WebMCP(浏览器智能体工具标准)
| 分类 | 🔗 技术协议 |
| 阅读时间 | ⏱️ 18 分钟 |
| 更新时间 | 📅 2026-10-09 |
| 条目编号 | ENC-PROTOCOL-20-webmcp |
关键要点 ✦
- 现为 W3C 社区组草案报告(Draft Community Group Report),编辑来自 Microsoft 与 Google,尚未进入正式标准轨道
- 命令式 API 为 document.modelContext.registerTool——2026 年 7 月起从 navigator.modelContext 迁移至 document,旧教程易过时
- 工具描述含名称、自然语言说明、JSON Schema 输入与执行回调;注解含 readOnlyHint、untrustedContentHint、consequentialHint 等
- 声明式表单 API(toolname、tooldescription 等属性)在规范中仍不完整,是最不稳定的部分
- Chrome 自 149 版开放 origin trial(2026-06-09 宣布),Edge 有实验性支持,Firefox 与 Safari 未宣布实现
- 与服务端 MCP 互补而非替代:离开页面仍可完成的任务应走服务端 MCP,依赖页面会话态的交互才适合 WebMCP
从 DOM 操作到工具契约
浏览器智能体今天操作网页的方式是「扮演用户」:序列化渲染后的 HTML,凭视觉或无障碍线索定位元素,模拟点击与键入,再截图核对结果。每一步都依赖推断——「哪个是加入购物车按钮」靠猜,页面改个布局整个流程就断,token 消耗也大。WebMCP 反转了这一模式:页面自己声明工具契约,例如注册一个 addToCart 工具并给出明确的 JSON Schema 输入,智能体改为发起类型化的函数调用,元素推断问题随之消失。Chrome 团队将收益概括为速度、可靠性与精确度的提升;社区流传的试点统计(token 减少约 67.6%、任务成功率约 97.9%)属二手口径,尚待独立基准复现。
规范要点与 API 形态
规范当前形态是 W3C Web 机器学习社区组的草案社区组报告,最新修订在 2026 年 9 月,编辑来自 Microsoft 与 Google。入口只有一处:命令式 API document.modelContext.registerTool,注册内容为工具名称、自然语言描述、JSON Schema 输入与执行回调;注解字段向智能体传递语义提示,readOnlyHint 标记只读操作,untrustedContentHint 提示输出可能包含信任边界之外的内容,consequentialHint 警示涉钱或删除类操作。另有基于 HTML 表单属性的声明式 API(toolname、tooldescription、toolparamdescription、toolautosubmit),浏览器据此合成 Schema,但这部分在规范中仍是待完善状态。注意 2026 年 7 月 API 已从 navigator.modelContext 迁至 document 对象,检索旧资料时需甄别。
安全边界
WebMCP 的信任模型沿用 origin 隔离加显式授权:默认工具仅对同源文档与浏览器内置智能体可见,跨源 iframe 需通过 exposedTo 显式列入;能力整体受名为 tools 的 Permissions-Policy 约束,默认值 self。草案明确要求把工具描述与返回结果都当作不可信内容处理,列出的风险包括提示注入、工具投毒、输出注入、破坏性意图歧义、隐私泄漏与参数过度化。值得注意的是,注解只是提示而非强制,浏览器确认弹窗是体验层保护而非授权策略——授权与业务不变式仍须在应用或服务端落实。Chrome Lighthouse 新增的 Agentic Browsing 审计类别会列出页面注册的全部工具,并在超过 40 个(其 MAX_RECOMMENDED_TOOLS 常量)时告警,提醒开发者控制工具集规模以免撑爆模型上下文并诱发工具混淆。
生态进展与落地
落地信号集中在 2026 年下半年:Chrome 149 起开放 origin trial(2026 年 6 月 9 日宣布),本地开发可用 chrome://flags/#enable-webmcp-testing 开关,试验 token 预计 2026 年 11 月到期;Edge 有实验性支持;Firefox 与 Safari 参与讨论但未宣布实现。应用侧,Stripe 已将面向智能体的结账流程构建在 WebMCP 之上(参见本站 MPP 词条);WordPress 官方 AI 插件仓库于 2026 年 9 月 30 日出现为块编辑器添加 WebMCP 实验的合并请求。Google 将 WebMCP 与服务端 MCP 定位为互补:服务端 MCP 从任何地方应答,WebMCP 只在用户访问站点期间生效,适合依赖页面内会话状态(筛选条件、购物车、多步表单进度)的交互。
适用边界与局限
WebMCP 并非普适方案。无头与后台任务不适用——工具存活于页面事件循环,需要标签页保持打开,CI 与定时任务应改用服务端 MCP。长尾站点的动力存疑:二十年来的微格式、schema.org 等自愿性元数据表明,缺乏分发激励时可选协议难获长尾采纳,对小型站点而言浏览器从既有 ARIA 角色合成能力可能更现实。已有服务端 API 的团队则面临第二份工具契约的漂移风险——页内描述与服务端真实逻辑需要双向同步。多模态输入、长任务进度上报、Service Worker 集成等特性仍未定。目前官方及行业暂未披露更多细节,后续将持续跟进迭代动态。
🎯 应用场景
✅ 最佳实践
- 保持注册工具集小而贴页:随页面状态注册与注销工具,避免一次性暴露全部能力
- 为每个参数提供完整描述,缺描述的字段将退化甚至无法被发现
- 在 execute 回调内做输入与前置条件校验,把每次智能体调用当作不可信的公开请求对待
- 上线前跑 Lighthouse Agentic Browsing 审计,检查工具数量、Schema 有效性
🔮 未来展望
WebMCP 的走向取决于三大浏览器的跟进意愿与规范能否从社区组草案进入正式轨道。若 Chrome 源试验顺利转正,面向智能体的网页改造将成为前端新课题;若各引擎实现分化,开发者又得回到兼容性老路。目前官方及行业暂未披露更多细节,后续将持续跟进迭代动态。