DocClaw办公文档深潜2026.08.28

你有没有过这种体验：把同一份 PDF 丢进系统，先问"这页写了什么"，再问"第三页合同金额是多少"，最后又让它抽"发票号、付款条件、供应商"。结果系统像失忆一样——OCR 重跑一遍、DocQA 重跑一遍、KIE 又重跑一遍，页面被反复解析，表格被反复识别，低质量区域每次都重新裁剪。你看着 token 和延迟一起涨，心里只想问一句：它刚才不是已经读过这里了吗？

这正是智能文档处理（IDP）长期被割裂的痛点。今天深潜的对象 DocClaw，给出的答案不是"再训一个大模型"，而是把文档任务差异放到技能层、把可复用知识放到状态层、把感知动作交给工具层——让 OCR、文档问答、关键信息抽取共享同一个"智能体↔文档"的交互过程。

一、它是什么：把三类文档任务塞进同一个交互循环

DocClaw 由南洋理工大学（NTU）与阿里巴巴 Qwen Team 联合提出（arXiv:2608.18685，代码 Apache-2.0，仓库 sxiangag/DocClaw），是一个统一的 agentic 文档处理系统。它要解决的真实问题是：

现有方案把 OCR（文字识别）、DocQA（文档问答）、KIE（关键信息抽取）当成三个孤立的预测问题，分别用单遍模型或固定流水线处理。结果一是** fragmentation**（每条链路重复造轮子），二是** 知识无法跨查询复用**（每个 query 都像第一次见到这份文档）。

作者把现有路线分成三类，并点出各自天花板：

• 单 pass 模型：直接输出，快，但长文档、低质量区域容易漏证据；
• 任务专用 pipeline：有布局解析、裁剪、OCR 等工具，但流程写死，碰到不同 query 缺弹性；
• 通用 agent：能调工具，但缺跨任务可复用的"文档记忆"。

DocClaw 的核心主张是：这三类任务在底层共享同一个过程——感知文档内容 → 获取相关信息 → 逐步精炼中间结果。差异（该先看哪页、该抽哪个字段）交给"技能"去引导，共性（页面结构、区域坐标、OCR 结果）沉淀进一个结构化"文档状态"，让 agent 能积累、回访、渐进精炼。

一句话定位：DocClaw 不发明新 backbone，它发明的是一套让文档知识在多次交互中"长记性"的运行时抽象。

二、具体怎么用：一个工程师拿到手怎么跑起来

DocClaw 是带代码的真实项目（不是只给论文）。最小可运行路径如下：

1. 克隆与环境

git clone https://github.com/sxiangag/DocClawcd DocClawpython3 -m venv .venvsource .venv/bin/activatepip install -r requirements.txt

2. 配置模型后端

默认配置走 GPU 加速的 PaddleOCR / PaddleX 专用解析组件，并需要一个 VLM 作为"规划器（planner）"大脑。README 默认示例用 Gemini：

export GEMINI_API_KEY=...

docclaw.toml 是核心配置文件，可改 provider / model / tool backends / device。也就是说，理论上可以把 backbone 换成 Qwen-VL 等（论文作者来自 Qwen Team，工程上天然倾向自家 VLM）。

3. 跑一个文档（单文档模式）

python3 -m docclaw \  --config docclaw.toml \  --document /path/to/document.pdf \  --task "提取所有供应商名称和对应付款条件"

4. 交互式多轮会话（最能体现"长记性"）

python3 -m docclaw chat \  --config docclaw.toml \  --document /path/to/document.pdf

在 chat 模式下，你连续追问不同问题，文档状态会在底层保留——第二问不会再重新解析整份 PDF。

接入自身业务的最小路径：把第 3 步封装成一个函数调用（输入 document + task，输出结构化结果），前面挂你们自己的文档上传/权限校验，后面接你们的字段落库。真正要调的只有三处：① docclaw.toml 里的 VLM provider；② 任务提示词（即 --task 或 chat 输入）；③ 若需新文档类型，在 docclaw/skills/ 下补一个技能。

注意：README 里的 clone 命令曾写成 github.com/docclaw/docclaw.git 占位，实际仓库是 sxiangag/DocClaw，以 GitHub 实际地址为准。

三、适用边界：什么条件下成立，什么条件下失效

基于论文公开数字与机制，给出可验证的边界，而非臆测：

成立的条件

• 同一份文档需要多轮、异质查询（先问答、再抽取、最后校对）——状态复用收益最大；
• 文档含扫描件 / 低质量区域 / 跨页表格，需要"看不清就 zoom 再识别"的主动精炼；
• 对可追溯性有要求：每次工具调用都有 trace，便于审计。

失效与已知局限

