Harrison Chase：獨創 AI 智能體「認知架構」，定製+極簡加減法雙驅動

LangChain’s Harrison Chase on Building the Orchestration Layer for AI Agents

1

AI 智能體的發展

Sonya Huang：智能體（Agent）是當前大家都非常關注的話題。自從 LLM（大語言模型）興起以來，你一直在智能體構建的前沿。能給我們介紹一下智能體的定義嗎？

Harrison Chase：要定義智能體其實有些棘手。人們可能對它有不同的理解，這很正常，因為我們還處在 LLM 和智能體相關發展的早期階段。

我個人的理解是，智能體是由LLM決定應用程序的控制流程。

舉個例子，在傳統的 RAG（檢索增強生成）鏈中，流程是預設的：生成搜索查詢、檢索文檔、生成答案，最後反饋給用戶。

而智能體則將 LLM 放在中心，讓它自主決定下一步的行動。有時它會發起搜索，有時直接回覆用戶，甚至可能多次查詢，直到得出答案。LLM 能動態決定整個流程。

工具的使用也是智能體的重要特徵。當 LLM 決定行動時，它通常會調用不同的工具來實現。此外，記憶也是關鍵，當 LLM 確定下一步時，它需要記住之前的操作。

總的來說，智能體的核心就是讓 LLM 決定應用程序的控制流程。

Pat Grady：你提到的很多都和「決策」有關，我想知道智能體是否就是一種行動方式？這兩者是否相輔相成？智能體的行為是否更偏向某一方面？

Harrison Chase：我認為它們確實是相輔相成的。智能體的很多行為本質上是在決定如何採取行動，而這個過程的難點在於找到正確的行動。因此，解決「決策」問題通常也能解決「行動」問題。一旦決策確定，LLM 系統就會執行相應的行動並反饋結果。

Sonya Huang：智能體與鏈的主要區別在於 LLM 自主決定下一步，而不是預先設定步驟。這種區分是否準確？

Harrison Chase：是的，這是一個很好的描述。不過，實際上有不同的層次。比如，簡單的路由器可能做的是鏈中的路徑選擇，雖然 LLM 依然在決策，但這隻是基礎應用。而完全自主的智能體則是另一種極端。整體來看，確實存在一些細微的差別和灰色地帶。

Sonya Huang：明白了，智能體的範圍從部分控制到完全自主決策都有，這很有趣。你覺得 LangChain 在智能體生態系統中扮演了什麼角色？

Harrison Chase：我們現在的重點是讓人們更容易創建介於這兩者之間的智能體。我們發現，最有效的智能體通常位於這個中間地帶。儘管完全自主的智能體吸引人，且已有原型，但它們常常偏離預期。因此，我們的工作集中在「編排層」，以便構建靈活但仍有一定約束的智能體。如果你想深入瞭解，我們可以再討論。但總的來說，LangChain 的願景是成為一個編排框架。

Sonya Huang：我記得在2023年3月左右，像 BabyAGI 和 AutoGPT 這樣的自主智能體引起了很多關注，但它們的首批迭代似乎沒有達到人們的期望。你認為原因是什麼？現在智能體的炒作週期處於什麼階段？

Harrison Chase：確實，AutoGPT 的出現開啟了智能體的炒作週期，尤其是在 GitHub 上受歡迎。這個熱潮從 2023 年春季持續到夏季，之後稍微降溫。到了 2024 年，我們開始看到一些實用的應用，比如 LangChain 與 Elastic 的合作，推出了 Elastic Assistant 和 Elastic Agent 等生產級智能體。這些應用，如 Klarna 的客戶支持機器人，引發了更多討論。此外，Devon 和 Cira 等公司也在智能體領域進行嘗試。

關於 AutoGPT 未能完全成功的原因，我認為主要是它們過於籠統，缺乏明確的任務和規則。企業希望智能體能完成更具體的工作，而不僅僅是模糊的自主智能體。因此，我們看到的智能體更多像是定製的認知架構，儘管靈活，但需要更多的工程投入和開發時間，這也是這些系統一年前還未出現的原因。

2

定製認知框架

Sonya Huang：你前面提到了「認知架構」，我很喜歡你對它的思考方式。能否解釋一下，什麼是認知架構？我們應該如何理解它？有沒有一個合適的思維框架？

