llms.txt 与智能体清单页面：一套维护型的机器可读站点索引

llms.txt 与智能体清单页面是一种面向机器的索引，它告诉 AI 系统一个网站代表什么、哪些公开页面是权威的，以及在业务支持智能体操作的情况下，哪些已验证的能力和政策适用。它是一张指向维护中来源的地图，而非这些来源的替代品，也不保证任何特定爬虫会使用它。

其契约是 身份 → 范围 → 权威目的地 → 可选能力 → 约束 → 时效性。只有当机器能够获取该文件、无需猜测即可解读、遵循实时规范 URL，并最终抵达仍与生产实际相符的事实时，该文件才算成功。

它回答的问题

核心问题是：“AI 系统应使用本网站的哪些部分来理解组织、其内容及其支持的操作？” 辅助问题包括：

• 网站的规范名称、域名、目的和受众是什么？
• 哪些产品、服务、文档、定价、政策和支持页面是权威的？
• 哪些页面应优先于归档页面、活动页面、参数页面或重复的区域版本？
• 该网站是否提供真实的智能体能力，还是仅提供人类可读的信息？
• 认证、速率限制、数据处理、商业条款和支持在哪里记录？
• 哪些陈述是指南性说明，而非访问控制规则？
• 谁拥有该文件？什么事件触发更新？如何检测信息偏差？

何时使用此文章类型

当网站拥有足够多公开、持久的内容，值得维护一个精选的机器可读索引，且有人能负责其维护时，可使用此类型。发布的目的是减少检索系统的歧义，而非为了创建而创建多一个 URL。

切勿将指引与控制混淆。robots.txt 表达爬虫访问偏好；XML 站点地图帮助爬虫发现 URL；认证和授权决定某个操作是否可执行。llms.txt 提供精选的上下文。llms.txt 中的一句话不能授予访问权限、撤销访问权限、保护机密或覆盖目标页面的条款。

最适合的业务类型

1. SaaS 。 最适合，因为软件公司通常拥有独立的产品、功能、定价、集成、API、安全、状态和文档来源。索引可以确定每个事实由哪个页面负责，而单独的能力清单仅描述产品真正支持的操作。
2. 电子商务 。 当产品、配送、退换货、库存和客服政策公开且规范时，效果很好。将易变的商品数据保留在数据源或 API 中；使用索引指向那些维护中的来源，而非将目录复制到 Markdown 中。
3. 市场平台 。 当买家、卖家、服务方和平台政策各不相同时很有价值。为每个受众和司法管辖区做好标注，以免智能体将卖方规则应用于买家，或从单个列表推断平台库存。
4. B2B 服务 。 有助于明确能力、行业、服务边界、证据、采购材料和联系渠道。不要将经过谈判的范围或针对特定客户的承诺转化为普适的机器可读声明。
5. 代理机构 。 当公司拥有大量服务、方法论、案例研究和专业能力页面时很有用。客户门户、资质证书、内部报告和内部手册应远离公开文件。
6. 制造商与工业企业 。 有助于引导系统找到产品系列、规格、认证、手册、经销商和安全文档。索引绝不可在受控文档为权威来源时对安全关键说明进行释义。

拥有五个稳定页面的小型宣传网站从另一个需要维护的工件中获益甚微。没有明确内容负责人的网站应首先解决规范化、导航和源质量问题，然后再发布一个很快就会过时的文件。

搜索意图

搜索意图 是查询期望得到的结果。此类型有两个意图不同的受众。机器获取可预测的根路径，期望简洁的 Markdown、稳定的标题、规范链接，并且没有装饰性噪音。人类搜索者通常想要实施指南：“llms.txt 示例”、“llms.txt 应包含什么"或"智能体清单格式”。公开的解释页面可以回答这些问题，而部署的 /llms.txt 则保持针对机器检索的优化。

该文件本身不是关键词落地页。不要添加通用定义、重复的类别术语或数百个博客链接来使其"排名"。每多一行就多消耗一份注意力，并创造一个新的维护义务。宁可用十个带有清晰描述的精简链接，也不要转储一万个 URL。

由于约定和消费者支持可能发生变化，请说明您的实施基于什么，并避免宣称已被普遍采纳。成功获取只能证明文件可访问且可解析，并不能证明某个特定 AI 产品将其用于排名、检索、训练或引用。

页面结构

字数区间是编辑约束而非目标。部署的文件应保持足够简洁，以便逐行审计。面向人类的实施说明可以更长，但绝不能复制到机器文件中。

典型的精选文件大约 200–700 词。长度不是质量信号：合适的规模是能确立身份并将消费者引导至维护中的来源，同时不掩盖关键区别的最小索引。

必需元素

索引应以最好的意义上"枯燥"：可预测、明确且易于对比。将关键解释信息放在可选链接之前，以免部分读取导致错误结论。

