从「能聊」到「能干」:大模型 Agent 上手浏览器,我踩到的三个工程真问题

前一天我让一个能自己操作浏览器的 Agent 去跑掘金的每日任务,本来只是想看看它对真实站点的适配能力,结果掉进了工程细节里:真正难的不是让模型「知道该点什么」,而是让整个循环在真实前端面前不出错。这篇文章不谈模型榜单,只谈我在这条链路上遇到的几个工程真问题,以及背后各家的取舍。

一、四条路线,同一个假设

目前主流的浏览器 Agent 大致分成四类:

  • 视觉为主:Anthropic 的 computer use 属于这一类,给模型截图,输出鼠标坐标与键盘动作。优点是泛化------任何界面都能试;代价是一屏 1080p 截图动辄上千 token,坐标回归差几十像素就点空。
  • 模型内置动作空间:OpenAI 的 Operator / CUA 类方案,把「浏览与点击」当成模型的原生动作,卖点是不需要站点配合。
  • 多标签与人在环:Google 的 Project Mariner 取向,强调并行标签页与关键动作的人工确认,把不确定性包到交互设计里。
  • 结构化 DOM / 可访问性树:国内 IDE 类工具(包括字节 Trae 的 browser 能力)与大量 MCP 服务的选择:把页面上可交互的元素规整成带 ref 的列表,模型只需要说「点 e42」。

四条路线共同的假设是:模型负责感知与决策,剩下的交给工程兜底。这个假设在读的场景里基本成立,在写的场景里会碎。

二、第一个真问题:上下文不是「塞进去」,是「编排」

一屏信息流页面原样吐进模型,几十万 token 不夸张。所以快照必须做可见性过滤、文本截断、重复节点合并。这一步本质上是在赌:模型不需要看到全部也能做对。

但真正影响成本与稳定性的是顺序能不能稳定。现在各家都在用 prompt caching / KV cache 降价,一个 Agent 循环里最理想的结构是:系统提示 + 工具定义 + 历史动作 保持字节级不变,只有末尾的快照在变。一旦快照里元素顺序、id 生成方式或者属性名拖了缓存的后腿,命中率一路下降,同一个任务的成本能差好几倍。

另一个坑是长任务的记忆。会话被自动压缩一次,如果交接摘要里没写清「哪几项已经做完、分别做了几次、有什么证据」,下一轮就会重复劳动。我后来固定四段式:已完成(带数字与证据)/ 未完成 / 明确禁令 / 下一步顺序。漏在摘要里的约束,等于从来没写过。

三、第二个真问题:写操作才是可靠性的分水岭

读页面的时候,Agent 几乎不会错;一碰到写操作,问题全出来。

举一个真实的例子:社区里的「点赞」按钮本质上是一枚 svg 图标,可访问性树上既没文本也没独立节点,工具只能拿到父容器再靠偏移坐标去猜。猜偏几像素,工具层返回 success,模型记一笔「已点赞」,而后端一个请求都没收到。

真正的验证只有两条:看网络请求里 interact_api/v1/digg/save 有没有出现;看 DOM 文案从「点赞」变成「已赞」。后者成本极低,因为 UI 的状态回写就是业务成功最好的断言。

所以我的写法是:工具契约里强制要求 postcondition。没有断言的写操作,不准它自己宣布完成。同理,重试逻辑要按幂等设计------一次点不中就停,宁可任务失败,也不要「点赞 + 取消」相互抵消后白刷一个风控标记。

四、第三个真问题:风控看的是行为特征

社区类反作弊现在很少只靠验证码下结论,而是看点击分布、停留时长、滚动曲线像不像人。两次零位移的连续点击,在风控眼里比一个慢慢滚动的脚本危险得多。

这一层对技术选型的影响比想象大:如果产品把 Agent 当功能,就必须同时定义允许的自动化频率上限;否则做的不是一个功能,而是一个自动刷号的入口。未来平台与 Agent 的约定,很可能不是靠协议,而是靠谁为行为负责。

五、一点思考:Agent 不会替代前端,但会重新定义好前端

当读页面这件事交给模型,语义化 HTML 就从无障碍合规变成了 AI 可用性接口。一个带 aria-label 的按钮,在 Agent 眼里的价值比三个装饰性 div 高。反过来说,那些靠 canvas 全量绘制、没有文本快照可用的界面,在 Agent 时代会自己变成信息孤岛。

至于验证应该放在模型还是 harness,我的判断很明确:模型负责意图,harness 负责可证实的状态迁移。这也解释了为什么同一个模型在不同 Agent 产品里表现差那么多------差异不在模型层,在工具层。

六、给准备上手的人

  1. 先区分读与写:读可以尽量自动化,写必须自带断言。
  2. 快照要可缓存:元素编号、顺序、属性集尽量稳定。
  3. 失败即停,按幂等设计重试,不要补刀。
  4. 长任务一定要写交接摘要,只留结论不留证据的摘要会直接导致重复劳动。
  5. 把需要信任的动作(支付、安全确认、公开发言)显式交回给人。

模型能力会一直卷下去,但能不能进真实工作流,取决于你能否兜住它的不确定。

(本文基于一次真实的浏览器 Agent 实验,数据为当日任务页面读数。想听听大家:你们公司的业务流程里,哪一个环节你敢交给 Agent,哪一个绝对不给?)

相关推荐
吴凡wudianmei2 小时前
从 0 搭一个 AI Agent(四):SSE 跑通之后,三处“契约错配”与它们的修复边界
前端·后端·aigc
李小轰_Rex4 小时前
零开销 AI 数字人方案|Live2D 数字人驱动方案分享
前端·aigc
Sayai5 小时前
让动漫角色复刻真人动作!MiniMax H3 动作控制实战:一段视频驱动角色动画(12G 显存,附模型下载)
人工智能·aigc·音视频·comfyui·动作捕捉·minimax
Dawson Zhu6 小时前
【Runtime推理引擎④】多流并发执行:用Stream+Event让计算与通信重叠
人工智能·语言模型·架构·aigc·agi
AI创界者10 小时前
【AI生视频本地部署】最新 MiniMax-H3 全模态生成模型本地部署与极致优化:N卡 6G 显存流畅跑、无审查加速完整工作流实战
人工智能·aigc·音视频
rich_Chan.10 小时前
【2026 实操】bl vision describe 批量照片核验教程:六字段清单、视频时间轴、三个解析坑与兜底
人工智能·ai·aigc·音视频
柳杉11 小时前
用 Codex 魔改卡神开源的 AIHOT,我做了个 3D 技术雷达
前端·aigc
技灵AI11 小时前
AI 开箱视频怎么做?用创意开场带出商品展示
人工智能·prompt·aigc
小和尚同志20 小时前
54.6k star 的 Multica: 集多 Agent 和看板于一体的 AI 平台
人工智能·aigc·three.js