8.0
热点
AI SCORE
编程提效2026-08-26 23:02
WebMCP：让网站开口与 AI 代理对话的协议
Hacker News#Agent#协议#Web
Editor brief · 编辑速览
WebMCP 是一种让网站无需 API 改造即可被 AI 代理调用的协议，解决 Agent 访问网页内容的信息提取与交互难题，降低网站接入 Agent 的工程成本。
想象一个 AI 智能体试图在你的餐厅网站上帮你订位。如今它的工作方式像一个超级有耐心、略有困惑的实习生。它加载页面，读取原始 HTML，试图找出四十个 <div> 元素中哪个是日期选择器，猜测绿色按钮可能意味着"确认"，点击它，等待，然后重新读取整个屏幕看有没有发生什么。下周把那个按钮挪个位置，智能体就坏了。改个 CSS 类名，它也坏了。在顶部加个 Cookie 弹窗，它就会点错东西。
这就是目前几乎所有"智能体使用网站"的方式：屏幕抓取，然后碰运气。这相当于通过电话描述截图来操作电脑——是自动化的原始形态。
WebMCP 提出了一个更合理的方案。智能体不再通过盯着网站来猜测它能做什么，而是让你的网站声明它能做什么，作为一组干净、结构化的工具让智能体直接调用。"这里有一个 book_table 工具，它接受日期、时间和人数。调用它。"不需要像素读取，不需要猜测。最棒的是：它已经在 Chrome 中以试用形式运行，添加你的第一个工具大约需要十分钟。
让我来展示完整内容。
核心转变：从抓取到声明
整个理念用一组对比就能说明。同样的任务，两个世界。
现在：智能体抓取
WebMCP：网站声明
book_table 工具左栏之所以脆弱，是因为智能体每次都在逆向工程你的 UI。右栏之所以稳定，是因为你给了它一个真正的接口。布局可以在保持工具名称和 schema 不变的情况下自由变化。
如果你读过之前关于 MCP 的文章——那个让 AI 接触世界的端口——这会让你感到熟悉，也应该让你感到熟悉。MCP 给 AI 提供了一个调用服务器上工具的标准方式。WebMCP 将同样的理念带入浏览器：网页本身成为一个提供工具的地方，运行在你已经打开的标签页中，使用你已经登录的会话。
WebMCP 是一个提议中的 Web 标准，由 Google（Chrome）和 Microsoft（Edge）在 W3C Web Machine Learning Community Group 中联合开发，它给网页提供一个小型的 JavaScript API 来注册工具，AI 智能体可以发现并调用这些工具。Google 在 Chrome 文档中平淡地描述它：一种"为 AI 智能体构建和暴露结构化工具"的方式，网站标注自己的功能，这样智能体就能"准确地知道如何与它们交互"。关于成熟度要精确说明：它是一份 Community Group 草案，不是完成的 W3C 标准，也还没有进入标准轨道——这正是为什么现在是学习它和塑造它的时机。
有三个要素让它运转起来：
发现：页面说"我提供这些工具"的标准方式，比如 checkout 或 filter_results，这样智能体可以列出它们。
Schema：每个工具声明其输入和输出为 JSON Schema，这样智能体准确地知道该传递什么，而且产生幻觉或误读的空间大大减少。
状态：对页面上当前内容的共同理解，这样智能体知道它实际可以操作什么。
WebMCP 是真实的、可运行的，但还处于早期阶段。它从 Chrome 149 开始作为 Chrome 源试用版可用，你可以通过标志 chrome://flags/#enable-webmcp-testing 在本地开启它。提案位于 github.com/webmachinelearning/webmcp，Angular 已有实验性支持，Chrome 提供了演示站点（一个披萨制作器、旅行搜索、餐厅订座）。Google 自己的话：它"正在积极讨论中，可能会有变化"。所以这是一个"尝试它并塑造它"的时刻，而不是"将它投入生产"的时刻——这正是为什么它值得现在学习。
WebMCP 是真实的、可运行的，但还处于早期阶段。它从 Chrome 149 开始作为 Chrome 源试用版可用，你可以通过标志 chrome://flags/#enable-webmcp-testing 在本地开启它。提案位于 github.com/webmachinelearning/webmcp，Angular 已有实验性支持，Chrome 提供了演示站点（一个披萨制作器、旅行搜索、餐厅订座）。Google 自己的话：它"正在积极讨论中，可能会有变化"。所以这是一个"尝试它并塑造它"的时刻，而不是"将它投入生产"的时刻——这正是为什么它值得现在学习。
这里是完整的循环，页面到智能体再回来。没有什么奇特的：页面注册工具，智能体列出它们，选择一个，用结构化参数调用它，然后你的 JavaScript 在页面中完成工作。
page › 注册工具
你的 JS 声明 book_table、search 等 →
agent › 发现
列出页面的工具及其 schema →
agent › 用参数调用
匹配 schema 的结构化 JSON →
page › execute() 运行
你的真实 JS，在已登录的页面中 →
agent › 获取结果
结构化的回答，清晰地显示在标签页中
工具的 execute 函数在你的实际页面中运行，使用你现有的 JavaScript、状态和用户自己的已登录会话。它在标签页中可见地发生，而不是在某个无头浏览器中不可见地发生，这样用户可以观察它并信任它。
"在你已经登录的页面中运行"这个细节很重要。智能体不是另一个用偷来的凭证在别处登录的机器人。它是在你打开的、已认证的标签页中调用一个函数，使用你已经拥有的会话。网站保留对暴露内容的控制权，用户可以看到正在发生的事情。
具体来说，当你让一个浏览器内智能体在启用 WebMCP 的网站上做某事时，它看起来是这样的：你的请求，智能体选择声明的工具，工具运行，结果。
you › 预订今晚 8 点 4 人的位子
agent › 在此页面上找到工具 book_table
agent › 调用 book_table({ date: "today", time: "20:00", party: 4 })
page › 已预订。8:00 PM 的 4 人桌，确认号 #A17。
这个交换过程中没有任何 DOM 猜测。智能体用一个带类型参数的命名函数来调用，页面用你自己的代码完成了其余工作。这就是"智能体在你的网站上操作"和"智能体在一张网站的照片上操作"之间的区别。
这是让人想要尝试的部分。注册一个工具只需一次调用。使用 Chrome 文档中当前的命令式 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}`;
}
});
这就是全部内容。你给工具一个名称、一个描述、一个 input schema，和一个调用你已写好的代码的 execute 函数。智能体通过 getTools() 发现它，你可以用一个 AbortController 在工具不再相关时将其撤回。还有一种声明式变体，你可以在 HTML 表单上做标注而不是写 JS。
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 做了什么：它调用了 addTodoToPage，这是一个已经存在于你的网站上的函数。WebMCP 没有让你重建任何东西。你只是在你的网站已经能做的操作上包了一层薄的、声明式的接口，这样智能体就能干净地调用它们。这就是为什么"十分钟"的声称是真实的。
一个准确性说明，因为 API 还年轻且在演进：当前的入口是 document.modelContext，而早期的草案使用 navigator.modelContext，这个移动是合理的，因为工具真的属于一个 document，而不是整个浏览器。如果你看到较旧的教程显示 navigator，现在你知道为什么了。一行 shim（const mc = document.modelContext || navigator.modelContext）在变更推出时桥接两者。预计还会有更多类似这样的边缘情况；这是一份草案。
官方的 WebMCP 演示都是"调用一个工具就完成"，订一个披萨，订一张桌子。有用，但它们低估了这个想法的价值，因为 WebMCP 有趣的部分不是一次工具调用。它是智能体链接工具来做真正的工作，并在关键部分有人类把关。因此，我没有用玩具演示，而是构建并部署了一个真实的来配合这篇文章，这一节是完整、诚实的走览，因为它比任何抽象的例子都更好地教了整个模型。
Career Copilot 是一个实验性的智能体职业门户。你提供一份简历，它从真实的公司职位看板读取真实职位描述，评估你真正的匹配度，指出你的技能差距，并准备好一批需要你一键审批的申请。没有半点虚假：职位是真实的，匹配计算基于真实的职位描述文本，任何操作都需要你明确批准才会执行。
Career Copilot，一个实时的 WebMCP 职业门户。打开它，点击"See it work instantly"，观看一个智能体在真实数据上完成整个求职任务：读取简历、从 GitLab、Stripe 和 Databricks 获取真实职位、阅读每个职位描述、评估你的匹配度、展示你的技能差距，并推荐一批申请让你审批。它在页面上注册了 13 个真实的 WebMCP 工具。打开在线演示 → 已部署并验证通过。开启 chrome://flags/#enable-webmcp-testing 后，页面会显示"WebMCP live, 13 tools registered"，它们会出现在 DevTools 的 WebMCP 面板中。不需要 flag 也能试用：一个按钮就能运行整个任务。它实际上从不真正提交申请，只是准备好后停下来等你确认。
打开它，点击"See it work instantly"，观看一个智能体在真实数据上完成整个求职任务：读取简历、从 GitLab、Stripe 和 Databricks 获取真实职位、阅读每个职位描述、评估你的匹配度、展示你的技能差距，并推荐一批申请让你审批。它在页面上注册了 13 个真实的 WebMCP 工具。
这不是一个示意图，而是真实的浏览器在证明这一点。开启 flag，打开 DevTools，Chrome 会新增一个 WebMCP 面板，列出页面注册的每个工具，每个工具的名称和描述都与智能体看到的一致。这就是整个理念的可视化呈现：网站声明自己的工具，浏览器直接从页面读取它们。
这些工具直接来自页面。Chrome DevTools → Application → WebMCP 面板。页面上注册的每个工具都以其真实名称和描述列出：aggregate_openings、compare_jobs、draft_outreach、explain_match，都是智能体会发现的内容。点击一个，查看其契约。选择 parse_resume 会打开一个详情面板：名称、完整描述、所在 frame，以及指向页面源代码中 registerTools 的 Origin。不需要爬取，不需要猜测，工具本身就是接口。来自已部署演示的真实截图。面板左侧是智能体看到的工具列表；右侧是一个工具的完整契约。这就是"网站与智能体对话"在当前浏览器中的实际样子。
而且真的有智能体在驱动它
在面板中列出工具是一回事。让生产环境中的 AI 智能体真正使用它们才是真正的考验。ChatGPT 现在支持 WebMCP，所以我让它访问这个在线演示，用大白话让它读取示例前端简历，找到技能匹配度最佳的职位，并在申请前停下来。它通过页面声明的工具完成了整个流程。
ChatGPT 使用这些工具。其自身追踪记录显示页面识别为 WebMCP live · 13 tools registered，命名了 parse_resume 工具，并以"Completed using the page's WebMCP tools."结束。没有 DOM 爬取，它调用的是声明的工具。它产生的结果。它读取了个人资料，聚合了 75 个真实职位，评估了 24 个真实职位描述，以真实百分比和实际差距排名匹配，停了下来：4 个入选，0 个申请。人类门槛守住了，完全符合设计预期。另一个供应商的智能体，使用了 DevTools 面板中列出的相同声明工具。分数不是从页面爬取的，是智能体调用 match_profile 工具时由其计算的。这正是 WebMCP 端到端工作的全部承诺：用文字描述任务，智能体通过清晰的接口操作网站，而不是猜测按钮的位置。
工作流程：智能体实际做了什么
这是整个任务的真实步骤。每行都是页面暴露的一个 WebMCP 工具；智能体将它们串联起来。注意这个形态：一个运行阶段，然后是一个需要人类确认的后果性操作阶段，在人类批准前停止。
| tool | activity |
|---|---|
| parse_resume | 读取任何简历为真实档案：技能、资历、专注领域 |
| aggregate_openings | 从三个真实公司职位看板拉取真实职位 |
| match_profile | 获取每个真实职位描述并评估你的真正匹配度+差距 |
| find_gaps | 将差距聚合成学习信号："学习 X 可解锁更多职位" |
| shortlist | 将最匹配的职位加入你的管道，可撤销 |
| prepare_applications | 为每个职位定制摘要，准备审核 |
| submit_batch | 打开人类审批面板：审核整个列表，可取消勾选，然后申请 |
| gate | 真正的智能体循环。前四个工具是只读的，智能体自由收集和推理。然后 shortlist 和 prepare 改变可逆状态。只有最后一个，以你的名义申请，才是有后果的，没有你点击批准就无法发生。这个分离就是 WebMCP 整个安全模型的具象化。 |
按功能分组的工具
这个分组值得深入理解，因为这才是设计任何 WebMCP 表面的正确方式：将纯粹读取的操作与真正执行的操作分开，并且只在真正需要的地方设置人类门槛。
读取（安全，无门槛）
执行（可撤销）
需要人类确认（后果性）
只有一个。这就是唯一会在你名义下执行操作的工具，所以它是唯一一个停下来等你批准的工具。13 个工具，三个层级。WebMCP 允许工具用类似 readOnlyHint 这样的提示来标记自己，这样智能体（和浏览器）就知道哪些调用可以自由执行，哪些需要人类介入。正确掌握这个分类法是让智能体表面值得信赖的关键。
一次真实的运行，不是模拟
这是一次经由前端工程师简历验证运行的真实工具活动日志。看它读取真实描述并诚实评分，没有虚假的 99%：
tool activity · real run →
tool parse_resume(…) ✓
result Sam Patel, Senior Frontend Engineer · 11 skills · frontend focus
→ tool aggregate_openings() ✓
result 75 live roles from GitLab, Stripe, Databricks
→ tool match_profile() ✓
result reading 24 real job descriptions… ✓
result Design Engineer, Presence @ GitLab: 80%, no gaps ✓
result Senior Software Engineer, Fullstack @ Stripe: 57%, gaps: python ✓
result AI Engineer @ GitLab: 54%, gaps: python, llm
→ tool find_gaps() ✓
result top gaps across matches: python, testing, api
→ tool shortlist([4 roles])
→ tool prepare_applications([4])
⏸ gate awaiting your approval for 4 applications… ✓
result applied to 3 (you unchecked 1) ✓
· Mission complete.
一次真实的运行。前端简历真正最匹配的职位——GitLab 上 80% 的 Design Engineer——来自阅读真实职位描述，而不是标题（标题里根本没有写"React"）。分数是诚实的、有上限的，差距是真实的，人类批准了这批中的 3 个。换上后端或数据简历，整个流程会重新排名为那个人的真实最佳匹配。这才是一个爬虫从根本上做不到的事情。
那件困难的事，以及为什么人类门槛是正确的答案
构建这个系统教会了我"自动申请"诚实的极限，这值得直说，因为这是真正的工程教训。在申请按钮之前的一切都很容易自动化，而且确实有用：读取简历、聚合职位、匹配、定制。最后一公里，真正提交到公司的申请系统，才是困难的部分。那些系统（Workday、Greenhouse 等）是故意不开放 API 的，它们躲在登录和机器人检测后面，自动化提交通常违反它们的服务条款。
这正是 WebMCP 要填补的空白。如果一个招聘网站像这个 Demo 一样暴露了一个 submit_application 工具，AI 智能体就能在你自己已认证的会话中干干净净地完成申请——而且经过你的批准。在网站做到这一点之前，正确的设计不是伪造最后一公里，而是把之前的所有步骤都自动化，保留一个人类在提交环节。这不是妥协。一个悄无声息地以你的名义投递简历的 AI 智能体是隐患；一个完成所有工作但在行动前征询你意见的 AI 智能体是超能力。WebMCP 的授权模型正是让这条界限可执行的东西。
完整的源代码是一个单一的、自包含的 HTML 文件，我在代码库中写了一篇更深入的产品思考、候选人端和雇主端、分阶段构建、诚实的局限性，作为设计笔记。
信任模型，因为这是令人担忧的部分
一个显而易见的担忧是：如果一个页面可以把工具交给 AI 智能体，一个恶意页面能否欺骗 AI 智能体做出可怕的事情？这个设计认真对待了这个问题，而且值得了解这些防护措施。
它运行在可见的标签页中。没有无头、后台执行。一个浏览上下文必须保持打开，所以操作发生在用户能看到的地方。
仅限同源。工具注册由一项 tools Permissions Policy 管控，默认只允许同源，因此一个随机的跨源 iframe 无法悄悄注册工具，除非顶层页面明确允许。
敏感操作可以要求人类确认。对于像购物这样的操作，一个工具可以要求在继续之前弹出明确的用户确认对话框。人在环中是内置于这个模式中的，而不是事后加上去的。
不可信内容会被标记。工具携带 readOnlyHint 和 untrustedContentHint 这样的注解提示，所以 AI 智能体可以对返回第三方内容的工具保持适当的怀疑，考虑到我们对提示注入的所有了解，这一点很重要。
这些并不能让它神奇地变得安全，标准还年轻，安全模型仍在制定中，但形状是对的：可见、同源、授权门控、对不可信数据诚实。
为什么它令人兴奋
结构化工具调用，而非脆弱的 DOM 抓取 在用户真实的、已登录的会话中运行，无需单独的机器人认证 网站保持对暴露内容的控制 经得起重新设计：工具契约比布局更持久 复用你已有的代码，引入成本极低 一个真正的标准方向，而非某一厂商的锁定
为什么它还很早期
实验性：仅限源试用，可能会有变化 目前仅限 Chrome；广泛的浏览器支持尚未到来 需要网站采用才能发挥作用；AI 智能体无法调用不存在的工具 可发现性缺口：客户端必须访问一个网站才能了解其工具 安全模型仍在成熟（恶意工具、注入） 复杂网站可能需要真正的重构才能暴露干净的工具
缺点几乎都是"它还早期"，而不是"它错了"。这是一个有前途的标准在其孕育期的特征：想法是合理的，生态系统还没跟上。
适用场景
这个模式在任何 AI 智能体需要在网站上做事的地方都能大放异彩，而不仅仅是读取内容。
电商：暴露 search_products、add_to_cart、checkout。AI 智能体通过真实的工具在你的商店购物，而不是通过点击四处逛。
预订和旅行：多城市、多乘客的行程或餐厅订位，当表单复杂且抓取困难时。
SaaS 仪表盘：让 AI 智能体运行你的应用已有的操作：创建工单、筛选报告、更新记录。
表单填写：声明表单的字段和一个提交工具；AI 智能体干净利落地映射数据，而不是猜测输入。
无障碍：一个声明式的、语义化的工具表面对于辅助 AI 智能体是一份礼物，比原始标记更清晰的意图。
内部工具：把你的管理面板的操作包装成工具，让内部助手能够安全、可见地驱动它们。
贯穿其中的主线：任何有"你可以做的事"（不仅仅是"你可以读的东西"）的网站都是候选者。你的网站操作越丰富，WebMCP 给你的就越多。
现在是精彩的部分，因为天花板很高。
最明显的下一步是在各浏览器间标准化。目前是 Chrome 试用版；目的地是一个每 个浏览器都实现的 Web 标准，就像 fetch 或 Clipboard API 那样无处不在。当那一天到来时，"这个网站有 AI 智能体接口吗？"成为一个和"这个网站移动端友好吗？"一样正常的问题。
那个方向刚刚得到了真正的推动：ChatGPT 现在支持 WebMCP。访问一个启用了 WebMCP 的页面，它就能自动使用该页面声明的工具来完成任务。这是一个有趣的信号——不只是 Google 和 Microsoft（他们编写了草案）了。当第二个主要 AI 厂商开始消费页面声明的工具时，一个处于孕育期的提案开始看起来像是生态系统真正在移动的方向。
然后是 AI 智能体化的 Web 本身。想象网站有意地与视觉界面一起发布 AI 智能体接口，就像今天他们发布移动布局一样。你的网站的 UI 是给人类的；它声明的工具是给 AI 智能体的；两者都是一等公民。一个擅长被 AI 智能体操作的网站会被更多的 AI 智能体使用，这变成了真正投资于工具表面的理由。
当你把 WebMCP 与远程 MCP 结合起来时，它变得更有趣了。WebMCP 处理浏览器中的内容（页面的自有操作、用户的会话），而远程 MCP 服务器处理后端工具和数据。AI 智能体可以流畅地同时使用两者：通过 WebMCP 调用页面的 add_to_cart 工具，然后访问远程库存 MCP 服务器查询库存，将客户端和服务器工具编织成一个任务。
再往后看：AI 智能体商务。如果一个商店暴露了干净的购买工具，并且 AI 智能体可以在用户已认证、已授权的会话中调用它们，你就拥有了一条让 AI 智能体安全地完成交易的路径——人类能够观察和确认，而不是爬虫疯狂捶打结账流程。同样的形态延伸到预订、排程、客服、任何交易性操作。
这一切背后的大赌注：Web 是为人类阅读和点击而构建的。下一个版本是为 AI 智能体也能被操作而构建的，干净利落，按网站自己的规则。WebMCP 是使这成为标准而非黑科技的首批认真尝试之一。
总结，以及去试试吧
用一句话概括整件事：WebMCP 让你的网站向 AI 智能体递出一套干净的工具，而不是强迫它逆向工程你的——