![氛围图](https://developer.qcloudimg.com/http-save/8729876/ee1c6b933f5bbd72bbabbcd993042afa.jpg)

> 💡 **一句话总结**：DocClaw 的贡献不是发明新 backbone，而是把文档任务差异放到技能层、把可复用知识放到状态层、把感知动作放到工具层；技能提升质量，状态降低重复计算。

## 导语：同一份 PDF，为什么要被系统反复肢解？

想象一个很常见的文档智能工作台：用户先问“这页写了什么”，接着问“第三页的合同金额是多少”，然后又要求抽发票号、付款条件和供应商字段。

很多系统会把这三件事当成三个任务：OCR 跑一遍，DocQA 再跑一遍，KIE 又跑一遍。页面被重复解析，表格被重复识别，低质量区域每次都要重新裁剪。你看着 token 和延迟一起涨，心里只想问：它刚才不是已经读过这里了吗？

这正是 DocClaw 要处理的问题。论文提出一个统一的 agentic intelligent document processing 框架，让 OCR、文档问答（DocQA）和关键信息抽取（KIE）共享同一个 agent 与文档的交互过程。

> **想自己动手试？**
> - 📄 论文：[arXiv 2608.18685](https://arxiv.org/abs/2608.18685)
> - 💻 代码：[GitHub · sxiangag/DocClaw](https://github.com/sxiangag/DocClaw)

## 这篇论文到底想解决什么问题？

论文的研究问题是：能否用一个共享的 agent 交互框架同时支撑 OCR、DocQA 和 KIE，而不是为每个文档任务单独设计模型或固定流水线？

作者把现有方案分成三类。单 pass 模型直接输出，速度快，但在长文档和低质量区域容易漏证据；任务专用 pipeline 有版面解析、裁剪、OCR 等工具，但流程固定，遇到不同 query 缺少弹性；通用 agent 能调工具，却常常缺少跨任务可复用的文档记忆。


*图说：DocClaw 试图同时避开单 pass 模型的静态感知、固定 pipeline 的僵硬流程和通用 agent 的记忆缺失。*

真实业务里，同一份材料往往会被连续使用。扫描件的页面结构、区域坐标、表格 HTML、局部裁剪和 OCR 结果，本质上都是可以沉淀的中间知识。如果没有 document state，每个 query 都像第一次见到这份文档。

所以论文的核心抽象是 agent-document interaction：任务目标不同，但底层都需要识别证据、获取相关信息、逐步精炼输出。差别交给技能层处理，共性放进共享状态和工具循环。

## 它的思路是什么？

DocClaw 的整体流程可以概括为“选技能、建状态、进循环、写状态、出结果”。它采用 ReAct 式工具调用：模型根据当前观察决定下一步动作，工具返回新的 observation，状态随之更新。


*图说：query 先映射到任务技能，再进入共享工具循环；中间观察写入 task memory，可复用知识沉淀到 document memory。*

这里有三个关键设计。

- 🧭 **Task-oriented document skills**：系统先判断任务是 OCR、DocQA 还是 KIE，再选择对应技能说明。技能规定优先查看的内容、可用工具、验证策略、输出 schema 和停止条件，避免 agent 在长文档里漫无目的游荡。
- 🧠 **Structured document state**：状态分为 document memory 与 task memory。前者保存页面、区域、OCR、表格、图像等跨 query 可复用内容；后者保存当前查询的中间证据。后续步骤读取状态，而不是重复解析同一区域。
- 🛠️ **Shared tool loop**：agent 检查证据是否足够；若不足，就从缩放、裁剪、旋转、OCR、检索、图像 grounded verification 等工具中选择一个。工具结果写回状态，直到满足停止条件。

为什么要把技能和状态分开？因为它们解决的是不同问题。技能回答“这个任务该怎么找证据”，状态回答“之前已经知道了什么”。一个提供任务先验，一个提供复用价值。

KIE 部分还加入了视觉验证。候选字段值会映射回页面区域，检查视觉证据与文本是否一致。这个设计很务实：字段抽取最怕幻觉和错位，仅靠生成概率无法保证值真的来自页面。

自问自答一下：为什么不直接上更大的 VLM？因为很多失败不是语义推理不足，而是输入表示不好。小字需要放大，表格需要局部结构，旋转页需要纠正；这些是感知动作，不是再多想一遍就能解决的问题。

## 效果到底怎么样？

论文在三类 benchmark 上验证同一个框架。最强配置在 OmniDocBench v1.6 达到 Overall 96.45，在 MMLongBench-Doc 达到 61.5，KIE 聚合分 86.9。

| 任务与基准 | 最强配置 | 结果 | 对比 |
|---|---|---:|---|
| OCR，OmniDocBench v1.6 | Gemini-2.5-Pro | 96.45 | PaddleOCR-VL-1.6 为 96.34 |
| DocQA，MMLongBench-Doc | Gemini-2.5-Pro | 61.5 | 高于 baseline 3.4 分 |
| KIE 聚合 | Gemini-2.5-Pro | 86.9 | 比 Qianfan-OCR 高 2.9 分 |

这些数字要分开读。OmniDocBench 上 0.11 分的领先很小，不能单独证明“统一系统优于专用 OCR”。更有说服力的是 MMLongBench-Doc 的 3.4 分提升，因为长文档正好是证据定位和状态复用的主场。

消融比总榜更有信息量。state-enabled 版本加入 document skills 后，Overall 从 92.85 提升到 97.10；skill-enabled 版本加入 document state 后，平均延迟从 95.81 秒降到 60.70 秒。质量收益和效率收益来自不同组件，这是论文最清楚的一条证据链。

KIE 的中文子集变化很醒目：vanilla VLM 为 54.3，加 OCR 后到 77.5，再加验证到 78.7。英文子集也从 83.3 提升到 87.5。显式 OCR 和区域验证确实能弥补直接视觉抽取的弱点。

不过，我对“96.45”这类总分仍保持克制。三个 benchmark 的指标含义不同，不能相加成“文档智能通用能力”。它验证的是一个共同框架在三类任务上可行，而不是给出了单一能力分数。

## 为什么你要关心？

如果你正在做文档 Agent、RAG 前处理或企业内容工作台，DocClaw 有几个可以直接借鉴的做法。

- 🗂️ **把 document memory 当一等公民**：页面、区域、OCR、表格结构和已验证证据都应带 provenance 存下来。连续 query 场景里，缓存命中率和状态复用直接决定成本。
- 🧩 **用 query-to-skill 路由约束探索**：通用 agent loop 容易“看遍全文档却不知道该看哪里”。技能层可以把任务先验写成工具偏好、验证方式和停止条件。
- 🔍 **对 KIE 做区域级验证**：字段值必须能映射回视觉或文本证据。尤其是金额、日期、证号和合同条款，幻觉代价比多一次工具调用高得多。

我的工程判断是，这篇论文最有迁移价值的不是 benchmark 数字，而是分层方式：任务差异放技能，文档知识放状态，感知动作放工具。这个边界清楚，也方便逐步移植到现有系统。

落地时建议先测连续 query 分布。如果你的系统每份文档只问一次，state 的收益可能有限；如果是工作台式多轮使用，它可能会显著改变延迟和费用。

## 理性看待

论文的主要限制在成本公平性。DocClaw 依赖多个强 VLM/LLM backbone 和丰富工具空间；收益可能部分来自更多推理时计算、强闭源模型和针对 benchmark 的工具配置，而不完全来自统一 agent 表述。论文报告了延迟，但缺少 token 费用、工具调用分布、失败恢复成本和缓存命中率的完整账本。

复现也有现实门槛。部分最佳结果依赖闭源 backbone，技能提示和配置需要检查仓库；不同部署环境的工具质量可能改变结论。

所以我的建议是把它当作架构参考，而不是直接照抄生产配置。先在固定 token 和工具预算下复现关键消融，再评估状态膨胀、错误传播和缓存策略。这样才不会把“看起来更聪明”误判成“更划算”。

> 作者：lusca
> 版本：lusca-paper-blog v1.5.0
> 出处：https://github.com/yjmm10/lusca-skill/tree/main/skills/lusca-paper-blog



💡 一句话总结：DocClaw 的贡献不是发明新 backbone，而是把文档任务差异放到技能层、把可复用知识放到状态层、把感知动作放到工具层；技能提升质量，状态降低重复计算。

DocClaw：让文档 Agent 记住自己刚刚读过哪里

人工智能

开发工具

算法

DocClaw提出统一agent框架，通过任务技能、文档状态和共享工具循环同时支撑OCR、DocQA和KIE，显著降低重复计算并提升准确率，在长文档基准上领先3.4分，适合多轮连续文档处理场景。

2026上云采购 | AI焕新·智启新局

documentocr

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

DocClaw：让文档 Agent 记住自己刚刚读过哪里-腾讯云开发者社区-腾讯云

DocClaw：让文档 Agent 记住自己刚刚读过哪里

DocClaw：让文档 Agent 记住自己刚刚读过哪里

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