TextIn xParse + Codex 实操：把复杂 PDF 表格解析成 Agent 可用数据

前言：

最近我在做一个 Agent 工作流测试：让 Agent 读取一份 PDF
技术报告，自动提取实验平台、硬件配置、系统环境和测试指标，再生成结构化对比摘要。

一开始我以为难点在 Agent 能不能总结，实际跑下来发现，真正影响结果的是更前面的一步：文档解析是否足够稳定。

尤其是表格。人看表格时，可以自然理解表头、行列、合并单元格和跨页内容；但对程序来说，如果表头层级丢了、合并单元格归属错了、行列关系错位了，哪怕每个字都识别对了，最后得到的数据也可能无法被下游使用。

这次我上手体验的是 TextIn xParse。它不是单纯把文档“转成文字”，而是更偏向把复杂文档解析成可继续消费的结构化结果，比如输出 Markdown、JSON，再接入知识库、RAG、Agent 或自定义工作流。

下面我会先聊复杂表格解析为什么会影响 Agent 的判断，再用同一张复杂业务表格对比 TextIn xParse、PaddleOCR 和 MinerU 的解析效果，最后把 xParse 接入 Codex，让解析能力进入 Agent 工作流。

一、复杂表格解析，真正难的不是识字，而是保留结构

在 Agent 工作流里，文档解析经常被当成一个前置步骤：先把 PDF 或图片解析出来，再让 Agent 总结、抽取、比对、入库或者生成报告。但这个前置步骤一旦出错，后面的结果也会跟着偏。

很多文档解析问题，不是在 OCR 阶段暴露的。

你打开解析结果，可能会发现文字都在，数字也没错，甚至顺序看起来也差不多。但一旦把结果交给程序处理，问题就来了。

比如：

• 多层表头被拍平成一行，下游不知道某个数值属于哪个大类；
• 合并单元格被拆散，原本共享的字段没有继承；
• 密集小字表里，行列发生错位；
• 嵌套表格的内外层关系混在一起；
• 跨页长表到了下一页，表头丢了，数据变成孤立行。

这些问题对人来说不一定明显，因为人会自动脑补上下文。但对 RAG、ETL、Agent 来说，它们不会“脑补”。它们只会相信输入。

所以当解析结果结构不稳时，后面的链路都会被影响：

RAG 可能召回了错误的单元格内容，回答时把字段张冠李戴；

ETL 入库时字段对不上，后续统计结果偏差；

Agent 根据解析结果执行操作时，可能拿错金额、日期或参数；

审计回溯时，也很难从最终结果追到原文档里的准确位置。

这就是我理解的“复杂表格解析断层”：表面上文档已经解析完了，实际上数据还没有进入可用状态。

对于开发者来说，判断文档解析是否完成，不能只看“识别率”或者“文字有没有出来”，而应该看结果能不能直接进入下游流程。

所以我这次没有只看“识别出了多少字”，而是先用一张真实业务里的复杂表格做对比：同一张图，分别交给 TextIn xParse、PaddleOCR 和 MinerU，看它们能不能把表格结构保留下来。

二、先看效果：同一张复杂业务表格，解析结果差在哪

我们可以先直接在 TextIn 官网体验 xParse：

这次我在官网上传了一张更接近真实业务场景的复杂表格图片：一份开放式基金交易业务申请表：

这类表格不是简单的“几行几列”。它同时包含基金账户信息、交易账号、业务申请类型、认/申购、赎回、转托管、基金转换等多个业务区域，而且每个区域里又混合了文本字段、勾选框、合并单元格、金额拆分格、份额拆分格和横向长表头。

对人来说，这是一张常见的金融业务申请表；但对解析系统来说，它的难点非常集中：

