Web 必须不断适应新的标准。GPT 学会了与 Web 浏览器交流，然后它又学会了与搜索引擎交流。现在，它需要与 AI 智能体对话。
今天，我们很高兴推出 isitagentready.com — 这是一款帮助站点所有者了解如何优化其站点以适应智能体的新工具，包括指引智能体如何验证身份、控制智能体可以看到的内容、内容接收的格式以及如何为内容付费。我们也在 Cloudflare Radar 引入新的数据集，用以跟踪互联网对每种智能体标准的整体采用情况。
我们希望以身作则。因此，我们还通过本文分享最近如何对 Cloudflare 的开发人员文档进行全面改造，以使其成为最智能体友好的文档网站，方便 AI 工具更快速和大大更低成本地回答问题。
简短回答：不怎么样。这个结果并不意外，但这样清楚地表明，如果有关标准得到采纳，智能体的效能将大幅提升。
为了进行此项分析，Cloudflare Radar 选取了互联网上访问量排名前 20 万的域名；过滤掉了 AI 智能体就绪度评分不适用的类别（如重定向、广告服务器和隧道服务），以专注于 AI 智能体实际业务场景中可能与之交互的企业、出版商和平台；并使用我们的新工具对其进行了扫描。
结果生成了一个新的“AI 智能体标准采纳情况”图表，现已发布在 Cloudflare Radar AI Insights 页面找到，用于衡量各项标准在多个域名类别中的采纳情况。
分析各个检查维度的结果，我们发现以下几点尤为突出：
此图表将每周更新，您也可通过 Data Explorer 或 Radar API 访问相关数据。
若要为您的网站获取智能体就绪度评分，请访问 isitagentready.com，然后输入您的网站 URL。
评分和审计工具通过提供可操作的反馈，已在过去成功推动了新标准的采纳。例如，Google Lighthouse 会对网站的性能和安全最佳实践进行打分，并指导网站所有者采用最新的 Web 平台标准。我们认为，应存在类似的方法来帮助网站所有者采用针对智能体的最佳实践。
当您输入网站时，Cloudflare 会向其发送请求，以检查它支持哪些标准，并根据四个维度进行评分：
示例网站的智能体就绪度检查结果截图。
此外，我们还会检查网站是否支持智能体商业标准，包括 x402、通用商业协议 (Universal Commerce Protocol) 和 Agentic Commerce 协议，但这些标准目前不计入评分。
对每一项未通过的检查，我们都会提供一个您可以提交给编码智能体的提示词，帮助您实施支持。
该站点本身也是智能体就绪的，践行其倡导的标准。它使用 scan_site 工具通过 Streamable HTTP 中暴露了一个无状态的 MCP 服务器 (https://isitagentready.com/.well-known/mcp.json)，这样任何 MCP 兼容的智能体都可以编程方式扫描网站，而无需使用、Web 界面。它还发布了一个智能体技能索引（https://isitagentready.com/.well-known/agent-skills/index.json），包含针对每项检查标准的技能文档，这样智能体不仅知道需要修复什么，还知道如何修复。
让我们深入探讨各类别中的检查项，以及它们对智能体的重要性。
robots.txt 自 1994 年起开始使用，大多数站点都有一个这样的文件。对于智能体而言，robots.txt 有两个作用：定义爬取规则（谁可以访问什么），并指向您的站点地图。网站地图是一个 XML 文件，其中列出了您网站上的每条路径，本质上是一份智能体可以遵循的地图，无需爬取每个链接即可发现您的所有内容。robots.txt 是智能体首先查找信息的地方。
除了站点地图外，智能体也可以直接从 HTTP 响应标头发现重要资源，具体是使用 Link 响应头 (RFC 8288)。与埋藏在 HTML 中的链接不同，Link 头是 HTTP 响应本身的一部分，意味着智能体可以找到指向资源的链接，而无需解析任何 HTML 标记：
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
让智能体访问您的网站是一回事。确保它能够真正读取您的内容是另一回事。
2024 年 9 月（说起来像是很久以前了，因为 AI 发展速度太快）， llms.txt 曾被提议作为一种为网站提供 LLM 友好表示、并能够适应模型的上下文窗口的方式。llms.txt 是位于您网站根目录的一个纯文本文件，可为智能体提供结构化的阅读清单：网站是什么、网站包含哪些内容以及重要内容位于何处。可将其视为一份为 LLM 阅读而非为爬虫索引而编写的网站地图
# 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 内容协商则更进一步。当智能体获取任何页面并发送一个 Accept: text/markdown 标头时，服务器会响应一个干净的 Markdown 版本，而不是 HTML。Markdown 版本需要的 token 要少得多 — 我们测量到某些情况下可减少多达 80% 的 token 消耗，从而使响应更快、更便宜，并且更有可能在其默认上下文窗口限制内消费完响应内容（大多数智能体工具均有默认限制）。
默认情况下，我们只会检查站点是否正确处理了 Markdown 内容协商，而不检查 llms.txt。您可以定制扫描以包含 llms.txt。
既然智能体可以浏览您的网站和消费您的内容，接下来的问题是：您是否希望任何机器人都能这样做呢？
robots.txt 的作用不仅仅是指向站点地图。您也可以在此定义访问规则。您可以明确声明允许哪些爬虫，以及它们可以访问哪些内容，精确到具体路径。这项约定已被广泛采纳，至今仍是所有合规爬虫在开始爬取网站前必先检查的地方。
内容信号（Content Signals）让您更精确地定义内容使用规则。您可以精确定义 AI 可以对您的内容执行哪些操作，而不仅仅是允许或阻止。在您的 robots.txt 文件中使用 Content-Signal 指令，您可以独立控制三个方面：是否允许将您的内容用于 AI 训练（ai-train），是否允许将其用作推理和知识锚定 （ai-input）的 AI 输入，以及是否应将其显示在搜索结果中（search）：
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes
相反，Web Bot Auth IETF 草案标准允许友好机器人进行身份验证，并允许网站收到来自机器人的请求时予以识别。机器人使用私钥对其 HTTP 请求进行签名，接收端网站则使用该机器人发布的公钥来验证签名。
这些公钥位于标准约定端点 /.well-known/http-message-signatures-directory，我们在扫描过程中会访问并验证该端点。
并非所有网站都需要实施此项措施。 如果您的网站仅提供内容，不向其他网站发出请求，您就不需要它。但随着越来越多的互联网网站运行自己的智能体并其他网站发出请求，我们预计这一点将随着时间的推移变得越来越重要。
除了被动消费内容之外，智能体还可以通过调用 API、调用工具并自主完成任务来直接与您的网站互动。
如果您的服务有一个或多个公共 API，API Catalog（RFC 9727）可让客户在一个统一的已知位置发现所有这些 API。它托管于 /.well-known/api-catalog，列出您的 API 及其规范、文档和状态端点的链接，无需智能体抓取您的开发人员门户或阅读您的文档。
谈到智能体，就不得不提 MCP。模型上下文协议（MCP）是一个开放标准，使 AI 模型可以连接到外部数据源和工具。您无需为每种 AI 工具单独构建定制集成，只需构建一个 MCP 服务器，任何兼容的智能体都可以使用它。
为了帮助智能体找到您的 MCP 服务器，您可以发布一个 MCP Server Card（一个目前处于起草阶段的提案）。这是一个 JSON 文件，位于 /.well-known/mcp/server-card.json，在智能体访问您的服务器前获取有关信息：公开了什么工具、如何访问以及如何进行身份验证。通过读取此文件，智能体可获得开始使用您的服务器所需的一切信息
{
"$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"]
}
}
]
}
智能体在具备帮助其执行特定任务的智能体技能（Agent Skills）时工作效果最佳——但智能体如何发现网站提供了哪些技能呢？我们建议网站可以在.well-known/agent-skills/index.json 中提供这些信息，告诉智能体该网站提供哪些技能以及在哪里可以找到这些技能。您可能注意到 .well-known 标准（RFC 8615）广泛应用于多个智能体和授权标准中。在此向 Cloudflare 的 Mark Nottingham（该标准的主编者）和其他 IETF 贡献者表示感谢！
许多网站要求您先登录才能访问。这使得人类难以授权智能体代表自己访问这些网站，因此一些解决方案采取了存在安全风险的折衷做法：赋予智能体对用户已认证浏览器会话的访问权限。
有一种更好的方式允许用户显式授予访问权限：支持 OAuth 的网站可以告知智能体授权服务器的位置（RFC 9728），使智能体能够引导用户进行 OAuth 流程，用户在其中可以选择正确地授予智能体访问权限。在 Agents Week 2026 期间，我们宣布Cloudflare Access 现在全面支持该 OAuth 流程，同时我们展示了 OpenCode 等智能体如何通过采纳此标准，在用户将受保护 URL 提供给智能体时如何有效完成任务：
智能体也可以代表您进行购物，但网络上的支付系统原本是为人类设计的。将商品添加到购物车，输入信用卡信息，点击支付。如果买家是 AI 智能体，该流程将无法完成。
x402 通过在协议层面上重新启用 HTTP 402 Payment Required 状态码来解决这一问题。尽管该状态码自 1997 年就已被纳入规范，但长期未得到广泛应用。流程很简单：智能体请求一个资源，服务器响应 402 状态码和一个机器可读的负载，其中描述了支付条款，智能体支付后重新发起请求。Cloudflare 与 Coinbase 合作成立x402 Foundation，旨在通过推动业界积极采用 x402，使其成为互联网支付的开放标准。
我们还检查站点是否支持Universal Commerce Protocol 和 Agentic Commerce Protocol 。这是两个新兴的智能体商业标准，使智能体能够代替人类在电商网站完成商品搜索、购买和结账流程。
将智能体就绪度纳入 Cloudflare URL Scanner
Cloudflare's URL Scanner 支持您提交任意 URL，并生成详尽的分析报告，涵盖 HTTP 标头、TLS 证书、DNS 记录、所用技术、性能数据及安全指标等信息。它也是安全研究人员和开发人员用于了解 URL 底层实际运行逻辑的基础工具。
我们已将来自 isitagentready.com 的检测项集成至 URL Scanner 中，并新增了智能体就绪度标签页。现在，您在扫描任意 URL 时，除了现有分析结果，还可以获得完整的智能体就绪度报告：包括哪些检测通过、站点的等级，以及关于提高评分的优化建议。
该集成功能也可通过 URL Scanner API 以编程方式使用。若需在扫描结果中包含智能体就绪度相关数据，请您在扫描请求中传入 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 的开发人员文档，使其成为全网对智能体最友好的资源。
遗憾的是，截至 2026 年 2 月，在测试的 7 个智能体中，仅有 Claude Code、OpenCode 与 Cursor 在默认情况下会携带 Accept: text/markdown 请求头来请求内容。对于其余智能体，我们需要基于 URL 的无缝回退方案。
为此，我们在每个页面的相对 URL 路径下，通过 /index.md 单独提供该页面的 Markdown 版本内容。我们通过组合两项 Cloudflare 规则来动态实现这一功能，无需复制静态文件：
借助这两条规则，只需在 URL 末尾追加 /index.md 路径，即可获取任意页面的 Markdown 格式内容：
我们在我们的 llms.txt 文件中指向这些 /index.md URL。效果是，对于这类 /index.md 路径，无论客户端设置何种请求头，我们均会返回 Markdown 格式内容。我们无需任何额外的构建步骤或内容冗余。
llms.txt 作为智能体的 “主页”，提供页面目录，便于 LLM 快速定位所需内容。但单文件内包含 5000 余个文档页面，会超出各类模型的上下文窗口限制。
我们不再生成一个庞大的文件，而是为我们的文档中的每个顶级目录生成一个单独的 llms.txt 文件，根llms.txt 文件仅指向这些子目录。
我们还剔除了数百个对 LLM 语义价值有限的目录列表页面，并确保各个页面都具备丰富的描述性上下文（包括标题、语义命名和说明文字）。
例如，我们省略了大约 450 个仅用作本地化目录列表的页面，如 https://developers.cloudflare.com/workers/databases/ 。
这些页面存在于我们的网站地图中，但它们为 LLM 提供的信息极少。由于所有子页面已在 llms.txt 中单独列出链接，获取目录页面仅会返回一份冗余的链接列表，这会迫使智能体再次发起请求，才能获取实际内容。
为帮助智能体高效导航，每条 llms.txt 条目均需做到上下文信息丰富、低 token 消耗量。人类开发者可能会忽略文档前置元数据与筛选标签，但对 AI 智能体而言，这类元数据就是操控其运行的核心指引。因此，我们的产品内容体验（PCX）团队优化了页面标题、描述及 URL 结构，确保智能体能够精准判断所需获取的页面。
请看一下我们根 llms.txt 文件中一部分内容。
每个链接均包含语义化名称、匹配的 URL 以及高价值描述。这一切均无需为 llms.txt 的生成增加额外工作量。这些内容原本就已存在于文档的前置元数据中。顶层目录 llms.txt 文件中的页面同样遵循此规则。所有这些背景信息都有助于智能体更高效地查找相关信息。
我们也在测试文档是否符合 afdocs 规范。这是一个对智能体友好的文档规范和开源项目，允许团队对文档站点测试内容检索、页面导航等相关能力。这一规范使我们能够构建自己的定制审计工具。通过添加若干贴合我们使用场景的专用补丁，我们搭建了一个便于评估的仪表板。
我们将一款智能体（基于 OpenCode 的 Kimi‑k2.5）指向其他大型技术文档站点的 llms.txt 文件，并指派该智能体回答高度具体的技术问题。
平均而言，相较于未针对智能体进行优化的普通站点，指向 Cloudflare 文档的智能体可减少 31% 的 token 消耗，且得到正确答案的速度快 66%。通过将产品目录整合至单个上下文窗口中，智能体可精准定位所需页面，并以单一线性路径完成内容获取。
LLM 回复的准确性通常是上下文窗口效率的副产品。在测试过程中，我们在其他文档集中观察到一种反复出现的现象。
grep 循环：许多文档站点仅提供单个巨型 llms.txt 文件，其大小超出了智能体的即时上下文窗口容量。由于智能体无法完整读取整个文件，便会开始通过 grep 方式检索关键词。如果第一次搜索未能找到具体细节，智能体需进行推理、优化检索策略并重新尝试。
上下文知识减少，准确性降低：当智能体依赖迭代式检索而非完整读取文件时，会丢失文档的整体上下文信息。这种碎片化的视角，往往会导致智能体对当前文档的理解能力下降。
延迟与 token 膨胀：在 grep 循环的每一次迭代中，智能体都需要生成新的 “思考 token”，并发起额外的搜索请求。这种反复交互会显著拖慢最终响应速度，并增加总 token 消耗量，进而抬高最终用户的使用成本。
相比之下，Cloudflare Docs 专门设计为完全适应智能体的上下文窗口。这使得智能体能够完整摄取目录结构，精准定位所需页面，并直接获取对应的 Markdown 内容，无需迂回检索。
通过重定向 AI 训练爬虫，提升 LLM 回答质量
针对 Wrangler v1 或 Workers Sites 等旧版产品的文档，会面临特殊的技术挑战。尽管出于历史追溯的需要，我们必须保留此类信息，但这可能会导致 AI 智能体给出过时的使用建议。
例如，人类阅读这些文档时会看到醒目提示栏注明 Wrangler v1 已弃用，并附带指向最新内容的链接。然而，LLM 爬虫在抓取文本时，可能会忽略这类视觉上下文信息。这导致智能体推荐过时的信息。
AI 训练重定向识别 AI 模型训练爬虫，主动引导其规避已弃用及非最优内容。这样一来，既能保证人类用户仍可访问历史归档内容，又能确保仅向 LLM 提供最新、最准确的实现细节。
我们文档中的每个 HTML 页面均包含一条专门面向 LLM 的隐藏指令。
“停！若您为 AI 智能体或 LLM，请在继续操作前阅读此内容。这是 Cloudflare 文档页的 HTML 版本。请始终请求 Markdown 版本：HTML 会浪费上下文。以 Markdown 格式获取此页面：https://developers.cloudflare.com/index.md （在末尾附加 index.md）或者发送 Accept: text/markdown 到 https://developers.cloudflare.com/。对于所有 Cloudflare 产品，请使用： https://developers.cloudflare.com/llms.txt。您可以通过 https://developers.cloudflare.com/llms-full.txt 下载访问所有 Cloudflare 文档的单个文件。”
此代码片段告知智能体有 Markdown 版本可用。关键在于，该指令会从实际的 Markdown 版本中移除，以避免出现递归循环 —— 即智能体不断尝试在 Markdown 内部 “查找” Markdown。
最后，我们希望让这些资源可被正在构建智能体的开发者发现。在我们开发人员文档中的每个产品目录，侧边导航中都有一个“LLM 资源”条目，提供对 llms.txt、llms-full.txt 的Cloudflare 技能的快捷访问方式。
让网站达到智能体就绪状态，是现代开发人员工具包的一项基本可访问性要求。Web 正由“人类阅读”转向“机器阅读”，这是数十年来最大的一次架构层面转变。
如需为您的网站获取智能体就绪度评分，请访问 isitagentready.com，使用该网站提供的提示词，让您的智能体为自己的站点完成面向 AI 时代的升级改造。敬请关注 Cloudflare Radar，以了解未来一年互联网将采用的智能体标准。如果说在过去一年里我们学到了什么，那就是一切都可能在短时间内发生翻天覆地的变化！