一個 agent PR 看起來可以很漂亮。
有清楚的 commit。有像樣的 PR description。有測試結果。Diff 也不大，甚至比某些人類同事更有禮貌。
但 reviewer 心裡還是會卡住一個問題：它到底是怎麼做到的？
這不是吹毛求疵。當 coding agent 真的進入 repo、CLI、CI 和本機開發環境，團隊要看的就不只是「它有沒有寫出 code」。更麻煩的是：它改過哪裡？用過哪些工具？拿到什麼權限？碰過哪些 credential？驗證證據是什麼？如果兩週後出事，能不能重建當時發生了什麼？
不能查帳的 agent workflow，短期看起來很省時間。長期來看，它只是把風險藏進日常操作裡。
很多團隊衡量 agent adoption 的方式太粗。
看 bot account 開了幾個 PR。看 commit message 有沒有標註 AI。看某個工具 dashboard 裡有多少 task。這些數字不是沒用，但它們只會抓到最明顯的那一層。
真實使用通常比較髒。
有人用本機 CLI 叫 agent 修一段測試，再自己 commit。有人讓 agent 先分析 issue，真正修改還是人類手動做。有人把 agent 產生的 patch 拆掉重組。也有人只把 agent 當成 shell 裡的助手，查檔、跑命令、整理錯誤訊息，最後沒有任何地方寫著「這是 AI 做的」。
所以問題不是「我們有多少 AI PR」。
問題是：repo 裡哪些工作其實有 agent 參與，而團隊能不能看見那些痕跡。
這件事會直接影響治理。你以為某個模組還是完全由人類維護，實際上 agent 已經頻繁修改測試、設定檔和 migration script。你以為只有低風險任務交給 agent，結果本機工具早就讀過 private repo、跑過內部命令、用過開發者 token。
看不見的 productivity，很容易變成看不見的責任歸屬。
很多人聽到 agent 風險，第一句話會說：「反正最後都有人 review。」
這句話太便宜。
人類 review 當然重要，但它不是魔法。當 diff 合理、說明合理、測試也顯示 pass，reviewer 很容易只看表面。尤其在真實團隊裡，reviewer 通常不是拿著一整個下午慢慢驗屍。他可能正在趕 release，可能同時被三個 PR 打斷，可能只知道這個模組的一半背景。
Agent 產出的危險點不一定是語法錯誤。更常見的是它給出一個很順的故事。
它說自己修了 edge case。它說自己補了測試。它說沒有改到其他行為。這些句子看起來像證據，其實只是敘述。Reviewer 如果要確認，就得重新讀 issue、讀 diff、讀測試、讀相關模組，甚至自己跑一輪命令。
這時候 audit trail 的價值就出來了。
它不是為了讓流程變官僚，而是為了讓 reviewer 不必從零開始猜。好的流程會先逼 agent 留下可檢查的東西：任務限制、修改範圍、實際跑過的命令、跳過的驗證、使用過的權限類型，以及哪些地方需要人類判斷。
沒有這些，所謂 human in the loop 只是把責任推給一個已經很忙的人。
Coding agent 的 token 不能再被當成普通開發玩具。
以前你裝一個套件、試一個 extension，風險可能是 build 壞掉、環境髒掉、資料夾多一堆垃圾。現在不一樣。只要那個工具能讀 private repo、呼叫 agent、存取 OpenAI 或其他模型服務、跑 shell command、花 API credit，它就已經進入你的供應鏈。
一個被偷走的 agent credential，不只是帳號被盜。
它可能代表攻擊者能讀你的專案內容，能消耗你的額度，能在看起來像開發者工具的流程裡活動。更糟的是，很多 agent workflow 的權限邊界不清楚。Token 放在哪裡？誰能讀？本機 plugin 能不能碰？CI 裡有沒有同一組 credential？過期或離職時怎麼 rotate？
這些問題聽起來不像「寫 code」。
但這就是 coding agent 進生產流程後的工程問題。Agent 越像一個可以代替人類操作工具的工作者，它的 credential 就越像 production secret。差別只是它常常躺在開發者電腦裡，而不是被好好放進 secret manager。
如果要把 agent 放進團隊流程，我會先訂一個很小的 audit contract。
不用一開始就導入一套大平台。先要求每次 agent work 至少留下四件事。
第一，任務來源與限制。
這次是根據哪個 issue、哪段需求、哪個錯誤訊息開始的？允許改哪些路徑？哪些地方不能碰？遇到超出範圍要不要停？這些要寫在 PR body 或 task note 裡，不要只留在聊天紀錄。
第二，修改範圍。
Agent 要列出 touched files，並說明每一群修改在解什麼問題。不是貼一長串檔名，而是讓 reviewer 可以快速判斷：這次改動有沒有超出派工範圍。
第三，驗證證據。
跑過哪些命令？結果是什麼？哪些測試沒跑？為什麼沒跑？如果只做了靜態檢查，就不要寫「verified」。如果 e2e 因為本機環境缺東西沒跑，就把錯誤說清楚。
第四，權限與 credential 類型。
不需要把 secret 寫出來，但要標明這次用到了什麼等級的權限。只讀 repo？能改檔？能跑 shell？能叫外部 API？有沒有碰到 cloud、package registry、部署設定或內部資料？
這四件事很無聊。
但它們能讓 reviewer 判斷一件更重要的事：這個 agent 產出是不是可以被追溯。
對小任務，audit contract 可以很輕。
PR body 裡寫清楚 touched files、commands run、tests skipped、remaining risks，大多數情況就夠了。重點不是格式漂亮，而是資訊真的能幫 reviewer 做判斷。
例如：
ryanvale
Scope: only touched auth error display and related unit test.
Commands: pnpm test auth-error, pnpm lint.
Skipped: e2e login flow; local OAuth fixture is unavailable.
Risk: did not change token refresh logic or permission checks.
這比「Implemented and tested」有用太多。
大任務就不要一次丟出巨大 patch。比較好的節奏是 plan -> diff -> evidence。
先讓 agent 交出計畫和預期修改範圍。人類確認後再改。改完以後不要只看 summary，要看證據：哪些假設被驗證、哪些命令真的跑過、哪些地方仍然需要人類判斷。
這樣做會慢一點。
但慢在前面，通常比慢在事故後便宜。
我不太相信「agent 會越來越像資深工程師」這種說法。
它可能會變得更會寫 code、更會找檔案、更會修測試，這些都會進步。但團隊真正需要的，不是把 agent 想像成一個不用管理的資深同事。
比較務實的想法是：把它當成一個能力很強、速度很快、但必須留下工作紀錄的執行流程。
成熟的 agent workflow，不是讓工程師少看 code。
它是讓工程師不用從零開始猜 agent 做了什麼。
所以以後我看一個團隊會不會用 coding agent，不會只看它買了哪個工具，也不會只看它一週開了多少 AI PR。
我會看幾件更普通的事。
它能不能說清楚 agent work 發生在哪裡。能不能限制 agent 拿到的權限。能不能在 PR 裡留下驗證證據。能不能在 credential 出事前就知道邊界在哪。能不能在兩週後重建某次修改為什麼發生、怎麼被驗證、誰授權它碰那些地方。
Code 寫得出來，只是第一步。
查得出來，才是 agent 真的進入工程流程的開始。
iThome鐵人賽
看影片追技術