人工智能搜索引擎本地部署后端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 现场报告user-feedback/16-agent-field-reports/2026-08-18-token-benchmark-harness.md一位 AgentClaude Opus 5 / Claude Code在 2026-08-18 受命验证检索比 grep 节省 token这一公开主张最终没有急着交出漂亮数字而是先建了一套带盲评、对账与校准的测量 harness。本文以该报告为核心骨架结合仓库中完整落地的 benchmarks/grep-vs-retrieval-lucene 目录逐层拆解这套 harness 的设计动机、运行方式、诚实性防线与试点结论。读完你会掌握为什么token 节省这类数字极易被操纵、如何用三臂对照 盲评 缓存中性成本构造可信测量以及如何把一次失败的试点变成比胜利更有说服力的证据。一、任务背景为40% token 浪费在 grep这句话建一个测量装置报告要测量的目标声明用户原话等待数据修正是your claude code / codex wastes 40% tokens just on grep/sed files; XERJ reduces it many times.这句话有两个互相独立的半句任何一半都可能单独被证伪半句 A40% 的 token 花在 grep/sed/read 上半句 BXERJ 能把 token 消耗减少很多倍。报告的原始动机是为一条营销推文产出数字。但第一次真实运行就暴露出这类基准最典型的陷阱——先有数字后验正确性。本文的主角不是XERJ 到底省了多少 token而是如何测量才不会被一个好看的数字骗到。这套测量装置在仓库中的完整实现位于 benchmarks/grep-vs-retrieval-lucene。它的 README 开宗明义地写着harness only. No results are published here yet——测量矩阵尚未全部跑完因此在全部运行被分级之前目录中刻意不放results.json、runs/或logs/。这正是该目录与一般 benchmark 目录的最大区别在结果被盲评之前没有结果可以被引用。这份 harness 还补上了 docs/case-studies/reference-coding/CASE_STUDY.md 里点名指出的缺口——测量 harness三臂 runner、专用参考库、隐藏测试任务规范不在本仓库中只有输出在。这份就是那个被交付出来的 harness。二、What worked索引 6,012 个 Lucene 文件xq返回带path:line的评分命中报告的第一段经验很朴素索引 Lucene 源码树6,012 个文件并查询符号没有任何意外。索引后检索臂拿到的是一个名为xq的检索工具。它返回的不是文件名列表而是带真实path:line的评分命中包括符号类型、签名和函数体。这意味着检索臂可以把实际实现直接交到 Agent 手里而不是给一个文件名让 Agent 自己去翻文件。这正是检索 vs grep之争的核心差异grep 给你的是命中的行索引给你的是命中的符号及其上下文。xq的实现见 benchmarks/grep-vs-retrieval-lucene/xq它是一个故意迟钝的查询工具接受模型提供的任意自由文本查询跑一个固定的 ES 查询模板multi_match于code、name_textboost 3、sigboost 2、doc字段minimum_should_match: 1返回符号级命中path:line、kind、签名和函数体每次命中代码上限1,600 字符MAX_CODE_CHARS 1600防止单次调用把整个语料库倒进上下文默认k5范围被钳制在 1–10。设计上最重要的一条约束写在xq的 docstring 里如果这个文件包含针对特定问题的逻辑基准就被作弊了所以它必须保持通用。没有任何逐题手写的查询、没有针对特定答案的 rerank。这个通用性是整个对照实验有效性的前提——如果检索臂拿到的是人肉调过的查询测量就变成了展示我们多会调 ES。三、What bit me第一次运行就产出了 35%——一个既漂亮又毫无价值的数字报告最核心的教训是这一段首次运行native 64,487 tokens vs xerj 42,068。这是一个可以引用的 35%但它一文不值因为两个答案都还没有被分级——更便宜的错误答案是一种损失不是胜利。这组数字在 benchmarks/grep-vs-retrieval-lucene/README.md 的试点小节中得到了完整复现n1 个问题每臂 1 次重复两臂都答对了 q01 的 256指标nativexerjbilled tokens 总计64,48742,068工具调用次数2GlobGrep1xq估算的工具输出 token1451,072工具占 billed token 比例0.5%5.1%缓存中性成本$0.3283$0.2153原始成本$0.0999$0.2345这份数据至少证伪了半句 A 在试点上的表现在一个目标精准的问题上native 臂只花了约 145 个 token 在 grep 输出上占 billed token 的 0.5%远不是40%。两臂真正的成本大头是每次 API 调用都要重新计费的固定 ~24k token 系统提示 工具定义native 3 次调用 vs xerj 2 次。XERJ 在这里的 token 优势约 1.53×主要来自更少的回合数而不是grep 输出很大。这也解释了报告的结论为什么如此坚决token 节省数字可以被答得更差轻易地操纵。一个不检查正确性的 token 基准衡量的是错误的东西——它奖励放弃或幻觉。所以最终构建的 grader 被设计成拒绝给未分级的运行打分报告为 UNKNOWN因为默认路径会产出一个没有正确性检查支撑的好看数字。四、三臂对照native / xerj / hybrid谁都不能被暗中照顾harness 的核心是三臂对照benchmarks/grep-vs-retrieval-lucene/run.sharm工具cwd代表什么nativeGrep, Glob, Read禁用Bash真实 Lucene checkout今天的 Claude Code 用户xerj仅Bash(xq:*)禁用Grep/Glob/Read空目录光靠索引能否回答问题hybridGrep, Glob, Read, Bash(xq:*)真实 checkout真实的产品体验三个设计要点xerj臂运行在空目录里物理上无法回退去读源码树——这是对仅检索的严格测试hybrid是最公平的正面交锋两边都是 agentic各自选择策略这个数字应该成为公开文章的锚点xerj是严格的底线两臂都是 agentic 的自己写查询没有人类调好的查询。xq是唯一的检索途径且刻意通用。对应三臂的精确 CLI 命令verbatim 自run.sh# native真实 checkout 常规文件工具 cd /home/claude/.xerj-code/corpora/lucene-meta/lucene claude -p $RULES\n\nQUESTION: $q \ --output-format stream-json --verbose \ --allowedTools Grep,Glob,Read --disallowedTools Bash,WebSearch,WebFetch,Task # xerj空 sandbox唯一工具是 xq经 Bash 调用 cd outreach/bench/.sandbox claude -p $RULES ... xq \query\ [k] ...\n\nQUESTION: $q \ --output-format stream-json --verbose \ --allowedTools Bash(xq:*) --disallowedTools Grep,Glob,Read,WebSearch,WebFetch,Task # hybrid两者都可用模型自己选 cd /home/claude/.xerj-code/corpora/lucene-meta/lucene claude -p $RULES ... xq ...\n\nQUESTION: $q \ --output-format stream-json --verbose \ --allowedTools Grep,Glob,Read,Bash(xq:*) --disallowedTools WebSearch,WebFetch,Task每轮运行把完整的原始stream-json转录保留在runs/。采集时不做任何摘要因此文章里的任何数字都可以从原始证据重新推导——这是可审计的具体含义。xerj臂的 prompt 还明确警告了索引内容索引里含有 backward-codecs 和 test 副本很多类存在近似重复所以在信任每个命中之前要检查它的路径——这个警告直接对应后面 q01 的真实陷阱。五、问题集10 个真实问题、3 个类别、写答案前先写 ground truth完整问题集在 benchmarks/grep-vs-retrieval-lucene/questions.jsonl共 10 个每个都携带确切的文件、行号以及判定对错的事实且在写下来之前全部对照语料库验证过。id类别问什么ground truth已验证q01_block_sizeprior_hostile当前默认 postings 格式的ForUtil.BLOCK_SIZE256lucene104/ForUtil.java:34——五个 backward-codecs 副本说 128q02_hnsw_levelmechanismHNSW 如何决定新节点的层级ml M1?1:1/Math.log(1.0*M)(int)(-log(u)*ml)q03_mmap_chunkprior_hostileMMapDirectory 的DEFAULT_MAX_CHUNK_SIZE不是常量JRE_IS_64BIT ? (1L34) : (1L28)q04_merge_scoremechanismTieredMergePolicy 如何给 merge 打分mergeScoreskew、* pow(totAfterMergeBytes, 0.05)、deletesPctAllowed20.0q05_hnsw_limitslookupLucene99HnswVectorsFormat 的硬上限MAXIMUM_MAX_CONN512、MAXIMUM_BEAM_WIDTH3200、HNSW_GRAPH_THRESHOLD100q06_bm25_k3prior_hostileBM25Similarity 是否有查询侧饱和参数k3存在默认-1f禁用((k31)*qtf)/(k3qtf)q07_iwc_flushlookupIndexWriterConfig 默认 flush 触发DEFAULT_RAM_BUFFER_SIZE_MB16.0、DEFAULT_MAX_BUFFERED_DOCSDISABLE_AUTO_FLUSHq08_osq_paramslookupOptimizedScalarQuantizer 默认值DEFAULT_LAMBDA0.1f、DEFAULT_ITERS5、MINIMUM_MSE_GRIDq09_exhaustive_countindex_hostile统计包含implements Accountable的文件数43grep -rl ... \| wc -lq10_tragic_eventmulti_hop记录 tragic exception 的方法tragicEvent(...):1869 vsonTragicEvent(...):713——两个不同的方法三个类别是故意设计的prior_hostileq01/q03/q06——checkout 与模型记忆矛盾。q01 是 256 而外界普遍说 128q06 的k3在上游 Lucene 根本不存在。从记忆作答的 Agent 在这里得0 分。它们存在的理由是构建过程中发现的问题见下节 4.1模型曾不调用任何工具就从记忆里回答了 Lucene 问题这类题让参数泄露可检测而非沉默。index_hostileq09——刻意让 XERJ 输的对照题。跨整棵树的穷举计数正是 top-k 检索做不到、而 grep 做得完美的事。把它放进集合是为了让结果可以对自己不利地报告延续 docs/research/wordpress-verification-and-xerj-vs-grep.md 的先例。lookup/mechanism/multi_hop——普通的中间地带覆盖查常量、机制理解和多跳调用链。选择这些题而非 trivia 的理由每一道都是工程师在改索引或向量搜索行为之前真正会问的问题——我的 postings 会用多大的块、HNSW 图该设多大、为什么 merge 没触发、什么触发了 writer flush、为什么量化器有损。没有任何一道能靠读 README 答出来。六、数据从哪里来claude -p --output-format json的真实字段与三个陷阱token 与成本数字来自claudeCLI 自己的记账claude -p --output-format json不是估算或字节代理。README 用一次真实的临时运行验证了真实返回的字段而非假设is_error duration_api_ms duration_ms num_turns stop_reason session_id uuid subtype total_cost_usd usage modelUsage permission_denials terminal_reason api_error_status fast_mode_state fast_mode_disabled_reason result ttft_ms ttft_stream_ms time_to_request_ms typeusage形如{input_tokens:6,cache_creation_input_tokens:5956,cache_read_input_tokens:68601, output_tokens:608,output_tokens_details:{thinking_tokens:89}, server_tool_use:{web_search_requests:0,web_fetch_requests:0}, service_tier:standard, cache_creation:{ephemeral_1h_input_tokens:5956,ephemeral_5m_input_tokens:0}, iterations:[ ... ]}modelUsage按模型细分inputTokens, outputTokens, cacheReadInputTokens, cacheCreationInputTokens, costUSD, contextWindow, maxOutputTokens, canonicalModel, provider。但它不暴露的东西才是关键这是整个基准的核心事实没有任何 per-tool 的 token 归因字段。没有任何字段说 Grep 或 Read 花了多少 token。40% 花在 grep 上这个数字不能直接从这份 JSON 读出来必须从转录中重建而重建就是估算。因此头条数字必须建立在精确的东西上答对同样问题少花 N 倍 token而不是重建出来的占比上。input_tokens是个陷阱。一次真实运行里它是2而实际计费输入约 24,000 token——几乎一切都落在cache_creation_input_tokens和cache_read_input_tokens里。引用input_tokens会把成本低估约 1000 倍。计费输入 input_tokens cache_creation_input_tokens cache_read_input_tokens。usage.iterations不是完整的逐调用日志。一次 3 次 API 调用的运行里它只有1条最后一条。逐调用数据必须来自--output-format stream-json --verbose并按message.id去重assistant事件。流式的output_tokens是部分值。求和得到 9真实值是 608。输出必须取自最终的result事件ledger.py对此做了断言input 与 cache 计数器精确对账output 取自result。有第二个模型在计费。每次运行还会调用claude-haiku-4-5约 $0.001。它与检索策略无关被单独报告绝不记到任何一臂头上。七、ledger.py转录 → 可审计 token 账本对不上就拒发benchmarks/grep-vs-retrieval-lucene/ledger.py 是整个诚实性机制的技术核心。它的存在理由写得很直白claude -p --output-format json只给汇总没有 per-tool 字段所以Agent 在 grep/read 上烧掉 X% token必须重建而它拒绝发出无法与 CLI 计费汇总对账的数字。方法逐调用用量从流的assistant事件恢复按message.id去重每个 id 在流式期间发出多个事件保留每个计数器的最大值——即该消息的最终值计费输入input_tokens cache_creation_input_tokens cache_read_input_tokens工具结果归因按字符用本语料实测的常量calibrate.sh用两个相差 20,000 字符真实 Lucene 源码的 prompt测得 billed token 差 7,181得2.785 chars/token。常见的 chars/4 规则会低估 Java 源码约 30%用它就会低估 grep 成本输出 token 取自权威的result事件并断言重建的 input/cache 计数器与 CLI 汇总精确对账reconciled字段不匹配就拒绝发数字主模型与 sidecarhaiku按modelUsage隔离sidecar 成本永不记到任何一臂头上。ledger.py还报告三种不同的占比因为它们回答不同的问题share_of_unique_ctx_pct——Agent 读过的所有东西里grep/read 输出占多少share_of_billed_pct——你实际付的钱里grep/read 输出占多少高于前者因为第 2 轮拉进来的工具结果会在之后每一轮按 cache-read 价格重新计费share_of_dollars_pct——同上但按 token 类别的真实价格加权cache read 约为 fresh input 的 10%。报告用户的那句40%是 billed/dollar 风格的声明——必须说清楚你指的是哪一种。另外两个被实测过的细节价格模型是推导出来的不是假设的通过求解 CLI 报告的costUSD与其自身计数器精确恢复出$5.00/Mtok 输入、$25.00/Mtok 输出。这还抓到一个错误这些运行用的是1 小时缓存写乘数 2.0×而非 5 分钟缓存1.25×——假设 1.25× 会推出负的输出价格。备选估算器连续调用间cache_creation增量被试用后否决开了扩展思考后该增量被重发的 thinking-block 签名 blob 主导819 字符的 grep 输出读出了 1,613 token约 5 倍高估只保留为宽松上界。还有一份并行的逐工具归因实现 benchmarks/grep-vs-retrieval-lucene/attribute.py它用两次 API 调用之间的 billed-prompt 增量减去本调输出来测工具输出——即提供方自己的计费表计量的工具输出不需要 tokenizer 和估算单次调用发出多个工具时按字符占比分摊并打标记。八、analyze.py两阶段盲评机械检查只能判 FAIL永不判对benchmarks/grep-vs-retrieval-lucene/analyze.py 实现了两阶段分级阶段 1机械从questions.jsonl读取must_match/must_not_match字符串检查。廉价、确定、可审计。它只能把运行判为 FAIL-certain 或 NEEDS-JUDGE永远不能独立判对——因为子串存在不等于理解一个答案可以包含256却在断言错误的东西。阶段 2盲评所有 NEEDS-JUDGE 答案写入judge_queue.jsonl去掉 arm 标签并按固定种子random.Random(20260818)打乱让评分者无法看到答案来自哪个臂。判定从judge_verdicts.jsonl读回。头条指标是tokens per CORRECT answer每答对一题消耗的 token不是每轮 token。一个因为放弃或幻觉而便宜的臂不能赢答错的运行只计成本、不给信用——这是N 倍更少 token有意义的唯一方式。统计用中位数而非均值一次失控的 agentic 运行不应决定头条。analyze.py输出还包含 per-arm 摘要表、per-question-class 的 token/准确率矩阵以及逐题的按臂对比——任何由单一类别驱动的胜利都会暴露。九、校准calibrate.sh实测本语料的 chars/tokenbenchmarks/grep-vs-retrieval-lucene/calibrate.sh 通过向 CLI 发送两个仅差已知字符数的相同 prompt 来测量本语料的 chars/token不需要 API key 也不需要 tokenizer# 用 head -c 取 2000 与 22000 字符的真实 Lucene 源码作为参考材料 # 分别跑 claude -p读出 cache_creation_input_tokens 的差值 # chars_per_token (22000-2000) / (cc_22000 - cc_2000)2026-08-18 记录的结果20,000 字符 → 7,181 token ⇒ 2.785 chars/token常见 chars/4 规则低估 Java 源码约 30%。十、完整运行流程从校准到盲评再到出表cd benchmarks/grep-vs-retrieval-lucene # 仓库内对应 outreach/bench ./calibrate.sh # 为这个语料重新推导 chars/token REPEATS3 ./run.sh all all # 3 臂 × 10 题 × 3 次重复 90 轮 python3 analyze.py # 生成 judge_queue.jsonl去标签、打乱 # 盲评 judge_queue.jsonl - judge_verdicts.jsonl然后 python3 analyze.py # 输出 head-to-head 表未分级按 UNKNOWN 处理并排除每轮run.sh输出原始 stream-json 转录到runs/stderr 到logs/已存在的运行被跳过支持断点续跑。run.sh也支持单臂单题单次重复如./run.sh native q01 1用于调试。十一、七条诚实性防线什么会让这个基准作弊以及如何阻止README 第四节逐条列出什么会让这变成骗局以及对应措施每条都有代码与试点证据4.1 把答案写进 prompt——构建中实测发现早期探测中模型零工具调用就从记忆回答了 Lucene 问题codec header 是9 codecName.length字节。对记忆化的 Lucene trivia 做基准测不到任何检索。缓解显式要求只根据本次会话检索到的内容作答、强制file:line引用、外加三道prior_hostile题让记忆给出错误答案使参数泄露可检测而非沉默。4.2 缓存暖热——最大威胁且真实发生。试点中xerj少用 1.5× token 却多花 2.4× 美元$0.2345 vs $0.0999native跑在暖的前缀缓存上57,945 个廉价 cache-readxerj跑在冷的缓存上21,693 个昂贵的 cache-write。两臂 prompt 前缀不同工具集、cwd 不同所以永远无法共享缓存暖热取决于运行顺序和 5 分钟/1 小时 TTL。应对原始美元不是公平的跨臂指标报告 token并报告cost_usd_cache_neutral所有输入按 fresh input 计价移除暖热运气。试点里 cache-neutral 比值1.52×与 token 比值1.53×吻合而原始美元是反转的。同时交错各臂、重复 3 次、用中位数、丢弃热身轮。4.3 挑选适合索引的问题——q09 的存在就是为了让 XERJ 输且结果按问题类别报告单一类别驱动的胜利无处可藏。ground truth 在任何臂运行之前写好看到结果后从不删题results.json保留每一轮。4.4 让 native 臂不像真实用户——native 臂在真实 checkout 里恰好得到Grep, Glob, Read不多不少不被削弱不强迫整文件读不被帮助无 Bash、无预置路径。同时xq输出上限 1,600 字符/命中索引臂也不能倾倒语料库。4.5 对你喜欢的臂评得更宽松——盲评arm 标签剥离、固定种子打乱机械字符串检查只能判 FAIL 或 NEEDS-JUDGE永不判对。4.6 忽视检索可能主动误导——真实观察q01 时xq先返回了无关的CharBlockArray第二个是错误的ForUtilbackward-codecs lucene103BLOCK_SIZE 128第三个才是正确的 lucene104。索引里有 backward-codecs 和 test 近似副本。完整运行中如果这误导了模型必须报告。4.7 索引零成本的说法——索引不花 token只对LLMtoken 成立。索引构建是 6,012 个文件上的 CPU/磁盘/墙钟时间外加 75,578 个保持存活的文档。如果文章说免费应该写**无 LLM token**而不是免费。十二、试点结论一个诚实的失败案例比胜利更买信任试点n1 题每臂 1 次重复的直接结论是这不支持40% 浪费在 grep 上。在目标精准的问题上native 臂只花了约 145 token 在 grep 输出上——0.5%的 billed token。两臂的成本大头是固定的 ~24k token 系统提示与工具定义在每次 API 调用上重新计费。XERJ 的 token 优势主要来自更少的回合。报告建议的措辞值得一字不差地引用这是整份文档的灵魂任何大的胜利很可能来自回合数减少任何大的grep 占比只会在探索密集、Agent 在多个文件间搜索的问题上出现。到底是 40%、18% 还是 3%正是完整矩阵要回答的。对应地README 预承诺了证伪条件半句 A 被证伪如果 native 臂工具输出占 billed token 的中位数明显低于 40%比如 25%——试点已测到 0.5%这半句已经严重存疑帖子里的数字必须改。半句 B 被证伪如果出现任一情况hybrid/xerj的每正确答案 token 中位数没有明显低于 native比值低于 ~1.3× 称不上很多倍XERJ 省了 token 但输了准确率优势只在原始美元里、在cost_usd_cache_neutral下消失优势由单一问题类别撑起而在其他类别反转q09 预期对 XERJ 不利如果mechanism和multi_hop也输就没有故事了。预承诺的报告规则无论测出什么数字都原样进文章包括 XERJ 输掉的 q09以及被修正过的 40% 数字。如果半句 A 塌了但半句 B 成立诚实的帖子应该是grep 不是你 token 的去处——回合才是检索把每正确答案的 token 砍了 N 倍——这比原声明更好、更经得起辩护。十三、Suggestion把失败案例链接进 README报告的第三条建议直接引用了一个文件Linkdocs/research/wordpress-verification-and-xerj-vs-grep.mdfrom the README. It publishes a case where XERJ lost, with the mechanism, and that buys more trust with skeptical engineers than the wins do.该文件确实存在于仓库中docs/research/wordpress-verification-and-xerj-vs-grep.md。它记录了一次 XERJ输给grep 的实测方法结果判定grep -rl wp_safe_remote_*14 个文件完整XERJ full-textmatchoncode9 个函数完整、函数级XERJ 预建调用图termoncalls1沉默的假阴性安全审计中最严重的错误是假的不可达而结构化调用图恰好产出了这个。根因是真实的 XERJ 查询层 bug数据确实在_source里XERJ 忽略keyword映射、对数组 keyword 字段做分词wp_safe_remote_get被切成[wp, safe, remote, get]于是{term:{calls:wp_safe_remote_get}}→ 0且booleanterm被当字符串匹配{term:{has_source:true}}→ 0{term:{has_source:true}}→ 440。只有多 token 和 boolean 两种情形会静默失败所以这个 bug 极易漏掉。这份文档给出了一个诚实的裁决与本文的基准哲学完全一致原始可达性谁调用了 X、Y 用在哪grep 与 XERJ full-text 完整可靠预建结构化调用图目前比 grep 差静默少报预建索引真正赢的地方是 grep无法表达的函数内计算指纹消毒序列顺序、SSRF 范围覆盖、cap-object 作用域——它们带来了实测的约 2,700× token 缩减净结论XERJ 作为文档存储、≈带函数作用域的 grep 的 full-text 层、以及预计算语义指纹的载体是真实帮助其结构化数据库表面精确 keyword/booleanterm有 bug在修复前不能用于安全可达性判断。这正是报告建议把它链进 README 的原因一个带机制的失败案例比十个胜利更能买来持怀疑态度的工程师的信任。这种发布自己输掉的结果的规则同样适用于本文的 token 基准——README 明确声明本仓库对 XERJ 输在哪里有着一以贯之的先例同样的规则适用于这个 harness 测出的一切。十四、对任何token 节省类基准的可移植清单结合本 harness 与 docs/TOKEN_USAGE.md后者给出了一个可直接复用的模型tokens ≈ envelope_overhead answer materialized_intermediate_data可以把这套方法提炼为可移植的七条规则测量线上的字节而不是工具调用数——token 来自请求/响应载荷两次 30 字节的调用胜过一次 15 KB 的调用节省只在双方都答对的任务上成立——返回更少字节但没返回有用信息不是节省排除任何一方答错的任务基线只使用问题自身的词汇——已经知道答案位置的人写的 grep 不是基线双方同等调优——基线是合格的XERJ 侧就必须用filter_path、size:0与原生模式用调好的基线与没调优的引擎比是另一种不诚实变化查询以击穿结果缓存报告第一次、未缓存的时间把timed_out:true与 bucket-vs-hits.total不一致判为错误而不是快把部分答案当完整答案是失败的极限形态每个比值旁必须报告语料构成——检索节省随 prose 比例放大分析节省随记录数放大单一头条 token 数字跨两类语料毫无意义。这套规则在仓库里由 demo/agent-gate/gate.py 用代码强制实施没有语料构成就拒绝打印比值。总结这份 agent 现场报告最终没有交付一个数字而是交付了一个能拒绝交付数字的系统。它的全部价值浓缩在三件事里数字本身会骗人——claudeCLI 的 JSON 没有 per-tool 归因input_tokens是陷阱缓存暖热可以让原始美元反转而更便宜的答案在没有盲评时会被误读为胜利可信度来自结构性约束——三臂对照 空目录隔离 通用xq 预写 ground truth 盲评 每正确答案 token 指标 缓存中性成本 预承诺的证伪条件每一步都把操纵空间压缩到极限最有说服力的证据是诚实的失败——无论是 q01 的 35% 空头数字、q09 的故意反 XERJ 控制题还是 WordPress 审计里调用图对 grep 的完败公开哪里输了、为什么输买来的信任远超一切胜利。如果你要在自己的项目上复刻这套方法起点就是 benchmarks/grep-vs-retrieval-lucene 目录里的六个文件questions.jsonl问题与 ground truth、run.sh三臂 runner、xq刻意通用的检索工具、ledger.py可审计账本、analyze.py盲评出表、calibrate.sh语料校准。它们共同定义了一个不假设结论、只测量结论的装置长什么样。赞分享人工智能搜索引擎本地部署后端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 对照 grep 的 Lucene 检索 token 基准三臂测量方案、账本设计与诚实性防线XERJ 对照 grep 的 Lucene 检索 token 基准三臂测量方案、账本设计与诚实性防线 本篇技术指南以仓库 benchmarks/grep vs人工智能搜索引擎本地部署后端MCP 服务MEX 检索基准评测方法论盲评对比 Greptoken 消耗直降 54% 的背后MEX 检索基准评测方法论盲评对比 Greptoken 消耗直降 54% 的背后 MEX 是一款把团队记忆放进代码仓库的开源工具核心能力之一是用代码图CLearn Harness Engineering 实战构建可观测、可调试、可基准测试的完整 Agent HarnessProject 06 Capstone 全解析Learn Harness Engineering 实战构建可观测、可调试、可基准测试的完整 Agent HarnessProject 06 Capston上一篇UMAP近邻数量选择n_neighbors参数对聚类结果的影响下一篇如何掌握boardgame.io游戏阶段与回合顺序打造专业桌游体验的终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考