本文根据云器科技联合创始人 & CPO 七良关于“数据 Agent 从 Demo 到生产落地”的分享整理。
过去几年，企业评估 Data Agent 的问题一直在变。
2022—2023 年，大家关心的是 Text-to-SQL：模型能不能理解复杂表关系，生成正确的 SQL？到了 2025 年，企业更习惯准备几十道甚至上百道固定题目，用准确率判断产品是否达到上线标准。如今，当越来越多 Data Agent 真正进入生产环境，问题又变成了另一句更直接的质疑：为什么它给出的答案不可信？
在七良看来，生产环境里最棘手的并不是模型“一本正经地胡说八道”。明显的幻觉反而容易识别。真正危险的是另一类错误：SQL 正常执行，指标也被调用，结果看起来合理，Agent 还能给出一套完整解释；但数据已经在关联、口径选择或数据源选择的某个环节悄悄偏离了业务事实。
这类错误不会触发告警，却可能继续进入报告、PPT 和经营决策。等到另一个熟悉业务的人指出数字不对，排查成本已经很高。更严重的是，几次这样的错误足以让用户失去对 Data Agent 的信任，最终使产品被停用。
七良将其称为数据 Agent 的“隐式问题”或“静默故障”。它也揭示了 Demo 与生产之间真正的分水岭：Demo 证明的是 Agent 能不能成功，生产系统还必须说清楚它会如何失败。
这场分享把问题进一步收敛成两个不能默认成立的假设：数据已经可靠，语义已经清楚。 一旦其中任何一个假设失效，Agent 都可能在没有报错的情况下给出完整答案。
Demo 与生产之间，变化的不只是数据规模
一个效果出色的 Demo，通常建立在一组没有被明说的前提上：数据经过清洗且相对固定，问题提前准备，指标口径能在小范围内快速对齐，答错后也可以重新调整。
在这样的环境中，团队最容易观察的变量是模型和 Agent 框架。换一个推理能力更强的模型，调整 RAG 或 Agent 的执行链路，固定题集上的表现往往就能提升。
但进入生产后，真正发生变化的是数据、语义和用户。
数据每天产生新分区，也会出现缺失、异常值和无法关联的孤儿记录；同一个 GMV，销售部门和总部可能采用不同定义；用户不再是会写 SQL 的分析师，而是用 HR、财务或经营语言提出问题的业务人员。问题无法穷举，错误的代价也从“重新评测一次”变成了错误汇报乃至错误决策。
这也是为什么，固定题集达到 95% 的准确率，并不自动等于生产可用。题集测试回答的是“在已知数据和已知口径下能否做对”，生产环境却要求系统处理持续变化的数据、开放问题和未必得到确认的业务规则。
图 1：Demo 测“能不能答上来”，生产还要回答“答错的时候会怎样”。*
七良分享了一个典型反馈：某个团队已经在 HR 场景中把 Data Agent 做得比较成熟，却不敢把它推广到财务域。团队担心的不是代码能否复用，而是进入新的业务域后，数据质量和语义质量是否仍然可控。
因此，生产化评估必须增加一个维度：除了统计成功率，还要建立失败模式清单，知道系统在什么条件下会给出错误答案，以及这些错误能否被用户发现。
三类静默故障：SQL 正确，不代表业务结果正确
从真实查询链路和项目案例看，静默故障大致发生在三个层面：数据关联、业务语义和数据源选择。它们的共同特点是，查询在技术上可以顺利完成，但业务结果已经失真。
数据关联：维表缺失，结果仍然可以正常返回
在一个网络供应商项目中，用户希望查询 Top 10 客户的营收。Agent 正常生成 SQL，查询也正常返回，但事实表与维表之间并不能完整对应：事实表包含大量区域记录，维表只覆盖了其中一部分。
当查询直接执行表关联时，无法匹配的记录会被排除。系统没有报错，用户仍然会得到一份排名清晰、数字完整的结果，只是这份结果实际建立在残缺的数据集上。
在 ICT 销售案例中，Agent 使用 INNER JOIN 查询 Top 10 客户营收。事实表和维表只有 692 行成功匹配，JOIN 覆盖率为 6.2%；约 10,529 行销售记录在关联时消失，约 94% 的事实数据没有进入排名。Agent 最终仍然返回了约 3100 万元的数字，并附带客户名和排名，看起来完整，实际只建立在 6% 左右的销售数据上。
图2:JOIN 覆盖率、匹配行数和被排除的事实记录共同揭示了静默丢数。
这种故障还具有累积效应。第一次查询遗漏部分客户，后续继续追问 Top 3 总收入、行业分布或区域占比时，分子和分母都可能沿用同一份残缺数据，错误随查询链路继续传播。也就是说，问题并不只在第一个 Top 10，而会沿着 Agent 的后续推理继续复利。
业务语义：两个公式都成立，但只有业务知道该用哪一个
保险行业的案例更能说明语义问题的特殊性。计算理赔率时，“全部理赔”是否只统计已经批准的理赔？分母中的保单，是仅包括当前有效保单，还是也要包含已经失效的保单？
这些状态条件不是 SQL 语法问题，而是企业内部的业务规则。按照不同定义生成的公式都能被正确执行，也都能得到看似专业的解释。最新 PPT 中，1,899 条理赔和 2,289 张 active 保单得到 83.0% 的结果；如果只采用 approved 理赔，结果则是 32.9%，差异来自口径选择，而不是计算错误。
图 3：两个结果都能算出来，但没有业务确认时，Agent 不知道哪一个才是用户要问的问题。
如果业务负责人没有参与确认，Agent 无论选择哪一种口径，实质上都在替组织做决定。问题不在于模型有没有完成推理，而在于它根本不具备这项规则的裁决权。
类似的歧义并不罕见。“最近 7 天”是否包含今天，同一个 GMV 是否含税、是否扣除退款，都可能因部门和场景而异。Agent 如果默认采用第一个检索到的定义，却没有向用户说明，静默故障就已经发生。
数据源漂移：同一个指标，Agent 到底从哪一层计算
在分层数仓中，同一指标往往可以从多个位置计算：原始数据层保留了明细，中间层完成了清洗和加工，汇总层又沉淀了面向业务的结果表。如果这些对象都对 Agent 可见，它可能从多个路径得到“答案”。
最危险的情况是，Agent 没有选用经过治理的结果表，而是回到未经清洗的原始数据重新计算。SQL 仍然正确，结果却可能与企业已经确认的指标不一致。由于数据表、查询路径和语义对象会持续变化，同一个问题甚至可能在不同时间得到不同结果。
除数据源漂移外，七良还列举了外键关联丢失、关联溢出导致结果放大、时间错位、占位符参与计算等问题。比如，当系统把身份证号识别为普通数值并纳入求和，计算本身不会失败，结果却没有任何业务意义。
这些案例共同指向一个事实：Data Agent 的生产质量不能只靠模型评测。数据质量校验、血缘关系、权威数据源和异常检测，仍然是整个系统不可省略的工程环节。
模型决定下限，数据与语义决定上限
当结果出现偏差，团队最自然的反应往往是换一个更强的模型，调整 Agent 框架，或者让另一个模型对答案进行复核。七良认为，这些方式能够改善执行能力，却无法解决企业私有知识缺失的问题。
他用“上限与下限”概括两者的关系：模型能力和 Agent 框架决定 Data Agent 的质量下限；数据质量和语义质量决定它的质量上限。
图 4：数据已达标、语义已签字，是生产环境不能默认成立的两个假设。
更强的模型可以更好地理解问题、规划步骤和生成 SQL，但它无法凭空知道一家企业内部尚未明确的业务约定。向模型提供更多历史查询，也只能证明某个人过去采用过某种写法，并不代表这套定义已经成为组织共识。再让一个模型评审，同样无法判断销售部门和总裁办公室的两套 GMV 口径究竟应该采用哪一套。
这意味着，数据问题和语义问题必须用不同机制解决。
数据侧通常存在可验证的正确答案。关联覆盖率是否完整、字段是否包含异常值、数据是否来自权威层，都可以通过传统数据工程和质量规则检查。语义侧处理的则是组织约定，最终判断只能来自人。模型可以发现冲突、整理文档、提示缺口，但指标口径、状态范围和业务版本仍需要相关负责人确认。
七良所说的“签字”并不一定是一份盖章文件。一次可追踪的沟通、一份经过确认的指标文档，都可以构成确认过程。关键是让组织明确知道：这套语义由谁认可，适用于什么场景，而不是把裁决权留给
Agent。
两道生产化机制：事前签字与断言契约
七良将两类问题进一步落成两道不同的生产机制。语义侧采用事前签字 ，数据侧采用断言契约 。两者的共同目标不是替 Agent 修好问题，而是让系统在越过边界时有资格拒答。
图 5：语义侧只能问人，数据侧通常可以直接检查，因此两者不能共用一套机制。
语义侧：在分析开始前确认问题
语义侧没有可以从数据里直接计算出来的唯一正确答案。比如“已完成订单”是否包含退货，“有效保单”是否包含已失效状态，最终都属于组织约定。
因此，确认应该发生在分析发起之前，而且应该签一人能读懂的一句话，而不是让用户勾选一组没人会真正检查的配置项。用户还没有看到数字时，先确认“理赔件数指全部还是已批准，有效保单指哪些状态”，可以避免结果先入为主。
这也是为什么“事后审核”往往不够可靠。用户看到 83.0% 之后，再让他判断这个数字对不对，实际上是在要求他验证自己并不掌握的数据和计算过程；让他先选择自己要问的口径，则只需要调用他对业务的判断。
数据侧：用断言获得拒答资格
数据侧通常存在客观判据，适合在查询前或查询过程中执行确定性的断言。例如检查维表主键是否唯一、关联前后粒度是否改变、时间汇总是否落在同一快照、字段中是否存在 999、-1 或 9999-12-31 等占位值。
断言的输出不是“让 Agent 再修一遍 SQL”，而是让系统获得拒答或降级的资格。最新 PPT 特别强调，断言应当是只读、确定性的检查，不调用模型来修复结果。因为自动修复很容易把一个可见的小问题改造成更复杂、也更难发现的错误。
断言也不是万能防线。演讲中的实验显示，结构断言只能接住约 7% 的错误。它的价值在于拦截那些只能从数据结构中观察到的故障，并把“这次不能可靠计算”的原因明确告诉用户，而不是承诺覆盖所有错误。
从“总要给答案”转向“响亮地失败”
多数 Agent 被设计成尽可能满足用户：检索缺了三步，就继续推理；数据不完整，也要尝试给出一个结果。这种“讨好型”交互在通用问答中或许可以接受，在对准确性和一致性要求很高的数据场景中，却会放大风险。
七良提出，Data Agent 应该具备“响亮地失败”的能力。
所谓响亮地失败，并不是简单返回一条报错，而是把失败原因转化为用户可以判断的信息。例如，系统发现某个成本字段有 49% 为空时，可以继续提供探索性结果，但必须明确说明数据缺陷及其可能影响；发现两个 GMV 定义时，应提示用户选择，或者说明当前答案采用了哪套定义；缺少足够依据时，则应该主动拒答。
这背后至少需要三种机制。
第一，执行过程可解释。Agent 不只展示答案，还要说明使用了哪些数据、采用了什么口径、做过哪些关键假设。
第二，提供探索模式。业务用户往往无法一次提出标准的分析问题，系统应允许他逐步确认指标、维度和筛选条件，而不是强迫每次对话都直接产出最终答案。但探索模式不能成为签字门的旁路：它可以让用户看到多个口径的对照，却不能把未经确认的结果直接导出、写入报表或被后续分析当成事实。用户从对照中选定一个口径，这次选择本身才完成了签字。
第三，建立拒答边界。什么情况下必须澄清，什么情况下只能提供带风险提示的探索性结果，什么情况下应该停止回答，需要被设计成明确的产品能力，而不能只依赖模型临场判断。
这样做也重新划分了人与 Agent 的责任。Agent 有责任暴露数据缺陷和推理假设，业务人员则在充分知情的前提下确认口径、判断结果是否适用于当前决策。系统不再默默替人完成判断，也不会让用户在不知情的情况下把全部责任推给模型。
可信的关键不是正确率，而是“可分辨性”
分享最后，七良给出了一个比准确率更接近生产现实的判断：Data Agent 的可信性不只来自正确率，更来自答案的可分辨性。
用户需要能够区分三种状态：已签字 ，口径已经有人确认，结果可以引用；探索 ，口径尚未签字，系统摊开多个选项供用户选择，但结果暂时不能流通；拒答 ，数据侧断言没有通过，系统停下来并说明差在哪里。
图 6：语义未签字时给选项，数据不达标时给拒答，两个状态的降级方式不同。*
如果这三种状态都被包装成同一种确定语气，用户就无法判断风险。相反，当系统能够解释数据来源、暴露假设并主动表达不确定性，即使它无法保证每次都答对，用户仍然可以判断何时采用结果、何时补充信息、何时交由人工处理。
这条原则同样适用于 RAG 和其他企业 Agent。只要系统可能影响业务判断，就不应该以“什么都能回答”为目标。Agent 可以替人执行任务，也可以提出建议，但凡它替人做了决定，就必须把这个决定及其依据明确告诉用户。
结语
从 Text-to-SQL 到固定题集评测，再到生产环境中的可信性问题，Data Agent 的竞争焦点已经从“能否生成答案”转向“能否管理不确定性”。
这背后其实是两道机制，分别对应语义侧和数据侧。
在语义侧，如果 Agent 不知道该选哪个口径，就不要替业务猜。它应该把冲突的定义、适用范围和待确认的问题摊开，让真正拥有业务判断权的人来选择。
在数据侧，如果 Agent 不知道数据是否足够可靠，就不要假装一切正常地继续计算。它应该明确拒答，或者给出带有风险说明的探索性结果，并告诉用户：数据缺在哪里，可能影响什么。
两道机制的唯一共同点，是拒绝让 Agent 无声地替人做决定。
图 7：语义侧把选项摊开让人挑，数据侧在数据不够格时拒答并说明差异。
它们不是为了让 Agent 显得更聪明，也不是为了把所有问题都交还给人，而是给系统一个能够说“我不确定”的位置。只有不确定性被看见，用户才知道什么时候可以使用结果、什么时候需要补充信息，什么时候必须由人来拍板。
如果你正在把 Data Agent 从试点推向生产，建议把这套机制带回团队继续讨论：哪些业务口径需要事前确认，哪些数据约束可以写成断言，哪些结果应该进入报表，哪些结果只能停留在探索阶段。完整 PPT 中还保留了更多故障清单、机制边界和交付状态示例，方便在内部评审时逐页展开。
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
