問「哪個 AI coding agent 最好」其實有點偷懶。
這個問題聽起來很工程，實際上常常是在逃避更難的事：這個任務到底能不能交出去？要交給誰？交出去之後，憑什麼相信它真的做完了？
以前 coding assistant 比較像 IDE 裡的副駕駛。它補 code、解釋錯誤、幫你寫測試。你不滿意就改 prompt，或乾脆自己寫掉。現在的 agent 形態不太一樣了。它可以被指派 issue，在背景工作，開 pull request，甚至在 PR 裡附上自己的說明與驗證結果。
這代表它不再只是「比較會回答的聊天框」。
它正在變成一種 PR 工作者。
一旦進到 PR 流程，真正重要的問題就不是哪個模型最聰明，而是哪種任務該交給哪種 agent、給多少權限、要什麼證據、什麼時候必須收回來給人處理。
沒有任務路由規則，再強的 agent 也只是更貴的猜測機器。
GitHub Copilot coding agent、OpenAI Codex 這類工具釋出的信號很清楚：coding agent 的工作位置正在從 editor 移到工作佇列。
你可以把一個任務交給它，讓它在背景看 repo、改檔案、跑測試，最後丟一個 PR 回來。對團隊來說，這很誘人。因為它看起來把「等待工程師有空」換成「先讓 agent 做一版」。
但這也改變了 review 的本質。
以前 review 一個人類工程師的 PR，你大概會看幾件事：需求有沒有對、diff 合不合理、測試有沒有補、邊界情境有沒有漏。你也會帶著一點上下文判斷：這個人懂不懂系統、他平常會不會亂碰不該碰的地方、他知道什麼時候該問問題。
Agent PR 少了這些隱性信任。
它可能產出一個看起來乾淨的 diff，但你不知道它是不是剛好繞過了真正的問題。它可能說測試通過，但你不知道它是不是只跑了最窄的一個命令。它可能修了一個 bug，順手改掉旁邊的行為，自己還覺得那是合理整理。
所以 review agent PR，不能只看 code。
你要 review 的是它做事的方法。
它讀了哪些檔案？改動範圍有沒有越界？它跑了哪些驗證？哪些沒跑？它遇到失敗時是停下來回報，還是自己往更大的範圍猜？這些問題，比「這個 agent 平均答題分數比較高」更接近工程現場。
很多 agent 評比會讓人產生一個錯覺：只要找到最強的那個，剩下就是把任務丟過去。
我不太相信這件事。
Pull request acceptance 這類研究已經開始用任務類型去看 agent 表現。這個方向比單純排行有意思，因為工程任務本來就不是同一種形狀。
補 README 跟追 race condition 不是同一件事。加一個單元測試跟改登入權限不是同一件事。修 UI copy、補型別、調整 CI、跨模組重構、處理安全敏感邏輯，這些任務需要的上下文、風險、驗收方式都不同。
如果團隊把它們全部丟進同一個「請幫我修」入口，agent 當然會變得難控。
問題不是 agent 不夠聰明。
問題是你沒有告訴系統，這到底是哪一種工作。
我會建議團隊先做一張很無聊、但很有用的任務路由表。
不用複雜。先把常見 agent 任務分成幾類就好。
| 任務類型 | 適合委派程度 | 權限邊界 | 驗收證據 |
|---|---|---|---|
| 文件、註解、README 整理 | 高 | 限定文件目錄或指定檔案 | diff、格式檢查、人工快速讀過 |
| 測試補洞 | 高 | 只改測試或 fixture，必要時小改 production code | 指定測試命令、覆蓋的失敗案例 |
| 低風險機械修改 | 高 | 明確檔案清單或模組範圍 | lint、typecheck、搜尋確認沒有漏改 |
| 局部 bug fix | 中 | 限定模組，禁止順手重構 | 重現案例、回歸測試、相關測試通過 |
| UI 或瀏覽器行為驗證 | 中 | 限定頁面與元件 | 截圖、互動步驟、可重跑的驗證命令 |
| 跨模組重構 | 低到中 | 需要人工先拆範圍 | 全量測試、風險清單、逐步 PR |
| 安全、權限、付款、資料刪除 | 低 | 預設不允許自主合併 | 人工設計審查、安全檢查、雙人 review |
這張表看起來不像什麼 AI 策略。
但它比「我們導入最強 agent」實際多了。
因為它把 agent 的使用從個人手感拉回團隊流程。每個人都知道什麼任務可以交出去，什麼任務只能讓 agent 先提建議，什麼任務需要人類先寫清楚 acceptance criteria。
更重要的是，它讓失敗可以被討論。
如果 agent 常常在「局部 bug fix」裡失敗，你可以回頭看是任務描述太模糊、測試太少、模組界線太亂，還是這類工作不適合目前的工具。沒有分類，你只會得到一句沒什麼用的結論：「AI 有時候很好用，有時候很雷。」
很多人丟給 agent 的任務，其實不是任務。
比較像願望。
「幫我把這段整理好。」
「修一下這個 bug。」
「看能不能改善效能。」
人類工程師收到這種訊息，至少會追問幾句，或用自己對系統的理解補洞。Agent 可能也會問，但更多時候，它會直接開始猜。
一個能委派的 agent task，最好像工作單。
例如：
修復
src/billing/usage.ts在免費方案用量歸零時顯示錯誤的問題。允許修改 billing 模組與對應測試，不要調整方案判斷規則。先新增一個失敗測試重現問題，再修改 production code。完成後跑pnpm test billing和pnpm lint。如果需要改到權限或付款流程，停止並回報原因。
這段不華麗，但很清楚。
它定義了範圍、禁止事項、驗證命令、停止條件。Agent 不需要猜這是不是順手重構的好機會，reviewer 也不用事後才發現它碰了不該碰的地方。
任務描述越像「請自由發揮」，agent 就越容易把未知轉成嘗試。
而嘗試在 PR 裡會變成 diff。
我看 agent PR 時，最不想看到的句子是「應該已經修好了」。
這句話人類講就已經有點危險，agent 講更危險。因為它的信心不等於系統真的穩。
比較好的 agent PR，應該附上很樸素的證據：
這些東西不是行政負擔。它們是 reviewer 的地圖。
沒有這張地圖，你只能從 diff 反推 agent 的思路。那很浪費時間，也很容易漏掉真正的風險。
尤其是 agent 很擅長產出「看起來合理」的修改。它不一定會把系統弄壞到測試全紅。更常見的是，它把某個邊界情境處理得很漂亮，卻改變了另一個隱含約定。這種問題，只看局部 diff 很難抓。
所以驗收不應該問：「agent 覺得完成了嗎？」
應該問：「它交回來的證據，足不足以讓人類承擔 merge 的責任？」
有些團隊一聽到路由表、權限、驗收證據，就覺得這樣會把 agent 管死。
我覺得剛好相反。
沒有規則的團隊，最後通常更不敢用。因為大家不知道 agent 會改到哪裡，不知道失敗後誰收尾，不知道 PR 裡哪些東西可信。幾次踩雷之後，管理方式就會變成一句很粗暴的規定：「重要的不要交給 AI。」
有規則，才敢把更多工作交出去。
你知道文件整理可以直接丟。你知道測試補洞可以讓 agent 先做。你知道局部 bug fix 要附重現測試。你知道跨模組重構只能先拆計畫。你知道安全敏感修改預設只能讓 agent 提分析，不能讓它自己改完等 merge。
這不是保守。
這是把 agent 放進工程系統，而不是放進許願池。
真正會用 coding agent 的團隊，不會是每件事都丟給 AI 的團隊。那只是把混亂自動化。
會用的團隊，是知道哪些事該交出去、哪些證據才算完成、什麼時候該把工作收回來的團隊。
等 agent PR 變得更普遍，模型能力當然還是重要。但團隊之間真正拉開差距的地方，可能不在誰買了哪個最強工具。
而在誰先把任務分派、驗收證據、停止條件這些無聊的東西設計好。
無聊，通常就是工程真正開始的地方。
ryanvale
iThome鐵人賽
看影片追技術