Chrome 团队发布了 WebMCP 的早期预览版，一句话概括：网站可以直接告诉 AI Agent「我这里能做什么、怎么做」，不用 Agent 自己去猜 DOM、点按钮了。这东西如果铺开，浏览器 Agent 的玩法会彻底改变。
现在的浏览器 Agent 有多脆弱？
先说背景。当前市面上的浏览器 Agent——不管是 Browser Use、Stagehand 还是各种 RPA 工具——本质上都在做同一件事：模拟人类操作。截屏、分析 DOM 树、猜测按钮位置、模拟点击。
这套方法存在几个致命问题：
网站一改版，Agent 就失效了。按钮换个位置、class 名改一下，之前写好的自动化脚本全部报废。做过爬虫的都懂这种痛苦。
速度慢、成本高。Agent 需要不断截屏、分析页面结构、推理下一步操作，每一步都在消耗 token。一个简单的机票搜索，可能要来回十几轮对话才能完成。
可靠性差。Agent 在猜测「这个按钮是干什么的」，猜错了就走偏了。复杂表单、多步流程、动态加载的内容，都是大坑。
用一个开发者的话说：「这就像让机器人走到仪表盘前面去读数字，而不是直接给它接一根数据线。」
WebMCP 到底是什么？
WebMCP 是 Chrome 团队提出的一个新 Web 标准，核心思路很简单：让网站主动暴露结构化的工具接口给 AI Agent。
具体来说，它提供了两种 API：
声明式 API：直接在 HTML 表单里定义标准操作。比如一个航班搜索表单，网站可以声明「这是一个搜索航班的工具，参数是出发地、目的地、日期」，Agent 拿到这个声明就知道怎么用了。
命令式 API：通过 JavaScript 的 navigator.modelContext 接口注册更复杂的工具。适合那些需要动态交互的场景，比如多步骤的结账流程。
知名 Web 开发者 Maximiliano Firtman 第一时间做了解读，他的推文拿到了 123 万阅读、2750 个赞。他指出了关键点：WebMCP 让 AI Agent 可以直接查询和执行网站服务，不用再像普通用户一样去「浏览」网页。
说白了，这就是从「爬虫模式」升级到「API 模式」。网站不再是一堵墙，而是一个主动开门的工具箱。
实际效果：数据说话
根据社区早期测试者的反馈，WebMCP 带来的提升相当可观：
- Token 消耗减少 89%
- 操作成功率达到 97.9%
- 单次交互成本降低 53%
这些数字来自 Stagehand 团队的实测。他们的创始人 Kyle Jeong 已经把 WebMCP 集成到了 Stagehand Agent 中，并录了一个演示视频：一个航班搜索网站暴露了 searchFlights 工具，Agent 直接调用这个工具完成搜索，不需要去页面上找搜索框、填表单、点按钮。
Kyle 说了一句很到位的话：「WebMCP 不是要杀死浏览器 Agent，而是给它们装上涡轮增压。」
两种 API 怎么用？
来看看具体的技术实现。
声明式 API 最简单，直接在 HTML 里标注：
<form data-tool="searchFlights">
<input name="origin" data-description="出发城市" />
<input name="destination" data-description="目的地" />
<input name="date" type="date" data-description="出发日期" />
<button type="submit">搜索</button>
</form>
Agent 看到这个表单，就知道这是一个搜索航班的工具，参数是什么、类型是什么，直接填入数据提交就行。
命令式 API 用 JavaScript 注册工具：
navigator.modelContext.registerTool({
name: "searchFlights",
description: "搜索可用航班",
parameters: {
origin: { type: "string", description: "出发城市" },
destination: { type: "string", description: "目的地" },
date: { type: "string", description: "出发日期" }
},
handler: async (params) => {
const results = await flightAPI.search(params);
return results;
}
});
网站开发者通过 registerTool 告诉 Agent：我这里有什么工具、怎么调用、返回什么。Agent 不需要理解页面布局，直接调用工具就行。
一个叫 Philomilan 的开发者在试用后评价：「网站告诉 Agent 怎么操作，Agent 就按规矩来——不再越界。这才是正确的交互方式。」
谁在推动这件事？
WebMCP 不是 Google 一家在搞。根据社区信息，Google 和 Microsoft 共同参与了 W3C 的规范制定。目前这个功能已经在 Chrome Canary 146 中可用，需要手动开启 flag。
WordPress 社区也动起来了。开发者 James LePage 用不到 200 行代码就把 WebMCP 适配到了 WordPress 的 Gutenberg 编辑器中。3D Web 开发工具 Needle Inspector 也已经加入了 WebMCP 支持。
这说明什么？标准一旦出来，生态跟进的速度可以很快。
但问题也不少
社区里不全是叫好声，也有不少冷静的声音。
采用率是最大的问号。 开发者 ejae_dev 说得很直白：「大多数网站连 meta 标签都懒得更新，你指望他们去写 WebMCP 工具声明？采用曲线大概率跟 schema.org 一样——几个大平台做得好，其他人等 Google 把它变成排名信号才会动。」
这个担忧很现实。WebMCP 需要网站主动适配，这跟当年的语义化 Web、结构化数据面临的问题一模一样。
安全和权限是另一个大坑。 开发者 GregoryMolt 列了三个 WebMCP 必须解决的问题：认证和用户同意的体验不能让人觉得可疑；最小权限原则加审计日志；可靠的速率限制和重试机制。
安全研究员 h4x0r_dz 更直接：「新的攻击面。」
还有人质疑必要性。 有开发者指出，现在的浏览器 Agent 在基准测试上已经能跑到 100% 的成功率了，WebMCP 真的有必要吗？
这个问题的答案取决于你怎么定义「成功」。基准测试和真实世界是两回事。在复杂的、动态变化的真实网站上，DOM 操作的脆弱性是结构性的，不是靠模型能力能完全弥补的。
更大的图景
有几个观点值得关注。
Leo Tavares 提了一个有意思的角度：如果每个网站都能声明式地暴露自己的能力，你其实在不知不觉中建了半个 Agent 间能力发现系统。Agent 可以在运行时发现新工具、组合工作流，而不是依赖硬编码的工具列表。这对多 Agent 协作来说是个巨大的解锁。
有人把 WebMCP 和 Tim Berners-Lee 2001 年提出的语义 Web 愿景联系起来——25 年前的想法，换了个马甲终于要落地了。当年是让机器理解网页内容，现在是让 Agent 理解网站能力。方向一样，只是驱动力从搜索引擎变成了 AI Agent。
还有一个有趣的观察：我们正在从「反机器人」转向「亲 Agent」。过去十年，网站花了大量精力防爬虫、防自动化。现在 Google 自己在推一个标准，让网站主动给 Agent 开后门。时代变了。
怎么参与？
WebMCP 目前处于早期预览阶段，需要加入 Chrome 的 Early Preview Program 才能访问文档和 API。
申请地址：https://developer.chrome.com/docs/ai/join-epp
Chrome Canary 146 已经可以通过 flag 开启 WebMCP 功能。如果你是网站开发者，现在就可以开始实验了。
不过说实话，现在入场更多是「看看方向」而不是「立刻上线」。标准还在早期，API 可能会变，生态还没起来。但如果你在做浏览器 Agent 相关的产品，这个方向值得密切关注。
WebMCP 能不能成，最终取决于一件事：大平台愿不愿意接入。如果 Amazon、Booking、各大银行开始支持 WebMCP，那就是真的起飞了。如果只停留在 demo 阶段，那就是又一个「好想法但没人用」的 Web 标准。
目前来看，Google 和 Microsoft 联手推、W3C 背书、社区反响热烈（原推 21 万阅读），赢面不小。但 Web 标准的推广从来不是技术问题，而是生态问题。这场仗，才刚开始。
更多关于前端开发和 AI 技术的讨论，欢迎访问云栈社区。
发表于 昨天 03:31
|
查看: 2|
回复: 0
