跳到正文
原文
人人都是产品经理· 易安说AI·· 5 小时前AI 评分49

WebMCP 开发指南助力开发者构建 AI 智能体

文章要点
  • 1WebMCP 让网页用 JavaScript 和 HTML 语义标注向 Agent 声明可调用工具与状态，不再靠猜 DOM 和按钮文案
  • 2接入分命令式与声明式两种 API，工具须有 JSON Schema 约束，购买支付等敏感操作要保留预览和网页内确认
  • 3该能力仍是提案和实验功能，从 Chrome 149 起加入 Origin Trial，开发者可经本地 Chrome Flag 提前实验
  • 4作者归纳三项限制，无头批处理不适用、复杂前端改造成本不低、工具可发现性依赖客户端直接访问网页
决策要点

WebMCP 把网页对 AI 智能体的暴露方式从猜按钮改为声明工具，目前仍是提案加实验能力，定位是渐进式增强而非替代现有网页交互

  • 影响：客服表单、预订和诊断这类结构化流程可被智能体在业务边界内更稳定地执行；能力尚处试验阶段，网站仍须保留普通表单和后端鉴权；敏感操作的预览确认、权限拆分和审计会构成新增工程量
  • 参考：可考虑先挑订单查询、客服表单这类只读场景定义工具 schema 并验证调用效果；值得保留传统表单路径兜底，并提前梳理支付删除等写操作的预览确认与审计方案
  • 依据：依据为社区作者对 WebMCP 提案和 Chrome 149 Origin Trial 的开发解读，属作者归纳整理，实验能力可能随浏览器版本变化
正文

浏览器里的 Agent 常常要先抓 DOM、再猜哪个按钮能点，页面改一行文案就可能走错流程。WebMCP 换了个思路：让网站用 JavaScript 和 HTML 语义标注，把可调用的工具、输入 schema 和当前状态直接声明给 Agent。

现在的浏览器 Agent 想帮用户订机票、提交表单或排查页面问题，通常要先抓取 DOM，再猜哪个按钮能点、哪个输入框该填。页面结构一变，按钮文案稍微调整，自动化就可能走错流程。

WebMCP 试图解决的正是这层不确定性：网站不再只把页面展示给人，也可以通过 JavaScript 和 HTML 语义标注，向 Agent 声明可调用的结构化工具。Agent 不需要从视觉和 DOM 猜测“这个按钮可能做什么”，而是直接看到工具名称、输入 schema、当前状态和预期结果。

WebMCP 目前仍是 Web 标准提案和实验性能力，不是已经普遍可用的浏览器基础设施。对开发者而言，它最值得关注的地方不是又多了一套 MCP 命名，而是 Web 应用开始拥有面向 Agent 的原生交互层。

WebMCP到底解决什么问题

MCP 解决的是模型与外部工具、资源之间的连接；WebMCP 则把相似思路带进网页，让网页本身能够注册和暴露工具。网站可以声明 checkout、filter_results、submit_application 或 run_diagnostics 等明确能力，Agent 通过标准 schema 传入参数，网页在可见界面中执行操作。

传统“模拟用户操作”通常要经历：读取页面、寻找元素、推断用途、点击或输入、检查页面变化。每一步都可能产生误判。WebMCP 把其中一部分意图直接写入工具定义，减少 Agent 对页面视觉布局和文案的依赖。

它的核心能力可以拆成三层：

能力 作用 开发者需要提供什么
发现 让浏览器和 Agent 找到网页可用工具 工具名称、用途和注册方式
JSON Schema 约束输入字段和预期输出 参数类型、必填字段、枚举和校验规则
状态 让 Agent 理解当前页面和可操作资源 当前用户、页面状态、可用数据和执行结果

这套机制不会自动让模型变得更聪明，但能减少“模型猜错按钮”的概率。工具描述越清楚，Agent 越容易在正确的边界内执行任务。

两种API：命令式与声明式

WebMCP 提供两条接入路径。

命令式 API 适合复杂应用。开发者可以用 JavaScript 定义工具，把表单输入、导航、状态管理或业务函数包装成可调用能力。工具内部仍然可以复用现有前端状态和服务调用，但需要明确输入、输出和副作用。

