AI 代理與開發工具
程式化工具呼叫在 14 款模型中有 11 款不輸 JSON，長鏈任務差距達 18.8 個百分點
新研究把 API schema 編譯為具型別的 Python stub，讓模型在單次推理中以程式串接或平行呼叫工具。方法在 BFCL v4 子集多數模型不輸原生 JSON，但目前只測到回傳參數的模擬工具，尚不能證明真實 API 工作流同樣受益。
多數代理框架要求模型每一步輸出 JSON function call，收到結果後再進行下一次推理；但能寫程式的模型也可以一次產生完整腳本。8 月 6 日發布的 [The Bitter Lesson of Tool Calling](https://arxiv.org/abs/2608.06370)將函式 schema 轉成具型別的 Python stub，模型以程式呼叫這些函式，代理外殼再於 subprocess 執行並擷取結果。這種 programmatic tool calling（PTC）可直接使用變數、迴圈與 `asyncio.gather`，避免每一段鏈結都增加一次模型回合。
研究選取 [Berkeley Function Calling Leaderboard v4](https://github.com/ShishirPatil/gorilla/tree/main/berkeley-function-call-leaderboard) 的 309 筆資料、八類任務，測試 14 款 2024 年 11 月至 2026 年 7 月間發布的模型。PTC 在其中 11 款追平或超越原生 JSON；GPT-5.6-Sol 與 Terra 分別由 72.2% 升至 82.8%、73.5% 升至 84.1%，都是 10.6 個百分點。長度至少 12 步的鏈式任務中，PTC 的整體優勢達 18.8 個百分點；平行 fan-out 測試則有 13 款不低於 JSON。
介面差異也暴露結構性邊界。Claude Sonnet 5 使用 JSON 時，在同回合要求 70 至 72 次以上呼叫會開始漏項；PTC 在 100 次呼叫仍維持完整列舉。高 fan-out 時，程式還能減少重複序列化：48 次呼叫的輸入輸出合計比較中，JSON 使用 5,097 token，PTC 為 3,535。不過低呼叫量時，PTC 因需在提示內嵌 stub 與說明，成本反而較高。
這不是所有模型都能直接換介面。GPT-4o、GPT-4.1 與 GPT-5.4-mini 會把多行程式的換行寫成字面 `\\n`，導致 subprocess 語法錯誤，成績比 JSON 低 19.7 至 26.9 個百分點。更重要的是，BFCL stub 只原樣回傳參數，沒有執行真實 API；小型消融每個條件也僅 31 至 52 題。工程團隊若採用 PTC，下一步應在受限沙箱、權限控管、超時與真實回傳值依賴下重測，不能只依賴函式參數匹配率。