LLM智能体能当交付工程师？企业Text-to-SQL实测

引言：从编码助手到“前驻工程师”

LLM编码智能体正在改变软件交付的方式，但它们能否更进一步，像前驻工程师（Forward-Deployed Engineer, FDE）那样，深入客户场景、挖掘模糊需求并交付可用的生产系统？一篇针对企业级Text-to-SQL任务的实证研究，把这个问题推到了台前。

研究构建了一个模拟客户，基于真实企业Text-to-SQL用例的需求设计，初始请求故意保持模糊。智能体需要先在“发现阶段”厘清验收标准、数据权限和硬件约束，再在“交付阶段”规划并执行后训练方案。结果并不乐观，但也极具启发性。

前驻工程师（Forward-Deployed Engineer, FDE） 是指常驻客户现场、负责将产品能力与客户实际业务场景深度结合的工程师角色，常见于 Palantir、Databricks 等企业软件公司。FDE 的核心价值不在于写通用代码，而在于：与客户反复沟通以澄清模糊甚至矛盾的需求、理解客户的数据权限与合规边界、在真实硬件与预算约束下设计并交付可运行的系统。将这一角色类比到 LLM 智能体，意味着智能体不仅要会写代码，还要具备主动追问、交叉验证、规划后训练实验并对照多维验收标准自检的能力。本文正是用企业级 Text-to-SQL 任务作为试验场，检验智能体能否端到端承担这种“需求发现 + 方案交付”的双重职责。

发现阶段：最强模型能挖出八成隐藏需求

在发现阶段，研究测试了15个模型。表现最强的模型能够发现超过80%的隐藏需求，而开源权重模型则只能发现40-50%。这意味着头部模型在需求挖掘上已具备一定实用价值，但开源模型与闭源顶尖模型之间仍存在明显差距。

更关键的是，发现阶段并非一次性问答，而是需要智能体主动追问、交叉验证。研究中模拟的客户不会主动暴露所有约束，智能体必须像真正的FDE一样，通过对话逐步逼近真实需求。这种能力目前高度依赖模型的推理与规划水平。

交付阶段：仅四分之一配置通过全部验收

交付阶段的挑战更大。在八种编码智能体配置中，只有25%的运行通过了全部验收标准。换句话说，即便需求已经被正确发现，把方案落地为可运行、可验收的交付物，仍然是大多数智能体的短板。

研究指出，交付阶段要求智能体完成数据准备、模型选择、后训练配方设计以及最终评估。每一步都可能出现偏差，而这些偏差会在后续环节被放大。验收标准往往涉及多个维度，任何一项不达标都会导致整体失败。

后训练（post-training） 指在预训练基础模型之上，通过继续预训练、监督微调（SFT）、偏好对齐（如 RLHF/DPO）等手段使模型适配特定任务与领域数据的过程。在企业 Text-to-SQL 场景中，后训练配方通常需要决定：选用哪个基础模型、用多少条标注 SQL 样本、是否引入 schema 链接与检索增强、采用何种微调策略与超参数，以及如何在留出集上评估。配方设计的空间很大，不同选择对最终准确率与部署成本影响显著，这也是研究强调“缺乏对基础模型和后训练方法的系统性比较”会成为瓶颈的原因——智能体若不能系统地遍历并记录这些配置，就很难判断哪个方案真正适合生产。

四大瓶颈：发现不全、执行不可靠、算力浪费、基准失真

研究识别出四个核心瓶颈。第一，发现不完整：40%的隐藏需求在最终方案中缺失或被错误表述。第二，执行不可靠：智能体在交付阶段的操作稳定性不足。第三，算力预算利用不充分，且缺乏对基础模型和后训练方法的系统性比较。第四，基准准确率并不能保证生产就绪，模型在评测集上的高分与实际部署表现之间存在鸿沟。

这四个瓶颈相互关联。发现不完整会导致后续实验方向跑偏，执行不可靠会浪费算力，而缺乏系统比较则让团队难以判断哪个方案真正适合生产。基准失真则可能让团队过早乐观，忽视真实场景中的边界条件。

基准失真（benchmark-reality gap） 指的是模型在公开评测集上的分数与其在真实生产环境中的表现之间存在系统性偏差。Text-to-SQL 领域的典型基准（如 Spider、BIRD）通常提供干净的 schema、明确的单轮问题和标准答案，而企业真实场景往往包含脏数据、多轮澄清、权限过滤、跨库 join 以及口径歧义。模型可能通过记忆基准模式或利用评测集的分布特征取得高分，却在面对真实数据权限和硬件约束时失效。因此研究建议不要以基准分数作为选型唯一依据，而应在真实数据权限与硬件条件下做小规模验证，把基准成绩视为必要非充分条件。

改进方向：人工复核、过程监控与实验规范

针对上述问题，研究提出了三项建议。首先，对智能体发现的需求进行人工复核，尤其是在数据权限和合规约束方面。其次，在交付执行过程中监控智能体的计划，而不是只看最终结果。第三，制定明确的实验环境规范，覆盖硬件、预算范围和生产检查项。

这些建议指向一个共同结论：当前的LLM智能体尚不足以独立承担FDE角色，但可以作为人类工程师的高效副驾。把发现阶段的输出交给人工确认，把交付阶段的过程暴露给监控，把实验边界写清楚，能显著降低风险。

对企业的启示

企业若想尝试用LLM智能体处理Text-to-SQL类需求，应优先选择发现能力强的模型，并为交付阶段设置人工检查点。同时，不要用基准分数作为选型唯一依据，而应在真实数据权限和硬件条件下做小规模验证。FDE智能体的成熟还需要时间，但这项研究已经勾勒出清晰的改进路径。