声明式 API 适合标准 HTML 表单。开发者通过给表单元素添加语义信息，让浏览器把现有字段映射为 WebMCP 工具。对于注册、申请、筛选和预约等流程，这种方式可以减少额外 JavaScript 改造。

两种 API 的共同要求是：工具不能只提供一个模糊的自然语言描述，还要有结构化 schema。比如日期字段应该明确格式、时区和允许范围；乘客数量应该是整数并限制上下界；购买操作应该返回待确认状态，而不是直接完成支付。

如果工具会修改数据，最好同时定义预览、确认和撤销路径。Agent 可以先调用预览工具生成变更摘要，用户确认后再调用真正的提交工具。

WebMCP适合哪些网页场景

客服与支持流程

软件客服往往需要先判断问题类型，再找到正确表单，最后把用户提供的信息填入多个字段。网站可以提供 find_support_form、fill_support_request 和 check_ticket_status 等工具，让 Agent 在明确的业务边界内推进流程。

旅行和复杂预订

多城市、多乘客、不同日期和票价规则会让传统点击自动化变得脆弱。WebMCP 可以把行程、乘客和筛选条件定义成结构化输入，让 Agent 少走几层页面，也更容易在提交前展示完整摘要。

结构化表单

submit_application 这类工具可以把对话中的信息映射到网页字段，并明确区分全名、名、姓、公司、证件和联系方式。字段语义由网站负责声明，Agent 负责收集和填充。

人类界面中的特殊控件

日期选择器、地图选点、座位选择和复杂筛选器通常为人类交互设计，通用 Agent 不一定能稳定操作。开发者可以提供 date_pick 或 select_seat 工具，把复杂 UI 变成有约束的输入接口，同时保留页面原有视觉交互。

应用诊断

开发者设置页面里经常藏着清缓存、重建索引、运行健康检查等功能。可以提供 run_diagnostics 工具，让 Agent 直接触发诊断流程，并把日志、状态和建议返回给用户。

这些场景有一个共同点：网页拥有业务语义，Agent 只需要在规则允许的范围内调用工具。真正的业务校验、权限判断和最终提交仍应由服务端负责。

敏感操作必须保留用户确认

购买、支付、发送邮件、提交申请、删除数据和修改权限都属于敏感操作。WebMCP 让 Agent 更容易执行，并不代表网站可以把确认环节省掉。

推荐把敏感流程拆成两步：

  1. Agent 调用预览工具，返回对象、金额、字段和即将产生的副作用。
  2. 用户在页面中确认后，系统才调用最终提交工具。

确认对话框应该由网页控制，而不是只在 Agent 回复中写一句“是否确认”。这样用户能看到真实页面状态，也能避免模型把一次确认误解成下一次操作的授权。

权限也要按工具拆分。查看订单可以是只读权限，修改订单需要更高权限，支付和删除则需要一次性确认。不要给所有 WebMCP 工具统一开放写入能力。

Chrome 149和本地开发方式

WebMCP 从 Chrome 149 开始加入 Origin Trial。希望提前验证的团队，可以申请 Origin Trial，或者在本地打开 Chrome Flag 进行实验。

本地测试流程是：

打开 Chrome

-> 访问 chrome://flags/

-> 找到 #enable-webmcp-testing

-> 设置为 Enabled

-> 重启 Chrome

-> 在本地网页注册和检查工具

实验能力可能随浏览器版本变化，不能直接用于生产承诺。开发阶段应同时保留普通表单和传统 API 路径，确保没有 WebMCP 的浏览器也能正常使用网页。

Chrome DevTools 可以用来检查浏览器解析的工具和 JSON Schema。Angular 目前也有实验性支持，具体能力应以当前框架和浏览器版本为准。

权限策略和跨源iframe

WebMCP 工具受到 tools 权限策略控制，默认值为 self。这表示顶层页面和同源上下文可以注册工具，跨源 iframe 默认不能直接使用。

如果确实需要让跨源 iframe 使用 WebMCP，需要显式添加：

<iframe src=”https://example.com/embedded-app” allow=”tools”></iframe>

这条配置不应该被当成通用开关。跨源页面一旦获得工具能力，宿主页面需要重新评估它能看到哪些数据、能触发哪些操作，以及工具调用结果是否会泄露给不受信任的上下文。

