WebMCP 深度解读：AI智能体如何重塑Web交互

当用户不再满足于让AI助手“写一封邮件”，而是希望它“把邮件发出去”时，Web的底层交互逻辑正面临一次根本性重构。在最近一场Chrome团队的技术访谈中，工程师Andre详细拆解了WebMCP（Web Model Context Protocol）的设计思路与落地进展。这不是又一个实验室概念，而是一个已经进入Chrome Origin Trial、并吸引了OpenAI、Cloudflare、Brave等玩家入场的基础设施提案。

从“人读网页”到“智能体用网页”

Andre将当前的变化定义为“Agentic Web”的到来。过去用户使用AI，多是问答、摘要、草稿生成；如今用户预期升级为任务执行——比如让智能体直接完成机票搜索和筛选。这意味着开发者需要确保自己的产品能被智能体“使用”，而不仅仅是被人“浏览”。

这个转变的规模，Andre认为不亚于甚至超过当年移动Web的普及。但核心逻辑并非让智能体取代用户，而是让智能体成为用户手中的工具，去调用你的产品。开发者要做的是：无论用户使用何种界面（人类的浏览器还是智能体的调用），产品都能被顺畅使用。

智能体友好的三个支柱

为了让产品对智能体可用，Chrome团队将其拆解为发现、理解、可用性三个层面。

发现层面，智能体需要知道你的产品存在、能做什么。robots.txt和sitemap依然有效，但新增了llms.txt这类文件，将站点核心内容集中在一个标准位置，减少智能体遍历全站的开销。

理解层面，关键在HTML的结构质量。许多智能体当前无法执行JavaScript，纯客户端渲染的空壳页面会让它们陷入困境——这与早期搜索引擎不执行JS的历史如出一辙。内容协商（Content Negotiation）也是手段之一：当识别到请求来自智能体时，返回更省token的Markdown版本，帮助智能体更高效地理解内容。

可用性层面，目前多数智能体依靠“actuation”模式工作：截图、视觉模型识别、模拟点击。这要求页面布局清晰、按钮看起来像按钮、表单与按钮的DOM关系符合语义。说个细节，Andre强调这些优化对普通用户同样有益——良好的可访问性标记、结构化的HTML，本就是Web开发的最佳实践。

llms.txt 是一种由社区提出、面向大语言模型的站点信息文件规范。它在站点根目录以 Markdown 格式提供，通常包含站点简介、核心页面链接、文档目录等结构化索引，帮助模型在不抓取全站的前提下快速定位关键内容。与 robots.txt（规定爬虫可访问范围）和 sitemap.xml（列出所有可索引 URL）不同，llms.txt 的诉求不是“允许或不允许抓取”，而是“用尽可能少的 token 告诉模型这里有什么、该读哪里”。对内容型站点和文档站而言，它能显著降低智能体遍历整站的开销。目前该规范尚无浏览器厂商的正式标准化，属于事实约定，站点可按需采用。

内容协商（Content Negotiation） 是 HTTP 的既有机制，客户端通过请求头（如 Accept、User-Agent）声明自己希望的表示形式，服务端据此返回不同版本。在 Agentic Web 语境下，其典型用法是：当检测到请求来自智能体时，返回精简的 Markdown 或纯文本版本，而非完整的 HTML 页面。这样既减少了传输体积，也避免了智能体为解析导航、广告、脚本等无关 DOM 而消耗上下文。实施时需注意基于请求头做内容差异返回时，要正确设置 Vary 响应头，以免中间缓存把智能体版本错误地返回给人类用户。

WebMCP 解决什么问题：从“猜”到“调”

截图加DOM加可访问性树，对智能体而言是巨大的上下文负担。上下文越大，响应越慢，出错概率也越高——点错按钮、误解意图。WebMCP的核心思路是：与其让智能体“猜”页面怎么用，不如让网站主动“告诉”它。

网站开发者通过WebMCP API注册工具（tools），智能体直接调用这些工具，跳过截图和DOM解析。这带来三个直接收益：更少的token消耗、更快的响应、更高的可靠性。同时，开发者通过工具描述和参数设计，实际上是在引导智能体正确地使用产品。

