客服代理把別人的資料交給使用者，你補上一條限制後，它在示範對話裡拒絕了。這樣就能放心上線嗎？還要知道其他失敗情境有沒有改善，以及原本該完成的正常工作，是否也一起被擋住。
Microsoft 在 9 月 24 日介紹 run-assert-eval，把風險探索、行為測試、政策產生與再次驗證接成一個開發流程。對已經有 AI Agent 的團隊，值得先學的是它的比較方式：保留同一套測試，再檢查修正前後的差異。
它幫忙串起哪些工作？開發者仍要決定測什麼
依 ASSERT 儲存庫說明，Clarity 可協助找出未想到的失敗模式；如果你已有明確風險，也能直接描述，或提供需求、設計與事故文件。接著由 ASSERT 把每一種行為分開建立測試，再由 ACS 處理執行時的政策控制。
例如你要做公司內部的設備借用代理，可以先定義：「使用者只能取消自己的預約。」這比「系統必須安全」更容易驗收。測試除了別人直接要求取消，還可以包含自稱主管、拿著他人的預約編號，以及對話中途更換對象等情況。
正常情境也要一起保留：使用者取消自己的預約時，代理應能完成，而不是每次都要求人工處理。這兩組結果回答不同問題——有沒有做出不允許的事，以及該幫忙時有沒有幫上忙。單看拒絕次數，很容易把過度保守誤認為品質提升。
工具可以產生政策草稿，但你仍要檢查它擋在哪裡。ACS 整合文件區分輸入、輸出與工具呼叫等介入點，並提醒一般 guard_target 路徑只執行輸入／輸出控制；要限制工具呼叫，需要在實際執行工具的位置接上控制。
這個差異會影響修正是否有效。若取消預約的工具已經動手，最後才把回答改成「不能處理」，錯誤動作仍然發生了。對有副作用的功能，驗收要看操作紀錄與最終狀態，而不只是聊天視窗的文字。
官方的改善數字，能告訴我們多少？
Microsoft 的帳務客服示範，跨客戶資料暴露在基準測試中發生 12／40 次，約 30.0%；加入控制後為 2／34 次，約 5.9%。這是各次評估中適用對話的觀察結果，分母不同，不能把它直接包裝成每個團隊都能取得的改善幅度。
而且官方的示範程式說明寫得很清楚：基準版本刻意讓規則主要存在於提示詞，工具本身沒有強制執行所有限制；帳務工具也在程式內模擬，不會操作真實帳務。它適合展示問題與驗證流程，不代表已完成你家正式系統的安全認證。
我建議先挑一個已知失敗案例，保留當時的輸入、工具呼叫和結果，再加上正常對照。第一次比較時固定代理版本、測試資料與評判方式，只改要驗證的那個控制；如果同時換了模型、提示詞和測試題，就很難知道改善來自哪裡。
讀報告時也別只看總百分比。假設設備代理原本會取消別人的預約，修正後不再取消，卻開始錯誤拒絕本人操作，就需要回頭檢查身分資訊怎麼傳給工具。保留每一筆失敗對話，會比只留下「通過」兩個字更有助於下一輪修正。
此外，ACS 文件把「有處理」和「確實阻擋」分開計算：警告可能仍允許動作執行。如果需求是禁止某個操作，應確認結果真的符合禁止條件。已知案例通過後，再加入新的情境與人工抽查，避免只把手上的考題修到全對。
要開始，可以先閱讀 ASSERT 的帳務範例，再把自己的單一風險寫成可觀察的行為。更完整的追蹤紀錄與評分設計，可延伸看 Agent 評估指南；若想了解 Clarity 的設計階段用途，則看 Microsoft RAMPART 與 Clarity 說明。