XERJ：一个会坦白自己数字灌水的编码代理搜索引擎

很少有一个项目，最有趣的特性是它自己的坦白。

XERJ 是一个用 Rust 写的代码与文档搜索引擎，面向编码代理（coding agents），通信协议兼容 Elasticsearch，采用 Apache-2.0 许可。它有一张带真实美元数字的基准测试表。它还有一条维护者说明，承认其 GitHub star 数被一个合成群体（synthetic cohort）灌水约十三倍，并请求大家不要引用这个数字。

这两件事都值得你花时间，而且它们彼此相关。

它想解决的问题

当一个编码代理需要理解一个代码库时，默认动作是 grep。grep 很诚实：它找出匹配某个模式的行。但用 grep 的代理必须读文件，才能判断这个匹配是否有意义，而读文件正是填满上下文窗口的元凶。一个大文件消耗的 token，可能比它带来的答案价值还多。

XERJ 的替代方案是本地索引。把它指向一个文件夹，autoindex 会嗅探文件类型、推断数据集、丢弃垃圾文件，并为每个数据集单独建索引。仓库里一次真实运行的日志是这样的：推断出 593 个数据集，A 阶段有 1,955 个垃圾或跳过文件，B 阶段用八个 worker 索引 25,329 个文件，158.1 秒完成，83,103 条记录在线。

代码用 tree-sitter 解析，保留符号和行号，而不是把所有东西压平成文本。这就是为什么 xerj def <symbol> 能返回文件、行号和签名——跨仓库的跳转到定义，这才是代理一开始就需要的东西。

基准测试，得仔细看

项目跑了八个任务、四种语言，每条实验臂十六次运行，并且实测 claude -p 的 token 消耗，而不是估算。三种设置：仅靠记忆、grep 驱动、XERJ。

仅靠记忆用了 260,916 个输出 token，花费 $11.18，解出 11/16。grep 用了 26,477 个 token，花费 $3.27，16 个全解。XERJ 用了 9,982 个 token，花费 $1.58，同样 16 个全解。

也就是说：输出 token 比 grep 少约 2.7 倍，比依赖模型记忆少 26 倍，而解出率没有变化。单个最佳案例——一个 Java 任务——省了 278 倍。用户报告端到端大约 5 倍。

现在说那条让这篇文章值得写的注脚。仓库的标题宣传语写着“比 grep 少 40 倍 token”。正文里的受控实验说 2.7 倍。这不是同一个声明，而两者之间的差距，恰恰就是让基准驱动的营销不可信的那种模式。值得肯定的是，README 自己说要以正文的数字为准。一个夸大的大标题配一条纠正它的脚注，是一种很奇怪的发布方式，但至少那条纠正在。

发布文里没人提的那个约束

这是大多数“为代理做搜索”的项目都会省略的一句话：收益取决于模型是否已经知道这段代码。

在私有、内部、小众或训练截止之后的代码上，检索能省很多，因为模型确实猜不出来。而在模型见过一万遍的热门开源库上，索引要么没用，要么有害——你花 token 去检索模型早就知道的东西。

就这一个约束，就改变了你该怎么部署它。它不是一次普适的升级。它是对一种特定失效模式的修复：代理在啃那些没人写过博客的代码。

--insecure 标记是一条真实的信任边界

运行 xerj --insecure 会关闭 TLS 和 API 认证。任何能连到这个端口的人实际上就是超级用户：读、写、删除所有索引，包括 /_memory 下的一切。在一个开发者自己的笔记本上这没问题，放在任何共享环境里都是灾难。

默认配置比这个标记好。新节点绑定到 127.0.0.1，而明文绑定到非回环地址会拒绝启动，除非你显式设置 server.allow_insecure_network_bind = true。项目还记录了：在 0.0.0.0 上以不安全模式运行曾是一个真实漏洞——局域网客户端可以未经授权写入——并已修复。给自己的旧漏洞起名字，是个好习惯。

那份应该被当作模板的公开说明

在一次 instrumentation 提交里，维护者写道：仓库的 star 和 fork 数被一个合成群体放大了约十三倍；真实安装数据很单薄——大约 145 次 release 附件下载、约 28 次完成的安装；而 Cloudflare RUM 在七月就停止记录了，所以网站上那张零流量图表只是个假象。

对于一个声称兼容 Elasticsearch、并通过了 1,371 项一致性测试（零失败、三次跳过）的项目来说，公开这些是很不容易的。它也顺便告诉你当前开源信号的状态：star 数是一个营销面，任何跑增长循环的人都能推动它。唯一值得相信的数字，是作者违背自身利益主动交代的那些。

你还会遇到的其他东西

安装方式是 curl 管道到 shell，它会校验 SHA256，如果找不到校验工具就拒绝继续——对这种模式来说，这是异常清醒的一道护栏。构建是静态 musl 加 jemalloc，Linux 优先，Windows 需手动安装。有一个 MCP 服务器暴露十三个工具，包括 xerj_plan 和 xerj_map，而 xerj init 一条命令就能接上 Claude Code 或 Cursor。支持带 scalar8 量化的 kNN。多节点部署带 Helm chart 和一个 compose 文件。

版本是 1.0.0-rc.x，CLI 还在变。CLA 改编自 Apache 的版本，并附了一条维护者说明：没有律师审过，还留着两个占位字段。很多提交由编码代理撰写并做了标注，这很透明，也是你该读一读自己所依赖的代码的理由。

参考式编码，没人做基准测试的那个用例

README 里埋着最有趣的用法：把索引指向与你正在解决的问题最接近的开源项目，然后在参考代码在上下文里的情况下写自己的版本。

很多真实的工程就是这么干的——找到已经解决过它的库，读一遍，然后实现一个更窄的东西。干得差的方式是把半个仓库粘进 prompt。干得好的方式，是能够问“这个项目在哪里处理背压”，然后拿到一个文件、一行和一个函数签名。

它也暴露了上面那个基准的局限。参考式编码需要下载并索引别人的仓库，这要花时间、磁盘和网络。省下来的东西在第二次、第三次查询时才出现，不是第一次。要评估它的人应该测整个会话，而不是单个任务。

关于 Elasticsearch 兼容性的说法

XERJ 说 Elasticsearch 的通信协议，项目报告 1,371 项一致性测试通过，零失败、三次跳过。如果这站得住，那些已经针对 Elasticsearch 写好的工具稍作改动就能指过来，而那些一直花钱养集群来存几百万文档的团队，就有了退路。

针对 Elasticsearch 的 SSPL 许可发出的批评是公道的：SSPL 在 OSI 意义上不是开源，这对想在搜索引擎之上做产品的公司很重要。但“兼容”是一个光谱。Query DSL 的覆盖度、聚合、分析器行为，才是差异显现的地方，而一致性测试套件是唯一能知道你到底站在线哪一边的办法。

你该用它吗

如果你的代理处理的是内部代码、大型私有仓库，或者没有任何模型见过的日志和文档，那理由相当充分：一个本地的、Apache-2.0 的、兼容 ES 的索引，懂 tree-sitter 符号，还配一份诚实的基准。如果你的工作主要围绕公开库，你大概会发现 grep 加一份好的 ripgrep 配置同样有效，而且维护成本低得多。

如果你要从这个项目里带走一样东西，带走那种公开说明的习惯，而不是这个搜索引擎。一个会告诉你自己数字被夸大的工具，比一个告诉你它好四十倍的工具更值得关注。