我们一直在关注AI Agent的重大变化,Langchain的一系列文章为我们理解Agent的发展趋势提供了很大帮助。在这篇文章中,第一部分是Langchain团队发布的关于AI Agent现状的报告。他们采访了1300多位从业者,包括开发者、产品经理和公司高管,揭示了今年AI Agent的现状以及面临的挑战:90%的公司都有AI Agent的计划和需求,但目前Agent的能力有限,用户只能在少数流程和场景中应用。与成本和延迟相比,大家更关注Agent能力的提升,以及对其行为的可观测性和可控性。
第二部分是我们对LangChain官网“In the Loop”系列文章中关于AI Agent关键要素的分析的编译:规划能力、UI/UX交互创新和记忆机制。文中分析了5种以大型语言模型为基础的产品的交互方式,并类比了3种复杂的人类记忆机制,这对理解AI Agent和这些关键要素都有启发。在这一部分,我们还加入了一些有代表性的Agent公司的案例研究,比如Reflection AI创始人的访谈,以展望2025年AI Agent的关键突破点。
在这个分析框架下,我们预计到2025年,AI Agent应用将开始大量涌现,开启人机协作的新纪元。当前,以o3为代表的模型在规划能力上表现出色,展现了强大的反思和推理能力。模型公司正在从仅仅是推理器(reasoner)逐步向 Agent(Agent)阶段迈进。随着推理能力的不断提升, Agent的“最后一公里”将集中在产品的交互方式和记忆机制上,这可能是创业公司实现突破的关键所在。关于交互,我们一直期待AI时代能迎来类似“图形用户界面(GUI)”的革命性时刻;关于记忆,我们相信上下文(Context)将成为 Agent落地的重要关键词。无论是个人层面的上下文个性化,还是企业层面的上下文统一,都将极大地提升 Agent的产品体验。
💡目录 💡
01 AI Agent的现状
02 AI Agent的核心要素
01.
AI Agent的现状
** Agent使用趋势:**
每家公司都在计划部署 Agent
AI Agent领域的竞争日益激烈。在过去的一年中,许多 Agent框架变得越来越普及。例如,使用ReAct结合大型语言模型(LLM)进行推理和行动,使用多 Agent(multi-agent)框架进行任务编排,或是使用类似LangGraph这样更具控制力的框架。
关于Agent的讨论不仅仅是Twitter上的热点话题。调查显示,大约51%的受访者已经在实际工作中使用了Agent。根据Langchain提供的数据显示,员工人数在100到2000之间的中型公司在采用Agent方面最为积极,达到了63%的使用率。
此外,有78%的受访者计划在不久的将来开始使用Agent。这表明大家对AI Agent的兴趣非常浓厚,但要真正打造一个可以投入生产使用的Agent,仍然是许多人面临的挑战。

尽管技术行业通常被认为是Agent的早期使用者,但实际上,各行各业对Agent的兴趣都在不断增加。在非技术公司的受访者中,有90%已经在使用或计划使用Agent(这一比例与技术公司几乎相同,为89%)。
Agent的常见应用场景
Agent最常见的应用场景包括进行研究和总结(58%),其次是通过定制化的Agent简化工作流程(53.5%)。
这些数据反映了人们希望有工具来处理那些耗时的任务。用户可以依赖AI Agent从大量信息中提取重要信息和见解,而不必自己去筛选和分析数据。同样,AI Agent可以通过协助完成日常任务来提高个人效率,让用户能够专注于更重要的事情。
无论是个人还是企业,大家都需要提高工作效率。客服领域是Agent应用的一个重要方向,占比达到了45.8%。Agent可以帮助公司处理客户咨询、解决问题,并加快跨团队的响应速度。此外,Agent在代码和数据处理方面的应用也很受关注,分别排在第四和第五位。

监控:Agent应用需要被观察和控制
随着Agent功能的不断增强,如何管理和监控这些Agent变得尤为重要。追踪和观察工具是必不可少的,它们帮助开发者了解Agent的行为和性能。许多公司还使用“防护栏”来确保Agent不会偏离预期的轨道。

