Data Agent 落地实录：把一句模糊的业务问题翻译成可信数据

「我们业务当前表现怎么样，今年目标完成有风险吗？」把这个问题分别交给一位熟练的分析师和一套 Agent 加数仓的系统，你会看到截然不同的第一秒反应：前者已经在组织思路，后者可能还在生成一段看似合理的 SQL。这一秒钟的差距，就是智能的差距。当前几乎所有数据团队都在把数仓接上大模型做 Data Agent，但能跑通取数的很多，能真正回答业务问题、给出靠谱判断的却很少。本文试图讲清这条链路背后的本质与难点。

两段翻译：分析的本质

一次看似简单的业务提问，本质上是一次两段往返的翻译。去程是降维：把「美食行业最近怎么样」这句业务语言，一层层翻译成机器能执行的查询语言，其中目标、口径、时间范围、对比基准全靠默认共识被省略着。回程是升维：把跑出来的数字重新装配成一句带结论、带判断、能拍板的业务语言。过去二十多年，组织靠数据运营、分析师、数据开发这些角色的精细分工来弥合两个世界之间的鸿沟，本质上是在弥补人类无法直接理解原始数据这个根本限制。

可靠性沿链路连乘衰减

所有工程学科都绕不开的拦路虎，是可靠性会沿链路连乘。一次分析涉及六步骨架，每一步里还藏着大量子步骤与推理。即便每步都做到 99% 准确，累计起来也会迅速衰减：十步后只剩约 90%，五十步后跌到六成，一百步后仅存三成多。这在数据分析上是灾难性的。与生文生图不同，数据分析连续对十次、第十一次错了，用户对 Agent 的信任就会瞬间崩塌。所以必须细看每一次翻译到底该做到、做好，还要做稳。

四件补齐：知识能力校验兜底

要让每一步翻译又准又稳，需要给 Agent 补齐四样东西：一是补知识，让它脑子里有货，知道业务在说什么、口径该怎么算，这依赖指标字典、知识图谱与提问人画像的建设；二是补能力，让它手上有活，会取数、会算、会验，也就是意图澄清、任务规划与检索能力的组合；三是卡校验，让它心里有尺，做完先自查，过不去不许出门，尤其要针对多表 Join、留存计算、比率指标等高风险场景设置门禁；四是留兜底，让它在关键处有人接手，做过的事有记录、可回收。前两样决定能不能做，后两样决定敢不敢信。

口径与幻觉：真正的深坑

很多人以为问数 Agent 的难点是会不会写 SQL，其实真正的坑是口径和幻觉。一个「收入」可能躺着应付、实付、核销三个口径，退单算不算全是坑，团队往往要经历长达一年的指标统一治理才能形成稳定共识。更危险的是大模型的讨好型天性：你要什么它就给什么，哪怕这东西根本不存在——没有目标数据它会一本正经地编数，表里没有门店字段它会凭空虚构一列。防线是查询前先做可得性核对：表在不在、字段有没有、粒度支不支持，凡是用到却拿不到的，一律不许编，只能如实报错。即便如此，线上运营中仍有 1% 到 3% 的任务会出现 LLM 幻想出不存在的表和字段，可见这道闸必须常设。

先体检、再解读，是分析师的老规矩，也应成为 Data Agent 的铁律。前面口径再对，只要跑出来的数带病，后面所有解读与判断都建在流沙之上。把人的先验知识、职业直觉与校验习惯逐条翻译成机器可执行的规则，是走向可信智能问数的必经之路。