導讀：2026 年，20B 以上的開源模型已能在消費級硬體上流暢運行，但接進 Agent 框架後，工具呼叫成功率常常不到一半。27 篇頂會論文指向同一個結論：瓶頸不在模型，在框架。
現象
Gemma4 26B 跑在 M4 Pro 48GB 上，單輪問答流暢，推理品質不錯。放進需要呼叫工具、維持多輪對話的 Agent 系統後，狀況就來了：JSON 格式出錯、工具參數拼錯、三輪之後忽略原始指令。
你的第一反應可能是「模型不夠大」或「量化損失太嚴重」。但 Berkeley Function Calling 排行榜上，8B 級的 xLAM-2-8b 已經是 function calling 冠軍（Zhang et al., 2024）。Gemma4 26B 在參數量和指令遵循上都超過這個基準。能力不是問題。
回顧 27 篇 2024 至 2026 年發表於 ICML、ACL、NeurIPS 等會議的研究，失敗的根因幾乎都在模型外圍：提示格式、上下文管理、工具架構。
提示裡的一個記號，就能毀掉整條工具鏈
要求模型回傳 JSON，產出的結果看起來像 JSON，卻過不了解析器。原因細微到你很容易忽略。
2026 年的一項研究（arXiv:2605.02363）測量了提示格式對結構化輸出的影響。Gemma 系列在提示中包含 markdown code fence（```json ```）時，結構化輸出成功率是 0%。把 code fence 拿掉，成功率升到 80%。Llama 系列碰到 LaTeX 符號也有類似問題，移除後成功率從 8.5% 升到 39%。模型不是「不會寫 JSON」，是特定的提示格式干擾了它的輸出分布。
解法也不複雜。XGrammar（arXiv:2411.15100）是一套結構化解碼引擎，在推理時強制輸出符合指定 JSON Schema 的結果。成功率 100%，額外延遲近乎為零，速度是 Outlines 的 100 倍。部署後格式問題不再出現。這不是什麼高深的演算法改進，就是在推理管線裡加一層語法約束。但效果是徹底的。
對話越長，模型越聽不見你在講什麼
格式問題解決了，還有一個更棘手的：多輪對話中的語意流失。
多輪對話後指令理解率平均下降 39%（arXiv:2505.06120）。不是模型遺忘了。是 context window 被系統提示、工具定義、對話歷史逐輪填滿，有效指令在注意力分配中被擠到邊緣。
怎麼辦？RECAP（arXiv:2509.04472）用了一個很直覺的做法：每輪結束時把使用者意圖濃縮成一句話，後續輪次只看這句改寫，不回溯完整歷史。瓶頸從「模型能記多少」轉移到「摘要寫得好不好」，後者容易控制得多。
另一種浪費更隱蔽：使用者偏好設定。偏好檔、工作流規則，這些設定佔大量 context 卻每輪重複。POPI（arXiv:2510.17881）的做法是把設定檔濃縮成 50 至 100 個 token 的摘要注入推理。省下上千 token，模型才有空間處理真正的指令。
壓縮系統提示本身也有效。LLMLingua-2（Pan et al., 2024, ACL）以 token 分類方式把提示壓到原來的二到五分之一，任務表現幾乎不變。26B 的 context window 比 8B 寬裕不少，壓縮後多輪穩定性仍有明顯改善，說明 context 浪費的問題跟 window 大小無關。
工具不夠用的時候
前兩個問題都有相對明確的解法。第三個比較開放：Agent 系統預定義的工具集無法覆蓋所有使用場景，而使用者的需求天然會超出這個集合。
換個角度想：找不到工具，何不直接寫程式？CodeAct（Wang et al., 2024, ICML）就是這個思路。模型在沒有匹配工具時直接生成 Python 程式碼，在本地直譯器中執行。效能比固定 JSON action 格式高 20%，不需要預先註冊工具（arXiv:2402.01030）。工具集從一份清單擴展成了整個 Python 生態。
ToolMaker（ACL 2025, arXiv:2502.11705）走得更遠：給它一個 GitHub 倉庫的 URL，它能自動安裝依賴、生成 Python 包裝函式，成功率 80%。也能掃描本機已安裝的 Python 套件自動轉成工具。工具缺口的解法正在從「人工維護清單」走向「自動發現和生成」。
代價是安全邊界模糊了。模型在本地跑任意 Python 程式碼，一行 os.remove 就可能造成不可逆的損害。生產環境中需要沙箱隔離，至少要限制檔案系統和網路存取。
微調值不值得做？
以上都是不動模型權重就能落地的方案。那如果願意投入微調呢？
先看一個數字。OPT-350M，350M 參數，經過針對工具呼叫的 SFT 之後，準確率達到 77.55%，而 ChatGPT 用 Chain-of-Thought 提示只有 26%（arXiv:2512.15943）。訓練資料可以用 ToolACE（arXiv:2409.00920）自動合成，不需要手工標註。在 Apple Silicon 上跑 QLoRA 微調也已經是成熟的工作流。350M 都能拉到這個水準，26B 模型針對特定工具集微調後的表現很有想像空間。
更遠的方向還包括讓 Agent 自己製造和管理工具。SMITH（arXiv:2512.11303）把工具庫和記憶系統做成統一架構，Agent 可以動態創建工具、跨任務共享經驗。聽起來很美好，但目前還停留在 benchmark 階段（GAIA 81.8% Pass@1），離生產環境有距離。
也有人嘗試把問題拆開來：規劃用一個模型、工具呼叫用另一個、結果彙整再用一個（arXiv:2401.07324）。降低了單一模型的負擔，但增加了系統複雜度和延遲。適不適合本地部署，取決於你願意為穩定性付出多少推理開銷。
回到眼前。清理提示格式、加上結構化解碼、壓縮系統提示，三件事不換模型、不微調、當天就能驗收結果。先把框架端的債還完，再考慮動模型。
常見問題
Q：Apple Silicon 上跑 26B 模型需要什麼配置？ A：M4 Pro 或 M4 Max 搭配 32GB 以上統一記憶體。48GB 可舒適運行 26B Q4 量化版，MLX 推理速度約每秒 20-40 token。
Q：結構化解碼會拖慢推理速度嗎？ A：XGrammar 的額外延遲近乎為零，速度是 Outlines 的 100 倍。在 26B 模型上使用幾乎感受不到差異。
Q：這些方法只適用於 macOS 嗎？ A：結構化解碼和 Prompt 壓縮全平台通用。MLX 是 Apple 專屬框架，Windows 和 Linux 可用 llama.cpp 或 vLLM 替代。
Q：論文數據能直接套用到生產環境嗎？ A：多數研究在受控 benchmark 上測試，與真實使用場景有落差。結構化解碼和提示壓縮已有成熟開源實作，可直接驗證；CodeAct 和 ToolMaker 的安全邊界仍需你自己根據部署條件評估。本文是研讀心得，不是系統性文獻回顧。
References
- (2026). When Correct Isn't Usable: Structured Output Reliability in LLMs. arXiv:2605.02363
- Wang et al. (2024). XGrammar: Flexible and Efficient Structured Generation Engine. arXiv:2411.15100
- Wang et al. (2024). CodeAct: Executable Code Actions Elicit Better LLM Agents. ICML 2024. arXiv:2402.01030
- Pan et al. (2024). LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression. ACL 2024 Findings. arXiv:2403.12968
- Zhang et al. (2024). xLAM: A Family of Large Action Models to Empower AI Agent Systems. arXiv:2409.03215
- Wang et al. (2025). RECAP: Rewriting Conversations for Accurate Intent Preservation. arXiv:2509.04472
- Qian et al. (2025). POPI: Personalizing LLMs via Preference Inference from Conversations. arXiv:2510.17881
- Yuan et al. (2025). ToolACE: Winning the Points of LLM Function Calling. arXiv:2409.00920
- Shi et al. (2025). SMITH: Self-Evolving Agent with Dynamic Tool Creation and Memory. arXiv:2512.11303
- Shi et al. (2025). LLMs Get Lost in Multi-Turn Conversation. arXiv:2505.06120
- (2025). Small LLMs for Efficient Agentic Tool Calling. AAAI 2026 Workshop. arXiv:2512.15943
- Liu et al. (2025). ToolMaker: LLM Agents Making Agent Tools. ACL 2025. arXiv:2502.11705
- (2024). Small LLMs Are Weak Tool Learners: A Multi-LLM Agent. arXiv:2401.07324
CYHsieh | 2026-05-11 基於 27 篇論文 (2024-2026) 的研讀心得，非系統性文獻回顧