• 表单和表格混在一起：既有“基金账户名称”“基金账号”“交易账号”这类字段，也有大块金额表格；
• 合并单元格很多：左侧业务类型、右侧填写区域、金额大小写区域经常跨行跨列；
• 金额和份额被拆成多个小格：比如“佰、十、亿、仟、佰、拾、万……”这种位数表头，如果结构错位，金额含义就会变；
• 勾选项和业务字段强绑定：比如“认/申购”“基金转换”等勾选项，必须和对应区域里的基金名称、代码、金额、份额保持关系。

这也是金融表单解析里很典型的痛点：不是把字识别出来就够了，而是要知道每个字段属于哪个业务区域，每个金额格对应哪个位数，每个勾选项控制的是哪一块内容。

我分别用 TextIn xParse、PaddleOCR 和 MinerU 对同一张图做了解析对比。

TextIn xParse：复杂结构保留更完整，适合继续进入下游流程

从 TextIn xParse 的解析结果看，整体结构保留得比较完整。

首先，顶部的基础信息区域能够按照字段关系展开。比如基金账户名称、基金账号、交易账号等内容，没有只是被识别成一段散乱文本，而是仍然保留了“字段名 - 字段值”的对应关系。

其次，在业务申请类型区域，xParse 对“认/申购”“赎回”“转托管/转出/转入”“基金转换”等不同业务块的边界识别比较清楚。每个业务类型左侧的勾选项和右侧填写区没有明显混在一起，后续如果要让 Agent 判断用户办理的是哪类业务，或者抽取某一类业务下的基金代码、金额、份额，结构基础会更稳。

更关键的是金额和份额区域。原图里很多金额不是普通数字，而是按中文金额位数拆成多个小格，例如“佰、十、亿、仟、佰、拾、万、仟、佰、拾、元、角、分”。xParse 在解析时保留了这类横向位数表头和下方填写格之间的对应关系。对于金融表单来说，这一点很重要，因为金额一旦错位，含义就会完全不同。

另外，xParse 还可以切换查看 Markdown、JSON、表格、公式、图片、手写、页眉页脚等不同类型的解析结果。也就是说，它不是只给出一段 OCR 文本，而是把文档拆成更适合下游继续使用的结构化内容。

对于这类金融表单来说，解析质量的核心不是“页面看起来像不像”，而是字段、勾选项、金额位数和业务区域之间的关系有没有保留下来。xParse 在这几个复杂点上的结构保留更完整，后续使用成本也更低。

PaddleOCR：能识别部分文字，但复杂表格结构保留不足

PaddleOCR 在这张图上的结果，更能体现“OCR 识字”和“复杂文档结构化解析”之间的差异。

从结果看，它能识别出标题和部分文字，但对于表格主体，尤其是业务申请类型下方的大块复杂表格，并没有完整还原出可用的行列结构。

也就是说，在这种金融申请表场景里，单纯 OCR 的结果离“下游可用”还有距离。文字识别出来只是第一步，真正影响业务自动化的是结构是否还能被程序理解。

MinerU：表格区域识别较完整，但复杂表单关系仍需关注

MinerU 对这张图的表格区域也做了较完整的识别，能够看到它尝试把原图中的大表格还原成结构化表格。对于一些常规行列关系，它的展示效果比单纯 OCR 更接近原始表格。不过在这张基金业务申请表里，难点不只是表格边框，而是表单字段、业务区域、勾选项、合并单元格和金额位数之间的关系。

从结果看，MinerU 能把大块表格识别出来，但部分内容会更偏向把表格整体摊开，嵌套结构识别不出来。比如“认/申购金额”“赎回份额”“转托管份额”“转换份额”等区域，本身都包含大写、小写、位数表头和填写格。如果下游要直接做字段抽取或金额校验，还需要进一步确认每个小格和表头的对应关系是否稳定。

这组对比之后，我对复杂表格解析的判断也更明确了：先在官网上传同一张复杂表格，可以快速验证工具到底能不能保住业务结构；但官网体验更多解决的是“效果确认”问题，真正要进入生产流程，还需要让解析能力变成 Agent 可以随时调用的工具。所以接下来，我就不只停留在网页上传测试，而是尝试把 TextIn xParse 接入 Codex，让它成为 Agent 工作流里的一环。

