Agentic Data Cracking：Agent 推理时"顺手"沉淀的结构，让后续查询便宜 53%

你有没有算过一笔账：让一个 Agent 回答一个需要翻 7 个 Wikipedia 页面的多跳问题，到底要烧多少钱？

哈佛 Idreos 组的这篇新论文给出了一个让人有点肉疼的数字——在 FanOutQA 上，单个问题最多消耗近 100 万 token，用 Haiku 这种便宜模型跑，一题也要接近 1 美元。而真正让团队坐不住的是另一个实验：如果把回答问题需要的每个事实提前人工抽出来存进数据库，同样的问题在库上推理，成本直接便宜 28 倍。

28 倍。这就是"开文档推理"和"查表"之间的成本鸿沟。这篇论文做的事，说穿了一句话：既然 Agent 为了回答当前问题已经把文档读进上下文了，那就让一个分身顺着这份已经付过钱的上下文，把可能对未来有用的结构顺手抽出来存着。下次相关问题再来，直接查库，不开文档。

核心摘要

论文提出了 Agentic Data Cracking——把数据库领域 2007 年就提出的 cracking（自适应索引）思想搬到 Agent 数据基础设施上。当主推理 Agent 因为结构化存储未命中而被迫打开原始文档时，一个 cracking 子 Agent 从已加载的上下文零边际成本分叉，投机性地抽取"附近"可能有用的实体、属性和关系，沉淀为带证据的共享 cracked-object store。在 FanOutQA 扩展基准上，这套方案把成本砍掉 53%，准确率几乎不动（LLM 评审 43% vs 42%，无统计显著差异）；在更难的电影调查案例研究上成本降 3 倍。我认为这是 Agent 基础设施方向一篇定位很准的"思想迁移"型工作——底层突破谈不上，但它指出的那个 28 倍成本空间是真实存在的，而且解法朴素得有点优雅。

论文信息 - 标题：Token-Efficient Data Reasoning Agents via Adaptive Structuring of Unstructured Data - 作者：Milad Rezaei Hajidehi, Qitong Wang, Stratos Idreos（哈佛大学） - 链接：https://arxiv.org/abs/2608.31082 （2026 年 8 月 31 日提交，7 页短文，3 张图）

🎯 问题动机：Agentic 推理是个"预填密集型"的赔钱买卖

先把成本结构看清楚。Data reasoning 这类任务——证据散落在网页、合同、财报、电话会记录里，需要多步推理把它们串起来——是个典型的 prefill-intensive 负载：Agent 反复把大文档塞进上下文恢复零散事实，而最后吐出来的答案往往就一句话。输入几十万 token，输出几百 token。钱全花在"读"上了。

你可能会说，那用 RAG 啊，检索 top-k 文档喂给模型不就完了？问题是固定 top-k 的 RAG 准确率真的不行。看论文 Figure 1 左边那张图，一目了然：

图 1：左图是 FanOutQA 上的准确率-成本散点。RAG top-5 和 top-10 便宜但准确率被 Agentic Reasoning（黑方块，约 75%）甩开一大截；ADC（绿星）几乎保住了 Agentic 的准确率，成本却降了 53%。右图是更扎心的对照：10 个采样问题，人工把所需事实全部抽进数据库后，Agent 在这个"理想预结构化存储"上推理便宜 28 倍——这个差距就是自适应结构化系统能吃下的空间。

右图那 28 倍是这篇论文真正的立论根基。作者的算法很直接：每个问题退化成"数据发现 + 一条短查询"（类似 Text2SQL），全程零文档打开。当然这个倍数是 FanOutQA 特有的——它的问题平均跨 7 个文档。真实企业场景里 fan-out 到几百个文档的问题，节省会是数量级的。

那为什么不能干脆把所有文档提前全量结构化？作者的反驳也挺有说服力：文档里潜在的实体、属性、关系比任何工作负载实际需要的多出几个数量级，全量抽取是一次"无界的 decode"；而且查询没来之前，你根本不知道哪些结构值得抽、复用频率有多高。论文里有句话我印象很深：Only the workload reveals which structure is worth extracting——只有工作负载自己知道哪些结构值钱。

说到这个，做数据库的人对这套逻辑太熟悉了。这不就是 Stratos Idreos 自己 2007 年在 CIDR 上提出的 database cracking 吗——不为查询建全量索引，而是每来一个查询就顺手把数据按查询谓词物理重组一点，索引在查询过程中"长"出来。区别在于，传统 cracking 重组的是已有结构，而这篇论文要在原本无结构的地方创造结构。作者把工作从数据库迁移到 Agent，坦白讲，这个迁移的角度选得很妙。

🏗️ 方法：从已加载上下文"零成本分叉"出的投机分身

整个方法的核心机制可以用一句话概括：系统从不专门为抽结构而打开文档；只有当主 Agent 因为结构化读取未命中、被迫打开原始文档时，cracking 子 Agent 才从这份已经加载进上下文的文档分叉出一个并行分支。

图 2：(a) 写入行为。注意上面的 token 布局——system、task、reasoning、document 这些段构成已缓存的共享前缀，cracking 分支（<cracking> 段）在这个共享前缀上做有界 decode，把投机抽取的对象写进 Cracked Object Storage。文档 prefill 只付一次钱，分叉几乎是免费的。(b) 读取行为。推理 Agent 先请求文档 d 的目录 Cat(d)，命中就直接结构化读取，缺东西才回退打开原始文档。

Context forking：为什么分叉近乎免费

这里的工程巧思在于利用了 KV cache 的前缀共享。文档被主 Agent 打开后，它的 prefill 已经算过、KV cache 条目已经存在：

• 本地推理（SGLang、PagedAttention 这类框架）：分叉分支直接复用文档的 KV cache 前缀，省掉第二次 prefill；
• API 模型：共享前缀命中 prompt caching，按缓存读取的低费率计费。

而且 cracking 分支跑在答案路径之外，并行执行，不拖慢当前查询的延迟。唯一的额外开销是一个有界的 decode——每题 4K token 的 cracking 预算。这个"顺手"两个字，是有底层系统机制撑着的，不是修辞。

投机抽取：用语义局部性替代地址局部性

子 Agent 抽什么？它能看到当前和此前对该文档的所有查询，然后做语义推理：不限于当前问题要的字段，而是推测"附近"哪些实体、属性、关系可能服务未来的相关查询。论文给的例子很直观——打开 NBA 球员页面查生涯得分时，顺手把生涯篮板也抽了；过几天有人问"IBM Award 获奖者的篮板数据"，直接命中。

作者自己给的类比挺准：这像 cache miss 之后的 prefetching，只不过预取依据的不是固定地址局部性，而是 Agent 发现的语义局部性。

约束也很明确：只抽有证据支撑（grounded）的事实，输出 schema 受限的 JSON；list 型关系要么完整抽出要么放弃。每次调用必须 crack 整个逻辑文档，避免"半个文档被结构化"带来的歧义。

数据模型：带证据和基数的扩展 RDF 边

抽出来的结构长这样——每条 cracked object 是一个六元组：

几个设计细节值得说：

• 主语-关系-宾语是开放域的，没有预定义 schema，由子 Agent 现场填充；
• 证据 \(\varepsilon = \langle d, \rho \rangle\)：每条边都标注来源文档和文档内的支撑区域——这是 grounded 的关键，出了问题能回溯；
• 基数 \(\kappa \in \{\text{singular}, \text{list}\}\)：单值关系一条边就完整；list 必须抽全所有成员才可用，成员存成独立边、可以独立索引和 join；
• 单位 \(u\)：系统统一规范化数字、单位、日期。

读取路径：目录先行，保守回退

读这一侧的设计我更欣赏。Agent 多了一个受限的结构化读取工具（按 subject、relation 或 subject-relation 对查询），关键是那个 Catalogue——cracked-object store 上的逻辑视图：

目录随文档搜索结果一起、在 Agent 决定是否打开文档之前呈现。看到需要的结构已经在库里，就发起结构化读取拿到带证据的紧凑值；不在，就老老实实打开原文档。这个 fallback 是保守兜底策略，也是准确率能保住的根本原因——宁可多花钱，不答错题。

顺便说一句，作者刻意只暴露受限读函数而不是完整 SQL，理由是保持工具接口小、fallback 语义明确、生成查询可靠。支持聚合、join、多跳被推到 future work。这个取舍我觉得务实，但也确实限制了当前形态能吃到的工作负载类型。

🧪 实验：53% 成本削减，准确率纹丝不动

实验设置的几个聪明之处

基础模型统一用 Claude-Haiku-4.5，baseline 和 ADC 系统同模型、同工具、同 prompt，唯一区别就是 cracking 接口。所有实验开 prompt caching。

数据集这块有个问题需要解决：FanOutQA 原始问题之间几乎不复用文档、没有局部性——这对 cracking 不公平也不真实。作者的扩展方式是给每个测试问题用 claude-opus-5 生成 1 个相关但不同的问题（实体集重叠、属性不同），生成器对 cracking 系统的设计完全不知情，生成后人工验证。而且主指标只在原始测试问题上报告，cracked-object store 完全由先前的相关问题预热填充——评估的是"热库"状态，避免空库冷启动噪声。这个设置老实说设计得相当克制，没有在基准上给自己放水。

另外还有一个更难的 Cinema 案例研究（希区柯克主题）：先问 20 个关于 Hitchcock 电影、生涯、生活的问题预热，再测 10 个相关问题，fan-out 是 FanOutQA 的 2 到 4 倍。

主结果

图 3：(a) token 用量——FanOutQA 上 prefill 从 189K 降到 87K，案例研究从 565K 降到 161K，decode 都在 3K 以下；(b) 每问题成本——FanOutQA $0.26 → $0.12，案例研究 $0.81 → $0.27；(c) 准确率——LLM 评审 43.0% vs 42.0%，string accuracy 76.1% vs 74.2%；(d) 成本 CDF 分布——中位数 $0.246 vs $0.072，cracking 中位数便宜 3.4 倍。

把关键数字收成一张表：

成本分布（图 3d）里有两个值得玩味的点。好的一面：四分之三的问题上 cracking 有正收益，成对成本比的第 10 百分位便宜 9 倍。诚实的一面：第 90 百分位是 baseline 的 1.24 倍——也就是对那些完全没有复用的问题，cracking 是纯开销。作者没藏这个数据，好评。

cracking 本身的开销也算得清楚：4K decode 预算在 FanOutQA 上增加 12% 开销/问题（含厂商收的 cache read 费），换回来约 150 个 cracked objects。摊销门槛很低——某题抽出的结构只要帮后续问题避免 1 到 2 次文档打开就回本了，之后每避免一次都是净赚。

敏感性：预算的边际收益递减

论文没有独立消融节，但讨论了 decode 预算的敏感性：预算越大，cracked objects 成比例变多，但多出来的对象更窄、更不可能被复用——边际收益递减。当前固定 4K 预算下，主结论"by a wide margin"依然成立。按查询或按文档智能分配预算留给了 future work。

🤔 我的判断

这篇论文最值钱的地方，在我看来不是那 53%，而是它把一件事说清楚了：Agent 推理过程中"已经付过钱"的证据，正在被我们白白扔掉。

想想看，现在所有做 Agent 的团队都在卷上下文管理——压缩、截断、摘要、记忆。但绝大多数方案处理的是"对话状态"，而这篇论文处理的是"语料库结构"。它和 agent memory（MemGPT、Mem0、Zep 那一系）的区别在于：那些系统记的是用户偏好和交互历史，cracking 记的是数据本身的结构，而且写入成本摊销到未来查询上。它和 semantic cache 的区别也很本质：缓存只在相同或近重复问题再来时有用，cracked objects 是紧凑、带证据、可跨不同查询 join 复用的原子结构。

另一个我很认同的判断是跟 KV cache 持久化的对比。有人会说，直接持久化 KV cache 不也省钱吗？问题是 KV cache 绑定单一模型、体积比源文本大得多、吃 GPU 内存；而 cracked 结构是纯文本——跨模型可迁移，模型升级后依然存活，而且随着工作负载累积成组织级资产。作者用了一个词，"data moat"（数据护城河）。这个词我觉得不是吹的：用同一个语料库跑了一年查询的组织，沉淀下来的 cracked-object store 确实构成了别人拿不走的东西。

当然，批评也得说。我的第一反应是实验规模偏小：FanOutQA 只扩展了 1 个相关问题/题，工作负载翻倍而已，真实企业场景的查询流要长得多也复杂得多。28 倍上限是 10 个采样问题人工抽出来的，样本小。7 页短文，没有独立消融节，复用率、投机命中率这些关键指标都没单独量化——"投机抽取的准确率到底多高"这个问题其实没被直接回答。还有那个 1.24 倍的最坏开销，在查询局部性差的真实负载上会不会更常见？说实话这块我没法从论文里得到答案，得等更长 trace 的实验。

另外一个隐忧是 stale data：论文假设静态语料，文档更新后的 cracked objects 失效机制只停留在讨论层面。企业数据是活的，这个坑在落地时绕不开。

但回到工程视角，如果你在做文档密集型问答系统，这篇论文给了三个可以直接拿走的东西：

1. prefill 复用不是优化项，是架构项——把 KV cache 前缀共享/prompt caching 当成一等公民来设计系统，子任务从已加载上下文分叉的边际成本趋近于零；
2. 目录先行的保守回退是保准确率的关键设计——结构化存储只承诺"有什么"，不承诺"够用"，缺了就读原文；
3. 让工作负载自己决定结构——别再纠结"该给文档建什么 schema"了，查询会告诉你答案。

收尾

Database cracking 花了十几年才从 CIDR 论文变成 MonetDB 等系统的实际特性。Agentic data cracking 这个概念现在还只是个 7 页的 workshop 体量工作，但它指向的方向——Agent 推理系统的下一层是一个随查询自组织、带证据、跨模型存活的结构化数据基底——我觉得是大概率会发生的。毕竟那个 28 倍的成本空间摆在那里，谁先把它吃进自己的基础设施，谁的 Agent 就能用 RAG 的价格卖 Agentic 的质量。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我