随着 AI 代理（Agent）逐渐从简单的问答工具演变为能够自主执行复杂任务的智能系统，网站与代理之间的交互方式正在发生根本性变化。传统针对人类用户优化的网页架构，在代理看来可能充满了障碍：需要 JavaScript 渲染的动态内容、缺乏机器可读的元数据、分散的 API 文档、模糊的访问权限声明 —— 这些问题直接影响代理能否有效地发现、理解和操作网站资源。Cloudflare 推出的 IsItAgentReady（isitagentready.com）正是为解决这一新兴需求而设计的评估工具，它从五个核心维度对网站的代理就绪程度进行系统化打分，帮助开发者和运维团队量化当前架构与代理友好标准之间的差距。
评估框架的五大维度
IsItAgentReady 采用的评估框架将网站的代理就绪程度划分为五个相互独立又彼此关联的检查类别，每个类别对应代理与网站交互过程中的一个关键阶段。第一维度是 Discoverability（可发现性），考察代理能否通过标准协议发现网站的存在并定位其核心资源，主要检查 robots.txt、sitemap.xml 以及 Link 响应头的有效性。第二维度是 Content Accessibility（内容可访问性），评估网站是否提供机器可读的内容格式，特别是 Cloudflare 推动的 Markdown for Agents 规范能否被正确返回。第三维度是 Bot Access Control（机器人访问控制），检查网站在 robots.txt 中是否明确声明了对不同 AI 爬虫的访问策略，以及是否支持 Content Signals 和 Web Bot Auth 等新兴授权协议。第四维度是 Protocol Discovery（协议发现），这是最为复杂的一个维度，涉及 MCP（Model Context Protocol）Server Card、Agent Skills、WebMCP、API Catalog、OAuth 发现机制以及 OAuth Protected Resource（RFC 9728）等多项标准和协议的暴露情况。第五维度是 Commerce（商业协议），评估网站是否支持 x402（可扩展支付协议）、UCP（统一支付协议）和 ACP（代理商业协议）等面向代理交易的支付标准。
可发现性：爬虫兼容性的工程基础
在代理就绪评估中，可发现性是最为基础但也最容易修复的维度。一个代理在尝试与网站交互时，首先需要确认自己是否有权访问该网站，以及网站的结构和资源分布在何处。如果网站缺少标准的 robots.txt 文件，代理将无法判断哪些路径被允许爬取，哪些区域被明确禁止，这不仅会导致访问被拒，还可能因为误入禁止区域而触发 IP 封禁等防御机制。sitemap.xml 则为代理提供了网站结构的全局视图，使得代理可以在不了解网站内部链接关系的情况下，直接获取所有重要页面的列表，从而大幅降低爬取成本并提高覆盖率。Link 响应头作为 HTTP 层面的补充机制，允许服务器在响应中直接声明相关资源的 URI，代理无需解析 HTML 即可发现关联内容，这对于单页面应用和 API 优先的网站尤为关键。
从工程实践角度，robots.txt 应至少包含对主流 AI 爬虫的明确声明，包括 User-agent: GPTBot、User-agent: Claude-Web、User-agent: Google-Extended 等常见代理的访问规则，同时提供 Sitemap 指向。sitemap.xml 的更新频率应与实际内容发布节奏保持一致，建议使用 lastmod 时间戳标注每个页面的最后修改时间，并合理设置 changefreq 和 priority 属性以指导代理的爬取优先级。对于动态内容较多的站点，Link 响应头的配置通常需要在 CDN 边缘或反向代理层实现，常见的用法包括在分页列表响应中通过 Link: <...>; rel="next" 声明后续页面，以及在 API 响应中通过 Link 头暴露相关资源的端点。
内容可访问性：Markdown 与结构化数据的双轨策略
当代理成功发现并获准访问网站后，下一个挑战在于能否高效地解析和理解内容本身。传统网页以 HTML 为主要载体，其中混杂了样式信息、交互脚本和语义标记，这要求代理具备完整的 DOM 解析能力和上下文理解能力，其成本远高于直接消费结构化文本。Markdown for Agents 是 Cloudflare 联合多家 AI 厂商推出的内容协商标准，其核心理念是允许客户端在请求头中声明对 Markdown 格式的偏好（Accept: text/markdown 或 Accept: text/markdown;version=v1），服务器则据此返回去除样式和脚本干扰的纯内容文档。这一机制与 HTTP 内容协商的经典模式保持一致，使得网站可以在不改变人类用户访问体验的前提下，为代理提供专门的机器可读版本。
在实现层面，网站需要确保 Markdown 格式的响应包含足够的语义信息。标题层级应该使用标准的 # 到 ###### 标记，代码块应标注语言类型以帮助代理识别可执行或可解析的内容片段，表格应使用标准 Markdown 表格语法而非 HTML 表格嵌入。结构化数据的暴露同样是不可或缺的一环，无论是产品信息、评论内容还是组织机构数据，都应该通过 JSON-LD 或 Schema.org 标记进行明确声明。值得注意的是，Google Search Central 对结构化数据的指导原则同样适用于代理场景：缺少必填属性会导致数据项无法被正确解析，而推荐属性的完整填充则能显著提升代理对内容意图的理解准确度。在实际工程中，建议为每个核心内容类型建立结构化数据模板，并在 CI/CD 流程中加入 Schema 验证步骤以防止部署退化。
协议发现：MCP 与 API Catalog 的协同机制
代理就绪评估中最具技术深度的维度是协议发现，它考察的是网站是否向外界暴露了可供代理理解和调用的能力接口。MCP（Model Context Protocol） 是由 Anthropic 主导推出的模型上下文协议，旨在为 AI 模型提供标准化的工具调用和资源访问机制。MCP Server Card 是该协议的核心组件之一，它以机器可读的形式声明了服务器提供的能力列表、每个能力的参数模式以及调用端点，代理可以在无需人工介入的情况下发现并绑定这些能力。类似地，Agent Skills 规范允许网站将自身功能封装为可供代理调用的技能单元，每个技能包含名称、描述、输入参数和输出格式的完整元数据。
API Catalog 是另一个关键的发现机制，它借鉴了 OpenAPI 规范的思想，要求网站在约定的知名路径（well-known location）发布 API 索引文件，该文件列出所有可用的 API 端点并链接到各自的规范文档、状态监控页面和认证说明。这一机制的价值在于，代理不再需要爬取开发者门户站点来发现 API 列表，而是可以直接通过读取索引文件获得完整的接口清单。对于已部署的 RESTful API，建议在 /.well-known/api-catalog.json 路径提供索引，并在其中包含每个端点的路径、HTTP 方法、认证要求和响应格式说明。OAuth 发现机制则遵循 RFC 8414 的规范，通过 /.well-known/oauth-authorization-server 路径暴露授权服务器的配置信息，包括授权端点、令牌端点、支持的授权类型和签名算法等，这对于需要代表用户执行操作的代理尤为重要。
Bot 访问控制与授权机制
可发现性解决的是代理能否找到网站的问题，而 Bot 访问控制解决的是代理能否合法使用网站的问题。当 AI 代理开始批量抓取网站内容时，网站所有者面临的核心困境在于：既要允许合理的代理访问以提升内容分发效率，又需要防止恶意爬虫和无节制的自动化流量耗尽服务器资源。传统的 robots.txt 虽然提供了基础的访问声明机制，但其声明式性质决定了它无法强制执行访问策略。为了弥补这一缺陷，Cloudflare 提出了 Content Signals 和 Web Bot Auth 两个补充方案，前者通过在页面元数据中嵌入特定的机器可读标记来声明内容的授权和许可信息，后者则通过 OAuth 2.0 流程为合法的机器人提供经过验证的身份令牌。
在工程实现层面，建议在 robots.txt 中明确列出允许和禁止的 AI 爬虫，例如在允许爬虫的 User-agent 块中设置合理的 Crawl-delay 指令以控制请求频率，同时在禁止爬虫的块中说明拒绝原因。对于需要更精细控制的场景，可以在 HTTP 响应头中携带 X-Robots-Tag 指令，该指令支持更丰富的访问控制参数，包括索引许可、片段提取权限和归档缓存策略。如果网站希望与特定代理建立长期授权关系，则应实现 Web Bot Auth 流程，为经过认证的代理提供带有访问令牌的自定义请求头或 Cookie，从而在服务器层面实现基于身份的访问控制。
面向代理交易的支付协议
电子商务场景下的代理就绪度是一个相对新颖但增长迅速的关注领域。当代理被授权代表用户执行购买决策时，传统的结账流程可能不再适用：用户不再通过浏览器点击按钮完成支付，而是由代理直接调用支付接口完成资金转移。x402 协议（扩展支付协议）正是为这一场景设计的，它定义了在 HTTP 请求中携带支付指令的标准方式，允许请求方在请求头中声明支付金额、货币类型和收款方信息，接收方则可以据此判断是否接受该支付并提供相应的服务。UCP（统一支付协议） 和 ACP（代理商业协议） 则进一步扩展了支付场景，前者致力于跨平台的支付能力抽象，后者则关注代理在商业交易中的行为规范和信任建立机制。
对于电商网站而言，在支付页面支持 x402 意味着代理可以直接通过 HTTP 请求完成支付而无需模拟浏览器行为，这不仅提升了交易成功率，也降低了中间环节的失败率。从技术角度看，网站需要在相关的 API 端点中检查 X-Pay-Amount、X-Pay-Currency 和 X-Pay-Recipient 等请求头，并根据支付验证结果决定是否返回完整的响应内容或错误提示。目前这些协议仍处于早期采用阶段，但对于预计在接下来一到两年内将代理深度集成到购物体验中的电商平台，现在开始关注并小规模试点将获得显著的先发优势。
工程实践建议与监控要点
基于上述五大评估维度，网站运营者可以采取分阶段的改进策略来提升代理就绪程度。第一阶段的 quick win 包括：部署符合规范且包含 AI 爬虫规则的 robots.txt、生成并定期更新的 sitemap.xml、在 CDN 层面启用 Markdown 内容协商支持。这一阶段的改动通常可以在数小时内完成，而评估分数的提升往往立竿见影。第二阶段应聚焦于结构化数据的完善和 API Catalog 的搭建，为核心内容类型添加完整的 JSON-LD 标记，并在约定路径发布 API 索引。第三阶段则涉及 MCP Server Card 的部署和 OAuth 发现机制的配置，这一阶段的技术复杂度较高，建议从非关键业务端点开始试点。
持续监控是确保代理就绪程度不发生退化的关键手段。建议将 IsItAgentReady 的评估分数纳入 CI/CD 流程中的质量关卡，每次重大部署前自动执行评估检查并在分数低于阈值时触发告警。同时，由于 AI 代理领域的标准演进速度较快，新的协议和能力声明规范可能在未来一到两年内持续出现，定期回顾评估维度的变化并及时调整站点配置将是保持竞争力的必要工作。
资料来源：IsItAgentReady 官方网站（https://isitagentready.com）及其评估维度说明；Cloudflare Blog 关于 Agent Readiness Score 的介绍文章。