从人类访客到 AI agents：Lighthouse 新实验项给网站提出新问题

2026 年 5 月 21 日，Jonathan Kemper 在 The Decoder 报道称，Google 正在 Lighthouse 中测试一个名为 “Agentic Browsing” 的实验性类别，用来评估网站处理 AI agents 的能力。Google 官方文档也显示，Agentic Browsing category 与 WebMCP support 目前都属于 experimental，并且基于 proposed standards。

这组审计项覆盖 WebMCP integration、accessibility tree、Cumulative Layout Shift（CLS）与 llms.txt presence。它没有沿用 Lighthouse 常见的 0-100 加权总分，而是显示页面通过检查项的比例。The Decoder 提到的 Airbnb 示例中，该页面只通过了 1/3 Agentic Browsing checks。

Lighthouse 开始测试“代理浏览”

这条消息的直接来源，是 Jonathan Kemper 在 The Decoder 于 May 21, 2026 发布的报道。报道说，Google 正在 Lighthouse 分析工具中测试新的实验性 “Agentic Browsing” 类别，用来检查网站处理 AI agents 的能力。

这件事值得注意，不是因为它立刻改变了网站评分规则，而是因为 Lighthouse 开始把“机器代理能否理解和操作页面”放进单独的审计视野。过去，Lighthouse 的核心语境主要围绕人类用户：页面是否足够快，布局是否稳定，可访问性树是否清楚，搜索引擎能否抓取主要内容。Agentic Browsing 把这些既有问题重新组织了一次，指向的对象从浏览器前的人，延伸到可能代替人执行任务的 AI agents。

Google 官方文档提供了相互印证的信息：Agentic Browsing category 与 WebMCP support 都被标注为 experimental，并建立在 proposed standards 之上。换句话说，这不是已经稳定下来的网页标准，也不能直接写成搜索排名规则。更准确的说法是，Google 正在 Lighthouse 里试探一组面向代理浏览的检查方式，观察网站是否能给机器代理提供更清晰、更可操作的页面信号。

它不打 100 分，而是显示通过比例

Google 对 Agentic Browsing 的评分方式也不同于 Lighthouse 常见的总分模型。Chrome for Developers 文档称，这一类别不会给出从 0-100 的加权平均分，而是显示页面通过了多少检查项。

“not have a weighted average score from 0 to 100”

这意味着 Agentic Browsing 目前更像一张实验清单，而不是一个可直接比较网站优劣的综合分。传统 Lighthouse 分数会把多个审计项折算进一个总分，方便开发者快速判断性能、可访问性或 SEO 的大致状态；Agentic Browsing 则把重点放在“哪些项通过、哪些项失败、哪些项不适用”上。这个设计本身也说明，相关能力还处在摸索阶段，很多网站未必已经具备 WebMCP 相关配置，Lighthouse 也未必会把每一项都纳入最终得分。

The Decoder 报道中的 Airbnb 示例显示，该页面在 Agentic Browsing 新类别下只通过 1/3 checks。报道称，accessibility tree 和 llms.txt 失败，WebMCP audits 则是 not applicable。这个例子更像一个信号：即便是成熟网站，在代理浏览语境下也可能暴露出新的缺口。不过，1/3 不能被简单理解为网站“不合格”，因为这个类别本身还没有进入稳定标准，也没有形成通用行业基线。

WebMCP、llms.txt 与 accessibility tree

从已列出的审计范围看，Agentic Browsing 覆盖 WebMCP integration、accessibility tree、Cumulative Layout Shift 和 llms.txt presence。Google 文档进一步说明，Lighthouse 使用 Chrome DevTools Protocol（CDP）的 WebMCP domain 监控 tool registration events。

WebMCP tools 可以通过 Declarative API 或 Imperative API 注册。Declarative API 要把 toolname 和 tooldescription attributes 直接加到 <form> elements；Imperative API 则使用 navigator.modelContext.registerTool 通过 JavaScript 注册 tools。这里的重点不是让每个网站马上接入一套新接口，而是说明 Google 正在观察网页是否能以结构化方式暴露可调用工具，让 AI agents 不只是“读页面”，还可能理解页面上有哪些动作可以执行。

“machine-readable summary of a website’s content”

这一定义对应的是 llms.txt。根据 Google 文档，llms.txt audit 在获取 llms.txt 时遇到 server error 会 flag pages；如果服务器返回 404，audit 会被标记为 Not Applicable（N/A），而不是直接失败。这个细节很重要，因为它把“没有提供 llms.txt”和“服务器出错”区分开来：前者在当前实验审计里可能只是 N/A，后者才会被视为需要提示的问题。

accessibility tree 和 CLS 则更接近网站团队已经熟悉的基础项。清晰的 accessibility tree 能帮助辅助技术理解页面，也可能帮助代理系统更稳定地解析控件、表单和内容层级；较低的 Cumulative Layout Shift 能减少页面加载中元素位置变化带来的误触和判断错误。放在 Agentic Browsing 里看，这些并不是全新的优化方向，而是被赋予了新的使用对象。

仍是实验，不是稳定标准

最需要谨慎处理的，是这件事与 SEO 或网站合规要求之间的关系。Google 官方文档明确称 Agentic Browsing 与 WebMCP support 仍属 experimental，并基于 proposed standards。因此，当前不能把 Lighthouse 的这个实验类别写成稳定标准，也不能把 llms.txt 或 WebMCP 写成 Google 已经强制要求的网站配置。

这种边界会影响开发优先级。对大多数网站来说，Agentic Browsing 还不应该挤掉性能、可访问性、安全和内容质量这些基础工作。它更适合作为一个观察窗口：如果未来代理浏览真的成为常见入口，网站需要怎样描述自身内容、暴露可执行动作、降低布局不确定性，并让机器代理在不破坏用户体验的前提下完成任务。

Google 建议开发者使用 semantic HTML、proper ARIA labels，并尽量减少 layout shifts。这些建议与 Agentic Browsing 审计项中的 accessibility tree 和 CLS 相关，也与既有的可访问性和页面稳定性实践重叠。对网站团队来说，先把这些基础项做好，比为了实验项仓促堆配置更稳妥。

开发者可以先关注已有基础项

短期内，更稳妥的理解是：Agentic Browsing 目前提供的是一组实验性检查项，而不是成熟的行业标准。网站团队可以先检查已经明确列出的项目：页面是否有清晰的 accessibility tree，是否减少 Cumulative Layout Shift，服务器对 llms.txt 的响应是否符合预期，以及是否需要关注 WebMCP proposed standards 的后续进展。

如果网站已经有较成熟的可访问性、性能和结构化内容治理流程，Agentic Browsing 可以被纳入监测范围，但不必被过度解读。它现在给出的信息更像早期方向提示：哪些页面元素对机器代理不够清楚，哪些服务响应会造成歧义，哪些交互可能需要更明确的工具描述。真正影响上线决策的，仍应是稳定文档、浏览器实现、平台采纳程度以及团队自身的用户场景。

Lighthouse 的 Agentic Browsing 目前仍是实验，但它已经把 WebMCP、accessibility tree、CLS 和 llms.txt 放进同一组面向 AI agents 的审计视野中。接下来值得观察的，是这些 proposed standards 是否会进入更稳定的阶段，以及 Lighthouse 是否继续扩大或调整这一实验类别。