三、Codex接入 xParse ：先装 Skills，再让 Agent 调用解析能力

官网对比能帮助我确认解析效果，但如果要进入真实 Agent 工作流，就不能一直停留在“手动上传、手动下载结果”的阶段。

我的思路是：先把 xParse 相关能力装进 Agent 环境里，让 Agent 在需要时自动调用解析工具，把 PDF 或文档转成 Markdown / JSON，再继续做总结、抽取、校验、入库等后续处理。

整体流程大概是这样：

原始文档 ↓ xparse-skills / xparse-cli ↓ TextIn xParse API 解析 ↓ Markdown / JSON 结构化结果 ↓ Agent / RAG / 知识库 / ETL / 自定义脚本

第一步是先安装xparse-skills。在 Agent 环境里，可以直接让它帮忙安装：

装好之后，再安装xparse-cli。macOS / Linux 可以在终端执行：

source <(curl -fsSL https://dllf.intsig.net/download/2026/Solution/xparse-cli/install.sh)

安装完成后，用下面命令验证版本：

xparse-cli version

Windows PowerShell 可以用：

irm https://dllf.intsig.net/download/2026/Solution/xparse-cli/install.ps1 | iex

如果是在 Agent 环境里，也可以更简单：直接让 Agent 帮忙安装。

比如在 Codex 这类开发 Agent 里说一句：

帮我装 xparse-cli

Agent 会自动执行安装命令，并在完成后返回版本信息。这个体验对我来说比较顺，因为很多时候我并不想在不同工具之间来回切换。

安装好之后，需要配置 API 密钥。登录 TextIn 控制台，在设置里拿到：

APP_ID SECRET_CODE

然后执行：

xparse-cli auth

按提示粘贴 APP_ID 和 SECRET_CODE 即可。配置完成后，凭证会保存在本地配置文件里，后续解析文档时会自动生效。

也可以检查当前配置：

xparse-cli auth --show

如果不想交互式输入，也可以通过环境变量配置：

export XPARSE_APP_ID=你的_APP_ID export XPARSE_SECRET_CODE=你的_SECRET_CODE

到这里，Agent 就可以在本地环境中调用 xParse 解析文档了。

四、从“解析文档”到“给 Agent 使用”

我这次比较关注两个输出格式：Markdown 和 JSON。

Markdown 更适合人读，也适合交给大模型做总结、问答、改写、归纳。比如让 Agent 把一份 PDF 解析成 Markdown，再继续提取关键信息、生成报告或者做结构化摘要。

命令很简单：

xparse-cli parse 文件.pdf

如果想保存到本地目录：

xparse-cli parse 文件.pdf --output ./outputs/

JSON 更适合程序继续处理。比如要把表格内容入库、做字段映射、做批量校验，或者让 Agent 基于结构化字段执行后续动作，JSON 会更稳。

xparse-cli parse 文件.pdf --view json

保存到目录：

xparse-cli parse 文件.pdf --view json --output ./outputs/

如果只想解析指定页，也可以加页码范围：

xparse-cli parse 文件.pdf --page-range "1-5"

在 Agent 场景里，我更常用的方式不是自己手动敲完整命令，而是直接描述目标：

帮我把这份 PDF 解析成 Markdown，保存到本地。

Agent 会调用对应命令，把结果文件保存下来。这样 xParse 就不只是一个“解析工具”，而是变成了 Agent 工作流里的一个基础能力。

我这次测试的 PDF 就是一份技术报告，里面有多页实验环境和测试结果表格。这类表格看起来只是普通测试环境说明，但对后续 Agent 来说非常关键。因为 Agent 如果要继续分析报告，首先要知道每一组测试结果是在什么硬件和软件环境下产生的。

如果这些表格结构没有被正确保留下来，后续分析就很容易出错。

比如：

• Agent 可能把国产 GPU 平台的 CPU、内存或 OS 信息和 A100 参考平台混在一起；
• 跨页表格如果断开，下一页的测试指标可能失去对应的实验平台上下文；
• 如果表头层级丢失，Agent 很难判断某个参数到底属于硬件配置、系统环境还是测试工具。

这就是技术报告解析里的典型痛点：OCR 把字识别出来还不够，真正重要的是保留“字段和字段之间的关系”。

因为下游 Agent 不是只要知道文档里出现过 “A100” 或 “BI-V150”，而是要知道各种具体的信息，后续测试结果必须放在对应环境下解读。

一旦这些关系被破坏，Agent 后面做总结、横向对比、性能归因或生成测试结论时，就可能基于错误上下文继续推理。

从实际解析结果看，xParse 对这类技术报告表格的行列关系、换行内容、合并单元格和层级表头保留得比较完整。输出的 Markdown / JSON 不只是“把文字提出来”，而是能基本维持原文档里的表格结构。

从实际解析结果看，xParse 对表格行列关系、合并单元格和层级表头的保留比较完整：

这样后续交给 Agent 时，就可以继续做更具体的任务：

• 自动提取实验平台配置；
• 汇总不同测试项对应的运行环境；
• 根据测试结果生成性能分析报告；
• 在 RAG 知识库中按平台、硬件、系统环境或测试指标进行检索。

所以xParse 的作用不是简单地把技术报告“转成文字”，而是把报告里的实验环境、测试条件和表格数据转成 Agent 能继续使用的结构化输入。

对于技术报告、评测报告、实验记录、软硬件适配文档这类材料来说，复杂表格解析的价值会非常明显。因为很多结论都依赖表格里的上下文：同一个性能数字，放在不同 CPU、GPU、内存、系统和驱动环境下，含义完全不同。只有上游解析把结构保住了，后续 Agent 才能更可靠地做总结、对比、归因和报告生成。

五、回到 Agent 工作流：文档解析质量决定后续 AI 应用的上限

回到一开始的任务：让 Agent 读取技术报告，自动提取实验平台、硬件配置、系统环境和测试指标，再生成结构化对比摘要。

这个任务真正依赖的，不只是 Agent 的总结能力，而是它拿到的输入是否可靠。

如果上游解析结果已经把表格结构弄乱了，Agent 往往不会停下来怀疑数据，而是会基于错误结构继续执行。它可能把 A100 参考平台的系统环境套到国产 GPU 平台上，也可能把某个测试指标放到错误的硬件配置下解释。最后生成的报告看起来逻辑完整，但底层依据可能已经错了。

复杂表格里最容易影响 Agent 的几类场景包括：

• 多层表头：只保留最底层字段后，指标归属容易混淆；
• 合并单元格：共享字段没有继承到每一行，入库时容易出现空值；
• 跨页长表：翻页后表头丢失，后续数据变成没有上下文的孤立内容；
• 密集小字表：行列错位后，字段和数值对应关系会被打乱；
• 嵌套表格：内外层结构混在一起，下游很难再恢复。

所以复杂表格解析的重点，不是“看起来像不像原文”，而是数据还能不能被程序继续使用。

换句话说，Agent 需要的不是一段看起来差不多的文本，而是结构稳定、关系清楚、可以继续抽取、问答、入库或执行的数据。

从这次体验来看，TextIn xParse 更像是文档进入 Agent 工作流前的一层“结构化入口”。它解决的不是简单识字，而是把复杂文档里的表格、字段和上下文关系尽量保留下来，并以 Markdown、JSON、表格等多种形式继续流向下游。

如果你的业务里有大量 PDF、扫描件、技术报告、金融表单、招投标文件或复杂表格，并且后面还要接 RAG、知识库、Agent 或自动化脚本，可以直接拿自己的复杂表格去 TextIn xParse 试一下。

体验链接（注册送1000页体验额度）：传送门