在测试大型语言模型(LLM)应用时,离线评估(39.8%)比在线评估(32.5%)更常被使用,这说明实时监控LLM存在一定的挑战。在LangChain的开放回答中,很多公司还安排人类专家手动检查或评估Agent的响应,以增加一层安全保障。
虽然大家对Agent充满热情,但在赋予Agent权限方面仍然比较谨慎。很少有公司允许Agent自由地读取、写入或删除数据。大多数团队只给予Agent读取权限,或者在进行写入或删除等高风险操作时,需要获得人类的批准。

不同规模的公司在管理Agent时有着不同的优先考虑因素。对于大型企业(员工超过2000人),他们更加谨慎,主要依赖“只读”权限来降低风险。这些企业通常会将防护措施和离线评估结合使用,以确保客户不会遇到任何问题。

另一方面,小型公司和初创企业(员工少于100人)则更注重监控,以便了解其Agent应用程序的运行情况,而不是过多地设置其他控制措施。根据LangChain的调查,小型公司倾向于通过查看数据来理解结果;而大企业则在各个方面设置了更多的控制。

将Agent投入使用的障碍和挑战
确保大型语言模型(LLM)的高质量表现并不容易。回答需要非常准确,并且符合正确的风格。这是Agent开发者最关心的问题,甚至比成本和安全等其他因素重要两倍多。
LLM Agent的输出是基于概率的,这意味着结果可能会有很大的不确定性。这增加了出错的可能性,使团队难以确保其Agent始终提供准确且符合上下文的回答。

对于小型公司来说,性能质量是他们最关心的问题,远远超过其他因素。调查显示,有45.8%的小型公司将性能质量视为首要任务,而关注成本的公司只有22.4%。这表明,对于这些公司来说,可靠和高质量的性能在将Agent从开发阶段转移到实际应用中是至关重要的。
对于大型公司来说,安全性是一个普遍关注的问题,尤其是那些需要严格遵守法规并敏感处理客户数据的公司。

然而,挑战不仅仅局限于性能质量。根据LangChain提供的开放式反馈,很多人对公司是否应该继续投资于Agent的开发和测试持怀疑态度。主要有两个原因:一是开发Agent需要大量的专业知识,并且需要不断跟进最新技术;二是开发和部署Agent需要耗费大量时间,而其能否稳定运行带来的收益尚不明确。
其他新兴话题
在开放性问题中,人们对AI Agent展现的能力给予了很多赞赏:
- 管理多步骤任务:AI Agent能够进行更深入的推理和上下文管理,这让它们可以处理更复杂的任务。
- 自动化重复性任务:AI Agent被视为自动化任务的关键工具,可以为用户节省时间,让他们专注于更具创造性的工作。
- 任务规划和协作:更好的任务规划确保了合适的Agent在合适的时间处理合适的问题,尤其是在多Agent系统中。
- 类似人类的推理:与传统的大型语言模型不同,AI Agent可以追溯其决策过程,包括根据新信息回顾和修改过去的决策。
除了已经取得的进展外,大家对未来还有两个最期待的方向:
在问答环节中,不少人提到了开发AI Agent时面临的最大挑战:理解 Agent的行为。一些工程师表示,他们在向公司利益相关者解释AI Agent的能力和行为时遇到困难。有时候,使用可视化工具可以帮助解释 Agent的行为,但很多时候,大语言模型(LLM)仍然像个黑箱,给工程团队带来了额外的解释负担。
AI Agent中的核心要素
什么是Agentic系统
在《AI Agent现状》报告发布之前,Langchain团队已经在 Agent领域开发了自己的Langraph框架,并在”In the Loop”博客中讨论了许多AI Agent的关键组件。接下来,我们将对其中一些重要内容进行简要说明。
首先,每个人对AI Agent的定义可能略有不同。LangChain的创始人Harrison Chase给出的定义如下:
💡
AI Agent 是一种使用大型语言模型(LLM)来决定程序执行路径的系统。换句话说,它是一种通过 LLM 来帮助应用程序做出决策的智能系统。
为了更好地理解这种系统的实现方式,文章中引入了“认知架构”的概念。认知架构描述了智能 Agent(Agent)是如何进行思考的,以及系统是如何组织代码和提示LLM的:
下图展示了不同层次的认知架构示例:

