OpenAI发起WebMCP挑战赛

OpenAI想让网站不只“给人看”，也能直接“被Agent调用”

OpenAI在8月26日宣布启动 WebMCP Challenge，邀请开发者在10天内新建一款面向AI Agent的网站，或为现有Web应用加入WebMCP支持。

这次活动的合作阵容包括Google Chrome、Cloudflare、Shopify、Vercel、Render和Netlify，评审则来自OpenAI浏览器Agent团队、Chrome、Shopify、Vercel、Netlify以及MCP-B等项目。参赛作品需要通过Devpost提交，并提供项目说明、可实际访问的在线应用、代码仓库和演示视频。

WebMCP是一套让网站把自身能力声明为结构化工具、供AI Agent直接发现和调用的实验性Web标准。 它试图解决一个正在快速暴露的问题：今天的浏览器Agent虽然已经能“看见”网页，却依然不真正“理解”网站能做什么。

OpenAI此次举办挑战赛的目的并不只是征集几个Demo，而是在为一种新的Web产品形态拉开发者入场。过去网站围绕鼠标、键盘和触摸屏设计，下一阶段的网站可能需要同时服务人类用户与AI Agent。

WebMCP解决的是浏览器Agent最笨重的一环

浏览器Agent目前最常见的工作方式，是截图、识别页面元素、推断下一步动作，再模拟鼠标和键盘完成点击与输入。

这套方法看起来接近人类操作，实际却非常脆弱。按钮位置移动、弹窗突然出现、页面响应变慢、无障碍标签缺失，甚至一次A/B测试，都可能让Agent点击错误元素。一个原本只需要调用一次函数的任务，最后可能变成十几轮截图、视觉推理和操作验证。

Computer Use是让模型通过屏幕图像与输入设备操作软件的能力。 它的优势是兼容面广，只要人能操作，理论上Agent就能尝试操作；它的缺点则是延迟高、Token和算力消耗大，而且每一步都可能出错。

WebMCP选择了另一条路：网站主动告诉Agent“我能做什么”。例如，一个电商网站可以明确暴露“搜索商品”“读取规格”“加入购物车”和“查询订单”等工具，并为每个工具声明参数、返回结果和用途。

这相当于餐厅不再要求Agent隔着玻璃猜菜单、找服务员和比划下单，而是直接递上一份机器可读的菜单。Agent不需要判断页面上哪个蓝色区域是购买按钮，只需要调用网站已经注册的“加入购物车”工具。

按照WebMCP当前的实验性设计，网站可以通过页面侧的modelContext机制注册工具；部分实现与技术讨论中可见navigator.modelContext等接口形态。由于WebMCP仍处于快速演进阶段，接口命名、权限机制和浏览器实现状态都可能继续调整，开发者不应把当前原型视为已经冻结的正式标准。

它与MCP同源，但不是把服务器接口搬进浏览器

MCP，即Model Context Protocol，是一种连接AI应用与外部数据、工具和服务的开放协议。 WebMCP延续了“把能力描述成结构化工具”的思路，但它关注的是网页运行环境以及用户正在访问的页面。

服务器侧MCP更像一个长期在线的工具服务，通常由Agent客户端主动连接；WebMCP则由当前网站在浏览器上下文中声明能力，并与页面状态、用户会话和可见界面结合。用户已经登录哪个账户、当前选中了什么商品、表单填写到了哪一步，这些信息天然存在于网页会话中。

这种区别决定了WebMCP不会简单取代传统MCP，也不会取代网站现有的后端接口。更可能出现的架构是：后端继续通过数据库、业务服务和服务器侧MCP提供能力，前端则利用WebMCP把适合当前用户调用的操作暴露给浏览器Agent。

| 方案 | Agent如何理解网站 | 可靠性 | 页面改版影响 | 典型成本 | 适合场景 | |---|---|---:|---:|---:|---| | 截图与视觉点击 | 识别像素并推断按钮、输入框 | 较低 | 很大 | 多轮截图与视觉推理 | 未适配网站、桌面软件 | | DOM与无障碍树操作 | 读取HTML元素、角色和标签 | 中等 | 中等 | 需要元素定位与状态判断 | 表单、后台系统、自动化测试 | | WebMCP | 网站主动声明可调用工具及参数 | 较高 | 较小 | 工具发现与结构化调用 | 电商、预订、客服、生产力应用 | | 服务器侧MCP | 连接独立MCP服务 | 较高 | 基本不受前端影响 | 需要部署、鉴权和客户端配置 | 数据库、企业系统、开发工具 |

