隨著人工智能技術(shù)的不斷進(jìn)步，AI Agent 正在成為推動(dòng)人機(jī)協(xié)作的新范式。本文通過(guò)對(duì) Langchain 團(tuán)隊(duì)的研究報(bào)告和行業(yè)案例的分析，揭示了 AI Agent 在規(guī)劃能力、UI/UX 交互創(chuàng)新和記憶機(jī)制方面的關(guān)鍵突破點(diǎn)，展望了 2025 年 AI Agent 應(yīng)用的廣闊前景，供大家參考。

AI Agent 是我們緊密追蹤的范式變化，Langchain 的一系列文章對(duì)理解 Agent 的發(fā)展趨勢(shì)很有幫助。在本篇編譯中，第一部分是 Langchain 團(tuán)隊(duì)發(fā)布的 State of AI Agent 報(bào)告。他們采訪了 1,300 多位從業(yè)者，包含開(kāi)發(fā)者、產(chǎn)品經(jīng)理、公司高管，揭示了 Agent 在今年的現(xiàn)狀和落地瓶頸：九成公司都對(duì) AI Agent 有計(jì)劃和需求，但 Agent 能力的局限讓用戶只能在少數(shù)流程和場(chǎng)景中落地。比起成本和 latency，大家更在乎 Agent 能力的提升，和對(duì)其行為的可觀測(cè)和可控性。

第二部分我們編譯了 LangChain 官網(wǎng)的 In the Loop 系列文章中對(duì) AI Agent 關(guān)鍵要素的分析：規(guī)劃能力、UI/UX 交互創(chuàng)新和記憶機(jī)制。文中分析了 5 種 LLM-native 產(chǎn)品的交互方式，類比了 3 種人類的復(fù)雜記憶機(jī)制，對(duì)理解 AI Agent，對(duì)理解這些關(guān)鍵要素有所啟發(fā)。在這一部分我們還加入了一些有代表性的 Agent 公司 case study，如 Reflection AI 創(chuàng)始人的訪談，來(lái)展望接下來(lái) 2025 年 AI Agent 的關(guān)鍵突破口。

在這個(gè)分析框架下，我們期待 2025 年 AI Agent 應(yīng)用開(kāi)始涌現(xiàn)，步入人機(jī)協(xié)作的新范式。對(duì)于 AI Agent 的規(guī)劃能力，以 o3 為首的模型正在展現(xiàn)出很強(qiáng)的反思和推理能力，模型公司的進(jìn)展正在從 reasoner 逼近到 Agent 階段。隨著推理能力持續(xù)提升，Agent 的“最后一公里”會(huì)是產(chǎn)品交互和記憶機(jī)制，這更可能是創(chuàng)業(yè)公司突破的機(jī)會(huì)。關(guān)于交互，我們一直期待 AI 時(shí)代的“GUI時(shí)刻“；關(guān)于記憶，我們相信 Context 會(huì)成為 Agent 落地的關(guān)鍵詞，個(gè)人層面的 context 個(gè)性化、企業(yè)層面的 context 統(tǒng)一都會(huì)讓 Agent 的產(chǎn)品體驗(yàn)得到大幅提升。

01.State of AI Agent

Agent 使用趨勢(shì)：每個(gè)公司都在計(jì)劃部署 Agent

Agent 領(lǐng)域的競(jìng)爭(zhēng)正在變激烈。在過(guò)去一年中，許多 Agent 框架變得普及：例如使用 ReAct 結(jié)合 LLM 進(jìn)行推理和行動(dòng)、使用 multi-agent 框架進(jìn)行編排，或者是使用類似 LangGraph 這樣更可控的框架。

關(guān)于 Agent 的討論并不全是 Twitter 上的炒作。大約 51%的受訪者目前正在生產(chǎn)中使用 Agent。根據(jù) Langchain 按公司規(guī)模的數(shù)據(jù)，100-2000 員工的中型公司在 Agent 投入生產(chǎn)方面最為積極，比例達(dá)到63%。

此外，78%的受訪者有在近期內(nèi)將采用將 Agent 投入生產(chǎn)的計(jì)劃。很明顯，大家對(duì) AI Agent 有很強(qiáng)烈的興趣，但實(shí)際要做好一個(gè) production-ready 的 Agent 對(duì)許多人來(lái)說(shuō)仍然是一個(gè)難題。

盡管技術(shù)行業(yè)通常被認(rèn)為是早期的 Agent 使用者，但所有行業(yè)對(duì) Agent 的興趣都在與日俱增。在非技術(shù)公司工作的受訪者中，有90%已經(jīng)或計(jì)劃將Agent投入生產(chǎn)（與技術(shù)公司的比例幾乎相同，為89%）。

Agent 的常用 use case

Agent 最常用的 use case 包括進(jìn)行研究和總結(jié)（58%），其次是通過(guò)定制化的 Agent 簡(jiǎn)化工作流程 （53.5%）。

這些反映了人們希望有產(chǎn)品來(lái)處理那些過(guò)于消耗時(shí)間的任務(wù)。用戶可以依賴 AI Agent 從大量信息中提取關(guān)鍵信息和見(jiàn)解，而不是自己從海量的數(shù)據(jù)中篩選，再進(jìn)行資料回顧或研究分析。同樣，AI Agent 可以通過(guò)協(xié)助日常任務(wù)來(lái)提升個(gè)人生產(chǎn)力，使用戶能夠?qū)Ｗ⒂谥匾马?xiàng)。

