作者 | Fabian Both

編輯 | 伊風 

為什么我們不再使用LangChain來構建我們的AI代理AI agents？ 

在Octomind，我們使用多個大型語言模型（LLM）的AI代理來自動創建和修復Playwright中的端到端測試。直到幾個月前，我們還在使用LangChain框架。

在這篇文章中，我將分享我們使用LangChain時遇到的困難，并解釋為什么用模塊化的構建塊替換其僵化的高級抽象后，我們的代碼庫變得更簡潔，使我們的團隊更快樂、更高效。

1.背景故事

我們在生產中使用LangChain超過12個月，從2023年初開始，然后在2024年將其移除。

2023年，LangChain似乎是我們的最佳選擇。它有一個令人印象深刻的組件和工具列表，并且其受歡迎程度迅速上升。它承諾“讓開發人員可以在一個下午內從想法變為可運行的代碼。”但隨著我們的需求變得更加復雜，問題開始浮現，LangChain變成了摩擦而不是生產力的來源。

隨著其不靈活性開始顯現，我們很快發現自己在深入研究LangChain內部，以改進我們系統的底層行為。但由于LangChain故意抽象了許多細節，因此通常不容易或不可能編寫我們所需的底層代碼。

2.早期框架的危險

AI和LLM是快速變化的領域，每周都有新概念和想法涌現。因此，當一個框架如LangChain圍繞多個新興技術創建時，設計能經受時間考驗的抽象是非常困難的。

我相信，如果我在他們創建LangChain時嘗試構建一個類似的框架，我也不會做得更好。事后看錯誤是很容易的，這篇文章的目的是不公平地批評LangChain的核心開發人員或其貢獻者。每個人都在盡力而為。

設計良好的抽象很難，即使需求是明確的。但當你在這樣一個變化多端的狀態下建模組件（如代理）時，僅對低級構建塊使用抽象是更安全的方式。

3.LangChain抽象帶來的問題

在我們簡單的需求與其使用假設一致時，LangChain最初是好用的。但其高度的抽象很快使我們的代碼變得難以理解與維護。當我們的團隊開始花費與構建功能一樣多的時間來理解和調試LangChain時，這不是一個好兆頭。

LangChain的抽象方法的問題可以通過這個將英文單詞翻譯成意大利語的簡單示例來展示。

這是一個僅使用OpenAI包的Python示例：

圖片

這是簡單且易于理解的代碼，包含一個類和一個函數調用。其余是標準的Python。

讓我們對比一下LangChain的版本：

圖片

代碼大致相同，但相似之處僅此而已。

我們現在有三個類和四個函數調用。但最令人擔憂的是引入了三個新的抽象：

• 提示模板：提供給LLM的提示
• 輸出解析器：處理LLM的輸出
• 鏈：LangChain的“LCEL語法”覆蓋Python的 `|` 運算符

所有LangChain所做的就是增加了代碼的復雜性而沒有明顯的好處。

這段代碼可能適用于早期階段的原型。但對于生產使用，每個組件都必須合理理解，以確保在實際使用條件下不會意外爆炸。你必須遵守給定的數據結構，并圍繞這些抽象設計你的應用程序。

讓我們再看看一個Python中的抽象對比，這次是從API獲取JSON。

使用內置的http包：

圖片

使用requests包：

圖片

勝利者顯而易見。這就是一個好的抽象的感覺。

當然，這些是簡單的例子。但我的觀點是，好的抽象簡化了你的代碼并減少了理解它所需的認知負擔。

LangChain試圖通過隱藏細節，用更少的代碼做更多的事情來讓你的生活更輕松。但當這以犧牲簡單性和靈活性為代價時，抽象就失去了價值。

LangChain還習慣于在其他抽象之上使用抽象，因此你常常被迫以嵌套抽象的方式思考如何正確使用API。這不可避免地導致理解巨大的堆棧跟蹤并調試你沒有編寫的內部框架代碼，而不是實現新功能。

4.LangChain對我們開發團隊的影響

我們的應用程序大量使用AI代理來執行不同類型的任務，例如測試用例發現、Playwright測試生成和自動修復。

當我們想從單一的順序代理架構轉向更復雜的架構時，LangChain成了限制因素。例如，生成子代理并讓它們與原始代理交互，或者多個專家代理相互交互。

在另一個實例中，我們需要根據業務邏輯和LLM的輸出動態更改我們的代理可以訪問的工具的可用性。但LangChain并沒有提供一種方法來外部觀察代理的狀態，導致我們不得不縮小實現的范圍以適應LangChain代理的有限功能。

一旦我們移除它，我們就不再需要將我們的需求轉換為LangChain適當的解決方案。我們只需編碼即可。

因此，如果不是LangChain，你應該使用什么框架？也許你根本不需要框架。

5.你需要一個框架來構建AI應用程序嗎？

LangChain在早期幫助了我們，因為它提供了LLM功能，使我們能夠專注于構建應用程序。但事后看來，從長遠來看，我們會更好地不用框架。

LangChain的長組件列表給人的印象是，構建一個LLM驅動的應用程序很復雜。但大多數應用程序需要的核心組件通常是：

• 一個用于LLM通信的客戶端
• 用于函數調用的函數/工具
• 一個用于RAG的向量數據庫
• 一個用于跟蹤、評估等的可觀察性平臺

其余的是圍繞這些組件的幫助工具（例如，用于向量數據庫的分塊和嵌入），或者是常規的應用程序任務，例如通過數據持久性和緩存管理文件和應用程序狀態。

如果你在沒有框架的情況下開始你的AI開發之旅，是的，組建你自己的工具箱會花費更長的時間，并且需要更多的前期學習和研究。但這是值得的時間投資，因為你正在學習你將要操作的領域的基本知識。

在大多數情況下，你對LLM的使用將是簡單而直接的。你主要會編寫順序代碼，迭代提示，并改進輸出的質量和可預測性。大多數任務可以通過簡單的代碼和相對較少的外部包來完成。

即使使用代理，也不太可能做超出簡單的代理到代理通信，在預定的順序流程中處理代理狀態和它們的響應。你不需要框架來實現這一點。

雖然代理領域正在迅速發展，有許多令人興奮的可能性和有趣的用例，但我們建議在代理使用模式穩定下來之前，保持簡單。

6.使用構建塊保持快速和精簡

假設你沒有向生產發布垃圾代碼，那么團隊創新和迭代的速度是成功的最重要指標。AI領域的許多開發是由實驗和原型驅動的。

但框架通常是為基于已建立的使用模式強制結構而設計的——LLM驅動的應用程序尚未有這些模式。將新想法轉換為框架特定的代碼，限制了你的迭代速度。

構建塊方法更喜歡使用簡單的低級代碼和精心選擇的外部包，保持你的架構精簡，使開發人員可以將注意力集中在他們試圖解決的問題上。

構建塊是指你覺得已經全面理解且不太可能改變的簡單組件。例如，一個向量數據庫。它是一種已知類型的模塊化組件，具有一組基礎功能，因此可以很容易地被替換掉。你的代碼庫需要保持精簡和適應性，以最大化你的學習速度和每個迭代周期的價值。

. . .

我希望我能恰當地和公平地描述我們在使用LangChain時遇到的挑戰，以及為什么完全放棄框架對我們團隊是非常有益的。

我們目前使用模塊化構建塊和最小化抽象的策略使我們現在能夠更快地開發，并減少了摩擦。

本文轉載自??51CTO技術棧??，作者：伊風