Harrison Chase：是的，我理解的認知架構，基本上是指在使用大語言模型（LLM）時，你的系統架構是什麼樣的。

如果你正在構建一個應用，其中涉及多個算法步驟，你是如何利用這些算法的？你是否用它們生成最終答案？還是用它們在不同任務間進行選擇？是否有非常複雜的分支，甚至包含多個循環？

這些都是認知架構的不同表現形式。認知架構其實就是指，從用戶輸入到輸出，LLM在調用過程中如何處理和流轉信息。

尤其是在把智能體投入生產時，我們發現流程通常是根據具體應用需求而定製的。

例如，某個應用可能需要先進行一些特定的檢查，再執行幾個步驟，每個步驟又可能包含循環或分支。這就像是你在畫一張流程圖，而這種定製化的流程越來越普遍，因為人們希望智能體在應用中更可控。

我之所以稱它為「認知架構」，是因為LLM的核心優勢在於它的推理能力，你可以通過編碼這種認知心理模型，將其變成軟件系統中的某種架構。

Pat Grady：你覺得這是未來的發展方向嗎？我聽到了兩點，一是非常定製化，二是它聽起來更像是硬編碼的。你認為這是我們當前的方向，還是暫時的解決方案？未來會出現更優雅的架構，或者一系列標準化的參考架構嗎？

Harrison Chase：這是個很好的問題，我花了很多時間在思考這個。我認為，在極端情況下，如果模型在規劃上非常強大且可靠，你可能只需要一個簡單的 for 循環，反復調用 LLM 來決定下一步該做什麼，然後執行操作並再次循環。

所有你希望模型遵循的約束都可以通過提示傳達，而模型也會按你預期的方式執行。儘管我相信模型在推理和規劃方面會越來越好，但我不認為它們會完全取代手動構建的架構。

首先是效率問題。如果你知道某個步驟總是需要在另一步驟之後執行，那麼你可以直接把它們按順序安排好。

其次是可靠性，尤其是在企業環境中，人們需要一定的保障，確保關鍵步驟按預期執行。

因此，我認為雖然構建這些架構可能會變得更容易，但它們仍然會有一定複雜性。

從架構的角度看，你可以認為「在循環中運行 LLM」是一種非常簡單但通用的認知架構。而我們在實際生產中看到的更多是定製化、複雜的架構。

我覺得隨著時間推移，通用規劃和反思功能會被直接訓練到模型中，但那些需要高度定製的規劃、反思和控制功能依然不會被取代。

Sonya Huang：可以這樣理解：LLM可以完成通用的智能體推理，但在具體領域中，你還需要定製化的推理能力。這些是無法完全內置到通用模型中的。

Harrison Chase：完全正確。自定義認知架構的核心思想在於，你讓人類來承擔規劃責任，而不是完全依賴 LLM。

儘管某些規劃功能可能會越來越接近模型和提示，但很多任務的規劃過程依然複雜，無法完全自動化。我們還需要時間，才能發展出高度可靠、即插即用的解決方案。

3

用戶體驗設計

Sonya Huang：我相信智能體將成為人工智能的新潮流，我們正從 AI 助手轉向 AI 智能體。你同意嗎？為什麼？

Harrison Chase：我基本同意。智能體的潛力在於，傳統的 AI 助手依賴人類輸入，任務能力有限。而智能體能更獨立地行動，偶爾與用戶互動，這使它們能自主處理更多任務。

但賦予它們更多自主性也帶來了風險，例如可能出現偏差或錯誤。因此，找到自主性與可靠性之間的平衡將是一個重要的挑戰。

Pat Grady：你在 AI Ascent 上提到了用戶體驗。通常，我們認為它與架構位於光譜的兩端——架構是幕後工作，而用戶體驗是前端展示。

但現在似乎情況有所不同，用戶體驗實際上可以影響架構的有效性。比如，當出現問題時，你可以像 Devin 一樣，回溯到規劃過程中出錯的地方。

你能談談用戶體驗在智能體或 LLM 中的重要性嗎？另外，你覺得有哪些有趣的發展？