WebMCP真正重要的地方，是把“页面自动化”变成“产品能力调用”。前者依赖Agent猜测界面，后者要求网站明确表达业务动作，这会显著降低交互歧义。

ChatGPT开始支持WebMCP，比赛才有现实意义

ChatGPT对WebMCP的实验性支持，是这次挑战赛区别于普通浏览器标准黑客松的关键。

一个新标准最容易陷入“网站等客户端、客户端等网站”的冷启动困境。网站不愿投入工程资源，因为没有用户侧产品支持；Agent产品也不愿优先支持，因为互联网上没有足够多的兼容网站。

OpenAI此次一边推动ChatGPT支持WebMCP，一边联合Chrome和Web基础设施厂商征集应用，本质上是在同时启动需求端和供给端。ChatGPT带来用户入口，Chrome提供浏览器平台影响力，Cloudflare、Vercel、Render和Netlify覆盖部署链路，Shopify则代表最适合Agent交易的电商场景。

这些合作方的组合并非随机拼盘。WebMCP如果要真正落地，需要浏览器实现、Agent客户端、网站框架、托管平台和真实业务同时参与，任何一层缺位都会让它停留在技术演示阶段。

Netlify已经宣布为参赛开发者提供总计300万额度的支持资源，并单独设置5000美元奖金池。需要注意的是，这部分属于Netlify面向挑战赛的配套支持，并不等于OpenAI官方公布的全部奖金总额。

OpenAI官方规则显示，最终排名前10的项目将获得OpenAI及活动支持方提供的不同奖项。项目将按照实用性、原创性、完成度、WebMCP使用是否合理，以及“人类—Agent协作体验”的质量进行评估。

最有价值的作品不会是“让Agent替你点按钮”

真正有竞争力的WebMCP应用，应当让人类界面与Agent工具共用同一套业务状态，而不是把现有按钮机械地包装一遍。

以旅行预订为例，用户可以先在页面上手动筛选日期和预算，再让Agent比较剩余酒店的取消政策；Agent完成初步选择后，用户回到可视化页面确认房型和总价。整个过程中，人和Agent可以交替接管任务，而不必从头同步上下文。

电商也是WebMCP最容易产生价值的领域。用户可以要求Agent“从当前店铺找出三款支持USB-C供电、重量低于1.5千克且本周能送达的显示器”，网站则通过结构化工具返回库存、规格和配送信息，而不是让Agent逐页阅读商品卡片。

企业软件的潜力同样明显。CRM、工单系统和数据后台往往包含大量表格、筛选器与多步骤表单，这些界面对熟练员工尚且繁琐，对依靠视觉操作的Agent更是高风险区域。WebMCP可以将“创建工单”“更新客户阶段”“导出当前报表”等动作直接定义为工具，同时保留页面作为审查和确认界面。

内容网站的价值则相对有限。一个只提供文章阅读的页面，本身没有多少值得调用的业务动作；如果为了追逐标准而注册大量“打开文章”“滚动页面”之类的工具，WebMCP反而会变成新的冗余层。

这意味着WebMCP更适合“可执行的网站”，而不是所有网站。交易、预订、管理、搜索、配置和协作类应用最可能率先采用，普通展示页与媒体页面未必需要跟进。

可靠性提升之外，安全才是最难的部分

WebMCP降低了Agent误点按钮的概率，却没有自动消除越权操作、提示注入和错误授权等风险。

网站一旦向Agent暴露工具，就必须区分只读操作与有副作用的操作。搜索商品和读取订单状态通常风险较低，提交订单、删除数据、发送消息和修改权限则必须要求更强的确认机制。

提示注入是恶意内容通过文本或页面指令诱导Agent偏离用户原始目标的攻击方式。 当Agent能够直接调用网站工具时，提示注入的后果可能从“读错一段内容”升级为“执行错误业务操作”。因此，WebMCP工具描述不能被页面中的任意内容覆盖，Agent也不能把网页文本自动视为可信指令。

网站还需要防止工具描述本身成为误导来源。一个名称为“获取最终报价”的工具，实际返回的如果只是税前价格，Agent就可能向用户给出错误结论。结构化调用解决了操作精度，却无法替代业务语义的准确性。

权限边界会成为WebMCP能否进入生产环境的决定性因素。一个成熟实现至少需要处理以下问题：

