WebMCP：把网站变成给 agent 的 API

让 AI 帮你买两张演唱会的票，它背后要做多少事？

按今天的做法，agent 会先把整个页面的 DOM 抓下来，再读一遍无障碍树（accessibility tree）去理解页面结构，然后截一张图，分析那些在 HTML 里看不到的元素，最后还要算一算目标按钮在屏幕上往下多少、往右多少，再点下去。这一长串动作很烧 token，而且脆。万一页面顶部刚好弹了个广告，把内容整体往下挤了一截，那一下点击就落空了。

Google Chrome 团队的 Tara Agyemang 在 AI Engineer 大会上讲了一个提案，想把这套「连看带猜」的操作方式换掉，叫 WebMCP。下面是我看完这场分享后的整理和判断。原视频：https://www.youtube.com/watch?v=ghJmWQCIHRM

网页一直是写给人看的

过去几十年，我们造网页是为人的眼睛和人的手服务的，所有优化都围着这个目标转。但现在用网页的不只有人，还有越来越多替人办事的 agent。问题在于，网站是按「人会看、会点」的假设设计的，agent 想完成一个简单动作，得付出前面说的那一大圈代价。

Tara 在讲 WebMCP 之前先泼了盆冷水：很多事，光把 Web 基础做扎实就能解决一大半。把语义化 HTML 写好，把无障碍标准做到位，把页面性能提上去（就是大家说的 Core Web Vitals），再把用户走的流程理顺。做到这些，你的网站其实已经对 agent 友好一半了。因为对人无障碍的网站，默认就对 agent 友好。她的原话是，只有当这些都到位了，再考虑 WebMCP 才有意义。

这点我特别认同，也愿意替她多说一句。WebMCP 还在很早期，但语义化和无障碍是十年前就该做、现在做了立刻见效的事。先去补 alt 文本和正确的表单标签，比急着追一个实验性标准划算得多。

WebMCP 到底是什么

WebMCP 的全称是 Web Model Context Protocol，一个还在提案阶段的 Web 标准。它让你把网站的能力定义成一组结构化的工具，交给 agent 去调用。

如果你熟悉 MCP，会立刻反应过来——这就是 MCP 那套思路搬到了浏览器里。我自己的知识库里一直把 MCP 记成「AI 连接外部世界的 USB-C」：不用每个 agent 各写各的接法，定义一次，所有支持的 agent 都能用。WebMCP 是同一个家族。Tara 的类比很传神：WebMCP 之于 MCP，就像 JavaScript 之于 Java，名字像、思路也借过来，但是另一个东西。

差别在于工具住在哪一边。经典 MCP 连的是服务端，你得自己搭一个服务，好处是 agent 随时随地都能访问。WebMCP 连的是浏览器：所有工具都活在浏览器窗口里，你必须开着那个网页，工具才存在。它专门服务客户端这一侧的交互。

核心变化只有一句话：以前 agent 要猜你的网站能做什么，现在你直接递给它一份菜单——一组有名字、有类型、有说明的动作，它照着调就行。Tara 说，这样一来 agent 操作网站的性能和可靠性都明显提升了。

两种写法：声明式和命令式

这是整场分享里最有干货的部分。WebMCP 给了两条实现路径，对应两种复杂度的场景。

声明式 API（declarative），针对普通表单。你有一个现成的 HTML <form>，只要加几个属性：给它起个工具名、写段工具描述，浏览器就会自动根据表单字段生成一份 JSON schema，agent 拿这份 schema 当参数说明来用。你几乎不用写额外代码。它还附带一些细节属性，比如有个 agent-invoked 的布尔值，能让你知道这张表单是 agent 填的还是人填的。

命令式 API（imperative），针对复杂的多步流程。当你的交互不是一张表单能搞定的，就自己注册工具。调用一个 registerTool 函数，传进去一个对象：手写一份 schema（和声明式自动生成的那份长得差不多）、起名、写描述。描述这块别偷懒，写得足够清楚，因为 agent 就是靠这段话判断什么时候该调它。然后是一个 execute 块，里面就是普通 JavaScript：你可以验证和清洗输入、操作 DOM、复用你已经写好的函数，最后把结果返回给 agent，让它知道这一步成没成、好接着做下一步。

两种写法的分工，列出来一眼就清楚：