不僅個(gè)人需要這種效率的提升，公司和團(tuán)隊(duì)也同樣需要?？头?5.8%）是 Agent的另一個(gè)主要應(yīng)用領(lǐng)域，Agent 幫助公司處理咨詢、故障排除，并加快跨團(tuán)隊(duì)的客戶響應(yīng)時(shí)間；排在第四、第五位的是更底層的 code 和 data 應(yīng)用。

監(jiān)控：Agent 應(yīng)用需要可觀測(cè)和可控性

隨著 Agent 實(shí)現(xiàn)功能變得更加強(qiáng)大，就需要管理和監(jiān)控 Agent 的方法。追蹤和可觀測(cè)性工具位列必備清單之首，幫助開(kāi)發(fā)人員了解 Agent 的行為和性能。很多公司還使用 guardrail（防護(hù)控制）以防止 Agent 偏離軌道。

在測(cè)試 LLM 應(yīng)用程序時(shí)，離線評(píng)估（39.8%）比在線評(píng)估（32.5%）被更常被使用，這反映了實(shí)時(shí)監(jiān)控 LLM 的困難。在 LangChain 提供的開(kāi)放式回答中，許多公司還讓人類專家手動(dòng)檢查或評(píng)估響應(yīng)，作為額外的預(yù)防層。

盡管人們對(duì) Agent 的熱情很高，但在 Agent 權(quán)限上普遍還是比較保守。很少有受訪者允許他們的 Agent自由地讀取、寫入和刪除。相反，大多數(shù)團(tuán)隊(duì)只允許讀取權(quán)限的工具權(quán)限，或需要人類批準(zhǔn) Agent 才可以做更有風(fēng)險(xiǎn)的行動(dòng)，如寫入或刪除。

不同規(guī)模的公司在 Agent 控制方面也有不同的優(yōu)先級(jí)。不出所料，大型企業(yè)（2000名以上員工）更加謹(jǐn)慎，嚴(yán)重依賴 “read-only” 權(quán)限以避免不必要的風(fēng)險(xiǎn)。他們也傾向于將 guardrail 防護(hù)與離線評(píng)估相結(jié)合，不希望客戶看到任何問(wèn)題。

與此同時(shí)，小型公司和初創(chuàng)公司（少于100名員工）更專注于追蹤以了解其 Agent 應(yīng)用程序中發(fā)生了什么（而不是其他控制）。根據(jù) LangChain 的調(diào)查數(shù)據(jù)，較小的公司傾向于專注于通過(guò)查看數(shù)據(jù)來(lái)理解結(jié)果；而大型企業(yè)則在全面范圍內(nèi)設(shè)置了更多的控制措施。

將 Agent 投入生產(chǎn)的障礙和挑戰(zhàn)

保證 LLM 的高質(zhì)量 performance 很難，回答需要有高準(zhǔn)確性，還要符合正確的風(fēng)格。這是 Agent 開(kāi)發(fā)使用者們最關(guān)心的問(wèn)題——比成本、安全等其他因素的重要性高出兩倍多。

LLM Agent 是概率式的內(nèi)容輸出，意味著較強(qiáng)的不可預(yù)測(cè)性。這引入了更多的錯(cuò)誤可能性，使得團(tuán)隊(duì)難以確保其 Agent 始終如一地提供準(zhǔn)確、符合上下文的回應(yīng)。

對(duì)于小型公司尤其如此，性能質(zhì)量遠(yuǎn)遠(yuǎn)超過(guò)了其他考慮因素，有 45.8 %的人將其作為主要關(guān)注點(diǎn)，而成本（第二大關(guān)注點(diǎn)）僅為22.4%。這一差距強(qiáng)調(diào)了可靠、高質(zhì)量的性能對(duì)于組織將 Agent 從開(kāi)發(fā)轉(zhuǎn)移到生產(chǎn)的重要性。

安全問(wèn)題對(duì)于需要嚴(yán)格合規(guī)，并敏感處理客戶數(shù)據(jù)的大型公司也普遍存在。

挑戰(zhàn)不止于質(zhì)量。從 LangChain 提供的開(kāi)放式回答中，許多人對(duì)公司是否要持續(xù)投入開(kāi)發(fā)和測(cè)試 Agent 仍保持懷疑。大家提到兩個(gè)突出的阻礙：開(kāi)發(fā) Agent 需要的知識(shí)很多，且需要一直跟進(jìn)技術(shù)前沿；開(kāi)發(fā)部署 Agent 需要的時(shí)間成本很大，是否能可靠運(yùn)行的收益又不太確定。

其他新興主題

在開(kāi)放性問(wèn)題中，大家對(duì) AI Agent 展示出的這些能力有很多稱贊：

• 管理多步驟任務(wù)：AI Agent 能夠進(jìn)行更深入的推理和上下文管理，使它們能夠處理更復(fù)雜的任務(wù)；
• 自動(dòng)化重復(fù)性任務(wù)：AI Agent 繼續(xù)被視為處理自動(dòng)化任務(wù)的關(guān)鍵，這可以為用戶解放時(shí)間，讓他們?nèi)ソ鉀Q更有創(chuàng)造性的問(wèn)題；
• 任務(wù)規(guī)劃和協(xié)作：更好的任務(wù)規(guī)劃確保正確的 Agent 在正確的時(shí)間處理正確的問(wèn)題，特別是在 Multi-agent 系統(tǒng)中；
• 類似人類的推理：與傳統(tǒng)LLM不同，AI Agent可以追溯其決策，包括根據(jù)新信息回顧并修改過(guò)去的決策。

