浏览器智能体真正的门槛，是状态连续性

重要的不是浏览器智能体会不会“点按钮”；重要的是它能不能把一个任务一路做完，因为真正难的不是单次动作，而是页面变化、登录中断、权限跳转之后还能不能接着做。

这个判断在最近的产品动向里越来越清楚。OpenAI 的 Codex changelog 里，很多更新都不是炫技式能力，而是围绕标签页恢复、项目排序、远程 SSH、后台 agent 交接这些“续航问题”做修补。换句话说，厂商自己也在承认：浏览器智能体首先要变得可靠，才谈得上聪明。再看 OpenAI 关于 agentic work 的新文章，它强调越来越多用户请求正在对应人类要花 30 分钟以上才能完成的工作。这种任务天然不是“一次点击就结束”，而是要靠持续状态、阶段性回收和可恢复执行。

很多人对浏览器智能体的理解还停留在“LLM + Chrome”。这个理解太窄了。真正能上生产的浏览器智能体，更像一个带语言模型的状态机。它要知道自己现在在哪个页面，哪些表单已经填过，哪个登录步骤已经过了，哪些数据已经抓到，哪些动作可重试，哪些动作一旦重复就会出错。只要其中一环不稳，演示可能很惊艳，真实工作却会很脆。

所以，今天竞争的核心已经不是“第一下点得准不准”，而是“断掉之后能不能接上”。很多时候，能稳定恢复上下文、保留会话、记录步骤证据、在失败后继续执行的产品，反而比一次成功率看起来更高但无法续跑的产品更有价值。买单的人并不是在买一次动作，而是在买“少盯着它”的能力。

这里有个很容易被忽略的机制：浏览器环境天生不友好。会话会过期，弹窗会打断流程，DOM 会变，验证码会出现，标签页会漂移，不同账号权限也不同。智能体不是只需要推理能力，它还需要一层连续性基础设施，把浏览器当成一个会不断失真的运行环境来处理。这意味着状态分层、动作日志、重试规则、证据保留和明确的人工接管点。

这也是为什么很多“agent”产品最后会长得像工作流平台，而不是聊天窗口。真正有用的不是模型自己多会想，而是它能不能把想法放进一个可恢复的执行链里。只要这个链条存在，模型的价值就会被放大；只要链条断裂，再强的模型也容易退化成一个会说话的演示器。

对团队来说，第二层含义更重要：如果浏览器智能体的本质是状态管理，那么产品重点就该从“提示词写得好不好”转向“状态怎么管”。哪些状态可以保存，哪些动作可以自动重试，哪些步骤需要 checkpoint，哪些证据必须可追踪，哪一步必须交给人。这里不是合规装饰，而是产品是否真正可用的分水岭。

这也会重新定义“更好的模型”到底意味着什么。模型在规划和恢复判断上仍然重要，但边际收益越来越来自模型外面的东西：会话持久化、标签页恢复、工具调用日志、按账号隔离的记忆、可回放的执行轨迹。也就是说，真正的壁垒不只是推理质量，而是能让推理穿过混乱网页环境的运营层。

对构建者最实际的建议很简单：先盯住浏览器状态边界，再去优化提示词。把会话丢失、登录失败、恢复耗时、重复执行、敏感动作重放这些指标先量起来。问自己一个问题：这个智能体能不能从 checkpoint 继续跑，而不会重复危险或不可逆的动作？如果答案不清楚，那你做出来的还不是一个成熟的浏览器智能体，而只是一个容易坏的 demo。

这也是今天读 agent 产品节奏时最值得记住的地方：前沿问题不是“它能不能做”，而是“网页把流程搅乱以后，它还能不能继续做”。

English companion: Browser Agents Are Becoming State-Management Products.

Related angle: Agentic AI Browser Automation Platforms.