Chrome WebMCP 要不要接入现有网站：工具接口、授权边界与失败回退

Chrome 在 Google I/O 2026 展示 WebMCP 后，很多团队第一反应是把现有 REST 接口接给浏览器里的智能体。但真正难的不是“能不能调用”，而是要不要把某个动作变成工具、调用前检查什么、失败后怎样退回人工页面。更稳妥的做法是先挑一个低风险、可撤销的查询动作，给它设计清晰的输入输出和授权边界，再用试验环境验证。

WebMCP 更像一层面向浏览器智能体的工具接口约定，不是把后端 API 批量公开的开关。先收敛动作，再控制权限和回退路径，才适合进入 origin trial。

WebMCP 这次变化，真正影响的是接口边界

Chrome 官方把 WebMCP 描述为一种让网站向浏览器智能体暴露结构化工具的提议方向，工具可以对应 JavaScript 函数或 HTML 表单。公开信息里还提到，实验性 origin trial 从 Chrome 149 开始，Chrome DevTools 149 已出现相关调试能力，但第三方工具和 WebMCP 调试仍不是默认开启的稳定能力。

这意味着团队现在面对的是接口设计问题，而不是一次普通的前端升级。把“查询库存”暴露成工具，和把“提交退款”暴露成工具，风险等级完全不同；前者可以重复，后者涉及金额、身份和审计。

先从一个不会改变数据的动作开始

假设电商后台有一个“查订单物流状态”的页面。页面原本通过 GET /api/orders/{id}/tracking 获取结果，用户需要登录，服务端会检查订单归属。这个动作适合做第一批试验：它有明确输入，结果可重复，调用失败时仍能回到订单页面。

工具层不应该直接复用一串模糊参数，可以把边界写得更清楚：

const tool = {
  name: "查询订单物流",
  description: "根据当前登录用户可访问的订单号查询物流节点",
  inputSchema: {
    type: "object",
    properties: { orderId: { type: "string", minLength: 8, maxLength: 32 } },
    required: ["orderId"]
  }
};

这里的 description 是给调用方理解动作的线索，不是权限声明。订单归属、登录状态、请求频率和数据脱敏都必须在服务端再次判断，不能相信浏览器传回的工具名称或参数描述。

参数、返回值和错误码要让调用方能做下一步

一个只返回“成功/失败”的工具，很快会把智能体逼回页面点击。建议把结果拆成状态、可读摘要和可继续处理的字段：

{
  "status": "in_transit",
  "summary": "包裹已到达杭州转运中心",
  "updatedAt": "2026-08-12T09:40:00+08:00",
  "nextAction": "等待下一节点",
  "traceId": "tr_7f2c"
}

错误也不要只返回 500。参数不合法、没有订单权限、物流供应商超时和工具版本不支持，分别对应不同的下一步：

涉及写入、付款和权限变更的动作先别直接开放

“创建售后单”“修改收货地址”“发放优惠券”都不是查询动作。它们至少需要一次确认，最好拆成预览和提交两个步骤：第一次只生成待确认内容，第二次由用户在原页面明确点击后提交。这样即使调用方重复请求，也不会把一次网络重试变成两笔业务。

同样要留意幂等键、审计日志和 CSRF 防护。WebMCP 只改变调用入口，不会替你解决业务一致性；工具请求仍然要走既有身份体系、权限中间件和风控策略。

用 origin trial 做小范围验证，保留三条观测线

试验阶段可以只对内部测试账号开放一个工具，并记录工具发现、参数校验、服务端执行和页面回退四类事件。日志里至少保留工具名、账号类型、结果码、耗时、traceId 和回退原因，不要记录完整订单地址或令牌。

验收时看三个结果：调用方能否理解工具的输入输出，服务端是否在未授权时稳定拒绝，用户是否能在异常后继续完成原任务。如果只能证明“工具被调用了”，还不足以说明接口设计合格。

常见问题

WebMCP 现在适合直接用于生产提现吗？

不建议把实验性能力当成稳定生产依赖。可以先把工具契约、权限和回退页面准备好，用内部账号验证，等浏览器支持范围和规范形态更明确后再扩大。

现有 REST API 能不能直接变成 WebMCP 工具？

可以复用后端业务能力，但不要直接暴露原始 API。工具需要面向调用方重新整理名称、参数、返回值和错误模型，服务端鉴权与审计仍然照旧执行。

最适合第一个试验的动作是什么？

优先选只读、可重复、数据敏感度低且能回到原页面的动作，例如订单状态查询、知识库检索或报表筛选。

把“能调用”变成“可控地调用”

WebMCP 的价值不在于替网页增加一个神奇入口，而在于把用户任务表达成结构清晰、权限可核验、失败可恢复的工具。先做一个查询动作，给它配好输入约束、错误分流、观测字段和人工回退，再决定是否继续扩展到写入操作，这条路线更容易在试验期获得真实结论。