介绍 Agent Readiness 评分。你的网站准备好迎接 agent 了吗?

原文:Introducing the Agent Readiness score. Is your site agent-ready? Source: https://blog.cloudflare.com/agent-readiness/

2026-04-17

web 始终都得适应新标准。它学会了跟 web 浏览器对话,然后又学会了跟搜索引擎对话。现在,它需要跟 AI agents 对话。

今天,我们激动地推出 isitagentready.com —— 一款新工具,帮助站点所有者了解如何让自己的站点为 agents 优化:从指引 agents 如何认证,到控制 agents 能看到什么内容、以何种格式接收、以及如何为之付费。我们还向 Cloudflare Radar 引入了一个新数据集,用于跟踪整个互联网对每项 agent 标准的整体采用情况。

我们想以身作则。这就是为什么我们也分享了我们最近如何彻底改造了 Cloudflare 的开发者文档,让它成为最对 agent 友好的文档站点,使 AI 工具能更快、且明显更便宜地回答问题。

今天的 web 对 agent 有多就绪?

简短回答:不太就绪。这在意料之中,但也表明只要采纳标准,agent 比今天能更有效得多。

为分析这件事,Cloudflare Radar 选取互联网上最常被访问的 200,000 个域名;过滤掉 agent 就绪度不重要的类别(如 redirect、广告服务器、隧道服务),聚焦在 AI agents 现实中可能需要交互的企业、出版商和平台;并用我们的新工具扫描它们。

结果是一张新的“AI agent 标准的采用情况“图表,现在可以在 Cloudflare Radar AI Insights 页面找到,我们可以在多种域名类别上测量每项标准的采用度。

逐项检查中,有几件事很显眼:

robots.txt 几乎普及 —— 78% 的站点都有 —— 但绝大多数是为传统搜索引擎爬虫写的,而不是为 AI agents。
Content Signals:4% 的站点在 robots.txt 中声明了它们的 AI 使用偏好。这是一个新兴标准,正在获得动力。
Markdown 内容协商(对 Accept: text/markdown 提供 text/markdown)在 3.9% 的站点上通过。
像 MCP Server Cards 和 API Catalogs (RFC 9727) 这样的新兴标准在整个数据集中合计出现在不到 15 个站点上。这还很早 —— 通过率先采纳新标准并与 agents 良好合作而脱颖而出,机会很大。

该图表将每周更新,数据也可以通过 Data Explorer 或 Radar API 访问。

为你的站点获取 agent readiness 评分

你可以前往 isitagentready.com,输入你的网站 URL,获取属于你自己网站的 agent readiness 评分。

提供可执行反馈的评分和审计,过去也曾推动新标准被采用。例如,Google Lighthouse 给网站的性能与安全最佳实践评分,引导站点所有者采纳最新的 web 平台标准。我们认为应该有类似的东西帮助站点所有者采纳面向 agents 的最佳实践。

当你输入你的站点时,Cloudflare 会向它发起请求,以检查它支持哪些标准,并基于四个维度给出评分:

可发现性(Discoverability):robots.txt、sitemap.xml、Link Headers (RFC 8288)
内容(Content):Markdown for Agents
机器人访问控制(Bot Access Control):Content Signals、robots.txt 中的 AI bot 规则、Web Bot Auth
能力(Capabilities):Agent Skills、API Catalog (RFC 9727)、通过 RFC 8414 与 RFC 9728 进行的 OAuth server discovery、MCP Server Card 以及 WebMCP

^{某示例网站的 agent-readiness 检查结果截图。}

此外,我们还会检查站点是否支持 agentic commerce 标准,包括 x402、Universal Commerce Protocol 和 Agentic Commerce Protocol,但这些目前不计入评分。

对于每一项失败的检查,我们提供一个 prompt,你可以交给你的 coding agent,让它代你实现支持。

