2025 AI Agent 落地展望：规划、交互、记忆三大要素解析

在快速发展的人工智能科技领域，AI Agent（人工智能体）正成为备受瞩目的范式变革。 知名 AI 科技评论机构 AI Share 近期深入研究了 AI Agent 的发展趋势，并参考了 Langchain 团队发布的一系列深度文章，希望借此帮助读者更好地理解 Agent 的未来走向。

本文整合了 Langchain 团队发布的 《State of AI Agent》 报告的核心发现，该报告调研了 1300 多位行业从业者，覆盖开发者、产品经理、企业高管等多种角色。调研结果揭示了 2024 年 AI Agent 的发展现状与落地瓶颈： 尽管有九成的公司都对 AI Agent 抱有积极规划和应用需求，但受限于 Agent 当前的能力局限，用户只能在特定的流程和应用场景中部署 Agent。 相比于成本和延迟等因素，大家更关注 Agent 能力的提升，以及对其行为的可观测性和可控性。

此外，本文还编译了 LangChain 官网 In the Loop 系列文章中关于 AI Agent 关键要素的深度分析，重点解读了 规划能力 (Planning)、UI/UX 交互创新和记忆机制 (Memory) 这三大核心要素。 文章深入剖析了 5 种基于大型语言模型 (LLM) 的原生产品交互模式，并类比了人类的三种复杂记忆机制，旨在为读者理解 AI Agent 的本质和关键要素提供有益的启示。 为了更贴近产业实践，本文还在关键要素分析部分，加入了 Reflection AI 创始人的访谈等一手案例，以此展望 2025 年 AI Agent 可能迎来的关键突破。

基于以上分析框架，AI Share 认为 2025 年 AI Agent 应用有望迎来爆发式增长，并逐步迈向人机协作的新范式。 在 AI Agent 的规划能力方面，以 o3 模型为代表的新兴模型展现出强大的反思和推理能力，预示着模型技术的发展正在快速从 Reasoner（推理器）向 Agent 阶段演进。 随着推理能力的持续提升，AI Agent 能否真正实现大规模落地，关键将取决于产品交互和记忆机制的创新，而这也将是创业公司实现差异化突围的重要机会。 在交互层面，行业一直期待着 AI 时代能够出现类似于 “GUI 时刻” 的人机交互革命； 在记忆层面，Context (上下文) 将成为 Agent 落地的核心关键词，无论是个人层面的 Context 个性化，还是企业层面的 Context 统一，都将大幅提升 Agent 的产品体验。

01 State of AI Agent：AI Agent 发展现状

Agent 应用趋势：每个公司都在积极规划部署 Agent

Agent 领域的竞争日趋白热化。 在过去一年中，涌现出许多流行的 Agent 框架。 例如，基于 ReAct 框架结合 LLM 进行推理和行动的方法，使用 Multi-agent 框架进行任务编排，以及像 LangGraph 这样更易于管控的框架。

Agent 的火热发展并非仅仅停留在社交媒体的讨论热潮。 调研数据显示，大约 51% 的受访企业已在生产环境中使用 Agent。 Langchain 的调研报告还按公司规模划分了数据，结果显示， 员工人数在 100-2000 人的中型公司在 Agent 生产部署方面最为活跃，比例高达 63%。

此外，78% 的受访者表示，他们计划在近期将 Agent 部署到生产环境中。 这清晰地表明，各行各业对 AI Agent 都抱有强烈的兴趣，但如何打造一个真正 production-ready (可用于生产环境的) Agent，对许多企业而言仍然是一个挑战。

尽管科技行业通常被认为是 Agent 技术的先行者，但各行各业对 Agent 的兴趣都在快速增长。 在非技术公司工作的受访者中，有 90% 的企业已经或计划将 Agent 投入生产环境，这一比例与技术公司几乎持平 (89%)。

Agent 的常用应用场景 (Use Case)

调研结果显示，Agent 最常见的 use case (应用场景) 包括信息研究和内容总结 (58%)，其次是通过定制化 Agent 简化工作流程 (53.5%)。

这反映出用户期望 Agent 产品能够帮助他们处理那些耗时费力的任务。 用户可以依靠 AI Agent 从海量信息中快速提取关键信息和洞察，而无需再亲自从大量数据中筛选，并进行资料回顾或研究分析。 同样，AI Agent 还可以协助处理日常事务，提升个人工作效率，使用户能够专注于更重要的工作内容。

不仅个人用户需要效率提升，企业和团队也同样需要。 客户服务 (45.8%) 是 Agent 的另一个主要应用领域。 Agent 可以帮助企业处理客户咨询、解决问题，并缩短跨团队的客户响应时间。 排在第四和第五位的应用场景是更偏底层的代码和数据处理。

