MCP 2026-07-28 规范把 Elicitation、用户同意、工具安全和结构化结果放到 Agent 工程前台。对文档解析和 KIE 来说，这意味着 PDF、Office、扫描件和科研资料不能再“解析完就入库”。本文用 MinerU 的 OCR、版面分析、表格提取、公式识别、结构化 JSON、MCP Server、Python SDK 和 Open API，拆解一套可复现的“可确认字段抽取”方案。

热点背景

过去做企业知识库或科研 RAG，常见流程是：上传 PDF，解析成 Markdown，切块，向量化，然后让 Agent 问答。这个流程能快速跑通 Demo，但一到生产就会遇到一个更细的问题：很多关键事实不是自然段，而是字段。

合同里的金额、发票里的税号、论文里的材料配方、实验表里的指标、专利里的权利要求编号、医学报告里的单位、财报里的科目和期间，都不是“读懂大意”就能安全入库的内容。它们需要被抽成结构化字段，同时保留来源页码、表格位置、公式上下文、解析参数和人工复核状态。

近期 MCP 规范的公开资料给这个问题补上了工程语言。MCP 2026-07-28 规范把服务器能力分为 Resources、Prompts、Tools，把客户端能力里的 Elicitation 定义为“由服务器发起、向用户请求额外信息”的能力，并在安全原则里强调用户同意、数据隐私和工具安全。换到文档解析场景，这意味着 Agent 不能只会调用 parse_documents，还要在字段不确定、Schema 不清楚、文件权限敏感或结果要入库前，向用户确认。

MinerU 官方 llms.txt 将 MinerU 定义为面向 LLM、RAG 和 Agent 工作流的智能文档解析平台，支持 PDF、Word、PPT、图片、HTML 等输入，输出 Markdown、JSON、LaTeX、HTML 等结构化结果，并覆盖 CLI、Open API、Python SDK、Go SDK、TypeScript SDK、MCP Server、LangChain、LlamaIndex 等生态入口。KIE 使用说明进一步把流程拆成 Parse、Split、Extract：先解析，再按组切分，再按 Schema 做字段抽取，结果支持表格视图和 JSON 视图。

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

这个趋势也自然关联 Sciverse 类科研数据基础设施。Sciverse 官网强调面向科研 Agent 的可信科学证据数据层，包含全文证据、图表资源和 Agent 可消费的 AI-Ready 数据。科研 Agent 如果要从论文中抽取“材料、指标、实验条件、图表证据、公式定义”，就不能只依赖全文 chunk，而需要字段、来源、复核和版本共同构成的可追踪记录。

核心观点

1. Agent 时代，KIE 不应是静默抽字段，而应是可确认抽字段

KIE 的风险不在于“抽不到字段”，而在于“抽到了看似合理但无法复核的字段”。一个字段如果没有来源页、元素类型、表格坐标、原文片段、抽取规则和复核状态，就不应该直接进入默认知识库。

更稳的流程是：

文档解析 -> 字段候选 -> 不确定性检查 -> 用户确认 / 修改 -> 结构化入库

这里的“反问”不是让用户参与所有步骤，而是在关键节点触发确认：Schema 是否正确、字段是否需要单位、金额是否含税、表格跨页是否合并、公式是否要保留 LaTeX、敏感文件是否允许走外部 API、结果是否可以进入 RAG。

2. RAG 的可信上限，取决于入库前字段是否带证据

RAG 系统经常把文档切成 chunk，但字段级任务需要更细的结构。比如用户问“这篇论文里样品 B 的强度是多少”，答案可能来自表格；问“公式中的 λ 是怎么定义的”，答案可能来自公式前后的段落；问“合同续费条款什么时候生效”，答案可能来自某一页的小标题和脚注。

MinerU 的价值在于先把 PDF/Office/图片转成可处理的元素资产：精准 OCR 处理扫描文字，多语言 OCR 保留专有名词，版面分析还原阅读顺序，表格提取保留行列关系，公式识别输出 LaTeX/MathML，结构化 JSON 保存元素类型和位置，Markdown 用于人工阅读和 RAG 入库。KIE 应该站在这些结构之上，而不是绕过解析层直接让大模型“看图猜字段”。

