Build 2026 刚讲完 Agent，我反而重看了一遍 MinerU

写这篇文章的时间是2026 年 6 月 4 日。

如果你这两天刷开发者社区，应该很难绕开三个信号：

• 2026 年 6 月 2 日，微软在 Build 2026 里继续把Agent Platform往前推
• 同样是2026 年 6 月 2 日，OpenAI 连着发了 Codex is becoming a productivity tool for everyone 和 Codex for every role, tool, and workflow，很明显已经不满足于“AI 写代码”这个单点叙事
• 2026 年 5 月 6 日，AWS 宣布 AWS MCP Server GA，MCP 从“有意思的协议”进一步往生产基础设施靠

这几件事放在一起看，其实已经很清楚了：

2026 年开发者圈最热的话题，不再是“哪个模型更强”，而是“怎么把 Agent 真正接进工作流”。

问题也随之变了。

过去我们问的是：

• 模型会不会写代码
• 模型能不能总结文档
• 模型能不能做问答

现在更现实的问题是：

• Agent 拿到的上下文到底干不干净
• 工具链能不能让它稳定调用真实世界的数据
• 一份 PDF、Word、PPT、扫描件，能不能变成 Agent 真能消费的输入

也正因为这个变化，我最近重新看了一遍MinerU。

不是因为“文档解析”这个方向突然变得性感，而是因为在这波Agent / MCP / 多工具编排的热潮里，文档入口这件事，反而成了最容易被忽略、却最影响效果的一层。

1. 这轮 Agent 热潮，真正卡住团队的不是模型，而是上下文

这波 Agent 最大的变化，不是模型突然更聪明了，而是大家都在把它从“会聊天的窗口”变成“会工作的系统”。

从官方表述里已经能看到这个趋势：

• 微软在 Build 2026 里强调的是build, operate, optimize and observe，不是单点模型能力，而是完整的 Agent 平台与治理
• OpenAI 在 6 月 2 日的两篇文章里，已经把 Codex 的使用人群从开发者扩展到了分析师、运营、研究、知识工作者
• AWS MCP Server GA 的重点也不是“多一个协议”，而是把认证、审计、权限边界和观测能力一起做进来

说白了，行业已经不再满足于“让模型回答一个问题”，而是想让它：

• 读取真实文件
• 搜索资料
• 调用内部系统
• 返回带出处的结果
• 在多步工作流里持续执行

这时候，Agent 的表现就不再只取决于模型推理，而更取决于它拿到的上下文质量。

如果上下文是脏的，后面的推理再强也很难救。

这件事在代码场景里不算陌生。我们都知道，给 coding agent 一个脏仓库、坏测试、缺文档，它大概率也写不好。

文档场景也是同一个道理。

给 Agent 一份排版错乱的 PDF、一份公式碎掉的论文、一份表格抽平的财报、一份扫描效果很差的合同，它当然也会答，但那个答案大概率只是“看起来像那么回事”。

所以我越来越认同一个判断：

Agent 时代，最值钱的不是“多一个工具”，而是“把真实世界的数据先整理成工具能吃的样子”。

而文档，恰恰是这件事里最麻烦的一类输入。

2. 为什么文档是 Agent 最难处理的上下文

很多团队第一次做 Agent，都会有一个天然误区：

“文档嘛，不就是 OCR 一下，抽成文本，再丢给模型。”

这个思路在简单场景里勉强成立，但一上真实业务，很快就会露底。

因为文档从来都不只是“文字”。

它往往同时包含：

• 双栏和跨栏排版
• 页眉、页脚、页码、脚注
• 复杂表格
• 图片、图注、流程图
• 公式、化学结构、特殊符号
• 扫描页和原生页混排
• Word、PPT、Excel、HTML 等不同格式

这类内容如果处理不好，Agent 常见的失败方式大概有几种。

2.1 阅读顺序错了，检索就已经偏了

双栏论文、研报、招股书特别容易出现这个问题。

人类读的时候会自然按版面走，但很多轻量文本抽取工具只会机械按坐标或顺序拼接。于是模型看到的内容，根本不是作者原本的表达顺序。

这时候你做 RAG：

• 切块会切错
• embedding 会带上错位上下文
• 检索召回会偏
• 最终回答会“句子都对，但逻辑不对”

2.2 表格一旦被抽平，Agent 就很难再复原

这是财务、法务、医疗、供应链场景里最常见的问题。

模型并不是完全不会理解表格，但前提是你至少得把表格关系保住。

如果文档解析阶段就把：

• 行列关系打散
• 合并单元格丢掉
• 表头错位
• 跨页表拆裂

那 Agent 后面再怎么问，都只能对着一堆数字猜。

2.3 OCR 不是终点，结构化才是

很多团队会把 OCR 当作文档理解的全部，但对 Agent 来说，OCR 只是第一步。