监控：Agent 应用需要可观测性和可控性

随着 Agent 功能日趋强大，如何有效管理和监控 Agent 的行为变得至关重要。 追踪和可观测性工具成为企业用户 Agent 技术栈的必备选项，可以帮助开发人员深入了解 Agent 的行为和性能表现。 许多公司还会采用 guardrail (防护措施) ，以防止 Agent 行为偏离预设轨道。

在测试 LLM 应用程序时，离线评估 (Offline Evaluation) (39.8%) 的使用频率高于 在线评估 (Online Evaluation) (32.5%)，这反映出实时监控 LLM 仍然面临着诸多挑战。 在 LangChain 的开放式问卷回复中，许多公司表示，他们还会安排人工专家手动检查或评估 Agent 的响应结果，作为额外的安全保障。

尽管人们对 Agent 抱有很高的热情，但在 Agent 的权限控制方面普遍持保守态度。 鲜有受访者允许 Agent 自由地进行读取、写入和删除等操作。 相反，大多数团队仅授予 Agent “只读” 权限，或者在 Agent 执行更具风险的操作 (如写入或删除) 时，需要人工审批。

不同规模的公司在 Agent 控制方面的侧重点也存在差异。 大型企业 (员工人数超过 2000 人) 通常更加谨慎，严重依赖 “只读” 权限，以最大限度地避免不必要的风险。 他们也倾向于将 guardrail (防护措施) 与离线评估相结合，力求避免任何可能对客户产生负面影响的问题。

与此同时，小型公司和初创企业 (员工人数少于 100 人) 则更关注追踪 Agent 的运行状况，以便深入了解其 Agent 应用程序的实际表现 (而非其他控制手段)。 LangChain 的调研数据表明，小型公司倾向于通过数据分析来理解结果，而大型企业则更注重构建全方位的控制体系。

将 Agent 投入生产的障碍与挑战

保证 LLM 输出高质量的 performance (性能表现) 仍然是一项极具挑战的任务。 Agent 的回答不仅需要具备高准确性，还需要符合正确的风格。 这是 Agent 开发者们最为关注的问题，其重要性远超成本、安全等其他因素的两倍以上。

LLM Agent 本质上是一种基于概率的内容输出模型，这意味着其输出结果具有一定的不可预测性。 这种不可预测性增加了出错的可能性，使得开发团队难以确保 Agent 始终如一地提供准确且符合上下文语境的回应。

对于小型公司而言，性能质量 的重要性尤为突出，45.8% 的小型公司将其列为首要关注点，而成本 (第二大关注点) 的比例仅为 22.4%。 这一差距凸显出可靠、高质量的性能对于推动组织将 Agent 从开发阶段过渡到生产阶段至关重要。

安全问题对于需要严格遵守合规性要求，并谨慎处理客户数据的大型企业也至关重要。

除了质量挑战之外，LangChain 的开放式问卷回复还显示，许多企业对是否要持续投入 Agent 的开发和测试仍持保留态度。 大家普遍提到了两个突出的阻碍： 一是开发 Agent 需要掌握大量专业知识，且需要持续追踪前沿技术； 二是开发和部署 Agent 的时间成本很高，但其能否可靠运行以及带来预期收益，仍然存在不确定性。

其他新兴主题

在开放性问题环节，受访者对 AI Agent 展现出的以下能力给予了高度评价：

• 管理多步骤任务: AI Agent 能够进行更深入的推理和上下文管理，使其可以胜任更为复杂的任务。
• 自动化重复性任务: AI Agent 仍然被认为是处理自动化任务的关键工具，这有助于用户解放时间，专注于更具创造性的工作。
• 任务规划与协作: 更优的任务规划能力可以确保合适的 Agent 在正确的时间处理正确的问题，这在 Multi-agent 系统中尤为重要。
• 类似人类的推理: 与传统的 LLM 不同，AI Agent 可以追溯其决策过程，包括根据新的信息回顾并修正过去的决策。

此外，受访者还对 AI Agent 的未来发展提出了两点主要期待：

• 对开源 AI Agent 的期待: 人们对开源 AI Agent 表现出浓厚的兴趣，许多人认为，集体的智慧可以加速 Agent 技术的创新步伐。
• 对更强大模型的期待: 许多人期待着由更大、更强大的模型驱动的 AI Agent 能够迎来下一次飞跃，届时，Agent 将能够以更高的效率和自主性处理更加复杂的任务。

