WebMCP 正在重写 Agent 与网页的交互方式：Codex Site tools 全景指南

Vibe Tools Expert Team

发布时间Aug 31, 2026

更新时间Aug 31, 2026

WebMCP 正在重写 Agent 与网页的交互方式：Codex Site tools 全景指南

2026 年 8 月，OpenAI 在 ChatGPT 桌面应用和 Codex 的内置浏览器中加入了一项新能力：网页可以主动向 Agent 暴露结构化工具。OpenAI 把这套实现称为 Site tools，它兼容正在形成中的 WebMCP 提案。

先给结论：WebMCP 不是 OpenAI 或 Codex 发明的私有协议，也不是传统 MCP 的替代品。 它更像是网页与 Agent 之间新增的一层交互接口——让 Agent 不必每次都从按钮、表单和页面布局中猜操作路径，而是直接调用网站明确注册的 search_products、compare_items、update_draft 等业务动作。

如果你只想用 30 秒判断它值不值得关注，可以记住四句话：

WebMCP 适合用户已经打开网页、已经登录，并且希望 Agent 在当前页面协助完成任务的场景。
它比纯点击自动化更结构化、更容易校验，但只对主动适配过的网站生效。
后台、跨应用、无人值守任务仍适合传统 MCP；未适配的网站仍需要浏览器自动化或 Computer Use。
现在最合理的做法不是把全站都“WebMCP 化”，而是先为一个高价值流程增加一个只读工具。

本文依据截至 2026 年 8 月 31 日可见的 OpenAI、WebMCP 草案和 Chrome 官方资料整理。WebMCP 仍处于实验阶段，浏览器版本、模型支持和 API 细节可能继续变化。

从 Site tools 到 WebMCP：先厘清标准与产品

WebMCP 让网页向 AI Agent 暴露结构化工具

WebMCP 来自 W3C Web Machine Learning Community Group。它当前发布的是 Draft Community Group Report，草案页面明确说明：这不是 W3C Standard，也不在 W3C Standards Track 上。WebMCP 社区草案描述了网页如何通过 document.modelContext 注册工具，让浏览器中的 Agent、辅助技术或其他用户代理发现并调用。

OpenAI 在 2026 年 8 月 25 日公布的是这项提案的一种产品实现：Site tools。根据 OpenAI 的 WebMCP 文档，ChatGPT Work 和 Codex 可以在内置浏览器中发现当前网页注册的工具，并在对话任务中调用。

所以更准确的表述是：

WebMCP：实验性的开放 Web API 提案
Site tools：OpenAI 对 WebMCP 的实现名称
Codex / ChatGPT Work：能够发现和使用这些工具的 Agent 产品

这个区别并非咬文嚼字。如果把 WebMCP 写成 Codex 私有协议，开发者会误以为它只能服务 OpenAI；如果把社区草案写成成熟标准，又会低估兼容性变化和安全治理仍在演进的事实。

从“猜界面”到“调用业务动作”

传统浏览器 Agent 要完成网页任务，通常需要观察页面，再通过坐标、视觉、DOM、无障碍树或选择器找到控件。现代工具早就不只是“截一张图、猜按钮在哪”，但它们仍然需要从页面结构中推断网站的真实业务动作。

WebMCP 把方向反了过来：网站主动说明自己允许 Agent 做什么。

WebMCP 在用户、内置浏览器与网页工具之间的工作原理

一个页面可以注册这样的工具：

search_products：按预算、库存和品类查找商品；
compare_items：对用户选中的商品生成结构化比较；
get_environment_info：读取页面可见的诊断信息；
update_draft：修改当前编辑器里的草稿；
stage_replacement：暂存一段精确替换，等用户审查后再保存。

每个工具至少包含名称、自然语言描述、JSON Schema 参数和执行函数。Agent 不必猜“先点筛选、再展开下拉框、再选价格区间”，而是可以用结构化参数调用一个站点认可的动作。

这带来三个直接变化：

第一，工具可发现。 Agent 进入页面后可以看到网站声明的能力，不需要提前硬编码所有 DOM 选择器。

第二，参数可约束。 JSON Schema 能限定字段、类型和可选范围，减少 Agent 把自然语言误填进错误控件的机会。

第三，复用当前会话。 工具在用户正在浏览的页面中运行，可以继续使用页面已经拥有的登录状态、选中项和实时 UI。网站不需要为了同一个前端流程再额外搭一套远程 MCP 服务。

