讓 AI 當你的 PM：多層 Agent 角色分工實踐

AI coding agent 現在真的很強。丟一個需求給它，它可以自己分析 codebase、寫出堪用的程式碼、跑測試、甚至自己 debug。聽起來很美好對吧？

但如果你真的讓一個 AI Agent「全權處理」一個稍微複雜的開發任務，你很快就會遇到這些問題：改著改著 scope 越來越大（scope creep）、改錯方向之後一路錯到底、沒有人 review 所以品質參差不齊、重構的時候把不該改的東西也改了。

我摸索了一段時間後，得出一個結論：AI Agent 不缺能力，缺的是制度。

把人類世界的角色分工搬過來

軟體開發這個領域，經過幾十年的演進，已經發展出一套很成熟的角色分工：PM 負責拆需求和管進度、Tech Lead 負責技術方向和 code review、Developer 負責實作。這套分工之所以行之有年，是因為它有效地解決了幾個根本問題：

關注點分離：每個角色專注自己的職責，不越界
制衡機制：Developer 寫的 code 要經過 Tech Lead review，不是球員兼裁判
品質管控：多一層檢查就少一層風險

那為什麼不把這套制度直接套用到 AI Agent 上？

三層角色設計

我目前的做法是把 AI Agent 拆成三層角色：

PM Agent（Orchestrator）

職責：

接收需求，拆解成可執行的任務（task spec）
分派任務給 Developer Agent
追蹤各任務的進度
彙整開發成果，回報最終結果

最重要的規則：PM Agent 絕對不碰程式碼。 它不讀 code、不寫 code、不改 code。它只處理任務層面的事情。

為什麼要這麼嚴格？因為一旦 PM Agent 開始看 code，它就會陷入 implementation detail，忘記自己應該站在更高的層次思考。我實際測試過，讓 PM 級的 Agent 去碰程式碼，它很容易從「這個任務的驗收標準是什麼」變成「這邊用 for loop 不如改成 map」。角色混淆是效率殺手。

Tech Lead Agent（Reviewer）

職責：

審查 Developer Agent 提出的開發計畫（plan）
驗收 Developer Agent 的開發成果
把關技術品質、架構一致性
確認沒有超出任務範圍的修改

Tech Lead Agent 的定位是 reviewer，不是 doer。它負責看、評估、給意見，但不直接動手寫 code。這跟人類世界的 Tech Lead 一樣——你不會期望 Tech Lead 去幫你寫每一行 code，但你會期望它在 code review 時抓出問題。

Developer Agent（Coding Agent）

職責：

分析目標 codebase 的結構
根據任務 spec 擬定開發計畫
實作程式碼
執行 build、lint、測試
提交 commit

Developer Agent 是唯一會實際接觸程式碼的角色。它在 feature branch 上工作，永遠不直接碰 main 或 develop 分支。

為什麼要這樣分？

你可能覺得：搞這麼複雜幹嘛？直接讓一個 Agent 做完不就好了？

我也是從「一個 Agent 做完」開始的，然後被教訓了好幾次之後才演進到這個架構。讓我分享幾個真實踩過的坑：

Context 爆炸

LLM 的 context window 是有限的。當你讓一個 Agent 同時處理「理解需求 → 分析 codebase → 擬定計畫 → 寫 code → 測試 → review」整個流程，它需要在 context 裡同時放需求文件、多個程式碼檔案、測試結果、編譯錯誤訊息……很快就會碰到 context 上限。

更糟的是，就算 context 還沒爆，LLM 在很長的 context 裡也會「注意力稀釋」——該注意的細節被淹沒在大量資訊中。

角色分工之後，每個 Agent 的 context 都是精簡的：PM 只看任務和進度、Tech Lead 只看 plan 和 code diff、Developer 只看相關的 source code 和任務 spec。

球員兼裁判

讓 Developer Agent 自己 review 自己寫的 code，就像讓學生自己批改自己的考卷。它很難客觀地發現自己的問題。我遇過好幾次 Developer Agent 寫了有問題的 code，但在 self-review 時完美地忽略了那些問題。

分出獨立的 Tech Lead Agent 之後，因為它是「另一個 LLM session」（甚至可以是不同的模型），它對 code 是全新的視角，更容易發現問題。

Scope creep

這可能是最嚴重的問題。讓 AI Agent 自由發揮時，它很喜歡「順便」做一些額外的事情。比如你讓它修一個 bug，它會「順便」重構一下周圍的 code、「順便」加一些 error handling、「順便」改一下命名風格。

這些「順便」的修改有時是好的，但更多時候會帶來風險——它改了你沒預期的東西，而你在 review 時可能不會注意到（因為你的注意力在 bug fix 上）。

有了 Tech Lead Agent 在 plan 階段就做 scope check，可以提前把不相干的修改擋掉。

Planning 前移：review proposal 比 review code 便宜

這是整個架構中我認為最重要的設計決策：讓 Developer Agent 先出 plan，Tech Lead review 通過後才開始寫 code。

