WebMCP：让网站直接与AI代理对话

元素中猜哪个是日期选择器，推测绿色按钮可能代表“确认”，点击后等待，再重新阅读整个屏幕看看是否发生了变化。下周网站挪动了按钮，代理就会失败；重命名了CSS类，也会失败；页面上多了一个Cookie横幅，它就可能点击了错误的东西。

这就是当前几乎所有“代理使用网站”的方式——屏幕抓取加不断猜测。本质上就像隔着电话描述屏幕截图来操作一台电脑，脆弱且不可靠。

WebMCP提出了一个更合理的方案。网站不再让代理靠“凝视”页面来猜测功能，而是直接声明自己可以做什么，给出一组干净、结构化的工具，代理可以直接调用。比如网站可以声明一个book_table工具，它接受日期、时间和人数作为参数，代理只需调用它即可，无需读取像素，无需猜测。

WebMCP的核心转变在于从“抓取”到“声明”。如果你了解过MCP（模型上下文协议），这个思路会非常熟悉。MCP让AI可以调用服务器上的工具，而WebMCP将同样的理念带入浏览器：网页本身成为一个提供工具的地方，运行在你已经打开的标签页中，使用你已经登录的会话。

具体来说，WebMCP是由谷歌Chrome和微软Edge在W3C Web机器学习社区组联合提出的Web标准提案。它给网页提供一个小型JavaScript API，用于注册AI代理可以发现和调用的工具。谷歌在Chrome文档中将其描述为“构建并暴露面向AI代理的结构化工具”，让网站通过标注自身功能，使代理“准确了解如何交互”。需要注意的是，它目前只是社区组草案，还不是完整的W3C标准，也尚未进入标准轨道。正因如此，现在正是了解它、参与塑造它的最佳时机。

WebMCP能够成立得益于三个关键设计。第一是发现机制：页面可以用标准方式声明“我提供这些工具”，例如checkout或filter_results，代理可以列出这些工具。第二是模式定义：每个工具都使用JSON Schema声明输入和输出，代理因此清楚应该传递什么参数，大大减少了幻觉和误读的空间。第三是状态理解：页面和代理共享对当前页面状态的认知，代理知道现在可以实际操作什么。

那么一次调用实际如何发生？整个循环并不神秘：页面注册工具，代理列出可用工具，选择一个，用结构化参数调用，然后获得结果。这比让代理去解析不可预测的DOM结构要可靠得多。对开发者而言，最大的吸引力在于门槛极低——在Chrome的试验版本中，为网站增加第一个WebMCP工具大约只需要十分钟。

WebMCP的价值在于它为网页与AI代理之间建立了一条语义清晰的高速通道。它不要求网站改变现有的业务逻辑，只需要在现有页面之上额外暴露一层“工具描述”，就能让代理像使用API一样使用网站。这既降低了开发者的维护成本，也提升了代理执行任务的稳定性和准确性。

当然，WebMCP尚处于早期阶段，其最终形态还需经过社区讨论和标准演进。但方向已经非常明确：未来的AI代理不再需要做“网页读心术”，网站会主动向代理伸出友好的手，告诉它们自己能做到什么，以及如何调用。这个从“猜测”到“声明”的转变，或许正是AI走向实用化的关键一步。