一个能把企业文档“吃干抹净”的AI,究竟有多离谱?

前言：

随着AI的极速变革，企业开始让 Agent 参与采购、审合同、跟进订单，一个问题却变得越来越具体：模型理解了任务，那作出判断所需的业务知识从哪里来？交付条件在合同里，设备要求在参数表里，最新变更可能还留在一封邮件中。这些材料记录着企业如何运转，却未必能直接成为 AI 可用的输入。过去，员工靠经验把它们联系起来，知道哪个版本有效，也知道表格下的一条备注可能改变整个判断。如今，这些工作逐渐交给 Agent，原本依赖人工补齐的信息关系，就需要被更完整地保留下来。文档解析的质量，会影响企业知识以什么样的面貌进入 AI 工作流。

这也是我关注 TextIn xParse 的原因。它处理复杂材料中的内容与结构，为后续检索、核验和问答提供基础。理解这层能力的价值，可以先从一张看似普通的设备参数表开始。

1. 读懂文档里的关系

企业文档里有很多信息，是靠排版表达的。一个数字放在哪一列，决定它是今年的数据还是去年的数据。一个标题管到哪里，决定后面几段话适用于哪类产品。几行参数共用一个单元格，则意味着它们归属于同一型号。

把文字逐个识别出来，只完成了其中一部分。原有的结构一旦丢掉，下游模型就得根据零散内容重新猜关系。这也是复杂文档解析值得单独做的原因。

TextIn xParse 是面向 LLM 和 Agent 的文档智能基础设施，负责把复杂文档转成可供 AI 使用的结构化数据。 放在 RAG 知识库里，它处在文档进入检索流程的前端；放在办公 Agent 中，它为后续抽取、核对和问答提供输入。

xParse 可以识别标题层级、阅读顺序和表格结构，处理跨页表格、合并单元格等情况，并输出 Markdown、JSON 等形式的结果。对于知识库和 Agent，这些结构决定了后续如何切分、检索和使用文档。

这次使用的是一张单页参数表。TX-200 和 TX-300 各有两种配置，型号单元格纵向合并；“电气参数”和“环境参数”下面还有第二层表头；增强版的温度带着星号，指向表下的一条限制条件。

上传 xParse 后，原图和解析结果可以对照着看。这张表的合并单元格、多级表头保留了下来，表下的附加条件也被提取出来。

这意味着，180 W 仍然对应 TX-200 增强版，280 W 仍然对应 TX-300 低温版。额定功率和待机功耗没有混成同一个字段，温度后面的附加条件也有文字可供继续核对。对于下游任务，这些关系比单纯得到一串数字更有用。

解析后的结构，决定了后续任务能拿到多少完整信息。这会影响知识库怎么切分内容。表格的条件和数值如果在前面就被拆散，后面即使检索到了某个数字，也可能没找到它的适用范围。等到模型开始生成答案，再要求它“认真核对”，未必补得回已经丢失的关系。

2. 从复杂文档到业务数据

同样是 PDF，里面装的东西可能完全不同。

有些文件保留着电子文本，有些页面其实是扫描图片，还有些材料把电子页和扫描页混在一起。一份技术规范中，也可能同时出现正文、参数表、公式和图纸。

让这些材料都按同一种方式处理，很容易遇到不适合的页面。

xParse 结合电子解析、OCR 和多模态解析，按页选择解析链路。电子页利用原本可读取的信息，扫描页处理图像中的文字与版面；遇到图纸、公式等复杂视觉内容，则可以通过 xParse–VLM 增强理解能力。

对接入团队来说，统一的文档处理入口可以减少为不同格式分别搭建流程的工作。业务应用继续关心字段怎么用、规则怎么校验，解析层负责先把各类材料整理成可用的输入。

我还会特别看一个不太起眼的能力：原文定位。

xParse 的解析结果可以保留版面元素、页码和坐标信息。这对办公场景很实在。Agent 给出一个参数后，审核的人通常还会追问：它在原文哪里？前面有没有限定条件？

如果结果保留了这些定位信息，下游应用就有条件把答案和原件联系起来。真正做到点击回看，还需要应用把定位信息接到界面上，但底层至少要先把依据留下。

结构化数据也方便继续加工。Markdown 便于查看文档的段落与层级；JSON 方便程序读取字段和元素信息。遇到复杂表格，应该按实际输出检查它如何表达合并关系，而不是只要求结果变成一张平整的文本表。

企业里的业务链路往往还要再走一步。采购订单、发票、收货单被放在同一个文件包里，先得分清各是什么，才能提取金额、日期和订单号，继续核对它们是否一致。

这时可以搭配 DocFlow：完成混合文档包的拆套分类、字段抽取、结构归一、校验审核与人工复核。xParse 提供文档结构和内容，DocFlow 承接面向业务字段的处理工作。

解析与业务审核的分工，在这里就变得具体了。解析层负责保留原文信息，抽取层负责把不同表达映射到业务字段，审核层继续检查这些字段之间是否一致。金额能够识别，不等于三张单据的金额已经核对完毕；日期能够提取，也不等于交付安排没有冲突。

3.解析如何影响答案

很自然会有人问：现在的模型已经能接收 PDF 和图片了，为什么还要增加解析这一步？

对一份内容简单的短文档，直接上传确实方便。增加一个环节有没有价值，要看具体材料和任务，尤其要看完整流程，而不只是模型最后说了什么。

为了看看这一步会怎样影响回答，我用前面那张参数表做了对照。模型和提示词保持一致，分别在两个新会话中提问。