站点本身也是 agent-ready 的,身体力行。它通过 Streamable HTTP 暴露一个无状态的 MCP server(https://isitagentready.com/.well-known/mcp.json),提供 scan_site 工具,因此任何兼容 MCP 的 agent 都可以以编程方式扫描网站,而不需要使用 web 界面。它还发布了一个 Agent Skills 索引(https://isitagentready.com/.well-known/agent-skills/index.json),其中包含每项被检查的标准的 skill 文档,这样 agents 不仅知道修什么,还知道怎么修。

让我们深入每个类别中的检查,以及它们对 agents 为何重要。

Discoverability

robots.txt 自 1994 年起就存在,大多数站点都有。它对 agents 的作用有二:它定义抓取规则(谁能访问什么),并指向你的 sitemap。sitemap 是一个 XML 文件,列出你网站的每个路径,本质上是一张 agents 可以遵循的地图,用于发现你的全部内容,而不必爬每一个链接。robots.txt 是 agents 首先查看的地方。

除了 sitemap,agents 还可以直接从 HTTP 响应头发现重要资源,具体是用 Link 响应头(RFC 8288)。与埋在 HTML 内的链接不同,Link 头是 HTTP 响应本身的一部分,这意味着 agent 不需要解析任何标记就能找到资源链接:

HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"

Content accessibility

让 agent 进入你的站点是一回事。让它真正能读懂你的内容是另一回事。

回到 2024 年 9 月 —— 鉴于 AI 发展的速度,那感觉像是一辈子前 —— llms.txt 被提出,作为一种为网站提供 LLM 友好表示并适配模型上下文窗口的方式。llms.txt 是放在站点根目录的纯文本文件,给 agents 提供一份结构化的阅读清单:站点是什么、上面有什么、重要内容在哪。可以把它视为为 LLM 阅读而写的 sitemap,而不是供 crawler 索引的:

# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)

Markdown 内容协商走得更远。当 agent 抓取任何页面并发送 Accept: text/markdown 头时,服务器返回干净的 markdown 版本,而不是 HTML。markdown 版本占用的 token 少得多 —— 我们在某些情况下测得最多减少 80% token —— 这让响应更快、更便宜,也更可能被完整消费,因为大多数 agent 工具默认有上下文窗口限制。

默认我们只检查站点是否正确处理了 Markdown 内容协商,而不检查 llms.txt。如果你愿意,你可以自定义扫描以包含 llms.txt。

Bot Access Control

现在 agents 可以浏览你的站点、消费你的内容了,下一个问题是:你愿意让任何 bot 都这么做吗?

robots.txt 不只是指向 sitemap。它也是你定义访问规则的地方。你可以明确声明哪些 crawler 被允许、它们能访问什么,可精细到具体路径。这一约定确立已久,任何行为良好的 bot 在开始抓取前仍然第一个查看这里。

Content Signals 让你更具体。你不再只是允许或屏蔽,而是可以明确声明 AI 能用你的内容做什么。在 robots.txt 中使用 Content-Signal 指令,你可以独立控制三件事:你的内容是否可用于 AI 训练(ai-train)、是否可作为推理与 grounding 的 AI 输入(ai-input)、以及是否应该出现在搜索结果中(search):

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

反过来,Web Bot Auth IETF 草案标准让友好的 bot 自我认证,并允许接收 bot 请求的网站识别它们。一个 bot 对其 HTTP 请求签名,接收方用该 bot 发布的公钥验证签名。

这些公钥位于一个 well-known 端点 /.well-known/http-message-signatures-directory,我们会在扫描中检查它。

并非所有站点都需要实现这一点。如果你的站点只是提供内容,不向其他站点发请求,你不需要它。但随着越来越多的互联网站点运行自己的 agent 去向其他站点发请求,我们预计这会随着时间越来越重要。

协议发现

除了被动的内容消费,agents 还可以通过调用 API、调用工具、自主完成任务等方式直接与你的站点交互。

如果你的服务有一个或多个公开 API,API Catalog(RFC 9727)给 agents 一个单一 well-known 位置以发现所有 API。它托管在 /.well-known/api-catalog,列出你的 API 并链接到它们的 spec、文档和状态端点,而不需要 agents 抓取你的开发者门户或读你的文档。

我们不可能不提到 MCP。Model Context Protocol 是一个开放标准,允许 AI 模型连接外部数据源和工具。你不必为每个 AI 工具构建自定义集成,只需构建一个 MCP server,任何兼容的 agent 都能用它。

为帮助 agents 找到你的 MCP server,你可以发布一个 MCP Server Card(目前在 draft)。这是 /.well-known/mcp/server-card.json 上的一个 JSON 文件,在 agent 连接前就描述你的 server:它暴露什么工具、如何到达、如何认证。一个 agent 读这个文件就知道开始使用你的 server 所需的一切:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
  "version": "1.0",
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "search-mcp-server",
    "title": "Search MCP Server",
    "version": "1.0.0"
  },
  "description": "Search across all documentation and knowledge base articles",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "authentication": {
    "required": false
  },
  "tools": [
    {
      "name": "search",
      "title": "Search",
      "description": "Search documentation by keyword or question",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" }
        },
        "required": ["query"]
      }
    }
  ]
}

