深度丨LangChain团队基于Agents用户体验设计的研究

3月份，LangChain 创始人 Harrison Chase 在红杉资本的 AI Ascent 上演讲，探讨 AI Agent 的下一步发展以及使用语言模型与外部世界交互的演变。Harrison 确定了下一代 Agents 的三个关键开发领域，规划、用户体验和记忆。

之后，7月份、8月份陆续在 LangChain 博客上深入探讨了针对智能体的用户体验设计，由于智能体用户体验设计有很多不同的内容，陆续发布了一系列的3篇博客文章。

文章经 GeekSavvy 翻译整理，并去除一些广告内容，尽可能保留原文，下面是针对智能体的用户体验设计这个系列的3篇文章，即为3部分。

    Part 1：聊天

    Part 2：环境（后台运行）

    Part 3：电子表格、生成和协作 UI/UX

Part 1 聊天

人与计算机的交互已经研究了很多年。我相信在未来几年，人与智能体的交互也将成为一个重要的研究领域。

智能体系统与过去的传统计算机系统不同，主要是因为它们面临着新出现的挑战，如延迟、不可靠性和自然语言界面。因此，我坚信，与这些智能体应用程序交互的新 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 模式值得考虑。不过，仍然值得提醒的是，聊天是一个非常好的用户体验设计，它被广泛使用是有原因的。

聊天的好处：

• 允许用户直接与模型交互

• 允许用户轻松提出后续问题和/或进行纠正

流式与非流式聊天的优缺点

Part 2：环境（后台运行）

在我们之前关于聊天型用户体验的博客文章中，我们探讨了聊天界面如何要求用户主动与 AI 互动。而如果 AI 可以在后台为您工作呢？

我认为，为了让智能体系统真正发挥潜力，必须实现让 AI 在后台运行的转变。当任务在后台处理时，用户通常对较长的完成时间更加宽容（因为他们不再过于追求低延迟）。这让智能体能够更专注地完成任务，而不是像在聊天界面中那样急于给出回应。

此外，后台运行的智能体能够让我们人类更高效地扩展我们的能力。聊天界面通常限制我们一次只能处理一个任务。但如果智能体在后台运行，多个智能体可以同时处理多个任务。

那么，后台运行智能体的用户体验是什么样的呢？

与后台智能体建立信任：

从“人在循环中”到“人在循环上”

要让智能体在后台运行需要建立一定的信任。如何建立这种信任呢？

一个简单的方式就是展示给用户智能体正在执行的每一步操作，并让用户随时查看这些信息。虽然这些信息不会像流式反馈那样实时显示，但应该为用户提供可以点击查看的选项。

下一步，不仅仅是让用户看到发生了什么，还要让他们能够纠正智能体的操作。如果用户发现智能体在第10步中的第4步做出了错误选择，他们应该能够回到第4步进行纠正。

这种纠正方式可以通过几种形式实现。以纠正错误调用工具的智能体为例：

1. 您可以手动输入正确的工具调用指令，使其看似由智能体生成，然后继续后续步骤。

2. 您可以向智能体提供明确的指令，告诉它如何更好地调用工具——例如，“用参数X调用，而不是参数Y”，并要求智能体更新其预测。

3. 您可以更新当时的指令或状态，并从该步骤重新运行。

选项2和3的区别在于智能体是否意识到其先前的错误。选项2是要求智能体认识到其错误并加以纠正，而选项3则是在不知情的情况下只遵循新的指令。

这种方法将用户从“在循环中”转变为“在循环上”。“在循环上”意味着智能体需要向用户展示其执行的所有中间步骤，用户可以在工作流中途暂停，提供反馈，然后让智能体继续执行。

一个已经实现了类似用户体验的应用是Devin，AI 软件工程师。Devin能够长时间运行，用户可以查看所有执行的步骤，回到某个特定时间点，并从那里进行纠正。

整合人工输入：智能体在需要时如何请求帮助

虽然智能体在后台运行，但这并不意味着它必须完全自主地完成任务。有些时候，智能体可能不知道接下来该怎么做或如何回应。这时，它需要引起人类的注意并请求帮助。

以我正在构建的电子邮件助手智能体为例。虽然它能够处理一些基础的邮件任务，但对于某些任务，我不希望自动化处理，例如复杂的 LangChain 错误报告审阅或决定是否参加会议。

在这种情况下，电子邮件助手需要一种机制向我请求信息，而不是让我直接处理回复。它希望获得我的意见，然后利用这些信息撰写邮件或安排会议。

