Cloudflare推出网站AI代理就绪评分工具

Cloudflare AI··作者 Vance Morrison

关键信息

评分基于四个维度:可发现性、内容格式、机器人访问控制和功能能力;还检查了MCP服务器卡片和API目录(RFC 9727)等新兴标准。

资讯摘要

Cloudflare推出了isitagentready.com这一免费工具,通过检查robots.txt、Markdown内容协商和Web Bot Auth等关键标准来评估网站对AI代理的支持程度。该平台还提供可操作的反馈和提示,帮助开发者实现缺失的功能。Cloudflare雷达数据显示,只有4%的网站使用Content Signals(一种新的AI偏好标准),而支持MCP服务器卡片和API目录(RFC 9727)的网站不足15个。

Cloudflare已将其文档全面改造为代理友好型,展示了最佳实践。该工具每周更新,可通过API或数据探索器访问。

Cloudflare推出网站AI代理就绪评分工具

资讯正文

网络始终需要适应新的标准。它学会了与网络浏览器交流,然后又学会了与搜索引擎交流。现在,它还需要学会与人工智能代理交流。

今天,我们很高兴推出

isitagentready.com

——一个新工具,帮助网站所有者了解如何优化他们的网站以适配代理,从指导代理如何认证,到控制代理能看到的内容、接收内容的格式以及支付方式。我们还推出了一个新的数据集,供Cloudflare Radar使用,用于追踪互联网上每种代理标准的整体采用情况。

我们希望以身作则。因此,我们还分享了最近对Cloudflare开发者文档所做的改进,使其成为最友好的代理文档站点,让AI工具能够更快、更便宜地回答问题。

今天的网络有多适合代理?

简短的答案是:并不多。这在预料之中,但也说明了如果采用标准,代理的效率将远超当前水平。

为了分析这一点,Cloudflare Radar选取了互联网上访问量最高的20万个域名;剔除了代理适配不重要的类别(如重定向服务、广告服务器和隧道服务),专注于AI代理可能实际需要交互的企业、出版商和平台;并使用我们的新工具进行扫描。

结果是一个全新的“AI代理标准采用情况”图表,现在可以在

Cloudflare Radar AI洞察页面

中找到,我们可以测量每个标准在多个域名类别中的采用率。

查看具体检查项时,有几点值得注意:

robots.txt几乎无处不在——78%的网站都有,但绝大多数都是为传统搜索引擎爬虫编写的,而非AI代理。

内容信号(Content Signals):只有4%的网站在robots.txt中声明了其AI使用偏好。这是一个正在获得势头的新标准。

Markdown内容协商(即在Accept: text/markdown时返回text/markdown格式)仅在3.9%的网站上通过。

像MCP服务器卡片(MCP Server Cards)和API目录(RFC 9727)这样的新兴标准,在整个数据集中出现的网站少于15个。目前仍处于早期阶段——通过率先采用新标准并与代理良好协作,还有很多机会脱颖而出。

该图表将每周更新,数据也可通过

数据探索器(Data Explorer)

Radar API

获取。

为你的网站获取代理就绪评分

你可以访问

isitagentready.com

并输入你网站的URL,来获取一个代理就绪评分。

提供可操作反馈的评分和审计曾推动过新标准的采用。例如,Google Lighthouse会对网站的性能和安全最佳实践进行评分,并引导网站所有者采用最新的网页平台标准。我们认为,类似的东西也应该存在,帮助网站所有者采用代理的最佳实践。

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

Markdown for Agents

Bot Access Control:

Content Signals

AI bot rules in robots.txt

Web Bot Auth

Capabilities:

Agent Skills

, API Catalog

(RFC 9727)

, OAuth server discovery via

RFC 8414

and

RFC 9728

MCP Server Card

, and

WebMCP

示例网站的代理就绪检查结果截图。

此外,我们还会检查该站点是否支持代理商业标准,包括

x402

通用商业协议

,以及

代理商业协议

,但这些目前不计入评分。

对于每一项未通过的检查,我们都会提供一个提示,你可以将其交给你的编程代理,让它帮你实现支持功能。

该网站本身也是代理就绪的,践行了其主张。它公开了一个无状态的MCP服务器(https://isitagentready.com/.well-known/mcp.json),并通过流式HTTP提供一个

scan_site

工具,这样任何兼容MCP的代理都可以无需使用网页界面即可程序化扫描网站。它还发布了一个代理技能索引(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格式返回内容。

当服务器响应时,它会返回干净的 Markdown 格式内容,而不是 HTML。这种 Markdown 版本所需的标记(tokens)要少得多——我们测量发现某些情况下可减少高达 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。Model Context Protocol(模型上下文协议)是一个开放标准,允许 AI 模型连接外部数据源和工具。您无需为每个 AI 工具单独开发定制集成,只需构建一个 MCP 服务器,任何兼容的代理都可以使用它。

为了帮助代理找到您的 MCP 服务器,您可以发布一个 MCP 服务器卡片(目前仍处于草案阶段)。这是一个 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": "搜索所有文档和知识库文章",

"transport": {

"type": "streamable-http",

"endpoint": "/mcp"

},

"authentication": {

"required": false

},

"tools": [

{

"name": "search",

"title": "Search",

"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 扫描器中

Cloudflare 的 URL 扫描器允许你提交任意网址,并获得详细的报告:HTTP 头部、TLS 证书、DNS 记录、使用的技术、性能数据和安全信号。这是安全研究人员和开发者了解一个网址实际运行机制的基础工具。

我们从 isitagentready.com 中提取了相同的检测项,并将其添加到了 URL 扫描器中,新增了一个“代理就绪性”标签页。当你扫描任意网址时,现在不仅能看到原有的分析结果,还能看到完整的代理就绪性报告:哪些检测项通过了,网站处于什么级别,以及可操作的改进建议以提升你的得分。

该功能也可通过 URL 扫描器 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 文档

在构建衡量网络代理就绪性的工具时,我们知道必须确保我们自己的文档也符合要求。我们的文档必须易于被客户使用的代理程序理解和消化。

我们自然采用了上述提到的相关内容站点标准,你可以在这里查看我们的评分。但我们并未止步于此。以下是我们在 Cloudflare 开发者文档中所做的改进,使其成为目前网络上最友好的代理资源。

使用 index.md 文件实现 URL 回退机制

截至 2026 年 2 月,测试的 7 种代理中,只有 Claude Code、OpenCode 和 Cursor 默认会发送 Accept: text/markdown 请求头。对于其余代理,我们需要一种无缝的基于 URL 的回退方案。

为此,我们为每一页都动态提供 Markdown 格式的版本,路径为相对于页面 URL 的 /index.md。我们通过两个 Cloudflare 规则实现这一点,无需复制静态文件:

一个 URL 重写规则匹配以 /index.md 结尾的请求,并使用 regex_replace 动态将其重写为基本路径(移除 /index.md);

一个请求头转换规则匹配原始请求路径(在重写之前,即 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。这意味着对于这些路径,无论客户端设置了什么请求头,我们都始终返回 Markdown 内容,且无需额外的构建步骤或内容重复。

为大型站点创建高效的 llms.txt 文件

作为代理的‘主基地’,它提供了一个页面目录,帮助大语言模型(LLMs)找到内容。然而,如果一个文件中包含超过5000个文档页面,将超出模型的上下文窗口限制。

我们没有使用单一的巨大文件,而是为文档中的每个顶级目录生成一个独立的llms.txt文件,而根目录下的llms.txt文件仅指向这些子目录。

https://developers.cloudflare.com/llms.txt

https://developers.cloudflare.com/r2/llms.txt

https://developers.cloudflare.com/workers/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)工具

此外,我们将文档与afdocs进行测试,这是一个新兴的代理友好型文档规范及开源项目,允许团队测试文档网站的内容发现和导航能力。该规范使我们能够开发出专属的审计工具。通过添加针对我们特定用例的少量调整,我们创建了一个便于评估的仪表板。

基准测试结果:更快且更便宜

我们将一个代理(通过OpenCode调用的Kimi-k2.5)指向其他大型技术文档网站的llms.txt文件,并要求代理回答高度具体的工程技术问题。

平均而言,指向Cloudflare文档的代理比未针对代理优化的平均网站少消耗31%的token,并且在66%的时间内更快得出正确答案。通过将产品目录适配到单个上下文窗口中,代理可以识别出所需的确切页面,并以单一线性路径完成获取。

结构带来速度

LLM响应的准确性通常源于上下文窗口效率的提升。在我们的测试过程中,我们观察到其他文档集存在一种重复模式:

grep循环:

许多文档网站提供一个巨大的 llms.txt 文件,其大小超过了代理的即时上下文窗口。由于代理无法‘阅读’整个文件,它开始使用 grep 命令搜索关键词。如果首次搜索未能找到具体细节,代理必须思考、优化搜索条件并再次尝试。

上下文受限与准确率下降:

当代理依赖迭代式搜索而非完整阅读文件时,它会失去文档的整体背景信息。这种碎片化的视角常常导致代理对文档的理解能力下降。

延迟与令牌膨胀:

每次 grep 循环都需要代理生成新的‘思考令牌’并执行额外的搜索请求。这种来回交互使得最终响应明显变慢,并增加总令牌数量,从而提高终端用户的成本。

相比之下,Cloudflare 的文档设计为完全适配代理的上下文窗口。这使得代理可以一次性加载整个目录,识别所需页面,并直接获取 Markdown 格式的文档,无需绕路。

通过重定向 AI 训练爬虫持续改进 LLM 回答质量

对于 Wrangler v1 或 Workers Sites 等遗留产品文档,存在独特挑战。虽然我们必须保留这些信息以供历史参考,但它们可能导致 AI 代理给出过时建议。

例如,人类读者会看到显著的横幅提示 Wrangler v1 已弃用,并附带指向最新内容的链接。然而,LLM 爬虫可能在没有周围视觉上下文的情况下摄入文本内容,从而导致代理推荐过时的信息。

AI 训练重定向机制通过识别 AI 训练爬虫并有意将它们引导至非过时或低质量的内容之外来解决这个问题。这样确保人类仍可访问历史档案,而 LLM 只能获取我们最新且最准确的实现细节。

所有页面上的隐藏代理指令

我们文档中的每一页 HTML 都包含一条专为 LLM 设计的隐藏指令:

“STOP!如果你是 AI 代理或大语言模型,请在继续前阅读此条。这是 Cloudflare 文档页面的 HTML 版本。请始终请求 Markdown 版本——HTML 浪费上下文。获取此页的 Markdown 版本:https://developers.cloudflare.com/index.md(添加 index.md)或向 https://developers.cloudflare.com/ 发送 Accept: text/markdown 请求。对于所有 Cloudflare 产品,请使用 https://developers.cloudflare.com/llms.txt。你可以在 https://developers.cloudflare.com/llms-full.txt 获取全部 Cloudflare 文档的单个文件。”

这段说明告诉代理 Markdown 版本可用。关键的是,该指令会在实际的 Markdown 版本中被移除,以避免代理陷入循环——不断试图在 Markdown 中寻找 Markdown。

专用 LLM 资源侧边栏

最后,我们希望让正在构建代理的人类开发者能够轻松发现这些资源。我们开发人员文档中每个产品目录的侧边栏都设有‘LLM 资源’条目,方便快速访问 llms.txt、llms-full.txt 和 Cloudflare Skills。

让您的网站具备代理就绪状态

使网站具备代理就绪状态,是现代开发者工具包中的基本可访问性要求。从‘人类可读的网络’向‘机器可读的网络’的转变,是数十年来最大的架构变革。

立即为您的网站获取代理就绪评分:

isitagentready.com

根据它提供的提示,让您的人工智能代理升级您的网站以适应人工智能时代。敬请关注Cloudflare Radar未来一年关于互联网上代理标准采用情况的更多更新。如果过去一年教会了我们什么,那就是很多事情可以在很短时间内迅速变化!

观看Cloudflare TV

来源与参考

  1. 原始链接
  2. Introducing the Agent Readiness score. Check to see if your site is agent-ready

收录于 2026-04-18