本章寫的是「為什麼需要 tool use」「structured output 怎麼運作」「設計工具時該如何思考副作用」這類跟具體 framework 無關的原理。OpenAI function calling spec、Anthropic tools API、JSON Schema constrained sampling 等具體格式半年一變、不在本章焦點；本章寫的是「換 spec 之後仍然成立」的設計取捨。

本章目標

讀完本章後你能：

1. 解釋為什麼 LLM 需要呼叫工具、純生成解不了什麼問題。
2. 看到 structured output / JSON mode 設定時、知道它在限制 sampling 的哪一層。
3. 判讀「這個模型 tool use 為什麼表現崩」的常見根因。
4. 設計工具時用「副作用範圍 + 信任邊界」思考、不只看「功能對不對」。

為什麼 LLM 需要呼叫工具

LLM 的能力邊界決定了什麼任務「光靠生成解不了」：

• 即時資料：模型訓練後不知道現在發生的事。「查今天天氣」「現在股價」必須拉外部資料。
• 精確計算：模型對大數運算、長乘法、開根號等表現不穩、calculator 一行解決。
• 副作用：把檔案寫到磁碟、發 email、call API——這些是「動作」、文字本身不會觸發磁碟 / 網路 / 外部系統的狀態變更（這也是為何要設計 sandbox 來限制副作用範圍）。
• 持久化狀態：模型本身無狀態、需要外部資料庫 / vector store / file system 儲存跨對話的資料。
• 規模化操作：搜尋一千個 file、處理 batch、跑 SQL——這些是 deterministic、用程式跑比讓模型「逐字模擬」快幾個量級。

Tool use 解的不只是「能力延伸」、更是「把 LLM 跟確定性系統接起來」。沒有 tool use、LLM 只能在自己的文字宇宙裡跑；有了 tool use、它變成可以呼叫資料庫、寫檔、發網路請求的「會說話的 agent」。

這個跨界本身帶來新的問題：模型輸出必須能被工程系統消費。自然語言對人類友善、對程式不友善——下一節要解的就是這個橋。

Structured Output 是 LLM 跨入工程系統的橋

自然語言對下游 parser 不友善：同一個意思有無限種表達、模型可能加 prefix、加 disclaimer、加 markdown 格式、漏關鍵欄位。如果直接 regex 解析、會 case by case 補例外、最終 parser 比 LLM 還複雜。

Structured output 解這個問題：把 LLM 的輸出約束到預定義的結構（JSON、YAML、XML、特定 schema）。實作機制有幾種：

• Prompt-level：在 prompt 裡明確要求「請輸出 JSON、schema 是 X」。靠模型 follow instruction 的能力、不保證 100% 合法。
• JSON mode / response_format：推論伺服器在 sampling 階段（從機率分佈挑下一個 token 的步驟）對每個 token 都套合法 JSON 約束、把不合法的選項機率歸零。
• Grammar-constrained sampling：用 grammar（描述合法語法的形式化規則、實作上常用 BNF 或類似格式）描述合法輸出形狀、推論時逐 token 過濾。可以約束到任意嚴格的結構。
• Function calling 訓練：模型訓練階段就教「該怎麼呼叫工具」、輸出格式內建在模型行為裡。

四種機制的層級不同：prompt-level 是「請模型自律」、JSON mode 跟 grammar 是「sampling 階段強制」、function calling 是「訓練讓模型自然」。越靠近 sampling / 訓練端的機制越穩、但實作越複雜。

理解這個 stack 的價值是：看到「模型輸出 JSON 不穩」時、知道該往哪一層下手。Prompt 寫得清楚不夠的話、要動 sampling 約束；sampling 約束打開了還不穩、要看模型本身的 tool use 訓練覆蓋度。

Function Calling 跟 Free-form Generation 的取捨

「讓 LLM 呼叫工具」有兩條路：

Function calling（模型訓練支撐）：

• 模型訓練時看過大量「使用者問題 → 工具呼叫格式」的範例、知道該怎麼決定要不要呼叫、傳什麼參數。
• 優點：呼叫格式穩、模型「自然」知道何時該呼叫；不需要 prompt 工程寫很長。
• 缺點：受訓練資料分佈影響大、跨模型行為不一致；只支援模型訓練過的協議格式。
• 適合：主流 / 大型模型、想用最少 prompt 工程拿穩定行為。

Free-form + structured output（推論時約束）：

