Chunlin 的论文科普

当模型越来越强，数据智能体的研究还有什么可做的？

LLM 与智能体

你可能用过 Text-to-SQL 工具：以前得靠人精心设计一套 pipeline——schema 链接、问题分解、SQL 校验，一步都不能少。但最近一年多，有人发现：直接让通用编码模型上，反而比这些精心搭的系统还准还快。那我们之前做的那些「智能体系统层」，还有意义吗？

一个反转：通用编码智能体反超了人工设计的专用系统

先来看一个有点打脸的实验。研究者在两个标准数据智能体基准（TAG-Bench 和 DAB）上，对比了两类系统的表现：一类是人类精心设计的专用数据智能体（比如 Agentar-Scale-SQL、DeepEye 这类带完整 pipeline 的系统），另一类就是最简单的通用编码智能体——直接把问题扔给通用大模型，让它自己写代码、自己执行、自己调试，没有任何专门为数据任务设计的模块 [1]。

结果很反直觉：在 2025 年初的 o3 模型上，人工设计的专用系统确实更准，毕竟那时候模型还弱，需要人类搭的「脚手架」帮它补推理能力。但仅仅过了一年多，到 GPT-5.6 Sol 这一代，通用编码智能体在两个基准上的准确率都显著高于同模型的人工设计专用系统 [1]。人类花了好多心血搭的分解、校验、纠错模块，反而成了拖后腿的累赘。

不仅更准，还更快更省。DAB 基准上，GPT-5.6 Sol 的通用编码代理比 o3 时代的准确率高了超过 35 个百分点，token 效率提升超 2 倍，每个任务需要的交互轮次减少了约 4 倍 [1]。以前大家觉得「智能体就是靠大量试错、低效探索」的印象，在强模型下不成立了——模型自己就知道该怎么一步步做，不需要人帮它规划步骤。

当然，实际情况比这个比喻更复杂：这里的「通用编码智能体」还是有最基础的代码执行环境，不是纯靠模型脑子里想；但核心的任务分解、schema 匹配、SQL 校验这些以前认为必须人工设计的环节，确实被模型自己内化了。

为什么会反转？从「推理瓶颈」到「环境知识瓶颈」

为什么会有这个反转？因为模型变强之后，失败的原因彻底变了。

研究者统计了 GPT-5.6 Sol 编码代理的错误分布：超过 60% 的失败，都来自「环境知识类错误」——比如误解了某个字段的语义、选错了数据源或表、不知道两个表该用什么键关联 [1]。而真正的执行错误（比如 SQL 语法错、逻辑写不对）占比已经很低，而且还在随着模型能力提升继续下降。

这很像人的情况：一个越聪明的人，越不会卡在「这道题该怎么算」，而是会卡在「这数据到底是什么意思」。给你一个完全陌生的企业数据库，哪怕你 SQL 写得再溜，你也不知道「user_profile 表里的 status 字段 0/1/2 分别代表什么」「order 表和 payment 表到底是用 order_id 连还是用 trade_id 连」——这些不是推理能力问题，是你对这个特定环境的知识不足。

以前模型弱的时候，推理能力是主要瓶颈，所以人类设计的各种分解、校验、纠错模块很有用，相当于帮模型补脑子。现在模型脑子够使了，瓶颈就转移到了「它不认识你家的数据」上——而这东西，通用模型再强也不可能天生就知道，因为每个企业、每个数据库的 schema 和语义都是独特的。

留得住的问题：持久语义上下文是什么？

那什么东西是模型永远内化不了、必须靠系统层解决的？这篇论文提出了一个核心概念：持久语义上下文（persistent semantic context） [1]。

简单说，就是把关于特定数据环境的所有知识——表是干嘛的、字段是什么意思、表之间怎么关联、常见的坑在哪——离线整理成模型能直接用的上下文，相当于给模型写了一本「工作手册」。以后每次处理新查询，模型先翻这本手册，而不是从零开始摸索数据结构。

你可能会问：这东西为什么不能被模型内化？因为它是环境特定的非参数知识。通用模型再强，它的参数里也不可能装下全世界每个公司、每个数据库的私有 schema 和业务语义。而且这些知识还会随时间变化——表会加字段、业务逻辑会改，总不能每次改个字段就重新训练一次模型吧？

这就像你上学时学的通用知识（比如数学公式、物理定律）可以记在脑子里，但你去一家新公司上班，还是得读他们的内部文档、了解他们的业务术语——这些东西是环境专属的，没法靠「变聪明」自动获得。

它真的有用吗？实验证据与代价

那这本「工作手册」到底有多大用？研究者做了个实验：用 GPT-5.6 Sol 基于 12 条 DAB 的开发轨迹，离线生成不同目标的持久语义上下文，然后在 42 道没见过的题上测试效果 [1]。

结果相当可观：用「准确率导向」的自整理上下文，比无上下文的基线准确率提升了 19 个百分点 [1]。如果是「schema 导向」的上下文，则能大幅减少 schema 探索的轮次——模型不用再一张张表去翻结构了，手册里都写好了。

但天下没有免费的午餐，这本手册的构建成本不低，而且不是越详细越好。实验里，schema 导向的上下文构建花了 3413.6 秒（近 1 小时），成本 9.6 美元，大小 162KB；而准确率导向的轻量版本只花了 164.9 秒，1.09 美元，只有 2.5KB [1]。更值得注意的是，schema 导向的上下文虽然省了探索轮次，但准确率反而略有下降——因为手册写得太细太具体，模型容易过度依赖、死记硬背，遇到稍微不一样的情况反而不会变通了，有点「过拟合」的意思 [1]。

而且这还只是 12 个数据集的小规模实验。论文作者也承认，真实企业环境里动辄 TB 级数据、几千张表，构建成本会随着数据规模和复杂度急剧上升 [1]。怎么高效构建、怎么控制粒度、怎么避免过拟合，都是还没解决的问题。

这事从哪来的？数据库 + LLM 的三年脉络

把这篇论文放进时间线里看，你会发现研究重心的转移非常清晰。

最早是 2023-2024 年的 DB-GPT 时代，那时候模型还弱，大家的思路是「私有化模型 + RAG + 专用 agent」——用领域数据微调模型，搭一套完整的检索增强生成 pipeline，再配上专门的 Text-to-SQL 智能体，目标是补模型的推理能力和领域知识 [6]。这时候的核心假设是「模型不够强，得靠系统层补」。

到了 2024 年 VLDB 的主题演讲，大家开始意识到光补推理不够，语义数据模型和增强上下文才是更关键的方向 [7]。这时候已经有人隐约感觉到，模型推理能力会越来越强，但对特定数据环境的理解是个持久问题。

再到 2025 年，研究进一步下沉到长上下文检索的系统优化——既然上下文重要，那怎么让上下文检索得更准、更快？比如 YOURA 这样的工作，通过基于注意力的检索技术，把长上下文问答的准确率提升了最多 15%，推理吞吐量提升 30% [8]。这时候重心已经从「怎么帮模型推理」完全转向「怎么给模型喂对环境知识」了。

而 2026 年的这篇论文，相当于把这个趋势挑明了：不用再纠结怎么设计智能体 pipeline 了，模型自己会搞定；真正的长期问题，是怎么管理和服务好这些环境特定的持久语义知识 [1]。

往前走一步：还有哪些没解决的系统问题？

如果持久语义上下文真的是未来方向，那现在还差得远，有一大堆系统问题等着解决。

首先是上下文的数据结构和存储。现在的上下文基本就是一段纯文本，扔给模型的上下文窗口里。但如果是几千张表、几万个字段的企业级环境，纯文本肯定不行——放不下、检索慢、更新难。要不要给上下文设计专门的数据结构？怎么存、怎么压缩、怎么快速检索相关部分？这些都是全新的问题 [1]。

然后是语义一致性模型。数据库有事务、有一致性保证，那语义上下文呢？数据 schema 改了、业务逻辑变了，上下文要不要跟着改？改的时候要保证多强的一致性？是强一致、最终一致，还是查询触发的时候再更新？不同的工作负载可能需要不同的一致性模型，这和数据库里的事务隔离级别有点像，但又完全不是一回事 [1]。

还有增量维护 vs 整体重建的权衡。上下文不可能一劳永逸，数据环境一直在变。是每次变一点就增量更新上下文，还是定期整体重建？增量更新快，但可能积累不一致；整体重建准，但成本高、周期长。怎么平衡这个 trade-off，也是个经典的系统问题 [1]。

当然，这篇论文本身也有不少局限。实验用的都是闭源前沿模型（o3、GPT-5、GPT-5.6 Sol），对开源生态的适用性没讨论；基准规模也比较小（12 个数据集、42 道题），能不能推广到真实企业环境还不好说；而且提出的研究议程都是方向性的，没有具体的系统实现和量化验证 [1]。这些都是后续工作要填的坑。

更广义的启示：哪些「系统层」不会被模型吃掉？

其实不止数据智能体，整个 AI 系统领域都在面临同一个问题：模型越来越强，哪些系统层的工作会被模型内化，哪些才是真正留得住的？

从这篇论文的结论往外推，一个合理的猜测是：凡是属于模型能力范围内的——推理、执行、通用知识、任务规划——都会被模型自己吃掉。你今天精心设计的分解模块、校验模块、纠错模块，明天模型变强了可能就不需要了，甚至还会拖后腿 [1]。

而凡是环境特定的、非参数的、需要持久化和一致性保证的知识，才是系统研究的长期阵地。因为这些东西不是靠模型参数增长就能自动获得的，它和具体的环境绑定，需要外部系统来管理、维护、服务 [1]。

数据库领域几十年前就明白了这个道理：计算能力再强，你也得有个地方存数据、管数据、保证数据的一致性和可靠性。现在到了 AI 时代，只不过存的东西从「字节」变成了「语义上下文」，管的东西从「数据一致性」变成了「语义一致性」——但系统研究的本质没变：给上层的计算能力提供可靠、高效、持久的环境知识底座。

就像 VLDB 2024 主题演讲里提到的，语义数据模型和增强上下文，是 LLM 时代数据库研究的新方向 [7]。现在看来，这个判断正在被一步步验证。

如果你只记住一件事

模型越强，越需要持久语义上下文——推理能力会被模型内化，但环境特定的知识永远是系统层要解决的核心问题。

参考文献

  1. What Happens When the Model Eats the Stack? Rethinking the Research Agenda for Data Agents to Withstand the Bitter Lesson（arXiv、2026、全文精读）
  2. CyrillicQA: The Influence of Phonetically Encoded Secret Language on LLM Performance（arXiv (Cornell University)、2026、全文精读）
  3. Remember and Reweight: Enhancing Multi-Agent Debate with Experience Memory and Confidence Estimation（arXiv、2026、全文精读）
  4. Translation as a Decision Space: A Multi-Agent Perspective on Low-Resource Dialect Generation（arXiv、2026、全文精读）
  5. Latent Space Refusal Anchoring for Low-Resource African Languages: Mechanistic Safety Recovery Without Retraining（arXiv、2026、全文精读）
  6. DB-GPT: Empowering Database Interactions with Private Large Language Models（2024、仅摘要）
  7. Harmonizing ML and Databases: A Symphony of Data (VLDB 2024 Keynote)（Proceedings of the VLDB Endowment、2024、仅摘要）
  8. From Persisting Bytes to Retrieving Context: Crash-Consistent PMEM Systems and Efficient Context Retrieval for LLMs（eScholarship (California Digital Library)、2025、仅摘要）