VAKRA 重播逾 8,000 個本機 API，代理遇多跳與政策限制時準確率驟降

IBM 研究團隊公開 [VAKRA](https://arxiv.org/abs/2608.12282)，試圖補上代理評測常把工具呼叫、RAG、多跳推理與政策遵循分開測試的缺口。基準把 BIRD-SQL 等資料轉成橫跨 62 個領域、逾 8,000 個可執行 API，再配上領域文件；任務要求代理完成二至五跳推理，將前一步取得的實體或欄位轉成後續 API 參數，有些流程還必須同時遵守文字描述的工具使用限制。

評分不只檢查最終答案。系統會在本機服務重新執行代理提交的工具軌跡，先確認工具與回傳資料是否涵蓋標準答案，再檢查政策，最後以模型評審判斷回答是否由工具結果支持。這種設計容許多條有效路徑，也能區分「選錯工具」、「參數值錯誤」與「拿到資料後仍生成錯誤結論」。公開實作以 Docker 或 Podman 啟動 SQLite、FastAPI、ChromaDB 與 MCP 服務；完整資料約需 35GB 儲存空間，部分測試至少要為容器配置 8GB 記憶體。

固定使用 ReAct 外殼後，GPT-5.5 在單一端點式 Dashboard API 任務取得 70.4%，但在需要組合操作的兩種 BI API 介面只剩約 50% 至 51%。多數模型隨推理跳數增加損失逾半準確率；當政策使問題不可回答時，Claude Opus 4.7 與 Gemini 3 Flash Preview 的相關成功率最低只有 2.4%。軌跡分析顯示，瓶頸多在實體消歧、跨來源對齊及欄位語意，而非產生函式呼叫語法。

工程團隊可用這套環境檢查代理是否真的能穿越異質企業系統，但結果不能直接當成生產可靠度。資料與政策多由既有研究語料及生成流程建構，Groundedness 階段仍依賴 LLM 評審，Claude Opus 4.7 也因成本只跑了子集；此外，公開授權限制為非商業研究用途。下一步值得觀察不同規劃器、結構化政策引擎及失敗後重試策略，能否在不更換底層模型下縮小多跳落差。