事件：ChatGPT 内置浏览器上线 WebMCP

8 月 25 日，OpenAI 在 ChatGPT / Codex Changelog 里正式加入了 Site tools（WebMCP）支持：在 ChatGPT 桌面 App 的内置浏览器里，ChatGPT Work 和 Codex 可以自动发现并调用当前网页自己暴露的 actions，无需为每个网站单独配置 MCP 连接器。同一时间，ChatGPT Sites 也支持了这套机制。

同一天，OpenAI 联合 Google Chrome、Cloudflare、Shopify、Vercel、Render、Netlify 发起了为期 10 天的 WebMCP Challenge：

• 提交截止 9 月 3 日，9 月 23 日公布 10 个获奖项目
• 前十名每个可得 3,000 美元现金、一年 ChatGPT Pro、一台 Codex Micro 键盘，外加 Vercel、Shopify 等赞助商的额度与礼品
• 官方给了参考 demo：协作写作、3D 建模、填字游戏生成、基于 DuckDB-Wasm 的浏览器内数据探索

注意一个容易搞混的点：这个标准的准确名字叫 WebMCP，不是「MCPWeb」。而且它不是 OpenAI 的私有协议——规范由 W3C Web Machine Learning Community Group 起草，作者来自 Microsoft 和 Google 的工程师，2026 年 2 月 10 日首次提出，明确声明模型无关（model-agnostic），OpenAI 只是当前把产品侧支持做得最激进的厂商。

WebMCP 是什么：把 MCP Server 塞进网页本身

过去想让 Agent 操作一个网站，主要有两条路：

第一条是 Computer Use。 Agent 看截图、识别控件、点击输入，再观察页面变化。覆盖面广（网站零改造），但代价也明确：UI 一变定位就失效，复杂表单和下拉框不断制造失败点，token 消耗和速度都不好看。

第二条是传统 MCP Server。 网站把能力做成 Tool，Agent 直连调用。结构化了，但开发者要维护一套 Agent-facing 的 Server、认证、部署、Schema 和版本——对一个静态 Web App 来说，成本可能比应用本身还重。

WebMCP 插在这两者中间：Tool 直接注册在当前网页里。规范定义了一个浏览器端 JavaScript 接口，网页调用 document.modelContext.registerTool() 即可注册工具，提供名称、自然语言描述、JSON Schema 输入和执行函数：

await document.modelContext.registerTool({
  name: "set_date_range",
  description: "Set the dashboard date range",
  inputSchema: {
    type: "object",
    properties: {
      start: { type: "string" },
      end: { type: "string" }
    },
    required: ["start", "end"]
  },
  execute: async ({ start, end }) => {
    return dashboard.setDateRange(start, end);
  }
});

Agent 看到的不再是两个日期输入框，而是一个参数明确的 set_date_range(start, end)。Chrome 的 WebMCP 文档还提供了第二条接入路径：对标准 HTML 表单用 Declarative API 标注，让现有表单直接变成 Tool；复杂状态管理则走 Imperative API。

几个关键设计：

• Tool 在页面 JavaScript 上下文里执行，天然共享用户当前的登录态、页面状态和应用权限——Agent 和用户在同一个 live page、同一个 signed-in session 上协作
• 不需要后端 Server。对主要逻辑就在浏览器里的静态 Web App，「让 Agent 能调用」不再等于「再部署一台 MCP Server」
• 当前规范刻意收窄：只覆盖 callable tools，MCP 协议里的 resources、prompts、sampling 都没有对应物，保证表面积小到能真正塞进浏览器

有一个技术细节值得澄清：WebMCP 规范把页面描述成「可以视作一个把 Tools 实现在 client-side script 里的 MCP Server」，但并不强制浏览器用 MCP transport 把这些 Tool 交给 Agent——浏览器可以用自己的 function-calling 机制。所以更准确的理解是 Agent-facing 的 Web API surface，而不是把传统 MCP Server 原封不动搬进浏览器。

OpenAI 自己的用法：Runme 案例

OpenAI 同步公开了一个内部案例说明取舍。Runme 是一个把 Markdown notebook 变成可交互文档的工具，OpenAI 团队需要 Codex 读取 notebook 里的 instructions、执行受限 JavaScript、修改内容并写回结果。

传统做法是单独建一个 MCP Server，处理部署和连接。他们最后选了 WebMCP：Runme 页面加载后直接注册 browser-side tools，Codex 在内置浏览器里发现并操作当前打开的 notebook——没有任何新增的服务端部署。这个案例点出了 WebMCP 最舒适的位置：业务动作本来就在网页里，Agent 需要的只是当前页面状态。

三种方案怎么选

OpenAI 自己的 Computer Use 文档也给了同样的选择原则：目标应用有结构化接口就优先用结构化接口，只有需要视觉检查或确实没有接口时才靠截图点击。

边界、限制与风险

目前的发布边界需要清楚：

• 站点工具在 ChatGPT 桌面 App 内置浏览器中可用，要求 GPT-5.6 Sol / Terra 模型；Luna 不支持，Enterprise / Edu 工作区暂不支持
• 工具与所在页面绑定，关掉页面即消失，跨页面不自动可用
• Chrome 146 已提供 DevTrial（藏在 Experimental Web Platform Features flag 后面）；Firefox、Safari、Edge 参与了 W3C 工作组但尚未实现——标准本身还在草案阶段
• OpenAI 明确提示了风险面：工具在登录态下执行，可能修改网站数据；prompt injection 和数据外泄是真实威胁。官方在购买、删除、改账户、发消息等动作前会要求用户确认，每次工具调用也有安全审查，但这不等于网站本身可信

生态侧倒是比想象中走得快：Google 5 月就给 Lighthouse 加了 Agentic Browsing 检查项（含 WebMCP），Shopify 7 月在自家 storefronts 铺开 WebMCP 工具，Cloudflare 8 月推出了边缘侧桥接，不改源站就能给站点挂上 WebMCP 接口。浏览器、电商、CDN、托管全家桶都到齐了。

一个判断

WebMCP 解决的不是「Agent 有没有办法点这个按钮」——Computer Use 早就做到了。它解决的是定价权问题：网站从「被动等待被截图和点击」变成「主动声明自己提供什么操作、什么参数、什么返回」。

这也是「Agentic Web」叙事里最实际的一步：越来越多的应用会从「为人设计、被 Agent 勉强使用」，走向「人和 Agent 共用一套接口」。两条开发赛道正在分开——面向人类的 UI 是终极产品，面向 Agent 的结构化接口是它的地基。WebMCP 给了 Web 开发者一个成本极低的地基入口：几行 JavaScript，不需要新服务，不需要新部署。

至于它能不能成，标准之争从来不只看技术。10 天 Challenge 的提交量、9 月 23 日的获奖名单、以及 Firefox / Safari 什么时候跟进实现，会是接下来几个月最值得盯的信号。

资料来源（核对于 2026-08-28）

• OpenAI ChatGPT & Codex Changelog：learn.chatgpt.com/docs/changelog
• OpenAI WebMCP / Site tools 文档：learn.chatgpt.com/codex/webmcp
• WebMCP Challenge 官方公告：community.openai.com（The WebMCP Challenge is here）
• WebMCP Draft Specification：webmachinelearning.github.io/webmcp
• Chrome for Developers WebMCP：developer.chrome.com/docs/ai/webmcp
• OpenAI Developers Blog：Automating repetitive work at OpenAI with Codex