本文是 LangChain 博客上关于智能体系列的第五、第六和第七篇文章,重点探讨了智能体交互模式这一关键主题。本系列由三篇核心文章组成:第一篇深入分析了 聊天模式(流式与非流式)的优缺点;第二篇探讨了 后台智能体 的概念以及如何建立用户信任;第三篇则介绍了 表格、生成式和协作式 这三种新兴的交互模式。通过本系列文章,读者可以全面了解当前智能体交互设计的最新趋势,并为构建更有效、更人性化的智能体应用获取灵感。
智能体的交互模式(一):聊天模式
本文改编自作者在红杉资本 AI Ascent 大会上关于智能体(Agent)的演讲(演讲视频请见此处)。本文将深入探讨智能体的交互模式。感谢 LangChain 的创始工程师 Nuno Campos 提供了许多最初的想法和见解。
智能体的交互模式涉及诸多方面,本主题将分为三篇系列文章。这是系列的第一篇。
人机交互(Human-Computer Interaction)已经是一个研究多年的领域。我相信在未来几年,人-智能体交互(Human-Agent Interaction)也将成为一个关键的研究领域。
与传统计算机系统相比,智能体系统由于其延迟性、不确定性和自然语言界面的特性,面临着全新的挑战。因此,我相信,与这些智能体应用交互的新型 UI/UX 范式将会不断涌现。
尽管智能体系统尚处于发展初期,但已经出现了多种交互模式。本文将重点讨论目前最为流行的交互模式:聊天。
流式聊天
"流式聊天"是目前最主流的交互体验模式。简而言之,流式聊天是指智能体系统以聊天形式,实时反馈其思考过程和行动。ChatGPT 是最典型的例子。这种交互模式看似简单,但效果显著,原因如下:
训练大型语言模型(LLM)的主要方式是使用自然语言。在聊天中,用户可以直接通过自然语言与 LLM 交互,这意味着用户和 LLM 之间几乎没有障碍。
💡 在某种程度上,流式聊天就像早期计算机的"终端"。
终端(尤其是在早期计算机中)提供了对底层操作系统更直接、更底层的访问。随着时间的推移,计算机转向了更多基于 UI 的交互。流式聊天可能与之类似:它是我们与 LLM 交互的第一种方式,提供了对底层 LLM 相当直接的访问。未来可能会出现其他的交互模式(就像计算机变得更加基于 UI 一样),但低级别访问具有显著优势,尤其是在早期阶段。
流式聊天的一大优点是能够缓解 LLM 处理任务时的延迟。流式传输让用户可以准确了解系统内部的运作。用户可以实时查看 LLM 执行的中间过程,包括其采取的行动、行动的结果,以及"思考"时生成的 tokens(即模型处理文本的基本单元)。
流式聊天的另一优势是,当 LLM 出现偏差或错误时,聊天界面提供了便捷的纠正和引导途径。我们已经习惯了进行后续对话,并在聊天中迭代地讨论问题。
当然,流式聊天也有缺点。首先,流式聊天是一种相对较新的交互模式,现有聊天平台(如 iMessage、Facebook Messenger、Slack 等)并未内置此模式。其次,对于长时间运行的任务,这种方式略显不便:难道用户要一直等待并观察智能体的运行吗?第三,流式聊天通常需要由用户触发,这意味着用户仍然深度参与整个流程。
非流式聊天
"非流式聊天"这个称呼可能有些陌生,因为两年前我们通常直接称之为"聊天"。但现在为了区分不同交互模式,我们使用了这个称呼。非流式聊天与流式聊天有许多相同属性:它将 LLM 直接呈现给用户,并且允许用户进行自然的纠正。
非流式聊天最大的区别在于响应是以完整的批次返回的,这一点有利有弊。主要的缺点是用户无法看到系统内部的处理过程,对具体细节知之甚少。
但是……这样真的可以吗?
Linus Lee 最近关于"委托"的观点(参见链接)颇具启发性。其中一个片段是:
我故意将界面构建得尽可能不透明。
他认为,不透明的界面需要一定程度的信任。但一旦建立信任,用户就可以直接将任务委托给智能体,而无需进行微观管理。这种异步性也有利于长时间运行的任务,这意味着智能体可以为用户完成更多工作。
假设建立了信任,这似乎是件好事,但也带来了其他问题。例如,如何处理"重复发消息"?用户发送一次消息,智能体开始处理,但在智能体完成之前,用户又发送了包含不同(有时甚至不相关)想法的消息。在流式聊天中,由于智能体持续输出信息,用户通常无法输入新内容,从而避免了这个问题。
非流式聊天交互模式的一个好处是更贴近我们现有的交流习惯,因此更容易集成到现有工作流程。人们习惯了给他人发消息,为什么不能轻松适应与 AI 交流呢?
💡 非流式聊天的另一个显著优点是,允许 AI 有更长的响应时间。
这通常是因为非流式聊天更融入我们现有的工作流程。我们不会期望朋友立即回复消息,那为什么又要期望 AI 这样做呢?这使得与更复杂的智能体系统交互更便捷,因为这些系统通常需要一段时间来处理。如果用户期望即时响应,可能会感到沮丧。非流式聊天通常消除了这种期望,让完成更复杂的任务变得更轻松。
总而言之,虽然流式传输在早期阶段更具优势,但随着用户对智能体系统信任度的提升,非流式聊天模式也可能迎来新的发展机遇。
除了聊天还有更多吗?
由于这只是三部分系列文章的第一篇,我们相信除了聊天之外,还有更多交互体验值得探讨。不过,值得强调的是,**聊天是一种非常好的交互模式,**它被广泛使用是有原因的。
聊天的优点:
- 允许用户直接与模型交互
- 允许轻松进行后续提问和/或更正
流式聊天与非流式聊天的优缺点
特性 | 流式聊天 | 非流式聊天 |
---|---|---|
优点 | 让用户看到智能体的工作进展;通过展示中间步骤,增强用户信任感; | 用户对即时响应的期望更低,智能体可以处理更多任务;更多现有应用支持非流式模式 |
缺点 | 现有应用大多不支持流式传输 | 用户难以了解底层运行情况;需要处理"重复发消息"问题(用户在智能体完成前再次输入); |
原文地址:UX for Agents, Part 1: Chat
智能体的交互模式(二):后台模式
本文是关于智能体 (Agent) 用户体验系列文章的第二篇,重点关注后台智能体。本文基于作者在红杉资本 AI Ascent 大会上的演讲(演讲视频见此处)。
在上一篇关于基于聊天的智能体交互模式的文章中,我们讨论了聊天如何要求用户主动与 AI 交互。但如果 AI 可以在后台为你工作呢?
我认为,要充分发挥智能体系统的潜力,就必须实现这种转变,让 AI 在后台运行。当任务在后台处理时,用户通常更能容忍较长的完成时间(因为他们降低了对低延迟的期望)。这使得智能体可以更专注、更细致地完成更多工作,效果往往优于聊天模式。
此外,在后台运行智能体可以更有效地扩展人类的能力。聊天界面通常一次只能处理一项任务。但如果智能体在后台运行,就可以有 多个 智能体同时处理多个任务。
那么,这种后台智能体的交互体验会是什么样子呢?
构建与后台智能体的信任:从"人在环路中(Human-in-the-loop)"到"人在环路上(Human-on-the-loop)"
让智能体在后台运行需要一定程度的信任。如何建立这种信任?
一个直接的思路是向用户展示智能体的确切行为。显示 它采取的所有步骤,让用户观察正在发生的事情。虽然这些信息可能不会像流式响应那样直接可见,但应该允许用户点击查看和观察。
下一步不仅是让用户 看到 正在发生的事情,还要让他们能够 纠正 智能体。如果用户发现智能体在 10 个步骤中的第 4 步做出了错误的选择,他们应该能够返回第 4 步并以某种方式纠正智能体。
这种纠正会是什么样子?可以有几种形式。让我们以一个具体例子来说明:纠正一个错误调用了工具的智能体。
- 你可以手动输入正确的工具调用,就像智能体输出了那样,然后从那里继续。
- 你给智能体明确的指示,告诉它如何更好地调用工具(例如,"使用参数 X,而不是参数 Y"),并要求智能体 更新 其预测。
- 你可以更新智能体在该时间点的指令或状态,然后从该步骤 重新运行。
选项 2 和 3 之间的区别在于智能体是否意识到之前的错误。在选项 2 中,智能体看到了之前不理想的生成结果并被要求纠正它;而在选项 3 中,它不知道自己的错误预测(只是遵循更新后的指令)。
这种方法将人从"人在环路中(Human-in-the-loop)"转变为"人在环路上(Human-on-the-loop)"。"人在环路上"需要能够向用户展示智能体采取的所有中间步骤,允许用户在工作流程进行到一半时暂停,提供反馈,然后让智能体继续。
AI 软件工程师 Devin 就是一个实现了类似交互体验的应用。Devin 会运行很长时间,但你可以看到它采取的所有步骤,回退到特定时间点的开发状态,并从那里进行更正。
整合人类输入:智能体如何在需要时寻求帮助
虽然智能体可能在后台运行,但这并不意味着它需要完全自主地执行任务。有些时候,智能体不知道该做什么或如何回答。这时,它需要引起人类的注意并寻求帮助。
我的一个电子邮件助理智能体就是一个很好的例子。虽然它可以回复基本的电子邮件,但它经常需要我就某些我 不想 自动化的任务提供意见。这些任务包括审查复杂的 LangChain 错误报告、决定我是否想参加会议等。
在这种情况下,电子邮件助理需要一种方式来告诉我它需要信息才能回复。请注意,它不是让我直接回复,而是寻求我对某些任务的意见,然后它可以利用这些意见来撰写和发送一封得体的电子邮件或安排一个日历邀请。
目前,我已经在 Slack 中设置了这个助理。它会向我发送一个问题,我在一个主题帖中回复它,这自然地融入了我的工作流程。如果我要考虑比我自己的电子邮件助理更大规模的这种类型的交互体验,我会设想一个类似于 客户支持仪表板的交互界面。这个界面将显示所有需要人工帮助的领域、请求的优先级以及任何其他元数据。
我最初在描述这个电子邮件助理时使用了"智能体收件箱(Agent Inbox)"这个术语,但更准确地说,它是 人类 协助智能体完成某些任务的收件箱…… 这想法有点让人不寒而栗。
结论
我非常看好后台智能体,因为我认为它们是让我们能够扩展自身能力的关键。
我们的团队在构建 LangGraph 时,也考虑到了这些类型的交互体验。我们对所有状态进行检查点,轻松实现 "人在环路上"的可观察性、回退和编辑。这也使智能体能够 联系到人类 并在继续之前等待他们的响应。
如果你正在构建具有后台智能体的应用程序,请联系我们。我们很想了解你的经验!
原文地址:UX for Agents, Part 2: Ambient
智能体的交互模式(三):表格、生成式和协作式 UI/UX
本文是关于智能体 (Agent) 用户体验系列文章的第三篇,重点关注表格、生成式和协作式 UI/UX。本文基于作者在三月红杉资本 AI Ascent 大会上的演讲(演讲视频见此处)。
这是我关于智能体用户体验的第三篇文章,但我可能还可以再写十篇 -- 在我们探索构建和与智能体交互的最佳方式时,有太多东西值得探索。智能体的 UI/UX 领域是我最感兴趣的领域之一,我将密切关注未来几个月的创新。
为了总结关于智能体 UI/UX 的讨论,我将重点介绍三种最近变得越来越流行但相对小众的交互模式,其中每一种都值得单独写一篇文章(以后可能会写!)。
表格 (Spreadsheet) 交互模式
过去两个月左右,我经常看到的一种交互模式是表格模式。我第一次看到这种模式是在今年早些时候,AI 原生表格应用 Matrices 发布的时候。
看到这个我很兴奋。首先,表格交互模式是一种非常直观且用户友好的方式来支持批量操作。每个单元格都成为它自己的智能体,去研究特定的内容。这种批量处理允许用户扩展并与多个智能体同时交互。
这种交互模式还有其他好处。表格形式是一种大多数用户都非常熟悉的常见交互模式,因此它非常适合现有的工作流程。这种类型的交互模式 非常 适合数据扩充(data enrichment),这是一个常见的 LLM 用例,其中每一列可以代表一个不同的属性来进行扩充。
自那以来,我看到这种交互模式在一些地方出现(Clay 和 Otto 是两个很好的例子)。
生成式 UI (Generative UI)
"生成式 UI" 的概念可能有几种不同的含义。
一种解释是真正的生成式 UI,其中模型生成要显示的原始组件。这类似于 WebSim 等应用。在底层,智能体主要编写原始 HTML,从而可以 完全 控制显示的内容。然而,这种方法允许生成的 HTML 质量存在很大差异,因此最终结果可能看起来有点粗糙或不完善。
另一种更受约束的生成式 UI 方法涉及以编程方式将 LLM 响应映射到不同的预定义 UI 组件。这通常通过工具调用来完成。例如,如果 LLM 调用天气 API,则会触发天气地图 UI 组件的渲染。由于渲染的组件不是真正 生成 的(而是更多地被选择),因此生成的 UI 将更加精美,但在生成内容方面灵活性较低。
你可以在我们的视频系列中了解有关生成式 UI 的更多信息,点击这里。
协作式 UX (Collaborative UX)
一个较少被探索的交互模式:当智能体和人类一起工作时会发生什么?想象一下 Google Docs,你可以在其中与团队成员协作编写或编辑文档 -- 但不同的是,你的合作者之一是智能体。
在我看来,这个领域的领先思想者是 Geoffrey Litt 和 Ink & Switch,他们的 Patchwork 项目是人和智能体协作的一个很好的例子。
协作式交互模式与之前讨论的后台交互模式相比如何?我们的创始工程师 Nuno 强调了两者之间的主要区别:
协作式和后台模式的主要区别在于并发性:
- 在 协作式交互模式 中,你和 LLM 通常同时工作,互相"提供"对方的工作成果。
- 在 后台交互模式 中,LLM 在后台持续工作,而你(用户)则专注于完全不同的事情。
这些差异也转化为构建这些应用时的不同需求:
- 对于 协作式交互模式,你可能需要显示 LLM 正在完成的细粒度工作片段。(这介于单个 token 和更大的、特定于应用程序的工作片段之间,例如文本编辑器中的段落)。一个常见的需求可能是有一种自动合并并发更改的方法,类似于 Google Doc 如何管理实时协作。
- 对于 后台交互模式,你可能需要总结 LLM 完成的工作或突出显示任何更改。一个常见的需求可能是通过其他系统中发生的事件(例如通过 webhook)触发运行。
为什么我们要考虑这个问题?
LangChain 并不是一家以 UI/UX 为中心的公司。但我们花了很多时间思考这个问题。为什么?
我们的目标是让构建智能体应用尽可能简单。人类如何与这些应用交互 极大 地影响了我们需要构建的基础设施类型。
例如,我们最近推出了 LangGraph Cloud,这是我们用于大规模部署智能体应用的基础设施。它具有多种流模式,支持"重复发消息"用例,以及异步后台运行。所有这些都直接受到我们看到的 UI/UX 趋势的影响。
如果你正在构建具有新颖或有趣的 UI/UX(例如非流式聊天)的应用程序,我们很乐意通过 hello@langchain.dev 与你联系!
原文地址:UX for Agents, Part 3: Spreadsheet, Generative, and Collaborative UI/UX
LangChain 智能体系列文章: