趋势变化

网站正试行向代理开放工具层

Cloudflare在开发者预览中推出WebMCP，试图让网站无需新建API或改造源站即可被浏览器代理调用。变化仍处于早期，但网站的代理可发现性开始成为独立接入变量。

By All We Need Editorial System

Cloudflare推出WebMCP开发者预览，称网站可通过一个开关向浏览器AI代理提供可用接口，而无需新增API或改造源站。这一变化尚不足以证明WebMCP会成为通用标准，但它把“网站是否可被代理发现和调用”从浏览器实验能力，推进为云平台可部署的产品选项。

接入位置开始前移

Cloudflare称，WebMCP可让网站在保留人类控制权和流量归属的前提下，向浏览器AI代理暴露可调用能力。其此前Browser Run文档显示，相关支持仅存在于使用Chrome 146 Beta的实验性lab sessions，且明确不适合生产工作负载。如今进入开发者预览，改变的是能力的部署位置：代理接口不再只由浏览器试验或单个应用承担，网站运营者可在边缘平台层尝试配置。

机制是把页面能力转成受约束工具

WebMCP的设想不是让代理任意操作网页，而是由网站声明可发现工具及其交互边界，代理在已访问的网站上下文中发现并调用这些能力。Google把它描述为proposed web standard，并在Chrome 149提供origin trial和本地开关；其设计还要求可见浏览器上下文、origin isolation和Permissions Policy。若这些约束被主流平台采用，网站可把原本隐含在页面流程中的操作，转换为更明确的代理工具接口。

分发机会伴随权限治理重写

对商家、SaaS和内容平台而言，代理工具层可能减少为不同助手重复建设专用集成的需求，并使确认、身份和工具调用记录成为新的产品能力。最强反例是安全边界尚未成熟：Google警告，代理在已认证会话中处理恶意工具描述或受污染输出时，可能遭遇间接提示注入、越权操作或数据泄露。现有社区文本也明确不是W3C标准，跨浏览器互操作性仍待验证。

接下来关注什么

下一步可观察三个信号：Chrome或其他浏览器是否扩大正式支持；Cloudflare是否披露采用网站、调用量和生产级权限控制；以及网站是否发布可审计的工具确认、撤销和跨域限制机制。若开发者预览长期停留在单一平台、没有跨浏览器实现或实际商家部署，WebMCP作为通用接入层的判断将被削弱。

信源