Marie-AI：让 AI Agent 协作处理你的文档

想象这样一个场景：一家三甲医院的档案室里，护士正在处理堆积如山的病历单——有手写的门诊记录、有打印的检验报告、还有拍照上传的处方图片。她需要的不是一款 OCR 工具，而是一套能自动识别、整理、提取关键信息的"智能助手"。Marie-AI 正是为这样的需求而生。

背景：为什么需要 Agent 化的文档处理框架？

传统的文档处理方案往往是单点工具的堆叠——用 Tesseract 做 OCR、用正则提取关键字段、用规则引擎做分类。每个环节独立运作，环节之间的数据流转和数据清洗成了最耗时的工作。更关键的是，当文档类型从病历扩展到合同、发票、学历证书时，规则引擎往往需要重新编写，扩展成本极高。

Marie-AI 的核心思路是将文档处理任务分解为多个专业化 Agent，每个 Agent 负责一个子任务（OCR、分类、NER、表格识别等），通过 DAG（有向无环图）引擎统一编排和调度。用户只需描述最终目标，系统自动完成从扫描件到结构化数据的全流程。

核心功能：一条管道，无限可能

Marie-AI 的处理管道覆盖了文档生命周期的各个环节：

智能 OCR：不只是光学字符识别，还包括版面分析（Layout Analysis）、手写体识别（ICR）和表格结构识别。底层基于 PyTorch + Detectron2，支持 PubLayNet、PubTabNet 等标准数据集预训练模型。

文档分类与分割：支持多级分类体系，可以区分合同类型、识别文档边界。document_classifier 和 document_splitter 组件提供了开箱即用的能力。

命名实体识别（NER）：从文本中提取人名、日期、金额、机构名等关键字段。配合下游的业务规则引擎，可直接生成结构化数据。

Agent 编排引擎：这是 Marie-AI 最具特色的部分。它不是简单的线性管道，而是一个 DAG 驱动的任务调度系统。每个 Agent 可以并行执行、可以条件分支、可以设置软硬 SLA（服务等级协议）。系统还支持通过自然语言指令驱动——你告诉它"提取这份发票的金额和日期"，它自动规划执行路径。

LLM 集成层：Marie-AI 不是一个独立的 AI 模型，而是一个集成框架。它支持 OpenAI GPT、Google T5、NVIDIA NeMo Guardrails 等主流 LLM，也支持 vLLM 和本地模型推理。通过统一的 LLM Wrapper，开发者可以灵活切换后端。

技术架构：Monorepo 下的多包协同

Marie-AI 采用 Monorepo 结构，主要分为以下几个包：

• marie（核心包，2-5GB）：包含完整的文档处理引擎、ML 模型、Gateway 和调度器。marie/_core/ 提供底层抽象，marie/agent/ 实现 Agent 生命周期管理，marie/components/ 提供文档处理组件（classifier、splitter、NER、模板匹配等）。
• marie-mcp（轻量包，约 5MB）：Model Context Protocol 服务器，允许 AI 助手（如 Claude）通过 MCP 协议直接调用 Marie-AI 的文档处理能力。
• marie-kernel：Jupyter Kernel 集成，可在 Notebook 环境中使用 Marie。
• marie-wasm：WebAssembly 编译支持，实现浏览器端运行。

核心依赖包括：PyTorch、Protobuf 5.x、grpcio、DocArray v2、OpenTelemetry 全家桶、Prometheus 监控。extra-requirements.txt-CUDA 提供了完整的 CUDA 加速依赖清单。

部署体验：没有一键启动，但有完整基础设施

Marie-AI 提供了一套完整的 Docker Compose 栈来部署基础设施栈（RabbitMQ、MinIO、ETCD、PostgreSQL、Prometheus）。但"一键启动"并不存在，因为它的目标用户是企业级部署而非个人尝鲜。

启动流程需要：先启动基础设施栈（bootstrap-marie.sh），再启动 Marie Gateway（gRPC:51000, HTTP:52000）和 Extract Executor（8080）。GPU 支持通过 cuda-312.Dockerfile 提供，gpu-310.Dockerfile 则针对 CUDA 11 环境优化。没有 Web 界面，所有交互通过 CLI、Python SDK 或 gRPC/HTTP API 完成。

部署难度评分为 4/5（困难），主要门槛在于：需要配置 MinIO 存储、RabbitMQ 消息队列、ETCD 服务发现等中间件，以及至少 8GB RAM 的运行环境。

争议与局限

Marie-AI 不是一个"小而美"的项目。它有 104 个 open issues，活跃维护但响应参差不齐。由于项目深度依赖 PyTorch 和 Detectron2，冷启动的 Docker 镜像体积可能达到数 GB。作为一个相对小众的框架，社区生态还不够成熟，第三方插件和教程较少。

行业意义

文档智能（Document Intelligence）是 RAG（检索增强生成）热潮中的关键基础设施。再强大的 LLM，如果输入的是扫描件 PDF 而非结构化文本，处理效果也会大打折扣。Marie-AI 代表了一种将 Agent 化思维引入传统文档处理的新范式——不再依赖规则引擎，而是让多个专业 Agent 协作完成复杂任务。

虽然距离"一键部署"还有距离，但它为企业级文档处理提供了一套有诚意的开源方案。如果你正在构建需要处理发票、合同、病历等非结构化文档的应用，Marie-AI 值得列入技术选型的考察清单。