为什么“理解文档”，正在成为下一代企业 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：
-
读取文档 -
形成初步假设 -
定位关键段落 -
验证假设 -
若不确定 → 回到文档重新查证
这与人类阅读高度一致。
不是“抽字段”，而是“反复阅读、确认、推理”。
转变三：从「规则系统」到「可解释推理」
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 的终点，不是字段，而是推理。