• 明确授权： 网站应向用户展示Agent正在申请调用什么能力。
• 最小权限： Agent只能访问完成当前任务所必需的工具和数据。
• 高风险确认： 支付、发布、删除和权限修改不能静默执行。
• 来源隔离： iframe、第三方脚本和广告内容不能随意注册高权限工具。
• 可审计性： 用户需要知道哪个Agent在什么时间调用了哪个工具。
• 可撤销性： 网站应支持终止授权，并尽可能撤回尚未完成的操作。

WebMCP的挑战不在于注册一个函数，而在于把浏览器安全模型延伸到Agent时代。Cookie、同源策略和OAuth解决的是用户、网站与服务之间的身份问题，WebMCP还要额外处理“Agent代表用户做到哪一步”的代理权限问题。

这也可能成为网站新的流量入口

WebMCP如果获得规模化采用，网站的竞争目标将从争夺搜索排名扩展到争夺Agent调用优先级。

传统SEO关注页面能否被搜索引擎抓取、理解和排序，WebMCP关注的则是网站能力能否被Agent发现、正确选择并稳定执行。未来两个功能相似的网站，可能因为其中一个提供了更清晰的工具描述、更透明的价格和更可靠的返回结果，而获得更多Agent发起的交易。

这也解释了Shopify为什么值得关注。电商平台拥有标准化程度较高的商品、库存、购物车和订单模型，一旦平台层统一支持WebMCP，大量商家可以在不理解底层协议的情况下成为Agent可操作网站。

不过，WebMCP也可能削弱网站对用户界面的控制。用户如果直接在ChatGPT中完成搜索、比较和下单，就可能不再浏览商家的推荐位、会员活动和品牌内容。网站获得了新的Agent流量，同时也可能失去部分广告展示和交叉销售机会。

平台与网站之间的利益分配因此不会自动达成一致。Agent客户端可能希望尽量减少交互步骤，网站则希望保留品牌展示、用户确认和商业推荐；WebMCP只是建立技术通道，无法替双方解决商业冲突。

OpenAI押注的是“Agent原生Web”，不是又一个自动化插件

OpenAI此次挑战赛最值得重视的信号，是浏览器Agent的竞争正在从模型能力转向网站基础设施。

过去一年，Agent产品主要比拼视觉理解、规划能力和任务成功率，但单纯依赖更强模型去猜网页，边际成本会越来越高。模型可以变得更聪明，却无法保证每次都正确识别一个缺少标签、不断移动并被弹窗覆盖的按钮。

WebMCP的路线更务实：与其让Agent无限适应为人类设计的界面，不如让网站增加一层机器可理解的能力描述。这与早期Web从纯文本走向语义化标签、从页面抓取走向结构化数据有相似之处，只是这次被描述的不是“页面讲了什么”，而是“网站能够执行什么”。

短期内，WebMCP不会替代Computer Use。互联网上绝大多数网站不会立刻适配新标准，Agent仍需要视觉操作作为通用兜底方案。更现实的组合是：优先调用WebMCP工具，缺少工具时读取DOM，最后才使用截图与模拟点击。

长期看，工具调用与视觉操作的混合路线很可能成为浏览器Agent的默认架构。结构化工具负责高频、关键和有副作用的操作，视觉模型负责探索未知网站以及处理没有标准化的长尾界面。

这场10天挑战赛本身不会决定WebMCP的成败，但它会快速暴露标准当前最缺少什么。开发者最终提交的作品如果只能展示“Agent成功调用了一个按钮”，说明生态仍停留在概念验证；如果能够出现真实交易、多人协作、权限确认和跨页面状态管理，WebMCP才算开始接近生产环境。

OpenAI真正想建立的，是一个网站主动向Agent提供能力的Web。对开发者而言，这不是给页面加一个聊天框，而是重新思考产品的功能应该如何被人类看见、又如何被机器安全调用。

参考来源

• WebMCP技术提案与公开实现讨论：收录WebMCP的设计方向、接口讨论及相关规范进展。
• WebMCP Issues：用于跟踪权限、安全、工具注册和浏览器实现等技术问题。

活动时间、合作伙伴、评审标准、提交要求与奖项信息来自OpenAI WebMCP Challenge官方公告；Netlify支持额度与奖金池数据来自其官方活动说明。受发布链接域名限制，文末仅保留符合要求的GitHub技术资料链接。