在问答环节中，许多受访者还提到了 Agent 开发过程中面临的最大挑战： 如何理解 Agent 的行为。 一些工程师表示，在向公司 stakeholder (利益相关者) 解释 AI Agent 的能力和行为时，他们会遇到困难。 虽然可视化插件在一定程度上可以帮助解释 Agent 的行为，但在更多情况下，LLM 仍然是一个 “黑箱”。 额外的可解释性负担仍然落在工程团队身上。

02 AI Agent 的核心要素分析

在 《State of AI Agent》 报告发布之前，Langchain 团队已经基于自身开发的 Langraph 框架，在 Agent 领域进行了深入探索，并通过 In the Loop 博客发表了多篇关于 AI Agent 关键组件的分析文章。 接下来，本文将编译 In the Loop 系列文章中的核心内容，深入剖析 Agent 的关键要素。

为了更好地理解 Agent 的核心要素，我们首先需要对 Agentic 系统 进行定义。 LangChain 创始人 Harrison Chase 对 AI Agent 给出了如下定义：

💡

AI Agent 是一个利用 LLM 来控制应用程序控制流决策的系统。

An AI agent is a system that uses an LLM to decide the control flow of an application.

关于 Agent 的实现方式，文章引入了 Cognitive architecture (认知架构) 的概念。 认知架构 是指 Agent 如何进行思考，系统如何编排代码或 Prompt (提示词) 来驱动 LLM。 理解认知架构有助于我们深入了解 Agent 的运行机制：

• Cognitive (认知): Agent 利用 LLM 进行语义推理，以确定如何编排代码或 Prompt LLM。
• Architecture (架构): Agent 系统仍然涉及到大量类似于传统系统架构的工程实践。

下图展示了不同层次的 Cognitive architecture (认知架构) 示例：

• 标准化的软件代码 (Code): 所有逻辑都是 Hard Code (硬编码) 实现，输入输出参数都直接固化在源代码中。 这种方式不构成认知架构，因为缺少 cognitive (认知) 部分。
• LLM Call (LLM 调用): 除了少量数据预处理外，应用程序的大部分功能都依赖于单个 LLM 的调用。 简单的 Chatbot 通常属于此类。
• Chain (链式调用): 一系列 LLM 调用，Chain 尝试将复杂问题拆解为若干步骤，并调用不同的 LLM 来逐个解决。 复杂的 RAG (检索增强生成) 系统属于此类： 例如，调用第一个 LLM 进行搜索和查询，调用第二个 LLM 生成答案。
• Router (路由): 在上述三种系统中，用户可以预先了解程序将执行的所有步骤。 但在 Router 架构中，LLM 可以自主决定调用哪些 LLM，以及采取哪些步骤。 这增加了系统的随机性和不可预测性。
• State Machine (状态机): 将 LLM 与 Router 结合使用，系统的不可预测性将进一步增强。 因为这种结合方式可以形成循环，系统理论上可以无限次地调用 LLM。
• Agentic 系统: 也常被称为 “Autonomous Agent (自主 Agent)” 。 当使用 State Machine 时，系统可以执行的操作以及执行操作后的流程仍然受到一定限制。 但当使用 Autonomous Agent 时，这些限制将被解除。 LLM 可以完全自主地决定采取哪些步骤、如何编排不同的 LLM，这可以通过使用不同的 Prompt、工具或代码来实现。

简而言之，一个系统越 “Agentic” ，LLM 在决定系统行为方式方面所起的作用就越大。

Agent 的关键要素：规划能力 (Planning)

Agent 的可靠性是当前应用实践中的一个痛点。 许多企业基于 LLM 构建了 Agent，但反馈 Agent 的规划和推理能力不足。 那么，Agent 的规划和推理能力具体指什么？

Agent 的 规划 (Planning) 和 推理 (Reasoning) 能力，指的是 LLM 思考和决策应该采取哪些行动的能力。 这涉及到短期和长期 reasoning (推理) 。 LLM 需要评估所有可用的信息，然后决定： 为了达成最终目标，我需要采取哪些步骤？ 当前最应该采取的第一个步骤是什么？

在实践中，开发者通常使用 Function calling (函数调用) 技术，让 LLM 选择要执行的操作。 Function calling 是 OpenAI 于 2023 年 6 月首次添加到 LLM API 的功能。 通过 Function calling，用户可以为不同的函数提供 JSON 结构，并让 LLM 匹配其中一个 (或多个) 结构。

要成功完成一项复杂的任务，Agent 系统通常需要按顺序执行一系列操作。 长期规划和推理 对 LLM 而言是一项非常复杂的挑战： 首先，LLM 必须考虑一个长期的行动规划，然后再细化到当前需要采取的短期行动； 其次，随着 Agent 执行的操作越来越多，操作结果会不断反馈给 LLM，导致上下文窗口持续增长，这可能会导致 LLM “分心” 并降低性能。