一组直接上传原图，另一组使用 xParse 解析后的内容。五个问题涉及额定功率、工作温度、供电范围、适用条件和功耗口径，都要求列出原文依据，不补充材料以外的信息。

最明显的差异出现在第二题。直接读图的一组，把 TX-200 增强版的工作温度写成了 10～45 ℃，在“原文依据”里也漏掉了负号。xParse 解析后的一组，则正确回答了 −10～45 ℃。

也有两组都做对的地方。满负载连续运行时，环境温度上限为 40 ℃，两边都结合脚注答了出来；TX-300 低温版的防护等级、启动电压范围，以及功耗不能直接相加的条件，也都回答正确。这次是单页样本的一次对照，能确认的是一个具体的数字读取差异。它不足以推导模型整体准确率，也没有覆盖跨页表格或完整链路耗时。但它提醒了我：回答看起来完整，不代表每一个字符都可靠。企业里核对技术参数、合同金额和采购数量，恰好就容不得这些小偏差。少一个负号、错一个单位，可能让人重新检查整份答案。对这类任务，评价效果时要回到原件逐项核对，不能只看回答是否通顺。

效率还要放到连续的业务流程里看。同一份技术文件，今天用于选型，明天可能用于采购核验，之后还会进入知识库。保存好的解析结果可以继续供这些任务使用，减少重复处理原件的工作。这类复用的收益，需要结合文档规模、更新频率和接入方式来衡量。对企业团队来说，独立的解析层还有一个工程价值：问题可以被定位。如果原件中的数据没有进入解析结果，就先处理输入；如果数据完整却没有被检索到，就检查切分和召回；如果上下文已经齐全，答案仍然出错，再看模型如何使用这些信息。不同环节有了可检查的结果，系统才更容易持续改进。

这比反复修改同一段提示词更接近企业应用的实际需要。一次演示可以靠人工补齐上下文，持续运行的系统却需要让文档处理、结果核验和后续复用都有稳定的位置。

4. 让多个智能体共享知识

当一份材料能够被准确解析，企业还会遇到下一层问题：同一个客户出现在多个系统里，合同约定和最新进度可能不同，业务资料也会随时间变化。单独读懂每个文件之后，还需要把这些事实关联起来，维护各自的来源与有效状态。

近期，在QCon 全球软件开发大会上，合合信息旗下企业 AI 基础设施 TextIn 推出了企业知识服务引擎。它依托 xParse 和 DocFlow 已有的文档处理能力，进一步把分散信息组织成 Agent 持续可用的上下文。

这里的上下文，是 Agent 完成当前任务所需的业务背景。它既包括文档里的内容，也包括内容属于哪个客户、关联哪张订单、当前是什么版本。把这些关系组织好，Agent 才能围绕业务问题取用信息，企业也不必为每个新任务重复整理同一批材料。

拿订单交付举个例子：CRM 里写着“A 公司”，合同上是“A 有限公司”，ERP 使用客户编码。合同约定 10 月 30 日交付，订单的最新预计时间却变成了 11 月 5 日。

员工问：“这笔订单能按时交吗？”要回答它，需要先知道几条记录指向同一客户、同一笔业务，再把合同约定和最新进度放在一起核对。合同日期依然有效，最新预计也需要保留，两者的差异正是判断延期风险的依据。生产运营场景示意，将物料、工艺、设备与产能等信息关联到订单，辅助识别交付风险。

企业知识服务引擎接入 PDF、Office、图片、CAD、网页、数据库、邮件等多源数据，经过解析与抽取，关联业务对象，维护关系、规则、来源和版本，再供 Agent 查询和使用。业务人员需要核查时，可以沿着当前事实回到通知单、邮件和原文片段。知识持续更新，原来的证据也需要留下，这样才能解释一次判断究竟依据了什么。

它和底层文档技术的关系也很清楚：xParse 保留文档结构与原文位置；DocFlow 按业务需要提取和核验字段；知识服务引擎继续把信息组织成带有关系和证据的业务知识。

这套知识还可以通过 API、MCP 和 SDK 等方式供不同 Agent 使用。交付 Agent 关注订单和生产进度，回款 Agent 关注合同、账单和付款记录，两者可以围绕同一客户获取各自需要的信息，减少重复建设和维护的工作。

“共享记忆库”也就有了具体含义：业务事实有来源，变化有记录，不同 Agent 能在相应权限下使用同一套知识。私有化部署、权限控制和人工确认，则让企业能按自己的 IT 环境与审核要求使用这套服务。

总结

企业落地 Agent，要解决的是如何让多年积累的业务知识持续发挥作用。合同里的约定、图纸中的参数、散落在邮件里的变更记录，只有被准确解析、关联和核查，才能成为可靠的判断依据。xParse 保留内容与结构，DocFlow 完成字段抽取与业务核验，企业知识服务引擎进一步组织这些信息，让多个 Agent 能够共同使用。

我认为，这类基础设施的长期价值，在于让企业的知识积累能够跟上 AI 应用的扩展。模型会更新，业务会变化，企业不应该每增加一个 Agent，就重新整理一遍材料。当一次文档处理的成果能够被后续任务反复使用，AI 建设的投入才会逐渐沉淀为组织自身的能力。 企业过去积累的经验，也才有机会在新的业务判断中继续发挥作用。

想先看看复杂文档的解析效果，可以直接注册登录 TextIn xParse，上传自己的材料试一试。企业知识服务引擎目前尚未正式上线，已开启预约试用。 如果你正在建设企业知识库，或者希望多个 Agent 共用业务资料，可以点击这里提交预约申请：https://b.intsig.com/solution-apply?from=Qcon_20261022