TopsTip
过去，AI Agent 想替你操作一个网站，常常要像第一次上网的人那样盯着页面：认按钮、猜表单、模拟点击，页面一改版，原来的路径就可能失效。8 月 6 日，Cloudflare 给出了另一种选择：网站所有者可以在控制台打开一个开关，让浏览器里的 Agent 直接看到网站愿意开放的工具。
Cloudflare 将这项能力称为 WebMCP developer preview。它没有修改网站源站代码，而是在边缘向 HTML 响应注入一段同源 bridge 脚本，再把工具注册给支持 WebMCP 的浏览器。消息的分量不只是“部署少写几行代码”，而是它把一个更大的问题摆到台前：如果 WebMCP 被大规模采用，网站可能不再只有给人看的页面，还会有一层给 Agent 调用的操作接口。
先说清边界。WebMCP 目前仍是实验性技术。相关规范由 W3C Web Machine Learning Community Group 发布，但规范页面明确写着，它不是 W3C 标准，也不在 W3C 标准轨道上。Chrome 正在通过早期预览和试验推进实现；Cloudflare 本次发布同样只是开发者预览，不能写成全网已经进入“Agent 原生”阶段。
Cloudflare 把“给网站加工具”压缩成一个开关
按 Cloudflare 公布的实现，网站开启 WebMCP 后，Cloudflare 使用 HTMLRewriter 在边缘给每个 HTML 响应加入 bridge 脚本引用。脚本先检查浏览器是否存在 WebMCP 接口；不支持时便不执行后续动作，原页面照常工作。支持时，它会组合站点选择的工具包，并通过 document.modelContext.registerTool 注册工具。
首批预览包含两个工具包。Content Credentials 工具包可在访问者浏览器本地读取图片中的 C2PA 内容来源元数据；Cloudflare 特别说明，当前功能是读取声明，并未完成密码学验证，返回结果会标记 signatureVerified: false。另一个 Site MCP Server 工具包，可以发现站点既有 MCP Server 提供的工具，再在页面里注册代理入口。
第二种能力尤其关键。Agent 调用工具时，请求可以直接从页面发往站点同源的 MCP 端点，并带上用户现有会话。换句话说，网站不必为了 WebMCP 重写一套业务逻辑，页面也能继续呈现状态变化；Cloudflare 在这一预览中负责注入和桥接，而不是把每次工具调用都转发到自己的服务器。
Cloudflare 今年 4 月已经让云端浏览器 Browser Run 支持发现和调用 WebMCP 工具。本次更新补上了另一端：不仅让 Agent 有一台会操作工具的浏览器，也让使用 Cloudflare 的网站更容易把工具交给浏览器。一个开关打通供给与调用，正是这次发布区别于单纯规范演示的地方。
WebMCP 改变的是 Agent 理解网页的方式
今天常见的浏览器 Agent 主要依赖视觉或 DOM 自动化。它看见“搜索”按钮，推断输入框的用途，点击后再观察结果。这种方式覆盖面广，因为几乎任何网站都能尝试操作；缺点是慢、耗费模型 token，而且容易把相似按钮认错。
WebMCP 的思路更像餐厅把后厨能做的菜写成结构化菜单。网站为“搜索商品”“提交工单”或“读取内容凭证”等动作提供名称、自然语言说明、输入结构和执行函数。Agent 不必猜某个蓝色按钮是什么意思，而是按参数调用网站明确开放的能力。
这不等于 WebMCP 规定了浏览器必须使用哪一种 MCP 传输方式。当前规范说明，浏览器可以把页面工具转成 MCP，也可以使用自有的 function calling 机制。真正被标准化的重点，是页面如何声明工具、浏览器如何居中协调，以及用户和 Agent 如何共享页面上下文。
因此，WebMCP 与传统后端 API、MCP Server 不是简单替代关系。API 适合稳定的服务对服务调用；后端 MCP Server 能在没有页面的情况下提供能力；WebMCP 则贴近用户正在打开的网页，可以复用页面状态、登录会话和可视确认。未来一个成熟产品很可能三者并存。
如果它普及，网站会多出一套“代理体验”
编辑判断：WebMCP 大规模采用后，产品竞争会从用户界面扩展到代理体验。过去产品经理关心按钮是否容易找到、流程要点击几步；以后还要关心工具描述是否准确、参数是否清楚、失败能否恢复，以及高风险动作何时必须把控制权交还给人。
电商网站可能开放搜索、筛选和加入购物车，旅行平台可能开放比价和生成行程，企业软件可能开放报表、工单和权限申请。界面不会因此消失。付款、删除、发布和授权仍需要让用户理解后果，很多任务也需要人在页面中核对结果。WebMCP 更可能消灭重复导航，而不是消灭所有视觉交互。
对网站经营者，变化还会触及分发。当用户在浏览器助手里说“找一件今晚能送到的雨衣”，Agent 可能直接比较多个站点的结构化工具，而不是先访问每个首页。网站仍可能获得订单，却未必获得传统的浏览路径、广告曝光和交叉推荐机会。
这会催生一套类似搜索优化、但对象不同的工作：工具能否被发现，描述是否容易被模型正确选择，返回结果是否足够可靠，调用成本是否可控。谁来排序这些工具、平台是否偏向自有服务、网站能否知道一次调用从何而来，都还没有稳定答案。
与此同时，简单接入会降低试验门槛，却也可能把基础设施平台推到新的控制点。Cloudflare 可以在边缘注入工具包，未来还计划让工具包调用 Workers AI 或 AI Search 等服务。公司已经披露的是产品方向；至于它会不会形成新的收费层、分发入口或生态护城河，目前没有足够信息，不能当成既定商业模式。
安全问题会从“Agent 会不会点错”升级为“网站开放了什么权力”
结构化工具减少了误点，却把权限风险集中到每一次工具调用上。一个名为“退款”的函数如果没有金额限制、身份校验和二次确认，后果会比点错一个按钮更直接。网站需要把只读查询与状态变更分开，对输入做服务器端验证，并为敏感动作保留清楚的确认、撤销和审计记录。
页面里的第三方脚本也是现实风险。如果广告、分析或被入侵的依赖可以篡改工具定义，Agent 看到的能力就可能与网站所有者预期不同。当前规范讨论来源信息、权限策略和安全提示，Chrome 文档也要求开发者在上线前做安全设计与评测，但这些机制仍需要真实部署来检验。
Cloudflare 的“无需改源站代码”很适合快速试验，却不能被理解成无需安全工程。尤其是 Site MCP Server 工具包会沿用访问者会话访问同源端点，服务端仍必须判断这个用户是否有权执行动作，不能把“由浏览器发起”当成授权证明。
决定 WebMCP 能否走向大众的四个信号
- 跨浏览器支持：它能否从 Chrome 实验进入稳定版本，并获得其他浏览器厂商参与。
- 高价值工具的开放程度：网站是否只开放搜索和读取，还是愿意让 Agent 触及下单、退款和账户管理。
- 授权与责任链：浏览器、Agent 平台和网站能否让用户看懂谁将执行什么动作，并在出错后追溯。
- 真实效果：结构化工具能否在成功率、速度与 token 成本上稳定胜过视觉和 DOM 自动化，而不增加新的维护负担。
对创业者，WebMCP 值得现在试验，但不值得现在押上全部分发：先选只读、可验证、失败成本低的动作，积累调用日志和评测。对产品经理，最重要的工作不是把每个按钮包装成工具，而是重新画出产品的权限边界。
对普通用户，短期变化可能只是浏览器助手偶尔少点几步。真正重要的长期变化是，网站开始同时面向两类访客：人看页面，Agent 调工具。那时，用户需要的不只是一个更能干的助手，还要一个能清楚说明“它代表我做了什么”的浏览器。
资料来源
- Cloudflare：Give any website a WebMCP interface（2026 年 8 月 6 日）
- Web Machine Learning Community Group：WebMCP 规范草案
- Chrome for Developers：WebMCP early preview
- Chrome for Developers：WebMCP 工具安全建议
- Cloudflare：Browser Run adds WebMCP support（背景资料）
说明：WebMCP 与 Cloudflare 的相关能力均处于早期阶段。本文将已发布功能、官方规划与编辑判断分开表述，未来接口、支持范围和商业模式均可能变化。
