Kitesurf 与 WebMCP 改写浏览器 Agent：创始人的能力阶梯

Cloudflare 在 2026 年 8 月 6 日集中发布了一组面向 Agent 的 Web 基础能力。Kitesurf 是一个运行在 Workers 上、专门为 Agent 设计的浏览器引擎，不以复刻完整人类桌面浏览器为目标。另一项 WebMCP developer preview 能在边缘为网站加入同源 bridge，无需修改源站代码，就可以把结构化工具暴露给浏览器里的 Agent。Cloudflare 同时发布了下一代无状态 MCP runtime，以及更完整的“Agentic Internet”构想。

最容易得出的结论是：浏览器 Agent 终于更便宜、更可靠了。对合适的任务，这有可能成立，但这还不是上线决策。读取一次公开网页、维持十分钟登录流程、下载文件、确认付款，需要的不是同一个“浏览器”。如果所有任务都拿到最强能力，成本和权限会无谓膨胀；如果所有任务都被塞进最轻量的引擎，会留下会话中断、能力缺口和假成功。

本文写给正在决定 Agent 如何使用 Web 的非技术创始人、AI app builder 用户和小型产品团队。你将获得一套五级能力阶梯、一个决策矩阵、一个完整运营场景、六项故障测试、一份可复用的上线契约，以及 Kitesurf 或 WebMCP 不适用时的明确边界。

核心判断是：为每项用户任务选择“能完成结果并提供独立证据”的最窄 Web 接触面。“它会浏览网页”不是产品需求。

2026 年 8 月 6 日到底发布了什么

Cloudflare 的 Kitesurf 公告把它描述为一个仍处早期阶段的浏览器引擎，运行在 Workers 的 V8 isolate 上，并用 Rust 与 WebAssembly 组件处理 HTML、CSS、布局、渲染、JavaScript 执行、网络访问和 Chrome DevTools Protocol 接口。它已在 Browser Run 中开放 beta，beta 期间免费。Cloudflare 把它定位为适合 HTML 提取、截图、PDF 和兼容交互页面的短生命周期引擎。

Kitesurf 不是简单的“小号 Chromium”。Cloudflare 表示，每次页面加载都按不可信输入处理，每个页面的 cookie 放在各自 cookie jar 中，不同组件相互隔离；除公开的 Engine 外，其余组件尽量保持无状态。但 Engine 本身仍然保存会话状态。这一区分非常重要：“能无状态就无状态”可以降低重建成本，却不会让 cookie、任务进度、应用状态自动消失，更不会替团队回答“会话归谁所有”。

WebMCP developer preview解决的是交互另一端的问题。Cloudflare 能在边缘向 HTML response 注入一个同源 bridge script，再由它通过实验性的 document.modelContext 接触面注册工具包。当前一个工具包可读取页面图片中的 C2PA metadata；另一个可以发现站点已有的 MCP 工具，并用访客当前登录会话，把调用代理到同源 /mcp endpoint。

几项能力解决的问题不同。Kitesurf 给 Agent 一个更轻的环境，用来加载和理解兼容页面；WebMCP 允许愿意配合的页面主动声明动作，Agent 不必再猜按钮、字段和页面状态；MCP 提供 server-side 工具契约，有些任务根本不需要打开可见页面；当 Kitesurf 尚不支持关键浏览器行为时，完整 Chromium 仍然是必要选项。

所有发布信息都必须带上成熟度标签。Kitesurf 是 beta，Cloudflare 的 WebMCP bridge 是 developer preview，现有 Browser Run WebMCP 文档仍把相关环境标为 experimental lab session，并明确不应用于 production workload。预览期能力可以进入架构试验，但未知项必须写进上线契约。

先定义五级 Web 能力

团队常把所有网页交互都叫作“浏览器自动化”。这个词把实际购买的能力、状态和权限藏了起来。更好的做法是分成五级。

