brainlid/langchain：Elixir 專案要接 LLM 時，值不值得引入這層抽象
Elixir implementation of a LangChain style framework that lets Elixir projects integrate with and leverage LLMs.
秒懂
- 它是什麼？
- 這是一個以 Elixir 撰寫、借鑑 LangChain 概念的 LLM 整合框架，主打多供應商 Chat 模型與可組合的 Chain。本文從它的實際機制、設定方式、版本節奏與限制，判斷什麼樣的 Elixir 團隊適合採用。
- 適合誰用？
- 如果你已經有一個 Elixir 應用，想把多個供應商的 Chat 模型接進來，並且需要 PromptTemplate 與 LLMChain 這類可組合的抽象，這個套件省下的是自己寫 adapter 與訊息格式轉換的時間；反之，若你只需要單一供應商、單一呼叫路徑，直接用 Req 打 API 會少一層相依與一層除錯難度。採用前請先確認三件事：你的 Elixir 版本是否達到 1.17、你要用的供應商是否真的在 README 列出的清單內（尤其 Bedrock 與 Vertex AI 這類走不同認證路徑的服務），以及你的 mix.exs 要鎖定哪個版本，因為 v0.12.0、v0.13.0、v0.13.1 在一個月內連續發布，README 範例卻仍寫著 ~> 0.9.0。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 Elixir（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是供應商碎片化，不是幫你寫 Prompt
Elixir 生態裡呼叫 LLM 本身不難，Req 發一個 POST 就能拿到回應。麻煩的是當你同時要用 Anthropic 的 Claude、OpenAI 的 Chat Completions、xAI 的 Grok、Google 的 Gemini，甚至自架的 Ollama 或 Bumblebee 時，每一家的訊息格式、角色欄位、回傳結構都不一樣。brainlid/langchain 的定位就是把這些差異收在一層共同的介面後面。README 的用語是讓應用能「chain」或連接不同流程、整合、函式庫與服務，並把價值主張拆成兩塊：一是 Components，也就是操作語言模型的抽象與各自的實作；二是 Off-the-shelf chains，把元件組裝成完成特定任務的結構。前者讓你在不引入整個框架的前提下也能單獨用某個元件，後者則給一條比較快能跑起來的路。目標讀者是已經在用 Elixir 寫產品、需要把模型能力嵌進既有系統的工程師，而不是想拿它來做模型研究或訓練的人。
Chain 是資料流，LLMChain 是它最薄的一層
README 對 Chain 的定義是「把不同流程、整合、函式庫、服務或功能與 LLM 連接起來」，這句話聽起來抽象，但落到程式碼上就是一個把輸入轉成輸出的資料流單元。最常見的組合是 PromptTemplate 加上一個 Chat 模型：模板負責把變數填進文字，模型負責產生回應，LLMChain 把這兩步串成一次呼叫。這種設計的好處是每一段都可以單獨替換，換模型不必動模板，改模板不必動模型。需要注意的是，這個專案並不追求與 JavaScript 或 Python 版 LangChain 的 parity，README 給的理由很直接：JS 與 Python 是物件導向語言，Elixir 是函數式，硬套同一種設計沒有意義；而且 JS 與 Python 版本起步較早，當時對話式 LLM 還不是常態，它們花了很多力氣在模型不支援對話歷史時自己想辦法保存歷史，這個專案不打算重做那件事。對於從 Python 版 LangChain 轉過來的人，這代表你熟悉的部分 API 形狀不會出現，必須重新理解它的組合方式。
供應商清單很長，但認證路徑並不統一
README 列出的 Chat 模型支援涵蓋 Anthropic Claude（含 extended thinking 與 AWS Bedrock）、AWS Bedrock Mantle、OpenAI ChatGPT 的 Chat Completions API、OpenAI 較新的 Responses API（支援 WebSocket 傳輸）、Cloudflare Workers AI、xAI Grok、Google Gemini、Google Vertex AI、DeepSeek（含 prompt caching）、Ollama、Mistral、Perplexity、orq.ai、Bumblebee 自架模型，以及透過 req_llm 套件做的多供應商轉接。這份清單的長度是這個專案最實際的資產，但長清單也藏著陷阱：Bedrock 與 Vertex AI 走的是雲端廠商自己的認證與端點，跟單純填一組 API key 不是同一回事；Cloudflare Workers AI 與 Bedrock Mantle 則是以 OpenAI 相容介面掛在 ChatOpenAI 之下，也就是說它們共用同一段程式碼路徑，行為差異取決於對方實作相容到什麼程度。挑選供應商時，請以 README 明確列出的名稱為準，不要假設清單上沒寫的服務也能直接套用。
安裝與設定：mix.exs 與 runtime.exs 的實際寫法
安裝需求是 Elixir 1.17 或更高。在 mix.exs 的 deps 中加入 {:langchain, "~> 0.9.0"} 即可，不過要注意這個版本約束是 README 範例裡的寫法，而近期發布已經到 v0.13.1，實際鎖定哪個版本得自己決定。設定放在 config/runtime.exs，OpenAI 相關的鍵是 config :langchain, openai_key 與 config :langchain, openai_org_id，Anthropic 用 config :langchain, :anthropic_key，xAI 用 config :langchain, :xai_api_key。值可以直接寫字串，也可以延後解析：用 tuple 形式 {MyApp.Secrets, :openai_api_key, []} 指向你自己的模組，或用匿名函式 fn -> System.fetch_env!("OPENAI_API_KEY") end。README 明確提醒 API key 應視為機密，不要進版控；在 fly.io 上的做法是 fly secrets set OPENAI_API_KEY=MyOpenAIApiKey，另外兩個鍵同理。底層的 HTTP 呼叫目前是用 Req 套件，這一點會影響你對連線行為與逾時的預期。
它不追求跨語言互通，這是取捨不是缺陷
JavaScript 與 Python 版 LangChain 的設計目標之一是兩邊盡可能互通，物件（prompt、LLM、chain 等）可以被序列化並在兩種語言之間交換。這個 Elixir 版本明確不這樣做。對單一語言團隊來說，這其實是好事：不必為了跨語言的序列化格式而遷就資料結構。但如果你所在的組織同時有 Python 的資料科學團隊與 Elixir 的產品團隊，想共用同一份 chain 定義或 prompt 資產，這條路在這邊是走不通的，你得自己在中間做轉換層。同樣地，因為它不重現 JS 與 Python 早期為非對話模型所做的歷史保存機制，任何依賴那種歷史處理行為的既有邏輯，搬到 Elixir 這邊都需要重寫。這兩個不追求 parity 的決定，決定了它適合什麼樣的團隊。
直接呼叫 API 或走 ReqLLM，什麼時候更划算
替代方案有兩條。第一條是完全不用這層抽象，在你的 Elixir 應用裡直接用 Req 呼叫供應商的 HTTP API，自己處理訊息格式與回應解析。差別在於：你換來的是零額外相依、完整的除錯可見度，以及不受套件版本節奏影響；代價是每加一個供應商就要重寫一次轉換邏輯，PromptTemplate 這類可組合的結構也得自己來。第二條是專案自己列出的 ReqLLM，它被描述為透過 req_llm 套件提供的多供應商轉接，涵蓋 Anthropic、OpenAI、Gemini、Groq、Ollama、AWS Bedrock 等。兩者的差異在抽象層次：ReqLLM 處理的是供應商連線與呼叫的統一，而這個專案處理的是把模型呼叫放進更大的組合流程裡。如果你只需要前者，引入整個 Chain 框架是多的；如果你需要後者，ReqLLM 本身不會給你 Chain 與 PromptTemplate 的組裝方式。
版本節奏與維護成本：一個月內三個版本意味著什麼
從發布紀錄看，v0.12.0、v0.13.0、v0.13.1 集中在 2026 年 8 月 22 日到 8 月 26 日之間，最近一次推送則在 2026 年 9 月 9 日，專案並未封存。對採用者來說，這代表兩件事。好處是上游供應商的 API 變動會被較快跟上，尤其是 OpenAI Responses API 這種較新的介面。風險是 0.x 階段的次版本仍可能有破壞性變動，而 README 的安裝範例停留在 ~> 0.9.0，文件與實際發布之間存在落差。實務上建議在 mix.exs 明確鎖定版本，並把升級當成獨立工作排程，而不是跟著 mix deps.update 一起放行。授權方面，倉庫的授權欄位顯示為 NOASSERTION，我無法從提供的資料判斷實際條款內容，任何商業用途在使用前都應該直接檢視倉庫中的授權檔案，這不是法律意見。
編輯結論
如果你已經有一個 Elixir 應用，想把多個供應商的 Chat 模型接進來，並且需要 PromptTemplate 與 LLMChain 這類可組合的抽象，這個套件省下的是自己寫 adapter 與訊息格式轉換的時間；反之，若你只需要單一供應商、單一呼叫路徑，直接用 Req 打 API 會少一層相依與一層除錯難度。採用前請先確認三件事：你的 Elixir 版本是否達到 1.17、你要用的供應商是否真的在 README 列出的清單內（尤其 Bedrock 與 Vertex AI 這類走不同認證路徑的服務），以及你的 mix.exs 要鎖定哪個版本，因為 v0.12.0、v0.13.0、v0.13.1 在一個月內連續發布，README 範例卻仍寫著 ~> 0.9.0。授權欄位在倉庫中是 NOASSERTION，無法從現有資料判定條款內容，商用前必須自行檢視授權檔。
社群筆記