Xberg：把 107 种格式塞进一个 Rust 内核的文档智能引擎

一、从一个具体的痛点说起

设想一个真实的团队场景：客服系统每周要处理 3 万份文件——PDF 合同、扫描件发票、Excel 对账单、Word 附件、邮件正文、PPT 汇报、甚至客户随手丢过来的 .zip 压缩包。最早的做法是拼装流水线：PyPDF 抽 PDF、pdfplumber 抽表格、python-docx 抽 Word、Tesseract 抽扫描件、邮件库解附件……每接一个格式就多一套依赖、多一套版本冲突、多一处线上崩溃点。

更糟的是表格。合同里的违约条款散落在无边框表格中，Excel 的合并单元格把"金额/税率/小计"打散成三行，OCR 出来的扫描发票里数字和文字错行。想把这些交给大模型，前置的解析层比模型本身还难伺候。

Xberg 的赌注是：别拼装了，把这件事做进一个内核里。

二、它是什么：从何而来

Xberg 诞生于 2025 年 1 月，由 xberg-io 团队以 Rust 从零实现，2026 年 11 月已积累约 9,540 Stars / 611 Forks，并保持着极高频率的提交（仓库提交量在万次量级）。它把自己定位为"文档智能引擎"（document-intelligence engine），而非某一个解析器。

它的自我认知很清晰：一个核心负责格式识别、读取与抽取，用户不需要自己组装 pipeline。官方文档直接把它与 Docling、MinerU、Unstructured 放在同一张基准表上比较——这是文档解析赛道里最硬的对标方式。

仓库结构也暴露了它的野心：crates/ 下 16 个 crate（核心、CLI、OCR 后端、PDF 渲染、FFI、JNI、Node/WASM 绑定），packages/ 下 11 个语言 SDK（Python、Node、Go、Java、C#、Ruby、PHP、Elixir、Dart、Kotlin、Swift、Zig），charts/ 是 Helm Chart，plugin/ 是面向 Claude Code / Codex / Cursor / Gemini CLI / Hermes 等 Agent 的插件，skills/ 是一组可安装的 Agent Skill。

三、一个类比：为什么是 Rust

如果把传统 Python 解析栈比作"一支临时拼起来的杂技团"，每个人只会一两个节目，串台时彼此踩脚；那 Xberg 更像是造了一台多功能机床——同一台机器换装不同的刀头（extractor），输入毛坯（任意文件），输出成品（干净的 Markdown / JSON）。

Rust 在这里的价值非常具体：

• 无 GC 的稳定延迟。批量解析场景里，P99 延迟抖动往往比平均速度更致命。
• 单文件分发。cargo binstall 能拿到一个自包含的静态 ELF，不拖 Python 虚拟环境。
• WASM 落地浏览器。官方 Live Demo（docs.xberg.io/demo.html）直接在浏览器里跑 WASM 解析，无需后端。

代价也很直白：源码构建门槛高（需要 Rust 1.99+、CMake、ONNX Runtime、pdfium、libheif 等原生依赖），这是它与纯 Python 方案最大的分水岭。

四、核心能力拆解

格式广度：官方口径是 107 种格式、140 个文件扩展名、53 个 MIME 别名，全部由原生 Rust 解析器处理，不依赖 LibreOffice 等外部二进制。覆盖 PDF、Office 全系（含老式 OLE/CFB 的 .doc/.ppt/.xls）、图片、邮件（EPUB/MBOX 等）、网页与标记语言、电子书、学术论文（LaTeX/JATS）、结构化数据（JSON/YAML/TOML/XML）、压缩包。

递归解压：.zip/.tar/.gz/.7z 内的文档可递归抽取，但有 zip bomb、压缩比（默认上限 100×）、归档大小（默认 500 MiB）、嵌套深度四道闸门，SECURITY.md 把"恶意输入文档"明确列为首要威胁模型。

OCR 与版面：支持 Tesseract、PaddleOCR、Candle（TrOCR/PaddleOCR-VL）、以及 VLM 后端，可组成 fallback 链，输出置信度并自动识别语言。版面侧用 PP-DocLayout-V3、RT-DETR 做阅读顺序还原，TATR、SLANet 做表格结构重建；PDF 标题层级用 K-means 对字号聚类得出 H1–H6。

音频转写：Whisper ONNX（tiny → large-v3），直接处理 MP3/M4A/WAV/WebM/MP4 音轨。

代码智能：通过 tree-sitter-language-pack 解析 371 种编程语言，抽取函数、类、导入、符号与 docstring，并提供语法感知的分块，直接对接 RAG 流水线。

结构化抽取与增强：本地（Ollama、LM Studio、vLLM）或托管 LLM（liter-llm 支持 165 家提供商）按 schema 直接产出 JSON，无需手写 prompt；另有 NER、YAKE/RAKE 关键词、摘要、翻译、脱敏、页面分类、QR 识别、TOON token 缩减等。

代码智能之外：嵌入（本地 ONNX 或托管，稀疏与 late-interaction）、cross-encoder 重排；URL 抓取与爬取（crawlberg 引擎，Auto/Document/Crawl 三模式）。

输出形态：纯文本、Markdown、Djot、HTML、JSON 树、Docling DocTags 六种输出，DocTags 还能反向解析回来，形成与 Docling / SmolDocling / Granite-Docling 生态的交换闭环。

