最近我做了一件有點瘋狂的事：我開始幫我的 AI 助理「組團隊」。
不是開玩笑。當你讓一個 AI Agent 同時處理需求分析、架構設計、寫 code、code review，結果就跟讓一個人同時當 PM、架構師、工程師、QA 一樣——每個都做，每個都做不好。
單一 Agent 的極限
身為一個小公司的技術主管，我大量使用 AI Agent 來輔助開發。日常工作流程大概是這樣：收到需求、拆 issue、寫 code、review、merge。聽起來很順對吧？
但問題來了——
當我把這整套流程丟給一個 Agent 處理時，踩到了幾個反覆出現的坑：
- Issue 不依規範做：Agent 拿到任務就開始寫 code，不會主動問「這個需求是不是有模糊的地方？」
- Pipeline 經常亂做：該先建 DTO 的跑去改 Controller，該等後端完成的前端已經開始 mock 了
- 開發階段失憶：跑到第五步忘了第二步的設計決策，又做出矛盾的東西
- PR Review 流於形式：「看起來沒問題，APPROVED」——拜託，你連 i18n key 不存在都沒發現
這些問題的根源其實很簡單：context 污染。一個 Agent 同時扮演多個角色，每個角色需要的背景知識不同、關注的重點不同，全部塞在同一個 context window 裡，結果就是什麼都知道一點、什麼都做不精。
人類團隊的啟發
回頭看人類團隊怎麼運作的。一個健康的開發團隊會有：
- PM 負責需求釐清，確保大家理解一致
- Tech Lead 負責技術決策，確保架構合理
- Developer 專注寫 code，不用煩惱需求是什麼意思
- QA 用另一雙眼睛看產出，專門挑毛病
每個角色有自己的 context、自己的關注點、自己的品質標準。這不是多餘的分工，是讓每個人能專注做好一件事的必要條件。
那 AI Agent 為什麼不能這樣？
多 Agent 架構設計
想通這一點之後，我開始設計一個多 Agent 協作架構。核心概念是：一個總指揮 + 多個專家 Agent，透過明確的協定溝通。
角色分工
整個架構的角色大概長這樣：
graph TD
User[👤 User] --> CS[Chief of Staff
總助理]
CS --> PM[PM Agent
需求分析]
CS --> TL[Tech Lead Agent
技術決策]
CS --> DEV[Developer Agent
寫 Code]
CS --> QA[QA Agent
Code Review]
PM -.->|Escalation| CS
TL -.->|Escalation| CS
DEV -.->|Escalation| CS
QA -.->|Escalation| CS
- Chief of Staff（總助理）：最懂使用者的 Agent，負責接收需求、理解意圖、派工給對的人、整合產出。不寫 code，不做技術決策。
- PM Agent：專門做需求分析和任務拆解，產出清晰的 spec
- Tech Lead Agent：負責架構設計和技術方向，確保 spec 落地可行
- Developer Agent：專注寫 code，嚴格按照 spec 和技術決策執行
- QA Agent：code review，用比開發者更嚴格的標準檢查產出
每個 Agent 是獨立的 session，有自己的 system prompt、自己的 context、自己的專業知識。這樣 Developer 不會被需求分析的 context 干擾，QA 不會因為「我剛剛才寫的 code」而放水。
為什麼要一個總指揮？
你可能會問：為什麼不讓 Agent 之間直接溝通？為什麼需要一個 Chief of Staff 當中間人？
原因很實際：Agent 之間直接溝通會失控。
沒有中央控制的話，PM 可能覺得需求很清楚了，但 Developer 覺得不清楚；QA 打回 PR，Developer 不知道該找 Tech Lead 還是自己硬改。訊息在 Agent 之間來回傳，沒有人知道全局狀態。
Chief of Staff 的存在就是為了解決這個問題。它是唯一有全局視角的 Agent，知道每個任務的狀態、每個 Agent 的產出、以及使用者真正要什麼。
三大核心協定
光有角色分工還不夠。Agent 之間怎麼溝通、什麼時候該停下來問人、失敗了怎麼恢復——這些才是讓整個系統真正運作的關鍵。
我設計了三個核心協定：
1. Intake Protocol（進場協定）
派工之前，必須完成一份需求釐清 checklist。不是問 Agent「你懂了嗎」（它永遠說懂），而是要求它產出一份結構化的理解確認：
- 這個需求要解決什麼問題？
- 影響範圍是哪些模組？
- 有沒有技術風險或模糊地帶？
- 成功標準是什麼？
如果 checklist 有任何一項不清楚，不派工。回去跟使用者確認。
這聽起來很囉唆，但實際上省掉了大量「做到一半發現方向錯了」的浪費。人類團隊的 kickoff meeting 其實也是在做一樣的事。
2. Escalation Protocol（上報協定）
這是我覺得最重要的一個。
Agent 最大的問題就是「不知道自己不知道」。遇到模糊的需求，它不會說「我不確定」，它會猜一個答案然後繼續做。遇到技術決策點，它不會停下來討論，它會直接選一個方案（通常是最簡單的那個）。
Escalation Protocol 就是強制 Agent 在特定情境下停下來：
- 需求有多種解讀方式 → 停，回報給 Chief of Staff
- 技術方案有 trade-off → 停，列出選項和各自的優缺點
- 連續失敗超過兩次 → 停，不要繼續盲目重試
- 發現前一個階段的產出有問題 → 停，回報而不是自己偷偷改
關鍵在於：停下來不是失敗，是品質保證。
寫進 system prompt 裡的措辭很重要。不能寫「如果遇到問題可以上報」，要寫「遇到以下情境你必須停止並上報，繼續執行是違反協定的」。對 LLM 來說，強制性的指令比建議性的指令有效得多。
3. Resume Protocol（恢復協定）
Pipeline 中斷了怎麼辦？Agent session 超時了怎麼辦？
Resume Protocol 要求在 pipeline 的關鍵節點設置 checkpoint。每個 checkpoint 記錄：
- 目前完成了哪些步驟
- 每個步驟的產出是什麼
- 下一步應該做什麼
- 當前的決策上下文
這樣即使中斷了，新的 Agent session 可以從 checkpoint 恢復，而不是從頭開始。
stateDiagram-v2
[*] --> Intake: 新需求
Intake --> Planning: ✅ Checklist 通過
Intake --> Intake: ❌ 需求不清
Planning --> Development: ✅ Spec 確認
Planning --> Escalation: ⚠️ 技術風險
Development --> Review: PR 建立
Development --> Escalation: ⚠️ 連續失敗
Review --> Done: ✅ Approved
Review --> Development: ❌ Changes Requested
Escalation --> Planning: 決策完成
Done --> [*]
更重要的是，關鍵節點要加入 human-in-the-loop。不是每一步都要人確認（那就失去自動化的意義了），而是在「影響範圍大」或「不可逆」的節點讓人看一眼。
比如：需求分析完成後讓人確認方向對不對、PR merge 前讓人看一下 review 結果。這兩個點的投入產出比最高。
實際跑起來的感受
說實話，這套架構還在迭代中。但即使是初版，也已經解決了幾個讓我很頭痛的問題：
需求品質變好了。有了 Intake Protocol，Agent 不再拿到 issue 就蒙頭寫 code。它會先產出一份理解確認，如果有模糊的地方會被擋下來。
Code Review 變嚴格了。讓獨立的 QA Agent 來 review，因為它沒有「這是我自己寫的」的包袱，會用更客觀的標準檢查。之前一個 i18n key 不存在的 bug 就是被 QA Agent 抓到的。
失敗恢復變順了。以前 pipeline 中斷，只能從頭來。現在有 checkpoint，可以從上次停的地方繼續。
當然也有問題：
- Agent 之間的溝通成本不低，token 消耗增加了
- 有時候 Escalation 太頻繁，反而拖慢速度（還在調整觸發條件）
- 每個 Agent 的 system prompt 需要精心設計，這本身就是一個工程
寫給同樣在折騰 AI 工作流的人
如果你也在用 AI Agent 處理複雜的開發流程，我的建議是：
不要期望一個 Agent 搞定所有事。 跟人一樣，專注做一件事的品質永遠比同時做五件事好。
流程管理不是可選的。 AI Agent 不會自己發展出好的工作習慣。你不寫 protocol，它就自由發揮，而自由發揮的結果通常不是你要的。
Human-in-the-loop 的位置很重要。 不是越多越好，也不是越少越好。找到「投入最少、攔截最多問題」的那幾個點。
停下來比做錯好。 這是我從 Escalation Protocol 學到最深的一課。教 Agent 說「我不確定」比教它「什麼都試試看」有價值得多。
說到底，管理 AI Agent 團隊跟管理人類團隊其實沒有本質區別——都是在解決分工、溝通、品質控制的問題。只是 AI 不會抱怨加班，但也不會主動告訴你它搞砸了。
如果這篇能讓你少走一些我踩過的彎路，那我凌晨兩點畫架構圖的時間就沒白費了 😂