工具呼叫用程式碼可能更好

BFCL v4 顯示，把工具呼叫改成程式碼介面，常比 JSON 呼叫更穩、更適合並行任務。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：相較 JSON 基線提升 10.6%
• 突破點：以型別化 Python stub 呼叫工具

The Bitter Lesson of Tool Calling 這篇論文在問一個很實際的問題：當模型要用工具時，真的一定要走 JSON 嗎？作者的答案是，對會寫程式的模型來說，把工具當成程式碼來呼叫，可能更符合它的工作方式，也更適合真實 agent 流程。

這不是單純的介面偏好。工具呼叫是很多 agent 的核心動作。介面一旦卡手，模型即使本身夠強，也可能在執行層面翻車。這篇摘要的重點，就是把焦點從「模型能不能做」拉回「介面是不是用對了」。

這篇在解什麼痛點

現在很多產品級工具呼叫，還是靠結構化 JSON。這種方式好處很明顯：好驗證、好接系統、也容易做 router。但問題也很直接。當任務需要連續呼叫多個工具、分支處理，或把工作拆成多段並行執行時，JSON 介面常常顯得很僵硬。

作者把這件事描述成一個落差：模型會寫程式，不代表工具介面也讓它像寫程式一樣做事。於是他們改測另一條路，直接把工具暴露成型別化的 Python stub，讓模型用程式方式去呼叫。

摘要裡也明講，過去沒有一個系統性評估，能把 tools-as-code 和原生 JSON tool calling 放在一起，比較現代與前幾代模型在真實任務條件下的表現。這篇就是要補這個洞，而且先從 BFCL v4 下手。

方法怎麼運作

程式化工具呼叫的概念很直白。模型不再吐出一個 JSON blob，交給外部工具路由器去解讀。它看到的是一組型別化的 Python stub，然後直接用程式語法去呼叫。

這種做法把互動形狀整個改掉了。模型可以在同一個 agent turn 裡串接多個工具，也可以更自然地做 parallel fan-out。換句話說，控制流程更像一般程式，而不是一筆一筆固定格式的表單提交。

作者沒有宣稱這種方法對所有情境都一定比較好。他們的測試重點是：當介面改成程式碼後，在 BFCL v4 上，模型表現會不會更接近它本來就擅長的推理與控制流程。

對開發者來說，這個觀點很實用。很多時候問題不在 prompt，而在執行模型。模型會不會思考是一回事，它能不能順著介面把動作做完，又是另一回事。

這篇實際證明了什麼

摘要中最清楚的比較，是拿 programmatic tool calling，也就是 PTC，去對上 native JSON tool calling。測試範圍是 BFCL v4，涵蓋 14 個語言模型。

結果是，PTC 在 14 個模型裡，有 11 個模型的表現持平或優於 JSON 呼叫。這代表程式化介面不是只在少數模型上碰巧有效，而是跨模型有一定一致性。

摘要裡最明確的單一數字，是 GPT-5.6 family 相較 JSON tool-calling baseline 提升 10.6%。不過摘要沒有公開完整的 per-model benchmark 表格，所以這個數字應該視為最關鍵的代表值，而不是完整全貌。

在 parallel fan-out 的設定下，PTC 也很有看頭。摘要說它在 14 個模型裡，有 13 個模型持平或優於基線。這對需要拆工、分流、同時查多個工具的 agent 特別重要，因為這類任務本來就很吃控制流程。

另一個結果是 context rot 條件。摘要指出，基線平均退化 2.3%，而 PTC 則維持穩定。摘要沒有進一步交代 context rot 的完整設定，所以比較安全的解讀是：在作者測到的條件裡，程式化工具呼叫對這類失效模式比較不敏感。

• PTC 在 BFCL v4 上，14 個模型中有 11 個持平或優於 JSON。
• GPT-5.6 family 相較 JSON 基線提升 10.6%。
• 平行 fan-out 情境下，PTC 在 14 個模型中有 13 個持平或優於基線。
• context rot 下，JSON 基線平均退化 2.3%。

對開發者有什麼影響

如果你在做 agent，這篇論文等於在提醒你：工具介面不是小事。對會寫程式的模型來說，讓它直接呼叫型別化 Python stub，可能比硬塞進 JSON 格式更自然。

這會影響實作方式。很多 agent 任務不是單次查詢，而是有分支、迴圈、並行、階段式執行。程式化工具呼叫更像是把這些流程直接寫進可執行的控制邏輯裡，而不是靠外部協調器一層層轉譯。

它也可能減少一種常見落差：模型內部已經在「像程式一樣思考」，外部卻要求它輸出一個固定格式的 JSON。當內外介面一致一點，執行失誤的機會可能就少一點。

但這篇摘要也沒有把話說滿。它只報 BFCL v4 的結果，沒有談 latency、成本、錯誤輸入下的穩定性，也沒有討論整合時的額外負擔。所以它更像是一個值得實驗的新方向，而不是可以直接宣布 JSON 退場的結論。

還有哪些限制

這篇摘要最明顯的限制，是公開資訊還不夠完整。它沒有附上完整 benchmark 表格，也沒有把每個模型的數字一一列出。你可以知道方向，但還不能從摘要直接判定所有模型的細節差異。

另外，摘要也沒有交代 BFCL v4 之外的表現。這代表它目前比較像是「在這個基準上，PTC 很有競爭力」，而不是「在所有 agent 場景都勝出」。對實務導入來說，這個界線很重要。

還有一點值得注意。摘要提到 PTC 追蹤模型在不同發行世代的能力變化，這暗示它的優勢可能和模型本身的 coding 能力有關，不一定是每個模型、每個工作都能直接複製。

所以比較務實的結論不是「JSON 死了」，而是「如果你的模型本來就能寫程式，而且任務又常常要串工具、分流、並行，那把工具當程式碼來呼叫，值得先做實測」。

對台灣開發者來說，這篇最有價值的地方，不只是它提出一個新介面，而是它把 agent 設計的重點拉回執行層。模型能力很重要，但介面設計，可能同樣決定 agent 能不能真的跑起來。