Chrome 的 WebMCP 指南把这类调用描述为比 click simulation 更可预测的路径；Google Cloud Tech 的演示（02:52）则展示了工具名称、描述和 Schema 如何在网页中注册。视频中关于节省 Token 的说法没有统一测量数据，因此更适合视为工程经验，而不是可复用的性能基准。

WebMCP 的六项核心能力

从提案与 OpenAI 实现来看，WebMCP 的核心能力可以归纳为六项：

1. 页面注册工具

网页通过 JavaScript 把现有业务函数包装成 Agent 可调用的工具。理想实现不是另写一套平行业务逻辑，而是复用页面已有的认证、授权、校验和数据操作函数。

2. 结构化输入

每个工具用 JSON Schema 描述参数。开发者可以禁止额外字段、限制枚举值，并把一个模糊任务拆成更窄、更容易验证的动作。

3. 返回可核验结果

工具可以返回标题、ID、数量、变更摘要或候选项，让 Agent 和用户确认执行结果。只返回 success: true 往往不够，因为用户无法判断到底改了什么。

4. 复用实时页面状态

WebMCP 工具与用户看到的是同一个应用状态，适合文档编辑器、购物车、设计器、诊断台等“人和 Agent 操作同一对象”的场景。

5. 暴露副作用信息

工具可以用描述和 annotations 告诉 Agent 它是否只读、是否会修改数据。高后果动作仍应保留明确确认，而不是把“网站注册了工具”理解成“Agent 获得了无限权限”。

6. 浏览器侧发现与审查

在 OpenAI 的实现中，用户可以在内置浏览器中查看当前页面提供的 Site tools 和最近调用记录，每次调用还会经过安全审查。与此同时，OpenAI 也明确提醒：站点工具是不受信任的输入，网站本身仍要承担权限与业务安全责任。OpenAI Site tools 文档

四类 Agent 工具的分工边界

WebMCP 最容易被误解为“浏览器版 MCP”，或者“Playwright 的终结者”。两种说法都过头了。

WebMCP、传统 MCP、浏览器自动化与 Computer Use 对比

方案	工具由谁提供	运行边界	最大优势	主要限制	更适合什么
WebMCP	当前网页	当前页面与会话	结构化动作、实时 UI、复用登录状态	网站必须适配，页面关闭后工具不可用	页面内搜索、填写、编辑、诊断与审核
传统 MCP	本地或远程服务器	独立于网页持续运行	跨资源、跨应用、后台和无头任务	需要服务端或本地连接与独立权限设计	数据库、代码仓库、企业系统、长任务
Playwright 等浏览器自动化	自动化脚本或 Agent	可访问的网页	无需网站主动适配，覆盖面广	依赖 DOM/选择器与页面结构	测试、抓取、操作未适配网站
Computer Use	通用模型与控制层	网页和桌面界面	能操作没有 API 的软件	路径长、成本高、结果更难约束	通用 GUI、遗留系统、跨应用任务
站内 Agent	网站自己	单个产品内部	产品体验可完全定制	每个网站重复建设模型、工具和 UI	高频垂直流程、品牌化助手

选择标准可以非常简单：

任务要在用户当前看到的页面里完成：优先考虑 WebMCP。
任务要跨系统、后台运行或页面关闭后继续：使用 MCP。
目标网站没有 WebMCP：使用浏览器自动化。
目标是没有 API 的任意桌面界面：使用 Computer Use。
产品需要一个长期驻留、深度定制的专属助手：再考虑站内 Agent。

Chrome 对 WebMCP 与 MCP 的比较也明确强调两者不是替代关系。实际系统完全可以让 MCP 负责后台数据和跨系统动作，让 WebMCP 负责当前页面的可见协作，再用浏览器自动化处理没有适配的页面。

最值得优先开放的页面工作流

最适合 WebMCP 的工作流通常同时满足三个条件：用户已经在页面中，任务目标可以结构化，结果能够由用户核验。

最适合 WebMCP 的六类页面工作流

值得优先尝试的场景

搜索与比较。 电商、SaaS 套餐、库存、知识库可以把过滤与比较直接注册成工具，减少 Agent 在复杂筛选器中来回操作。

