llms.txt 最佳实践：给 AI Agent 一份不会迷路的地图

AI 爬虫和 Agent 正在成为网站的新访客，但大多数站点并没有为它们准备一份像样的"导览图"。llms.txt 就是为此而生的约定格式——它不决定谁能进门，但决定了进门后的读者能不能在三步之内找到答案。

llms.txt 到底是什么，不是什么

先厘清一个常见误解：llms.txt 不是提交机制，没有注册表，没有排队队列，也没有 ping 端点。这个约定由 AnswerDotAI 在 2024 年 9 月提出，至今仍栖息在一个刻意保持小巧的 GitHub 仓库里，核心结构只有三样东西——一个 H1 站点名、一段 blockquote 摘要、若干 H2 分组下的链接列表。

它解决的是检索问题，不是索引问题。等任何东西来读你的文件时，一个"要不要抓取你的站点"的决定早已做完：可能是浏览助手、编程 Agent，或者一份把你的域名放进白名单的 RAG 管线。这个读者带着任务和 token 预算到场，/llms.txt 就是你递给它的那张地图。

Google 关于 AI 搜索功能的官方指南说得很直白：页面要出现在 AI 驱动的结果里，不需要任何特殊文件或标记。爬虫权限是另一个问题，由 robots.txt 管辖，OpenAI 也详细记录了其爬虫的工作方式。你不能用一份文本文件"选择加入"AI 可见性，就像单靠 sitemap 不能让你进入搜索索引一样。

一个恰当的比喻：llms.txt 是放在前台接待桌上的媒体资料包。它告诉访客档案室在哪、该找谁，但它不决定谁进得了那扇门。

robots.txt 是网站根目录下的纯文本文件，采用爬虫排除协议（Robots Exclusion Protocol），通过 user-agent、allow、disallow 等指令告诉爬虫哪些路径可以抓取。它管的是"能否进入"，属于权限层面；而 llms.txt 管的是"进门后怎么找到答案"，属于导航层面。两者常被混为一谈，但用途完全不同。

sitemap 则是给搜索引擎看的 URL 清单，帮助爬虫发现站点页面，通常以 XML 格式提供。它解决的是"有哪些页面"的发现问题，而不关心页面的语义和优先级，也不会描述每个链接的用途——这正是 llms.txt 用短描述和任务分组补上的缺口。

RAG 管线 指检索增强生成流程：先从知识库或网页中检索相关片段，再交给大模型生成回答。把域名加入白名单，意味着该管线的检索阶段会优先抓取并信任你的内容，因此一份清晰的 llms.txt 能直接影响它会选取哪些页面。

一份会被真正读取的文件，长什么样

我们检查过的大多数文件都是链接堆——六十个 URL，没有描述，没有排序。读者扫一眼找找域名匹配就走了。真正被用起来的文件，共享六个特征：

• 一个 H1，与人们搜索的名字一致
• 一句 blockquote，说清这东西是什么、服务谁
• 两三行纯文本上下文——base URL、认证模型、各部分位置
• H2 按任务而非部门命名，这样读者找"如何取消订阅"时能认出标题
• 每个链接旁附十词以内的描述
• 底部一个 Optional 区，收纳次要材料

以下是一个可以直接参考的实例：

# Northwind Analytics

> Northwind is a billing API for subscription software teams. Docs, SDKs, and pricing live here.

Northwind exposes a REST API, four official SDKs, and a hosted webhook relay.
Base URL: https://api.northwind.example/v2

