写这篇文章的时间是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 GAMCP 从“有意思的协议”进一步往生产基础设施靠这几件事放在一起看其实已经很清楚了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 例子真实系统里文档源头通常是混合的PDFDOC/DOCXPPT/PPTXXLS/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 ServerMinerU-Ecosystem明确把“Enable my AI agent to parse documents”当成一类官方场景来支持这几点拼在一起才是它今天有讨论价值的原因。它其实不只是“把文档解析出来”而是在做一件对 Agent 很关键的事把人类文档提前整理成机器工作流可以直接接住的结构。这一层如果缺失很多团队表面上在做 Agent实际上只是把模型接到了更脏的数据上。4. 不是所有文档工具都适合放进 Agent 工作流为了避免把这篇写成“谁都比不过 MinerU”的广告稿我更愿意用工程分类的方式来讲。如果你站在 Agent 工作流的视角看常见文档处理方案大概可以分成四类。类型典型工具优点缺点更适合什么场景纯 OCRTesseract、PaddleOCR 基础识别成熟、便宜、部署简单结构恢复有限接入 Agent 还要补很多层图片识别、单字段抽取轻量文本抽取PyMuPDF、pdfplumber、MarkItDown快、依赖少、简单 PDF 很顺手多栏、表格、公式、扫描件容易出问题简单 PDF 转文本云端解析服务LlamaParse、部分 SaaS Parser接入方便效果通常比纯抽文本好成本、可控性、格式边界、隐私约束快速 PoC、云端管线面向 Agent 的复杂文档解析MinerU多格式、结构化输出、可进 MCP / RAG / Agent对简单文档不一定是最低成本方案复杂文档知识流、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 loaderMinerULoader(sourcereport.pdf,split_pagesTrue,modeprecision)docsloader.load()print(docs[0].page_content[:500])print(docs[0].metadata)这段代码真正重要的不是“能跑起来”而是后面的Document质量更高标题层级更接近原文页面切分更自然表格和复杂结构更不容易碎metadata 更有机会保留页码、来源、结构信息对检索系统来说这意味着你后面的chunkingembeddingrerankingcitation都更有基础。这一点在 Agent 场景里尤其重要。因为 Agent 不是只回答一次问题它通常会先检索再读局部再决定要不要继续调用别的工具最后返回答案和出处前面的文档结构越稳后面的链路就越稳。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 的深度技术文不是因为“文档解析”突然成了最热关键词。而是因为这几天真正热的是AgentMCP工作流编排知识工作自动化而这些话题一旦真的往深处走都会撞到一个现实问题上下文从哪里来代码上下文可以来自仓库。业务上下文可以来自数据库、API、CRM、工单系统。但大量关键知识仍然躺在PDFWordPPT网页扫描件这些文档里。你不把这层打通Agent 就永远只能在“会调用工具”和“真的拿到可用知识”之间反复打滑。从这个角度看今天写 MinerU不是在蹭文档解析的热点而是在蹭一个更大的主题当大家都在谈 Agent 时哪些底层基础设施会变得更重要我的判断是文档输入层一定会是其中之一。而 MinerU恰好是这个位置上少数已经把复杂文档解析机器可读输出MCP 接入RAG 生态Agent 工作流这些点串起来的项目。这也是它今天最值得讨论的地方。8. 最后一句实话我现在越来越少相信那种“某个模型、某个 Agent、一夜之间改变一切”的叙事。真正能把系统跑起来的往往不是最响亮的概念而是那些不起眼但必须做对的中间层。文档解析就是这种中间层。过去它只是 OCR 工程、知识库预处理、搜索系统前置步骤的一部分。但到了今天它开始变成 Agent 真正工作的入口。所以这篇文章如果只想留一个结论我会写得很直接这轮 Agent 热潮里很多人高估了模型本身低估了文档上下文。而 MinerU 值得重看恰恰不是因为它“会解析文档”而是因为它在试图解决一个更现实的问题怎么把复杂文档变成 Agent 真能用的输入。这件事可能比“再换一个更强的模型”更影响最后的效果。参考资料Microsoft Build 2026: Be yourself at workhttps://blogs.microsoft.com/blog/2026/06/02/microsoft-build-2026-be-yourself-at-work/OpenAI: Codex is becoming a productivity tool for everyonehttps://openai.com/index/codex-for-knowledge-work/OpenAI: Codex for every role, tool, and workflowhttps://openai.com/index/codex-for-every-role-tool-workflow/AWS: The AWS MCP Server is now generally availablehttps://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/Model Context Protocol Architecturehttps://modelcontextprotocol.io/specification/2025-06-18/architectureMinerU 开源仓库https://github.com/opendatalab/MinerUMinerU-Ecosystemhttps://github.com/opendatalab/MinerU-EcosystemMinerU Open API 文档https://mineru.net/apiManage/docsMinerUllms.txthttps://mineru.net/llms.txt