forge：自架 LLM 工具呼叫的可靠性層，以及它不打算做的事
A Python framework for self-hosted LLM tool-calling and multi-step agentic workflows
秒懂
- 它是什麼？
- forge 是一個 Python 框架，在單一 agentic 迴圈內處理工具呼叫的解析、重試與驗證。它用 proxy、WorkflowRunner、guardrails 中間件三種入口服務不同需求，但明確不處理多 agent 協調，也不做程式碼代理的骨架。
- 適合誰用？
- 如果你已經在用 opencode、aider、Cline 或 Claude Code，而且痛點是本地模型工具呼叫格式不穩，forge 的 proxy 模式是最低改動的切入點；如果你要的是多 agent 圖、DAG 規劃或跨 agent 協調，forge 在 README 中已聲明不在範圍內，換工具比改造它便宜。採用前先確認三件事：你的模型在 llama-server 上跑得動且能吃 --jinja，你的 Python 是 3.12 以上，以及你的部署方式要不要安裝獨立發行版的 forge-proxy。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 15 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
forge 解決的是工具呼叫的失敗率，不是流程編排
本地模型跑工具呼叫最常見的失敗不是答錯，而是格式壞掉：參數少一個括號、工具名稱拼錯、該呼叫工具卻回一段自然語言。forge 把自己定位成這一層的可靠性層。README 的敘述是，你給它一組工具，模型自己決定呼叫哪個、什麼順序，而 rescue parsing、retry nudges、response validation 這些 guardrails 在沒有任何 required_steps 的情況下也會生效。
目標讀者是有 GPU 或願意付 API 費、正在自架推論的 Python 開發者。README 舉的數字是 8B 本地模型在 26 個情境的 v0.7.0 eval 套件上從個位數提升到 84%，Sonnet 4.6 在同一工作負載從 85% 到 98%（Anthropic 的數字量測於 v0.6.0，v0.7.0 未重跑，理由是成本不低）。這些是專案自己公布的評測結果，我沒有重跑，也不建議把它當成你環境的預期值。真正值得注意的是它連強模型都能拉高，代表問題出在工具呼叫的協定層，而不是模型能力本身。
三種入口，責任邊界完全不同
forge 提供的三個使用方式不是同一件事的三種包裝。Proxy server 是獨立發行的 sidecar，命令是 forge-proxy，或用 Python 套件裡的 python -m forge.proxy 啟動，同時講 OpenAI chat-completions 與 Anthropic Messages（/v1/messages）兩種 API，塞在客戶端與本地模型伺服器之間。README 說客戶端會以為自己在跟更聰明的模型講話。
WorkflowRunner 是直接寫 Python 的路線，forge 接管系統提示、工具執行、context compaction 與 guardrails 的完整生命週期。同一條路線上的 SlotWorker 提供對共享推論槽的優先佇列存取與自動搶占，README 把它對應到多個專門 workflow 共用一張 GPU 的情境。第三種是 guardrails 中間件，你保留自己的迴圈，forge 只負責驗證回應、救援格式壞掉的工具呼叫、強制 required_steps，範例在 examples/foreign_loop.py。
這三者的選擇其實是問你願不願意把迴圈交給 forge。交給它，你得到 context 管理與搶占；不交給它，你得到控制權，但要自己處理對話狀態。
proxy 的安裝與 forge-proxy 命令的所有權
獨立發行版的安裝在 Linux 與 macOS 是 curl -fsSL https://raw.githubusercontent.com/antoinezambelli/forge/main/install.sh | sh，Windows PowerShell 是 irm https://raw.githubusercontent.com/antoinezambelli/forge/main/install.ps1 | iex。裝完開新終端，執行 forge-proxy init 建立 profile，再用 forge-proxy check 驗證。README 說明這個包自帶 forge、私有 Python runtime 與 Anthropic SDK，因此主機不需要 Python 或 pip，但它不裝後端執行檔、模型、GPU stack、服務、憑證或客戶端設定。
Python 套件是另一條路：pip install forge-guardrails 是核心，pip install "forge-guardrails[anthropic]" 加上 Anthropic 客戶端。這裡有個容易踩的設計：Python 套件刻意不裝全域的 forge-proxy 命令，Proxy 要用 python -m forge.proxy 跑。README 寫得很直接，獨立安裝器是 forge-proxy 命令與其更新、卸載生命週期的唯一擁有者。
實務上的意思是，如果你的部署流程用 pip 管理一切，你會少一個命令；如果你混用兩種安裝方式，升級與卸載的責任歸屬會變模糊。這是刻意的取捨，不是疏漏，但它會影響你怎麼寫 Dockerfile 或部署腳本。
後端選擇與 llama-server 的 --jinja 旗標
forge 支援通用 OpenAI 相容端點、Ollama、llama-server、Llamafile、vLLM 與 Anthropic。README 的建議很明確：llama-server 是首選，前十名的 eval 設定都跑在 llama-server 上；Ollama 設定較簡單，但在較難的工作負載上稍弱。
llama-server 的啟動範例是 llama-server -m path/to/Ministral-3-8B-Instruct-2512-Q8_0.gguf --jinja -ngl 999 --port 8080。--jinja 這個旗標值得單獨指出：它讓模型套用 chat template 與工具呼叫模板，是工具呼叫能不能正常運作的關鍵，少了它，後面所有 guardrails 都在補救一個本來不該發生的問題。-ngl 999 是把層數全部丟給 GPU。
Ollama 路線是 ollama pull ministral-3:8b-instruct-2512-q4_K_M，量化從 Q8_0 降到 q4_K_M。Anthropic 路線不需要本地 GPU，裝 pip install -e ".[anthropic]" 並設 export ANTHROPIC_API_KEY=sk-...。README 另外指向 docs/BACKEND_SETUP.md 與 docs/MODEL_GUIDE.md 處理完整設定與硬體對應，我沒有讀到那兩份文件的內容，所以無法在這裡轉述它們的建議。
WorkflowRunner 的最小可用範例與它揭露的設計
README 的 Quick Start 先啟 llama-server，再跑 Python。工具用 pydantic 定義參數模型，包成 ToolSpec，再包成 ToolDef 並附上實際的 callable。Workflow 物件帶 name、description、tools 字典、required_steps、terminal_tool 與 system_prompt_template。範例裡 required_steps 是空陣列，terminal_tool 設為 get_weather，意思是模型可以自由決定順序，但一旦呼叫了 get_weather 就結束。
執行端用 LlamafileClient，參數是 gguf_path、mode="native"、recommended_sampling=True。context 由 ContextManager(strategy=TieredCompact(keep_recent=2), budget_tokens=8192) 管理，runner 是 WorkflowRunner(client=client, context_manager=ctx)，最後 await runner.run(workflow, "What's the weather in Paris?")。
幾個細節值得注意。required_steps 與 terminal_tool 是選用的約束，不是必要結構，這跟 README 開頭的說法一致：工作流結構是 opt-in。TieredCompact 搭配 keep_recent=2 與 budget_tokens=8192 顯示 context 壓縮是分層策略，只保留最近兩輪，其餘壓縮進預算內。範例用的是 LlamafileClient 而不是 llama-server 的客戶端，README 的後端建議與範例客戶端並不一致，實際使用時要對照你啟動的後端挑對應的 client 類別。
什麼時候 forge 是錯的工具
README 自己列了兩個不是：不是 agent orchestrator，也不是 coding harness。第一點說得更細，forge 待在單一 agentic 迴圈裡面，多 agent 圖、DAG 規劃器、跨 agent 協調都在範圍外。如果你的架構需要一個規劃器把任務拆給多個 agent 再合併結果，你不會在這裡找到那層抽象。
第二點是它不綁定程式碼領域，所以它不提供 repo 索引、diff 套用、測試執行這類 coding agent 的基礎設施。README 給的替代路徑是反過來用：如果你已經在用 opencode、aider、Cline 這類工具，用 proxy 模式把 guardrails 疊上去，不用重寫。
還有一個沒有寫在「不是」清單裡、但從安裝說明可以推出來的限制：forge 不裝後端、模型或 GPU stack。它假設你已經有一個跑得起來的推論服務。對只想 pip install 然後什麼都有的人來說，這是一段要自己補的工作。另外 Python 需求是 3.12 以上，這會排除一些還在 3.10 或 3.11 的既有環境。
與直接呼叫模型 API 的差異在哪
最直接的替代方案是自己在應用層呼叫 OpenAI 相容端點或 Anthropic API，工具呼叫的錯誤處理自己寫。差異在於 forge 把救援與重試做成可組合的中間件，而不是散在你的業務邏輯裡。examples/foreign_loop.py 展示的就是這個用法：你保留迴圈，forge 只做驗證與強制步驟。自己寫的話，你要處理的是同一組問題：模型回傳的工具呼叫 JSON 解析失敗、模型該呼叫工具卻回文字、模型跳過必要步驟，這些都得各寫一次。
另一個方向是換更強的模型。README 的數字顯示 Sonnet 4.6 在加了 forge 之後從 85% 到 98%，這說明即使換模型也還是有協定層的損失，但換模型要付的是每次呼叫的費用與延遲，而 forge 的 guardrails 是本地執行的。兩者的成本結構完全不同：一個是推論成本，一個是整合與維護成本。
如果你的工具呼叫已經穩定，或者你的工具只有一兩個、錯誤可以人工重試，那 forge 這一層的價值就低。它值得裝的前提是你的失敗模式確實落在格式與步驟遵守上。
版本節奏、授權與升級成本
授權是 MIT，README 與 repo 標示一致，這對商業整合是寬鬆的條件，但我不在這裡給法律意見，實際條款要看 LICENSE 全文。
版本節奏可以從近期發布看出一些東西。v0.9.5 標題是 Equivalent dual-auth compatibility，v0.9.4 是 Anthropic reasoning capture，v0.9.3 是 Proxy command ownership hotfix。三個版本間隔都在一週以內，其中一個是 hotfix，而且修的是 proxy 命令的所有權問題，正好對應前面提到的雙軌安裝設計。這代表 0.9.x 期間命令與認證相關的行為還在調整，鎖版本是合理的做法。
升級成本取決於你走哪條入口。用獨立 proxy 的人，更新與卸載由安裝器負責，README 指向 docs/PROXY_INSTALLATION.md 說明支援平台、指定版本安裝、profile、更新、復原與卸載。用 Python 套件的人，升級就是 pip，但沒有 forge-proxy 命令的自動生命週期。兩條路都走的人要自己決定誰是命令的擁有者，README 已經指定是獨立安裝器。
編輯結論
如果你已經在用 opencode、aider、Cline 或 Claude Code，而且痛點是本地模型工具呼叫格式不穩，forge 的 proxy 模式是最低改動的切入點；如果你要的是多 agent 圖、DAG 規劃或跨 agent 協調，forge 在 README 中已聲明不在範圍內，換工具比改造它便宜。採用前先確認三件事：你的模型在 llama-server 上跑得動且能吃 --jinja，你的 Python 是 3.12 以上，以及你的部署方式要不要安裝獨立發行版的 forge-proxy。最後一項決定了日後升級與卸載由誰負責，README 對這點寫得很硬。
社群筆記