人工智能搜索引擎本地部署后端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 corpus/xerj code命令与配套的xerj-code技能为核心教你为代码 Agent 建立参考语料库在写代码之前先检索真实实现从而把猜 API → 编译失败 → 再猜的输出 Token 消耗替换为一次廉价的输入 Token 检索。读完你可以立刻在本地启动 XERJ、把任意开源库克隆进参考语料、在每次编码任务前自动检索并引用file:line同时知道这套方法在哪些场景下不值得用。一、为什么需要先检索、再写码输出 Token 是最贵的 Token代码 Agent 面对陌生 API 时最常见的循环是猜一个方法名 → 运行 → 编译/测试失败 → 根据报错再猜。每一轮试错都在消耗输出 Token——按 COSTS.md 中记录的 Anthropic 定价模型Claude Opus 5 的输入是 $5/MTok、输出是$25/MTok5 倍而缓存读只有约 $0.50/MTok输出与缓存输入相差约50 倍。因此参考编码reference-coding的核心交易是检索值得做当且仅当它添加的上下文成本低于它避免掉的输出成本。输出是缓存输入的 50 倍所以一段被检索的代码片段拥有很大的预算空间——前提是它真的消除了后续迭代。OPENER_PROMPT.md 就是写给 Agent 的开场指令它会要求 Agent 把本地的参考语料索引好并在整个会话中自动地在写非平凡代码前先执行xerj code corpus what you need读取返回的真实定义后改写遇到同一错误循环两次时第三次必须先检索。二、开场指令原文一行行拆解OPENER_PROMPT.md 全文共 5 步它是本工作流的协议准备运行环境确保本地 XERJ 实例已启动、xerj-code技能可用。未安装时用curl -fsSL https://xerj.org/get | sh安装然后以xerj -d ./.xerj-data --insecure启动。按问题域建库观察当前项目的依赖与所涉及的领域找出已经解决这些问题的知名开源库用xerj corpus add name git-url...把它们克隆进参考语料库按问题域分组async、parsers、storage…而不是按语言分组。索引语料xerj corpus index name其内部执行xerj autoindex。每次任务先检索对每个编码任务在写非平凡代码之前先运行xerj code corpus what you need读取返回的实现并改写依赖时标注file:line复制前检查许可证。若检索无结果明说并回退到正常工作同一错误循环两次后第三次必须先检索。保持索引新鲜参考变更时重新索引拒绝使用过期索引。注意文档中的xerj corpus add/xerj corpus index/xerj code是 #977 之后的二进制内置子命令在此之前它们是对应xc-corpus.sh/xc-index.sh/xc.py三个包装脚本迁移对照见 tools/xerj-code/README.md。三、完整命令环从建库到检索的五个动作在 tools/xerj-code/SKILL.md 中整个循环被归纳为一条命令链xerj corpus add name git-url... # 克隆参考仓库每个领域一次 xerj corpus add --from manifest # ……或重建别人已定义并审校过的语料 xerj corpus build name --recipe r # ……或用 recipe 把记录收割成可移植 pack xerj corpus index name # 用 xerj autoindex 建立索引每个语料一次 xerj code name what you need # 写码前检索每个任务执行3.1 建库按问题域分组保持小而锐利xerj corpus add async-rust \ https://github.com/tokio-rs/tokio \ https://github.com/hyperium/hyper克隆是浅克隆--depth 1落在~/.xerj-code/corpora/name/。关键原则按问题域分组而非按语言——async Rust语料装 tokio/hyper/towerparsers语料装 nom/pest/tree-sitter。一个什么都装的语料检索起来就像没有查询的搜索引擎。3.2 可移植的语料定义corpus.json与--from每次xerj corpus add都会在旁边写下一个corpus.jsonURL、完整 40 位 commit SHA、许可证几百字节不含任何源码。这个文件就是可共享的语料定义{corpus:xerj-storage,cloned_at:2026-08-06T20:24:00Z,repos:[ {repo:sled,url:https://github.com/spacejam/sled,licence:Apache-2.0/MIT, sha:e449d17111f4a097e1c66b6db241962ccb6a4136,files:70,bytes:1322994} ]}把它交给任何人xerj corpus add --from their-corpus.json就能在对方机器上以完全相同的 commit重建语料已有克隆会被精确移动到记录 SHA本地修改和未跟踪文件被丢弃。SHA 必须是完整 40 位因为git fetch --depth 1 origin e449d17短 SHA会报couldnt find remote ref而完整 SHA 可以。本仓库内已审校的语料定义见 tools/xerj-code/hub/例如xerj corpus add --from hub/xerj-storage.json xerj corpus index xerj-storage3.3 索引xerj corpus index与退出码语义xerj corpus index async-rust它在进程内对本地 XERJ 实例执行xerj autoindex--url/$XERJ_URL默认http://localhost:9200。退出码 3 表示带垃圾文件完成不是失败——任何真实仓库里总有不可解析的文件把 0 和 3 都当成功其余才是真失败。节点必须可达离线无法构建。需要重建时用xerj corpus index corpus --fresh它在现有索引旁边构建替换索引验证成功autoindex 退出 0 或 3且_count 0后原子换名切换再按精确名称删除旧索引。失败的构建会被移除旧索引、旧状态文件原样保留。索引本身很快案例研究中 102k 条记录的novel-libs树约 10 秒完成索引。3.4 检索xerj code返回的是定义不是字节窗口xerj code async-rust graceful shutdown with a broadcast channel返回的是匹配的定义例如─── 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[]中定位。在此之前272KB 文件里截取 8KB 片段能否命中答案是抛硬币——关于 null 回复的查询正确排到networking.c却返回了它的许可证横幅因为addReplyNull在第 1460 行。xerj code的退出码把无匹配、故障、未加载区分开便于脚本化退出码含义0有命中passages 在 stdout1无匹配——包括--json返回空hits.hits回退提示是让你回退到正常工作不是重试2用法错误、节点不可达、传输失败、30 天过期拒绝、独立 semantic 失败3语料在state/中但本节点上有 0 个存活索引——这不是无匹配只是语料没加载到这台服务器四、常用参数与检索模式xerj code的完整参数在 engine/crates/xerj-common/src/xccode/mod.rs 中定义默认值与当年的xc.py完全一致k5、bm25、full800、symbol 开启。参数默认说明--mode bm25\|semantic\|hybridbm25检索模式见下文表格--full N800每个 passage 的字符上限--full 0为文件头模式前 400 字符明确标注用于无符号的数据文件--no-symbol关闭回退到原始字节窗口仅对完全没有符号的数据文件有用--stale-ok关闭默认拒绝回答超过 30 天的索引STALE_DAYS 30定义于 xccode/mod.rs除非显式放行--json关闭输出原始搜索 JSON含空结果--meatl关闭每命中一行机器可读输出ok ffile:line score12.34[ whylicence]检索模式的实测选择来自 tools/xerj-code/SKILL.md 中两个语料、12 条手工标注查询的测量| | rust-text | | kv-oss (C) | | combined | | |--|--:|--:|--:|--:|--:|--:| | | top-1 | top-3 | top-1 | top-3 | top-1 | top-3 | |bm25| 3/6 | 6/6 |6/6| 6/6 |9/12|12/12| | hybrid |5/6| 6/6 | 2/6 | 4/6 | 7/12 | 10/12 | | semantic | 4/6 | 4/6 | 2/6 | 3/6 | 6/12 | 7/12 |top-3 是实际有效指标Agent 读的是 k 个 passage不是 1 个而 BM25 在 top-3 上完美且从不是最差臂还快约 5 倍。hybrid 采用服务端原生hybrid查询、RRF 融合k60即 xccode/mod.rs 的RRF_K仅在语料有广泛semantic_text覆盖且你特别关心 top-1 时使用。另有两条已知约束xerj code从不请求highlight该引擎上 highlight 会改变_score并重排结果issue #177同一查询无 highlight 时 top-1 6/6有则 1/6semantic 臂只对body映射为semantic_text的索引生效否则整个请求 400。五、许可证纪律检索结果是证据不是权威xerj corpus add会为每个仓库记录许可证并把 AGPL/SSPL/Elastic/BUSL/GPL 家族/MPL/未知等受限许可证的命中打上警告行!! licence: adapt the APPROACH, do not copy the code。许可证检测是文本匹配启发式确实出过错ES 的三重许可证被误记为 Apache-2.0sonic 的 MPL-2.0 被误记为 GPL所以 tools/xerj-code/hub/ 中的清单都带人工填写的review块review: {spdx: AGPL-3.0-only OR SSPL-1.0 OR Elastic-2.0, use: approach-only, by: xerj-org, at: 2026-08-12, note: Triple-licensed; the detector reports only the first match.}use三档adapt-with-attributionApache-2.0/MIT/BSD可自由改写但仍须标注file:line、approach-onlycopyleft/源码可用读设计、写自己的代码、绝不粘贴、mixed宽松核心 受限部分如 Meilisearch 的 MIT 核心 BUSL-1.1 企业版复制前查文件头。XERJ 本身是 Apache-2.0把不兼容许可证的实现贴进来是真问题。三条纪律写在 SKILL.md检索结果是证据不是权威——它只证明那个项目在自己的约束下怎么解决的依赖时标注file:line并明确说明是改写而非复制复制前查许可证过期索引比没有更糟——它返回已不存在的代码带着看似权威的来源把人带进死路xerj code默认拒绝回答 30 天以上旧索引正确做法是重新xerj corpus index corpus --fresh。六、无 Shell 的 Agentxerj_code_searchMCP 工具不是每个 Agent 都能跑命令。同一套管线的 MCP 化版本是xerj_code_search见 engine/crates/xerj-mcp/src/lib.rs文本输出与xerj code逐字节一致。退出码三角被映射为 MCP 的布尔值30 天过期、语料不在台账、语料未加载、传输失败等拒绝是isError: true文本里带补救说明而无匹配是isError: false——miss 是指导信息不是工具故障。licence_policy: strict还会从受限许可证命中里剥离 passage 文本只留定位符 许可证 警告。七、源码级的实现原理7.1 检索语义的单一实现xerj-common::xccode#977 之后参考编码循环的全部语义收敛进 engine/crates/xerj-common/src/xccode/mod.rs 一个纯实现CLI 与 MCP 从同一个渲染器输出逐字节一致的 prose每个契约30 天过期拒绝、受限许可证警告、未加载诊断、退出码三角只有一处归宿和一套测试。模块布局state—state/corpus.json台账读取、过期、不完整覆盖警告、原子写入licence— 受限许可证元组 克隆时检测器manifest—corpora/corpus/corpus.json读写 hub 清单pathgate— 所有 manifest 派生路径在破坏性操作前通过的硬性门禁fields— 映射解析后的multi_match字段 semantic 能力索引发现passage— 符号 passage / 最佳窗口 / 文件头选择render— 唯一的输出渲染器prose MEATLHTTP 被抽象成 3 方法的XcHttptrait纯核心不依赖任何客户端xerj-autoindex用阻塞Es客户端实现xerj-mcp用 reqwest 实现。混合检索发出引擎原生顶层hybrid查询让服务器融合融合逻辑不在这两层任何一边。7.2 索引侧符号与签名如何进入可检索字段xerj autoindex对源码文件抽取符号/定义元数据经 tree-sitter写出symbols结构化数组{name, kind, line}与defs每符号一行kind name换行拼接让 BM25 能匹配查询——见 engine/crates/xerj-autoindex/src/extract/code.rs 的模块文档。xerj code正是从symbols[]定位定义行号这是返回定义而非字节窗口的机制基础。7.3 曾验证过的服务端增强诚实测量的无效SERVER_UPLIFT_SCORECARD.md 记录了一次值得注意的诚实测量给服务器加签名 标识符子词分解getHTTPResponse→get http response以增强defs在 doc-comment 丰富的语料上 16 条查询的排序逐字节不变——因为库文件自带模块级 doc-comment 描述行为扁平 BM25 已饱和到 top-1没有可移动的空间。在剥离注释的 terse 语料上它甚至轻微稀释 BM25。修复方案把增强放进独立低权重字段defs_expanded检索时defs_expanded^0.5最终做到了零回归加一处增益per tick refill→ cadence 从缺失到 #1。这组实验的稳健结论是检索 vs 不检索的巨大收益两个服务器版本都能等量交付而服务端微调在真实查询上不改变排序。八、这套工作流的价值边界什么情况下不值得用8.1 官方案例研究给出的答案SUMMARY.md 与 CASE_STUDY.md2026-08-05 完成六条赛道、五种语言、真实 token 与真实美元把边界画得很清楚价值由模型是否已记忆决定且界线锐利。模型未记忆的代码7 个带不可回忆契约的领域21 次运行纯记忆bare只解出1/21且烧掉$21.9xerj与 native同一个 agentic Claude Code一个注入检索片段、一个自己 grep都解出21/21xerj比 native少 1.5× 输出 token、便宜 1.3×比 bare便宜 6.5×$3.38 vs $21.9。编译器能泄漏 API名称但永远泄漏不了契约。五种语言、16 次运行xerj 与 native 都解 16/16xerj 用 9,982 输出 token 对 native 的 26,4772.7×$1.58 对 $3.272.1×bare 解 11/16且最高烧到 xerj 的278×tokenJava。具体例子一个 Java 任务上 bare 写了 503 行 append-log 仍败在 seal 契约上ledger-checkpoint-bare-FAIL.javaxerj 用 103 输出 token 写了 4 行正确解ledger-checkpoint-xerj-1.java。已记忆的公开代码甚至一张 256 值量化表检索是纯开销裸记忆最便宜注入大段引用甚至可能成为最差臂——因为模型会把塞给它的东西重新输出一遍。原始逐次运行数据在 docs/case-studies/reference-coding/data/两臂实际生成的程序在 docs/case-studies/reference-coding/generated/。原始数据印证了上述数字以 results-sift.json 的 sift-build 为例bare 第一轮 30,828 输出 token 仍编译失败而 native 以 929、xerj 以数百 token 一次通过。8.2 一个直观对照同一个任务三种做法sieve-member带 Kirsch–Mitzenmacher 双重哈希与settle-before-sense封印的 Bloom filter任务中bare 无法读取 crate只能从编译器报错猜 API写出一段自述注释vendoredsievecrate source is not readable from this session…the calls below are written against the most likely names and backed by fallback traits完整 282 行见 sieve-member-bare-FAIL.rs最后仍然测试失败——猜中了 API 表面却猜不中哈希方案。而 xerj 拿到注入的参考后写了 8 行sieve-member-xerj-0.rs注释里明确写着sensepanics unless the sieve has been sealed first——它从 passage 中学会了封印契约这正是 bare 永远无法恢复的东西约 670 输出 token一轮正确。8.3 实测的什么时候不值得清单来自 COSTS.md无关检索语料选错 → passage 只加 token、误导 Agent、可能增加迭代。这是最常见的失败。从不循环的任务本来一次就能写对的每个检索 token 都是浪费。缓存敌对的放置把检索片段注入到稳定内容之前会使缓存前缀失效、整个对话按全价输入重新计费检索上下文应放在最后一个缓存断点之后。一次性任务的分摊克隆 索引有固定墙钟与磁盘成本两三次工具调用能完成的任务还不上本。过期索引见上文比没有检索更糟。SKILL.md 因此给出了明确使用时机陌生库/框架/协议、移植已有参考实现的算法、在大代码库中匹配既有惯例、以及任何同一错误已循环两次的时刻——那是猜测不收敛的信号。相反只在本仓库内存在的代码普通读文件更便宜、一行改动、或你已知的 API都不用检索。九、开场指令已被独立验证OPENER_VERIFICATION.md 记录了将开场指令逐字作为全新 Claude Code Agent 指令、再由独立验证者复核不信任执行者报告亲自检查文件系统与 XERJ、编译并测试输出的过程场景运行中的 XERJ 在:9200xerj-code技能可用本地有一个参考库sift一个刻意不用new()/push()/top_k()、而是用两阶段 seal 门控 count-min sketch 的真实 Rust crate。任务用 sift 的真实 API 实现top3必须检索、不得猜测。开场指令驱动 Agent 完成了三件事① 索引参考3 条记录上线经_count → 3确认② 写码前检索查询返回sift/src/lib.rs读取定义并使用真实 API③ 写出尊重seal-before-read 契约的正确代码。独立裁决WORKS四项全过——indexed ✓ · retrieved ✓ · used_real_api ✓ · compiles_and_correct ✓。验证者新建 cargo crate 依赖真实 sift 路径放入生成的solution.rs运行cargo test --release2 passed0 failed。为什么这是确实用了检索的强证据sift 的定义特征是 seal 门控的两阶段契约读前未 seal 会 panic、seal 后 absorb 会 panic、crest 在 seal 时物化刻意排斥常规new/push/top_k形状。凭记忆的模型不可能发明这套契约和 width-first/depth-second 的furnish签名能尊重它的代码必定读过被索引的源码。验证中生成的最终程序原文逐字use sift::Sift; /// Return the 3 most frequent keys in stream as (key, count), heaviest first. pub fn top3(stream: [u64]) - Vec(u64, u32) { let mut sketch Sift::furnish(4096, 4); // width first, then depth for key in stream { sketch.absorb(key); } sketch.seal(); // mandatory before any read sketch.crest(3) }十、给读者的落地清单安装并启动curl -fsSL https://xerj.org/get | sh然后xerj -d ./.xerj-data --insecure生产环境去掉--insecure并配置鉴权。建库xerj corpus add name git-url...按问题域分组或xerj corpus add --from tools/xerj-code/hub/name.json直接复用 hub/ 中已审校的语料。索引xerj corpus index name0 与 3 都算成功参考变更或索引超 30 天后用--fresh重建。写码前检索xerj code name what you need读取定义、标注file:line、检查许可证无 Shell 时用xerj_code_searchMCP 工具xerj mcp。诚实使用只在模型未记忆的代码上依赖它已记忆的公开库、一次性小任务、本仓库内部代码直接写。把同一错误循环两次后必须先检索写进你自己的 Agent 指令——这就是 OPENER_PROMPT.md 教给你的会话纪律。相关深入材料完整方法学与全部数字见 CASE_STUDY.md成本算术见 COSTS.md技能全文见 tools/xerj-code/SKILL.md语料定义见 tools/xerj-code/hub/契约测试从engine/运行cargo test --profile ci-test -p xerj-common xccode。赞分享人工智能搜索引擎本地部署后端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 参考库索引实战让编码 Agent 写代码前先检索到机制实现reference codingXERJ 参考库索引实战让编码 Agent 写代码前先检索到机制实现reference coding 导读 参考库编码reference coding人工智能搜索引擎本地部署后端MCP 服务用 XERJ autoindex 为 Coding Agent 建立可检索的 Monorepo 索引一次建索引查询替代逐文件读取用 XERJ autoindex 为 Coding Agent 建立可检索的 Monorepo 索引一次建索引查询替代逐文件读取 本指南围绕 XERJ 的人工智能搜索引擎本地部署后端MCP 服务XERJ 参考编码的成本模型用一次廉价的输入检索省下昂贵的输出重试轮次XERJ 参考编码的成本模型用一次廉价的输入检索省下昂贵的输出重试轮次 导读本文围绕 XERJ 参考编码reference coding背后的成本模型人工智能搜索引擎本地部署后端MCP 服务上一篇如何让小爱音箱秒变AI学霸MiGPT终极改造指南下一篇MagicSurfaceView性能优化指南线程分组与渲染效率提升终极教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考