让前端站点也能被 AI Agent 读懂：Chrome 出了个 Agent-Ready Toolkit，Lighthouse 也加了新分类

让前端站点也能被 AI Agent 读懂：Chrome 出了个 Agent-Ready Toolkit，Lighthouse 也加了新分类

导语

2026 年浏览器又往前端加了一层新身份：不再只是给人看的网页，还要给 AI Agent 看。最近 Chrome 150 前后把 agentic browsing 做进了 Lighthouse，还放出了一个叫 Agent-Ready Toolkit 的东西。如果你还在只优化 Core Web Vitals，这篇文章能帮你补上“非人类访问者”这一块。

正文

问题：Agent 来了，你的站点还只给人看

过去十年里，前端的质量标准非常统一：加载快、不抖动、交互跟手。但现在 AI Agent 越来越多，它们会通过浏览器帮用户订会议室、填表单、搜内容。你站点的结构是否好理解，直接影响 Agent 能不能帮你完成任务。更具体地说，如果按钮没有 aria-label，表单没有明确的结构，Agent 很可能读错、点错、甚至放弃任务。

Chrome 团队给这个问题起了个新名字：agentic readiness，也就是“站点是否已经为 Agent 交互做好准备”。这不是 SEO，也不是可访问性 alone，而是对两者做了一个新整合。

方案：三大块能力组合

Google 目前推出的思路分三层：

• Lighthouse Agentic Browsing 分类：从 M150 开始加入，检测 accessibility、stability、WebMCP 三个维度。与传统的 Accessibility 和 Performance 审计相比，它更关注机器是否容易理解你的页面。
• WebMCP 标准：让站点主动声明结构、表单和可用工具。Agent 不必猜页面交互是什么，而是直接读站点提供的结构。简单说，WebMCP 像是在给页面加一份“机器可读说明书”。
• Chrome DevTools for Agents：允许开发者模拟 Agent 视角调试页面，甚至直接把当前页面的状态喂给 Lighthouse 跑审计。

这三层里，Lighthouse 分类是最容易落地的，不用改业务代码也能先跑个体检。

一个能直接跑的例子

假设你有个简单的表单：

<form id="booking">
  <label for="name">姓名</label>
  <input id="name" name="name" />
  <button>提交</button>
</form>

如果直接交给 Agent，它能识别“这是一个表单”，但无法知道这个按钮是不是触发提交。补一句简单的 aria-label，或者把按钮文案改成“提交预约”，就能让它更可靠。更完整的方式是加上 WebMCP 声明，把页面能力显式暴露出去。

落地步骤

• 打开 Chrome M150+，在 Lighthouse 里勾选 Agentic browsing，先看当前站点的得分。
• 优先修复“交互元素没有程序化名称”“CLS 过高导致 Agent 点错位”这两类高概率失败项。
• 对关键流程，补充表单语义、按钮说明，或尝试接入 WebMCP。
• 用 DevTools for Agents 做一轮模拟 Agent 流程，验证是否稳定。

结论

Agent-Ready 本质上是把 AI 当成真正的用户来优化。你之前已经为人类用户做的可访问性、语义化、稳定交互，现在也是给 Agent 做的。差别只在于：人类有上下文、能猜意思；Agent 没有。

如果你已经做完了 Core Web Vitals 优化，下一步就可以让站点先过一遍 Lighthouse 的 Agentic browsing 分类，把它当成今年 Q3 的基建小任务。

收尾

下一次优化不只是“更快”，还要“更可读”。你可以在本周给自己的站点跑一遍 Agentic browsing 审计，看看 Agent 视角下最大的三个问题是什么。