跳到主要内容

4 篇博文 含有标签「agent-ux」

查看所有标签

异步智能体需要收件箱,而非聊天框

· 阅读需 12 分钟
Tian Pan
Software Engineer

对话隐喻有一个引信,大约在 30 秒左右就会燃尽。超过这个时间,加载动画不再是进度指示器,而变成了一种承诺机制——做出承诺的是你的用户,而他们中的大多数人都会选择放弃。你可以在会话回放中看到这一幕:正在输入指示器出现,用户等待,在 12 秒左右切换标签页,其中一半人再也没有回来。产品团队看到一个已完成的 Agent 运行,而另一端没有人类在场,便将其记录为一次成功。这不叫成功。这是一个碰巧完成了的、被遗弃的产物。

这是一个结构性问题的初步显现,大多数 Agent 产品都用加载动画和流式文本来掩盖它:对话界面是为回合制的人类和快速模型设计的,当这两个前提中的任何一个失效时,它就会悄无声息地失败。如果你的 Agent 需要几分钟才能运行完,那么你交付的就不是一个等待时间较长的对话功能。你交付的是一个不同的产品,它需要一种不同的 UI 原语。

对话分支作为一等公民:为什么线性线程迫使用户不断杀死并重启对话

· 阅读需 12 分钟
Tian Pan
Software Engineer

你的聊天产品需要分支功能的最明显信号,往往也是最容易被忽略的:用户不断地将旧对话复制粘贴到新的会话中。他们不是在更换供应商,也不是因为无聊。他们是在尝试询问“如果我早点反驳那个假设会怎样?”,同时又不想丢失花费了 40 轮对话建立的上下文。线性线程只为他们提供了两个选项——要么覆盖下一条消息并丢失原始回复,要么开始新聊天并丢失前置内容。于是,他们利用剪贴板发明了第三种方案。

每当用户这样做时,你的产品就在通过这种变通方法泄露一个功能需求。这个变通方法很糟糕:它剥离了消息元数据,破坏了工具调用(tool-call)的联动,丢失了文件附件,并产生了不再映射到连贯任务的孤立线程。但它之所以存在,是因为另一种选择——放弃花费 30 分钟建立的上下文——更糟糕。对话在结构上是一棵树,而 UI 却坚持它是一个列表。用户只能手动填补这个鸿沟。

温和交接模式:设计智能体与人类之间的流畅控制权转移

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数智能体升级流程都是披着善意外衣的冷转接。智能体决定无法继续推进,丢下一句"正在为你转接人工客服",然后将会话路由给一个对此前发生的一切一无所知的坐席——不知道智能体尝试了什么、哪里失败了、用户究竟需要什么。人工客服从零开始,用户不得不重复自己。信任就此侵蚀——不是因为 AI 出了错,而是因为没有人设计好那个边界。

温和交接模式是一套架构规范,专门针对智能体让渡控制权的那个关键时刻。它将这个边界视为系统的一等关注点,而非事后诸葛。做好了,接收方——无论是人类还是另一个智能体——都能进入一个已经被充分告知、结构清晰的场景。做差了,那个边界就是用户信任的坟场。

为什么你的智能体 UI 体验糟糕(以及如何修复它)

· 阅读需 13 分钟
Tian Pan
Software Engineer

你已经发布了一个性能卓越的 Agent。底层模型很强大 —— 它能检索到正确的上下文,调用正确的工具,并生成连贯的输出。然后你观察一个用户第一次尝试它,整个会话就崩溃了。他们不知道 Agent 什么时候在工作,看不出它是否理解了自己的意思。他们会在任务执行中途打断它,因为长时间的沉默感觉像是死机了。他们最终选择了放弃,并拨打你的支持热线。

模型不是问题所在,界面才是。

这是工程师在构建第一个 Agent 产品后不断重新发现的模式:人机交互(human-agent interaction)层本身就是一门工程学科,而大多数团队都将其视为事后才考虑的事情。他们在检索质量和工具准确性上花费了数月时间,然后直接接一个聊天框作为界面,并奇怪为什么即使后端日志显示成功,产品用起来还是感觉不可靠。