简介：围绕数据应用开发框架在自然语言转SQL能力上的版本演进，本文对比LLM直评与Agent评测两种模式，分析多环境评测的差异、适用场景、接入成本与迁移注意事项，帮助开发者、技术负责人及企业用户在构建或改造Text2SQL能力时形成更清晰的选型判断。
在AI原生数据应用开发中，自然语言转SQL，即Text2SQL，已经从早期的实验能力逐步进入生产链路。随着基础模型能力提升，单纯“能不能生成SQL”不再是唯一关注点，团队更需要回答几个问题：生成结果是否稳定、是否可复现、是否能在不同数据环境中保持可用、是否适合直接接入Agent流程，以及出现问题时如何定位和优化。
围绕这些需求，评测体系的建设路径也出现分化。较早的评测方式通常以模型直接生成SQL并进行结果比对为主，执行链路短、易于搭建，但难以覆盖复杂任务。另一种方式把SQL生成放入Agent执行链中，由模型或规则模块完成规划、检索、生成、校验和修正，更接近真实系统行为，但成本更高、调试更复杂。
本文以数据应用开发框架的版本演进为线索，重点对比两种Text2SQL评测模式：基于模型的直接评测与基于Agent的评测，并扩展到单环境与多环境评测的差异。目的是帮助读者理解两类方式不是简单的新旧替代关系，而是在不同阶段、不同目标下形成的技术分叉。
这种模式把Text2SQL视为一个相对单一的生成任务。评测时输入自然语言问题、表结构信息或少量样本，模型输出SQL，随后与标准SQL或预期结果进行比对。评测关注点集中在生成准确率、语法正确性、关键字段覆盖度等指标。
直接评测的优势在于链路短、易于复现。它适合作为模型选型阶段的基线测试，也适合在版本升级时快速验证基础能力是否回退。但其局限也较明显：缺乏对任务上下文的理解，难以评估模型在复杂问题、多表关联、模糊表达或需多次尝试时的表现。
Agent评测不再只考察单次生成能力，而是关注一个任务从理解到执行完成的整体表现。评测环境中通常包含任务规划、表结构检索、SQL生成、执行校验、错误修复等环节。系统可能多次调用模型，也可能引入工具调用、记忆或反馈机制。
这种模式更接近生产环境中的真实表现，能够反映模型在动态链路中的稳定性和纠错能力。评测指标也从单纯的SQL匹配，扩展到任务完成率、重试次数、修复成功率、步数消耗等维度。相应地，搭建和维护成本明显上升。
两种评测模式并非完全对立，它们共享若干基础逻辑。
首先，两者都依赖统一的评测数据集。数据集通常包括自然语言问题、数据库Schema、标准SQL或预期查询结果。评测目标都是衡量自然语言到SQL转换的语义准确性与执行可用性。
其次，两者都关注模型输出与目标结果之间的差异。即便Agent模式引入中间步骤，最终仍需判断SQL是否可执行、是否返回正确数据。直接评测中的核心指标在Agent评测中依然有效，只是评价方式更复合。
第三，两者都面临数据环境准备、指标口径统一和结果可复现问题。无论是简单模式还是复杂模式，评测集的版本管理、数据库实例初始化、结果记录和错误分类都是基础工作。否则不同评测之间缺乏可比性。
直接评测的执行链路通常为“输入问题—加载Schema—模型生成SQL—执行或比对—输出结果”。系统边界清晰，依赖组件较少，适合快速验证。
Agent评测链路则可能是“输入问题—任务规划—环境检索—SQL生成—执行校验—错误修正—最终输出”。链路中包含更多中间状态和决策节点，系统边界延伸到任务管理、工具调用和反馈处理。它更像一个微型数据应用系统，而非单纯生成器。
直接评测主要覆盖基础生成能力，包括单表查询、多表连接、条件过滤、聚合统计等。对于复杂语义、多步推理、模糊字段映射等场景，直接评测可能因为缺少必要上下文而低估模型能力。
Agent评测能够覆盖更完整的任务类型。例如当问题涉及多个数据源或需要先确认字段含义时，Agent可以先检索相关表结构，再生成SQL；当首次执行失败时，可以基于错误信息重新生成。评测深度更高，也更能暴露链路中的薄弱环节。
直接评测的误差来源相对集中，多半来自模型理解偏差或Schema信息不足。结果波动较小，容易定位问题。
Agent评测由于链路更长，同一任务可能因为规划路径不同、工具返回顺序变化或中间步骤误差累积，导致最终结果不同。稳定性不仅取决于生成模型，还受规划模块、检索模块、执行环境反馈等因素影响。分析误差需要分层追踪，定位成本更高。
直接评测的资源消耗主要集中在模型推理和数据库执行。任务量较小时，成本可控，适合频繁回归。
Agent评测可能对同一任务进行多次模型调用，并涉及工具调用、日志记录、中间结果存储等额外开销。如果包含错误修复循环，消耗会进一步上升。在评测集规模较大或需要高并发测试时，需要预先评估算力和时间成本。
直接评测通常只涉及数据库只读查询，权限模型较简单。但仍需注意，生成SQL可能包含不可预期操作，建议使用受限账号和只读实例。
Agent评测中，如果Agent具备执行或修复权限，安全要求会提高。需要明确模型能否访问元数据、能否执行SQL、能否修改会话状态等。多环境评测时，不同环境之间的数据隔离、账号隔离和审计记录也必须提前设计。
直接评测的运维重点在于数据集更新、指标统计和结果归档。由于链路短，日志追踪简单。
Agent评测则需要更完整的可观测性设计，包括每次任务执行的步骤记录、模型输入输出、工具调用结果、错误类型和修复过程。否则当某条用例失败时，很难判断是规划错误、生成错误还是执行环境问题。
| 对比维度 | 基于模型的直接评测 | 基于Agent的评测 |
|---|---|---|
| 执行链路 | 短，单次或少量调用 | 长，包含规划、检索、生成、校验、修复 |
| 评测目标 | 单次SQL生成质量 | 任务端到端完成能力 |
| 适用阶段 | 模型选型、基线回归 | 能力验收、生产模拟 |
| 评测深度 | 基础查询与语义匹配 | 复杂任务、错误修复、多步推理 |
| 资源消耗 | 相对较低 | 较高，多次调用与工具开销 |
| 稳定性 | 较稳定，误差来源集中 | 波动较大，误差来源分散 |
| 定位难度 | 易于定位 | 需分层追踪 |
| 安全要求 | 较低，只读受控环境即可 | 较高，需权限隔离与审计 |
| 维护成本 | 低 | 高，需维护Agent链路与可观测性 |
多环境评测的提出，意味着Text2SQL能力不再只在固定Schema和固定数据库上验证，而是需要跨数据库类型、跨Schema规模、跨方言语法进行测试。
单环境评测实现简单，结果易于复现，适合早期开发。但随着应用场景扩展，用户会面临不同数据库、不同命名规范、不同字段注释质量等问题。只在一个环境上表现良好的模型，切换到另一个环境后可能出现明显下降。
多环境评测的价值在于暴露模型对Schema变化的敏感度、对不同SQL方言的适应能力，以及在缺少完整注释时是否仍能生成合理查询。它也要求评测框架具备环境配置、结果汇总和跨环境对比能力。
此外，多环境评测不意味着简单的重复执行。不同环境可能带来不同错误模式，例如某些数据库对隐式类型转换更严格，某些环境缺少索引导致执行计划差异。评测结果分析需要结合环境特征，避免只比较准确率数值。
当团队处于模型选型阶段，目标是快速判断不同基础模型在Text2SQL上的基本水平时，直接评测更为高效。同样，在每次模型升级或提示词微调后，需要快速回归核心能力是否下降，也可以使用直接评测作为基线。
如果数据集结构清晰、字段注释完善、问题类型集中在标准查询，直接评测能提供足够可用的信号，开发和维护成本较低。
当Text2SQL需要嵌入到实际数据应用或智能问答系统中，用户问题多样，且无法保证Schema信息完整时，Agent评测更接近真实需求。尤其在需要根据中间结果修正SQL、从多个候选表中检索正确目标、或结合上下文进行多轮交互时，Agent评测能揭示直接评测无法覆盖的问题。
对于计划将Text2SQL能力产品化、需要评估上线风险的团队，建议在后期引入Agent评测作为验收手段。
当数据应用需要支持多种数据库或面向不同客户环境交付时，多环境评测应纳入常规流程。它特别适合数据库方言差异较大、元数据管理不规范或需要跨团队协作的场景。
如果暂时只服务单一业务线和固定数据库，可以先从单环境入手，但建议在评测框架设计时预留多环境扩展能力，避免后期重构。
选型时不应将直接评测与Agent评测视为二选一的对立关系。更合理的做法是分阶段组合使用。
在早期开发与模型筛选阶段，优先使用直接评测，以低成本获得稳定、可复现的基线。当基线能力满足基本要求后，再引入Agent评测进行深度验证。对于核心场景，可以使用Agent评测作为发布门禁，直接评测作为日常回归。
多环境评测的引入时机取决于业务是否需要跨数据库交付。如果需求明确，建议在评测集建设初期就纳入环境维度，而不是事后补充，否则数据集组织、指标统计和结果对比都会面临返工。
从资源投入角度看，能力建设优先级建议为：先构建可复现的单环境直接评测，再补充多环境能力，最后引入Agent评测。这样可以在可控成本下逐步提升评测有效性。
如果团队已有基于直接评测的体系，向Agent评测或多环境评测演进时，需要注意以下问题。
首先是数据集兼容性。直接评测使用的数据集可能只包含问题、Schema和标准SQL，Agent评测还需要错误信息、可用工具描述、表结构检索范围等补充信息。迁移时需要评估原有数据集能否复用，是否需要重新标注。
其次是指标口径。直接评测常用准确率、语法正确率等指标，Agent评测还需要任务完成率、平均步数、修复成功率等。新旧体系并行期间，建议明确指标定义，避免混用导致误判。
第三是环境配置管理。多环境评测要求每个环境有独立的连接配置、账号权限、初始化脚本和清理策略。需要避免不同环境之间相互污染，尤其是数据库实例复用时要严格隔离。
第四是日志与错误分类。Agent评测会产生较多中间日志。建议在早期就定义统一的任务标识、步骤标识和错误类型，否则结果分析将非常困难。
第五是性能预算。Agent评测的耗时和资源消耗高于直接评测。在持续集成中，需要设计分级触发策略，例如提交级只做直接评测，每日或每周做Agent评测。
Text2SQL评测体系的升级，本质上是从单一生成能力评价走向任务级、生产级能力评价。直接评测与Agent评测的差异，并不仅是复杂度不同，而是关注点不同：前者关注模型个体，后者关注系统行为。多环境评测则进一步把能力验证放到更真实的交付条件下。
对于开发者和技术团队而言，关键是明确当前处于哪个阶段、需要回答什么问题。若目标是选模型，直接评测足够；若目标是判断能否上线真实应用，Agent评测更可靠；若目标是对外提供数据服务，多环境评测不可缺失。三类能力可以组合演进，但不应混为一谈。只有把评测目标、系统边界和成本结构对齐，才能建立可持续、可解释、可落地的Text2SQL质量体系。