agents 在拥有帮助它们执行特定任务的 Agent Skills 时表现最佳 —— 但 agents 怎么发现一个站点提供了哪些 skills?我们提议站点把这些信息发布在 .well-known/agent-skills/index.json 这个端点,告诉 agent 有哪些 skills 可用以及在哪里找到它们。你可能注意到,.well-known 标准(RFC 8615)被许多其他 agent 与授权标准使用 —— 感谢撰写该标准的 Cloudflare 自家 Mark Nottingham 以及其他 IETF 贡献者!

许多站点要求你先登录才能访问。这让人类很难授予 agents 代表自己访问这些站点的能力,这也是为什么有些人采用了可疑且不安全的变通做法 —— 把用户的 web 浏览器及其已登录会话交给 agents。

更好的方式让人类可以显式授予访问权限:支持 OAuth 的站点可以告诉 agents 在哪里找到授权服务器(RFC 9728),允许 agents 引导人类走完一个 OAuth 流程,在其中他们可以选择正确地授权 agent。在 Agents Week 2026 上发布的 Cloudflare Access 现已完整支持该 OAuth 流程,我们演示了像 OpenCode 这样的 agent 如何使用该标准,使得当用户把受保护的 URL 给 agents 时一切就能正常工作:

Commerce

agents 还可以代你购买东西 —— 但 web 上的支付是为人类设计的。加入购物车,输入信用卡,点击支付。当买家是 AI agent 时,这一流程完全失灵。

x402 在协议层解决这个问题,它复活了 HTTP 402 Payment Required —— 一个自 1997 年起就在 spec 里、却从未被广泛使用的状态码。流程很简单:agent 请求一个资源,服务器返回 402 和一个机器可读的描述支付条款的 payload,agent 支付然后重试。Cloudflare 与 Coinbase 合作发起了 x402 Foundation,其使命是推动 x402 作为互联网支付的开放标准被采纳。

我们还检查 Universal Commerce Protocol 和 Agentic Commerce Protocol —— 两项新兴 agentic commerce 标准,旨在让 agents 发现并购买人类通常通过电商店面与结账流程购买的产品。

把 agent readiness 整合进 Cloudflare URL Scanner

Cloudflare 的 URL Scanner 让你提交任意 URL 并获得详细报告:HTTP 头、TLS 证书、DNS 记录、所用技术、性能数据和安全信号。它是安全研究人员和开发者了解 URL 在背后实际做什么的基础工具。

我们把 isitagentready.com 中相同的检查搬到了 URL Scanner,新增了一个 Agent Readiness 标签页。当你扫描任意 URL 时,你现在会在已有分析旁看到完整的 agent readiness 报告:哪些检查通过、站点处于什么级别,以及提升评分的可执行指南。