复杂表单。 客服工单、差旅申请、活动注册和配置向导通常字段多、依赖关系复杂。WebMCP 可以把“完成一项业务任务”作为工具，而不只是暴露几十个输入框。

可见编辑。 文档、代码草稿、图表、设计器和 Notebook 非常适合“Agent 修改、用户现场审查”的模式。

支持与诊断。 页面可以提供读取环境、状态、配置和日志摘要的只读工具，再由 Agent 整理问题和生成工单。

预览与审核。 Agent 可以先生成配置、暂存变更或创建草稿，把发布、支付、删除等最终动作交给用户。

交互式应用。 游戏、架构图、模拟器等产品可以把领域动作直接注册成工具，让 Agent 不必推断每个画布元素的意义。

Chrome 官方示例包括旅行规划、结构化表单、复杂日期选择器、开发者诊断，以及 zaMaker、旅行应用和 Le Petit Bistro 等演示项目。Chrome WebMCP 文档

暂时不值得做的场景

页面只是静态内容，没有需要 Agent 执行的高价值动作；
任务主要发生在后台，用户不会保持页面打开；
流程需要跨多个不受你控制的网站；
团队还没有可靠的认证、授权和服务端校验；
只是为了追热点，却没有具体任务、成功指标和用户需求。

WebMCP 工具只会在 Agent 访问并发现页面后出现。因此，它不是让一个陌生网站自动获得全网分发的 SEO 魔法，也不能替代 API、结构化数据、可访问性或正常的人类 UI。

热度之外：社区仍在争论什么

WebMCP 社区呈现高关注度与早期成熟度并存

截至 2026 年 8 月 31 日，WebMCP 规范仓库在 GitHub 页面约有 3.6k stars、235 forks、107 issues；WebMCP Challenge页面显示 4,355 名参与者，而且比赛仍在进行。这些数字足以说明开发者关注度很高，但不能当成生产采用率。

社区的正面评价主要集中在三点：

领域工具比反复寻找按钮更直接；
JSON Schema 比自然语言填表更容易约束；
Agent 与用户共享同一页面状态，演示效果非常直观。

一位社区作者为 GeoGrid 注册游戏动作后，称 Agent 能在几秒内完成任务；另一条讨论展示了把 WordPress 能力暴露成工具的插件。这些反馈可以证明“有人已经做出来并获得了更顺畅的个人体验”，但不能推出所有网站都会获得同样速度。GeoGrid 与 WebMCP 讨论

质疑也同样具体：

Playwright 本来就能读取 DOM 和无障碍树，不能把旧方案描述成只会截图；
网站需要主动实现，真实采用速度取决于投入回报；
工具通常在用户访问页面后才能发现，是否需要统一目录或注册中心仍有争论；
第三方脚本能否注入工具、Agent 身份如何表达、权限与审计如何标准化，仍是开放问题。

“stop pretending”讨论帖里就有人纠正“旧 Agent 只能截图”的过度简化；WebMCP 发现机制讨论则呈现了两种看法：有人希望建立目录，也有人认为 WebMCP 本来就以用户主动访问后的共浏览为主。

因此，目前最准确的社区判断不是“大家都在叫好”，也不是“没人会用”，而是：演示令人兴奋，标准、兼容性、商业回报与安全治理仍在快速试错。

从 Runme 到代码工作区：真实项目的共同模式

目前最有参考价值的项目不是“让 Agent 自动点一个按钮”，而是把完整工作流重新划分为结构化工具与人类决策。

WebMCP 官方与社区真实项目案例

OpenAI Runme：让 Codex 在可见 Notebook 中完成评估工作

OpenAI 内部使用开源网页 Notebook 应用 Runme，把重复的模型评估流程交给 Codex。Codex 先读取目标和说明，生成计划并等待人类批准，然后执行评估、记录命令、失败路径和关键决策。

Runme 是客户端网页应用。如果为了这些页面操作额外建设传统 MCP 服务，就要增加后端、基础设施和新的数据处理路径。WebMCP 则让 Runme 直接在浏览器侧注册读取说明、执行受限 JavaScript、更新 Notebook 和读取文档等工具。OpenAI Runme 案例

这个案例的重点不是“全自动”：Codex 负责计划和执行重复步骤，人仍然决定计划是否合理，以及哪些高后果选择可以继续。

AgentMarkup Studio：在同一草稿上协作生成 Agent 配置

