【调研】WebMCP：让网页把能力交给 Agent
内容提要
WebMCP 是让网页将业务能力注册为结构化工具、供 AI Agent 直接调用的浏览器 API，由 W3C WebML 社区组孵化，Chrome 已进入 Origin Trial。它支持声明式与命令式两种接入方式，工具具有生命周期，需采用窄 Schema 与稳定命名。主要风险包括提示注入、权限错配与跨源边界问题，需通过服务端授权、审计和预览确认来兜底。目前 Safari 和 Firefox 尚未支持，宜作为渐进增强，先试点只读低风险操作。
延伸解读
WebMCP 与 MCP 的定位差异
文章明确区分了 WebMCP 与 MCP：MCP 连接 Agent 与后端服务、数据库或本地进程，适合后台任务、跨系统集成和无头运行；WebMCP 则面向当前打开的网页，让 Agent 在已登录页面内调用页面注册的工具。两者并非替代关系，而是互补。WebMCP 的优势在于直接复用页面状态、登录会话和可见 UI，适合人与 Agent 在同一上下文协作的场景。
工具生命周期与并发设计要点
WebMCP 的工具不是静态清单，而是具有注册、注销的生命周期。用户登录、切换项目或路由变化时，可用工具会动态调整。规范通过 AbortSignal 和 toolchange 事件支持这一机制。开发时需注意：工具执行中可能被取消，页面卸载或调用方取消时前端应停止请求并清理状态；toolchange 事件来自独立任务源，消费方收到后应重新读取工具快照，避免缓存不一致。
安全风险与分层建议
文章指出 WebMCP 的主要风险包括提示注入、权限错配和跨源边界问题。工具描述、输入 Schema 和返回内容都可能成为注入入口。工具注解如 readOnlyHint 只能作为风险信号，不能替代服务端授权。建议按风险分层：只读操作限制字段与行数；可逆修改记录前后值并提供撤销；提交/发布先预览再确认；高影响操作早期不开放。首个工具应只读、可审计且返回内容有限。
标准现状与落地策略
WebMCP 由 W3C WebML 社区组孵化，当前为 Draft Community Group Report，并非 W3C 标准。Chrome 已进入 Origin Trial，Edge 实验性支持，但 Safari 和 Firefox 尚未支持，存在成为 Chromium 专用能力的风险。因此应将其视为渐进增强，保留人工 UI 和传统回退方案。生产团队宜将工具合同放在业务层，浏览器注册层保持轻薄，以便 API 变化时只需调整适配层。
Q&A
WebMCP 和 MCP 有什么区别？
MCP 通常连接 Agent 和后端服务、数据库或本地进程；WebMCP 面对的是当前打开的网页，让页面把业务能力注册为结构化工具供 Agent 调用。两者不是替代关系：MCP 适合后台任务、跨系统集成和无头运行；WebMCP 更适合人与 Agent 在同一个已登录页面里协作。
WebMCP 支持哪两种接入方式？
支持声明式和命令式两种。声明式 API 给标准表单用，站点在表单、输入框上标 toolname、tooldescription 等属性，浏览器据此生成工具和输入 Schema；命令式 API 适合复杂应用，通过 document.modelContext.registerTool() 注册函数，可复用已有前端状态管理、校验和业务逻辑。两条路可以共存。
WebMCP 的 Tool 有生命周期吗？
有。工具可随登录态、路由或 feature flag 注册、注销。registerTool() 可接收 AbortSignal，信号触发后会注销工具；工具集合变化会通知 toolchange 事件。执行中的 Tool 也有自己的取消信号，页面卸载、调用方取消或执行被撤销时，前端代码需要正确停止请求、清理临时状态。
WebMCP 目前有哪些浏览器支持？
Chrome 是目前最积极的实现方，WebMCP 已进入 Origin Trial；Edge 跟随 Chromium 做实验性支持。Mozilla 仍是 Neutral，WebKit 公开反对。Safari 和 Firefox 尚未形成共识，因此它仍有变成 Chromium 专用能力的风险，做产品时只能把它当渐进增强。
WebMCP 的主要安全风险有哪些？
主要风险包括：Tool poisoning（工具名称或描述塞入误导 Agent 的指令）、Tool output injection（合法 Tool 返回的用户生成内容或第三方文本中混入恶意指令）、Tool hijacking（第三方脚本注册、替换或篡改 Tool）、权限错配（标着 readOnly 的工具实际触发写操作）。这些不能靠浏览器开关解决，边界仍在服务端授权、显式确认、审计日志和可撤销流程上。
开发团队落地 WebMCP 有什么建议？
建议先挑一两个低风险动作做实验，别一上来就把整个后台工具化。可执行的最小路线：找一个只读或可预览的页面动作；设计窄的 JSON Schema，避免万能 payload；复用 UI 已有的服务层和校验，服务端继续做最终授权；记录调用人、页面、参数摘要、结果和错误；在支持 WebMCP 的浏览器里试验，同时保留人工流程和 DOM/Computer Use 回退。
