HarnessSQL：训练时从没见过执行环境，部署时却要和数据库对话——训练-部署失配怎么补

一个被忽视的断裂

你训练了一个 Text-to-SQL 模型。训练数据是"问题 + schema → SQL 查询"的配对。模型在 Spider 基准上表现不错，准确率 15%。

然后你把它部署到真实环境。用户问"上季度销售额超过 10 万的客户有哪些"，模型生成了一条 SQL。但真实数据库的 schema 和训练时看到的不完全一样——有些表名是缩写，有些列名有歧义，有些 JOIN 路径不是最短的。模型生成的 SQL 报错了。

在传统范式里，这就完蛋了——模型只学过"生成 SQL"，没学过"SQL 报错了怎么办"。但在真实场景里，一个数据库代理应该能：执行探针查询看看 schema 长什么样、发现报错后诊断原因、修正 SQL、重新提交。

这就是 HarnessSQL 论文要解决的训练-部署失配问题：模型在训练时只见过"一次性生成 SQL"的模式，但部署时需要在有状态的多轮交互中和数据库对话。

三层失配

论文把这个问题拆得很清楚，失配发生在三个层面：

1. 环境失配。 训练时的数据库是静态的 schema 描述，部署时的数据库是活的——有运行时状态、有实际数据分布、有特定 JOIN 路径。模型从没在训练中"碰过"真实数据库。

2. Harness 失配。 "Harness"是代理和数据库之间的交互协议——代理能执行什么操作、能收到什么反馈、什么时候能提交最终答案。训练时没有这个 harness，部署时突然就有了。就像一个人从没学过开车，但你把他扔进一辆有方向盘、油门、刹车的车里，告诉他"这些工具你用着用着就会了"。

3. 监督失配。 训练时的监督信号是"最终 SQL 对不对"，但部署时代理需要学习的是"整条交互轨迹对不对"——包括什么时候该探针、什么时候该修正、什么时候该提交。

HarnessSQL 的解法

HarnessSQL 的核心思路是：训练时就让模型在 harness 里玩。

具体做法分三步：

第一步：构建可执行沙箱。 对每个目标数据库，从真实引擎中提取运行时 schema、样本列值、有效 JOIN 路径。不是静态描述，是活的数据库环境。79 个数据库，每个都配了隐藏的执行 oracle（标准答案）。

第二步：四工具 SQL harness。 定义一个最小的交互协议——代理只能通过四个工具和数据库交互。教师模型在这个 harness 里跑轨迹，只有通过 denotational verification（执行结果正确）和 protocol check（交互格式合规）的轨迹才保留。最终拿到 2512 条验证过的轨迹。

第三步：全轨迹 SFT + 执行奖励 RL。 用验证过的轨迹做 full-sequence SFT（不是只学最终 SQL，是学整条交互过程），然后做 execution-reward RL（执行结果作为奖励信号）。

数字说话

效果非常显著：

更关键的是跨基准迁移：在 BIRD-Interact Mini 和 LiveSQLBench 这两个训练时没见过的交互式基准上，HarnessSQL 训练的模型也表现不错。这说明模型学到的不是"记住某个数据库"，而是"和数据库交互"的通用能力。

对比之下，专门的 SQL 模型如 OmniSQL-32B（13.3%）和 Arctic-Text2SQL-32B（14.8%）在 Spider 2.0-SQLite 上只有 13-15%，远低于 HarnessSQL 训练的 8B 模型。参数量多 4 倍，准确率只有三分之一。

为什么这件事重要

1. 训练-部署失配是 Agent 的普遍问题。 HarnessSQL 解决的是 SQL 领域的问题，但这个模式到处都是：代码生成模型训练时见的是"问题描述→代码"，部署时需要"读报错→改代码→再跑"；工具使用模型训练时见的是"任务→工具调用"，部署时需要"调用失败→换参数→重试"。任何 Agent 都有"训练时静态、部署时动态"的断裂。

2. Harness-native 训练比 Agent 框架更底层。 现在很多人在 Agent 框架层做补偿——给模型加 ReAct prompt、加 reflection 机制、加 retry 逻辑。HarnessSQL 的思路是：与其在推理时补偿，不如在训练时就让模型在 harness 里学习。这是从"框架层补能力"到"训练层建能力"的转变。

3. 四工具协议的极简主义。 HarnessSQL 只用四个工具就定义了完整的数据库交互协议。这和 Unix 哲学一样——少而精的接口比多而杂的接口更好。四工具协议是 SQL 交互的"窄腰"（narrow waist），所有复杂交互都建立在这个最小契约之上。

一个类比

传统 Text-to-SQL 训练就像教人写求职信——给你看一堆"职位描述→求职信"的范例，你学会了模式匹配。但真实找工作不是一次性写求职信就完了——你要先看公司官网、查 LinkedIn、了解业务、写信、等回复、可能还要改。HarnessSQL 训练的是整个求职流程，不只是写信那一步。

诚实评价

数据规模。 79 个数据库、2512 条轨迹，对于训练一个通用数据库代理来说，规模还偏小。真实世界的数据库场景远比这复杂——多表 JOIN、窗口函数、CTE 嵌套、存储过程。HarnessSQL 的四工具协议能否覆盖这些复杂场景，需要更多实验验证。

SQLite 限制。 主实验都在 SQLite 上做。SQLite 是单文件嵌入式数据库，和 PostgreSQL/MySQL 这种服务端数据库的交互模式有差异。HarnessSQL 的方法能否迁移到更复杂的数据库引擎，论文没有充分验证。

教师依赖。 轨迹由教师模型生成，教师模型的能力上限决定了学生模型的天花板。如果教师本身不擅长某种复杂查询，学生也学不到。

但作为一个"训练-部署失配"问题的概念验证，HarnessSQL 足够有说服力。它指向一个正在形成的范式：Agent 训练不再是"输入→输出"的映射学习，而是"在环境中交互"的轨迹学习。

论文：HarnessSQL: Harness-Native Training for SQL Agents in Realistic Database Environments

代码：YangHaolin0526/HarnessSQL

相关基准：

• bird-bench/livesqlbench（LiveSQLBench）
• Spider 2.0