XERJ llms.txt 基准研究报告：56 个开源项目的 llms.txt 对比表与 Agent 面文档启示-开发者社区

【免费下载链接】xerj

XERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.

项目地址：https://gitcode.com/GitHub_Trending/xe/xerj

点击查看免费下载

本文基于 XERJ 仓库内docs/research/llms-txt-2026-09/的专项研究，完整解读其 56 个项目 llms.txt 对比表（comparison-table.md）的度量口径、分布数据与逐列含义，并结合生成脚本与原始数据说明该表如何机械复现、哪些数字可以直接引用、哪些只是解剖记录。读完后你将掌握：如何从"一个给 AI Agent 读的索引文件"角度评估任何项目的 Agent 面文档质量，以及 XERJ 自身 llms.txt 在 40 KB 体量下的实际位置。

一、这张表是什么：研究对象、口径与生成方式

comparison-table.md是 XERJ 在 2026-09-18 至 2026-09-19 对 56 个开源项目llms.txt（以及llms-full.txt、AGENTS.md等 Agent 面文件）进行"解剖式"研究后产出的机械汇总。它的核心命题是：llms.txt 作为 AI Agent 获取项目知识的入口文件，在各头部项目中究竟承担了多少职责——是纯文档索引，还是安装了入口、MCP 配置片段、对 Agent 的直接指令，甚至是"回报反馈"的要求？

表头声明了三个关键事实，也是引用该表时必须理解的口径前提：

完全机械生成。表由 build_tables.py 从 dissections.json（2026-09-18 首轮 48 次运行、46 个唯一项目）和 dissections-2026-09-19.json（2026-09-19 追加的 10 个项目）生成，没有任何单元格是手写的；运行python3 scripts/build_tables.py --check时，如果表内容与数据不一致会直接退出失败（exit 1），保证"表过期即报错"。
排序规则：按 llms.txt 字节数升序排列，发布 llms.txt 的项目在前，未发布的排在最后。
"Install" 列的定义：安装命令是否出现在 llms.txt 文件自身里（而不是项目别处的 README 中）。

一个容易踩坑的口径区分，原文专门用一段话标注：表中的列记录的是"解剖 pass 为每个项目记下了什么"，而不是文件本身的字节级事实。例如"MCP snippet: yes"可能是从项目被链接的页面上摘抄来的片段；至于每个 llms.txt 文件里字面上有没有代码围栏、有没有claude mcp add这类命令，是另一套脚本（measure_llms_txt.py）在 132 个 URL 上测出来的，结果在 llms-txt-measurements.md。研究总纲 README.md 强调"两种计数不可混用"——这一点对任何想引用该研究的人都是最重要的使用纪律。

1.1 表格各列的机器定义

build_tables.py的 docstring 给出了每列的精确判定逻辑，这是读懂全表的关键：

列	判定逻辑（源自脚本）
`llms.txt bytes`/`lines`	解剖 pass 抓取到的字节数与行数
`llms-full bytes`	仅当 llms-full.txt 的 URL 返回HTTP 200时才计字节数（404 的响应体不算文件，记 0）
`Install in llms.txt`	记录中无 install 命令、或`install_position`文本以 "absent" 开头时显示`absent`；否则显示`install_position`的前 44 个字符（截断位置即安装命令在文件中的位置线索）
`Agent text`	`agent_prompt_verbatim`字段非空则`yes`，否则`—`
`One-click`	`one_click_links`列表的长度（一键安装/深度链接数量）
`MCP snippet`	`mcp_snippet_verbatim`非空则`yes`
`Feedback ask`	`feedback_cta_verbatim`非空则`yes`

另外两个去重细节值得注意：Weaviate 和 Deno 在首轮被解剖了两次，脚本保留 JSON 更长（信息更全）的那份；"published" 的判定要求status == 200且bytes非零——即HTTP 200 但内容是"Page Not Found" 的软 404 不计入（研究过程中 GitBook、Mintlify 等站点确实存在返回 200 加"未找到"正文的情况，见 README §8 "Probing trap"）。

