一、现有文档解析在复杂表格场景中的核心挑战

在供应链结算、财务报销和企业对账等场景中，文档自动化处理看起来已经很成熟：单据上传后，OCR 能够识别出大部分文字和数字，系统也可以进一步做入库、检索或审批流触发。但在实际落地过程中，我遇到过一个很典型的问题：TextIn xParse供应链结算时，一张发票、一份采购单和一份对账单里的信息都已经识别出来了，但系统始终无法准确匹配对应字段，金额校验也经常失败，最终还是需要财务人工核对；结果就是，原本希望实现自动流转的业务流程，又回到了人工核对、人工修正的状态。

问题的根源并不是 OCR 没有“看见内容”，而是文档中的结构关系没有被正确保留下来。比如一张供应链结算单中，供应商信息、采购方信息、结算明细、金额汇总和合计行同时存在，系统不仅要识别出“256,780.00”这样的数字，还要知道它到底属于含税金额、税额还是不含税金额。

所以，在企业级文档处理中，OCR 解决的是“看见内容”，而真正影响下游系统使用的是“理解结构”。当文档中出现嵌套表格、合并单元格、多层表头等复杂结构时，传统解析方案很容易出现结构断裂，导致识别结果虽然可读，但无法直接用于 ETL、RAG 或 Agent 自动化流程。

这也是本文关注供应链结算单的原因：它既包含供应商、采购方、明细表和金额汇总，又涉及字段匹配、金额校验和审批判断，能够较集中地体现复杂表格解析的结构化难点。

1.1 文档解析技术流程的本质链路

从工程角度来看，一个完整的文档解析流程通常包含以下几个阶段：

• 图像预处理（去噪 / 倾斜矫正 / 增强）
• 版面分析（Layout Detection）
• 表格结构识别（Table Structure Recognition）
• 内容识别（OCR Text Recognition）
• 语义重建（Semantic Reconstruction）

在理想情况下，这一流程可以输出结构化 JSON、Markdown 或数据库可用结构。对于普通表格来说，只要行列关系清晰，解析系统通常可以较好地恢复字段和值的对应关系。

但在实际业务单据中，表格结构往往没有这么简单。以供应链结算单为例，主表中可能包含供应商信息、采购方信息、结算明细和金额汇总，有些单元格内部还会继续包含金额拆分。这类“表格中再包含局部结构”的情况，本质上就是嵌套表格。

在嵌套表格场景中，问题往往出现在第三和第五阶段：

• 表格结构识别阶段无法准确表达“主表—子表”的嵌套关系；
• 语义重建阶段无法恢复字段、金额、合计行之间的业务归属关系。

因此，复杂表格解析的难点不只是把文字识别出来，而是要在识别之后继续保留表格内部的层级关系和业务含义。

1.2 嵌套表格带来的核心困难

嵌套表格本质上是一种“表中结构”，而不是简单的二维表格。

在实际业务文档中，它通常表现为：

• 单元格中包含子表
• 子表具有独立行列结构
• 子表与主表存在父子关系绑定

例如在供应链结算单中：

• 主表：订单信息 / 金额汇总
• 子表：金额拆分 / 税额结构 / 明细分类

此时如果解析失败，通常会出现三类问题：

• 子表被拍平成文本流
• 父子关系丢失
• 汇总逻辑无法建立

因此，复杂表格解析的关键并不是单纯提升文字识别率，而是要让系统保留“字段属于谁、金额对应哪一列、合计行服务于哪一组明细”这些业务关系。后面的实测也会围绕这一点展开。

二、嵌套表格解析失败对结算单自动化处理的影响

在进入具体工具实测之前，可以先看这类解析失败会如何影响结算单自动化处理。对于供应链结算单来说，下游系统真正需要的不是一段可读文本，而是一份可计算的数据结构。

如果解析工具把这些内容拍平成普通文本，或者在表格重建时出现字段错位、数字错误、合计行归属不清，那么后续的自动入库、金额校验和审批判断都会受到影响。

2.1 自动入库：字段错位会导致结算数据不可用

在这张供应链结算单中，系统通常需要把供应商信息、采购方信息、结算明细和金额汇总分别写入不同字段。例如，供应商名称、统一社会信用代码、单据编号、含税金额、税额、不含税金额等字段，都需要稳定落到对应位置。

