Rig：用 Rust 打造模組化 LLM 應用，但先讀懂它的取捨
⚙️🦀 Build modular and scalable LLM Applications in Rust
秒懂
- 它是什麼？
- Rig 是 Rust 生態中試圖統一 LLM 供應商與向量資料庫介面的框架，背後有明確的架構切割與實驗性質的版本承諾。本文從實際程式碼與文件出發，拆解它的設計、啟動方式與適用邊界。
- 適合誰用？
- Rig 適合已經用 Rust 寫後端、需要同時對接多個 LLM 供應商或向量資料庫的團隊，尤其是看重 OpenTelemetry GenAI 語意與 WASM 可攜性的專案。不適合追求 API 穩定、不願頻繁跟上破壞性變更的產品，因為 README 明言未來數月會持續推出 breaking changes。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這不是另一個 Python 框架的移植，而是 Rust 原生的 LLM 抽象層
Rig 解決的問題很具體：Rust 工程師要接 LLM，通常得面對各家 SDK 的型別不一致、串流處理方式不同、工具呼叫格式互不相容。Rig 把這些差異收斂到單一介面後面。README 列出 20 多家模型供應商與 10 多家向量資料庫整合，全部透過統一的 completion、embedding 與 vector store trait 操作。它服務的對象是那些不想為每家供應商各寫一套 adapter 的團隊，尤其是像 ilert 或 Nethermind 這樣需要多供應商備援或多代理協作的系統。Rig 不是 LangChain 的 Rust 克隆，它的核心切割方式更接近「先定義合約，再談代理」。
rig-core 與 rig-agent：把可攜帶邏輯和代理執行緒分開的架構
Rig 的架構在 0.40 之後明顯重組。rig-core 只放 provider-neutral 的訊息、completion model、可攜帶工具、記憶體與向量儲存合約，以及內建的供應商映射。rig-agent 則包含 classic builder、prompt 與 streaming trait、型別化 hook、contextual tools、extraction，以及一個可序列化的 AgentRun 狀態機。這個切分的意義在於：如果你的應用只需要呼叫模型或嵌入，不一定要拉起整個代理執行緒；反之，代理邏輯可以依賴 core 的介面，不受特定供應商綁死。README 特別註明 rig-agent 預設啟用，根 crate rig 同時 re-export 兩者，所以多數程式碼只需相依 rig。這樣的設計讓核心可以編譯到 wasm32-unknown-unknown，而 rig-agent 的 classic runtime 也支援瀏覽器 WASM，但 WASI 與 MCP 相關的 rig-rmcp 僅限原生平台。換句話說，Rust 的無瀏覽器 WASM 場景在這裡被明確排除。
從 README 的範例看實際啟動流程
Rig 的入門方式沒有提供完整 code sample 在 README 中，但從文件結構可以推斷流程：先在 Cargo.toml 加入 rig 相依，然後選擇一個 provider 的 feature。官方文件 rig.rs/docs 與 docs.rs API reference 提供詳細範例。典型做法是建立一個 completion model，例如用 OpenAI 相容的 client，接著呼叫 completion 或 embedding。若要使用代理，則透過 rig-agent 的 builder 設定 system prompt、工具與 hook。README 強調 minimal boilerplate，意思是抽象層幫你處理 request 格式，但這不代表沒有學習曲線，你仍需理解 rig-core 的 trait 與 rig-agent 的 builder 生命週期。實際跑起來的第一步，應該先參考 docs.rs 上 rig 的最新版範例，因為舊版範例可能因 breaking changes 失效。
GenAI 語意相容與可觀測性的務實選擇
Rig 宣稱完整支援 OpenTelemetry 的 GenAI Semantic Convention。這不是行銷詞，而是代表它產生的 span 與 attribute 會遵循業界定義的命名，例如 LLM 呼叫的 token 數、模型名稱、工具呼叫等欄位。對維運 LLM 應用的團隊來說，這直接影響你能不能用標準儀表板監控成本與延遲。Rig 把這項能力內建，而不是留給使用者自行打點。這在 Rust 生態中相對少見，多數 SDK 只提供基本 logging。不過相容性不等於完整實作，你仍需要自己接 OpenTelemetry exporter。文件沒有細列哪些 attribute 被覆蓋，所以上線前最好用測試環境驗證 span 是否符合預期。
供應商與向量庫的整合廣度，以及它帶來的隱藏成本
20 多家模型供應商與 10 多家向量資料庫的整合，聽起來很誘人，但這代表 rig-core 必須為每家供應商撰寫 trait 實作。廣度帶來的好處是切換供應商時，應用層程式碼幾乎不動。代價是每個供應商的行為差異會被抽象化，例如某些模型不支援 tool calling，或 embedding 維度不同。Rig 的統一介面會強迫你使用最低公分母，還是保留各家特色？文件沒有明說。從 README 的「one singular unified interface」口號來看，它傾向於抹平差異，這對於需要特定供應商進階功能的團隊可能反而是限制。此外，新增一個供應商通常需要等待上游 PR 合併，無法自行擴充，除非你 fork。
明確的破壞性變更警告，這是特色還是警訊？
README 開頭就放了 warning：「Here be dragons!」並說明未來數月會有一連串功能更新，且會包含 breaking changes。這對 Rig 的採用決策影響巨大。v0.42.0 在 2026 年 8 月釋出，距離 v0.40.0 只有一個多月，代表迭代速度極快。對一個還在 0.x 版本的專案來說，API 不穩定是常態，但 Rig 特別強調 migration path 會隨變更提供。這表示團隊有意識地管理破壞，但使用者仍需投入時間追蹤 changelog。如果你的產品生命週期長，或你不想每季改程式碼，這會是主要障礙。反之，如果你能接受鎖定版本並定期升級，Rig 的活躍發展反而是好處，因為功能會快速補齊。
與直接使用供應商 SDK 的差異，以及替代方案的實際比較
最直接的替代方案是使用各家官方 Rust SDK，例如 OpenAI 或 Anthropic 的 crate。差異在於：官方 SDK 專注單一供應商，型別完全貼合該 API，升級時跟著上游走，沒有抽象層的語意損失。Rig 則提供跨供應商的統一型別，換供應商時只需改 client 初始化，但這也意味著你失去該供應商特有的參數，例如某些模型的 logprobs 或 moderation 設定。另一個替代方案是其他 Rust LLM 框架，但 README 沒有指名，因此無法具體比較。若你的需求只是 prototype，直接呼叫 REST API 可能更快；若你要建多代理系統，Rig 的 AgentRun 狀態機與序列化能力才有價值。實際選擇取決於你多常需要切換供應商。
授權與維護成本：MIT 帶來的自由與快速迭代的負擔
Rig 以 MIT 授權釋出，這對商業使用相當友善，你可以自由整合、修改，甚至嵌入專有產品，只要保留著作權聲明。但授權自由不等於維護免費。Rig 的版本節奏快，v0.40 到 v0.42 之間僅相隔約五週，每個版本都可能調整 trait 或 builder 介面。升級時，你需要對照 release notes 修改程式碼，這是實際的維護成本。文件提到會標註 migration path，但沒有保證每個 breaking change 都有自動遷移工具。另外，rig-rmcp 的 MCP 支援僅限原生平台，如果你的部署目標是 WASI，這部分直接不能用。採用前，建議先追蹤 rig 的 GitHub issues 或 Discord，了解近期 breaking changes 的實際影響範圍，再決定是否投入。
編輯結論
Rig 適合已經用 Rust 寫後端、需要同時對接多個 LLM 供應商或向量資料庫的團隊，尤其是看重 OpenTelemetry GenAI 語意與 WASM 可攜性的專案。不適合追求 API 穩定、不願頻繁跟上破壞性變更的產品，因為 README 明言未來數月會持續推出 breaking changes。採用前應先確認你依賴的供應商 SDK 與向量庫在 rig-core 的 trait 映射中是否完整，並鎖定一個具體版本，例如 v0.42.0，搭配 Cargo.lock 追蹤升級。若你的核心需求只是單一供應商的簡單呼叫，直接用該供應商的官方 SDK 會少一層抽象，也少一層遷移成本。
社群筆記