某种意义上，LangChain 可能是最了解 Agent（智能体）的平台。
最近，LangChain 创始人 Harrison Chase 发表了一系列对于 Agent 的设计、规划和用户交互设计的探讨。对于当下如何理解 Agent、如何设计 AI 应用的交互上，有很多来自第一线的认知，推荐一读。
一些有意思的点：
什么是智能体？每个人似乎都有不同的定义，吴恩达的建议是，「与其争论什么应被归类为真正的智能体，不如承认系统具有不同程度的智能体特性（agentic）」，就像自动驾驶汽车有不同的自动化等级一样。
目前最主流的 UX 是「流式聊天」，一个很典型的例子是 ChatGPT，用户通过自然语言和 LLM 进行交互，不过，不少创业者相信，除了聊天之外，还有更多的 UX 模式值得考虑。
和流式聊天最大的区别在于，非流式聊天的响应是以完整的批次返回的，这是个缺点，因为你不知道系统内部发生了什么，但另一方面，Linus Lee 提到，「我有意将界面设计得尽可能不透明」，不透明的界面需要一定程度的信任，但信任一旦建立，你就只需要把任务委派给智能体，而不必过多干预。
如何建立用户对智能体的信任？一个简单的方式，把每次操作展示给用户。除此之外，不仅让用户看到发生了什么，还要让他们能够纠正智能体的操作。用户可以在工作流中途暂停，提供反馈，然后让智能体继续执行。
需要将用户从「在循环中」转变为「在循环上」。「在循环上」意味着智能体需要向用户展示其执行的所有中间步骤，用户可以在工作流中途暂停，提供反馈，然后让智能体继续执行。一个已经实现了类似用户体验的应用是 Devin——AI 软件工程师。
点击关注，每天更新深度 AI 行业洞察
01
什么是智能体？
「什么是智能体？」
我几乎每天都会被问到这个问题。在 LangChain，我们构建工具帮助开发者创建大语言模型（LLM）应用程序，特别是那些作为推理引擎并与外部数据和计算资源交互的系统。这些系统通常被称为「智能体」。
每个人似乎对智能体的定义都有些不同。我的定义可能比大多数人更加技术化：
智能体是一个使用大语言模型（LLM）来决定应用程序控制流的系统。
即便如此，我承认我的定义并不完美。人们通常认为智能体是高级的、自主的、类似人类的——但如果是一个简单的系统，LLM 只是在两条不同路径之间进行路由选择呢？这符合我的技术定义，但与人们普遍对智能体应具备的能力认知不一致。要精确定义什么是智能体，确实非常困难！
因此，我非常喜欢 Andrew Ng 上周的推文。在推文中，他建议「与其争论什么应被归类为真正的智能体，不如承认系统具有不同程度的智能体特性（agentic）。」就像自动驾驶汽车有不同的自动化等级一样，我们也可以将智能体的能力视作一个光谱。我非常赞同这一观点，并且认为 Andrew 表达得非常到位。未来，当再有人问我什么是智能体时，我将转而讨论什么是「智能体特性」。
原文地址：https://x.com/AndrewYNg/status/1801295202788983136
什么是智能体特性？
去年我在一场关于 LLM 系统的 TED 演讲中使用了下面这张幻灯片，来讨论 LLM 应用中不同的自主性级别。
系统越依赖 LLM 来决定其行为方式，它就越具有「智能体特性」。
使用 LLM 将输入路由到特定的下游工作流中，表现出少许「智能体」行为。这会归类为上图中的 Router（路由器）类别。
如果你使用多个 LLM 执行多个路由步骤呢？这会介于 Router 和 State Machine（状态机）之间。
如果其中一个步骤是在决定是否继续或结束——实际上允许系统循环运行直到完成？那么这就会归类为 State Machine。
论文地址：https://arxiv.org/abs/2305.16291
「智能体特性」有什么用？
正如所有概念一样，我们有必要思考，为什么我们需要「智能体特性」这个概念？它有什么帮助？
了解系统的智能体特性能够指导你在开发过程中做出决策——包括构建、运行、与之交互、评估，甚至是监控。
系统的智能体特性越强，编排框架的作用就越大。如果你正在设计一个复杂的智能体系统，拥有一个具备这些概念的抽象框架能够加速开发。这个框架应该支持一流的分支逻辑和循环控制。
系统的智能体特性越强，运行难度就越大。它会变得更加复杂，有些任务可能需要很长时间才能完成。这意味着你可能需要将任务设为后台运行。同时，也需要具备持久执行能力，以应对任务过程中出现的错误。
系统的智能体特性越强，你就越希望在系统运行时进行交互。你会希望能够观察系统内部正在发生的事情，因为具体步骤可能无法提前预知。你还需要在某个时间点调整智能体的状态或指令，以便当它偏离既定轨道时纠正回来。
系统的智能体特性越强，你就越需要为此类应用构建一个评估框架。由于随机性会逐步累积，因此你可能需要多次进行评估。你不仅需要测试最终输出，还需要评估中间步骤，检查智能体的行为效率。
系统的智能体特性越强，你就越需要一种全新的监控框架。你希望能够深入分析智能体执行的每一个步骤，还希望可以根据智能体执行的步骤来查询运行情况。
理解并运用系统的智能体能力光谱，能提升开发过程的效率与稳健性。
02
如何为智能体进行规划
在三月份的 Sequoia AI Ascent 大会上，我提到了智能体的三大限制：规划、用户体验（UX）和记忆。你可以在此观看演讲：https://www.youtube.com/watch?v=pBBe1pk8hf4
如果你询问任何使用大语言模型（LLM）构建智能体的开发者，他们很可能会提到规划和推理能力的不足是影响智能体可靠性的一大问题。那么，规划对智能体意味着什么？人们目前是如何克服这一短板的？未来智能体的规划和推理能力可能会如何发展？我们将在下文中讨论这些问题。
什么是规划和推理？
智能体的规划和推理涉及 LLM 决定采取哪些行动的能力。这个过程包括短期和长期的步骤。LLM 需要评估所有可用的信息，然后决定：我需要采取哪些步骤？当前我应该采取的第一步是什么？
大多数情况下，开发者使用函数调用（也称为工具调用）来让 LLM 选择行动。函数调用是 OpenAI 于 2023 年 6 月首次在 LLM API 中引入的功能，随后在 2023 年底和 2024 年初被其他平台采用。通过函数调用，你可以为不同的函数提供 JSON 架构，让 LLM 输出的对象匹配这些架构之一。
函数调用通常用于让智能体选择当前的即时行动。然而，成功完成复杂任务往往需要一系列连续的行动。这种长期规划和推理对 LLM 来说更具挑战，原因有以下几点。首先，LLM 需要考虑一个长远的目标，但同时还必须跳回到当前的短期行动中。其次，随着智能体采取更多的行动，这些行动的结果会反馈给 LLM，这会导致上下文窗口不断扩大，进而可能导致 LLM 分心，表现不佳。
正如 LLM 领域的许多事情一样，当前模型在规划和推理方面的表现难以准确衡量。有一些合理的基准测试，例如伯克利函数调用排行榜，用于评估函数调用能力。我们也进行了一些关于多步骤应用的研究。但是，要了解这方面表现的最佳方式是针对你的具体问题建立一个评估集，并自行进行评估。
从经验来看，目前的规划和推理能力还没有达到处理现实任务所需的水平。
有哪些方法可以改善智能体的规划能力？
改善规划能力最简单的方式是确保 LLM 拥有进行合理推理和规划所需的所有信息。虽然这听起来很基础，但很多时候传递给 LLM 的提示中并没有包含足够的信息，导致它无法做出合理的决策。添加一个信息检索步骤，或者更加明确地说明提示中的指令，可以作为简单的改进措施。这也是为什么需要实际查看数据，看看 LLM 实际接收到的信息是什么。
接下来，我建议你尝试改变应用程序的认知架构。所谓「认知架构」，是指应用程序用于推理的数据处理逻辑。你可以选择两类认知架构来改善推理能力：通用认知架构和领域特定认知架构。
通用认知架构 vs. 领域特定认知架构
通用认知架构尝试在任意任务中提升推理能力。一个很好的例子是「规划与解决」架构。这篇论文（https://arxiv.org/abs/2305.04091）探讨了一种架构，在这种架构中，首先制定一个计划，然后逐步执行计划中的每一步。另一个通用架构是 Reflexion 架构，这篇论文（https://arxiv.org/abs/2303.11366）提出，在智能体完成任务后增加一个「反思」步骤，以评估任务执行得是否正确。
尽管这些想法展示了推理能力的提升，但它们往往过于通用，难以应用于生产环境中的智能体。相反，我们发现智能体通常使用领域特定的认知架构。这通常体现在领域特定的分类和路由步骤、验证步骤等方面。虽然某些通用的规划和反思理念在这里同样适用，但通常是以领域特定的方式应用。
以 AlphaCodium 论文（https://www.qodo.ai/products/alphacodium/）为例，它通过使用「流程工程」（认知架构的另一种说法）实现了当前最先进的性能。下图展示了他们所使用的流程。
该流程非常针对其要解决的问题。他们要求智能体按步骤进行操作——首先编写测试，然后编写解决方案，接着迭代更多的测试等。这个认知架构高度领域特定，并不会对写作任务产生帮助。
为什么领域特定的认知架构如此有用？
我喜欢从两个角度来解释这一点。
首先：你可以将其视为另一种向智能体传达其应执行任务的方式。你可以通过提示来传达指令，也可以通过代码明确规定具体的步骤。两种方式都是有效的！代码是传达预期行为的极佳方式。
其次：这实际上是将规划责任从 LLM 转移到了我们这些工程师手中。我们基本上是在告诉 LLM：「不用担心规划，我来替你做！」当然，我们并没有完全移除 LLM 的规划责任，因为在某些情况下我们仍要求它进行部分规划。
例如，回到上面的 AlphaCodium 例子。流程中的步骤基本上是我们替 LLM 进行的规划！我们告诉它先编写测试，然后写代码，再运行测试等。这实际上是作者认为编写软件的一个好计划。如果他们要为某个问题制定一个解决方案，可能也是以这种方式进行规划的。与其通过提示告诉 LLM 执行这些步骤——提示可能被忽略、误解或缺少细节——他们通过构建领域特定的认知架构向系统传达如何操作。
我们看到，几乎所有生产环境中的高级「智能体」实际上都有非常领域特定且定制的认知架构。
我们通过 LangGraph 让构建这些定制认知架构变得更加容易。LangGraph 的一个核心重点是可控性。我们设计了 LangGraph，使其操作非常底层且高度可控——因为我们发现，要创建可靠的定制认知架构，100% 的可控性是必须的。
规划和推理的未来会怎样？
LLM 领域变化迅速，我们在构建应用程序时，尤其是在构建工具时，应该对此保持关注。
我目前的看法是，通用推理将越来越多地融入模型层。模型将变得越来越智能，无论是通过规模的扩大还是研究的突破——押注这一趋势似乎是不明智的。模型也会变得更快、更便宜，因此传递大量上下文信息给它们将变得更加可行。
然而，我相信，无论模型多么强大，你始终需要以某种形式向智能体传达其应执行的任务。因此，我认为提示和定制架构将继续存在。对于简单任务，提示可能就足够了；而对于复杂任务，可能需要通过代码来定义其行为。代码优先的方法可能更快、更可靠、更易于调试，并且在很多情况下表达起来更加简洁、合理。
我最近参加了一个 podcast，与 Sequoia 的 Sonya 和 Pat 讨论了这个话题。他们绘制了一张很棒的图，展示了提示、认知架构和模型的角色和重要性如何随着时间推移而演变。
所以，尽管 LLM 的规划和推理能力将不断提升，我们依然坚信，如果你正在构建一个任务特定的智能体，定制认知架构将是必不可少的。这也是我们对 LangGraph 未来充满信心的原因。
03
用户交互之一：
聊天体验不一定需要流式
人与计算机的交互已经研究了很多年。我相信在未来几年，人与智能体的交互也将成为一个重要的研究领域。
智能体系统与过去的传统计算机系统不同，主要是因为它们面临着新出现的挑战，如延迟、不可靠性和自然语言界面。因此，我坚信，与这些智能体应用程序交互的新 UI/UX 模式将会出现。
虽然目前智能体系统还处于早期阶段，但我认为已经有多个正在兴起的 UX 模式。本章，我们将讨论目前最主流的 UX 形式：聊天。
流式聊天
「流式聊天」UX 是目前最主流的 UX。它简单地指的是一个智能体系统以聊天格式实时返回其思考和行为——ChatGPT 是其中最受欢迎的例子。这种交互模式看似简单，但实际上有几个重要的优点。
与大语言模型 (LLM) 交互的主要方式是通过自然语言。在聊天中，你可以通过自然语言直接与 LLM 互动。这意味着你和 LLM 之间几乎没有任何障碍。
在某些方面，流式聊天就像早期计算机的「终端」。
终端（尤其是早期计算机的终端）提供了更底层、更直接的访问操作系统的方式。但随着时间的推移，计算机逐渐转向更多基于图形用户界面的交互。流式聊天可能类似——这是我们与 LLM 互动的第一种方式，它提供了对底层 LLM 的直接访问。随着时间的推移，其他 UX 可能会出现（就像计算机逐渐转向更多的 UI 交互）——但低层次的访问在初期有显著的优势！
流式聊天的一个优势是 LLM 可能需要一些时间来处理。流式方式让用户能够理解系统内部的实时情况。你可以看到 LLM 执行的中间步骤（包括它采取的动作和结果）以及它「思考」时生成的 token。
流式聊天的另一个好处是 LLM 经常出错。聊天提供了一个非常自然的界面，可以用来纠正和引导它！我们已经习惯了在聊天中进行后续对话，并通过这种迭代方式讨论问题。
当然，流式聊天也有其缺点。首先，流式聊天是一种相对较新的 UX，因此我们现有的聊天平台（如 iMessage、Facebook Messenger、Slack 等）还没有内置这种模式。其次，对于需要较长时间运行的任务来说，这种模式可能会有点别扭——难道我要一直坐在那里看着智能体工作吗？第三，流式聊天通常需要由人类触发，这意味着人类仍然深度参与其中。
非流式聊天
称它为「非流式聊天」听起来有些奇怪，因为直到两年前，我们还只是把它称为「聊天」——但事实就是这样。非流式聊天与流式聊天有很多相似之处——它向用户直接暴露 LLM，并且允许非常自然地进行纠正。
非流式聊天的主要区别在于，响应是以完整的批次返回的，这既有利也有弊。最大的缺点是你无法看到系统内部发生了什么，结果就是你会被蒙在鼓里。
但是……这真的是问题吗？
Linus Lee 最近对「委托」发表了一些精彩的见解，我非常喜欢。他的一个片段很好地说明了这一点：
我有意将界面设计得尽可能不透明。
他认为，不透明的界面需要一定程度的信任，但一旦建立了这种信任，就可以让你_只需将任务委派给智能体_，而不必进行微观管理。这种异步性质也有助于处理长时间运行的任务——这意味着智能体可以为你做更多的工作。
假设信任得以建立，这似乎是一个好事情。但它也会引发其他问题。例如，如何处理「重复发送」——即用户发送一条消息，智能体开始执行任务，而用户在智能体完成任务之前再次发送另一条（有时是无关的）消息。在流式聊天中，通常不会出现这种问题，因为智能体的流式信息会阻止用户输入新的内容。
非流式聊天 UX 的一个优势是它更符合我们的日常习惯，这意味着它可能更容易整合到现有的工作流程中。人们习惯于与其他人通过文本消息交流——为什么不也适应与 AI 进行文字交流呢？
非流式聊天的另一个大优点是，它通常允许 AI 花费更多的时间来回应。
这通常是因为非流式聊天更自然地集成到我们现有的工作流程中。我们不期望朋友立刻回复消息——为什么我们要期望 AI 这样做呢？这使得与更复杂的智能体系统交互变得更容易——这些系统往往需要时间，而如果我们期待即时回复，可能会感到沮丧。非流式聊天往往消除了这种期望，使得执行更复杂的任务变得更加轻松。
流式聊天似乎是更新、更闪亮、更具未来感的技术……但随着我们对智能体系统的信任增加，这种趋势是否会逆转呢？
聊天之外的更多 UX 形式？
我们相信除了聊天之外，还有更多的 UX 模式值得考虑。不过，仍然值得提醒的是，聊天是一个非常好的用户体验设计，它被广泛使用是有原因的。
聊天的好处：
允许用户直接与模型交互
允许用户轻松提出后续问题和/或进行纠正
流式与非流式聊天的优缺点
04
用户交互之二：
后台运行也可以建立用户信任
在之前关于聊天型用户体验的章节中，我们探讨了聊天界面如何要求用户主动与 AI 互动。而如果 AI 可以在后台为您工作呢？
我认为，为了让智能体系统真正发挥潜力，必须实现让 AI 在后台运行的转变。当任务在后台处理时，用户通常对较长的完成时间更加宽容（因为他们不再过于追求低延迟）。这让智能体能够更专注地完成任务，而不是像在聊天界面中那样急于给出回应。
此外，后台运行的智能体能够让我们人类更高效地扩展我们的能力。聊天界面通常限制我们一次只能处理一个任务。但如果智能体在后台运行，多个智能体可以同时处理多个任务。
那么，后台运行智能体的用户体验是什么样的呢？
与后台智能体建立信任：从「人在循环中」到「人在循环上」
要让智能体在后台运行需要建立一定的信任。如何建立这种信任呢？
一个简单的方式就是展示给用户智能体正在执行的每一步操作，并让用户随时查看这些信息。虽然这些信息不会像流式反馈那样实时显示，但应该为用户提供可以点击查看的选项。
下一步，不仅仅是让用户看到发生了什么，还要让他们能够纠正智能体的操作。如果用户发现智能体在第 10 步中的第 4 步做出了错误选择，他们应该能够回到第 4 步进行纠正。
这种纠正方式可以通过几种形式实现。以纠正错误调用工具的智能体为例：
您可以手动输入正确的工具调用指令，使其看似由智能体生成，然后继续后续步骤。
您可以向智能体提供明确的指令，告诉它如何更好地调用工具——例如，「用参数 X 调用，而不是参数 Y」，并要求智能体更新其预测。
您可以更新当时的指令或状态，并从该步骤重新运行。
选项 2 和 3 的区别在于智能体是否意识到其先前的错误。选项 2 是要求智能体认识到其错误并加以纠正，而选项 3 则是在不知情的情况下只遵循新的指令。
这种方法将用户从「在循环中」转变为「在循环上」。「在循环上」意味着智能体需要向用户展示其执行的所有中间步骤，用户可以在工作流中途暂停，提供反馈，然后让智能体继续执行。
一个已经实现了类似用户体验的应用是 Devin——AI 软件工程师。Devin 能够长时间运行，用户可以查看所有执行的步骤，回到某个特定时间点，并从那里进行纠正。
整合人工输入：智能体在需要时如何请求帮助
虽然智能体在后台运行，但这并不意味着它必须完全自主地完成任务。有些时候，智能体可能不知道接下来该怎么做或如何回应。这时，它需要引起人类的注意并请求帮助。
以我正在构建的电子邮件助手智能体为例。虽然它能够处理一些基础的邮件任务，但对于某些任务，我不希望自动化处理，例如复杂的 LangChain 错误报告审阅或决定是否参加会议。
在这种情况下，电子邮件助手需要一种机制向我请求信息，而不是让我直接处理回复。它希望获得我的意见，然后利用这些信息撰写邮件或安排会议。
目前，我已经在 Slack 中设置了这个助手。它通过问题通知我，我在线程中回复，轻松集成到我的工作流程中。如果这种用户体验在更大范围内应用，我会设想一个类似客户支持仪表盘的界面，展示所有需要人工帮助的任务、请求的优先级及其他元数据。
我最初将这个电子邮件助手称为「智能体收件箱」——但更准确地说，它是一个为人类帮助智能体完成任务的收件箱……这种想法令人深思。
05
用户交互之三：
电子表格、生成式和协作式 UI
了解批量处理智能体工作负载的电子表格用户体验、生成式 UI 以及与智能体协作的用户体验。
当我们共同探索构建和与智能体互动的最佳方式时，有太多值得挖掘的领域。智能体的 UI/UX 领域是我非常感兴趣的一个领域，我会密切关注未来几个月的创新。为了总结关于智能体 UI/UX 的讨论，我将重点介绍三种最近变得更受欢迎的用户体验。
电子表格用户体验
在过去两个月中，我看到的一种用户体验范式是电子表格用户体验。第一次见到这种方式是在今年早些时候推出的 Matrices——AI 原生电子表格。
我非常喜欢这种方式。首先，电子表格用户体验是支持批量处理工作负载的超级直观且用户友好的方式。每个单元格都可以变成一个独立的智能体，去研究特定的任务。这种批处理方式允许用户同时扩展并与多个智能体交互。
这种 UX 还有其他优势。电子表格格式是非常常见的用户界面，大多数用户都很熟悉，因此它可以轻松融入现有的工作流程中。这种 UX 对于数据丰富化尤其适用，这是 LLM 的一个常见使用场景，每列可以代表不同的待丰富属性。
从那时起，我在几个地方看到了这种 UX（Clay 和 Otto 是两个很好的例子）。
生成式 UI
「生成式 UI」可以有多种不同的含义。
一种解释是模型生成用于显示的原始组件，即真正的生成式 UI。这类似于 WebSim 等应用程序。其背后是，智能体主要编写原始 HTML 代码，允许其完全控制显示的内容。然而，这种方法可能会导致生成的 HTML 质量不一，因此最终结果可能看起来有些粗糙或不够精致。
另一种更受限的生成式 UI 方法是通过编程将 LLM 的响应映射到不同的预定义 UI 组件上。这通常是通过工具调用实现的。例如，如果 LLM 调用了天气 API，它将触发天气图组件的渲染。由于渲染的组件并非真正生成的（而是被选择的），因此生成的 UI 会更加精致，但在可生成内容的灵活性上有所限制。
协作式 UX
一种较少被探讨的 UX 是：当智能体和人类一起工作时会发生什么？想象一下 Google Docs，你可以与团队成员合作撰写或编辑文档——但其中一个合作伙伴是智能体。
我心目中该领域的领先思想家是 Geoffrey Litt 和 Ink & Switch，他们的 Patchwork 项目 是人类与智能体协作的一个很好的例子。
协作式 UX 与之前讨论的环境 UX 有何不同？我们的一位创始工程师 Nuno 强调了两者之间的主要区别：
主要区别在于并发性：
在协作式 UX 中，你和 LLM 经常同时工作，互相「借鉴」彼此的工作
在环境 UX 中，LLM 持续在后台工作，而你则专注于其他事情
这些差异也转化为构建这些应用时的不同需求：
对于协作式 UX，你可能需要展示 LLM 完成的细粒度工作（这可能介于单个 Token 和较大的应用程序特定工作单元之间，例如文本编辑器中的段落）。一个常见需求是自动合并并发更改的方式，类似于 Google Docs 管理实时协作的方式。
对于环境 UX，你可能需要总结 LLM 所完成的工作或突出显示变更。一个常见需求可能是触发由其他系统中的事件（例如通过 webhook）所启动的运行。