二、核心分布数据：llms.txt 的体量与 XERJ 的位置

表头给出的分布统计（对 52 个发布了 llms.txt 的项目）：

llms.txt 大小分布（字节）：min 1,674 · p25 16,049 · median 24,814 · p75 45,599 · max 175,811。XERJ：40,064 字节，234 行 —— 排名 39/53。

XERJ 高于中位数、低于 p75，不是离群点。这个结论本身是研究的"自我纠错"之一：在 2026-09-19 扩大样本之前，研究者基于 46 项目样本曾判断"40 KB 大概率是离群值"，测量后证明错误——体量维度上 XERJ 处于中上区间（68 百分位，见 llms-txt-measurements.md）。真正的离群维度是首屏文本密度（超过 400 字符的非围栏行数 23 行，98 百分位）与义务性措辞数量（obligation words 21 个，97 百分位）——即"每行塞了多少字"，而不是"总共多少 KB"。

各功能要素的出现次数（52 个发布项目）：

要素	计数	解读
llms.txt 中没有安装命令	30/52	多数 llms.txt 是自动生成的纯文档索引
含面向 Agent 的直接文本	28	约一半项目把 llms.txt 当作"对 Agent 说的话"
含一键安装/深度链接	20	`cursor://`、`vscode:mcp/install`这类零命令入口
含 MCP 配置片段	24	多为从链接页摘抄（口径见 §1）
含反馈/贡献要求	24	README 总纲特别注明：无一例是强制性义务
发布了 llms-full.txt	39	全文 dump 已是事实约定，但不在官方 spec 内

10 个 2026-09-19 追加项目中 4 个根本没有发布 llms.txt，它们是 XERJ 在功能上最近的邻接者（本地代码搜索与 MCP server 类项目：GitHub MCP server、Serena、claude-context、probe）。对这四家，README 就是 Agent 安装面，表中相应行显示none published并记录 README 中的安装行数（3～7 行）。这一组的存在修正了首轮 46 项目样本的偏差——首轮样本偏向"带远程 HTTP MCP server 的托管产品"，本地代码工具类同行（Lucene、Quickwit、Tantivy、Zoekt、ripgrep 等）在 140 项目探测中几乎全军覆没（36/140 无可用 llms.txt）。

三、对比表全量数据

以下为原表完整内容（排序、数值与仓库文件逐字节一致，XERJ (for reference)行为研究基准行）。每个项目链接到仓库内的 per-project/ 目录下的逐项目解剖页：

