别急着给它接上数据库。
最近，Data Agent 几乎成了企业 AI 项目里最容易让人兴奋的方向。
产品经理想要一个“懂业务的数据助手”：老板可以直接问“为什么本月利润下降了”，运营可以问“哪些客户最可能流失”，销售可以问“华东区域还有哪些机会”，系统不仅能返回数字，还能自动拆解原因、生成图表，甚至进一步触发分析、预警和行动。
演示通常也很顺利。
接入一个数据源，配置几个指标，写一段系统提示词，再让大模型调用 SQL 工具。几分钟后，一个看起来会思考、会查数、会总结的 Data Agent 就诞生了。
但我想先劝一句：
如果你还没有解决数据口径、权限边界和业务问题定义，就不要急着做 Data Agent。
因为 Data Agent 最危险的地方，不是它不会回答，而是它可能会用一种非常流畅、非常自信的方式，回答一个本来就没有标准答案的问题。
从FineBI Next的产品链路也能看出，自然语言问数并不是在数据库上直接增加一个聊天入口。业务人员提出问题后，系统仍要基于已经连接和准备的数据，结合指标、维度与权限组织分析；得到结果后，还可以继续下钻、生成图表，并进入仪表板、数据门户和预警等应用场景。
它没有绕过原有的数据体系，而是把 AI 放进数据准备、分析和应用的完整链路里。这恰恰说明，Data Agent 能不能落地，关键并不只是模型能否听懂问题，而是模型背后的数据是否已经具备被理解、被查询和被验证的条件。
FineBI Next需要自取：https://s.fanruan.com/zk65g（复制到浏览器）
一、Data Agent 不是“自然语言版 BI”
很多团队对 Data Agent 的第一理解，是把自然语言转换成 SQL：
用户提问，模型生成 SQL，数据库返回结果，模型把结果翻译成人话。
这个链路当然有价值，但它更接近 Text-to-SQL，而不是完整的 Data Agent。
真正的 Data Agent 至少要处理五件事：
理解问题：用户到底在问什么？“销售下滑”指收入、订单量，还是新客数？
识别口径：应该使用哪个指标、哪个时间范围、哪个组织层级？
选择数据：哪些表可信，哪些字段可用，哪些数据已经过期？
组织分析：是直接回答，还是需要同比、环比、分群、钻取和归因？
表达不确定性：数据不足时，是否应该追问，而不是编造一个确定结论？
SQL 只是其中一个执行环节。
如果企业没有把前面的业务语义定义清楚，模型生成的 SQL 越“聪明”，问题反而越大。
它可能准确地查出了一个错误口径，也可能把多个看似相近的字段拼在一起，产生一张逻辑完整、业务错误的结果表。
像FineBI Next的 AI 助理，并不是简单把自然语言转换成数据库查询，而是基于企业已有的数据资产理解业务语义，辅助完成指标选择、分析路径拆解和可视化分析。
所以，Data Agent 的核心不是“让模型会查库”，而是让模型知道：什么时候该查什么、为什么查、查出来之后能不能这样解释。
二、最先被自动化的，往往不是分析，而是误解
数据分析里有一个经常被低估的事实：很多问题不是计算问题，而是定义问题。
比如，业务负责人问：
“上个月我们的活跃客户有多少？”
这个问题看似简单，至少可能存在几种不同口径：
当月登录过一次的客户；
当月产生过交易的客户；
当月完成某项关键行为的客户；
当月仍处于有效合同期内、且发生过互动的客户；
去掉测试账号、内部账号和已注销账号后的客户。
如果人工分析师面对这个问题，通常会追问：“你说的活跃是哪个定义？”
但很多Data Agent为了提供即时体验，会直接选择一个它认为最合理的口径，然后给出答案。
这就是 Data Agent 的第一个风险：
——它会把本来需要沟通的问题，伪装成一个已经解决的问题。
而且，答案越具体，风险越容易被忽略。
“活跃客户是 18,632 个”看起来比“需要进一步确认口径”更像一个专业答案。但数字的精确，不等于结论的可靠。真正重要的不是小数点后几位，而是这个数字是否被所有相关的人用同一种方式理解。
三、做 Data Agent 前，先检查你的数据是不是“可被问”
很多企业的问题不是没有数据，而是数据还没有准备好接受自然语言提问。
一个可以被 Data Agent 稳定使用的数据环境，至少应满足以下条件。
指标有明确的业务定义
不能只有字段名和指标名，还要说明：
指标的业务含义；
计算公式；
时间口径；
统计粒度；
包含和排除哪些对象；
数据更新时间；
适用的业务场景；
与相似指标的区别。
例如，“客户数”不能只写成count(customer_id)。你需要明确它是注册客户、有效客户、付费客户，还是去重后的交易客户。
指标之间的关系是可解释的
收入、订单、客户数、客单价、转化率之间存在业务关系。Data Agent 不只是要能查出这些指标，还要知道哪些指标可以相除、相加或进行趋势比较。
如果系统不知道“订单金额”和“回款金额”不是一回事，那么它可能会给出一条数学上成立、业务上错误的结论。
维度和实体有统一的主键
客户、门店、商品、合同、订单、区域这些实体，是否在不同系统中使用同一套编码？
如果 CRM 里的客户编号和财务系统里的客户编号无法稳定关联，Data Agent 做出来的“客户价值分析”就可能只是多个不完整数据集的拼接。
数据有时间和质量状态
数据不是静态资产。一个指标需要知道：
是否实时；
是否存在延迟；
最近一次刷新是否成功；
是否发生过回补；
是否存在缺失和重复；
当前数据覆盖到哪一天。
没有数据新鲜度和质量状态的 Data Agent，回答“今天的销售情况”时，可能使用昨天甚至上周的数据，却不会主动告知用户。
权限可以被细粒度执行
“这个用户能不能看到这张表”只是最粗的一层权限。
更现实的问题是：
他能看全国数据，还是只能看自己负责的区域？
他能看到收入，能不能看到利润？
他能看到客户数量，能不能看到客户名称和联系方式？
他能查看汇总结果，能不能继续钻取到明细？
Agent 的分析过程是否会把用户无权访问的字段带入上下文？
如果权限只停留在前端按钮层面，Data Agent 会成为一个新的数据泄露入口。
四、真正难的不是让 Agent 会回答，而是让它知道什么时候不能回答
一个成熟的 Data Agent，不能把“回答率”作为唯一目标。
它还要具备三种克制能力。
第一，知道何时追问
“利润下降了吗？”至少要确认：
看哪一个利润指标？
与哪个周期比较？
统计全公司还是某个业务线？
是否需要剔除一次性项目？
如果这些信息会改变结论，Agent 就应该追问，而不是擅自补全。
第二，知道何时拒答
如果数据没有覆盖目标时间范围，或者用户没有相应权限，或者指标定义存在冲突，最专业的答案可能是：
“当前无法可靠回答。原因是 A 数据只更新到 8 月 20 日，而你询问的是 8 月 21 日至 25 日；如果你愿意，我可以先给出截至 8 月 20 日的结果。”
拒答不是体验失败。在数据场景里，错误的确定性往往比暂时没有答案更昂贵。
第三，知道何时把问题交给人
当问题涉及重大经营判断、财务披露、合规审查或异常事件归因时，Agent 可以完成数据整理和证据汇总，但不应自动把推测包装成最终结论。
它可以说“以下三个因素与利润下降同时发生”，但不应该在没有验证因果关系时直接说“利润下降是因为这三个因素导致的”。
五、一个可落地的 Data Agent，应该长什么样？
我更倾向于把 Data Agent 设计成一个“受约束的分析系统”，而不是一个自由发挥的聊天机器人。
如果把FineBI Next的能力链路和 Data Agent 放在一起看，可以得到一个更现实的产品架构：
前端是自然语言交互和智能分析，底层是可连接、可准备、可检查的数据资产，中间是指标、维度、权限和分析过程，后端则是仪表板、数据门户、移动触达、预警和业务行动。
这样的架构有一个关键好处：
Agent 不需要独自承担所有工作。它可以在多维探索分析中辅助用户拆解问题，在仪表板中引用已经定义好的指标和交互关系，在数据门户和应用市场中找到适合角色的分析内容，再通过预警、推送、回填和下钻，把结论接入实际管理流程。
这比单纯让模型直接查询数据库更接近企业真正需要的 Data Agent：不是一个会生成 SQL 的聊天机器人，而是一套能够在可信数据基础上，帮助用户完成“发现问题—分析原因—辅助决策—推动行动”的受约束分析系统。
它至少需要以下几层能力：
语义层：把业务语言翻译成统一概念
包括指标、维度、实体、同义词、业务规则和时间口径。
例如，用户说“成交额”“GMV”“交易金额”，系统需要知道它们是否指向同一个指标，还是在不同业务场景下存在差异。
计划层：先制定分析路径，再执行查询
对于复杂问题，Agent 不应该直接生成一段 SQL，而应该先拆解任务：
明确比较对象；
确定时间范围；
选择指标和维度；
判断是否需要分群或钻取；
规划验证步骤。
这使得分析过程更容易审查，也更容易定位错误。
工具层：使用受控的数据工具
不要让模型直接拥有整个数据库的任意读权限。更好的方式是提供经过封装的指标查询、明细钻取、趋势分析、异常检测等工具，并限制参数、字段和返回规模。
证据层：让答案能够被复核
一条可信的答案至少应该说明：
使用了哪些指标；
数据截至什么时间；
采用了什么比较口径；
结果来自哪些数据集；
哪些部分是事实，哪些部分是推断；
是否存在数据缺口或异常。
评估层：用真实问题持续测试
不要只测试“能不能查到数”，还要测试：
口径是否正确；
权限是否正确；
SQL 是否高效；
解释是否超出证据；
数据缺失时是否会主动提示；
面对歧义时是否会追问；
同一个问题在不同时间是否保持一致。
Data Agent 没有一次性验收。它更像一套需要持续评估的数据产品。
六、做之前，先问自己七个问题
在启动 Data Agent 项目前，可以先回答这七个问题：
我们最想解决的，是取数慢，还是业务不会定义问题？
目标用户最常问的十个问题是什么？是否有稳定答案？
这些问题涉及的指标，是否拥有明确且唯一的业务口径？
数据是否有统一的实体、主键、时间范围和刷新状态？
用户权限能否落实到查询和结果，而不是只停留在页面？
当答案不确定、数据不足或问题有歧义时，Agent 要如何处理？
我们准备用什么真实问题评估它，而不是只看演示效果？
如果其中一半问题都答不上来，建议先别急着写 Agent Prompt。
先做数据盘点、指标治理和场景收敛。你可能会发现，当前最需要的不是一个更聪明的 Agent，而是一套更清楚的数据定义。
结语：Data Agent 的起点，不是模型，而是共识
Data Agent 会改变数据工作的入口。
过去，业务人员需要打开报表、寻找字段、申请权限、等待分析师；未来，他们可能直接用自然语言提出问题，并在几秒内获得一份带有解释和证据的结果。
但入口变得更简单，不代表问题本身变简单了。
恰恰相反，当每个人都可以自由提问，企业会更频繁地面对这些基础问题：
什么是收入？
谁是有效客户？
哪个版本的利润口径才是对的？
为什么不同系统给出了不同答案？
所以，做 Data Agent 前真正要听的那句劝是：
不要先问模型能不能回答，而要先确认企业是否知道什么才算正确答案。
一个没有语义、没有治理、没有边界的 Data Agent，只会把数据混乱传播得更快。
一个建立在可信数据和清晰规则之上的 Data Agent，才有机会成为真正的决策基础设施。
这两者看起来只差一个 Agent，实际上差的是整个组织对数据的理解能力。
