XERJ 与 DocFetcher 文档搜索对比：面向 Agent 的本地搜索引擎 vs 面向人类的桌面 GUI

DocFetcher 是一款成熟的开源桌面搜索 GUI，能读取 Outlook PST 邮件与多层嵌套压缩包，其便携版可把索引随身放在 U 盘上；XERJ 则是一个单二进制 Rust 搜索引擎，程序通过 HTTP（Elasticsearch 兼容 REST API）或 MCP 协议调用它，一条 xerj autoindex 命令即可把文档文件夹变成可检索、可被 Agent 引用的结构化数据。本文逐项对比两者的能力边界、给出可直接运行的 XERJ 操作命令，并说明各自最适合的使用场景。

TL;DR — DocFetcher 是给人在键盘前用的桌面 GUI；XERJ 是给程序（尤其是 AI Agent）调用的搜索服务。本文是能力对比（capability comparison），不是基准测试：未冻结共享语料、未安装 DocFetcher 与 XERJ 同场评测、未测量任何召回率、命中数或延迟，页面不给出任何"胜负计数"。

先说清楚：这篇对比没有跑基准

在进入细节之前，先明确本页的事实边界：

• 我们没有冻结一份共享语料库；
• 我们没有在 XERJ 旁边安装 DocFetcher 做同场评测；
• 我们没有测量召回率（recall）、命中数量（hit counts）或延迟（latency）。

本页没有任何"赢家计数"（win count），也没有任何一次运行（run）作为计数依据。关于 DocFetcher 的每一条陈述都来自其官方网站，关于 XERJ 的每一条陈述都是该二进制文件的可文档化能力（documented capability）。

如果你需要数字，正确做法是：用自己的文件夹在两个工具里分别建索引，自己对比两份结果列表——只有这种对比才描述得了你自己的文档。

Agent 提示词：把整条链路串起来

原文档为 AI Agent 提供了可直接使用的提示词模板，它描述了一条完整的"本地文档问答"工作流：启动节点 → 建索引 → 读数据地图 → 用短语查询并引用来源路径。

Act as a coding agent on a Windows or Linux workstation with a documents folder. Read https://xerj.org/llms.txt, start a local XERJ node, run xerj autoindex on the folder, read the data map, then answer the user question with a match_phrase query that cites the ax_path of every hit.

（在 Windows 或 Linux 工作站上充当编码 Agent，面对一个文档文件夹：阅读 llms.txt，启动本地 XERJ 节点，对文件夹运行 xerj autoindex，读取数据地图，然后用 match_phrase 查询回答用户问题，并为每个命中引用其 ax_path。）

这条提示词背后的每一步都可以用下面的四段命令落地。

四条命令：从索引到 Agent 查询的完整闭环

原文档给出了四条无需配置文件、无需 mapping 的完整命令，全部可以直接复制运行。

命令 1：索引文档文件夹

xerj autoindex ./Documents --url http://127.0.0.1:9200 --prefix docs --progress plain

要点：不需要任何配置文件，也不需要 mapping。xerj autoindex 会读取文件夹并按内容（content）识别每个文件的类型族（family），按文件形态推断数据集（dataset）并写入文档。--url 指定 Elasticsearch 兼容端点（默认 http://localhost:9200），--prefix docs 给索引加前缀（默认 ax），--progress plain 把进度输出为适合管道/CI/Agent 解析的固定两行格式（xerj-bar 展示行 + xerj-progress 机器行）。

从源码看，内容嗅探（content sniffing）是这条命令的核心：在 sniff.rs 中，模块头注释明确写着 "Content-based format detection. NEVER trusts file extensions"（基于内容的格式检测，绝不信任文件扩展名），检测顺序是 magic bytes → 二进制检查 → 文本启发式（json/jsonl → html/xml → logs → sql dump → csv → yaml → txt）。也就是说，一个扩展名写错的 CSV 文件仍然会落进类型化数据集，这正是"混合文件夹"场景的关键能力。

