很多团队讨论浏览器 Agent 风险时，第一反应通常都是“它会不会乱点按钮”。这当然是问题，但如果注意力只停在最后那一下点击，往往会错过真正更早发生、也更容易被低估的风险起点：agent 连接到用户现有浏览器的那一刻。
为什么这一步值得单独拿出来说？因为浏览器不是一个空白执行容器，它更像是一个已经被权限、上下文和业务状态填满的工作现场。里面可能同时开着公开网页、公司后台、客服工单、财务页、私有知识库、管理控制台，甚至还有本地 localhost 面板和多个系统的登录态。对人来说，“看看现在开了哪些标签页”像是一件很自然的小事；但对 agent 来说，这其实已经是在读取一个高密度权限环境的结构信息。
这也是为什么我越来越不认同“先 attach，再决定要不要做事”这种默认设计。因为 attach 本身就不是中性的。只要 agent 开始做 tab discovery，它就可能知道用户此刻正在处理什么系统、接触哪些数据、有哪些内部域名、哪些页面仍保持登录状态。它甚至不需要真正点进这些页面，这些上下文已经足以影响后续判断，并在日志、截图、摘要或错误回显里形成额外暴露面。
更常见、也更糟糕的问题，是工程实现里喜欢把几种本该分开的能力混在同一个长生命周期上下文里：先读公开网页，再顺手复用同一浏览器去看已登录系统，接着跨站跳转、抽取内容、最后执行写操作。这样一来，所谓“读能力”并不只是读，它会把不可信输入、登录态、跨 origin 导航和外部副作用接到同一条链路上。真正的风险不只是模型会不会理解错，而是它一旦理解错，仍然站在一个过度授权的环境里继续行动。
更稳的默认方案应该反过来：公开网页读取优先放在隔离上下文里；只有任务明确需要登录态时，才进入 attach 模式；而 attach 应被视为特权升级，不是默认入口。到了写操作阶段，还应再加两道硬边界：写前把目标对象和 payload 回显出来，写后再读回结果确认。这样做不是为了让 agent 变笨，而是为了让系统的能力范围、责任边界和事故半径都更清楚。
未来浏览器 Agent 的成熟度，未必取决于谁更像人，而更取决于谁更懂得克制。能把“连接浏览器”从默认能力降级成受控特权，把“看见上下文”和“对外动作”认真拆开，才更有资格进入真实工作流。