• Chain(链条):想象一下,把一个复杂的问题分解成多个简单的小问题,每个小问题交给一个不同的AI模型来解决。比如,先用一个AI模型来查找信息,然后再用另一个AI模型来生成答案。这种方法就像是一个接力赛,把任务分成几步来完成。
• Router(路由器):在某些系统中,我们可以提前知道程序会怎么一步步解决问题。但在“路由器”系统中,AI模型可以自己决定要调用哪些AI模型和采取哪些步骤,这样的系统更有随机性和不可预测性。
• State Machine(状态机):这是把AI模型和路由器结合起来用的系统,因为它可以在一个循环中无限次调用AI模型,所以它的行为更加不可预测。
• Agentic的系统:也被称为“自主 Agent”。在使用状态机时,虽然有些操作和流程是有限制的,但在自主 Agent中,这些限制被去掉了。AI模型可以自由决定采取哪些步骤,并通过不同的提示、工具或代码来安排其他AI模型的工作。简单来说,系统越“自主”,AI模型对系统行为的控制就越大。
Agent的关键要素
规划
Agent的可靠性一直是个大问题。许多公司在使用大型语言模型(LLM)构建Agent时,常常会发现这些Agent在计划和推理方面表现不佳。那么,这里的计划和推理究竟是什么意思呢?
简单来说,Agent的计划和推理就是指LLM在思考该采取哪些行动时的能力。这包括短期和长期的思考过程。LLM会评估所有可用的信息,然后决定:我需要采取哪些步骤?哪个步骤是我现在应该首先进行的?
开发者通常会使用一种叫做函数调用(Function calling)的方法来帮助LLM选择要执行的操作。函数调用是OpenAI在2023年6月首次引入到LLM API中的一项功能。通过函数调用,用户可以为不同的函数提供JSON结构,然后让LLM选择并匹配其中一个或多个结构。
要成功完成一项复杂任务,系统需要按顺序采取多个步骤。这种长期的计划和推理对LLM来说非常复杂:首先,LLM必须制定一个长期的行动计划,然后再回到需要采取的短期行动上;其次,随着Agent执行的操作越来越多,这些操作的结果会反馈给LLM,导致上下文信息越来越多,这可能会让LLM“分心”,从而影响其表现。
要让大语言模型(LLM)更好地进行推理和规划,最简单的方法就是确保它们拥有所有必要的信息。虽然这听起来容易,但实际上,提供给LLM的信息往往不够充分,导致它们无法做出明智的决定。为了解决这个问题,我们可以增加信息检索步骤,或者对提示(Prompt)进行更详细的说明。
接下来,我们可以考虑修改应用程序的认知架构。认知架构分为两种类型:通用认知架构和特定领域认知架构,它们都能帮助提升推理能力。
1. 通用认知架构
这种架构可以用于任何任务。比如,有两篇论文提出了两种通用架构。第一种是“计划与解决”架构(plan and solve),在论文《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》中提出。这个架构的工作原理是,智能体(Agent)先制定一个计划,然后逐步执行计划中的每一步。第二种是Reflexion架构,在论文《Reflexion: Language Agents with Verbal Reinforcement Learning》中介绍。这个架构的特点是,智能体在完成任务后,会有一个明确的“反思”步骤,用于评估自己是否正确完成了任务。具体细节可以参考上述两篇论文。
虽然这些想法展示了一些改进,但它们通常过于笼统,不足以让智能 Agent在实际生产中使用。(译者注:这篇文章发布时还没有 o1 系列模型)
2. 专门领域的认知架构
相反,我们发现智能 Agent是通过专门领域的认知架构来构建的。这通常体现在特定领域的分类、规划步骤,以及验证步骤中。虽然规划和反思的一些理念可以在这里应用,但它们通常是以特定领域的方式来实现的。
在 AlphaCodium 的一篇论文中,有一个具体的例子:他们通过使用所谓的“流工程”(这是一种描述认知架构的方法)达到了最先进的性能。