傳統的做法是 Developer 寫完 code 再做 code review。但這有一個問題：如果 review 時發現方向錯了（比如用了錯誤的設計模式、或是漏掉了某個需求），Developer 就要把已經寫好的 code 大幅修改甚至重寫。

而 plan review 就不一樣了。Plan 是一份文字描述，寫起來快（幾分鐘），review 也快。如果方向錯了，改 plan 的成本遠低於改 code。

我的 plan review checklist 給 Tech Lead Agent：

需求覆蓋：plan 是否涵蓋任務 spec 裡的所有需求？有沒有遺漏？
Scope 控制：plan 裡有沒有包含超出任務範圍的修改？有的話要求移除。
Convention 遵循：命名風格、檔案結構、架構模式是否符合專案現有的慣例？
風險評估：plan 裡的修改有沒有可能影響現有功能？如果有，是否有相應的測試計畫？

這四個檢查點可以在 plan 階段就攔截掉大部分的問題，避免浪費在「寫了 code 才發現方向錯」上面。

分支策略：永遠在 feature branch

另一個很重要的規則：Developer Agent 永遠在 feature branch 上工作，不碰 main 或 develop 分支。

這看起來是基本常識，但你會驚訝於 AI Agent 如果沒有明確被限制，它有多喜歡直接在 main 上面改東西。

分支策略帶來的好處：

安全網：就算 Agent 寫的 code 有問題，main branch 不受影響
容易回滾：不要這個修改了？直接刪掉 feature branch 就好
Clean diff：每個 feature branch 的 diff 就是這個任務的所有修改，方便 review
並行開發：多個任務可以同時在不同的 feature branch 上進行

實際應用場景

Bug Fix 流程

PM Agent:   接收 bug report → 分析影響範圍 → 產生 task spec
                                                    ↓
Developer:  閱讀 task spec → 分析相關 code → 提出修復 plan
                                                    ↓
Tech Lead:  review plan → 確認修復方向正確 → approve
                                                    ↓
Developer:  在 feature branch 實作 → build → test → commit
                                                    ↓
Tech Lead:  review code diff → 確認修復正確且無 side effect → approve
                                                    ↓
PM Agent:   確認任務完成 → 更新進度

新功能開發

PM Agent:   接收 feature request → 拆成多個 user stories → 逐一派工
                                                    ↓
Developer:  針對每個 user story 出 plan
                                                    ↓
Tech Lead:  batch review 所有 plan → 確認一致性和完整性
                                                    ↓
Developer:  逐一實作 → 每完成一個就提交
                                                    ↓
Tech Lead:  逐一 review → approve 或要求修改
                                                    ↓
PM Agent:   追蹤整體進度 → 全部完成後彙整

重構

重構特別需要嚴格的角色分工，因為重構的風險最高：

PM Agent:   定義重構 scope（明確哪些要改、哪些不能動）
                                                    ↓
Developer:  評估影響範圍 → 提出分批重構計畫
                                                    ↓
Tech Lead:  審查計畫 → 評估每批的風險 → 確認分批策略合理
                                                    ↓
Developer:  逐批執行 → 每批完成後 build + test
                                                    ↓
Tech Lead:  逐批驗收 → 確認沒有破壞現有功能

重構最忌一口氣全改，分批執行 + 逐批驗收的方式可以把風險控制在可管理的範圍內。

導入的成本與效益

坦白說，這套架構會增加開發的「步驟數」。原本一個 Agent 一氣呵成的事情，現在要經過 plan → review → execute → verify 好幾道關卡。

但從結果來看：

返工率大幅降低：以前常常 Agent 寫完 code 才發現方向錯了，改完又錯，反覆好幾次。現在在 plan 階段就能攔截方向性的問題。
品質更穩定：有了 Tech Lead 的 review，那種「看起來能跑但其實有隱患」的 code 明顯減少了。
Scope 更可控：PM Agent 盯著 scope，Developer Agent 就不容易偷偷做額外的事情。
出事更好查：因為每個環節都有明確的輸入輸出，出問題時很容易定位是「需求沒拆清楚」、「plan 沒 review 到」、還是「實作有 bug」。

結語

我常常看到有人抱怨「AI coding agent 寫的 code 品質不好」、「AI 修 bug 越修越多」。我的觀察是：大部分問題不是 AI 的能力不足，而是我們沒有給它足夠的制度約束。

這就跟管理人類團隊一樣。一個能力很強的工程師，如果沒有 PM 幫他定義 scope、沒有 Tech Lead 幫他 review code、沒有流程規範告訴他什麼能做什麼不能做，他一樣可能寫出一團亂。

人類世界花了幾十年演進出的軟體開發方法論——角色分工、code review、branch strategy、planning before coding——這些不是官僚作業，是無數血淚教訓的結晶。把這些制度套用到 AI Agent 上，不需要什麼革命性的新技術，只需要把已經被驗證過的管理智慧重新應用。

AI Agent 最強大的時候，不是它自由發揮的時候，而是它在一套好的制度下運作的時候。