BAML：把 Agent 的輸出釘死在型別裡的程式語言

它解決的不是 prompt 問題，是輸出問題

多數 LLM 框架把精力放在怎麼寫 prompt、怎麼串 chain。BAML 的切入點不同。README 開宗明義說它「看起來像 TypeScript」，但每個功能都是為了讓 agent 犯更少的錯。這裡的錯不是答錯題，而是輸出結構不對、型別跑掉、該回 JSON 回成散文。BAML 把輸出 schema 變成語言的一等公民，型別在執行期仍然存在，沒有 any，也不准隨便轉型。換句話說，它要解決的是「LLM 回傳的垃圾資料」這個工程問題，而不是「怎麼讓模型更聰明」。目標使用者是那些把 agent 接進生產系統、需要穩定介面的後端工程師，不是做 prompt 實驗的研究員。

型別系統只是表面，重點是執行期型別還活著

很多語言有靜態型別，但編譯完就消失。BAML 宣稱型別在執行期持續存在，這意味著它不只是編譯期檢查，而是執行期驗證的基礎。當 agent 回傳的內容不符合宣告的型別，BAML 的執行期可以攔截，而不是讓髒資料流進下游。README 特別強調「沒有 any 也沒有危險的轉型」，這在 LLM 輸出場景是關鍵，因為模型輸出本質上是非結構化的，你必須有一個機制把它硬轉成結構。BAML 的做法是讓這個轉換過程受型別系統管轄，而不是靠開發者手寫 parsing 再祈禱沒錯。它還提到錯誤是型別化且靜態分析的，意思是連失敗路徑都被納入型別設計，這比多數框架的 try-catch 更嚴格。從 repository 的 Rust 實作來看，這是個編譯器等級的專案，不是簡單的 wrapper。

檔案系統即模組，綠色執行緒與無色並發

BAML 的模組系統不走 import 語句，而是用檔案系統描述命名空間。這是一個大膽的設計，目錄結構就是模組結構，少了 import 地獄，但也代表重構檔案時要連帶改所有引用。它還宣稱有綠色執行緒和「無色並發」，這個詞來自 Go 的哲學，意思是函式不必區分同步或非同步，呼叫端不需要知道底層是否阻塞。對 agent 程式來說，這解決了一個實際痛點：agent 經常要並行呼叫多個工具或模型，傳統 async/await 會污染整個呼叫鏈。BAML 讓並發變成語言內建行為，開發者不用在每個函式前面加 async。不過 README 沒有給出具體語法範例，實際使用時需要查文件確認這套並發模型怎麼寫。

從 brew install 到跨語言呼叫的實際路徑

README 給的起步指令很直接：brew install baml，然後 baml agent install，再 baml init，最後 baml ide install --code 安裝編輯器外掛。這四個指令假設你在 macOS 且有 Homebrew，Windows 或 Linux 使用者得另尋安裝方式。baml init 會產生一個專案骨架，之後你寫 .baml 檔案定義型別和函式，再用 baml ide 獲得語法高亮和靜態檢查。關鍵的採用策略是「可以獨立執行，也能漸進採用」，README 明說你可以從 TypeScript、Python、Go、C#、Java 呼叫 BAML 函式。這代表 BAML 不是一個要你全部重寫的框架，而是可以嵌進現有 agent 程式的一個模組。實際運作時，BAML 編譯器會生成對應語言的 binding，你在原語言裡像呼叫本地函式一樣呼叫 BAML 定義的 agent 任務。

nightly 版本與 Rust 核心：維護成本的線索

從 release 頁面看，最新版本是 0.18.1-nightly.20260908.a，而且預設分支叫 canary。這透露兩個訊號：專案還在快速迭代，且 nightly 版本是常態。對生產團隊來說，追 nightly 意味著 API 可能隨時變動，編譯器行為也可能改。repository 主要語言是 Rust，這對效能是好事，但對貢獻者來說門檻高，不是每個 agent 開發者都熟 Rust。授權是 Apache-2.0，這對商業使用友善，沒有 copyleft 包袱，但你要自己注意相依套件的授權。README 沒有提到升級路徑或遷移工具，考慮到語言還在 0.x 階段，跨版本升級很可能需要手動改 .baml 檔案。維護成本不會低，尤其是當你依賴 IDE 外掛和編譯器兩者的版本同步。