Level 1：直接请求或 quick action。 产品请求公开 HTML、Markdown、链接、截图、PDF 或结构化提取结果。没有长期存在的 tab，通常也没有点击循环。Cloudflare 的 Browser Run quick-action 指南把它用于简单、无状态任务；更复杂的自动化或持久会话则应使用 Playwright、Puppeteer 或 CDP。 Level 2：短生命周期的 Agent-first 渲染。 Kitesurf 加载兼容网页、执行 JavaScript、生成 DOM，并提供 CDP 或 REST 接口。它面向“每项任务从新环境开始，完成后立即销毁”的模式，用部分兼容性和渲染精度换取更低资源占用。 Level 3：完整浏览器会话。 通过 Playwright、Puppeteer 或 CDP 使用 Chromium，获得成熟的浏览器行为。持久登录、文件下载、视频、WebGL、困难的反机器人握手、extension 或高精度渲染往往需要这一层。代价是更多状态、资源开销和清理责任。 Level 4：页面声明的 WebMCP 工具。 页面在当前浏览上下文中向 Agent 注册带类型和 schema 的函数。Agent 可以直接调用 search_products，不必猜测搜索表单如何操作。原始 WebMCP explainer描述了注册、发现、调用、页面内执行和结构化返回的完整生命周期，也把 origin、iframe 权限、页面生命周期和动态工具列表当作 Web 原生问题。 Level 5：直接 remote tool 或 API。 MCP server 或普通应用 API 不经过 UI actuation，直接执行一项业务操作。如果产品同时拥有调用端和服务端，这通常是最清晰的路径；但认证、授权、幂等、审批与结果回执仍需单独实现。工具名有类型，不等于这些控制自动存在。

五级不是成熟度排行榜，数字更大也不代表更好。同一个 Agent 可以用 Level 1 读取公开政策页，用 Level 4 在可见登录会话里准备预订，再用 Level 5 读取稳定的内部记录。决定层级的应当是任务，而不是团队对某个工具的偏好。

选择能完成任务的最窄接触面

不要问“我们应该统一用哪一个浏览器”，而要问：这项任务必须看见什么、记住什么、改变什么、向用户展示什么，又用什么证明结果？

产品任务	最低合理层级	原因	何时暂停或升级
读取公开定价页	直接请求或 quick action	不需要登录、写入或持久状态	内容依赖尚未支持的 JavaScript，或必须核对视觉呈现
截取兼容 dashboard	先试 Kitesurf	一次性渲染可能已经够用	画面有实质差异、页面报错或需要未支持行为
在登录 portal 中跨页研究	Chromium 会话	登录、导航和状态需要持续存在	会话所有者或 credential scope 不清楚
在配合 WebMCP 的网站填表	浏览器里的 WebMCP 工具	类型化参数可替代易碎的 UI 猜测	schema 含糊、动作对用户不可见或授权无法证明
在自有系统里退款	带审批闸门的直接 MCP/API	业务动作不应依赖 CSS 或页面布局	账户、金额、权限、幂等或结果回执缺失
完成付款	浏览器或 WebMCP 做准备，人类确认	用户需要看见并确认付款边界	Agent 可绕过参数绑定的同意直接完成
下载并转交报告	未证明前使用完整浏览器	下载生命周期、文件类型、存储和清理都很重要	destination、扫描、保留周期或租户隔离未知

这张表防止两种方向相反的错误。第一种是能力膨胀：因为团队手里已经有持久且带 credential 的浏览器，就拿它去做公开网页读取。第二种是否认任务需求：把依赖长期 cookie、真实 TLS fingerprint、下载或十分钟人工暂停的流程，强行塞进短生命周期引擎。

Cloudflare 自己的 Browser Run 选择指南也从运维角度区分 quick action 与 browser session。创始人还要多做一步：把技术选择连接到产品权限与用户能看到的结果证据。

用一个供应商入驻 Agent 走完整流程