命令 2：打印数据地图

xerj autoindex map --url http://127.0.0.1:9200

打印数据地图，让下一条查询能指名真实的索引和真实的字段。Agent 先读地图，再写查询，就不会去猜字段名。地图数据来自 catalog 索引（autoindex-catalog）中每个数据集的 fields_json 字段——该字段携带 profiler 推断出的 FieldSpec 列表：字段名、es_type、基数估计、覆盖率、示例值等（见 map.rs 的模块文档）。命令行下加 --json 可输出原始 catalog 文档，供程序直接消费。

命令 3：短语查询并读取每个命中的文件路径

curl -s -XPOST http://127.0.0.1:9200/docs-*/_search -H 'content-type: application/json' -d '{"query":{"match_phrase":{"body":"purchase order"}},"size":10,"_source":["ax_path","ax_format","title"]}'

这条命令用通配索引模式 docs-* 覆盖所有以 docs 为前缀的索引，对 body 字段执行 match_phrase 短语匹配，并把 _source 投影到 ax_path（原始文件相对路径）、ax_format（检测出的格式）和 title 三个字段——每个命中都能被 Agent 引用到具体源文件。注意 catalog 的 GOTCHAS 提示（catalog.rs）：查询全部数据应使用通配索引模式或逗号列表，不要用多索引别名；文档在运行结束时会做一次 refresh，新建写入需要先 _refresh 才能被搜索到。

命令 4：把同一节点暴露为 MCP 服务器

xerj mcp --url http://127.0.0.1:9200

把同一节点以 stdio MCP 服务器形式提供给 Agent。xerj mcp 与主二进制同在一个可执行文件里，无需单独安装。从 xerj-mcp 源码 看，它通过 stdio 传输（stdin/stdout 上的换行分隔 JSON-RPC 2.0）暴露 16 个工具，其中 13 个 1:1 映射到 XERJ 真实的 REST 接口，3 个 Corpus Hub 工具运行 xerj ask 流程。与本文主题直接相关的工具包括：xerj_search（POST /{index}/_search）、xerj_map（POST /autoindex-catalog/_search，即命令 2 的 MCP 形态）、xerj_memory_store / xerj_memory_recall（Agent 记忆读写）。每个工具都是薄代理（thin proxy）：构造引擎本就接受的请求并转发，自身不增加任何能力。

认证方面：当目标为 loopback 地址且未显式提供 --auth/XERJ_AUTH 时，服务器会回退到本地节点自写的管理密钥（<data_dir>/admin.key），这正是 xerj init 一键初始化能直接工作的原因；对非 loopback URL 该回退永不触发，避免凭据泄露。

DocFetcher 是什么

DocFetcher 是一款 Eclipse Public License 许可的开源桌面搜索应用，支持 Windows、Linux 和 macOS。当前发布版本为 1.1.27，自 1.1.26 起无需单独安装 Java 运行时。

使用方式上，按文件夹建索引：GUI 基于索引作答，提供结果窗格（result pane）、预览窗格（preview pane）和命中高亮；过滤器可按文件大小、文件类型和位置收窄结果列表。查询语法是常见的布尔集合：支持通配符（wildcards）、短语搜索（phrase search）、模糊搜索（fuzzy search）、邻近搜索（proximity search）和权重提升（boosting）。

一个值得注意的设计决定：DocFetcher 默认什么都不索引——这是项目官方页面上的明确设计，由用户挑选文件夹而不是整盘索引。

XERJ 是什么

XERJ 是一个单一 Rust 二进制，运行一个搜索节点。xerj autoindex <folder> 读取文件夹并按内容识别每个文件类型族，按文件形态推断数据集并写入文档——命令不需要配置文件、不需要 mapping。