Harrison Chase：用戶體驗在當前非常重要，因為 LLM 並不完美，時常出錯。聊天模式特別有效，它允許用戶實時查看模型的反應，並及時糾正錯誤或追問細節。雖然這種模式已成為主流，但它的局限在於依然需要用戶的持續反饋，更多是一種「助手」的體驗。

如果能減少用戶的介入，讓 AI 自動完成更多任務，將帶來巨大的變革。

不過，如何在自動化和用戶參與之間找到平衡是個難題。一些有趣的想法正在嘗試解決這個問題。例如，創建一個智能體透明度列表，讓用戶清晰瞭解AI執行的每一步。如果某個步驟出錯，用戶可以直接回溯並調整指令。

另一個創新的想法是引入「收件箱」體驗，讓智能體在後台並行運行，當需要人類幫助時，它可以像發郵件一樣提醒用戶，這樣用戶就可以在合適的時機介入，而不必全程監控。

在協作方面，智能體可以先起草文檔，用戶作為審閱者提供反饋。實時互動的體驗也很吸引人。

例如，用戶在評論時，智能體能夠立即修復問題，就像在 Google Docs 中一樣。這種互動方式能夠增強用戶體驗，使AI真正成為高效的工作夥伴。

Pat Grady：你提到的關於智能體如何從交互中學習，真的很有意思。如果我每次都要重覆給同一個反饋，那體驗就會變得很糟糕，對吧？系統該如何提升這種反饋機制？

Harrison Chase：確實！如果我們不斷給智能體相同的反饋，而它卻不改進，那無疑會讓人沮喪。因此，系統的架構需要能夠從這些反饋中學習，不僅僅是修復當前的問題，還能積累經驗，避免將來再犯。

這方面的進展雖然還處於早期階段，但我們已經花了很多時間在思考這些問題上，並相信隨著技術的進步，智能體會變得越來越「聰明」，從而帶來更流暢的用戶體驗。

讓啤酒變得更好

Sonya Huang：在過去六個月，智能體領域取得了顯著進展。普林斯頓的研究表明，他們的智能體能解決 12.5% 的 GitHub 問題，而依賴檢索增強生成（RAG）時只有 3.8%。

儘管有所進步，但 12.5% 仍不足以取代實習生。你認為智能體的發展到了哪個階段？它們能否在面向客戶的環境中可靠部署？

Harrison Chase：是的，SWE 智能體相對通用，可以處理多種 GitHub 問題。定製智能體的可靠性雖然沒有達到「99.999%」，但已經足夠在生產環境中使用。例如，Elastic 的智能體已在多個項目中應用。雖然我沒有具體的可靠性數據，但它們足夠可靠，可以上線。通用智能體面臨更大挑戰，需要更長的上下文窗口和更好的推理能力才能廣泛應用。

Sonya Huang：你提到過思路鏈（Chain of Thought）等技術，能分享認知架構對智能體性能的影響嗎？你認為最有前途的認知架構是什麼？

Harrison Chase：AutoGPT 等項目沒有成功的一個原因是早期 LLM 無法明確推理第一步該做什麼。思路鏈等技術為模型提供了更好的推理空間。

姚舜宇的 ReAct 論文是第一個專門用於智能體的認知架構之一。ReAct 結合了推理和行動，讓模型不僅執行動作，還能進行推理，從而提高其能力。現在，隨著模型訓練的深入，顯式推理步驟變得不再那麼必要。

當前主要挑戰在於長期規劃和執行，模型在這方面表現不佳，需要認知架構幫助生成計劃並逐步執行。反思則幫助判斷任務是否完成。

總的來說，規劃和推理是目前最重要的通用認知架構，未來隨著訓練改進，這些問題將得到更好的解決。

Sonya Huang：你提到傑夫·貝索斯說過「專注於讓你的啤酒更好」。這讓我想到早期許多啤酒廠選擇自己發電。今天很多公司面臨類似問題：是否需要控制認知架構來提升業務？構建和優化這些架構真的能「讓你的啤酒更好」，還是應該放棄控制，專注於用戶界面和產品開發？

Harrison Chase：這取決於你構建的認知架構類型。如果是通用架構，可能不會直接提升業務。未來，模型提供商會專注於通用的規劃和認知架構，企業可以直接使用這些來解決問題。但如果是高度定製的架構，反映了特定的業務流程或最佳實踐，那它確實能提升業務，尤其在依賴這些應用的領域。