## Core documentation
- [Quickstart](https://docs.northwind.example/quickstart): auth, first charge, five minutes
- [API reference](https://docs.northwind.example/api): every endpoint, request and response
- [Webhooks](https://docs.northwind.example/webhooks): events, retries, signature checks

## SDKs
- [Python](https://docs.northwind.example/sdk/python)
- [TypeScript](https://docs.northwind.example/sdk/typescript)

## Pricing and limits
- [Plans](https://northwind.example/pricing): tiers, overage, annual discounts
- [Rate limits](https://docs.northwind.example/limits): per-key quotas and backoff

## Optional
- [Changelog](https://northwind.example/changelog)
- [Status](https://status.northwind.example)

两个细节承担了大部分工作。绝对 URL，因为读者可能在脱离上下文的场景里解析你的文件，没有可靠 base 可以解析相对路径。短描述，因为它们是唯一能告诉读者"Core documentation 下这六个链接里哪个回答了我手上的问题"的信号。

这个体裁有个很好的先例——Hugging Face 的模型卡：一小段供人扫读、供机器解析的结构化文字，与一个大得多的东西并排摆放。你的 llms.txt 就是网站的模型卡。

手工维护的文件会腐烂。端点废弃了，定价页搬家了，产品改名了，地图还指着旧地址。更可靠的做法是在构建时从 sitemap 和 frontmatter 里生成，把它接入构建文档的同一根管线——这样地图漂移不会超过一个部署周期。

Agent 流量才是真正的回报场景

聊天机器人在你的读者群里要求最低：抓一个页面，综合一下，完事。Agent 完全不同——它跨多步持有一个目标，会在任务中途选择工具，MCP 给了它们调用工具的标准方式。一个刚收到"帮这位客户升级套餐"指令的 Agent，需要按顺序找到你的端点、认证方案和错误码，而不是抓十二个页面去判断哪个重要。

这正是决定文件形态的权衡。什么都覆盖，就会烧掉拿不回来的上下文。llms-full.txt 是为那些确实想一次性拿到全部语料的读者准备的，对文档站点来说那可能是一个四万词的载荷，往往在读到有用章节之前就被截断了。默认策略：用紧凑的 llms.txt 当地图，用 llms-full.txt 服务那些点名要全量的读者。

具体回报是什么样的？一个处理账单问题的客服 Agent 读你的文件，看到 [API reference](...)，抓那一个页面，找到端点，停止。三个请求代替一次爬取——这就是全部收益。

MCP 全称 Model Context Protocol，是 Anthropic 在 2024 年底提出的开放协议，用于让大模型以标准化方式调用外部工具和数据源。它定义了客户端与服务器之间的通信格式，使 Agent 不必为每个服务单独写适配代码。

token 预算 指一次模型调用或一个任务中可使用的 token 总量上限，包含输入与输出。Agent 在多步执行中每读取一个页面都会消耗上下文，一旦超出窗口，早期内容可能被截断或丢弃。因此 llms.txt 的价值在于让 Agent 用最少的抓取次数命中目标页面，把有限的 token 花在真正的答案上，而不是浪费在扫描无关链接。这也解释了为何短描述比单纯罗列 URL 更关键——它是降低检索成本的直接手段。

它做不到的三件事

管不住爬虫。 那是 robots.txt 的职责，Google 关于该协议入门的文档仍然是理解 user-agent 指令能做什么、不能做什么的正确起点。一份写着"请引用我们"、而你的 robots.txt 同时屏蔽了爬虫的文件，就是留在一个上锁房间里的便条。

建立不了身份。 实体身份来自结构化数据——schema.org 上的 Organization、Product 和文章类型，它们给机器一个规范名称、logo 和 sameAs 关系。面向 Agent 的结构化数据才能让模型把你的品牌解析为一个真实实体，而不是出现在十一个不相关页面上的一个字符串。

修不好单薄的内容。 如果你的文档锁在登录后面，或者最好的答案躺在 2019 年的一份 PDF 里，再整洁的链接地图也指向虚无。Bing 搜索团队发布的站长指南解释了 Copilot 如何呈现内容，答案与 Google 押韵：可爬取、结构良好、描述朴素的页面。没有文件能绕过这一点。

而它能做的事小而真实且便宜：为那些本来就会来的读者，从检索循环里省掉几个请求。

schema.org 是 Google、微软、Yahoo 等联合发起的结构化数据词汇表，定义了 Organization、Product、Article、FAQPage 等类型及其属性。站长可以用 JSON-LD 或微数据把页面内容标注为这些类型，搜索引擎和 AI 系统便能据此抽取实体信息，而非仅靠文本猜测。

sameAs 是 schema.org 的一个属性，用于声明某实体的官方外部链接，例如维基百科条目、社交媒体主页或其他权威档案。它帮助机器确认多个 URL 指向的是同一个真实实体，从而把品牌名称从"出现在若干页面上的字符串"升级为可被消歧的正式身份。缺少结构化数据和 sameAs，llms.txt 里的链接再整齐，也只是指向一堆未被机器确证的页面。

怎么衡量，怎么维护

服务器日志是唯一确凿的证据。统计 GET /llms.txt 的次数，看看 user agent 分布，观察一个季度的趋势。除此之外都是推断——目前没有公开数据说明有多少站点发布了这个文件、哪些引擎会消费它，所以任何引用"提升数字"的人引用的都是他们自己编的东西。

我们跑的五步维护循环里，只有第一步是关于文件本身的：

1. 记录抓取。 如果九十天内没有任何东西请求过这个文件，那它就不是你的瓶颈。
2. 追踪引用。 答案引擎引用追踪告诉你哪些 URL 正在被引用，这与你自认为重要的清单往往不同。
3. 发现衰减。 引用随时间流失的页面，通常是失去了准确性的页面——一次调价、一个废弃端点、一个版本升级。内容衰减检测与刷新能在竞品页面取代你成为来源之前抓住它。
4. 修补缺口。 对域名做一次 GEO / AI 可见性审计，看看你缺席了哪些问题，再检查本该回答那个问题的页面是否存在、可爬取、并在你的文件里被描述过。
5. 随部署重新生成。 这个文件是产物，不是文档。

顺序很重要。从第五步开始的团队，会花一个季度给一个"什么都回答不了"的站点画一张漂亮的地图。

GEO 全称 Generative Engine Optimization，即生成式引擎优化，指针对 AI 驱动的搜索与问答系统优化内容可见性的做法，与传统的 SEO 在目标和手段上都有区别：SEO 关注排名和点击，GEO 关注是否被 AI 引用、被摘要、被当作答案来源。

一次 GEO / AI 可见性审计通常会检查：你的域名在特定问题下是否被 AI 系统引用、哪些竞品替代了你、引用链接指向哪些页面，以及回答你核心问题的页面是否存在且可爬取。这类审计输出的正是维护循环第三步和第四步所需要的输入——衰减在哪里、缺口在哪里。需要强调的是，llms.txt 是 GEO 工作流中的一个可选环节，而非捷径；审计先于文件，顺序不能颠倒。

常见问题

llms.txt 能提升我在 AI 摘要或 ChatGPT 里的排名吗？

不能。Google 的 AI 功能指南明确表示页面出现不需要特殊文件或标记，该文件对排名毫无作用。纯粹把它当作服务已到达读者的检索辅助。

OpenAI、Anthropic、Google 真的会读它吗？

OpenAI 的爬虫文档和 Google 的 AI 功能指南都没有把该文件列为输入。不过 Anthropic 为自己的开发者文档发布了一份，这说明格式对构建这些系统的人来说是可理解的。可理解不等于被消费——诚实的立场是：支持情况因引擎而异，且未被公开。

应该发 llms.txt、llms-full.txt，还是两个都发？

两个都发是站得住脚的默认选择。短文件服务需要导航的 Agent，完整文件服务想单次抓取拿到语料库的管线。如果只能维护一个，维护短的那个——过时的地图还能活，过时的内容不行。

文档在子域名上，文件该放哪？

放在服务内容的那个主机的根目录，所以 docs.example.com/llms.txt 覆盖该文档站。如果你有多个子域名，根域名文件可以作为子域名文件的索引。正文里的绝对 URL 无论如何都能消除大部分歧义。

多久更新一次？

只要底层导航变了就更新——新增章节、下线产品、定价页搬家。实践上意味着每次部署都自动生成，结构变化时人工审查 diff，而不是段落变化时。

下一步

在写第一行文件之前，先搞清楚引擎们现在怎么评价你。一次 GEO 审计会显示哪些页面被引用、你缺席了哪些问题、以及一张地图到底是帮人导航，还是只是在描述一座空楼。