agent-team-orchestration

核心用法

Agent Team Orchestration 是一套面向多代理协作的生产级编排手册，适用于需要 2 个以上专业代理持续协作的场景。其核心用法围绕四个维度展开：

角色定义：明确划分 Orchestrator（路由与决策）、Builder（执行产出）、Reviewer（质量验证）、Ops（运维调度）四类角色，避免职能重叠导致的协调混乱。

任务生命周期管理：采用 Inbox → Assigned → In Progress → Review → Done/Failed 的标准状态机，由 Orchestrator 统一控制状态流转，并要求每次状态变更附带注释说明。

交接协议：工作传递时必须包含五项要素——已完成内容摘要、产物精确路径、验证方法、已知问题、下一步行动，杜绝"做完了，看文件吧"式的模糊交接。

质量门禁：建立跨角色审查机制，Builder 审规格可行性、Reviewer 核实现完整性、Orchestrator 把控优先级，跳过审查将在 3-5 个任务内引发质量劣化。

显著优点

1. 架构清晰：将复杂的多代理协作抽象为可复用的模式语言，降低团队设计成本
2. 风险前置：通过明确的交接协议和审查节点，在流程层面预防常见协作失效
3. 成本优化：支持按角色配置不同推理能力的模型（Orchestrator/Reviewer 用高推理模型，Builder/Ops 用经济型模型）
4. 可扩展性：从最小 2 人团队到复杂多代理系统，均基于同一套核心循环构建
5. 文档完备：配套 4 份详细参考文档覆盖团队搭建、任务流转、沟通模式、工作流模式

潜在缺点与局限性

1. overhead 成本：对于单代理或一次性任务，引入完整的编排流程反而降低效率
2. 路径依赖：文档中的示例路径（如 /shared/artifacts//）需根据实际环境调整，直接套用可能导致产物丢失
3. 沉默代理风险：若未严格执行"启动-阻塞-交接-完成"四节点注释要求，Orchestrator 将失去对任务状态的感知
4. 能力匹配责任：系统不自动验证代理能力（如浏览器访问、图像处理），错误分配需人工预防
5. Orchestrator 角色侵蚀：文档反复强调 Orchestrator 不得参与执行，但实践中"顺手改一下"的诱惑难以杜绝

适合的目标群体

• 需要持续运行多代理协作的研发团队（如 AI 编程助手团队、自动化内容生产线）
• 追求可审计、可复现任务流转的企业级应用场景
• 希望降低多代理系统协调复杂度的技术负责人
• 正在从单代理实验向生产级多代理系统迁移的开发者

使用风险

性能风险：多代理串行工作流可能引入显著延迟，复杂任务需考虑并行模式（见 patterns.md）。

依赖风险：该 Skill 本身为零依赖纯文档，但实际落地时需配套任务看板/数据库、共享存储、代理通信机制等基础设施。

人为执行风险：文档规范的有效性高度依赖团队执行力，状态更新、注释要求、审查节点均需纪律保障。

模型成本误判：虽支持经济型模型用于 Builder/Ops，但错误地将高推理任务分配给低成本模型将导致返工成本超过模型节省费用。