很多人对 AI 智能体的想象是：给它一个目标，它自己打开网页、点按钮、填表单。但真做起来，智能体往往要靠截图识别和模拟点击，既慢又脆。WebMCP 提供了另一条路：让网站主动把自己能做的事告诉智能体。

简单说，WebMCP 是一项实验性的浏览器 API。网站可以在页面里显式声明一组工具，比如查询订单、创建任务、修改设置，AI 智能体随后就能直接调用这些工具。它和经典 MCP 的关键区别在于运行位置。经典 MCP 通常在浏览器之外运行，而 WebMCP 依赖浏览器上下文：页面得开着，需要登录的站点得先登录，工具才可用。因此它更适合通过带有智能体能力的浏览器或 Chrome 扩展来使用。

这个定位决定了它最自然的使用场景。它不太像给多智能体系统做大规模网页抓取的底层设施，更像是帮助普通用户操作他们已经熟悉的产品。用户不需要重新学一套界面，网站也不需要为了 AI 把产品推倒重来。网站仍然可以是一个正常网站，按钮照点，表单照填，WebMCP 只是额外增加了一条结构化的交互通道。

一个演示项目把这一点表现得比较清楚。它模拟了一家创业公司的经营面板：现金、月收入、员工数、生产事故、员工幸福度、热度值，还有董事会决策，比如采用 AI、转向智能体、用 Rust 重写、裁员、招人。活动日志会记录每一步。这个站点本身就是普通网页，手动操作完全可用；接入 WebMCP 后，智能体也能调用同样的能力。

接下来的问题很实际：谁来调用这些工具？可以用现成的云端助手或公开扩展，但云方案依赖网络，界面在演示场景下也未必好用。于是有人做了一个本地 Chrome 扩展，叫 WebMCP Local Agent。它接收用户意图，检查当前页面暴露了哪些 WebMCP 工具，然后决定调用哪些。

这个扩展本质上就是一个循环：模型拿到用户意图和可用工具，决定调用什么，拿到结果后继续判断下一步。默认最多循环十次，可以在配置里改。它支持三种后端：Google 的 Prompt API，由 Chromium 管理 Gemini Nano，模型下载后推理在本地完成，不需要 API 密钥；Ollama，同样本地运行，模型可自选，但最好选工具调用表现好的；以及一个云端 Gemini Flash 模型，需要 API 密钥。本地推理带来一个实际好处：提示词和模型输出可以留在用户机器上，不必每次交互都发往云端。

本地模型确实能跑，但别期待完美。Llama 3.1 偶尔会不按 JSON 返回，而是给出 Markdown 或额外的解释性文字。这是当前大模型的常见毛病，不是这个扩展独有的问题。

更值得认真对待的是安全问题。WebMCP 改变了交互模型：用户不再逐步点击每个操作，而是表达一个意图，模型自己规划并调用工具。有些工具无伤大雅，比如查看状态、读取数据。但也有些操作后果严重，比如解雇员工、修改财务设置、删除数据。如果智能体在未经确认的情况下执行了这些操作，结果可能无法收拾。

WebMCP 的推进者已经加入了工具注解机制，用来标记某个工具是否具有重大后果。扩展也支持这一机制。当智能体试图调用被标记为有后果的工具时，界面会先弹出确认提示，用户可以批准或拒绝。这个设计并不复杂，但很关键：把最终决定权留在人手里。

从更广的视角看，WebMCP 不需要一场架构革命。它没有要求网站变成另一种东西，也没有要求用户放弃原有界面。它只是在已有产品上加了一层结构化接口，让智能体有路可走。有人形容这不是汽车替代马车的革命，而只是更快的马。如果更快的马正好解决眼前的问题，那也够用了。

文章摘自：https://www.cnblogs.com/lastidea/p/23102957