改进规划能力最直接的方法是确保 LLM 拥有进行合理推理和规划所需的所有信息。 虽然听起来简单，但实际情况是，传递给 LLM 的信息往往不足以支撑 LLM 做出合理的决策。 添加检索步骤或优化 Prompt 可能是一种简单的改进方案。

更进一步地，可以考虑调整应用程序的 认知架构 。 目前主要有两类认知架构可以用于改进 Agent 的推理能力： 通用认知架构 和 特定领域的认知架构。

1. 通用认知架构

通用认知架构 可以应用于各种不同的任务场景。 学术界提出了两种具有代表性的通用架构： “Plan and Solve” 架构 和 Reflexion 架构。

“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 在执行任务后，会增加一个明确的 “反思 (Reflection)” 步骤，以评估其任务执行情况是否正确。 本文不再赘述这两种架构的具体细节，感兴趣的读者可以查阅上述两篇论文原文。

尽管 “Plan and Solve” 架构 和 Reflexion 架构 在理论上展现出一定的改进潜力，但它们通常过于笼统，难以在 Agent 的实际生产应用中发挥作用。（译者注： 在本文发布时，o1 系列模型尚未发布。）

2. 特定领域的认知架构

与通用认知架构不同，许多 Agent 系统选择采用 特定领域的认知架构 。 这通常体现在特定领域的分类或规划步骤，以及特定领域的验证步骤中。 通用认知架构中提出的规划和反思思想，可以在特定领域的认知架构中得到借鉴和应用，但通常需要以更贴合特定领域的方式进行调整和优化。

AlphaCodium 的一篇论文提供了一个特定领域的认知架构的典型案例。 AlphaCodium 团队通过使用他们所谓的 “流工程 (Flow Engineering)” (本质上是另一种描述认知架构的方式) ，实现了当时最先进的性能。

如上图所示，AlphaCodium Agent 的流程设计与其试图解决的编程问题高度相关。 他们详细地告知 Agent 需要分步骤完成的任务： 首先提出测试用例，然后提出解决方案，接着迭代更多的测试用例，等等。 这种认知架构是高度专注于特定领域的，不具备通用性，难以直接泛化到其他领域。

Case Study: Reflection AI 创始人 Laskin 对 Agent 未来的展望

在红杉资本对 Reflection AI 创始人 Misha Laskin 的访谈中，Misha Laskin 分享了他对 Agent 未来发展的愿景： 通过将 RL (强化学习) 的 Search Capability (搜索能力) 与 LLM 相结合，Reflection AI 致力于构建性能卓越的 Agent 模型。 Misha Laskin 和联合创始人 Ioannis Antonoglou (AlphaGo、AlphaZero、Gemini RLHF 负责人) 正在专注于训练专门为 Agentic Workflow (Agent 工作流) 设计的模型。 访谈的核心观点如下：

• 深度是 AI Agent 中缺失的关键要素。 尽管当前的语言模型在知识广度方面表现出色，但它们缺乏可靠完成复杂任务所需的深度。 Misha Laskin 认为，解决 “深度问题” 对于创建真正有能力的 AI Agent 至关重要。 这里的 “能力” 是指 Agent 能够通过多个步骤规划和执行复杂的任务。
• 将 Learn (学习) 和 Search (搜索) 相结合是实现超人性能的关键。 借鉴 AlphaGo 的成功经验，Misha Laskin 强调，AI 领域最深刻的理念是将 **Learn (学习) ** (依靠 LLM) 和 **Search (搜索) ** (找到最优路径) 有效结合。 这种方法对于创建在复杂任务中超越人类表现的 Agent 至关重要。
• Post-training (后训练) 和 Reward modeling (奖励建模) 带来了巨大挑战。 与具有明确奖励机制的游戏不同，现实世界的任务通常缺乏明确的奖励信号。 如何开发可靠的 reward model (奖励模型) ，是创建可靠 AI Agent 的关键挑战。
• Universal Agents (通用 Agent) 可能比我们想象的更接近。 Misha Laskin 预测，我们可能只需三年时间就能实现 “digital AGI (数字通用人工智能)” ，即同时具备广度和深度的 AI 系统。 这一加速的时间表凸显出在快速发展 Agent 能力的同时，同步解决安全性和可靠性问题的紧迫性。
• 通往 Universal Agents (通用 Agent) 的道路需要一种 方法。 Reflection AI 专注于扩展 Agent 的功能边界，从一些特定的环境 (如浏览器、代码编辑器和计算机操作系统) 入手。 他们的最终目标是开发 Universal Agents (通用 Agent) ，使其能够胜任各种不同领域的任务，而不仅仅局限于特定任务。

