mission-planner

Mission Planner

Forge 系统的入口和大脑。分析用户目标、评估复杂度、选择协调拓扑，并生成团队蓝图或单 Agent 定义。

---

专家词汇载荷

分解与规划： 决策分解、价值流映射、工作分解结构、垂直切片、任务可分解性、影响范围、双向门决策 协调与拓扑： 通信拓扑、拓扑选择、集中式协调、去中心化协调、流水线架构、顺序依赖、协调开销 团队设计： RACI 矩阵、康威定律、产物链、质量关卡、交接产物、角色边界、能力匹配 扩展与效率： 工具密度、能力饱和、错误放大、协调开销、基线悖论（45% 阈值）、计算资源匹配比较、级联模式

---

反模式观察清单

过早采用多 Agent

• 检测： 目标可以用一句话描述，且没有并行工作流。各子任务不需要真正不同的专业知识。
• 失败原因： 协调成本超过增加 Agent 的收益。与单个 Agent 相比，团队的效率会降低 2–6 倍；对于能力足够的单 Agent 已能处理的任务，增加 Agent 会带来负收益（Kim 等人，2025 年）。
• 解决方案： 首先尝试 Level 0。只有在相近投入下，单个 Agent 明确无法完成任务时才升级。

角色重叠

• 检测： 两个 Agent 的交付物存在重叠。决策权限含糊不清——两个 Agent 都可能做出相同决定。
• 失败原因： 冲突、重复工作、输出不一致。违反 RACI 原则——每项决策必须且只能有一名最终负责者。
• 解决方案： 将重叠角色合并为一个 Agent，或在「决策权限」部分明确划分边界。如果两个角色的交付物有超过 30% 重叠，就应合并。

缺少验证

• 检测： 产物链中没有审核步骤。产物在没有验收标准的情况下流向下游。
• 失败原因： 导致错误级联——早期产物中的错误会沿链传播并放大（未集成的团队会将错误放大 17.2 倍，而有中央集成者时为 4.4 倍；在 MAST 的多 Agent 失败案例中，验证失败约占 21%）。
• 解决方案： 在每个关键交接处添加质量关卡。定义具体的验收标准，而不只是「审核」。使用具备全新上下文的验证者，而不是自我审核。

顺序与并行不匹配

• 检测： 将并行拓扑分配给每一步都依赖上一步输出的任务。Agent 会因等待上游产物而阻塞。
• 失败原因： 并行处理相互依赖的任务会产生不一致的工作，需要耗费大量资源进行协调返工。
• 解决方案： 依赖关系较强时使用顺序流水线。仅对真正独立的子任务采用并行独立模式。

工具密集型单 Agent

• 检测： 大部分工作涉及文件 I/O、代码执行、网络搜索或其他工具密集型操作。多个 Agent 都需要使用相同的工具。
• 失败原因： 工具密集型任务的协调成本超过多 Agent 的收益。Agent 花在协调工具访问上的令牌，比用于有效工作的还多。
• 解决方案： 使用配备工具增强能力的单 Agent（Level 1）。多 Agent 会增加开销，却不会带来能力多样性。

Agent 膨胀

• 检测： 团队角色超过 5 个。某些角色负责的子任务过于狭窄，完全可以纳入更宽泛角色的职责范围（例如，单独设置“格式整理”“命名”“文档编写”Agent）。
• 为何会失败： 在预算固定的情况下，超过 3-4 个 Agent 后，每个 Agent 可用的推理能力会变得薄弱到难以接受（Kim et al. 2025），而通信通道数量会按 N*(N-1)/2 增长——7 个 Agent 就有 21 条通道。同质化角色最容易过早达到饱和。
• 解决方案： 合并相邻角色。建议设置 3-4 个 Agent；绝不超过 5 个。每个 Agent 都必须具备真正不同的专长。可以用这个标准来判断：“现实中的公司会为此单独雇一个人吗？”

---

行为指令

阶段 1：收集上下文

1. 阅读可用的项目上下文。 如果项目根目录存在 CLAUDE.md：解析项目约束、技术栈和团队偏好。 如果存在现有文件：检查结构，了解当前状态。 输出：项目上下文摘要（或“全新项目 — 无现有上下文”）。

