最近我做了一件有點瘋狂的事：把一個 AI Agent 拆成一整個開發團隊。
不是開玩笑。我真的建了 PM、Tech Lead、Developer 三種角色的 Agent，各自有不同的工具權限、工作範圍和人格設定。聽起來像在玩辦家家酒？也許吧，但效果比我預期的好太多了。
為什麼一個 Agent 不夠？
如果你用過 ChatGPT 或 Claude 來寫程式，一定遇過這個問題：你叫它幫你改一個 bug，它改完之後順便把你沒提到的地方也「優化」了。或者你請它做架構規劃，結果它直接開始寫 code，寫了一堆你根本不需要的東西。
問題出在哪裡？角色不清楚。
這跟帶真人團隊一模一樣。你不會讓 PM 去改程式碼，也不會讓 Junior Developer 直接拍板系統架構。每個人有自己的職責範圍，越界就容易出事。
AI Agent 也是一樣的道理。
我的三層架構
經過幾個月的摸索，我最終定下來的架構長這樣：
第一層：PM Agent
- 負責：需求拆解、任務派發、進度追蹤、彙整回報
- 絕對不碰的事：寫程式碼
- 工具權限：讀取需求文件、操作任務管理系統、發訊息通知
第二層：Tech Lead Agent
- 負責：系統架構設計、任務拆解成具體 coding 單元、Code Review
- 絕對不碰的事：直接修改 source code
- 工具權限：讀取程式碼、查詢文件，但禁止執行 shell 指令
第三層：Developer Agent
- 負責：根據任務描述寫程式碼、跑測試、提交 PR
- 工具權限：完整的開發環境存取
你可能會想：「這不就是把一件事拆成三步驟嗎？」
不，這是強制約束。
強制約束比提示工程有效一百倍
這是我學到最重要的一課。
一開始，我試過在 system prompt 裡面寫「你是 Tech Lead，請不要直接修改程式碼」。猜猜看發生什麼事？它答應得很乖，然後在你不注意的時候偷偷 git commit。
LLM 天生就是想要「把事情做完」。你在 prompt 裡寫再多限制，它的本能還是會驅使它越界。這就像跟一個超級積極的新人說「先不要動手」，他嘴上說好，但手已經開始打字了。
所以後來我改用工具層面的硬限制：
1 | tools: |
Tech Lead Agent 直接拿掉執行 shell 指令的能力。它想寫 code 也寫不了。這比任何 prompt 都有效。
同理，PM Agent 根本不給它讀程式碼的工具。它想越界也越不了。
軟約束（prompt）搭配硬約束（工具權限），這才是正確的做法。
Workspace 隔離：每個 Agent 有自己的家
另一個關鍵設計是 workspace 隔離。
每個 Agent 都有自己的工作目錄，裡面放的東西完全不同：
- PM Agent 的 workspace：任務文件、會議記錄、回報模板
- Tech Lead 的 workspace：架構文件、Review Checklist、技術規範
- Developer 的 workspace：專案 source code、開發工具設定
這樣做的好處不只是安全性。它強迫每個 Agent 只看到跟自己角色相關的資訊。
如果 Tech Lead 能看到所有 source code 的細節，它就會忍不住去「修」東西。但當它的視野被限制在架構層面，它反而能給出更好的設計決策。
這又是帶團隊的常識：讓人專注在自己該做的事情上，產出品質自然會提升。
人格設定：不只是好玩而已
OK，我承認設定 Agent 人格有一部分純粹是因為好玩。但它其實有實際用途。
我發現，當你給 Agent 一個明確的人格特質時，它的行為模式會更穩定、更可預測。比如：
- Tech Lead 設定為「架構優先」的人格：它回覆問題時真的會先思考系統層面的影響，而不是直接跳到解法
- PM 設定為「不碰技術細節」：它在回報時會用業務語言而非程式術語，更適合跟非技術人員溝通
- Developer 設定為「任務導向」：給它一個明確的 unit prompt，它就專心執行，不會東想西想
人格不是裝飾品，它是行為框架。就像公司裡的職位頭銜一樣——叫一個人「架構師」和叫他「工程師」，他處理同一個問題的方式真的會不一樣。
溝通協議：Agent 之間怎麼「開會」
多 Agent 架構最頭痛的問題是：它們之間怎麼溝通？
我試過幾種方式：
方式一：共享文件
讓 Agent 透過讀寫共同的文件來傳遞資訊。簡單粗暴，但問題是沒有版本控制、容易衝突、而且很難追蹤「誰在什麼時候做了什麼決定」。
方式二：中央協調者
所有溝通都經過一個 orchestrator。PM 告訴 orchestrator 要做什麼，orchestrator 轉達給 Tech Lead，Tech Lead 拆完任務再透過 orchestrator 派給 Developer。
這個方式更可控，但 orchestrator 本身會變成瓶頸。
方式三：事件驅動（我目前用的）
每個 Agent 完成工作後，發出一個事件通知。其他 Agent 訂閱相關事件，自動觸發後續流程。
比如 Tech Lead 完成任務拆解後，自動通知 Developer Agent 開始工作。Developer 完成後，自動通知 PM Agent 更新進度。
這個架構最接近真實團隊的運作方式——大家各做各的，透過明確的交接點同步資訊。
踩過的坑
聽起來很美好對吧？但問題來了——
坑一：Skill 載入問題
不同 Agent 需要不同的 skill（工具集合），但 skill 的載入路徑是綁在 workspace 裡的。當你的 Tech Lead workspace 跟 PM workspace 分開時，共用 skill 就變成一個問題。
我的解法是設定額外的 skill 搜尋路徑，讓所有 Agent 都能存取共用的 skill 目錄。但這引出了另一個問題：
坑二：工具權限與 Skill 衝突
你明明在工具層面禁止了 exec，但某個 skill 裡面偷偷呼叫了 shell 指令。於是 Tech Lead 雖然不能直接跑指令，但透過某個 skill 間接執行了。
防範方式：Review 每個 skill 的實作，確保它們尊重 Agent 的工具限制。 很煩，但必要。
坑三：Context 爆炸
每個 Agent 都需要知道一些基本背景（專案架構、編碼規範、客戶需求），但如果每次都把所有 context 灌進去，token 用量會爆炸。
我的做法是兩層 context：全域的放在配置裡（所有 Agent 都看得到的基本規範），任務特定的放在每次執行的 prompt 裡。這樣大部分情況下不需要重複傳遞基本資訊。
坑四：通知靜默丟失
Agent 完成任務後發通知，但通知走的是非同步佇列，如果沒有觸發即時 heartbeat，通知就會卡在佇列裡等下次輪詢。
你以為任務完成了，其實只是通知還沒送到。這種 bug 超級難抓。
解法很直覺：發完事件後立刻觸發一次 heartbeat，強制清空佇列。
這套架構適合誰？
說實話，如果你只是偶爾用 AI 寫寫 code，這套架構完全是 overkill。
但如果你像我一樣，有一堆平行進行的開發任務，每個任務都需要經過「需求 → 設計 → 實作 → 驗收」的流程，那角色分離就會開始展現它的價值。
特別是在這些場景：
- 多個專案同時推進，需要統一的任務管理視角
- 架構決策需要跟實作分開（避免「邊做邊改設計」的混亂）
- 想要有 Code Review 機制，但 reviewer 不應該是同一個寫 code 的 Agent
寫在最後
把 AI Agent 當成一個團隊來管理，聽起來有點中二。但在實踐中，它解決了一個很根本的問題：LLM 太想要把所有事情一次做完了。
透過角色分離、工具限制和 workspace 隔離，你可以讓每個 Agent 專注在自己最擅長的事情上。PM 專心拆需求，Tech Lead 專心做架構，Developer 專心寫 code。
就像真實的軟體團隊一樣——分工，才是效率的起點。
如果你也在嘗試多 Agent 架構，歡迎留言討論。這條路上我踩過的坑絕對比這篇文章能寫的多得多 😂