UI/UX 交互创新

在未来几年，人机交互 (Human-Computer Interaction, HCI) 将成为 AI 领域的一个关键研究方向。 Agent 系统与传统的计算机系统截然不同，延迟、不可靠性和自然语言界面等新特性带来了全新的挑战。 因此，与 Agent 应用程序进行交互的新型 UI/UX (用户界面/用户体验) 范式必将应运而生。 尽管 Agent 系统仍处于早期发展阶段，但已经涌现出多种新兴的 UX 范式。 下面将逐一进行探讨。

1. 对话式交互 (Chat UI)

对话式交互 (Chat UI) 通常分为两种主要类型： 流式聊天 (Streaming Chat) 和 非流式聊天 (Non-streaming Chat) 。

流式聊天 (Streaming Chat) 是目前最常见的 UX 范式。 它本质上是一种 Chatbot (聊天机器人)，以类似人类对话的格式，将 Agent 的思考过程和行为逐步 流 (Stream) 式地返回给用户。 ChatGPT 是流式聊天的典型代表。 这种交互模式看似简单，但却非常有效，原因在于： 首先，用户可以使用自然语言与 LLM 进行直接对话，用户与 LLM 之间几乎不存在沟通障碍； 其次，LLM 完成任务通常需要一定时间，流式处理可以户实时了解后台任务的执行进度； 第三，LLM 有时可能会出错，Chat 界面提供了一种友好的方式，让用户可以自然地纠正和引导 LLM，用户已经非常习惯于在聊天过程中进行后续对话和迭代，以逐步明确需求并解决问题。

然而，流式聊天 (Streaming Chat) 也存在一些局限性。 首先，流式聊天仍然是一种相对较新的用户体验，我们目前常用的聊天平台 (如 iMessage、Facebook Messenger、Slack 等) 尚未普遍采用这种交互方式； 其次，对于运行时间较长的任务而言，流式聊天的用户体验略显不足，用户可能需要长时间停留在聊天界面，等待 Agent 完成任务； 第三，流式聊天通常需要由人类用户主动触发，这意味着在 Agent 执行任务的过程中，仍然需要大量的人工参与 (Human-in-the-loop)。

非流式聊天 (Non-streaming Chat) 与流式聊天的最大区别在于，Agent 的响应结果是分批返回的。 LLM 在后台默默工作，用户无需焦急等待 Agent 立即给出回复。 这意味着非流式聊天可能更容易集成到现有的工作流程中。 用户已经习惯于给朋友发送短信，为什么不能适应与 AI “发短信” 呢？ 非流式聊天将使得与更复杂的 Agent 系统进行交互变得更加自然和轻松。 因为复杂的 Agent 系统通常需要较长的运行时间，如果用户期望 Agent 立即响应，可能会感到沮丧。 非流式聊天在一定程度上消除了用户对即时响应的期望，从而更轻松地执行更复杂的任务。

下表总结了 流式聊天 (Streaming Chat) 和 非流式聊天 (Non-streaming Chat) 的优缺点：

2. 后台环境 (Ambient UX)

用户可能会主动向 AI 发送消息，这是前文讨论的 Chat UI (聊天界面) 。 但如果 Agent 只是在后台默默运行，我们应该如何与 Agent 进行交互呢？

为了充分发挥 Agent 系统的潜力，我们需要将人机交互模式转变为允许 AI 在 后台环境 (Ambient UX) 中运行。 当任务在后台处理时，用户通常可以容忍更长的任务完成时间 (因为他们降低了对 latency (低延迟) 的期望)。 这使得 Agent 可以有更充足的时间执行更多任务，通常也能够比在 Chat UX 中更仔细、更高效地完成更多推理工作。

此外，在 后台环境 (Ambient UX) 中运行 Agent，有助于扩展人类用户自身的能力。 聊天界面通常限制用户一次只能执行一项任务。 但是，如果 Agent 在后台环境中运行，则可以支持多个 Agent 同时处理多项任务。

要让 Agent 在后台可靠运行，关键在于建立用户对 Agent 的信任。 如何建立这种信任？ 一个直接的想法是： 向用户清晰地展示 Agent 正在做什么。 实时显示 Agent 正在执行的所有步骤，让用户能够观察正在发生的一切。 虽然这些步骤可能不会像流式传输响应那样立即呈现，但应该允许用户随时点击并查看 Agent 的执行进度。 更进一步地，不仅要让用户看到 Agent 在做什么，还要允许用户纠正 Agent 的错误。 例如，如果用户发现 Agent 在第 4 步 (共 10 步) 中做出了错误决策，用户可以选择回退到第 4 步，并以某种方式更正 Agent 的行为。

