或許從誕生那天起，LangChain 就註定是一個口碑兩極分化的產品。
看好 LangChain 的人欣賞它豐富的工具和組建和易於整合等特點，不看好 LangChain 的人，認為它註定失敗 —— 在這個技術變化如此之快的年代，用 LangChain 來構建一切根本行不通。
誇張點的還有：
「在我的諮詢工作中，我花了 70% 的精力來說服人們不要使用 langchain 或 llamaindex。這解決了他們 90% 的問題。」
最近，一篇 LangChain 吐槽文再次成為熱議焦點：
作者 Fabian Both 是 AI 測試工具 Octomind 的深度學習工程師。Octomind 團隊會使用具有多個 LLM 的 AI Agent 來自動建立和修復 Playwright 中的端到端測試。
這是一個持續一年多的故事，從選擇 LangChain 開始，隨後進入到了與 LangChain 頑強鬥爭的階段。在 2024 年，他們終於決定告別 LangChain。
讓我們看看他們經歷了什麼：
「LangChain 曾是最佳選擇」
我們在生產中使用 LangChain 超過 12 個月，從 2023 年初開始使用，然後在 2024 年將其移除。
在 2023 年，LangChain 似乎是我們的最佳選擇。它擁有一系列令人印象深刻的元件和工具，而且人氣飆升。LangChain 承諾「讓開發人員一個下午就能從一個想法變成可執行的程式碼」，但隨著我們的需求變得越來越複雜，問題也開始浮出水面。
LangChain 變成了阻力的根源，而不是生產力的根源。
隨著 LangChain 的不靈活性開始顯現，我們開始深入研究 LangChain 的內部結構，以改進系統的底層行為。但是，由於 LangChain 故意將許多細節做得很抽象，我們無法輕鬆編寫所需的底層程式碼。
眾所周知，人工智慧和 LLM 是瞬息萬變的領域，每週都會有新的概念和想法出現。而 LangChain 這樣圍繞多種新興技術建立的抽象概念，其框架設計很難經得起時間考驗。
LangChain 為什麼如此抽象
起初，當我們的簡單需求與 LangChain 的使用假設相吻合時，LangChain 還能幫上忙。但它的高階抽象很快就讓我們的程式碼變得更加難以理解，維護過程也令人沮喪。當團隊用在理解和除錯 LangChain 的時間和用在構建功能上的時間一樣時，這可不是一個好兆頭。
LangChain 的抽象方法所存在的問題，可以透過「將一個英語單詞翻譯成義大利語」這一微不足道的示例來說明。
下面是一個僅使用 OpenAI 軟體包的 Python 示例：
這是一段簡單易懂的程式碼，只包含一個類和一個函式呼叫。其餘部分都是標準的 Python 程式碼。
將其與 LangChain 的版本進行對比：
程式碼大致相同，但相似之處僅此而已。
我們現在有三個類和四個函式呼叫。但令人擔憂的是，LangChain 引入了三個新的抽象概念：
Prompt 模板： 為 LLM 提供 Prompt；
輸出解析器： 處理來自 LLM 的輸出；
鏈： LangChain 的「LCEL 語法」覆蓋 Python 的 | 運算子。
LangChain 所做的只是增加了程式碼的複雜性，卻沒有帶來任何明顯的好處。
這種程式碼對於早期原型來說可能沒什麼問題。但對於生產使用，每個元件都必須得到合理的理解，這樣在實際使用條件下才不至於意外崩潰。你必須遵守給定的資料結構，並圍繞這些抽象設計應用程式。
讓我們看看 Python 中的另一個抽象比較，這次是從 API 中獲取 JSON。
使用內建的 http 包：
使用 requests 包：
高下顯而易見。這就是好的抽象的感覺。
當然，這些都是微不足道的例子。但我想說的是，好的抽象可以簡化程式碼，減少理解程式碼所需的認知負荷。
LangChain 試圖透過隱藏細節，用更少的程式碼完成更多的工作，讓你的生活變得更輕鬆。但是，如果這是以犧牲簡單性和靈活性為代價的，那麼抽象就失去了價值。
LangChain 還習慣於在其他抽象之上使用抽象，因此你往往不得不從巢狀抽象的角度來思考如何正確使用 API。這不可避免地會導致理解龐大的堆疊跟蹤和除錯你沒有編寫的內部框架程式碼，而不是實現新功能。
LangChain 對開發團隊的影響
一般來說，應用程式大量使用 AI Agent 來執行不同型別的任務，如發現測試用例、生成 Playwright 測試和自動修復。
當我們想從單一 Sequential Agent 的架構轉向更復雜的架構時，LangChain 成為了限制因素。例如，生成 Sub-Agent 並讓它們與原始 Agent 互動。或者多個專業 Agent 相互互動。
在另一個例子中，我們需要根據業務邏輯和 LLM 的輸出，動態改變 Agent 可以訪問的工具的可用性。但是 LangChain 並沒有提供從外部觀察 Agent 狀態的方法，這導致我們不得不縮小實現範圍，以適應 LangChain Agent 的有限功能。
一旦我們刪除了它，我們就不再需要將我們的需求轉化為適合 LangChain 的解決方案。我們只需編寫程式碼即可。
那麼，如果不使用 LangChain，你應該使用什麼框架呢？也許你根本不需要框架。
我們真的需要構建人工智慧應用程式的框架嗎？
LangChain 在早期為我們提供了 LLM 功能，讓我們可以專注於構建應用程式。但事後看來，如果沒有框架，我們的長期發展會更好。
LangChain 一長串的元件給人的印象是，構建一個由 LLM 驅動的應用程式非常複雜。但大多數應用程式所需的核心元件通常如下：
用於 LLM 通訊的客戶端
用於函式呼叫的函式 / 工具
用於 RAG 的向量資料庫
用於跟蹤、評估等的可觀察性平臺。
Agent 領域正在快速發展，帶來了令人興奮的可能性和有趣的用例，但我們建議 —— 在 Agent 的使用模式得到鞏固之前，暫時保持簡單。人工智慧領域的許多開發工作都是由實驗和原型設計驅動的。
以上是 Fabian Both 一年多來的切身體會，但 LangChain 並非全然沒有可取之處。
另一位開發者 Tim Valishev 表示，他會再堅持使用 LangChain 一段時間：
我真的很喜歡 Langsmith：
開箱即用的視覺化日誌
Prompt playground，可以立即從日誌中修復 Prompt，並檢視它在相同輸入下的表現
可直接從日誌輕鬆構建測試資料集，並可選擇一鍵執行 Prompt 中的簡單測試集（或在程式碼中進行端到端測試）
測試分數歷史
Prompt 版本控制
而且它對整個鏈的流式傳輸提供了很好的支援，手動實現這一點需要一些時間。
何況，只依靠 API 也是不行的，每家大模型廠商的 API 都不同，並不能「無縫切換」。
你怎麼看？
原文連結：https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents