当代码成了Agent的"工作语言"：三个编码智能体如何啃下企业数据这块硬骨头
做过企业数据集成的人都懂那种痛——数据躺在十几个CSV、Excel、JSON里，业主、数据工程师、分析师三方反复拉扯，每次交接都要把"我理解的数据长什么样"翻译成一段话、一份文档、一个口头约定。然后下一个人再把这段话翻译回代码。来来回回，信息一层层掉。这篇论文给的解法挺干脆：别再传文本了，直接传能跑的代码。
核心摘要
企业里的数据集成有个老大难问题：数据从原始状态变成能查询的库，要经过业主、工程师、分析师之间一轮轮"有损交接"——每次都把可执行的东西降维成文本描述，再让下一个人翻译回去。C3 AI 团队这篇 Data Intelligence Agents（DIA，arXiv:2606.19319） 的思路是把整条链路压缩成三个智能体：数据解释器、Schema 创建器、查询生成器。关键的反直觉点在于——它把自主编码智能体（Autonomous Coding Agent, ACA）当成系统的一等抽象，Agent 之间传递的不是文字，而是能跑、能验、能修的具体 artifact（profiling 脚本、加载脚本、schema、查询日志）。论文重点深挖了查询生成器，在七个 SQL benchmark、四类任务、四种方言上全自主跑，七个全部匹配或超过当前最好的公开结果，其中对话式交互那个 benchmark 直接领先 33 分。说到底，这不是又一个 text-to-SQL 模型，而是一套"用执行来接地"的工程范式——值得做数据平台的人认真看看。
论文信息
- 标题：Data Intelligence Agents: Interpreting, Modeling, and Querying Enterprise Data via Autonomous Coding Agents
- 作者：Anoushka Vyas、Aarushi Dhanuka、Sina Khoshfetrat Pakazad、Henrik Ohlsson
- 机构：C3 AI
- 链接：https://arxiv.org/abs/2606.19319 （提交于 2026 年 6 月 17 日）
🎯 先说说这个问题到底有多烦
你可能没做过企业级的数据集成，那我先把场景铺一下。
某个大客户给你一堆数据：销售系统导出的 CSV、财务那边的 Excel、还有几个 API 拉下来的 JSON。任务是把它们整合成一个能查询、能出报表的数据库。听起来不难对吧？
实际干起来是这样的：业主知道"这个字段是客户编号但偶尔会混进供应商编号"，但他不会写代码，只能跟工程师口头说一遍。工程师按理解写了加载脚本，但他不知道"这列的空值其实代表已退货"这种业务语义。分析师拿到库之后想查个"复购率",发现 join 出来的数字翻了几十倍——因为没人告诉他那张表是一对多的。
问题出在哪？每一次交接，都是把一个可执行、可验证的东西，压缩成一段自然语言，再让下一个人翻译回可执行的东西。 信息在这个"可执行 → 文本 → 可执行"的来回里一点点流失。论文管这叫 "repeated, lossy handoffs"，我觉得这个词抓得挺准。
传统的 text-to-SQL 系统其实也在犯同样的毛病——模型吐出来的是一段 SQL 文本（或者一段对查询的批评），但企业数据工作真正消费的是能跑的、能检查的产物。文本和产物之间，又隔了一层。
DIA 的回答很直接：那就别让 Agent 输出文本了，让它直接输出代码、执行代码、检查结果、修复问题。
📖 先看一眼成绩单
直接上 Figure 1，这是 DIA 跟每个 benchmark 上最强公开系统的对比，按领先幅度排序。
图1：DIA 在七个 SQL benchmark 上对阵各自最强的先前系统，按领先幅度排序。每个 benchmark 用其官方指标打分。可以看到除了最饱和的 BIRD-Dev 是持平，其余六个都是正向领先，对话式的 BIRD-Interact 拉开的差距最夸张。
我第一眼看到 BIRD-Interact 那根条的时候是有点怀疑的——领先 33 分这种幅度，在已经卷成红海的 SQL benchmark 上不太正常。后面看了它的拆解才明白原因，这个待会儿讲。先记住一个判断：这套方法在"需要多步交互、需要先把数据摸清楚"的任务上优势最大，在"一锤子买卖"的简单生成任务上优势收窄。 这个规律其实暗示了它真正的价值所在。
🏗️ 方法核心：把"会写代码的Agent"当成积木
一个 Agent，三种角色
先纠正一个容易误会的点。论文说的"三个 Agent",物理上其实是同一个 ACA，在一个共享工作区 W 上被调用三次，扮演三种角色。它们共享同一份记忆 M，每个角色产出的 artifact 都会摆到领域专家面前过一遍目（human-in-the-loop）。
来看系统全貌：
图2：DIA 系统。单个 ACA 在共享工作区 W 上运作，实现三个 Agent（数据解释器、Schema 创建器、查询生成器），把原始数据 D 和问题 q 转化成有依据的答案 R。每个 Agent 在 W 中读写可执行 artifact；所有 Agent 都从共享记忆 M 取用经验；领域专家审查每个 artifact。
这张图把整条流水线说清楚了：原始数据 D 进来，问题 q 进来，中间三个角色接力，每一棒交接的都是工作区里的可执行 artifact，而不是一段描述。最后吐出有依据的答案 R。
我挺喜欢这个设计的克制——不是搞三个独立模型各管一段，而是一个 ACA 配上不同的自然语言指令，去扮演不同角色。整个系统的定制几乎全部收敛到自然语言指令这一层，这其实是这篇论文最想证明的命题：一个建立在"执行"之上的架构，能靠改指令就泛化到整个数据智能工作流。
角色一：数据解释器，用"跑代码"代替"看数据"
数据解释器干的活，是把异构的原始数据 D = {d₁,…,dₙ} 转成一份结构化的"解释" P。形式化写作 \(\mathcal{I}: (D, M^*) \to P\)。
关键在于它怎么得到 P。不是让 LLM 瞄一眼数据然后用自然语言描述"这看起来像个订单表",而是让 ACA 完全通过执行 profiling 代码把 P 推出来。
P 里记了这些东西：
- 每个数据源的推断 schema（列名 + 语义类型）
- 每列的值分布、空值统计、模式观察
- 候选的主键和外键
- 跨数据源可能的 join 路径
- 需要人工介入的数据质量问题
你看，这些全是跑出来的事实,不是猜出来的描述。"这列有 3% 空值"是 count 出来的，"这两张表能通过客户ID join"是试探过的。这就把开头说的那个"可执行→文本→可执行"的损耗给堵上了第一道口子。
角色二：Schema 创建器，先装数据再谈规范
Schema 创建器接过解释 P 和原始数据 D，物化并验证一个真正能用的关系型数据库：\(\mathcal{S}: (P, D, M^*) \to (\Sigma, \beta)\)。其中 Σ 是表结构、键约束、完整性约束的三元组，β 是把 Σ 实例化、把 D 的记录灌进去的物理表。
这里有个我觉得特别"工程老炮儿"的纪律：load-first-normalize-second（先加载后规范化）。
具体是这么干的：staging 表先把 D 的每一条记录原样吃进来，还带上 provenance 字段（来自哪个源文件、什么时候加载的）；然后 refined 表和视图才在上面做类型转换和结构规范。
为什么这么设计？因为如果你一边加载一边规范化，遇到脏数据就容易静默丢弃，最后行数对不上你还不知道丢哪了。先全量装进来，至少保证"东西都在",再慢慢收拾。做过 ETL 的应该对这个顺序深有体会。
配套的是四轴验证：
| 验证维度 | 检查什么 |
|---|---|
| 行数对账 | 源数据和 β 之间行数核对，确保没丢 |
| 列覆盖 | 每个源列都被保留，任何重命名都记录在案 |
| 键有效性 | 主键唯一、外键引用完整 |
| 加载完整性 | 装不进去的记录路由到每表的 reject buffer，而不是静默丢掉 |
最后它还会跑一组测试查询 τ，只有当数据装载成功、且 τ 里每个查询都按预期执行了，才接受这个 schema。同时产出一份 schema manifest 和一份验证报告，摆给专家看。
我特别认同 reject buffer 这个设计。静默丢数据是企业数据集成里最阴险的坑——你以为整合好了，其实丢了 5% 的记录，等业务方发现报表数字不对的时候，已经过了三个月。
角色三：查询生成器，论文的主角
这是论文重点研究的对象。它把自然语言问题 q 翻译成已经执行过的 SQL：\(\mathcal{Q}: (q, \Sigma, \beta, M^*) \to y\)。分析型问题以只读模式访问 β，修改型任务则产出 DDL/DML。
它的工作流分四步，核心叫"execution-grounded（执行接地）":
第一步，形状声明（Shape declaration）。 在写任何 SQL 之前，ACA 先从问题 q 推导出期望的结果"形状" \(\kappa = (C_\kappa, g_\kappa, o_\kappa, f_\kappa)\)——分别是隐含的列、行粒度（每个实体一行？还是每组一行？还是每个时间桶一行？）、排序规范、过滤条件。这一步相当于先把"我要的答案应该长什么样"写下来，作为后面自我检查的标尺。
第二步，Schema 探索（Schema exploration）。 ACA 对 Σ 和 β 跑一些轻量探针查询——确认 join key 真的存在、采样几个代表性的列值看看格式、验证基数假设。注意这步的精髓：它不光看列名瞎猜，而是真的去库里探一探。 列名叫 customer_id 不代表它就是干净的客户ID，跑一下才知道。
第三步，生成与执行（Generation and execution）。 基于问题、schema、检索到的记忆、声明的形状，产出候选查询 \(y = \mathcal{G}(q, \Sigma, M^*, \kappa)\)，执行得到结果 \(R = \text{exec}(y, \beta)\)。
第四步，自我验证（Self-verification）。 这步是灵魂。Agent 绝不把第一条查询当最终答案。它用第一步声明的形状 κ 来检查结果：
逐个分量对着 \(C_\kappa, g_\kappa, o_\kappa, f_\kappa\) 核对。注意——这个检查是 Agent 自己算出来的，由执行结果得出，没有外部验证器，也没有人来打分。一旦 \(V(R,\kappa)=0\)，它就诊断哪里对不上、改写 y、在同一轮里重新执行，确认没问题了才把答案发出去。
整个流程跟任务类别和 SQL 方言无关，只有 κ 的语法在不同任务间变一变。这就是为什么它能用一套架构横扫四种方言、四类任务——变的只是自然语言指令和 κ 的形状。
🧠 共享记忆：Agent 自己写笔记，但用之前先验真
记忆这块设计得挺有意思，我觉得是这篇论文除了"执行接地"之外第二个值钱的地方。
它的记忆是基于 artifact 的。因为 ACA 在沙箱里干活，它往前携带的不是"我之前学到了什么"这种文本摘要，而是它真正产出并验证过的具体 artifact——schema、加载脚本、验证报告、查询日志、之前的解法。
记忆分两个层面、三个层级：
任务内：每个 Agent 在工作区 W 里前一个 Agent 留下的 artifact 上接着干，自然衔接。
跨任务：经验存储 M 保留一个可复用子集，分三级，刚好对应人类记忆的层次：
- 检索到的示例（情节性记忆）：为当前问题浮现的相似历史"问题-解法"对
- 会话教训（session lessons）：在当前这个数据库上确认过的条件规则
- 跨会话教训（cross-session lessons）：那些能跨数据库泛化的规则，作为长期的语义记忆
这里有两个我觉得设计得很克制的点：
第一，pull-based 且用前验证。 记忆条目只通过引用浮现，Agent 觉得相关才去读正文。更关键的是——任何答案在 live probe 确认它的前提条件在当前数据上还成立之前，绝不会被改变。也就是说，过时的经验会被执行当场抓住，而不是被传播下去。这一招很重要，因为记忆系统最大的风险就是"上次对的这次不一定对",它用执行把这个风险摁住了。
第二，整套机制是 training-free 的。 Agent 回答完会反思、记录带证据的条件规则，更新存储 \(M \leftarrow w(M, a, o)\)（a 是产出的 artifact，o 是观察到的结果）。函数 w 只在 o 支持的时候才接纳跨会话教训——没有学习型裁判，也没有人工裁判。整个记忆的形成和筛选全靠执行证据。
举个论文里的真实例子（california_schools 数据集）：Agent 想通过一个一对多 join 来统计学校数量，发现 COUNT(*) 对某个学校返回了 9,977（这是 join 之后的事实行数），而 COUNT(DISTINCT CDSCode) 返回 1。由此它蒸馏出一条规则：通过重复 join 统计实体时，该用 COUNT(DISTINCT pk) 而不是 COUNT(*)。
这个例子特别接地气。任何写过 SQL 的人都踩过这个坑，而 DIA 是自己踩了一次、记下来、下次不踩。重点是这条规则不是人教的，是它从自己的执行观察里蒸出来的。
🧪 实验：七个 benchmark，全自主，无微调
实验设置
先把家底亮一下，这个评测规模不小，共 4,187 个实例：
| Benchmark | 实例数 | DBs | 方言 | 任务类别 | 主指标 |
|---|---|---|---|---|---|
| BIRD-Dev | 1,534 | 11 | SQLite | 生成 | EX |
| BIRD-Critic | 500 | 15 | SQLite | 调试 | EX |
| LiveSQLBench | 600 | 22 | PostgreSQL | 生成 | EX |
| BIRD-Interact | 600 | 22 | PostgreSQL | 对话式 | SR |
| Spider2-Lite | 342 | 88 | SQLite, Snowflake | 生成 | EX |
| Spider2-Snow | 547 | 152 | Snowflake | 生成 | EX |
| Spider2-DBT | 64 | 64 | DuckDB | 项目完成 | DM |
四类任务（生成、调试、对话式交互、dbt 项目完成）、四种方言（SQLite、PostgreSQL、Snowflake、DuckDB）、三种指标（EX 执行准确率、SR 任务成功率、DM 数据库匹配）。
配置上有个细节值得说：ACA 用的是 OpenHands（由 Claude Sonnet 4.5 驱动，没有微调），BIRD-Interact 对话协议里用户模拟器是 o3。每个 benchmark 的定制只限于"一个常驻 seed 文件 + 逐问题的 prompt 脚手架",全程全自主、无人工干预。
我得给这个设置点个赞——用的是没微调的现成模型，定制限制在指令层，这才能支撑它"靠改自然语言就能泛化"的核心主张。如果偷偷给每个 benchmark 微调了模型，那这篇论文的结论就站不住了。
主表：七个 benchmark 的逐一对比
| Benchmark | 系统 | 得分(%) |
|---|---|---|
| BIRD-Dev | Agentar-Scale-SQL | 74.9 |
| CHASE-SQL | 74.9 | |
| DIA | 77.7 | |
| MARS-SQL | 77.8 | |
| BIRD-Critic | Claude Opus 4.6 | 46.2 |
| BIRD-Talon-14B | 48.0 | |
| Gemini 3.1 Pro Preview | 48.8 | |
| DIA | 64.2 | |
| LiveSQLBench | OpenHands + Kimi 2.5 | 32.2 |
| OpenHands + Claude Sonnet 4.5 | 35.2 | |
| OpenHands + Claude Opus 4.6 | 38.0 | |
| DIA | 50.7 | |
| BIRD-Interact | Claude Opus 4.6 | 17.5 |
| MERIT + Claude Opus 4.6 | 20.8 | |
| MERIT + GPT-5.4 | 22.7 | |
| DIA | 55.7 | |
| Spider2-Lite | DSR-SQL | 46.8 |
| AutoLink + DeepSeek-R1 | 52.3 | |
| ReFoRCE + o3 | 55.2 | |
| DIA | 71.3 | |
| Spider2-Snow | APEX-SQL | 53.0 |
| ReFoRCE + o3 | 62.9 | |
| DSR-SQL + DeepSeek-R1 | 63.8 | |
| DIA | 69.5 | |
| Spider2-DBT | Spider-Agent + o1-preview | 13.2 |
| Spider-Agent + Claude 3.7 Sonnet | 14.7 | |
| Spider-Agent-DBT + GPT-5.4 | 35.3 | |
| DIA | 37.5 |
领先幅度从大到小排一下：BIRD-Interact 领先 33.0 分（最猛）、Spider2-Lite 领先 16.1 分、BIRD-Critic 领先 15.4 分、LiveSQLBench 领先 12.7 分、Spider2-Snow 领先 5.7 分、Spider2-DBT 领先 2.2 分，BIRD-Dev 基本持平（77.7 对 MARS-SQL 的 77.8）。
有个很值得玩味的现象：优势最小的 BIRD-Dev，恰恰是最饱和的 benchmark——全场系统都挤在一个百分点内。这其实说明 DIA 的价值不在"再刷高一个已经卷烂的榜",而在那些需要探索、需要多轮、需要把数据真正摸清楚的硬任务上。
关键发现一：结构化任务反而更容易
类别拆解里有个一致的模式，我觉得挺反直觉的：那些看起来更"重"的修改类任务，得分反而更高。
- BIRD-Critic 里 Management 切片拿 78.7 分，而 query 切片只有 64.4
- LiveSQLBench 里 Modification 拿 66.3，而 query 只有 43.4
为什么？论文的解释是：修改任务奖励 Agent "先声明目标对象、再通过执行验证"的习惯。换句话说，修改任务天然逼着它把"我要改什么、改完该是什么样"讲清楚，而这正好契合 DIA 那套"先声明形状再执行验证"的工作流。这个解释我是买账的——它的方法论本来就偏好"目标明确、能验证"的任务。
关键发现二：高层抽象问题最难啃
另一个一致模式，是高层（high-level）问题最难。这类问题往往甩给你一个复合指标的名字，却不给公式：
- LiveSQLBench：高层问题 41.6 分 vs 非高层 58.9，掉了约 17 分
- BIRD-Interact：高层 47.6 vs 低层 63.1
道理也好懂——当用户问"给我算个客户健康度"却不告诉你健康度怎么定义时，Agent 要么自己分解这个指标（容易猜错），要么主动反问。这其实暴露了执行接地的天花板：执行能验证"语法对不对、形状对不对",但验证不了"我对意图的理解对不对"。
关键发现三：BIRD-Interact 那 33 分是怎么来的
回到开头那个让我怀疑的 33 分。拆开看就明白了——它是两阶段任务：
- Phase 1 是瓶颈，通过率 64.2
- Phase 2 的条件通过率高达 86.8——也就是说，一旦 Phase 1 那个正确查询落了地，后面的追问几乎都能答对
Phase 2 的五种追问类型还有进一步拆解：聚合类（120 个）条件通过率 95.9%（最容易，纯机械变换）；基于结果的追问（266 个）条件通过率 82.4（最难，因为依赖第一个答案返回的具体值）；话题转向（51 个）无条件得分最高 68.6（因为它更像是在已经探索过的库上问一个全新问题）。
所以这 33 分的领先，本质来自 DIA 在第一步把数据摸透之后，后续多轮交互几乎是顺水推舟。这恰好印证了前面那个判断：它的护城河是"探索 + 记忆 + 执行验证",而不是单点的 SQL 生成能力。这个领先是真实的，但你得理解它强在哪——强在交互式、需要积累上下文的场景。
错误分析：失败的几乎都是"语义错"
这块我觉得是全文最诚实、也最有信息量的部分。
几乎每个失败实例都跑到了完成、返回了一个错误答案，而不是执行崩溃。换句话说，剩下的错误压倒性地是语义错误，不是语法错误。Agent 干干净净地执行了一个查询，只是回答了一个"微妙不同"的问题。
论文把递归错误分成三类：推理（reasoning）、输出约定（output convention）、接地（grounding），其中推理错误最频繁——最常见的是在欠规约的请求上用错了 join、filter 或公式。
这跟前面"高层问题最难"是一回事的两面。说到底，执行接地这套机制有个绕不过去的死角：当 Agent 误读了意图，它生成的查询和它的自我检查会继承同一个误读——它拿着自己脑补的标尺去量自己脑补的答案，自然量得"对"。错误就这么悄悄溜过去了。论文自己也坦白了这点，我觉得很加分。
💡 我的判断
先说优点。这篇论文最值钱的不是七个 SOTA——SOTA 这东西半年就被刷掉了。它真正立得住的是那个范式主张：把 ACA 当一等抽象，让 Agent 之间传递可执行 artifact 而非文本，用执行来接地、用执行来验证、用执行来筛选记忆。这套思路把"LLM 会幻觉"这个老问题，转化成了"凡是说的都得能跑、跑出来还得对得上声明的形状"。幻觉没消失，但被执行这道闸门拦住了一大半。
我尤其欣赏三个工程细节：load-first-normalize-second 的纪律、reject buffer 不静默丢数据、记忆"用前必须 live probe 验真"。这些都是真在生产里摔过跟头的人才会有的设计，不是实验室里拍脑袋想出来的。论文也提到 DIA 已经在为企业客户做生产部署，这点可信度就上来了。
再说我的保留意见。
第一，评测范围有意收窄了，这点论文自己也承认——三个 Agent 只深入评测了查询生成器一个，数据解释器和 Schema 创建器没有 benchmark；只测了单一 LLM，没做跨模型敏感性；对话任务用的是 o3 模拟用户而非真人；记忆只做了定性考察。所以这篇论文严格说是"查询生成器的实证 + 另两个 Agent 的系统描述",标题的野心比实证范围大。
第二，成本是真不低。每个问题都要走生成-执行-验证的迭代循环，对话任务还要多轮交互，每个问题平均耗时从不到一分钟到约十分钟。这是典型的"拿算力换可靠性"。在离线批处理、高价值分析场景下这笔账划算，但要做低延迟的交互式 BI，十分钟一个问题就不太能接受了。
第三，前面反复说的那个语义验证的天花板——执行能保证形状对，保证不了意图对。在用户表达欠规约的真实企业场景里，这恐怕是比 benchmark 里更突出的问题。
🔧 对工程的启发
如果你也在做数据平台、Agent 系统或者 text-to-SQL，这篇论文有几个可以直接借鉴的点：
- 能用执行验证的，就别用文本描述传递。 这是整篇论文的方法论内核，迁移性很强——不止 SQL，任何"生成-检查"的 Agent 任务都适用。
- 让 Agent 先声明期望的输出形状，再拿结果对照。 这个"先立标尺再答题"的小动作，比事后让另一个模型来评判要稳得多，而且零额外训练成本。
- 记忆系统一定要做"用前验证"。 别把历史经验当成永远正确的真理，每次用之前去当前环境探一下，让执行来判断它还成不成立。
- 数据加载坚持先全量后规范、脏数据进 reject buffer。 这是老 ETL 智慧，但太多新系统忘了。
这类"执行接地 + artifact 化记忆"的架构，我个人觉得很可能会成为未来企业数据 Agent 的标配——毕竟在企业场景里，能跑、能验、能审计，比模型本身聪明几个点重要得多。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我