为什么Claude用浏览器像个喝醉的实习生，以及如何修复

我们花了几年时间构建客户支持的AI智能体。第一个版本基本上是针对支持上下文的智能搜索：文档、工单、之前解决方案、内部笔记。这种方案已经能取得不错的效果，但支持工作很快会触及产品状态。答案往往取决于客户的账户：配置、权限、计费状态，或者某个隐藏在三级菜单深处的管理员设置。因此，智能体必须检查产品，有时还要改变它。

我们一开始并不是想“构建一个浏览器智能体”，而是“智能体需要连接到API”。那么，为什么Claude用浏览器像个喝醉的实习生呢？你可能已经用过至少一个浏览器智能体，无论是Comet、Claude、ChatGPT Atlas、Browser Use还是其他。流程总是相同的：探索页面，甚至截图，找到可能的目标，移动鼠标，点击，等待，再次截图，滚动，尝试下拉菜单，从弹窗中恢复，猜测状态是否改变。我理解——这是我们能获取的信息和暴露的功能。但这极其缓慢，效率极低。

这就像让一个语音智能体通过拨打另一个语音智能体来预约理发师。技术上可行，第一次使用甚至可能觉得神奇，但一旦意识到两个系统本可以直接交换结构化数据，就显得荒谬。UI是为人类优化的：布局、标签、渐进式展示、悬停状态、响应式断点、视觉层次。这些都不是产品的实际执行模型。

在底层，前端已经在与一个结构化系统对话。一次点击变成一个请求、变更、RPC调用、WebSocket消息、服务器动作、签名请求、持久化GraphQL操作或特定于产品的命令。有输入、输出、错误、权限、副作用和状态转换。这正是智能体应该想要的接口，也是我们有MCP服务器和CLI的原因。但由于许多产品还没有MCP服务器，智能体只能盯着屏幕判断要点击哪个按钮。

显而易见的解决方案是让智能体使用UI底层的结构化接口，而非像素。一个操作可以取代十几个UI步骤。一个小脚本可以取代脆弱的点击路径。不要要求模型从截图和布局推断意图，而是给它对象、字段、方法、响应、错误和不变量。这对当前模型来说更合适——它们已经非常擅长代码、结构化数据和工具调用。而解析截图、正确点击并祈祷UI没有变化，它们的可靠性就差得多了。

因此问题似乎很简单：为什么不直接使用底层API？不那么明显的答案是：难点不在于接口不存在——UI一直在使用它——而在于该接口没有被结构化地暴露或文档化。它通常不公开，可能不稳定，且常常分散在REST端点、GraphQL操作、WebSocket消息、签名请求、WASM模块、Web Worker、客户端缓存、服务器动作和纯前端约定中。一些重要行为可能存在于请求排序、ID解析、验证响应、缓存失效或权限相关分支中。“直接使用API”跳过了智能体需要学习UI实际依赖的契约这一部分。

智能体需要知道：存在什么对象，哪些操作创建或修改它们，认证如何工作，服务器端语言如何映射到面向用户的UI语言，甚至有时状态ID取决于用户的语言（比如Zendesk）。这些信息通常只隐含地存在于前端代码、网络流量、运行时状态、缓存更新和错误处理中。因此，浏览器仍然重要——不是作为运行时接口，而是作为发现接口。

当前端执行一个操作时，它揭示了产品契约。它会获取对象、发送操作、验证输入、接收错误、更新状态。智能体可以检查源代码，观察发生了什么，并提取工作流的形状：路由、操作或消息模式，请求和响应形状，必需字段和对象关系，验证、授权和成功状态。那么，我们如何让智能体从中学习？通过构建技能。

一个简单的循环已经相当有效：给智能体自己的会话，然后告诉它根据什么有效、在什么地方挣扎以及新发现了什么来更新技能。由于这种学习跨用户进行，我们需要对敏感数据极其小心。幸运的是，我们花了三年时间研究如何让智能体从过去的支持工单中安全学习而不泄露用户数据。同样的原则适用。采用这种方法，我们目前已经积累了超过4,300个Web应用的产品特定技能集合。

这些技能包括API路径、代码片段、工作流逻辑、领域知识、有用的边缘情况以及关于产品实际行为的注释。提取过程还有很多改进空间，但即使是最简单的方法——让智能体从会话中生成有用的技能——也能取得令人惊讶的效果。一旦你有了这些技能，就几乎像拥有一个完美的MCP服务器。智能体可以直接从代码与API对话，编写执行多步骤工作流的脚本，并理解从抽象工具描述中永远无法得知的产品特定事项。

一旦这些技能跨产品存在，工作流也不再局限于一个标签页：从一个工具导出数据，转换数据，更新另一个工具，并验证结果。想象一下Claude通过计算机使用去操作VS Code，而不是Claude Code直接处理文件——这就是Pluno与其他浏览器智能体的速度差异。

我们创建了一个基准测试，它可能有点不公平，但我想不出其他方法来展示学习产品所产生的效果。我们在24个工具（包括HubSpot、Notion、Stripe、Linear等）的312个真实任务中比较了Pluno和其他浏览器智能体。比较并不公平：Pluno之前已经学习过这些产品，知道它们的API、工作流、对象模型、权限以及奇怪的边缘情况。其他智能体大多像对待新网站一样处理它们：检查页面，推断下一次点击，尝试，失败后恢复。这不是一个学术上干净的比较，但这是我们要构建的产品体验。用户不想要一个每天早晨重新发现Stripe、Notion、Linear、Salesforce或HubSpot的智能体。他们想要一个已经了解底层软件、因此快上10倍的智能体。

我们预计主要差距在于速度。直接执行避免了截图、光标移动、重试和等待页面稳定。但在可靠性上也存在巨大差异。许多浏览器智能体不仅运行缓慢，还会卡在UI中、点击到死胡同、丢失状态或放弃。界面不仅是速度的瓶颈，也是成功的瓶颈。因此，请带着这个前提看待数据：它们并不能证明Pluno在未见过的产品上更优秀，而是展示了当智能体学习了产品后，再将该知识用于下一个任务时会发生什么。

像素仍然重要的情况包括：首次探索往往需要浏览器，视觉产品需要视觉上下文，画布工具、设计工具、仪表盘、地图和模糊的工作流可能需要查看屏幕。有些产品可能不暴露可用的后端契约。有些任务需要视觉确认。重点不在于智能体永远不应使用UI，而是UI不应成为重复性SaaS操作的默认执行层。像素应该是引导层，而非运行时。

浏览器智能体缓慢的主要原因是它们使用了错误的接口。我们让越来越擅长代码和结构化数据的模型，却通过截图、按钮、下拉菜单、布局变化和弹窗状态运行。这是本末倒置。软件在UI之下已经有结构化行为。难点在于安全地将该行为暴露给智能体：学习契约、编辑痕迹、验证模式、限制权限、要求确认副作用，以及在必要时回退到视觉检查。未来的方向不是智能体更擅长点击按钮，而是它们学习UI之下的契约，然后直接使用这些契约。如果你想试一试，这里有一个浏览器扩展形式的智能体。