Ryan Vale

把 resolved、verified、accepted 分開，讓 AI code review 的結論綁定到可定位的 revision 與驗證證據。

用可觀察事件與交接證據建立 coding agent 的行為回歸測試，避免只看 patch 判定成功。

自己託管 coding agent 不代表模型也在本機。文章用四份契約拆開推論、執行、資料外流、憑證與 worker 生命週期的控制邊界。

Coding agent 能持續追 PR、修 checks 與處理衝突後，團隊更需要把可自動修復的 blocker 和必須由人承擔的例外分開，讓每張例外卡帶著 revision、證據與停止條件回到人的 inbox。

coding agent 接進產品時，先把能力、生命週期與產物差異說清楚，再設計 adapter 介面。

Slack、Teams 等協作入口可以接收 agent 意圖，但執行前仍要先把請求轉成可核對、可審查、可歸責的任務封套。

從使用者目標、權限、狀態、失敗與收據，定義 agent 可安全呼叫的 action contract。

可攜格式解決重複設定，卻不會自動處理信任；團隊需要一張能被 review、也能約束 runtime 的能力清單。

把 task、tool、approval、state 和 receipt 畫成可恢復的邊界，讓 agent 在 timeout 或升級後仍能安全接手。

模型會停用，團隊需要把相依、認證、golden work set、fallback 與 rollback 寫成可驗證的 migration contract。

Agent 的完成不該只是一句 done；把檢查、觀察、重試與 receipt 寫成可重跑的 verification loop。

AI 降低了漏洞報告的生成成本，但證明漏洞存在的成本沒有消失；驗證鏈必須先於修補佇列。

排程 agent 最重要的規格，不是 prompt，而是清楚的觸發範圍、預算、停止條件與失敗出口。

想像一個已經做得很順的 demo。

小團隊無法每次重做供應鏈威脅分析；更好的工具會讓安裝、更新與發布在沒有人明確決定時先少做一步。

想像一個很普通的 pull request。 Coding agent 改了幾個元件、補了測試，也順手修改 repo 裡的 REVIEW.md。接著 AI reviewer 讀完這個 branch，留下六則看起來很完整的意見：型別沒有問題、錯誤處理可以再補、某段查詢可能拖慢頁面。

我最近看 coding agent 跑前端專案，最常卡住的地方往往很無聊。 它執行了 dev，終端機沒有退出，於是它不知道該繼續等，還是另開一個 session。第二次啟動時，連接埠已被占用。它接著讀一段有顏色、有動畫、有縮排的 log，從裡面猜網站是不是已經 ready。猜錯了，就先睡五秒再試一次。

背景 agent 讓任務可以非同步完成，也把責任、停止條件與交接證據變成小團隊必須先設計的工作流程。

AI agent 的確認按鈕，只有在使用者看得懂真實路徑、命令副作用與批准範圍時，才算真正的 human-in-the-loop。

團隊導入 AI agent，難點不是買工具，而是讓任務切法、執行紀錄、review 證據和失敗停點變成同事看得懂、能複製的工作方式。