• 任务覆盖窄：论文只验证了 OCR / DocQA / KIE 三类。表格转 Excel、文档分类、版式转结构等 IDP 类型未验证，别默认它能干；
• 强依赖 backbone VLM 与专用 OCR：规划器与识别都靠外部模型（Gemini-2.5-Pro / PaddleOCR-VL-1.6 / PP-DocLayout v3），它们的错误会沿链路传导；
• 中文 KIE 偏弱：KIE 在 OCRBench v2 上 EN 87.5、CN 仅 78.7，差距近 9 个点——中文票据/合同抽取要留人工复核余量；
• 成本与延迟随文档长度上升：每个 query 是多轮 VLM 调用（规划 + 多次工具）。DocQA 在 MMLongBench-Doc 仅 61.5，离人类水平仍有距离，不适合"零错"场景；
• 默认需 GPU：PaddleOCR / PaddleX 解析组件默认走 GPU，纯 CPU 环境需改后端；
• 它是研究框架，不是开箱即用的 SaaS：没有现成 Web 产品、没有权限体系、没有批量队列。

何时不该用 DocClaw

• 单页清晰 PDF 只想做纯 OCR → 直接上 PaddleOCR，便宜且快一个数量级；
• 文档是纯数字文本（无扫描）→ 轻量 pipeline 足够；
• 要求每字段 100% 准确、零容错（如报税直连）→ 必须加人工或额外校验门，别信 agent 自检。

四、实现原理（机制级）：黑盒是怎么被打开的

这是本期重点。DocClaw 真正的巧思不在某个神经网络，而是一套状态-技能-工具三元解耦的运行时。下面把机制拆到能复现的程度。

4.1 核心抽象：agent↔document 的交互

给定文档 D 和查询 q，目标是产出任务特定输出 y（OCR 的识别内容 / KIE 的字段对 / DocQA 的答案）。DocClaw 不把它做成单遍映射，而是建模为：agent 依据文档状态迭代调工具、更新状态、渐进精炼。

每次查询 q，agent 先从预定义技能集 𝒦 中选一个文档技能 k（由"对查询目标的理解"决定），初始化状态，进入 ReAct 风格循环。

4.2 结构化文档状态：两套分离的内存

状态记为 s_t = (m_t, e_t)——这是整个系统的命门：

• 文档内存 m_t（Document Memory）：跨查询持久、复用、精炼，分层组织：

  • 文档级：全局信息 + 所含页面索引；
  • 页面级：原始页面图像 + 处理中获得的 OCR 文本、布局结构、阅读顺序；
  • 区域级：空间坐标、区域类型、识别文本、工具附加属性（与对应页面关联）。
  • 不同工具（布局分析、识别等）围绕同一个共享文档实体逐步添/精炼知识；规划器通过压缩表示 φ(s_t) 访问，省略图像和全文以压低上下文开销。
• 任务内存 e_t（Task Memory）：只记当前查询上下文——所选技能、检索证据、已检查页面/区域、中间结果、交互历史。每步完全暴露给规划器；查询一结束就丢弃（e_0^{(j+1)}=∅），而 m 保留（m_0^{(j+1)}=m_{T_j}^{(j)}）。

设计直觉：m 是"这份文档我知道什么"，e 是"这次任务我做到哪了"。前者要长记性，后者要轻装上阵。这正是它比"通用 agent 缺记忆"高明的地方。

4.3 工具空间与技能

工具空间 𝒯 分三类（实现细节 §4.1）：

1. 解析 Parsing：文本/表格/公式/图表识别，主力 PaddleOCR-VL-1.6；
2. 搜索 Search：关键词 BM25、文本 ColBERT、图像 ColPali、基于 VLM 的视觉搜索；
3. 分析 Analysis：布局分析 PP-DocLayout v3、VLM 图像理解、视觉精炼（zoom / crop / rotate）、OCR 质量检查、证据抽取、答案生成、候选验证（均用与 planner 同骨干）。

文档技能 𝒦（把任务差异装进来）：

• OCR-oriented：先布局分析识别区域，路由到文本/公式/表格解析；低质量区域鼓励视觉增强（zoom/crop/rotate 后再识别）；
• DocQA-oriented（两个互补技能）：

  • Inspection：粗到细搜索，逐步缩小候选页、检查内容、提取证据；
  • Enumeration：保持广泛文档级覆盖，适合计数、分组等需全局推理的问题；
• KIE-oriented：先从图像直接抽字段 → 调 OCR 拿文本二次抽取 → 对不一致字段以原图为准解决冲突（视觉+OCR+图像验证三重保险）。

4.4 交互循环算法（伪代码）