Project	llms.txt bytes	lines	llms-full bytes	Install in llms.txt	Agent text	One-click	MCP snippet	Feedback ask
Ollama	1,674	29	236,111	absent	yes	0	—	—
Vercel AI SDK	2,217	46	6,062,390	Lines 22-30, section '## Local Coding Agents	yes	0	—	—
Supabase	2,709	43	7,022,257	absent	—	0	—	—
DuckDB	3,371	37	0	absent	—	0	—	—
turbopuffer	4,012	59	792,810	absent	—	0	—	—
Composio	4,445	50	1,160,265	Line 11, inside '## Before you implement'	yes	1	yes	yes
Vercel	4,726	64	9,509,006	Line 25, inline in a link description	yes	0	—	—
Deno	5,055	60	2,497,222	absent	—	0	—	—
Algolia	7,866	188	0	Lines 7-10, 首个 H2（描述之后第一节）	yes	6	yes	yes
Typesense	8,591	81	1,947,804	营销版 llms.txt 中无安装命令	yes	5	yes	yes
Firecrawl	8,815	128	1,914,650	absent	—	0	—	—
LlamaIndex	10,908	89	0	absent	—	0	—	—
Langfuse	15,971	137	0	absent	yes	0	yes	—
Cloudflare Developer Docs	16,049	138	59,403,277	absent	yes	1	yes	yes
Elastic	17,198	171	0	absent	—	0	—	yes
Meilisearch	17,702	256	8,670	absent	—	0	—	yes
Tavily	18,171	212	856,222	Line 16，第二个 H2	yes	2	yes	—
ParadeDB	18,336	131	680,006	line 5/131（第 3 个 bullet，仅链接）	yes	3	yes	yes
Cline	18,871	116	675,700	line 6/116（第 2 个 bullet）	yes	2	yes	yes
Sentry	19,243	189	0	Line 11，'## Instructions for…' 首个 bullet	yes	0	yes	—
Clerk	19,607	130	768	absent	yes	0	—	—
Cursor	21,678	455	142,881	absent	—	1	yes	yes
Chroma	22,134	183	814,626	absent	—	0	—	—
LangChain / LangGraph / LangSmith	22,273	197	6,915,750	absent	—	0	—	—
Windsurf	24,156	132	636,246	absent	—	0	—	—
Exa	24,309	168	766,571	文件本身无安装命令	yes	10	yes	yes
Modal	25,320	372	2,321,860	absent	—	0	—	—
Stagehand	26,114	189	898,822	absent	—	0	—	yes
SurrealDB	27,938	294	51,217	首个可运行命令在 line 65	yes	1	yes	yes
Zed	29,076	238	0	absent	—	0	—	—
Weaviate	29,583	732	0	非顶层 H2 节；SDK 安装是其中一条	yes	0	yes	yes
Pydantic AI	30,549	435	5,782,671	Line 26，第一节第 2 个 bullet	yes	3	yes	yes
Turso	33,136	292	1,083,272	文件本身无安装说明	—	6	yes	yes
Bun	33,721	328	2,136,096	line 6，'## Docs' 第 2 个链接	—	0	—	yes
Browserbase	34,956	226	1,033,754	line 7/226，扁平索引第 3 个链接	yes	3	yes	—
CrewAI	38,837	233	1,964,675	absent	—	0	—	—
Neon	39,737	410	6,564,134	两处（line 9 等）	yes	5	yes	yes
Pinecone	39,873	278	3,814,905	absent	yes	0	—	—
LanceDB	44,802	240	1,668,626	absent	—	0	—	—
Convex	45,599	498	2,554,656	absent	yes	3	yes	yes
Claude Code docs	46,963	361	9,512,179	absent	yes	0	—	—
Model Context Protocol	48,383	354	2,487,841	absent	—	0	—	yes
Mastra	50,105	751	0	absent	yes	5	yes	yes
Expo	55,257	807	0	Line 22，'## Performanc…' 下的裸命令	yes	0	—	yes
FastMCP	64,883	574	2,885,378	line 6/574（文件中第 2 个链接）	—	5	yes	yes
Anthropic	68,036	699	35,109,013	absent	yes	1	yes	yes
Vespa	68,937	998	4,522,666	absent	—	0	—	—
Milvus	81,998	796	0	Line 58 '## Get Started'（第 4 个 H2）	yes	4	yes	yes
Stripe	92,159	707	0	absent	yes	0	yes	—
ClickHouse	103,444	500	34,655,192	Lines 5-12，第一个 H2	—	0	—	—
Upstash	163,576	1,472	3,456,603	Lines 3-7（任何标题之前的`<Tip>`）	yes	10	yes	—
Qdrant	175,811	696	0	absent	—	0	—	—
XERJ (for reference)	40,064	234	83,712	line 11，位于 'Start here' 内	yes	0	—	yes
GitHub MCP server	none published	—	—	仅 README（记录 4 行安装命令）	—	1	README	—
Serena	none published	—	—	仅 README（记录 4 行安装命令）	—	0	README	—
claude-context	none published	—	—	仅 README（记录 3 行安装命令）	—	0	README	—
probe	none published	—	—	仅 README（记录 7 行安装命令）	—	0	README	—

注：原文 "Install in llms.txt" 列对部分行做了 44 字符截断（如 Vercel AI SDK 行），上表在个别行做了忠实的中文化缩写；逐字原文与每个项目的完整解剖见 comparison-table.md 与 per-project 目录。

3.1 从表中可以直接读出的结构