工具还应该遵循最小权限原则：只暴露当前页面真正需要的能力；参数做服务端校验；写操作具备幂等键；每次调用记录用户、Agent、工具、参数摘要、结果和副作用。

如何测试WebMCP工具

开发者可以使用示例 Agentic Chrome 扩展程序或 Model Context Tool Inspector Extension，检查自然语言指令是否按预期调用网页工具。测试时要区分两个问题：Agent 能不能发现工具，工具执行后是否真的产生正确业务结果。

建议覆盖以下测试：

  • 工具名称相近时，Agent 是否能正确选择。
  • 缺少必填字段时，是否要求补充而不是猜测。
  • 参数类型错误时，schema 和服务端是否都能拒绝。
  • 用户取消确认后，是否不会继续执行提交动作。
  • 网络超时或重复请求时，是否不会产生重复订单或重复修改。
  • 页面刷新、登录过期和权限变化后，工具状态是否同步更新。
  • 工具返回的敏感数据是否会进入后续上下文或日志。

测试扩展需要模型 API 时，应把 API Key 保存在本地服务端，不要写进网页脚本，也不要交给网页工具。端侧 Prompt API 可以减少密钥传输，但仍要检查端侧模型对敏感工具的调用权限。

WebMCP的三个现实限制

第一，无头环境并不是它的主要目标。WebMCP 更适合有人参与的本地浏览器工作流，纯服务端批处理仍应该使用稳定的后端 API。

第二，复杂前端的改造成本不低。如果页面状态分散在多个组件、工具调用会触发大量异步副作用，就需要重新设计状态同步和错误恢复。

第三，工具可发现性取决于客户端和浏览器是否直接访问网页。Agent 只拿到一份离线 HTML，或者通过中间代理访问时，可能无法得到完整的可调用工具列表。

因此，WebMCP 更像“渐进式增强”：网页先保证人类用户和普通 API 可用，再额外暴露 Agent 工具。不要把所有业务逻辑搬到浏览器工具里，也不要让 Agent 绕过后端鉴权。

WebMCP适合怎样接入开发流程

可以先选一个低风险、结构化、可回滚的场景，例如订单查询、筛选结果、客服表单或 CI 诊断。先定义工具 schema，再实现只读版本，之后增加预览和确认，最后才考虑写入能力。

一个可控的落地顺序是：

  1. 梳理人类用户当前完成任务的步骤和业务规则。
  2. 找出可以稳定表达为输入、输出和状态的操作。
  3. 为每个操作设计 JSON Schema、错误码和权限等级。
  4. 先实现只读工具，验证 Agent 发现和调用能力。
  5. 为写操作增加预览、确认、幂等和审计。
  6. 用真实失败案例测试注入、重复调用、超时和撤销。

国内开发者如果需要将 Claude Code 等工具接入兼容 API，可通过 Code80(https://code.ai80.vip/home) 配置 endpoint；WebMCP 工具的权限、用户确认、密钥和服务端审计仍需要由项目侧控制。

常见问题

WebMCP和MCP是什么关系？

MCP 更偏向模型与外部工具或资源的连接协议，WebMCP 则把结构化工具暴露能力带进网页，让网页可以直接声明 Agent 可调用的功能。

WebMCP会替代网页API吗？

不会。它更适合作为面向 Agent 的渐进式增强层，普通网页交互、后端 API 和服务端鉴权仍然需要保留。

为什么要使用JSON Schema？

Schema 可以明确字段类型、必填项、枚举、范围和输出结构，减少 Agent 猜测参数和误解工具用途的概率。

支付和删除操作能否自动执行？

不建议直接执行。应该先生成预览和副作用摘要，再通过网页确认对话框获得用户明确授权。

WebMCP能在无头浏览器中使用吗？

可以存在实验性支持，但它主要面向有人参与的本地浏览器工作流；纯无头批处理更适合稳定的后端 API。

国内开发者如何接入兼容 API？

可以通过 Code80 了解接入方式，同时自行管理模型权限、工具网关、密钥、数据留存和审计日志。

本文由人人都是产品经理作者【易安说AI】，微信公众号：【易安说AI】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

来源：人人都是产品经理 · woshipm.com

#教程实践#Agent#数据安全#Google