通稿只说"数据理解—规划执行—验证修复"，等于没说。把它的执行轨迹拆开，才看到那个真正拉开差距的东西
不是拍脑袋编的题，是从客户的真实烂数据里反向提炼的题。
先说这个榜的出身。DAB 全称 Data Agent Benchmark，由 UC Berkeley 的 EPIC Data Lab 和 Hasura PromptQL 合作推出，论文《Can AI Agents Answer Your Data Questions?》在 2026 年 3 月挂上 arXiv。它自称是"第一个面向真实、复杂数据任务的 AI Agent 端到端基准"。
规模不大，密度极高：12 个数据集、54 条自然语言查询、9 个领域，底下横跨 PostgreSQL、MongoDB、SQLite、DuckDB 四种数据库。
关键在于题是怎么出的。出题人没有坐在办公室里编。他们先对 PromptQL 的六个行业客户——技术、金融、餐饮、电商、SaaS、医疗——做了一轮形成性研究，把"企业数据为什么难用"归纳成四类硬伤，然后拿开源数据集做系统性改造，把这四类硬伤一条条复刻进去。标准答案全部由原始数据确定性推导，不靠人工拍脑袋，也不让大模型判卷。
四类硬伤本尊长这样：
| 难点 | 论文里的定义 | 落到考题上 |
|---|---|---|
| 多库集成 | 一个问题的数据可能分散在多个库，查询语言还不一样 | crmarenapro 一个数据集就有 6 个库、3 种数据库类型、27 张表 |
| 连接键格式烂 | 同一实体的标识符在不同库里不一致：前缀不同、尾部空格、名字缩写 | 关联之前，先得认出"这两个字段其实是同一个东西" |
| 答案埋在文本里 | 答案藏在文本字段中，必须先解析成结构化值才能筛选和聚合 | 要算的字段根本没有列，得从一段自然语言里抠出来 |
| 领域知识 | 光看数据推不出来，得懂行业口径 | 不告诉你"复权"是什么，但题里就问复权收盘价 |
举个具体的。bookreview 这个数据集是怎么造的？出题人干了两件事。
第一件，把表里的 publishedDate 和 publisher 两列直接删掉，再用大模型生成句子，把这两个值揉进一个新的 details 列。于是"出版年份"不再是一个可以拿来 group by 的字段，而变成了半句话。想用，先解析。
第二件，把两张表分开放——一张进 PostgreSQL，一张进 SQLite，然后给 join key 各加一个前缀：id 改叫 bid，book_id 改叫 bref。你想把两张表接起来，第一关是"认出这俩是同一个东西"。
领域知识那类题更冷。stockmarket 里有一道要求"复权收盘价高于 200 美元的 ETF"——你得知道拆股和分红为什么要复权。patents 里那道要求识别"EMA 平滑系数 0.2 下专利数最高、且最佳年份是 2022 年的 level-5 CPC 代码"——这些概念不在数据字典里，在行业里。
再看怎么打分。核心指标是 Pass@1：第一次尝试就答对的比例。每条查询至少跑 5 次，先对单条查询的多次结果求均值，再按数据集分层平均——不是拿 54 道题的分数简单一除，而是保证 12 个数据集权重相当。提交时要交结果 JSON 加上完整的执行轨迹，提 Pull Request 上榜，缺轨迹直接拒。
榜单上的成绩是这样的：OceanBase 团队提交的方案以 90.62% 的 Pass@1 位列第一，是该榜单首个突破 90% 的参评方案，成绩提交于 2026 年 9 月 8 日，超过了多项基于 GPT、Claude Opus、Claude Fable 搭出来的方案。
但比"第一"更值得问的是下一个问题：它是怎么答出来的？
通稿那句话等于没说，得看轨迹。
先说身份。参评方案内部代号 Scout，由 OceanBase Lab 提交，底座用的是开源模型 GLM-5.2——而且注意一个细节：**它把 thinking 关掉了**。54 道题每条跑 5 轮，一共 270 组答案与轨迹。
媒体通稿给出的解释是"数据理解—规划执行—验证修复"三步闭环。这话没错，但基本上所有队都能这么说，等于没说。
真东西在它自己上传的那份执行轨迹包里——里面存着完整的 system prompt、工具 schema、每一次模型调用和每一次工具返回。拆开之后，Scout 的做法清晰了：它给模型配了一个编译器。
Scout 的 system prompt 里列了这样一套工具，每一条都带使用约束：
| 工具 | 干什么 |
|---|---|
| schema_overview | 先摸清所有库的表结构，"除非已有可信的画像" |
| describe_table / sample_data | 看列、看样本行，且明确提示"抽样是有界预览，永远不是答案的完整总体" |
| query_db | 直接跑 SQL 或 Mongo 查询 |
| workflow_query | 编译器本体。system prompt 里的原话是"preferred compiler-backed tool"，用于多步、跨库的查询、join、过滤、聚合、排序、ID 子集、时段过滤和加权指标 |
| classify_aggregate | 闭集文本分类的唯一入口，负责成员语义、完整总体和计数/占比/分组排名 |
| extract_fields | 模型驱动的开放式文本抽取 |
| text_search | 文本发现 |
| execute_python | 本地 Python 3.12、pandas/pyarrow、断网。"只在工具或内核无法表达这份工作时才用" |
| note_finding | 记录发现。事实类结论必须带本轮有效证据引用，否则只能算"待验证假设" |
| return_answer | 交卷。evidence_ids 只能填直接用于这个答案的变量键 |
配套的还有一套结果存储机制：每次工具调用的完整结果存进一个变量（key 形如 var_call_xxx），模型在写 Python 时可以直接当变量名用。聊天窗口里显示的是有界预览，但完整数据一直都在。
看一道真题。bookreview 那道"哪个十年的平均评分最高"，Scout 交给编译器的不是一段 SQL，而是一份声明式计划：
这份计划里有三个细节，说明它确实是编译器而不是提示词模板。
第一，它有类型化的操作原语。regex_extract、compute_expression、replace_prefix、schedule_filter、加权指标，都是编译器认识的操作符，不是让模型自由发挥。看那行 id_transform——它处理的是"两张表一个叫 book_id 一个叫 purchase_id，但其实是同一个实体"这个问题。**这正是 DAB 故意埋的坑，而 Scout 手里有一个内置原语专门治它。**
第二，内核会拒绝语义错误的计划。这是整份轨迹里最有价值的一段。模型提交了一份 join 计划，内核没执行，直接弹回来：
翻译一下：这个 join 会让左表的行数变多，你的口径就歪了，先去重或先聚合，再回来。这段话不是报错信息，是一句**可直接执行的修复指令**。这就是 PR 里说的 bounded plan repair——不是让模型自己"反思一下"，是内核拒绝执行、把错误翻译成修复要求、模型改计划再交。
很多方案会把答案吐出来就结束。**能拒绝，才叫有校验。**
第三，Python 被降级成了兜底。约束原话是"只在工具或内核无法表达这份工作时才用"。换句话说，随性写脚本是最不优先的路径。
DAB 论文里有一句判决书式的观察：所有参评的 agent 都用正则表达式去抠自由文本，没有任何一个靠 NLP 或再叫一次大模型来抽取。所以在日期格式五花八门的数据集上，前排方案齐刷刷翻车。
Scout 的工具清单里有两个工具，专门干这件事：classify_aggregate 管闭集分类，extract_fields 管开放式抽取，而且明确要求用"名称+类型+描述"的结构声明要抽什么。它是那道题上的例外。
再看调用频次分布，能看出它真实的肌肉长在哪：
| 工具 | 调用次数 | 工具 | 调用次数 |
|---|---|---|---|
| query_db | 5950 | schema_overview | 372 |
| workflow_query | 3428 | text_search | 312 |
| execute_python | 2607 | extract_fields | 232 |
| return_answer | 1110 | classify_aggregate | 198 |
| describe_table | 918 | batch_query_tables | 93 |
| sample_data | 708 | entity_resolution | 33 |
还有两处值得单独说。
一次 query 的每一次运行，都会单独落盘一份 planner_output.json 和 planner_trace.jsonl——所谓"按需 planner 子智能体"是个独立组件，不是修辞。日志里还留着护栏事件的计数：重复调用被拦截、输出工具校验失败、模型响应不可用、修复无进展。
另一次典型运行的开销也拿到了：bookreview 第一题第 0 轮，20 次模型调用、139.6 秒，迭代上限设的是 100。轨迹里还附了一份隔离证明：进程隔离、独立子进程、禁用持久缓存读写、禁用记忆注入与事后抽取、数据源绑定到指定文件并附哈希。
最强前沿模型 38%，还有一个数据集，全员零分。
论文里的基线成绩是这样的：
| 指标 | 数值 | 意味着什么 |
|---|---|---|
| 最强前沿模型 Pass@1 | 38%（Gemini-3-Pro） | 裸模型上场，六成以上的题答错 |
| 同模型 Pass@50 | 不超过 69% | 给 50 次机会反复试，仍有三成题目搞不定 |
| 完全无解的数据集 | 1 个 | 所有 agent 在全部试验里，一道都没答对 |
| 错误来源 | 85% 来自规划或实现 | 很少是"选错了数据源" |
最有信息量的是最后一行。85% 的错答案，坏在规划错了或者实现错了，而不是找错了表。这个分布挺残酷：它说明模型不是不懂问题，是执行链条太长，中间某一步歪了，后面算得再漂亮也是错的。
这也正好解释了 Scout 为什么要在第 02 章那样做。既然错都错在规划和实现，那就把规划和实现这两段单独拿出来管——写计划的是模型，执行计划的是内核，校验计划的是内核的类型系统。**它针对的正是论文指出的那 85%。**
论文里还有个反直觉的发现：探索不是越多越好。准确率最高的两个 agent，各自把大约 20% 的工具调用花在"先看看数据长什么样"上。少了摸不清底细，多了纯烧预算。
把榜单前排的 PR 说明全抓出来，一对比就清楚了。
DAB 要求提交时附上 agent 配置说明。所以前排各家的自述是可以直接横向比的。我抓了前七名，结果有点反直觉。
| 方案 | 分数 | PR 里自述的架构 | 确定性组件在哪一层 |
|---|---|---|---|
| Permute EQ | 0.9467 | 正文里一句架构都没有，只有一张"哪道题用哪个提示词"的分派表 | 无 |
| Scout（OceanBase） | 0.9062 | 主 Agent + 按需 planner 子 Agent；确定性 workflow compiler + data kernel 执行计划 | 执行层 |
| Camber | 0.8790 | 每个数据集一个专用 notebook agent，每次 trial 全新 context | 无 |
| Sentinel | 0.8450 | 单 Agent ReAct + deterministic verify_step 断言层（行数、唯一性、非空、值域） | 校验层 |
| Sarvam Code | 0.8208 | 单 Agent + 确定性 answer gate + 盲解第二求解器交叉验证 | 校验层 |
| DataTrail v1 | 0.8201 | "一个模型循环 + 一个 execute 工具"，明确写"subagents are disabled" | 无 |
| DataBridge | 0.6137 | 一个开源 MCP server，主要靠大 system prompt | 无 |
按"到底靠什么拿分"，这七家能切成三类。
第一类，纯提示词加模型循环。最典型的就是榜一 Permute EQ——它是七家里最不工程化的一家，正文明明白白只有逐题提示词分派，没有任何架构描述。第二名 DataBridge 稍进一步，用一个 MCP server 做跨库 join 发现，但分数最低。
第二类，模型循环加沙箱，但主动关掉复杂结构。DataTrail v1 明写"只有 1 个模型循环 + 1 个 execute 工具，subagents 关闭、challenger 关闭"，它的工程投入全在隔离与可审计上。Camber 是每个数据集一个专用 notebook agent，每次全新上下文，工具链只有驱动 Jupyter 内核的两个函数。
第三类，模型循环加明确的确定性层，只有三家。Sentinel 的 verify_step 是"由 agent 自己调用的非 LLM 断言检查"；Sarvam 是"答案闸门加盲解交叉验证"。**这两家的确定性都在事后校验这一层。**
而 Scout 那一句是"a deterministic workflow compiler and data kernel execute these plans"——它的确定性在**执行计划本身**。
差别打个比方：Sentinel 和 Sarvam 是写完代码跑测试，Scout 是先把代码编译成目标文件再执行。前者能发现错，后者能让错压根执行不了。
这条路不是 OceanBase 独家发明的，它有个更古老的名字。
先把话说清楚：把 LLM 的不确定性关进确定性执行框架，不是 OceanBase 首创，数据行业已经做了好几年，而且有量化证据。
dbt Labs 在 2026 年做了一组对照基准，拿同一批问题、同一个模型，分别用"纯文本转 SQL"和"经过语义层"两条路跑：
| 模型 | 纯文本转 SQL | 加语义层 |
|---|---|---|
| claude-sonnet-4-6 | 90.0% | 98.2% |
| gpt-5.3-codex | 84.1% | 100.0% |
机理说得很直白：语义层让查询生成变成确定性的——模型只要选对了指标和维度，查询就保证正确，不可能生成错的 join 或错的聚合。
更关键的是失败模式变了。dbt 的原话是：纯文本转 SQL 失败的样子是"**一个看似合理但错误的答案**"；语义层失败的样子是"**一条报错**"。对企业来说，前者是灾难，后者只是麻烦。
Snowflake 的对照也类似，自测同一底层模型下，带语义模型平均 78%，不带 57%，差 21 个百分点。第三方对企业真实 schema 的汇总更狠：裸文本转 SQL 大约 40%，加上语义层到 85% 到 95%。
而语义层、口径定义、指标卡这些东西，是数据库公司几十年的家底。
OceanBase 官方披露过同一套方法论在 DataPilot 上的做法——**这里要说清楚，那篇材料讲的是另一个基准 DABstep 的场景，不是 Scout 的实证**，但能看清这套工程的骨架：
CEO 杨冰的说法是："模型决定 AI 的能力边界，数据决定 AI 的业务价值。"另一句是数据库正在"从存放数据，到承载智能"。落到 DAB 这件事上，这两句话的意思就是：**当所有队的模型都不差时，胜负手移到了数据侧。**
6 个数据集满分，一个只有 0.45，而且它现在不是第一。
90.62% 是个平均数，摊开到 12 个数据集上，能看到它强在哪、栽在哪：
| 数据集 | Pass@1 | 数据集 | Pass@1 |
|---|---|---|---|
| bookreview | 1.0000 | DEPS_DEV_V1 | 0.9000 |
| googlelocal | 1.0000 | yelp | 0.8571 |
| music_brainz_20k | 1.0000 | GITHUB_REPOS | 0.8000 |
| PATENTS | 1.0000 | agnews | 0.4500 |
| PANCANCER_ATLAS | 1.0000 | stockmarket | 0.9600 |
| stockindex | 1.0000 | crmarenapro | 0.9077 |
六个数据集满分，包括那个出题人精心埋了坑的 bookreview，也包括需要领域知识的 patents 和 stockindex。唯一难看的是 agnews，0.45——正好是那个"从文本里分类抽标签"的数据集，也是全场所有方案都头疼的地方。
顺带说明一下为什么 0.45 没把总分拖垮：因为计分是分层的，先算每个数据集的平均，再对 12 个数据集取均值。所有数据集权重相同，一两个短板不会决定全局，但也意味着——**你不能靠刷某一个数据集把分刷上去。**
还有一件事得照实说。Scout 的 PR 里，评委发现提交的轨迹包自述写着"选择性替换与重新编号，并非未筛选的冻结评测"，于是追问：是不是把失败的 run 删掉换了？
作者承认了，并给出了理由：原计划一次跑完 270 组，但部分查询因为大模型 API 并发限制和间歇性不稳定崩了；为了不整体重跑，他们按数据集级别丢弃受影响的 trial、重新编号、补跑完整数据集级别的轮次。替换的判据是"执行崩溃，而不是答案对错"，并且提交的轨迹里仍然包含答错的样本。这份披露写在轨迹包的 README 里，是主动的。
评委最终收录了这份成绩。所以 90.62% 这个数字，建立在一次"披露过的、由崩溃驱动"的 trial 替换之上——**它跟那些干干净净跑完 270 组、零替换的方案，严格来说不完全可比。**这一点我认为读者应该知道。
按最新的官方榜单，OceanBase 现在排第二。
媒体报道的"登顶"不是造假，但它描述的是一个时间切片。Scout 提交于 2026 年 9 月 8 日，那一刻它确实排第一，也是第一个站上 90% 的方案。三天之后，2026 年 9 月 11 日，一个叫 Permute EQ 的方案用 Claude-Opus-5 提交了 94.67%，把第一拿走了。
这件事不丢人。前排方案基本都在 0.8 以上打转，第一名和第二名之间那 4 个百分点是几个月的量级，不是代差。而且从提交节奏看，这个榜的头部一直在动。
最后提醒一句，别把两个榜混着用。DABstep 和 DAB 只差一个后缀，完全是两个东西。DABstep 是 Adyen 和 Hugging Face 在 2025 年 2 月做的，450 道真实金融支付业务题，分 Easy/Hard 两级。OceanBase 的 DataPilot 在 2025 年 12 月拿过 Hard 榜第一，2026 年 1 月官方还发博客说"连续一个月大幅领先"；现在已经是 NVIDIA 的 KGMON 排第一，DataPilot 第三。
两个榜的变迁说明同一件事：这个领域的榜首是流动的，几个月就换一轮。真正留下来的不是名次，是能力有没有变成产品的一部分。
成绩会过期，能力不会。
OceanBase 官方说得很明确：Scout 只是参评代号，能力后续会沉淀到 DataPilot 产品里——承接数据理解、任务规划、分析执行、结果验证这四项。
它不是孤零零一个产品。数据库这一侧的配套这几年一直在铺：seekdb（2025 年 11 月发布并开源，AI 原生混合搜索数据库，向量、全文、标量、空间统一混合搜，兼容 30 多个 AI 框架）、PowerRAG（智能文档解析加一体化 RAG 工具）、PowerMem（分层记忆架构，LOCOMO 基准 78.70 分 SOTA，token 消耗降 96%）、4.4 版本（第一次把事务处理、分析处理和 AI 能力装进同一个内核）、Lakebase（湖库一体的底层引擎）。
拼起来是一句话：数据库不再只负责把数据存好、算好、取出来，还要帮 AI 理解数据、组织数据、验证结果。
有个佐证：在《IDC MarketScape：中国 Data Agent 2026 年厂商评估》里，OceanBase 进了"领导者"象限。IDC 还预测，到 2028 年 60% 的中国 500 强企业会部署企业级 Data Agent。
这家公司的底子能解释它为什么敢往这个方向压：2010 年立项，蚂蚁集团完全自研，2021 年 6 月开源 300 万行核心代码；商业化客户超过 4000 家；是唯一在事务处理和分析处理两个 TPC 国际基准上都刷新过世界纪录的中国自研数据库。
回到最开始那个问题。Scout 牛在什么地方？
不在模型——它用的 GLM-5.2 是开源的，关掉 thinking，谁都能下载。不在提示词——榜一的提示词工程比它更细。**它牛在给模型配了一个编译器：计划必须被编译、必须被执行内核接受、错了必须按内核给的指令修。**
论文说 85% 的错答案坏在规划和实现。它没有去求一个更聪明的模型，而是把规划和实现这两段单独拿出来，装上了一个会说"不"的内核。
至于名次，下个月再看吧。