可以看到,智能 Agent的流程是针对他们试图解决的问题量身定制的。他们指导智能 Agent逐步操作:先设计测试,然后提出解决方案,再进行更多测试的迭代等。这种认知架构是高度专注于特定领域的,无法轻易地应用到其他领域。
案例研究:
Reflection AI 创始人 Laskin 对智能 Agent未来的愿景
IMG_27
在红杉资本对 Reflection AI 创始人 Misha Laskin 的采访中,Misha 谈到了他的新目标:在他的公司 Reflection AI 中,结合强化学习(RL)的搜索能力与大型语言模型(LLM),打造出最优秀的智能 Agent模型。他和他的联合创始人 Ioannis Antonoglou(曾负责 AlphaGo、AlphaZero 和 Gemini RLHF 项目)正在训练专为智能工作流设计的模型。访谈的要点如下:
-
深度是 AI Agent中缺失的关键。 当前的语言模型虽然在广度上表现优异,但在深度上有所欠缺,这使得它们在完成复杂任务时显得力不从心。Laskin 认为,解决这个“深度问题”对创建真正强大的 AI Agent至关重要。这里的“强大”是指 Agent能够规划和执行多步骤的复杂任务。
-
结合学习和搜索是实现卓越性能的关键。 借鉴 AlphaGo 的成功经验,Laskin 强调 AI 中最深刻的理念是将学习(依赖于 LLM)与搜索(找到最佳路径)结合。这种方法对于创建能够在复杂任务中超越人类的智能 Agent至关重要。
-
后期训练和奖励建模面临的挑战。 在游戏中,我们通常知道如何得分,但在现实生活中,我们很难明确知道什么是“好”或“坏”。因此,创建一个能准确判断AI表现的奖励模型,是开发可靠AI助手的关键难题。
-
通用智能 Agent可能比预期更快实现。 根据Laskin的预测,我们可能只需三年就能打造出“数字通用人工智能(AGI)”,这是一种既有广度又有深度的AI系统。这种快速发展的趋势也提醒我们,必须同时解决AI的安全性和可靠性问题。
-
实现通用智能 Agent的路径。 Reflection AI公司正在努力扩展AI的功能,从一些特定的环境开始,比如浏览器、编程和操作系统。他们的目标是开发不局限于特定任务的通用智能 Agent。
用户界面和用户体验的交互
未来几年,人机交互将成为研究的一个重要领域。与传统电脑系统不同,智能 Agent系统因延迟、不可靠性和自然语言界面带来了新的挑战。因此,新的用户界面和用户体验(UI/UX)模式将会出现。虽然智能 Agent系统还处于早期阶段,但已经有多种新的用户体验模式正在兴起。以下是其中的一种:
1. 对话式交互(聊天界面)
这种交互方式类似于我们与朋友聊天,通过对话框与AI交流,简单直观。
聊天方式主要有两种:流式聊天和非流式聊天。
流式聊天是目前最常见的用户体验。它就像一个聊天机器人,以对话的形式实时返回信息。ChatGPT 就是一个流式聊天的热门例子。这种交互方式看起来简单,但效果不错,原因有几个:首先,你可以用自然语言和大语言模型(LLM)对话,就像和人聊天一样,没有障碍;其次,虽然 LLM 处理信息可能需要一些时间,但流式聊天能让你看到后台正在进行的操作;最后,LLM 有时会出错,而聊天界面提供了一个很好的平台,让你可以自然地纠正和引导它,我们已经习惯在聊天中进行后续对话和讨论。
不过,流式聊天也有一些不足之处。首先,这种聊天方式相对较新,所以我们常用的聊天平台(如 iMessage、Facebook Messenger、Slack 等)还没有完全支持这种方式;其次,对于需要较长时间的任务,流式聊天可能会让人觉得尴尬,因为用户需要一直看着系统工作;最后,流式聊天通常需要人来启动,这意味着需要大量的人机互动。
非流式聊天与传统聊天的最大不同在于,它的回复是分批次返回的。也就是说,后台的人工智能模型(LLM)在处理信息时,用户不需要急着等即时答复。这种方式很容易融入到现有的工作流程中。就像我们习惯给朋友发短信一样,为什么不能适应用AI来发短信呢?非流式聊天让我们更轻松地与复杂的智能系统互动,因为这些系统通常需要时间来处理信息。如果我们总是期待立即得到回复,可能会感到沮丧。而非流式聊天则消除了这种即时回复的期待,因此更容易完成复杂的任务。
这两种聊天方式各有优缺点:

2. 后台环境 (Ambient UX)
当用户考虑给AI发消息时,这就是我们之前提到的聊天方式。但如果智能系统是在后台默默工作,我们该如何与它们互动呢?
为了让智能系统真正发挥作用,我们需要让AI在后台工作。这样一来,用户通常能接受任务需要更长时间完成,因为他们不再期待快速的反馈。这让智能系统有更多时间去处理任务,通常比在聊天界面中更细致、更认真地进行推理。
另外,让智能系统在后台运行可以增强我们的能力。聊天界面通常限制我们一次只能做一件事。但如果智能系统在后台运行,可能会有多个智能系统同时处理多个任务。
让一个智能助手(Agent)在后台工作,确实需要用户的信任。那么,如何才能赢得用户的信任呢?一个简单的方法就是让用户清楚地知道这个助手正在做什么。你可以想象一下,这就像是给用户展示一个助手的工作流程图。虽然这些步骤可能不会立刻全部显示出来(就像我们在看流式视频时,内容是逐步加载的),但用户应该能够点击查看每一个步骤的细节。
不仅如此,用户还应该有机会纠正助手的错误。比如,如果用户发现助手在第4步(总共10步)中做错了选择,他们可以选择回到第4步,进行某种形式的修正。
这种方式将用户的角色从“参与其中”转变为“监控全局”。所谓“监控全局”,就是要能够向用户展示助手执行的所有中间步骤,允许用户在中途暂停工作流程,提供反馈,然后再让助手继续工作。
AI软件工程师Devin正在开发一个类似的用户体验应用程序。虽然Devin的程序运行时间较长,但用户可以看到所有的步骤,甚至可以回到某个特定的时间点进行修改。即使助手在后台运行,也不意味着它必须完全自主地完成任务。有时候,助手可能会不知道下一步该怎么做或如何回答问题,这时它就需要提醒人类并寻求帮助。
Harrison 正在开发一个名为 Agent 的电子邮件助手。这个助手虽然能自动回复一些简单的邮件,但在处理复杂任务时,比如查看 LangChain 的错误报告或决定是否参加会议时,还是需要 Harrison 的人工干预。也就是说,邮件助手会向 Harrison 提出问题,征求他的意见,然后根据他的反馈来撰写邮件或安排会议。
目前,Harrison 在 Slack 上设置了这个助手。当助手需要帮助时,会通过问题通知 Harrison,Harrison 则在一个仪表板上进行回复,这个流程与他的日常工作无缝对接。这种用户体验(UX)类似于客户支持仪表板,界面会显示助手需要人工介入的所有任务、任务的优先级以及其他相关信息。

3. 电子表格 (Spreadsheet UX)

