挑選最佳 LLM 結構化輸出函式庫不該花掉你一整個禮拜的研究時間。我們用這些工具打造過生產系統，對哪些值得你花時間有非常明確的看法。這份排名清單涵蓋了全部八個主流選項，從毫無懸念的第 1 名，到你只在特定情境下才會用到的小眾引擎都有。如果你剛接觸結構化輸出，建議先閱讀我們的 LLM 結構化輸出完整指南。
排名總覽
| 排名 | 函式庫 | 語言 | 最適合 | 我們的評價 |
|---|---|---|---|---|
| 1 | Instructor | Python（+ TS、Go、Ruby） | 大多數 Python 團隊 | 預設首選，從這裡開始。 |
| 2 | Vercel AI SDK | TypeScript | TS / Next.js 專案 | TypeScript 界的 Instructor |
| 3 | BAML | Python、TS、Ruby、Go、Rust | 跨語言團隊 | 最佳 DSL 方案，成長迅速 |
| 4 | Pydantic AI | Python | Agent 管線 | 如果你在建 agent，選它 |
| 5 | XGrammar | C++/Rust（引擎） | 自架 LLM | vLLM/SGLang 背後的引擎 |
| 6 | Outlines | Python | 自架原型開發 | Python 原生的約束解碼 |
| 7 | LiteLLM | Python | 多供應商代理 | 跟 Instructor 搭配堪稱完美 |
| 8 | Marvin | Python | 快速原型 | 極度簡單，但範圍有限 |
接下來，我們逐一說明每個工具為何能上榜。
第 1 名：Instructor，預設首選
Instructor 是目前最受歡迎的結構化輸出函式庫，而且領先幅度相當大：GitHub 超過 12K 顆星、PyPI 每月下載量超過 300 萬次，還有龐大的範例、教學和整合生態系。它能拿下第一名，是因為它在核心任務上——從 LLM 取得帶型別、經過驗證的資料——做得比其他任何工具都好、都穩定。
優點
API 設計得漂亮又簡潔。你只需要裝飾一個現有的供應商客戶端（OpenAI、Anthropic、Gemini、Ollama，或其他 15 種以上），定義一個 Pydantic 模型，然後呼叫 client.chat.completions.create() 並傳入 response_model=YourModel，就這樣。Instructor 會處理 JSON Schema 產生、回應解析，以及——這是它的殺手級功能——帶有驗證錯誤回饋的自動重試。當 LLM 產出無效輸出時，Instructor 會把驗證錯誤回傳給模型，讓它自行修正。大多數情況下，第二次就能成功。
透過 Partial[Model] 實現的部分串流也是一大亮點。你可以在 token 陸續抵達時串流部分填好的 Pydantic 物件，這對於需要即時顯示結構化資料的 UI 來說至關重要。透過直接整合或 LiteLLM 實現的多供應商支援，代表你永遠不會被鎖定在單一廠商上。
缺點
它是一種執行時期方案。你的 schema 跟 LLM 實際會回傳什麼之間沒有編譯時期的型別檢查，錯誤要到執行時期才會發現。你也跟 Pydantic 緊密耦合了，如果你本來就在用（大多數 Python AI 專案都是），這沒問題，但如果沒有，就多了一層概念上的相依。這個函式庫也無法修復根本就有問題的 LLM 輸出——如果模型回傳的是用 markdown 包裹的 JSON，或在結構化回應之前先輸出一段思考鏈推理，Instructor 的嚴格 JSON 解析器就會卡住。而這正是 BAML 要填補的缺口。
價格
完全免費且開源（MIT 授權）。你只需要付 LLM API 呼叫的費用。沒有託管方案，也沒有藏在付費牆後面的進階功能。
誰該用
任何需要從 LLM 取得可靠結構化輸出的 Python 團隊。獨立開發者、新創、企業——Instructor 都能隨著你擴展。如果你不確定該選哪個函式庫，答案就是它。
結論：第 1 名，因為它擁有最好的生態系、最簡潔的 API，並解決了 90% 的結構化輸出需求。除非你有明確的理由不選它，否則就從這裡開始。
第 2 名：Vercel AI SDK，TypeScript 的標準
Vercel AI SDK 之於 TypeScript，就像 Instructor 之於 Python。它的 generateObject() 和 streamObject() 函式接受 Zod schema，並回傳完整帶型別的物件。如果你在用 TypeScript 或 Next.js 開發任何東西，這就是顯而易見的選擇。
優點
它與 TypeScript 生態系的整合非常順暢。Zod 在這裡扮演的角色就跟 Pydantic 在 Python 中一樣——它是從你的 TypeScript 型別產生 JSON Schema 的驗證層。你能獲得完整的型別推斷，所以你的 IDE 會精確知道回傳物件的結構。這個 SDK 開箱即支援 OpenAI、Anthropic、Google 和其他 20 多家供應商，而且串流體驗非常適合用 React Server Components 打造即時 UI。
更廣泛的生態系也很重要。這不只是一個結構化輸出工具，它是 TypeScript 領域佔主導地位的 AI SDK，與 Next.js server actions、串流回應和工具呼叫都有緊密的整合。你的結構化輸出程式碼能自然地融入 AI 應用的其餘部分。
缺點
它只支援 TypeScript。如果你的後端是 Python（大多數 ML/AI 基礎設施都是），你就需要在那邊另外找方案。它的重試邏輯沒有 Instructor 那麼精密——開箱即用時，你拿不到帶有驗證錯誤的自動重新提示。而且雖然 Zod schema 能涵蓋大多數使用情境，但帶有條件邏輯的複雜巢狀 schema，寫起來會比 Pydantic 模型冗長。
價格
免費且開源（Apache 2.0）。沒有進階付費方案。
誰該用
TypeScript 和 Next.js 開發者。如果你的技術棧從頭到尾都是 JavaScript/TypeScript，那在結構化輸出這件事上，真的沒有理由去看別的。
有兩個替代方案值得認識：Instructor-TS 把 Instructor 的 API 模式移植到了 TypeScript，如果你偏好那種風格的話。BAML-TS 則從 BAML schema 產生 TypeScript 客戶端——當你的團隊同時使用 Python 和 TypeScript，且希望只用一份 schema 定義時，這是正確的選擇。
| 功能 | Vercel AI SDK | Instructor-TS | BAML-TS |
|---|---|---|---|
| 串流 | streamObject() | Partial 物件 | 原生串流 |
| 供應商 | 20+ | 10+ | 任意（透過 BAML 設定） |
| Schema | Zod | Zod | BAML DSL |
| 生態系 | 最大的 TS AI 生態系 | 對應 Python Instructor | 跨語言一致性 |
結論：第 2 名，因為它是無可爭議的 TypeScript 領導者，串流體驗出色、供應商支援廣泛，且與 Next.js 深度整合。
第 3 名：BAML，跨語言的強者
BoundaryML 出品的 BAML 採用了跟這份清單上其他所有工具根本不同的做法。你用一套專用的 DSL 撰寫 .baml schema 檔案，然後為 Python、TypeScript、Ruby、Java、Go 和 Rust 產生帶型別的客戶端。把它想成 LLM 結構化輸出的 Prisma。
優點
最突出的功能是 Schema 對齊解析（SAP）。Instructor 依賴嚴格的 JSON 解析，而 BAML 能處理 LLM 輸出的混亂現實——JSON 中嵌入的 markdown、結構化回應之前的思考鏈推理、多餘的空白、尾端逗號，以及其他會讓 json.loads() 出錯的怪異情況。根據我們的經驗，這點比你預期的更重要。LLM 的輸出本來就很隨便，而 BAML 就是為了優雅地處理這種隨便而生的。
程式碼產生意味著在所有支援的語言中都能獲得完整的 IDE 自動完成和編譯時期錯誤捕捉。如果你有一個 Python 後端和一個 TypeScript 前端，你只需要在 BAML 中定義一次 schema，就能同時拿到兩端的型別安全客戶端。這用其他任何工具都很難做到。
缺點
你需要一個建置步驟。在程式碼能使用產生的客戶端之前先執行 baml-cli generate，這增加了摩擦，尤其是在快速原型開發時。DSL 也是另一樣要學的東西——它不複雜，但它畢竟不是 Pydantic 或 Zod。社群和生態系比 Instructor 小（5K+ 對 12K+ 顆星），所以你能找到的教學和 Stack Overflow 解答比較少。而且如果你是純 Python 的單一語言團隊，跨語言的優勢對你沒有幫助。
價格
免費且開源（Apache 2.0）。BoundaryML 提供託管的 playground 和測試工具，但核心函式庫是免費的。
誰該用
跨多種語言工作、希望為 LLM schema 建立單一真相來源的團隊。如果你的 LLM 輸出很混亂，而 Instructor 的嚴格 JSON 解析不夠用，它也是很好的選擇。
結論：第 3 名，因為跨語言方案和彈性解析確實獨一無二。建置步驟的摩擦讓它在單一語言團隊中無法超越 Instructor。
第 4 名：Pydantic AI，結構化輸出遇上 Agent
Pydantic AI 是 Pydantic 團隊推出的官方 agent 框架——就是打造那個驅動 Instructor 和大多數 Python LLM 工具之驗證函式庫的同一群人。結構化輸出在這裡不是附加功能，而是內建在每個 agent 中的核心原語。
優點
如果你正在打造需要帶型別回傳值、同時還要工具呼叫、相依性注入和複雜工作流程的 AI agent，所有東西都在同一個屋簷下。Agent 會回傳帶型別的 Pydantic 模型，跨 20 多家供應商自動驗證並重新提示。這個框架包含串流、圖狀工作流程，以及大多數 agent 框架所缺乏的測試方案。
Pydantic 團隊的背景賦予了它可信度和持久力。這些人比 Python 生態系中任何人都更懂驗證，而從結構化輸出層與其他一切的整合方式中就能看得出來。
缺點
Pydantic AI 的範圍比結構化輸出函式庫更廣，這既是它的優勢也是劣勢。如果你只需要從 LLM 呼叫中提取帶型別的資料，Instructor 用更少的程式碼和更少的概念負擔就能做到。Pydantic AI 的 agent 抽象層對於簡單的提取任務來說是多餘的機制。這個函式庫在 2025 年底才發布，所以生態系仍在成熟中——跟 Instructor 相比，整合比較少、範例比較少、經過實戰考驗的生產部署也比較少。
價格
免費且開源（MIT 授權）。Logfire（Pydantic 的可觀測性平台）是付費的配套產品，但完全是選擇性的。
誰該用
在 Python 中打造 AI agent 系統、而結構化輸出只是眾多考量之一（工具、記憶、工作流程）的團隊。如果你本來就打算使用 agent 框架，Pydantic AI 等於免費送你結構化輸出。
結論：第 4 名，因為它是 agent 導向架構的最佳選項，但如果你只需要結構化提取，那就太重量級了。
第 5 名：XGrammar，隱形的引擎
XGrammar 運作的層級跟上面所有東西完全不同。Instructor 和 BAML 是在 LLM 產生 token 之後才運作（驗證並重試），而 XGrammar 是在 token 產生過程中運作——遮蔽無效的 token，讓模型在物理上就不可能產出格式錯誤的輸出。它是 vLLM、SGLang 和 TensorRT-LLM 的預設約束解碼後端。
優點
零開銷的結構化輸出。透過詞彙分區和自適應 token 遮罩快取，XGrammar 比早期的約束解碼方案快上最多 100 倍。模型第一次就能輸出有效的 JSON，每次都行——不需要重試、不浪費 token。它支援 JSON Schema、正規表示式和 EBNF 文法，幾乎涵蓋你需要的所有輸出格式。
如果你在 vLLM 或 SGLang 上跑自架 LLM，不管你知不知道，你其實已經在用 XGrammar 了。它就是內建的文法引擎。
缺點
你沒辦法把它跟 OpenAI 或 Anthropic 這類 API 供應商一起用——它純粹是推論伺服器層級的技術。它沒有方便随手使用的 Python API；它的設計目的是嵌入服務框架，而不是從應用層程式碼呼叫。而且約束解碼有時會降低複雜 schema 的輸出品質，因為模型沒辦法在結構化輸出之前自由地「思考」。
價格
免費且開源（Apache 2.0）。
誰該用
在 vLLM、SGLang 或 TensorRT-LLM 上運行自架 LLM、需要保證結構化輸出且零延遲開銷的基礎設施工程師。
結論：第 5 名，因為它是從自架模型取得結構化輸出最快的方式，但如果你用的是託管 API 供應商，那就跟你無關。
第 6 名：Outlines，可改造的替代方案
dottxt 出品的 Outlines 是一個 Python 原生的約束解碼函式庫，使用基於 FSM 的 token 遮罩。它會將 schema 編譯成索引結構，讓每個生成步驟都能以 O(1) 查找有效 token。
優點
如果你想要一個真的能從應用層程式碼呼叫的 Python API，它比 XGrammar 容易上手得多。你可以直接在 Python 腳本中實驗自訂文法、正規表示式模式和 JSON Schema 約束。它支援 transformers、vLLM 和 llama.cpp，所以你在服務框架之間有彈性。超過 10K 的 GitHub 星數和活躍的社群代表文件和完善支援都有保障。
缺點
在生產推論工作負載上比 XGrammar 慢（XGrammar 的 C++/Rust 實作和詞彙分區給了它顯著的優勢）。如果你已經在用 vLLM 或 SGLang，XGrammar 是內建的——加上 Outlines 等於多了一個更慢的額外相依。這個函式庫最適合實驗和自訂文法的使用情境，而非高吞吐量的生產服務。
| 功能 | XGrammar | Outlines |
|---|---|---|
| 語言 | C++/Rust | Python |
| 整合 | vLLM、SGLang、TensorRT-LLM（內建） | transformers、vLLM、llama.cpp |
| 效能 | 最快 100 倍（詞彙分區） | 快速（FSM 索引） |
| 易用性 | 引擎層級（較無直接 API） | Python 原生、可改造 |
| 最適合 | 生產推論伺服器 | 結構化生成實驗 |
價格
免費且開源（Apache 2.0）。dottxt 提供託管 API，但函式庫本身是免費的。
誰該用
想要一個 Python 原生的約束解碼函式庫來做實驗、自訂文法或自架 LLM 原型開發的研究人員和開發者。
結論：第 6 名，因為它是最容易上手的約束解碼函式庫，但在生產環境的自架部署上，XGrammar 勝過它。
第 7 名：LiteLLM，萬用轉接器
LiteLLM 嚴格來說不是結構化輸出函式庫——它是一個統一代理，讓你在 100 多家供應商之間使用 OpenAI 相容的 API。但它能上榜，是因為 LiteLLM 搭配 Instructor 是現有的最強結構化輸出組合之一。
優點
一套 API 搞定所有事。OpenAI、Anthropic、Gemini、Mistral、Cohere、Azure、Bedrock、Ollama，還有幾十家，全部透過同一個 completion() 呼叫。由於 Instructor 支援 LiteLLM 作為後端，你能在 LiteLLM 支援的每家供應商上都獲得自動重試和 Pydantic 驗證。它還包含成本追蹤、負載平衡、速率限制，以及供團隊使用的代理伺服器模式。
缺點
它增加了一層抽象，可能讓除錯變得更困難。出問題時，你得同時診斷兩個函式庫而不是一個。LiteLLM 本身也不處理結構化輸出——你還是需要在上面疊加 Instructor（或手動處理 JSON Schema）。而且供應商相容性矩陣並非總是完美；較新供應商或功能的邊緣情況可能會落後。
價格
核心免費且開源。LiteLLM 提供帶有團隊管理功能的託管代理，但函式庫本身是免費的。
誰該用
使用多家 LLM 供應商、想避免供應商鎖定的團隊。把它跟 Instructor 搭配，就能獲得最佳的多供應商結構化輸出體驗。關於更廣泛的技術棧決策，請參閱我們的 SaaS AI 技術棧指南。
結論：第 7 名，因為它是黏合層，不是結構化輸出層。對多供應商架構來說是必需品，但永遠要跟 Instructor 搭配使用。
第 8 名：Marvin，快速原型工具
Marvin 提供了 Python 生態系中最簡單的結構化輸出 API：cast()、extract() 和 classify()。你傳入資料和型別，Marvin 搞定剩下的。
優點
上手速度快得離譜。十行程式碼就能讓結構化提取跑起來。API 直覺到你幾乎不需要看文件。做原型、示範和快速腳本，沒有比它更快的了。
缺點
它基本上只支援 OpenAI，這對生產環境的多供應商架構來說是致命傷。讓原型開發變快的簡單 API，在你需要自訂重試邏輯、部分串流或複雜驗證時就變成限制。跟 Instructor 和 BAML 相比，這個專案的開發活躍度較低，周圍的生態系也比較小。
價格
免費且開源（Apache 2.0）。
誰該用
需要在五分鐘內讓結構化提取跑起來、用於原型、示範或內部工具的開發者——且 OpenAI 是唯一的供應商。
結論：第 8 名，因為它用能力換取了簡潔。做原型完美，但你很快就會超出它的範圍。
你真的需要結構化輸出函式庫嗎？
誠實的回答：也許不需要。原生的供應商 SDK 已經出乎意料地強大了。
OpenAI 的 .parse() 搭配 Strict Mode 保證 100% 符合 JSON Schema。Anthropic 的 output_config 直接支援 JSON Schema。Google Gemini 有 response_schema。如果你鎖定單一供應商、處理簡單的扁平 schema，而且不需要重試邏輯或部分串流，原生 SDK 真的就夠了。零額外相依。
當事情變得嚴肅時，你就需要函式庫了：多供應商支援（這樣你才不會被鎖定）、帶有驗證回饋的自動重試（讓 LLM 看到自己哪裡錯了）、巢狀物件的部分串流，或者需要跨語言型別安全的複雜 schema。如果你對函式呼叫與結構化輸出的關係感興趣，這兩種做法是互補的——結構化輸出用於資料提取，函式呼叫用於執行動作。
結論：如果你只用一家供應商、schema 也很簡單，就從原生 SDK 開始。碰到它的極限時，再加上 Instructor 或 BAML。
為什麼 Techsy 選 Instructor 當第 1 名
我們在客戶專案中用 Instructor、BAML 和 Vercel AI SDK 打造過生產級的結構化輸出管線。以下是 Instructor 持續勝出的原因：
- 最快寫出能用的程式碼。 團隊中的新開發者能在一小時內加上一個結構化提取端點。用 BAML 的話，DSL 的學習曲線和建置步驟會多花一天。
- 重試迴圈簡直是魔法。 Instructor 帶有驗證回饋的自動重試能從糟糕的 LLM 輸出中恢復，完全不需要自訂的錯誤處理程式碼。根據我們的經驗，15 個欄位以下的 schema，重試恢復率都在 95% 以上。
- 供應商彈性在實務上很重要。 我們經常在同一個專案中切換 OpenAI（求速度）、Anthropic（處理複雜推理）和本機模型（控成本）。Instructor + LiteLLM 讓這件事輕而易舉。
- 生態系能回答你的問題。 當我們碰到邊緣情況時，幾乎總能找到現成的範例、GitHub issue 或部落格文章涵蓋它。BAML 和 Pydantic AI 正在追趕，但 Instructor 的領先優勢是實實在在的。
話雖如此，跨語言專案我們會切換到 BAML，agent 導向的專案則用 Pydantic AI。沒有一體適用的答案，只有一個穩固的預設選擇。
該怎麼選？決策框架
找到你對應的那一行就搞定了。
| 如果你需要... | 用這個 | 為什麼 |
|---|---|---|
| 簡單的 Python 提取，任意供應商 | Instructor（第 1 名） | 最大的生態系、最簡單的設定、15+ 供應商 |
| TypeScript / Next.js 專案 | Vercel AI SDK（第 2 名） | 原生 TS、Zod schema、串流、20+ 供應商 |
| 跨語言團隊（Python + TS + 其他） | BAML（第 3 名） | 單一 schema，為 6 種語言產生客戶端 |
| 帶有結構化回傳值的 AI agent | Pydantic AI（第 4 名） | 以帶型別輸出為核心原語的 agent 框架 |
| 自架 LLM（vLLM、SGLang） | XGrammar（第 5 名） | 預設引擎，約束解碼快 100 倍 |
| 自架且需要 Python API | Outlines（第 6 名） | Python 原生、基於 FSM 的結構化生成 |
| 多供應商抽象層 | LiteLLM（第 7 名）+ Instructor（第 1 名） | 跨 100+ 供應商的統一 API |
| 快速原型，僅 OpenAI | Marvin（第 8 名） | 最簡單的 API：cast()、extract()、classify() |
| 單一供應商，簡單 schema | 原生 SDK | 不需要額外相依 |
需要客製化方案？
如果你正在打造 AI 產品，不確定結構化輸出該如何融入你的架構，或者你需要針對特定使用情境在這些工具之間做選擇的協助——這正是我們擅長解決的問題。我們已經為提取、分類和跨不同 LLM 供應商的多步驟 agent 系統打造過結構化輸出管線。查看我們的 AI 整合服務。聯絡我們預約免費技術諮詢。
常見問題
LLM 結構化輸出最好的函式庫是什麼？
Python 的話，Instructor 是我們的第 1 名——它擁有最大的生態系、最多的供應商支援和最簡潔的 API。TypeScript 的話，搭配 Zod schema 的 Vercel AI SDK 是明確的領導者。正確的選擇取決於你的語言、供應商需求，以及你是在建 agent 還是做提取。
結構化輸出該用 Instructor 還是 BAML？
要快速設定和最大生態系，選 Instructor。如果你跨多種語言工作（Python + TypeScript + 其他），想要單一的 schema 定義，或者你的 LLM 輸出很混亂、需要 BAML 彈性的 Schema 對齊解析而非嚴格 JSON 驗證，那就選 BAML。
Instructor 比 OpenAI 原生的結構化輸出更好嗎？
OpenAI 原生的 .parse() 搭配 Strict Mode 在單一供應商、簡單 schema 的架構下運作完美。Instructor 透過帶有驗證回饋的自動重試、部分串流、多供應商支援和複雜巢狀驗證來增加價值。如果你只用 OpenAI 且 schema 是扁平的，原生 SDK 真的就夠了。
Pydantic AI 是什麼？跟 Instructor 比起來如何？
Pydantic AI 是 Pydantic 團隊推出的 agent 框架，結構化輸出是內建的原語，而非唯一焦點。Instructor 則完全專注於提取——定義模型、取得帶型別的輸出。當你需要帶有工具、相依性注入和結構化輸出協同運作的 agent 時，選 Pydantic AI。當你只需要可靠的帶型別提取時，選 Instructor。
Vercel AI SDK 如何處理結構化輸出？
透過接受 Zod schema 的 generateObject() 和 streamObject() 函式。你定義一個 Zod schema，把它和提示一起傳給函式，就能拿回一個完整帶型別的物件。它支援 20 多家供應商，包括 OpenAI、Anthropic 和 Google，並內建部分物件串流以支援即時 UI。
XGrammar 是什麼？什麼時候該用？
XGrammar 是一個約束解碼引擎——它在推論伺服器層級運作，透過在生成過程中遮蔽無效 token 來保證結構化輸出。如果你在 vLLM、SGLang 或 TensorRT-LLM 上跑自架 LLM，就用它。它已經作為預設文法後端內建在這些伺服器中了。你不會把 XGrammar 跟 OpenAI 這類基於 API 的供應商一起用。
Outlines 跟 XGrammar 比起來如何？
Outlines 是一個有直接 API 的 Python 函式庫；XGrammar 是嵌入推論伺服器中的 C++/Rust 引擎。Outlines 在實驗和自訂文法方面更容易上手。XGrammar 更快（透過詞彙分區最多快 100 倍），而且已經整合進生產推論架構。對生產環境的 vLLM 部署來說，XGrammar 是預設選擇。對研究和原型開發來說，Outlines 給你更多控制權。
Instructor 能跟 Anthropic 和 Gemini 一起用嗎？
可以。Instructor 直接支援 15 家以上的供應商，包括 Anthropic Claude、Google Gemini、Ollama、Mistral 和 Cohere。對於沒有直接支援的供應商，你可以透過 LiteLLM 路由，它透過統一的 OpenAI 相容 API 讓 Instructor 存取 100 多家供應商。
最好的 TypeScript 結構化 LLM 輸出函式庫是什麼？
Vercel AI SDK。它擁有最大的 TypeScript AI 生態系、原生 Zod schema 支援、部分物件串流，並支援 20 多家供應商。如果你偏好 Instructor 的 API 模式，Instructor-TS 是不錯的替代方案。BAML-TS 則適合在 Python 和 TypeScript 服務之間共用 schema 定義的團隊。
我需要結構化輸出函式庫，還是用原生 API 就好？
原生 API（OpenAI Strict Mode、Anthropic output_config、Gemini response_schema）在單一供應商、簡單 schema 的架構下運作良好。當你需要多供應商支援、帶有驗證回饋的自動重試、部分物件串流或跨語言型別安全時，就該用函式庫了。函式庫加上的那一層薄薄的抽象，會在 LLM 第一次回傳格式錯誤的輸出、而你的應用優雅地處理而非崩潰時，就值回票價了。