📍 真實場景
小林，在小公司當後端工程師，剛用 vLLM 自架一個開源模型，要做公司內部的 AI 助理
他讓模型透過「工具呼叫」去查網頁、查資料庫，但助理偶爾會突然當機或答非所問
😖 卡住的地方：他翻遍紀錄才發現，模型有時會吐出格式錯誤的工具呼叫。每 25 次大約就有 2 次，後面的對話全建立在錯誤內容上
💡 讀完你會知道問題出在哪、vLLM 0.31 之後怎麼開一個伺服器旗標來解決，以及今天就能怎麼驗證自己的系統有沒有中招
⚡ 一句話講清楚
AI 要使用外部工具（例如「抓取網頁內容」），其實分兩步：先把可用工具的清單告訴模型，這份清單是一份 JSON一種把資料整理成「名稱: 內容」的固定文字格式，程式很容易讀懂 ，裡面寫著工具名稱、需要哪些參數；再要求模型照這個格式，輸出「我要呼叫哪個工具、參數填什麼」。這個「照格式輸出」的環節，就是工具呼叫（tool call）。
問題在於模型是用「一個字一個字猜下一步」的方式產生文字，不是真的在填表單，所以偶爾會寫歪。Ubicloud 這篇文章的實測是：用 vLLM 0.28 版跑 Kimi K2.6，只有 92% 的工具呼叫符合預期的 schema事先規定好的格式規格，例如「url 必須是字串、format 只能是 text、markdown 或 html」 ，也就是每 25 次就有 2 次失敗。對需要連續多輪對話的 agentic 任務讓 AI 自己決定步驟、反覆呼叫工具去完成一件事的用法 ，一次錯誤會讓後面全部建立在無意義的內容上，品質就明顯掉下來。作者因此說，自己用開源模型時看到的結果，常和評測分數差很遠。
解法是 受限解碼（constrained decoding）在模型每猜一個字時，系統先把「不符合格式的選項」直接擋掉，模型只能從合法的字裡選 。vLLM 近期加入這項技術，並在 0.31 版變成伺服器端的一個旗標。文章指出，打開之後，搭配較新的 Kimi 與 DeepSeek 模型，格式正確率可以到 100%。要注意的是，它保證的是「格式正確」，不代表模型挑對了工具或填對了內容。
🏃 快速上手三步（今天就能做）
1
查：你的 vLLM 是哪一版 在跑 vLLM 的那台機器執行 pip show vllm（或 python -c "import vllm; print(vllm.__version__)"）確認版本號。文章提到旗標是 0.31 版才以伺服器參數釋出，所以低於 0.31（例如文章測試的 0.28）就是潛在受害者。接著到 vLLM 官方文件或 0.31 的 release notes，搜尋 tool calling 與 constrained decoding，找出實際的旗標名稱，不要憑記憶猜。
▼
2
試：先量出自己的失敗率，再開旗標比較 準備 50 到 100 個會觸發工具呼叫的測試問題，跑一輪並記錄「輸出能不能被 JSON 解析」和「是否符合你定義的 schema」（Python 可用 jsonschema 套件驗證），算出通過比例。接著升級到 0.31 以上、加上文件查到的旗標，用同一批題目再跑一次。有量過前後差異，才知道旗標對你的模型有沒有用，文章的 92% 到 100% 只是它們的實測結果。
▼
3
注意：只保證格式，不保證判斷正確 文章的實測對象是較新的 Kimi 與 DeepSeek 模型，你用的模型不一定有相同結果，所以要在自己的模型上驗證。另外，格式 100% 正確後，仍要抽查「選對工具了嗎、參數值合理嗎」，例如抽 20 筆人工看。判斷標準是：格式失敗率歸零，而且任務完成率沒有下降，才算真的改善。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼工具呼叫的格式錯誤，比一般的答非所問更危險？
一般的錯誤答案，使用者看得到，可以重問。工具呼叫的錯誤多半發生在系統內部：格式壞掉可能直接讓程式報錯，更糟的是被寬鬆解析後帶著殘缺參數執行，結果又被當成上下文送回模型。錯誤會在多輪對話中層層累積，而且不易察覺。所以把「格式」從機率問題變成保證，是用工程手段換取穩定性，這比期待模型『下次會更乖』可靠。
🔭 受限解碼在每一步限制可選的字，會有什麼代價或取捨？
好處是格式必定合法，不用再寫重試與修補的程式。可能的代價是：每一步多了檢查合法字詞的運算，延遲與吞吐量可能受影響（文章摘錄沒有提供這部分數據，上線前要自己壓測）；而且被強制套進格式時，模型原本想寫的內容可能被迫改成別的合法字，這就是為什麼要同時抽查語意品質。另外，旗標綁在 vLLM 0.31 以上，升級也要評估對現有部署的相容性。
ai-lecturer 速報｜藍圖 flash-brief-v1.0｜零外部依賴