此外大家還有兩個(gè)最期待的進(jìn)展：

1. 對(duì)開(kāi)源 AI Agent 的期待：人們對(duì)開(kāi)源 AI Agent 的興趣明顯，許多人提到集體智慧可以加速 Agent 的創(chuàng)新；
2. 對(duì)更強(qiáng)大的模型的期待：許多人正在期待由更大、更強(qiáng)大的模型驅(qū)動(dòng)的 AI Agent 的下一次飛躍—在那時(shí)，Agent 能夠以更高的效率和自主性處理更復(fù)雜的任務(wù)。

問(wèn)答中很多人也提到了 Agent 開(kāi)發(fā)時(shí)最大的挑戰(zhàn)：如何理解 Agent 的行為。一些工程師提到他們?cè)谙蚬?stakeholder 解釋 AI Agent 的能力和行為時(shí)會(huì)遇到困難。部分時(shí)候可視化插件可以幫助解釋 Agent 的行為，但在更多情況下 LLM 仍然是一個(gè)黑箱。額外的可解釋性負(fù)擔(dān)留給了工程團(tuán)隊(duì)。

02.AI Agent 中的核心要素

什么是 Agentic 系統(tǒng)

在 State of AI Agent 報(bào)告發(fā)布之前，Langchain 團(tuán)隊(duì)已經(jīng)在 Agent 領(lǐng)域?qū)懥俗约旱?Langraph 框架，并通過(guò) In the Loop 博客討論了很多 AI Agent 中的關(guān)鍵組件，接下來(lái)就是我們對(duì)其中關(guān)鍵內(nèi)容的編譯。

首先每個(gè)人對(duì) AI Agent 的定義都略有不同，LangChain 創(chuàng)始人 Harrison Chase 給出的定義如下：

AI Agent 是一個(gè)用 LLM 來(lái)做程序的控制流決策的系統(tǒng)。
An AI agent is a system that uses an LLM to decide the control flow of an application.

對(duì)其實(shí)現(xiàn)方式，文章中引入了 Cognitive architecture（認(rèn)知架構(gòu)） 的概念，認(rèn)知架構(gòu)是指 Agent 如何進(jìn)行思考、系統(tǒng)如何去編排代碼/ prompt LLM：

• Cognitive：Agent 使用 LLM 來(lái)語(yǔ)義推理該如何編排代碼/ Prompt LLM;
• Architecture: 這些 Agent 系統(tǒng)仍然涉及大量類似于傳統(tǒng)系統(tǒng)架構(gòu)的工程。

下面這張圖展示了不同層次 Cognitive architecture 的例子：

• 標(biāo)準(zhǔn)化的軟件代碼（code） ：一切都是 Hard Code ，輸出或輸入的相關(guān)參數(shù)都直接固定在源代碼中，這不構(gòu)成一個(gè)認(rèn)知架構(gòu)，因?yàn)闆](méi)有 cognitive 的部分；
• LLM Call ，除了一些數(shù)據(jù)預(yù)處理外，單個(gè) LLM 的調(diào)用構(gòu)成了應(yīng)用程序的大部分，簡(jiǎn)單的 Chatbot 屬于這一類；
• Chain：一系列 LLM 調(diào)用，Chain 嘗試將問(wèn)題的解決分成若干步，調(diào)用不同的 LLM 解決問(wèn)題。復(fù)雜的 RAG 屬于這一種：調(diào)用第一個(gè) LLM 用來(lái)搜索、查詢，調(diào)用第二個(gè) LLM 用于生成答案；
• Router：在前面的三種系統(tǒng)中，用戶可以提前知道程序會(huì)采取的所有步驟，但在 Router 中，LLM 自行決定調(diào)用哪些 LLM ，采取怎樣的步驟，這增加了更多的隨機(jī)性和不可預(yù)測(cè)性；
• State Machine ，將 LLM 與 Router 結(jié)合使用，這將更加不可預(yù)測(cè)，因?yàn)檫@樣結(jié)合放入循環(huán)中，系統(tǒng)可以（理論上）做無(wú)限次的 LLM 調(diào)用；
• Agentic 的系統(tǒng)：大家也會(huì)稱為“ Autonomous Agent ”，使用 State Machine 時(shí)，對(duì)于可以采取哪些操作以及在執(zhí)行該操作后執(zhí)行哪些流程仍然存在限制；但當(dāng)使用 Autonomous Agent 時(shí)，這些限制將被刪除。LLM 來(lái)決定采取哪些步驟、怎樣去編排不同的 LLM ，這可以通過(guò)使用不同的 Prompt 、工具或代碼來(lái)完成。

簡(jiǎn)單來(lái)說(shuō)，一個(gè)系統(tǒng)越是“ Agentic ”，LLM 就越大程度地決定系統(tǒng)的行為方式。

Agent 的關(guān)鍵要素

規(guī)劃

Agent 可靠性是一個(gè)很大的痛點(diǎn)。常常會(huì)有公司使用 LLM 構(gòu)建了 Agent，卻提到 Agent 無(wú)法很好地規(guī)劃和推理。這里的規(guī)劃和推理是什么意思呢？

Agent的計(jì)劃和推理指的是 LLM 思考要采取什么行動(dòng)的能力。這涉及短期和長(zhǎng)期 reasoning ，LLM 評(píng)估所有可用信息，然后決定：我需要采取哪些一系列步驟，哪些是我現(xiàn)在應(yīng)該采取的第一個(gè)步驟？

