团队智能体编排 是做什么的？
当智能体是像团队一样管理而非单一助手时，使用本技能。其目的是使基于团队的编排变得可靠：清晰的工作项、明确的所有权、智能体看板状态、分支隔离、控制面板可见性和合并门禁。
何时激活
- 任务跨越多个智能体、工具、工具集、分支或工作树。
- 用户提及团队编排、智能体看板、小队（squad）、指挥者（conductor）、控制面板、管理者（manager）、桌面应用、Zellij、tmux、Hermes、Devin、Codex、Claude Code 或多智能体工作。
- 项目需要在人员和智能体之间共享工作流状态。
- 现有的智能体扇出模式虽然产生输出，但生成的产物无法合并。
运行模型
将每个智能体视为一个拥有狭窄契约的队友：
- 所有者：对工作项负责的人或智能体。
- 范围：文件、分支、工具表面和禁止区域。
- 状态：待办（backlog）、就绪（ready）、运行中（running）、审查（review）、阻塞（blocked）、已合并（merged）或已归档（archived）。
- 证据：测试、截图、日志、审查记录或评估报告。
- 合并门禁：允许集成的确切条件。
智能体看板
当工作需要跨会话可见时，使用智能体看板。
| 列 | 含义 | 退出标准 |
|---|---|---|
| 待办（Backlog） | 候选工作项，尚未明确成形 | 编写验收标准 |
| 就绪（Ready） | 已成形并可分配 | 已分配所有者和分支/工作树 |
| 运行中（Running） | 智能体正在积极工作 | 交接产物和已更改的文件存在 |
| 审查（Review） | 工作完成但未合并 | 测试、差异审查和风险评估通过 |
| 阻塞（Blocked） | 需要外部输入或门禁失败 | 阻塞项具有所有者和下一步操作 |
| 已合并（Merged） | 已集成到主分支 | PR 已合并或本地主分支已更新 |
| 已归档（Archived） | 不再相关 | 记录原因 |
每个卡片应遵循此结构：
{
"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 的链接。
- 按所有者分组的阻塞项及其解除阻塞动作。
- 按门禁（而非直觉）指示的合并就绪状态。
- 应成为共享专业技能的可复用工作流候选。
在操作者能够回答以下问题之前，不要添加更多自动化：谁拥有这个？什么发生了变化？哪个门禁失败了？哪些内容可以安全合并？
动态工作流兼容性
当卡片需要动态工作流模式时：
- 将任务本地的工具集放在卡片所有者的管辖下。
- 将输入和输出存储在卡片上。
- 在从“运行中”转移到“审查”之前，需要进行一次评估。
- 仅在该工具集重复使用后，才将其提升为共享专业技能。
需关注的失败模式
- 智能体汤：许多智能体同时运行，但没有所有者或合并门禁。
- 不可见的工作：有用的输出仅存在于聊天记录中。
- 看板表演：看板存在，但卡片没有验收标准。
- 重叠写入：没有工作树隔离时，并行智能体编辑相同文件。
- 无产物产物：流程产生了文档，但没有可运行或可发布的成果。
输出标准
每次编排过程结束时，应产出：
- 看板/卡片的变更。
- 已合并或待合并的分支。
- 测试和评估证据。
- 带有所有者和下一步操作的阻塞项。
- 新的共享专业技能候选。