电子表格的用户体验(UX)是一种非常直观、易于使用的方式,特别适合批量处理工作。每个表格甚至每一列都可以看作是一个独立的 Agent,专注于研究某个特定问题。这种批量处理方式让用户可以同时与多个 Agent 进行互动。
这种用户体验(UX)设计还有其他好处。电子表格格式是一种大多数人都很熟悉的用户界面,因此它非常适合现有的工作流程。这种类型的用户界面特别适合用于数据扩展,这是一种常见的大型语言模型(LLM)应用场景,其中每一列都可以代表需要扩展的不同属性。
像 Exa AI、Clay AI、Manaflow 等公司都在使用这种用户界面设计。下面以 Manaflow 为例,展示这种电子表格用户界面如何处理工作流程。
案例分析:
Manaflow 如何利用电子表格与智能 Agent进行交互
Manaflow 的灵感来源于其创始人 Lawrence 曾经工作的公司 Minion AI。Minion AI 开发了一款名为 Web Agent 的产品,这款产品可以控制本地的 Google Chrome 浏览器,使其能够与各种应用程序进行交互,比如订机票、发送电子邮件、安排洗车等。受到 Minion AI 的启发,Manaflow 选择让智能 Agent操作类似电子表格的工具,因为智能 Agent在处理人类用户界面方面并不擅长,它们真正擅长的是编程。因此,Manaflow 让智能 Agent通过调用用户界面的 Python 脚本、数据库接口和 API 链接,直接对数据库进行操作,包括查看时间表、预订、发送电子邮件等。
Manaflow 的工作流程是这样的:它的主要界面是一个叫做 Manasheet 的电子表格。在这个表格中,每一列代表一个工作流程的步骤,而每一行则是一个负责执行任务的 AI Agent(Agent)。用户可以用自然语言来编写每个电子表格的工作流程,这样即使是不懂技术的人也能用简单的语言来描述他们的任务和步骤。每个电子表格都有一个内部的依赖关系图,这个图用来决定每一列的执行顺序。然后,这些顺序会被分配给每一行的 AI Agent,AI Agent会并行处理任务,比如数据转换、API 调用、内容检索和发送消息等。

要生成一个 Manasheet,你可以输入类似于上图红色框里的自然语言描述,比如说你想给客户发送一封关于定价的邮件,你就可以通过 Chat 输入提示语(Prompt),来生成相应的 Manasheet。通过这个表格,你可以看到客户的姓名、邮箱、所属行业,以及邮件是否已经发送等信息。只需点击“执行 Manasheet”按钮,就可以开始执行任务了。
4. 生成式 UI (Generative UI)
“生成式 UI”有两种不同的实现方式。
一种方式是让模型自己生成所需的基础组件。这有点像 Websim 等产品的工作方式。在后台,AI Agent主要是编写基础的 HTML 代码,以便完全控制显示内容。然而,这种方法生成的网页应用质量可能会有很大的不确定性,所以最终的结果可能会有较大的变化。

另一种更为简化的方法是:预先定义一些用户界面(UI)组件,通常通过工具来实现。例如,当大型语言模型(LLM)调用天气API时,它会触发天气地图的UI组件显示。因为这些组件不是完全由模型生成的(但有更多选项可供选择),所以生成的UI会更加精美,尽管它的灵活性可能不如完全生成的内容。
案例分析:
个人人工智能产品 Dot
举个例子,2024年被誉为最佳个人AI产品的Dot,就是一个很好的生成式UI产品。
Dot 是由 New Computer 公司推出的,其目标是成为用户的长期伙伴,而不仅仅是一个更好的任务管理工具。根据联合创始人Jason Yuan的说法,Dot 的存在感就像是,当你不知道该去哪里、做什么或说什么时,你会向Dot求助。以下是两个关于这个产品的例子:
• 创始人 Jason Yuan 经常在深夜让 Dot 推荐酒吧,说自己想要一醉方休。经过几个月的互动,有一天他下班后再次提出类似请求,Dot 竟然开始劝他不能再这样下去了;
• Fast Company的记者 Mark Wilson 与 Dot 相处了几个月。有一次,他向 Dot 分享了书法课上他手写的一个「O」,Dot 居然找出了几周前他手写「O」的照片,并夸奖他的书法水平有所提高。
随着你使用Dot的时间越来越长,Dot开始更好地了解你的喜好。比如,如果你喜欢去咖啡馆,Dot会主动为你推荐附近的好咖啡馆,并告诉你为什么这些地方值得一去。最后,它还会贴心地询问你是否需要导航到那里。