定製的業務邏輯和認知模型可以顯著提高系統表現，個性化後更加精確和高效。儘管用戶體驗和界面設計依然重要，但定製化智能體顯然是企業的一個重要優勢。我認為通用和定製之間有很大的區別。

4

編排和可觀察性

LangSmith and LangGraph

Sonya Huang：我們能聊聊 LangSmith 和 LangGraph 嗎？你們解決了哪些問題？特別是在智能體管理方面，你們的產品如何幫助人們更好地管理狀態和提高智能體的可控性？

Harrison Chase：當然可以。LangChain 的推出解決了關鍵問題，尤其是標準化各個組件的接口。這讓我們能夠與多種模型、向量存儲、工具和數據庫進行廣泛集成，這也是LangChain受歡迎的重要原因。

LangChain 還提供了一系列高級接口，使用戶可以輕鬆使用功能，如 RAG（檢索增強生成）和 SQL 問答，同時動態構建鏈的運行時間也較短。我們把這些「鏈」視為有向無環圖（DAG），這一點很重要。

LangGraph 解決了與可定製和可控的循環元素相關的問題。循環引入了新挑戰，比如設計持久化層，以便恢復狀態並讓循環在後台異步運行。因此，我們關注如何有效部署長期、循環和人機交互的應用程序。

關於 LangSmith，自公司成立以來我們就一直在研究它，專注於 LLM 應用的可觀察性和測試。

我們發現，LLM 作為核心時，其固有的不確定性使得可觀察性和測試尤為重要，以確保能自信地投入生產。LangSmith 的設計使其能夠與 LangChain 無縫配合。

此外，LangSmith 還提供了提示中心，幫助用戶管理和手動審查提示。這在整個過程中顯得尤其重要，因為我們需要明確 LLM 輸出的新內容。

可觀察性是 LLM 的顯著特徵，而測試的複雜性也在增加。因此，我們希望人們能更頻繁地審查內容，而不僅僅局限於傳統的軟件測試。LangSmith 提供的工具和路由正是為瞭解決這些挑戰。

可觀察性

Pat Grady：你是否有一種啟髮式的方法來評估現有的可觀察性、測試和填空，看看它們在多大程度上適用於 LLM？哪些特徵使得現有 LLM 與之前的模型有顯著不同，以至於你們需要開發新產品、新架構或新方法？

Harrison Chase：是的，這確實是一個值得深入思考的問題。尤其是在可觀察性和測試方面，LLM 的複雜性讓我們必須創新。雖然像 Datadog 這樣的工具可以很好地監控，但要深入分析多步驟的應用程序，LangSmith 能提供更精細的痕跡分析，幫助更好地調試和應對 LLM 的不確定性。

測試方面也很有趣。在傳統軟件測試中，通常只關注結果是否通過，而不進行成對比較。然而，LLM 評估中，像 LLMSYS 這種工具允許並排比較兩個模型，這種方式在 LLM 測試中尤為關鍵。

另一個挑戰是，LLM測試中你不會總是有100%的通過率，因此跟蹤進展非常重要，確保你在不斷進步，而不是退步。相比傳統測試的通過/失敗判斷，LLM的測試需要更細緻的跟蹤和分析。

最後，人類的參與至關重要。儘管我們希望系統自動化運行，但人工干預往往更可靠。這和軟件測試中簡單的等式驗證非常不同，我們需要引入人類判斷，使測試更加精確且靈活。

5

軟件開發的未來

Pat Grady：在深入討論智能體構建細節前，我想問一個問題。我們的創始人唐·華倫丁有一個著名的提問「那又怎樣？」如果自主智能體完美運作，那又怎樣？這對世界有什麼影響？我們的生活將如何不同？

Harrison Chase：從更高層面來看，這意味著我們人類將可以關注不同的事情。

現階段，很多行業都依賴重覆性、機械性的工作，而智能體的想法是自動化其中的大部分，從而讓我們能夠專注於更高層次的問題。我們可以利用智能體的輸出進行更多創造性和高槓桿的工作，像公司運營中的許多職能可以外包給智能體。