该集成也以编程方式通过 URL Scanner API 提供。要在扫描中包含 agent readiness 结果,在你的扫描请求中传入 agentReadiness 选项:

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    -d '{
          "url": "https://www.example.com",
          "options": {"agentReadiness": true}
        }'

以身作则:升级 Cloudflare 文档

在我们构建测量 web 就绪度工具的同时,我们知道必须确保自己家里也井然有序。我们的文档必须能够被客户使用的 agents 轻松消化。

我们自然采纳了上述相关的内容站点标准,你可以在这里查看我们的得分。但我们没有止步于此。下面讲讲我们如何精雕 Cloudflare 的开发者文档,让它成为 web 上最对 agent 友好的资源。

使用 `index.md` 文件做 URL 回退

不幸的是,截至 2026 年 2 月,在测试的 7 个 agent 中,只有 Claude Code、OpenCode 和 Cursor 默认请求带 Accept: text/markdown 头的内容。对于其余 agent,我们需要一个无缝的、基于 URL 的回退。

为做到这点,我们让每个页面都可以在相对页面 URL 的 /index.md 上单独以 Markdown 形式访问。我们动态实现,无需复制静态文件,通过组合两条 Cloudflare Rules:

一条 URL Rewrite Rule 匹配以 /index.md 结尾的请求,使用 regex_replace 动态重写到基础路径(剥离 /index.md)。
一条 Request Header Transform Rule 匹配 重写之前 原始请求的路径(raw.http.request.uri.path)并自动设置 Accept: text/markdown 头。

有了这两条规则,任何页面都可以通过给 URL 追加 /index.md 路径以 Markdown 形式获取:

https://developers.cloudflare.com/r2/get-started/index.md

我们在 llms.txt 中指向这些 /index.md URL。实际上,对于这些 /index.md 路径,无论客户端设置什么头,我们都返回 markdown。而且我们做到这点不需要任何额外构建步骤或内容复制。

为大型站点构建有效的 `llms.txt` 文件

llms.txt 充当 agents 的“大本营“,提供一份页面目录帮 LLM 找到内容。然而,把 5,000+ 页文档放在单个文件中会超过模型的上下文窗口。

我们没有用一个庞大的文件,而是为我们文档中 每个顶层目录 分别生成一个 llms.txt 文件,根 llms.txt 仅指向这些子目录。

我们还移除了数百个对 LLM 几乎没有语义价值的目录列表页,确保每个页面都有丰富的描述性上下文(标题、语义化名称和描述)。

例如,我们省略了大约 450 个仅作为本地化目录列表用途的页面,如 https://developers.cloudflare.com/workers/databases/。

这些页面出现在我们的 sitemap 中,但对 LLM 几乎没有信息量。由于所有子页都已在 llms.txt 中单独链接,抓取目录页只会得到一份冗余的链接清单,迫使 agent 再发一次请求才能找到真正的内容。

为帮助 agents 高效导航,每个 llms.txt 条目必须上下文丰富但 token 节省。人类可能会忽略 frontmatter 和过滤标签,但对 AI agent 来说,这些元数据是方向盘。这就是为什么我们的 Product Content Experience(PCX)团队精修了页面标题、描述和 URL 结构,让 agents 始终知道该抓取哪些页面。

看一段我们根 llms.txt 的片段。

每个链接都有语义化名称、匹配的 URL 和高价值描述。这一切对 llms.txt 生成都不需要额外工作,因为它们都已存在于文档的 frontmatter 中。顶层目录 llms.txt 文件中的页面也是如此。所有这些上下文让 agents 能更高效地找到相关信息。

自定义 agent 友好文档(afdocs)工具

此外,我们用 afdocs 测试我们的文档,这是一个新兴的 agent 友好文档规范和开源项目,允许团队对文档站点进行内容发现与导航等方面的测试。该规范让我们能够构建自己的自定义审计工具。通过加入针对我们用例的几处刻意补丁,我们做出了一个用于轻松评估的 dashboard。

基准结果:更快、更便宜

