智慧代理驗收規則錯了，怎樣完成一次真正的糾正

Google 於 2026 年 10 月 28 日發布的 Agents CLI 指南，建議分別管理評估輸入與預期結果的版本。這項建議來自 Google，而非本文首創。原文

我們追問的是發現另一個問題之後該怎麼辦：如果驗收規則本身錯了呢？團隊可能一直在獎勵智慧代理完成某種業務不應允許的動作。修正規則，可以讓昨天的分數下降，卻不會改變昨天的行為；它還可能暴露新分數本身無法解決的後續問題。

Open Market Notes 以一個假設性的設備維修流程討論這個問題。以下是獨立的操作設計建議，不是實測實驗，也不是對 Google 已部署系統的描述。

一次糾正，面對兩類讀者

假設一個助手負責準備設備維修工單。最初的測試把「工單完整」視為成功，後來業務人員意識到，涉及特定受限區域的工作必須先獲得核准。及時完成這類工單的代理，可能通過了舊測試，卻越過了業務原本希望保留的操作邊界。

第一類讀者是決定下一個版本的工程團隊；第二類是對已經處理的工作負責的業務負責人。前者需要一條面向未來的驗收規則，後者需要知道過去的輸出有沒有越界。如果把兩件事都當成修改提示詞的任務，第二個問題就可能始終沒有答案。

這一發現並不等於真實事故已經發生。準備好的工單也許從未提交，也許被人工駁回，或者它本來只是沒有外部影響的模擬測試。首先應查明證據支持哪一種狀態，而不是把評估失敗直接寫成已經造成業務損害的指控。

保留歷史結果，補上新的判斷

CLI 文件允許不重新執行代理，直接對保存的軌跡再次評分。評估文件

我們建議的糾正記錄，應保留原結果及其當時的含義，附上修訂後的判斷，並說明修改理由。不要覆蓋過去，彷彿正確規則一直存在。讀者應看得出：舊的「通過」，可以準確反映舊測試的結果，卻不足以證明相關行為在業務上合格。

這個區分與責任有關。開發者不一定忽略了書面要求，要求可能原本就不存在或含糊不清。反過來，測試遺漏一項檢查，也不代表有權忽視已經明確的業務限制。記錄應區分產品要求什麼、測試實際檢查什麼，以及操作者做了什麼。僅憑一個標籤改變，不能推斷責任歸屬。

只問記錄能夠回答的反事實問題

有效的銜接有兩部分。重新判斷保存的互動，回答的是：新規則是否接受這段已經發生的行為？用修改後的代理重播案例，回答的是另一個問題：在重建條件下，擬議修復能否產生合格的下一步動作？

這兩者不能互換。新版代理請求核准，不能證明舊版當時也問過；也不能證明核准最終一定會獲得。如果歷史軌跡只留下最終工單摘要，缺少權限記錄可能意味沒有檢查，也可能只是日誌漏記。在其他有權使用的記錄解決疑問之前，應把這種差異標為未確定。

因此，這個例子中的修復目標應受到約束：在審批邊界停下，並指出缺少的授權。不能拿想像中的核准結果為它評分。案例可以檢查一個系統能夠控制的下一步，而無需虛構後續業務決定。

重建本身也要說明邊界。現在的設備記錄，可能包含原始請求之後才發生的修改。用它重播有助於測試今天的流程，卻沒有復原舊代理當時掌握的資訊。如果歷史輸入無法取得，就明確說明，讓追溯結論保持較窄範圍，而不是用聽起來合理的故事補空白。

技術修復，不等於業務問題結案

更好的提示詞可以改變未來行為，卻無法撤回已經提交的工單、通知受影響的主管，或者確定維修是否已經開始。這些動作屬於經過授權的業務處理程序，而不是評估腳本可以自行決定的事情。

對於假設中的維修團隊，糾正記錄可以關聯一項獨立處理狀態：沒有發生外部動作；有權審核的人確認工單適當；工單已經撤回；或狀態仍未解決。這些是建議使用的分類，不是實際發生的事件。目的在於防止把「下一版已經修復」誤認為「歷史後果已經處理完畢」。

另一個風險同樣存在：過度追溯可能消耗本該用於緊急修復的資源。適度的做法，是優先限定新發現的限制、相關時間窗口和可觀察的外部動作，不預設每個歷史失敗都需要同等調查。應由明確的負責人解釋這個範圍為何合理，以及哪些不確定性仍被保留。

先定義何謂完成，再追求更高分

在這項建議流程裡，完成糾正不只是通過修訂後的測試。業務負責人認可正確規則，工程團隊證明系統能夠執行獲准的下一步，而有權處理歷史案例的人則解決問題，或明確繼續承擔未結事項。每一種確認回答的都是不同問題。

這種設計有局限。它需要對業務記錄設定存取權限、制定合理的保存政策，並投入時間複核含糊證據。工具或模型變化之後，精確重播也可能根本做不到。這些限制應促使團隊限定結論，而不是把近似重建說成確定事實。

實際價值在於，組織可以更清楚地區分改善系統與糾正過去對系統的判斷。評分規則可以立即修好；要恢復信任，還必須說明糾正確認了什麼、哪些內容仍不知道，以及誰負責尚未完成的工作。