Reflex 4 月 27 日发布的一项基准测试，把同一款后台管理系统交给两类 AI 代理处理：一类通过浏览器截图、识别界面并点击按钮，另一类直接调用应用的 HTTP 端点。结果显示，在相同 Claude Sonnet、相同数据集、相同任务下，视觉代理的成本约为 API 代理的 45 倍，平均耗时约 17 分钟；API 代理约 20 秒完成。

这件事真正重要的地方，不是证明某个模型的视觉能力强弱，而是给企业内部工具的 Agent 路线选择定了一个更现实的参照。若系统本来由团队自建，继续让 AI 像人一样读页面、翻页、点按钮，可能是在用推理成本弥补工程接口的缺失。

同一后台任务下，差距来自界面而不是业务逻辑

测试应用是一个客户、订单、评论管理后台，原型参考 react-admin 的 Posters Galore demo。任务要求代理找到名为 Smith 且订单最多的客户，定位其最近一笔待处理订单，接受该客户所有待处理评论，并把订单标记为已送达。它涉及过滤、分页、跨实体查询和写入，接近客服、运营、风控后台每天会遇到的工作形态。

两条路径的差异很直接：视觉代理使用 browser-use 0.12 驱动 UI；API 代理通过工具调用访问前端按钮背后的同一批处理函数。Reflex 称，API 代理 5 次运行均为 8 次调用；视觉代理最初只处理了 4 条待处理评论中的 1 条，因为剩下 3 条在页面可视区域之外，它没有识别出还需要翻页或滚动。

项目视觉代理（Sonnet）API 代理（Sonnet）API 代理（Haiku）
步骤/调用53 ± 13 步8 ± 0 次8 ± 0 次
耗时1003 秒 ± 254 秒19.7 秒 ± 2.8 秒7.7 秒 ± 0.5 秒
输入 token约 55.1 万 ± 17.9 万约 1.2 万约 9478
稳定性波动大基本稳定基本稳定

为了让视觉代理最终完成任务，Reflex 还给它补了一份 14 步 UI walkthrough，明确侧边栏、标签页和字段的点击顺序。这部分提示工程没有体现在模型单次价格里，却是部署成本的一部分。

视觉代理的短板是结构性成本，不只是模型误判

浏览器代理的优势，是能接管没有 API 的系统。OpenAI 的 computer use、Anthropic 的 Claude Computer Use、以及 browser-use 这类项目，都在解决同一个问题：让 AI 操作已经存在的人机界面。它们适合第三方 SaaS、遗留系统、供应商后台，尤其是企业无法要求对方开放接口的场景。

但内部工具不同。一个页面为了人类阅读而设计，天然会隐藏分页、折叠表格、懒加载结果、只渲染局部状态。AI 每走一步都要看截图、理解布局、决定下一次点击。更好的视觉模型可以减少看错按钮的概率，却不能消除“必须看到每个中间页面”的成本。

API 路线则相反。结构化响应会直接告诉代理结果集、分页、字段和值。Sonnet 在 API 路径里每次都走 8 次调用，是因为返回信息约束了决策空间；视觉路径在 43 到 68 个循环间波动，则说明截图—推理—点击的闭环本身不稳定。

这里有一个原文没有展开但工程团队必须算清的变量：Reflex 0.9 能从应用 event handlers 自动生成 HTTP endpoints，降低了 API 面的开发成本。但并非所有团队都用 Reflex，也不是所有老系统都能轻松暴露干净接口。把这项便利泛化成“API 零成本”，会高估结论的适用范围。

受影响的是正在选型 Agent 架构的内部工具团队

对 AI Agent 团队和技术负责人来说，这项测试更像采购与架构评审的提醒：如果目标系统是自家客服、订单、审核、CRM 或运营后台，优先建设 REST、MCP 或工具调用层，通常比给浏览器代理写长提示更可控。

更现实的决策不是“视觉代理要不要用”，而是把它放在哪里用。可控系统优先暴露结构化接口；不可控系统再让视觉代理兜底。这个分工也符合过去 RPA 的教训：录屏点击能快速上线，但页面一改、流程一变，维护成本就会回来。

这项基准仍有边界。结果限定在 browser-use 0.12、固定小数据集，以及 Reflex 自动生成端点的实验条件下；数据规模只有 900 名客户、600 个订单、324 条评论。Haiku 未能完成视觉路径，也与 browser-use 0.12 的结构化输出 schema 适配有关，不宜简单归因于模型“看不懂界面”。

接下来最该观察的，不是 45 倍这个数字会不会被刷新，而是企业内部工具框架是否会默认生成 Agent 可读的接口层。如果 MCP、REST 工具面和权限审计能一起成为后台标配，视觉代理就会从“默认方案”退回到“不得不用的方案”。