真正关键的是：

• 识别完之后怎么恢复文档结构
• 怎么保留标题层级
• 怎么处理表格和公式
• 怎么输出成后续工具链能继续使用的格式

如果最后产出只是一大段连续文本，那它最多只是“看过了”，谈不上“能稳定调用”。

2.4 多格式混合，是生产系统绕不过去的问题

别看网上讨论 Agent 时经常举 PDF 例子，真实系统里，文档源头通常是混合的：

• PDF
• DOC/DOCX
• PPT/PPTX
• XLS/XLSX
• 图片
• 网页

如果一套系统只能处理其中一两类输入，后面你很快就会补一堆胶水层，最后维护成本远超模型本身。

这也是为什么，文档问题不是“模型看不看得懂”，而是“工程上有没有一层文档编译器”。

3. 这个时间点，我为什么会重看 MinerU

如果只把 MinerU 当作“又一个 OCR 工具”，那确实很难理解它为什么值得在今天讨论。

但如果把它放到Agent / MCP / 可调用工作流这个背景里看，它的位置就不一样了。

根据 MinerU 官方仓库、llms.txt、API 文档和 MinerU-Ecosystem 的公开资料，它现在更准确的定位应该是：

把复杂文档转换成适合 LLM、RAG、MCP、Agent 工作流使用的 Markdown / JSON。

这个表述很重要。

它意味着 MinerU 关注的不是“识字”本身，而是“文档如何进入下游系统”。

截至我在2026 年 6 月 4 日查看的官方公开资料，MinerU 这套体系有几个点是值得认真看的：

• 支持PDF、图片、Word、PPT、网页等输入
• 输出形态面向机器可消费的Markdown / JSON
• 既能处理原生文档，也覆盖扫描文档
• 强调阅读顺序恢复、页眉页脚移除、表格和公式结构保留
• 生态层已经有CLI、Python/Go/TypeScript SDK、LangChain Loader、MCP Server
• MinerU-Ecosystem明确把“Enable my AI agent to parse documents”当成一类官方场景来支持

这几点拼在一起，才是它今天有讨论价值的原因。

它其实不只是“把文档解析出来”，而是在做一件对 Agent 很关键的事：

把人类文档，提前整理成机器工作流可以直接接住的结构。

这一层如果缺失，很多团队表面上在做 Agent，实际上只是把模型接到了更脏的数据上。

4. 不是所有文档工具，都适合放进 Agent 工作流

为了避免把这篇写成“谁都比不过 MinerU”的广告稿，我更愿意用工程分类的方式来讲。

如果你站在 Agent 工作流的视角看，常见文档处理方案大概可以分成四类。

这里我想强调一句很现实的话：

MinerU 不是所有场景都该上。

如果你的输入非常规整：

• 单栏 PDF
• 纯文本为主
• 没有复杂表格和公式
• 不需要进入 Agent、多步调用、引用和深读

那用轻量工具完全可能更合适。

但如果你的目标变成了：

• 让 MCP client 直接读文档
• 让 Agent 从 PDF、Word、PPT 里稳定取上下文
• 让文档进入 LangChain / LlamaIndex / RAGFlow / Dify
• 让结构化结果被后续工具反复消费

这时 MinerU 的价值才开始真正出现。

换句话说，它不是“替代 OCR”，而是更像一层面向 Agent 的文档输入层。

5. 两种最实用的接入方式

这部分我只写两种最容易在今天落地的方式，一种给 Agent，一种给 RAG。

5.1 用 MCP，让 Agent 把 MinerU 当原生工具

这是最近最贴近热点的一种方式。

MinerU-Ecosystem 官方仓库已经给出了 MCP Server 方案，典型配置大概是这样：

{"mcpServers":{"mineru":{"command":"uvx","args":["mineru-open-mcp"],"env":{"MINERU_API_TOKEN":"your_key_here"}}}}

它的意义不在于“又多一个接口”，而在于：

• 文档解析变成了 Agent 可直接发现和调用的工具
• 文档输入不再需要手工预处理后再贴给模型
• 能比较自然地进入 Cursor、Claude Desktop、Windsurf 这类 MCP client 的工作流

如果你最近在折腾 MCP，这个接法其实很顺。

尤其在多格式资料场景里，Agent 不用自己硬啃 PDF，也不用你先手动做一遍“文档转文本”，而是先调用解析工具，再拿结构化结果做后续推理。

5.2 用 LangChain Loader，让文档直接进入检索链路

如果你更偏向 RAG 或知识库工程，那另一条路径是直接用langchain-mineru。

官方仓库给出的思路很直接：

fromlangchain_mineruimportMinerULoader loader=MinerULoader(source="report.pdf",split_pages=True,mode="precision")docs=loader.load()print(docs[0].page_content[:500])print(docs[0].metadata)

