8B逆袭32B！开源首个长程交互SQL Agent框架，面向真实数据库
新智元报道 在企业级真实业务与复杂数据分析中，让大模型「一眼看穿数据库并写出完美SQL」，往往只是一个不切实际的幻想。传统的Text-to-SQL大多将其简化为单轮文本生成：给定问题和静态Schema，让模型一步生成最终SQL。但现实数据库动辄包含上百张表、数千字段与百万级数据，资深分析师绝不会「单轮盲猜」，而是在CL
新智元报道
新智元报道
在企业级真实业务与复杂数据分析中，让大模型「一眼看穿数据库并写出完美SQL」，往往只是一个不切实际的幻想。
传统的Text-to-SQL大多将其简化为单轮文本生成：给定问题和静态Schema，让模型一步生成最终SQL。但现实数据库动辄包含上百张表、数千字段与百万级数据，资深分析师绝不会「单轮盲猜」，而是在CLI或IDE 中执行 `SHOW TABLES`、探查表结构（DDL）、跑试探性查询（Probe Query），并根据报错反复修正逻辑后才提交代码。
在Spider2.0、BIRD-Interact和LiveSQLBench等长程交互基准上，传统静态微调模型纷纷暴露致命短板：训练时只学会「直接写终点答案」，部署到交互环境（Harness）后却缺乏探索试错、状态追踪与错误恢复能力，极易陷入死循环或因报错崩溃——即「训练与部署脱节」（Train–Deploy Mismatch）。
针对这一瓶颈，港科大与微软等团队推出了首个原生长程环境交互训练框架HarnessSQL，在密闭沙盒与专用SQL Harness中进行长程轨迹监督微调（SFT）与执行奖励强化学习（RL）。
在Spider 2.0-SQLite 上，HarnessSQL仅凭8B参数即斩获45.2%执行准确率（近基线3倍），大幅超越32B专用模型（OmniSQL 14.8%、Arctic-Text2SQL 16.3%）与多智能体系统（MARS-SQL 12.6%），14B模型更达54.8%！
论文链接：https://arxiv.org/abs/2610.12274
开源代码：https://github.com/YangHaolin0526/HarnessSQL
图1：从单轮Text-to-SQL到具备沙盒与专用Harness的交互式数据库Agent演进。
交互式Text-to-SQL可形式化为由执行环境契约（Execution Harness）POMDP）。任务实例定义为四元组 x = (q, D, h, v)，分别对应自然语言指令q、底层数据库D、执行Harness h与隐藏真实验证器（ExecutionOracle）v。
在第t ∈ [1, T]轮交互中，智能体根据环境观测o_t∈O，由策略π_θ生成推理与工具调用行动a_t∈A，完整轨迹表述为：
其中y为终止步提交的最终SQL，任务成败由联合奖励函数评估：
其中，
R_result(y, v)∈{0, 1}：在真实数据库D上比对候选产物y与标准答案v的执行结果集外延等价性，打破表层字符匹配局限；
R_protocol(τ, h)∈{0, 1}：校验轨迹是否遵守Harness契约（只读权限、语法合规、无死循环且在T步内显式提交）。
然而，现有后训练框架大多仍停留在传统的静态监督损失：
这种静态训练模式导致了三重核心脱节：
1.抹杀中间探索状态：只将最终SQL作为目标，忽略了中间探测表结构与验证假设的交互过程；
2.面对执行反馈盲目：训练时从未见过运行报错或空结果集，推理时一旦遇到报错极易崩溃；
3.缺乏动作边界约束：模型不理解数据库CLI的权限边界与终止协议，易产生工具格式幻觉。
为打破上述脱节，HarnessSQL构建了三大基石：高保真密闭执行沙盒、极简SQL Harness契约，以及两阶段长程后训练流水线。
1.密闭SQL执行沙盒与蓝图合成
团队基于Spider 2.0-Lite（30个SQLite）与Spider 2.0-DBT（49个DuckDB，零损迁移至SQLite）构建了79个复杂数据库沙盒，并采用SQL-First蓝图合成法：先从活动引擎提取Schema、样本值与外键路径，采样出难度可控的可执行SQL，再反向生成自然语言问题与验证Oracle。
沙盒具备只读绑定、单语句约束与60秒超时保护，并通过语法、非空与语义变异测试（Mutation Tests）保障数据质量。
2. 专为SQL任务定制的极简Harness契约（DSH-SQL）
通用编程Agent的繁杂Bash工具易导致模型注意力涣散。HarnessSQL改造了DeepSeek-Harness（DSH），提炼出四元极简动作契约：
sql_list_tables：枚举数据库内所有数据表及各自的数据行数；
sql_schema：探查指定表的完整DDL定义、字段类型与真实采样数据；
sql_exec：试探性执行只读SQL查询，获取前排真实输出或运行时错误堆栈；
sql_submit：终极提交已验证正确的SQL产物并退出长程会话。
环境中间件同时内置三大护栏：确定性行数截断防止大输出撑爆上下文；循环调用警示器主动纠偏重复无效查询；压力触发上下文压缩确保长程探索保留核心事实。
3. 原生Harness两阶段后训练：SFT筑基+RL登顶
第一阶段：全轨迹长程SFT（冷启动）。利用教师模型在沙盒中自主探索，筛选通过Oracle验证的优质多轮轨迹（平均11.8Ktokens、16轮交互、14次真实执行）进行全序列监督：
关键机制：计算损失时，所有环境观测token（o_t）均被掩码忽略（Masked Out），仅在模型自身生成的推理、工具调用与最终提交上计算梯度，迫使模型学会根据环境反馈推演下一步行动。
第二阶段：执行奖励强化学习（自主进化）。为赋予模型应对未知数据库的试错能力，HarnessSQL采用动态解耦裁剪策略优化（DAPO）在沙盒中持续对齐，计算轨迹组标准化优势：
奖励信号完全依托隐藏Oracle的真实执行对比：结果等价且合规得1分，报错、超时或结果不符均得0分。不设任何人工中间奖励（Reward Shaping），倒逼模型探索出稳健的自纠错策略。
图2：HarnessSQL整体架构流水线与沙盒交互轨迹示例。
团队在三大真实数据库基准上展开评测：域内长程交互基准Spider 2.0-SQLite、含用户模拟器的域外动态交互基准BIRD-Interact Mini，以及跨领域复杂推理基准LiveSQLBench Base-Lite SQLite。
对比基线涵盖执行准确率（Execution Accuracy）评估。
表1：三大基准上的执行准确率对比，粗体为最优，下划线为次优。
实验呈现出三大核心结果：
1. 8B小模型全面反超32B模型：在Spider 2.0-SQLite上，HarnessSQL-8B达到45.2%，较同底座基线（15.5%）提升近3倍，大幅超越OmniSQL-32B（14.8%）、Arctic-Text2SQL-32B（16.3%）和Qwen2.5-Coder-32B（16.3%）。
2. 14B模型逼近55%大关：扩展至Qwen3-14B后，执行准确率进一步攀升至54.8%，验证了原生Harness训练出色的规模扩展性。
3. 强劲的域外泛化能力：在未见过的BIRD-Interact Mini与LiveSQLBench上，HarnessSQL同样遥遥领先。其中在LiveSQLBench上，8B（24.8%）与14B（28.5%）达到所有32B基线（7.0%–8.9%）的3～4倍，证明模型习得了通用探索策略而非机械记忆Schema。
面对交互环境任务，该直接做强化学习（Direct RL）还是先做轨迹微调（SFT）？受控实验给出了清晰对比：
冷启动直接RL提升有限：8B基座直接跑RL仅从15.5%微升至20.0%（+4.5%）。缺乏交互先验时，稀疏二值奖励难以在长轨迹中有效分配信用。
全轨迹SFT奠定交互基础：经验证轨迹SFT后，8B和14B分别跃升至30.4%（+14.9%）与37.8%（+15.6%），快速掌握了工具调用与报错纠偏规范。
SFT+RL实现性能质变：在SFT基础上引入DAPO强化学习，8B再涨14.8%达45.2%，14B再涨17.0%达54.8%（增益达直接RL的3倍以上）。这确立了长程Agent的黄金范式：SFT赋予交互框架与探索常识，RL释放未知环境下的自适应寻优潜能。
围绕长程Agent训练的关键设计选择，消融实验提炼出四项核心发现：
启示一：训练与推理接口的强对齐（Training-Inference Alignment）
若推理采用DSH-SQL交互环境，但训练使用非交互式（Non-harness）SFT数据，Spider2.0准确率仅9.6%，甚至低于未微调基座（15.5%）；而原生HarnessSFT达30.4%。这证明：静态训练会破坏模型与动态环境的协作，训练与部署环境必须严格同构。
非交互式与原生Harness训练和推理在域内及域外基准上的交叉消融对比。
启示二：全序列轨迹组织显著优于单步拆解（Full-Trajectory>Turn-Split）
构建SFT数据时，保留完整轨迹上下文的全序列监督（Full-trajectory）在三大基准上全面优于单步拆解（Turn-split）。长程任务高度依赖前后多轮的因果脉络，拆碎样本会割裂全局决策连贯性。
图3：全轨迹监督（Full-trajectory）显著优于单步拆解监督（Turn-split）。
启示三：超长上下文容量是长程探索的生命线（8K->16K->32K）
真实数据库探查伴随密集Schema与中间结果反馈，轨迹动辄上万tokens。当训练与推理上下文从8K扩展至16K和32K时，Spider2.0准确率从27.4%跃升至45.2%——截断早期历史等同于剥夺模型的复盘与溯源记忆。
图4：上下文窗口长度对执行准确率的影响，32K上下文带来显著提升。
启示四：DAPO算法更加契合稀疏奖励下的长程策略优化
在相同预算与沙盒下对比GRPO（40.7%）、GSPO（43.7%）与DAPO（45.2%），DAPO表现最优。其动态过滤零方差轨迹组、解耦裁剪范围与全批次token归一化机制，有效缓解了稀疏奖励下的策略震荡。
团队也客观指出了当前系统的演进方向：
1.跨数据库方言扩展：从当前的SQLite生态进一步拓展至Snowflake、BigQuery、PostgreSQL等企业级云原生方言，构建更完善的权限隔离与生态适配。
2.多模态与多元分析工具：除命令行查询外，进一步融合可视化图表、文档报告与交互式BI仪表盘等多元分析环境。
大模型正加速从「对话助手」走向「自主执行智能体」。HarnessSQL证明：面对需要工具调用与试错反馈的复杂任务，仅灌输静态「正确答案」远远不够，必须将交互环境（Harness）纳入核心训练闭环，让模型在动态环境中原生习得长程探索与容错能力。
目前，HarnessSQL的代码、沙盒环境与合成轨迹资产已全部在GitHub开源，为Text-to-SQL、数据库智能体与通用Agent研发提供了可直接复用的标杆参考。
参考资料：
https://arxiv.org/abs/2610.12274