• 寫 prompt 描述工具、用 grammar / JSON mode 約束輸出。
• 優點：跨模型可移植、不依賴模型 fine-tune；支援任意自訂協議格式。
• 缺點：模型可能不知道「何時該呼叫」、需要 prompt 工程描述觸發條件；嚴格約束下品質可能受影響。
• 適合：跨多家 LLM 都要用同一套程式、或用較弱的模型不能依賴 function calling 訓練。

實際應用常混用：主流模型走 function calling、fallback 模型走 free-form。但混用增加維護成本、小型應用挑一條走通常更簡單。

判讀「該用哪一條」的訊號：

• 目標模型主流 + 規模大（>30B）→ function calling、函式呼叫格式通常穩、prompt 工程量最低（注意：Llama 3 70B 等大模型也有 function calling 訓練不均的 case、實際採用前最小驗證）。
• 目標模型小或非主流 → free-form + structured output、跨模型較穩。
• 想跨 LLM 供應商可移植 → free-form + 標準化 schema、不綁特定 provider 的 function spec。

為什麼本地小模型 Tool use 失敗率高

寫 code 場景的本地小模型（7B、14B 級）跑 tool use 經常失敗、表現訊號清楚：

• 呼叫格式錯（JSON 不合法、欄位拼錯）。
• 參數胡亂填（type 不對、value 超出 schema 範圍）。
• 不該呼叫時呼叫（簡單問題硬要叫 calculator）。
• 該呼叫時不呼叫（複雜計算自己算錯）。
• 連續呼叫 loop（一直叫同一個工具不收斂）。

根因有兩層、訓練端跟推論端各佔一半：

訓練端：

• Tool use 範例在預訓練資料中比例低（網路文字主要是「人類對話」、不是「人類 + 工具 trace」）。
• SFT 階段才大量加 tool use 資料、但 SFT 規模相對小、小模型容量有限、學不全。
• 大模型（70B+）SFT 學得進、能 generalize；小模型 SFT 容量不夠、tool use 只在訓練過的 narrow 場景表現好。

推論端（同一個模型在不同推論配置下失敗率不同）：

• Temperature 過高：分佈被拉平、原本合法 JSON 的 token 機率被攤稀、不合法 token 反而被 sample 到。Tool use 場景建議 T ≤ 0.3。
• Context 接近上限：tool schema + 歷史對話 + retrieval result 把 context 用滿、模型在末段對 schema 的記憶衰減、輸出開始飄。
• 多 tool / 巢狀 schema：可選工具超過 5 個、或單個 tool 參數有 3 層巢狀時、小模型 capacity 不足以同時 hold 所有結構約束。

緩解策略：

• 限制 tool 數量：把可用 tool 控制在 3-5 個內、小模型較能 handle。
• 詳細 prompt 描述每個 tool：補模型訓練的不足。
• 強 structured output 約束：用 grammar 強制輸出合法、把不合法輸出的機率在 sampling 階段壓到零。
• 重試 + fallback：第一次失敗的話、加 error feedback 重試；多次失敗 fallback 到「不用 tool」的 free-form。
• 接受能力限制：複雜 multi-step tool use 本地小模型現階段做不好、切到雲端。

判讀「該不該本地跑 tool use」的反射：先看任務的 tool 複雜度，單 tool / 簡單呼叫本地堪用，multi-step / 跨多 tool 通常需要 30B+ 模型，否則失敗率高到不實用。

工具的「副作用範圍」設計

設計給 LLM 用的工具時、除了「功能對不對」、把「副作用範圍 + 可逆性」一起納入設計。

可逆性 spectrum、由低風險到高風險：

每升一級、人類審查的需求越高、agent 的自主度越低。設計工具時、把同樣功能切到不同等級可以大幅降風險：

• 「edit file」分成「propose diff」（等級 2）+「apply diff」（等級 3）、前者自動、後者要確認。
• 「query DB」分成「SELECT」（等級 1）+「INSERT / UPDATE」（等級 4）、前者自動、後者強制確認。
• 「run shell command」是 spectrum 上分佈最廣的工具——讓 LLM 自由跑 shell 等於開放等級 1-5 全部、是常見的 over-permissioned 設計。

這個 framing 跟 OS 的權限模型同概念：least privilege 套用到 LLM tool use。每個工具設計時、先問「最差情況是什麼」、再決定該不該全自動。個人 dev 場景跑本地 LLM 的 tool use / MCP server 權限判讀（檔案系統 / shell / 網路存取邊界、第三方 MCP 信任）見 6.2 tool use 與 MCP server 的權限模型。

