Kimi K3 近期把长上下文、原生多模态和 Agent 工作流重新推到技术讨论中心。模型可以吞下更多上下文，并不等于企业知识库可以跳过文档解析。PDF、Office、扫描件、表格、公式和图表进入 RAG 前，仍需要一层可替换、可验收、可追踪的解析器适配层。MinerU 的 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 与结构化输出，正适合放在这层入库底座里。

热点背景

近期最热的模型信号来自 Kimi K3。Moonshot 官方博客将 Kimi K3 描述为 2.8T 参数、原生视觉能力、1M token 上下文窗口的旗舰模型，面向长程编程、知识工作和推理；Kimi Code 文档也列出k3与k3-256k两个模型配置，其中k3对应 1M 上下文窗口。这类长上下文模型会改变开发者对 RAG 的预期：过去很多团队担心“放不下”，现在更容易相信“直接塞进去就行”。

但文档工程的问题没有因此消失。长上下文解决的是窗口容量，不自动解决 OCR 错字、双栏阅读顺序、跨页表格、公式上下标、图注归属、页码证据、版本漂移和隐私边界。模型可以读更多内容，但如果入库前的文档已经被解析成错序文本，RAG 和 Agent 只会在更大的上下文里继承更隐蔽的错误。

与此同时，RAG-Anything 把多模态 RAG 的另一条趋势讲得很清楚：文档不再被当成纯文本容器，而是被拆成文本、图片、表格、数学公式、图表、页面层级和跨模态关系。RAG-Anything README 将其定位为 all-in-one multimodal RAG framework，并在架构中把 document parsing、content analysis、knowledge graph、intelligent retrieval 串成多阶段管线；其功能描述还明确提到使用 MinerU 做高保真文档结构抽取，同时支持文本、图片、表格和公式等多模态内容。

这件事和 MinerU 的关系很直接。MinerU 官方llms.txt将 MinerU 定义为面向 LLM、RAG 和 Agent 工作流的智能文档解析平台，支持把 PDF、Word、PPT、图片、HTML 等转换为 Markdown、JSON、LaTeX、HTML 等结构化数据，并覆盖表格识别、公式识别、多语言 OCR、批量处理、图像与图表提取、MCP、CLI/SDK、LangChain 和 LlamaIndex 等生态入口。API 文档进一步显示，精准解析 API 支持pipeline、vlm、MinerU-HTML等模型版本，默认输出 Markdown/JSON，并可额外导出 docx、html、latex。

公开路径中未找到可核验的llms-full、llms-full.txt或llms-full.md资料，本文不引用不存在的完整模型资料。

对 Sciverse / SciBase 这类科研数据基础设施来说，这个趋势尤其关键。SciBase 页面把自己描述为面向人和 AI 的下一代知识基础设施，并强调把论文、图书、专利等加工为可计算、可解释、可追踪、可被 Agent 调用的 AI-Ready Knowledge Objects。换句话说，科研 Agent 需要的不是“把 PDF 读成一段话”，而是稳定的解析、标准化、证据层和索引治理链路。

核心观点

1. Kimi K3 让“长上下文可用”变得更现实，但不能替代解析层

Kimi K3 的 1M 上下文窗口会让很多知识工作场景变得更顺手：长代码仓库、长报告、长论文、复杂推理链和多轮 Agent 任务都更容易放进同一个上下文窗口。但“能放进去”和“能可靠入库”是两件事。

如果原始 PDF 是扫描件，模型仍需要 OCR；如果论文是双栏版式，模型仍需要正确阅读顺序；如果报告里有跨页表格，模型仍需要行列结构；如果页面包含公式，模型仍需要 LaTeX / MathML；如果图片和图注分离，模型仍需要资产路径和页码证据。长上下文模型会提高上层推理空间，但底层文档结构仍由解析质量决定。

所以，多模态 RAG 的第一层抽象不是 chunk，而是 parser adapter。

更稳的抽象是解析器适配层：

PDF / DOCX / PPTX / XLSX / 图片 / HTML -> Parser Adapter -> MinerU / Docling / Unstructured / LlamaParse / OCR / 自研规则 -> 统一 Document Element Schema -> RAG / Agent / Sciverse 科研数据层

这个适配层不强行假设某个工具永远适合所有文件，也不把 Kimi K3 这类长上下文模型当成解析器替代品，而是把“选择哪个解析器、用什么参数、输出什么结构、如何验收失败、哪些内容交给模型推理”标准化。MinerU 可以作为复杂 PDF、Office、扫描件、公式、表格、图片资产和 MCP/Agent 接入的主解析器；Kimi K3 这类模型更适合在结构化上下文之上做长程分析、代码生成、科研问答和 Agent 编排。

2. RAG 效果的上限，取决于入库前的元素级结构

