团队智能体编排 是做什么的？
当智能体像团队而非单个助手一样被管理时，使用此技能。其目的是使基于团队的编排可靠：明确的工作项、明确的所有权、智能体看板状态、分支隔离、控制面板可见性和合并门控。
何时激活
- 任务涉及多个智能体、工具、操控程序、分支或工作树。
- 用户提及团队编排、智能体看板、小队、指挥、控制面板、经理、桌面应用、Zellij、tmux、Hermes、Devin、Codex、Claude Code 或多智能体工作。
- 项目需要跨人员和智能体共享工作流状态。
- 现有的智能体扇出正在产生输出，但产物不可合并。
运作模式
将每个智能体视为具有狭窄契约的队友：
- 负责人：对工作项负责的个人或智能体。
- 范围：文件、分支、工具界面和禁止区域。
- 状态：积压、就绪、运行中、审查中、已阻塞、已合并或已归档。
- 证据：测试、屏幕截图、日志、审查笔记或评估报告。
- 合并门控：允许集成的确切条件。
智能体看板
当工作必须在会话之间保持可见时，使用智能体看板。
| 列 | 含义 | 退出标准 |
|---|---|---|
| 积压 | 候选工作项，尚未成形 | 验收标准已编写 |
| 就绪 | 已成形并可分配 | 负责人和分支/工作树已分配 |
| 运行中 | 智能体正在积极工作 | 交接产物和已更改的文件存在 |
| 审查中 | 工作已完成但尚未合并 | 测试、差异审查和风险检查通过 |
| 已阻塞 | 需要外部输入或门控失败 | 阻塞项有负责人和下一步行动 |
| 已合并 | 已集成到主线 | PR 已合并或本地主线已更新 |
| 已归档 | 不再相关 | 原因已记录 |
每张卡片应遵循此模式：
{
"id": "agent-card-001",
"title": "构建动态工作流技能",
"owner": "codex",
"state": "running",
"branch": "product/dynamic-workflow-team-orchestration",
"worktree": ".",
"acceptance": [
"技能存在",
"测试覆盖所需概念",
"内容产物包含视频和文章角度"
],
"merge_gate": "lint、重点测试和目录检查通过",
"handoff": "path/to/handoff.md"
}
基于团队的编排流程
- 塑造看板：将模糊的雄心转化为带有负责人和合并门控的工作项。
- 选择执行模式：单智能体、动态工作流模式、dmux/tmux、工作树扇出或外部桌面编排器。
- 分配边界：每张卡片一个负责人，明确文件范围，并且在没有集成者的情况下不允许重叠写入。
- 运行智能体：每个智能体编写证据和交接笔记，而不仅仅是代码。
- 按序审查：先测试，然后差异审查，接着是安全/风险检查，最后是内容/产品润色。
- 谨慎合并：一个集成者解决冲突并更新控制面板或状态产物。
- 提取可复用技能：如果卡片模式重复出现，将其推广到
skills/。
控制面板要求
一个好的团队编排控制面板应显示：
- 活跃的工作项及其智能体看板状态。
- 负责人、操控程序、分支、工作树和最后心跳。
- 指向交接产物、测试、屏幕截图和 PR 的链接。
- 按负责人和解除阻塞操作分组的阻塞项。
- 基于门控而非直觉的合并准备状态。
- 应成为共享技能的可复用工作流候选。
在操作者能回答以下问题之前，不要添加更多自动化：谁拥有这个？什么改变了？什么门控失败了？什么可以安全合并？
动态工作流兼容性
当卡片需要动态工作流模式时：
- 将任务本地的操控程序置于卡片负责人之下。
- 在卡片上存储输入和输出。
- 在从“运行中”移动到“审查中”之前，需要一次评估。
- 仅在重复使用后，才将操控程序推广为共享技能。
需注意的故障模式
- 智能体混乱：许多智能体在运行，但没有负责人或合并门控。
- 隐形工作：有用的输出仅存在于聊天记录中。
- 看板形式主义：存在看板，但卡片没有验收标准。
- 重叠写入：并行智能体在没有工作树的情况下编辑相同文件。
- 无产品产物：过程产生文档，但没有可运行或可发布的表面。
输出标准
每次编排流程完成时，需提供：
- 看板/卡片变更。
- 已合并或待处理的分支。
- 测试和评估证据。
- 带有负责人和下一步行动的阻塞项。
- 新的共享技能候选。