接入方式：14 条 CLI 命令（extract/batch/detect/formats/version/cache/tree-sitter/doctor/serve/mcp/api/embed/chunk/completions）、REST API（xberg serve）、MCP Server（9 tools / 3 prompts / 4 resources）、Docker、Helm。

五、上手门槛：三条路径

路径一：SDK（最省事）。pip install xberg / npm install @xberg-io/xberg / cargo add xberg / go get github.com/xberg-io/xberg/packages/go@latest（注意 Go 必须指定 /packages/go 子目录，仓库根目录不是 Go module）。预编译包覆盖 Linux/macOS/Windows，多数场景零编译。

路径二：CLI / Docker（最通用）。docker pull ghcr.io/xberg-io/xberg:latest 后一条命令起 API 服务；Core 镜像约 1.0–1.3 GB，Full 镜像约 1.5–2.1 GB，两者都含 Tesseract 12 语言。

路径三：源码构建（最深）。需要完整 Rust 工具链与大量系统库，且 Dockerfile 里对 pdfium、ONNX Runtime、libheif、libde265、aom、x265、dav1d 有逐一固定版本与哈希 pin——这是工程严谨，也是劝退点。

Web UI 情况：仓库内没有传统 Flask/Streamlit 式的管理后台，但提供了 Astro Starlight 文档站与基于 WASM 的浏览器 Live Demo，Agent 侧则通过 MCP 与官方插件接入 Claude Code、Codex、Cursor、Gemini CLI、Hermes、Pi、opencode、Factory Droid、Copilot CLI 等。

硬件门槛：默认纯 CPU，不要求 GPU。官方镜像的 ONNX Runtime 只有 CPU 版，要 GPU 必须带 cuda feature 从源码编译。硬性提醒：预编译 ONNX 依赖 AVX/AVX2 指令集，Intel Atom、Celeron N5105 等老 CPU 会在 ONNX 相关功能上直接 invalid opcode 崩溃（文本抽取、Tesseract OCR 不受影响）。内存建议 2 GB 起，磁盘 2 GB 起。

六、争议与局限

1. 社区体量与 star 数不完全匹配。约 9.5K star 对应的贡献者约 73 人（GitHub contributors 接口统计），项目由小团队高度集中维护，"内置 with alef"、CHANGELOG 46 万字节、.ai-rulez 生成文件等痕迹说明它有自研的工程化流水线，但也意味着关键路径依赖少数人，需评估 bus factor。
2. 开源与商业版边界。官方站点同时列出开源 Xberg、自托管的 Xberg Pro 与面向 K8s 的 Xberg Enterprise。部分高级能力（尤其分布式与治理）只存在于商业版本，选型时要问清哪些能力属于开源版。
3. Rust 门槛的普适性。对 Python 数据团队而言，"pip 装不上就得先装 Rust"是真实摩擦；此外 ONNX 动态库在 Windows 上的 PATH/LD_LIBRARY_PATH 问题、NuGet RID 发布、DllNotFoundException 等都已在文档中留下"gotcha"，说明跨语言绑定的边角仍在持续踩坑。
4. 格式广度 vs 单格式深度。107 种格式意味着每个格式的"极限场景"（复杂公式、嵌套表格、加密文档、异常 PDF）必然弱于该格式的专用解析器。它追求的是"够用的通用底座"，不是"每种格式的最优解"。
5. 基准测试需自证。官方自述对标 Docling/MinerU/Unstructured，但这类对比往往由项目方自己完成，测试文档集与参数选择会直接影响结论，落地前建议用自己的真实样本复测。
6. 目录级许可细节：仓库主体为 MIT，但 skills/ 目录下的 SKILL.md 标注 license: Elastic-2.0（仅针对 Agent Skill 打包内容），二次分发前需分别确认。

七、行业意义

Xberg 代表的趋势可以概括为一句话：文档解析正在从"一堆脚本"走向"一个可嵌入的运行时"。

过去三年 LLM 应用的最大瓶颈不在模型，而在"喂给模型之前的脏活"。谁能把这段脏活做到一个内核、零拼接、可在任意语言里调用、可在浏览器里跑，谁就真正拿下了 RAG 基础设施的入口位置。

Xberg 的三个信号值得注意：

• 多语言绑定的广度是护城河。15 种语言的 SDK + WASM + 10 个语言的端到端测试矩阵，这是在赌"未来解析能力会像数据库驱动一样被各语言生态直接消费"。
• 对 AI Agent 生态的主动适配。仓库里直接带 MCP server、Agent Skills 和九种 Agent 客户端的插件配置，还内置 xberg-chunking、xberg-extracting-tables、xberg-extracting-with-ocr 等面向 Agent 的技能包——它把"给 Agent 喂文档"当成一等公民场景。
• 与 Docling 生态的互操作性。支持 DocTags 输入输出，意味着它能和 SmolDocling / Granite-Docling 这类文档视觉语言模型组成流水线，而不是互相排斥。

对团队的实用结论：如果你的痛点是"多格式、批量、要表格、要 OCR、要嵌进已有服务"，Xberg 值得优先做一次 PoC——官方镜像起服务只要一条命令，两周内能得出是否替换现有 Python 栈的结论。如果你的场景单一且格式固定，专用解析器依然更省心。

---

数据采集时间：2026-11-05；仓库状态：未归档（archived=false），MIT 许可，最新推送 2026-11-05。