港科大与微软等团队发布了面向真实数据库的长程交互式 SQL Agent 训练框架 HarnessSQL，并同步开源论文与代码。该工作瞄准企业级真实业务中的 Text-to-SQL 难题：面对包含上百张表、数千字段和百万级数据的数据库，模型很难靠单轮生成一次写出可执行且正确的 SQL。
论文显示，传统 Text-to-SQL 方法通常把任务简化为「给定问题和静态 Schema，直接生成最终 SQL」。但在真实环境里，分析师往往会先执行 `SHOW TABLES`、查看表结构定义（DDL）、运行试探性查询，再根据报错和结果反复修正逻辑，最后才提交代码。研究团队认为，现有静态微调模型在 Spider2.0、BIRD-Interact 和 LiveSQLBench 等长程交互基准上暴露出的核心问题，是训练时只学会直接输出答案，部署到交互环境后却缺少探索试错、状态追踪和错误恢复能力，形成「训练与部署脱节」。
把交互式 Text-to-SQL 形式化为 POMDP
论文将交互式 Text-to-SQL 任务形式化为由执行环境契约调解的部分可观测马尔可夫决策过程（POMDP）。一个任务实例被定义为四元组 x = (q, D, h, v)，分别对应自然语言指令 q、底层数据库 D、执行 Harness h，以及隐藏的真实验证器 ExecutionOracle v。
在第 t ∈ [1, T] 轮交互中，智能体根据环境观测 o_t∈O，通过策略 π_θ 生成推理与工具调用动作 a_t∈A，最终在终止步提交 SQL 结果 y。任务成败由联合奖励函数评估，其中 R_result(y, v)∈{0, 1} 用于比较候选结果与标准答案在真实数据库 D 上的执行结果集是否外延等价，R_protocol(τ, h)∈{0, 1} 用于检查轨迹是否遵守 Harness 契约，包括只读权限、语法合规、无死循环以及在 T 步内显式提交。
研究团队指出，现有后训练框架大多仍采用传统静态监督损失，只把最终 SQL 当作目标。这会带来三类问题：中间探索状态被抹去，训练阶段看不到执行报错或空结果集，模型也不理解数据库 CLI 的权限边界与终止协议，推理时容易出现工具格式幻觉、死循环或直接崩溃。
HarnessSQL 的三项核心设计
为解决上述问题，HarnessSQL 采用了高保真密闭执行沙盒、极简 SQL Harness 契约，以及两阶段长程后训练流水线。
79 个复杂数据库沙盒
团队基于 Spider 2.0-Lite 的 30 个 SQLite 数据库和 Spider 2.0-DBT 的 49 个 DuckDB 数据库构建了 79 个复杂数据库沙盒，后者被零损迁移至 SQLite。数据构造采用 SQL-First 蓝图合成法：先从活动引擎提取 Schema、样本值和外键路径，采样出难度可控的可执行 SQL，再反向生成自然语言问题与验证 Oracle。
这些沙盒具备只读绑定、单语句约束和 60 秒超时保护，并通过语法、非空和语义变异测试来保证数据质量。
四元极简动作契约
在工具设计上，团队没有沿用通用编程 Agent 常见的复杂 Bash 工具，而是基于 DeepSeek-Harness（DSH）提炼出专为 SQL 任务设计的 DSH-SQL 契约，包含四个动作：
- sql_list_tables：列出数据库中的全部数据表及各自数据行数；
- sql_schema：查看指定表的完整 DDL、字段类型和真实采样数据；
- sql_exec：执行只读 SQL 试探查询，返回前排真实输出或运行时报错堆栈；
- sql_submit：提交最终 SQL 并结束长程会话。
环境中间件还加入了三项护栏：确定性行数截断，用于防止大输出撑满上下文；循环调用警示器，用于纠偏重复无效查询；压力触发上下文压缩，用于在长程探索中保留核心事实。
两阶段后训练：SFT 加 RL
HarnessSQL 的训练分为两个阶段。第一阶段是全轨迹长程监督微调（SFT）冷启动。教师模型先在沙盒中自主探索，再筛选通过 Oracle 验证的高质量多轮轨迹用于监督训练。论文给出的平均轨迹规模为 11.8K tokens、16 轮交互、14 次真实执行。
在损失计算上，所有环境观测 token 都会被掩码忽略，只在模型自身生成的推理、工具调用和最终提交上计算梯度。团队认为，这样可以迫使模型根据环境反馈决定下一步动作，而不是机械模仿静态答案。
第二阶段是执行奖励强化学习。HarnessSQL 采用动态解耦裁剪策略优化（DAPO）在沙盒中持续对齐，奖励完全依赖隐藏 Oracle 的真实执行对比：结果等价且合规得 1 分，报错、超时或结果不符得 0 分。论文没有设置人工中间奖励，目标是让模型自行学会稳健的纠错策略。
三大基准上的结果
团队在 Spider 2.0-SQLite、BIRD-Interact Mini 和 LiveSQLBench Base-Lite SQLite 三个真实数据库基准上进行了评测。对比对象包括通识编程模型 Qwen2.5-Coder-32B、SQL 专用模型 OmniSQL 7B/32B、Arctic-Text2SQL 7B/32B，以及多智能体系统 MARS-SQL 3×7B，统一使用执行准确率（Execution Accuracy）作为指标。
在 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%，以及多智能体系统 MARS-SQL 的 12.6%。扩展到 Qwen3-14B 后，执行准确率进一步升至 54.8%。
在域外泛化测试中，HarnessSQL 也保持领先。论文提到，在 LiveSQLBench 上，8B 版本达到 24.8%，14B 版本达到 28.5%，而所有 32B 基线的区间为 7.0% 至 8.9%。团队据此认为，模型学到的是通用探索策略，而不是对 Schema 的机械记忆。
SFT 与 RL 的组合效果
论文还比较了直接强化学习与先做轨迹微调的差异。以 8B 基座为例，冷启动直接做 RL，准确率只从 15.5% 升到 20.0%，增幅为 4.5%。研究团队认为，在缺乏交互先验的情况下，稀疏的二值奖励很难在长轨迹中完成有效信用分配。
加入全轨迹 SFT 后，8B 和 14B 模型分别提升到 30.4% 和 37.8%，对应增幅为 14.9% 和 15.6%。在此基础上再叠加 DAPO 强化学习，8B 再提升 14.8% 至 45.2%，14B 再提升 17.0% 至 54.8%。论文将这一结果概括为长程 Agent 的训练范式：先用 SFT 建立交互框架和探索常识，再用 RL 释放模型在未知环境中的自适应优化能力。
四项消融实验结论
训练与推理接口必须强对齐
如果推理阶段使用 DSH-SQL 交互环境，但训练阶段使用非交互式 SFT 数据，Spider2.0 上的准确率只有 9.6%，甚至低于未微调基座的 15.5%；而原生 Harness SFT 可以达到 30.4%。论文据此指出，静态训练会破坏模型与动态环境的协作，训练与部署环境需要严格同构。
全轨迹监督优于单步拆解
在 SFT 数据组织方式上，保留完整上下文的全轨迹监督在三大基准上都优于单步拆解监督。研究团队认为，长程任务依赖多轮交互之间的因果链条，拆分样本会削弱全局决策连贯性。
更长上下文窗口带来明显提升
真实数据库探查会产生大量 Schema 信息和中间结果反馈，轨迹长度经常达到上万 tokens。论文显示，当训练与推理上下文从 8K 扩展到 16K 和 32K 时，Spider2.0 上的准确率从 27.4% 提升至 45.2%。团队认为，过早截断历史信息，会直接削弱模型复盘和溯源的能力。
DAPO 在稀疏奖励下表现最好
在相同预算和沙盒条件下，DAPO 与 GRPO、GSPO 的对比结果分别为 45.2%、40.7% 和 43.7%。论文将 DAPO 的优势归因于动态过滤零方差轨迹组、解耦裁剪范围和全批次 token 归一化机制，这些设计缓解了稀疏奖励场景下的策略震荡。
后续扩展方向
团队在论文中提到两个后续方向。其一是跨数据库方言扩展，从当前的 SQLite 生态继续拓展到 Snowflake、BigQuery、PostgreSQL 等企业级云原生方言，并完善权限隔离与生态适配。其二是引入多模态和更多分析工具，把可视化图表、文档报告和交互式 BI 仪表盘纳入分析环境，而不只停留在命令行查询。
论文与代码已开源
论文认为，大模型正在从对话助手走向自主执行智能体。HarnessSQL 给出的结论是，面对需要工具调用和试错反馈的复杂任务，只训练静态「正确答案」并不够，交互环境本身需要进入训练闭环。
目前，HarnessSQL 的代码、沙盒环境和合成轨迹资产已经在 GitHub 开源。论文链接为 https://arxiv.org/abs/2610.12274，代码地址为 https://github.com/YangHaolin0526/HarnessSQL。
本文来自微信公众号「新智元」，作者为新智元，编辑为 LRST。
