WebMCP：让您的网站与AI代理对话

# WebMCP：教会你的网站与AI代理对话 来源：https://sreenathmenon.com/blog/2026-08-04-webmcp-teaching-websites-to-talk-to-ai-agents/ 想象一个AI代理正试图在餐厅网站上为你预订餐位。如今，它的工作方式就像一个非常有耐心、但略显困惑的实习生：加载页面，阅读原始HTML，试图从四十多个元素中找出哪个是日期选择器，猜测绿色按钮可能意味着“确认”，点击它，等待，然后重新读取整个屏幕看是否有任何变化。如果下周把按钮挪个位置，代理就会失效。改个CSS类名，它也失效。在顶部加一个Cookie横幅，它就会完全点错东西。 这就是目前几乎所有“使用网站的代理”的工作方式：屏幕抓取，然后祈祷成功。这相当于通过电话描述截图来操作计算机，是自动化领域等效的低效操作。 **WebMCP**提出了一种更合理的方式：代理无需通过“凝视”来猜测你的网站能做什么，而是让你的网站主动*声明*自己能做什么——以一组清晰、结构化的工具形式，供代理直接调用。“这里有一个`book_table`工具，它接受日期、时间和用餐人数。调用即可。”无需像素识别，无需猜测。 最棒的是：它已经在Chrome浏览器后台试运行，添加你的第一个工具大约只需十分钟。让我为你详细说明。 ## 核心转变：从抓取到声明 整个理念可以用一个简单的对比来概括：相同的任务，两个不同的世界。 #### 现状：代理抓取网页 1. 读取整个DOM 2. 猜测哪个元素是日期字段 3. 模拟输入和点击 4. 重新读取整个页面以检查结果 5. 布局改变时就会失效 #### WebMCP：网站声明能力 1. 页面注册一个**book_table**工具 2. 代理读取该工具的模式（schema） 3. 代理使用结构化参数调用它 4. 工具运行你的真实JS代码，返回结果 5. 设计重构？没问题——工具就是契约 左侧方式之所以脆弱，是因为代理每次都逆向工程你的界面。右侧方式之所以稳定，是因为你提供了一个真实的接口。只要工具的名称和模式保持不变，底层布局可以自由调整。 如果你读过我之前关于MCP的文章《MCP：让AI触及世界的端口》(https://sreenathmenon.com/blog/2026-06-30-mcp-the-port-that-let-ai-touch-the-world/)，你会感到熟悉，也应该如此。MCP为AI提供了一种调用服务器工具的标准方式。WebMCP将同样的理念带入浏览器：网页*本身*成为一个提供工具的地方，在你已打开的标签页中运行，使用你已登录的会话。 ## 它到底是什么 WebMCP是一个拟议的Web标准，由Google（Chrome）和Microsoft（Edge）在W3C Web机器学习社区组联合开发，它为网页提供了一个小型JavaScript API，用于注册AI代理可以发现和调用的工具。Google在Chrome文档中对此的描述直截了当：一种“为AI代理构建和暴露结构化工具”的方式，网站通过标注自身功能，让代理“确切知道如何与它们交互”。 需要明确其成熟度：它是一个社区组*草案*，而非最终的W3C标准，也尚未进入标准轨道。这正是现在学习并塑造它的时机。 三点使其成为可能： - **发现机制。**页面以标准方式声明“我提供这些工具”，如`checkout`或`filter_results`，代理便可列出它们。 - **模式（Schemas）。**每个工具以JSON Schema声明其输入和输出，代理确切知道传递什么，大大减少了幻觉或误读的空间。 - **状态感知。**对页面当前状态有共同理解，使代理知道它实际上可以操作什么。 ## 现状如何 WebMCP是真实可运行的，但尚处于早期阶段。它从**Chrome 149开始作为Chrome源（Origin）试用版**提供，你也可以在本地通过标志`chrome://flags/#enable-webmcp-testing`启用。该提案托管在`github.com/webmachinelearning/webmcp`，Angular已提供实验性支持，Chrome还提供了示例网站（披萨制作器、旅行搜索、餐厅预订）。 用Google自己的话说：它“正在积极讨论中且可能变更”。所以这是一个“尝试并塑造它”的时刻，而非“部署到生产环境”的时刻，这正是现在值得学习的原因。 ## 一次调用的实际流程 以下是完整的循环：从页面到代理再返回。没有神奇之处：页面注册工具，代理列出它们，选择一个，用结构化参数调用它，你自己的JavaScript在页面中完成工作。 页面**注册工具** → 你的JS声明`book_table`、`search`等 → 代理**发现工具** → 列出页面的工具及其模式 → 代理**带参数调用** → 匹配模式的结构化JSON → 页面**执行execute()** → 你的真实JS，在已登录的页面中运行 → 代理**获得结果** → 一个结构化的答案，在标签页中可见地呈现 工具的`execute`函数在你实际的页面内运行，使用你现有的JavaScript、状态和用户已登录的会话。它在标签页中可见地发生，而非在某个不可见的无头浏览器中，因此用户可以观看并信任它。 这个“在你已登录的页面中运行”的细节意义重大。代理不是使用盗用凭证在别处登录的独立机器人。它在*你*打开且经过身份验证的标签页中调用函数，使用你已有的会话。网站保持对其暴露内容的控制，用户可以亲眼看到过程。 ## 观看一次调用发生 具体来说，当你要求浏览器内的代理在支持WebMCP的网站上执行操作时，流程如下：你的请求，代理选择声明的工具，工具运行，结果返回。 你 › 今晚8点为4人订一桌 代理 › 在此页面上找到工具 `book_table` 代理 › 调用 `book_table({ date: "today", time: "20:00", party: 4 })` 页面 › 已预订。4人桌，晚上8点，确认号#A17。 整个交互中没有任何DOM猜测。代理调用了一个带有类型化参数的命名函数，页面用自己的代码完成了其余工作。这就是代理*操作你的网站*与代理*操作你网站的照片*之间的区别。 ## 代码量确实极小 这部分内容让人想立刻尝试。注册一个工具只需一次调用。使用当前来自Chrome文档的命令式API，一个待办事项网站添加“添加条目”工具大致如下： ```javascript // 注册一个WebMCP工具（命令式API） await document.modelContext.registerTool({ name: 'add_todo', description: 'Add an item to the to-do list', inputSchema: { type: 'object', properties: { text: { type: 'string' } }, required: ['text'] }, execute: async ({ text }) => { addTodoToPage(text); // 你现有的函数 return `Added to-do: ${text}`; } }); ``` 就这么多。你为工具命名、添加描述、定义输入模式，并提供一个调用你已有代码的`execute`函数。代理通过`getTools()`发现它，如果工具不再相关，你可以用`AbortController`将其撤回。 还有一种声明式方式，你可以标注HTML表单而无需编写JS。 注意`execute`的作用：它调用了`addTodoToPage`，一个你网站上已存在的函数。WebMCP并不要求你重建任何东西。它是将你网站已能执行的操作包装在一个轻量的、声明的接口中，以便代理可以干净地调用它们。这就是“十分钟”说法的真实之处。 一个准确性说明：由于API年轻且在发展，入口点最近从`navigator.modelContext`（原名，现已弃用）移至`document.modelContext`，因为工具真正属于文档，而非整个浏览器。如果你参考较早的教程看到`navigator`，原因即在此。一行垫片代码（`const mc = document.modelContext || navigator.modelContext`）可在变更推出期间兼容两者。预计还会有类似边界变化；这是草案阶段。 ## 一个贯穿始终的真实案例 官方的WebMCP演示都是“调用一个工具就结束”，比如订披萨、订桌。有用，但低估了其理念。因为WebMCP有趣之处不在于单次工具调用，而在于代理*链接*工具以完成实际工作，并在重要环节设置人类监督。所以，我并非构建一个玩具，而是创建并部署了一个真实的案例以配合本文，这一节是对其诚实的详细说明，因为它比任何抽象示例都能更好地诠释整个模型。 **Career Copilot**是一个实验性的智能职业门户。你上传简历，它从实时公司招聘板读取真实的职位描述，评估你的实际匹配度，告诉你技能缺口，并准备一批申请供你一键批准。没有任何伪造：职位是真实的，匹配是根据真实的职位描述文本计算得出，在未经你明确同意的情况下不会提交任何申请。 **Career Copilot，一个实时WebMCP职业门户** 打开它，点击“立即查看工作效果”，观看一个代理在实时数据上执行完整的求职任务：读取简历，从GitLab、Stripe和Databricks拉取真实职位空缺，阅读每个职位描述，评估你的匹配度，发现你的技能缺口，并为你建议一批待批准的申请。它在页面上注册了**13个真实的WebMCP工具**。 打开实时演示 → (https://webmcp-career-copilot-production.up.railway.app/) 已部署并验证。开启`chrome://flags/#enable-webmcp-testing`后，页面报告“WebMCP active, 13 tools registered”，并在DevTools WebMCP面板中显示。无需开启标志即可尝试：一个按钮即可运行整个任务。它实际上从不提交申请，只是准备好供你审核后停止。 ### 工作流程：代理实际做了什么 以下是真实的任务，逐步说明。每一行都是页面暴露的一个WebMCP工具；代理将它们链接起来。注意其结构：一个运行阶段，然后是重要的操作阶段，该阶段会等待人类介入。 `parse_resume` 读取**任何**简历为真实档案：技能、资历、关注领域 `aggregate_openings` 从三个真实的公司招聘板拉取实时职位 `match_profile` 获取每个真实的**职位描述**并评估你的真实匹配度 + 差距 `find_gaps` 将差距汇总为学习信号：“学习X以解锁更多职位” `shortlist` 将最匹配的职位加入你的候选清单。可逆 `prepare_applications` 为每个职位定制摘要，供审核 `submit_batch` 打开**人类批准**面板：审核集合，取消勾选任何不想申请的，然后申请 `gate` 真实的代理循环。前四个工具是只读的，代理可以自由收集和推理。然后`shortlist`和`prepare`改变可逆状态。只有最后一个，代表你申请，是产生实际影响的，没有你的点击批准就不会发生。这种分割是WebMCP整个安全模型的具体体现。 ### 工具按功能分组 这种分组值得内化，因为这是设计任何WebMCP接口的方式：区分仅仅*读取*和实际*操作*，并将人类批准仅设置在真正需要的地方。 13个工具，三个层次。WebMCP允许工具通过诸如`readOnlyHint`之类的标志来标记自身，这样代理（和浏览器）就知道哪些调用可以自由安全地进行，哪些需要人类参与。正确分类是使智能接口值得信赖的关键。 ### 一次真实运行，而非模拟 以下是使用一位前端工程师简历进行的真实运行中的实际工具活动日志。观察它如何阅读真实描述并诚实评分，没有虚假的99%匹配度： 工具活动 · 真实运行 → 工具 `parse_resume(...)` ✓ 结果 Sam Patel, Senior Frontend Engineer · 11 skills · frontend focus → 工具 `aggregate_openings()` ✓ 结果 75个实时职位来自GitLab, Stripe, Databricks → 工具 `match_profile()` ✓ 结果 正在阅读24个真实的职位描述... ✓ 结果 **Design Engineer, Presence @ GitLab: 80%**, 无差距 ✓ 结果 Senior Software Engineer, Fullstack @ Stripe: 57%, 差距: python ✓ 结果 AI Engineer @ GitLab: 54%, 差距: python, llm → 工具 `find_gaps()` ✓ 结果 匹配职位中的主要差距：python, testing, api → 工具 `shortlist([4 roles])` → 工具 `prepare_applications([4])` ⏸ gate 等待你批准4份申请... ✓ 结果 已申请3份（你取消了1份） ✓ · 任务完成。 一次真实的运行。前端简历真正的最佳匹配，80%的Design Engineer职位，来自阅读真实的职位描述，而非职位名称（标题从未提到“React”）。评分诚实且有上限，差距真实，人类批准了批量中的4份中的3份。 换上后端或数据简历，整个列表会根据那个人的真实最佳匹配重新排序。这是抓取工具根本无法做到的。 ### 唯一困难的部分，以及为何人类批准是正确答案 构建这个项目让我认清了“自动申请”的诚实极限，值得明确指出，因为这是真正的工程经验。在申请按钮之前的一切都容易自动化且真正有用：阅读简历、汇总职位、匹配、定制。*最后一公里*，即实际提交到公司的申请系统，才是困难所在。这些系统（Workday、Greenhouse及其同类）有意不提供开放API，它们位于登录和机器人检测之后，自动化提交通常违反其服务条款。这正是WebMCP旨在弥合的差距。 如果一个招聘网站像这个演示一样暴露一个`submit_application`工具，代理就可以在你自己的认证会话中，经你批准，干净地申请。在网站这样做之前，正确的设计不是伪造最后一公里，而是**自动化到那一步为止，并在提交环节保留人类决策**。这不是妥协。一个默默代表你申请工作的代理是风险；一个完成所有工作并在代表你行动前征求你同意的代理是超能力。WebMCP的同意模型使得这条界线可以被强制执行。 完整源代码是一个自包含的HTML文件，我在仓库中以设计说明的形式写下了更深入的产品思考、候选人和雇主视角、分阶段构建、以及诚实的局限性。 ## 信任模型，因为这是令人担忧的部分 显而易见的担忧是：如果页面可以向代理提供工具，恶意页面是否能诱骗代理做可怕的事情？设计认真对待了这一点，值得了解其防护措施。 - **它在标签页中可见运行。**没有无头、后台执行。浏览上下文必须打开，因此操作发生在用户可见的地方。 - **仅限源隔离。**工具只能在源隔离的文档中注册，并受`tools`权限策略控制，默认为`self`，因此随机的跨源iframe无法悄悄注册工具。 - **敏感操作可要求人类参与。**对于购买等操作，工具可以在进行前要求明确的用户确认对话框。人在回路中是内置于模式的，而非事后添加。 - **不受信任的内容会被标记。**工具带有诸如`readOnlyHint`和`untrustedContentHint`之类的注释提示，这样代理可以对返回第三方内容的工具保持适当的警惕，考虑到我们关于提示注入 (https://sreenathmenon.com/blog/2026-08-02-llm-security-prompt-injection-and-the-cost-of-defending/) 的所有知识，这很重要。 这些都不能使其神奇地安全，标准还年轻，安全模型仍在完善中，但方向是正确的：可见、同源、同意门控，并对不受信任的数据保持诚实。 ## 诚实的优缺点 **为何令人兴奋** * 结构化工具调用取代了脆弱的DOM抓取 * 在用户真实的、已登录的会话中运行，无需单独的机器人认证 * 网站保持对暴露内容的控制权 * 能适应设计重构：工具契约比布局寿命更长 * 复用你已有的代码，采用成本极低 * 真正的标准化方向，而非某个厂商的锁定 **为何尚属早期** * 实验性：仅限源试用，可能变更 * 目前Chrome优先；广泛的浏览器支持尚未到来 * 需要网站采用才能发挥作用；代理无法调用不存在的工具 * 可发现性差距：客户端必须访问网站才能了解其工具