WebMCP实战：让网站为AI智能体做好准备

AI智能体正在改变用户与网页的交互方式。越来越多的用户不再亲自点击、填表、翻页，而是把这些任务交给AI代理来完成。这就带来一个关键问题：你的网站，准备好被AI智能体使用了吗？在Google I/O Connect的一场实操工作坊中，两位讲者Kasper与Andrei系统讲解了「智能体网络（Agentic Web）」的概念，以及一项名为WebMCP的新提案标准。本文梳理其核心思路与可落地的实践步骤。

什么是智能体网络

在计算机科学里，智能体（Agent）指的是一个自主实体：它观察环境、收集信息、处理信息，并采取行动以达成特定目标，然后循环往复。近年来真正的变化在于，我们给智能体接入了大语言模型（LLM）这一推理引擎，从而解锁了全新能力。

讲者Andrei强调，智能体网络并不是一个独立于现有互联网之外的新网络，而是我们熟悉的Web的一次自然演进。Web最初是为人类创造、分享、消费内容以及在线购物而生的，这些场景不会改变——变化的是用户越来越多地借助AI智能体来完成这些任务。

智能体本身有多种形态：可以是直接集成到网站里的站内智能体（on-site agents），成为网站体验的一部分；可以是浏览器智能体（browser agents），既可能是浏览器原生的（如Chrome里的Gemini），也可能通过浏览器扩展提供；甚至还有浏览器之外的智能体，比如通过CDP等协议与浏览器通信的CLI应用。

AI智能体是如何「看」网页的

作为开发者，要让用户在借助AI智能体使用网站时获得成功，就必须先理解智能体是如何感知一个页面的。讲者拆解出三种主要方式。

第一种是直接看页面。智能体对渲染后的页面截图，再用视觉模型去解读，这与人类的观察方式非常接近。第二种是读取渲染后的DOM，分析文本结构。元素的嵌套关系——比如一个按钮嵌在div里——会告诉模型文本的层级；而按钮标签里的文字则直接说明了这个按钮的功能。DOM树从根本上强化了页面元素之间的关系。

第三种是无障碍树（accessibility tree）。这是浏览器原生的API，它把DOM提炼为最重要的信息：交互元素的角色（roles）、名称（names）和状态（state），为智能体提供页面的语义摘要。有意思的是，这也正是屏幕阅读器所使用的技术。

结论很朴素但重要：把网站做得对人类友好，往往也就让它对AI智能体友好。高质量的视觉呈现、语义化的HTML、清晰的层级结构以及良好的无障碍实现，都会让智能体更好地使用你的网站。

无障碍树（Accessibility Tree）由浏览器根据DOM和ARIA属性自动构建，以树状结构暴露给辅助技术。每个节点包含三个关键属性：**角色（role）**表示元素的语义类型（如button、heading、checkbox）；**名称（name）**是该元素的可读标签，通常来自aria-label、alt文字或元素内容；**状态（state）**描述元素当前是否可用、是否被选中等动态属性。相比完整的DOM树，无障碍树去除了纯装饰性节点，只保留对交互和内容理解有意义的元素，上下文体积更小、语义更集中，这正是AI智能体优先利用它的原因。开发者可通过Chrome DevTools的Elements面板中的Accessibility子面板实时查看任意页面的无障碍树结构。

复杂任务带来的挑战

仅靠「看」和「读」并不够。讲者以酒店预订为例说明问题：人类访问一个陌生的酒店网站时，能凭经验快速找到搜索栏、日期选择器和按钮，并把在其他网站积累的操作经验迁移过来。但对智能体而言，随着用户旅程变得复杂——搜索、筛选、选择偏好、办理晚退房等——它需要综合截图、DOM、无障碍树等多路信号来理解当下状态。

上下文越膨胀，所需的算力就越多，响应就越慢，同时模型误读某个信号、走错方向的概率也随之上升。核心矛盾由此浮现：如何让网站与智能体之间的交互既更快又更可靠？

WebMCP：向智能体暴露结构化工具

答案是WebMCP。这是一项拟议中的Web标准，目标是在现有网站上向AI智能体暴露结构化的工具（tools）。

它的意义在于：当用户想在你的披萨网站上把某款披萨加入购物车时，智能体除了分析视觉、读取DOM和无障碍树之外，还可以直接调用网站提供的工具。如果存在一个能够支撑用户意图的工具，整个流程就大大简化了——工具就在那里，无需智能体费力推断。

book, table, EPTBistro tools

讲者用一个名为EPTBistro的餐厅预订Demo做了演示：左侧的调试智能体会列出网站提供的工具（如book、table）及其名称与描述。当输入「我想和Kasper庆祝工作坊圆满成功，晚上7点以Andrey的名义订个桌」时，智能体便调用工具自动填好了姓名、日期、时间、人数乃至特殊备注。另一个迷宫游戏Demo则更进一步：给出「一直移动直到抵达出口，捡起沿途物品并用它们打通道路」这样的高层指令后，智能体会自主组合move、look、pick up、use等工具去解题——这展示了用户可能以开发者未曾预想的方式创造性地使用工具。

