给 Agent 写目录，别写营销页

llms.txt 要不要做，看你的 Agent 判断成本。如果它判断要不要用你的软件只需 500 个 Token，这套目录适合文档复杂、工具多、用户开始抱怨额度的团队。把 llms.txt 丢进根目录就完事，通常不够。

第一天，我把一套内部影像工具说明拆成 llms.txt。Token 是模型处理文本的计量单位，llms.txt 像给 Agent 看的站点目录。我写了工具名、入口、适用场景、不该用它的场景，用的就是本地 Markdown 编辑器。我把它喂给 Claude。它问我这个工具解决什么任务。我说检索报告，它就开始要 API 文档。我这才发现，我写的还是官网口吻，只有有什么，没有什么时候用。

第三天，我改了三处，每页大概多少 Token，哪些页面不要爬，哪些任务要人工确认。再跑 WorkBuddy。这个工具我用了1个月。它没有像以前那样把整套说明吞下去，先读目录，再挑一个页面。以前 Agent 像实习生，拿到一摞材料就全看，现在像有导航，知道先去哪页。有案例提到一份 REST API 快速入门文档能到 193,217 个 Token，直接塞给 Agent，容易截断、跳过，最后还可能自己编答案。我这边没那么大，但长文档一多，额度确实肉眼可见地往下掉。

一周后，我把它接到多步骤任务上，试了刚上手的 MCP。MCP 是给 Agent 连接外部工具的插座。过去我让它查接口、生成示例、再检查参数，它容易反复读同一堆说明。现在我先给它一个短目录，它判断要不要用你的软件，这一步很快，剩下的调用才展开。省下来的是试错。

目录能省上下文，也能减少盲爬，产品文档有了给机器看的入口。它不是 SEO 插件，写完不会自动变准。目录描述一旦像营销，Agent 会被带偏；工具边界没写清，它会误调用；文档更新后目录不维护，比没有更麻烦。

我的判断是先给高频工具做一页短目录，别贪全。像影像 AI 进科室，医生实际使用反馈里最怕那句「我还是得重看一遍」。Agent 读软件也一样，先让它用很短的上下文判断该不该进入你的工作流。