智能体团队编排

用于运行多智能体团队的生产手册，包含明确角色、结构化任务流程和质量关卡。

快速入门：最小化双智能体团队

一个构建者与一个评审者。最简单实用的团队配置。

1. 角色定义

编排者（您）—— 路由任务、跟踪状态、汇报结果
构建智能体 —— 执行工作、产出成果物

2. 发起任务

1. 创建任务记录（文件、数据库或任务看板）
2. 启动构建者时需提供：
   - 任务ID与描述
   - 成果物输出路径
   - 交接说明（产出内容、存放位置）
3. 完成后：评审成果物、标记完成状态、生成报告

3. 添加评审者

构建者产出成果物 → 评审者检查 → 编排者发布或退回修改

这是核心循环流程。后续所有扩展均基于此模式。

核心概念

角色体系

每个智能体仅承担一个主要角色。角色重叠将导致混乱。

→阅读references/team-setup.md当定义新团队或添加代理时。

任务状态

每个任务都遵循一个定义的生命周期：

收件箱 → 已分配 → 进行中 → 审核 → 完成 | 失败

规则：

• 协调器负责状态转换——不要依赖代理自行更新其状态
• 每次转换都需要添加注释（谁、做了什么、为什么）
• 失败是有效的结束状态——记录原因并继续

→阅读references/task-lifecycle.md在设计任务流程或调试卡住的任务时。

交接

当工作在不同代理之间传递时，交接消息应包括：

1. 已完成的工作——变更/输出的摘要
2. 工件存放位置——确切的文件路径
3. 如何验证——测试命令或验收标准
4. 已知问题——任何未完成或有风险的事项
5. 下一步——接收代理的明确后续操作

不良交接："已完成，请检查文件。"良好的交接："认证模块已构建于/shared/artifacts/auth/。运行npm test auth进行验证。已知问题：限流功能尚未实现。下一步：审核者检查错误处理的边缘情况。"

审核

跨角色审核可防止质量下滑：

• 构建者审核规格—— "这可行吗？缺少什么？"
• 审核者检查构建—— "这符合规格吗？边缘情况呢？"
• 协调者审核优先级—— "当前做这项工作是合适的吗？"

跳过审核步骤，质量会在3-5个任务内下降。每次都是如此。

→阅读references/communication.md以设置智能体通信渠道。→阅读references/patterns.md以获取成熟的多步骤工作流程。

参考文件

常见陷阱

未指定明确的产物输出路径就启动任务

智能体完成了出色的工作，但你却找不到产出物。务必在启动指令中明确指定确切的输出路径。使用具有可预测结构的共享产物目录。

没有审查步骤 = 质量漂移

"这只是个小改动，跳过审查吧。"这样做三次，就会产生复合错误。每个产物至少应由非创建者本人审阅一次。

智能体未对任务进度进行评论

沉默的智能体会造成协调盲点。要求在以下节点进行评论：开始、遇到阻塞、交接、完成。如果智能体保持沉默，应假定其已停滞。

分配任务前未验证智能体能力

将基于浏览器的测试任务分配给无法访问浏览器的智能体。将图像工作分配给纯文本模型。在路由任务前检查其能力。

协调器执行具体工作

协调器负责路由和跟踪——它不负责构建。一旦你开始"快速处理这个小任务"，你就失去了对团队其他成员的监督。

何时不应使用此技能

• 单智能体设置——只需遵循标准的 AGENTS.md 规范。团队协调会增加单智能体不需要的开销。
• 一次性任务委派——直接使用sessions_spawn。此技能适用于涉及多次交接的持续性工作流程。
• 简单的问答路由——如果你只是将问题转发给专家，那只是一条消息，而非工作流程。

此技能适用于持续性团队工作流程——即智能体在多项任务中相互依赖产出的、反复出现的协作模式。