很多時(shí)候開(kāi)發(fā)者使用 Function calling（函數(shù)調(diào)用）來(lái)讓 LLM 選擇要執(zhí)行的操作。Function calling 是 OpenAI 于 2023 年 6 月首次添加到 LLM api 的能力，通過(guò) Function calling ，用戶可以為不同的函數(shù)提供 JSON 結(jié)構(gòu)，并讓 LLM 匹配其中一個(gè)（或多個(gè)）結(jié)構(gòu)。

要成功完成一項(xiàng)復(fù)雜的任務(wù)，系統(tǒng)需要按順序采取一系列行動(dòng)。這種長(zhǎng)期規(guī)劃和推理對(duì)于 LLM 非常復(fù)雜：首先 LLM 必須考慮一個(gè)長(zhǎng)期的行動(dòng)規(guī)劃，再回到要采取的短期行動(dòng)中；其次，隨著 Agent 執(zhí)行越來(lái)越多的操作，操作的結(jié)果將反饋給 LLM ，導(dǎo)致上下文窗口增長(zhǎng)，這可能會(huì)導(dǎo)致 LLM “分心”并表現(xiàn)不佳。

改進(jìn)規(guī)劃的最容易解決的辦法是確保 LLM 擁有適當(dāng)推理/計(jì)劃所需的所有信息。盡管這聽(tīng)起來(lái)很簡(jiǎn)單，但通常傳遞給 LLM 的信息根本不足以讓 LLM 做出合理的決定，添加檢索步驟或闡明 Prompt 可能是一種簡(jiǎn)單的改進(jìn)。

之后，可以考慮更改應(yīng)用程序的認(rèn)知架構(gòu)。這里有兩類認(rèn)知架構(gòu)來(lái)改進(jìn)推理，通用認(rèn)知架構(gòu)和特定領(lǐng)域的認(rèn)知架構(gòu)：

1）通用認(rèn)知架構(gòu)

通用認(rèn)知架構(gòu)可以應(yīng)用于任何任務(wù)。這里有兩篇論文提出了兩種通用的架構(gòu)，一個(gè)是 “plan and solve” 架構(gòu)，在 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models 一文中提出，在該架構(gòu)中，Agent 首先提出一個(gè)計(jì)劃，然后執(zhí)行該計(jì)劃中的每個(gè)步驟。另一種通用架構(gòu)是 Reflexion 架構(gòu)，這一架構(gòu)在 Reflexion: Language Agents with Verbal Reinforcement Learning 中提出，在該架構(gòu)中，Agent 執(zhí)行任務(wù)后有一個(gè)明確的 “反射” 步驟，以反映它是否正確執(zhí)行了該任務(wù)。這里不贅述，詳細(xì)可看上兩篇論文。

盡管這些想法顯示出改進(jìn)，但它們通常過(guò)于籠統(tǒng)，無(wú)法被 Agent 在生產(chǎn)中實(shí)際使用。（譯者注：這篇文章發(fā)布時(shí)還沒(méi)有 o1 系列模型）

2）特定領(lǐng)域的認(rèn)知架構(gòu)

相反，我們看到 Agent 是使用特定領(lǐng)域的認(rèn)知架構(gòu)構(gòu)建的。這通常表現(xiàn)在特定領(lǐng)域的分類/規(guī)劃步驟、特定領(lǐng)域的驗(yàn)證步驟中。規(guī)劃和反思的一些思想可以在這里應(yīng)用，但它們通常以特定領(lǐng)域的方式應(yīng)用。

AlphaCodium 的一篇論文中舉了一個(gè)特定的例子：通過(guò)使用他們所謂的 “流工程”（另一種談?wù)撜J(rèn)知架構(gòu)的方式）實(shí)現(xiàn)了最先進(jìn)的性能。

可以看到 Agent 的流程對(duì)于他們?cè)噲D解決的問(wèn)題非常具體。他們告訴 Agent 分步驟做什么：提出測(cè)試，然后提出解決方案，然后迭代更多測(cè)試等。這種認(rèn)知架構(gòu)是高度專注特定領(lǐng)域的，不能泛化到其他領(lǐng)域。

Case Study:

Reflection AI 創(chuàng)始人  Laskin 對(duì) Agent 未來(lái)的愿景

在紅杉資本對(duì) Reflection AI 創(chuàng)始人 Misha Laskin 的訪談中，Misha 提到他正在開(kāi)始實(shí)現(xiàn)他的愿景：即通過(guò)將 RL 的 Search Capability 與 LLM 相結(jié)合，在他的新公司 Reflection AI 中構(gòu)建最佳的 Agent 模型。他和聯(lián)合創(chuàng)始人 Ioannis Antonoglou（AlphaGo、AlphaZero 、Gemini RLHF 負(fù)責(zé)人）正在訓(xùn)練為 Agentic Workflows 設(shè)計(jì)的模型，訪談中的主要觀點(diǎn)如下：

? 深度是 AI Agent 中缺失的部分。 雖然當(dāng)前的語(yǔ)言模型在廣度方面表現(xiàn)出色，但它們?nèi)狈煽客瓿扇蝿?wù)所需的深度。Laskin 認(rèn)為，解決“深度問(wèn)題”對(duì)于創(chuàng)建真正有能力的 AI Agent 至關(guān)重要，這里的能力是指：Agent 可以通過(guò)多個(gè)步驟規(guī)劃和執(zhí)行復(fù)雜的任務(wù)；