这种方法将用户与 Agent 的交互模式 从 “In-the-loop (环内)” 转变为 “On-the-loop (环上)” 。 “On-the-loop (环上)” 模式要求系统能够向用户展示 Agent 执行的所有中间步骤，允许用户在任务执行过程中暂停工作流，提供反馈，然后让 Agent 基于用户反馈继续执行后续任务。

AI 软件工程师 Devin 是实现类似 UX 的应用程序的代表。 Devin 的运行时间通常较长，但用户可以清晰地看到 Agent 执行的所有步骤，回溯到特定时间点的开发状态，并从该状态发布更正指令。 尽管 Agent 可能在后台运行，但这并不意味着它需要完全自主地执行任务。 有时 Agent 可能不知道接下来该做什么，或者不确定如何回答用户的问题。 在这种情况下，Agent 需要主动引起人类用户的注意，并寻求人类用户的帮助。

电子邮件助理 Agent 是 Ambient UX (后台环境) 的另一个应用案例。 LangChain 创始人 Harrison Chase 正在构建一款电子邮件助理 Agent。 虽然这款 Agent 可以自动回复一些简单的电子邮件，但在某些情况下，它仍然需要 Harrison 人工参与，处理一些不适合自动化的任务，例如： 审阅复杂的 LangChain 错误报告、决定是否参加某个会议等。 在这种情况下，电子邮件助理 Agent 需要一种有效的方法，向 Harrison 传达它需要人工协助才能继续完成任务。 请注意，Agent 并不是直接向 Harrison 索要答案，而是征求 Harrison 对某些任务的意见，然后 Agent 可以利用这些人工反馈来撰写一封高质量的电子邮件，或安排会议日历邀请。

目前，Harrison 在他的 Slack 工作区中设置了这个电子邮件助理 Agent。 当 Agent 需要人工协助时，它会向 Harrison 的 Slack 发送一个问题，Harrison 可以在 Dashboard (仪表板) 中回答问题，这种交互方式与 Harrison 的日常工作流程无缝集成。 这种类型的 UX 类似于客户支持 Dashboard 的 UX。 Dashboard 界面可以清晰地显示助手需要人工帮助的所有任务、请求的优先级以及其他相关数据。

3. 电子表格 (Spreadsheet UX)

电子表格 UX (Spreadsheet UX) 是一种非常直观且用户友好的交互方式，特别适合批量处理工作。 在电子表格界面中，每个表格，甚至每一列都可以被视为一个独立的 Agent，用于研究和处理特定的任务。 这种批量处理能力允许用户轻松扩展与多个 Agent 的交互。

电子表格 UX (Spreadsheet UX) 还具有其他优势。 电子表格格式是大多数用户都非常熟悉的 UX，因此它非常容易融入到现有的工作流程中。 这种类型的 UX 非常适合数据扩充 (Data Enrichment) 的应用场景，在数据扩充场景中，电子表格的每一列可以表示需要扩充的不同数据属性。

Exa AI、Clay AI、Manaflow 等公司都在其产品中采用了 电子表格 UX (Spreadsheet UX) 。 下面以 Manaflow 为例，介绍 电子表格 UX (Spreadsheet UX) 如何应用于 Agent 交互工作流程。

Case Study: Manaflow 如何使用电子表格进行 Agent 交互

Manaflow 的灵感来源于其创始人 Lawrence 曾任职的公司 Minion AI。 Minion AI 的核心产品是 Web Agent。 Web Agent 可以控制本地的 Google Chrome 浏览器，并允许用户通过 Web Agent 与各种 Web 应用程序进行交互，例如在线订机票、发送电子邮件、预约洗车等。 受到 Minion AI 的启发，Manaflow 选择让 Agent 直接操作电子表格等工具。 Manaflow 团队认为，Agent 并不擅长直接处理人类的 UI 界面，Agent 真正擅长的是 Coding (编程) 。 因此，Manaflow 让 Agent 直接调用 UI 界面的 Python 脚本、数据库接口和 API 接口，然后直接对数据库进行操作，包括读取数据、安排日程、发送邮件等。

Manaflow 的工作流程如下： Manaflow 的主要交互界面是一个电子表格 (Manasheet)。 Manasheet 中的每一列代表工作流程中的一个步骤，每一行对应于一个执行特定任务的 AI Agent。 每个 Manasheet 工作流都可以使用自然语言进行编程 (允许非技术用户使用自然语言描述任务和步骤)。 每个 Manasheet 都有一个内部依赖关系图，用于确定每列的执行顺序。 这些执行顺序会被分配给每一行的 Agent，Agent 并行执行任务，处理数据转换、API 调用、内容检索和消息发送等流程：