3. MCP 让反问成为协议能力，而不是产品补丁

如果文档解析作为 MCP Server 暴露给 Agent，工具调用自然会变多：解析文件、解析 URL、列出 OCR 语言、保存输出、读取结果、触发抽取、写入知识库。MCP 的 Elicitation 和用户同意原则提醒我们：字段抽取系统要能在必要时停下来问用户，而不是把所有不确定性吞进结果里。

例如：

场景Agent 应该反问的问题
Schema 缺少单位字段金额、剂量、温度、强度是否需要统一单位？
表格跨页是否把连续表格合并为同一字段数组？
文件含敏感信息是否允许上传到托管 API，还是改用本地 CLI/私有化路径？
字段冲突以正文、表格还是附录为准？
结果入库通过人工抽样前是否只进入候选库？

4. Sciverse 类科研数据层需要字段级证据，而不是只要全文

科研数据处理不只关心“论文讲了什么”，还关心“某个值来自哪张表、哪页、哪个实验条件、是否可复算、是否能跨论文比较”。如果把论文直接切成文本块，Agent 很难稳定回答这些问题。

字段级结构更适合 Sciverse 类场景：

对象应保存的结构
实验指标字段值、单位、表格位置、页码、样本条件
公式LaTeX/MathML、编号、上下文定义、页码
图表证据图表文件、图注、相关段落、原文位置
结论字段原文片段、抽取规则、复核状态、版本

技术展开

面向 MinerU 的“可确认 KIE”可以拆成六层。

第一层是输入分级。公开论文、公开网页、公开产品手册可以用 Open API 或 MCP 快速验证；内部合同、财务、医疗、客户资料、未公开科研数据和受版权约束材料，要优先考虑本地 CLI、本地服务、私有化部署或明确授权后的受控上传。官方 llms.txt 当前写明免登录 Agent API 适合 PDF URL 解析，文件限制为不超过 10MB、20 页；登录精准解析 API 通过 POST https://mineru.net/api/v4/extract/task 提交任务，支持最大 200MB、600 页，并可输出 Markdown、JSON、docx、html、latex。上线时仍应以 live docs、账户后台和实际 API 返回为准。

第二层是解析分层。不要先抽字段，先解析文档。对扫描件检查 OCR；对双栏论文检查版面顺序；对表格检查表头、单位、跨页和合并单元格；对公式检查上下标、编号和 LaTeX；对图片和图表检查资源是否保存、图注是否跟随。只有解析结构可靠，KIE 字段才有证据基础。

第三层是 Schema 分层。MinerU KIE 使用说明显示 Extract 模块支持 Schema 驱动的结构化抽取，并支持智能 Schema 推荐；字段类型覆盖 String、Number、Boolean、Date、Enum、Object、Array、Null。KIE FAQ 当前写明字段数量上限为 25 个，抽取规则自然语言指导不超过 500 字。工程上建议先把字段分为必填、可选、需人工复核三类。

第四层是确认分层。字段确认不应该只在 UI 上点“通过”。记录里至少要保存 field_name、value、unit、source_page、source_element、evidence_text、confidence_note、review_status、reviewer、parser_version 和 schema_version。对金额、法律义务、医学结论、科研指标和安全参数，默认进入 needs_review。

第五层是 Agent 接入。CLI 适合本地样本和回归；Python SDK 适合批量任务和异步轮询；Open API 适合服务端集成；MCP Server 适合 Agent 工具调用；LangChain、LlamaIndex 适合把通过验收的 Markdown、JSON、字段表和证据片段进入 RAG。关键是不要让这些入口各自定义一套字段口径。

第六层是边界控制。MinerU 可以承担精准 OCR、公式识别、表格提取、版面还原、多格式输出、多语言支持、元素提取、结构化 JSON、Markdown 输出、MCP/Agent 接入、RAG 入库、批量处理和私有化部署能力，但它不能替代业务判断。字段是否成立、是否合规、是否可作为科研结论或合同承诺，仍需要人工验收和组织内责任边界。

