因为原内容是一篇典型的“指南类”文档，开发者在用 AI Agent（如 LangGraph 或 CrewAI）构建自动化文档解析工作流时，最容易在“实体识别”和“状态机转换”上翻车。

以下是改写后的技术帖：

*

分享一个用 AI Agent 做文档自动化解析时的离谱踩坑经历

很多人吹 AI Agent 能自动处理所有结构化文档，但实测下来，只要文档里涉及“状态迁移”（比如某个账户从 A 状态变成 B 状态），大模型极其容易在逻辑链条上产生幻觉。

我前阵子在写一个自动化解析财务类文档并同步到数据库的 Agent 工作流，逻辑很简单：识别文档中的实体 → 提取状态 → 更新数据库。结果在处理一个关于“账户状态变更”的 PDF 文本时，Agent 直接把“原债权人”和“第三方收购方”搞混了，导致数据库里出现了大量重复且错误的记录。

具体的坑点在哪里？

问题的核心在于 LLM 对“时间线”和“所有权转移”的理解极其不稳定。文档中提到一个账户在 180 天后会从 Internal Collections 变成 Charge-Off，然后被卖给第三方。

我的 Agent 在执行提取任务时，识别到了两个实体（原公司 A 和收购公司 B），但它没有意识到这是一个替代关系，而是把它当成了并行关系。

报错现象：
在运行验证脚本时，我发现数据库出现了如下异常数据：

{
  "account_id": "ACC_12345",
  "status": "Active",
  "owner": "Company_A",
  "collection_status": "Charged-off"
},
{
  "account_id": "ACC_12345",
  "status": "Collection",
  "owner": "Company_B",
  "collection_status": "Active"
}

同一个 ID 出现了两条互斥的记录，Agent 在第二次解析时没有触发 UPDATE 而是直接执行了 INSERT。

我是怎么排查并解决的？

我起初以为是 Prompt 没写好，试了三种不同的提示词工程方案，但只要文档描述稍微复杂一点，Agent 还是会翻车。后来我意识到，不能指望 LLM 在一个 Step 里完成“理解 → 判定 → 操作”，必须引入状态校验环。

1. 强制引入 Schema 校验

我放弃了让 Agent 直接输出 JSON，改为先让它输出一个中间状态的 XML 结构，并强制要求它标注出实体的“生命周期”。

<entity_transition>
    <original_owner>Company_A</original_owner>
    <current_owner>Company_B</current_owner>
    <transition_event>Debt Sale</transition_event>
    <timestamp>Day 180+</timestamp>
</entity_transition>

2. 增加一个“冲突检测”节点 (Conflict Resolver)

我在 LangGraph 的工作流中增加了一个节点，专门用来对比当前提取的实体与数据库已存在实体的关系。如果发现同一个 ID 出现了不同的 Owner，强制 Agent 重新阅读原文并回答：“这两个实体是同一个债务的不同阶段，还是两个独立的债务？”

3. 实测数据对比

优化前后的准确率差异非常明显：

• 优化前： 100 篇复杂文档，实体识别错误率约 22%，状态重复记录 15 篇。
• 优化后： 引入状态校验环后，实体识别错误率降至 4%，重复记录基本清零，单篇文档的处理延迟从 3.2 秒增加到了 4.8 秒（增加了校验步骤），但数据一致性终于保住了。

总结的一点思考

别太迷信 AI Agent 的“自主推理”能力。在处理具有严格逻辑先后顺序的文档时，最好的做法是将 LLM 当作一个不稳定的提取器，而在其外部构建一个确定性的状态机。

如果你在做类似的工作流，建议在写入数据库之前，一定要加一层基于规则的 Validation Layer，否则你的数据库迟早会被 AI 搞成垃圾场。