“为什么本周转化率下降了？”
一个 NL2SQL 工具可以把这句话翻译成查询。一个真正的 Data Agent 则要先问清楚：是哪条业务线、哪个转化漏斗、自然周还是滚动七天、当前用户有权查看哪些数据。随后，它还要找到可信的数据集，调用指标定义，拆解异常，运行查询，检查样本量和数据新鲜度，最后把结论连同证据交给使用者。
二者都可能有聊天框，也都可能生成 SQL。区别不在界面，而在于谁对完整任务闭环负责。
一个可以落地的定义
Data Agent 是运行在受治理数据环境中的自主或半自主软件系统。它接受自然语言或高层任务，在权限边界内完成上下文装配、规划、工具执行和结果验证，交付可追溯的数据答案、洞察或行动。
这里的每个限定词都有用：
- 数据环境意味着系统面对的是真实表、指标、文档、元数据和访问策略，而不是一组预设答案。
- 自主或半自主意味着它能维护任务状态，根据中间结果继续、修正或停止，而不是只完成一次生成。
- 受治理意味着模型不能绕开身份、权限和审批规则；高风险操作必须有边界。
- 可追溯意味着使用者能看到结论依据了什么数据、口径和执行过程，也能复核关键结果。
近年的 Data Agent 研究也反复指出：这个名称同时被用于查询助手和自主系统，术语混用会掩盖能力差异。《A Survey of Data Agents》因此提出了从 L0 到 L5 的分类；后续的《Data Agents: Levels, State of the Art, and Open Problems》则把数据管理、准备和分析都纳入同一个工具使用框架。定义的价值，不是再造一个新名词，而是让产品承诺可以被检验。
Data、Model 和 Harness 缺一不可
只看大模型，很容易把 Data Agent 理解成“更会推理的聊天机器人”。实际系统更接近三个部分的乘积。
Data：不只是数据库连接
数据侧至少包含三类上下文：
- 事实数据：仓库、湖仓、业务数据库、文件和 API。
- 业务语义：指标定义、维度层级、实体关系、同义词和计算规则。
- 治理上下文：身份、行列权限、数据分级、新鲜度、血缘和使用限制。
能连上 Snowflake 或 BigQuery，只解决了“数据在哪里”。如果不知道“有效订单”是否排除退款，也不知道财务口径何时生效，系统仍然会稳定地产生错误答案。
Model：提供推理，不拥有权限
模型擅长理解意图、提出假设、生成 SQL 或 Python，并把结果组织成人能读懂的说明。但模型参数不是企业事实库，也不应该成为权限系统。把业务定义塞进提示词，只能暂时改善某个问题，无法替代版本化的语义层和强制执行的访问策略。
Harness：把能力组织成可靠过程
Agent Harness 是最容易被低估的部分。它负责装配上下文、保存状态、安排步骤、选择工具、传递身份、限制执行、校验结果并记录轨迹。模型可以替换，工具可以增加；只要 Harness 的契约稳定，系统仍能按同一套治理规则工作。
这也是 Data Agent 与“模型直接连数据库”之间最重要的工程差别。
四项判断标准
评估一个产品时，可以先不看它是否使用了 “Agent” 这个名字，直接检查以下四项。
| 标准 | 应该看到什么 | 常见伪装 |
|---|---|---|
| 真实环境 | 使用调用者身份访问真实数据、元数据和语义定义 | 只在样例库或预先索引的问答集上工作 |
| 多步执行 | 保存状态和中间结果，能基于反馈调整计划 | 把一段很长的提示词包装成“一键分析” |
| 结果验证 | 检查执行错误、口径、粒度、新鲜度和异常值 | SQL 成功运行就直接生成结论 |
| 治理闭环 | 有权限控制、审计、评测、停止条件和人工升级 | 只有操作日志，没有决策边界 |
前三项决定它是否承担了数据任务，第四项决定它能否进入生产环境。
1. 它是否在真实环境中工作？
真正的任务不是“生成一段看起来合理的 SQL”，而是在当前用户的权限和业务上下文中找到正确答案。系统必须知道可访问哪些资产、哪些数据已经过期、哪个指标版本适用于当前问题。
2. 它是否维护多步状态？
分析很少一次命中。转化率下降可能先要排除埋点延迟，再按渠道和版本切分，随后检查样本结构。Data Agent 应该知道已经验证了什么、下一步依赖什么，以及何时停止继续钻取。
3. 它是否验证答案，而不只验证语法？
查询成功只说明语法和运行环境接受了它。业务答案还可能因为重复 Join、错误时间窗、分母变化或数据延迟而出错。可靠系统会把这些检查做成执行过程的一部分，并对无法消除的不确定性做明确说明。
4. 它是否知道何时不能继续？
成熟的智能体不以“尽量给出答案”为唯一目标。缺少关键口径时应该提问；数据质量不足时应该降级；涉及写入、调度或外部通知时应该触发审批；超出授权范围时应该停止。这些行为比一段流畅的解释更能说明系统是否可控。
它和 NL2SQL、ChatBI、Copilot 有什么区别？
这些形态不是互斥产品，而是不同的任务边界。
- NL2SQL解决语言到查询的转换，是 Data Agent 可以调用的一项能力。
- ChatBI用对话降低查询和看板使用门槛，但不一定负责完整分析过程。
- Copilot协助人完成步骤，计划和最终判断仍主要由人掌握。
- Data Agent在明确的授权范围内接管任务级闭环，并对过程、证据和停止条件负责。
因此，一个产品可以从 NL2SQL 起步，逐渐增加语义检索、规划、验证和治理能力，最终接近 Data Agent；没有必要为了命名而假装已经实现了全自治。
五分钟产品检查
下次看到一个新的 Data Agent，可以直接问五个问题：
- 它如何确定指标口径，而不是只找到字段名？
- 每次工具调用使用谁的身份，权限在哪里强制执行？
- 中间结果如何影响下一步计划？
- 查询运行成功后，还会做哪些业务与数据质量检查？
- 哪些情况会让它停止、请求澄清或升级给人？
如果答案集中在“模型更强”“提示词更长”或“SQL 准确率更高”，它大概率仍是一个能力出色的查询助手。如果这些问题能落到具体的系统组件、策略和记录上，它才开始具备 Data Agent 的形态。
现实边界：今天仍以辅助和半自主为主
Data Agent 的长期方向是扩大端到端任务范围，但生产系统不应该用愿景代替现状。上述研究的 L0–L5 框架，以及配套的 Awesome Data Agents 项目，都把当前系统主要放在辅助型、工具型和早期的半自主阶段；能够跨环境长期运行、自我改进并独立承担高风险决策的 L4、L5 仍是目标状态。
这并不削弱 Data Agent 的价值。恰恰相反，承认边界，才能把注意力从“像不像人”转回真正有用的工程问题：语义是否一致，执行是否可靠，证据是否充分，权限是否守住，以及人在关键节点能否有效接管。
Data Agent 最值得建设的，不是一个什么都敢回答的界面，而是一条让数据任务更快完成、又不会失去控制和可信度的路径。