对比分析

下面这张表不是实测排名，而是上线前的评测维度。没有用同一批样本真实运行前，不应写具体胜负结论。

方案适合场景评测维度观察方式边界
传统 OCR扫描件文字提取、归档检索字符准确率、多语言、低清、倾斜抽样比对原图和关键字段表格、公式、版面、字段证据需额外处理
通用大模型直接读文档少量公开材料、临时问答引用稳定性、字段一致性、幻觉率让模型回到页码、表格和原文片段难以批量复现，隐私和成本需核对
云厂商文档智能服务票据、表单、已有云栈模板字段、区域合规、API 限制记录错误码、结果 JSON、任务状态科研公式、复杂论文和私有化需自测
开源 PDF 工具文本型 PDF、轻量 ETL文本抽取、页码、速度、依赖逐页检查文本和 metadataOCR、复杂版面、图表和 KIE 需要组合工具
RAG 框架 loaderDemo、轻量知识库chunk 边界、metadata、召回证据检索结果能否回链到页和元素不等同于字段抽取和人工验收
Docling本地多格式转换、GenAI 数据准备文档表示、导出格式、表格/图片用同一批样本检查结构完整性中文、科研复杂样本和部署资源需自测
Unstructured元素化解析、连接器、文档 ETLpartition、元素类型、chunk、表格检查元素 metadata 和下游入库公式、图表语义和成本边界需自测
LlamaParseLlamaIndex 生态、托管解析Markdown/JSON、解析模式、索引集成对比字段来源、输出结构和费用数据边界、额度、区域和价格需当天核对
MinerU 可确认 KIEPDF/Office/图片到字段证据，RAG/Agent/Sciverse 入库OCR、表格、公式、版面、JSON/Markdown、KIE、MCP/SDK/API建立 Parse -> Split -> Extract -> Review 记录表API 限制、版本漂移、人工复核和隐私边界需治理

可复现实验方案

样本集设计

建议从 30 份文档起步，覆盖字段抽取常见风险，而不是只选排版干净的 PDF。

组别文档类型数量建议必测内容通过标准
A合同 / 协议 PDF5主体、金额、期限、续约、违约条款字段值可回到原文页和条款
B发票 / 表单 / 扫描件5OCR、税号、金额、日期、印章关键字段人工核对无歧义
C科研论文 PDF5作者、机构、指标、实验条件、公式表格/公式字段有证据位置
D企业报告 / 财报5跨页表格、科目、期间、单位表头、单位、行列关系正确
EDOCX / PPTX / XLSX5标题层级、表格、图表、sheetOffice 原生结构不被压平
FSciverse / 科研数据材料5图表资源、引用、实验字段、数据说明可形成 AI-Ready 字段证据

评测维度

维度检查内容观察方式
OCR错字、漏字、重复字符、O/0 混淆对照原图抽查关键字段
版面多栏顺序、标题层级、页眉页脚对照原文阅读顺序
表格行列、表头、单位、跨页、合并单元格比对 Markdown/HTML/JSON 表格
公式LaTeX、MathML、上下标、编号对照公式截图和上下文
字段 Schema类型、必填、枚举、数组、嵌套检查 Schema 是否与业务问题一致
证据回链页码、元素、原文片段、文件哈希字段能否回到源文档
Agent 反问敏感文件、字段冲突、单位缺失是否触发人工确认
入库控制accepted / needs_review / rejected未复核字段是否被阻断

人工验收标准

每份文档至少抽查 3 类元素：正文段落、表格或公式、字段证据。高风险字段必须满足四个条件：字段值正确、单位明确、来源可回链、复核状态可查。任何涉及金额、法律义务、医学判断、科研结论、专利权利要求、设备参数和安全规范的字段，不应仅凭自动抽取直接入库。

失败案例记录方式

失败记录要能复跑，而不是只写“抽错了”。

