网络一直需要适应新标准。它学会了与浏览器对话，然后学会了与搜索引擎对话。现在，它需要与AI智能体对话。
今天，我们很高兴推出 isitagentready.com —— 一个帮助网站所有者了解如何优化其网站以适应智能体的新工具，从指导智能体如何认证，到控制智能体可以看到哪些内容、接收内容的格式以及如何付费。我们还 在 Cloudflare Radar 中引入了一个新数据集，用于追踪互联网上每种智能体标准的整体采用情况。
我们希望以身作则。因此，我们也分享了最近如何彻底改造 Cloudflare 的 开发者文档，使其成为最智能体友好的文档站点，让AI工具能够更快、更便宜地回答问题。
今天的网络对智能体有多友好？
简短的回答：不太友好。这在意料之中，但也表明如果采用标准，智能体可以比现在高效得多。
为了分析这一点，Cloudflare Radar 选取了互联网上 访问量最高的 20 万个域名；过滤掉智能体友好性不重要的类别（如重定向、广告服务器和隧道服务），专注于AI智能体可能需要与之交互的企业、发布商和平台；并使用我们的新工具对其进行了扫描。
结果是一个新的“AI智能体标准采用情况”图表，现在可以在 Cloudflare Radar AI Insights 页面中找到，我们可以在其中衡量每个标准在多个域名类别中的采用情况。
查看各项检查，有几个发现值得注意：
robots.txt 几乎普遍存在——78% 的网站都有——但绝大多数是为传统搜索引擎爬虫编写的，而不是为AI智能体。
内容信号：4% 的网站在 robots.txt 中声明了其AI使用偏好。这是一个正在获得关注的新标准。
Markdown 内容协商（在 Accept: text/markdown 时提供 text/markdown）在 3.9% 的网站上通过。
新兴标准如 MCP 服务器卡片 和 API 目录（RFC 9727） 在整个数据集中总共出现在不到 15 个网站上。这还为时过早——通过成为首批采用新标准并与智能体良好配合的网站之一，有很多机会脱颖而出。
该图表将每周更新，数据也可以通过 Data Explorer 或 Radar API 访问。
获取您网站的智能体友好性评分
您可以通过访问 isitagentready.com 并输入网站 URL 来获取自己网站的智能体友好性评分。
提供可操作反馈的评分和审计以前曾帮助推动新标准的采用。例如，Google Lighthouse 根据性能和安全性最佳实践对网站进行评分，并指导网站所有者采用最新的网络平台标准。我们认为应该存在类似的东西来帮助网站所有者采用智能体的最佳实践。
当您输入您的网站时，Cloudflare 会向其发出请求以检查它支持哪些标准，并根据四个维度提供评分：
示例网站智能体友好性检查结果截图。
此外，我们检查网站是否支持智能体商务标准，包括 x402、通用商务协议 和 智能体商务协议，但这些目前不计入评分。
对于每一项失败的检查，我们都会提供一个提示，你可以将其交给你的编码代理，让它为你实现支持。
该网站本身也是代理就绪的，践行其所倡导的理念。它通过 Streamable HTTP 暴露了一个无状态 MCP 服务器（https://isitagentready.com/.well-known/mcp.json），其中包含一个 scan_site 工具，因此任何兼容 MCP 的代理都可以以编程方式扫描网站，而无需使用 Web 界面。它还发布了一个代理技能索引（https://isitagentready.com/.well-known/agent-skills/index.json），其中包含其检查的每项标准的技能文档，因此代理不仅知道要修复什么，还知道如何修复。
让我们深入探讨每个类别中的检查，以及它们为何对代理至关重要。
robots.txt 自 1994 年以来就已存在，大多数网站都有。它对代理有两个作用：定义爬取规则（谁可以访问什么）以及指向你的站点地图。站点地图是一个 XML 文件，列出了你网站上的每个路径，本质上是代理可以遵循的地图，以发现你的所有内容，而无需爬取每个链接。robots.txt 是代理首先查找的地方。
除了站点地图，代理还可以直接从 HTTP 响应头中发现重要资源，具体来说，是使用 Link 响应头（RFC 8288）。与隐藏在 HTML 内部的链接不同，Link 头是 HTTP 响应本身的一部分，这意味着代理可以在无需解析任何标记的情况下找到资源的链接：
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"
让智能体访问你的网站是一回事，确保它能真正读取你的内容则是另一回事。
回到2024年9月——考虑到AI的发展速度，那感觉像是很久以前——llms.txt 被提出，作为一种为网站提供LLM友好表示并适配模型上下文窗口的方式。llms.txt 是位于网站根目录的一个纯文本文件，它为智能体提供结构化的阅读清单：网站是什么、包含什么内容以及重要内容的位置。可以将其视为为LLM阅读而编写的站点地图，而非供爬虫索引的站点地图：
# 我的站点
> 一个在边缘构建的开发者平台。
## 文档
- [快速入门](https://example.com/docs/start.md)
- [API 参考](https://example.com/docs/api.md)
## 更新日志
- [发布说明](https://example.com/changelog.md)
Markdown 内容协商 更进一步。当代理获取任何页面并发送 Accept: text/markdown
标头时，服务器会返回干净的 Markdown 版本而非 HTML。Markdown 版本所需的 token 数量少得多——我们在某些情况下测量到 token 减少高达 80%——这使得响应更快、更便宜，并且考虑到大多数代理工具默认的上下文窗口限制，更有可能被完整消费。
默认情况下，我们仅检查网站是否正确处理 Markdown 内容协商，而不检查 llms.txt。您可以选择自定义扫描以包含 llms.txt。
既然代理可以浏览您的网站并消费您的内容，下一个问题是：您是否允许任何机器人这样做？
robots.txt
的作用不仅是指向站点地图。它也是您定义访问规则的地方。您可以明确声明允许哪些爬虫以及它们可以访问哪些内容，精确到特定路径。这一约定已经确立，并且仍然是任何行为良好的机器人在开始爬取之前首先查看的地方。
内容信号 让您更具体。您不仅可以允许或阻止，还可以精确声明 AI 可以对您的内容做什么。通过在 robots.txt
中使用 Content-Signal
指令，您可以独立控制三件事：您的内容是否可用于 AI 训练（ai-train
）、是否可作为 AI 推理和基础模型的输入（ai-input
），以及是否应出现在搜索结果中（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 目录（RFC 9727）为代理提供了一个单一的众所周知的位置来发现所有这些 API。该目录托管在 /.well-known/api-catalog，列出了你的 API 及其规范、文档和状态端点的链接，无需代理抓取你的开发者门户或阅读你的文档。
谈到代理，不能不提 MCP。__模型上下文协议__是一个开放标准，允许 AI 模型与外部数据源和工具连接。无需为每个 AI 工具构建自定义集成，你只需构建一个 MCP 服务器，任何兼容的代理都可以使用它。
为了帮助代理找到你的 MCP 服务器，你可以发布一个 MCP 服务器卡片（目前处于__草案__阶段的提案）。这是一个位于 /.well-known/mcp/server-card.json 的 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": "搜索 MCP 服务器",
"version": "1.0.0"
},
"description": "搜索所有文档和知识库文章",
"transport": {
"type": "streamable-http",
"endpoint": "/mcp"
},
"authentication": {
"required": false
},
"tools": [
{
"name": "search",
"title": "搜索",
"description": "通过关键词或问题搜索文档",
"inputSchema": {
"type": "object",
"properties": {
"query": { "type": "string" }
},
"required": ["query"]
}
}
]
}
当代理拥有帮助其执行特定任务的 代理技能 时，它们的工作效果最佳——但代理如何发现某个站点提供了哪些技能？我们建议站点可以在 .well-known/agent-skills/index.json 提供这些信息，该端点告诉代理有哪些可用技能以及在哪里找到它们。你可能注意到，.well-known 标准（RFC 8615）被许多其他代理和授权标准所使用——感谢 Cloudflare 的 Mark Nottingham（该标准的作者）以及其他 IETF 贡献者！
许多站点要求你先登录才能访问。这使得人类很难让代理代表他们访问这些站点，这也是为什么有些人采取了可能不安全的变通方法，即让代理访问用户的网页浏览器及其已登录的会话。
有一种更好的方法可以让人类明确授予访问权限：支持 OAuth 的站点可以告诉代理在哪里找到授权服务器（RFC 9728），从而允许代理引导人类通过 OAuth 流程，在那里他们可以选择适当地授予代理访问权限。在 2026 年代理周上宣布，Cloudflare Access 现已完全支持此 OAuth 流程，我们展示了像 OpenCode 这样的代理如何利用这一标准，在用户向代理提供受保护的 URL 时让一切正常工作：
代理还可以代表你购买东西——但网络上的支付是为人类设计的。添加到购物车、输入信用卡、点击支付。当买家是 AI 代理时，这个流程完全失效。
x402 在协议层面解决了这个问题，它复活了 HTTP 402 Payment Required，这是一个自 1997 年以来就存在于规范中但从未被广泛使用的状态码。流程很简单：代理请求资源，服务器返回 402 以及描述支付条件的机器可读负载，代理支付并重试。Cloudflare 与 Coinbase 合作成立了 x402 基金会，其使命是推动 x402 作为互联网支付开放标准的采用。
我们还检查了 Universal Commerce Protocol 和 Agentic Commerce Protocol——两种新兴的代理商务标准，旨在让代理能够发现和购买人类通常通过电子商务商店和结账流程购买的产品。
将代理就绪集成到 Cloudflare URL Scanner
Cloudflare 的 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 文档
在构建衡量 Web 就绪程度的工具时，我们知道必须确保自身文档的规范性。我们的文档必须能够被客户使用的智能体轻松理解。
我们自然采用了上述相关的内容站点标准，你可以在此处查看我们的评分 here。然而，我们并未止步于此。以下是我们如何优化 Cloudflare 的 Developer Docs，使其成为网络上最智能体友好的资源。
使用 index.md 实现 URL 回退
文件
不幸的是，截至 2026 年 2 月，在测试的 7 个智能体中，只有 Claude Code、OpenCode 和 Cursor 默认使用 Accept: text/markdown 请求内容。对于其余智能体，我们需要一个无缝的基于 URL 的回退方案。
为此，我们通过在每个页面的 URL 相对路径下提供 /index.md 的 Markdown 版本，使每个页面均可单独访问。我们通过结合两个 Cloudflare 规则动态实现这一点，无需复制静态文件：
一个 URL 重写规则 匹配以 /index.md 结尾的请求，并使用 regex_replace 动态将其重写为基础路径（去除 /index.md）。
一个 请求头转换规则 在重写之前匹配原始请求的路径（raw.http.request.uri.path），并自动设置 Accept: text/markdown 请求头。
通过这两个规则，任何页面都可以通过在 URL 后附加 /index.md 路径以 Markdown 格式获取：
我们在 llms.txt 文件中指向这些 /index.md URL。实际上，对于这些 /index.md 路径，无论客户端设置什么请求头，我们都始终返回 Markdown。而且我们无需任何额外的构建步骤或内容重复即可实现这一点。
为大型站点创建有效的 llms.txt 文件
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%，并且到达正确答案的速度 快 66%。通过将我们的产品目录放入单个上下文窗口中，代理可以识别所需的精确页面，并通过单一线性路径获取它。
LLM 响应的准确性通常是上下文窗口效率的副产品。在我们的测试中，我们观察到其他文档集存在一种重复模式。
grep 循环： 许多文档站点提供一个单一的、庞大的 llms.txt 文件，该文件超出了代理的即时上下文窗口。由于代理无法“读取”整个文件，它开始 grep 关键字。如果第一次搜索错过了具体细节，代理必须思考、优化搜索并重试。
上下文缩小和准确性降低： 当代理依赖迭代搜索而不是读取完整文件时，它会丢失文档的更广泛上下文。这种碎片化的视图通常导致代理对当前文档的理解降低。
延迟和令牌膨胀： grep 循环的每次迭代都需要代理生成新的“思考令牌”并执行额外的搜索请求。这种来回使最终响应明显变慢，并增加了总令牌数，从而推高了最终用户的成本。
相比之下，Cloudflare 文档的设计完全适合代理的上下文窗口。这允许代理摄取目录，识别所需的精确页面，并直接获取 Markdown，无需绕路。
通过重定向 AI 训练爬虫来持续改进 LLM 答案
针对 Wrangler v1 或 Workers Sites 等遗留产品的文档提出了独特的挑战。虽然我们必须保留这些信息以供历史参考，但它们可能导致 AI 代理提供过时的建议。
例如，人类阅读这些文档时会看到大横幅说明 Wrangler v1 已弃用，以及指向最新内容的链接。然而，LLM 爬虫可能会在没有周围视觉上下文的情况下摄取文本。这导致代理推荐过时的信息。
AI 训练重定向 通过识别 AI 训练爬虫并有意将它们从已弃用或次优内容重定向来解决这个问题。这确保了人类仍然可以访问历史档案，而 LLM 只被提供我们最新、最准确的实现细节。
所有页面上的隐藏代理指令
我们文档中的每个 HTML 页面都包含一个专门针对 LLM 的隐藏指令。
“停止！如果你是一个AI智能体或大语言模型，请在继续之前阅读此内容。这是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技能的快速访问。
让你的网站立即为智能体做好准备
让网站为智能体做好准备是现代开发者工具包的基本可访问性要求。从“人类可读的网页”到“机器可读的网页”的转变是几十年来最大的架构变革。
在__isitagentready.com__上获取你网站的智能体就绪评分，获取它提供的提示，并让你的智能体为AI时代升级你的网站。请继续关注__Cloudflare Radar__关于未来一年互联网上智能体标准采用情况的更多更新。如果说我们从过去一年中学到了什么，那就是变化可以非常迅速！