結構化輸出的失敗模式

Structured output 用得好的時候、parser 不用寫 error handling；用得不好的時候、會撞到幾種典型失敗：

• Schema 太嚴：模型「失敗」次數多、流程卡住。例如要求 enum 只能是 5 個值、但實際 query 有第 6 種情境、模型只能硬選一個錯的。
• Schema 太寬：模型輸出歧義、下游解析失敗。例如欄位定義成 string、模型可能輸出空字串、null、"N/A"、"none"、各種變體。
• Free-form 跟 structured 混合：要求 JSON 但同時要求「reasoning 寫在 markdown」、模型容易把 markdown 寫進 JSON string 亂掉 escape。
• 巢狀太深：超過 3 層的 JSON 巢狀、模型容易在中間漏 } 或 ,。Grammar-constrained sampling 可解、純 prompt 控制就脆弱。

緩解模式：

• Schema 寬度配合 retry：先用較寬 schema、解析失敗時 retry + 把錯誤訊息餵回模型修正。
• 拆步驟：把複雜 structured output 拆成多個小步驟、每步驟一個簡單 schema、累積成完整結果。
• Few-shot 範例：在 prompt 裡放 3-5 個正確輸出範例、比文字描述 schema 更穩。

何時不需要 Tool use

Tool use 的適用面有邊界、下列情境純生成已足夠、加 tool use 反而增加成本與失敗點：

• 純文字產出任務：寫文章、改寫、翻譯、摘要——輸出本身是文字、不需要副作用、tool use 沒戲。
• 單一回應對話：使用者問問題、模型答問題、不需要去 fetch 外部資料時。模型參數記憶覆蓋的範圍直接回答即可。
• 靠 prompt + 模型內知識能解的任務：簡單 reasoning、code generation 不需要 file I/O、解釋程式碼——這些 tool use 加進去 overhead 大於收益。
• 小型 in-process 應用、tool 數量極少（1-2 個）：可能直接 if-else 比 function calling 更簡單。

判讀反射：先問「不用 tool use 能不能做到」、能做就保留純生成路徑。Tool use 是 LLM 能力延伸、把「加 tool use」當「應用變高級」的標誌會踩到過度設計、single-call 能解的問題包進 tool 是常見浪費。

何時過時 / 何時不過時

不會過時的部分：

• 「LLM 輸出需要被工程系統消費」這個 framing。
• Structured output 是 LLM 跟工程接軌的底層機制。
• Function calling vs free-form 的取捨判讀。
• 訓練資料分佈如何影響 tool use 能力（小模型崩的根因）。
• 副作用範圍 / 可逆性 spectrum 的設計框架。

會變的部分：

• 具體 schema spec（OpenAI function spec → Anthropic tools API → 未來的標準化）。
• 各 framework 的 tool 註冊 API。
• 哪些模型 function calling 訓練得好（會隨新模型更新）。
• Grammar-constrained sampling 的具體實作（llama.cpp / vLLM / Outlines 等會持續演化）。

看到新 tool use 介面或新 framework 時、回到本章的 framing 評估：它支援哪一層的 structured output、訓練過哪些 protocol、對副作用範圍有沒有設計——這些問題的答案決定它在你的場景能不能用。

下一章

下一章：4.4 Agent 架構原理、看 LLM 自主決策的設計取捨。副作用等級跟 HITL 時機怎麼配（pre-act / mid-stream / post-hoc）見 4.5 人機協作拓樸。本地 dev 場景把 tool use 落地到「實際給 wrapper 寫權限」的 hands-on、見 Ollama 改檔案 / 寫程式碼的權限邊界；個人 dev 視角的 tool use / MCP 權限判讀見 6.2。

本章把三者的層級差異拆開、解釋為什麼會出現 MCP、跟它們在實際應用中怎麼組合。具體 spec 細節（OpenAI function calling JSON 格式、Anthropic tools API、MCP server 實作）不在本章——這些半年一變、本章寫的是「換 spec 之後仍成立」的概念結構。

本章目標

讀完本章後你能：

1. 用一句話分別說清楚三者解什麼問題。
2. 看到「啟用 function calling」「設定 structured output」「裝 MCP server」這些句子時、知道在說哪一層。
3. 判斷一個 LLM 應用該用哪幾個組合、什麼情境只需要一部分。
4. 解釋為什麼 MCP 會出現、它複用了哪個成功模式。