这段代码真正重要的不是“能跑起来”，而是后面的Document质量更高：

• 标题层级更接近原文
• 页面切分更自然
• 表格和复杂结构更不容易碎
• metadata 更有机会保留页码、来源、结构信息

对检索系统来说，这意味着你后面的：

• chunking
• embedding
• reranking
• citation

都更有基础。

这一点在 Agent 场景里尤其重要。因为 Agent 不是只回答一次问题，它通常会：

1. 先检索
2. 再读局部
3. 再决定要不要继续调用别的工具
4. 最后返回答案和出处

前面的文档结构越稳，后面的链路就越稳。

6. 如果你今天要评估 MinerU，我建议不要只看“识别率”

很多团队评估文档解析时，还是习惯只看 OCR 准不准。

这在 2026 年其实有点不够了。

如果你的目标是给 Agent 用，我更建议按下面这几个维度来评估：

6.1 结构完整性

• 标题层级是否保留
• 多栏阅读顺序是否正确
• 页眉页脚能否有效去噪
• 图表、段落、列表能否分得开

6.2 机器可消费性

• 输出是不是稳定的 Markdown / JSON
• 结构字段是否适合后续程序处理
• metadata 是否足够支撑页码和引用

6.3 工作流兼容性

• 能不能直接接进 LangChain / LlamaIndex
• 能不能通过 MCP 暴露给 Agent
• 能不能和现有 RAG、知识库、自动化系统接起来

6.4 成本与复杂度

• 简单文档是否值得用重方案
• 复杂文档能不能用一套体系覆盖
• 云端与本地的边界是否清楚

如果只看“识别几个字”，你很可能会低估 MinerU。

但如果把评估目标改成：

这份文档最后能不能稳定地进入 Agent 的检索、推理、调用、归因链路？

那它的价值就会更容易看清。

7. 一个更现实的判断：今天该不该写 MinerU

回到这篇文章开头的问题。

为什么我觉得2026 年 6 月 4 日这个节点，适合发一篇关于 MinerU 的深度技术文？

不是因为“文档解析”突然成了最热关键词。

而是因为这几天真正热的是：

• Agent
• MCP
• 工作流编排
• 知识工作自动化

而这些话题一旦真的往深处走，都会撞到一个现实问题：

上下文从哪里来？

代码上下文可以来自仓库。

业务上下文可以来自数据库、API、CRM、工单系统。

但大量关键知识，仍然躺在：

• PDF
• Word
• PPT
• 网页
• 扫描件

这些文档里。

你不把这层打通，Agent 就永远只能在“会调用工具”和“真的拿到可用知识”之间反复打滑。

从这个角度看，今天写 MinerU，不是在蹭文档解析的热点，而是在蹭一个更大的主题：

当大家都在谈 Agent 时，哪些底层基础设施会变得更重要？

我的判断是，文档输入层一定会是其中之一。

而 MinerU，恰好是这个位置上少数已经把：

• 复杂文档解析
• 机器可读输出
• MCP 接入
• RAG 生态
• Agent 工作流

这些点串起来的项目。

这也是它今天最值得讨论的地方。

8. 最后一句实话

我现在越来越少相信那种“某个模型、某个 Agent、一夜之间改变一切”的叙事。

真正能把系统跑起来的，往往不是最响亮的概念，而是那些不起眼但必须做对的中间层。

文档解析就是这种中间层。

过去它只是 OCR 工程、知识库预处理、搜索系统前置步骤的一部分。

但到了今天，它开始变成 Agent 真正工作的入口。

所以这篇文章如果只想留一个结论，我会写得很直接：

这轮 Agent 热潮里，很多人高估了模型本身，低估了文档上下文。

而 MinerU 值得重看，恰恰不是因为它“会解析文档”，而是因为它在试图解决一个更现实的问题：

怎么把复杂文档变成 Agent 真能用的输入。

这件事，可能比“再换一个更强的模型”更影响最后的效果。

参考资料

• Microsoft Build 2026: Be yourself at work
  https://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/
• OpenAI: Codex is becoming a productivity tool for everyone
  https://openai.com/index/codex-for-knowledge-work/
• OpenAI: Codex for every role, tool, and workflow
  https://openai.com/index/codex-for-every-role-tool-workflow/
• AWS: The AWS MCP Server is now generally available
  https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/
• Model Context Protocol Architecture
  https://modelcontextprotocol.io/specification/2025-06-18/architecture
• MinerU 开源仓库
  https://github.com/opendatalab/MinerU
• MinerU-Ecosystem
  https://github.com/opendatalab/MinerU-Ecosystem
• MinerU Open API 文档
  https://mineru.net/apiManage/docs
• MinerUllms.txt
  https://mineru.net/llms.txt