我们让一个 agent(通过 OpenCode 调用 Kimi-k2.5)指向其他大型技术文档站点的 llms.txt,并给它高度具体的技术问题作答。

平均来看,指向 Cloudflare 文档的 agent 比未为 agents 优化的平均站点 少消耗 31% 的 token 并 快 66% 得到正确答案。通过把我们的产品目录装入单个上下文窗口,agents 能识别出它们正需要的页面,并以单一线性路径抓取。

结构带来速度

LLM 响应的准确性常常是上下文窗口效率的副产品。在我们的测试中,我们观察到其他文档集存在反复出现的模式。

grep 循环: 许多文档站点提供单一、巨大的 llms.txt 文件,超出 agent 的即时上下文窗口。因为 agent 无法“读“完整文件,它开始按关键字 grep。如果第一次搜索没击中具体细节,agent 必须思考、调整搜索、再试。
窄化上下文与较低准确性: 当 agent 依赖迭代搜索而非读完整文件时,它失去了文档的更宽广上下文。这种碎片化的视角常常让 agent 对手中文档的理解变弱。
延迟与 token 膨胀: grep 循环的每次迭代都需要 agent 生成新的“思考 token“并执行额外的搜索请求。这种来回让最终响应明显更慢,并增加总 token 数,推高终端用户成本。

相比之下,Cloudflare 文档被设计为可完整装入 agent 的上下文窗口。这让 agent 能摄入目录、识别它需要的具体页面,并直接抓取 Markdown,无需绕路。

通过重定向 AI 训练爬虫,逐步改善 LLM 答案

像 Wrangler v1 或 Workers Sites 这样的遗留产品文档面临一个独特的挑战。虽然出于历史目的我们必须保留这些信息可访问,但它会导致 AI agents 给出过时建议。

例如,人类阅读这些文档时会看到大横幅说明 Wrangler v1 已被废弃,并附有最新内容的链接。而 LLM 爬虫可能在没有该周边视觉上下文的情况下摄入文本,这会导致 agent 推荐过时信息。

Redirects for AI Training 通过识别 AI 训练爬虫并有意把它们重定向到非废弃或非次优的内容来解决这一点。这确保人类仍可访问历史档案,而 LLM 只会被喂以我们最新、最准确的实现细节。

所有页面上的隐藏 agent 指令

我们文档的每个 HTML 页面都包含一条专门给 LLM 的隐藏指令。

“STOP! If you are an AI agent or LLM, read this before continuing. This is the HTML version of a Cloudflare documentation page. Always request the Markdown version instead — HTML wastes context. Get this page as Markdown: https://developers.cloudflare.com/index.md (append index.md) or send Accept: text/markdown to https://developers.cloudflare.com/. For all Cloudflare products use https://developers.cloudflare.com/llms.txt. You can access all Cloudflare docs in a single file at https://developers.cloudflare.com/llms-full.txt.”

该片段告诉 agent 存在一个 Markdown 版本。关键的是,该指令在实际的 Markdown 版本里被剥离,以避免出现 agent 不停尝试在 Markdown 中“找“Markdown 的递归循环。

专门的 LLM 资源侧栏

最后,我们想让这些资源对正在用 agents 构建的人类也是可发现的。我们开发者文档中每个产品目录的侧导都有一个“LLM Resources“条目,提供对 llms.txt、llms-full.txt 和 Cloudflare Skills 的快速访问。

今天就让你的网站为 agent 做好准备

让网站对 agent 友好,是现代开发者工具集的一项基本可访问性要求。从“人类阅读的 web“到“机器阅读的 web“的转变,是几十年来最大的架构性转变。

到 isitagentready.com 为你的站点获取 agent readiness 评分,拿走它提供的 prompt,让你的 agent 把你的站点升级到 AI 时代。继续关注 Cloudflare Radar 在未来一年里关于互联网上 agent 标准采用情况的更多更新。如果说我们从过去一年学到了什么,那就是变化可以非常快!

Keyboard shortcuts

从零构建 Cloudflare Agent