WebMCP详解：让网站发布工具，而非让智能体点击用户界面。

想象一个小型侧项目，其中人工智能代理需要独立操作一个网络应用。第一个版本的工作方式与大多数浏览器代理相同：代理获取应用访问权限，然后根据页面显示的内容来处理任务。对于一个简单的待办事项应用，请求可能是“将‘买鸡蛋’添加到我的列表中”。为了执行此操作，代理必须查看页面，找到输入框，确定哪个按钮用于提交表单，点击该按钮，然后再检查结果。

这种方法虽然可行，但显得过于繁琐。应用本身已经明确知道应该执行什么操作。那个按钮背后有一个函数，该函数背后又有 API，而整个操作只需一次简单的调用即可完成：

add_todo(title)

那么，为什么代理还要盯着界面去猜测那些应用程序早已能描述清楚的操作方法呢？这就是 WebMCP 开始发挥作用的时刻。其工作流程大致如下：

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

对于人类访问者而言，界面依然存在。智能体只需执行操作，无需解码该界面。这改变了整个问题的框架。问题或许不在于如何让人工智能更擅长使用网站，而在于如何让网站更善于向人工智能说明自身的功能。

当前智能体使用网络的两种方式及其各自的局限性

目前，需要在网站上执行操作的智能体主要有两种常见途径。

第一种是浏览器自动化。智能体会截取屏幕截图，判断哪些元素可点击，移动光标，填写表单，点击按钮，检查操作结果，然后重复这一流程。这就像观看一个人操作浏览器，也存在同样的缺陷：速度慢、消耗大量资源，且容易出错。哪怕是微小的布局变化、隐藏的菜单、仅支持悬停交互的功能，或是多出一步的操作流程，都可能让智能体陷入混乱。

第二种方案是为您的应用定制的MCP服务器。对于工具而言，这种方式能带来更好的使用体验。不过其代价体现在其他方面，因为智能体必须先知晓服务器的存在并与其建立连接。如果每个网站都自行开发定制化的集成方案，这种模式就无法扩展，这也是定制MCP方法的实际局限。

这就出现了一个空白地带：浏览器自动化过于间接，而定制集成又过于繁琐。WebMCP正是旨在填补这一空白。

WebMCP究竟是什么

简单来说，WebMCP允许网站向AI智能体告知“在这一页上你可以执行哪些操作”。这样智能体就不必自行猜测该点击哪个按钮，网站会直接提供操作列表。

例如，一家在线商店就可以发布这样的工具：

search_products()
get_product_details()
add_to_cart()

正在浏览该网站的智能体可以自行找到这些工具，并根据每个工具指定的结构化输入格式来调用它们。无需事先在智能体中注册任何内容，这些工具都是从网站上动态发现的，这一点尤为值得注意。这样一来，网站就不再仅仅是一堆页面，而是开始具备实际功能。

具体示例：待办事项应用

以一个简单的待办事项应用为例。在没有 WebMCP 的情况下，智能体需要先查看页面，找到输入框，输入文字，定位“添加”按钮并点击它，最后重新读取更新后的界面。

借助 WebMCP，该应用可以发布四种工具：

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

该智能体不再需要了解任何视觉布局信息，它只知道应用程序能做什么。一个按照这种方式构建的演示展示了某个待办事项应用，其中提供了四种工具，连接的智能体会读取这些工具的架构并立即调用add_TODO函数。告诉智能体将“我得去买鸡蛋”添加到列表中，就会触发对应的工具调用，新条目随即会出现在应用中。

这种思维模型更加清晰：用户界面是为人类设计的，工具则是为智能体准备的，而两者都在同一个应用程序上运行。

工具定义的格式

前端工程师会对此感兴趣。那个演示中的实现是通过navigator.modelContext来注册工具的。每个工具都包含若干组成部分：

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

其结构始终一致：包括名称、描述、输入架构，以及用于执行任务的执行函数，该函数通常通过调用应用程序已有的后端API来完成工作。最后一点非常重要。WebMCP并不要求你为人工智能重新编写业务逻辑。现有的应用程序依然是执行操作的系统，而代理仅提供了一种结构化的方式来触发这些操作。

认证方面的问题

一旦应用程序不再只是玩具，情况就会变得复杂起来。试想一下这样的工具：

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

未知的代理不应能够随意调用这些功能。同一材料中的第二个演示正是通过OAuth来解决这一问题的。WebMCP工具建立在已通过身份验证的应用程序之上，未登录的用户无法执行受保护的操作。

这一点很重要，因为代理可能来自多种类型的客户端：具备AI功能的浏览器、桌面代理或其他代理应用。与为每种集成都设计独立的登录流程相比，OAuth这样的标准机制能让能力层在所有这些客户端上都更容易得到保护。一旦网站向代理开放了相关能力，身份验证就会从一开始就成为代理体验的一部分，而非事后添加的补丁。

前端设计面临的新问题

多年来，前端架构一直围绕一条链条展开：界面、状态、API、后端。WebMCP则提出了另一个问题：该应用应向代理暴露哪些功能？

这看似微不足道，却可能改变功能的设计方式。“加入购物车”按钮属于人类交互操作，而这个调用则属于应用功能：

add_to_cart(productId, quantity)

这两种界面最终可能会被设计在一起。用户能够获得简洁的界面，智能体则拥有结构化的能力接口，二者最终都会遵循相同的业务逻辑。

这不仅仅是速度的问题

相比提升智能体的速度，这背后还有更深层次的原因。当智能体需要通过截图和点击来操作时，界面本身就构成了契约，而界面的任何变化都可能破坏智能体的正常运行。而使用 WebMCP 后，工具定义便成为了这份契约的一部分。

这为前端开发者带来了新的工作内容：工具名称、描述、输入格式、执行行为以及认证规则。他们的工作不再仅仅是设计界面，还必须考虑如何让软件以合适的方式呈现给智能系统。

仍处于早期阶段

有一点需要特别强调。WebMCP目前仍属于早期预览版本，并非已确定的网页标准。该演示是在开启浏览器标志选项的Chrome Beta版本中运行的，演示者也明确表示该API仍有可能发生变化。现在就基于它来构建生产环境架构还为时过早。不过进行相关实验则是另一回事，因为其背后的理念远超当前的API功能。

几十年来，网站的建设一直基于一个前提：另一端必定是人类操作者。WebMCP则是首批挑战这一前提的尝试之一。未来网页应用可能不得不回答两个问题：人类应如何使用它？人工智能代理又应如何使用它？第一个问题催生了现代前端工程技术，而第二个问题很可能会决定未来的发展方向。