WebMCP提供两种注册方式：声明式（在现有表单上添加特殊属性，使其变成工具）和命令式（JavaScript API）。访谈中的机票搜索演示使用了命令式API——搜索页注册了searchFlights工具，筛选页动态注册setFilters工具。有趣的是，工具可以动态注册和注销，智能体甚至能在一次对话中自动发现新页面注册的工具并连续调用。

actuation 模式指的是智能体不依赖网站提供的结构化接口，而是像人一样“操作”页面：截取屏幕、用视觉模型识别按钮与输入框位置、再模拟鼠标点击或键盘输入。这种方式的优点是通用——任何网页都能尝试操作；缺点是脆弱且昂贵：每一步都要传入图像和 DOM 快照，上下文迅速膨胀，页面稍有改版或存在遮挡、懒加载，识别就会失效。WebMCP 的思路是把这种“视觉猜测”换成“显式调用”，由网站声明工具名称、参数与语义，智能体只需按 schema 构造调用即可完成同样操作，从而把不确定性从识别环节转移到受控的接口约定上。这也是为什么文章强调其收益集中在 token 消耗、响应速度和可靠性三方面。

权限设计：只读提示与破坏性评估

工具调用是否需要用户确认，是智能体UX的关键决策。WebMCP API已提供部分提示机制，比如read-only hint，告诉智能体该工具不改变页面状态、仅返回信息。但Andre指出，只读不等于安全——读取敏感用户信息的工具，风险可能高于某些写入操作。

对于写入类工具，判断标准不应是“是否写入”，而是“破坏性多大、可逆性如何”。搜索航班的工具影响有限，但涉及支付的工具就必须谨慎授权。目前部分提示能力已落地，部分仍在演进中，智能体也会结合工具描述自行判断是否请求许可。

Origin Trial（源试用） 是 Chrome 推出的一项机制，允许开发者在正式标准化之前，于真实用户环境中测试尚未默认启用的 Web 平台新特性。开发者需要为自己的源（origin）申请一个 token，并在页面中以 meta 标签或响应头的方式声明，随后该源下的访问者即可启用该特性，无需用户手动改设置。它的意义在于：标准草案可以借助真实流量验证 API 设计与兼容性，同时把影响范围限制在自愿加入的站点内。对 WebMCP 而言，加入 Origin Trial 意味着站点注册的工具可以被启用了该协议的智能体发现和调用，但接口仍可能随反馈调整，生产使用需评估稳定性风险。

生态进展：从实验到生产

据Andre介绍，WebMCP标准由微软、谷歌及社区成员共同发起，目前有来自不同企业的贡献者参与。Chrome已开启Origin Trial，网站开发者可主动加入，加入后所有访问用户即可使用，用户侧无需任何操作。开发环境也可通过Chrome flag直接开启。

智能体侧的支持正在铺开。Gemini in Chrome已在实验WebMCP；Cloudflare的Browser Run产品已支持并将WebMCP投入生产环境；Brave在其智能体Leo中进行了实验；OpenAI近期也将WebMCP支持落入了其智能体。Andre坦言生态仍处早期，但网站端和智能体端的兴趣都在增长，这对双边生态的启动至关重要。

Chrome扩展目前通过content script调用页面级API来读取和执行工具，尚无扩展专用API。扩展同样可以注册工具供其他智能体调用。

尚未回答的问题：进度反馈与技能组合

访谈末尾，Andre提到了WebMCP当前的能力边界。一个典型痛点是长时任务的进度反馈：如果工具执行需要几分钟（如下载文件），页面目前无法向智能体回报进度状态。这是社区反馈中频繁出现的需求。

另一个更具想象空间的方向是“skills”——能否让网站给智能体一份“食谱”，指导它如何组合多个工具完成更复杂的任务。Andre认为这仍是开放问题，WebMCP本身也只是刚刚开始。

至于Web的未来，Andre的判断是：浏览不会消失，因为浏览本身有乐趣和探索价值；智能体的强项在于消除流程摩擦和自动化工作流。两者并非替代关系，而是分工。

对开发者而言，眼下最务实的动作或许是：检查HTML语义结构、完善可访问性标记、评估是否需要llms.txt，然后考虑加入WebMCP Origin Trial，把自己的核心操作注册成工具——在智能体成为重要流量入口之前，先让产品“被看见、被理解、被调用”。