Frontmatter

遵循 frontmatter 规范 。在此文章类型规范上，使用 entity = "post-type-llms-txt-page" 和 schemaType = "Article"。在面向特定组织的人类实施页面上，使用稳定的标识符如 acme-ai-access-index，而非活动名称或日期。

使用 Article 因为该网页解释的是实施方案。结构化标记 描述可见内容；它不会将原始文本文件转变为可识别的智能体协议。除非页面的可见内容和模板独立满足相关要求，否则不要将页面标记为 SoftwareApplication、Dataset 或 HowTo。

原始的 /llms.txt 文件通常没有 frontmatter，因为 frontmatter 不得泄漏到已发布输出中。将其操作元数据存储在 CMS、生成器配置或仓库记录中：规范域名、区域范围、负责人、来源集合、生成模式、最后验证日期、下次审查规则、验证器结果和告警接收方。如果存在本地化文件，请记录选择规则并保留一个明确的规范根响应。

完整示例

以下虚构文件展示了一个 SaaS 平台的简洁索引。其中的 URL、产品和能力仅为示例；模式才是规范。

# Northstar Analytics

> Northstar Analytics 是一个面向运营团队的报告平台。本索引指向定义产品、方案、文档、政策和受支持智能体能力的公开页面。

访问权限由 robots.txt、认证以及下方链接的政策控制。本文件不授予访问权限或内容重用许可。

## 产品

