概述
Agent Team Orchestration 是一套用于运行多智能体团队的生产级操作手册（playbook），目标是以清晰的角色分工、结构化的任务流转和明确的质量门禁来组织多个智能体协作。该技能用于持续性的团队工作流，即智能体在多个任务中相互依赖彼此产出的反复协作模式。
主要能力
角色定义
资料指出，每个智能体应有一个主要角色，角色重叠会导致混乱。资料列出的角色及说明如下：
- Orchestrator（编排者）：路由工作、跟踪状态、做出优先级判断。模型建议使用高推理能力模型（负责判断）。
- Builder（构建者）：产出交付物，如代码、文档、配置。对于机械性工作可使用成本更低的模型。
- Reviewer（审查者）：验证质量、对缺口提出异议。模型建议使用高推理能力模型（捕捉构建者遗漏的问题）。
- Ops（运维）：定时任务、站会、健康检查、分派。使用可靠的前提下最便宜的模型。
资料建议在定义新团队或新增智能体时阅读 references/team-setup.md。
任务状态
每个任务经过定义好的生命周期：
Inbox → Assigned → In Progress → Review → Done | Failed
规则：
- 编排者拥有状态转换权——不要依赖智能体自行更新状态。
- 每次转换都要有评论（谁、什么、为什么）。
- Failed 是合法的终态——记录原因后继续推进。
资料建议在设计任务流或排查卡住的任务时阅读 references/task-lifecycle.md。
交接（Handoffs）
当工作在智能体之间传递时，交接消息应包含：
- 完成了什么：变更/输出的摘要。
- 产物在哪里：确切文件路径。
- 如何验证：测试命令或验收标准。
- 已知问题：任何未完成或有风险之处。
- 下一步是什么：接收方智能体明确的下一步动作。
资料给出的正反示例：
- 反例："Done, check the files."
- 正例："Built auth module at /shared/artifacts/auth/. Run npm test auth to verify. Known issue: rate limiting not implemented yet. Next: reviewer checks error handling edge cases."
审查（Reviews）
跨角色审查可防止质量漂移：
- 构建者审查规格——"这可行吗？缺了什么？"
- 审查者检查构建成果——"是否符合规格？边界情况如何？"
- 编排者审查优先级——"现在做这件事对吗？"
资料强调：跳过审查步骤，质量会在 3-5 个任务内退化，“每次都是如此”。
资料建议在建立智能体通信通道时阅读 references/communication.md，在实现特定的多步骤工作流（规格→构建→测试、并行研究、升级）时阅读 references/patterns.md。
使用方式
快速开始：最小双智能体团队
一个构建者加一个审查者，即最简单可用的团队。
1. 定义角色
- Orchestrator（你）——路由任务、跟踪状态、报告结果
- Builder agent——执行工作、产出交付物
2. 派生（Spawn）一个任务
- 创建任务记录（文件、数据库或任务看板）。
- 派生构建者，带上：
- 任务 ID 和描述
- 交付物输出路径
- 交接说明（要产出什么、放在哪里）
- 完成后：审查交付物、标记完成、报告。
3. 增加审查者
构建者产出交付物 → 审查者检查 → 编排者交付或退回。
资料称这就是核心循环，下文所有内容都是对这一模式的扩展。
适用场景
适用于持续性团队工作流——即智能体在多个任务中依赖彼此产出、反复协作的模式。
限制与不适用场景
资料明确指出在以下情况不应使用本技能：
- 单智能体配置：只需遵循标准的 AGENTS.md 约定即可。团队编排会增加单智能体不需要的开销。
- 一次性任务委派：直接使用 sessions_spawn。本技能面向的是有多次交接的持续性工作流。
- 简单问题路由：如果只是把问题转发给专家，那是一条消息，而不是工作流。
常见陷阱（Common Pitfalls）
- 派生时未指定明确的交付物输出路径：智能体产出很棒的工作，但你找不到它。始终在派生提示中指定确切的输出路径，使用结构可预测的共享产物目录。
- 没有审查步骤等于质量漂移："改动很小，跳过审查吧。"这样做三次就会产生累积错误。每件交付物至少要有一次非产出者的眼睛检查。
- 智能体不评论任务进度：沉默的智能体会造成协调盲区。要求在以下时点评论：开始、遇到阻塞、交接、完成。如果智能体沉默，就假定它卡住了。
- 分配前未核实智能体能力：把浏览器测试分配给没有浏览器访问权限的智能体；把图像工作分配给纯文本模型。分配前先核实能力。
- 编排者亲自做执行工作：编排者的职责是路由和跟踪，而不是构建。一旦开始"就快速做这一件事"，就会失去对团队其余部分的监督。
参考资料文件
资料列出的参考文件及其阅读时机：
- team-setup.md：定义智能体、角色、模型、工作区时阅读。
- task-lifecycle.md：设计任务状态、转换、评论时阅读。
- communication.md：建立异步/同步通信、产物路径时阅读。
- patterns.md：实现特定工作流（规格→构建→测试、并行研究、升级）时阅读。
（上述参考文件的正文内容未在资料中提供。）