Agent 最全 Playbook：場景、記憶和交互創新
編譯：Jiayu,Cage
AIAgent是我們緊密追蹤的范式變化，Langchain的一系列文章對理解Agent的發展趨勢很有幫助。在本篇編譯中，第一部分是Langchain團隊發布的StateofAIAgent報告。他們采訪了1,300多位從業者，包含開發者、產品經理、公司高管，揭示了Agent在今年的現狀和落地瓶頸：九成公司都對AIAgent有計劃和需求，但Agent能力的局限讓用戶只能在少數流程和場景中落地。比起成本和latency，大家更在乎Agent能力的提升，和對其行為的可觀測和可控性。
第二部分我們編譯了LangChain官網的IntheLoop系列文章中對AIAgent關鍵要素的分析：規劃能力、UI/UX交互創新和記憶機制。文中分析了5種LLM-native產品的交互方式，類比了3種人類的復雜記憶機制，對理解AIAgent，對理解這些關鍵要素有所啟發。在這一部分我們還加入了一些有代表性的Agent公司casestudy，如ReflectionAI創始人的訪談，來展望接下來2025年AIAgent的關鍵突破口。
在這個分析框架下，我們期待2025年AIAgent應用開始涌現，步入人機協作的新范式。對于AIAgent的規劃能力，以o3為首的模型正在展現出很強的反思和推理能力，模型公司的進展正在從reasoner逼近到Agent階段。隨著推理能力持續提升，Agent的“最后一公里”會是產品交互和記憶機制，這更可能是創業公司突破的機會。關于交互，我們一直期待AI時代的“GUI時刻“；關于記憶，我們相信Context會成為Agent落地的關鍵詞，個人層面的context個性化、企業層面的context統一都會讓Agent的產品體驗得到大幅提升。
01. Agent使用趨勢：
每個公司都在計劃部署Agent
Agent領域的競爭正在變激烈。在過去一年中，許多Agent框架變得普及：例如使用ReAct結合LLM進行推理和行動、使用multi-agent框架進行編排，或者是使用類似LangGraph這樣更可控的框架。
關于Agent的討論并不全是Twitter上的炒作。大約51%的受訪者目前正在生產中使用Agent。根據Langchain按公司規模的數據，100-2000員工的中型公司在Agent投入生產方面最為積極，比例達到63%。
此外，78%的受訪者有在近期內將采用將Agent投入生產的計劃。很明顯，大家對AIAgent有很強烈的興趣，但實際要做好一個production-ready的Agent對許多人來說仍然是一個難題。
監控：Agent應用需要可觀測和可控性
隨著Agent實現功能變得更加強大，就需要管理和監控Agent的方法。追蹤和可觀測性工具位列必備清單之首，幫助開發人員了解Agent的行為和性能。很多公司還使用guardrail（防護控制）以防止Agent偏離軌道。
將Agent投入生產的障礙和挑戰
保證LLM 的高質量performance 很難，回答需要有高準確性，還要符合正確的風格。這是Agent開發使用者們最關心的問題——比成本、安全等其他因素的重要性高出兩倍多。
LLMAgent是概率式的內容輸出，意味著較強的不可預測性。這引入了更多的錯誤可能性，使得團隊難以確保其Agent始終如一地提供準確、符合上下文的回應。
其他新興主題
在開放性問題中，大家對AIAgent展示出的這些能力有很多稱贊：
管理多步驟任務：AIAgent能夠進行更深入的推理和上下文管理，使它們能夠處理更復雜的任務；
自動化重復性任務：AIAgent繼續被視為處理自動化任務的關鍵，這可以為用戶解放時間，讓他們去解決更有創造性的問題；
任務規劃和協作：更好的任務規劃確保正確的Agent在正確的時間處理正確的問題，特別是在Multi-agent系統中；
類似人類的推理：與傳統LLM不同，AIAgent可以追溯其決策，包括根據新信息回顧并修改過去的決策。
此外大家還有兩個最期待的進展：
對開源AIAgent的期待：人們對開源AIAgent的興趣明顯，許多人提到集體智慧可以加速Agent的創新；
對更強大的模型的期待：許多人正在期待由更大、更強大的模型驅動的AIAgent的下一次飛躍—在那時，Agent能夠以更高的效率和自主性處理更復雜的任務。
問答中很多人也提到了Agent開發時最大的挑戰：如何理解Agent的行為。一些工程師提到他們在向公司stakeholder解釋AIAgent的能力和行為時會遇到困難。部分時候可視化插件可以幫助解釋Agent的行為，但在更多情況下LLM仍然是一個黑箱。額外的可解釋性負擔留給了工程團隊。
02.AIAgent中的核心要素
什么是Agentic系統
在StateofAIAgent報告發布之前，Langchain團隊已經在Agent領域寫了自己的Langraph框架，并通過IntheLoop博客討論了很多AIAgent中的關鍵組件，接下來就是我們對其中關鍵內容的編譯。
首先每個人對AIAgent的定義都略有不同，LangChain創始人HarrisonChase給出的定義如下：
AIAgent是一個用LLM來做程序的控制流決策的系統。
AnAIagentisasystemthatusesanLLMtodecidethecontrolflowofanapplication.
對其實現方式，文章中引入了Cognitivearchitecture（認知架構）的概念，認知架構是指Agent如何進行思考、系統如何去編排代碼/promptLLM：
Cognitive：Agent使用LLM來語義推理該如何編排代碼/PromptLLM;
Architecture:這些Agent系統仍然涉及大量類似于傳統系統架構的工程。
下面這張圖展示了不同層次Cognitivearchitecture的例子：
CaseStudy:
ReflectionAI創始人 Laskin 對Agent未來的愿景
在紅杉資本對ReflectionAI創始人MishaLaskin的訪談中，Misha提到他正在開始實現他的愿景：即通過將RL的SearchCapability與LLM相結合，在他的新公司ReflectionAI中構建最佳的Agent模型。他和聯合創始人IoannisAntonoglou（AlphaGo、AlphaZero、GeminiRLHF負責人）正在訓練為AgenticWorkflows設計的模型，訪談中的主要觀點如下：
深度是AIAgent中缺失的部分。雖然當前的語言模型在廣度方面表現出色，但它們缺乏可靠完成任務所需的深度。Laskin認為，解決“深度問題”對于創建真正有能力的AIAgent至關重要，這里的能力是指：Agent可以通過多個步驟規劃和執行復雜的任務；
將Learn和Search相結合是實現超人性能的關鍵。借鑒AlphaGo的成功，Laskin強調AI中最深刻的理念是Learn（依靠LLM）和Search（找到最優路徑）的結合。這種方法對于創建在復雜任務中可以勝過人類的Agent至關重要；
Post-training和Rewardmodeling帶來了重大挑戰。與具有明確獎勵的游戲不同，現實世界的任務通常缺乏真實獎勵。開發可靠的rewardmodel，是創建可靠的AIAgent的關鍵挑戰
UniversalAgents可能比我們想象的更接近。Laskin估計，我們可能只用三年時間就可以實現“digitalAGI”，即同時具有廣度和深度的AI系統。這一加速的時間表凸顯了在能力發展的同時解決安全性和可靠性問題的緊迫性
通往UniversalAgents的道路需要一種的方法。ReflectionAI專注于擴展Agent功能，從一些特定的環境開始，如瀏覽器、coding和計算機操作系統。他們的目標是開發UniversalAgents，使其不局限于特定任務。
UI/UX交互
在未來幾年，人機交互會成為research的一個關鍵領域：Agent系統與過去的傳統計算機系統不同，因為延遲、不可靠性和自然語言界面帶來了新的挑戰。因此，與這些Agent應用程序交互的新UI/UX范式將出現。Agent系統仍處于早期階段，但已經出現多種新興的UX范式。下面分別進行討論：
1.對話式交互(ChatUI)
聊天一般分為兩種：流式聊天（streamingchat）、非流式聊天（non-streamingChat）。
流式聊天是目前最常見的UX。它是一個Chatbot，以聊天格式將其思想和行為流回——ChatGPT是最受歡迎的例子。這種交互模式看起來很簡單，但也有不錯的效果，因為：其一，可以使用自然語言與LLM進行對話，這意味著客戶和LLM沒有任何障礙；其二，LLM可能需要一段時間才能工作，流式處理使用戶能夠準確了解后臺發生的事情；其三，LLM常常會出錯，Chat提供了一個很好的界面來自然地糾正和指導它，大家已經非常習慣于在聊天中進行后續對話和迭代討論事情。
但流式聊天也有其缺點。首先，流式聊天是一種相對較新的用戶體驗，因此我們現有的聊天平臺（iMessage、FacebookMessenger、Slack等）沒有這種方式；其次，對于運行時間較長的任務來說，這有點尷尬—用戶只是要坐在那里看著Agent工作嗎；第三，流式聊天通常需要由人類觸發，這意味著還需要大量humanintheloop。
非流式聊天的最大區別在于響應是分批返回的，LLM在后臺工作，用戶并不急于讓LLM立刻回答，這意味著它可能更容易集成到現有的工作流程中。人們已經習慣了給人類發短信——為什么他們不能適應用AI發短信呢？非流式聊天將使得與更復雜的Agent系統交互變得更加容易—這些系統通常需要一段時間，如果期望即時響應，這可能會令人沮喪。非流式聊天通常會消除這種期望，從而更輕松地執行更復雜的事情。
這兩種聊天方式有以下優缺點：
3.電子表格(SpreadsheetUX)
4.生成式UI(GenerativeUI)
“生成式UI”有兩種不同的實現方式。
一種方式是由模型自行生成需要的的原始組件。這類似于Websim等產品。在后臺，Agent主要編寫原始HTML，使其能夠完全控制顯示的內容。但是這種方法允許生成的webapp質量有很高的不確定性，因此最終結果可能看起來波動較大。
5.協作式UX（CollaborativeUX）
當Agent和人類一起工作時會發生什么？想想GoogleDocs，客戶可以在其中與團隊成員協作編寫或編輯文檔，但倘如協作者之一是Agent呢？
GeoffreyLitt和Ink&Switch合作的Patchwork項目是人類-Agent合作的一個很好的例子。（譯者注：這可能是最近penAICanvas產品更新的靈感來源）。
1.程序記憶（ProceduralMemory）：有關如何執行任務的長期記憶，類似于大腦的核心指令集
人類的程序記憶：記住如何騎自行車。
Agent的程序記憶：CoALA論文將程序記憶描述為LLM權重和Agent代碼的組合，它們從根本上決定了Agent的工作方式。
在實踐中，Langchain團隊還沒有看到任何Agent系統會自動更新其LLM或重寫其代碼，但是確實存在一些Agent更新其systemprompt的例子。
2.語義記憶(SemanticMemory):長期知識儲備
人類的語義記憶：它由信息片段組成，例如在學校學到的事實、概念以及它們之間的關系。
Agent的語義記憶：CoALA論文將語義記憶描述為事實存儲庫。
在實踐中上，常常是通過使用LLM從Agent的對話或交互中提取信息來實現的。此信息的確切存儲方式通常是特定于應用程序的。然后這些信息在將來的對話中檢索并插入到SystemPrompt中以影響Agent的響應。
3.情景記憶（EpisodicMemory）：回憶特定的過去事件
人類的情景記憶：當一個人回憶起過去經歷的特定事件（或“情節”）時。
Agent中的情景記憶：CoALA論文將情景記憶定義為存儲Agent過去動作的序列。
這主要用于讓Agent按預期執行動作。在實踐中，情景記憶的更新通過Few-ShotsPrompt的方法實現。如果相關更新的Few-ShotsPrompt足夠多，那么接下來的更新就通過DynamicFew-ShotsPrompt來完成。
如果一開始就有指導Agent正確完成操作的辦法，后面面對同樣的問題就可以直接使用這種辦法；相反，如果不存在正確的操作方式，或者如果Agent不斷做新的事情，那么語義記憶就會更重要，反而在前面的例子中，語義記憶不會有太大幫助。
除了考慮要在Agent中更新的記憶類型外，開發人員還要考慮如何更新Agent的記憶：
更新Agent記憶的第一種方法是“inthehotpath”。在這種情況下，Agent系統會在響應之前記住事實（通常通過工具調用），ChatGPT采取這種方法更新其記憶；
更新Agent記憶的另一種方法是“inthebackground”。在這種情況下，后臺進程會在會話之后運行以更新記憶。
比較這兩種方法，“inthehotpath”方法的缺點是在傳遞任何響應之前會有一些延遲，它還需要將memorylogic與agentlogic相結合。
但是，“inthebackground”可以避免這些問題-不會增加延遲，并且memorylogic保持獨立。但是“inthebackground”也有其自身的缺點：記憶不會立即更新，并且需要額外的logic來確定何時啟動后臺進程。
更新記憶的另一種方法涉及用戶反饋，這與情景記憶特別相關。例如，如果用戶對某次交互標評分較高（PostiveFeedback），Agent可以保存該反饋以備將來調用。
基于以上編譯內容，我們期待規劃、交互、記憶三個組件的同時進步，會讓我們在2025年看到更多可用的AIAgent，進入人機協同工作的新時代。