工具調用與開源模型的 MxN 難題

背景

在封閉原始碼模型如 OpenAI 的環境下，工具調用（Tool Calling）的過程對開發者而言是透明且無縫的，但在開源模型領域，這卻演變成一個複雜的 M×N 難題。由於每個模型家族在訓練時選擇的「線路格式」（Wire Format）各異，導致推理引擎必須為每一款新模型撰寫專屬的解析器，否則就會出現 JSON 格式錯誤或推理標記洩漏等問題。

社群觀點

針對開源模型工具調用的混亂現狀，Hacker News 社群展開了多層次的討論。部分參與者認為這反映了 AI 產業仍處於極早期階段，儘管技術進步神速，但基礎設施的標準化顯然跟不上模型釋出的速度。有觀點指出，這種缺乏標準的現狀可能並非偶然，具備市場領導地位的廠商往往缺乏動力去推動標準化，因為相容性越高，用戶切換供應商的門檻就越低。

對於如何解決格式不一的問題，社群內存在分歧。一些開發者認為這並非真正的技術難題，而是一個尚未被解決的社會協作問題。他們主張透過建立如 libToolCallParser 這樣的通用函式庫，並利用現代模型輔助開發，理論上可以在極短時間內完成主流格式的適配。然而，另一派意見則指出，工具調用不只是解析文字那麼簡單，模型在訓練時對特定標記的依賴，意味著如果模型未針對特定工具集進行端到端訓練，其表現將大打折扣。這使得單純在推理層做格式轉換（如 LiteLLM 所做的嘗試）雖然能解決 API 相容性，卻無法保證模型邏輯的穩定性。

此外，關於 MCP（Model Context Protocol）是否能解決此問題也引發了辯論。有留言釐清，MCP 主要規範的是代理程式如何向模型描述工具清單，但模型輸出的原始文字如何被解析回結構化數據，依然受限於模型本身的訓練格式。更有進階討論觸及了底層架構的革新，有參與者提議是否能跳過文字解析，直接透過神經元激活來觸發工具調用，以徹底解決數據與元數據混淆導致的提示詞注入風險。但反對者認為，只要數據需要影響輸出，兩者就無法完全分離，目前的特殊標記（Special Tokens）已經是某種程度上的神經元觸發機制。

最後，不少開發者分享了實際操作中的痛苦經驗，例如在處理 GLM 或 Qwen 模型時，必須不斷進行手動清理與過濾才能讓 UI 正常顯示。這種「每個模型都要重新造輪子」的現狀，讓社群普遍共識到，雖然目前有 vLLM 或 SGLang 等引擎在努力做 OpenAI 格式的相容層，但若缺乏一種聲明式的規範來描述模型格式，這種追趕新模型的逆向工程循環將永無止境。

延伸閱讀

在討論中被提及的相關工具與資源包括：

• LiteLLM：用於適配不同供應商工具調用語法的轉接層。
• Outlines 與 XGrammar：專注於結構化生成與語法約束的引擎。
• MCP (Model Context Protocol)：由 Anthropic 推出的工具描述標準。
• Antigravity：Google 推出的一種新型編排器或協議嘗試。