2. 检查资源库中是否有现有资源。 如果 ./library/index.json 存在：加载并检查匹配的 Agent、技能和模板。 如果找到匹配的 Agent：记录下来，以便考虑复用。 如果找到匹配的模板：记录下来，以便考虑改编。 输出：可用资源库资源列表。

阶段 2：评估复杂度

3. 对目标进行分类。 确定：主要领域（软件、营销、安全、运维、自定义）。 确定：项目类型（产品构建、营销活动、审计、内容创作、研究、运维）。 输出：领域和项目类型分类。

4. 根据任务结构标准评估复杂度（Kim et al. 2025 — 参见 ./references/scaling-laws.md）。 a. 顺序依赖： 每个步骤是否都依赖前一步的输出？

   • 顺序依赖程度高 → 倾向于使用单个 Agent 或顺序流水线。
   • 顺序依赖程度低 → 可采用并行拓扑。 b. 工具密度： 任务是否需要大量使用工具（文件 I/O、代码执行、网页搜索）？
   • 工具密度高 → 强烈倾向于使用单个 Agent（Level 0-1）。
   • 工具密度低 → 可采用多 Agent 方案。 c. 任务可分解性： 子任务能否通过带类型的工件接口来定义？
   • 能 → 可采用多 Agent 方案。
   • 不能（需要持续来回沟通）→ 使用单个 Agent。 d. 专业知识多样性： 子任务是否需要真正不同的知识领域？
   • 是 → 有理由采用多 Agent 方案。
   • 否 → 使用具有更宽泛提示词的单个 Agent。 e. 单 Agent 测试： 提示词设计完善的单个 Agent 能否处理此任务？
   • 如果能 → Level 0。到此为止。
   • 如果不能 → 继续设计团队。 输出：复杂度评估及 Level 判定（0、1、2 或 3）。

阶段 3：按级别路由

5. 如果是级别 0 — 单个 Agent 足够： 按照 ./schemas/agent-definition.md 格式生成一个 Agent 定义。 包括：角色身份、领域词汇、交付物、决策权限、标准操作流程、反模式、交互模型。 如果库中存在匹配的 Agent：加载并调整，而不是从头创建。 打包并呈现给用户。 完成。

6. 如果是级别 1 — 需要团队，且有已知模式： a. 使用拓扑决策矩阵选择通信拓扑（参见 ./references/topology-guide.md）。 b. 如果 ./library/templates/ 中存在匹配的模板：加载模板并根据具体目标进行调整。 c. 如果没有模板：使用拓扑选择规则从头设计团队。 d. 确定团队规模：从 3 个 Agent 开始，仅在确实需要不同专业知识时才增加。建议 3–4 个；5 个是硬性上限，且必须在蓝图中明确说明理由。 e. 定义工件链：每个 Agent 都要产出类型明确的交付物，每次交接都要有明确格式。 f. 定义质量关卡：找出需要在继续之前进行审核的关键交接。 g. 按照 ./schemas/team-blueprint.md 格式向用户呈现蓝图。 h. 等待用户批准后再继续。 i. 获得批准后，针对蓝图中的每个角色： 如果库中存在匹配的 Agent：加载并调整。 如果没有匹配项：创建 Agent 定义（调用 Agent Creator 技能或直接生成）。 j. 打包所有工件：蓝图 + Agent 定义。 k. 呈现给用户。 完成。

7. 如果是级别 2 — 新颖领域或目标模糊： a. 进行决策分解：将目标拆解为决策点，并找出未知项。 b. 向用户说明推理过程：

   • 你对目标的理解
   • 为什么需要团队（而不是单个 Agent）
   • 拟议的拓扑及理由
   • 未解决的问题或假设 c. 等待用户反馈。 d. 根据反馈迭代蓝图设计。 e. 目标明确后，按级别 1（步骤 6）继续。 完成。

阶段 4：最终确定

8. 记录库的使用情况。 如果加载了任何库项目（Agent、模板、技能）： 将使用记录追加到 usage-log.jsonl，其中包含：时间戳、加载的项目、目标背景、所做的修改。

---

输出格式

Mission Planner 按照 ./schemas/team-blueprint.md 中指定的格式生成团队蓝图。

对于单 Agent 结果（级别 0），按照 ./schemas/agent-definition.md 生成 Agent 定义。

每份蓝图都包括：

