货拉拉的经营策略团队每周一上午都有一场雷打不动的策略复盘会。说是复盘会前半小时其实都在等数——运营在问“为什么这周夜间订单应答率掉了3个点”数据同学还在临时写 SQL、跑数、手工拆城市维度。这个场景我们忍了一年多后来干脆动手做了一个 DataAgent把“拉数—解释—给建议”这条链路整体交给智能体编排业务同学直接对话问数几分钟拿到带归因和策略建议的复盘结论。这篇文章就是把这个项目的思路、架构、落地细节和踩坑记录完整拆出来给同样在做数据智能化、策略分析自动化的团队一个可参考的样本。如果你是数据团队负责人、策略运营或者正在研究如何让大模型真正落地到业务分析场景这篇内容应该能帮你想清楚几件事复盘类需求到底难在哪通用 ChatBI 为什么撑不住以及一个面向复盘的 DataAgent 该怎么设计、怎么调、怎么防幻觉。1. 策略复盘到底“重”在哪从业务痛点反推需求1.1 复盘会上的真实场景先还原一个典型的货拉拉策略复盘场景。城市运力运营提出了一版“夜间高峰加价”策略目的是在晚高峰时段用加价手段刺激司机出车减少用户叫车后的应答时长。策略上线两周后复盘会上需要回答三个问题整体应答率是否改善分城市看哪些地方有效、哪些地方无效如果无效是供给没起来还是需求被加价压下去了这些问题听起来不难但真要回答需要同时关联订单表、司机轨迹表、运价配置表、城市基础信息表还要在“夜间”“高峰”“加价覆盖订单”这些口径上定义清楚。传统做法是数据同学先花半天写 SQL 和透视表再花半天做 PPT最后在会上被追问“这个数字为什么和上周统计口径不一样”又回去查。一轮复盘跑下来两三天就过去了策略迭代的节奏被严重拖慢。所以复盘业务的真实痛点不是“没数据”而是“把数据变成结论”的链路太长。链路里有三个参与者策略运营负责提问和拍板数据分析师负责取数与解读管理层负责基于结论做资源投入决策。这三类人最需要的不是又一个报表工具而是一个能把“问题”自动转化为“取数计划—数据查询—归因分析—结论草稿”的智能体。1.2 为什么通用 ChatBI 撑不起复盘很多人听到 DataAgent 的第一反应是这不就是 ChatBI 吗做个对话式 BI让用户用自然语言查数。我们最初也这样想但实际落地后发现复盘场景对智能体的要求比“查数”高了一个层次。通用 ChatBI 的核心能力是“问—答”用户问“上周订单量多少”系统返回一个数字或一张图表。但复盘的核心是“看数—归因—建议”三段式用户真正要的是“数字变了为什么变接下来该怎么办”。比如运营不会只问“夜间应答率是多少”他会问“夜间应答率比上周降了是不是因为加价幅度不够还是运力投放减少导致的”。这个问题不能靠单轮问答回答需要智能体自己去拆解指标、对比维度、匹配原因、给出假设、再验证假设。这就要求我们把“复盘”本身当成一个工作流来做而不是一个问答入口。DataAgent 的定位由此清晰起来它是一个以 LLM 为大脑、以指标平台和查询引擎为手脚的分析执行体能够把一条模糊的业务疑问逐步拆解成可执行的查询计划并在多轮工具调用后生成一份有数据依据、有归因推理、有策略建议的复盘结论。通用 ChatBI 是“点菜”DataAgent 是“厨师配菜做饭”区别就在这。2. DataAgent 整体设计把复盘拆成一条可编排的工作流2.1 三层架构与状态流转我们在设计 DataAgent 时没有一上来就堆大模型技术而是先画了一条复盘任务的状态流需求理解、方案规划、指标选择、数据查询、异常归因、报告生成。这条状态流来自对人工复盘过程的模拟分析师平时就是这么干活的。系统整体分三层。最上层是交互与展示层负责处理用户的自然语言输入展示图表、归因树和报告中间是 Agent 编排层承载状态机、任务规划、工具调用和记忆管理这一层我们基于 LangGraph 搭建因为它的图结构能清晰表达“并行拆解城市维度”和“串行执行归因”这类流程最下层是工具层包括指标服务平台、OLAP 查询引擎、规则归因引擎、报告渲染服务和 RAG 知识库。状态流转的核心逻辑是Agent 先把用户的模糊需求解析成结构化分析任务比如“对比夜间加价覆盖订单近两周应答率按城市拆解”会被解析出时间范围、业务筛选条件、目标指标、拆分维度四个槽位。接着 Agent 基于指标字典选择匹配的指标生成查询计划调用查询工具获取数据。拿到数据后先做显著性判断比如幅度低于阈值就不进入归因避免对正常的波动过度解释。最后把数据结论、归因结果和策略建议组装成报告并附上每条结论对应的数据来源。2.2 工具层选型指标平台、NL2SQL、归因引擎、报告生成工具层的选型决定了 Agent 的上限。我们一开始也考虑过让 LLM 直接读库表结构生成 SQL但很快放弃了因为货拉拉的指标口径分散在订单、运力、用户、支付等多个业务域同样的“应答率”在不同团队可能有不同算法。最终我们把指标平台定位成唯一指标出口。所有指标的口径、维度、负责人、可用范围都在平台上登记Agent 不直接面对裸表而是通过指标服务 API 查询。这么做有两个好处口径天然收敛Agent 不容易因为表结构复杂而选错字段权限控制可以在指标层统一做而不是散落在 SQL 层。工具层另一个重要决策是把归因分析交给规则引擎而不是交给 LLM 的“推理”。我们自建了一个轻量的归因引擎输入是目标指标的时间序列和维度数据输出是各维度贡献度排名和原因候选集。LLM 的作用是把这个候选集翻译成业务语言而不是凭空创造原因。报告生成则采用“模板结构 LLM 渲染”的方式固定的章节骨架保证报告结构稳定LLM 负责润色表述和填充归因解释。2.3 把口径知识做成 RAG而不是塞进 Prompt复盘场景对口径的准确性极其敏感。同一个指标在“不含取消订单”和“含取消订单”两种口径下数字可能差出好几个百分点。如果 Agent 在生成 SQL 时用错了口径后面的归因和结论全部作废。我们早期尝试把所有指标口径、业务规则、历史复盘结论直接写进系统提示词结果 Prompt 越来越长Token 消耗越来越大且每次更新口径都要重新调试。后来改成 RAG 方案把指标字典、历史复盘报告、异常原因词条库做向量化在 Agent 规划任务前先检索相关知识再注入到当前任务的上下文里。举一个具体例子运营问“夜间加价策略覆盖订单的应答率情况”Agent 会先检索到“应答率应答成功订单数/呼叫订单总数夜间定义为 21:00—次日 5:00加价覆盖订单指订单创建时运价方案含夜间服务费”这条口径记录再带着这个定义去指标平台找数据。这一步看似简单实际效果却很明显——指标命中率从最初的 61% 提升到 79%而且是在不大改模型的情况下做到的。RAG 的检索我们用的是向量库 关键词混合召回TopK 取 5 条左右。这里有一个小经验不要只检索相似度最高的那条复盘问题往往同时涉及指标定义和业务背景Top5 的上下文给 LLM 更多判断余地但候选太多又会引入噪音5 条是一个实测比较稳的平衡点。3. 核心环节落地从一句提问到一份复盘报告3.1 策略意图识别与对话澄清Agent 接到的第一个任务是把用户那句口语化需求变成结构化任务。我们内部把这一步叫做“意图槽位填充”本质上和传统对话系统的意图理解一致但难点在于策略复盘问题的表达方式非常多样。运营可能说“看看夜间加价效果怎么样”也可能说“这周应答率对比上周按城市拆一下”还可能直接扔一个指标名“夜间接单率”。这三种说法对应的槽位完整度完全不同。我们的做法是Agent 先尝试用已有信息填充槽位如果发现目标指标缺失或时间范围缺失就主动发起一轮澄清追问而不是猜一个默认值。这里最容易犯的错是“闭眼默认”。最初的版本里运营说“看看夜间效果”Agent 就默认取最近 7 天、全城市、应答率这一个指标。结果运营本意是想看取消率和投诉率两个指标答案给偏了。后来我们在状态机里加了一步“槽位确认”当关键槽位缺失时Agent 会返回一个候选列表让用户选择。这一步增加了半轮对话但大幅降低了后续返工率。我们还做了一个细节解析“夜间高峰”这类业务时间段时不硬编码时间段而是从策略配置中心读取当前生效的定义。因为晚高峰的开始时间会随着季节和城市运营节奏调整写死在代码里的时间范围迟早会和策略配置对不上。3.2 Text-to-SQL 的工程化调优Text-to-SQL 是 DataAgent 最容易翻车的技术点。我们初版上线时 SQL 执行成功率只有 72%也就是大约四分之一的查询语句要么语法错误、要么结果明显不符合问题描述。这个准确率在专案场景下完全不可接受因为运营判断不了 Agent 到底是不是算对了只能凭直觉发现“这个数好像不对”。我们的调优思路不是换更大参数的模型而是从工程侧做约束。第一步是 schema linking在做 SQL 生成前先通过指标平台拿到相关表和字段清单而不是把整个数仓的表结构都丢给模型。表少了选错表的概率就低了。第二步是 few-shot 示例我们挑选了五十条历史复盘中最常见的查询模板覆盖趋势对比、维度下钻、同环比计算三类模式让模型照着写。第三步是语法和逻辑校验在模型生成 SQL 后先用解析器检查语法再检查字段名是否存在于 schema 中最后检查聚合粒度是否匹配问题中的维度。效果提升最明显的是“值约束”这一步。比如运营问“深圳的夜间应答率”我们会在 SQL 生成前先把城市枚举值注入上下文提示模型“城市字段取值必须来自该列表”。这个方法把因为城市名写法不同导致的查询错误几乎清零因为模型只要从给定列表里选值就不会再把“深圳市”“深圳”“SZ”混用了。3.3 归因分析和策略建议怎么才可信拿到数据之后Agent 要回答“为什么变了”。最容易踩的坑是让 LLM 直接对着一串数字自由发挥它会生成看似合理但完全没有数据支撑的归因比如“可能是竞争加剧导致需求下降”但这句话背后没有对应任何数据验证。我们做了两个机制来管控归因的可信度。第一归因必须建立在数据指标之上。观测到夜间应答率下降后Agent 会先按城市维度拆解计算每个城市对整体下降的贡献度再按订单类型拆解看是“加价订单”还是“正常订单”贡献了主要变化最后才会结合天气、活动、竞对补贴等外部数据源做原因推断而外部数据源也必须有字段记录可查。第二原因候选必须来自规则库。我们沉淀了一个“归因原因词条库”里面存了类似“近期连续降雨导致司机出车意愿下降”“附近商圈举办大型活动导致短时需求激增”这类经过验证的业务解释并关联了可验证的数据特征。Agent 在做归因时是先看数据是否符合某个特征再引用对应词条。这样生成的归因结论是“跑过数据”的不是模型“脑补”的。策略建议部分也是类似逻辑。我们不要求 LLM 给出天马行空的策略创新而是让它在历史策略方案库里召回相似场景下的做法再结合本次数据表现做调整。这样做出来的建议可能不是最惊艳的但它是可执行的、和当前业务上下文匹配的这对策略团队来说比创意更重要。3.4 一次完整复盘任务的执行回放用一个具体例子把上面这些串起来。运营在 DataAgent 对话框里输入“帮我复盘下夜间加价策略上线后这两周的应答率变化重点看一线城市如果有下降的城市帮我分析原因。”Agent 的执行过程大致是这样的先解析出时间范围“策略上线后两周”目标指标“应答率”维度“城市、策略类型”筛选条件“一线城市 加价覆盖订单”。容易发现“对比什么”这个槽位缺失于是自动追问“需要和策略上线前一周对比吗”运营确认后进入执行。Agent 会并行创建两条查询任务一条查上线前后两周的应答率序列一条按城市维度做同环比对比。两组数据回来后归因引擎先做整体显著性判断发现应答率整体提升 1.8%但深圳同比下降 1.2 个百分点进入异常归因流程。随后 Agent 继续查询深圳的供给指数和用户取消率发现万单司机在线时长下降 8%同时取消率上升 0.5%结合原因词条库匹配到“夜间运力供给不足”这条原因生成解释“深圳夜间应答率下降主要受供给端影响司机在线时长明显下滑运力缺口扩大。”最后报告自动生成核心结论放最前面附上查询 SQL、数据来源表、归因推理链和策略建议建议从历史方案中召回“夜间任务补贴”“热区调度倾斜”两个相关策略供运营评估。从提问到报告生成整个过程耗时约两分钟而过去人工做同样的事至少需要半天。4. 踩过的坑与排查实录4.1 Text-to-SQL 准确率从 72% 到 88% 的优化过程上面提到初版 Text-to-SQL 准确率只有 72%我把踩坑细节展开说因为这可能是大多数团队会遇到的第一个技术瓶颈。我们当时统计了一批失败样本按原因分类后大致是这样失败类型占比典型表现表选择错误34%想查应答率却关联了订单详情表和司机信息表导致聚合粒度错乱字段选择错误22%把“用户取消率”写成“司机取消率”口径完全不一样过滤条件缺失19%忘记加城市或时间过滤查出来的是全量数据值格式不一致11%城市名写法、日期格式混用查不出结果聚合粒度错误8%按司机粒度聚合却想得到订单口径的结果其他6%语法问题、模型理解偏差等表选择错误占比最高这和我们最初把所有表结构都丢给模型有关。解决方式前面说过就是引入指标平台做 schema linking让模型在动手前先拿到一个“本次查询只需要哪几张表”的白名单。字段选择错误则靠指标字典中的字段别名和同义词来解决例如在字典里维护“应答率 应答成功订单数 / 呼叫订单总数别名含响应率、接单率在表 order_wide 的 respond_order_cnt 字段”模型拿到的信息越精确胡写的概率越低。三个月迭代下来我们把准确率从 72% 提到了 88%。这个 88% 不是一个特别惊艳的数字但它刚好够用剩下的 12% 错误基本都能被自动校验或人工复核发现不至于影响复盘结论的正确性。如果哪天运营对某个数据有疑问报告里有一键跳转到原始查询的功能可以查看到完整的 SQL 和参数透明度也建起来了。4.2 数据权限隔离Agent 能看什么必须可控数据权限是 DataAgent 上线前被安全团队卡得最严的一块。策略复盘数据涉及核心业务数据不同城市运营只能看自己城市的数据不同管理层级能看的粒度也不同这些问题不能因为接入了智能体就推倒重来。我们在权限设计上遵循一个原则Agent 只是一个执行者它本身不拥有任何超过用户本人的数据权限。落地方式是在工具层统一做权限注入——用户登录后系统获取该用户的数据权限范围生成一个权限上下文注入到每一次查询的前置过滤条件中。比如一个负责深圳的运营发起查询Agent 生成的 SQL 会被自动追加“city Shenzhen”的条件不管用户的提问里是否显式声明了城市。这么做最大的坑在于如果用户在问题里故意问“对比其他城市”Agent 生成的 SQL 和权限注入条件就会冲突。我们专门处理了这类场景做法是权限条件作为最高优先级永不覆盖。如果问题里的筛选条件和用户权限不符Agent 会先提示“你无权查看该城市数据”而不是带着用户绕过权限查询。涉及个人补贴明细等敏感字段时工具层还会做脱敏处理即使 Agent 查到数据展示层也只返回聚合结果不返回明细。4.3 幻觉治理没有数据支撑就不准下结论复盘报告的价值建立在“每一条结论都有数据支撑”这个前提上。但 LLM 天然有“一本正经胡说八道”的倾向哪怕我们设定了严格的工具调用规则它偶尔还是会发挥想象力。我们在一次内测中遇到了一个典型事故。运营问“司机完单率为什么下降”Agent 生成报告时写了一句“司机活跃度下降参与接单的司机数量减少”。事实上当天司机活跃数并没有明显变化完单率下降的主要原因是一批低价订单的接单率变低而不是司机数量减少。这句话就是典型的无依据推断模型看到“下降”就自动联想了一套叙事。从那以后我们给报告生成加了一条硬规则任何归因结论都必须携带对应的数据特征引用。比如“司机在线时长下降 8%”这句必须来自在线时长指标的查询结果而不是模型自己补的。具体实现是在归因引擎里定义数据特征模板模板里每个结论槽位都要求填数据指标名和数值LLM 只能在这个结构里润色语言不能新增结论条目。还有一条防线是“拒绝回答”。如果 Agent 发现某个归因方向没有可查的数据字段支撑它必须明确说“当前数据无法解释该变化可能原因包括 A、B、C需要补充 XX 数据”而不是硬编一个原因。这条经验很重要有时承认不知道比给一个错误结论更显专业。4.4 评估集与长期维护机制做 DataAgent 和做传统分析系统的本质区别之一是它的行为是概率性的所以必须有持续评估机制否则版本更新后某个能力突然退化都没人发现。我们构建了一个复盘场景评估集从过去一年真实的人工复盘中抽样了 200 条需求每条需求对应标准的查询计划和预期结论。评估时Agent 依次执行这些需求分别考核任务成功率、指标命中率、SQL 正确率和报告可用率四项指标。任务成功率指 Agent 能在 5 轮工具调用内完成整个流程指标命中率看最终报告中的指标是否和标注一致SQL 正确率靠结果集比对实现我们在评估集里预存了正确答案报告可用率则是抽样让人工打分考察结论是否清晰、归因是否成立、建议是否可执行。评估集建好后我们跑了定期回归每两周跑一次全量评估任何一次升级都要保证四项指标不下降才能发上线。这个机制看起来投入不小但对 Agent 类系统来说这笔投入不能省因为它相当于给大模型这个“概率性组件”加了一道确定性保险丝。另一个长期维护项是知识库的持续更新。指标口径会调整、策略方案会迭代、异常原因会出现新类型如果知识库不跟着更新RAG 迟早会基于过时信息给出错误结论。我们把知识库更新纳入日常维护流程每月梳理一次口径变更记录每季度复盘一次原因词条库的有效性删除已经不再适用的词条。4.5 常见问题速查表现象可能原因排查思路解决建议Agent 生成的 SQL 查不出数据指标字段名与库表实际字段不一致对比指标平台元数据和数据库字典统一字段别名映射查询前做字段锚定复盘报告中出现无依据结论任务规划阶段未强制工具调用检查报告生成链路是否给模型留出自由发挥空间增加结论槽位、强制引用数据指标用户跨城市串数权限上下文没有注入查询前置条件检查工具层权限拦截逻辑通过中间件统一注入行级权限不依赖模型自纠指标口径不一致前后报告对不上RAG 未检索到最新口径定义检查知识库版本和向量化更新时间建立口径更新机制检索时标注版本时间Agent 追问过多用户体验差意图槽位策略过于保守分析对话日志评估哪些槽位可以默认推断根据历史记录配置默认值必要时才澄清查询速度慢尤其是多个城市并行下钻串行调用工具未做并行拆解排查工作流是否支持并行分支执行在编排层设计并行分支归因前先并行取数这张表是我们内部维护知识库的一部分几乎每周都会新增一两条真实案例。把现场问题沉淀成可检索的排查手册是 Agent 项目长期运行的重心因为它能让团队在面对新问题时快速定位而不是每次都从头开始试错。最后说一个个人体会比较深的事DataAgent 上线后最明显的改变不是省了多少人力而是策略运营团队开始把“数据验证”当成日常习惯了。以前他们有了一个策略想法会先凭经验判断值不值得做现在会直接打开 DataAgent 查历史数据支撑因为问起来太方便了。对一个数据团队来说这大概就是做智能体最有成就感的回报——不是替代分析师而是让每个做决策的人都能用分析师的方式思考问题。