SkillRouter

## 核心定位 agent-team-orchestration 是一套面向多Agent协作的生产级编排框架，而非执行引擎。它聚焦于角色定义、任务生命周期管理、交接协议与质量门禁四个核心维度，适用于2人以上Agent团队的可持续协作场景。 ## 核心用法 1. 四角色模型：Orchestrator（调度员，高推理模型）、Builder（执行者，成本优先模型）、Reviewer（质检员，高推理模型）、Ops（运维机器人，最便宜可用模型）。角色重叠是首要忌讳。 2. 五态任务流：Inbox → Assigned → In Progress → Review → Done | Failed。Orchestrator独占状态机控制权，禁止Agent自更新状态。 3. 五要素交接协议：每次工作移交必须包含——完成内容摘要、产物精确路径、验证命令/验收标准、已知风险清单、下一步明确动作。示例对比鲜明：从敷衍的"Done, check files"升级为结构化信息包。 4. 三阶质量门禁：Builder预审规格可行性、Reviewer核验构建质量、Orchestrator终审优先级合理性。跳过Review环节将在3-5个任务内引发质量劣化。 ## 显著优点 - 防沉默机制：强制要求Agent在启动、阻塞、交接、完成四个节点添加注释，解决多Agent协作中的"黑箱"问题。 - 成本感知设计：明确区分高推理模型与成本效益模型的使用场景，避免资源浪费。 - 故障模式前置：列举5种常见陷阱（产物路径不清、跳过评审、Agent沉默、能力错配、调度员越位执行），均附具体后果描述。 - 边界清晰：明确排除单Agent、一次性任务、简单问答路由三种误用场景，降低认知负荷。 ## 潜在局限 - 纯文档约束：无强制执行的运行时机制，依赖Orchestrator的人工纪律维持。 - 同步假设隐含：未深入讨论分布式时钟、并发冲突、脑裂等分布式系统经典问题。 - 扩展性留白：4角色模型在10+Agent场景下的层级化调度（如子Orchestrator）未涉及。 ## 适合人群 - 已具备基础Agent使用经验，正从"单兵作战"向"团队协作"迁移的开发者 - 需要建立可重复、可审计的AI辅助工作流的技术负责人 - 关注成本控制的工程团队（文档明确建议模型分层选型） ## 常规风险 - 纪律衰减风险：框架效能高度依赖Orchestrator持续遵守"不亲自执行"原则，长期运行中易出现角色侵蚀。 - 评审疲劳："每个产物至少一双外部眼睛"在高压排期下易被主观妥协。 - T3来源提示：Skill来自社区个人开发者(arminnaimi)，无组织背书，建议结合内部安全策略复核文档建议。