Gorilla 與 BFCL：當函式呼叫變成可量測的工程問題

Gorilla 想解的不是聊天，是語法正確的呼叫

README 對這個專案的一句話定位是「Gorilla enables LLMs to use tools by invoking APIs」，並補上一句更精確的說明：給定自然語言查詢，Gorilla 產生語意與語法都正確的 API 呼叫。這裡的重點在「語法正確」。模型可以理解使用者要查天氣，卻把參數名稱寫成 city_name 而文件定義的是 location，這種錯誤在純文字對話裡無關痛癢，在函式呼叫裡就是執行失敗。專案最初用 APIBench 這個 API 集合來訓練與評估，README 稱其為當時最大的 API 集合之一。

目標讀者因此分成兩類。第一類是研究或平台團隊，手上有一批內部 API 或工具定義，想量測某個模型在這些定義上的呼叫正確率。第二類是模型供應商或評測單位，需要一個公開、可重現的基準來比較不同模型。若你只是想在應用裡接上一個代理迴圈，這個倉庫不是那個層次的工具。

BFCL 的評測流程與執行期抽象是兩條不同的線

倉庫的目錄結構本身就說明了架構。berkeley-function-call-leaderboard 是評測線，README 的更新紀錄顯示它從 V1 一路走到 V4：V2 加入企業貢獻資料與真實場景，V3 引入基於狀態的評測來處理多輪與多步工作流，V4 則轉向代理情境，涵蓋需要多跳推理與錯誤回復的網頁搜尋、代理記憶管理，以及格式敏感度。所謂基於狀態，指的是評測不只看單次呼叫的參數對不對，還要追蹤服務狀態在連續呼叫之間如何變化。

goex 是另一條線，README 描述它是一個執行期，用來執行 LLM 產生的動作，例如程式碼與 API 呼叫，並提供 post-facto validation、undo 與 damage confinement 這幾個抽象。這代表它處理的是「動作已經產生之後」的問題：如何驗證、如何撤銷、如何把損害限制在範圍內。這兩條線共用同一個倉庫，但解決的問題不同，一個量測模型，一個承接模型的輸出。

至於最早的 gorilla/inference 與 gorilla/eval，README 說明它們分別用來執行微調後的 Gorilla 模型與重現論文結果。這是倉庫裡最舊的一層，與後來的 BFCL 並沒有共用同一套評測介面。

安裝與執行：從 BFCL 目錄與推論目錄下手

README 指向 berkeley-function-call-leaderboard 目錄作為評測程式的所在，並在同一目錄下維護 CHANGELOG.md 記錄資料集與模型更新。實際的安裝指令、模型設定鍵與執行參數並沒有出現在這份 README 的內容裡，需要進到該目錄的說明文件才能確認。這一點必須說清楚：本文無法給出可貼上就執行的指令，因為材料裡沒有。

可以確定的是兩件事。第一，評測的對象清單會變動，CHANGELOG 是判斷某個模型是否已被支援的依據。第二，README 在 2024 年 4 月 1 日的更新中提到，leaderboard 加入了成本與延遲指標，這意味著評測輸出除了正確率之外還有這兩個維度，如果你的決策只在乎正確率，這部分輸出可以忽略，但它確實存在。

推論那條線的入口是 inference/README.md，README 提到 2023 年 5 月 30 日提供了 CLI 介面與 Gorilla 對話。模型本身在 Hugging Face 上以 gorilla-llm 組織發布，README 也提到早期版本同時提供 Torch Hub 與 TensorFlow Hub 的載入方式。

限制：這不是代理框架，也不保證跨版本可比

第一個限制是定位。倉庫裡沒有代理編排、沒有工具註冊中心、沒有重試策略的成品。goex 提供的是執行期的驗證與撤銷抽象，但那是低階機制，不是拿來組裝產品的框架。如果你的需求是「讓模型自己決定呼叫哪個工具並串起流程」，這個倉庫只給你評測與執行期零件。

第二個限制是可比性。BFCL 從 V1 到 V4 之間新增了類別與評測方式，V2 加入企業貢獻資料，V3 改用基於狀態的評測，V4 加入代理情境。這代表不同版本的分數不能直接放在一起比較。README 用 CHANGELOG 來追蹤這些變動，本身就暗示了基準會隨時間演化。任何拿舊分數跟新分數對照的結論都要先確認版本。

