AI Agent 终于不用再费劲地“装人类”浏览网页了。
Google 在 Chrome 146 中悄然上线了 WebMCP 的早期预览版，通过一个实验性 Flag 即可开启。这一举措，很可能彻底改写 AI Agent 与网页交互的底层逻辑。
Chrome 146 包含了 WebMCP 的早期预览，通过 flag 开启，允许 AI Agent 直接查询和执行服务，而无需像用户一样浏览网页。服务可以通过命令式的 navigator.modelContext API 或声明式的表单来声明。
开发者 Alex Volkov 对此有个精妙的比喻：这就像是 UI 里的 API。
简单来说，WebMCP 是一个新的 Web 标准提案，它允许网站开发者向 AI Agent 或智能浏览器暴露一套结构化的工具集。这样一来，Agent 就不再需要模拟点击按钮或填写表单，而是可以直接调用网站提供的功能函数。
当前 AI Agent 的困境：在“蒙眼”操作
目前，绝大多数 AI Agent 操作网页的方式，本质上是在 模拟一个人类用户 的行为：截图、识别按钮位置、点击、等待页面加载、解析新页面的内容……
这就像一个天才助手被蒙上眼睛操作电脑，只能依靠一次次的截屏来“感知”屏幕变化。效率低下、成本高昂且异常脆弱——网站布局一旦改版，Agent 的识别逻辑就可能完全失效。
一个简单的搜索操作，Agent 可能需要消耗上千个 token 来处理截图和 DOM 解析。而 WebMCP 提供了一种截然不同的思路：让网站主动告知 Agent “我能为你做什么”。
WebMCP 的两种能力暴露方式
WebMCP 为开发者提供了两种将网站能力暴露给 Agent 的路径。
命令式 API
开发者可以通过 JavaScript 的 navigator.modelContext.registerTool() 方法来注册工具函数。例如，一个电商网站可以注册一个 search_products 工具，AI Agent 发现后，可以直接传入关键词调用该工具，并立即获得结构化的商品数据列表。整个过程无需截图、无需解析DOM、更无需模拟点击搜索框。
声明式表单
通过在 HTML 表单元素上添加特定的注解（annotations），让 Agent 自动理解页面提供的交互能力。这种方式配置更简单，适合功能相对固定的轻量级场景。
这两种方式可以混合使用，为不同复杂度的网站提供了极高的灵活性。熟练的开发者可以用命令式 API 实现精细控制，而简单的网站则可以通过声明式表单快速接入。
效率的飞跃：极大节省 Token 消耗
根据实际测试数据显示，使用 WebMCP 的结构化工具调用，相比传统的截屏式 Agent 交互，token 消耗最多可降低 89%。
这意味着，过去需要花费 2000 个 token 来处理一张截图才能“看懂”的页面内容，现在可能只需要一个 20 到 100 个 token 的 JSON 响应就能搞定。而且，由于调用的是明确的功能接口，Agent 无需再对操作结果进行额外的“验证截图”，工具的返回值本身就是可信的确认。
行业合力：微软与谷歌的联手
值得注意的是，WebMCP 并非谷歌的单方面行动。微软 Edge 团队曾独立提出了“WebModel Context”方案，而 Chrome 团队也有一个类似的“Script Tools”提案。
双方意识到方向一致后，决定在 W3C Web Machine Learning 社区组 的框架下，将提案合并为统一的 WebMCP。微软 Edge 平台的产品经理 Kyle Pflug 对此解释道：
WebMCP 让网页能够向 Agent 暴露 MCP 工具，类似于传统 MCP 服务器暴露的工具，但不需要单独的服务器组件。这对于“人在回路”的场景是天然适配的，因为它运行在浏览器的浏览上下文中，可以简化状态管理和认证——而这在传统的浏览 Agent 方案中非常棘手。
换言之，网页自身就变成了一个 MCP 服务器，却无需实际部署任何后端服务器组件。
认证与安全：复用现有会话
关于安全性，一个自然的疑问是：Agent 如何认证？它会复用用户当前的登录会话吗？
答案是肯定的。WebMCP 运行在浏览器的现有“浏览上下文”中，天然继承了用户当前的认证状态，并严格遵守浏览器的 同源安全模型。这意味着 Agent 调用的工具，其权限范围与用户手动操作完全一致，不需要额外申请 OAuth 或配置 API 密钥，这比传统的服务端 MCP 方案要简便得多。
Kyle Pflug 也预计，未来“一些网站会同时使用 WebMCP 和传统 MCP 服务器”，因为两者服务场景不同：WebMCP 适合用户在场的浏览器辅助场景，而传统 MCP 更适合无头的、自动化的服务端集成场景。
核心理念：AI 是辅助，而非替代
WebMCP 的设计哲学中有一条明确的红线：Agent 是人类的辅助工具，而非替代品。其官方文档列出的几项基本原则清晰地体现了这一点：
- 网页的人类交互界面仍然是主体，WebMCP 不会替代你的 UI。
- AI Agent 用于增强而非取代人类与网页的交互。
- 用户对 Agent 的所有操作应保持可见和可控。
- 设计目标是促进人与 AI 的协作，而非让 AI 完全自主运行。
因此，WebMCP 不支持无头浏览、完全自主的 Agent，也不支持直接的后端服务集成。它的设计初衷就是为了“用户坐在浏览器前，Agent 在旁提供智能协助”这一特定场景。
展望：两层 Web 与 “Agent SEO” 的萌芽
当主流浏览器开始原生支持 AI Agent 与网页进行结构化交互时，一个有趣的趋势可能出现：未来的网站或许需要构建两层接口。
- 面向人类的界面层：注重视觉体验、品牌叙事和情感化交互。
- 面向 Agent 的结构层：提供标准化、Schema驱动、高效响应的功能接口。
这甚至可能催生出新的竞争维度——“Agent SEO”。你的网站对 AI Agent 是否友好，提供的工具是否丰富易用，或许会成为影响其可见性和实用性的关键因素。那些不愿或未能暴露 WebMCP 工具的网站，对高效的 Agent 而言，可能会逐渐变得“不可见”。
尽管目前的 WebMCP 仍处于非常早期的阶段，API 设计仍在迭代，Chrome 146 中的实现也需要手动开启实验性 Flag，但其预示的方向已经相当清晰：浏览器正在演化，它不再仅仅是人类的交互工具，同时也正成为 AI Agent 高效运作的操作平台。对于开发者而言，提前了解并思考如何适应这一变化，或许能在即将到来的智能交互浪潮中占据先机。欢迎大家在 云栈社区 的 前端 & 移动 等相关板块进一步探讨 WebMCP 的技术细节与未来影响。
相关链接：
发表于 2026-2-11 21:00:23
|
查看: 33|
回复: 0
