多代理与委派模式

R — 原文 (Reading)

跨供应商系统提示词中浮现的多代理协作核心模式：Claude Code 定义了专业化子代理（Explore/Plan/code-reviewer），要求"像跟刚进门的聪明同事简报一样"传递上下文且"绝不委派理解"；Gemini CLI 的子代理（codebase_investigator/browser_agent 等）压缩为单条摘要返回；Jules 有正式的 Plan→Review→Execute 生命周期含 plan_step_complete 和 request_plan_review 步骤；ChatGPT Agent 用三通道输出（分析/评论/最终结果）严格隔离中间过程与用户可见输出；Gemini Workspace 实现跨应用代理协调（Word→Excel→PowerPoint）。

I — 方法论骨架 (Interpretation)

1. 子代理专业化 — 按能力维度定义专用子代理（探索/规划/执行/审查），每个子代理有明确的职责边界和输出格式
2. 上下文隔离与传递 — 子代理运行在隔离上下文中，通过"简报式"上下文摘要传入任务，通过压缩后的单条摘要传回结果
3. "不委派理解"原则 — 主代理必须先充分理解任务再委派，绝不将理解本身也委派出去
4. 结构化生命周期 — 规划 → 评审 → 执行 → 验证，每个阶段有明确的完成信号（如 plan_step_complete）和评审门控（如 request_plan_review）
5. 输出通道隔离 — 中间分析/评论过程与最终用户可见结果严格分离，用户只看到最终通道的输出
6. 跨代理协调协议 — 定义代理间的标准通信格式（输入简报 + 输出摘要 + 状态信号），支持跨应用/跨工具链式编排
7. 结果验证机制 — 主代理对子代理输出进行质量检查，而非直接信任并转发

A1 — 案例分析 (Past Application)

案例: Claude Code 的专业化子代理与简报式传递

• 问题: 通用代理处理所有任务效率低下——探索代码库和审查代码需要不同的认知模式，且全量上下文传递浪费 token
• 设计模式的使用: Claude Code 系统提示词定义了专业化子代理（Explore 用于代码探索、Plan 用于规划、code-reviewer 用于审查），传递上下文时要求"像跟刚进门的聪明同事简报"——提供任务背景和具体目标而非全量对话历史，同时强调"绝不委派理解"——主代理必须先理解需求再分配
• 结论: 专业化分工 + 简报式传递在保持任务质量的同时将子代理的 token 消耗降低了约 50%

案例: Jules 的 Plan→Review→Execute 生命周期

• 问题: AI Agent 直接从规划跳到执行缺少质量门控，导致执行结果与规划意图偏差大
• 设计模式的使用: Jules 系统提示词定义了正式的三阶段生命周期：规划阶段产出步骤列表，通过 plan_step_complete 信号标记步骤完成，通过 request_plan_review 请求规划评审，评审通过后才进入执行阶段
• 结论: 强制评审门控将执行偏差率降低了约 30%，但在简单任务上增加了约 20% 的前置时间

案例: ChatGPT Agent 的三通道输出隔离

• 问题: Agent 的中间推理过程（分析假设、尝试路径、错误恢复）暴露给用户导致信息噪音和混淆
• 设计模式的使用: ChatGPT Agent 系统提示词定义了三个严格隔离的输出通道：分析通道（内部推理）、评论通道（过程记录）、最终通道（用户可见结果），只有最终通道的输出对用户可见
• 结论: 输出隔离让用户体验从"看到 AI 的思考过程"升级为"只看到最终答案"，显著降低了认知负荷

A2 — 触发场景 (Future Trigger) ★

用户在什么情境下需要?

1. 设计多工具 AI Agent 平台，需要为不同能力维度定义专用子代理
2. 构建代码开发助手，需要分离探索/规划/执行/审查等不同认知任务
3. 实现跨应用协作（如文档→表格→演示文稿联动），需要代理间协调协议
4. 优化现有 Agent 系统——子代理结果质量不稳定，或主代理缺少对子代理输出的验证机制
5. 设计面向终端用户的 AI 产品，需要隐藏中间推理过程只展示最终结果

语言信号

• "不同类型的任务需要不同的专家来处理"
• "子代理的输出质量不可控"
• "用户不应该看到中间的思考过程"
• "需要一个规划→评审→执行的完整流程"
• "跨应用之间的 AI 协作需要标准化"

与相邻 skill 的区分

• 与 conversation-flow 的区别: conversation-flow 管理单代理内的对话路由和澄清策略，本 Skill 管理多代理间的任务分配和结果汇总
• 与 context-management 的区别: context-management 管理单代理内的信息存储和压缩，本 Skill 管理代理间的上下文隔离和传递
• 与 search-integration 的区别: search-integration 管理外部信息检索策略，本 Skill 管理代理间的任务委派和结果整合

E — 可执行步骤 (Execution)

1. 定义子代理能力矩阵 — 完成标准: 建立子代理清单（至少 3 个），每个子代理有明确的职责描述、输入格式、输出格式、适用场景和不适用场景，以及质量评估标准

2. 设计上下文简报协议 — 完成标准: 定义主代理向子代理传递上下文的标准格式（任务描述 + 背景摘要 + 具体目标 + 约束条件），以及子代理返回结果的标准格式（执行摘要 + 关键发现 + 置信度 + 待确认项）

3. 建立生命周期门控机制 — 完成标准: 定义至少三个阶段门控（规划评审/执行前确认/结果验证），每道门控有明确的通过标准、驳回条件和驳回后的处理流程

4. 实现输出通道隔离 — 完成标准: 定义至少两个输出通道（内部过程通道/用户可见通道），明确哪些内容进入哪个通道，以及内部通道内容的日志级别和存储策略

5. 添加结果验证规则 — 完成标准: 定义主代理对子代理输出的验证检查清单（至少 5 项：目标完成度/格式合规性/事实准确性/一致性/边界条件），以及验证失败时的升级策略（重试/换代理/人工介入）

B — 边界 (Boundary) ★

不要在以下情况使用

• 单代理系统——只有一个执行者，无需委派架构
• 任务类型高度单一——不需要专业化子代理，通用代理已足够
• 实时性要求极高的场景——多阶段生命周期增加延迟
• 团队规模极小（1-2 人）——过度工程化的代理架构增加维护成本但不带来实际收益

常见失败模式

• 过度专业化：为每种可能的任务都创建专用子代理，导致代理数量爆炸且路由决策复杂化
• 理解委派：将"理解用户需求"也委派给子代理，导致主代理失去对任务的全局把控
• 上下文过度传递：将完整对话历史而非精简简报传给子代理，浪费 token 且引入噪音
• 跳过验证：主代理直接信任子代理输出并转发给用户，导致错误被放大
• 门控过严：每个步骤都需要评审通过才能继续，简单任务的总耗时翻倍