三個概念的層級差異

三者正交、可獨立或組合：

• 用 function calling 但不用 structured output：訓練過 tool use 的模型直接呼叫工具、靠模型自律輸出合法 JSON。
• 用 structured output 但不用 function calling：模型沒訓練過 tool use、用 prompt + grammar 強制輸出合法格式。
• 用 MCP 但不用 function calling：MCP 標準化 tool 的暴露方式、模型用什麼機制呼叫不重要。
• 三者都用：function calling 讓模型穩、structured output 約束格式、MCP 提供 tool ecosystem。

把這張表記熟、再看 LLM 應用相關討論、會發現「這個工具支援 function calling」「我的應用要 MCP」這類句子實際在說不同層級。

Function Calling 是模型能力

Function calling 是模型在訓練階段建立的能力：SFT 階段大量「使用者 query + 該呼叫什麼工具 + 傳什麼參數」的範例、讓模型學會「看到 query 知道何時呼叫、怎麼呼叫」。

判讀模型 function calling 強弱的訊號：

• 該呼叫時呼叫、不該呼叫時不呼叫的準確度。
• 呼叫格式合法率（不亂寫 JSON）。
• 參數準確度（type 正確、value 合理）。
• 多工具情況下選對工具的準確度。

這四個訊號跨模型差異大、根因是訓練資料分佈：

• OpenAI / Anthropic 旗艦模型 SFT 階段 function calling 範例大量、表現穩定。
• Llama 3 / Gemma 4 / Qwen3 開源旗艦模型 SFT 階段也加 function calling、但範例量不一、表現有落差。
• 小型開源模型（< 14B）function calling 訓練嚴重不足；tool schema 複雜、多工具選擇、巢狀參數時失敗率高、單一工具 + 平坦 schema 仍可用。

理解這點的價值：看到「這個模型支援 function calling」的宣稱、要追問「訓練範例 coverage 多廣」、不是 binary 的支援 / 不支援、是 spectrum 的訓練深度。

Structured Output 是 Sampling 約束

Structured output 是推論階段的技巧、跟模型訓練無關：在 sampling（從機率分佈挑下一個 token 的步驟）時對每個 token 做 grammar / schema 約束、不合法 token 的機率（logit、token 機率的對數）被歸零、把不合法輸出的可能性壓到不會被 sample。

主要實作機制（適用 / 限制條件附在每項下）：

• JSON mode：每步 sampling 過濾、只允許「保持 JSON 仍合法」的 token。適用：絕大多數 OpenAI 相容 API 都有支援；限制：只保 JSON 合法、不保 schema 對位。
• Grammar-constrained sampling：用 grammar（描述合法語法的形式化規則、實作上常用 BNF 或 Lark grammar）描述完整輸出形狀、推論時逐 token 過濾。適用：需要嚴格自訂格式（DSL、特定 query language）；限制：要伺服器層支援（llama.cpp、vLLM 有、有些雲端 API 沒）。
• Schema-guided：依 JSON Schema 動態決定每步允許哪些 token、強制 enum / type / required 等約束。適用：複雜結構化資料；限制：實作複雜度高、跨伺服器一致性差。
• Logit bias：對特定 token 加 bias、間接引導 sampling、最弱但最靈活的方式。適用：簡單的 token 黑名單 / 白名單；限制：無法保證結構合法。

優勢相對 function calling：

• 跨模型可移植：不依賴模型訓練、任何能跑 sampling 的模型都能上。
• 可任意自訂格式：不限於 OpenAI 或某 provider 的 function spec、想定義什麼 schema 都行。
• 保證 100% 合法輸出：grammar 約束下不可能輸出 invalid JSON。

代價：

• 約束太嚴可能跟模型「自然」輸出衝突：模型本來想說 A、grammar 強制只能說 B、品質會降。
• 實作成本：grammar 解析跟動態 logit mask 在推論伺服器要支援、不是所有 server 都成熟。
• 跟模型訓練脫鉤：模型「不知道」自己被約束、可能還是用沒用 function calling 訓練的「猜測」方式生成。

實務上 structured output 跟 function calling 經常組合：function calling 訓練讓模型「自然」傾向合法輸出、structured output 約束兜底保證「真的合法」。

MCP 是 Server 協議