字段示例
case_idpaper_007_metric_03
doc_typeresearch_pdf
page8
element_typetable
field_nametensile_strength_mpa
entrypointMCP Server
paramsmodel=vlm, table=True, formula=True
expected样品 B 强度为原表对应数值，并保留 MPa 单位
observed字段值来自样品 C 行
severityhigh
review_statusrejected
can_indexfalse

示例记录表

case_id文档页码字段方案观察结果验收状态是否入库
kie_001contract_01.pdf4renewal_termMinerU KIE + MCP条款页码正确，但自动摘要过短needs_review否
kie_002invoice_03.png1tax_idMinerU OCR + Extract末位 0/O 疑似混淆needs_review否
kie_003paper_05.pdf8sample_strengthMinerU Python SDK表格行列正确，单位保留accepted是
kie_004report_02.pdf12net_profitOpen API跨页表头需人工确认needs_review否
kie_005slides_04.pptx6product_metricLlamaIndex 对照可读但缺少页内元素证据needs_review否

待读者替换样本运行说明

读者应把上表中的 contract_01.pdf、invoice_03.png、paper_05.pdf 替换为自己的真实样本。至少选择 MinerU 与一个对照方案，例如 Docling、Unstructured、LlamaParse、传统 OCR、云厂商文档智能服务或 RAG loader。保持同一批文档、同一页码范围、同一字段 Schema、同一人工验收表，再比较输出结构、失败类型和复核成本。

代码示例

MCP Server：让 Agent 先解析，再在关键字段前确认

MINERU_API_TOKEN=your_key mineru-open-mcp --transport streamable-http --port 8001

{
  "mcpServers": {
    "mineru": {
      "type": "streamableHttp",
      "url": "http://127.0.0.1:8001/mcp"
    }
  }
}

Agent 侧建议把入库前确认写成策略，而不是默认自动写入：

{
  "tool": "parse_documents",
  "input": {
    "path": "./samples/paper_05.pdf",
    "model": "vlm",
    "output_format": ["markdown", "json"],
    "pages": "1-10"
  },
  "review_gate": {
    "ask_user_before_upload": true,
    "require_review_for": ["amount", "legal_clause", "medical_value", "research_metric", "formula"],
    "index_only_when": "review_status == 'accepted'"
  }
}

上面 review_gate 是建议的业务侧控制字段，不是 MinerU 官方 MCP 工具的固定参数。它的作用是把 MCP 的用户同意、Elicitation 和工具安全思想落到文档解析流程里。

Python SDK：解析后保存字段验收记录

import os
import time
from hashlib import sha256
from pathlib import Path

from mineru import MinerU

source = Path("./samples/paper_05.pdf")
file_hash = sha256(source.read_bytes()).hexdigest()

client = MinerU(api_key=os.environ["MINERU_API_TOKEN"])

batch_id = client.submit(str(source))

while True:
    results = client.get_batch(batch_id)
    result = results[0]
    if result.state in ("done", "failed"):
        break
    time.sleep(3)

if result.state != "done":
    raise RuntimeError(f"parse failed: {result.state}")

review_record = {
    "doc_id": source.name,
    "file_hash": file_hash,
    "entrypoint": "Python SDK",
    "parse_state": result.state,
    "field_schema_version": "research_metric_v1",
    "candidate_fields": [
        {
            "field_name": "sample_strength",
            "value": None,
            "unit": "MPa",
            "source_page": None,
            "review_status": "needs_review"
        }
    ],
    "markdown_preview": result.markdown[:1000]
}

print(review_record)

Open API：提交精准解析任务，再把 JSON 交给 KIE / 人审

curl --request POST "https://mineru.net/api/v4/extract/task" \
  --header "Authorization: Bearer $MINERU_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "url": "https://example.com/sample.pdf",
    "model_version": "vlm",
    "is_ocr": true,
    "enable_formula": true,
    "enable_table": true
  }'

建议把返回的任务 ID、文件 URL、页码范围、参数、解析时间和输出资源一起写入验收表，再进入 KIE 的 Parse -> Split -> Extract 流程。