? 將 Learn 和 Search 相結(jié)合是實(shí)現(xiàn)超人性能的關(guān)鍵。 借鑒 AlphaGo 的成功，Laskin 強(qiáng)調(diào) AI 中最深刻的理念是 Learn（依靠 LLM）和 Search（找到最優(yōu)路徑）的結(jié)合。這種方法對(duì)于創(chuàng)建在復(fù)雜任務(wù)中可以勝過(guò)人類的 Agent 至關(guān)重要；

? Post-training 和 Reward modeling 帶來(lái)了重大挑戰(zhàn)。 與具有明確獎(jiǎng)勵(lì)的游戲不同，現(xiàn)實(shí)世界的任務(wù)通常缺乏真實(shí)獎(jiǎng)勵(lì)。開(kāi)發(fā)可靠的 reward model，是創(chuàng)建可靠的 AI Agent 的關(guān)鍵挑戰(zhàn)

? Universal Agents 可能比我們想象的更接近。 Laskin 估計(jì)，我們可能只用三年時(shí)間就可以實(shí)現(xiàn)“digital AGI”，即同時(shí)具有廣度和深度的 AI 系統(tǒng)。這一加速的時(shí)間表凸顯了在能力發(fā)展的同時(shí)解決安全性和可靠性問(wèn)題的緊迫性

? 通往 Universal Agents 的道路需要一種的方法。 Reflection AI 專注于擴(kuò)展 Agent 功能，從一些特定的環(huán)境開(kāi)始，如瀏覽器、coding 和計(jì)算機(jī)操作系統(tǒng)。他們的目標(biāo)是開(kāi)發(fā) Universal Agents ，使其不局限于特定任務(wù)。

UI/UX 交互

在未來(lái)幾年，人機(jī)交互會(huì)成為 research 的一個(gè)關(guān)鍵領(lǐng)域：Agent 系統(tǒng)與過(guò)去的傳統(tǒng)計(jì)算機(jī)系統(tǒng)不同，因?yàn)檠舆t、不可靠性和自然語(yǔ)言界面帶來(lái)了新的挑戰(zhàn)。因此，與這些 Agent 應(yīng)用程序交互的新 UI/UX 范式將出現(xiàn)。Agent 系統(tǒng)仍處于早期階段，但已經(jīng)出現(xiàn)多種新興的 UX 范式。下面分別進(jìn)行討論：

1）對(duì)話式交互 (Chat UI)

聊天一般分為兩種：流式聊天（streaming chat）、非流式聊天（non-streaming Chat）。

流式聊天是目前最常見(jiàn)的 UX。它是一個(gè) Chatbot，以聊天格式將其思想和行為流回——ChatGPT 是最受歡迎的例子。這種交互模式看起來(lái)很簡(jiǎn)單，但也有不錯(cuò)的效果，因?yàn)椋浩湟?，可以使用自然語(yǔ)言與 LLM 進(jìn)行對(duì)話，這意味著客戶和 LLM 沒(méi)有任何障礙；其二，LLM 可能需要一段時(shí)間才能工作，流式處理使用戶能夠準(zhǔn)確了解后臺(tái)發(fā)生的事情；其三，LLM 常常會(huì)出錯(cuò)，Chat 提供了一個(gè)很好的界面來(lái)自然地糾正和指導(dǎo)它，大家已經(jīng)非常習(xí)慣于在聊天中進(jìn)行后續(xù)對(duì)話和迭代討論事情。

但流式聊天也有其缺點(diǎn)。首先，流式聊天是一種相對(duì)較新的用戶體驗(yàn)，因此我們現(xiàn)有的聊天平臺(tái)（iMessage、Facebook Messenger、Slack 等）沒(méi)有這種方式；其次，對(duì)于運(yùn)行時(shí)間較長(zhǎng)的任務(wù)來(lái)說(shuō)，這有點(diǎn)尷尬—用戶只是要坐在那里看著 Agent 工作嗎；第三，流式聊天通常需要由人類觸發(fā)，這意味著還需要大量 human in the loop。

非流式聊天的最大區(qū)別在于響應(yīng)是分批返回的， LLM 在后臺(tái)工作，用戶并不急于讓 LLM 立刻回答，這意味著它可能更容易集成到現(xiàn)有的工作流程中。人們已經(jīng)習(xí)慣了給人類發(fā)短信——為什么他們不能適應(yīng)用 AI 發(fā)短信呢？非流式聊天將使得與更復(fù)雜的 Agent 系統(tǒng)交互變得更加容易—這些系統(tǒng)通常需要一段時(shí)間，如果期望即時(shí)響應(yīng)，這可能會(huì)令人沮喪。非流式聊天通常會(huì)消除這種期望，從而更輕松地執(zhí)行更復(fù)雜的事情。

這兩種聊天方式有以下優(yōu)缺點(diǎn)：

2）后臺(tái)環(huán)境 (Ambient UX)

用戶會(huì)考慮向 AI 發(fā)送消息，這是上面談到的 Chat，但如果 Agent 只是在后臺(tái)工作，那我們?cè)撊绾闻c Agent 交互呢？

為了讓 Agent 系統(tǒng)真正發(fā)揮其潛力，就需要有這種允許 AI 在后臺(tái)工作的轉(zhuǎn)變。當(dāng)任務(wù)在后臺(tái)處理時(shí)，用戶通常更能容忍更長(zhǎng)的完成時(shí)間（因?yàn)樗麄兎艑捔藢?duì)低延遲的期望）。這使 Agent 可以騰出時(shí)間做更多的工作，通常比在聊天 UX 中更仔細(xì)、勤奮做更多推理。

