WebMCP：公开网站工具，让代理停止抓取DOM

网站原本是为人类点击、表单填写以及 API 接口而设计的。如今，所谓的“用户”往往可能是从不接触可视化用户界面的 AI 智能体。那些通过抓取 DOM 树或操作浏览器来工作的智能体，一旦标记结构发生变化就会失效。WebMCP（Web 模型上下文协议）是在 Chrome 生态系统中提出的，其目的是让网站能够直接向智能体暴露结构化的工具——包括工具名称、输入参数、输出结果以及调用时机——从而使自动化操作变得明确而非需要推测。

什么是 WebMCP？

简而言之，WebMCP 允许页面发布面向智能体的工具，而无需依赖抓取工具能准确猜中操作方式。

在没有 WebMCP 的情况下，智能体只能针对不透明的用户界面临时应对：

AI Agent → Reads HTML → Guesses → Clicks → Hopes it works

而使用 WebMCP 后，同样的操作意图就能转化为明确的工具调用：

AI Agent → Reads structured tools → Executes correctly

Chrome 的文档将这一优势描述为提升智能体交互的速度、可靠性和精确度。

WebMCP 诞生的原因

考虑预订酒店吧。那种脆弱的流程需要打开页面、查找输入项、解析日期、点击搜索并处理结果——在DOM结构变动时极易出错。而使用WebMCP后，代理可以调用结构化的操作：

searchHotels({
 location: "Tokyo",
 checkIn: "2026-08-10",
 checkOut: "2026-08-15",
 guests: 2
})

无需进行XPath查询，也不用依赖CSS选择器，更不需要为常规流程设计复杂的视觉路径——只需直接执行指令即可。

WebMCP的工作原理

它包含两个互补的API：

1. 命令式API

JavaScript会明确注册各种工具：

navigator.webMCP.registerTool({
  name: "create-event",
  description: "Creates a calendar event",
  inputSchema: {
    type: "object",
    properties: {
      title: { type: "string" },
      date: { type: "string" }
    }
  },
  execute: async ({ title, date }) => {
    return await createCalendarEvent(title, date);
  }
});

代理能够获取工具的名称、功能、所需输入以及执行路径——前端逻辑被转化为可调用的功能模块。

2. 声明式API

以HTML为核心，尤其适用于表单处理：

<form webmcp-tool="book-flight">
  <input name="from" />
  <input name="to" />
  <input name="date" />
</form>

运行时会将表单转换为结构化的工具，这样现有应用只需稍作标记修改即可与代理兼容。

WebMCP与MCP的区别

混淆是很常见的现象。一个实用的区分方式是：WebMCP面向前端界面；而MCP则针对后端系统与服务。可以这样理解：MCP相当于服务器端的“大脑”，WebMCP则是UI层面的“躯体”。二者结合便能实现全栈的智能工具功能，无需依赖脆弱的浏览器自动化操作。

实际应用场景

1. 电子商务

顾客希望找到价格在预算范围内的运动鞋并完成支付。可使用的工具可能包括：

searchProducts()
filterProducts()
addToCart()
applyCoupon()
checkout()

智能代理无需在各种界面间反复点击即可完成整个流程。

2. 旅游预订

通过工具搜索航班、比较酒店、预订地面交通、添加保险服务，而非依靠不稳定的宏命令。

3. SaaS控制面板

分析功能界面可以展示诸如以下操作：

generateReport()
downloadCSV()
inviteMember()
changeBillingPlan()

应用内的辅助功能随后会以按钮形式呈现给用户，调用与人类所见相同的操作功能。

4. CRM系统

无需经过十级界面点击：

createLead()
assignSalesRep()
scheduleFollowUp()

5. 客户支持

可通过经过验证的工具来取消订阅、申请退款及追踪货物，而非依靠复杂的HTML结构。

为什么开发者应该关注

前端工作从“绘制像素”转变为“为客服人员提供工具”。职责重点转向清晰的命名、完善的架构以及可靠的执行。功能设计的前后对比不再像是：

Build components for humans

而是更像：

Build components for humans + machines

最佳实践

让工具具备单一功能

避免功能过于杂乱的功能整合：

manageEverything()

优先选择专注型工具：

createInvoice()
sendInvoice()
downloadInvoice()

明确的定位能提升客服的准确度。

使用清晰的名称

模糊的标签：

doTask()

能体现功能的名称：

submitExpenseClaim()

降低认知负担

不要强制模型预计算应用已经知晓的信息。应避免：

durationInMinutes

最好接受后端能够标准化处理的原始输入：

startTime: "10:00"
endTime: "12:00"

优雅地处理故障

智能体应会重试，相关工具在重试过程中必须保持安全——幂等性至关重要。

安全问题

如果智能体能够执行工具，恶意脚本注入虚假工具便成了一个需要研究的问题。可采取的缓解措施包括来源验证、注册审核、权限限制，以及让用户确认可能产生的副作用。切勿盲目信任注册信息。

更宏观的视角

WebMCP隶属于更广泛的智能代理网络：网站公开自身功能，代理能够理解这些功能，人们可以委托任务，从而加快工作进度。团队已经在为开发者构建API，接下来的发展方向则是为代理提供工具。那些率先提出“这款应用的哪些部分应该转化为AI工具？”的先行者，将塑造下一波网页架构的发展趋势——就如同REST、GraphQL、WebSockets以及服务器组件从小众技术逐渐成为标准一样。这项技术尚处于早期阶段，但其发展方向不容忽视。

现有应用的采用路径

首先使用声明式 API 标记一个高价值表单或结账步骤，通过与旧抓取工具的对比来衡量操作员的工作效率，然后为需要自定义验证的流程扩展命令式工具。在支付和可能破坏账户状态的更改操作上，仍需人工确认机制，直到监控数据表明这些操作具备安全的幂等性。应将工具架构视为公共 API：审核其名称、为其版本控制，并拒绝来自不可信脚本的注册请求。