1.2 万页只精读 2 页:文档 Agent 的 2 遍 OCR 法

LlamaIndex 创始人 Jerry Liu 把当下主流 agent harness（Claude Cowork、Codex 等）处理文档的一个默认动作总结成了一个词：just-in-time Agentic OCR（即时智能体 OCR）。说白了就一句话——别一上来就把整份文件丢给昂贵的视觉模型做 OCR，先免费粗读一遍，检索命中后再对那几页精细读。他用 84 份 SEC 财报（共 12,013 页）实跑了一遍：整套流程跑完，真正交给 VLM 精读的只有 2 页，第一遍粗读还几乎是免费的。

为什么这件事现在值得看？因为“数据室”类场景正在爆发——尽调、合同审阅、研报问答，用户随手丢上来 10 到 100 份文档就要 Agent 开口答。很多人直接整篇调 VLM-OCR，结果又慢又贵，还经常把表格读串行。两遍法不是新框架，而是把“先找后读”这个朴素逻辑变成了可落地的工程模式。

第一遍：免费粗读（skim）

Agent 对上传的每一份文件跑一次轻量、无模型参与的文本抽取。输出不完美，但足够支撑 grep 和语义检索。

# LiteParse 文本模式，纯 x/y 坐标还原，不调用任何模型lit parse report.pdf --no-ocr

LiteParse 是 Rust 写的免费开源解析器（Apache 2.0，12k+ stars），32 秒就把全部 84 份财报、12,013 页解析完，第一遍基本不花钱。--no-ocr 让它只取已有文本层并保留版面坐标，表格不会像 pdftotext 那样被按列拆散。

第二遍：检索 + 即时精读（zoom in）

粗读之后，Agent 在文本上检索，定位到相关文件和相关页，再只对这几页做 VLM 级精读。

# 检索命中：grep 直接定位到 3M 2022 年报第 25 页grep "Organic sales" 3m_2022_10k.md

# 只对命中页做 VLM 精读，而不是整篇 252 页lit parse 3m_2022_10k.pdf --pages 25# 或 LlamaParse 的 MCP 调用，按页号传入estimateFileComplexity(3m_2022_10k.pdf)  # 先判复杂度，再决定哪些页要 VLM

关键在“按页付费”：检索只命中 3M 年报第 24–25 页，Agent 就只精读这两页，延迟和成本同时砍掉。整轮下来 12,013 页里真正走 VLM 的只有 2 页，耗时几秒。

一个真实例子：被读散的表格

光说数字不够直观，看 3M 2022 年报第 25 页那张“各业务板块销售变化”表。pdftotext 默认模式把表格按列一股脑吐出来：先“Organic sales”，再五个板块名，再五个数字——你根本分不清哪个数对应哪一行。

Worldwide Sales Change By Business Segment Organic sales Acquisitions Divestitures Translation Total sales change Safety and Industrial 1.0 % – % – %(4.2) % (3.2) % Transportation and Electronics 1.2 – (0.5) (4.6) (3.9) Health Care 3.2 – (1.4) (3.8) (2.0) Consumer (0.9) – (0.4) (2.6) (3.9) Total Company 1.2 – (0.5) (3.9) (3.2)

LiteParse 因为保留了 x/y 坐标，能把行列对齐；而真正棘手的还是第 24 页那张 14 列、三行堆叠表头的表——任何纯文本表示都含糊。这时把这两页交给 LlamaParse agentic 模式，拿回带 rowspan/colspan 的规范 HTML 表格，答案才清楚：Consumer 板块有机销售下滑 0.9%。差距不在“能不能读”，而在“读出来能不能直接用”。

怎么判断哪些页“值得”精读

LiteParse 自带一个判官命令，直接打印每一页是否需要 OCR 及理由（扫描件 / 无文本层 / 文本稀疏 / 嵌入图片 / 乱码）：

lit is-complex report.pdf

在 84 份财报上它标出 12,013 页中的 2,605 页（21.7%）需要 OCR，其中绝大多数是“文本稀疏”（密集表格、文字覆盖率低），另有 253 页含嵌入图、75 页完全没有文本层。LlamaParse 也提供同款 estimateFileComplexity MCP 工具，把每页映射到对应解析档位。

成本账：差的不是一点

很多人默认用 frontier 模型当 OCR 引擎，但文档 OCR 从来不是各家实验室的优化重点。ParseBench（2,078 页人工校验企业文档、169k 条测试规则）上的对比很说明问题：

更致命的是“落地可信度”（visual grounding）：Opus 4.8 只有 18.7，非思考版的 Haiku 4.5、GPT-5 Mini 甚至低于 7，而 LlamaParse 是 84。没有 bounding box 和置信度，Agent 一旦读错一个单元格，错误就会一路传下去，还无从审计。

“大多数文档页根本不需要昂贵的 VLM——只在检索命中后，才精读那几页。”

适用边界：别用反了

两遍法只适合中等规模数据室：用户上传约 10–100 份文档、临时提问。Agent 还能用文件系统命令多跑几轮、把每篇都爬一遍兜底，检索偶尔漏了也能补救。

一旦规模到 1k–1M+ 文档的离线管道，规则反过来：检索只返回它看得到的，而文本质量决定了检索准不准，所以必须前置整篇 VLM-OCR，在索引之前就把每一页都读成高质量文本。两类场景同理的还有发票抽取、理赔受理、KYC 这类“每个字段都得对”的批处理——没有“之后再说”的余地，必须一次读对，还要 bounding box 和置信度供人审。

出箱实现的三个坑

主流 harness 默认用 pdftotext 当第一遍、Opus 5 当第二遍，实测有三个问题：其一，Opus 5 不是最佳 VLM，规模化太贵且缺落地可信度；其二，pypdf/pdftotext 作为第一遍不够全能；其三，Agent 为了重建 OCR 工具本该提供的能力，写了大量一次性代码。换成 LiteParse（第一遍）+ LlamaParse（第二遍，MCP 或 skill 接入任意 harness）能把准度和成本同时拉回来。

把 LlamaParse 接进任意 agent harness 只需一段 MCP 配置，之后让 Agent 自己决定按页号调用：

{  "mcpServers": {    "llamaparse": {      "command": "npx",      "args": ["-y", "@llamaindex/mcp-server-llamaparse"],      "env": { "LLAMAPARSE_API_KEY": "你的密钥" }    }  }}

接上之后，Agent 在 zoom-in 阶段不会再整篇重读，而是先 estimateFileComplexity 打分、再只把靶页送进去。后台还可以把整批文件提前跑一遍 VLM-OCR 并缓存，后面会话就不用对同一批文档重复烧钱。

一句话收束

两遍法不是银弹，它赌的是“检索能准确定位”。在 10–100 份文档的数据室里这个赌注稳，因为 Agent 还能用文件系统命令把每篇都爬一遍兜底；可一旦文档规模到了百万级，检索只返回它看得到的文本，文本质量直接决定检索准不准——那时就得反过来，在索引之前就把每一页都读成高质量文本。选哪种，看的是文档规模和“读错一次要不要紧”，而不是模型够不够新。

参考来源

• • AIHOT 条目：https://aihot.news/items/cmtym2c3q0003rob0w6kxvnn3
• • 原文：Jerry Liu, Just-in-Time Agentic OCR, LlamaIndex Blog — https://www.llamaindex.ai/blog/just-in-time-agentic-ocr

数据来源：AIHOT