AgentMarkup Studio 案例注册了八个 WebMCP 工具，让 Agent 编辑页面中同一份可见的内存草稿，再由确定性编译器生成 llms.txt、robots.txt、JSON-LD、Agent Card 等文件。

它没有让 Agent 直接修改线上网站；撤销、重置和下载仍是人类操作。这个设计非常值得借鉴：把 Agent 擅长的结构化编辑交给工具，把最终落地权留给用户。

Cloudflare：在边缘为现有站点注入工具

Cloudflare 的开发者预览尝试在边缘为站点注入同源 WebMCP bridge，允许开发者暴露工具包、C2PA 扫描器，或把现有站点 MCP 能力代理到当前浏览器会话。Cloudflare WebMCP 预览

这条路线的意义是降低旧站改造成本，但它仍是开发者预览，不能写成所有 Cloudflare 网站已经自动支持 WebMCP。

社区项目：游戏、CMS 与代码工作区

社区已经出现 GeoGrid 游戏动作、WordPress abilities 插件，以及浏览器代码工作区等原型。代码工作区的典型设计是让 Agent 搜索、读取和暂存精确替换，再由用户审查 diff；它避免让浏览器中的 Agent直接获得不受控的文件系统写权限。

播客和视频也在迅速放大这一概念。例如 Greg Isenberg 的工具比较（10:03）把 API、MCP、Computer Use、浏览器 MCP、WebMCP 和站内 Agent 放在一起讨论，但节目后段也承认 WebMCP 仍是实验性技术。此类内容适合观察产品想象力，不应替代官方兼容性文档。

一条稳妥的落地路线：从只读工具开始

最差的做法是先列出几十个工具，把页面里的每一个按钮都重新包装一遍。工具越多，描述冲突、权限误判和维护成本越高。

更推荐下面这条路线：

从一个只读工具开始的 WebMCP 接入路线

第一步：选择一个真实任务

不要从“我们要支持 WebMCP”开始，而要从“用户希望 Agent 帮他完成什么”开始。优先选择高频、步骤明确、结果可检查的任务，例如读取当前订单状态、比较已选商品或汇总页面诊断信息。

第二步：先做一个只读工具

只读工具能验证工具发现、描述、Schema、结果展示和失败处理，同时把权限风险控制在最低。等真实测试证明有价值，再增加暂存草稿或更新设置等写操作。

第三步：复用现有业务逻辑

WebMCP 应该只是已有能力的新入口。认证、授权、校验、限流和数据写入仍走原来的可信路径。不要在 execute 中复制一套更宽松的业务规则。

第四步：让 Schema 尽可能窄

一个工具只接收完成任务所需的最少字段。能用枚举就不要接受任意字符串；不需要额外参数时设置 additionalProperties: false；不要为了“更灵活”把整个页面状态都暴露给 Agent。

第五步：返回用户能检查的结果

写操作返回变更前后摘要、对象 ID 和当前状态；搜索返回有限候选项和关键字段；失败返回明确的可恢复原因。目标是让用户知道发生了什么，而不是只告诉模型调用成功。

第六步：保留确认与正常 UI

支付、发布、删除、发送消息和修改权限等动作应继续要求确认。页面还要保留普通 UI 与功能检测：不支持 WebMCP 的浏览器和用户仍然能完成同一任务。

第七步：用真实任务评估

记录任务成功率、平均耗时、确认次数、失败原因和用户是否采用结果。没有真实评估前，不要宣称准确率提升到某个百分比，也不要引用来源不明的 Token 节省数字。

最小接入示例：十分钟注册一个只读工具

下面的例子只读取当前页面标题，不修改任何数据。它使用 OpenAI 当前支持的顶层页面 imperative API，并在浏览器不支持时安静回退。

if (typeof document.modelContext?.registerTool === "function") {
  await document.modelContext.registerTool({
    name: "get_page_title",
    description: "读取当前页面标题；不会修改页面或用户数据。",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false,
    },
    annotations: {
      readOnlyHint: true,
    },
    execute: async () => ({
      title: document.title,
      url: location.href,
    }),
  });
}

接入时注意四点：

使用 document.modelContext，不要照搬早期文章中的 navigator.modelContext；
面向 Codex/ChatGPT 当前实现时，在顶层页面用 JavaScript 注册；
工具描述要明确写出副作用，名称要表达业务意图；
页面提供的认证与权限只是第一层，服务端仍要重新验证写操作。