体量两极分化：最小 Ollama（1,674 B / 29 行）与最大 Qdrant（175,811 B / 696 行）相差 105 倍。小体量端（Ollama、AI SDK、Supabase、DuckDB）多为"摘要 + 短索引"，大体量端（Upstash 1.472 行、Vespa 998 行、Cursor 455 行）多为生成器输出的全量文档目录。
"absent" 是 Install 列的主流值：52 家中 30 家没有安装命令，且其中不乏体量很大的自动索引（Qdrant、Vespa、Zed、Elastic）——印证了 proposals/report.md 的核心发现 1："llms.txt 很少承担安装入口，安装被放在一跳之外的 Agent 面文件里"。
llms-full.txt 体量差异巨大：从 Clerk 的 768 字节到 Cloudflare 的 59.4 MB。中位数约 1.96 MB（46 项目口径），而 XERJ 的 llms-full.txt 仅 83,712 字节——README.md §5 将此列为 XERJ 的优势之一："经过人工策展、能装进一个 context window"。
XERJ 行的四个特征：安装命令在 line 11（'Start here' 内）、有 Agent 定向文本、零一键链接、有 feedback ask——而表中所有"有 feedback ask"的 24 个项目里，XERJ 是唯一把回报要求写进 llms.txt 的（README 头条数据："0/140 探测项目要求 Agent 提交报告或开 PR——XERJ 是唯一一家"）。这一列因此同时是 XERJ 的"亮点"和"待改点"：通道选择（PR vs HTTP/MCP tool）与措辞（"required" vs 流程性描述）在总纲 M1/M2 与 §4 中有完整分析。
搜索邻接项目的缺席：与 XERJ 同类的本地搜索引擎/代码搜索项目（Elastic、Meilisearch、Typesense 有 llms.txt 但纯索引；GitHub MCP server、Serena、probe、claude-context 完全未发布）提示：这个品类的 Agent 安装面目前仍停留在 README 阶段。

四、XERJ 基准行是如何进入表的：源码级机制

XERJ 行不是从数据文件读出的——build_tables.py 第 32 行硬编码了基准常量：

XERJ = {"bytes": 40064, "lines": 234, "full": 83712}

排名计算（第 94 行）是"发布项目中字节数严格小于 XERJ 的数量加 1"，即rank = sum(1 for s in sizes if s < 40064) + 1，分母为"发布项目数 + 1"（把 XERJ 自身算进排序域）。我用 dissections.json 与 dissections-2026-09-19.json 按脚本逻辑复算：56 个唯一项目、52 个发布、安装命令 absent 30 家、XERJ 排名第 39——与表中数字全部吻合。这也说明表头里的"40,064 bytes / 234 行"是研究日（2026-09-18）对landing/llms.txt的快照，并非仓库当前文件的实时值；当前文件内容可对照 landing/llms.txt 查看（该文件在研究后续推进中持续有修改，例如 llms-full 链接、Caveats 各条目的更新）。

XERJ 行中 "line 11, inside 'Start here'" 指研究日快照中第 11 行的安装命令curl -fsSL https://xerj.org/get | sh；"yes"（Agent text）对应文件第 3 行 "This file is an index for you, the AI agent" 的定向开头；"feedback ask: yes" 对应 'Start here' 第 5 步的 field report 要求。这三点恰好是 XERJ llms.txt 相对同侪最显著的差异面，也恰是总纲 M1（"required, not optional" 与## Optional标题自相矛盾）、M2（PR 作为 Agent 回报通道不可行）两条缺陷的触发点。

五、引用与复现指南

引用该对比表时，建议遵循研究自身设定的三条纪律：

