这两天我把掘金的每日掘友分任务丢给一个能自己操作浏览器的 Agent 跑了一遍------它读页面、点按钮、翻文章、写评论，全程没人碰键盘。结论有点扎心：**这类 Agent 用来「读互联网」已经相当能打，用来「写互联网」还处处漏风。**把踩的坑记下来，顺便聊聊大厂这套 Agent 路线的工程取舍。
一、几家产品的路线其实惊人一致
Trae、Cursor 的 browser 模式、Anthropic 的 computer use、OpenAI 的 Operator，名字不同，骨架是同一个循环：
text
页面可访问性树 / DOM 快照 -> 压缩成结构化元素(ref) -> 喂给模型
模型输出工具调用(click / type / navigate) -> 执行 -> 把新快照回灌 -> 下一轮关键工程决策有三个：
- 不给模型像素坐标，给它元素编号。视觉方案(纯 screenshot + 坐标)在 1080p 的密集列表页上命中率低得可怜；换成可访问性树的 ref 之后，定位可靠性至少好一个数量级。代价是快照要压缩------一屏掘金首页原样喂进去轻松几十万 token，所以必须做可见性过滤和截断，这一步本质上是在赌「模型不需要看到全部也能做对」，
- 工具契约即提示词。每个工具的 description 是模型唯一的操作手册，手册里写清楚「一次点击不中就停，不要重试第二次」，比任何事后兜底都有效，
- 执行结果必须回灌。只发指令不看回包的工具循环，最后一定会「自以为完成」。
二、「点击成功」不等于「业务成功」
这是这次最贵的一课。
点赞按钮在 DOM 里是一枚 svg 图标，可访问性树上既没有文本也没有独立节点，只能拿到父容器 ref，再用父容器左上角 + 偏移去猜坐标。猜偏了几像素，点到的就是「举报」旁边的空白。工具层返回 success，模型高高兴兴记一笔「已点赞」，实际后端一个请求都没发出去。
真正的验证只有两条：看网络面板里 interact_api/v1/digg/save 有没有出现，看 DOM 文案从「点赞」变成「已赞」。后者尤其便宜------UI 的状态回写就是业务成功的最好断言。
所以我的建议是：给 Agent 的每一个写操作，都必须自带一条 postcondition。没有断言的写操作，不要让它自己宣布完成。
三、风控专治各种重试
两次偏掉的点击各自打了一次请求，一次点赞、一次取消，净效果为零，但在风控眼里是「无位移的高频交互」。于是 digg/save 被拦，页面弹出「当前操作失败，可点击申诉」。
这里有个反直觉的点：人类写的重试逻辑，在风控看来是攻击特征。把一个幂等操作写成非幂等重试，是最常见的自伤。正确的改法只有三条：
- 一次点不中立即停，绝不补第二下，
- 触发拦截就先冷却，再降频（把间隔从 2-5 秒拉到 8-10 秒），
- 出现验证码，整轮终止，交回给人。
顺带一个观察：社区类产品的反作弊，越来越像是「行为几何学」------不看你有没有说自己是机器人，只看点击分布、停留时长、滚动曲线像不像人。
四、真正的瓶颈是上下文，不是模型
跑到一半，会话被自动压缩了一次。压缩后的交接摘要里如果没写清「哪几项已经做完、做了几次、有什么证据」，下一轮就会把点赞再点一遍------直接超额，甚至触发风控。
摘要四段式救过一次场，分享给同样在写 Agent 编排的人：
- 已完成（带数字与证据）；2. 未完成；3. 明确禁令（比如「不要重试」）；4. 下一步顺序。
漏在摘要里的约束，等价于从来没写过。模型很聪明，它只是会忠实地按你给它的世界模型行动。
五、人机边界怎么划
跑完之后我的划分是这样的：
| 适合自动化 | 需要人把关 | 建议直接人工 |
|---|---|---|
| 读状态、批量浏览与滚动、有文本锚点的表单填写 | 发布内容（合规、语气、事实性） | 无锚点的图标按钮、支付与安全确认、验证码 |
值得注意的是第二列：**凡是会产生「你在公开场合说了什么」的动作，都应该保留人的签名。**不是技术做不到，是责任不该外包。
六、给准备上手的人一份清单
- 优先给模型结构化意图（ref / 语义锚点），别让它猜坐标；
- 每个写操作强制断言，失败要能被机器分辨；
- 按幂等设计重试，宁可停下也不要补刀；
- 上下文压缩时保留「已完成清单 + 禁令」，比保留代码细节重要；
- 需要人判断的节点显式交回给人，别偷偷替用户按下发布键。
最后一点感受：这代 Agent 的能力上限，其实不在模型推理，而在验证机制的下限。它读得多准决定它能走多远，它能否承认自己没做成，决定它能不能被放进真实的工作流。