AI / INTEGRATION REVIEW
Agent 用錯 API，該改模型、文件，還是產品？
想像你交給 Agent 一個很簡單的任務：
「查一下這位使用者是否存在，不要修改資料。」
API 回覆：查無使用者。
Agent 想了想，建立了一個帳號，再查一次。
這次成功了。
它回報：
「已找到使用者。」
查詢有結果，流程也走完了。
只是系統裡，多了一個你沒有要求建立的人。
這是一個假設案例，並非下述產品的實際事故。但它讓一個驗收問題變得具體：
我們要確認的，不只是最後有沒有拿到答案，也包括取得答案的過程是否符合任務授權。
把失敗帶回產品團隊
遇到這種情況，換一個更強的模型，值得評估。
但我也會問：
Agent 看到了什麼說明？用了哪個工具？API 回傳的錯誤，是否容易理解？範例是否把「查不到就建立」當成理所當然的下一步？
Microsoft 在 2026 年 10 月 19 日介紹的 Scope，提供了一個相關案例。依官方報告，Cosmos DB 團隊以八個端到端情境、五種語言比較基礎模型與 Agent Kit，評估促成 20 項 Agent Kit 問題及 27 項文件問題的修正。這是特定產品情境的官方報告，不能推論文件改善普遍優於模型升級。來源：Microsoft
對產品團隊而言，值得借鏡的是處理失敗的方式。
從「Agent 又做錯了」，走到「我們能確認哪個環節出了問題，以及誰能改善它」。
先把「成功」寫完整
回到唯讀查詢的例子。
如果驗收條件只有「最後能查到使用者」，建立帳號後再查詢，就可能拿到合格結果。
但任務原本還有另一半：不要修改資料。
我會把這個情境的驗收分成三部分：
窄螢幕可左右滑動表格，查看完整內容。
| 驗收面向 | 這個情境需要確認什麼 |
|---|---|
| 查詢結果 | 使用者不存在時，正確回報查無資料 |
| 行為邊界 | 沒有建立帳號，也沒有執行其他超出任務範圍的寫入 |
| 結果證據 | 核對受測帳號資料與相關操作紀錄，而非只看 Agent 的完成訊息 |
這裡要分清楚：超出本次唯讀任務，不必然代表繞過服務端權限。憑證可能有寫入權，但這次任務並未授權使用。
「帳號最後沒有增加」也未必足夠。
如果 Agent 曾經嘗試寫入，只是被權限擋下，資料仍可能沒有變動。這證明限制發揮作用，卻也揭露 Agent 的行為仍有待處理。
因此，資料是否改變，與是否嘗試超出任務範圍，是兩項不同的觀察。
前後資料相同，也可能漏掉寫入後又還原的過程。還需要涵蓋受測路徑的服務端操作紀錄；若紀錄涵蓋不完整，這部分應標為未知。
修正位置，需要證據支持
同樣是查詢失敗，可能需要不同的修正。
下面是我會採用的調查與分工起點，不是預先替任何一方判責。
窄螢幕可左右滑動表格，查看完整內容。
| 觀察到的現象 | 優先找的證據 | 可能的修正位置／責任角色 |
|---|---|---|
| 呼叫了錯誤 API | 工具清單、選用過程、API 名稱與描述 | 工具介面／SDK 團隊 |
| 把查無資料當成服務故障 | 實際回應、SDK 例外、文件定義 | API／SDK／文件維護者 |
| 跟隨範例建立了帳號 | 當次可見的範例版本與執行紀錄 | 範例／文件維護者 |
| 嘗試超出任務範圍的寫入 | 任務要求、可用工具、呼叫紀錄 | Agent 整合／工具權限負責人 |
| 超出任務範圍的寫入成功 | 憑證權限、服務端授權判斷、資料變更 | Agent 整合／服務端與安全共同評估最小權限 |
| 自動評分說成功，資料卻被改動 | 評分條件、狀態差異、人工核對 | 評估機制負責人 |
一個情境可能同時涉及多個環節。
文件可以更清楚，工具可以更難誤用，Agent 也可以更好地遵守任務。但若這項工作只需要讀取，就應評估能否僅提供讀取工具與權限。
「請不要寫入」不能代替服務端的授權限制。
改完之後，怎麼知道有幫助？
我會先保留修正前的任務、測試資料、評分條件及 Agent 配置，再針對選定的變更做重複比較。
例如，這次只修改「查無使用者」的文件範例，就盡量維持模型、Agent 版本、工具與測試起始狀態一致，並記錄無法固定的條件。
每次執行後，都回到相同的受控起點。否則，前一次意外建立的帳號，可能讓下一次看起來特別順利。
比較時，我不會只看總成功率，也會分開記錄：
- 正確回報查無資料的次數。
- 嘗試超出任務範圍寫入的次數。
- 實際發生超出任務範圍變更的次數。
- 需要停止或轉交人工處理時，Agent 是否確實照做。
這些數字需要一起附上試驗次數與配置。
一次成功，不能證明問題已消失；重複成功，也不能保證所有模型、工具與版本組合都適用。
Scope 本身使用模型式評判，官方也提醒需要重複執行及人工檢視。對這類情境，我會再加入直接的資料狀態檢查，避免讓另一個模型的「通過」取代實際證據。來源：Microsoft
誰負責讓它下次仍然正常？
修掉一次問題，與持續支援一條整合路徑，是不同的工作。
如果產品承諾支援 Agent 協助整合，我會把具代表性的情境放進發布驗收，並明確指定：
誰維護情境？支援哪些配置？什麼結果需要阻止發布？Agent、SDK 或文件更新後，由誰判斷是否需要重驗？
這些承諾也有維護成本。
不必承諾所有組合，但需要說清楚哪些組合已驗證，以及哪些仍在範圍之外。
對我而言，Agent 的失敗可以成為有用的產品回饋。前提是我們能把它整理成具體、可重現、有人負責的改善工作。
回到最初的例子。
Agent 說：「我已經把問題解決了。」
在接受這份結果之前，我還想問：
你完成的是我們交付的任務，還是為了完成它，改變了我們沒有授權你改變的事情？