很多团队讨论浏览器 Agent 风险时，注意力往往集中在“它会不会乱点按钮”上：会不会误发消息、会不会点错提交、会不会被 prompt injection 诱导去做不该做的写操作。这个担心当然合理，但如果只盯着最后那一下点击，还是会低估真正的风险起点。因为在很多真实系统里，风险在执行动作之前就已经出现了——它发生在 agent 附着到用户现有浏览器，并开始枚举标签页的那一刻。
为什么 tab discovery 本身就敏感？因为用户浏览器不是一个空白容器，而是装满上下文的工作现场。里面可能同时开着公司后台、客服工单、财务页面、私有知识库、管理控制台、localhost 调试面板，甚至还保留着多个系统的登录态。对人来说，“看见有哪些标签页”像是一件很自然的事；但对 agent 来说，这其实已经是在读取高密度权限环境的结构信息。它不需要真正点进某个页面，光是知道这些页面存在、标题是什么、属于哪些域名，就已经足以暴露敏感上下文，并改变后续推理路径。
更麻烦的是，很多自动化流程默认把几种能力混在一个上下文里：先读公开网页，再复用同一个浏览器上下文去访问已登录系统，接着跨站跳转、抽取内容、最后执行写操作。这样一来，所谓“读能力”并不真的只是读。它会把不可信输入、登录态、跨 origin 导航和外部副作用重新接到同一条链路上。问题不只是模型可能理解错，而是它理解错之后，仍然站在一个过度授权的环境里继续行动。
所以更可靠的默认设计，不该是“先 attach 再说”，而应该把 attach 视为一种特权模式。公开网页检索与摘要，优先放在隔离上下文里完成；只有当任务明确需要登录态时，才进入附着浏览器；而且最好限制 origin 范围，避免顺手枚举现有标签页。到了写操作阶段，还要再加两道硬边界：写前把目标对象和内容回显出来，写后再读回结果确认。这样做的核心不是让 agent 更保守，而是让能力范围和动作后果保持可解释、可回放、可审计。
未来浏览器 Agent 真正的竞争力，未必是谁更像人，而是谁更懂得克制。能把“附着浏览器”从默认能力降级为受控特权，把“读上下文”与“做动作”清楚拆开，才更有资格进入真实工作流。