当 AI 代理试图自动订机票时，网站却可能偷偷引导你买更贵的航班——这并非科幻，而是正在发生的现实。最近，Google Chrome 团队推出了一项名为 WebMCP 的新标准，宣称能让网站更高效地与 AI 代理交互。但黑客新闻上的开发者们却在疯狂吐槽：「这根本不是问题」、「不过是让网站暴露更多接口给 AI，但维护成本全由网站承担」。一场关于未来网络的争论，正悄然爆发。

WebMCP 全称 Web Model Context Protocol，是 Chrome 团队在 2026 年 2 月推出的早期预览功能。根据 Chrome for Developers 的官方博客，它的目标是让网站能被 AI 代理更可靠地交互。具体来说，它提供了两种 API：声明式 API 通过 HTML 表单直接定义标准操作，命令式 API 则用 JavaScript 处理复杂动态交互。

例如，一个航班预订网站可以用声明式 API 定义「搜索航班」、「选择座位」等标准动作，而复杂的流程如「根据预算和偏好筛选航班」则用命令式 API 处理。这样，AI 代理无需解析 HTML，就能直接调用这些功能，提高效率和准确性。这听起来很理想，但开发者们立刻发现了问题：「为什么需要新标准？OpenAPI 早就存在了」。

为什么需要新标准？

OpenAPI（曾用名 Swagger）是广泛使用的 API 描述规范，用于后端服务交互。但 WebMCP 针对的是前端 UI 操作——比如用户在网页上点击按钮、填写表单的场景。有人质疑：「如果网站已经提供 OpenAPI，为什么还要额外维护 WebMCP？」评论中有人直言：「这不过是让网站暴露更多接口给 AI，但维护成本全由网站承担」。

更尖锐的批评来自技术细节。一位开发者指出：「浏览器自动解析 DOM 比维护额外接口更合理」。意思是，AI 代理可以直接读取现有 HTML 结构，无需网站专门适配。而 WebMCP 要求网站开发者额外编写代码，这反而增加了工作量。另一位用户讽刺：「当 AI 智能到能自动理解网页时，何必再让网站重新设计接口？」。

安全与滥用风险

WebMCP 的核心争议在于信任模型。在本地 MCP（如 Claude 的工具调用）中，用户明确选择可信的工具；但 WebMCP 让网站直接定义工具，浏览器自动调用。这意味着恶意网站可能暴露虚假接口。例如，一个「add_to_cart」工具可能实际执行数据窃取，而非添加商品。

一位开发者警告：「WebMCP 翻转了信任模型：网站定义工具，浏览器决定调用，安全风险远高于本地 MCP」。具体来说，如果网站定义「book_flight」工具，但内部代码偷偷将用户数据发送到第三方服务器，AI 代理根本无法察觉。这比单纯爬取网页更危险——因为操作权限被主动授予。

类似担忧也出现在支付场景。有评论提到：「Klarna/BNPL 这种内置支付选项，用户从未主动开启」。WebMCP 可能让网站在用户不知情下，通过 AI 代理完成高风险操作。安全专家认为：「这比 CAPTCHA 更难防御，因为攻击者直接利用了网站自身的接口」。

与现有技术的冲突

WebMCP 的出现让人联想到「语义网」（Semantic Web）——20 年前的尝试，用 RDF、OWL 等让机器理解网页数据。但语义网最终失败，因为「没人愿意花时间标记数据」。如今 WebMCP 重蹈覆辙：「网站为何要为 AI 适配？这只会让竞争对手更容易获取数据」。

无障碍标准（accessibility）也面临类似质疑。有人问：「为什么不用现有的无障碍 API？它已经能让屏幕阅读器理解页面结构」。而 WebMCP 的支持者辩称：「无障碍针对残障人士，AI 代理需要更直接的交互」。但反对者反驳：「两者目标重叠，重复建设只会让生态更混乱」。

最现实的对比是 OpenAPI。一位开发者指出：「如果网站想让 AI 代理访问，直接提供 API 即可，WebMCP 只是营销话术」。技术上，WebMCP 的声明式 API 本质是 HTML 表单的增强版，命令式 API 则是 JavaScript 函数封装——这些早已被 OpenAPI 覆盖。「为什么不用已有的标准，非要发明新名词？」这是多数开发者的困惑。

大公司控制的阴影

WebMCP 的争议还涉及权力集中。Google 曾推出 AMP（加速移动页面），承诺提升网页加载速度，但实际导致内容生产者被迫适应 Google 的标准，否则搜索排名下降。AMP 最终被弃用，但期间损害了生态。如今 WebMCP 被质疑：「这会成为 Google 的私人网络，内容生产者只能接受其规则」。

评论中有人直言：「当 Google 控制浏览器和 AI 模型，WebMCP 将决定哪些网站能被 AI 代理访问」。例如，如果网站不支持 WebMCP，Google 的 Gemini 可能直接屏蔽其内容。这与 AMP 的逻辑一致：「网站必须遵循 Google 的规则，才能获得流量」。一位开发者总结：「AMP 死了，但 WebMCP 的幽灵还在游荡」。

现实中的替代方案

反对者并非完全否定 AI 代理的价值。他们指出，现有工具早已能解决复杂任务。例如，matrix.itasoftware.com 已能处理「查找最便宜航班，避开早晚航班，包含行李费」等复杂查询，且运行了近 30 年。「为什么需要新标准？」这是许多人的疑问。

对内部系统，AI 代理确实有用。有开发者分享：「我的企业应用用本地 MCP，让 AI 自动处理工单，效率提升明显」。但这属于可控环境，无需全网标准。而 WebMCP 试图将这种模式推广到公开网站，却忽略了「网站不想被 AI 代理抓取数据」的商业逻辑。「如果 Amazon 不想让 AI 自动下单，它会主动开放接口吗？」一位评论者反问。

未来会怎样？

WebMCP 的争议本质是技术理想与商业现实的碰撞。支持者认为：「AI 时代需要标准化的交互协议」；反对者则坚持：「让网站用现有 API，AI 代理自己解析页面更简单」。历史经验表明，类似标准往往难逃「宣传时轰轰烈烈，落地时无人问津」的命运。

AMP 的教训犹在眼前：Google 推动的标准，最终因缺乏广泛支持而消亡。WebMCP 可能重蹈覆辙。一位开发者总结：「当技术与商业利益交织，WebMCP 的未来取决于开发者和用户能否真正掌握选择权」。但当前的舆论风向已经明确：「这大概率是又一场营销闹剧」。