XERJ.code 参考编码实战：让 Agent 用一次本地检索替代整轮 grep 重试循环

人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ 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 开源仓库中xerj-code参考编码技能的完整技术指南。它讲解一条与直觉相反的 Agent 工作流与其让不懂某个 API 的 Agent 反复猜测、编译、失败不如先把“已经有人写对过的实现”克隆下来用 XERJ 建成本地语料库并索引在写代码之前用一次检索拿到精确段落。读完本文你将掌握xerj corpus/xerj code这套二进制内置命令的完整用法、语料库与 Hub 清单的选择方法、四种检索模式与退出码契约以及源码级的工作原理与已被实测验证的适用边界。为什么查一次比猜十次便宜输出 token 与输入 token 的成本差一个不了解某 API 的 Agent 会走这样的循环猜测 API → 运行 → 失败 → 再猜。每一圈消耗的都是输出outputtoken而输出 token 恰恰是昂贵的那一种。xerj-code的思路是用查找替代循环克隆那些已经包含正确实现的仓库用 XERJ 索引在动手写代码前检索到目标段落。检索消耗的是输入inputtoken——单价更低、且可被缓存复用。这一交换是经过成本模型验证的完整的算术在 docs/case-studies/reference-coding/COSTS.md。以 Anthropic 官方列表价为参考价格会变动引用前需核对输入与输出的价差约为 5×而缓存读取的成本约为基础输入的 0.1×因此在 Opus 5 这类模型上缓存输入约 $0.50/MTok而输出约 $25/MTok相差约 50 倍。据此可推导出平价公式令C为每次任务新增的检索上下文 token 数L为一次被避免的重试循环所消耗的输出 token 数则检索在C × 输入价 L × 输出价时是划算的——未缓存时C 5L缓存命中时C 50L。换句话说一次产生 800 个输出 token 的失败重试足以支撑高达 4,000未缓存乃至 40,000缓存个输入 token 的检索上下文。这正是本方案往往占优的数学基础也恰恰是它必须被测量而非假设的原因检索若没有真正减少迭代次数就是纯损失——你为段落付了费却还是跑完了每一圈。被测量过的结论价值真实但边界清晰xerj-code的状态被写得很直白测量过价值真实但狭窄。完整案例研究真实 token 与真实美元见 docs/case-studies/reference-coding/CASE_STUDY.md其核心对比对象不是裸模型而是原生 Claude Code——同一个 Agent只是让它自己去 grep 源码。在三个 regime 下、同一 Agent、同一客观判据编译通过 通过隐藏测试模型无法回忆的不熟悉代码seal 契约、generational handle、lazy refill、特定哈希方案——跨 7 个专为测试构建的库、21 次运行native 与 xerj 均解决21/21xerj 比 native 少用 1.5× 输出 token、成本低 1.3×因为检索替代了 grep。纯记忆则失败 1/21且烧掉6.5× 的成本。这是决定性的胜利编译器能在重试循环中泄露 API 的名字却永远泄露不了契约。模型已记忆的代码任何流行公开 crate——哪怕是一张 256 值表或 protobuf 风格的 varint检索是纯开销。纯记忆最便宜注入大段参考甚至可能成为最差的臂因为模型会重新吐出喂给它的内容。因此结论非常明确当参考是模型未记忆的代码时使用本方案——你自己的私有/专有代码、内部 API、截止日期之后或小众的库。对于模型已熟知的公开库参考检索的成本大于收益。native 与 xerj 的差距随语料库规模增长而拉大grep 把整棵树拉进上下文检索只拉一段。自 #977 起整个循环已内置进xerj二进制——xerj corpus add/xerj corpus index/xerj code——外加供无 shell 的 Agent 使用的xerj_code_searchMCP 工具。旧的包装脚本xc-corpus.sh、xc-index.sh、xc.py已被移除你现有的~/.xerj-code语料库和索引无需任何改动即可继续使用见文末迁移章节。本仓库的固定语料库检索先行是强制要求在 xerj 仓库中对于非平凡引擎工作检索后再写码从 2026-08-06 起是必需而非可选项。每个语料库都有一个在 tools/xerj-code/hub/ 中固定提交、经许可审查的定义——xerj corpus add --from hub/name.json就能在任何机器上以与他人完全相同的提交重建它语料库项目用途xerj-searchlucene、tantivy、meilisearch、quickwit、sonic、elasticsearchFTS、BM25、postings、合并策略、拼写容错、段布局、ES wire 语义xerj-vectorqdrant、usearch、instant-distance、hnswlibHNSW 构建、近邻启发式、量化、过滤 kNNxerj-storagesled、fjall、redbWAL、刷盘 epoch、崩溃恢复、压缩、页分配xerj-columnarclickhouse列式存储、聚合执行、压缩编解码器、向量化扫描仅限参考approach-only的来源elasticsearchAGPL-3.0 / SSPL-1.0 / Elastic-2.0 三许可证与sonicMPL-2.0。绝不能把它们的代码复制进 Apache-2.0 的 XERJ对 ES 而言粘贴源码还会让项目公开的与 Elasticsearch 零代码共享声明变成谎言。meilisearch核心是 MIT但其Enterprise Edition 部分是 BUSL-1.1——复制前先检查文件头与路径。正确做法是阅读设计自己写实现。每个 manifest 的review.use字段标明仓库属于哪个桶tools/xerj-code/hub/README.md 解释了三种桶的定义。review.use的取值语义如下它在 hub/xerj-storage.json 这样的真实清单中逐仓库记录adapt-with-attribution宽松许可Apache-2.0 / MIT / BSD——可自由改编但仍需在引用处标注file:lineapproach-onlycopyleft 或 source-availableAGPL、SSPL、Elastic、BUSL、GPL、LGPL、MPL——阅读设计自己写代码绝不粘贴mixed宽松核心 受限部分如 Meilisearch 的 MIT 核心 BUSL-1.1 EE——复制任何东西前检查文件头与路径。Hub 语料库还是本地语料库两种语料库并存于同一本地节点回答不同类型的问题Hub 语料库本地语料库内容固定提交的公开资料某个库的源码、标准、法规、咨询源只有这台机器才有的文件你正在开发的项目、私有文档、导出使用时机需要一个你无法精确背出的细节时答案就在你自己的文件里时添加xerj corpus add --from ./slug.json然后xerj corpus index slugxerj autoindex folder查询xerj code slug 问题· MCPxerj_code_searchxerj search 词·xerj def 符号· MCPxerj_search对于你已经能精确陈述的事实两者都不要用对已记忆的内容检索就是开销见上文状态说明。Hub manifest 来自corpus-hub分支的 checkouttools/xerj-code/hub/slug.json无 checkout 时则来自其原始 URL。corpus index与code都要与一个运行中的节点通信curl -fsSLO https://raw.githubusercontent.com/xerj-org/xerj/corpus-hub/tools/xerj-code/hub/slug.json xerj corpus add --from ./slug.json # 最后一行提示next: xerj corpus index slug xerj corpus index slug # 结束输出corpus slug searchable: N records xerj code slug 问题 # 段落以文件路径和行号开头注意--from只读取本地文件v1.0.0-rc.95 不会去抓取 URL传入 URL 会得到no such manifest的答复。为手头项目挑选语料库按领域而非规模上面四个引擎语料库是本仓库的固定集合。完整的在线目录可浏览 hub.xerj.org每行一个语料库的llms.txt版本也在那里节点已加载的内容用xerj corpus list --url node查看。每个语料库都固定到某一提交并按来源逐一记录许可证。G7一个五问题检索门禁其套件在检索运行之前就已预注册只对部分语料库评过分每个 hub 页面都会标明。选型应依据项目领域而不是语料库大小。常用映射关系节选自 SKILL.md 全表项目是…从哪个开始为什么搜索/查询引擎xerj-searchpostings、BM25、合并策略、段布局、ES wire 语义向量搜索/ANNxerj-vector、faiss、annoyHNSW 构建、近邻启发式、量化、过滤 kNN存储引擎/KVxerj-storage、duckdb、rocksdb、leveldb、badger、lmdb、pebble、valkey-srcWAL、崩溃恢复、压缩、页分配LSM-vs-B 树分析/列式xerj-columnar、duckdb、arrow-rs、parquet-format、iceberg列式布局、编解码器、向量化扫描、表格式数据库服务器sqlite-src、postgres-src解析器、规划器、执行器消息/共识kafka-src、rabbitmq、nats-server、etcd-src、raft-rs、dragonboat日志压缩、投递语义、quorum/lease 正确性TLS/密码学/隧道rustls、openssl、s2n-tls、boringtun现代 TLS 实现、加固先例、常量时间模式压缩/序列化zstd、lz4、brotli、zlib-ng、snappy、protobuf、flatbuffers、capnproto、msgpack-c格式设计、分块/熵编码、零拷贝 schema协议/规范一致性openapi-spec、graphql-spec、json-schema-spec、w3c-css、whatwg-specs、ecma262、nats-protocol、kafka-protocol实现被评判的规范文本Rust 依赖安全审查rustsec-advisoriesrust-vulnspack每条公告一个文本记录受影响版本、修复版本、符号列表正则 DoS 先例redos-precedent634 条正则专用 ReDoS 公告病态输入、受影响函数、有界改写漏洞/弱点分类法mitre-cwe、mitre-capecCWE 弱点定义与 CAPEC 攻击模式在安全区块内要选两次——先生态系统后缺陷类别。同一 CVE 的公告存在于多个数据库先从与项目生态匹配的语料库入手Rust crate 用rustsec-advisories、PyPI 用pysec、Go 模块用go-vulndb、混合树或不明确时用超集ghsa-db当审查对象是正在查看的模式而非某个包如喂给用户输入的正则、某个密码或密钥管理调用点时切换到地层语料库redos-precedent、crypto-misuse-precedent它们更小、专为那一缺陷类别挑选于是机制本身病态输入、弱原语、修复它的有界改写能排到前面而不是被几千条泛泛的公告淹没。三条规则让选择保持诚实语料库只对未记忆的代码有帮助。对模型已熟知的流行公开库代码检索是开销——实测交叉点记录在案例研究数据中私有、内部、小众和截止日期之后的代码才是它决定性胜出的地方33 个被测量语料库上bare 20% vs 带语料库 98%。形态胜过规模。答案挤在一个巨型文件里3 MB 的单页规范、50 MB 的 JSON 包的语料库输给同一内容的每节一个文件镜像——整文件索引会跳过它无法分块的东西而近重复的包会挤占答案。Hub 的 G7 门禁正是为抓这一点而设未通过的语料库被降级并预注册修复方案而不是被填充成live。引用你改编过的东西。检索命中只是那个项目在其许可与约束下如何解决的证据——在注释里写file:line复制任何内容前先查 manifest 的review.use桶。实际踩过的运营陷阱/tmp下不能放任何东西。克隆位于~/.xerj-code/corpora/索引在~/.xerj-code/data可用XERJ_CODE_HOME覆盖根目录。数据目录放在/tmp会在重启后丢失整个语料库会静默检索不到任何内容。xerj corpus index corpus --fresh才是重建且永远不会让你失去可用的索引。它在现有索引旁边构建替代品——目录形如xc-corpus-bstamp-*并带一个位于~/.xerj-code/autoindex-state/corpus/的独立 autoindex--state-dir——验证通过autoindex 退出0或3且_count 0后用原子重命名把state/corpus.json切换到新索引然后才按精确名称删除旧索引。构建失败或返回空的构建会被移除旧索引、旧 state 文件与旧 state 目录原样保留。它不是xerj autoindex --fresh该命令从不转发这个标志那个标志只会丢弃 autoindex 的恢复日志一旦语料库代次已提交就会被拒绝——这正是--fresh曾在每个已索引语料库上失败的原因#930。节点答不上来的记录数绝不能读作零。计数是三态的一个数字、一个 404没有匹配的索引——真正为零、或Unknown超时、5xx、不可解析的回复。Unknown不授权删除或切换节点数不清现有索引就假定它是可用的、不让任何失败构建压过它数不清新构建就什么都不删、什么都不切。只有数字——或 404——才授权删除或切换。被中断的首次构建会被保留xerj code会明确告知。当构建在写入记录后失败、且没有可用索引可回退时命令会保留它而不是让语料库为空并在 state 文件中记录salvaged: true与真实的autoindex_exit。这种构建可能是部分的因此xerj code会在每次查询时向 stderr 警告覆盖率 INCOMPLETE——此时未命中不能作为代码不存在的证据——xerj corpus list也会标记该语料库。普通的xerj corpus index corpus会恢复它同前缀、同 state 目录完成后清除标记。普通的xerj corpus index corpus是原地更新。它针对已记录构建的前缀和 state 目录重新运行 autoindex因此增删改与重命名都能增量对账。state 文件故意有两个前缀。prefix永远是xc-corpus——整个命名空间任何按xc-corpus*通配的东西在重建之间持续可用。index_prefix是那个被验证的构建xerj code查询的正是它所以重建期间半成品替换永远不会泄漏进答案。重建期间两个构建同时存在节点会短暂持有语料库两份。大语料库要为磁盘预算。始终验证curl -s $URL/xc-corpus*/_count必须 0。命令本身会做并声明若你在脚本中围绕它编程请再验证一次。什么时候值得用当任务涉及别人已经正确写过的代码时使用不熟悉的库、框架或协议移植一个已有参考实现的算法在大型代码库中匹配既定约定任何你已经就同一个错误循环过两次的时候——那是猜测不再收敛的信号。不要用于只存在于本仓库的代码普通文件读取更便宜、一行式修改或你已了解 API 的情况。索引有固定的搭建成本两个工具调用就能完成的任务偿还不了它。完整循环xerj corpus add name git-url... # 克隆参考仓库每个领域一次 xerj corpus add --from manifest # ...或重建别人定义好的语料库 xerj corpus build name --recipe r # ...或将 RECORDS 收割成可移植 pack xerj corpus index name # 用 xerj autoindex 索引每个语料库一次 xerj code name 你需要什么 # 写代码前先检索每个任务任意时刻的状态xerj corpus list显示台账中的每个语料库、其索引前缀、是否已加载到本节点— loaded — N index(es)/— NOT loaded here (0 indices) — stale/other-server以及任何 INCOMPLETE 标记。1. 构建语料库按问题领域而非语言分组仓库。异步 Rust语料库应包含 tokio、hyper、tower解析器语料库应包含 nom、pest、tree-sitter。保持语料库小而锐利——什么都装的语料库检索起来就像没有查询的搜索引擎。xerj corpus add async-rust \ https://github.com/tokio-rs/tokio \ https://github.com/hyperium/hyper克隆是浅克隆--depth 1落在~/.xerj-code/corpora/name/。每次构建都会在旁边写出corpus.json——URL、完整 commit SHA 与许可证几百字节不含源码。这个文件就是可共享的语料库定义把它交给别人然后xerj corpus add --from their-corpus.json就能在他们机器上重建同样的提交已有克隆会被移到记录的 SHA两棵树完全一致。本项目使用的经过审查的定义在 hub/xerj corpus add --from hub/xerj-storage.json xerj corpus index xerj-storage语料库名与仓库名在触碰文件系统之前就被校验——含/、*、前导.或保留字的名称在解析期即被拒绝因为固定克隆的 checkout 会在该路径内执行git checkout --force。这一安全门在源码中的实现是 engine/crates/xerj-common/src/xccode/pathgate.rsvalid_corpus_name拒绝任何路径逃逸与通配符注入valid_repo_name要求^[A-Za-z0-9_][A-Za-z0-9._-]*$valid_sha则拒绝任何非完整 40 位十六进制 SHA——因为git fetch --depth 1 origin 短SHA会以couldnt find remote ref失败短 SHA 会让固定重建悄悄落在 tip 上与固定背道而驰。并不是每个语料库都是源代码。Record pack——公告、数据集、任何结构化数据——由 recipe 构建而非克隆xerj corpus build rust-vulns --recipe tools/packs/rust-vulns/recipe.toml xerj corpus add rust-vulns --from ~/.xerj-code/builds/rust-vulns/pack/rust-vulnsrecipe 声明来源、身份边同一个漏洞以 RUSTSEC/GHSA/CVE 到达时合并为 ONE 记录、合并优先级与派生字段产出的 pack 带校验和用与语料库定义相同的corpus add --from安装。来自他人的 pack例如每日发布的 rust-vulns releases在其 SHA256SUMS 上携带 ed25519 签名——用--verify-sig pubkey-file添加以在索引任何东西之前校验来源密钥与 recipe 一同发布绝不放进 pack。仓库内示例是 tools/packs/rust-vulns/。2. 索引它xerj corpus index async-rust这会针对本地 XERJ 实例--url/$XERJ_URL默认http://localhost:9200在进程内运行xerj autoindex。退出码 3 表示带着垃圾文件完成不算失败——任何真实仓库里总有些文件无法解析。把 0 和 3 都当作成功其他任何值才是真问题。节点必须可达离线什么都构建不了。3. 写代码前先检索xerj code async-rust graceful shutdown with a broadcast channelxerj code返回匹配的定义而不是字节窗口─── valkey/src/networking.c (score 12.68, BSD) [function addBulkStringToReplyIOV line 2635 — 366 of 272,498 chars] static void addBulkStringToReplyIOV(char *buf, size_t buf_len, ...) {这个行号就是全部意义所在。一条记录是一个完整文件所以排序只能告诉你哪个文件匹配定义则从索引已携带的symbols[]中定位。在此之前从 272 KB 文件中切出 8 KB 片段答案是否在其中纯粹是掷硬币——一个关于 null 回复的查询正确地把networking.c排到第一返回的却是它的许可证横幅因为addReplyNull在 1460 行。定位并阅读命名的定义、引用它如果顶部命中不相关就明说并回退到正常工作而不是强行套用。--full N把每段限制在 N 字符--full 0打印文件头并提示如何获取匹配的定义。--no-symbol回退到原始窗口只对完全没有符号的数据文件有用。段落选择的源码实现在 engine/crates/xerj-common/src/xccode/passage.rssymbol_passage用查询词对每个符号跨度打分符号名字中的命中额外加 25 分这是 Agent 最能据以行动的信号——查询提到addReplyNull就该返回 addReplyNullbest_window在粗粒度步长上为每个候选起点打分、取词项密度最高的窗口且只在整行对齐不损失查询证据时才做行对齐——历史教训是取文件头曾是本工具最严重的 bug检索排对了文件却交回了 21,461 个字符、其中查询词出现次数为零全是许可证横幅和#include行。provenance则从ax_path/ax_file/line字段生成file:line定位符绝不虚构行号。退出码xerj code区分未命中、损坏与未加载——脚本可围绕它编程退出码含义0有命中段落输出到 stdout1未命中——包括--json时hits.hits为空回退文案提示你回退到正常工作而不是重试2用法错误、节点不可达、传输失败、30 天过期拒绝、独立语义模式失败3语料库在state/中但本节点上有 0 个 live 索引——这不是 no match——语料库只是没有加载到这台服务器上。重新索引或把XERJ_URL指向持有它的节点这与姊妹命令xerj search刻意不同后者在空结果时退出0——不同的工具不同的契约。这套退出码三角形在 engine/crates/xerj-common/src/xccode/mod.rs 的CodeOutcome中实现并由run_code_query全程驱动台账缺失 → 退出 2 并指明修复命令超过 30 天且未传--stale-ok→ 拒绝退出 2cat_indices返回空 → 专属的未加载诊断退出 3检索零命中 → 显式的 miss 文案退出 1。检索模式默认是bm25。在两个语料库、十二条手工标注查询上的实测rust-textkv-oss (C)combinedtop-1top-3top-1top-3top-1top-3bm253/66/66/66/69/1212/12hybrid5/66/62/64/67/1210/12semantic4/64/62/63/66/127/12top-3 才是有效的指标——Agent 读的是k段而非一段——BM25 在上面满分且从不是任一语料库上最差的臂。它还快约 5×没有向量往返、没有 mapping 查询。BM25 的查询字段是实测选定而非拍脑袋的body, defs, title的平坦权重在 324 文件的 Rust 语料库上以 top-3 6/6 胜出symbols.name与裸*通配符被刻意排除前者让整个 multi_match 静默归零后者把所有分数压平到 2.0。字段解析与语义能力索引发现见 engine/crates/xerj-common/src/xccode/fields.rs。Hybrid 曾经是默认只因在rust-text上赢得 top-1——那是语料库特异的结论在 C 语料库上向量臂只触及 407 个索引中的 5 个issue #173融合把好排序与一个看不到 98.8% 材料的排序混在一起。只有当语料库有广泛的semantic_text覆盖且你确实在意 top-1 时才用--mode hybrid——并在信任它之前先测量它。xerj code rust-text lazy DFA cache eviction # bm25默认 xerj code rust-text lazy DFA cache eviction --mode hybrid # 向量RRF 融合 xerj code rust-text lazy DFA cache eviction --mode semantic # 仅向量自 #977 起 hybrid 是服务端融合一条原生顶层hybrid查询带{fusion:{method:rrf,k:60}}没有客户端排序合并——因此按命中、按臂的排名没了服务器不暴露它们每次 hybrid 运行都改以一句 arms-ran 说明开头例如[hybrid RRF(k60) — BM25 over 9 index(es), vector over 3 of 9]。在只有部分索引具备语义能力的语料库上融合查询只瞄准有能力的那部分说明会点名被排除的纯词法索引——把语义腿射向覆盖纯文本索引的通配符会让整个请求 400。RRF_K 60与混合查询体的构造在 engine/crates/xerj-common/src/xccode/mod.rs 中它发出引擎原生的顶层hybrid请求BM25 腿 semantic 腿融合由服务端完成。hybrid 的答案以一行实际运行的臂开头当向量臂无法运行时会明确说BM25 only — ...而不是假装。向量臂只在body被映射为semantic_text时工作而semantic查询对没有该映射的索引不会降级——它会让整个搜索以 400 失败并连带通配符中的其他索引一起遭殃。xerj code会先读 mapping、只把向量臂指向有能力的索引semantic_capable正是为此。Hybrid 还会跑一次 BM25 size-1 预检词法臂一无所获时答案是一个诚实的 miss退出 1——在词法 embedder 下向量近邻不是匹配的证据。xerj code从不请求highlight。在这台引擎上highlight 块会改变_score并打乱排序issue #177同一查询不带它 top-16/6带上只有1/6。既然段落现在来自symbols[]高亮器一无所获却毁掉排序。没有 shell用 MCP 工具不是每个 Agent 都能跑命令。同一管线就是第十一个 MCP 工具xerj_code_search见xerj mcp各客户端的注册片段在 llms 文档里。它的文本输出与xerj code的散文逐字节一致——同样的命中、同样的!!许可警告、同样的页脚——退出码三角形映射到 MCP 的布尔值上拒绝30 天过期、语料库不在台账、语料库未加载到本服务器、传输失败是isError: true且文本中带补救指引而未命中是isError: false——miss 是指导而非工具故障。警告随成功文本载荷走MCP 没有 stderr。licence_policy: strict额外从受限许可的命中上剥掉段落文本只保留定位符 许可 only-approach 警告。这个映射在 engine/crates/xerj-common/src/xccode/mod.rs 的CodeOutcome.is_error中定义恰好对需要行动的状态2 和 3为真miss 为假。让这套东西保持诚实的规则检索到的代码是证据不是权威。一段 passage 证明的是那个项目在它自己的约束下如何解决问题。依赖它时引用file:line并明说你是在改编而非复制。复制前检查许可。xerj corpus add把每个仓库的许可记录进corpus.json来自受限许可AGPL、SSPL、Elastic、BUSL、GPL 系、MPL、未知的每个命中都在其段落正下方携带警告行!! licence: adapt the APPROACH, do not copy the code。把 GPL 实现复制进宽松许可的项目是真问题不是技术细节。许可不兼容时改编思路、写自己的代码。许可证检测本身是个易错环节engine/crates/xerj-common/src/xccode/licence.rs 记录了它两种方向都错过的历史——Elasticsearch 的三许可证因正文含Apache License 2.0 compatible license字样曾被记为Apache-2.0修复先查受限短语sonic 的纯 MPL-2.0 因正文用 GNU GPL 定义 Secondary License 曾被记为 GPL修复标题先于正文。因此 Hub 中的 manifest 都携带人工填写的review块。过期索引比没有更糟。它返回已不存在的代码用虚假的信心把 Agent 送上死路。xerj code拒绝回答超过 30 天未更新的索引除非传--stale-ok改为重跑xerj corpus index corpus --fresh。这条 30 天上限是源码常量STALE_DAYS 30engine/crates/xerj-common/src/xccode/mod.rs且唯一的绕过途径就是显式参数——没有环境变量后门。永远不要把你正在工作的仓库索引进共享语料库。参考语料库是给别人的代码用的。混入自己的代码会让检索把你的错误当作先例返回。MEATL机器可读检索对 agent-to-agent 和 agent-to-tool 的交换xerj code --meatl每个命中输出一行机器可读记录——紧凑、可校验的格式在无人阅读的消息上削减输出 token。它明确不是给用户看的文本对人说话就用散文。语法ok ffile:line score12.34[ whylicence] # 每个命中一行 ok ffile:line rrf0.1234[ whylicence] # 原生 hybrid 分数 no qquery whyno-match-in-corpus # miss退出 1 mode arms-ran note # hybrid/semantic 说明行f是与散文块打印完全一致的溯源定位符path:linewhy是该命中仓库在corpus.json中记录的许可未知时省略。MEATL miss 保持退出 1 及其 no-match 记录。渲染在 engine/crates/xerj-common/src/xccode/render.rs 中与散文共用同一渲染器测试保证了两者逐字节一致。测量它从案例研究到 SWE-bench 挂钩已发布的数字、每次运行的原始数据与价格模型都在 docs/case-studies/reference-coding/CASE_STUDY.md是完整报告COSTS.md解释为何输出 token 是贵的那种data/results-*.json是每个数字背后的运行generated/是两个臂实际产出的代码。核心结果7 个无法回忆契约的领域、21 次运行bare 解决1/21并烧掉$21.9native 与 xerj 均 21/21xerj比 native 少 1.5× 输出 token、便宜 1.3×$3.38 vs $4.26、轮次少约 35%、比 bare 便宜 6.5×。跨五种语言16 次运行两者均 16/16xerj 用9,982 输出 token 对 native 的 26,4772.7×、$1.58 对 $3.27bare 只解 11/16最差时Java花掉 xerj 的278×token。一个具体对照同一 Java 任务bare 写了503 行append-log 仍失败于 seal 契约xerj 拿到参考后在103 输出 token内写出正确的 4 行解。测量挂钩本身csrun.py、专为测试构建的参考库、隐藏测试任务规格不随本仓库发布——它驱动的检索循环现已内置进二进制而 tools/xerj-code/swebench/ 中 SWE-bench 形状的挂钩gen_predictions.py以同样方式驱动xerj code跑同一 Agent 的三个臂——bare仅记忆、native自己 grep 语料树、xerj注入检索段落——任务判据是客观的生成的代码编译并通过模型从未见过的隐藏测试。报告中位数而非均值一次失控试验可以是另一次的 5×。两条决定结果是否有意义的规则花一个 token 之前先验证任务。注入参考正确的解必须通过和一个貌似合理的错误解——正确但二次复杂度或漏掉契约——后者必须失败。一个放行错误代码的基准什么也没测出来。不要在模型已记忆的代码上测量。它连 256 值表都能凭记忆复现检索于是表现为纯开销。诚实的试验床是从未进过训练集的代码——你自己的私有代码就是现实场景。会话之后xerj feedback想告诉维护者使用 XERJ 的真实感受一条命令就能起草报告并替你填上它可观测的事实版本、OS、索引了什么# 打开 PR只含报告的分支 提交 gh pr create xerj feedback --open-pr --used-for reference coding \ --verdict …哪些有效哪些无效… # 沙箱里无法推送起草并打印确切的 gitgh 命令 xerj feedback --dry-run --used-for reference coding --verdict …它只会自动填可观测的事实所有观点都留给你填——绝无编造的结论。只添加现场报告field report的 PR 不受 CLA 门槛限制。xerj feedback --help有完整契约。这是提供不是要求查询后自动打印的提示已被移除2026-09-18 指令——不得使用义务性语言也绝不向 Agent 索要 PR任何方向都不会写入标记文件。从包装脚本迁移#977能力移进了二进制你的数据什么都没动#977 之前#977 之后xc-corpus.sh name git-url.../xc-corpus.sh --from m.jsonxerj corpus add name git-url.../xerj corpus add --from m.jsonxc-index.sh name/xc-index.sh name --freshxerj corpus index name/xerj corpus index name --freshxc.py name queryxerj code name queryxc.py --listxerj corpus list你现有的~/.xerj-code语料库、state 文件与索引无需改动——同样的布局corpora/、state/、autoindex-state/、data/、同样的corpus.jsonschema、同样的xc-corpus索引命名空间、同样的退出码三角形。不再需要python3git仍然需要用于xerj corpus add。一个刻意的变化hybrid 融合现在在服务端因此按命中的按臂排名标注消失了arms-ran 说明承担了那个职责。快速上手指南与运行环境需要什么xerj二进制release 构建或curl -fsSL https://xerj.org/get | sh一个运行中的 XERJ 实例--url或$XERJ_URL默认http://localhost:9200例如xerj --data-dir ~/.xerj-code/data --insecuregit用于xerj corpus add。一切都在~/.xerj-code/下corpora/克隆 corpus.json、state/台账、autoindex-state/每次构建的日志、data/服务器目录——可用XERJ_CODE_HOME覆盖。全部持久化绝不放进/tmp。共享的是定义不是索引corpus.json是几百字节的 URL、commit SHA 与许可不含源码没有再分发问题在任何地方都能重建同一语料库。测试契约这些行为有对应的 scoped cargo 测试在engine/下用--profile ci-test运行cargo test --profile ci-test -p xerj-common xccode过期、许可、退出码三角形、hybrid 形态、段落、台账、-p xerj-autoindex xc_语料库生命周期、路径门、用法、-p xerj-mcp工具 schema 与 isError 映射、-p xerj-common xccode::manifesthub manifest 通过不可信输入门。这套工作流的底线判断是xerj-code的市场是用户自己的私有、专有或截止日期之后的代码——模型无法依赖记忆、而原生 Claude Code 必须爬一棵未索引的树的地方。对模型已记忆的公开库参考它赚不到任何东西——诚实的能力说明必须把这一点写清楚而本文的每一条规则都围绕这个边界展开。赞分享人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ 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 reference-coding 实战让 Agent 用一次检索替换整轮试错告别输出 Token 浪费XERJ reference coding 实战让 Agent 用一次检索替换整轮试错告别输出 Token 浪费 本文是一份可直接落地的工作流指南。它以开源人工智能搜索引擎本地部署后端MCP 服务XERJ 参考编码实战实测检索注入能否击败原生 Claude Code 的 grep 循环XERJ 参考编码实战实测检索注入能否击败原生 Claude Code 的 grep 循环 本文基于 xerj 仓库中完整的 reference codi人工智能搜索引擎本地部署后端MCP 服务XERJ 参考编码的成本模型用一次廉价的输入检索省下昂贵的输出重试轮次XERJ 参考编码的成本模型用一次廉价的输入检索省下昂贵的输出重试轮次 导读本文围绕 XERJ 参考编码reference coding背后的成本模型人工智能搜索引擎本地部署后端MCP 服务上一篇Allure2测试失败分析终极指南10个技巧快速定位错误堆栈和截图下一篇终极指南如何将Cover-Agent与GitLab CI深度集成打造智能化测试流水线创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考