人机共用浏览器时，智能体为何反复清空表单

让 AI 代理操作你已经登录的浏览器，遇到验证码时再由你接手，听起来很顺。作者却发现，代理会反复重开页面，把人刚填的表单、刚过的验证码一起清掉，多个代理还可能争抢同一个标签页。

作者给出的解法，是在真实浏览器前面加一层 broker，约束标签页归属和危险操作，再要求代理每次行动前重新读取页面。它值得关注的地方，是把「人和多个代理怎么共用浏览器」拆成了具体规则；但这些规则的实际效果，原文没有给出量化验证。

为什么你刚填完，代理又把页面重开了

10 月 22 日晚，作者让 AI 代理帮忙退出数据经纪商和人员搜索网站的信息收录。代理运行在作者日常使用的 Brave 中，里面已有各种账号的登录状态。作者也在旁边使用同一个浏览器，准备处理验证码或必须由真人完成的点击。

问题出在交接过程。

代理在隐藏的工作页面和展示给人的可见页面之间切换，两份页面的状态却不互通。只要觉得情况不对，代理就重新展示页面，而展示又触发重新加载。作者刚完成的验证码和表单因此被清空。有代理还把确认链接打开在已经提交过的页面上，任务结束后也没清理标签页。

更麻烦的是，代理没有在操作前查看页面的当前状态。它依赖几步之前的观察，于是在人看来已经完成的表单，在代理的记忆里仍然等待处理。

页面状态已经变了，代理却还在执行旧计划。

多代理并发又放大了问题。原文提到，Cursor 论坛也有人反馈多个代理共用标签页、互相覆盖导航。按作者转述，Cursor 将其称为已知限制，并建议一次只让一个代理使用浏览器。这个办法能减少冲突，但也牺牲了作者想保留的并行能力。

把标签页分开，为什么还不够

作者已有一个开源项目 browser-agent，分成 agent 和 broker 两部分。agent 在作者自己的 Mac 上运行，驱动真实的 Brave；broker 位于浏览器调试端口前，负责分配和限制访问。

可以把 broker 理解为浏览器操作的门卫：每个代理拿到自己的标签页，不能查看或占用其他代理及用户的标签页，也不能把浏览器窗口强行拉到用户面前。

但当晚的故障说明，标签页隔离只解决了「谁能动哪个页面」，还需要解决「这个页面现在能怎么动」。作者随后增加了几类规则：

• 一个任务从头到尾使用同一个标签页。需要人接手时，展示现有标签页，不再打开同一页面的副本。
• 每次点击或输入前，重新读取页面当前状态。用户已经完成验证码或表单时，代理应从这个进度继续。
• 任务进行中禁止重新加载或关闭页面。这条由 broker 在代码里阻止，不只依赖代理遵守提示。
• 卡住时用一句话询问用户，不再通过重开页面重试。
• 任务结束后关闭相关标签页。隐藏工作页在代理释放时关闭，展示给用户的页面在任务完成后关闭。

这些规则分别对应不同故障：页面复用避免状态分叉，操作前读取减少过时判断，代码拦截保护人工输入，结束清理则防止标签页持续堆积。

代理负责判断下一步，broker 负责限制哪些动作可以执行。

项目以 MIT 许可证发布，仓库名为 nicedreamzapp/browser-agent，broker 位于同一仓库的独立目录。作者称，broker 接管端口 9222 后，已有工具仍可连接原来的端口。不过，原文没有展开具体协议兼容范围，不能仅凭端口不变就认定所有工具都能直接适配。

我的判断

我认同作者把部分约束放进代码里的做法。「不要刷新用户正在填写的页面」如果只写进提示词，仍然需要代理在每次决策时记住；由 broker 拦截，才有明确的执行边界。对共享浏览器来说，这比单纯要求模型更谨慎更有说服力。

但「每步操作前读取页面」也有局限。读取与点击之间，用户仍可能继续操作，页面也可能异步更新。原文没有说明如何处理这段时间里的变化，也没有给出任务结束的判定方式。中途禁止刷新能保护输入，遇到页面确实需要刷新才能恢复时，又该如何放行，同样没讲清。

此外，文章给出了故障经历和改造规则，却没有提供改造后的成功率、冲突次数或对照实验。它是一套针对真实问题的工程经验，还不能据此判断并发协作已经稳定。

替代方案也各有位置。一次只让一个代理操作浏览器，更容易控制；给代理单独的浏览器环境，能减少与日常工作的相互干扰，但可能需要重新处理登录。作者的方案更适合「必须复用现有账号，而且需要人随时接手」的任务，这也是它最明确的使用前提。

能拿来做什么

• 如果你正在写浏览器代理或 Node 自动化工具，可以先明确任务与标签页的对应关系，让人工接手继续使用原页面，避免为展示进度额外导航或复制页面。
• 在表单和验证码流程中，把重新读取页面放到点击、输入之前，并识别用户已经完成的步骤，减少重复提交和从头执行。
• 把刷新、关闭、跨标签页访问等操作集中到控制层处理，同时定义任务进行中和任务结束后的不同权限。
• 如果现有 AI 编程工具已经出现争抢标签页，可以先限制浏览器任务串行执行；确实需要并发时，再评估标签页隔离和操作拦截是否覆盖了实际冲突。