用户可以通过多种方式生成 Manasheet。 最常见的方式是输入类似上图红色框中的自然语言指令。 例如，如果用户想要向客户批量发送包含定价信息的邮件，可以通过 Chat 界面输入 Prompt (提示词)，Agent 会自动生成 Manasheet。 通过 Manasheet，用户可以清晰地看到客户的姓名、邮箱、所属行业、是否已发送邮件等关键信息。 用户只需点击 “Execute Manasheet (执行 Manasheet)” 按钮，即可批量执行邮件发送任务。

4. 生成式 UI (Generative UI)

“生成式 UI (Generative UI)” 主要有两种不同的实现方式。

第一种方式是由模型自主生成所需的 UI 组件 。 这类似于 Websim 等产品。 在后台，Agent 主要编写原始 HTML 代码，使其能够完全控制用户界面所显示的内容。 然而，这种方法的缺点是，生成的 Web App 质量具有很大的不确定性，用户体验可能参差不齐。

另一种更受约束的方法是： 预先定义一系列常用的 UI 组件，然后通过 工具调用 (Tool Calls) 的方式来动态渲染 UI 组件。 例如，如果 LLM 调用了天气 API，则会触发天气地图 UI 组件的渲染。 由于渲染的 UI 组件是预先定义好的 (用户有更多选择)，因此最终生成的 UI 将更加精致，但其灵活性也会受到一定限制。

Case Study: Personal AI 产品 dot

Personal AI 产品 dot 是 生成式 UI (Generative UI) 的优秀案例。 dot 在 2024 年曾被誉为 “最佳 Personal AI 产品”。

dot 是 New Computer 公司旗下的明星产品。 dot 的目标是成为用户的长期数字伴侣，而不仅仅是一个高效的任务管理工具。 正如 New Computer 联合创始人 Jason Yuan 所说，dot 的应用场景是 “当你不知道该去哪里、该做什么或该说什么时，你就会求助于 dot”。 以下是 dot 的几个典型应用案例：

• New Computer 创始人 Jason Yuan 经常在深夜让 dot 推荐酒吧，希望能 “一醉方休”。 在持续数月的 “深夜酒吧” 对话后，某天 Jason Yuan 再次向 dot 提出类似问题时，dot 竟然开始劝解 Jason “不能再这样下去了”。
• 《Fast Company》 记者 Mark Wilson 也与 dot 相处了几个月时间。 有一次，他向 dot 分享了他在书法课上写的一个手写 “O” 字。 dot 竟然立即调出了几周前 Mark Wilson 手写的 “O” 字照片，并称赞他的书法水平 “进步很大”。
• 随着用户使用 dot 的时间越来越长，dot 能够更深入地理解用户的兴趣偏好。 例如，当 dot 了解到用户喜欢打卡咖啡馆后，会主动向用户推送附近优质的咖啡馆，详细介绍推荐理由，并在最后贴心地询问用户是否需要导航。

在上述咖啡馆推荐案例中，dot 通过预定义的 UI 组件，实现了基于 LLM-native 的自然人机交互效果。

5. 协作式 UX (Collaborative UX)

当 Agent 和人类用户协同工作时，会产生怎样的人机交互模式？ 类似于 Google Docs，多位用户可以实时协作编写或编辑同一个文档。 如果协作者之一是 Agent 呢？

Geoffrey Litt 和 Ink & Switch 合作的 Patchwork 项目 是人机协同的 协作式 UX (Collaborative UX) 的优秀代表。（译者注： OpenAI 近期发布的 Canvas 产品更新可能受到了 Patchwork 项目的启发）。

协作式 UX (Collaborative UX) 与前文讨论的 Ambient UX (后台环境) 有何区别？ LangChain 创始工程师 Nuno 强调了两者之间的主要区别在于是否具备 并发性 (Concurrency) ：

• 在 协作式 UX (Collaborative UX) 中，人类用户和 LLM 通常需要同时工作，并将彼此的工作成果作为输入。
• 在 Ambient UX (后台环境) 中，LLM 在后台持续运行，而用户则可以完全专注于其他任务，无需实时关注 Agent 的运行状态。

记忆机制 (Memory)

记忆 (Memory) 对于提升 Agent 的用户体验至关重要。 试想一下，如果你的同事从不记得你告诉过他的任何信息，总是让你不断重复相同的内容，这种协作体验将非常糟糕。 人们通常期望 LLM 系统天生就具备记忆能力，这可能是因为 LLM 在某些方面已经非常接近人类的认知水平。 然而，LLM 本身并不具备记忆能力。

