想象一下，一个AI代理试图在一家餐厅的网站上为你预订一个桌子。今天，它就像一个非常耐心、稍微困惑的实习生。它加载页面，读取原始HTML，试图弄清楚哪个四十个<div>元素是日期选择器，猜测绿色按钮可能意味着“确认”，点击它，等待，然后重新阅读整个屏幕看看有没有发生什么。如果下周移动那个按钮，代理就会崩溃。更改CSS类名也会崩溃。在上面添加一个cookie横幅，它可能完全点击错误的东西。这正是目前几乎所有“使用网站的代理”的工作方式：屏幕抓取和希望。这是通过电话描述屏幕截图来操作计算机的自动化等价物。WebMCP提出了一种更合理的方法。代理不再通过盯着你的网站来猜测它能做什么，而是你的网站声明它能做什么，作为一组清晰、结构化的工具，代理可以直接调用。“这是一个book_table工具。它需要一个日期、一个时间和一个派对人数。调用它。”没有像素读取。没有猜测。最棒的是：它已经在Chrome中运行，处于试用状态，添加你的第一个工具大约需要十分钟。让我给你展示整个过程。核心转变：从抓取到声明整个想法可以用一个比较来概括。同样的任务，两个世界。今天：代理抓取 1 读取整个DOM 2 猜测哪个元素是日期字段 3 模拟输入和点击 4 重新阅读整个页面以检查 5 布局变化时崩溃 WebMCP：网站声明 1 页面注册一个book_table工具 2 代理读取工具的架构 3 代理按结构化参数调用 4 工具运行你的真实JS，返回结果 5 经受住重新设计：工具是合同 左侧列很脆弱，因为代理每次都在逆向工程你的用户界面。右侧列则稳定，因为你给了它一个真实的接口。布局可以在工具的名称和架构保持相同的情况下自由变化。如果你看过我之前关于MCP的文章，AI接触世界的港口，这个内容会让你感到熟悉，而这也是应该的。MCP为AI提供了一种标准方式来调用服务器上的工具。WebMCP将这个想法带到浏览器中：网页本身成为一个提供工具的地方，在你已经打开的标签中运行，与你已经登录的会话一起使用。它实际上是什么 WebMCP是一个建议的网络标准，由Google（Chrome）和Microsoft（Edge）在W3C Web机器学习社区小组中共同开发，给网页提供一个小的JavaScript API，用以注册AI代理可以发现和调用的工具。Google在Chrome文档中简单地描述它：一种“为AI代理构建和公开结构化工具”的方式，其中网站注释其自身功能，以便代理“确切地知道如何与它们互动”。为了准确描述成熟度，它是一个社区小组草案，而不是完成的W3C标准，也尚未在标准轨道上，这就是现在学习和塑造它的时刻。使其顺利进行的三个要素：发现。页面以标准方式说明“我提供这些工具”，如checkout或filter_results，以便代理可以列出它们。架构。每个工具声明其输入和输出为JSON架构，因此代理确切知道要传递什么，错误理解的余地大大减少。状态。对当前页面实际内容的共同理解，以便代理知道可以采取的实际操作。当前状态 WebMCP是现实且可运行的，但仍处于早期阶段。它作为Chrome 149的原始试验可用，并且你可以通过标志chrome://flags/#enable-webmcp-testing在本地启用它。该提案存在于github.com/webmachinelearning/webmcp，Angular已经有实验性支持，而Chrome则发布了演示网站（一个披萨制作器、旅行搜索、餐厅预订）。Google的话说，它“正在积极讨论并可能会更改。”所以这是一个“试一下并塑造它”的时刻，而不是“推出生产”的时刻，这正是现在值得学习的原因。调用实际上是如何流动的 这是整个循环，页面到代理再返回。没有什么特别的事情发生：页面注册工具，代理列出它们，选择一个，以结构化参数调用它，而你自己的JavaScript在页面中执行工作。页面 注册工具 你的JS声明book_table、search等。→代理 发现 列出页面的工具及其架构→代理 以参数调用 结构化JSON与架构匹配→页面 execute()运行 你的真实JS，在已登录页面中→代理 获取结果 结构化答案，明显地在标签中 工具的execute函数在你实际页面中运行，使用你现有的JavaScript、状态和用户自己的登录会话。它可见地发生在标签中，而不是在某个看不见的无头浏览器中，因此用户可以观察并信任它。那个“在你已经登录的页面中运行”的细节是一个大问题。代理不是一个在某个地方以被盗凭证登录的独立机器人。它在你打开的、经过身份验证的标签中调用一个函数，使用你已经...