在我们委托对500名重度依赖文档工作的美国专业人士进行的调查中，88%的人表示他们对其分析和AI系统的数据准确性充满信心。然而，同样是这88%的人报告称，他们至少偶尔会在源自文档的数据中发现错误。这两个事实同时存在，而这种矛盾正是为何我们需要AI Agent的结构化数据的根本原因。
这不是数据统计上的假象。这是当今大多数团队的真实运作状态：充满自信，却又经常犯下足以产生实际影响的错误。你的Agent正好处于该数据的下游，却没有任何Agent会停下来思考：“等一下，这个总金额看起来不对劲”。
因此，当Agent卡壳、向错误的供应商付款、或者针对错误的保单号提出索赔时，人们的本能反应往往是责怪模型，并试图寻找更好的模型替代。但其实模型通常没有问题。真正缺失的是模型处理前的那个关键步骤：那个将新到达的文档转化为真正经过人工规则检验的命名字段的步骤。
分为六个阶段。全过程无需开发人员。具体方法就在下面。
核心要点
- AI Agent的结构化数据意味着使用具有可预测类型的命名字段，而不是让Agent在运行时自行解析文档内容。
- Agent在处理文档时会在四个具体方面遭遇失败：扫描件缺乏OCR层、发送方之间的布局变化（漂移）、悄无声息的字段遗漏，以及缺乏用于核对的置信度信号。
- Gartner预计到2027年底，超过40%的Agentic AI（代理型AI）项目将被取消。其另一项预测是：到2026年，缺乏AI就绪数据（AI-ready data）支持的AI项目中有60%将被放弃。这两种失败都源于模型的上游环境。
- 该流水线分为六个阶段：捕获、分类、定义schema、提取、验证、交付。跳过验证这一步，就会把一个原本完美的产品演示变成一场生产事故。
- 置信度拦截机制（Confidence gating）决定了你的Agent是“仅供观赏”还是“值得信赖”。仅由人工审核少数不确定数据的团队，在处理速度最高提升五倍的同时，准确率达到了99.9%。
- 所有这些都不需要开发人员。n8n、Make和Zapier负责流程编排，而提取层则完成了核心的复杂解析任务。
AI Agent的结构化数据到底意味着什么
AI Agent的结构化数据是指将文档内容转换为具有可预测类型和已知单位的命名字段，因此Agent接收到的是invoice_number、due_date、total和line_items，而不是它必须自己去解析的PDF文件。Agent读取的是具体的数据值。它并不负责阅读文档本身。
在实践中，它就像这样精简：
{
"invoice_number": "INV-4821",
"supplier": "Northwind Supplies",
"due_date": "2026-08-14",
"currency": "USD",
"total": 1340.0,
"source_document": "https://files.example.com/inv-4821.pdf"
}
与抛给模型一份三页长的PDF外加一句“查找总金额”的提示词相比，你的工作流可以直接基于这简单的六行代码运行分支逻辑。每个字段都有一个名称、一个类型，以及一条追溯回源文档页面的明确路径。
这听起来或许只是个技术细节。但这正是“在产品演示中完美运行的Agent”与“在11月业务高峰期依然稳定工作的Agent”之间的分水岭。将同一张发票交给模型两次，它可能会返回两个略微不同的答案，这在聊天窗口中看起来可能挺有趣，但在凌晨3点无人值守运行的自动化循环中却是灾难性的。而当模型接收到一个经过验证的JSON对象时，它每次的表现都会完全一致，因为没有任何需要它再去做模糊解释的空间了。
这个问题之所以不断出现，是因为这些原始材料从一开始就不是为机器准备的。大约80%到90%的企业数据是非结构化数据：电子邮件、PDF、扫描件、附件、表格，所有这些都是为人类阅读而构建的。大多数团队也没有去弥补这一鸿沟。在一项关于发票处理的调查中，34%的企业仍在手动处理数据，而只有17%的企业实现了完全自动化的数据捕获。
原始材料是人类格式。Agent期望的是机器格式。而在组织架构中，几乎没有人专门负责这种转换。如果你想了解更多深入讨论，这种鸿沟正是Agentic AI中缺失的一层所探讨的主题，如果你想看更一般的适用情况，可以参考将非结构化数据转换为结构化数据。本文将专注于针对Agent的具体场景。
为什么AI Agent在处理文档时会失败
几乎每一次AI Agent在处理文档时产生的幻觉，都可以追溯到以下四个原因之一。四种原因，对应着四种不同的修复方法。
扫描件没有OCR层。 扫描件是一张带有文字的图片，而不是文字本身。如果给模型一张图片且没有文本层，它会读取它能清晰辨认的内容，并自信地捏造剩下的内容，而且永远不会告诉你哪一半是真实的，哪一半是编造的。
发送方之间的布局漂移。 40个供应商，40种发票设计，而你的流水线只是针对你在三月份测试的其中三种设计构建的。当第十二个供应商将总金额移到不同的单元格时，系统不会报错。提取过程只会默默地返回错误的单元格数据。
悄无声息的字段遗漏。 文档上没有采购订单（PO）编号，因此该字段返回为空，但Agent依然继续往下执行。表面上看起来没有任何问题。但两周后，它会在没有人喜欢处理的月底对账过程中彻底暴露出来。
没有置信度信号。 由于输出结果中没有任何地方标注“我对这个总金额只有60%的把握”，因此每个数据值都获得了同等的信任，哪怕是模型凭空编造出的值。
这种错误的代价不仅仅停留在理论层面。在受访者中，近七成的人报告称自己有时、经常或非常频繁地发现错误，这使得糟糕的文档数据变成了一种常态化的运行环境，而不是偶然事故。特别是在应付账款方面，支付错误率占供应商总支出的0.1%到0.4%之间。比例虽小，分母却很大：在这样的错误区间内运行2000万美元的供应商支出，意味着每年有2万到8万美元的资金流向了你根本未曾设想的地方。
Gartner从不同的角度得出了同样的结论：63%的组织要么没有适合AI的正确数据管理实践，要么不确定他们是否有。这其实是一种礼貌的说法，潜台词是大多数Agent项目都建立在一个无人检查的脆弱基础上。如果OCR这一环正是你的痛点所在，我们在为什么AI OCR会失败一文中有更深入的探讨。
为什么将PDF直接发送给模型行不通了
将原始文件发送给GPT、Claude或Gemini在初期是行得通的，直到它突然失效，而行得通与行不通的界限，在于是否有人在检查输出结果。
准确率数据解释了其中的原因。在干净的纯文本PDF上，字段提取的准确率在96%到98%之间。但在扫描文档上，同样的模型准确率下降到了大约90%到94%。这种差距本身并不是最致命的问题。问题在于，这两种情况下的响应结果看起来是一模一样的。没有标志，没有警告，没有任何暗示表明这份特定的文档属于“难以处理”的那一类。
在聊天窗口中，这是可以容忍的，因为当发票上明明写着$13.40而读取出的总金额却是$1,340时，人类会注意到这个错误。但在无人值守的自动化循环中，没有人会注意到这一点，错误的数字会直接进入接下来的任何业务流程。
这背后隐藏着一个设计理念，我们在为什么单模型文档处理已死一文中已经进行了长篇论述：一次单纯的模型调用并不等同于一条流水线。流水线是由多个阶段组成的，而各个阶段是可以被检查的。一次单次的裸调用，仅仅是你决定去盲目信任的一次抛硬币罢了。
从文档到Agent的六阶段流水线
为AI Agent解析文档绝不是一个单一的步骤，而是六个。我们所见过的每一个可靠的系统都运行了所有这些步骤，无论该团队是一开始在白板上就这样严谨设计，还是在经历了一个糟糕的月度教训后才不得不走到这一步。
1. 捕获文档并保留原始文件
关注文档实际到达的地方：共享收件箱、Drive或SharePoint文件夹、表单上传、SFTP传输目录、服务工单上的附件等。在进行任何操作之前，先将原始文件安全地存储在一个稳定的地方。
保留源文件不仅仅是为了保持整洁。这让你在六个月后能够确切回答“这个数字到底是从哪里来的”，而且这也是审计员查账时最先要求查看的东西。
2. 提取前先分类
在决定要提取哪些字段之前，先弄清楚文档是什么类型。发票、采购订单、合同、送货单、银行对账单、简历，或是未知类型。
这比看起来重要得多，因为发票和采购订单有着相同的字段名称，但业务含义却截然不同。如果把它们混合在一起处理，你得到的记录能够通过所有的代码验证检查，但在业务实质上却是完全错误的。这也是风险高度集中的地方：受访者指出发票 (21%)、采购订单 (18%) 和面向客户的文档 (17%) 是他们最容易出错的文档类型。
任何落入“未知类型”的文档，都应该交由人工处理，而不是让机器去瞎猜。
3. 为每种文档类型定义一个schema
schema是你的文档和Agent之间的契约。它命名每个字段，指定其类型，并明确标记出哪些字段是必填的。
按照字段的含义而不是它的位置来定义字段，因此无论total_amount出现在页面的哪个位置，它指的都是发票总金额。现代AI提取技术无需进行模板设置即可读取其从未见过的布局，这意味着一个schema就可以覆盖40家不同的供应商。请克制住为每个发件人构建单独schema的冲动，那将是一条没有尽头的维护不归路。
标记出下游系统必须依赖才能运行的字段。这些字段将成为你在第五阶段进行“硬性拦截”的标准。
4. 使用专用层进行提取，而不仅仅是调用一次模型
这就是准确率的来源。如果做得正确，AI Agent数据提取不只是一个简单的提示词，而是一项完整的服务，它们之间的差异直接体现在数字上：纯OCR系统的准确率只有85%到95%，且难以应对不一致的布局，而基于AI和机器学习的提取准确率则达到约99%，并且无需重建模板即可适应新的布局。
一个专用提取层能为你带来什么裸模型调用无法提供的东西：针对扫描件的高质量OCR、表格和明细项目提取、对照schema进行数据规范化和验证、回溯到源文件的页面引用、重试处理机制、可选的人工审核步骤，以及能够随时更改schema而不会破坏历史记录的版本控制功能。有些提取层还在此基础上添加了按字段评估的置信度评分，有这个功能固然很有用，但你不应仅仅围绕它来构建整个拦截机制。
2026年的大多数生产流水线不再是只选一种方法，而是结合使用多种方法：对于条件允许的文档，使用成本低廉的确定性提取；对于条件不允许的文档，则使用基于大模型的提取。有关此主题的更深层次探讨，请参阅代理型文档提取。
5. 在数据到达Agent之前进行验证和拦截把关
对照schema检查提取出的记录。确保必填字段存在、类型正确、总计金额匹配、日期可解析、数值在合理范围内。然后，应用你的置信度规则。
通过验证的记录可以直接发送给Agent。未通过的记录则交给人工处理。将第二条路径构建为一条“绕行路线”而不是“死胡同”，这样，一条经过审核的记录一旦获得人工批准，就能重新回到原有的工作流中，从而避免了一份棘手的文档阻塞其后面的整个处理队列。
这个单一的分支就是整个系统的安全机制，我们在下文专门辟出一节来讨论它，因为这往往是团队最常跳过，也是最常感到后悔的部分。
6. 将干净的记录交付给Agent
将验证后的对象推送到Agent获取工作任务的任何地方：自动化平台中的webhook、数据库中的一行数据、或CRM/ERP中的一条记录。Agent收到的是一个完成的结构化对象，它自始至终都不会看到文档本身。
数据究竟是如何到达Agent的
以下四种机制几乎涵盖了你将来可能构建的每一个AI Agent集成。它们之间并非真正的竞争关系。每种机制都回答了关于“时机”和“所有权”的不同问题。
| 机制 | 工作原理 | 适用场景 | 注意事项 |
|---|---|---|---|
| Webhook | 提取工具在记录准备就绪的瞬间将其推送出去 | 文档连续不断地到达，并且你希望Agent能迅速采取行动 | 你需要处理重试机制，并为投递失败的数据找个落脚点 |
| REST API pull | 你的工作流按计划时间表请求提取记录 | 批处理，或者当接收系统无法接受入站调用时 | 会增加延迟，且你需要自己编写和维护轮询逻辑 |
| Shared database | 记录存入一张数据表，Agent从中读取 | 多个Agent或系统需要相同的数据，且你需要保存历史记录 | 必须有人负责维护schema的变更和数据清理工作 |
| Tool call | Agent在运行时（通常通过MCP）请求文档数据 | Agent在执行任务期间自行决定它需要哪份文档 | 最难调试，而且这通常不是文档工作流真正需要的方式 |
表格的最后一行值得特别说明，因为模型上下文协议（MCP）近来备受关注。MCP是一种切实有效的方法，能将数据源作为可调用工具暴露给Agent。但它通常不太适合文档处理场景，因为文档是按照它们自己的节奏到达的，并且携带着你早已知道自己需要的字段。将结构化数据推送到工作流中的webhook不仅更容易构建、更容易调试，而且能完美完成同样的工作。
这也是隐藏在所有四行选项背后的真相：AI Agent并没有什么特殊的API。只需一个普通的API，交付Agent可以采取行动的字段即可。Parseur可通过前三种机制中的任意一种发送提取出的数据，完整的目标平台列表请参见导出和集成页面。
如何在无人监督时确保Agent不会基于错误的数字采取行动
你能确信这一点，是因为你提前设定好了Agent允许操作的范围，而在此范围之外的所有异常情况都会停下来等待人工处理。
这是最坦诚的回答。任何吹嘘的高准确率都不能让这个问题凭空消失，因为即使是极好的提取系统也有出错的时候，而且错误的分布是不均匀的。真正能消除这种焦虑的，是你精心设计的拦截关卡。
拦截关卡（gates）是一小组规则，在记录送达Agent之前进行强制检查：
- 任何字段的置信度低于你的阈值，路由至人工审查环节。这一条依赖于你的提取层提供按字段计算的置信度，而许多提取层并不具备此功能，这就是为什么此列表中的其余规则如此重要。
- 缺少必填字段，判定记录失败。绝不要将一个空字符串当作实际值向后传递。
- 数值超过审批限额，无论置信度多高都要求人工签字确认。一张完美提取出的80,000美元发票依然需要人工过目。
- 遇到新的供应商、发件人或文档类型，先人工审核前几份文档，直到建立起稳定的模式。
- 分类结果为“未知”，将其发送到人工分流处理，而不是去盲猜一个schema。
- 总金额与明细项目不符，判定其失败。算术校验是你所能拥有的最廉价的测谎仪。
关于阈值本身：并不存在一个放之四海而皆准的标准，任何向你报价统一数字的人肯定没仔细看过你的文档。请根据你自己的真实生产文件样本进行校准，将阈值设定在“即使漏网的错误也是你的下游系统能够承受的”水平上。一条直接进入付款流程的发票，和一份仅仅用于更新数据仪表板的送货单，显然不应设定相同的审核标准。
其回报是肉眼可见的。采用这种模式的团队，让AI处理有把握的绝大部分数据，而人类则专注于审查不确定的剩余部分，从而在处理速度最高提升五倍的同时，达到了99.9%的准确率。一家实现了理赔自动化的北欧保险公司完全自动处理了大约70%的文档，人工则集中处理那些复杂的案例。在应付账款领域，“优秀”与“一般”之间的差距也恰恰体现在这里：表现最好的企业仅有9%的异常处理率，而其他企业则高达22%。
请注意这些数字所描述的含义。它们并非在描述一个“从未遇到过棘手文档”的Agent，而是在描述一个“知道哪些文档十分棘手”的Agent。如果想要了解如何实际设计这一人工审核步骤，请参阅我们关于人在回路AI（Human-in-the-loop AI）、HITL最佳实践以及数据验证的指南。
无需编写代码即可构建AI Agent工作流
所有这些全都不需要开发人员，这往往会让那些一听到“流水线”就脑补出需要耗费工程师整整一个季度时间的人感到惊讶。
分工非常明确。提取层完成了艰难的部分：读取文档、应用schema、对字段进行规范化和验证。你的自动化平台则负责编排调度：在新文档到达时触发、调用提取器、接收结果、检查规则、路由异常情况，并将完成的结构化对象交给Agent。这种合理的劳动分工正是一个成功在生产环境中存活下来的AI Agent工作流应有的样子。
在n8n中，整个过程只需要四个节点：一个接收提取记录的webhook触发器，一个检查规则的IF条件节点，一个指向Agent的分支，以及一个指向人工的分支。上面提到的所有关于拦截把关的内容都装在那个IF节点里，而拦截率最高的往往是那些最简单的规则：比如缺失了一个必填字段，或者总计金额与明细项目对不上。
n8n适合那些需要复杂分支逻辑、错误处理机制和自托管的团队，目前大部分Agent的构建都在这里进行。Make是对可视化多步流程最友好的平台，你不需要接触任何类似代码的东西。如果流程大致上是线性的，Zapier甚至能让你在今天下午就直接上线。我们在n8n vs Zapier vs Make的对比文章中深入探讨了这几者的权衡。
它们自身都无法做好的事情，就是读取扫描版的PDF。它们内置的文件节点只能处理干净的、基于文本的文档，仅此而已。而这恰好是提取层所填补的空白，这就是为什么这两部分应该结合在一起使用，而不是相互竞争。
提取层、RAG，还是纯大语言模型：你需要哪一个？
人们经常争论这三者作为替代方案的优劣，然而它们解决的其实是完全不同的问题。
| 方法 | 擅长领域 | 适用场景 | 局限性所在 |
|---|---|---|---|
| 提取层 (Extraction layer) | 从同一类型的每个文档中提取相同的命名字段 | 你清楚你需要哪些字段，并且某个Agent或系统将基于这些字段采取行动 | 并非为解决关于文档含义的开放性问题而生 |
| RAG (检索增强生成) | 针对一段长文本回答开放性问题 | “我们的主协议关于终止是怎么规定的？” | 难以验证准确性，且检索质量决定了一切 |
| 纯LLM调用 (LLM call alone) | 原型设计、一次性任务，以及遇到真正不常见的特殊文档类型 | 你正在探索阶段，并且有一个人类在阅读所有的输出结果 | 没有置信度信号，没有审计跟踪，也没有拦截过滤的方法 |
最常见的错误就是在明明一个schema就能搞定的情况下，偏偏去选择了RAG。如果你能提前把所需的字段写下来，那么提取方式不仅速度更快、成本更低，而且要证明其正确性也要容易得多。把RAG留给那些你无法穷举的问题吧。
这也是**AI数据就绪（AI data readiness）**不再只是一张PPT幻灯片，而变成了一份真正核对清单的地方。大多数关于这一主题的文章，谈论的都是数据仓库表和治理策略。但对于文档工作流而言，它意味着四个具体的要求：带名称的字段、带类型的字段、每个值在向下游移动之前都已对照schema完成验证，以及一条可追溯回该数值出处页面的链接。想要了解更广泛的领域概念，请参考智能文档处理。
如何使用Parseur构建这一切
Parseur正是上述流水线中的专用提取层。它的诞生，是因为有两位工程师厌倦了看到人们去一遍遍地手动重新输入计算机早就能自己读取的内容。
设置过程分为四个步骤：
- 创建一个邮箱并让你的文档指向它。转发供应商的电子邮件、把文件拖放进去，或者连接到它们已经所在的文件夹。
- Parseur的AI会自动提取字段。 文本AI引擎负责处理电子邮件和文本文档，视觉AI引擎负责处理PDF、扫描件和图像。无需构建模板，就算有一天某家供应商重新设计了他们的发票，你也不需要去维护任何东西。
- 验证，并审查你选择需要审查的内容。 每个字段都会根据你的邮箱schema进行规范化和验证，因此日期、数字和选项都会以你的下游工具所期望的格式呈现。开启可选的人工审核步骤后，即可由人工在导出前检查记录。Parseur不会为字段的置信度评分，因此由你来决定哪些文档需要人工过目，而不是由一个黑盒阈值替你做决定。
- 导出结构化结果到你的Agent、自动化平台、数据库、CRM中，或直接接入一个API。
它可以读取PDF、电子邮件、扫描件、电子表格和附件，并且自2016年以来一直都在这么做。到目前为止已处理了超过1亿份文档，且未接受过任何一分钱的外部投资，而这正是你在打算长期运行的底层流水线中所需要的那种“枯燥的稳定性”。
在这一切接入你的ERP系统之前，通常会面临两个问题（往往在同一周内分别来自IT和财务部门）。数据去哪了：文档绝不用于训练模型，数据处理符合GDPR标准，其余详细信息请见安全性页面。费用如何：我们提供免费计划，因此唯一明智的评估方法，就是把你那最糟糕的五份文档丢进去跑一遍，然后看看返回的到底是什么字段。
值得费心去做这件事的理由是一道算术题。在美国公司，人工数据录入的成本大约为每位员工每年28,500美元。这才是你的Agent项目真正要在预算线上竞争的对象。而且，当有一天你的团队认定这条自动化流水线不再值得信任，从而开始手工核对每一条记录时，这笔成本又会在不知不觉中悄悄回归。
随着模型的优化，这一提取层会消失吗？
提取技术每年都在进步。但在文档与涉及资金的系统之间设立一道经过检验的边界的需求，却从未改变。
这里有一道永远无法绕开的算术题。在99%的字段准确率下，每百份文档中就有一份带有错误数值。如果每月处理一万份文档，那就是一百个错误数值，而且每一个错误看起来都和正确的一模一样。即使将准确率推高到99.5%，依然会有五十个。情况是好些了，但仍然不是零，而“绝对的零错误”正是“Agent可以完全无人值守运行”这个美好假设背后的隐形前提。
真正改变的其实是比例。需要人工介入的文档变少了，而那些确实需要人工处理的文档会被更加精准地标记出来，人工审查的积压任务从一个部门的工作量缩减为了某个人一个下午的工作量。这是一个巨大的进步，值得我们去争取。但这并不等同于提取层的消失。
到了2028年，那些能让Agent愉快稳定运行的团队，绝对不是那些碰巧找到了一个足够好以至于能跳过验证环节的模型的团队。而是那些尽早搭建起拦截关卡的团队：他们看着关卡成功拦截下各种错误，然后再根据表现，慢慢地、一点点地获得了拓宽关卡的底气与权利。
最后更新于