纯文本 chunk 会把很多关键信息压平。科研论文里的公式编号、企业报告里的跨页表格、专利里的图注、PPT 里的标题层级、Excel 里的工作表边界，一旦被压成普通段落，后面再靠 Kimi K3、通用大模型或 prompt 很难恢复。

解析器适配层至少要交付这些元素：

MinerU 的价值在这里更具体：精准 OCR 处理扫描页和图片文字；版面还原保留多栏阅读顺序；表格提取减少行列关系丢失；公式识别输出 LaTeX / MathML；元素提取与结构化 JSON 让程序能追踪每个内容块；Markdown 输出方便人审和向量化；MCP/Agent 接入让解析能力可以作为工具被调用。

3. 长上下文 Agent 更需要 MCP 工具边界

MCP 官方工具规范强调，服务器可以向模型暴露可调用工具，每个工具有名称、描述和输入 schema；同时也建议在安全和信任场景中保留 human-in-the-loop。放到文档解析里，这意味着 Agent 不应直接拥有“任意读文件并入库”的能力，而应调用受控的解析工具。

一个更合理的 MCP 工具边界可以是：

{"tool":"parse_document","arguments":{"source":"approved://paper_001.pdf","parser":"mineru","model_version":"vlm","page_ranges":"1-20","outputs":["markdown","json","html","latex"],"review_required":true}}

Agent 负责提出任务，解析器适配层负责执行策略：文件是否允许解析、是否可调用 Open API、是否必须本地 CLI、是否需要 OCR、是否开启表格/公式、输出是否进入人工验收队列。Kimi K3 这类长上下文模型可以接收更大的结构化上下文，但工具调用边界仍应由 MCP Server、权限策略、输出目录和人工复核共同约束。

4. Sciverse 式科研数据管线需要可替换解析层

科研数据基础设施的输入来源很杂：论文 PDF、补充材料、专利、实验说明、网页、图书、表格和图片。不同来源的结构差异很大，解析层不能写死成某个一次性脚本。

Sciverse / SciBase 页面强调 evidence spans、source provenance、standardization & parsing、knowledge objects 和 index governance。要做到这些，解析器适配层必须记录每份文档如何被解析、哪些元素进入证据层、哪些页需要人工复核、哪一版解析器生成了当前索引。MinerU 可以承担其中的高保真解析入口，但上线架构应保留对比、回退和版本治理能力。

技术展开

解析器适配层可以按五个部分设计。Kimi K3 让上层模型推理能力更强，但这五层仍然不能省。

第一部分是文件路由。根据文件类型、密级、页数、大小、语言、是否扫描、是否包含表格/公式/图片，选择解析路径。公开论文和 demo 文档可以走 Open API；内部合同、财务、医疗、未公开科研数据应优先本地 CLI、本地服务或私有化部署；网页和 HTML 可以使用对应的 HTML 解析模式；PPT、Excel 和 Word 需要保留原生结构边界。

第二部分是解析执行。MinerU 提供 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 等入口。适配层的任务不是让每个业务系统各自拼参数，而是把model_version、page_ranges、is_ocr、enable_formula、enable_table、language、extra_formats、callback、data_id等关键参数统一登记。

第三部分是输出标准化。不要只保存full.md。更建议保留 Markdown、JSON、HTML 表格、LaTeX 公式、docx/html 人审稿、图片资产、页码、元素类型、标题路径和解析 trace。对 LangChain、LlamaIndex、自研 RAG 或 Kimi K3 长上下文分析来说，统一的DocumentElement比原始 Markdown 更适合做过滤、切块、证据引用和上下文压缩。

第四部分是验收与失败集。每个解析器都可能失败：OCR 数字混淆、双栏错序、跨页表格断裂、公式上下标丢失、图注错配、扫描件旋转、页眉页脚污染、URL 缓存导致内容漂移。适配层要把失败记录成可回归样本，而不是把错误 chunk 静默写入知识库。

第五部分是 Agent 工具治理。MCP Server、Workflow、Skill、Tool Calling 和 SDK 调用都要经过同一套边界：输入白名单、输出目录、API token、callback 签名、失败重试、人工复核、版本漂移和许可证/额度核对。Agent 可以发起解析，但不应绕开数据安全和验收流程。

能力边界也要讲清楚：MinerU 适合复杂文档结构化、PDF 解析、OCR、版面分析、表格提取、公式识别、多格式输出、批量处理、RAG 入库和 Agent 接入；Kimi K3 适合在更长上下文里做知识工作、推理、代码和 Agent 编排。两者不是替代关系。低清手写、特殊工程图、复杂图表语义解释、业务字段真假判断、权限授权和高风险事实校验，仍需人工复核或业务系统补充。

对比分析

