摘要
一句话摘要
谷歌推出的 WebMCP 早期预览版是一种浏览器原生 API，允许网站注册结构化函数供 AI 代理直接调用，通过继承当前会话状态和同源策略，实现了比传统 DOM 解析更高效、确定且安全的交互模型。
核心要点
- 发布动态：谷歌于2月13日宣布推出 WebMCP 早期预览版，开发者可通过 Chrome 实验性版本进行测试。
- 解决痛点：取代了传统 AI 代理依赖解析 DOM、可访问性树和模拟点击的脆弱方式，显著降低了 Token 消耗与执行延迟。
- 暴露模型：支持两种工具注册方式：声明式 API（基于 HTML 表单元数据自动注册）和命令式 API（基于 JavaScript 编程控制）。
- 局部性（Locality）特征：工具在活动的浏览器会话内部执行，直接继承现有的身份验证状态、Cookie 和同源边界，无需外部授权栈。
- 核心控制平面：浏览器通过暴露
navigator.modelContext充当中介，负责维护注册表、验证 Schema 输入、路由调用并强制执行安全边界。 - 标准制定：WebMCP 的正式规范目前正由 W3C Web 机器学习社区组（Web Machine Learning Community Group）负责制定。
- 生态协同：WebMCP 补充了 Chrome 的内置 AI API（本地推理），并可与 InsForge 等提供后端 MCP 服务器的 BaaS 平台结合，实现端到端的确定性代理执行。
风险与不足
- 提示词注入风险：WebMCP 虽然缩小了攻击面，但并未消除更广泛的安全风险，例如工具逻辑中可能存在的提示词注入（Prompt Injection）。
- 跨站执行限制：受浏览器同源策略的严格约束，默认情况下不允许跨站执行能力调用。
正文
2月13日，谷歌宣布推出 WebMCP 的早期预览版（Early Preview），为 AI 代理（AI Agents）提供了一种与网站交互的浏览器原生方式。要理解其重要性，我们需要先看看当前 AI 代理是如何运作的。
目前，AI 代理通过解析 DOM、检查可访问性树（accessibility trees）、分析渲染页面，然后模拟点击或输入来理解和操作界面。每一个动作都依赖于对表现层的推理。这不仅增加了 Token 的消耗和延迟，还常常导致执行过程非常脆弱。
这种局限性是结构性的。Web 最初是为人类浏览界面而设计的，而 AI 代理需要的是可以通过编程方式调用的、定义清晰的能力。
WebMCP 填补了这一空白。它允许网站注册结构化的 JavaScript 函数，AI 代理可以在浏览器运行时（runtime）中直接调用这些函数。这些工具在现有的会话状态和同源约束下执行，仅暴露网站明确定义的功能。
其结果是形成了一种更直接的交互模型，将前端系统与后端 MCP 集成中已经确立的确定性工具模式对齐。本文将探讨 WebMCP 的架构、它与传统 MCP 的对比，以及它对由代理驱动的 Web 基础设施意味着什么。
模型上下文协议（MCP）的现状与浏览器限制
模型上下文协议（MCP）为 AI 代理与外部系统交互建立了一个结构化模型。工具通过清晰的 Schema 进行定义，代理使用结构化输入来调用它们，并以可预测的格式返回响应。这确保了执行的确定性，而不是依赖于自由形式的推理。
这种架构通常是客户端-服务器模式。代理连接到暴露了封装 API、数据库或内部服务的工具的 MCP 服务器。这种模型非常适合在浏览器外部执行的后端环境。
然而，Web 应用程序的运行前提不同。用户身份、会话状态以及大部分应用逻辑都存在于浏览器内部。身份验证流程依赖于与该会话绑定的 Cookie 和联合登录系统。外部的 MCP 服务器无法自动继承这些上下文，这使得授权和状态管理变得复杂。
由于这种分离，与 Web 应用程序交互的 AI 代理往往最终只能控制界面本身，而不是调用结构化的能力。
WebMCP 技术概述
WebMCP 是一个浏览器原生的 API，允许网站直接在页面运行时内暴露结构化的、可供代理调用的工具。它借鉴了模型上下文协议的概念模型（即代理调用由 Schema 定义的工具），但专门针对浏览器内的客户端执行进行了实现。
在其核心，WebMCP 引入了一个全新的浏览器交互面。该接口允许网页注册可供 AI 代理发现和调用的能力。每个工具包含：
- 工具名称
- 工具描述
- 输入 Schema（参数的结构化定义）
- 执行处理程序（Execution handler）
与传统的 MCP 不同，WebMCP 不依赖于独立的 JSON-RPC 服务器。网页本身成为了工具提供者。执行过程与应用程序逻辑在同一个 JavaScript 环境中进行。
其正式规范目前正由 W3C Web 机器学习社区组（Web Machine Learning Community Group）制定。
工具暴露与执行模型
WebMCP 定义了能力是如何暴露的，以及代理如何在浏览器运行时内调用它们。它支持两种暴露模型：
1. 声明式 API（基于 HTML） 可以通过元数据对表单进行注解，从而实现工具的自动注册。浏览器从表单输入中派生出工具定义，使得简单的操作无需额外的 JavaScript 即可被代理调用。
2. 命令式 API（基于 JavaScript） 开发者可以通过编程方式注册工具。这种方法提供了对输入 Schema 和执行逻辑的完全控制，支持动态的、感知状态的或复杂的能力。
当代理加载启用了 WebMCP 的页面时，流程如下：
- 浏览器暴露已注册的工具。
- 代理检查可用的能力。
- 代理使用结构化参数调用选定的工具。
- 处理程序在页面运行时内执行。
- 向代理返回结构化的响应。
WebMCP 的决定性特征是局部性（Locality）。工具执行发生在浏览器会话内部，并继承：
- 当前的身份验证状态
- 会话 Cookie
- 同源边界
这消除了对外部传输层或独立授权栈的需求。WebMCP 专门专注于针对浏览器环境优化的、由 Schema 定义的工具调用，将 MCP 概念适配于客户端执行。
核心架构组件
WebMCP 引入了一种由浏览器中介的架构，将代理直接连接到应用程序的能力上，而无需外部传输层。
以下是完整的执行路径。WebMCP 定义了一个浏览器中介的执行模型，将代理直接连接到已声明的应用程序能力：
- AI 代理（AI Agent）： 代理发现已注册的工具，根据用户意图选择一个工具，发送符合声明 Schema 的结构化输入，然后接收结构化输出。交互通过明确的能力进行，而不是直接操纵界面。
- 浏览器运行时控制平面（Browser Runtime Control Plane）： 浏览器暴露
navigator.modelContext，它负责维护工具注册表、根据 Schema 验证输入、将调用路由到适当的处理程序、强制执行同源边界，并在活动页面上下文中执行处理程序。这消除了对外部传输层或独立 MCP 服务器的需求。 - 工具层能力面（Tool Layer Capability Surface）： 每个工具定义了一个命名的能力、其预期的输入 Schema 和一个执行处理程序。这些工具构成了应用程序和代理之间的契约。只有声明的能力才是可访问的。
- 应用程序执行层（Application Execution Layer）： 处理程序与 Web 应用程序在同一个 JavaScript 环境中运行。它们可以访问会话 Cookie、依赖现有的身份验证状态、调用内部服务并更新应用程序状态。执行始终保持在活动的浏览器会话中。
整体流程非常直接。页面加载并注册工具；代理检查可用能力并使用结构化输入调用其中一个；浏览器验证请求，在页面运行时内执行处理程序，并将结构化输出返回给代理。
与传统 MCP 及浏览器自动化的对比
WebMCP 介于后端 MCP 服务器和浏览器自动化框架之间。从架构、执行模型和能力暴露方面进行对比，差异会更加清晰。
传统的 MCP 提供结构化调用，但在浏览器上下文之外运行。浏览器自动化保留了会话状态，但依赖于界面操纵。WebMCP 则结合了结构化 Schema 与浏览器内执行，暴露已声明的能力，而不依赖于页面布局或选择器。
安全模型与执行边界
WebMCP 通过将执行限制在明确声明的工具上，缩小了代理与 Web 应用程序之间的交互面。
- 明确的能力暴露： 代理只能看到已注册的工具。除非有意暴露这些能力，否则代理无法随意遍历 DOM 或触发未记录的行为。
- 同源强制执行： 工具执行受浏览器同源策略的约束。页面只能在其自身的源边界内暴露能力。默认情况下不允许跨站执行。
- 会话继承： 工具在活动的浏览器会话中执行。它们继承页面中已建立的身份验证状态、Cookie 和用户上下文。WebMCP 本身不引入额外的凭证交换层。
- 受控的调用面： 输入参数必须符合声明的 Schema。浏览器在路由执行之前会验证结构化输入，从而限制格式错误或意外的调用。
与界面级别的自动化相比，WebMCP 通过将代理的访问权限限制在声明的函数上，减少了攻击面。它并没有消除更广泛的风险（例如工具逻辑中的提示词注入），但它将执行约束在由浏览器运行时强制执行的已定义能力边界内。
Chrome 早期预览与内置 AI 战略
WebMCP 可通过 Chrome 的早期预览计划（Early Preview Program）获取，并可以在实验性的 Chromium 版本中启用。该预览版允许开发者测试通过 navigator.modelContext 进行的工具注册，并评估浏览器内结构化的代理交互。
WebMCP 是对 Chrome 内置 AI API（支持设备端模型执行）的补充。内置 AI 实现了本地推理，而 WebMCP 则定义了代理如何通过声明的工具与 Web 应用程序进行接口交互。
这些举措共同将浏览器定位为 AI 执行环境，以及供外部代理使用的结构化能力交互面。
InsForge 与模型上下文协议
InsForge 是一个为 AI 辅助开发构建的开源后端即服务（BaaS）平台。它提供核心后端基础设施，包括数据库管理、身份验证、存储、无服务器函数和 AI 集成。其 API 经过结构化设计，以支持确定性的代理执行。
在其核心，InsForge 暴露了一个模型上下文协议（MCP）服务器，允许 AI 代理通过由 Schema 定义的工具与后端资源进行交互。代理可以检查数据库 Schema、执行查询、管理身份验证、执行存储操作，并使用结构化输入和可预测的响应来调用后端函数。
这种基于 MCP 的设计使代理能够以更清晰的执行路径和更少的歧义完成工作流。通过暴露明确的能力契约，InsForge 支持可靠的多步操作，而不依赖于界面级别的自动化。
总结
WebMCP 为 AI 代理提供了一种在浏览器内部与 Web 应用程序交互的明确方式。代理不再需要抓取 DOM 或模拟点击，而是使用类型化的 Schema 调用明确声明的函数。
这些函数在用户的活动会话中执行，并遵守常规的浏览器安全边界。这使得代理的行为更加可预测，也更容易推理。
InsForge 利用模型上下文协议（MCP）为 AI 代理提供结构化、由 Schema 定义的后端能力，从而实现确定性执行，并为 AI 原生应用程序提供更可靠的基础设施。
- 尝试使用 InsForge
- 快速入门指南请见此处