此外，在后臺(tái)運(yùn)行 Agent 能擴(kuò)展我們?nèi)祟愑脩舻哪芰ΑＡ奶旖缑嫱ǔＯ拗莆覀円淮沃荒軋?zhí)行一項(xiàng)任務(wù)。但是，如果 Agent 在后臺(tái)環(huán)境運(yùn)行，則可能會(huì)有許多 Agent 同時(shí)處理多個(gè)任務(wù)。

讓 Agent 在后臺(tái)運(yùn)行，是需要用戶信任的，該如何建立這種信任？一個(gè)簡(jiǎn)單的想法是：向用戶準(zhǔn)確展示 Agent 在做什么。顯示它正在執(zhí)行的所有步驟，并讓用戶觀察正在發(fā)生的事情。雖然這些步驟可能不會(huì)立即可見(jiàn)（就像在流式傳輸響應(yīng)時(shí)一樣），但它應(yīng)該可供用戶點(diǎn)擊并觀察。下一步是不僅讓用戶看到發(fā)生了什么，還讓他們糾正 Agent 。如果他們發(fā)現(xiàn) Agent 在第 4 步（共 10 步）中做出了錯(cuò)誤的選擇，客戶可以選擇返回第 4 步并以某種方式更正 Agent 。

這種方法將用戶從 “In-the-loop” 轉(zhuǎn)變?yōu)?“On-the-loop”?！癘n-the-loop”要求能夠向用戶顯示 Agent 執(zhí)行的所有中間步驟，允許用戶中途暫停工作流，提供反饋，然后讓 Agent 繼續(xù)。

AI 軟件工程師 Devin 是實(shí)現(xiàn)類似 UX 的一個(gè)應(yīng)用程序。Devin 運(yùn)行時(shí)間較長(zhǎng)，但客戶可以看到所采取的所有步驟，倒回特定時(shí)間點(diǎn)的開(kāi)發(fā)狀態(tài)，并從那里發(fā)布更正。盡管 Agent 可能在后臺(tái)運(yùn)行，但這并不意味著它需要完全自主地執(zhí)行任務(wù)。有時(shí) Agent 不知道該做什么或如何回答，這時(shí)，它需要引起人類的注意并尋求幫助。

一個(gè)具體的例子是 Harrison 正在構(gòu)建的電子郵件助理 Agent 。雖然電子郵件助理可以回復(fù)基本電子郵件，但它通常需要 Harrison 輸入某些不想自動(dòng)化的任務(wù)，包括：審查復(fù)雜的 LangChain 錯(cuò)誤報(bào)告、決定是否要參加會(huì)議等。在這種情況下，電子郵件助理需要一種方法來(lái)向 Harrison 傳達(dá)它需要信息來(lái)響應(yīng)。請(qǐng)注意，它不是要求其直接回答；相反，它會(huì)征求 Harrison 對(duì)某些任務(wù)的意見(jiàn)，然后它可以使用這些任務(wù)來(lái)制作和發(fā)送一封漂亮的電子郵件或安排日歷邀請(qǐng)。

目前，Harrison 在 Slack 中設(shè)置了這個(gè)助手。它向 Harrison 發(fā)送一個(gè)問(wèn)題，Harrison 在 Dashboard 中回答它，與其工作流程原生集成。這種類型的 UX類似于客戶支持 Dashboard 的 UX。此界面將顯示助手需要人工幫助的所有區(qū)域、請(qǐng)求的優(yōu)先級(jí)以及任何其他數(shù)據(jù)。

3）電子表格 (Spreadsheet UX)

電子表格 UX 是一種支持批量處理工作的超級(jí)直觀且用戶友好的方式。每個(gè)表格、甚至每一列都成為自己的 Agent，去研究特定的東西。這種批量處理允許用戶擴(kuò)展與多個(gè) Agent 交互。

這種 UX 還有其他好處。電子表格格式是大多數(shù)用戶都熟悉的 UX，因此它非常適合現(xiàn)有的工作流程。這種類型的 UX 非常適合數(shù)據(jù)擴(kuò)充，這是一種常見(jiàn)的 LLM 用例，其中每列可以表示要擴(kuò)充的不同屬性。

Exa AI、Clay AI、Manaflow 等公司的產(chǎn)品都在使用這種 UX，下以 Manaflow舉例展示這種電子表格 UX 如何處理工作流程。

Case Study:

Manaflow 如何使用電子表格進(jìn)行 Agent 交互

Manaflow 的靈感來(lái)源于創(chuàng)始人 Lawrence 曾任職的公司 Minion AI，Minion AI 構(gòu)建的產(chǎn)品是 Web Agent 。Web Agent 可以控制本地的 Geogle Chrome，允許其與應(yīng)用程序交互，例如訂機(jī)票、發(fā)送電子郵件、安排洗車等。基于Minion AI 的靈感，Manaflow 選擇讓 Agent 去操作電子表格類的工具，這是因?yàn)?Agent 不擅長(zhǎng)處理人類的 UI 界面，Agent 真正擅長(zhǎng)的是 Coding。因此 Manaflow 讓 Agent 去調(diào)用 UI 界面的的 Python 腳本，數(shù)據(jù)庫(kù)接口，鏈接API，然后直接對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作：包括閱讀時(shí)間、預(yù)定、發(fā)郵件等等。