如果解析结果只是连续文本，或者表格列关系没有保留下来，就会出现很直接的问题：单据编号可能被截断，金额字段可能对应错列，“合计”行也可能被当成一条普通明细写入系统。这样一来，即使文字识别看起来没有太大问题，最终进入数据库的数据仍然是不可靠的。

对于结算单处理来说，最危险的不是系统直接报错，而是数据成功写入了，但业务含义已经发生偏移。例如税额被写入含税金额列，或者合计金额被当成普通订单金额，后续对账和审计时就会持续放大问题。

2.2 金额校验：数字识别出来了，但无法判断属于哪一列

结算单自动化处理中，一个很常见的任务是做金额校验。例如系统需要判断每条明细中的“含税金额 = 不含税金额 + 税额”，并进一步核对合计行是否等于所有明细金额之和。

但这个任务成立的前提是，解析结果必须保留字段归属关系。系统不仅要识别出这些数字，还要知道它们分别对应“含税金额”“税额”和“不含税金额”。

如果表格结构被打散，模型或程序看到的只是几个相邻数字，就无法稳定完成金额校验。它可能知道这些数字都来自结算单，但不知道每个数字属于哪一列，也就无法判断计算关系是否正确。

2.3 审批判断：结构不稳定会让自动化流程退回人工整理

在这张结算单中，另一个常见任务是审批判断。例如系统需要遍历所有结算明细，筛选出含税金额超过 20 万元的单据，并生成财务复核建议。

这类逻辑本身并不复杂，理想情况下可以直接写成类似下面的结构化处理流程：

for order in data["orders"]:
    if order["amount_with_tax"] > 200000:
        trigger_finance_review(order)

但如果解析结果中没有 orders 这种结构化列表，或者金额字段只是散落在一段文本里，Agent 或业务系统就无法直接执行判断。它要么需要重新让大模型从文本中猜测字段归属，要么需要开发者额外写规则进行二次解析。

这样一来，原本希望实现的“自动读取结算单、自动校验金额、自动生成审批建议”，就会退化为“先人工整理表格，再半自动处理”。所以，对这类供应链结算单来说，文档解析的关键不是简单识别文字，而是把结算单转换成字段明确、关系稳定、可被程序直接处理的数据对象。

三、供应链结算单结构解析实测：PaddleOCR、MinerU 与 xParse 对比

为了验证上述问题到底出现在“文字识别”还是“结构理解”层面，我选用同一张供应链结算单图片作为测试样本，对不同方案进行同条件对比。测试文档并不是一个只有单一表格的简单样本，而是一个典型的复合型业务文档，这个样本同时覆盖了长数字字段识别、文本块划分、表格结构还原、汇总区域抽取以及多区域版面理解几个关键问题，比较适合用来观察不同解析方案在真实业务单据场景下的能力边界。

重点关注四个维度：文本识别稳定性、结构还原能力、表格一致性以及结果是否可直接用于下游系统（ETL / RAG / Agent）。

3.1 PaddleOCR 实测表现：文本可读，但结构完全扁平化

PaddleOCR 在该样本中可以正确识别大部分文字与数字内容，例如供应商信息、采购方信息及主表数据，但整体输出呈现明显的文本流结构，文字识别还算准确：

但主要问题集中在：

• 长数字字段（统一社会信用代码、单据编号）存在截断或错误
• 主表被展开为连续文本，缺乏列结构表达
• “合计”等汇总行与普通数据无法区分
• 业务字段之间缺乏结构绑定关系

从工程角度来看，这种输出的本质问题并不在于“有没有识别出来”，而在于“识别之后没有结构重建能力”，也就是说PaddleOCR完成的是从图像到文本的映射，但没有完成从文本到业务结构的组织，因此在进入ETL或数据库写入阶段时，开发者仍然需要依赖大量规则去重新切分字段、对齐列关系以及手动恢复表格结构，否则数据无法直接进入可计算状态。

3.2 MinerU 实测表现：版面结构恢复能力增强，但字段一致性与关系表达仍存在偏差

