作者、編輯：程天一
排版：Lydia、Zoey
LangChain 很火，有關它的前途命運也有很多争議，但一個相對肯定的結論是：LangChain 已經成為了 AI 應用開發的新手村。22 年 11 月初，Hacker News 上“如何入門 AI”的文章回複中，LangChain 第一次被列進入門套裝：
看 Fast.ai 和 Andrej Karpathy 的 YouTube 頻道。在本地試試跑 Stable Diffusion。用 YOLO 标記你的圖檔。用 LangChain，在 Hugging Face 學學如何使用 Transformer 的庫。然後去 Kaggle 吧。
LangChain 由前 Robust Intelligence 的機器學習工程師 Chase Harrison 在 22 年 10 月底推出，是一個封裝了大量 LLM 應用開發邏輯和工具內建的開源 Python 庫，有成為第一個被廣泛認可的 LLM 應用開發架構的勢頭。随着 Harrison 為 LangChain 添加了很多實用的抽象，以及 23 年 1 月衆多 AI Hackathon 決賽項目使用 LangChain，它的 Github Star 迅速破萬，成為 LLM 應用開發者選擇中間件時想到的第一個名字。
從開發者視角看，LangChain 是個挺友好且優美的庫：
• 它非常子產品化，還通過 Chain、Agent、Memory 對 LLM 的抽象幫助開發者提高了建構較複雜邏輯應用的效率；而且每個子產品有很好的可組合性，有點像“為 LLM 提供了本 SOP”，能實作 LLM 與其他工具的組合、Chain 與 Chain 的嵌套等邏輯；
• 它一站式內建了所有工具，從各種非結構化資料的預處理、不同的 LLM、中間的向量和圖資料庫和最後的模型部署，貢獻者都幫 LangChain 跟各種工具完成了迅速、全面的內建。
作為成長期投資者看 LangChain，它本身還太早期，遠沒到成長邏輯。除此之外，我對它在商業層面未來發展的核心擔憂在于：
• 我們不能直接套用舊時代的中間件視角，随着 ChatGPT Plug-In 出現和 OpenAI 的更多邊界延伸，LangChain 的價值可能被取代，很快像機器學習曆史上的其他明星庫一樣隐入塵埃；
• LangChain 本身的壁壘也比較薄，是“其他開源庫身上的開源庫”，沒有太多技術壁壘，隻是替大家省下來了碼的時間。如果要收費使用，很多開發者可能會選擇自己把 LangChain 這套東西碼出來；
• 目前使用 LangChain 庫的以個人開發者和極客的 side project 為主，還不是正經的企業級 LLM 內建工具，而稍微有點體量的公司都會選擇 fork LangChain 的源碼或者幹脆自己再碼套架構。
從投資人的角度看，LangChain 的創始人 Harrison Chase 想做的不止是 LangChain 這個開源庫而已，我們比較期待他服務 AI 應用開發者的下一步動作。此外，我在本文使用了盡可能通俗易懂的方式呈現和分析 LangChain 的能力，是以沒有技術背景的讀者也可以放心閱讀本文，也歡迎 LangChain 開發者填寫回報征集問卷。
以下為本文目錄，建議結合要點進行針對性閱讀。
👇
01 建構 AI 應用遠不隻是調用模型 API
02 案例：為一本 300 頁的書建構問答機器人
03 産品：拼接好 LLM 的大腦和四肢
04 挑戰：對 Prompt Ops 的質疑
05 競争：以和為貴、各展神通的時代
06 未來：Harrison 超越 LangChain
01.
建構 AI 應用遠不隻是
調用模型 API
一旦在 LLM 領域花了足夠多的時間，在興奮之餘你會意識到目前模型本身的兩點局限：
1. 它隻有“腦子”沒有“手臂”，無法在外部世界行動，不論是搜尋網頁、調用 API 還是查找資料庫，這些能力都無法被 OpenAI 的 API 提供；
2. 甚至它的“腦子”也不完美，OpenAI 的訓練資料截止至 2021 年，并且沒有任何企業和個人的私有資料，這讓模型隻能根據自己的“記憶”回答問題，并且經常給出與事實相悖的答案。一個解決方法是在 Prompt 中将知識告訴模型，但是這往往受限于 token 數量，在 GPT-4 之前一般是 4000 個字的限制。
從抽象層面看，我們使用 LLM 時在期待兩種能力（這是個沒那麼科學嚴謹的分類）：
1. 一種是使用它的生成能力，這是 GPT-3 和 ChatGPT 剛剛出現時最初被體驗的能力 —— 讓 ChatGPT 寫首詩，你可以接受它的上述不完美；
2. 進入到圍繞模型建構“真正有用”的應用時，我們更多在使用它通過思想和記憶進行推理的能力。而簡單直接地通過 API 調用模型無法将推理所需的一些事實和知識給到它，即這時候模型總是缺少“Context”（廣義的上下文）。
這就需要為模型注入 Context 并進行一定的 Prompt Engineering。正确的 Prompt 可以激發出 LLM 的能力，這在 GPT-3.5 以前的時代更為重要。将 Context 注入 LLM 實際上在 Prompt Engineering 的上遊，把知識告訴 LLM，Prompt 隻是中間橋梁。前 Stitch Fix 的 ML 總監 John McDonnell 畫的這幅圖很好地展示出了二者的關系：
“腦子”的問題目前已經有了成熟的解決方案來繞開 token 數量的限制。通常的方法借鑒了 Map Reduce 的思想，涉及到給文檔切片、使用 Embedding 引擎、向量資料庫和語義搜尋（我們在 02 中詳細介紹了這個過程）。
關于“手臂”的探索也早就有很多，OpenAI 的 WebGPT 給模型注入了使用網頁資訊的能力，Adept 訓練的 ACT-1 則能自己去網站和使用 Excel、Salesforce 等軟體，PaLM 的 SayCan 和 PaLM-E 嘗試讓 LLM 和機器人結合，Meta 的 Toolformer 探索讓 LLM 自行調用 API，普林斯頓的 Shunyu Yao 做出的 ReAct 工作通過結合思維鍊 prompting 和這種“手臂”的理念讓 LLM 能夠搜尋和使用維基百科的資訊……
有了這些工作，在開源模型或者 API 之上，開發者們終于可以做有相對複雜步驟和業務邏輯的 AI 應用。而 LangChain 是一個開源的 Python 庫（後續又推出了 Typescript 版本），封裝好了大量的相關邏輯和代碼實作，開發者們可以直接調用，大大加速了建構一個應用的速度。
如果沒有 LangChain，這些探索可能首先将被局限在 Adept、Cohere 等有充足産研資源的公司身上，或僅僅停留在論文層面。然後随着時間推移，開發者需要悶頭碼個幾周來複現這些邏輯。但是有了 LangChain，做一個基于公司内部文檔的問答機器人通常隻需要兩天，而直接 fork 别人基于 LangChain 的代碼建構個人的 Notion 問答機器人則隻需要幾個小時。
02.
案例：為一本 300 頁的書建構問答機器人
我自己知道的第一個使用 Map Reduce 思想的應用是 Pete Hunt 的 summarize.tech，一個基于 GPT-3 的 YouTube 視訊總結器。Pete 在去年 9 月興沖沖地在 Twitter 上表示自己找到了讓 GPT-3 調用成本下降 80% 的方法 —— 不是一股腦将 YouTube 視訊的文稿做總結，而是先将它分成很多的文本塊（chunk），對每個塊分别總結，最後給使用者傳遞的是“摘要的摘要”，過程中消耗的 token 數能節省很多。
事實上，這不光能讓成本降低，還可以解決單個 Prompt 中 token 數量限制的問題。随着 12 月 OpenAI 新的 Embedding 引擎推出和 ChatGPT 讓更多 AI 應用開發者入場，這種做法目前已經成為解決 Context 問題的絕對主流做法。
下面我們以一個 300 頁的書的問答機器人為例，給讀者展示下 LangChain 如何封裝這個過程（這個例子來自 YouTube 部落客 Data Independent 的 LangChain 101 系列視訊，如果你想迅速上手 LangChain，強烈推薦觀看）：
1. 哪怕是 GPT 的 32k token 限制，300 頁的書也絕對超過了，是以我們需要引入上文這種 Map Reduce 的做法；
2. LangChain 提供了許多 PDF loader 來幫助上傳 PDF，然後也提供許多類型的 splitter 讓你可以将長文本切成數百個文本塊，并盡量避免這麼切可能導緻的語義缺失；
3. 有了文本塊之後，你可以調用 OpenAI 的 Embedding 引擎将它們分别變成 Embeddings，即一些大的向量；
4. 你可以在本地存儲這些向量或者使用 Pinecone 這樣的雲向量資料庫存儲它們；
5. 調用 LangChain 的 QA Chain 就可以進行問答了，這背後發生的是 —— 輸入的問題也被 Embedding 引擎變成向量，然後使用 Pincone 的向量搜尋引擎找到語義最接近的一些 Embedding，将它們再拼接在一起作為答案傳回。
LangChain 在過程中提供了完整的內建，從 OpenAI 的 LLM 本身、Embedding 引擎到 Pinecone 資料庫，并且将整體的互動邏輯進行了封裝。如果你想用别人基于 LangChain 的代碼 fork 這個 PDF 問答機器人，基本隻需要換一下 OpenAI API key、Pincone API key 和用的這份 PDF。
03.
産品：拼接好 LLM 的大腦和四肢
LangChain 身上有許多标簽：開源的 Python 和 Typescript 庫、第一個被廣泛采用的 LLM 開發架構、Model as a Service 設想的中間件、AI 應用層的基礎設施...... 感興趣上手使用 LangChain 的讀者可以參考下圖觀遠資料的這個講解視訊，或是去 LangChain 的文檔中心和 Github 逛逛。
Source：《微軟 365 Copilot 是如何實作的？
揭秘 LLM 如何生成指令》- Bilibili
我在這一部分将不再羅列 LangChain 本身的一系列功能，而是詳細講講我認為 LangChain 最重要的 3 個身份 —— 讓 LLM 擁有上下文和行動能力的第一選擇、所有 LLM Ops 工具的粘合劑/螺栓、一個快速崛起的開源社群。
讓 LLM 擁有上下文和行動能力
目前基于 LangChain 開發的第一用例是建立使用私有資料的問答機器人，而大多數開發者想到要導入私有資料，第一選擇就是基于 LangChain 來做。可以說 LangChain 是目前将上下文資訊注入 LLM 的重要基礎設施。Harrison 在去年 11 月為 LangChain 總結的 4 大價值主張支柱也都圍繞這一點，展現出了很優美的子產品化和可組合性特點：
LLM 和 Prompts
如果是一個簡單的應用，比如寫詩機器人，或者有 token 數量限制的總結器，開發者完全可以隻依賴 Prompt。此外，這也是更複雜的 Chain 和 Agent 的基礎。LangChain 在這一層讓切換底層使用的 LLM、管理 Prompt、優化 Prompt 變得非常容易。
此處最基礎的能力是 Prompt Template。一個 Prompt 通常由 Instructions、Context、Input Data（比如輸入的問題）和 Output Indicator（通常是對輸出資料格式的約定）。使用 LangChain 的 Prompt Template 很好地定義各個部分，同時将 Input Data 留作動态輸入項。
圍繞 Prompt，LangChain 還有很多非常有意思的小功能，比如 0.0.9 版本上的兩個能力：Dyanamic Prompts 可以檢查 Prompt 的長度，然後調整 few-shots 給出的示例數量，另一個 Example Generation 可以檢查 Prompt 裡 token 數量還有剩餘的話就再多生成些示例。
Chain
當一個應用稍微複雜點，單純依賴 Prompting 已經不夠了，這時候需要将 LLM 與其他資訊源或者 LLM 給連接配接起來，比如調用搜尋 API 或者是外部的資料庫等。LangChain 在這一層提供了與大量常用工具的內建（比如上文的 Pincone）、常見的端到端的 Chain。
今天 LangChain 封裝的各種 Chain 已經非常強勁，一開始 300 頁 PDF 的案例中用到的是它的 QA Chain，我再舉一些足夠簡單、易于了解的 Chain 作為例子：
它的第一個 Chain 可以讓完全沒有技術背景的讀者也對 Chain 有個概念 —— 這個 Chain 叫做 Self Ask with Search，實作了 OpenAI API 和 SerpApi（Google 搜尋 API）的關聯，讓 LLM 一步步問出了美國網球公開賽冠軍的故鄉。
還有一個很直覺的 Chain 是 API chain，可以讓 LLM 查詢 API 并以自然語言回答問題，比如下面這個示例中 LLM 使用了 Open-Mateo（一個開源的天氣查詢 API）來擷取舊金山當天的降雨量：
Agent
Agent 封裝的邏輯和賦予 LLM 的“使命”比 Chain 要更複雜。在 Chain 裡，資料的來源和流動方式相對固定。而在Agent 裡，LLM 可以自己決定采用什麼樣的行動、使用哪些工具，這些工具可以是搜尋引擎、各類資料庫、任意的輸入或輸出的字元串，甚至是另一個 LLM、Chain 和 Agent。
Harrison 将 Agent 的概念引入 LangChain 是受到前文提到的 ReAct 和 AI21 Labs 的 MRKL（Modular Resaoning, Knowledge, and Language 子產品化推理、知識和語言）系統的啟發。作為 Agent 的 LLM 深度展現了思維鍊的能力，充當了交通指揮員或者路由者的角色。
重新回歸 OpenAI 的 Anrej Karpathy 在 Twitter 上經常說 LLM 會成為編排資源的認知引擎，LangChain 的 Agent 走得其實就是這個方向。是以 Agent 究竟能幹什麼呢？下面是我最喜歡的一個例子。
衆所周知，ChatGPT 能聽懂你的幾乎所有問題，但是老胡編亂造。另外有一個叫 Wolfram Alpha 的科學搜尋引擎，擁有天文地理的各類知識和事實，隻要能聽懂你提問就絕不會出錯，可惜之前隻能用官方給的文法搜尋，非常難用。是以它的創始人 Wolfram 老師一直在鼓吹 ChatGPT 與 Wolfram Alpha 結合的威力。
23 年 1 月 11 日，LangChain 貢獻者 Nicolas 完成了 ChatGPT 和 Wolfram Alpha 的內建。Agent 可以像下圖一樣運作，自行決定是否需要工具和 Wolfram Alpha，在回答“從芝加哥到東京的距離”時選擇了調用它，在回答“Wolfram 是否比 GPT-3 好”時選擇不調用它，自行回答。
Memory
LangChain 在上述的 3 層都做得很好，但是在 Memory 上一直相對薄弱，Harrison 自己不懂，一直由非全職的貢獻者 Sam Whitmore 貢獻相關代碼，他也承認 LangChain 在這塊兒有些技術債。
對于不了解 Memory 是什麼的讀者，你在 ChatGPT 每個聊天 session 都會出現在入口的左側，OpenAI 會貼心地為你生成小标題，在每個 session 的問答裡 ChatGPT 都能記住這個對話的上文（不過也是因為每次請求都會把之前的問答 token 都傳給 OpenAI），但是新的對話 session 中的 ChatGPT 一定不記得之前 session 中的資訊。LangChain 中的 Chain 在前幾個月一直也都是這種無狀态的，但是通常開發 App 時開發者希望 LLM 能記住之前的互動。
在前 ChatGPT 時代，LangChain 不久還是實作了 Memory 的概念，在不同的 Query 間傳遞上下文，實作的方法跟開始的總結 300 頁 PDF 類似：
• 總體而言的方法是記錄之前的對話内容，将其放到 Prompt 的 Context 裡；
• 記錄有很多的 tricks，比如直接傳遞上下文，或者對之前的對話内容進行總結，然後将總結放 Prompt 裡。
微網誌部落客寶玉 xp 畫過一個系統互動圖，如果不使用被封裝好的庫，自己手寫的話實際上這套邏輯也很複雜。
在 Scale AI 今年的 Hackthon 決賽上，Sam 又為 LangChain 做了 Entity Memory 的能力，可以為 LLM 和使用者聊天時 Entity 提供長期記憶上下文的能力：
在 ChatGPT 釋出後，LangChain 又優化了 Memory 子產品，允許傳回 List[ChatMessage]，将邏輯單元拆分為了更小的元件，更符合子產品化的思想。
一站式粘合所有工具
子產品化和可組合性是 LangChain 的關鍵理念，但它還有一個理念和我們介紹過的 Universal API 公司很像。
其實站在投資者的視角看，LangChain 的壁壘比較薄。有人問過 Harrison：為什麼開發者要用 LangChain 而不是直接使用 OpenAI 或者 Hugging Face 上的模型？LangChain 作為一個開源庫仍然主要依賴于其他的開源庫，它的長期目标是什麼？Harrison 的回答是：
Hugging Face、OpenAI、Cohere 可以提供底座模型和 API，但是在産品中內建和使用它們仍然需要大量的工作，長期目标是幫助人們更容易地建構 LLM 支援的應用。
從這個視角看，LangChain 更像“膠水”和“螺栓”。它的價值在于：
1. 全過程一站式的內建，從非結構化資料的預處理到不同模型結果的評估，開發者所需要的工具和庫 LangChain 基本都有現成的內建。
2. LangChain 作為 Universal Layer 在 LLM 身上包了一層，讓使用者可以更自由地在多個 LLM、Embedding 引擎等之間切換，以避免單點風險和降低成本。
這裡的邏輯和 Universal API 很像 —— 每個 LLM 提供者的 API 資料結構不同，但是 LangChain 包了一層後做了遍 Data Normalization。從想象力的角度看，LangChain 有一定的編排價值，如果 Model as a Service 和多模型是未來，那麼 LangChain 的價值會比想象中厚一些。
舉兩個例子：
去年 OpenAI 的 API 還很貴的時候，一些資料加載器将文本塊變成向量的方式是調用 OpenAI 的 Davinci Embedding，Harrison 覺得 LangChain 可以做到先用 Hugging Face 或者 Cohere 上便宜的模型做一道，然後再傳給 Davinci Embedding，這樣可以降低不少成本。
還有今年以來，ChatGPT 有時候會崩，這也引發了應用開發者們的擔憂。Will Brenton 覺得出于這種理由用 LangChain 就很值得，可以用幾行代碼實作在多個 LLM 之間切換的邏輯，一個 LLM 如果服務挂掉了就自動試下一個。
使用 LangChain 對比多個模型的輸出
快速崛起的開源社群
LangChain 是目前 LLM 領域最熱門的開源項目之一，從下面可以看出今年以來的曲線和絕對 Star 數跟最熱門的開源模型 LLama 相比也不遑多讓，釋出不到 5 個月已經擁有了超過 1 萬個 Github Star。
人多力量大，我們在上文介紹的內建大多數也都是社群貢獻的，目前 LangChain 的全職團隊隻有 2-3 個人：
• 發起人是 Harrison Chase，他 17 年從哈佛大學畢業，分别在 Kensho（一家金融自動化公司，做金融分析決策與 NLP 的結合）和 Robust Intelligence（AI 模型部署的安全公司）做機器學習工程師，在 2022 年 9 月 的 Homebrew AI Club 聚會上聽到 Sam Whitmore 建構 AI 應用的過程和痛點後，他開始做 LangChain；
• 第一位全職加入 Harrison 的 LangChain 創業之旅的人似乎是 Ankush Gola，他從普林斯頓畢業後分别在 Facebook、Robust Intelligence 和 Unfold 做軟體開發，可以彌補 Harrison 在軟體工程方面經驗的缺失。Harrison 搞不定 LangChain 的異步支援問題，Ankush 加入後迅速彌補了這一點，讓 LangChain 能夠使用 asyncio 庫。
開源是擴大影響力和話語權的最好手段，LangChain 在 ChatGPT API 和 GPT-4 問世的當天都迅速釋出了內建，基于 LangChain 建構的應用想轉用 GPT-4 隻需要換下 API key 和模型名字就行了，顯然 LangChain 是 OpenAI 的重點合作對象之一。
除了 OpenAI 的這些更新，Zapier 推出的 Natural Language Actions API 也是跟 LangChain 進行了深度合作，Zapier NLA 對其 2 萬多個工具的操作實作了“自然語音 → API call → LLM-friendly 輸出”，也是基于 LangChain 做的。然後在推出當天，LangChain 也官宣了跟 Zapier NLA 的內建，使用者可以先在 Zapier 支援的 App 上設定好一個 NLA API endpoint，然後就可以在 LangChain 中調用群組合使用 Zapier。
從這兩個案例看，LangChain 是大模型能力“B2B2C”的一個重要中間站。
此外，除了給 LangChain 項目直接做貢獻，還有不少人已經在圍繞 LangChain 做生态項目，下面是我最喜歡的 2 個：
LangChain 本身是一個沒有 UI 的庫，但社群成員 Rodrigo Nader 為它建構了一個開源的 UI，叫做 LangFlow，讓使用者可以通過拖拽就能做出來應用原型。
大多數使用者會使用 Streamlit 或者 Replit 來部署它們的應用，但是已經有社群成員開始為 LangChain 應用打造更炫酷的部署方式，比如 Kookaburra，可以讓 LangChain 應用非常友善地被部署為短信機器人。
04.
挑戰：對 Prompt Ops 的質疑
從投資者視角，我對 LangChain 的擔憂有兩點：
1. 它是一個很難被商業化的開源項目，因為它是一個“依賴其他開源庫的開源庫”，我所訪談的 LangChain 開發者也都認為自己不會為它付費，如果要建構一個基于 LLM 應用的公司，他們會選擇自己 fork LangChain 再寫一套架構，還能順手把成本和延時問題做更多優化；
2. 和第一點相輔相成的是，目前使用 LangChain 的主流人群是 Hacker 和獨立開發者們，而不是 B 輪以後的 Mid-Market 或者大型企業公司。當然，這是目前 AI 應用生态的現狀，獨立開發者在數量上占據主導。而且目前的 LangChain 實作一些複雜邏輯需要多個 Chain 的嵌套，并且多次 call LLM API，對于大規模調用的産品可能也确實成本不經濟也有不穩定的情況。但是正因為此，LangChain 更難進行商業化，特别是在從資料準備到模型部署的全環節已經非常卷的情況下。
從演進的視角看，我對于 LangChain 這個庫本身能不能具備服務中大型公司倒比較有信心 —— 兩個月前人們還不認為 LangChain 是一個在生産環境中可靠的東西，一個月前 LangChain 才剛剛支援自托管模型，讓企業 LLM 使用者可以在 LangChain 中調用共享遠端 API，但是它在客戶自己的雲賬戶或者本地硬體中運作。給 LangChain 時間，貢獻者們會讓它高度可用。
市場上普遍對 LangChain 有擔心，但是我認為短期影響不大的兩點是：
1. LLM 本身的變化會讓 LangChain 庫中的許多部分過時。這一點我認為恰恰是開源項目的優勢，貢獻者可以迅速幫助它過渡到新版本；
比如 ChatGPT API 釋出後，它有了新的互動，這也意味着需要新的抽象，原來的很多 Prompt 不管用了，适用于 GPT-3 的 Prompt Templates 在 ChatGPT 下效果不好，是以 LangChain 又新增了 PromptSelectors 功能。此外 ChatGPT 在遵循特定的輸出資料格式上表現得不好，有很多“無法解析 LLM 輸出”的報錯，LangChain 很快上了一個 chat-zero-shot-react-description Agent 來嚴格限制輸出的資料格式，還大受好評。使用 LangChain 可能幫助很多公司避免過多的 Prompt Engineering 開發資源浪費。
2. 随着模型支援的 token 數量變多，LangChain 的核心用例 —— 用分塊、Embedding、語義搜尋、再拼回來 —— 可能會直接消失。這在短期内不是個問題，因為哪怕 GPT-4 的 3.2 萬 token 也仍然不是很夠用。同時，這種 Map Reduce 的方式還能省錢。
在理性的質疑中，我比較認可的是 Notion AI 的 Linus 的觀點，他在 Twitter 上表示目前所有類似 LangChain 的 Prompt Ops 工具都是為 side-project 級别的使用者服務的，很難正經接受它們，主要有 3 點原因：
1. 這些工具都假設一個服務是對 LLM 的調用，然後在此之上把業務邏輯耦合進去。而不是反過來，在已有業務邏輯裡插入對 LLM 的調用，這讓現有的 SaaS 等公司很難使用這些工具；
2. 對于模型的輸出大家目前都沒有可量化的方式來評估，Humanloop 已經有最好的模型評估 UI 了，但是也是為了人類回報對齊而不是為了應用開發者的性能優化和疊代；
3. 這些工具都希望成為生産環境下工作負載的關鍵中間點，但是有延時和安全性上的很有問題，還不如給使用者傳遞模型配置和最終 prompt 然後讓使用者自己調用模型。
一些朋友在 Linus 的觀點下指出： LangChain 不是一個 Prompt Ops 工具，它是一個 LLM 增強工具，通過粘合一系列的子產品（這些子產品本身可能是 Prompt 增強工具）增加了 LLM 可以融入的業務邏輯複雜度。Linus 也認同這一點。總體而言，我認為這些批評為 LangChain 指明了方向，它也的确在 3 月擁有了更多和模型評估以及性能可觀測性相關的內建。
05.
競争：以和為貴、各展神通的時代
抛開直接面向消費者的應用不看，LangChain 的核心競争對手是三類：
• GPT-Index 本身是基于 LangChain 建構的，它的用例更集中于 Memory 和将資料導入 LLM，用例非常明晰，而 LangChain 的功能更抽象和龐大，使用者需要在其中挑選符合自己用例的進行組合；
• Microsoft Semantic Kernel 的整體目标和 LangChain 非常接近，Planner 類似我們上文提到的 Agent，但是它針對的閱聽人不是獨立應用開發者，而是那些需要在兼顧原有開發工作的同時将 LLM 能力嵌入自家應用的工程師們，是以采用了一個輕量級 SDK 的形式傳遞，它是 LangChain非常強勁的潛在競争對手，但是 Microsoft 和 OpenAI 的親密關系可能讓它在未來無法像 LangChain 一樣靈活支援各類 LLM；
• Dust 和 Scale AI Spellbook 代表着 LLM 應用開發的無代碼和低代碼思路，擁有非常好的 UI/UX，但是大多數開發者認為自己并不是需要低代碼的工具，而是需要更多的功能和可實驗性。
我們訪談的所有 LangChain 使用者都隻使用 LangChain，對于 GPT-Index 和 Dust 隻探索到去它們的 Github 和官網逛逛的程度。有 Twitter 部落客專門橫向測評了這三個工具，結論是：
如果你想建構複雜邏輯并且自己托管後端的應用，那就使用 LangChain。Dust 和 Everyprompt 是通過 UI 來定義 Prompt 和建立 LLM 工作圖，LangChain 作為一個 Python 庫提供了更多的靈活性、可控度但更笨重。它的 game changer 是圍繞 Agent 的能力，一個可以跟外部工具（python interpreter、搜尋引擎）互動進而回答問題的 LLM，這是其他工具所不具備的。
不看大廠的話，創業三傑 LangChain、GPT-Index、Dust 互相有很多羁絆，絕對不是火并競争的關系：Dust 比 LangChain 出現得更早，由前 OpenAI 的Stanislas 建立，它的理念和對可組合性的重視對 Harrison 做 LangChain 有很大的啟發。而 GPT-Index 的創始人 Jerry Liu 是 Harrison 在 Robust Intelligence 時的同僚，是以兩個人經常交流産品想法，GPT-Index 和 LangChain 互相有非常多的內建。
甚至 GPT-Index 本身也是基于 LangChain 建構的，能享受 LangChain 基建更新的許多好處。比如 LangChain 在 1 月底提供了 tracing 的能力，讓使用者能更好觀測和 debug 自己的 Chain 和 Agent，GPT-Index 作為基于 LangChain 的包也自動獲得了這個功能。下圖是一個 GPT-Index query 的 tracing 視圖：
06.
未來：Harrison 超越 LangChain
LangChain 是一個開源項目，Harrison Chase 想建構的似乎不止于 LangChain。上個月，The Information 報道 Benchmark 以數千萬美元估值投資了 LangChain 數百萬美元。Harrison 有可能在繼續擴大 LangChain 影響力的同時做出更産品化的開發者工具。
從早期投資押注人的角度，Harrison 是一個很好的創業者和項目經理，盡管還沒有直接交流過，但我比較喜歡他的幾個特質：
敏銳地把握到了 LangChain 的機會
在 22 年下半年，市場逐漸開始意識到 LLM 的下一步是“Action”，也就是在外部世界能夠采取行動。标志性的事件之一是 Cohere 在 9 月推出了基于 LLM 的 Discord 搜尋機器人。
Harrison 這時候已經花了不少時間思考下一步所需要的工具，并且留意到了 Dust 的嘗試，随後就開始建構 LangChain 這個 Python 包，并且在 10 月就立馬推出。在此期間，碰到有人做應用，Harrison 經常會問問對方“什麼工具會幫你提效”、“還缺什麼工具”。
回過頭看，LangChain 能繼續火下去的前提是，目前 AI 應用已經從模型技術能力的 pk 到了産品能力的 pk，Harrison 自己的總結是“能有好的産品創意的人 > 能建立更好模型的人”，而 LangChain 就希望解鎖這些人的創意和效率。
對 LLM 的進展、能力、痛點
有自己獨到的了解
從後視鏡看，LangChain 的 Chain 和 Agent 邏輯似乎是個無腦的選擇。但是 Harrison 當時選擇建構這一點是基于對 Action 驅動和對 LLM 能力的判斷，受到了 ReAct 這篇論文不少影響。
他對于 token 數量限制的了解也很敏銳，将 Map Reduce 的實作提到了 LangChain 比較高的優先級，後面随着 1 月份各種 AI Hackthon（Hugging Face、Scale AI 等）的舉辦，對快速使用這個邏輯的需求激增，并且相關參賽隊伍都會提到自己使用了 LangChain，讓 LangChain 迅速變成了 AI 應用開發者們的第一選擇。
LangChain 開發者舊金山 Meetup 的盛況
非常緊貼使用者需求并且展現出
很強的執行力
LangChain 上線各類新模型和新內建的速度非常快，Harrison 自己幹活快，而且迅速讓 LangChain 的社群非常有凝聚力 —— AI 和 LLM 本身是有趣且實用的，Harrison 推動做了 LangChain Hub，旨在為使用者提供一個易于分享和發現 Prompt Sequence、Chain 和 Agent，又加深了這一點。同時，Harrison 很善于跟社群成員交流獲得更多的回報，在 LangChain Discord 社群頻繁互動，并且建立了一個專用的 Slack 頻道幫助大家将 LangChain 用于生産環境。
有一個小的細節是：在 1 月中旬，有使用者回報 LangChain 的 verbose（根據内容來自的模型或元件來使用突出色号顯示）挺有用但可以更詳細，比如每個查詢到底用了多少 token，這樣在應用可能被大規模使用時可以更好地追蹤成本。這是個很細節的功能，但是 Harrison 表達了重視并且在一周之後添加了對 token 的計算和顯示，并且通過 GPT-Index 統計 token 的具體使用情況。類似的例子我還觀察到了不少，隻要是 Harrison 答應使用者的需求，一定不久就會釋出。
Reference
Blog@LangChainTwitter@Harrison Chasehttps://www.youtube.com/watch?v=h0DHDp1FbmQhttps://www.youtube.com/watch?v=X51N9C-OhlEhttps://www.youtube.com/watch?v=Zn-L6t1BliAhttps://www.youtube.com/watch?v=lhby7Ql7hbk&t=8s
Runway：AI Native Tools工廠，視訊生成領域的位元組跳動
Jasper：早期GPT生态最大赢家，是否會被邊緣化？
Anthropic：出走OpenAI，Google站隊，AGI是天使還是魔鬼？
Character.AI：個性化的ChatGPT，AI大模型時代的UGC平台
OpenAI創始人的AGI預言：AI Safety、Scaling laws與GPT-20