團隊代理協調 是做什麼的？
當代理以團隊而非單一助手的形式管理時，使用此技能。目標是讓基於團隊的協調變得可靠：清晰的工作項目、明確的所有權、代理看板狀態、分支隔離、控制面板可見性以及合併閘門。
何時啟用
- 任務涉及多個代理、工具、框架、分支或工作目錄。
- 使用者提及團隊協調、代理看板、小隊、指揮、控制面板、經理、桌面應用程式、Zellij、tmux、Hermes、Devin、Codex、Claude Code 或多代理工作。
- 專案需要跨人員和代理共享的工作流程狀態。
- 現有的代理扇出模式雖有產出，但無法產生可合併的成品。
營運模式
將每個代理視為擁有狹義合約的團隊成員：
- 擁有者：對工作項目負責的人員或代理。
- 範圍：檔案、分支、工具使用範圍及禁止區域。
- 狀態：待辦事項、就緒、執行中、審查中、受阻、已合併或已封存。
- 證據：測試、螢幕截圖、日誌、審查記錄或評估報告。
- 合併閘門：允許整合的明確條件。
代理看板
當工作需要在不同會話間可視化時，使用代理看板。
| 欄位 | 含義 | 離開條件 |
|---|---|---|
| 待辦事項 | 未成形的工作項目候選 | 寫好驗收標準 |
| 就緒 | 已成形且可指派 | 已指派擁有者與分支/工作目錄 |
| 執行中 | 代理正在積極工作 | 存在交接產物與已變更的檔案 |
| 審查中 | 工作已完成但尚未合併 | 測試、差異審查與風險檢查通過 |
| 受阻 | 需要外部輸入或閘門失敗 | 阻礙原因有指定擁有者與下一步行動 |
| 已合併 | 已整合到主線 | PR 已合併或本地 main 已更新 |
| 已封存 | 不再相關 | 記錄原因 |
每張卡片應符合以下結構：
{
"id": "agent-card-001",
"title": "建立動態工作流程技能",
"owner": "codex",
"state": "executing",
"branch": "product/dynamic-workflow-team-orchestration",
"worktree": ".",
"acceptance": [
"技能已存在",
"測試涵蓋所需概念",
"內容產物包含影片和文章角度"
],
"merge_gate": "lint、重點測試與目錄檢查通過",
"handoff": "path/to/handoff.md"
}
基於團隊的協調流程
- 塑形看板：將模糊的構想轉化為帶有擁有者和合併閘門的工作項目。
- 選擇執行模式：單代理、動態工作流程模式、dmux/tmux、工作目錄扇出或外部桌面協調器。
- 指派範圍：每張卡片一個擁有者、明確的檔案範圍，且在沒有整合者的情況下避免重疊寫入。
- 運行代理：每個代理不僅產出程式碼，還要撰寫證據與交接備註。
- 依序審查：先測試，再進行差異審查、安全/風險檢查，最後是內容/產品打磨。
- 審慎合併：一位整合者解決衝突，並更新控制面板或狀態產物。
- 提取可重用技能：如果卡片模式重複出現，將其提升到
skills/目錄中。
控制面板需求
一個實用的團隊協調控制面板應顯示：
- 活躍的工作項目及其代理看板狀態。
- 擁有者、框架、分支、工作目錄以及最後一次心跳。
- 交接產物、測試、螢幕截圖與 PR 的連結。
- 依擁有者分組的阻礙項目及其解決行動。
- 基於閘門而非感覺的合併就緒狀態。
- 應成為共享技能的可重用工作流程候選。
在操作者能夠回答以下問題之前，不要增加更多的自動化：誰擁有這個？什麼變更了？哪個閘門失敗了？什麼可以安全地合併？
動態工作流程相容性
當一個卡片需要動態工作流程模式時：
- 將任務層級的框架置於卡片擁有者之下。
- 將輸入和輸出儲存在卡片上。
- 在從執行中移至審查中之前，需要一次評估。
- 僅在重複使用後，才將框架提升為共享技能。
需要注意的故障模式
- 代理混戰：多個代理在運行，但沒有擁有者或合併閘門。
- 無形工作：有用的輸出僅存在於對話記錄中。
- 看板形式主義：有看板，但卡片沒有驗收標準。
- 重疊寫入：平行代理在沒有工作目錄的情況下編輯相同檔案。
- 無產品產物：流程產生了文件，但沒有可執行或可發布的成果。
輸出標準
每次協調工作完成後應產出：
- 看板/卡片變更。
- 已合併或待處理的分支。
- 測試與評估證據。
- 帶有擁有者與下一步行動的阻礙項目。
- 新的共享技能候選。