Agent 的 记忆机制 (Memory) 设计需要根据产品本身的具体需求来确定。 不同的 UX 范式也为收集信息和更新反馈提供了不同的方法。 从 Agent 产品的记忆机制中，我们可以观察到不同类型的高级记忆模式，它们在一定程度上模仿了人类的记忆类型。

论文 《CoALA: Cognitive Architectures for Language Agents》 将人类的记忆类型与 Agent 的记忆机制进行了映射，分类方式如下图所示：

1. 程序记忆 (Procedural Memory)

程序记忆 (Procedural Memory) 是一种关于 如何执行任务 的长期记忆，类似于人脑中的核心指令集。

• 人类的程序记忆: 例如，记住如何骑自行车。
• Agent 的程序记忆: CoALA 论文将程序记忆描述为 LLM 权重和 Agent 代码的组合，它们从根本上决定了 Agent 的工作方式。

在实践中，Langchain 团队尚未发现任何 Agent 系统能够自动更新其 LLM 或重写其代码。 但确实存在一些 Agent 系统能够动态更新其 System Prompt (系统提示词) 的案例。

2. 语义记忆 (Semantic Memory)

语义记忆 (Semantic Memory) 是一种长期知识储备，用于存储事实性知识。

• 人类的语义记忆: 由各种信息片段组成，例如在学校学到的事实、概念以及它们之间的关系。
• Agent 的语义记忆: CoALA 论文将语义记忆描述为事实知识的存储库。

在实践中，Agent 的语义记忆通常通过使用 LLM 从 Agent 的对话或交互过程中提取信息来实现。 信息的具体存储方式通常取决于具体的应用程序。 然后在后续对话中，系统会检索这些存储的信息，并将其插入到 System Prompt (系统提示词) 中，以影响 Agent 的响应。

3. 情景记忆 (Episodic Memory)

情景记忆 (Episodic Memory) 用于回忆特定的过去事件。

• 人类的情景记忆: 当一个人回忆起过去经历的特定事件 (或 “情节”) 时，就使用了情景记忆。
• Agent 的情景记忆: CoALA 论文将情景记忆定义为存储 Agent 过去动作的序列。

情景记忆主要用于确保 Agent 能够按照预期执行操作。 在实践中，情景记忆的更新通常通过 Few-Shots Prompt (少样本提示) 的方法来实现。 如果在初始阶段，系统通过 Few-Shots Prompt (少样本提示) 指导 Agent 正确地完成了操作，那么在后续面对类似问题时，Agent 就可以直接复用这种操作方法。 相反，如果系统中不存在指导 Agent 正确操作的有效方法，或者 Agent 需要不断尝试新的操作方式，那么 语义记忆 (Semantic Memory) 将变得更加重要，情景记忆 (Episodic Memory) 在这些场景中的作用相对有限。

除了考虑需要在 Agent 中更新的记忆类型外，开发人员还需要考虑 如何更新 Agent 的记忆 。 目前主要有两种更新 Agent 记忆的方法：

第一种方法是 “in the hot path (热路径更新)” 。 在这种模式下，Agent 系统会在生成响应之前实时地记住相关的事实信息 (通常通过工具调用实现)。 ChatGPT 目前就采用了这种方法来更新其记忆。

第二种方法是 “in the background (后台更新)” 。 在这种模式下，后台进程会在会话结束后异步运行，并在后台更新 Agent 的记忆。

“in the hot path (热路径更新)” 方法的缺点是，在返回任何响应之前，都会产生一定的 latency (延迟) 。 此外，它还需要将 memory logic (记忆逻辑) 与 agent logic (Agent 逻辑) 紧密结合。

“in the background (后台更新)” 方法可以有效避免上述问题，它不会增加响应延迟，并且 memory logic (记忆逻辑) 可以保持相对独立。 但 “in the background (后台更新)” 也存在自身的不足： 记忆不会立即更新，并且需要额外的逻辑来确定何时启动后台更新进程。

另一种更新记忆的方法涉及到用户反馈，这与 情景记忆 (Episodic Memory) 尤其相关。 例如，如果用户对 Agent 的某次交互给出了较高的评分 (Postive Feedback (积极反馈)) ，Agent 可以保存该反馈信息，以便在未来类似场景中调用。

基于以上编译内容，AI Share 认为，规划能力、交互创新和记忆机制这三大关键要素的同步发展和持续进步，将有望在 2025 年催生更多实用化的 AI Agent 应用，并引领我们迈向人机协同工作的新时代。