你可以想像自己扮演首席執行官的角色，而智能體負責營銷、銷售等其他職能，自動化大量重覆性工作，讓你有更多時間進行戰略思考或產品開發。這將使我們自由地做我們擅長的、有興趣的事情，擺脫那些不太願意做的機械工作。

Pat Grady：你有沒有看到任何現實中的例子，或者有什麼正在開發中的有趣項目？

Harrison Chase：目前兩個最受關注的智能體領域是客戶支持和編碼。

客戶支持是一個很好的例子，很多公司都需要外包這類服務，而智能體可以高效地替代這部分工作，這會非常有力。

至於編碼，它更複雜，涉及許多創造性和產品定位的思考。雖然某些編碼任務確實限制了人的創造力，但如果有智能體可以自動完成這些編碼任務，像我媽媽有一個網站的想法但不會編程，這樣的智能體就能讓她把更多精力放在網站的想法和範圍上，而代碼部分可以自動生成。

客戶支持智能體已經開始發揮作用，而在編碼領域，也有許多新進展，儘管它還未完全成熟，但許多人正開展有趣的項目。

Pat Grady：你提到的編碼問題很有趣，因為這是我們對人工智能抱有樂觀態度的原因之一。AI有可能縮短從想法到執行的距離，讓創造性的想法更容易變成現實。像 Figma 的 Dylan 經常談論這一點。

Harrison Chase：是的，自動化可以消除那些阻礙創作的東西，這種「從想法到現實」的轉換非常吸引人。在生成式 AI 時代和智能體時代，「構建者」的定義將發生變化。

今天的軟件構建者大多是工程師，或者需要僱傭工程師。而未來，借助智能體和生成式 AI，構建者可以構建更多的東西，因為他們可以低成本地利用智能體，獲得所需的知識和能力。這相當於讓智能體商品化了情報，意味著更多人可以成為構建者。

Pat Grady：我很好奇，對於那些試圖使用 LLMs 構建產品或 AI 的開發人員來說，有哪些問題是你們目前沒有直接解決，但未來可能會考慮的？

Harrison Chase：是的，確實有兩個主要領域。一個是模型層，另一個是數據庫層。

比如，我們並不打算構建矢量數據庫，但關於如何存儲數據，這是個非常有趣的問題。不過，這並不是我們現在的重點。我們也不構建基礎模型，也不專注於微調。

我們更多是想幫助開發者在數據管理上簡化工作流程，但並不打算為了微調去搭建基礎設施。

有很多公司，比如 Fireworks，正在專門做這些事，這真的很有趣。對於開發者來說，這些問題處於技術堆棧的底層。

同時，另一個值得思考的問題是，如果智能體真的像我們設想的那樣變得更加普遍，將會出現哪些新的基礎性問題？所以說實話，現在就說我們未來會做什麼或者不會做什麼還為時尚早。因為我們現在離一個完全可靠的智能體經濟系統還有一段距離。

不過，有些概念已經很吸引人了，比如智能體的身份驗證、授權、支付等基礎設施。

想像一下，未來的某天，智能體給人類支付服務費用，而不是相反！這種場景真的讓人興奮。如果智能體真的像我們想像的那樣流行起來，我們需要什麼樣的工具和基礎設施來支持這一切？

這些問題和開發者社區中構建 LLM 應用程序的需求有些不同。LLM 應用已經在這裏了，智能體正在逐步成熟，但整個智能體生態系統還沒有完全成型。這會是一個非常有趣的發展方向。

Sonya Huang：你剛才提到微調，說你們目前不打算深入這個領域。看起來提示工程和微調常常被認為是互相替代的工具。你怎麼看現在提示與微調的使用方式？你覺得未來的走向會怎樣？

Harrison Chase：其實，我並不認為微調和認知架構是互相替代的。相反，我覺得它們在很多方面是互補的。

當你有更定製化的認知架構時，智能體每個部分或節點的職責變得更加具體明確。而在這種情況下，微調就顯得格外有用。因為當你明確了每個模塊的工作範圍時，微調就可以進一步優化這些模塊的表現。

所以我覺得微調和架構的關係並不是互相競爭的，而是各司其職，互相增強的。