第三個限制是資料來源。V2 的說明提到資料來自企業貢獻與真實場景，這提升了貼近實務的程度，但也意味著評測集的組成部分由外部貢獻決定，你無法完全掌握其偏誤。若你的應用領域不在這些場景涵蓋範圍內，高分不代表在你的工具定義上也會高分。

替代方案：自建評測集與通用代理框架的差別

若你的目標是量測模型在自家 API 上的表現，替代做法是自己寫一份呼叫測試集，用模型輸出比對期望的函式簽章。差別在於成本結構：自建評測集的好處是貼合你的工具定義與錯誤容忍度，缺點是你得自己處理多輪狀態、錯誤回復、格式變體這幾類情境，而 BFCL 已經把這些做成類別。反過來說，BFCL 的類別是通用設計，對特定領域的覆蓋可能不如自建。

若你的目標是跑一個代理系統，替代方向是成熟的代理框架，它們處理的是工具選擇、迴圈控制與記憶，而不是評測。Gorilla 在這條路上提供的是 goex 這種執行期層，關注動作執行後的驗證與撤銷。兩者的抽象層級不同，不能互相取代：框架不會告訴你模型在你的工具上準不準，BFCL 也不會幫你把工具接起來。

維護成本與 Apache-2.0 的實務含義

授權是 Apache-2.0，README 在 2023 年 6 月 6 日的更新中特別註明當時發布的 Gorilla 模型是商業可用且採 Apache-2.0。這對企業採用是相對寬鬆的起點，但授權條款如何套用到你實際使用的模型權重、資料集與評測程式，仍需由法務確認，本文不提供法律意見。

維護成本主要來自基準的追蹤。CHANGELOG 顯示從 v1.1（2024 年 8 月）到 v1.3（2025 年 7 月）之間持續有資料集與模型更新，跨版本重新評測幾乎是必然的工作。若你把 BFCL 分數寫進內部決策文件，就需要一併記錄版本號，否則半年後沒人說得清那個數字是哪一版。

評測本身還有一個容易被忽略的成本：呼叫外部模型供應商 API 會產生費用，而 README 提到 leaderboard 已納入成本與延遲指標，說明這在社群裡被視為評測的一部分。批次跑大量題目之前，先確認計費方式。

誰該採用，誰該先確認目標模型在不在支援清單裡

需要一個公開、可重現的函式呼叫基準來比較多個模型或供應商 API 的團隊，這個倉庫是合理起點，因為 README 明確把評測程式、資料集與 CHANGELOG 放在同一個目錄下，版本脈絡可追溯。想研究模型如何產生語法正確的 API 呼叫、或需要重現論文的團隊，gorilla/inference 與 gorilla/eval 是對應入口。

不該採用的情況同樣清楚。需要現成代理框架、工具註冊或對話流程管理的團隊，這裡沒有。只想接一個模型來處理單一 API 的團隊，用 BFCL 是過重的做法。另外，若你的工具定義高度客製且與 BFCL 現有類別差異很大，先自建一份小規模測試集會比直接套用基準更有資訊量。

第一個要驗證的具體事項是目標模型是否已在 BFCL 支援清單內，這要看 berkeley-function-call-leaderboard/CHANGELOG.md 而不是 README 的更新摘要。第二個是評測流程是否需要外部 API 金鑰與相應費用。第三個是確認你要引用的是哪一個版本的分數，因為 V1 到 V4 的評測方式並不相同。

編輯結論

把 Gorilla 當成模型來用的人應該先確認自己是否需要它：倉庫裡同時存在 gorilla/inference 的推論程式與 berkeley-function-call-leaderboard 的評測程式，兩者服務的對象不同。需要替自家模型或供應商 API 建立可重複的函式呼叫基準，尤其是多輪與多步情境，BFCL 是倉庫中文件最完整的一塊，值得先跑通單一模型再擴充。若只是想要一個現成代理框架，這裡沒有你要的東西，goex 提供的是執行期抽象而非代理編排。採用前請確認三件事：目標模型是否已在 BFCL 支援清單內、評測是否需要呼叫外部供應商 API 而產生費用、以及貴團隊能否承擔隨 BFCL 版本更新而重跑基準的成本，因為 CHANGELOG 顯示資料集與模型清單在 v1.1 到 v1.3 之間持續變動。

官方來源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. ShishirPatil/gorilla on GitHub