MCP（Model Context Protocol、2024 年由 Anthropic 提出）是「LLM application ↔ 外部 tool server 之間的標準化協議」。它不在模型能力層、不在 sampling 層、是更高層的架構規範。

要理解 MCP 的定位、回顧 LLM 生態的歷史問題：

每個 LLM application（Cursor、Continue.dev、Claude Desktop、aider 等）要接每個 tool（檔案系統、資料庫、search、自訂 API），都得寫 adapter。N 個 application × M 個 tool 的整合成本是 N×M、生態擴張時成本爆炸。

MCP 把這個成本拆成兩段：

• LLM application 端：實作 MCP client（一次）、之後支援任意 MCP server。
• Tool 端：實作 MCP server（一次）、之後被任意 MCP client 接到。

整合成本從 N×M 降到 N+M。同樣的 ecosystem effect 跟模組零的 OpenAI 相容 API 一樣——標準化中介把生態整合複雜度從乘法降到加法。

MCP 涵蓋的「server 該提供什麼」包括：

• Tool 註冊（這個 server 提供哪些 tool）。
• Tool schema（每個 tool 的參數定義）。
• Tool 呼叫協議（呼叫方式 + 回應格式）。
• Resource 暴露（檔案、文件等讀取資源）。
• Prompt template 共享（reusable system prompt）。

這些都在 protocol 層、模型怎麼用 tool（function calling 還是 structured output）不在 MCP 規範範圍——MCP 不管你模型強不強、它只管「tool 怎麼被暴露」。

為什麼會出現 MCP

MCP 是 LLM application 生態擴張到一定程度後的必然產物。觀察生態演化：

• 2023 早期：每個 LLM app 各自寫工具整合、Cursor 接 file system、Continue.dev 接 codebase、aider 接 git——各自的 adapter 邏輯互不通用。
• 2024 中期：function calling spec 標準化（OpenAI 跟 Anthropic 各自定義）、解決「模型怎麼呼叫工具」、但「工具怎麼暴露給 application」還是各家自己處理。
• 2024 底：Anthropic 提 MCP、把「工具暴露」也標準化、補完 ecosystem 拼圖。

複用 OpenAI 相容 API 的成功模式：

• OpenAI 相容 API：標準化「介面層 ↔ 推論伺服器」、所有 IDE plugin 都接這個。
• MCP：標準化「LLM application ↔ tool server」、所有 application 都接這個。

兩者都採用同個策略：定義最小可用標準、讓生態繞著標準長、所有 player 受益。

MCP 成熟度判讀訊號（不固化在某一個時間點、用這幾個 signal 重新評估）：

• Application 採納範圍：主要 LLM application（Claude Desktop、Cursor、Continue.dev、其他主流 IDE / chat 介面）是否原生支援。
• Tool server catalog 規模：社群維護的 MCP server 數量跟覆蓋範圍（檔案系統、git、Slack、雲端 API 等是否都有現成 server）。
• 本地推論生態接入度：Ollama、LM Studio 等本地伺服器是否原生支援 MCP（或仍以 OpenAI 相容 API 為主）。
• 跨平台一致性：Windows / macOS / Linux 上的 MCP server 行為是否一致、SDK 是否穩定。

四個訊號全部成熟前、MCP 仍處於「主要 application 支援、本地生態剛開始接」的擴張期；訊號逐步達標後、預期會像 OpenAI 相容 API 一樣成為應用層的默認標準。

它跟 function calling 的關係：MCP 提供 tool 的暴露機制、模型怎麼呼叫這些 tool 仍走 function calling（如果模型支援）或 structured output（如果用約束）。三者疊加而非互斥。

三者組合的實際工作流

一個完整 LLM application 的典型 stack：

 1使用者 prompt
 2  ↓
 3LLM application（Claude Desktop / Cursor / 自家應用）
 4  ↓ (MCP client、列出所有可用 tool)
 5MCP server pool（檔案系統 server、git server、自家 API server...）
 6  ↑
 7LLM application 把 tool 描述塞進 prompt
 8  ↓
 9推論伺服器（OpenAI API / Ollama / Anthropic API）
10  ↓ (function calling 訓練 + structured output 約束)
11模型輸出：「我要呼叫 tool X、參數是 Y」
12  ↓
13LLM application 用 MCP 把呼叫送到對應 server
14  ↓
15Server 執行、回應
16  ↓
17LLM application 把結果塞進 context、回到推論伺服器繼續

