XERJ：让编程智能体检索代码而非逐文件读取

为什么智能体总在「读文件」上浪费上下文

用 AI 编程智能体改一个小函数，它却把整个文件甚至整个目录读进上下文——这是很多开发者熟悉的场景。据 B 站「每日 GitHub 快报」第 598 期介绍，本地 AI 搜索引擎 XERJ 试图改变这一工作方式：与其让智能体逐个打开文件，不如先把项目建成索引，让它像人查资料一样直接检索出相关片段。

这一思路的价值在于上下文预算。智能体的上下文窗口有限，把整文件塞进去不仅昂贵，还会稀释真正有用的信息。XERJ 把「读文件」替换为「检索片段」，让智能体在上下文之外定位代码。

XERJ 本地索引示意

上下文窗口指大模型单次推理能接收的 token 总量上限，输入（系统提示、对话历史、工具返回内容）与输出共享这一预算。智能体每读取一个文件，其内容就整体占用窗口，可用的推理空间随之减少。窗口被大量无关代码占满后，模型对关键信息的注意力会被稀释，还可能出现「中间遗忘」现象，即位于长上下文中间位置的内容更容易被忽略。这正是检索式上下文注入要解决的问题：只把与当前任务相关的片段放进窗口，把有限的 token 留给推理本身。

XERJ 是什么：跑在本地的代码搜索引擎

按照视频中的描述，XERJ 是一个跑在本地环境中的 AI 搜索引擎，专门为自己的代码和文档建立索引，供编程智能体直接查询。

它支持索引的对象不只限于源代码，还包括文档、日志和 PDF，通过一条 XERJ Auto Index 命令即可完成建索引。这意味着智能体的检索范围从单一代码库扩展到项目相关的各类资料，处理私有、内部或不熟悉的代码库时收益最为明显——这类场景恰恰是智能体最缺乏先验知识、最容易盲目翻文件的地方。

由于索引建立在本地，代码不必上传到外部服务，这对内部项目是一个现实的考量点。

代码索引与代码检索和传统关键词搜索的区别在于，索引阶段会把代码切分成函数、类、注释块等语义单元，并为每个单元生成向量表示或倒排索引；查询时按语义相似度或关键词匹配返回最相关的片段，而不是整份文件。这类系统通常需要定期重建索引以跟上代码变更，索引质量直接决定检索召回率。本地运行意味着嵌入模型和索引库都部署在开发机上，查询请求不出内网，适合处理不能外传的私有代码。

接入方式与返回结果

接入成本被刻意压低。视频介绍，用 XERJ Init 一条命令就能把它接进 Claude Code 或 Cursor 等主流编程智能体工具。

一条命令接入 Claude Code 或 Cursor

检索结果的呈现方式同样关键：返回内容直接带 File 和 Line 信息，也就是文件路径与行号。对智能体而言，这比返回一大段无出处的文本更实用——它可以据此精准跳转到目标位置，而不必再次全量读取文件。

File 与 Line 信息指检索结果中标注的源文件路径和行号范围，相当于给智能体一个可直接定位的坐标。多数编程智能体具备按行号读取文件片段的能力，例如只读取第 120 到 180 行，而不必加载整个文件。返回带行号的引用还能让智能体在后续编辑中准确落到目标位置，减少因缺少位置信息而重复全量读取文件的情况，这也是检索式方案能显著压缩 token 消耗的机制之一。

实测数据：Token 消耗的量级差异

视频给出的核心量化结论是：实测输出 Token 约为 Graph 工作流的 1%。需要说明的是，原始素材对这一数据的表述重复出现且措辞不够完整（「1%日期」应为口播转录误差），这里只能确认「1%」这一量级对比，具体基准工作流的细节未在素材中展开。

即便只看量级，这个数字也指向一个明确的方向：在智能体工作流中，检索式上下文注入相比图结构式的全量遍历，可能带来数量级的 Token 节省。当然，单一来源的实测数据仍需更多独立验证，读者不宜将其视为普适基准。

Graph 工作流在这里指以图结构组织代码或知识的工作流：先把仓库解析成节点（文件、函数、类）与边（调用、引用、继承）构成的图，智能体沿图遍历来定位相关代码。这类方法定位精度较高，但遍历过程往往需要多轮工具调用，每轮返回的内容都会累加到上下文中，token 开销随之放大。文中「1%」的对比正是把这种多轮图遍历的累计输出与单次检索返回的片段量级放在一起比较，因此只能作为方向性参考，不能等同于同等任务下的普遍比值。