OpenAI 上线 WebMCP 站点工具：ChatGPT 现在直接调用你的应用，而不再靠抓取
这套标准用结构化的工具契约取代截图抓取 —— 但只在支持它的站点上生效
OpenAI 于 8 月 25 日开始在 ChatGPT 桌面版内置浏览器中支持WebMCP（Web 模型上下文协议）—— 这是该标准首次在有意义的规模上面向真实用户部署。这项被 OpenAI 称为「站点工具」的功能，允许兼容网站注册具名、可调用的 JavaScript 函数，ChatGPT Work 与 Codex 可以直接发现并调用它们，取代当前基于浏览器的 AI 智能体所依赖的截图捕获、DOM 解析和「猜按钮」—— 而后者正是这类智能体大部分成本与不可靠性的来源。
这一步把 WebMCP 从 Chrome 的一项实验变成了面向数千万 ChatGPT 桌面用户的正式功能，距谷歌 Chrome 团队最初在 Chrome Canary 146 中以实验开关的形式发布该标准约六个月。它也改变了那些一直在旁观望的网站运营方的算盘：一个没有 WebMCP 工具的站点，从此在 ChatGPT 智能体来访时会**无声地**退回到那条更旧、更脆弱的自动化路径。
浏览器智能体那套昂贵的猜谜
要理解 WebMCP 改变了什么，先得说清楚它取代的是什么。今天 AI 智能体访问一个网站去完成任务时 —— 订机票、搜商品目录、从仪表盘取数 —— 它对这个站点能做什么并无明确知识。它靠推断行事。
在截图方案里（目前多数浏览器智能体仍以此为主），智能体截下可见页面的图像，交给多模态模型，请它指认可操作元素：搜索框在哪、哪个按钮是提交、筛选下拉里有什么。每一次截图都需要一次完整的图像推理调用，而像「按价格区间筛选商品目录并加入购物车」这样一个多步任务，往往要十几轮甚至更多的「截图—推理—动作」循环。每一轮都吃掉一大块上下文窗口 ——WebMCP 规范指出，典型的一次截图交互每个页面状态要花 2000 token 以上，而一次结构化的工具调用大概只要 20 到 100 token。
另一条路是 DOM 解析：读页面底层的 HTML 和 JavaScript，而不是它渲染出来的样子。这比图像推理省 token，但仍然逼着智能体去理解一种为**浏览器渲染**而设计、而非为**模型导航**而设计的文档格式。它对动态加载内容、自定义组件库，以及任何会改变元素标识或位置的版面调整，都很脆弱。
两条路有着同一个根本问题：智能体像个靠看路牌来破译一座外国城市的游客。WebMCP 的思路是给这位游客一本会话手册 —— 更准确地说，是一份菜单，写清这家餐厅供应什么、怎么点。
WebMCP 的工具注册是怎么工作的
WebMCP 提供两条发布能力的路径。简单的那条是声明式 API，不需要写 JavaScript。开发者给现有的 HTML 表单元素加上机器可读的属性 —— 一个搜索表单可以直接在标记里声明它的工具名和一句自然语言描述。浏览器读取这些属性并把它们呈现给智能体，无需额外代码。对于表单结构规整、内容静态的站点，这可能只要几个小时的开发量。
更丰富的那条是命令式 API：用 JavaScript 调用document.modelContext—— 浏览器新增的面向智能体的接口 —— 注册带类型化输入模式的具名函数，很像开发者在配置模型工具调用时发给 OpenAI 或 Anthropic API 的那些工具定义。一个订票站点可以注册searchFlights(origin, destination, departureDate, returnDate, passengers)工具，并附上智能体能据以推理的参数说明。一个文档编辑器可能注册addComment(section, text)。一个数据仪表盘可能暴露setDateRange(start, end)，好让智能体不必模拟点击日历控件就能圈定查询范围。
两条注册路径共享一个关键性质：工具定义**纯粹在客户端**。没有另外要部署的服务端进程、没有要维护的 webhook 端点、没有要管理的 API 密钥轮换计划。开发者把现有前端 JavaScript 函数包成 WebMCP 工具注册，复用的是生产环境里已经在跑的代码。相比构建一套等价的服务端 MCP 集成 —— 那需要一个 Python 或 Node.js 服务器、网络安全加固，以及持续的基础设施维护 —— 对于前端 JavaScript 已经成熟的站点，这里的额外开销要低得多。一个电商站点如果已经在客户端 JavaScript 里实现了加购物车函数，那么它与一次 WebMCP 工具注册之间的差距，只是几行模式定义。
浏览器本身在每一次交互中充当中介。正如微软的 Patrick Brosset 在 W3C 工作组讨论中澄清的，网站页面从不使用 MCP 的 JSON-RPC 协议直接与智能体对话。浏览器接收工具调用、校验它、把它交给注册的 JavaScript 函数，再把结构化结果返回给智能体。这层中介是该标准安全模型的核心：浏览器可以强制确认关卡、在地址栏呈现有哪些工具可用（OpenAI 称之为「站点工具」检查器），并在执行前施加安全审查。OpenAI 确认每一次工具调用都会经过安全检查，而购买或权限变更这类风险更高的动作仍需要用户显式确认。
有一处架构特性让 WebMCP 与服务端 MCP 显著不同，而这个不同对安全和采用都很要紧。因为 WebMCP 工具运行在用户已登录浏览器会话的页面 JavaScript 上下文里，智能体**继承**了登录用户已有的权限 —— 用户无需生成、分享或轮换 API 密钥。网站可以对已登录用户有条件地暴露比匿名访客更多的工具，而这些工具能做什么，由站点既有的授权逻辑管辖。代价是这些工具带着用户完整的会话权限运行，也就意味着一个恶意站点可以注册专门用来操纵智能体行为的工具描述 —— 这类攻击有时被称为工具投毒，与提示注入类似之处在于：攻击者把误导性指令埋进一个智能体信任的界面。不同的是，提示注入攻击的是模型的输入流，而工具投毒攻击的是智能体的**能力发现**环节，浏览器的安全审查是主要防线。审阅过该规范的安全分析人士把这个取舍讲得很直白：智能体调用某个站点的工具时继承了登录会话 —— 这既是它有用的原因，也是它危险的原因。
这个标准并不是它名字暗示的那个东西
尽管共用了三个字母，WebMCP 不是 MCP。这个区别在实务上和商业上都很要紧。
Anthropic 的模型上下文协议（MCP）现由 Linux 基金会下的Agentic AI Foundation维护，它是一个后端协议。开发者跑一套服务端 MCP 集成，意味着起一个 Python 或 Node.js 服务器、通过 JSON-RPC 暴露工具、再让 AI 客户端经由网络端点连上去。AI 智能体直接与那个服务器通信；不需要有打开的浏览器标签页、不需要有人在场、也不需要共享会话。MCP 适合服务与服务之间的自动化、数据流水线集成，以及任何按计划无头运行的智能体工作流。
WebMCP 填的是另一块空间：浏览器标签页 —— 用户在场并且在看，智能体和用户看的是同一个实时页面。谷歌与微软的规范作者在 W3C 文档里把「非目标」写得很明确：完全自主的无头浏览不是 WebMCP 的设计意图。那类场景更适合交给谷歌的 Agent-to-Agent 协议或既有的服务端 MCP。而对于「人类用户在自己活跃的浏览器会话里把一项任务委派给智能体」这一类交互 —— 在购物站点上组购物车、与 AI 协同编辑文档、探索数据仪表盘 —— WebMCP 提供了一条服务端 MCP 无法复制的结构化路径。
工作组有意选择**不**把 MCP 完整的 JSON-RPC 协议搬进浏览器。据亚马逊工程师 Alex Nahas 所说 —— 他早前的开源 MCP-B 概念验证正是 WebMCP 规范的灵感来源 —— 这个决定反映了 W3C 工作组不愿与任何单一公司的规范强耦合。WebMCP 借用了 MCP 的概念模型（带名称、描述和类型化模式的工具），但实现的是一个浏览器原生接口：任何智能体，无论由 OpenAI、谷歌、Anthropic 还是开源模型驱动，都能通过同一套 API 调用它。
采用情况：数百万家店铺，和一个尚未准备好的网络
WebMCP 最大规模的部署与整个网络之间的落差非常悬殊。在 OpenAI 宣布站点工具的当天，Shopify 的杰出工程师、CEO 技术顾问 Ilya Grigorik 表示，已有数百万家 Shopify 店铺启用了 WebMCP，让智能体能通过结构化工具调用而非模拟点击来浏览商品目录、组建购物车。
这个规模来自平台层面的启用：Shopify 把 WebMCP 支持加进了商家店铺基础设施，一次性对其整个客户群生效。Progress Software 于 2026 年 8 月在其 Telerik 与 Kendo UI 企业开发者工具包中发布了 WebMCP 支持，成为最早提供自动工具注册的企业级 UI 框架之一 —— 旗舰的数据表格、日程组件和表单组件如今无需为每个应用写定制代码即可注册为可调用工具。
在 2026 年 5 月的 Google I/O 上，谷歌列出 Expedia、Booking.com、Instacart、Target、Credit Karma、TurboTax、Redfin 和 Etsy 为 Chrome 源试用的参与方 —— 这些是消费级网络中访问量最大的交易类站点之一。需要说明：这些是各公司自报的试用承诺，不是已确认的具体工具实现的生产部署。
在这批具名采用方之外，图景截然不同。截至 2026 年年中发表的独立分析一致发现，WebMCP 在更广泛的网络上的采用率实际上为零。其中一份评估援引 freeCodeCamp 的实现指南，标题就叫《发布一个采用率 0% 的标准》。OpenAI 在宣布站点工具的同时启动的挑战赛 —— 为期 10 天、由 OpenAI、Cloudflare、Shopify、Vercel、Render 和 Netlify 提供总额 3.5 万美元奖金 —— 正反映了它对这个供给侧缺口的清醒。前十名各获 3000 美元现金外加一年 ChatGPT Pro 与合作方额度；投稿 9 月 3 日截止，9 月 23 日公布结果。
WebMCP 给了站点运营方一种智能体此前从不提供的控制权
关于这个标准，报道一直低估的最重要的一面，不是它给了智能体什么，而是它给了**网站运营方**什么。
在当前的截图或 DOM 解析范式下，任何足够强的 AI 智能体都能与任何网站交互，无论站点运营方是否希望发生这种交互。智能体从像素里逆向出界面。运营方没有任何直接机制去塑造或限定这种访问 —— 他们可以上机器人检测和限流，但没法告诉一个智能体「你只可以做这三件事，别的不行」。
WebMCP 从结构上改变了这层关系。实现该标准的站点发布的是一组**经过选择**的工具定义。使用这些工具的智能体，只在运营方选择暴露的那块面积内行动。一个金融站点可以提供只读的账户信息导航工具，而明确不把任何转账或支付动作暴露为工具。一个内容平台可以暴露文章检索，而不暴露用户数据查询。已登录用户拿到的工具比匿名访客多 —— 用的就是站点既有的认证与授权逻辑。
参与设计该标准的谷歌 Chrome 高级软件工程师 Khushal Sagar，用三个组织性原则描述了它的理念：上下文（给智能体它需要的数据）、能力（定义可执行的动作）、协同（规定智能体何时把控制权交还给人）。这个三段式框架挑明了一件事：WebMCP 是一个为人机协作而建的**协作式**标准，不是智能体优先的自主标准。规范作者把默认假设反了过来 —— 智能体在站点划定的边界**之内**行动，而不是绕过它。
这一点还有一层几乎无人讨论的监管相关性。欧盟《人工智能法案》第 50 条针对智能体 AI 系统的透明度义务已于 2026 年 8 月 2 日生效。暴露 WebMCP 工具的站点，可以把披露直接构建进工具定义本身 —— 这种做法契合该法规在「AI 辅助行为的透明度」上的意图，而黑箱式的截图自动化做不到。这层联系目前还没被广泛讨论，但它可能成为欧洲市场采用 WebMCP 的一个合规理由。
GPT-5.6、浏览器覆盖，以及这个标准仍然做不到的事
OpenAI 的实现带着一条会在近期限制其覆盖面的模型约束：WebMCP 站点工具需要 GPT-5.6 Sol 或 Terra —— OpenAI 当前模型家族中能力更高的两档。最快、最便宜的 Luna 档禁用了 WebMCP。企业版和教育版工作区用户则完全无法使用站点工具，无论用哪一档模型。
浏览器这一侧的局面同样受限。谷歌 Chrome 发布了首个 WebMCP 实现，目前正在从 Chrome 149 到预计的 Chrome 156 期间进行源试用，稳定版启用预期在 2026 年第四季度。7 月，规范把主 API 端点从navigator.modelContext改到了document.modelContext，体现了工作组的判断：工具属于具体页面，而不是全局的浏览会话。Chrome 150 弃用了旧的 API 形式，而源试用期间两者仍同时提供；Angular 等框架正处在迁移途中 —— 这意味着任何 7 月之前发布的实现指南，引用的都是已弃用的 API 路径。
Edge 的状态未定。微软是 WebMCP 规范的共同作者，并正把它纳入 Edge 与 Copilot 的路线图，但截至 Edge 147 于 2026 年 4 月的发布说明，WebMCP 并未列入该版本的新 Web 平台特性。Edge 的其他端侧 AI API —— Prompt、Writer、Rewriter、Proofreader —— 都在 147 里发了，WebMCP 没有，至少没有公开发。Firefox 没有正式承诺，只参与了 W3C 社区组的讨论。Safari 和 Apple Intelligence 至今没有任何公开表态。
这个规范也有意限制了自己的范围。WebMCP 目前只覆盖工具：带描述和类型化输入模式的具名函数。它没有 MCP 的 resources 原语（暴露数据上下文）、prompts 原语（可复用的提示模板）或 sampling 原语（智能体到模型的往返）的对应物。工作组选择先发布一个小而聚焦的接口面，反映的是 MCP 早期开发的一条教训：范围收窄的 API 达到稳定的浏览器实现，比一个大而全的快得多。这种克制是一个设计选择，不是一个等着被立刻填上的缺口。
源试用的时间窗本身，给这个规范的下一步演进定了硬期限。Chrome 的源试用从 Chrome 149 跑到预计的 Chrome 156，这个窗口大致对应 2026 年第四季度。到试用关闭时，工作组需要已经解决 API 端点的迁移（从navigator.modelContext到document.modelContext）、敲定声明式 HTML 表单属性语法，并回答工具命名空间与冲突处理的开放问题 —— 当智能体的活跃会话里、来自不同页面的多个工具共用相似名称时该怎么办。上游的 MCP 规范已于 2026 年 7 月底切出第一个候选发布版，而 MCP 工具原语的变化会传导进 WebMCP 的概念模型 —— 所以这两个标准并非各自独立演进。
智能体电商的竞争筹码
WebMCP 的商业理由在电商上最为具体 —— 这个标准正是在那里被构想出来，也在那里有最直接的部署。一个能调用addToCart(productId, quantity)的智能体，相比「定位那个绿色按钮、确认它是不是对的元素、模拟点击、再确认购物车已更新」，不只是更快 —— 它在结构上更可靠，能扛住商品目录变更、季节性改版、A/B 测试变体这一整条长尾，而这些恰恰是把基于截图的自动化频繁弄坏的东西。
Shopify 的平台级启用之所以重要，正是因为它绕开了那个让 WebMCP 在开放网络上停留在接近零的采用壁垒。商家开发者不必逐个实现这套标准，Shopify 在平台层把它打开了。这个模式 —— 基础设施提供方启用、商家受益 —— 正是 WebMCP 能比逐站采用扩散得更快的机制。可以类比 2010 年代中期的 SSL/TLS 普及：站长们迁到 HTTPS 一直很慢，直到主机平台和内容分发网络开始默认启用，采用率才在几个月内加速。WebMCP 的路径很可能走同样的杠杆点：主流 SaaS 平台、电商基础设施提供方，以及企业级 UI 框架，把这套标准变成它们客户的阻力最小路径。
Progress Software 在 2026 年 8 月把 WebMCP 集成进 Telerik 与 Kendo UI —— 两个部署最广的企业级 JavaScript 组件库 —— 就是这个动力学的早期例证。当数据表格、日程组件、表单字段这些旗舰组件自动注册为智能体可调用的工具时，每一个建立在这些工具包之上的企业应用都不必开发者动手就获得了 WebMCP 兼容性。把这个数字乘上 Shopify 的商家基数，再加上 Progress Software 的企业客户量，启用了 WebMCP 的页面数就开始显得比开放网络的原始采用率数字所暗示的大得多。
竞争性的方案不会消失。Browserbase、Steel 这类公司提供的托管无头浏览器基础设施，承接的是那条永远不会实现 WebMCP 的长尾网站，而网络的大部分在未来数年里仍将是不配合的。近期的现实是一个分裂的网络：一边是不断增长的配合站点，智能体在那里通过结构化契约行动；另一边是数量未变的站点，智能体在那里继续解析截图、猜测 DOM 元素。这两条路并不互斥 —— 用 ChatGPT 桌面浏览器的智能体，在站点工具可用时用它，不可用时退回标准浏览。
对一个正在决定要不要现在实现 WebMCP 的电商站点来说，这笔账自该标准 2 月首次出现以来已经变了。六个月前，唯一的消费方智能体是躲在实验开关后、跑在 Chrome Canary 里的 Gemini。而自 8 月 25 日起，消费方智能体的人群包括了所有 ChatGPT 桌面安装量上的 ChatGPT Work 与 Codex 用户 —— OpenAI 称其付费各档合计有数千万。这种不对称现在是真实的：启用了 WebMCP 的站点，能从这批人群获得结构化、可靠的智能体交互；没实现的站点，得到的是脆弱的截图自动化，或者什么也没有 —— 取决于智能体的兜底行为。
OpenAI 的 WebMCP 挑战赛想要回答的那个隐含问题是：开发者激励能否把「配合站点」的数量拉快到足以改变局面。这次挑战赛的评分标准 —— 实用性、原创性、完成度，以及人机协作体验的质量 —— 显示 OpenAI 找的是「这种协作模式能让什么成为可能」的有说服力的演示，而不只是技术上正确的实现。对采用而言，这个问题的十个最佳答案，可能比那 3.5 万美元奖金更有价值。
延伸阅读：Codex 用户破两千万，Claude Code 在 AI 编程上的领先正在收窄
OpenAI 这次部署的时机很说明问题。Chrome 的 WebMCP 稳定版推送还有几个月，Firefox 没有承诺，Edge 的支持未经确认。OpenAI 选择在自家桌面应用的浏览器里发布站点工具，而不是等这个标准在更广的浏览器市场上稳定下来。这个决定让 OpenAI 掌握了体验的定义权 —— GPT-5.6 Sol 与 Terra 拿工具结果做什么、安全审查怎么走、「站点工具」检查器长什么样 —— 同时也让它跑在了 Chrome 更慢的发布周期前面。OpenAI 今天在自家桌面浏览器里发出来的东西，很可能会定义用户对这件事的预期，而 Chrome 将来的稳定版实现会被拿来与之比较。