XERJ：讓 AI 智慧體少燒 token 的本地搜尋引擎

现在的 coding agent 有一个很常见的毛病：进入陌生项目后，只能靠 grep、sed 和逐个打开文件来摸清情况。每读一个文件就消耗一批 token，读错了方向还要再来一轮。项目越大，这笔开销越明显，模型也越容易在无关内容里迷失。XERJ 针对的正是这个痛点。它是一个用 Rust 写成的本地 AI 搜索引擎，定位很清楚：让智能体先通过索引认识数据，再按需取回精确内容，而不是靠蛮力去扫。在生态位置上，它不是又一个向量数据库，而是介于传统全文搜索引擎和智能体工具链之间的一层。它兼容 Elasticsearch，所以现有客户端可以直接接入，不必改写；同时它又面向 MCP 和 skill 这类智能体接入方式。项目主题标签里出现了 bm25-search，说明传统的词频排序仍是它的基础，文档中还有专门的向量页面，可见它并不排斥语义检索。它的主要用例被官方称为参考编码：让智能体先找到与任务最接近的开源仓库并建立索引，再借鉴别人的解法去写代码。

从核心能力看，最重要的是 autoindex。官方描述是：一条命令就能为代码、文档、日志和 PDF 建立索引，之后可以用于搜索、RAG、安全审计和智能体记忆。这些场景共用同一套索引，意味着团队不必为每种用途各搭一套系统。搜索结果以排序后的片段返回，并带有 file:line 位置，智能体拿到的是可以直接引用的出处，而不是整篇文件。除了 search，还有 def 命令，用来做跳转定义，直接给出文件行号和函数签名，这对代码导航很实用。另一个值得注意的设计是 xerj gain 命令，它会汇报工具到底帮你做了什么，而且强调是实际计数，不是估算。很多效率工具只讲概念，这种可核对的统计更容易让人信服。至于效果，描述中给出的口径是比 grep 少用 40 倍 token；在一项受控研究里，编码智能体的输出 token 降低 2.7 倍，解决率仍是 16/16；日常使用者的反馈则大约是 5 倍。三个数字的口径各不相同，读者应分开看待，不宜混为一谈。

官方还提到，这足以让更小、更便宜的模型胜过依赖记忆写代码的更贵模型。上手路径相当短。官方给了两条路：一是把一段提示词交给智能体，让它自己读 llms.txt 并完成安装、索引和参考编码的配置；二是自己动手，用 curl 安装脚本，再启动 xerj 服务，运行 xerj init 把它接入 Claude Code 或 Cursor，最后用 xerj autoindex 指向项目目录。之后就可以用 xerj search 提问，比如询问某个项目里日志段是如何轮转的。Windows 用户和想手工核对安装的人，README 里另有说明。文档方面，项目提供了命令行、查询语法、智能体记忆配方、向量检索、基准测试和安装等多个页面，还提供了面向模型阅读的 llms.txt，对智能体友好。需要特别留意的是 --insecure 参数。它会关闭 TLS 和 API key 认证，任何能连上端口的调用方都是超级用户，可以读取和删除所有索引，包括每个 /_memory 命名空间。官方的定位是单人开发机使用：新节点默认只绑定 127.0.0.1，在其他网卡上用明文绑定则拒绝启动，除非明确允许。

安全模型写在 docs/SECURITY_MODEL.md 中，上手前值得先读一遍。XERJ 的意义在于，它把「让智能体少读、读准」这件事做成了独立的基础设施。当 agent 成本变成团队的实际账单，把检索从模型的上下文窗口里移出来、交给一个可计数、可复用的索引层，是一条务实的思路。兼容 Elasticsearch 也降低了迁移门槛，已有的运维经验和客户端库可以继续使用。项目采用 Apache-2.0 许可，社区方式也有些特别：官方希望使用者提交一份简短的使用报告，作为参与社区的凭证，并明确欢迎人类和智能体两类参与者。这种做法能积累真实反馈，但报告的质量与口径能否统一，还需要观察。风险同样明确。其一，效果数字来自项目方的研究和用户自述，在自己的代码库上是否同样成立，需要自行测量，好在 xerj gain 提供了计数手段。其二，索引会汇集代码、日志和智能体记忆，一旦安全配置失当，暴露面会比较大。其三，让智能体自动下载并索引外部开源仓库，会带来许可证和来源可信度的问题。接下来值得关注的是基准测试的公开程度、向量检索的成熟度，以及在更大规模、多人协作环境中的认证与权限设计。