智能体浏览器真正需要的是状态，而不是速度
Cloudflare 的 Kitesurf 让浏览器执行变得更轻、更短暂。真正的工程瓶颈转向跨运行保存状态、权限与恢复路径。
重要的不是 AI 智能体拥有了一个更轻的浏览器，而是浏览器执行已经便宜到可以随时丢弃；因此，状态连续性、权限和恢复能力才是真正的产品界面。
Cloudflare 发布的 Kitesurf 是面向智能体的浏览器，运行在 Workers 的 V8 isolate 中。Cloudflare 将它描述为无状态、可丢弃，并专门为智能体工作负载设计（Cloudflare Blog）。在 Agents Week 的总结中，浏览器也被放进“智能体云”而不是用户桌面这个语境里（Cloudflare Blog）。这传递出一个重要的基础设施信号：浏览器正在变成一种短生命周期的执行原语。
浏览器会话不再是产品本身
人类浏览默认拥有连续性：登录一次，保持标签页，发现可疑跳转时停下来，并记得已经检查过什么。智能体不会自动获得这些能力。它需要一个新鲜环境、一组范围明确的凭证、针对任务的策略，以及一份能说明发生过什么的持久记录。
Kitesurf 的设计首先解决旧浏览器栈的一个成本问题：不必为每个任务长期维持完整浏览器。一个轻量 isolate 可以按请求启动，任务结束后销毁。这有助于提高密度、减少空闲成本，也让并行浏览更容易。
但“销毁”会提出更尖锐的工程问题：什么必须留下？不需要留下整个浏览器，而应保留一组经过选择的状态：认证范围、cookie 或令牌、页面来源、提取出的事实、尚未完成的副作用，以及安全恢复所需的证据。
运营团队容易看错什么
第一个误区，是把浏览器体积当成主要障碍。Chromium 的启动成本当然重要，但真实工作流中更贵的失败通常是语义性的：智能体迷路、重复提交、遵循页面注入的恶意指令，或者说不清楚哪个页面支持了这次操作。
第二个误区，是持久化太多东西。保存截图档案或可重放的浏览器镜像看似安全，却扩大了隐私和凭证边界。持久状态应该最小化、类型明确、加密，并绑定到具体任务，而不是永久复制智能体访问过的所有页面。
第三个误区，是把“无状态执行”误解成“无状态工作”。一次性运行时只有在工作流拥有明确的交接协议时才有价值；否则，每次启动的只是一个便宜浏览器，却要付出昂贵的重新发现成本。
应该围绕什么机制设计
可以把每次浏览运行视为一个状态机，并记录四类信息：
- 意图： 任务、允许访问的域名和允许产生的副作用。
- 观察： URL、页面论断、时间戳，以及带来源的提取值。
- 提交： 准备执行或已经执行的外部动作，包括幂等键。
- 恢复： 下一次短运行可以安全继续的位置。
这比泛泛的浏览器 trace 更有用。它能区分“智能体看到了一个按钮”和“智能体有权点击这个按钮”，也让重试变得可测试。无论是结账、更新工单还是部署，系统都应该能恢复，而不是猜测上一次是否已经完成。
产品设计上，浏览器适配器应当从属于工作流账本。浏览器调用只是可替换的执行步骤；授权、证据和恢复由账本负责。这样，任务也更容易从托管浏览器迁移到本地或嵌入式浏览器，而无需重写业务逻辑。
这与网站此前讨论的智能体恢复能力和审计轨迹基础设施相连。反复出现的结论很具体：演示里最显眼的是自主性，决定运营者能否信任系统的却是可恢复性。
最实际的采用测试
在采用智能体浏览器前，刻意中断一个真实工作流。分别在认证之后、关键数据提取之后、最终副作用之前杀掉运行时，然后要求系统继续。
测量四个指标：重复动作率、安全恢复时间、必须重新读取的状态比例，以及人类能否从证据记录还原决策。这些指标通常比浏览器启动速度更能预测价值。
反方观点是，早期产品使用持久浏览器更简单，而且常常确实如此。如果任务短、风险低、只有一个租户，持久会话可能更快落地。只有当并发、隔离和失败恢复成为主要问题时，一次性执行的价值才会显现。
接下来要观察的是，智能体浏览器平台是否开始公开状态 schema、权限边界和可恢复检查点，而不只是展示更快的页面交互。现实检查很简单：更便宜的浏览器不会自动让智能体可靠，它只是让可靠性缺失的那一层再也藏不住。
阅读英文版，了解同一判断的英文版本。