节点对外提供 Elasticsearch REST API。xerj autoindex map 打印"这个文件夹变成了什么"的数据地图，Agent 读地图后就能指名真实的索引和字段。xerj mcp 是同一二进制内的 stdio MCP 服务器，对已启动的节点提供 16 个工具；Agent 记忆存放在引擎的 /_memory/{namespace} 路径下（由 xerj_api 的 authz 中间件保护，authz.rs 可见 /_memory/{namespace}[/…] 的路由与权限表）。

XERJ 是单节点的：没有副本、没有故障转移（failover）。默认嵌入器是**词法特征哈希（lexical feature hashing）**而非神经模型，神经检索需通过 --embed-mode neural 显式开启。这一点在 xerj-ai 中体现为统一的 embedder 后端（lexical / proxy / Candle neural），其内置零配置确定性文本嵌入器即特征哈希；catalog 的 GOTCHAS 也注明：semantic_text 字段默认由内置词法特征哈希嵌入器（384 维混合词法+向量，非神经）在服务端嵌入。

能力逐项对比

以下每一行都是两个工具的文档化能力，没有一行是测量结果。

能力	DocFetcher	XERJ
带预览窗格的人工 GUI	有，且命中高亮	无，仅 HTTP 与 MCP
Windows 桌面应用	有（Windows 7 SP1 及以上）	服务进程，无窗口
索引可放 U 盘随身携带	有（portable 版本）	数据在节点数据目录
Outlook PST 邮件	有	无 PST 读取器；仅 mbox 与 .eml
zip、7z、rar、tar 压缩包	有，无限层嵌套	无压缩包处理
纯图像 PDF 的 OCR	无	无
模糊与邻近操作符	有（查询语法内建）	仅词项（terms）与短语（phrases）
自动更新索引	有（应用运行期间）	重跑 xerj autoindex
格式检测	文件扩展名（另附正则选项）	按内容逐族嗅探
HTTP 查询 API	免费版没有	有，Elasticsearch REST API
面向 Agent 的 MCP 服务器	无	有，xerj mcp，16 个工具
被拒文件的目录清单	GUI 内索引报告	autoindex-catalog，每个文件一个原因
引擎内的 Agent 记忆	无	有，/_memory/{namespace}
许可证	Eclipse Public License	Apache-2.0

值得展开的几行：

• 被拒文件目录：XERJ 每次运行都会把 doc_kind: file 的档案写入 autoindex-catalog 索引，携带 status 与 reason（每个被拒/跳过文件一个原因，如"byte-identical content already indexed from …"），见 catalog.rs。这正是"这个文件夹到底索引了什么、为什么跳过某些文件"的可审计答案。
• 格式检测：XERJ 的检测顺序是 magic bytes → 二进制检查 → 文本启发式，检测出的 family 覆盖 JSONL/JSON/CSV/Logs/XML/HTML/YAML/PDF/EML/mbox/DOCX/PPTX/XLSX/XLS/DOC/EPUB/IPYNB/man/SQLite/SQL dump/源码/Unity 资源/BVH 等 30 余种（sniff.rs）。
• 自动更新索引：DocFetcher 在应用运行期间自动更新；XERJ 的常规方式是重跑 xerj autoindex（幂等、可恢复），此外 --watch 模式可在首轮索引后常驻并重索引变更文件。

什么时候该选 DocFetcher

• 当搜索的人是"人"时：DocFetcher 的 GUI 经过多年打磨，带预览窗格的结果窗口对人工阅读者胜过 API。
• 在 Windows 工作站上：它作为桌面应用安装，不需要终端、不需要节点、不需要 HTTP 调用。
• 当索引必须"随身携带"时：portable 版把索引放在应用文件夹内，整个文件夹可以放进 U 盘、加密卷或云盘。
• 面对 Outlook PST 文件时：XERJ 能读 mbox 和 .eml，但没有 PST、OST、Maildir 的读取器，仍留在 Outlook 自己存储里的邮件永远进不了 XERJ 索引。
• 面对压缩包时：DocFetcher 能无限层嵌套地遍历 zip、7z、rar、tar；XERJ 没有压缩包处理器。
• 当查询需要模糊或邻近操作符时：XERJ 只匹配词项和短语。

