作者 | 王軼群
責編 | 唐小引
出品丨AI 科技大本營（ID：rgznai100）
受益於工具而又受限於工具的例子很多，這次我們的主角是大模型套用開發的主流框架——LangChain。
最近一篇【為什麽我們不再使用 LangChain 來構建我們的 AI Agents 】的博文，引起了開發者的廣泛討論。
該博文的作者 Fabian Both 是 AI 測試工具 Octomind 的深度學習工程師。Octomind 團隊會使用具有多個 LLM 的 AI Agent 來自動建立和修復 Playwright 中的端到端測試。其團隊豐富的實踐經驗和作者的親身經歷，讓文章更具說服力。
諸多限制下，棄用 LangChain 海闊天空
一句話總結：受益於 LangChain 也受限於 LangChain，建議大家也不要用了！
Fabian 在文章中闡釋了當抽象弊大於利時，在生產中使用 LangChain 的經驗教訓以及應該采取的措施。
他講述了團隊在生產中使用 LangChain 超過 12 個月，從 2023 年初開始，並於 2024 年將其移除的故事。
LangChain 在2023年是其團隊的最佳選擇，但隨著計畫要求變得越來越復雜，問題開始浮出水面，這「使 LangChain 成為摩擦源，而不是生產力。」
他舉了將英語轉譯成義大利語的例子，相比之下僅使用 OpenAI 包的 Python 範例比與 LangChain 的版本相比要簡單得多。
使用 OpenAI 包的 Python 範例
使用 LangChain 的範例
LangChain 引入了三個新的抽象：
1、提示樣版：為 LLM 提供提示
2、輸出解析器：處理 LLM 的輸出
3、Chains：LangChain 的「LCEL 語法」覆蓋了 Python 的 `|` 運算子
由此可見，LangChain 徒增了程式碼的復雜性，而未帶來任何明顯的好處。
另一個例子是從 API 中獲取 JSON：
使用內建的 http 包程式碼範例
使用請求包範例
後者的優勢顯而易見。作者表示：「但我的觀點是，好的抽象可以簡化你的程式碼，並減少理解程式碼所需的認知負擔。」
「當我們想要從具有單個順序代理的架構轉變為更復雜的架構時，LangChain 是限制因素。 例如，生成子代理並讓它們與原始代理互動。 或者多個專業代理相互互動。 」
Fabian 還在舉出了另一個開發場景受限例子：「我們需要根據業務邏輯和 LLM 的輸出動態更改代理可以存取的工具的可用性。但 LangChain 不提供從外部觀察代理狀態的方法，這導致我們縮小了實施範圍以適應 LangChain 代理可用的有限功能。」
這一切的解決方法，就是放棄 LangChain：「一旦我們刪除了它，我們就不再需要將我們的需求轉化為適合 LangChain 的解決方案。我們只需編寫程式碼即可。」
網友表示：臣附議！
一石激起千層浪，不少網友表示對該博文的內容很有共鳴。
有網友表示，自己在開發一個 RAG agent 因不用 LangChain 而遭受同事的質疑，終於有大佬站在自己這邊：
「我在過去三個半月的實習時間裏建立了一個RAG代理。公司裏的每個人都問我為什麽不用llangchain或者LlamaIndex，就像我是個瘋子一樣。在我的公司裏，每個做RAG的人都用的是 LangChain ，有一個甚至進了Prod。
我一直告訴他們，如果你有一個標準的用例，它會工作得很好，但如果你需要一些原創的東西，你必須經歷5層抽象，只是為了改變一個微小的細節。此外，你不會真正理解流程中的每一步，所以如果出現任何問題或者你需要改進流程，你將從頭開始。這（篇博文）真的讓我信心大增。」
「群體思維在程式設計師中非常普遍，尤其是當他們不知道自己在說什麽的時候。這表明你不需要很多經驗就能看出皇帝沒有穿衣服，但你確實需要註意。」網友評論道。
有網友與該博文的作者有著相似經歷：
「LangChain 剛問世時，我也有過類似的經歷。我花了很多時間嘗試使用它——包括做出一些貢獻來添加我需要的功能——但最終放棄了它。這讓我頭疼。
大多數LLM應用程式只需要字串處理、API呼叫、迴圈，如果你正在做RAG，可能還需要一個向量DB。你不需要幾個抽象層和一大堆依賴關系來管理基本的字串插值、HTTP請求和for/while迴圈，尤其是在Python中。
在提示方面，除了一些很容易實作的基本技巧（如CoT、情境學習等)，提示是一種逐例叠代的方法，有效地使用提示主要依賴於理解這些模型是如何工作的，而不是模仿其他人正在使用的提示。LLM 應用程式在概念上並不是難以實作的應用程式，但它們很挑剔，很難控制，像 LangChain 這樣的東西只會阻礙我。」
「也符合我的經驗。大約一年前，我嘗試過 LangChain 來開發一款套用，並且有一個相當標準的用例，但即使稍微偏離軌域，我也必須挖掘抽象層，而使用原始的 openai lib 會容易得多。因此，如果您的用例是在您的套用中提供許多不同的 LLM 提供程式，那麽它可能會有所幫助，但如果您知道您不會很快更換 LLM 提供程式，那麽最好不要使用這樣的框架。」HN使用者siva也如此表示。
認識到 LangChain 的不足，網友們構建了其他工具：
還有網友表示：「我沒有使用過LangChain，但我感覺它真正幫助人們的是流處理和異步控制流。雖然有一些庫可以使它變得更容易，但我認為在Python中正確地做這些事情就像在當前的潮流中遊泳，因為它的歷史主要是同步的、單執行緒的執行時。」
不用 LangChain 的情況下，該網友用 Go 語言構建了一個基於代理的 AI 編碼工具。他表示，自己對這個選擇非常滿意。「雖然 LLM 相關的庫和框架生態系並不完善，但 Go 的並行原語讓我可以輕松實作任何我需要的東西，而且我永遠不必擔心漏洞百出或難以理解的抽象。」
有網友還是贊同 LangChain 做出的貢獻，並表示還有多重工具供選擇：
「盡管人們不同意他們的一些設計選擇，但我仍然欽佩 LangChain 團隊的努力。OpenAI API 和其他 API 還很原始，開發人員很難抵制在其基礎上構建抽象的誘惑。
在這次對話中，有些人將 Langchain 等庫與 ORM 進行比較，但我認為也許更好的比較物件是 Web 框架。例如，Web/HTML/JSON 也「只是文本」，但你可能不想每次啟動新計畫時都重新發明一堆字串和檔頭解析庫。從 JS 生態系來看，我想很多人都會喜歡像 Express 這樣的輕量級庫，它可以處理無聊的部份但不會妨礙工作。」
「現在用大模型解決的業務問題，多數都是小問題，幾條 prompt、幾輪對話的事兒。基於原生 API，自己匹配著需求設計架構，更清晰、靈活、可控。」AGI class.ai & ChatALL.ai 創始人孫誌崗表示，目前Agent開發的主要工作量在拆業務、整理數據、調 prompt 上，這些框架都幫不上什麽忙（有些框架內建的 prompt 還可能幫倒忙）。「當開始搞復雜的工作流，多 Agent 協作，對框架的要求就上來了，LangChain 們的價值就大一些了。」
爭議之下，依然是主流框架
不可否認的是，LangChain 一直以來在開發者中的口碑和影響力依舊。
在幫助開發者構建LLM套用的框架中，LangChain是最早且星標數最多的計畫之一，在開源 LLM 開發框架領域占據領先地位。
LangChain的 GitHub 倉庫星標數量顯著 —— Python 版本87.9k ，JavaScript 版本11.7k 。 相比之下，同類計畫如 AutoGen 目前有27.7k 顆星，LlamaIndex 有33k顆星。
GitHub 星數
在 LangChain 中一共有六大核心元件，分別是模型的輸入輸出 (Model I/O)、數據連線 (Data Connection)、記憶體記憶（Memory）、鏈（Chains）、代理（Agent）、回呼（Callbacks）。LangChain 能解決大模型的兩個痛點，包括模型介面復雜、輸入長度受限於模組設計。
此外，LangChain 生態系還包括多個相關開源計畫。LangChain 為開發者提供了全面的 LLM 套用開發支持，涵蓋從開發到部署的各個環節:
LangGraph：專註於 Agentic 套用開發的框架
LangServe：用於構建微服務的框架
LangSmith：全生命周期可觀測性平台
【LangChain入門指南】一書的作者李特麗總結道，LangChain 作為常用的大模型套用開發框架，LangChain 具有以下優勢：
1. 強大的提示詞工程構建功能
2. 實用的輸出解析器
3. 豐富的RAG(檢索增強生成)數據增強工具
同時，李特麗也指出了 LangChain 的一些缺陷：
1. 過度抽象:某些介面的抽象程度過高,新手可能難以理解源碼,導致了對"源碼解讀"的需求。
2. 學習曲線陡峭:復雜的巢狀結構可能讓初學者感到困惑。
3. 效能開銷:在Agent場景下,使用LangChain可能會引入不必要的效能開銷，Agent呼叫LLM API的次數很多。
4. 很多提示詞工程，沒有對中文支持。
「LangChain 封裝了比如說React這些框架，也是讓初學者能夠迅速的就開發出來一個還能夠做DEMO的agent，但不是說真正能夠用在生產的這個級別。」新加坡科研局資深研究員、【GPT圖解 大模型是怎樣構建的】作者黃佳表示，「但是現在又真正有多少的agent就能夠投入到生產中呢？其實也不多。」
同時，爭議帶來了熱度上漲。谷歌搜尋趨勢顯示，近期 LangChain的全球熱度是遠超其他框架，且在不斷攀升。
LangChain 中文網創始人康軼文表示：「一邊使用一邊吐槽，這也許是產品發展的最佳土壤。」
在這些正或負向的反饋下，LangChain 正在不斷叠代更新：3到6月一次大更新，每天都在做小更新。
康軼文表示：「 LangChain 本來就是為了方便普通程式設計師轉向LLM套用開發的一個框架，本身會隱藏一些程式碼到背後讓前端程式碼顯得簡單，但是在某些深層需求時，就變得很麻煩和難維護。」
「像許多高度整合的框架一樣，LangChain 也面臨一些挑戰。最顯著的是其「黑盒」特性 —— 某些內部工作機制對開發者來說可能不夠透明。為了應對這一問題，LangChain 從 0.1 版本開始大力推廣 LangChain Expression Language (LCEL) 語法。LCEL 旨在使 LLM 邏輯流程更直接、更清晰，增強了框架的可理解性和可控性。」 馭勢科技雲平台研發總監 張海立表示。
對此，官方已經意識到這一點了，並在0.1版本和0.2版本上都做了很大的改進。「LangChain 拿了融資以後我們看到他在積極的改進這些，我們已經看到的他的正在轉變，從單純的開發到整體的運維，這種進步也是業界領先的。」他表示。
孫誌崗就是其貢獻者之一。「記得我給 LangChain JS 貢獻程式碼的時候，有個統計 token 數的 bug 解決不了，問 reviewer 建議，他直接說這個不重要，然後就把我的程式碼 merge 了。某種程度來說，業內最新的技術、方法論，LangChain 都會第一時間融入進來。所以看看 LangChain 的 release notes 和部落格，能學到不少東西。比如 Rerank 我就是從 LangChain 學到的。然後，對感興趣的可以馬上在 LangChain 裏用一下，找找體感，做個 demo，速度很快。」
李特麗也表示：「LangChain 0.2版本的更新降低了模組間的耦合度，使得開發者能更方便地使用其封裝好的工具函式。值得一提的是，吳恩達團隊的多個計畫都使用了LangChain的模組，如最近開源的轉譯Agent計畫就使用了LangChain的文本分割模組。」
還需要使用 Langchain 一類的框架嗎？專家：看需求和段位！
在博文的結尾，作者提出了一個更深層的提問：「我們真的需要一個用於構建 AI 應用程式的框架嗎？」
對此他表示：「LangChain 早期透過提供 LLM 功能幫助了我們，讓我們可以專註於構建應用程式。但事後看來，長期來看，如果沒有框架，我們的處境會更好。」
他建議道：「如果你在沒有框架的情況下開始你的人工智慧開發之旅，那麽你需要花更長的時間來整合你自己的工具箱，並且需要更多的前期學習和研究。但這是值得的，也是對你和你的應用程式未來的一項值得的投資，因為你正在學習你將要操作的領域的基礎知識。」
對此，專家們表達了在不同立場和需求下的觀點。
「Langchain定義的一套開發概念，某些程度會和有經驗的開發者產生沖突，讓這部份人覺得不順手。」康軼文表示，網站社群裏也有使用者從早期使用、到現在不用並開始轉為自己的框架，「LLM開發是一定會用到框架的，這個是確定的，但框架長什麽樣子順不順手每個人的要求標準都不一樣。」
「頂級大廚可以用一把菜刀做所有的事，他會覺得沒必要這麽多輔助工具。而剛入門的廚師會需要買各種刀具來提升效率和水平。」康軼文比喻道。
李特麗表示：
對於經驗豐富的開發者，在簡單場景下,直接使用LLM API和向量資料庫可能更加高效和靈活。
對於新手開發者來說，AI套用框架如 LangChain 可以降低學習門檻，提供最佳實踐和解決方案框架能幫助新手處理介面錯誤、延遲和重試等復雜問題使用框架可以讓新手更快地理解LLM套用開發的整體架構和關鍵概念。
這樣的區分並非絕對，李特麗還解釋了框架工具提供的長期價值和靈活性：「即使經驗豐富的開發者也可能從使用框架中獲益，如文章作者在使用 LangChain 一年後才完全脫離框架提供的抽象和工具可以加速開發過程，特別是在復雜計畫中。而隨著計畫復雜度增加，框架提供的工具和抽象可能會變得更有價值開發者 可以根據需求選擇性地使用框架的某些元件，而不必完全依賴。」
孫誌崗認為： 「在試驗新技術、原型驗證、快速搭 demo 的場景裏，框架是有用的，能節省時間。 在套用了復雜的工作流、多 Agent 產品裏，長期來看也需要穩定的框架支撐 。 」
「對於有些場景來說，直接調大模型的API，不管是 OpenAI 的 API，還是本地模型的API，都可以直接解決問題的時候並不需要 LangChain。」黃佳表示。對於是否還需要框架他表示：「尤其是 RAG 這個場景，我認為有框架比較好，但是 LangChain 並不一定是做的最好的框架。」
張海立也表示：「RAG 和 Agent 技術的未來發展很大程度上依賴於核心流程和演算法的創新。在這個背景下，LangChain、LlamaIndex 等 AI 套用框架應被視為強大的工具集，而非黑盒解決方案。」他認為，開發者應謹慎使用框架中的封裝元件，深入理解這些元件的工作原理，而不是簡單地依賴它們。
具體的建議是：
關註底層開發框架：LCEL 和 LangGraph 等相對透明的「底層」開發框架值得開發者重點關註。這些工具提供了構建復雜 LLM 套用所需的靈活性和可控性。
利用開源資源：LangChain 團隊基於這些底層能力實作了多種廣受認可的 RAG 和 Agent 演算法。開發者可以在 LangGraph 官方文件（ https://langchain-ai.github.io/langgraph/ ）中找到這些實作，作為學習和創新的起點。
平衡效率與控制：雖然直接使用 API 可能看似更直接，但框架提供的抽象和工具可以顯著提高開發效率,特別是在處理復雜場景時。關鍵是要在使用框架提供的便利和保持對底層邏輯的控制之間找到平衡。
考慮長期維護：在選擇開發方法時，要考慮到長期的可維護性和可延伸性。成熟的框架通常提供了更好的文件、社群支持和長期更新，這在維護大型計畫時尤為重要。
雖然說法不一，但在最後大家得出了一個共同的結論：AI 套用框架和直接 API 呼叫各有其適用場景，選擇哪種方式應該基於開發者的計畫需求、團隊經驗和長期維護做考慮。
同樣，相應開發者需求的 LangChain 也在做著更多改進。
對於未來趨向，張海立表示，LangChain 的發展軌跡可能會集中在兩個方向:
LangChain 將繼續深化其生態系，特別是在支持從原型到生產的無縫過渡方面。其中，作為 LangChain 的核心流程開發框架的LangGraph Cloud 的開發就是這一戰略的具體體現。LangGraph 的一個顯著優勢在於其提供了相對底層的 Agent 流程及演算法開發框架。雖然這增加了學習曲線的陡峭度，但也為開發者提供了極大的靈活性和創新空間。
進一步強化其在 AI 套用全生命周期管理方面的能力，包括但不限於改進模型評估方法、最佳化資源使用效率，以及增強與各種 LLM 和工具的整合能力。
李特麗補充道，LangChain 未來發展還將關註「采用優勝劣汰的生態發展策略,將有價值的工具外掛程式提升至核心模組；積極響應主要大模型廠商的更新；關註解決開發者在實際項用中遇到的問題,如支持多個大模型之間的結果互通」等。
對於 LangChain 等原生 Agent 架構發展趨勢，李特麗指出了兩點趨勢：「各大模型廠商將普遍支持類似GPTs的功能，使使用者能透過提示詞構建個人化Agent。框架重點將轉向解決多Agent間的互動和數據流通問題。」
「現在大模型還處於早期，變數很大，沒形成固定的套路。需要一段時間沈澱下最佳實踐，框架才有更大發揮空間。只不過，因為大模型抽象層高、API 簡單這一特點，我認為大模型開發框架在未來，不大可能像 Vue、React 那樣成為標準一樣地存在。」孫誌崗表示。
工具總有千般利弊，但工具的開發與使用的人才是關鍵。要理解並充分利用這些工具、改進工具、創造更多工具，而不是受其限制。
參考連結：
https://www.octomind.dev/blog/why-we-no-longer-use-langchain-for-building-our-ai-agents
https://news.ycombinator.com/item?id=40739982
https://blog.csdn.net/2301_81940605/article/details/137627288
由 CSDN 和 Boolan 聯合主辦的「2024 全球軟體研發技術大會（SDCon）」將於 7 月 4 - 5 日在北京威斯汀酒店舉行。
由世界著名軟體架構大師、雲原生和微服務領域技術先驅 Chris Richardson 和 MIT 電腦與 AI 實驗室(CSAIL)副主任，ACM Fellow Daniel Jackson 領銜，BAT、微軟、字節跳動、小米等技術專家將齊聚一堂，共同探討軟體開發的最前沿趨勢與技術實踐。
大會官網： http://sdcon.com.cn/ （可點選 閱讀原文 直達）
