浏览器时代，网站学会了对人说话；搜索引擎时代，网站学会了对爬虫说话；现在，网站需要学会对 AI Agent 说话。但绝大多数网站，还没开始学。
一、第三次范式迁移
网络一直在适应新标准。它学会了向浏览器说话，然后学会了向搜索引擎说话。现在，它需要学会向 AI Agent 说话。
这不是比喻意义上的"适应"，而是具体的、可测量的技术标准差距。Cloudflare 为此推出了 isitagentready.com，以及一套追踪全球 Agent 标准采用率的公开数据集。
二、现状：Web 的 Agent 就绪程度有多低
Cloudflare Radar 抓取了互联网上访问量最高的 20 万个域名，过滤掉重定向、广告服务器、隧道服务等 Agent 可达性不重要的类别，聚焦于 AI Agent 实际可能需要交互的企业、出版商和平台，并用新工具对它们进行了扫描。
扫描结果并不乐观：
robots.txt 几乎无处不在------78% 的网站都有，但绝大多数是为传统搜索引擎爬虫写的，并非为 AI Agent 写的。Content Signals（声明 AI 使用权限的新标准）只有 4% 的网站采用。Markdown 内容协商（在收到 Accept: text/markdown 请求头时返回 Markdown 版本）只有 3.9% 的网站支持。MCP Server Card 和 API Catalog（RFC 9727）这类新兴标准，在整个数据集中合计出现在不到 15 个网站上。
这组数字的另一面是机会：现在采用这些标准，就是在 Agent 生态竞争的早期阶段建立先发优势。
三、isitagentready.com：给你的网站打分
评分工具参考了 Google Lighthouse 的思路------通过可操作的审计报告来驱动新标准的采用。你输入网站 URL，Cloudflare 向它发起请求，检查支持哪些标准，并从四个维度给出评分：可发现性、内容可访问性、Bot 访问控制、能力发现。
对于每一项不通过的检查，工具还会生成一段现成的 Prompt，你可以直接交给自己的编程 Agent，让它帮你实现对应的标准支持。
四、维度一：可发现性
robots.txt 自 1994 年就存在，大多数网站都有。它对 Agent 有两个作用：定义爬取规则（谁能访问什么），以及指向你的 sitemap。sitemap 是一个列出网站所有路径的 XML 文件，相当于一张地图，让 Agent 能够发现全部内容，而不必逐一爬取每个链接。robots.txt 是 Agent 首先查看的地方。
除了 sitemap，Agent 还可以通过 HTTP 响应头直接发现重要资源，具体是使用 Link 响应头（RFC 8288）：
javascript
HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"与埋在 HTML 里的链接不同，Link 头是 HTTP 响应本身的一部分，这意味着 Agent 无需解析任何标记就能找到资源链接。
五、维度二：内容可访问性
llms.txt：为 LLM 写的站点地图
llms.txt 是网站根目录下的一个纯文本文件，为 Agent 提供一份结构化的阅读清单：网站是什么、有什么内容、重要内容在哪里。把它理解为一张为 LLM 阅读而写的 sitemap，而不是为爬虫索引而写的。
markdown
# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md "Getting Started")
- [API Reference](https://example.com/docs/api.md "API Reference")Markdown 内容协商：最高节省 80% Token
Markdown 内容协商更进一步。当 Agent 获取任意页面并发送 Accept: text/markdown 请求头时，服务器响应干净的 Markdown 版本而非 HTML。Markdown 版本所需的 Token 远少于 HTML------在某些情况下测量到高达 80% 的 Token 减少------这使响应更快、更便宜，也更容易被完整消费，考虑到大多数 Agent 工具默认设置的上下文窗口限制。
Token 的节省直接转化为成本和速度的双重收益，这对于需要处理大量文档的 Agent 来说是实质性的改善。
六、维度三：Bot 访问控制
Content Signals：精细声明 AI 使用权限
Content Signals 让你更精确地声明意图。不只是允许或屏蔽，你可以明确声明 AI 能对你的内容做什么。在 robots.txt 中使用 Content-Signal 指令，可以独立控制三件事：内容是否可用于 AI 训练（ai-train）、是否可用作推理和知识接地的 AI 输入（ai-input）、是否应出现在搜索结果中（search）。
ini
User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes三个开关相互独立，可以组合出任意策略------允许 Agent 使用你的内容做问答，但不允许用于训练；允许搜索索引，但拒绝 AI 输入。
Web Bot Auth：让友好 Bot 能证明身份
Web Bot Auth IETF 草案标准允许友好 Bot 对自己进行身份验证，并允许接收 Bot 请求的网站识别它们。Bot 对 HTTP 请求进行签名，接收方网站使用 Bot 发布的公钥验证这些签名。这些公钥位于 /.well-known/http-message-signatures-directory 这个知名端点。
并非所有网站都需要实现这一点。如果你的网站只是提供内容，不向其他网站发起请求，就不需要它。但随着越来越多的网站运行自己的 Agent 向其他网站发起请求，预计这一标准会越来越重要。
七、维度四：能力发现
API Catalog（RFC 9727）
如果你的服务有一个或多个公开 API，API Catalog（RFC 9727）为 Agent 提供一个单一的知名位置来发现所有这些 API。托管在 /.well-known/api-catalog，它列出你的 API，并链接到其规范、文档和状态端点，无需 Agent 爬取你的开发者门户或阅读文档。
MCP Server Card
MCP Server Card 是一个 JSON 文件，位于 /.well-known/mcp/server-card.json，在 Agent 连接之前就描述你的服务器：它暴露哪些工具、如何访问、如何认证。Agent 读取这个文件就能知道开始使用你的服务器所需的一切信息。
Agent Skills 与 OAuth 授权发现
Cloudflare 提议网站可以在 .well-known/agent-skills/index.json 端点发布 Agent 技能索引，告知 Agent 哪些技能可用以及在哪里可以找到它们。
许多网站需要先登录才能访问。支持 OAuth 的网站可以告知 Agent 在哪里找到授权服务器（RFC 9728），允许 Agent 引导用户完成 OAuth 流程，让用户选择正式授权 Agent 访问------而不是让 Agent 拿着用户的浏览器会话去操作。
八、附加检查：Agentic Commerce
Agent 也可以代你购买东西------但网络上的支付流程是为人类设计的。加入购物车、填写信用卡、点击支付，这套流程在买家是 AI 时完全行不通。
x402 在协议层解决这个问题，方法是复活 HTTP 402（需要付款）状态码------这个状态码自 1997 年就在规范里，但从未被广泛使用。流程很简单：Agent 请求一个资源，服务器以 402 响应并附上描述支付条款的机器可读载荷，Agent 完成支付后重试。
isitagentready.com 同时检查 UCP（Universal Commerce Protocol）和 ACP（Agentic Commerce Protocol）两个新兴标准，但目前这三项商务标准不计入总分。
九、集成进 Cloudflare URL Scanner
Cloudflare 将 isitagentready.com 的同一套检查加入了 URL Scanner，新增了一个 Agent Readiness 标签页。当你扫描任意 URL 时，现在可以看到其完整的 Agent 就绪报告，以及通过 API 以编程方式获取这些数据。
bash
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 自己怎么做：开发者文档的 Agent 化改造
说完工具，再看 Cloudflare 如何在自己的开发者文档上实践这些标准，以及改造后带来了哪些可测量的收益。
/index.md：动态返回 Markdown，不增加构建成本
截至 2026 年 2 月，测试的 7 个 Agent 中只有 Claude Code、OpenCode 和 Cursor 默认发送 Accept: text/markdown 请求头。对于其余的，需要一个基于 URL 的无缝降级方案。
Cloudflare 通过两条规则实现：URL 重写规则将以 /index.md 结尾的请求动态重写为基础路径；请求头转换规则在重写之前匹配原始请求路径，自动设置 Accept: text/markdown 请求头。这样，任意页面都可以通过在 URL 后附加 /index.md 以 Markdown 格式获取，无需额外构建步骤，无需内容重复。
分级 llms.txt：避免超出上下文窗口
5000 多个文档页面放在一个文件里会超出模型的上下文窗口。Cloudflare 的方案是：为每个顶级目录单独生成一个 llms.txt 文件，根目录的 llms.txt 只指向这些子目录。同时删除了约 450 个对 LLM 几乎没有语义价值的目录列表页，因为这些页面只是链接列表，Agent 还需要再发一次请求才能找到实际内容。
页面内嵌隐藏指令
开发者文档的每个 HTML 页面都包含一段专门针对 LLM 的隐藏指令，大意是：如果你是 AI Agent，请不要读 HTML 版本，HTML 浪费上下文，请改用 Markdown 版本，并告知 Markdown 的访问方式。这段指令会从 Markdown 版本中剥离，以避免递归循环。
AI Training 重定向：不让 LLM 吃过时文档
对于 Wrangler v1 等历史遗留产品的文档，Cloudflare 启用了 Redirects for AI Training，识别 AI 训练爬虫并将它们从废弃内容定向引导到最新文档，确保人类仍然可以访问历史存档，而 LLM 只被喂给当前准确的实现细节。
基准测试：少 31% Token，快 66%
Cloudflare 将一个 Agent（Kimi-k2.5，通过 OpenCode）分别指向 Cloudflare 和其他大型技术文档站点的 llms.txt 文件，让 Agent 回答高度具体的技术问题。平均而言，指向 Cloudflare 文档的 Agent 消耗的 Token 减少了 31%，得出正确答案的速度快了 66%。
背后的逻辑是清晰的：许多文档站点提供一个超出 Agent 即时上下文窗口的单一巨型 llms.txt 文件，导致 Agent 开始逐关键词 grep。每次搜索失败，Agent 就需要重新思考、精化搜索词、再次尝试。这种碎片化的方式不仅慢，还让 Agent 失去了对文档整体结构的理解，准确性随之下降。而 Cloudflare 的文档设计为完全适配 Agent 的上下文窗口，让 Agent 能摄取目录、定位所需页面、一次性完成 Markdown 获取，没有任何绕路。
十一、总结
让网站对 Agent 友好，是现代开发者工具包的基本可访问性要求。从"人类可读的网络"到"机器可读的网络"的过渡，是几十年来最大的架构转变。
这篇文章涉及的标准数量不少，但核心逻辑只有一条：Agent 不是更聪明的浏览器，它们需要不同的接口。robots.txt 告诉它能去哪里，llms.txt 告诉它内容在哪，Markdown 协商让它少花 Token，MCP Server Card 告诉它能做什么，Content Signals 告诉它能用这些内容做什么。
这些标准目前采用率还极低，这意味着现在采用的成本低、先发优势明显。可以从 isitagentready.com 查看自己网站的当前评分，并借助工具生成的 Prompt 让 Agent 帮你完成改造。