WebMCP（Web Model Context Protocol）在命名上与Anthropic提出的MCP（Model Context Protocol）有所关联——MCP是一套让LLM应用连接外部数据源和工具的通用协议，已被众多AI框架采纳。WebMCP可视为MCP在浏览器环境中的Web原生落地方案：它不要求搭建独立的MCP服务器或后端，而是直接让网页通过浏览器API向运行在同一上下文中的AI智能体暴露工具，从而降低实施门槛。目前该提案由Google主导，处于Origin Trial阶段，意味着开发者可申请在真实用户环境中测试，但规范本身仍可能随社区反馈发生变化，尚未成为W3C正式标准。

两种定义工具的方式

WebMCP提供了命令式（imperative）和声明式（declarative）两套API。

命令式 API

命令式API使用标准JavaScript。通过调用document.modelContext.registerTool来注册工具，一个工具需要包含：名称（name）、描述（description）、输入模式（input schema）和执行块（execute block）。

输入模式采用JSON Schema格式，定义模型调用工具时传入的参数；
执行块是工具被真正调用时执行的逻辑，它可以是网站已有的任意JavaScript函数，也可以是新写的函数。

执行块可以是网站已有的任意函数

一个关键细节是：执行块的返回值会被送回给智能体（进而可能回传给模型）。这意味着当参数出错，或者你想报告成功状态、提示下一步操作时，都可以通过返回值传达——这条消息不是给用户的，而是给智能体本身的。若要注销工具，可以在注册时传入一个AbortController，需要时调用abort即可。对Angular开发者来说，甚至可以把工具的生命周期与组件的onDestroy钩子绑定。

声明式 API

如果你已经有一个HTML表单，声明式API只需添加两个必需属性：toolname和tooldescription。加上它们之后，浏览器就会把该表单识别为一个WebMCP工具。可选的toolparamdescription则为智能体提供某个输入项的使用上下文。

为表单添加声明式属性

讲者特别提醒：工具的命名、描述以及参数描述不仅仅是文档，更是智能体判断何时调用工具的重要上下文，可以把它理解为一种专门的提示工程（prompt engineering）。声明式API默认要求用户手动点击提交按钮，智能体只负责填充；若希望填完自动提交，可使用autosubmit属性。此外，表单的submit事件新增了agentInvoked成员，当提交由智能体触发时其值为true，开发者可据此做校验并通过respondWith返回详细反馈，让智能体从错误中学习并重试。

调试与审计：DevTools 与 Lighthouse

WebMCP工具本质上要么基于JavaScript，要么基于HTML表单，因此可以用你熟悉的一切JS调试手段来处理它们。在Chrome DevTools中，可以查看有哪些工具被调用、传入了什么参数、返回了什么结果；还能选中某个工具直接跳转到它在代码中的注册位置，并设置断点排查问题。

用DevTools调试工具

关于评估（evaluation），讲者给出的建议是：能确定性测试的工具尽量做确定性测试，再用LLM去评估与智能体的触点——例如，给定工具列表，智能体能否选对工具？能否选对参数？能否把一个工具的结果作为另一个工具的输入？

从Chrome Milestone 150起，Lighthouse^广告新增了「智能体浏览（agentic browsing）」审计类别。它会检查若干对智能体至关重要的指标：无障碍性、内容布局偏移（content shifts）、以及WebMCP工具的模式（schema）是否正确等。讲者现场对Google高级搜索页面运行审计后，得到了「无障碍树结构良好、WebMCP schema有效」但「仍需修复布局偏移、部分表单缺少注解」的反馈。需要注意的是，该审计目前仍是实验性的。

内容布局偏移（Content Layout Shift，CLS）是Core Web Vitals的核心指标之一，衡量页面加载过程中视觉元素发生意外位移的程度。对人类用户而言，高CLS意味着点错按钮的体验问题；对AI智能体而言，危害更为直接——智能体在截图或读取无障碍树时确定了某个可交互元素的坐标，若布局在操作前发生偏移，智能体点击的位置可能已是另一个元素，导致任务失败或产生错误操作。因此Lighthouse在智能体浏览审计中将CLS列为重要检测项，是有充分理由的。优化CLS的常见手段包括为图片和广告位预留固定尺寸、避免在页面顶部动态插入内容等。

让网站为智能体做好准备的实践步骤

工作坊最后总结出清晰的行动清单：

打好基础：智能体的可用性始于我们早已熟知的原则——把网站做好、做得可访问。高质量视觉、语义化HTML、良好的无障碍实现是前提。
尝试WebMCP：同时试用命令式与声明式两套API，为你的核心功能暴露结构化工具。
用Lighthouse审计：借助新的智能体浏览审计检查网站的智能体就绪程度。
加入Origin Trial：WebMCP仍是拟议标准，现在正是提供反馈、参与塑造API的最佳时机。

对开发者而言，智能体网络不是遥远的未来，而是需要现在就动手准备的现实。把网站做好、暴露清晰的工具、持续审计与反馈——这套组合拳既服务了当下的人类用户，也为即将大量涌入的AI智能体铺好了路。