name: team-agent-orchestration
description: 使用工作项、所有权、代理看板、合并门禁和控制面板交接来运行基于团队的代理小队编排。
origin: ECC

团队代理编排

当代理以团队形式而非单个助手进行管理时，应使用此技能。其目标是使基于团队的编排可靠：清晰的工作项、明确的责任人、代理看板状态、分支隔离、控制面板可见性以及合并门。

何时激活

• 任务涉及多个代理、工具、框架、分支或工作树。
• 用户提及团队编排、代理看板、小组、指挥、控制面板、管理器、桌面应用、Zellij、tmux、Hermes、Devin、Codex、Claude Code 或多代理工作。
• 项目需要在人员和代理之间共享工作流状态。
• 现有代理扇出产生了输出，但无法合并成产品。

运行模式

将每个代理视为具有狭窄契约的队友：

• 责任人：对工作项负责的人员或代理。
• 范围：文件、分支、工具表面及禁止区域。
• 状态：待办、就绪、运行中、审查中、已阻塞、已合并或已归档。
• 证据：测试、截图、日志、审查笔记或评估报告。
• 合并门：允许集成的确切条件。

代理看板

当工作必须在会话之间可见时，使用代理看板。

每张卡片应遵循此模式：

{
  "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"
}

基于团队的编排流程

1. 塑造看板：将模糊的雄心转化为带有责任人和合并门的工作项。
2. 选择执行模式：单代理、动态工作流模式、dmux/tmux、工作树扇出或外部桌面编排器。
3. 分配边界：每张卡片一个责任人，清晰的文件范围，无集成者时禁止重叠写入。
4. 运行代理：每个代理不仅要写代码，还要写证据和交接笔记。
5. 按序审查：先测试，再差异审查，然后是安全/风险检查，最后是内容/产品打磨。
6. 审慎合并：一个集成者解决冲突并更新控制面板或状态产物。
7. 提取可复用技能：如果卡片模式重复出现，将其提升到 skills/ 中。

控制面板要求

一个用于团队编排的有效控制面板应显示：

• 活跃工作项及其代理看板状态。
• 责任人、框架、分支、工作树及最后心跳。
• 指向交接产物、测试、截图和 PR 的链接。
• 按责任人及解除阻塞操作分组的阻塞项。
• 按门的合并就绪状态，而非凭感觉。
• 应成为共享技能的可复用工作流候选。

在操作者能够回答“谁拥有这个、发生了什么变化、哪个门失败了、什么可以安全合并”之前，不要增加更多自动化。

动态工作流兼容性

当卡片需要动态工作流模式时：

• 将任务本地框架置于卡片责任人之下。
• 在卡片上存储输入和输出。
• 在从“运行中”移动到“审查中”之前，要求进行评估。
• 仅在重复使用后，将框架提升为共享技能。

需要关注的失败模式

• 代理汤：多个代理运行，但没有责任人或合并门。
• 隐形工作：有用的输出仅存在于聊天记录中。
• 看板表演：存在看板，但卡片没有验收标准。
• 重叠写入：并行代理在没有工作树的情况下编辑相同文件。
• 无产品产物：过程产生了文档，但没有可运行或可发布的内容。

输出标准

每次编排循环结束时，应包含：

• 看板/卡片变更。
• 已合并或待处理的分支。
• 测试和评估证据。
• 带有责任人和下一步操作的阻塞项。
• 新的共享技能候选。