近期 AI Engineer World’s Fair 有幾場演講都在談同一個問題：Agent 可以很快產生程式碼、文件與各種產物，團隊卻還沒有同樣成熟的方法判斷工作是否真的完成。當產出速度超過審查速度，「完成」這個狀態本身已經不夠用了。
Sumaiya Shrabony 分享她維護一套 19 個 skill 的內容系統，從排程、研究、製作到保存，中間有七次交接。她遇到的危險情況，是產物格式完整、文字看起來也能用，實際上聲音規則不符、數字沒有來源，或開場跟舊內容重複。系統若只檢查檔案存在與欄位齊全，這類產物仍會被送進待發布目錄。她後來加入輸出格式、領域規則、來源驗證、去重與稽核紀錄，整套系統逐漸具備 CI/CD 的基本控制。
Paperclip 創辦人 Dotta 對「完成」的定義更接近一組資料。裡面要有交付產物、適用範圍、驗收標準、完成證據、驗證者、核准權限、剩餘風險與下一個負責人。這個做法讓 Agent 不只把任務狀態改成完成，也讓後續的人知道這項工作依照什麼標準通過、誰做過確認，以及接下來能不能合併或部署。
因為真實的世界有其限制：所有產物都交給人從頭檢查，審查能量很快就會塞滿。eBay 工程師 Sachin Gupta 把這種負擔稱為 ReviewDebt（審查債），並嘗試用變更範圍、測試證據、跨團隊檔案分布與變更理由等可計算訊號，先找出需要較多注意力的 PR。這個方向的重點是把人的判斷留給高風險項目，同時讓一般項目先通過可重跑的機械驗證。
Google DeepMind 的 Philipp Schmid 在 skill eval 分享中也採用類似做法。每個 skill 都需要附上測試案例，變更時在隔離環境重跑，檢查是否在正確情境觸發、產出是否符合要求，也保留不應觸發的反例。很多檢查只需要 regex 或腳本，不必每次再請另一個 LLM 判斷。這讓驗收標準比較穩定，也能在模型或 harness 更新後持續檢查退化。
我覺得企業導入 Agent 的 KPI 可以開始記錄「附可驗證證據的合格交付率」。一次合格交付至少要能回答：產物在哪裡、依什麼標準驗收、哪個驗證程式成功、輸入與版本是什麼、證據能不能重跑、還有哪些風險。產出如果是文章就必須附上來源；如果是程式碼，則可能附上測試與 diff，UI 可能附操作錄影或截圖；不同工作需要不同證據，但都要讓下一個人可以重新判斷產出是否合格。
當 Agent 能大量工作，真正需要擴充的是整套驗收能力。把驗收標準、validator、evidence 與責任歸屬放進工作流程，Agent 的速度才會轉成團隊可以信任的交付，也讓人在需要判斷時看得到完整脈絡。
參考資料：
https://www.youtube.com/watch?v=WLXxTaPagA8
https://www.youtube.com/watch?v=7P0elyLIxXo
https://www.youtube.com/watch?v=TJPInBjhE4Q
https://www.youtube.com/watch?v=0vphxNt4wyk
https://www.youtube.com/watch?v=8G_1-3IO4ZQ
沒有留言:
張貼留言