其工作流如下：Manaflow 的主要界面是一個(gè)電子表格（Manasheet），其中每列代表工作流程中的一個(gè)步驟，每行對(duì)應(yīng)于執(zhí)行任務(wù)的 AI Agent。每個(gè)電子表格的 workflow 都可以使用自然語(yǔ)言進(jìn)行編程（允許非技術(shù)用戶用自然語(yǔ)言描述任務(wù)和步驟）。每個(gè)電子表格都有一個(gè)內(nèi)部依賴關(guān)系圖，用于確定每列的執(zhí)行順序。這些順序會(huì)分配給每一行的 Agent 并行執(zhí)行任務(wù)，處理數(shù)據(jù)轉(zhuǎn)換、API 調(diào)用、內(nèi)容檢索和發(fā)送消息等流程：

生成 Manasheet 可以的方法為：輸入類似上面紅色框里的自然語(yǔ)言，如上圖中想向客戶可以發(fā)送定價(jià)的郵件，就可以通過(guò) Chat 輸入 Prompt，來(lái)生成 Manasheet。通過(guò) Manasheet 可以看到有客戶的姓名，客戶的郵箱，客戶所屬的行業(yè)，是否已經(jīng)發(fā)送郵件等信息；點(diǎn)擊 Execute Manasheet 即可執(zhí)行任務(wù)。

4）生成式 UI (Generative UI)

“生成式 UI”有兩種不同的實(shí)現(xiàn)方式。

一種方式是由模型自行生成需要的的原始組件。這類似于 Websim 等產(chǎn)品。在后臺(tái)，Agent 主要編寫原始 HTML，使其能夠完全控制顯示的內(nèi)容。但是這種方法允許生成的 web app 質(zhì)量有很高的不確定性，因此最終結(jié)果可能看起來(lái)波動(dòng)較大。

另一種更受約束的方法為：預(yù)定義一些 UI 組件，這通常是通過(guò)工具調(diào)用來(lái)完成的。例如，如果 LLM 調(diào)用天氣 API，則它會(huì)觸發(fā)天氣地圖 UI 組件的渲染。由于渲染的組件不是真正生成的（但是有更多選擇），因此生成的 UI 將更加精致，盡管它可以生成的內(nèi)容不完全靈活。

Case Study：

Personal AI 產(chǎn)品 dot

舉例來(lái)說(shuō)，在 2024 年曾被稱為最好的 Personal AI 產(chǎn)品的 Dot，就是一個(gè)很好的生成式 UI 產(chǎn)品。

Dot 是 New Computer 公司的產(chǎn)品：其目標(biāo)是成為用戶的長(zhǎng)期伴侶，而并不是更好的任務(wù)管理工具，據(jù)聯(lián)合創(chuàng)始人Jason Yuan講，Dot 的感覺(jué)是，當(dāng)你不知道該去哪里、該做什么或該說(shuō)什么時(shí)，你就會(huì)求助于 Dot。這里舉兩個(gè)例子介紹產(chǎn)品是做什么的：

? 創(chuàng)始人 Jason Yuan 常常在深夜讓 Dot 推薦酒吧，說(shuō)自己想要一醉方休，斷斷續(xù)續(xù)幾個(gè)月，某天下班之后，Yuan 再次問(wèn)了相似的問(wèn)題，Dot 竟然開(kāi)始勸解 Jason，不能再這樣下去了；

? Fast Company 記者 Mark Wilson，也和 Dot 相處了幾個(gè)月的時(shí)間。有一次，他向 Dot 分享了書(shū)法課上他手寫的一個(gè)「O」，Dot 竟然調(diào)出了幾周前他手寫「O」的照片，夸他的書(shū)法水平提高了。

? 隨著使用Dot的時(shí)間越來(lái)越多，Dot 更加理解了用戶喜歡打卡咖啡館，主動(dòng)推送給主人附近的好咖啡館，附上了為何這個(gè)咖啡館好，最后還貼心的詢問(wèn)是否要導(dǎo)航.

可以看到在這個(gè)咖啡館推薦的例子中，Dot 通過(guò)預(yù)定義 UI 組件，來(lái)達(dá)到 LLM-native 的交互效果。

5）協(xié)作式 UX（Collaborative UX）

當(dāng) Agent 和人類一起工作時(shí)會(huì)發(fā)生什么？想想 Google Docs，客戶可以在其中與團(tuán)隊(duì)成員協(xié)作編寫或編輯文檔，但倘如協(xié)作者之一是 Agent 呢？

Geoffrey Litt 和 Ink & Switch 合作的 Patchwork項(xiàng)目是人類- Agent 合作的一個(gè)很好的例子。（譯者注：這可能是最近 OpenAI Canvas 產(chǎn)品更新的靈感來(lái)源）。

協(xié)作式 UX 與前面討論的 Ambient UX 相比如何？LangChain創(chuàng)始工程師 Nuno 強(qiáng)調(diào)了兩者之間的主要區(qū)別，在于是否有并發(fā)性：

• 在協(xié)作式 UX 中，客戶和LLM 經(jīng)常同時(shí)工作，以彼此的工作為輸入；
• 在環(huán)境 UX 中，LLM 在后臺(tái)持續(xù)工作，而用戶則完全專注于其他事情。

記憶

記憶對(duì)于好的 Agent 體驗(yàn)至關(guān)重要。想象一下如果你有一個(gè)同事從來(lái)不記得你告訴他們什么，強(qiáng)迫你不斷重復(fù)這些信息，這個(gè)協(xié)作體驗(yàn)會(huì)非常差。人們通常期望 LLM 系統(tǒng)天生就有記憶，這可能是因?yàn)?LLM 感覺(jué)已經(jīng)很像人類了。但是，LLM 本身并不能記住任何事物。

