API 文档 AI 就绪度评分标准 — 28 项
AgentFit 会对每个已审计的站点按 28 项标准打分，这些标准归为六大类，满分共 100 分。每项标准都有明确的规范：审计检查什么、评分档位如何对应分值，以及一行用于补齐差距的提示。该规范是确定性的，并在 Go 代码中完整复刻。 阅读方法论文章了解整体思路。
除 28 项计分标准外，AgentFit 还会呈现一些新兴信号，例如 WebMCP 支持情况和 MCP 服务器检测。 WebMCP · MCP.
本页内容
AI 就绪度到底指什么
智能体是通过 HTTP 读你的文档的，而不是在有人操作的浏览器里读。它不执行你的 JavaScript，不滚动页面，不会把鼠标悬停在标签上以展开端点列表，也不会去问同事速率限制是多少。它发起请求、解析响应，然后要么找到一份可用的契约，要么放弃并靠猜。AI 就绪度衡量的就是这条路径中机器能独立走完的比例。
它之所以可测量，是因为这条路径上的每一步都是可观察的 HTTP 事实：/llms.txt 是否存在、是否能解析；页面是否带有绝对 canonical 地址；OpenAPI 文档是否有效、是否描述了响应模式；在任何脚本运行之前返回的原始 HTML 里，是否已经包含方法、路径和一个可用示例。这些都不需要判断文字写得好不好。AgentFit 检查 28 项这样的事实，并逐项报告它看到了什么，附上抓取的 URL 和作为证据的片段。
分数是怎么算出来的
28 项标准每一项都有一套整数档位和一个权重。每项标准返回一个状态——存在、部分、缺失、不适用或错误——以及一个介于零和其权重之间的分值。28 个分值汇总为六大类，合计正好 100 分。「不适用」和「错误」都记零分，但刻意分开标注：「我们没能测到」和「它不存在」不是同一个论断，把两者混为一谈，会让一次被拦截的抓取冒充成一项检测结论。
权重不是编辑口味。每一个权重都来自在计算数字之前就写下的规则：当一项标准能区分在其余部分打成平手的站点时，它获得权重；当它的得分主要由站点所用的文档平台决定时，它失去权重。因为选了某家文档托管而拿到的分，说明的是你的托管，而不是你的文档。规则、指标和最终权重向量都在校准运行之前提交进了仓库；提交顺序就是审计轨迹，而同一套流程曾经否掉过它作者自己的假设。
审计是确定性的：同一个站点抓两次，产出的 JSON 逐字节相同。评分过程中不运行任何语言模型——两个用于示例真实性和端点完整性的小型分类器被编译进二进制并与其一同版本化，因此一次重新训练不可能悄悄改变你的分数。当尺子本身发生变化时，评分标准的版本号会提升并盖在该次运行上；用不同版本评出的两次运行，系统会拒绝比较，而不是把我们换尺子说成你的站点发生了变化。
各类别权重。第三列是该类别替你回答的问题。
| 类别 | 权重 | 回答什么问题 |
|---|---|---|
| A — 可发现性 | 14 | 智能体能否在可预测的 URL 上找到你的文档？ |
| B — 页面要素 | 21 | 解析器能否直接读取每个页面的内容？ |
| C — API 契约 | 17 | API 契约是否以机器可读的规范形式发布？ |
| D — 内容 | 23 | 每个端点页面是否携带足够的上下文以供使用？ |
| E — 渲染与卫生 | 21 | 站点在没有 JavaScript 的情况下是否稳定且可用？ |
| F — 代理能力 | 4 | 站点是否暴露面向智能体的接口（llms.txt、WebMCP、MCP、可访问性）？ |
A — 可发现性 · 14/100
智能体能否在可预测的 URL 上找到你的文档？
可发现性涵盖智能体在读到第一页文档之前能找到的一切：主机根目录下的 /llms.txt 索引、全文聚合的 /llms-full.txt、对 AI 爬虫表明明确立场的 robots.txt、列出真实页面而非标签归档的 sitemap，以及首页上指向 markdown 副本的标签。这是整张记分板上最便宜的一类——其中每个产物都是构建时生成的静态文件——却也是最常被留空的一类。
A1 · 主机根目录下的 llms.txt 符合 llmstxt.org 规范
智能体（以及初次接触站点的人）需要一份单一、可预期的索引来定位文档所在位置。/llms.txt 正是 Anthropic 与 llmstxt.org 社区共同提出的约定：在主机根目录放置一个 Markdown 文件，给出文档地图。
评分。 2 = 含 H1 + ≥1 个 H2 + ≥3 条链接，且全部可正常访问 · 1 = 任意带 H1 的文件（若链接无法访问，则从 2 降级）· 0 = 缺失或仅为 HTML 外壳。
改进。 在主机根目录发布 /llms.txt，包含一个 `# H1` 标题、若干 `## H2` 小节标题，以及至少三条指向具体文档页面的 Markdown 列表链接。规范详见 https://llmstxt.org 。
A2 · 存在 llms-full.txt 或按小节拆分的 LLM 聚合文件
/llms-full.txt 是把文档全文汇总到一处的导出文件——大语言模型智能体更愿意直接读它，而非爬取 200 个 HTML 页面。按小节拆分的变体（如 /llms-api.txt 等）同样有效。
评分。 3 = 主机根目录下存在 /llms-full.txt 且大于 1 KB · 2 = 通过 llms.txt 发现按小节拆分的聚合文件 · 0 = 两者皆无，或 /llms-full.txt 仅为 SPA 外壳。
改进。 在构建时生成 /llms-full.txt（mkdocs、docusaurus 均有相应插件），并以 text/plain 提供。文件应控制在 100 MB 以内，以便智能体无需流式传输即可获取。
A3 · robots.txt 声明了 AI 爬虫策略与绝对路径的 Sitemap
每个 AI 爬虫（GPTBot、ClaudeBot、Google-Extended、PerplexityBot、CCBot）在抓取前都会先读取 /robots.txt。为各 UA 显式声明 Allow/Disallow，再加上一条绝对路径的 `Sitemap:` 指令，就能消除关于是否索引以及索引哪些内容的歧义。
评分。 3 = 同时含显式 AI 爬虫 UA 指令与绝对路径的 Sitemap: 行 · 2 = 仅含 AI 爬虫指令 · 1 = 仅含绝对路径的 Sitemap · 0 = 两者皆无，或返回 404。
改进。 为每个主流 LLM 爬虫加上 `User-agent: GPTBot\nAllow: /`（或按策略改用 Disallow），并补一行 `Sitemap: https://example.com/sitemap.xml`。Cloudflare 的 `Content-Signal:` 指令同样计入。
A4 · sitemap.xml 格式规范、使用绝对 URL、分类噪声低
站点地图告诉爬虫该索引什么、内容多久变更一次。一个格式规范的 `<urlset>`，其中各页面均使用绝对路径的 `<loc>` URL，表明覆盖范围真实可信；而只有一个 URL 的占位文件（或 70% 以上都是 /tag/、/category/ 噪声的文件）则提供不了任何信号。
评分。 3 = 格式规范 + ≥3 条不同路径 + 分类垃圾占比 <30% · 2 = 过于单薄（<3 条路径）或垃圾占比 30-70% · 1 = 仅格式规范 · 0 = 404 或解析错误。
改进。 在构建时生成 /sitemap.xml，将每个文档页面以绝对 URL 写入 `<loc>`，并排除 /tag/、/category/、/author/、/page= 等变体。再在 robots.txt 中用一行绝对路径的 `Sitemap:` 引用它。
A5 · 首页发现标签：Markdown 备用版本 + OpenGraph
发现标签让智能体无需额外探测即可找到页面的 Markdown 版本，而 OpenGraph 则能把分享出去的文档链接在 Slack、Discord、Twitter 上渲染成富预览。两者都表明站点对机器消费者有所考量。
评分。 2 = 含 `<link rel=alternate type=text/markdown>` + ≥3 个不同的 `og:` 属性 · 1 = 仅有 Markdown 备用版本，或仅有 OpenGraph · 0 = 两者皆无。
改进。 在 canonical 链接旁加上 `<link rel="alternate" type="text/markdown" href="/page.md">`，并确保首页设置了 `og:title`、`og:description`、`og:image`（至少 3 个属性）。
B — 页面要素 · 21/100
解析器能否直接读取每个页面的内容？
页面构件决定了单个页面能否被无歧义地摄取：以 .md 或 Accept: text/markdown 提供的干净 markdown 副本、可解析且声明了类型的 JSON-LD、绝对 canonical 地址、机器可读的修改日期，以及标明内容在哪里结束、导航从哪里开始的 main 或 article 元素。智能体依据 canonical 去重，依据日期决定重新抓取什么；没有这些信号，你的页面对它而言只是一堵无差别的 div 墙。
B1 · 文档页面的 .md 配套版本返回干净的 Markdown
为读文档而浏览 200 个 HTML 页面，对人来说尚可接受；但对智能体而言，这是数量级的分词开销。为每个页面提供一个 Markdown 孪生版本，可让智能体只拉取正文内容。
评分。 7 = 抽样的 3 个页面中 3 个都有可用的 .md 孪生版本 · 4 = 2/3 · 2 = 1/3 · 0 = 0/3。
改进。 在每个 HTML 页面旁提供 `{page}.md`（或 `{page}/index.md`），或者支持 `Accept: text/markdown` 内容协商并返回 `Content-Type: text/markdown`。mkdocs-material 与 docusaurus 均有相应插件。
B2 · 首页与样本文档页含带有效 @type 的 JSON-LD
JSON-LD 是兼容 schema.org 的方式，用来声明“本页面是一篇 Article”/“本产品是一个 SoftwareApplication”。搜索引擎、智能体和结构化数据提取器都依赖它。
评分。 4 = 首页与某个样本文档页“同时”含可解析、带 `@type` 的 JSON-LD · 3 = 两者之一 · 0 = 都没有。
改进。 在每个文档页面嵌入 `<script type="application/ld+json">{"@context":"https://schema.org","@type":"TechArticle",...}</script>`。首页则适合用 `WebApplication` 类型。
B3 · 首页与样本页含绝对路径的 <link rel=canonical>
canonical 链接能确定性地回答“这是 http 还是 https 版本？带不带末尾斜杠？带不带查询参数？”的问题。缺了它，智能体可能把同一份内容索引到多个 URL 之下。
评分。 3 = 首页与某个样本页“同时”含绝对路径的 canonical · 2 = 仅首页有 · 1 = 存在但为相对路径 · 0 = 缺失。
改进。 在每个页面的 `<head>` 中加上 `<link rel="canonical" href="https://example.com/page">`。URL 必须包含协议和主机名（相对路径的 canonical 虽是合法 HTML，但对跨主机的智能体而言失去了意义）。
B4 · 新鲜度：dateModified（JSON-LD）或 Last-Modified 头
对于不声明最后更新时间的文档，智能体（和搜索引擎）会降低信任度。一个 2019 年的文档页面如果没有任何新鲜度信号，就和昨天才更新的页面没有区别。
评分。 2 = 存在 JSON-LD 的 `dateModified` 或 HTTP `Last-Modified` 头 · 0 = 两者皆无。
改进。 要么在 JSON-LD 块中加入 `"dateModified": "2026-05-28"`，要么让 CDN/服务器发出 `Last-Modified` HTTP 头。大多数静态站点生成器在构建时套用模板即可免费做到这一点。
B5 · 机器可读的分类法（关键词、标签、类别）
打了标签的文档可帮助智能体在不解析全文的情况下进行筛选（如“给我看与鉴权相关的页面”）。`<meta name="keywords">`、JSON-LD 的 `keywords`，或形如 `/tags/` 的 URL 都算数。
评分。 2 = 至少存在一种分类法信号（meta keywords、JSON-LD keywords，或 /tags|/categories|/topics/ 风格的链接模式）· 0 = 都没有。
改进。 为每个页面加上 `<meta name="keywords" content="api,auth,oauth">`，或在 JSON-LD 中加入 `keywords` 数组，或将内容组织到 `/topics/`、`/tags/` 等 URL 前缀之下。
B6 · 用 <main> 或 <article> 包裹主体正文内容
语义化的 HTML5 包裹元素让智能体（和屏幕阅读器）能剥离导航、页脚、侧边栏，只读文档正文。如果页面正文全是 `<div>`，就只能靠猜了。
评分。 2 = `<main>` 内文本 >200 字符且 `<article>` 内文本 >100 字符 · 1 = 仅有 `<main>`，或仅有 `<article>` · 0 = 两者皆无。
改进。 用 `<main>` 包裹页面的主体正文（单个文档页面可用 `<article>`）。不要拿它们去包侧边栏或导航——这些标签是给真正的内容用的。
C — API 契约 · 17/100
API 契约是否以机器可读的规范形式发布？
API 契约这一类只问一件事：是否存在一份智能体能找到且可以信赖的规范。C1 是整套标准中最重的一项，8 分，拆成「在可发现的 URL 上找到该文档」和「它是带 info、路径和响应模式的有效 OpenAPI 3.x」两半。这样拆是有意为之：文件存在却不描述返回什么，只算半份契约。一份有效规范比任何一页散文都值钱，因为客户端、测试套件和工具定义都能由它生成，完全不必读文档。
C1 · OpenAPI / Swagger / AsyncAPI 规范 — 已发现且有效
OpenAPI 规范是 REST API 的首要机器可读契约：找到有效规范的代理无需读取 HTML 即可生成客户端、测试和准确文档。v3 将发现与有效性合并为一个条目。
评分。 8 = 有效的 OpenAPI 3.x（info、≥1 个 path、≥30% 操作带响应模式）· 3 = 在可达 URL 找到规范但非有效 3.x（含 Swagger 2.0）· 0 = 无 · error 表示首页抓取失败。
改进。 在主机根目录发布 `/openapi.json` 或 `/openapi.yaml`（或通过 RFC 9727 api-catalog `service-doc` 声明）。将其升级为 OpenAPI 3.x 并为每个操作提供 `responses` 模式——这样才能拿满 8 分。
C2 · 可发现下载/fork 的 Postman 集合或 SDK
OpenAPI 规范让智能体能生成客户端；而精心整理的 Postman 集合或预构建的 SDK 能让“人”在 30 秒内试用 API。两者都体现了对开发者体验的投入。
评分。 4 = 含 Postman 集合链接且有 ≥1 个 SDK 仓库链接 · 3 = 含 Postman 或 ≥2 个 SDK 链接 · 2 = 1 个 SDK 链接 · 0 = 什么都没有。
改进。 发布一个指向 god.gw.postman.com/run-collection 的“Run in Postman”按钮，并在文档首页直接链接到至少一个来自 npm/PyPI/RubyGems 等的官方 SDK。
C3 · 端点页面展示方法、URL、类型、是否必填及示例
一个只写着“调用 /users”的文档页面毫无用处——缺了方法、参数类型、必填字段，以及示例请求/响应。智能体（和人）需要这五样齐全才能发起一次可用的调用。
评分。 5 = 抽样页面中多数被 ML 模型判定为 `complete` · 3 = 多数为 `partial`（或 2 个 complete + 1 个 absent）· 1 = 多数为 `absent` · 0 = 未找到候选页面。
改进。 在每个端点页面包含：HTTP 方法 + 路径、带类型和必填标记的参数表、一个 curl 示例，以及一个带状态码的 JSON 响应示例。Markdown 风格的参数表和 `<pre>` JSON 块能被清晰地分类识别。
D — 内容 · 23/100
每个端点页面是否携带足够的上下文以供使用？
内容是最大的一类，也是唯一无法靠改配置文件解决的一类。它检查端点页面是否带有不止一种语言的可运行示例，这些示例用的值是否像真实数据而不是 foo 和 example.com，错误是否按错误码和成因编成目录，认证与速率限制是否有文档，以及同一个概念在全站是否始终用同一个名字。智能体的回答以你的示例为依据；充满占位符的代码片段会被原样抄进生成的代码里。
D1 · 代码示例同时包含 curl 与至少一种语言 SDK
curl 示例普遍可被直接测试；SDK 示例则展示地道的用法。两者结合，既满足“能不能快速试一下？”的需求，也满足“我该如何集成？”的需求。
评分。 4 = 至少 1 个页面同时含 curl 与语言 SDK 代码块 · 2 = 仅有 curl · 1 = 仅有 SDK · 0 = 两者皆无。
改进。 为每个端点加一个分页签的代码块，至少包含 curl 与你最常用的 SDK 语言（Python 或 JavaScript）。使用 `<code class="language-python">` 或 `language-bash`，让语法高亮器和我们的分类器都能识别。
D2 · 示例贴近真实（而非 foo/bar/example.com）
`/users/{id}` 配上 `id = 1`、`email = [email protected]`，会迫使读者去想象真实数据长什么样。贴近真实的占位值（如 `[email protected]`、`org_2N5x...`）能降低使用阻力，也能避免直接从文档复制粘贴而出错。
评分。 4 = ML 模型判定占位符密集的代码块 <20% · 3 = 20-40% · 2 = 40-60% · 1 = 60-80% · 0 = >80% 或没有代码块。
改进。 把 `foo`/`bar`/`example.com`/`your_api_key`/`<string>` 替换为看起来真实的值（如 Stripe 的 `pk_test_51N5...`、Twilio 的 `+14155552671`）。不要使用真实的客户数据——但要模仿其形态。
D3 · 错误目录：含 HTTP 状态码 + 原因说明
当集成在凌晨 3 点出故障时，开发者需要在不提工单的情况下弄清 `403 - resource_not_owned` 到底意味着什么。一个专门的错误参考页面，决定了这是一次 5 分钟的修复还是半小时的调试。
评分。 3 = 专门的错误页面（≥3 个状态码并附说明）· 1 = 错误码散落在各页面内联记录 · 0 = 没有。
改进。 发布 `/errors`（或 `/reference/errors`），列出你会返回的每个 HTTP 状态码 + 应用级错误码 + 每个错误一句话的成因说明。用表格效果不错，`<dl>` 定义列表也可以。
D4 · 同时记录了鉴权与限流
鉴权是基本盘；而限流则关系到开发者能否判断自己的集成是否扛得住生产负载。两者都应放在从首页就能发现的顶级文档页面上。
评分。 3 = 鉴权与限流都有记录 · 2 = 仅有鉴权 · 1 = 仅有限流 · 0 = 两者皆无。
改进。 增加 `/authentication`（bearer / API-key / OAuth 流程）和 `/rate-limits`（每分钟请求数、`X-RateLimit-Remaining` 等响应头、429 重试语义）页面。每个页面都需要至少 200 字符的说明——而不只是一段代码片段。
D5 · 提供术语表，或跨页面术语保持一致
到底叫“工作区”、“团队”还是“组织”？选定一个术语并在所有文档中一以贯之，能避免一类“X 在这里是什么意思？”的支持工单。专门的术语表最理想；用法一致也可以接受。
评分。 3 = 专门的 /glossary，含 ≥3 组结构化的术语/定义对 · 2 = 无术语表，但跨页面术语保持一致（主导写法占比 ≥80%）· 1 = 有术语表链接但内容稀少 · 0 = 两者皆无。
改进。 用 `<dl>` 发布 `/glossary`，以 `<dt>术语</dt><dd>定义</dd>` 成对呈现（或用定义不少于 50 字符的两列表格）。同一术语在所有页面中保持相同的大小写与拼写。
D6 · 已废弃 / beta 端点以纯文本明确标注
开发者把你 2022 年的代码示例粘到 2026 年的项目里，不应该到运行时才发现该端点已被废弃。在文档中显式标注 `deprecated`/`beta`/`sunset`，能省去迁移时的麻烦。
评分。 2 = OpenAPI 规范中含 `deprecated`，或 ≥2 个样本页面在端点标题附近标注 · 1 = 出现 beta/experimental 等关键词但无废弃标记 · 0 = 没有。
改进。 在 OpenAPI 中为每个已废弃端点标注 `deprecated: true`，并在 HTML 文档中加一个可见的徽标或提示框（如 Mintlify 的 `<Warning>`、Docusaurus 的 admonition 语法等）。beta 端点同理——要在正文中可见，而不能只写在规范里。
E — 渲染与卫生 · 21/100
站点在没有 JavaScript 的情况下是否稳定且可用？
渲染与卫生关注的是上述这一切能否经受住普通 HTTP 客户端的检验。E1 是这一类的门槛：如果内容不在 JavaScript 运行之前返回的 HTML 里，无论文档写得多好，智能体看到的都只是一个空的应用外壳。这一类的其余部分涵盖站点迁移后 URL 是否稳定、是否有明确的 API 版本、内部链接是否真的可达、是否声明了使用条款，以及控件是否带有可访问名称——当智能体不是读页面而是操作页面时，它需要这些名称来定位。
E1 · 无需 JavaScript 即可在纯 HTML 中看到内容（门禁项）
这是“门禁”准则。如果你的文档只有在 JavaScript 运行后才渲染（即单页应用外壳），那么抓取原始 HTML 的智能体将一无所获。网络爬虫、抓取器、curl 以及大多数 AI 抓取程序都不会执行 JS。
评分。 6 = 在各 UA 模式下，首页或 2 个子页面中至少一个的正文文本 >500 字符 · 3 = 首页通过但子页面为 SPA · 0 = 处处都是 SPA 外壳，或命中统一外壳陷阱（3 个以上 URL 返回完全相同的正文）。
改进。 在静态 URL 上提供预渲染的 HTML。如果你用 Next.js/Nuxt/SvelteKit，请为文档部分启用 SSG 或 SSR。单页应用外壳（React SPA、未做 SSR 的 Vue SPA）会无法通过这道门禁，并连带把许多其他准则一并清零。
E2 · 稳定 URL：用 301 重定向保留旧路径
当你重新组织文档时，旧链接不应返回 404——而应 301 跳转到新 URL。稳定的 URL 是来自博客、Stack Overflow 和书签的内部链接在你重构后仍能存活的关键。
评分。 2 = 抽样的 2 个 URL 变体中 ≥1 个有稳定的 301/308 重定向 · 1 = canonical 别名模式（返回 200 并带 `<link rel=canonical>`）· 0 = 302（非永久）、404 或无重定向。
改进。 更改文档 URL 时，从旧路径加一个 301 重定向到新路径。静态站点生成器可通过 `_redirects`（Netlify）或 `vercel.json` 的 `redirects:`（Vercel）配置来处理。
E3 · 在 URL 路径、标题或 OpenAPI 规范中显式标注 API 版本
`/v1/users` 对 `/v2/users` 是一种既省事又能让智能体一目了然的 API 版本管理方式。仅存在于请求头（而不在路径或文档标题中）的版本元数据，对爬虫是不可见的。
评分。 2 = 版本出现在文档自身的 URL 结构中（站点地图或 OpenAPI 规范 URL：`/v1/`、`/2024-01-15/`） · 1 = 版本出现在文档化的 API 端点 URL（curl/代码示例）、OpenAPI 的 `info.version` 或 `<h1>`/`<h2>`/页脚标题中 · 0 = 没有。
改进。 为 API 路径加上 `/v1/`、`/v2/` 前缀，并在 curl/代码示例中展示它们；或在 OpenAPI 规范中设置非空的 `info.version`。按日期版本化的 API（`/2024-01-15/users`）同样计入。
E4 · 抽查 5 条内部链接 → 全部返回 200
经过多年迭代后，失效的内部链接是文档最常见的故障模式。抽查 5 条链接能在不爬取每一条链接的前提下，揪出最严重的情况（首页上的链接直接返回 4xx/5xx）。
评分。 2 = 抽样的同主机链接中 5/5 返回 200 · 1 = 4/5 · 0 = ≤3/5，或在首页找到的不同同主机链接不足 5 条。
改进。 在 CI 中运行链接检查工具（lychee、htmltest、linkinator）。对于首页上流量最大的链接，发布前先修掉所有 404。首页上有 5 条可用链接是最低要求。
E5 · 使用条款：明确的 TOS / 许可证 / AI 策略
没有明确的 TOS 或 AI 使用策略，每个 LLM 抓取器就只能猜测你的立场。增加一个内容充实的 `/terms` 或 `/license` 页面——尤其是带有 AI/ML 关键词的页面——能让策略变得机器可读。
评分。 2 = 找到 TOS 页面且其正文含 AI/ML 策略关键词 · 1 = 找到 TOS（内容充实但无 AI 关键词，或链接存在但页面 404/内容稀少）· 0 = 没有 TOS 链接。
改进。 发布 `/terms`（或 `/legal`、`/license`），至少含 1000 字符的策略文本。就 AI 抓取、模型训练和自动化访问给出明确表述——即使你允许一切，把它说出来本身就是信号。
E6 · 代理可访问性：静态名称 + ARIA 有效性
AI 代理通过可访问性树操作页面：每个按钮、链接、输入框和图片都需要可定位的名称。v3 将此条目从 F 类移到 E 类、紧邻 E1，因为它评估的是渲染后的页面，而非发现表面。
评分。 4 = 0 处违规（且至少有 1 个可检查元素）· 2 = 1–2 · 1 = 3–5 · 0 = ≥6 · not_applicable 表示无可命名元素 · error 表示无法扫描页面。静态启发式（无 axe-core/headless）。
改进。 为每个 `<button>`/`<a>`/图标提供可访问名称；将 `<label>` 与输入框关联；为图片加 `alt`、为内联 SVG 加 `<title>`；移除正的 `tabindex`；修正拼错的 `aria-*` 属性和角色。
F — 代理能力 · 4/100
站点是否暴露面向智能体的接口（llms.txt、WebMCP、MCP、可访问性）？
智能体能力记录的是面向智能体的显式接口：页面中的 WebMCP 工具接口（声明式或脚本式均可），以及 OAuth 元数据符合 RFC 9728 与 RFC 8414 的、已对外声明的 MCP 服务器。这一类刻意做得很小——一百分里只占四分。两份规范都还年轻、仍在变动，在少数几家文档平台之外，采用率只是个位数百分比；因为没有实现一项实验性标准就给每个站点扣分，说明的是我们的热情，而不是它们的文档。等采用率上来了，权重也会随之提高。
F2 · 面向浏览器内智能体的 WebMCP 工具接口
WebMCP 让页面向运行在浏览器标签页内的 AI 智能体暴露可调用的工具——可以通过声明式的 `<form toolname tooldescription>` 标记、命令式的 `navigator.modelContext` API，或者一个 polyfill。F2 对检测到的任何一种接口都给分；对声明式表单的模式校验只进入诊断信息，不影响得分。
评分。 1 = 检测到 WebMCP，0 个模式错误且 0 个警告 · 1 = 检测到但存在模式问题（错误或警告）· 0 = 未检测到 · error 表示首页无法被扫描。
改进。 添加 WebMCP 工具接口。声明式写法是外部审计方唯一能从静态 HTML 中验证的形式：给 `<form>` 加上 `toolname` + `tooldescription`，并给每个输入项加上 `name` + `toolparamdescription`。优先修复缺失 toolname、必填参数缺 name 等错误，它们属于硬性失败。
F3 · 对外公布 MCP 服务器（RFC 9728 / 8414 OAuth）
MCP 服务器让智能体能以受治理的工具方式调用你的 API。F3 奖励通过标准的 `.well-known` 元数据，公布一个可发现、受 OAuth 保护的 MCP 端点，让智能体无需定制配置即可完成鉴权并连接。
评分。 3 = 完整的 oauth-mcp（RFC 9728 受保护资源 + RFC 8414 授权服务器元数据 + PKCE S256）· 2 = 部分满足 · 1 = 仅有端点 · 0 = 没有 · error 表示站点无法访问。
改进。 提供 `/.well-known/oauth-protected-resource` 并指向你的 MCP 端点，再在同一主机上提供一份符合 RFC 8414 的授权服务器元数据文档，公布 `S256` PKCE。
从哪里入手
在 AgentFit 公共语料库的 5827 个站点中，得分中位数是 22 分（满分 100），四分之一的站点不到 11 分，只有 19 % 超过 40 分。分数总是丢在同样的四个地方，下面按每小时工作能拿到的分数排序：
- 主机根目录没有 /llms.txt——75.0 % 的站点在 A1 上得零分，该项值 3 分。一个生成的文件，一个构建步骤。语料库中有 57 % 既没有 llms.txt，也没有 llms-full.txt，robots.txt 里也没有 AI 爬虫政策：等于完全没有为智能体声明入口。
- robots.txt 没有点名任何 AI 爬虫，也没有绝对形式的 Sitemap 行——65.8 % 的站点在 A3 上得零分，该项值 3 分。五行文本，而且写在每个爬虫最先读的那个文件里。
- 文档页面没有 markdown 副本——在能够完成该检查的站点中，77.9 % 在 B1 上得零分，该项值 5 分。大多数静态站点生成器手里本来就有源 markdown；要做的是路由，而不是写作。
- 没有可发现且有效的规范——96.4 % 的站点在 C1 上得零分，该项值 8 分。这是记分板上最大的单项损失，也是四项中唯一需要真正工程投入而非改配置的一项。
顺序比清单本身更重要。九项标准——llms.txt、llms-full.txt、robots、sitemap、首页发现标签、JSON-LD、canonical、修改日期、分类体系——合计 27 分，且不需要改写任何一行文档；平均站点只拿到其中的 8.5 分，也就是有十八分白白摆在桌上。C1 和 D 类中的错误目录则是以周计的工作量，应当排进计划，而不是顺手塞进某个迭代。关于因果关系有一点提醒：有 llms.txt 的站点中位数是 41 分，其余是 18 分，但这并不意味着这个文件能带来 23 分。因果方向更可能相反：本来就在维护文档的团队，才会去加这个文件。标记是便宜地拿分的办法，不是把文档做好的办法。
本节所有数字都是一份冻结快照：在评分标准 v3 下有一次有效运行的 5827 个主机，快照时间为 2026 年 7 月 27 日，每个主机取一次运行，不包含 AgentFit 自有的域名。本页上方的图表则取自实时语料库和当前评分标准，而权重在该快照之后已经调整过——两组数字本就不必一致，出现分歧时以图表为准。这些 URL 是用户自己提交的，并非精选的 API 文档清单，因此中位数描述的是被提交的样本，而不是整个市场。
常见问题
llms.txt 是什么，我真的需要吗？
它是放在主机根目录的一个 Markdown 文件，用来索引你的文档：一个 H1 标题、若干章节标题，以及指向重要页面的链接，格式由 llmstxt.org 提出。没有任何爬虫有义务读它，AgentFit 也不声称它是标准。给它计分的理由是：它只需要一个构建步骤，而且这是唯一一个由你、而不是由别人的爬虫启发式来划定「什么算你的文档」的地方。配套的 /llms-full.txt 是同一思路的全文版本。
想拿高分是不是必须有 MCP 服务器？
不必。整个智能体能力类别只有 4 分（满分 100）——一个既没有 MCP 服务器也没有 WebMCP 的站点照样能拿到九十多分。这一类存在的意义是记录谁在建设面向智能体的接口，而不是惩罚没建设的人。如果你确实运行着 MCP 服务器，F3 会检查它是否按规范预期的方式对外声明：符合 RFC 9728 的受保护资源元数据、符合 RFC 8414 的授权服务器文档，以及采用 S256 的 PKCE。
这和 Lighthouse 或 SEO 审计有什么区别？
读者不同。Lighthouse 衡量的是人在浏览器中的体验：绘制时间、布局偏移、渲染后页面的可访问性。SEO 审计衡量的是与搜索索引及其排序信号的契合度。AgentFit 衡量的是：一个不执行你的 JavaScript、也不滚动页面的程序，能否取得你的 API 契约。三者确实有重叠——无 JS 渲染、canonical、结构化数据在三者中都出现——但失败模式各不相同，Lighthouse 满分与一份智能体无法使用的文档站完全可以并存。
评分里为什么没有语言模型？
因为无法复现的分数不是测量。每一项检查都是一次 HTTP 请求加上一个解析器或一条规则，所以同一个站点两次得到相同结果，而且每一分背后都有一个 URL 和一段可供你自己核对的片段。有两个小型分类器辅助两项标准；它们被编译进二进制并与其一同版本化，别人的重新训练不会在一夜之间改变你的分数。实际效果是：一次完整审计约三十秒，运行不花钱，并且经得起怀疑者的复核。
应该多久重新跑一次审计？
在文档的构建或分发方式发生任何变化之后跑一次，其余时间每月一次。分数只在事实变化时才变化，所以每天跑主要测到的是你 CDN 的噪声。用 diff 视图比较两次运行；如果两次之间评分标准版本变了，系统会拒绝比较，而不是把我们换尺子显示成你的退步。
我的分数很低，这说明什么？
通常并不说明文档对人不好。低分最常见的形态是：一个写得不错的站点以 JavaScript 应用的方式交付，且没有任何面向机器的接口——智能体拿到一个空壳，没有 markdown 副本，没有规范，后面的一切也就跟着一起失败。请从修复清单开始读报告：它按每单位投入能拿到的分数排序，每一条都写明了抓取的 URL，你可以先复现结论，再去安排工作。
分数高就能让 ChatGPT 引用我的文档吗？
没有人能作这种承诺，本工具也不承诺。高分意味着一件更窄、也更可核实的事：能够访问到你站点的智能体，可以在不使用浏览器的情况下取得、解析并引用它。至于回答型引擎是否会引用你，还取决于它的爬虫政策、人们提问你产品的频率，以及各家厂商都不公开的排序机制。AgentFit 衡量的是你能控制的那部分。
我可以自己跑这套标准吗？
可以——手工来。完整规范就在本页，逐项列出；同一份内容在本地址上通过 Accept: text/markdown 以 Markdown 形式提供，报告的结构定义在公开的 OpenAPI 文档里。做不到的是运行我们的实现：源码不公开，我们也不发布构建产物。但你可以反过来监督我们——/reproducibility 上放着三份原始报告，以及把它们与同一站点的实时运行逐字段比对的确切命令。所有已审计的站点都可浏览，因此你可以先和同行比较，再动手。
审计你的文档 · 浏览已审计的站点 · 检查 MCP 服务器