你以为 AI 写代码只能靠你把每个工具地址都配好？今天 Chrome 156 把这件事的发现机制彻底原生化了

你以为 AI 写代码只能靠你把每个工具地址都配好？今天 Chrome 156 把这件事的发现机制彻底原生化了

当一个 AI agent 想调用工具，它得先知道这个工具在哪。长期以来，这件事只能靠你手写配置文件，或者用户自己去装各种插件。但这件事，马上要被一个开放规范彻底改变。

这个规范叫 ARD（Agentic Resource Discovery）。Google、Microsoft、Hugging Face 三家联合发布，Chrome 156 即将在两周内把它的审计集成进 Lighthouse DevTools——你的网站有没有配 ard.json，浏览器马上就能告诉你。

它解决什么问题

现在的 agent 调用工具有两种方式：要么你提前装好插件，要么你告诉 agent「去调用这个 URL」。这两种本质上都是「地址硬编码」，当工具数量从几个变成几十个时，光配置文件就能写满一整屏。

ARD 想做的是：让网站自己站出来说「我这儿有哪些可被 AI 调用的东西」，而不是让 AI 猜测或者靠人力维护配置。具体实现方式很像 SEO 的逻辑：网站在 /.well-known/ard.json 这个文件里声明自己的 AI 资源——MCP 服务器、A2A agent、skills、或者普通的 OpenAPI。然后分布式的注册中心（Registries）去索引这些目录，AI agent 在需要的时候去注册中心查，找到匹配的资源，再去调用。

和 SEO 的区别在于：搜索的是 AI，不是人。

谁在推这个规范

R.V.Guha——这个名字值得停下来。他是 RSS 的作者、Schema.org 的合创者，这已经是他第四次尝试让 Web 自己描述自己了。2026 年 5 月，他联合 Google 的 Junjie Bu 和 Hugging Face 的 Shaun Smith 发布了 ARD 初版，8 月 26 日更新到 v0.91。参与方还包括 Cisco、GitHub、Nvidia、Salesforce、ServiceNow、Snowflake。

整个协议栈正在快速成型：MCP（agent → 工具）已经捐赠给 Linux Foundation 的 Agentic AI Foundation，2026 年 7 月最新 spec 每周 npm 下载超过 5000 万次；A2A（agent → agent）2026 年 3 月发布 v1.0，AWS 和 Microsoft 已经生产可用；WebMCP（agent → 浏览器页面）已在 Chrome 149/150 开启 Origin Trial；ARD（agent → 目录）是最上层，2026 年 5 月才发布，v0.91，刚满三个月。

97% 的文件没人用，这规范还有戏吗

说到数据，现实比想象冷静。Ahrefs 2026 年 6 月对 13.7 万个域名的调查显示：28% 的站点发布了 llms.txt（ARD 的前身），但其中 97% 在 2026 年 5 月收到的请求数是零。

但另一组数据更值得关注：在被实际请求的文件里，19.5% 来自 GPTBot 和 Claude-Code——它们是 AI 编程工具，在抓取开发者文档时主动读取 llms.txt 和 ARD 目录。换句话说，用得最勤的是 coding agent，不是那些通用搜索助手。

Google 自己也在踩刹车：Google Search 明确说「我们不看 llms.txt，不会因为你有这个文件就给你更高排名」。但 Chrome 的 Lighthouse 从 2026 年 5 月起开始检查它，9 月 20 日又把 ARD 审计加了进去——工具在追，规范在等。

Chrome 156 做了什么

Lighthouse 13.5 新增了 Agentic Browsing 审计分类，包含两个检查项：

llms.txt：检查 /.well-known/llms.txt 或 /.well-known/ai-catalog.json，告诉开发者「没有这个文件，AI agent 读你的网站结构要多花 token」。

ARD：检查 /.well-known/ard.json（之前叫 ai-catalog.json，v0.91 改名），对比 manifest 结构和 JSON Schema 的匹配度。

这个审计预计两周内随 Chrome 156 稳定版进入 DevTools，届时你的 PageSpeed Insights 报告会多出一个「Agent Discovery」分类。如果你的站点还没配这个文件，审计会标记为 absent——不是报错，但是会告诉你「这里有一个可选项，你没填」。

怎么落地

最小化实现只需要两件事：

第一步，在站点根目录创建 public/.well-known/ard.json，格式是：

{
  "entries": [
    {
      "identifier": "urn:air:example.com:tools:my-api",
      "displayName": "我的 API 文档",
      "type": "application/vnd.api+json",
      "url": "https://example.com/openapi.json"
    }
  ]
}

identifier 必须是域锚定的 URN，type 是 IANA 注册的媒体类型，url 指向资源本身。这份文件一旦存在，Lighthouse 就能检测到它是否符合规范。

第二步，如果你的站点是文档站，顺手加一个 llms.txt——格式更简单，就是一份 Markdown 导航：

# Example 文档

这里是我们的 API 文档。

## 快速开始
https://example.com/docs/quickstart

## API 参考
https://example.com/docs/reference

llms.txt v2（2026 年 8 月 10 日更新）新增了两条 link relation：<link rel="alternate" type="text/markdown"> 让页面声明自己的 Markdown 版本；<link rel="describedby"> 让页面声明「我是由哪份 llms.txt 描述的」。大站点可以给不同 section 配不同的 llms.txt，agent 读到哪页就知道查哪份目录。

要不要现在做

看场景。如果你的站点是给 AI 编程工具用的文档站，这个时间点刚好：Claude Code 和 Hugging Face CLI 已经在用，Chrome 156 两周内集成 Lighthouse 审计，现在配等于提前占位。

如果你的站点是普通营销站，内容面向真人用户，规范本身说得很清楚：「什么都不放也不会坏」，因为没有哪个主流搜索引擎因为你没有 llms.txt 而降权。

这件事的本质，是一个尚未完全定型的开放标准在工具层的率先采纳——就像 2000 年代初的 sitemap.xml，最早只有 Google 支持，后来成了标配。现在 ARD 还在那个早期阶段，v0.91，463 个 GitHub star，但 Chrome 把它放进了开发者工具，这个信号值得注意。

先把 ard.json 放上去，格式不用一步到位，符合 spec 的 identifier + displayName + type + url 四件套就行。规范在变，但这份最小实现永远是你未来接入注册中心的底座。