WebMCP 是一项提案中的浏览器 API，可以代替用户去发现、描述并执行给 AI 智能体使用的结构化工具。网站声明每个动作做什么、接受哪些输入；智能体直接调用这个工具，不用再猜该点哪个按钮或哪个字段。这能让表单、预订流程或诊断任务更快更可靠，但它并不是浏览器自动化的通用替代品。 Chrome 的 WebMCP 文档
实际选择是一个架构问题。WebMCP 是服务端的配合：网站所有者发布一份面向智能体的契约。浏览器自动化则是客户端的观察：智能体操作已经存在的界面，包括已获授权的登录会话。你掌控网站、能定义安全工具时用前者；需要面对今天的网页时用后者。 安全工具指南
什么是 WebMCP？
WebMCP（Web Model Context Protocol）是 Chrome 团队与 WebMCP 社区提出的浏览器侧 API 提案。Chrome 的文档把它描述为一种为智能体构建并暴露结构化工具的方式，同时保留可见的网页应用和用户的控制权。网站可以把搜索、结账、日期选择、客服或诊断工具作为渐进增强发布出来；没有智能体在场时，人依然可以继续使用同一个页面。 Chrome 的源试用公告
WebMCP 是怎么工作的？
启用了 WebMCP 的页面会向浏览器注册工具。每个工具都有名称、描述、输入 schema，以及一段在页面内运行的实现。命令式 API 用 JavaScript 编写自定义操作；声明式 API 则是对普通 HTML 表单做标注。Chrome 的文档点出了对智能体重要的三件事：发现、输入输出的 JSON Schema，以及描述当前页面能做什么的状态。
结果可能是一条更短的操作路径。智能体不必读取庞大的 DOM、推测某个按钮意味着 submit_application，再指望选择器能扛过一次改版，而是可以直接调用具名工具，并传入由 schema 描述的字段。操作依然在网站上可见地执行，因此页面可以显示进度，并在购买或其他会改变状态的操作前请求确认。
我们在 Chrome 152 上的 WebMCP 实测全过程
2026 年 9 月 11 日，我们在官方 Chrome Labs Hotel Chain 演示上做了一次引导式测试，环境是 macOS 上的 Google Chrome 152.0.7977.76 与 WebMCP Model Context Tool Inspector 1.9.15。操作者使用合成住客数据，没有 Gemini API key，也没有任何真实的酒店、支付或账号凭据。这是一次行为走查，不是速度或可靠性基准测试。
- Inspector 发现了页面的工具和 schema。我们调用 search_location 查询巴黎、9 月 18 日、三晚、一位成人；页面显示了两处房源。
- 我们以 breakfast 调用 filter_search_results。可见的结果数量从两条变成了一条，只剩 Montmartre Suites。
- 我们打开那家酒店，进入预订流程，并填入合成身份 Alex Chen。工具准备好了表单，但没有完成预订。
- 页面停在 Confirm Reservation。直到操作的人亲自点击该控件，演示才显示 Reservation Confirmed。
还有一项工具限制也值得注意：在我们手动执行 Execute Tool 流程之后，Inspector 的 Copy trace 动作返回了空的 JSON 数组。因此我们把截图和结构化的步骤记录作为这次运行的证据，也不把这个 trace 结果推广到 Inspector 的其他模式。
WebMCP 和浏览器自动化是什么关系
WebMCP 与浏览器自动化解决的是不同的失效模式。当网站发布一份好的契约时，WebMCP 消除了歧义。传统自动化，无论是 Playwright、Selenium、browser-use，还是由智能体驱动真实浏览器，都是靠读取渲染后的页面并与之交互来处理没有发布契约的网站。因此 WebMCP 是对自动化的补充：客户端可以在工具可用时调用页面工具，不可用时退回普通浏览。
把这件事当作能力边界来审计最容易。选路线之前，正面和反面两栏都要看。
| 方式 | 它能做什么 | 它不能做什么 |
|---|---|---|
| WebMCP | 调用页面暴露的、具名且由 schema 描述的工具 | 触达没有注册工具的页面，或导入另一套浏览器登录状态 |
| 基于 DOM 的自动化 | 用选择器、截图或无障碍状态操作几乎任何渲染后的页面 | 在不解读界面的情况下知道网站预期的操作 |
| 真实浏览器会话复用 | 使用一份明确配置、已获授权的登录浏览器状态 | 保证能访问、绕过 CAPTCHA，或凌驾于网站策略之上 |
务实的落地方式是先做一个只读工具、一个受支持的浏览器，以及一个可见的确认步骤。等退路跑通了再扩大范围。
会话边界同样重要。WebMCP 运行在客户端访问的页面中，不会把用户的 Chrome Cookie 转移到新的云端会话。对于没有 WebMCP 的网站，ego (lite) 是一款本地 Chromium AI Agent 浏览器：浏览器状态由你明确提供，兼容 Agent 通过 ego-browser 在专用、可见的 Space 中操作网站。Space 会把任务标签页和控制权与你正在进行的工作分开，但它不是远程 VM 或多租户隔离边界。这条路径改变的是浏览器的执行方式，而不是网站的界面契约。 OpenClaw 2.0 的发行说明
用这张评估表把决定讲清楚，而不是把 WebMCP 当成一次全面升级。
| 评估问题 | 以下情况选 WebMCP…… | 以下情况选浏览器自动化…… |
|---|---|---|
| 网站是否由你掌控？ | 是；你能发布并保护页面工具 | 否；你需要面对第三方网站 |
| 这项任务需要已有的登录状态吗？ | 页面自身的已认证会话就够了 | 智能体必须复用另一份单独配置的本地会话 |
| 部署目标是什么？ | 为受支持的客户端提供稳定、有类型的契约 | 不必等网站适配就能跨页面立即作业 |
什么时候该用 WebMCP？
当应用属于你、你能定义稳定的任务边界，并且希望智能体完成结构化工作时选 WebMCP，例如客服表单、旅行搜索、结账或内部诊断。对于人知道预期操作、但智能体否则需要大量解读式点击的复杂界面，它尤其有用。工具要保持小、有类型、可观察。
当你不掌控网站、需要已有的授权登录、必须跨越许多互不相关的网站作业，或者需要在今天就有一条流程而不是等网站适配之后，选真实浏览器自动化。对于已经投入的 CI 脚本，确定性自动化依然合适；对于交互式的登录工作，一个可见的本地浏览器能让智能体拿到与人相同的账号和页面状态，方便人复核。
WebMCP 的安全边界在哪里
WebMCP 本身并不授予权限。Chrome 用来源隔离和 tools 权限策略来管控这些 API；跨来源 iframe 默认禁用。网站只能把工具暴露给它信任的来源，而 Chrome 的安全指南建议对不改变状态的工具使用 readOnlyHint，并在输出包含用户生成或外部文本时使用 untrustedContentHint。
提示词注入仍然可能发生，因为智能体会把指令和网页内容一起处理。让说明和输出保持简洁、在服务端校验输入、对有后果的操作要求用户确认，并且只暴露所需的最小来源和工具集合。WebMCP 是更清晰的接口，不是省掉认证、授权、审计日志或人工复核的理由。
WebMCP 目前的挑战和限制
WebMCP 最大的限制在于采用：客户端必须访问一个受支持的页面，浏览器也必须实现这项实验性 API。Chrome 还指出，无头场景不是主要的设计目标，复杂的应用可能需要重构状态，而且提案仍在变化。
这在可预见的未来会形成混合的技术栈。网站可能暴露一个出色的结账工具，却把账号设置留作普通的 DOM 控件；浏览器可能在测试中支持 WebMCP，却不在你的生产机群里。保留常规的自动化退路，并在反复运行中度量工具错误、确认率和人工接手的情况。
现在怎么试着用上 WebMCP
要在本地实验，请在 Chrome 中启用 chrome://flags/#enable-webmcp-testing 后重启。要做实况测试，Chrome 的文档会请开发者参考 Chrome 149 的源试用。使用官方演示和 Model Context Tool Inspector 扩展来查看已注册的工具、手动调用它们，并同时测试合法与非法的输入。由于提案仍在热烈讨论中，请固定浏览器版本并预期 API 会变动。 OpenAI 的 WebMCP Challenge
如果你是使用智能体的一方而不是网站所有者，不必等 WebMCP 被采用。在受支持的编码智能体里运行 /ego-browser，描述边界清晰的任务，并让浏览器会话和权限保持明确。两种做法会并存：WebMCP 让愿意配合的网站更容易操作；真实浏览器自动化则触达剩下的部分。
常见问题
WebMCP 和 MCP 服务器是一回事吗？
不是。传统的 MCP 服务器是一个外部进程或服务，向客户端暴露工具。WebMCP 则是从网页本身把工具暴露给浏览器里的智能体，以浏览器来源和权限策略为边界。
WebMCP 能自动化不支持 WebMCP 的网站吗？
不能。客户端必须访问一个注册了工具的页面。对于尚未采用 WebMCP 的网站，请使用常规的浏览器自动化；当认证或挑战要求人工介入时就停下来。
谁需要实现 WebMCP？
网站所有者负责实现 WebMCP 工具；智能体客户端和浏览器必须能够消费它们。访问者无法给别人的网站添加工具。
WebMCP 的主要好处是什么？
WebMCP 给智能体提供了具名操作、由 schema 描述的输入以及页面状态，这在愿意配合的网站上减少了猜选择器和解读式点击。应用仍然需要校验每一份载荷。
WebMCP 的主要限制是什么？
WebMCP 需要页面采用和浏览器支持，在 Chrome 中仍属实验性，也没有解决无头环境的一致性、认证策略或提示词注入。
WebMCP 工具可以在没有人参与的情况下运行吗？
一些低风险工具可以自动运行，但敏感操作应当请求用户交互与确认。Chrome 的设计针对的是有人留在流程中的本地浏览器工作流。
WebMCP 会把工具暴露给每一个 iframe 吗？
不会。来源隔离和 tools 权限策略会管控注册；跨来源 iframe 需要明确授权和可信的暴露方式。
WebMCP API 会保持稳定多久？
目前还没有任何稳定性保证。Chrome 把 WebMCP 标注为仍在热烈讨论中的提案标准，所以请固定版本，并持续关注 explainer 和源试用的说明。
我可以在已登录的账号下使用 WebMCP 吗？
页面可以在自己的已认证会话内暴露工具，但 WebMCP 不会把 cookie 转移到另一个浏览器。请把授权和确认留在网站的安全模型里。
当网站还没有 WebMCP 时，我该用什么？
使用常规的浏览器自动化。对于已授权的本地会话，ego (lite) 让受支持的智能体通过 /ego-browser 操作一份单独配置的真实浏览器。
我在哪里可以读到实现指南？
先从 Chrome 的 WebMCP 文档、安全工具指南、源试用页面，以及 GitHub 上的 WebMCP explainer 看起；链接都列在下面的来源说明里。