MinerU 表现与 PaddleOCR 有明显不同。它的优势在于，对文档版面和表格轮廓的恢复能力更强，尤其是在 Markdown 视图下，已经可以把这张结算单重构成相对完整的结构结果：

但是从实际结果细节来看，其问题主要集中在字段级一致性与跨字段关系表达上，例如部分数字字段仍然存在识别误差或轻微截断现象，单据编号等关键索引字段在部分行中出现不完整情况，同时主表虽然被还原为结构化表格形式，但在列与列之间的严格对齐上仍存在一定偏差，这会在下游计算场景中仍然存在一定歧义。

整体来看，MinerU更接近于一种“结构可视化重建工具”，它能够帮助用户理解文档长什么样，但在“让系统真正理解数据之间关系”这一层能力上仍然存在一定缺口。

3.3 xParse 实测表现：结构化表达完整，文档被转化为可计算对象集合

在xParse的解析结果中可以明显看到，其输出方式已经不再停留在简单的文本或表格还原层面，而是将整份文档拆解为带有明确语义类型的结构化元素集合，每一个元素都具备独立的 type、coordinates、page_number 以及 element_id 等信息，从而使得文档从“视觉对象”转变为“结构对象”：

具体来看，标题“供应链结算单”被识别为Title类型，结算单编号、结算期间、结算日期以及币种等基础字段被拆分为独立的NarrativeText节点，而供应商信息与采购方信息则被分别识别为独立Table结构单元，不再混合在统一文本流中，使得整个文档在逻辑上被拆分为多个可独立消费的结构单元。

从工程视角来看，这种输出方式的关键意义在于，它不再要求开发者在下游系统中重新进行结构推断，而是直接提供了一组可遍历、可定位、可索引的结构化对象集合，因此无论是进入ETL系统进行字段入库，还是进入RAG系统进行语义切分，亦或是进入Agent或Codex工作流进行逻辑调用，都可以直接基于结构本身进行操作，而不需要额外依赖复杂的规则重建。

四、文档解析与 Agent 系统的结合方式：基于 Codex 的实际工作流

在完成工具对比后，我进一步尝试把 xParse 接入到 Codex 工作流中，验证它是否能够从“网页上的解析工具”进一步变成 Agent 可以调用的文档解析能力。这个部分的重点不是单纯演示接口调用，而是观察文档解析能力如何作为一个标准工具，被 Codex 这类编程 Agent 直接使用，并把一张图片形式的供应链结算单转换成结构化结果。

4.1 在 TextIn 控制台获取接口密钥

首先需要在 TextIn 控制台进入“账号与开发者信息”页面，获取后续调用接口所需的 x-ti-app-id 和 x-ti-secret-code。

TextIn 控制台会在开发者信息区域展示对应的 App ID 和 Secret Code，并提供复制入口。这个步骤相当于为后续 MCP Server 或 xparse-cli 提供认证凭证，只有完成这一步，Agent 才能通过工具调用方式访问 TextIn 的解析能力：

4.2 在 Codex 环境中配置 TextIn MCP Server

拿到密钥后，下一步是在 Codex 配置文件中增加 MCP Server 配置。实际配置中使用的是 @intsig/server-textin，通过 npx 启动，并在 env 中写入 APPID、APPSECRET 和请求超时时间。配置形式如下：

[mcp_servers.textin-ocr]
command = "npx"
args = ["-y", "@intsig/server-textin"]
timeout = 600

[mcp_servers.textin-ocr.env]
APPID = "你的APPID"
APPSECRET = "你的APPSECRET"
MCP_SERVER_REQUEST_TIMEOUT = "600000"

4.3 安装 xParse Skill，让 Codex 具备文档解析指令能力

除了 MCP Server 之外，还可以通过 npx skills add intsig-textin/xparse-skills --yes 安装了 xParse Skill：

安装完成后，系统显示已安装 xparse-parse，其能力包括使用 xparse-cli 将 PDF、图片、Office 文档、HTML、OFD 等文件解析为干净的 Markdown 或结构化 JSON，同时支持加密 PDF、指定页码范围、Markdown / 纯文本输出和结构化提取等功能。

