从 OCR 到 Agentic Document AI

为什么“理解文档”，正在成为下一代企业 AI 的分水岭？

文档，一直是企业数字化中最被低估、却最核心的“非结构化资产”。

合同、发票、标书、工单、制度、报告、邮件、扫描件、PDF…… 在几乎所有企业系统中，真正承载业务含义的，并不是数据库字段，而是文档本身。

过去 20 年，企业对文档的处理路径高度一致：

OCR → 规则抽取 → 人工校验 → 入库

而今天，这条路径正在被彻底重写。

一、传统 Document AI 的三大“天花板”

在进入 Agentic Document AI 之前，我们必须先承认一个事实：

绝大多数“文档识别系统”，并不理解文档。

1️⃣ OCR ≠ 理解

OCR 解决的是“看清字”，不是“理解意思”。

即便识别率达到 99%，系统依然不知道：

• 这是一份合同，还是报价单？
• “交付日期”指的是哪个条款？
• 哪一页才是最终版本？

2️⃣ 模板与规则不可扩展

传统 Document AI 的核心是：

• 固定模板
• 正则规则
• 字段位置假设

一旦遇到：

• 多版本合同
• 扫描质量差
• 表格结构变化
• 跨页语义

系统就会指数级崩溃。

3️⃣ 系统“只提取，不思考”

传统方案本质上是一个 ETL：

文档 → 字符 → 字段 → 表

它无法回答任何业务级问题：

• 这份合同是否存在风险？
• 是否违反公司制度？
• 与历史合同相比是否异常？

二、LandingAI ADE：不是“更强 OCR”，而是范式迁移

Andrew Ng 在 LandingAI ADE 中提出的，并不是一个“更准的识别模型”，而是一个全新的文档理解范式。

我们可以把 ADE 的核心理念总结为一句话：

文档不再是“输入数据”，而是 Agent 的工作对象。

ADE 背后的三个关键转变

转变一：从「字段提取」到「任务驱动理解」

传统系统问的是：

“我该从这份文档里提取哪些字段？”

Agentic Document AI 问的是：

“我现在要完成什么任务？这份文档对任务意味着什么？”

举例：

• 任务是 合同风险审查
• 任务是 费用合规判断
• 任务是 工单归类与路由

文档只是 Agent 推理过程中的一个上下文证据源。

转变二：从「一次性推理」到「多轮思考」

ADE 的核心不在 OCR，而在 Agent Loop：

1. 读取文档
2. 形成初步假设
3. 定位关键段落
4. 验证假设
5. 若不确定 → 回到文档重新查证

这与人类阅读高度一致。

不是“抽字段”，而是“反复阅读、确认、推理”。

转变三：从「规则系统」到「可解释推理」

ADE 强调：

• 每一步推理可追溯
• 每个结论有证据
• Agent 的“为什么”可被审计

这对企业系统极其关键。

三、Agentic Document AI 的标准架构拆解

如果你要在自己的工程体系中理解或复刻 ADE，本质上要掌握下面这套 Agentic Document Pipeline。

1️⃣ 文档感知层（Document Perception）

这一层并不只是 OCR，而是：

• OCR（文本）
• Layout Parsing（版式）
• Table Detection（表格）
• 图像区域理解
• 页级 / 段级结构建模

目标是构建：

“可被 Agent 操作的文档结构表示”

2️⃣ 语义分块与知识单元化

这是很多 RAG 系统失败的地方。

错误做法：

• 固定长度 chunk
• 无视语义边界

Agentic 系统应当：

• 按 语义单元 分块
• 保留层级结构（章节 / 条款 / 附录）
• 标注来源页码、上下文关系

这一步决定了后续 RAG 的“智商上限”。

3️⃣ Agent 推理与工具调用层

核心能力包括：

• 文档内搜索（非向量）
• 跨文档对比
• 多轮自问自答
• 不确定性检测
• 决策分支

Agent 不只是调用 LLM，而是：

在文档空间中“行动”

4️⃣ RAG 深度融合（不是外挂）

在 ADE 思路中，RAG 不是：

“我先查，再让模型回答”

而是：

RAG 是 Agent 推理过程中的一个工具

Agent 可以：

• 多次检索
• 动态调整 query
• 验证多个证据源
• 放弃不可靠结果

5️⃣ 输出层：结构化 + 可解释

最终输出必须满足：

• 可落库
• 可追溯
• 可复核
• 可审计

否则无法进入核心业务系统。

四、ADE 之外：同类 Agentic Document AI 产品全景

LandingAI 并不是孤例。全球范围内，Document AI 正在集体走向 Agent 化。

下面从“理念相近度”维度进行梳理。

1️⃣ Google Document AI + Gemini

特点：

• 强大的版式与表格理解
• 与 Gemini 深度集成
• 偏“平台能力”

局限：

• Agent 行为可控性较弱
• 企业定制成本高

2️⃣ Azure Form Recognizer → Copilot Stack

特点：

• 强调与业务系统集成
• 强合规、强审计

局限：

• Agent 能力偏弱
• 推理链可解释性有限

3️⃣ Amazon Textract + Bedrock Agents

特点：

• 可组合性强
• 适合工程化落地

局限：

• 架构复杂
• 需要较强云原生能力

4️⃣ Rossum / Hyperscience

特点：

• 财务与票据领域极强
• 强人机协同

局限：

• 场景相对垂直
• Agent 通用性有限

5️⃣ 自建：LLM + LayoutLM + RAG + Agent

这是越来越多大厂正在走的路。

优势：

• 可控
• 可深度定制
• 可沉淀为平台能力

代价：

• 架构复杂
• 需要长期演进能力

五、给工程与架构负责人的关键建议

如果你真正想“学习 ADE 的产品理念”，而不是“用 ADE 这个工具”，我给你 5 条落地级建议。

建议一：别从 OCR 开始，从“任务”开始

先问清楚：

• 文档要支撑什么决策？
• 谁对结果负责？
• 错一次的成本是多少？

建议二：把文档当成“Agent 环境”

不是数据源，而是：

• 可探索
• 可回溯
• 可质疑

建议三：RAG 是基础设施，不是亮点

真正的护城河在：

• Chunk 设计
• 检索策略
• 失败路径处理

建议四：必须有人类兜底机制

Agentic Document AI 的本质是：

人机协同，而不是全自动。

建议五：把“解释性”当一等公民

否则它永远进不了核心系统。

六、结语：谁先“理解文档”，谁就理解业务

我们正在经历的，并不是一次 OCR 升级，而是一次企业认知系统的升级。

当 Agent 能够阅读、理解、质疑文档， 它才真正开始理解企业。

LandingAI ADE 的价值，不在于一个产品，而在于它清晰地告诉我们：

Document AI 的终点，不是字段，而是推理。