三者各司其職：

• Function calling 讓模型穩定輸出工具呼叫（訓練支撐）。
• Structured output 兜底保證呼叫格式合法（sampling 約束）。
• MCP 提供 tool ecosystem、application 不用為每個 tool 寫專屬 adapter（架構標準）。

少了任一個都還能跑、但效率跟生態擴展性降一級：

• 沒 function calling、靠 prompt + structured output、跨模型品質不穩。判讀訊號：同 prompt 在不同模型上 tool 呼叫格式錯誤率差 30% 以上。
• 沒 structured output、靠模型自律、偶有失敗。判讀訊號：< 30B 模型在複雜 schema 下 JSON 合法率 < 90%。
• 沒 MCP、每個 application 自己寫所有 tool 整合、ecosystem 不可規模化。判讀訊號：團隊維護 > 5 個 tool adapter、每換 LLM provider 重寫一輪。

常見的組合誤用

三者組合在以下情境會失敗、是判讀「我的應用為何不穩」的常見候選：

• Structured output 蓋過 function calling 訓練：模型訓練時用 Anthropic tools 格式、應用強制套 OpenAI function spec 的 grammar、模型輸出「合法但語意空洞」的 JSON（schema 對、欄位填湊數）。修法：用模型訓練過的 spec、避免在 grammar 層強制改寫。
• MCP server 在 prompt context 撐爆 tool 描述：MCP server 暴露幾十個 tool、每個都有 schema 跟 description、全塞進 system prompt 把 context budget 耗光。修法：dynamic tool selection（先讓 LLM 看「tool 摘要」選相關的、再把選中 tool 的詳細 schema 塞進 context）。
• Function calling + structured output 兩邊 schema 不一致：模型訓練的 function spec 跟 application 套的 JSON schema 欄位不對、模型輸出符合訓練 spec 但不符合 application schema、parser 失敗。修法：grammar 直接從 function spec 生、避免人工維護兩份。
• MCP server 沒做 input validation、prompt injection 通過 tool 結果污染 context：tool 回的內容沒檢查、惡意內容（如 PR 留言中的「請執行 rm -rf」）被模型當指令執行。修法：tool 輸出做 sanitization、可疑內容用 sandbox 標籤包起來、模型 prompt 明確區分「使用者指令」vs「tool 結果」。個人 dev 在自己機器上跑 MCP server 的權限模型（檔案系統 / shell / 網路存取邊界、第三方 MCP 信任）見 6.2；IDE 場景中 codebase / 外部文件 / 剪貼簿等 prompt injection 攻擊面見 6.3。

何時可以只用一部分

三者組合的需求視場景而定：

• 單純 structured 輸出（不呼叫工具）：只需 structured output、不需 function calling / MCP。例：把使用者輸入分類成 enum、輸出固定 schema 的 JSON。
• In-process tool（直接 Python function）：function calling + 簡單 dispatcher、不需 MCP。應用規模小時最直接。
• 跨 application 共用 tool：才需要 MCP。如果你只寫自己用的 app、in-process 比 MCP 簡單。
• 用較弱模型：可能只用 structured output、跳過 function calling。

三者的「最小可用組合」視應用複雜度而定。早期應用通常從 function calling 開始、規模化後加 MCP、品質要求高時加 structured output 兜底——演化路徑不必一步到位。

何時過時 / 何時不過時

不會過時的部分：

• 三個層級的分界（模型能力 / sampling 約束 / server 協議）。
• N×M → N+M 的標準化收益、跟 OpenAI 相容 API 的對應。
• 三者疊加而非互斥的設計取捨。
• 「最小可用組合」的判讀框架。

會變的部分：

• MCP 是 2024-2025 才標準化的協議、未來 5 年可能演化或被新協議補充（協議層更新慢、但會更新）。
• 各家 function calling spec 的具體格式（OpenAI / Anthropic / 開放標準會持續細化）。
• Structured output 的具體實作（grammar engines / JSON mode 會持續優化）。
• 哪些工具有 MCP server 可用（生態 catalog 會擴展）。

看到新協議或新 spec 時、回到本章三層 framing 問：它解的是哪一層？能不能跟既有的另兩層組合？這個問題的答案能很快定位新東西在 stack 中的位置。

下一章

下一章：4.7 Workflow 編排模式、把多 LLM call 組合的設計模式整理出來。