这一点和普通 API 调用的区别在于，Skill 更贴近 Agent 的使用习惯。用户不需要每次都手写完整接口调用代码，而是可以直接对 Codex 说“用 xparse-cli 解析这份结算单”，Agent 会根据当前环境自动调用对应工具。对于开发者来说，这种方式降低了文档解析能力接入 Agent 的门槛。

4.4 使用 xparse-cli 解析供应链结算单，Codex 返回结构化内容

完成配置后，我直接在 Codex 对话中输入指令，让 Codex 调用 xparse-cli 对供应链结算单图片进行解析。从实际结果来看，Codex 成功运行了解析命令，并返回了 JSON 视图中的全部结构化数据，包括每个元素的坐标、类型、表格单元格内容、页面信息等：

在结算明细表部分，Codex 展示出了完整的表格结构，并保留了 5 条明细数据和合计行，解析的十分正确：

4.5 结构化结果进入 Codex 业务逻辑

当 Codex 获取到 xParse 的结构化结果后，后续流程就可以从“文本理解”转向“对象处理”。例如，对于这张结算单，可以让 Codex 继续执行以下任务：提取所有单据编号并生成对账清单，筛选含税金额超过 20 万元的单据，核对合计金额是否等于所有明细金额之和，生成财务审批摘要，或者把主表转换成 CSV / JSON 供 ERP 系统导入：

整个链路可以概括为：

供应链结算单图片
→ xparse-cli 结构化解析
→ Codex 获取 JSON / Markdown
→ 解析结算明细表
→ 执行金额判断、合计校验、审批摘要生成

如果没有结构化解析，Codex 只能面对一段复杂文本，需要通过自然语言推理去猜测字段归属；而有了 xParse 的结构化结果后，Codex 可以直接围绕表格对象、字段对象和汇总对象进行处理。这个差异决定了 Agent 工作流能否从“辅助阅读”升级为“可靠执行”。

五、结论：真正的分水岭不是 OCR，而是结构能不能被系统使用

这次用同一张供应链结算单做测试后，最直观的感受是：复杂文档解析的难点，已经不只是“字能不能识别出来”，而是识别出来之后，数据还能不能保持原来的业务关系。PaddleOCR 更像是把图像中的文字读出来，MinerU 能进一步还原版面和表格形态，而 xParse 更突出的地方在于，它把标题、主体信息、交易明细、金额汇总、备注和签章区拆成了可定位、可遍历的结构化元素，让这张结算单不再只是一张“可阅读的图片”，而是变成了可以被程序处理的数据对象。

这对财务、供应链、审计、知识库和 Agent 自动化系统很关键。更有意思的是，在 Codex 中接入 xParse Skill / MCP 后，文档解析不再是一个孤立工具，而是变成了 Agent 可以直接调用的能力。过去的流程是“上传文件—下载结果—人工整理—再交给程序”，现在可以直接让 Codex 调用 xparse-cli 解析文档，并继续完成字段提取、金额判断、合计校验和审批摘要生成。

从产品能力来看，**TextIn Xparse面向的并不是单一 OCR 识别场景，而是更完整的智能文档处理链路。**它可以将 PDF、图片、Office、OFD 等多类型文档解析为 Markdown、JSON 等结构化结果，并进一步支持 API、MCP Server 和 Skill 等方式接入开发者工作流。对于需要处理合同、票据、表格、报告、申请表和业务单据的企业来说，这类能力的价值在于把原本只能“人工阅读”的文档，转化为可以被系统消费的数据。

尤其是在复杂表格、嵌套表格、多层表头、跨页表格和混合版式文档中，TextIn xParse 的作用不只是识别文字，而是尽可能保留标题、段落、表格、坐标、页码、元素类型和结构关系。这样解析结果才能继续进入 ETL、RAG、Agent、ERP、审批流等下游系统，而不是停留在一份需要人工二次整理的文本结果。

所以这次测试给我的结论是：OCR 解决“看见内容”，结构化解析解决“组织内容”，而 TextIn xParse 更适合解决复杂业务文档进入 AI 工作流之前的关键一步——把文档变成 Agent 和业务系统真正能处理的数据。

体验链接（注册送1000页额度）：https://www.textin.com/register/code/Q3XMV4