Tara 说，实际用得最多的是命令式，因为大家手上的流程往往比一张表单复杂。这个判断挺实在。真正值钱的 agent 场景，恰恰是那些步骤多、用户填起来嫌烦的：订机票、按一堆条件筛商品、填复杂的医疗或金融表单。她举了个很生活化的例子：在购物网站上找一个「黑色、仿皮、能塞进手机」的手拿包，与其一个个点筛选框，不如一句话让 agent 去办。

一个容易被忽略的设计：工具是跟着页面走的

Tara 现场演示了两个 demo，其中迷宫那个藏着一个我觉得最该划重点的点。

那是个迷宫逃脱游戏，特别之处在于它根本没法用鼠标点着玩，只能靠 agent 操作。配套有一个 Chrome 扩展叫 Model Context Tool Inspector，挂在侧边栏，会把当前页面上能找到的工具全列出来。一开始这个页面只有一个工具：开始游戏。

agent 调用「开始游戏」进到迷宫之后，页面上的工具一下子多了起来——往北/南/东/西移动、查看当前位置和哪些方向是通的、捡起/放下/使用道具。你跟 agent 说「先往下，再往右」，它会把这句话映射到 move 这个工具，把方向翻译成对应的参数发过去。你甚至可以直接说「把迷宫走完」，让它自己反复调用这些工具，直到觉得做完了。Tara 提了一句很实用的经验：prompt 越具体，agent 越高效。比如你补一句「出口在右下角」，它就少走很多冤枉路。

这里的关键不是迷宫好不好玩，是工具的作用域是页面级的。第一个页面只有一个工具，进了迷宫页就换成另一套。这意味着网站作者能精确控制「在这一屏，agent 被允许做哪些事」。这跟服务端 MCP 那种「一个服务端工具集全程可用」是两种思路。对做产品的人来说，这是个很自然的权限和上下文边界——agent 在结账页能调的工具，本就不该和在商品列表页一样。

第二个 demo 是个演唱会购票网站，Tara 说用 Gemini 3.1 跑得更顺。她说要买 Summer Vibes Festival 的两张 VIP 票，整个过程被拆成三次工具调用：先 searchConcerts 按名字找到演出、拿到它的 ID，再 openConcertPage 用这个 ID 打开页面，最后 purchaseTicket 带上数量 2 和区域名下单，花了 £356。每一步界面都同步更新，让用户看得见 agent 在干什么。她特意留了个尾巴：真到付款那一步，最好还是让用户自己手动点，毕竟那是花真钱。

这套东西现在能用吗

能试，但别当生产工具。Tara 反复强调，WebMCP 还在 early preview，非常实验性，会变，过去几周就一直在改，她现场展示的代码下周可能就不一样了。他们正是想让人早点上手、早点反馈。

想试的话，路径是这样：WebMCP 从 Chrome 146 开始支持，建议直接用 Chrome Canary，免得动你日常浏览器的实验性 flag；然后在 URL 里启用 WebMCP 的测试 flag；再从 Chrome 网上应用店装那个 Model Context Tool Inspector 扩展，方便调试和观察自己的工具。官方放了两个资源：一篇介绍 early preview 计划的博客（注册后能拿到初始文档和最佳实践），还有一个 GitHub 仓库（装着 inspector、六七个 demo、迷宫的源码，以及一个能测自己网站的 eval CLI）。

我的判断

把 WebMCP 放回我对 agent 生态的整体看法里，它补上了一块此前空着的拼图。我之前记的 MCP 全是服务端故事——连数据库、连 GitHub、连 Slack。WebMCP 是同一套「结构化工具」思路往客户端、往浏览器里长的那一支。一句话概括 Tara 想干的事：把每个网站变成一个给 agent 用的高性能 API，同时不牺牲给人用的体验。

值得记住的有两点。一是那个反直觉的顺序——先把无障碍和性能做好，再谈 WebMCP，前者现在就有回报，后者还在变。二是那个 agent-invoked 属性，看着不起眼，但「网站能分清这张表单是人填的还是 agent 填的」这件事，往后在风控、反爬、计费上都会很有用，我会留意它怎么演进。

至于现在要不要投入，我的答案是：花一两个小时拿 Canary 跑一遍迷宫 demo，把「工具菜单」这个心智模型建立起来，足够了。等它稳下来，再回头看自己手上哪个复杂流程值得第一个改造。