WebMCP 首次亮相后，网站如何把表单和 JavaScript 工具交给浏览器代理

如果一个旅行网站只能让代理“像人一样”逐个点击出发地、日期和人数，流程一长就容易卡在字段歧义和页面状态上。Chrome Developers 在 2026 年 Google I/O 文章中首次介绍 WebMCP：网站可以把结构化的 JavaScript 工具或 HTML 表单交给浏览器代理调用，但它目前仍是提案和实验性能力，不是所有浏览器都能直接使用的稳定标准。

WebMCP 改变的是调用入口，不是业务权限

WebMCP 被 Chrome Developers 描述为一种拟议的开放 Web 标准，目标是把 JavaScript 函数和 HTML 表单这样的结构化工具暴露给浏览器内的代理。以“规划多城市旅行”为例，代理可以调用一个带参数的行程查询工具，再把候选方案交给用户确认；它不应该因此获得后台 API 密钥，也不应该跳过站点已有的身份、库存和风控判断。

这个区分很重要：工具是新的入口，权限仍归业务服务端。前端能做的是把输入、返回值和可操作范围描述得更清楚，让代理少猜页面状态。

先从一个只读工具划出最小边界

新闻里的概念落到工程上，第一步不是把整个网站变成“可操作代理”，而是挑一个不产生副作用的查询任务。下面这个示例表达的是工具契约思路，具体注册 API 要以当时的 WebMCP 试验文档为准：

const searchTrips = {
  name: "searchTrips",
  description: "查询多城市行程候选，不创建订单",
  inputSchema: {
    type: "object",
    required: ["from", "to", "departDate"],
    properties: {
      from: { type: "string", minLength: 3 },
      to: { type: "string", minLength: 3 },
      departDate: { type: "string", format: "date" }
    }
  },
  async call(input) {
    const response = await fetch("/api/trips/search", {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(input)
    });
    if (!response.ok) throw new Error("trip search unavailable");
    return response.json();
  }
};

这里有三个刻意的限制。第一，工具名和描述说的是“查询”，不暗示创建订单；第二，日期和字符串长度先在边界校验；第三，返回值来自站点自己的服务端，代理拿不到内部鉴权细节。页面仍然保留普通搜索表单，不能识别工具的客户端照样可以完成任务。

表单和 JavaScript 工具适合不同的任务压力

Chrome 的介绍同时提到 HTML forms 和 JavaScript functions。两者不是二选一的品牌包装，而是两种不同的交互契约：

如果一个任务既能用表单完成，又需要代理组合多个只读数据源，可以先把表单字段整理成稳定的工具输入，再让服务端复用同一套校验。不要为了“支持代理”另外维护一套绕过页面规则的接口。

真正的难点在副作用、确认和失败回退

代理调用最容易被低估的不是参数解析，而是副作用。一个名为 createBooking 的工具会改变库存和订单状态；如果它被重复调用，哪怕接口返回结构完全正确，也可能产生重复订单。

实践中至少要把下面四道门放在工具边界附近：

1. 权限门：服务端重新校验当前用户、资源归属和操作权限，不能信任代理传来的 userId。
2. 确认门：涉及付款、发送、删除或公开发布时，先返回待确认摘要，等用户在站点界面明确确认。
3. 幂等门：写操作要求幂等键，超时重试只能查询原结果，不能盲目再次扣库存。
4. 回退门：工具不可用、参数不完整或浏览器不支持时，回到普通表单并把失败原因展示给用户。

试验阶段怎么判断是否值得接入

Chrome Developers 的公开说明提到，实验性 WebMCP origin trial 从 Chrome 149 开始，DevTools 中的 WebMCP 调试能力也仍是 experimental、默认未启用。因此接入评估要看业务结果，不要只看能不能注册一个工具。

1. 先记录普通表单流程的完成率、字段纠错次数和失败原因。
2. 只放出一个只读任务，在测试用户和可撤销数据上验证参数、超时与结果解释。
3. 观察代理是否能稳定得到结构化结果，而不是只统计“调用成功”。
4. 对浏览器不支持、工具超时、权限不足、用户拒绝确认分别做回退演练。

这个结果先别下结论。若工具调用次数上升，却没有减少人工纠错或页面中断，说明契约还不够清楚；若只读流程稳定，再考虑把“生成待提交草稿”作为下一步，而不是直接开放最终写操作。

常见问题

WebMCP 是不是已经成为所有浏览器都支持的标准？

不是。公开资料把它称为 proposed open web standard，并说明相关能力仍在实验阶段。上线前应检查目标浏览器的最新试验文档，并保留普通表单路径。

网站接入 WebMCP 后，代理能绕过登录吗？

不能把它当作绕过权限的通道。每次工具调用仍应由服务端检查会话、资源权限和风控状态。

支付和下单能不能直接交给 JavaScript 工具？

可以把候选订单或待提交草稿结构化，但最终扣款、下单、发送和删除最好保留可见确认，并用幂等键防止重试造成重复副作用。

不支持 WebMCP 的浏览器怎么办？

继续提供语义清晰的 HTML 表单、label、错误提示和提交结果。工具只是增强入口，不能成为完成核心任务的唯一入口。

判断清单：先做可验证的小闭环

适合试验 WebMCP 的任务通常是只读、参数边界清楚、结果可解释、失败可回退；不适合直接开放的任务则包含支付、删除、群发、库存扣减或不可逆状态变化。前端团队可以从一个查询工具开始，用真实表单作为基线，等代理调用稳定且用户确认链条完整后再扩大范围。