Cloudflare 推出的 WebMCP 开发者预览，试图解决一个现实问题：网站通常只为人类浏览器设计，而浏览器 AI 智能体需要可识别、可调用、可约束的操作接口。按照发布摘要，站点开启一个开关后即可供浏览器 AI 智能体使用，不必新增 API，也不必修改源站；与此同时，用户仍掌握操作控制权，内容创作者也能保留进入网站的流量。
它改变的不是页面，而是交互契约
传统浏览器自动化依赖 DOM、CSS 选择器和视觉识别。智能体要提交表单，可能需要猜测哪个按钮是“确认”，还要处理动态类名、弹窗和页面改版。这样的脚本既脆弱，也很难表达权限边界。
WebMCP 的价值可以理解为：在现有网页之上增加一层面向智能体的能力描述。智能体不再只看到像素和元素，而是能够识别“搜索商品”“加入购物车”或“提交预约”之类的意图及其输入。
根据发布摘要，这一层由 Cloudflare 在站点前方提供，因此部署方不必专门建设一套智能体 API，也不需要修改源站应用。这里有三个直接影响：
- 接入成本降低：已有网站可以先通过边缘层加入开发者预览，而不是等待后端团队设计新接口。
- 网站仍是交互入口：智能体通过网站完成任务，创作者不必把内容和交易流程全部让渡给第三方聚合服务。
- 控制权需要显式保留：搜索和读取可以自动执行，但购买、发布、删除或发送消息等动作应让用户确认。
“无需修改源站”不等于“无需治理”。站点仍然需要决定哪些能力可以暴露、哪些字段属于敏感数据，以及高风险动作在哪里暂停。
从浏览到行动，风险边界更重要
浏览器 AI 智能体与普通爬虫不同。爬虫通常读取页面，智能体则可能填写地址、预订服务、修改账户或触发付款。能力越强，错误调用和提示注入造成的影响越大。
上线时可以按副作用划分工具：
| 操作类型 | 示例 | 建议策略 |
|---|---|---|
| 只读 | 搜索、查看库存、读取公开文章 | 可自动执行，保留速率限制 |
| 可撤销写入 | 保存草稿、加入购物车 | 执行后向用户展示结果 |
| 外部通信 | 发送邮件、发表评论 | 执行前确认收件人和正文 |
| 高风险交易 | 支付、删除账户、提交合同 | 强制确认，并重新校验身份 |
站点还应保留常规 Web 安全措施。WebMCP 不应成为绕过登录、CSRF 防护、风控、库存校验或支付确认的新通道。智能体发起的操作最终仍需服从原有业务规则。
可以这样实践：先写一份能力治理清单
公开摘要没有给出具体配置格式，下面的 YAML 不是 Cloudflare WebMCP 的官方配置文件，而是一份可直接改造并纳入代码仓库的治理清单。它适合在打开预览开关之前，由产品、安全和工程团队共同评审。
将以下内容保存为 webmcp-policy.yaml，再按站点的真实路径、负责人和风险等级修改：
version: 1
site: https://shop.example.com
owner: web-platform@example.com
preview: true
capabilities:
- name: search_products
route: /search
mode: read
authentication: optional
confirmation: never
rate_limit_per_minute: 30
- name: add_to_cart
route: /cart
mode: reversible_write
authentication: required
confirmation: after_action
rate_limit_per_minute: 10
- name: place_order
route: /checkout
mode: transaction
authentication: required
confirmation: before_action
rate_limit_per_minute: 3
blocked_fields:
- password
- payment_card_number
- security_code
- session_cookie
observability:
log_agent_actions: true
redact_personal_data: true
retention_days: 14
rollback:
disable_switch_on:
- unauthorized_action
- confirmation_bypass
- error_rate_above_threshold
可以使用 Python 检查每个高风险能力是否要求操作前确认。下面的脚本可直接运行，需要 Python 3 和 PyYAML：
python -m pip install pyyaml
python - <<'PY'
from pathlib import Path
import sys
import yaml
policy = yaml.safe_load(Path("webmcp-policy.yaml").read_text())
errors = []
for capability in policy.get("capabilities", []):
if capability.get("mode") == "transaction":
if capability.get("authentication") != "required":
errors.append(f"{capability['name']}: authentication must be required")
if capability.get("confirmation") != "before_action":
errors.append(f"{capability['name']}: confirmation must occur before action")
if errors:
print("Policy check failed:")
print("\n".join(f"- {error}" for error in errors))
sys.exit(1)
print("Policy check passed")
PY
这段检查不能验证 WebMCP 本身的行为，但能把团队的安全约束变成可审查、可进入 CI 的规则。正式启用时，具体开关位置、支持范围和接口行为应以开发者预览所提供的产品界面与文档为准。
上线前不要只测“能不能调用”
开发者预览阶段更适合从低风险路径开始。可以选取搜索、目录查询或公开内容导航，观察智能体是否理解能力、是否仍将用户带回网站，以及页面变更后行为是否稳定。
建议至少完成以下检查：
- 使用测试账户验证登录态、权限隔离和会话过期行为。
- 对付款、删除、发布和外部通信设置人工确认点。
- 记录能力名称、参数、执行结果和失败原因，同时脱敏个人数据。
- 测试页面中的恶意文本是否会诱导智能体越权调用工具。
- 验证限流、机器人防护和业务风控不会被智能体路径绕过。
- 准备关闭开关的回滚流程，并明确告警阈值和负责人。
WebMCP 的吸引力在于，它可能让现有网站快速进入浏览器智能体的工作流，而不要求团队先重建后端。真正决定能否投入生产的，却不是开关本身，而是能力边界、确认机制、审计记录和回滚速度。开发者预览可以用来验证交互模型，但高风险交易仍应保持保守。