- [产品概览](https://www.northstar.example/product)：当前产品范围及受支持的报告工作流程。
- [方案与定价](https://www.northstar.example/pricing)：当前公开方案、所含功能及计费条款。
- [集成](https://www.northstar.example/integrations)：受支持的数据源及目标系统。

## 文档

- [文档首页](https://docs.northstar.example/)：当前的用户和管理员文档。
- [API 参考](https://docs.northstar.example/api/)：公开端点、结构、认证、错误及速率限制。
- [发布说明](https://docs.northstar.example/releases/)：按日期记录的产品及 API 行为变更。

## 信任与支持

- [安全](https://www.northstar.example/security)：安全计划及当前保证文档。
- [隐私政策](https://www.northstar.example/privacy)：数据处理、保留及用户权利。
- [支持](https://www.northstar.example/support)：受支持的联系渠道及服务状态链接。

## 智能体能力

- [报告导出操作](https://docs.northstar.example/agents/export-report)：认证操作契约、可接受的输入、输出格式、速率限制及错误处理。可用性取决于用户的方案和角色。

## 可选

- [研究库](https://www.northstar.example/research)：带有方法和发布日期的原创基准报告。

2026-08-27 由文档运营团队验证。从规范公共资源注册表生成；在产品、方案、政策、API 或 URL 变更后需验证。

该示例仅声明了一个能力，因为确实存在一个真实的、有文档记录的操作契约。如果产品没有受支持的智能体操作，请省略该部分。切勿因存在搜索框、表单或无文档记录的端点而推断出交易能力。

对于与 /llms.txt 分开存储的智能体清单，保持同样的原则。指定带版本号的格式、规范标识符、生产端点、认证方法、允许的操作、输入和输出结构、速率限制、同意边界、错误状态及策略 URL。针对线上系统进行验证。语法正确但宣传已禁用操作的声明同样是错误的。

设计画廊

原始文件有意几乎没有视觉设计。画廊变体应测试信息架构、扫描顺序、人类实施页面在移动设备上的可读性以及运营证据——而非装饰。

质量检查清单

仅在每个适用陈述都为真时发布：

• 文件在目标根 URL 下可解析，无需认证、重定向循环、同意墙或渲染的应用外壳。
• 响应为可读的纯文本或 Markdown，使用 UTF-8 编码，且不依赖 JavaScript 来展示内容。
• H1 给出规范的组织或站点名称，描述说明目的、受众和范围，不含口号。
• 每个链接的 URL 都是规范的、公开的、按策略可被索引的、可访问的，且属于该组织所有或明确标注为外部链接。
• 链接描述说明目标地址持有哪些权威信息；不重复通用锚文本如"了解更多"。
• 主要的产品、定价、文档、政策和支持来源与索引一致。
• 归档页面、搜索结果、跟踪参数、重复区域版本、活动页面及低价值的标签页面被排除在外。
• 能力声明与真实、受支持、经过认证的契约匹配，并包含相关约束。
• 没有机密、令牌、私有端点、个人数据、客户文档、未发布路线图项目或安全敏感的实施细节出现。
• 访问、权限、许可和政策语言指向控制性来源，且不被索引所矛盾。
• 文件不宣称保证排名、引用、训练排除或通用消费者支持。
• 每当定价、政策、可用性或文档存在差异时，明确说明区域范围。
• 负责人、来源注册表、生成过程和验证方法记录在文件外部或末尾。
• 在相关部署后，运行断链、意外重定向、响应状态、内容哈希及必需章节检查。
• 验证日期仅在目标、描述、能力和政策经过实质性检查后才会更新。

常见错误

将文件视为站点地图。 完整的 URL 清单会破坏优先级排序且难以审查。保留 XML 站点地图用于发现；围绕权威来源和有意义的分类来精选 llms.txt。

将其视为访问控制。 Markdown 中的请求不是执行层。在 robots.txt 中表达爬取规则，用认证保护私有资源，并在相关政策和系统控制中放置具有约束力的要求。

将目标内容复制到索引中。 重复的定价、产品规格和政策会产生分歧。仅总结足以识别权威性的内容，然后链接到维护中的来源。

发布推测性的能力。 无文档记录的表单或 API 路由并不能让网站为智能体做好准备。仅声明具有认证、结构、约束、错误和负责人的生产支持操作。

“以防万一"地包含一切。 更多的链接带来更多的歧义和更多的故障点。可选内容应通过回答主要章节未覆盖的潜在检索需求来赢得被包含的权利。

暴露私人材料。 公开的机器可读文件是公开的。绝不要列出未有意批准发布的分期环境、内部 API、凭据、客户导出文件、未发布文档或安全细节。

无治理地生成。 自动化可以高速复制不良源数据。生成器需要经过审批的源注册表、排除规则、确定性排序、验证、审查所有权和部署告警。

手动编辑生成的文件。 下一次生成会覆盖修复。请更正源记录或生成器，重新生成，并记录实质性变更。

声称未受支持的结果。 “这保证 AI 引用"将不确定的实施约定变成了误导性的承诺。请将可访问性和检索证据与可见性和引用结果分开报告。

仅更新日期而不检查实际情况。 新的时间戳无法修复失效的文档 URL、已更名的方案或已禁用的操作。验证意味着将每个重要声明与其生产来源进行比较。

内部链接

当作者需要将机器索引与目录、文档页面或政策页面区分时，将人类实施页面向上一级链接到 SEO 文章类型 。将每个运营声明链接到其控制性来源：产品范围到产品页面、当前价格到定价、行为到文档、权限到访问控制、义务到政策。

原始文件应使用规范的绝对 URL，因为它可能在正常站点导航之外被获取。每个事实只应有一个权威目标地址。如果两个页面存在重叠，在列出双方之前先解决所有权问题；索引应展示来源层级，而非保留内部分歧。

使用简短、稳定的章节名称，如 Product、Documentation、Policies 和 Agent capabilities。仅当区域变体存在实质性差异时才将其放入明确标注的分组中。不要链接每篇博客文章；仅当持久的研究或指南能帮助系统理解网站主题和证据时才进行选择。

入站链接在运营层面也很重要。文档、开发者门户和 AI 可访问性指南应将维护者指向实施记录，而记录则指向实时文件和验证器。这样为人类创建了一条审查路径，同时又不使机器索引变得杂乱。

如何衡量结果

首先将文件作为基础设施来衡量，其次作为可见性输入。仅仅因为引用增加发生在发布之后，并不能归因于 llms.txt。

跟踪四个层面：

• 可用性： 根 URL 响应状态、重定向行为、内容类型、编码、延迟、渲染独立性和正常运行时间。
• 完整性： 解析成功率、必需章节、重复 URL、断链、重定向目标、规范不匹配、未授权域名、暴露的机密及内容哈希变更。
• 时效性： 自上次实质性验证以来的天数、验证后的目标变更次数、来源注册表覆盖范围、负责人确认及修复偏差所需时间。
• 结果： 在法律和技术条件允许的情况下，可识别智能体对服务器日志的获取次数、索引目标的访问量、首选规范页面的 AI 引用数，以及针对品牌或产品问题的答案准确性。

在部署前建立基线：哪些 URL 被引用、哪些事实被错误陈述、根文件是否存在、哪些爬虫请求了它。标注发布及每次实质性更新的时间。比较足够长的观察窗口，以避免将单次获取或引用误读为趋势，并保持相关性与因果性之间的区分。

直接测试故障模式。重命名列表中某个 URL 的暂存副本，确认验证器会检测到断裂。更改规范映射，确认生成器会更新索引。在受控测试环境中禁用某项能力，确认清单检查会失败。这些测试证明的是维护系统本身的有效性，而非外部采纳程度。

使用 我们如何衡量结果 来区分技术可用性、机器表征、发现、引用、互动和业务成果。在 AmICited 中，在"智能体可访问性"下审查实时文件，并使用 Cockpit 报告 结合部署标注来观察被引用的 URL 和 AI 可见性。可信的成功主张是"文件有效、最新，并将系统引导至预期来源”；任何下游可见性变化都需要单独的证据。

FAQ

常见问题