假设一家四人规模的采购创业公司 LedgerFox 正在做供应商入驻 Agent。用户输入供应商名称后，Agent 要收集公开安全资料、登录客户 portal、下载 SOC 2 报告、填写内部审核，再提交供应商审批。

原型很可能把整条流程放进一个浏览器会话里。这很容易演示，却很难治理。会话同时装着公开 Web 内容、客户 credential、下载下来的机密报告、内部审核数据和提交决定的权限。一次 prompt injection、过期登录或选错租户，就可能连续跨过多条边界。

用能力阶梯把任务拆开。

公开研究使用 Level 1。 请求供应商的安全与隐私页面，保留 source URL 与读取时间，只抽取 LedgerFox 真正需要的字段。如果 JavaScript 导致读取失败，先针对该站点试 Kitesurf，而不是立刻打开持久的客户会话。
视觉核验使用 Level 2 或 3。 如果合规 badge 或披露信息必须结合渲染后上下文理解，就保存截图以及 URL、时间、viewport 和 browser mode。若 Kitesurf 输出存在实质差异或页面依赖未支持能力，再升级到 Chromium。
Portal 登录使用 Level 3。 由人建立客户专属会话，产品把这个会话绑定到一个租户、一个 operator、一个任务和一个 expiry，绝不允许另一个客户复用。
报告下载留在 Level 3。 产品记录请求的文件、response origin、MIME type、hash、存储位置、扫描结果、所属租户和 retention deadline。“浏览器点了 Download”不算文件回执。
内部表单准备可用 Level 4 或 5。 WebMCP 工具可以在当前应用中填写可见 draft；直接 API 也可以创建未提交的审核草稿。两者都不拿到 submit 权限。
提交使用 Level 5，并放在审批闸门后。 人工确认供应商、租户、证据集、风险评级和动作。server 对不可变的精确 request 做授权，创建审核并返回 system-of-record ID。浏览器 transcript 只是辅助证据，不是最终回执。

这样一来，故障就能被限制在自己的层级。某个公开站点无法在 Kitesurf 中运行，只会影响资料研究，不会污染已登录 portal；下载中断不会被静默标成“报告已完成”；过期 WebMCP 工具也不能提交审核，因为权威动作有独立闸门。架构跟随业务边界，而不是跟随 demo 里的点击顺序。

把现有登录会话当成权限，而不是便利

Cloudflare 的 Site MCP Server preview 特别值得谨慎看待：它最大的便利，同时也是最重要的信任边界。边缘注入的 bridge 会发现站点 MCP endpoint 提供的工具，再从访客 origin、带着访客当前 session 发起调用。这样可以省去二次登录，也能保留站点 UI 状态；与此同时，工具调用很可能携带真实客户权限。

“同源”不能等同于“业务动作已获授权”。server 仍然必须验证实际生效的人、租户、角色、动作、目标、标准化参数和当前 policy。不能因为 request 带着有效 cookie，就默认它拥有相应权限。登录 account A 的客服用户，不应因为模型给了另一个 ID，就能让 Agent 操作 account B。

Chrome 的 WebMCP 文档把 WebMCP 定位为 proposed standard 和 progressive enhancement。由于工具调用由页面 JavaScript 处理，它需要 browsing context；页面既可以通过 JavaScript 主动注册工具，也可以用表单 annotation 声明工具。这些特性适合可见、理解当前状态的人机协作，却不等同于授权系统。

工具列表还会动态变化。页面导航或登录状态改变后，可能新增或移除工具。Agent 必须在关键状态迁移后重新发现工具；如果 schema 或预期版本变化，则拒绝调用。把昨天缓存的 approve_vendor 定义带到今天另一个账户，是产品故障，即使 request 在语法上完全正确。

对后果较大的动作，以下四项职责必须放在模型判断之外：

server-side 授权必须绑定准确的 principal、tenant、action、target 和 parameters；
涉及金钱、外部沟通、权限、删除或不可逆状态时，人工审批必须绑定具体参数；
response 丢失或重试时，使用幂等和 reconciliation；
由 system of record 提供最终业务状态回执。

