用 Lighthouse 测网站的 AI 智能体就绪度
想让 AI 智能体（Agent）顺利使用你的外贸独立站——先别猜行不行，用 Lighthouse 跑一次"代理就绪度"报告就清楚了。Google 在 Chrome Canary 版 Lighthouse 中新增了 Agentic Browsing 类别，量化检查网站对 AI 代理的友好程度：无障碍树（Accessibility Tree）做导航骨架、WebMCP 标准暴露可执行动作、llms.txt 提供推理级网站说明。它不是又一个 SEO 评分，而是直接回答一个问题——AI 代理能不能在你的网站上完成用户交给它的任务。本文给外贸团队一套检测步骤、分数解读框架和分层优化清单，帮助你把 GEO 投入从"信仰"变成"数据驱动"。
AI 代理就绪度，为什么突然变得"可测量"了
过去两年，我们一直在讨论 AI 智能体会不会用我们的网站、哪些优化能让它用得更顺畅。但讨论归讨论——没有标准、没有量分、没有工具，"代理就绪"这件事一直是一个模糊的概念。
直到 Google 把一个看似微小的功能塞进 Chrome Canary 的 Lighthouse 面板：Agentic Browsing 报告。这不是营销噱头，这是 Google 官方第一次用工程化手段告诉你：你的网站在 AI 智能体眼中有多"可操作"。
这件事的时机很值得玩味。2026 年 4 月，Cloudflare 发布了 Project Think——一个给 AI 智能体提供持久执行能力的运行时基础设施；同月，OpenAI 升级了 Agents SDK，大幅强化多步骤任务调用和状态管理。用 Slobodan Manic 在 Search Engine Journal 上的话说："模型读取的是运行时交给它的内容——不是直接读取你的网站。"
换句话说，AI 智能体与你的网站之间，已经多了一个"中间层"。而 Lighthouse 的 Agentic Browsing 报告，测的就是你的网站对这个中间层来说是否"可解析、可操作"。
这对做外贸独立站的企业意味着什么？很简单：如果你的网站 100% 为人眼设计、用大量 JavaScript 动态渲染、没有任何结构化动作标记，AI 智能体在执行任务（比如帮客户"比较三家供应商的价格并预约打样"）时，会直接跳过你——不是因为你产品不行，是因为你的网站机器读不懂。这就是为什么量化必须先行。
Lighthouse Agentic Browsing 到底检测哪三个维度
打开 Chrome Canary，安装完成后访问你要检测的页面，右键"检查"→ Lighthouse 面板 → 选择 Agentic Browsing 类别 → 运行——几分钟后你会拿到一个分数和具体建议。目前报告主要覆盖以下三大检测维度。理解这些维度，远比拿一个总分重要。
维度一：无障碍树——从屏幕阅读器到 AI 导航地图
很多人把"无障碍"理解成残障人士适配，觉得那是政府网站才需要做的事。但在 AI 智能体时代，无障碍标记已经不再是选配——它天然是 AI 代理的导航地图。
为什么？因为 AI 代理理解网页的方式，不是"眼睛看"，而是通过三个层级：视觉快照、HTML 源码、无障碍树（Accessibility Tree）。其中无障碍树承担了一个独特角色——告诉代理哪里是按钮、哪里是表单输入框、哪里是人机交互的关键节点。当一个网站完全没有 ARIA 标记、语义化 HTML 时，AI 代理就像走进了一个没有任何路标的城市。
Marine Haynes 在介绍这个新功能时说了一句非常准确的判断："无障碍树最初是为屏幕阅读器设计的，但它实际上告诉 AI 代理按钮在哪里。"这个历史巧合意味着：过去几年认真做了无障碍合规的团队，已经在这个新维度上拿了高分。而那些把"无障碍"当成可选需求的团队，现在发现自己面对的不是合规问题，而是代理友好度的系统性扣分。
具体排查什么？首先检查你外贸站的页面是否有正确的语义标签（<button> 而不是 <div onclick>）、表单字段是否有正确的 label 关联、导航是否有清晰的 landmark 标记。这些都是 Lighthouse 报告会直接列出的扣分项。
关于 AI 代理如何读取网站信息、什么样的结构才算"可解析"，AI 是怎么获取你网站信息的 一文中我们做过完整拆解，建议对照阅读，理解抓取链、解析链和索引链的区别。
维度二：WebMCP——把网站动作暴露为机器可读的协议
这可能是三个维度中最被低估、但未来杠杆最高的一个。
WebMCP（Model Context Protocol for Web）是一个新提出的网页标准，核心思想很简单：让开发者能为 AI 智能体构建并暴露"结构化工具"。它分成两类：声明式（告诉代理这个表单的字段含义和提交目标）和命令式（支持双向交互，网站可以主动响应代理的请求）。
这样理解吧——传统 HTML 表单对 AI 代理来说就是一堆 <input name="field_7"> 这样的无意义标签，代理要靠"猜"来判断哪个字段填邮箱、哪个填数量。WebMCP 直接告诉代理："这是邮邮箱、这是数量、提交后会创建一个询价单。"猜的成本消除，代理完成任务的意愿和成功率自然大幅提升。
与 WebMCP 形成互补的，是 Google 在 2026 年初发布的 UCP（Universal Commerce Protocol，通用商务协议）。我们之前在 Agent 化搜索来了：让 AI 智能体能用你的网站 中讨论过它的架构。UCP 包含五个"机器优先架构"的属性：可发现的动作、可预测的结果、工作流连续性、错误恢复、代理策略——WebMCP 可以看作是这套架构在网页层面的技术实现路径。
对外贸独立站来说，WebMCP 优先级取决于你的业务类型：如果你的网站上有"提交询价"、"预约样品邮寄"、"获取报价"等需要代理代用户执行的动作，那么 WebMCP 就是高优先级基础设施。如果你是纯内容型网站、没有交易动作，目前可以保持关注但不急于落地。
维度三：llms.txt——被误解最多的一个文件
关于 llms.txt，市场上有两种矛盾的指导。Google Search 团队明确说过"不需要它来提升搜索可见度"——但 Lighthouse 的 Agentic Browsing 报告明确检查它。
两者都对，因为它们说的是不同场景：
- 搜索可见度场景：llms.txt 对传统 Google 搜索结果排名没有直接影响，Search 团队的说法成立。
- 代理理解场景：llms.txt 在 AI 智能体推理时提供网站的"目录"——告诉代理哪些页面重要、哪些是可执行动作、哪些内容允许抓取。Lighthouse 检查它，是因为它直接提升代理执行任务的成功率。
Marie Haynes 的原话点穿了定位差异："这和'搜索优化'不同——这个文件帮助代理在推理时理解你的网站，告诉它被允许的代理活动和重要信息的位置。"
所以 llms.txt 该不该做？用下表快速决策：
| 你的网站类型 | 是否应该做 llms.txt | 理由 |
|---|---|---|
| 有下单/预约/咨询等交易动作 | 应该做 | 代理需要知道哪些动作可执行、哪些页面是核心流程 |
| 纯内容站/博客（无交易） | 可做可不做 | 对引用有帮助但不是决定性因素 |
| 只为"刷分"而做 | 不要做 | 没有真实代理场景支撑的 llms.txt 没有意义 |
关于 llms.txt 的内容策略，放行 AI 爬虫：GPTBot/ClaudeBot 等配置清单 中有完整的爬虫配置对照，在做 llms.txt 之前，建议先确保你的 robots.txt 和必要的 AI 爬虫放行规则已经就位，避免"写了指引但代理进不来"的尴尬。
动手检测：从装 Chrome Canary 到读懂报告
如果你还没动起来，下面是具体步骤。整个流程从安装到产出可执行清单，熟练了只需要 30 分钟。
- 安装 Chrome Canary：去 Google 官网下载（注意是 Canary 测试版，不是普通 Chrome），安装后会独立存在，不影响你的正式浏览器。
- 打开你要测的页面：建议先测首页、核心产品页、询价/联系页三个关键端点。不要只测一个页面就下结论——不同页面的代理就绪度可能差异很大。
- 运行 Agentic Browsing 报告：F12 打开开发者工具 → Lighthouse 标签 → 勾选 Agentic Browsing → 点击"Analyze page load"。几分钟后出报告。
- 看分数、读诊断项：不要只看总分。逐个展开诊断条目，重点关注标红和标黄的项。Lighthouse 会给出每个问题的解释和修复建议。
- 建立基线：第一次跑出的分数就是你网站的"代理就绪度基线"。把它记录下来——一个月优化后再跑一次，对比变化。
关于网站整体可被 AI 检测和抓取的诊断方法，你的网站在各大 AI 里可见吗？一套自测方法 里有一套跨平台检查流程，可以和 Lighthouse 检测配合使用——前者测的是"能不能被找到"，后者测的是"找到后能不能被用"。
如何解读分数：不是"及格就行"
Lighthouse 的报告通常给一个 0-100 的分数。但要警惕一个误区：追求 100 分没有意义，关键在于搞清楚分数背后的优化优先级。
以下是我们基于外贸独立站实战经验给出的分层解读框架——不同分数段，代表不同的紧迫程度：
| 分数段 | 状态评估 | 对应行动 | 典型场景 |
|---|---|---|---|
| 0-30 分 | 代理基本不可用 | 紧急修复——先解决无障碍树和无结构数据两大扣分项 | 大量使用 JS 动态渲染、无 Schema 标记、移动端排版错乱的网站 |
| 31-60 分 | 代理可"看"但不可"动" | 聚焦动作层——补充 WebMCP 或 Schema Actions 标记 | 有结构化内容但缺少机器可读动作标记的网站 |
| 61-85 分 | 基本可用，但缺少精细指引 | 做 llms.txt 和端点级优化，明确代理策略 | 在 Lighthouse 无障碍评分不错但缺少代理特定指导的网站 |
| 86-100 分 | 代理友好，保持即可 | 定期监测，关注 WebMCP 标准演进而非停滞 | 已经投入过无障碍 + 结构化数据的成熟网站 |
一个实际案例：2025 年底我们为一家工业零部件外贸企业做 GEO 审计时，用 Lighthouse 检测他们的产品分类页，得分只有 19 分。扣分最严重的三项是：无障碍树缺失（按钮使用 <div> 实现）、表单无 label 关联、没有任何 Schema 标记。这个分数直接解释了为什么他们网站的"询价"动作对 AI 代理来说完全不可见——不是在隐私层级被屏蔽，而是在解析层级就"透明"了。
分层优化清单：按投资回报率排序
资源永远是有限的。下面是按高→中→低 ROI 排列的优化动作，建议按顺序做，不要"平均分配资源"。
第一层：脚手架层（高 ROI，立即做）
- 修复无障碍树问题：把
<div onclick>换成<button>；为所有表单输入框设置语义化<label>；为主页面添加合理的landmark（如<header>、<main>、<nav>）。这些不仅提升代理就绪度，本身就是无障碍合规的要求——所谓"一次重构，两个维度受益"。 - 为关键端点补 Schema 标记：至少覆盖产品页（
Product、Offer）、组织页（Organization、ContactPoint）、文章页（Article、BreadcrumbList）。关于 Schema 与 AI 引用之间的关系，FAQ 与 Schema：用结构化问答喂养 AI 一文有实操模板可参考。 - 用 curl 测试关键页面的纯 HTML 返回：不看浏览器渲染效果，看服务器直接返回的 HTML 里有没有你的核心产品信息。如果信息全藏在 JavaScript 里，AI 代理读到的是一个空壳。
第二层：动作层（中 ROI，按阶段推进）
- 评估 WebMCP 是否适用于你的交易页面：如果你的网站有询价、预约、样品申请等功能，研究 WebMCP 的声明式实现路径。目前标准还在早期，但先做技术预研不会浪费——等标准成熟再追，成本成倍放大。
- 为"代理可执行"的动作做 llms.txt：不要照搬 sitemap 做全站映射。llms.txt 应该精准告诉 AI 代理："这些页面可以自主操作、这些页面需要人类确认、这些页面禁止代理访问。"
- 检查认证机制是否支持多调用场景：如果你有会员登录、询价单管理等需要身份验证的功能，传统 Session Cookie 模式在 AI 智能体"跨多次调用、跨不同时间点"的场景下经常失败。API Key 认证是更友好的替代方案。
第三层：专业级优化（低 ROI 但有战略价值）
- 实现完整的 Agent Policy 声明：明确告诉 AI 代理哪些操作允许、哪些需要人类审批、哪些完全禁止。这不是技术炫技，而是防止代理自主做出超出你预期的操作。
- 为 JSON-LD 格式的结构化数据增加"动作描述"：在 Schema 标记中嵌入
Action类型，让代理不只知道"这是什么"，也知道"我能拿它做什么"。 - 关注
/.well-known/端点标准：Google UCP 和 WebMCP 都使用这个路径作为能力清单的发布位置。定期关注规范更新，确保你的实现跟上标准迭代。
先量化，再优化——把 AI 准备度从感觉变成数据
GEO 优化圈子里有一个普遍的问题：太多人凭感觉做判断，太少人拿数据做基线。"我觉得我们内容挺结构化啊""我们技术说网站对 AI 应该挺友好的吧"——这些话在数据面前没有意义。
回想一下传统 SEO：你会在优化前先跑一次 Ahrefs、Google PageSpeed Insights 或 Semrush，拿到关键词排名、网站速度、外链数据作为基线，然后基于数据制定策略、量化追踪进展。为什么到了 GEO 和 AI 搜索时代，这套科学流程反而被跳过了？
Lighthouse Agentic Browsing 的意义正在于此——它把"AI 能不能用我的网站"这个之前只能拍脑袋的问题，变成了一组可测量、可对比、可追踪的工程指标。
这和询盘云在项目启动时做"量化基线"的方法论一致：每一个外贸独立站的 GEO 项目，我们都会在启动阶段跑完搜索引擎可见度诊断、结构化数据审计、内容可引用性评估、代理可交互性检测等几个模块，产出一份"就绪度基线"后，才开始制定优化路径。为什么非要这么做？因为不量化的 GEO 投入和赌博没什么区别——你可能在错误的维度上花了大半年资源，最后才发现 AI 代理根本进不来。
关于量化方法论的延伸阅读，建议看 GEO 是什么？外贸人必须搞懂的生成式引擎优化，里面讲清楚了 GEO 为什么必须从"能测量"开始，而不是从"能写内容"开始。
三个领域的实操侧重
外贸网站类型不同，在代理就绪度这件事上的紧迫点和发力点也不同。细分一下：
B2B 工业品 / 机械设备
这类网站以询价、打样、技术支持为核心动作。用户的采购决策链条长，AI 代理代表买家执行"比较三家、发起询价、获取报价"这类任务的概率极高。表单字段的语义化标记和 Schema Action 是你最该优先做的事。一个没有 label 关联的"联系人"表单，在 AI 眼里就是一堆无意义的输入框——优化它不需要重构网站，通常是前端 markup 层面的改进。
DTC 消费品
购物车、结账、产品筛选——这些是 AI 代理最常尝试执行的操作。检查无障碍树和 WebMCP 可行性是你的高优项。如果一个加购按钮的实现是 <div class="add-to-cart"> 而不是 <button>，AI 代理可能根本不知道它是可以点击的。投资无障碍修复对这类网站的 ROI 最高，因为直接影响转化。
本地服务 / 定制加工
预约、咨询、提交需求——这些动作如果不可被代理执行，你失去的不是"流量"，是"本可以自动完成的交易"。在 Schema 里嵌入 Actionable 标记，显式告诉 AI 代理"这个预约动作可以被代理自动执行，无需人类客户端确认"。同时做 llms.txt，标注清晰的能力清单。
最后说一个容易被忽略的判断： Lighthouse Agentic Browsing 报告跑出来的分数，不是你做了所有优化才能用的"终极成绩单"，而是用来指导你下一步先改什么的"优先级地图"。看到低分不用焦虑——它们恰好告诉你，解决哪三个问题就能最快提升代理可用性。真正该焦虑的，是那些从来没有跑过这个报告、直到 2027 年 AI 代理大规模进入采购流程才发现自己网站"从结构上就不可用"的团队。
常见问题（FAQ）
如何在Lighthouse中生成AI代理就绪度报告？
您需要下载Chrome Canary版浏览器，打开开发者工具中的Lighthouse面板，在类别中勾选“Agentic Browsing”后运行审计。报告会从无障碍树完整性、WebMCP暴露的动作数量、llms.txt文件存在性与质量三个维度评分。例如，某外贸站首次报告仅得43分，主要扣分在缺失llms.txt和无障碍标签不足；补充llms.txt并修复关键ARIA标签后，分数提升至81分，AI代理任务完成率从32%提高到74%。
无障碍树（Accessibility Tree）为什么是AI代理的导航骨架？优化它能带来什么具体提升？
AI代理依赖无障碍树理解页面结构，如同视障用户使用的屏幕阅读器。若按钮缺少语义标签，代理无法识别可点击元素；若标题层次混乱，代理难以定位信息。对比案例：某B2B产品页优化前无障碍树节点中无可交互标记占比47%，代理提取规格表成功率仅22%；为关键元素补充aria-label、role属性后，可交互标记覆盖率达92%，代理正确提取率升至85%。
WebMCP标准如何让AI代理执行动作？我们的网站需要怎样对接？
WebMCP（Web Model Context Protocol）是一种暴露网站可执行动作的标准，通过结构化JSON描述每个操作（如搜索、筛选、提交）。对接时需在页面嵌入符合规范的JSON-LD脚本，声明动作的输入参数和触发方式。例如，某询盘表单对接后，代理可自动填写并提交，无需依赖视觉解析。实测数据显示，提供WebMCP的站点代理完成任务耗时平均缩短40%，误操作率降低67%。
llms.txt文件究竟是什么？它如何帮助AI代理做任务规划？
llms.txt是专为大语言模型设计的网站说明文件，用简洁的Markdown描述网站核心功能、关键页面和常用操作指令。它相当于给AI代理的速查手册。一个优秀llms.txt示例：列出产品搜索页路径、询盘提交流程步骤、FAQ快速入口，并附上示例查询语句。没有该文件的站点，代理可能需要多轮试错才能理解结构；加入后，任务完成跳步数减少50%以上，首次正确率显著提升。
Agentic Browsing报告分数低，我应该优先优化哪一部分？
分数报告会给出三个维度的子分数。建议优先修复llms.txt缺失——这是成本最低、见效最快的优化，创建一个10行内的清晰说明即可提升15-20分。其次处理无障碍树关键遗漏：用Chrome DevTools的Accessibility面板找出所有无标签按钮、无标题链接并补充aria-label。最后再投入资源实施WebMCP，这需要开发配合但能带来质的飞跃。某工具站按此优先级优化后，三周内代理驱动转化率从0.3%升至2.1%。
本文由询盘云 RAG GEO 内容生产线产出，部分案例与数据引用自询盘云原创资料及公开行业研究。