mcpField
W
wf-planning-fusion-optimizer

wf-planning-fusion-optimizer

github.com/adobe开发31845 次安装1 天前更新
代码仓库

关于 wf-planning-fusion-optimizer

用于只读审查 Workfront Fusion 场景导出蓝图的技能，针对 Workfront Planning 连接器分析结构问题。它在无需连接工作区的情况下，按优先级报告运行时间、操作消耗和 API 调用量的影响因素；连接 Workfront Planning MCP 后还可选做实例级架构检查。

主要功能

  1. 01只读蓝图分析
  2. 02识别 Planning 专用连接器
  3. 03按优先级呈现性能问题
  4. 04可选调用构成数据
  5. 05可选 MCP 架构补充检查

适用场景

  1. 01审查运行缓慢的 Planning 场景
  2. 02调查操作数或配额消耗
  3. 03评估 API 调用量及 429 风险
  4. 04检查复制或同步蓝图

MCP 相关

基础分析器无需 MCP 连接即可处理导出蓝图。若有 Workfront Planning MCP，可解析 ID 并核验建议的架构可行性；此补充检查为只读。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/adobe/skills --skill wf-planning-fusion-optimizer

安装后在 Claude Code 中输入/wf-planning-fusion-optimizer确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

README.md
evals/
evals.json
references/
findings.md
mcp-enrichment.md
scripts/
analyze_blueprint.py

详细介绍

Workfront Planning + Fusion 场景优化器

功能说明

接收一个或多个使用 Workfront Planning（Maestro）连接器的 Fusion 场景蓝图导出文件（.json），并生成一份只读评估报告，按优先级列出影响场景性能的因素：运行时间、消耗的操作数和 API 调用量（这决定了速率限制触发 429 的情况）。它只生成报告，绝不会修改蓝图，也不需要访问实时工作区。

目标不只是解决速率限制问题。在 Fusion 中，每次模块执行都会计为一次操作；操作会消耗运行时间和配额，而循环嵌套会让这些消耗成倍增加。因此，同一组结构性修复通常可以同时提升速度、降低成本，并增加速率限制余量。429 只是同一类低效问题的症状之一。

适用范围：仅限 Workfront Planning

此评估器专为 Workfront Planning 连接器（workfront-maestro 模块）设计，并非通用 Fusion 优化器。如果蓝图中没有 Planning 模块（例如 Salesforce 到 Slack 的场景），分析器会检测到这一点，并清楚地返回“不适用”结果，列出检测到的连接器，而不会假装对其进行了评估。不要将它用于非 Planning 场景；请告知用户它仅适用于 Planning，并可在用户需要时另行提供通用 Fusion 建议，无需使用此技能。

何时使用

只要讨论的是 Workfront Planning Fusion 场景，且用户关心速度、运行时间、超时、操作数／配额、成本、可靠性或 API 限制，就使用它，即使用户没有提到“优化”或“429”。复制、同步和迁移场景受益最大，因为它们会遍历层级结构并产生大量调用，但它适用于任何 Planning 场景。

运行方法

  1. 获取导出的蓝图文件（Fusion 场景蓝图导出文件，.json）。 可以同时评估多个文件。

  2. 运行：

    python scripts/analyze_blueprint.py <blueprint.json> [<blueprint2.json> ...]

    如需结合实测数据进行分析，可提供每次请求的调用导出文件（CSV，包含 Resource、Method、Status Code 列，Duration 列可选）：

    python scripts/analyze_blueprint.py <blueprint.json> --callmix <calls.csv>

    添加 --json 可生成机器可读结果。

  3. 将 Markdown 报告作为交付内容，并按照报告返回的顺序呈现问题（影响最大的问题排在最前）。不要编造脚本未提供的数字。

如何解读问题

所有内容都应围绕一个模型展开：调用量和操作数等于模块数量乘以每个模块的运行次数，而迭代深度会起到放大作用。 在场景顶层执行的 GET 开销很低，但在多层循环中执行时开销就很高。说明每条发现可以改善的方面：调用量、操作数、运行时间、可靠性或吞吐量。因此，报告会为每条发现标注“改善方面：”。

请尽早说明一点：没有批量读取端点。 读取数据只能使用 Search 和单条 GET；批量操作仅适用于写入。因此，提高限制或批量写入都无法解决读取密集型场景的问题，只有减少读取次数并扩大每次读取的范围才有帮助。基于这一点，应优先介绍读取相关的发现（F1、F2、F3）。

发现代码、依据和建议修复方法见 references/findings.md。需要了解某个代码的完整说明时，请阅读该文件；每条发现都已在报告中附上一条简短建议。

可选：使用已连接的 Workfront Planning MCP 补充信息

静态分析器是基础工具，无需连接。但如果会话中已连接 Workfront Planning MCP（大多数使用 Planning 的客户都有一个），请使用它，让建议贴合具体实例，而非泛泛而谈。它可以将蓝图中的不透明 ID（Rt69e105...、F6a2010...）转换为真实的记录类型和字段名称。更重要的是，它能通过实时架构确认每项读取合并问题在实际中是否可行：子记录类型是否有可筛选的父记录引用，以及逐条记录 GET 获取的字段是否已作为查找字段包含在搜索结果中。否则，这项检查需要用户粘贴示例才能完成。

运行 python scripts/analyze_blueprint.py <blueprint.json> --ids，列出蓝图引用的记录类型和字段 ID，然后通过 Planning MCP 解析这些 ID。完整工作流以及一项重要注意事项（MCP 验证的是架构和可行性，而不是 Fusion 连接器输出的嵌套结构）见 references/mcp-enrichment.md。Planning MCP 可用时请阅读该文件。此步骤严格只读；如果未连接 MCP，请跳过：静态报告本身即可独立使用。

注意事项

  • 这是对导出文件进行的启发式结构审查，并非实时测量。请明确说明这一点。
  • 引用和记录类型 ID 因工作区实例而异；具体修复方案必须根据客户的实时架构进行解析。
  • 建议在优化前后测量一次有代表性的运行，并在推广前于沙盒中验证。
  • 不要承诺提升百分比。指出成本所在，让实际的优化前后测量得出具体数值。
  • 基于休眠的限流（P1）必须在读取路径缩减后按顺序移除，否则请求突发可能会加剧。应解释这个顺序，而不只是说“移除它”。
  • 使用 --callmix 时，占比通常是抽样所得：应将其视为比例。

评论

支持 Markdown