目前，我已经在 Slack 中设置了这个助手。它通过问题通知我，我在线程中回复，轻松集成到我的工作流程中。如果这种用户体验在更大范围内应用，我会设想一个类似客户支持仪表盘的界面，展示所有需要人工帮助的任务、请求的优先级及其他元数据。

我最初将这个电子邮件助手称为“智能体收件箱”——但更准确地说，它是一个为人类帮助智能体完成任务的收件箱……这种想法令人深思。

结论

我非常看好后台运行的智能体，因为它们是帮助人类扩展自身能力的关键。

我们团队在继续构建 LangGraph 时，始终以这些用户体验为目标。我们对所有状态进行检查，轻松支持“人在循环上”的可观察性、回滚和编辑。这还使得智能体能够请求人类反馈，并在获得回复后继续执行。

Part 3：电子表格、生成和协作 UI/UX

电子表格用户体验

在过去两个月中，我看到的一种用户体验范式是电子表格用户体验。第一次见到这种方式是在今年早些时候推出的 Matrices，AI 原生电子表格。

我非常喜欢这种方式。首先，电子表格用户体验是支持批量处理工作负载的超级直观且用户友好的方式。每个单元格都可以变成一个独立的智能体，去研究特定的任务。这种批处理方式允许用户同时扩展并与多个智能体交互。

这种 UX 还有其他优势。电子表格格式是非常常见的用户界面，大多数用户都很熟悉，因此它可以轻松融入现有的工作流程中。这种 UX 对于数据丰富化尤其适用，这是 LLM 的一个常见使用场景，每列可以代表不同的待丰富属性。

从那时起，我在几个地方看到了这种 UX（Clay 和 Otto 是两个很好的例子）。

生成式 UI

“生成式 UI” 可以有多种不同的含义。

一种解释是模型生成用于显示的原始组件，即真正的生成式 UI。这类似于 WebSim 等应用程序。其背后是，智能体主要编写原始 HTML 代码，允许其完全控制显示的内容。然而，这种方法可能会导致生成的 HTML 质量不一，因此最终结果可能看起来有些粗糙或不够精致。

另一种更受限的生成式 UI 方法是通过编程将 LLM 的响应映射到不同的预定义 UI 组件上。这通常是通过工具调用实现的。例如，如果 LLM 调用了天气 API，它将触发天气图组件的渲染。由于渲染的组件并非真正生成的（而是被选择的），因此生成的 UI 会更加精致，但在可生成内容的灵活性上有所限制。

LangChain 的有一个视频系列讲了更多关于生成式 UI 的内容。请查看以下链接。

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

协作式 UX

一种较少被探讨的 UX 是：当智能体和人类一起工作时会发生什么？想象一下 Google Docs，你可以与团队成员合作撰写或编辑文档——但其中一个合作伙伴是智能体。

我心目中该领域的领先思想家是 Geoffrey Litt 和 Ink & Switch，他们的 Patchwork 项目 是人类与智能体协作的一个很好的例子。

协作式 UX 与之前讨论的环境 UX有何不同？我们的一位创始工程师 Nuno 强调了两者之间的主要区别：

主要区别在于并发性：

• 在协作式 UX中，你和 LLM 经常同时工作，互相“借鉴”彼此的工作

• 在环境 UX中，LLM 持续在后台工作，而你则专注于其他事情

这些差异也转化为构建这些应用时的不同需求：

• 对于协作式 UX，你可能需要展示 LLM 完成的细粒度工作（这可能介于单个 Token 和较大的应用程序特定工作单元之间，例如文本编辑器中的段落）。一个常见需求是自动合并并发更改的方式，类似于 Google Docs 管理实时协作的方式。

• 对于环境 UX，你可能需要总结 LLM 所完成的工作或突出显示变更。一个常见需求可能是触发由其他系统中的事件（例如通过 webhook）所启动的运行。

相关的原文链接：

LangChain 创始人 Harrison 在红杉资本的 AI Ascent 的演讲

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

Part 1：聊天

https://blog.langchain.dev/ux-for-agents-part-1-chat-2/

Part 2：环境（后台运行）

https://blog.langchain.dev/ux-for-agents-part-2-ambient/

Part 3：电子表格、生成和协作 UI/UX

https://blog.langchain.dev/ux-for-agents-part-3/

关注公众号，用极客视角洞察未来！