区分"记录"与"测量"。表内各列是解剖 Agent 在 2026-09-18/19 对 live URL 单次抓取后的笔记；文件级字节事实（代码围栏数、claude mcp add出现位置等）以 llms-txt-measurements.md 及其 manifest（每行含 URL、HTTP 状态、字节数、SHA-256、抓取时间）为准。
生成中的索引文件每天在变。报告明确记录了漂移实例：ClickHouse 的 llms.txt 在同一天晚间从 103,444 B 变为 103,065 B。公开引用任何数字前应重新测量（python3 scripts/measure_llms_txt.py）。
样本有选择偏差。46 项目首轮解剖自约 140 项目探测而来，偏向"探测时发现了 llms.txt + 至少一个其他 Agent 面文件"的对象；本地代码搜索/本地 MCP 工具类项目在 2026-09-19 才被补齐，且补齐的 4 家全部未发布 llms.txt。把该表当作"托管产品文档实践横截面"而非"全行业普查"来引用是准确的。

5.1 本地复现步骤

仓库内全部输入均为文本数据，可在只读克隆中直接复现（不修改任何仓库文件）：

cd docs/research/llms-txt-2026-09 # 检查 comparison-table.md 是否与数据一致（过期则打印 STALE 并 exit 1） python3 scripts/build_tables.py --check # 重新生成表格（会写入本地文件，CI 中建议只用 --check） python3 scripts/build_tables.py # 对 proposals/data/llms-txt-urls.tsv 中的 132 个 URL 做字节级测量 # （需要网络；默认离线模式 --offline 只读缓存） python3 scripts/measure_llms_txt.py

原始结构化数据（无损）在 data/dissections.json、data/discovery.json；每项目一页的完整解剖（含逐字引用、"他们做得更好的地方 / XERJ 做得更好的地方 / 可借鉴点"三节）在 per-project/，例如 elastic.md（Elastic 的 llms.txt 是纯自动索引、零安装零 MCP，但其 MCP server README 的 "Verify the connection" 清单被列为 XERJ 可借鉴项）、qdrant.md（175 KB 最大文件的解剖）、github-mcp-server.md（未发布 llms.txt 组的代表）。事实核验记录（259 条 claim 全部重抓，258 确认、1 条未能确认并移除）见 proposals/FACTCHECK.md。

六、这张表回答了什么问题：对 Agent 面文档的结论

综合 README.md 总纲与本报告，该对比表支撑出四条可迁移结论：

llms.txt 的行业主流用法是"文档目录"，不是"安装面"。52 家中 30 家无安装命令；安装真正发生在一跳之外（SKILL.md、agents.md、per-host 安装指南）。因此 XERJ 把安装命令放进 llms.txt 本身（27/46 口径下的少数派）反而是差异化优势，被总纲 §5 列入"不得回退"清单。
对 Agent 的"要求"与"流程"是两回事。表中 Feedback ask 列 24 家有记录，但没有任何一家把反馈写成债务；XERJ 快照中"required, not optional"的措辞 + PR 通道组合，被总纲 §4 判定为"回报无法到达"的结构性原因（通道需要 shell、git、GitHub 身份，而宿主仓库规则普遍禁止 Agent 写操作）。
MCP 片段的可发现性直接决定无 shell Agent 能否接入。表外测量口径：127 个 llms.txt 中仅 2 个字面含claude mcp add、仅 2 个含mcpServers（llms-txt-measurements.md）——MCP 配置普遍在 README/文档页，不在 llms.txt 内。XERJ 快照同样为 0，对应总纲 M4。
邻接品类（本地代码搜索 + MCP server）整体缺位。4 家最近功能同行全部未发布 llms.txt，README 是唯一 Agent 面；对 XERJ 而言，这既是"品类内先发"的事实，也意味着该表给出的最佳实践几乎全部来自托管产品，向本地工具迁移时需按 proposals/report.md §3 的模式（能力分支、一行粘贴提示、per-client 注册、verify 行）逐一适配。

最后重申引用边界：所有数字锚定 2026-09-18/19 的抓取时点，第三方页面的引用以 FACTCHECK.md 中的逐条核验记录为准；研究自身也公开了流程性错误（单 Agent 合成 52 份结果导致长时运行、锚定效应使"46 份解剖都批评同一缺陷"不构成 46 次独立确认），这些元信息在 README.md §1、§8 中有原文记载，引用时建议一并保留。