OWASP AI Agent Security Cheat Sheet支持同样的职责拆分：最小化工具权限、验证参数、限制 permission scope、为高影响动作增加审批、记录活动，并提供中断和 rollback。结构化浏览器工具能减少界面歧义，却不能移除这些责任。

不要过度解读 Kitesurf benchmark

Cloudflare 表示 Kitesurf 已通过超过 215,000 项选定的 Web Platform Tests。它还公布了一个 14 URL corpus 上、每项 Browser Run quick action 运行五次后的中位数。在这些厂商自测中，Kitesurf 做截图和 HTML 提取时，CPU 使用量比 warm Chromium pool 低 3.1–3.8 倍，内存低 4.7–7 倍；但 wall time 慢 1.7–1.8 倍。

这些数据足以支持一次试验，不足以支持全面迁移。它们来自 Cloudflare，而不是独立 benchmark；corpus 较小，任务范围较窄，中位数也看不到 tail latency 与失败分布。Web Platform Tests 衡量标准行为，Cloudflare 自己也强调，真实网站 integration test 与 visual regression test 仍然不可少。

这组对比真正展示的是取舍，而不是赢家。对兼容且流量突发的任务，Kitesurf 可能提高密度、降低资源成本；warm Chromium 在已测任务中更快，同时覆盖更宽的 Web 行为。小团队应该测自己的“可验收结果”：

每个可验收 Web 任务成本 = 浏览器成本 + 模型成本 + 重试 + 人工恢复 + 失败动作修复

每项任务都记录成功率、p50/p95 duration、browser mode、重试、缺失元素、JavaScript error、渲染差异、会话故障、人工恢复分钟数，以及最终业务证据是否拿到。一张便宜的截图，如果还要 reviewer 重新打开 Chromium，就不能算可验收任务。

Cloudflare 明确列出 Kitesurf 当前不适用的场景：video playback、WebGL、需要真实 TLS fingerprint 的 bot-challenge handshake，以及依赖持久状态的十分钟 authenticated session。官方建议这些任务继续使用默认的 Chromium Browser Run。可以先把这些限制当作硬 routing rule，再根据自有故障数据收紧。

为下载、付款和人工接管单独设计

有三类能力后果太大，不能藏在一个笼统的“可浏览”权限中。

下载会产生新的数据对象。产品必须决定允许的 origin、文件类型、大小、扫描、存储、租户、文件名处理、保留周期、访问和删除，并区分 requested、received、scanned、rejected、stored 与 handed off。短生命周期 session 只有在文件生命周期能安全脱离它继续存在时，才真正有帮助。

文件状态应建模在浏览器会话之外。给文件稳定 object ID 和可 reconciliation 的状态迁移，即使 tab 或引擎消失也能追踪。如果 session 在收到 bytes 后、完成存储前关闭，产品应报告 received_unverified，而不是“下载完成”；如果 scanner 拒绝文件，不能因为浏览器记录过成功 network response 就让它进入可用状态。

付款与有约束力的提交需要清晰可见的承诺边界。WebMCP 工具可以用类型化参数准备购物车、quote 或 booking。Cloudflare 的 WebMCP 文档演示过等待人工确认的预订工具，这个模式有价值，但 pass 条件不是“页面出现了确认按钮”。用户必须看到实际提交的 merchant、item、amount、currency、recurring terms、account 和 cancellation rule。任何关键参数变化都会让旧审批失效。 人工接管需要连续性。人应该看到相同 URL、会话、待填写字段、工具结果和未解决决策，不应收到隐藏 credential 或含糊的成功状态。如果 Kitesurf 无法保持所需的持久 session，或不能提供必要 live view，就应在流程进入接管点之前路由到 Chromium。不要等到 checkout 或 identity challenge 才发现当前引擎无法移交控制。

