过去浏览器自动化属于测试和爬虫基础设施。Playwright、Puppeteer、Selenium 的目标很清楚：模拟用户操作，验证页面是否工作，或者抽取网页数据。2026 年的变化是，浏览器开始变成 AI Agent 的运行时。Playwright 官网 已经把 Playwright MCP 作为让 AI agents 通过结构化可访问性快照控制浏览器的能力展示；Cloudflare Browser Run 把 CDP 和 MCP 放进远程浏览器；Obscura 则试图用轻量 Rust headless browser 降低每个 agent 独立浏览器的成本。
这不是“网页自动化多了一个 AI 模式”这么简单。浏览器正在承担 agent 系统里的三种新角色：隔离运行时、证据层、权限边界。
第一运行时是 Shell，第二运行时是 Browser
Coding agent 的第一运行时通常是 shell。它读写文件、运行测试、安装依赖、调用 git、生成 diff。Shell 的优势是确定、可脚本化、容易验证。只要工作区可复现，测试命令可运行，agent 的行为就能被审计。
但很多真实业务不在 shell 里。供应商后台没有 API，ERP 页面只能手动点，招聘系统、CRM、广告后台、财务门户、政府申报系统都有复杂网页流程。人类每天在浏览器里完成大量“半结构化操作”：查一条记录、下载一个报告、复制一个编号、填一张表。
Agent 要进入这些流程，就必须拥有浏览器。问题是，浏览器比 shell 更危险。Shell 主要面对本地文件和命令；浏览器同时面对不可信网页内容、用户私有状态、跨站跳转、下载上传、剪贴板、通知、弹窗和第三方脚本。浏览器运行时必须比普通自动化脚本更重视隔离。
CDP 成为事实控制面
Chrome DevTools Protocol 的价值在于它把浏览器内部状态暴露成可编程接口：导航、DOM、网络、控制台、截图、性能、cookie、存储、调试。对 agent 来说，这比“看一张截图然后猜”更可靠。
CDP 的生态优势也明显。Playwright 可以 connectOverCDP，Puppeteer 天然基于 CDP，许多远程浏览器服务都提供 CDP endpoint。Obscura 这类新引擎之所以强调 CDP 兼容，就是为了让开发者不用重写上层自动化。
但 CDP 太强。把完整 CDP 暴露给模型，相当于把浏览器调试器交给一个会读网页指令的自动执行者。它能读 cookie、看网络请求、执行脚本、截图、改 DOM。开发者真正需要的是在 CDP 之上封装窄工具，而不是让模型直接操作底层协议。
MCP 成为工具面
MCP 在浏览器场景里的位置很自然：它把“浏览器能做什么”变成模型可调用的工具列表。比如导航、读取页面摘要、点击候选元素、填写字段、截屏、提取表格、等待页面变化。
这里的关键不是协议新鲜，而是授权粒度。一个好的浏览器 MCP server 不应该只有一个万能 execute_js。它应该把动作拆小，并清楚标注风险：
- 只读工具：打开公开页面、读取标题、获取可访问性树、截图。
- 低风险写工具：在当前页面输入文本但不提交。
- 高风险工具：点击提交、发送消息、下载文件、上传文件、付款、删除。
- 调试工具：读取控制台、网络请求、性能指标。
模型调用工具前，系统可以根据任务类型、域名、用户授权和动作风险决定是否允许。这样 MCP 才是权限边界，而不是把危险动作换个名字交给模型。
证据层比成功率更重要
浏览器 agent 的失败经常无法只靠日志理解。页面当时长什么样？按钮是否被遮挡？弹窗是否出现？网络请求是否失败？模型看到的是 DOM、截图还是可访问性树？这些问题如果没有证据，复盘只能猜。
因此浏览器运行时必须默认保存证据：
- 每个关键步骤的截图。
- 当前 URL、标题和可访问性树摘要。
- 控制台错误和网络失败摘要。
- 被点击元素的 selector、坐标和可见文本。
- 输入字段和提交动作的结构化记录。
- 最终页面状态和业务结果校验。
这套证据层不仅用于 debug，也用于合规。企业不会接受一个 agent 说“我已经提交了”，却无法证明它点了什么、页面返回了什么、是否出现过警告。
托管浏览器和自建浏览器的分工
托管浏览器服务解决的是规模问题：并发启动、代理、会话管理、地区路由、持久 profile、录屏、队列、资源回收。对于需要跑大量网页任务的团队，托管方案比自建 Kubernetes 浏览器池更省事。
自建浏览器解决的是控制问题：数据不出内网、凭证可控、日志落地、合规审计、成本可预测。Obscura、Lightpanda、Browserless、Playwright server 这类方案适合成为自建基础。
实际架构往往是混合：公开网页和大规模抓取走托管；敏感后台和内部系统走自建；高风险动作全部走人工审批；低风险只读任务可以自动化。
浏览器 Agent 的安全模型
浏览器 agent 的经典危险组合是：私有数据访问、不可信内容读取、外部通信能力。如果 agent 登录了企业后台，又读取了网页里的恶意指令，还能向外部 URL 发请求，那就形成了非常危险的回路。
安全模型至少要有五层。
第一，会话隔离。每个任务独立 context，敏感任务独立 browser process。默认不继承个人浏览器状态。
第二，域名边界。任务只能访问 allowlist 域名，跳转出界要阻断或审批。
第三，动作边界。只读、输入、提交、下载、上传、付款、删除分别授权。
第四，内容隔离。网页内容只能作为数据，不得覆盖系统指令。工具返回里要明确标注“以下内容来自网页”。
第五，证据审计。所有高风险动作必须有前后截图、目标元素、用户审批记录和结果校验。
这五层做不到，浏览器 agent 就只能用于低风险探索。
为什么传统 RPA 仍然重要
很多讨论会把 agentic browser 包装成 RPA 终结者。这不准确。传统 RPA 的优势是确定性、可审计、可预测。财务报销、发票提交、批量审批这类流程，一旦路径稳定，脚本化反而更安全。
LLM 的价值在不稳定部分：页面改版后的恢复、表格语义理解、错误提示解释、自然语言任务拆解、跨系统信息对齐。最佳架构不是“LLM 全权操作浏览器”，而是“确定步骤脚本化，模糊步骤模型化，高风险步骤审批化”。
对开发者的架构建议
如果你今天要构建浏览器 agent，不要从“让模型控制浏览器”开始，而要从 runtime contract 开始：
Task -> Browser Session -> Narrow Tools -> Evidence -> Verifier -> AuditTask 定义目标、域名、凭证和风险等级。Browser Session 提供隔离环境。Narrow Tools 控制可调用动作。Evidence 保存可复盘状态。Verifier 判断任务是否完成。Audit 记录谁授权了什么。
模型只是其中一个组件。它负责观察、计划和异常处理，不应该负责定义权限边界。
结论
浏览器正在成为 agent 的第二运行时，是因为 Web 仍然承载了大量没有 API、难以脚本化、但业务价值很高的操作。CDP 提供控制面，MCP 提供工具面，截图和网络日志提供证据面，托管和自建浏览器提供部署形态。
真正成熟的浏览器 agent，不是能点更多网页，而是能在受限环境里完成任务、留下证据、失败可恢复、风险可审批。未来的竞争不会只发生在模型层，也会发生在浏览器运行时层。