截至 2026 年 8 月 31 日，OpenAI 文档显示 Site tools 需要最新桌面应用的内置浏览器，GPT-5.6 Sol 或 Terra 可用，Luna 不可用；Enterprise/Edu 尚不可用。当前 OpenAI 浏览器也不支持草案中的声明式 HTML 表单 API，且不发现 iframe 中注册的工具。OpenAI WebMCP 使用说明

Chrome 侧的当前官方指南则写明 origin trial 从 Chrome 149 开始，本地测试可使用 chrome://flags/#enable-webmcp-testing。较早资料出现过 Chrome 146，这是快速预览阶段的版本差异；接入时应以最新 Chrome 官方文档为准。

安全设计必须回到既有信任边界

网页能注册工具，不代表 Agent 可以绕过原有权限。WebMCP 新增的是调用入口，也新增了工具投毒、参数过宽、第三方脚本注入和意图误导等攻击面。

WebMCP 接入需要保留的安全边界

上线前至少检查下面这些问题：

工具名称和描述是否准确反映真实动作；
输入字段是否只包含完成任务所需的数据；
execute 是否复用既有认证、授权与服务端校验；
写操作是否返回可核验摘要，并要求用户确认；
工具输出是否会被模型误当成新的可信指令；
第三方脚本是否有能力注册或修改高权限工具；
是否记录工具调用、结果和失败原因以便审计；
页面不支持 WebMCP 时，普通 UI 是否仍然可用。

WebMCP 草案本身已经讨论提示注入、工具投毒、意图误报、过度参数化和来源边界等风险；社区还在讨论 Agent 身份、权限策略、同意与审计模型。WebMCP 草案安全章节与 GitHub 安全提案都说明这些问题仍在演进。GitHub issue 是讨论，不是已经落地的安全保证。

结语：值得试验，不必押注全部架构

WebMCP 最有价值的地方，不是让 Agent “终于能点网页”，而是让网站可以主动表达自己的业务动作、参数和结果。它为 Agent 与实时网页建立了一条更清晰的协作路径。

但它现在仍然是实验性提案：兼容范围有限，工具只能在访问页面后被发现，浏览器实现尚未完全一致，安全与身份模型仍在演进。把它描述成新的万能协议，会重复早期 MCP 热潮中最常见的问题——先建一大堆工具，再寻找真实需求。

我们的建议很具体：

为一个用户已经在页面中完成的高价值流程，增加一个只读 WebMCP 工具；用真实任务验证价值。后台继续使用 MCP，未适配网站继续使用浏览器自动化，高后果动作继续由人确认。

如果这个最小工具真的减少了步骤、提高了成功率，而且用户愿意采用结果，再扩展到搜索、比较、暂存修改和审核工作流。这样的 WebMCP 才是产品能力，而不是演示能力。

参考资料

博客

WebMCP 正在重写 Agent 与网页的交互方式：Codex Site tools 全景指南

WebMCP 正在重写 Agent 与网页的交互方式：Codex Site tools 全景指南

从 Site tools 到 WebMCP：先厘清标准与产品

从“猜界面”到“调用业务动作”

WebMCP 的六项核心能力

1. 页面注册工具

2. 结构化输入

3. 返回可核验结果

4. 复用实时页面状态

5. 暴露副作用信息

6. 浏览器侧发现与审查

四类 Agent 工具的分工边界

最值得优先开放的页面工作流

值得优先尝试的场景

暂时不值得做的场景

热度之外：社区仍在争论什么

从 Runme 到代码工作区：真实项目的共同模式

OpenAI Runme：让 Codex 在可见 Notebook 中完成评估工作

AgentMarkup Studio：在同一草稿上协作生成 Agent 配置

Cloudflare：在边缘为现有站点注入工具

社区项目：游戏、CMS 与代码工作区

一条稳妥的落地路线：从只读工具开始

第一步：选择一个真实任务

第二步：先做一个只读工具

第三步：复用现有业务逻辑

第四步：让 Schema 尽可能窄

第五步：返回用户能检查的结果

第六步：保留确认与正常 UI

第七步：用真实任务评估

最小接入示例：十分钟注册一个只读工具

安全设计必须回到既有信任边界

结语：值得试验，不必押注全部架构

参考资料

最新博客文章