每类能力都需要安全降级状态：保存 draft 但不下载、准备 transaction 但不 commit，或在输入 credential 前把任务交给人。“让 Agent 再试一次”不是恢复设计。

填写浏览器能力契约

每项产品任务单独写一份契约，不要给整个 Agent 只写一份。下面的 YAML 可以放进 AI app builder specification、workflow 文档或 release checklist。

yaml

web_job:
  name: vendor-report-intake
  user_outcome: attach one verified report to one vendor review
  interaction_level: full-browser-session
  allowed_origins: ["https://portal.vendor.example"]
  principal: "verified operator + tenant_id"
  session:
    owner: "tenant_id/operator_id/task_id"
    created_by: human
    expires_after_minutes: 20
    reusable_across_tasks: false
  inputs: [vendor_id, requested_report_type]
  reads: [portal_page, download_response]
  writes: [encrypted_review_attachment]
  prohibited: [cross_tenant_access, external_upload, auto_submit]
  download:
    mime_types: [application/pdf]
    max_mb: 30
    malware_scan: required
    receipt: [origin, sha256, scanner_result, storage_id]
  approval:
    required_for: [submit_vendor_review]
    binds: [tenant_id, vendor_id, evidence_hashes, risk_rating]
  outcome_evidence: system_of_record_review_id
  fallback: handoff_same_session_to_operator
  cleanup: close_session_delete_temp_files_revoke_task_token
  hold_if: [schema_changed, tenant_unknown, receipt_missing]

如果团队填不出 principal、session.owner、prohibited、outcome_evidence 和 cleanup，这项任务就还不适合自主浏览。先保持公开只读、只生成 draft，或由人操作。

扩大权限前先跑六项测试

使用合成账户和可逆数据。每次保存所选层级、browser engine、tool schema、session identity、请求动作、观察结果和 system-of-record 结果。

1. 兼容页面测试

把同一组有代表性的公开页面分别交给直接请求、Kitesurf 和 Chromium。比较抽取字段、JavaScript 是否完成、截图精度、console failure、wall time、重试和可验收结果。routing 根据实际兼容性，而不是产品标签。

2. 状态过期测试

让 cookie 过期、轮换 task token，并让流程闲置到超过支持时间。Agent 必须明确显示需要重新认证，不能编造已完成状态，也不能静默换到另一个账户。确认新任务无法继承旧 session。

3. 工具漂移测试

在页面状态变化前后，修改 WebMCP 工具的名称、description、input schema、可用性或返回状态。只有当 Agent 会重新发现当前工具、拒绝过期参数，而且绝不会把缓存的高影响动作带到新 context，才算通过。

4. 租户与参数替换测试

给两个合成用户不同租户权限。先让有权限的用户批准一条记录，再在执行前替换 tenant、target、amount 或 destination。即使 browser session 仍然有效，server 也必须拒绝或要求重新审批。

5. Response 丢失测试

让下游 server 接受写入后丢失 response，再重试任务。只有幂等 key 或 reconciliation 阻止重复，而且产品能从权威系统读回最终状态，才算通过。模型 transcript 不能充当证明。

6. 接管与清理测试

分别在登录、下载、审批和结果未知状态中断。验证接管的人能理解已经发生的事情，并安全继续。任务关闭后，再确认 cookie、临时文件、token、活动 browser session 和 pending action 都按文档清除或过期。

明确每种方案不适用的边界

当关键路径需要 video、WebGL、困难的 bot challenge、高精度渲染、长期 authenticated state，或站点尚未验证时，不应把 Kitesurf 设为默认。它仍然可以承担同一产品中的公开内容提取。

如果任务只是一次性公开读取，不产生外部影响，完整 Chromium 又显得过重。它带来更高成本，也让 workflow 多出 cookie、storage、network behavior 和生命周期需要管理。

当没有可见浏览上下文的价值、网站不配合，或直接 server API 才是稳定契约时，WebMCP 不是合适抽象。如果注册工具背后没有真实授权，它同样不足以上线。