输入: 文档 D, 查询序列 q^(1), q^(2), ...对每个查询 q^(j):  k^(j) = 选择文档技能(q^(j))            # agent 对查询目标的理解  s_0 = (m_0, e_0=∅)                     # 新文档 m_0 来自页面图像 {p_i}; 旧文档复用保留的 m  for t in 1..T_j:      a_t = (τ_t, c_t) = π_θ( q^(j), k^(j), φ(s_t) )   # 规划器读压缩状态决策      τ_t ∈ 𝒯,  c_t ∈ 𝒞(τ_t)             # τ_t=工具, c_t=参数      r_t = 𝓕_{τ_t}( D, c_t ; s_t )      # 执行工具      s_{t+1} = 𝒰(s_t, a_t, r_t)              = ( 𝒰_m(m_t, a_t, r_t),     # 文档知识 → 进 m                  𝒰_e(e_t, a_t, r_t) )    # 任务上下文 → 进 e      if 信息充足:          a_out = 终止动作          break  y^(j) = 𝓕_out( q^(j), k^(j), s_{T_j}^(j) )   # 生成最终输出  m_0^(j+1) = m_{T_j}^(j)                  # ★ 文档记忆保留给下一查询  e_0^(j+1) = ∅                            # ★ 任务记忆清空

数据流一句话：查询 → 技能引导 → 规划器看 φ(s_t) 决策工具 → 工具在 D 上执行 → 结果回写 m/e → 循环直至信息充足 → 输出；m 跨查询留存，e 每轮重置。

        ┌─────────────── DocClaw 运行时 ───────────────┐  q ──► │  技能选择 k           文档状态 s_t=(m_t,e_t)   │        │     │                      │   ▲              │        │     ▼                      ▼   │              │        │  π_θ(q,k,φ(s_t)) ──► a_t=(τ_t,c_t)          │        │                          │                  │        │                  工具执行 𝓕_{τ_t}(D; s_t)     │        │                          │  r_t             │        │                          ▼                  │        │                  状态更新 𝒰(s_t,a_t,r_t) ────┘        │                          │        │                  充足? ──否──► 继续循环        │                   │是        │                   ▼        │              y = 𝓕_out(q,k,s)   →  m 保留 / e 清空        └───────────────────────────────────────────────┘   工具空间: [Parsing: PaddleOCR-VL] [Search: BM25/ColBERT/ColPali/VLM]             [Analysis: PP-DocLayout v3 / zoom·crop·rotate / 证据抽取 / 验证]

4.5 工程实现要点与 trade-off

• 状态复用是延迟的主杠杆：消融显示，加文档状态后平均延迟从 95.81s 降到 60.70s（核心来自"已解析区域不再重算"）；加技能后质量分从 92.85 升到 97.10。质量靠技能拉、延迟靠状态压，二者正交。
• 视觉精炼的取舍：OCR 精炼共触发 433 页，其中 zoom 354 页（贡献主要增益 0.23），crop 77、rotate 41。说明绝大多数收益来自"对低质量区域定向 zoom"，而不是无脑全量增强——这是成本可控的关键。
• KIE 验证的性价比：先用图抽、再 OCR 抽、最后以原图验证冲突。验证阶段把 EN 错误纠正 35.3%、CN 纠正 47.7%——中文错误近半能被"回头看原图"救回，这也是 CN 能从 54.3 拉到 78.7 的原因。
• 状态压缩 φ 的双刃剑：规划器看不到原始图像和全文，上下文省了，但细粒度信息可能丢；论文未给出 φ 压缩导致的漏检定量，这是潜在盲区。
• backbone 是瓶颈也是单点故障：所有规划与 verification 都依赖同一个 VLM，它的幻觉/偏见会被放大；换模型要同时改 docclaw.toml 的 provider 与工具后端的推理封装。

4.6 性能数字（论文公开）

数字读起来很漂亮，但请结合第三节边界一起看：DocQA 61.5 离"可用替代人"还远，CN KIE 78.7 必须配人工复核。

总结与延伸

DocClaw 给办公文档场景的 agent 设计上了一课：别急着堆更大的模型，先把"知识该存在哪、任务上下文该扔在哪"想清楚。它用"文档内存跨查询留存、任务内存每轮清空"这个看似简单的分离，解决了 IDP 长期重复的算力浪费；用"技能层装差异、状态层装共性、工具层装感知"的三元解耦，让一个 agent 同时吃下 OCR/DocQA/KIE。

但要清醒：它仍是研究框架——任务覆盖窄、强依赖外部 VLM、中文抽取偏弱、无产品化外壳。把它当可复用的文档 agent 运行时原语来借鉴，比直接当生产系统更划算。

延伸阅读 / 源码

• 论文：arXiv:2608.18685 — https://arxiv.org/abs/2608.18685^[1]
• 代码：GitHub sxiangag/DocClaw（Apache-2.0）
• 同类对照：TabClaw（表格推理 self-evolving agent，arXiv:2606.10316）、GUIDE（企业文档到工件的受控多智能体，arXiv:2608.12133）、RAGFlow（深度文档理解 RAG 引擎）

引用链接