你看不到 agent 腦中怎麼想。
但你看得到它留下來的 diff。
這件事聽起來很廢話，卻是很多 coding agent review 討論最常跳過的一步。大家很容
没
易直接問：這個模型可不可信？這個 agent 會不會幻覺？它的推理過程能不能看？這些問題不是不重要，只是太大了，大到最後會變成一種沒有操作性的焦慮。
工程團隊真正能 review 的，通常不是模型的內心活動。
是它改了哪些檔案、改了哪幾種東西、跑了什麼命令、留下什麼測試證據，以及哪些地方它根本沒碰。
所以我越來越覺得，agent PR 的第一個問題不該是「這是不是 AI 寫的」。應該是：
這次它到底改了什麼？
有一種做法，是把 agent PR 當成一般同事的 PR。
照常看 diff，照常跑測試，照常留言。反正 code review 本來就不是相信人，而是相信證據。這個方向有一部分是對的。最後進 repo 的仍然是 patch，不是 prompt，也不是聊天紀錄。
但它也太樂觀。
人類同事通常知道什麼叫「我不確定」。他可能會在 PR description 裡寫「這段我不太熟，請特別看一下」。他也知道哪些地方是公司內部慣例，哪些檔案雖然看起來相關但最好不要動。更重要的是，你可以根據過去合作經驗判斷他的盲點。
Agent 沒有這種脈絡信用。
它可以把 summary 寫得很順，把測試結果列得很像樣，甚至把風險講得好像已經想過。但 reviewer 不能因此偷懶。你要確認那些話跟 diff 對得起來。
另一種做法，是把 agent PR 全部當成不可信黑盒。
這也不太實際。如果每個 agent patch 都要當重大事故預演來審，團隊很快就不會用了。不是因為大家不重視風險，而是成本太高。Agent 最常進來的地方，往往是補測試、修小 bug、整理型別、改文件、拆重複邏輯。把所有這些改動都用同一種強度審查，最後只會讓 review policy 變成口號。
比較成熟的做法，是 change-type routing。
先判斷它改的是哪一類東西，再決定誰看、看多深、要補什麼證據。
最近一篇研究把 AI coding agents 在 performance-improving PR 裡的 diff hunk 做分類。它不是要證明某個 agent 比較聰明，而是問一個比較工程的問題：這些 agent 實際上都在改什麼？
這個方向很有意思。
因為 agent 的推理過程可能不透明，prompt history 也常常不完整，但 diff 是留下來的。它不一定代表全部風險，至少是可檢查的部分。研究裡提到的主要類型包含 name modification、object creation、type change 等。這些分類不能直接外推到所有 agent work，因為資料集聚焦在 performance-relevant PR；但它提供了一個很實用的起點。
Review agent code，不要先問「這個模型強不強」。
先問「這個 patch 的形狀是什麼」。
命名改動、物件建立、型別改動、控制流程、資料流、依賴、設定、測試，每一種都該有不同的 review 問題。把它們混在一起，只會得到一堆空泛建議：要小心、要測試、要人工審查。
這些話都對。
也都不夠。
命名改動看起來最安全。
把 user 改成 account，把 payload 改成 requestBody，把某個 helper 換成更清楚的名字。這種 diff 很容易讓 reviewer 放鬆，因為它不像邏輯改動，也不太會讓測試紅掉。
但命名不是表面功夫。
在大型 codebase 裡，命名常常承載領域判斷。member、user、account、profile 可能不是同義詞。active 可能指帳號狀態，也可能指訂閱狀態。Agent 如果只是順著附近的 pattern 改名，可能會把原本刻意保留的差異抹平。
所以命名類 diff 的 review 重點，不是「有沒有更好讀」。
是語意有沒有被偷偷改掉。
我會要求 agent 在 PR description 裡講清楚：這次命名改動是純 readability，還是同步某個 domain concept？如果是前者，改動範圍應該很窄；如果是後者，就要有人懂那個 domain 的 reviewer 來看。
Object creation 類的改動更麻煩。
Agent 很擅長補一個 wrapper、建一個 client、塞一個 cache、加一個 intermediate object。看起來像是把責任拆乾淨了。問題是，新的物件一旦進系統，就會有生命週期。
誰建立它？
誰釋放它？
它有沒有共享狀態？
它會不會被重複初始化？
它的錯誤怎麼傳出去？
它有沒有把原本單純的函式呼叫，變成一個隱性的依賴圖？
這些問題靠「看起來架構更乾淨」回答不了。尤其是 performance 相關 patch，agent 很可能為了少做一點事而引入 cache、pool、lazy initialization。這些東西如果沒有清楚邊界，短期 benchmark 可能變好，長期 debugging 會變痛苦。
物件建立類 diff，我會看測試之外的兩件事：初始化路徑和失敗路徑。
只測 happy path，通常不夠。
Type change 很容易被包裝成安全改進。
把 any 收窄。把 nullable 拆清楚。把一個 enum 補完整。把 schema 轉成更嚴格的型別。這些改動當然可能是好事，我也希望更多 agent 做這種髒活。
但型別改動最危險的地方，常常在邊界。
資料從 API 進來時真的符合新型別嗎？舊資料庫裡有沒有奇怪值？第三方 webhook 會不會送文件沒寫的欄位？前端 localStorage 裡的舊 payload 會不會被新 parser 拒絕？
TypeScript 或型別檢查過了，只代表你現在的程式碼同意這套宣告。
它不代表外部世界也同意。
所以 type change 類 diff 的 review，不只看 compiler。要看 migration、runtime validation、向後相容、錯誤訊息，以及是不是需要灰度。Agent 很容易把型別整理得漂亮，卻忘了世界很髒。
世界通常真的很髒。
控制流程改動最需要慢下來。
if 條件調整、early return、loop 改寫、錯誤處理重排、retry policy 改變，這些 diff 不一定大，但行為面積很大。Agent 寫這類 patch 時，常常可以讓主要測試通過，卻漏掉一個不常見 branch。
這不是 agent 專屬問題，人類也會。
差別是，agent 有時候會很有自信地把「我跑了測試」講成「我驗證了行為」。這兩件事差很多。
控制流程類 diff，我會要求 PR 裡列出它認為受影響的 branch。正常情境、空資料、錯誤回傳、權限不足、timeout、重試後仍失敗，至少要知道哪些有被測，哪些只是靠 reviewer 判斷。
如果 agent 連哪些 branch 存在都講不清楚，這個 patch 不應該快審。
很多團隊會低估 config diff。
改一個 GitHub Actions 權限。更新一個 package。多一個 postinstall script。調整 Dockerfile。新增一個環境變數。這些東西在 diff 裡可能只有幾行，但它們碰的是供應鏈和 runtime 邊界。
這裡要特別小心一個盲點：不是所有風險都會出現在最後的 repo diff。
之前 0DIN / Mozilla AI 的 repo setup 攻擊示範就很刺眼。重點不是要再講一次攻擊流程，而是提醒我們：有些風險發生在 clone、install、run、fetch、DNS lookup、shell execution 的過程裡。最後你 review 的 diff 可能很乾淨，但本機或 CI 已經執行過不該執行的東西。
所以 diff taxonomy 必要，但不充分。
設定、依賴、setup 類改動，要搭配 command log、network visibility、sandbox、secret hygiene。只看 code review 頁面，會漏掉 agent 實際做過的事。
如果 agent 只是偶爾幫你補一個小函式，review policy 粗糙一點也許還能撐。
但現在的方向不是這樣。
Codex 使用研究裡提到，active users 在 2026 上半年快速成長，也有使用者在某些週同時管理三個以上 agents。Skills、instructions、可重複工作流也開始變得重要。這代表 coding agent 正在從「好用的輔助工具」變成 workflow infrastructure。
一旦人開始同時委派多個 agent，review bottleneck 會變得很現實。
你不可能每個 patch 都用同樣方式重看一遍。你也不能只相信 agent 自己說「已完成」。團隊需要一套可以分流的 artifact standard，讓 reviewer 先知道這個 patch 屬於哪一類、風險在哪裡、證據在哪裡。
不然多 agent 只會把產出速度拉高，把驗收能力留在原地。
這是最容易被 dashboard 遮住的地方。
如果一個團隊問我 agent PR 最低交付標準，我會先從六樣東西開始。
第一，change summary。不是漂亮摘要，而是具體說明它改了哪個行為、哪個模組、哪個邊界。
第二，diff category。命名、物件建立、型別、控制流程、資料流、依賴、設定、測試，至少要自己分類。可以多選，但不能空白。
第三，test evidence。跑了哪些命令，結果是什麼，哪些測試沒跑。不要寫「tests passed」就結束。
第四，commands run。尤其是 install、build、migration、script、network 相關命令。Reviewer 要知道 agent 在產出 diff 之前做過什麼。
第五，files intentionally untouched。這點很重要。Agent 應該說明哪些看似相關的地方它刻意沒改，原因是什麼。這可以暴露它是否真的理解範圍。
第六，known uncertainty。它不確定什麼？需要人類看哪裡？如果 agent 的回答永遠零不確定，那不是可靠，是可疑。
這些不是官僚表格。
這些是 review 的索引。
有了這些資訊，reviewer 才能決定這個 patch 要快看、慢看、退回、補測，還是乾脆要求人類重寫。
我不喜歡一種說法：既然 agent 只是工具，錯了都是人類責任，所以不用特別設計流程。
這話只對一半。
最後責任當然在人類團隊。可是責任不是靠口號承擔的。責任要落在流程裡，落在誰能 approve、哪些 evidence 夠、什麼類型的 diff 不能自動合併、什麼命令不能讓 agent 自己跑。
Diff category 的目的，不是幫 agent 找藉口。
是讓人類責任有地方站。
命名改動可以比較快，但 domain term 要有人看。型別改動可以很有價值，但邊界資料要驗。控制流程要慢。設定和依賴要更慢。Setup-time 行為要看 log，不只看 diff。
這樣的 review policy 才像工程。
不是「AI 很危險，所以全部小心」。
而是「這一類改動有這一類風險，所以我們要這一類證據」。
我不覺得團隊需要等到模型完全透明，才開始用 coding agent。
也不覺得 agent PR 可以因為測試過了，就自動進主幹。
比較務實的位置在中間：把 agent 當成會產出 patch 的工作者，但不要把它當成懂你系統的同事。它可以做事，但它交出來的東西要被分類、被驗證、被分派責任。
所以回到最一開始。
不要先問「這個 agent 值不值得信任」。
這個問題太大，也太容易變成信仰。
先問小一點、硬一點的問題：
這次它到底改了什麼？
我們用什麼證據接受它？
如果團隊能穩定回答這兩題，coding agent 才有機會從一個會產出很多文字和 patch 的黑盒，變成真正可以放進工程流程的工具。
ryanvale
iThome鐵人賽
看影片追技術