Agent 的記憶是基于產(chǎn)品本身需要的，而且不同的 UX 提供了不同的方法來(lái)收集信息和更新反饋。我們能從 Agent 產(chǎn)品的記憶機(jī)制中看到不同的高級(jí)記憶類型——它們?cè)谀７氯祟惖挠洃涱愋汀?/p>

論文 CoALA: Cognitive Architectures for Language Agents 將人類的記憶類型映射到了 Agent 記憶上，分類方式如下圖的所示：

1）程序記憶（Procedural Memory）：有關(guān)如何執(zhí)行任務(wù)的長(zhǎng)期記憶，類似于大腦的核心指令集

? 人類的程序記憶：記住如何騎自行車。

? Agent 的程序記憶：CoALA 論文將程序記憶描述為 LLM 權(quán)重和 Agent 代碼的組合，它們從根本上決定了 Agent 的工作方式。

在實(shí)踐中，Langchain 團(tuán)隊(duì)還沒(méi)有看到任何 Agent 系統(tǒng)會(huì)自動(dòng)更新其 LLM 或重寫其代碼，但是確實(shí)存在一些 Agent 更新其 system prompt 的例子。

2）語(yǔ)義記憶(Semantic Memory): 長(zhǎng)期知識(shí)儲(chǔ)備

? 人類的語(yǔ)義記憶：它由信息片段組成，例如在學(xué)校學(xué)到的事實(shí)、概念以及它們之間的關(guān)系。

? Agent 的語(yǔ)義記憶：CoALA 論文將語(yǔ)義記憶描述為事實(shí)存儲(chǔ)庫(kù)。

在實(shí)踐中上，常常是通過(guò)使用 LLM 從 Agent 的對(duì)話或交互中提取信息來(lái)實(shí)現(xiàn)的。此信息的確切存儲(chǔ)方式通常是特定于應(yīng)用程序的。然后這些信息在將來(lái)的對(duì)話中檢索并插入到 System Prompt 中 以影響 Agent 的響應(yīng)。

3）情景記憶（Episodic Memory）：回憶特定的過(guò)去事件

? 人類的情景記憶：當(dāng)一個(gè)人回憶起過(guò)去經(jīng)歷的特定事件（或“情節(jié)”）時(shí)。

? Agent 中的情景記憶：CoALA 論文將情景記憶定義為存儲(chǔ) Agent 過(guò)去動(dòng)作的序列。

這主要用于讓 Agent 按預(yù)期執(zhí)行動(dòng)作。在實(shí)踐中，情景記憶的更新通過(guò) Few-Shots Prompt 的方法實(shí)現(xiàn)。如果相關(guān)更新的 Few-Shots Prompt 足夠多，那么接下來(lái)的更新就通過(guò) Dynamic Few-Shots Prompt 來(lái)完成。

如果一開(kāi)始就有指導(dǎo) Agent 正確完成操作的辦法，后面面對(duì)同樣的問(wèn)題就可以直接使用這種辦法；相反，如果不存在正確的操作方式，或者如果 Agent 不斷做新的事情，那么語(yǔ)義記憶就會(huì)更重要，反而在前面的例子中，語(yǔ)義記憶不會(huì)有太大幫助。

除了考慮要在 Agent 中更新的記憶類型外，開(kāi)發(fā)人員還要考慮如何更新 Agent 的記憶：

更新 Agent 記憶的第一種方法是 “in the hot path”。在這種情況下， Agent 系統(tǒng)會(huì)在響應(yīng)之前記住事實(shí)（通常通過(guò)工具調(diào)用）， ChatGPT 采取這種方法更新其記憶；

更新 Agent 記憶的另一種方法是 “in the background” 。在這種情況下，后臺(tái)進(jìn)程會(huì)在會(huì)話之后運(yùn)行以更新記憶。

比較這兩種方法，“in the hot path” 方法的缺點(diǎn)是在傳遞任何響應(yīng)之前會(huì)有一些延遲，它還需要將 memory logic 與 agent logic 相結(jié)合。

但是， “in the background ”可以避免這些問(wèn)題 – 不會(huì)增加延遲，并且 memory logic 保持獨(dú)立。但是“in the background ”也有其自身的缺點(diǎn)：記憶不會(huì)立即更新，并且需要額外的 logic 來(lái)確定何時(shí)啟動(dòng)后臺(tái)進(jìn)程。

更新記憶的另一種方法涉及用戶反饋，這與情景記憶特別相關(guān)。例如，如果用戶對(duì)某次交互標(biāo)評(píng)分較高（Postive Feedback），Agent 可以保存該反饋以備將來(lái)調(diào)用。

基于以上編譯內(nèi)容，我們期待規(guī)劃、交互、記憶三個(gè)組件的同時(shí)進(jìn)步，會(huì)讓我們?cè)?2025 年看到更多可用的 AI Agent，進(jìn)入人機(jī)協(xié)同工作的新時(shí)代。

Reference

https://www.langchain.com/stateofaiagents

https://blog.langchain.dev/tag/in-the-loop/

https://www.sequoiacap.com/podcast/training-data-misha-laskin/

https://www.youtube.com/watch?v=pBBe1pk8hf4

https://www.qodo.ai/products/alpha-codium/?ref=blog.langchain.dev

https://news.ycombinator.com/item?id=41259754

https://arxiv.org/pdf/2309.02427

https://github.com/mem0ai/mem0