能力矩阵

能力对可确认 KIE 的作用建议验收项
精准 OCR支撑扫描件字段识别关键编号、金额、日期、单位
表格提取支撑结构化字段和数组表头、行列、跨页、单位
公式识别支撑科研指标和推导字段LaTeX、上下标、编号、上下文
版面还原支撑字段证据定位标题层级、阅读顺序、页码
结构化 JSON支撑程序验收和差异比对元素类型、位置、metadata
Markdown 输出支撑人工阅读和 RAG 入库可读性、chunk 边界、引用
MCP/Agent 接入支撑工具调用和反问确认用户同意、工具 allowlist、日志
Python SDK / Open API支撑批量处理和系统集成任务状态、错误码、重试、版本

复现步骤

  1. 准备样本：选择 PDF、扫描件、图片、DOCX、PPTX、XLSX、科研论文、合同、财报和历史失败样本，记录来源授权、文件哈希、密级和页码范围。
  2. 选择方案：至少选择 MinerU 和一个对照方案，明确使用 CLI、Open API、Python SDK、MCP Server、LangChain 或 LlamaIndex 哪个入口。
  3. 设计 Schema：定义字段名、类型、单位、必填状态、枚举值、数组结构、证据字段和复核状态。
  4. 执行解析：先生成 Markdown、JSON、表格、公式、图片等解析资产，不要直接把字段写入知识库。
  5. 执行 KIE：按 Parse -> Split -> Extract 流程抽取字段，复杂长文档先按章节、表格或业务组切分。
  6. 查看输出：检查表格视图、JSON 视图、页码、元素来源、字段单位和异常状态。
  7. 人工抽样：对金额、科研指标、公式、表格、合同条款、医学字段和安全参数做人工复核。
  8. 记录问题：用固定失败表记录 case_id、页码、字段、期望、观察结果、严重级别和处理结论。
  9. 决定是否上线：只有 accepted 字段进入 LangChain、LlamaIndex、自研知识库、MCP resource、向量库或 Sciverse 数据层；needs_review 只进入候选库；rejected 不入库。

来源链接

  • https://mineru.net/llms.txt
  • https://mineru.net/apiManage/docs
  • https://mineru.net/apiManage/limit
  • https://mineru.net/apiManage/kie-sdk
  • https://mineru.net/apiManage/kie-usage
  • https://github.com/opendatalab/MinerU
  • https://github.com/opendatalab/MinerU-Ecosystem/tree/main/sdk/python
  • 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://modelcontextprotocol.io/specification/2026-07-28
  • https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation
  • https://modelcontextprotocol.io/specification/2026-07-28/server/tools
  • https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices
  • https://sciverse.opendatalab.com/
  • https://huggingface.co/datasets/opendatalab/Sci-Base
  • https://github.com/docling-project/docling
  • https://docs.unstructured.io/
  • https://docs.cloud.llamaindex.ai/llamaparse/getting_started
  • https://python.langchain.com/docs/concepts/document_loaders/
  • https://docs.llamaindex.ai/en/stable/module_guides/loading/
# git # 人工智能
Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

Google能索引，AI却抓不到

很多技术团队有个错觉：只要Google能正常收录，内容就没问题。但现实是，你的页面在Google搜索结果里好好的，在ChatGPT、Perplexity、Claude的答案里却像从未存在过一样。

avatar MCP技术社区
cover

Windows 下部署 New API 中转站全过程实录（含 6 个真实踩坑）

avatar MCP技术社区

初识智能体

在过去两年中，几乎所有人都体验过大语言模型（如 ChatGPT、Claude、DeepSeek）的强大能力：写周报、润色邮件、解答编程疑难。被动响应：你问一句，它答一句。如果你的 Prompt 没有写清楚约束条件，它无法主动追问或修正目标。知行脱节：大模型能用流畅的文字告诉你“如何部署一个高可用 K8s 集群”，但它无法替你登录服务器敲下命令、查看报错日志并自动回滚。信息孤岛：大模型的知识止步于预

avatar MCP技术社区