微軟 ThinkingBox：衡量 AI 代理人「一致性」與「可靠性」的新基準
ThinkingBox 不是單純評估 AI 產出的文字，而是檢視代理人在執行工具呼叫（tool call）後，留下的資料庫狀態與副作用是否符合預期。微軟將此測試框架開源於 Hugging Face，讓開發者可以自行驗證模型的真實可靠度。
為何僅看「工具呼叫」不足？
在一個客訴案例中，AI 代理人完成了九次工具呼叫：查詢訂單、追蹤物流、檢視客戶資料、兩次比對退貨政策、確認無既有工單、開立新工單、記錄時間線，最後正確讀取政策，並回覆「您的問題已解決，還需要協助嗎？」
然而，物流例外仍未解除，且客戶並未得到實質的「延遲賠償」答案。
*工具呼叫本身看似完整，卻因資料庫中 ticket 狀態 被錯誤標記為 solved（應為 hold），導致最終結果不符合需求。
ThinkingBox 的核心即是捕捉這類「前後端不一致」的情形：只要後端記錄與預期不符，即算作失敗。
評測方法與規模
- 測試環境：先安裝 Typesense、啟動 MCP 伺服器與 OpenEnv 伺服器，確認服務就緒後即可執行。
- 測試內容：共 507 個具備狀態的商業工作流程，每個流程在 12 種大型語言模型（LLM）上重複執行 20 次。
- 評分依據：代理人在每次執行結束後留下的資料庫狀態與副作用（例如欄位值、工單狀態）是否與「理想終態」相符。
主要發現
| 項目 | 數據 | |------|------| | 總有效試驗次數 | 121,680 次 | | 未通過可執行檢查（executable checks）的次數 | 79,853 次 | | 失敗案例中仍「乾淨」結束且有狀態變更的比例 | 67.24% | | 檢查發現欄位值錯誤的比例 | 77.61% |
這表示，即使代理人在對話中看似順利完成任務，超過 三分之二 的失敗仍會在資料庫層面留下錯誤痕跡，而 近八成 的失敗涉及欄位值不正確。
思考「一致性成本」
一致性（consistency）不只是模型能否正確產生文字，更牽涉到 Pareto 成本前緣：在提升模型準確度的同時，可能需要額外的工具整合、測試與監控資源。ThinkingBox 讓企業能量化這筆隱形成本，評估是否值得在特定工作流程中部署 AI 代理人。
未來展望與讀者啟示
- 可重現的基準：開源的 ThinkingBox 讓開發者可自行在本地環境跑測試，快速驗證新模型或新工具的影響。
- 從「回應」到「結果」：企業在導入 AI 服務時，應將 最終資料庫狀態 作為唯一可信的評估指標，而非僅憑對話文字。
- 持續監控：即使模型在測試中表現良好，實際運營時仍需建立 執行檢查（executable checks）機制，捕捉潛在的狀態不一致。
結語：微軟的 ThinkingBox 為 AI 代理人的可靠性提供了可量化、可操作的衡量標準。對於希望在客服、物流、金融等高度依賴資料正確性的領域部署大型語言模型的企業而言，這項工具不僅揭示了「看起來正確」與「實際正確」之間的落差，也提醒我們在追求 AI 效能的同時，必須正視一致性所帶來的隱形成本。透過自行部署與驗證，業者才能在 AI 時代保持服務品質與信任度。