什么时候该选 Recoll 或 ripgrep-all

• 想要带邮件索引、OCR 钩子和 open-at-page 的桌面 GUI 时，选 Recoll——详见 Recoll 对比。
• 想"今天就一个问题、不要任何索引"时，选 ripgrep-all——详见 ripgrep-all 对比。
• 当文档必须分布在多个主机上时，选 Elasticsearch：XERJ 没有副本和故障转移，它只在一个节点上讲同样的 REST API。

什么时候 XERJ 更合适

• 当调用方是程序时：免费版 DocFetcher 是一个有窗口、没有 API 的应用；说 HTTP 或 MCP 的 Agent 无需任何包装就能调用 XERJ。
• 当搜索必须无桌面运行：XERJ 是服务进程，可在无头主机上运行并跨网络应答。
• 当文件夹是混合类型时：格式检测读内容而非扩展名，扩展名写错的 CSV 仍会落入类型化数据集。
• 当答案必须携带出处（provenance）时：每个文档都带 ax_path、ax_file、ax_format 等关键词字段，Agent 可以引用源文件。源码证据上，def.rs 的代码检索默认 _source 即包含 ax_path；byte-identical 重复路径只索引一次，规范记录保留全部当前文件名于 _source.ax_paths（见 catalog GOTCHAS）。
• 当同一节点还要存放 Agent 记忆时：/_memory/{namespace} 把持久化的 Agent 记忆放在文档旁边。

XERJ 明确没有的东西

• 没有 GUI：没有结果窗口、没有预览窗格、没有词条高亮。
• 没有 OCR，没有压缩包处理器：邮件读取覆盖 mbox 与 .eml，不含 PST、OST 或 Maildir；没有基于角色的访问控制（RBAC），没有单点登录（SSO）。
• 单节点运行：没有故障转移，请按"从副本恢复"来规划。

如何正确阅读这篇对比

这是一份取自各自官方文档的能力对比，不是基准测试，也不是对你文件的断言。

诚实的总结很短：DocFetcher 是 Windows 上更好用的桌面应用，XERJ 是替你做搜索的程序所用的搜索引擎。 完整的 XERJ 侧实战可参考 文件夹搜索完整演练。

FAQ

在 Windows 上不用 Spotlight 如何搜索文档文件夹？

用你自己的工具给文件夹建索引。DocFetcher 为键盘前的人建索引；XERJ 为程序建索引，并通过 HTTP 或 MCP 应答。

DocFetcher 对比本地搜索 API？

DocFetcher 是免费版没有 API 的 GUI 应用。本地搜索 API 应答的是程序而非人——这正是对 Agent 而言最关键的区别。

如何一次性搜索一个同时包含 PDF、Word 和 markdown 的文件夹？

两个工具都能一次遍历建索引。DocFetcher 在结果窗口里展示命中；xerj autoindex 写出类型化文档，再由 match_phrase 查询通过 HTTP 读取。

你们有没有跑 XERJ 与 DocFetcher 的正面基准？

没有。没有冻结共享语料，没有测量召回率或时序数字，所以本页只发布文档化能力，不发布任何胜负计数。

哪个工具能把索引放在 U 盘上？

DocFetcher。portable 版把索引放在应用文件夹内，被索引的资料随盘携带；XERJ 的数据存放在节点数据目录。

Agent 能直接调用 DocFetcher 吗？

免费桌面版不行——它有 GUI 且没有 API。多用户 Web 界面是单独销售的 DocFetcher Server。

相关阅读

• 我有一个包含 PDF、Word 和 markdown 的文件夹，如何一次性全部搜索？
• 如何搜索一个 .docx 合同文件夹？
• ChatGPT 能搜索我笔记本电脑上的文件夹吗，还是需要别的工具？
• 本地桌面搜索 PDF 和文档文件夹，哪家最强？
• 如何从命令行 grep PDF 和 Word 文档？