當 BAML 是錯的工具：動態 schema 與快速原型

BAML 的強項是靜態型別，但這也直接是它的限制。如果你的 agent 需要根據使用者輸入動態產生輸出結構，例如讓 LLM 自己決定回傳哪些欄位，BAML 的型別系統會卡住你，因為你必須在編譯期就宣告所有可能的形狀。另一個不適合的場景是純 prompt 實驗，你只是想知道某個模型能不能輸出特定格式，這時候寫 .baml 檔案、跑編譯器、生成 binding 的流程太重。README 自己承認它可以漸進採用，但漸進採用仍然要求你先建立一個 BAML 專案並學會它的語法。對於一次性 script 或內部工具，直接用 Python 的 Pydantic 或 TypeScript 的 Zod 做輸出驗證會更快，雖然那沒有靜態分析錯誤的好處。

替代方案的真實差異：驗證函式庫 vs 語言

最直接的替代不是另一個 agent 框架，而是輸出驗證函式庫。Pydantic 之於 Python、Zod 之於 TypeScript，它們都做執行期 schema 驗證，也能把 LLM 輸出轉成型別安全的物件。差別在於：驗證函式庫是事後檢查，你寫一般的程式，呼叫 LLM，拿到字串，再丟給 validator。BAML 把 schema 變成語言的一部分，編譯器可以在你寫錯型別時就報錯，而且錯誤是型別化的。另一個替代是 JSON Mode 或 function calling 的內建機制，OpenAI 等供應商提供強制 JSON 輸出的選項，但那只能保證格式，不能保證內容符合你的業務邏輯。BAML 的型別系統可以表達像是「這個欄位是 enum，而且只能是這三個值」的約束，function calling 做不到。選擇的關鍵在於你多依賴編譯期保證：如果只是要擋掉偶發的壞 JSON，驗證函式庫就夠；如果要建立大型 agent 系統，BAML 的靜態分析才有價值。

結論：先確認供應商清單與版本節奏再上車

BAML 不是一個「試試看」的專案，它是一個要你改變開發流程的語言。它的型別系統、執行期型別、內建測試框架和跨語言 binding 都是為了解決 agent 輸出不可靠的問題，而且設計上明顯參考了 Rust 和 Go 的優點。但它的代價是學習曲線、nightly 版本的穩定性風險，以及對靜態 schema 的依賴。我會建議符合以下條件的人採用：你的 agent 要處理大量結構化輸出、你已經受夠手寫 parsing 和驗證、你的團隊願意投資學一個新語言。不符合的人包括：只寫 prototype、需要動態輸出、或不想維護額外建置步驟。採用前務必做兩件事：第一，去 boundaryml.com/explore 看實際範例，確認 BAML 的語法風格你團隊能接受；第二，檢查 baml 是否支援你用的模型供應商，因為 README 沒有列出供應商清單，這點要自己查證。若這兩關都過，BAML 值得放進你的工具鏈，否則就用 Pydantic 或 Zod 撐著。

編輯結論

BAML 適合那些受夠 LLM 回傳髒資料、想要在編譯期就抓住 schema 錯誤的團隊，尤其是已經用 TypeScript、Python、Go、C# 或 Java 寫 agent 的人。不適合只想快速寫個 prompt、不願引入新語言和建置流程的個人專案，也不適合需要動態 schema 的場景，因為 BAML 的型別系統本質上要求靜態定義。採用前務必先確認三件事：你的 LLM 供應商是否在 baml 的支援清單內、nightly 版本的更新頻率是否會拖累你的 CI、以及團隊是否願意維護一份額外的 .baml 檔案與對應的生成程式碼。若你無法接受「為 agent 寫編譯器」這個前提，直接用 Zod 或 Pydantic 做輸出驗證會更輕量。

官方來源

1. BoundaryML/baml on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases