What Happens When the Model Eats the Stack? Rethinking the Research Agenda for Data Agents to Withstand the Bitter Lesson
Liana Patel, Siddharth Jha, Negar Arabzadeh, Carlos Guestrin, Ion Stoica, Matei Zaharia
cs.DB
2026-09-03
GPT-5.6通用编码Agent在DAB上比o3高出35分以上、轮次约降4倍，专用脚手架被吃掉；用12条轨迹离线写成的持久语义上下文，还能再把准确率抬19分。
Sutton 的 bitter lesson 说得很直：能靠算力端到端学出来的能力，手工脚手架最终都会被吃掉。数据库社区过去两年却在往相反方向加层，给数据 Agent 配规划器、SQL 生成管线、多 Agent 工作流，用来补模型在单条查询上的短板。
Berkeley 与 Stanford 这组人问的是另一件事：模型继续变强之后，这些层还剩什么？他们用 2025 到 2026 的三代模型（o3、GPT-5、GPT-5.6 Sol），在 TAG-Bench 和 DAB 上对打通用编码 Agent（Codex harness）和当时最好的专用数据 Agent。结论很硬。单任务上的专用脚手架正在被模型吃掉；真正跨查询还在、还会相对变贵的，是对环境本身的知识。
评测分两段。
第一段看「模型吃栈」有多快。TAG-Bench 测的是关系库上要同时做精确计算、语义推理和世界知识的查询；DAB 测的是打散在企业数据源上的多步分析。通用侧一律走 Codex 编码 Agent，不加任务特化。专用侧在 TAG 上用 BIRD 榜靠前的 Agentar-Scale-SQL。完整推理代码未公开，论文按其公开 prompt 加一轮执行反馈做近似，并且只跑 60 条非聚合查询。DAB 上 Agentar 不适配多轮，改用开源的 DeepEye 工作流 Agent，并加了 DuckDB 与 MongoDB 连接器。推理档位扫过，正文报的是 low reasoning。
第二段看什么不会被吃掉。他们让 GPT-5.6 Sol 在 12 条开发轨迹上离线写一份持久语义上下文（persistent semantic context），冻住后拼进 42 条 held-out 查询的第一条 user prompt。三种目标：Accuracy、Latency、Schema。另用 GEPA 做准确性导向的指令进化。对照是 No Context，每条查询现场探环境。
弱模型时专用管线还能赢：TAG 上 o3 的 Agentar 近似比同模型编码 Agent 更准、更省 token。换到 GPT-5.6 Sol，编码 Agent 在两个榜上都反超同模型专用 Agent。DAB 上编码 Agent 相对 o3 同款 harness 高出 35 分以上，输出 token 效率好过 2 倍；TAG 上 GPT-5.6 Sol 编码 Agent 已经贴近 Oracle（专家写查询、LOTUS 运行）。Figure 1 是散点图，论文没有另给精确表。
轮次掉得更狠。DAB 上编码 Agent 平均轮次从 o3 的 23.2 降到 GPT-5 的 9.9，再到 GPT-5.6 Sol 的 6.0，大约 4 倍。砍掉的主要是分析查询和校验、恢复；schema 探查的相对占比反而从 16% 升到 25%。失败模式跟着搬家。执行错误随模型变强而消失。GPT-5.6 Sol 的 40 次失败里，C1 语义理解占 40%，C2 选错表或字段占 18%，C3 实体与 join key 占 38%，环境知识合计超过 60%。
离线上下文能把这些成本摊掉，但账单立刻出现。
| 方法 | 相对 No Context | 平均轮次 | 构建代价 |
| Self-Curated (Accuracy) | 准确率 +19 分 | 6.0 | 164.9 秒 / 1.09 美元 / 2.52KB |
| Self-Curated (Latency) | 低于 Accuracy 目标 | 4.5 | 154.9 秒 / 1.13 美元 / 2.25KB |
| Self-Curated (Schema) | 准确率略降 | 4.6，schema 探查从 25% 掉到 9% | 3413.6 秒 / 9.60 美元 / 162KB |
| GEPA (Accuracy) | 介于 No Context 与 Accuracy 之间 | 4.9 | 1359.8 秒 / 12.16 美元 / 7.55KB |
Accuracy 上下文把准确率抬了 19 分，轮次几乎没变。Latency 上下文把轮次压到 4.5，端到端延迟仍高于 No Context。Schema 上下文才是真存环境知识的那份，探查被砍掉，准确率却掉下去。论文怀疑是 12 条轨迹过拟合，线上又过度依赖这份笔记。
给做企业内部数据 Agent 的人，这篇把赌注从「再加一层规划器」挪到「把环境知识做成可摊销的一等公民」。规划、写代码、调工具、debug，模型正在内化；公司特有的指标定义、权威表、join 路径、口径冲突，训练时没见过，每条查询现场再探一遍会越来越亏。
它也直接顶了 CIDR 2026 那篇 Supporting Our AI Overlords 的前提：未来数据系统会被海量投机查询淹没。这里看到的是相反曲线。更新的模型单条查询更省、失败更少。系统该优化的可能不是吞吐投机 SQL，而是一份会过期的语义层。
这是议程论文，不是新系统。能立刻抄的只有很粗的「让 Agent 离线写 Markdown 再拼进 prompt」。19 分是在 42 条 held-out、12 个库的小规模上拿到的。后面提出的语义一致性协议、上下文数据结构和压缩策略，都还停在设计空间。
专用基线并不完整。Agentar-Scale-SQL 的多生成器、修订器和选择器没公开，论文只用了 prompt 加一轮执行反馈，还砍掉了聚合查询；DAB 上的 DeepEye 是 BIRD 开源次优，并加了额外连接器。弱模型上专用管线曾经领先，其中一部分可能来自「专用系统被削过」。
失败聚类由 GPT-5.6 Sol 自己打标，分类器与被评模型同族。上下文实验只有 12 条轨迹、12 个库，Schema 变体已经过拟合；论文自己也写了，真实环境是 TB 级、上千张表，构建代价会按这个警告放大。只测了 OpenAI 三代加 Codex harness。Latency 上下文轮次少了，墙钟延迟反而高于 No Context，「少干活」和「更快结束」不是一回事，原因没有拆开。