在这个咖啡馆推荐的例子中,我们可以看到Dot通过预设的用户界面组件,实现了一种与大型语言模型(LLM)自然互动的效果。
5. 协作式用户体验(Collaborative UX)
想象一下,当一个智能助手和人类一起工作时会是什么样子?就像在Google Docs中,你可以和团队成员一起编写或编辑文档,但如果其中一个协作者是智能助手呢?
Geoffrey Litt与Ink & Switch合作的Patchwork项目就是一个人类与智能助手合作的好例子。(翻译者注:这可能是最近OpenAI Canvas产品更新的灵感来源。)

那么,协作式用户体验与之前提到的环境用户体验有何不同呢?LangChain的首席工程师Nuno指出,主要区别在于是否存在并发性:
记忆
好的Agent体验离不开记忆。想象一下,如果你有个同事总是忘记你告诉他的事情,你就得不停地重复,这样的合作体验会很糟糕。人们通常认为大型语言模型(LLM)系统天生就有记忆,可能是因为它们看起来很像人类。但实际上,LLM本身并不具备记忆功能。
Agent的记忆是根据产品的具体需求设计的,不同的用户体验(UX)会采用不同的方法来收集信息和更新反馈。我们可以从Agent产品的记忆机制中看到模仿人类记忆的不同高级类型。
在论文《CoALA: Cognitive Architectures for Language Agents》中,研究人员将人类的记忆类型映射到Agent的记忆上,分类如下图所示:

**1. 程序记忆(Procedural Memory):**这是关于如何执行任务的长期记忆,就像大脑的核心指令集一样。
在实际应用中,Langchain团队还没有看到任何Agent系统会自动更新其LLM或重写其代码,但确实有一些Agent会更新其系统提示(system prompt)。
2. 语义记忆(Semantic Memory): 长期知识储备
3. 情景记忆(Episodic Memory): 回忆特定的过去事件
-
对于人类来说,情景记忆是指我们回忆过去经历的具体事件,就像重温一段段人生片段。
-
对于智能体来说,情景记忆被CoALA论文描述为记录智能体过去行为的序列。这种记忆主要是为了让智能体按照预期执行任务。在实际应用中,情景记忆的更新是通过一种叫做Few-Shots Prompt的方法来实现的。如果需要更新的Few-Shots Prompt足够多,那么接下来的更新就通过动态Few-Shots Prompt来完成。
假如一开始就有一个方法可以指导智能助手(Agent)正确地完成任务,那么以后再遇到相同的问题时,就可以直接使用这个方法来解决。反之,如果没有一个正确的操作方法,或者智能助手总是尝试新的方法,那么语义记忆就会显得更加重要。不过在前面提到的例子中,语义记忆的作用就不那么显著了。
除了考虑智能助手需要更新哪种类型的记忆,开发人员还需要思考如何更新它的记忆:
更新智能助手记忆的第一种方式叫做 “in the hot path”。在这种情况下,智能助手会在给出回答之前记住一些信息(通常是通过调用工具来实现)。像ChatGPT这样的系统就采用这种方式来更新记忆。
另一种更新记忆的方法是 “in the background”。在这种情况下,后台进程会在对话结束后运行,以便更新记忆。

比较这两种方法,“in the hot path”方法的缺点是会在给出任何回答之前产生一些延迟,而且需要将记忆逻辑和智能助手的逻辑结合在一起。
而“in the background”方法可以避免这些问题——不会增加延迟,并且记忆逻辑保持独立。不过,“in the background”也有自己的缺点:记忆不会立即更新,并且需要额外的逻辑来决定何时启动后台进程。
另一种更新AI记忆的方法是通过用户的反馈,这在处理特定情境的记忆时尤为重要。举个例子,如果用户对某次交互给予了很高的评价(也就是正面反馈),那么AI助手可以将这个反馈保存下来,以便在未来的相关场合中使用。
基于上述内容,我们希望在规划、交互和记忆这三个方面同时取得进展,这将使我们在2025年看到更多实用的AI助手,并进入一个人机协同工作的新时代。
参考资料