编排具有明确角色、任务生命周期、移交协议和工作流程的多代理团队。适用于：(1) 设置2个以上具有不同专业化的代理团队，(2) 定义任务路由和生命周期（收件箱 → 规格说明 → 构建 → 审查 → 完成），(3) 创建代理之间的移交协议，(4) 建立审查和质量关口，(5) 管理代理之间的异步通信和工件共享。
运行具有清晰角色、结构化任务流和质量关口的团队生产手册。
一个构建者和一个审查者。最简单的有用团队。
编排者（你）—— 路由任务，跟踪状态，报告结果
构建代理 —— 执行工作，产出工件
1. 创建任务记录（文件、数据库或任务板）
2. 派生构建者，并提供：
- 任务 ID 和描述
- 工件输出路径
- 移交说明（要生产什么，放在哪里）
3. 完成后：审查工件，标记完成，报告
构建者生产工件 → 审查者检查 → 编排者交付或返回
这就是核心循环。下面的所有内容都在扩展这个模式。
每个代理都有一个主要角色。重叠会造成混乱。
| 角色 | 目的 | 模型指导 |
|---|---|---|
| 编排者 | 路由工作，跟踪状态，做出优先级决策 | 高推理能力模型（处理判断） |
| 构建者 | 生产工件 —— 代码、文档、配置 | 机械性工作可以使用成本效益高的模型 |
| 审查者 | 验证质量，对缺陷进行回退 | 高推理能力模型（捕获构建者遗漏的问题） |
| 运维 (Ops) | Cron 任务、站立会议、健康检查、调度 | 最便宜但可靠的模型 |
→ 定义新团队或添加代理时，阅读 references/team-setup.md。
每个任务都会经历定义好的生命周期：
收件箱 → 已分配 → 进行中 → 审查 → 完成 | 失败
规则：
→ 设计任务流或调试卡住的任务时，阅读 references/task-lifecycle.md。
当工作在代理之间传递时，移交消息包括：
糟糕的移交："完成了，检查文件。"
良好的移交："在 /shared/artifacts/auth/ 构建了认证模块。运行 npm test auth 进行验证。已知问题：速率限制尚未实现。下一步：审查者检查错误处理边缘情况。"
跨角色审查防止质量退化：
跳过审查步骤，质量会在 3-5 个任务内下降。每次都是如此。
→ 设置代理通信通道时，阅读 references/communication.md。 → 实现经过验证的多步骤工作流时，阅读 references/patterns.md。
| 文件 | 何时阅读... |
|---|---|
| team-setup.md | 定义代理、角色、模型、工作空间 |
| task-lifecycle.md | 设计任务状态、转换、评论 |
| communication.md | 设置异步/同步通信、工件路径 |
| patterns.md | 实现特定工作流（规格→构建→测试、并行研究、升级） |
代理做出了很好的工作，但你找不到它。总是在派生提示中指定精确的输出路径。使用具有可预测结构的共享工件目录。
"这是个小的变更，跳过审查。" 这样做三次，你就会有复合错误。每个工件至少要有一双没有生产它的眼睛来审查。
沉默的代理会造成协调盲点。要求在以下时候评论：开始、阻塞、移交、完成。如果代理沉默，假设它卡住了。
将基于浏览器的测试分配给没有浏览器访问权限的代理。将图像工作分配给仅文本模型。路由前检查能力。
编排者路由和跟踪 —— 它不构建。当你开始"快速做这一件事"的那一刻，你就失去了对团队其他部分的监督。
sessions_spawn。此技能适用于具有多次移交的持续工作流。此技能适用于 持续团队工作流 —— 代理在多个任务中相互依赖输出的重复协作模式。