跨国深谈← 返回←为什么99%准确率的浏览器智能体还是会失败

为什么99%准确率的浏览器智能体还是会失败

关联

人物 Derek Meegan

公司 Browserbase

概念 浏览器智能体 · 智能体 · 工具调用 · 计算机使用 · 无障碍树 · 可观测性 · 模型成本 · 反机器人机制 · 技能 · 重试

浏览器智能体的演示总是很惊艳：在一个网站上跑一次，你在旁边盯着，一切顺利。

但生产环境完全不同——成千上万次无人值守的运行，网站随时会变，模型也可能状态不佳。

Derek Meegan 是 Browserbase 的软件工程师，这场演讲回答了一个核心问题：演示和生产之间，到底差了什么。

智能体是怎么“看”网页的

可以把模型的输出理解为一种概率分布：

模型收到输入（页面状态、目标、已执行的步骤），在所有可能的动作中挑出最可能的一个，转成结构化的工具调用，再去操作浏览器。

但浏览器本身很复杂，有好几层接口：

进出的网络请求、页面的 HTML 文档树、截图、无障碍树（一种页面的语义化文本描述），以及底层的动态代码执行环境，可以直接写 JavaScript 去控制浏览器。

业界主要有三种接法：一是把页面转成文本表示；二是靠截图让模型像人一样“看”屏幕操作；

三是越来越流行的做法——去掉定制工具，让智能体直接对浏览器写任意代码 。

为什么说“没有部分分”

问题的核心在于一种不对称：成本是持续累积的，价值却只在最后一步兑现。

智能体每走一步，都在增加成本，也累积失败的风险。但只有整个任务从头到尾完成，你才拿到价值。付账单付到 99% 等于没付。

用 Meegan 的话说，浏览器智能体“没有部分分” 。

一个思想实验说明了问题有多严重：假设每一步的独立成功率是 99%，听起来很好。但如果一个任务要 100 步，整体成功率只剩约 36% 。

这就是为什么单纯换更强的模型不够。

先想清楚：智能体到底给你什么

在算细账之前，Meegan 提醒大家回到一个简单的公式：利润等于收入减去成本。

你的智能体只是账上的一行，它给你的必须多于它拿走的。

在 Browserbase 的场景里，客户往往不是为自己自动化，而是替他们的用户在网上执行操作。

所以浏览器智能体真正给你的，是反复可靠地替客户完成任务的能力 。

衡量这个系统，按重要性排三个维度：性能、成本、可维护性。

其中性能是关键——一旦确认智能体能完成任务，成本和可维护性就都变成了优化问题，而优化问题是可以靠工程手段解决的 。

成功要留下“证据”，而且要允许重试

成功的定义要具体：一次运行应该留下一个可查证的产物。

付账单是确认邮件，下单是订单号或收据，提交表单是系统里新增的一条记录 。

衡量成功率也有讲究。单次运行成功率 50% 的智能体，如果允许每次交易最多重试 4 次，按交易计算的成功率就能升到 94% 。

客户不在乎你重试了几次，只在乎任务是否可靠完成。所以：允许重试，按交易而非按运行来算成功率。

风险从哪来：网站会反扑，任务会漂移

即使系统跑起来了，还有几类风险。

环境会反抗——反爬虫机制处处针对自动化；任务本身会变；模型天生的不确定性意味着它可能偏离关键路径 。

还有一个经典困境：如果你今天在自动化某个网站，明天对方开放了官方接口怎么办？

Meegan 的判断是，对绝大多数浏览器智能体的用例来说，官方接口短期内不会来 。

实战：一次医保门户自动化是怎么搭起来的

演讲最精彩的部分是一个真实例子：自动化一个健康保险门户，登录并下载一份福利说明文件。

系统的演进分几步，每步都在砍掉模型不必要的责任。

一开始只有最简的智能体。

然后发现下载文件涉及和页面的程序化交互、还要从存储里取回文件，干脆把这些封装成一个工具调用，不用模型临场决策 。

接着给智能体一个校验工具，用文字识别确定性地提取文件里的信息，和系统记录比对——智能体从此能权威地知道自己做对了没有 。

再往后，注意到登录流程永远不变，就把认证逻辑从模型手里抽出来，做成独立函数。

步骤更少、成本更低、性能更好，还能在同一个门户的多个业务流程里复用 。

最后，为剩下真正有模糊性的部分写一份“技能”——类似过去给人类用的标准操作流程，只不过是给智能体的。

回到开头概率分布的比喻：智能体知道自己在第二步，也知道下一步该做什么，歧义就从决策过程中被移除了 。

最终的系统是：

请求进来，独立的认证函数先登录浏览器，智能体按技能文档导航门户，调用确定性的下载函数，再用校验工具确认成败。

整个设计的原则就是：把不需要模型负责的步骤，统统从模型手里拿走。

本集带走

• 浏览器智能体没有部分分：成本逐累积，价值只在终点兑现，每步 99% 的成功率跑 100 步只剩约 36%。
• 按“交易”而非“单次运行”衡量成功率，允许重试——50% 单次成功率加重试可达 94%。
• 成功要可验证：每次运行应留下具体产物，如确认邮件、订单号、新记录。
• 性能是第一位的；确认能完成任务后，成本和可维护性都是可工程化的优化问题。
• 架构的核心思路是做减法：把确定性步骤（登录、下载、校验）封装成工具和函数，只让模型处理真正模糊的部分。

这一切是说，你的智能体只是又一个账目项目，你的智能体应该带给你的多于它索取的。
And this is all to say that your agent is just another line item and that your agent should give you more than it takes.
—— Derek Meegan · [06:40]

然而，如果你允许该智能体针对某笔交易进行重试，也许最多四次重试，你的每笔交易成功率会迅速攀升到 94%。
Yet, if you permit that agent to retry for a particular transaction, maybe up to four retries, your per transaction success rate quickly climbs to 94%.
—— Derek Meegan · [08:58]

客户并不一定在乎你执行了多少次重试，而是在乎工作流是否成功且可靠地完成了。
The customer does not care necessarily how many retries you perform, but rather that the workflow was completed successfully and reliably.
—— Derek Meegan · [09:16]