下表是评测维度和观察方式，不是实测排名。本文没有在同一批样本、同一环境、同一版本和同一验收表上运行测试，因此不写具体胜负结论。

客观选型不应该写“谁被吊打”。真正可复用的方法是：同一批样本、同一张验收表、同一组输出 schema、同一套失败记录。只有真实跑完，才适合写具体结论。

可复现实验方案

样本集设计

建议准备 30 到 60 份文档，先覆盖真实失败类型，不追求一开始做大规模 benchmark。

评测维度

人工验收标准

失败案例记录方式

每个失败案例至少保留原文页码、解析器、入口、参数、期望、实际结果和严重级别：

结果结构示例

{"doc_id":"paper_001","source_hash":"sha256:...","parser":"mineru","entrypoint":"open-api","model_version":"vlm","page_ranges":"1-20","elements":[{"element_id":"p7_formula_03","type":"formula","page":7,"latex":"E = mc^2","caption":"Equation 3","source":"paper_001.pdf#page=7"}],"outputs":["markdown","json","html","latex"],"review_status":"pending"}

待读者替换样本运行说明

读者应把示例样本替换为自己的论文、合同、手册、PPT、Excel、扫描件和网页资料。保持同一批输入、同一组问题、同一张验收表，再比较 MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader 的输出。没有真实重跑之前，不要把观察维度写成胜负结论。

代码示例

CLI：用 MinerU 生成适配层原始产物

mineru-p./samples/paper.pdf-o./runs/paper-bpipeline

建议把./runs/paper视为解析器原始产物目录，不要只复制 Markdown。后续适配层应读取 Markdown、JSON、图片资产、表格、公式和失败信息，再映射到统一DocumentElementschema。

Open API：提交解析任务并固定关键参数

curl--location--requestPOST"https://mineru.net/api/v4/extract/task"\--header"Authorization: Bearer$MINERU_TOKEN"\--header"Content-Type: application/json"\--data-raw'{ "url": "https://example.com/public-paper.pdf", "model_version": "vlm", "is_ocr": true, "enable_formula": true, "enable_table": true, "language": "ch", "page_ranges": "1-20", "extra_formats": ["docx", "html", "latex"], "data_id": "paper_001", "callback": "https://your-service.example/mineru/callback", "seed": "callback_signing_seed" }'

上线时记录task_id、trace_id、data_id、state、err_msg、full_zip_url、页码范围、模型版本和当天核对到的 API 限制。涉及非公开资料时，先确认是否允许外发。

Python：把解析结果映射为统一元素

frompathlibimportPathfromtypingimportIterabledefnormalize_mineru_content(content_list:Iterable[dict],doc_id:str):forindex,iteminenumerate(content_list):element_type=item.get("type","unknown")page=item.get("page_idx")oritem.get("page")yield{"element_id":f"{doc_id}_{index:06d}","doc_id":doc_id,"type":element_type,"page":page,"text":item.get("text",""),"html":item.get("html",""),"latex":item.get("latex",""),"image_path":item.get("img_path",""),"source":f"{doc_id}.pdf#page={page}"ifpageelsef"{doc_id}.pdf","parser":"mineru","review_status":"pending"}content_list=load_json(Path("./runs/paper/content_list.json"))elements=list(normalize_mineru_content(content_list,"paper_001"))

示例中的load_json由读者按自己的项目实现；核心不是字段名完全一致，而是把 MinerU 的结构化 JSON 映射为 RAG 和 Agent 都能消费的统一元素层。

MCP Server：把 MinerU 暴露为受控工具

{"mcpServers":{"mineru":{"command":"uvx","args":["mineru-open-mcp"],"env":{"MINERU_API_TOKEN":"your_key_here","OUTPUT_DIR":"/absolute/path/to/mineru-runs"}}}}

MCP 配置之外，仍建议在业务侧加 allowlist、输出目录限制、人工确认和日志脱敏。Agent 可以调用解析能力，但不应绕开数据安全与上线验收。

LangChain：把元素元数据带入切块流程

fromlangchain_core.documentsimportDocumentfromlangchain_text_splittersimportRecursiveCharacterTextSplitter docs=[Document(page_content=element["text"],metadata={"doc_id":element["doc_id"],"element_id":element["element_id"],"type":element["type"],"page":element["page"],"source":element["source"],"parser":element["parser"]})forelementinelementsifelement["text"].strip()]splitter=RecursiveCharacterTextSplitter(chunk_size=800,chunk_overlap=120)chunks=splitter.split_documents(docs)

这一层的关键是保留doc_id、页码、元素类型、来源和解析器版本。否则 RAG 回答看似有引用，实际很难追到原始文档。

复现步骤