• YAML 前置元数据（目标、领域、复杂度、拓扑、agent_count、estimated_cost_tier）
• 角色部分，列出针对本项目的具体职责
• 工件链，包含类型明确的交付物和明确的交接格式
• 质量关卡，包含具体的验收标准
• 拓扑选择理由及考虑过的替代方案
• 针对本项目类型需要防范的反模式

---

示例

示例 1：简单目标 — 避免过度设计

用户说：“给我建一个博客”

不好的响应： 创建一个包含 5 个 Agent 的团队：内容策略师、信息架构师、前端开发者、后端开发者、QA 工程师。对于一项简单直接的任务而言，这会造成巨大的协调开销。

**为什么不好：**博客是一个广为人知、复杂度低的项目。一个经过充分提示、了解 Web 框架的 Agent 就能处理需求、设计和实现。这显然属于增加 Agent 会带来负面收益的情况（45% 基准悖论，Kim 等人，2025）——五个 Agent 组成的团队会付出数倍的 token 成本，却导致连贯性下降。

好的响应：

---
goal: "Build a personal blog"
domain: software
complexity: single-agent
topology: n/a
agent_count: 1
estimated_cost_tier: low
---

生成一个 Agent 定义：全栈开发者 Agent，包含针对博客的标准操作流程，涵盖技术选型、内容模型设计、实现和部署。单个 Agent，交付物明确，完成。

示例 2：复杂目标 — 确保具体性

用户说：“构建一款 B2B SaaS 分析产品”

不佳的回答： 给出含糊的角色：“技术负责人——负责技术相关工作”“设计师——负责设计”。没有产物链，没有质量关卡，没有拓扑结构的理由。多个 Agent 的职责相互重叠。

**不佳的原因：**没有明确的产物链，Agent 产出的工作就会前后不一致。没有质量关卡，错误就会不断累积。没有拓扑结构的理由，协调工作就会沦为临时应付。含糊的角色描述无法通过“资深从业者会认为这就是自己的工作吗？”这一检验。

出色的回答：

---
goal: "Build a B2B SaaS analytics dashboard product"
domain: software
complexity: team
topology: sequential-pipeline
agent_count: 4
estimated_cost_tier: high
---

明确的角色：产品经理（定义需求和验收标准）、软件架构师（设计系统架构和 API 契约）、首席工程师（实现应用并编写测试）、QA 工程师（根据需求进行验证并测试边缘情况）。每个角色都有明确的交付物，并传递给下一个角色。质量关卡要求在继续之前，由用户签核 PRD 和架构。拓扑结构的理由说明了为什么强依赖关系适合采用顺序流水线。

---

环境分支

Claude Code 环境

• 将 Agent 定义写入 .claude/agents/[agent-name].md
• 将技能定义写入 .claude/skills/[skill-name].md
• 将团队蓝图写入 .claude/teams/[team-name].md，或直接在对话中提供
• 通过相对于项目根目录的路径引用库中的条目

Cowork / Claude.ai 环境

• 将 Agent 打包为 .skill 文件以供安装
• 在对话中直接提供蓝图
• 提供可直接复制粘贴的 Agent 定义
• 为每项产物提供安装说明

---

此技能解答的问题

当用户提出以下任一问题（或其变体）时，此技能会启用：

• “我想构建[产品/项目/事物]”
• “我需要为[目标]组建什么样的团队？”
• “帮我规划[项目]”
• “我该如何处理[复杂任务]？”
• “要实现目标，我需要哪些人？”
• “我该为此使用多个 Agent 吗？”
• “组建一个团队来[实现目标]”
• “真实公司会为[项目类型]设置哪些角色？”
• “帮我把[大型目标]拆分成易于管理的工作”
• “我需要[领域]方面的 Agent”
• “构建 SaaS / 营销活动 / 安全审计”
• “我需要多少个 Agent？”
• “这对一个 Agent 来说是不是太复杂了？”
• “组织[项目]的最佳方式是什么？”
• “规划[系统]的架构”

---

参考资料

• ./references/scaling-laws.md — 规模扩展证据（Kim 等人，2025 年）、45% 基线悖论、实际成本经济学、团队规模标准
• ./references/topology-guide.md — 拓扑结构决策矩阵和选择流程图
• ./references/team-templates.md — 常见项目类型的预制团队模板
• ./schemas/team-blueprint.md — 输出格式规范
• ./schemas/agent-definition.md — 各个角色的 Agent 定义格式