当用户必须看见并操作页面状态、完成 identity challenge、检查视觉证据，或接管进行中的流程时，直接 MCP/API 也不能替代浏览器。把 UI 动作搬到不可见 server，不一定更可靠，反而可能降低透明度。

有些流程应继续由人操作。高金额付款、法律申报、受监管决策、账户恢复、身份验证，以及 rollback 含糊的动作，可能需要合资格复核和浏览器选择之外的正式控制。引擎无法把本来不可接受的业务流程变得可接受。

一套 48 小时创始人上线流程

第 0–4 小时：盘点五项真实任务。 如果产品涉及这些能力，至少选一个公开读取、一个登录后读取、一个文件传输、一个写入和一个需要人确认的动作。描述用户结果，不要只列 UI 步骤。 第 4–8 小时：分配最低层级。 每项任务从最窄的合理接触面开始，记录为什么需要 JavaScript、视觉渲染、持久状态、WebMCP 或直接 server action。不要默认让公开读取继承登录浏览器。 第 8–16 小时：填完契约。 绑定 origin、principal、tenant、session owner、inputs、reads、writes、prohibited action、approval、receipt、fallback 和 cleanup。预览期行为与厂商主张，在自有环境观察前都标为 unverified。 第 16–24 小时：建立 routing 和安全状态。 把不兼容或需要持久状态的任务从 Kitesurf 转向 Chromium，把 prepare 与 commit 分开，并提供 draft、awaiting login、awaiting confirmation、verifying、completed、failed 和 unknown-result 状态。 第 24–36 小时：运行六项测试。 使用代表性网站、合成租户、过期会话、变化后的工具 schema、被替换的参数、丢失的 response 和被中断的人工接管。衡量可验收结果与人工恢复，而不只看浏览器是否报成功。 第 36–42 小时：削减权限。 删除不需要的 origin、工具、credential、下载与 write scope，禁止不同用户和任务之间复用 session。任何关键参数变化都必须重新做决策。 第 42–48 小时：逐项做 release decision。 Kitesurf 只批准给已经验证兼容的任务；Chromium 只保留在确实需要完整浏览器行为的地方；只有 server-side 权限和可见用户状态都清楚时才启用 WebMCP 工具；高后果写入在独立回执通过前继续 hold。

创始人该做的决定

Cloudflare 这组发布让面向 Agent 的 Web stack 变得更清楚。这件事有价值，因为“浏览器 Agent”一直在掩盖几种互不相同的产品契约。

Kitesurf 为短生命周期、兼容、突发式 Web 任务提供了一个值得试验的新引擎；Chromium 仍是覆盖更广的会话接触面；WebMCP 可以在可见用户 context 中，用页面声明工具替换易碎的界面猜测；直接 MCP 与 API 则能把稳定业务动作彻底移出 UI。

没有任何一项能力会替团队解决状态、权限、证据、降级和清理。可选择的交互面越多，明确这些责任反而越重要。

不要为整个 Agent 选一个浏览器。把产品拆成任务，为每项任务选择能完成它的最小能力，只在故障证据足够时扩大。最好的 Web stack 不是“什么都能做”的那套，而是在用户依赖它之前，就能把每项能力、边界和结果说清楚的那套。

参考资料

Cloudflare，Introducing Kitesurf：运行在 Cloudflare Workers V8 isolate 上的 Agent-first 浏览器
Cloudflare，为任何网站提供 WebMCP interface
Cloudflare，下一代 MCP
Cloudflare Developers，Browser Run 入门与能力选择
Cloudflare Developers，Browser Run WebMCP
Cloudflare Developers，Browser Run Quick Actions
Chrome for Developers，WebMCP
Web Machine Learning Community Group，WebMCP explainer 与规范仓库
OWASP，AI Agent Security Cheat Sheet
Cloudflare，Building an open Agentic Internet