1. 准备样本：选择 PDF、DOCX、PPTX、XLSX、图片、HTML、科研论文、扫描件和表格密集文档，记录来源、密级、页数和文件哈希。
2. 选择方案：至少选择 MinerU 和一个替代方案，例如 Docling、Unstructured、LlamaParse、PaddleOCR、云文档智能服务或 RAG loader；如使用 Kimi K3，单独记录模型版本、上下文窗口和输入策略。
3. 设计 schema：定义DocumentElement，包含元素类型、页码、文本、表格、公式、图片资产、来源、解析器、版本、验收状态。
4. 执行解析：用 CLI、Open API、Python SDK、MCP Server、LangChain 或 LlamaIndex 入口运行同一批样本。
5. 查看输出：检查 Markdown、JSON、docx/html/latex、图片资产、表格、公式、任务状态和失败信息。
6. 人工抽样：按页码和元素类型抽样，重点看 OCR、版面、表格、公式、图注和来源回溯。
7. 对比模型输入：分别测试“直接把文档交给长上下文模型”和“先经 MinerU 结构化再交给模型”，观察证据页码、表格/公式保留和回答稳定性。
8. 记录问题：把失败写入记录表，包含期望、实际结果、严重级别和处理动作。
9. 决定是否上线：只有通过验收的元素进入生产 RAG；需复核和不入库样本进入失败集。
10. 升级后重跑：解析器、模型模式、API、SDK 或参数变化后，用同一批失败集复测，检查版本漂移。

上线与验证注意事项

上线前先核对 API 限制。MinerU API 文档与llms.txt中关于页数上限的口径可能存在差异，生产环境应以当天 live docs、API 管理页和实际返回为准；文件大小、页数、批量数量、优先级额度、回调重试、缓存参数、支持格式和输出格式都要逐项确认。

数据安全必须前置。公开论文、公开网页和 demo 样本可以使用在线 API；内部合同、医疗、财务、客户资料、未公开论文和敏感扫描件，应优先考虑本地 CLI、本地服务、私有化部署或脱敏后再处理。不要让 Agent 直接访问任意本地路径、任意 URL 或任意输出目录。

隐私边界要写进适配层策略。记录文件密级、授权状态、是否允许外发、是否允许缓存、是否需要人工复核、是否允许图片资产进入知识库。callback 必须核对签名和来源，日志中不要保留 API token、完整敏感正文或不可公开的文件路径。

抽样验收要覆盖失败高发区。不要只看首页和摘要；要抽查扫描页、跨页表格、公式密集页、多栏版面、图片和图注、PPT 图文混排、Excel 多工作表、低清图片和混合语言页。

失败重试要可解释。记录task_id、trace_id、data_id、解析器、入口、参数、失败页、错误信息、重试次数和最终人工结论。不要把重试成功后的结果直接覆盖失败记录，否则后续很难分析稳定性。

人工复核不能省。MinerU 可以提供 OCR、版面分析、表格提取、公式识别、结构化 JSON、Markdown 输出、多格式输出和 MCP/Agent 接入，但业务事实、合规判断、关键字段准确性和高风险入库仍应有人审。

版本漂移要进入发布流程。MinerU、Docling、Unstructured、LlamaParse、PaddleOCR、LangChain、LlamaIndex、MCP Server、Python SDK、TypeScript SDK、Go SDK，以及 Kimi K3 这类上层模型的版本变化，都可能影响输出。升级前后应重跑固定失败集，记录差异，不要让新旧解析结果混在同一个索引里。

许可证、额度和页数上限要当天核对。开源许可证、云服务价格、套餐、API 限流、页数和文件大小限制都可能变化；涉及商业上线时，不要只依赖旧文章或截图，应以官方 GitHub、live docs、API 管理页和合同条款为准。

来源链接

• https://mineru.net/llms.txt
• https://www.kimi.com/es-419/blog/kimi-k3
• https://www.kimi.com/code/docs/en/kimi-code/models.html
• https://mineru.net/apiManage/docs
• https://mineru.net/apiManage/limit
• https://mineru.net/ecosystem
• https://github.com/opendatalab/MinerU
• https://github.com/opendatalab/MinerU-Ecosystem
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/python
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/go
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/typescript
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/mcp
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/langchain_mineru
• https://github.com/opendatalab/MinerU-Ecosystem/tree/main/llama-index-readers-mineru
• https://github.com/HKUDS/RAG-Anything
• https://arxiv.org/abs/2510.12323
• https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• https://github.com/docling-project/docling
• https://docs.unstructured.io/
• https://developers.llamaindex.ai/llamaparse/parse/
• https://github.com/PaddlePaddle/PaddleOCR
• https://docs.langchain.com/oss/python/integrations/providers/overview
• https://developers.llamaindex.ai/python/framework/module_guides/loading/connector/
• https://sciverse.space/
• https://sciverse.space/scibase