如果你在货运平台做过策略运营大概率经历过这样的深夜调度策略上线两周完单率涨了、投诉率也涨了业务负责人望着大屏问了一句“这周策略到底行不行”。分析师转头开始拉工单、写 SQL、翻维度表凌晨两点交了一份结论靠猜的复盘报告。我们做货拉拉 DataAgent 的初衷很简单——把这块“人肉复盘”里最耗时、最容易出错的部分交给一个懂业务口径、会调用数据工具、能自己形成分析链路的智能体来干。这篇内容会从痛点、架构、核心实现、踩坑实录几个角度把整个实践过程摊开聊一遍。1. 从人肉复盘到 DataAgent一次策略复盘方式的改造1.1 传统复盘到底慢在哪货运平台上的策略复盘比如运力调度策略、订单匹配策略、用户补贴策略和普通互联网产品的流量复盘不太一样。它更依赖线下配送场景的离散数据司机位置、货物重量、车型偏好、路线拥堵情况、天气、节假日甚至一个批发市场的营业时间都会影响指标走势。一个策略上线后复盘要看的东西往往是一张二维表搞不定的——先看核心指标有没有达到预期再看细分城市、车型、时段、司机活跃度有没有结构性偏移最后还要判断这些变化到底是策略本身带来的还是外部因素叠加造成的。传统流程里分析师拿到复盘需求后第一步先确认口径转化率分子分母是什么完单率要不要排除取消单补贴 ROI 的口径跟财务是否一致。这步通常要问三个人。第二步写 SQL在离线数仓和实时 OLAP 引擎之间来回切写错一个 join 条件结果就全偏了。第三步做可视化用 BI 工具把趋势图和下钻表拼在一起这个过程极其枯燥。第四步才是写归因分析而这一步基本靠经验和感觉。所以真正耗时的不只是取数而是“口径确认、数据验证、归因推理”这三件事缠绕在一起。我们当时统计过一次中等级别的策略复盘分析师平均要花 2 到 3 个工作日其中约 60% 的时间花在取数和验证数据上真正用来思考业务结论的时间不到 20%。这是个很讽刺的事情人是被数据和工具绑架了而不是在分析。1.2 DataAgent 不是“ChatGPT 套壳”而是一条分析流水线很多人听到 DataAgent 的第一反应是把那段时间很火的对话式 BI 接上大模型用户问一句系统答一句。我们一开始也差点这么做后来发现完全不够。策略复盘不是单轮问答它是一个多步骤分析过程。你问“华东区调度策略效果怎么样”你真正需要的是一组分析链条先确认这次复盘的对象和实验范围再对比上线前后核心指标再看不同维度的分化再检测异常波动再做归因最后生成一份结构化的复盘报告。单独靠 ChatBI 那种“问一句答一句”的模式没法保证分析链条完整大模型很擅长在中间步骤偷懒——问它指标为什么波动它会一本正经告诉你“可能是市场竞争加剧”这种回答没有任何数据支撑也完全没有运营价值。所以 DataAgent 在我们这里的定位是大模型做任务拆解和表达底下的数据系统做计算知识库做口径约束最后用报告模板兜底。大模型不是一个什么都会的超级分析员而是一个“阅读理解能力很强、但必须按规矩办事的分析流水线调度员”。这个定位决定了后面的所有架构设计。2. 整体架构拆解四个层各干什么2.1 任务编排层把“复盘”变成可执行的工作流我们首先做的不是训练模型、不是调接口而是把“策略复盘”这件事彻底结构化。这个步骤太关键了如果你连复盘流程都定义不清楚后面什么 Agent 都白搭。我们梳理了货运场景下最常见的一类复盘策略上线后的周期性效果复盘。标准步骤是数据范围确认确定策略覆盖的城市、车型、时间区间找出对照组或基线。核心指标总览拉取单量、完单率、应答时长、司机活跃度、补贴成本等核心指标的时序数据。差异对比策略上线前后对比、实验组与对照组对比、不同细分维度对比。异动检测找出哪些指标、哪些维度发生了什么时间段的变化。下钻拆解按城市、车型、车型承接方式、司机新老、用户分层等维度逐层拆。归因分析结合内外部数据给出候选原因区分策略因素和外部因素。结论与建议输出结构化结论以及下一步是否调整策略的方向。任务编排层的核心是一张复盘模板表。每一类复盘对应一个模板模板里定义好需要执行哪些分析步骤、每步调用什么工具、步骤之间的依赖关系是什么。DataAgent 接收到用户输入后先用大模型做意图识别把输入映射到最接近的模板然后按模板执行工作流。有人会问为什么不直接让大模型自由发挥、自己决定每一步干什么那样看起来更“智能”但我们试过之后发现自由发挥在大模型场景下等于不可控。Step 2 的分析还没做完它可能就跳到 Step 6 给你下了一个听起来很有道理、但前因后果全没验证的结论。用模板不是为了限制智能而是为了保证分析过程可验证、可审计、可复现。2.2 工具层大模型只当调度员不当计算器工具层解决的是一个很朴素的问题大模型不擅长精确计算我们就不让它算大模型不擅长写准确 SQL我们就不让它直接写。我们实现了一套工具注册机制每个工具就是一个可以被 Agent 调用的函数带输入输出参数、必要权限校验、日志记录。常用的工具有这么几个指标查询工具接收指标 ID、维度组合、时间范围返回聚合后的数据表。异动检测工具输入时间序列输出显著变化的时间点和变化幅度。维度下钻工具输入指标和父维度自动计算各子维度贡献度。实验对比工具输如实验组与对照组数据输出显著性检验结果。报告渲染工具接收结构化的分析结果 JSON渲染成 Markdown 报告。工具层的设计原则是每个工具只做一件简单、确定的事情包括计算逻辑也必须确定。比如异动检测我们用的是 Z-Score 加滑动窗口而不是让大模型靠“感觉”判断哪个波动值得注意。大模型在这里只负责根据模板决定调用哪个工具、按什么顺序调用、从工具结果里抽取关键信息。这就像你给实习生安排活你负责告诉他“先看趋势再拆城市”但具体加总、排序这件事必须靠 Excel 函数完成不能靠心算。2.3 语义层与知识层把业务口径和数据模型喂给系统策略复盘最大的隐性成本是口径不统一。同一个“完单率”在调度组和财务组的定义可能不一样同一个“活跃司机”可能包含注册了但从未接单的司机。如果 DataAgent 不理解这些口径它生成的结论就是空中楼阁。我们在 DataAgent 里做了一个指标字典和一个维度字典。指标字典记录了每个指标的业务口径、对应数仓表字段、聚合方式、是否去重、常见拆分维度。维度字典则记录了城市、车型、司机分层等维度的取值含义和层级关系。这两个字典被注入到大模型的 Prompt 上下文里同时也在 SQL 生成层做了硬约束。知识层则更进一步把历史复盘报告、策略上线记录、常见归因案例沉淀成知识条目。例如“雨天对完单率的影响”“节假日前后司机活跃度波动”这类经验性知识。当 DataAgent 做归因分析时不是完全凭大模型训练集里的通用知识而是优先检索知识层里与当前场景匹配的案例。这能显著提高归因的合理性和可解释性。这里有一个很关键的设计语义层和知识层是分开的。语义层负责让大模型“看得懂”数据知识层负责让大模型“想得起”经验。如果混在一起Prompt 会非常臃肿而且每次检索都会把大量无关知识灌给大模型反而干扰判断。3. 核心环节的实现细节从一句提问到一份报告3.1 第一步意图识别和复盘模板匹配用户输入的一句话可能是“帮我复盘一下华南区域调度新策略”“最近完单率掉了分析下原因”“给我拉一下上周的补贴数据”。这三句话背后的需求截然不同第一个是完整的策略复盘第二个是异动归因第三个是普通取数。DataAgent 不能一律用复盘模板处理。我们让大模型根据三个要素做意图分类对象策略/指标/普通查询、动作复盘/分析/取数/归因、约束条件时间/地域/车型。分类结果是一段结构化 JSON例如{ intent: strategy_review, target_strategy: yunli_dispatch_v2, region: south_china, time_range: { start: 2025-01-01, end: 2025-01-14 }, need_attribution: true }拿到这个结构化结果后我们不是直接吞掉而是回传给用户确认一遍“您是要复盘华南区域调度新策略 v2 近两周的效果吗是否需要包含归因分析”这一步看着多余实际上极大避免了后期分析做歪。特别是货运业务里同一个策略可能在不同城市、不同车型上同时跑不先对齐范围后面所有数据都可能是错的。匹配模板时我们用规则优先、大模型兜底。也就是说先根据策略 ID 和指标 ID 查模板表如果没查到再让大模型在历史模板里做语义匹配。这能避免大模型因为脑补而“创造”出一个不存在的模板。3.2 第二步指标查询与自然语言转 SQL 的稳妥做法自然语言转 SQL 是很多数据智能体最兴奋也最容易翻车的点。我们内部做过一个测试让大模型直接针对数千张表写 SQL在离线测试集上准确率能做到 78%。听起来还行但你要知道线上业务里一个 SQL 错误轻则查错数重则权限绕过、数据越权而且用户根本不知道答案算错了。78% 的准确率在生成场景里是几乎不可用的因为错误会以非常隐蔽的方式出现。所以我们没有走“大模型直接写完整 SQL”这条路而是设计了**“语义解析 模板填充 白名单校验”**的稳妥链路。第一步把用户描述的口径映射到指标字典。例如用户说“完单率”系统会匹配到指标finish_rate并通过指标字典找到它的计算口径是“已完成订单数 / 应答订单数”涉及的字段是order_finish_ts、order_accept_ts。这一步直接用字典的 ID 映射不用大模型自由发挥。第二步把维度条件映射到维度字典。例如“华南区域”会被识别为region_codeSC的过滤条件具体城市列表也来自维度字典维护的映射表。第三步根据查询模板拼接 SQL模板中把指标 ID、时间范围、维度字段、聚合方式、过滤条件作为参数填充进去。第四步SQL 生成后做一层白名单校验检查查询只涉及预授权表且权限范围不越过用户所属层级。这里给出一个简化版的模板示例SELECT {{dimension}}, SUM({{metric_expression}}) AS metric_value FROM {{authorized_table}} WHERE partition_date BETWEEN {{start_date}} AND {{end_date}} AND {{region_filter}} AND {{other_filters}} GROUP BY {{dimension}} ORDER BY metric_value DESC LIMIT {{limit}}这套做法牺牲了一部分“自由度”但换来了可审计性。用户看到的不仅是最终报告还能看到系统执行查询时用到的 SQL 和口径说明。一旦数据结果有疑问可以直接检查取数过程而不是对着黑盒答案干瞪眼。3.3 第三步异动检测与维度下钻指标查询结果回来后DataAgent 不会直接拿给大模型做文字解读而是先跑异动检测。我们选的是一个比较简单、业界常用的方法对时间序列计算滑动窗口内的均值和标准差用 Z-Score 识别显著性波动。同时对关键节点策略上线日做前后对比看指标是否出现断点效应。举个例子假设调度新策略在 1 月 5 日上线我们会对完单率时间序列做如下判断上线前 7 天均值是 85.2%上线后 7 天均值是 88.6%相对变化 3.99%。上线当天 Z-Score 为 2.3超过阈值 2视为显著变化。但与此同时1 月 5 日所在城市开始下雨所以不能直接归因为策略效果。异动检测的价值在于它把“肉眼找波动”变成“算法找波动”而且结果是一组可量化的数据事实。大模型在后续归因时只能基于这些事实说话不能自己编一个新的“波动”。维度下钻则基于贡献率分解。比如我们发现完单率整体下降需要看是哪些城市拖累的。系统会自动按城市维度计算每个城市的指标值和权重并结合整体均值差计算贡献度。这能很快定位“主要问题在城市 A 和城市 B”而不是笼统地说“部分地区表现不好”。下钻支持多级维度链区域 → 城市 → 城市内商圈 → 司机活跃分层。每一级下钻都保留上层的上下文最终形成一个多维分析结果集。这类多级下钻如果交给大模型自由发挥很容易出现中间环节丢失或维度选择跳跃的问题所以我们把它设计成模板里定义好的固定步骤。3.4 第四步归因与报告生成怎么让结论靠谱归因是整个策略复盘里最难的部分也是 DataAgent 价值最容易被质疑的部分。大模型天生爱讲故事你问指标为什么涨它能给你编出五条振振有词的原因但每一条可能都没数据支撑。我们的解决方案是**“让归因从讲故事变成拼证据”**。第一层归因是数据证据层。系统把异动检测、维度下钻、实验对比的结果整理成事实清单。比如“完单率从 85.2% 提升至 88.6%提升 3.4 个百分点”“华南区域贡献了 70% 的增量其中深圳单城贡献 35%”“上线前后司机应答时长无显著变化”“上线期间华南区降雨天数 4 天去年同期 2 天”第二层归因是知识联想层。DataAgent 从知识库中检索与这些事实匹配的案例。比如知识库里有一条“降雨天气会导致用户叫车意愿上升但司机出车率下降可能对冲完单率”。这条知识与当前场景匹配会被提取出来作为候选解释。第三层才是大模型生成层。我们要求大模型只能基于第一层的事实清单和第二层的候选解释来生成归因内容并且每个结论后面必须标注数据依据。如果数据清单不足以支撑某个结论那就必须明确写“无法从当前数据判断”而不是硬凑一个理由。报告生成则更进一步。我们定义了一个固定 JSON 结构包含背景、数据范围、核心指标变化、维度拆解、异动清单、归因分析、下一步建议等模块。大模型的工作不是自由写文章而是把前面各环节产出的结构化结果“翻译”成通顺的中文。这就极大降低了幻觉风险。我们在 Prompt 里加了硬性约束报告中的所有数字必须来自于传入的数据字段不允许生成任何未在数据中出现的数值。同时会做一道校验环节解析生成报告里的每一个数字与数据字段逐一核对不一致就打回重写。这个机制看着笨但很有效。4. 落地效果与踩坑实录4.1 效果复盘时间从 2 小时到 15 分钟在完成第一个可用的 DataAgent 版本后我们拿了过去 30 份历史策略复盘请求做了一次回放测试。测试方式是让 DataAgent 重新执行这些复盘任务并让资深分析师对照原报告检查结论完整性和数据准确性。结果有几个数据可以分享单次策略复盘的平均耗时从分析师人工的 2~3 天缩短到 15 分钟左右其中大部分时间花在数据查询和异动检测的等待上。报告结构完整度显著提高原先人工报告经常漏掉的“口径说明”“外部因素排除”DataAgent 会按模板强制输出。数据准确性上完全由 DataAgent 跑出的数据错误主要来自底层表和字典映射不全而不是计算错误。因为我们的工具层把计算交给了确定的代码大模型没有机会“创作”出错误数字。我们并没有直接用 DataAgent 完全替代分析师。目前的实际使用模式是DataAgent 先产出一份结构完整、数据基本可信的复盘初稿分析师在初稿基础上做校准、补充业务判断、决定下一步动作。这样既保证了效率又留出了人的判断空间。4.2 踩坑一NL2SQL 的准确率陷阱刚才提到我们一开始也让大模型直接写 SQL测试集里准确率 78%。这个数字误导了我们因为在测试集里模型生成的 SQL 大多数是“部分正确”的——指标对、维度对但限制条件漏了一个玩家身份过滤或者 join 方式写错。这种错误在测试集上不容易被察觉因为部分正确也能跑出结果只是结果不对。我们花了大量时间建了一个更贴近真实场景的校验体系把每条 SQL 放到执行计划层做逻辑校验并与人工标注的预期结果对比。发现直接生成的方案很难达到 95% 以上的准确率而且每提升一个百分点都要投入大量人工调 Prompt。后来我们决定改路线用“模板 参数抽取 白名单校验”替代端到端生成。效果立竿见影准确率稳定在 95% 以上而且每次查询过程都可解释。这条路线的代价是用户不能随心所欲地问一些非常规分析问题比如“写一段 SQL 查一下司机和一小时内连续接三单的关联关系”。但我们评估后发现在策略复盘这个场景里绝大多数查询都落在模板可覆盖的范围内。真正复杂的一次性分析仍然由分析师用专业工具完成DataAgent 负责处理高频、重复、标准化的那部分。4.3 踩坑二大模型的“万金油归因”第一次把归因模块带上线时我们发现生成结论里有大量类似“由于市场竞争环境变化导致指标出现波动”的废话。这类句子在排版上很正式但战略价值为零因为它没法指导下一步行动。追问上去大模型自己也说不清楚哪个市场、哪种竞争、变化了多少纯粹是训练语料里的高频套话。我们把这类“无依据归因”作为重点攻击对象。第一轮修正是在 Prompt 里禁止使用模糊词语效果一般模型换个说法照样编。第二轮修正才起了作用——强制归因结论必须引用证据列表中的一条或多条并且证据列表本身必须来自数据工具层所以模型根本没有空子可钻。例如模型可以说“深圳区完单率提升主要受策略覆盖范围扩大影响证据是策略覆盖司机数较上线前提升 18%”但它不能说“市场环境变化”因为证据列表里没有这个数据。这个调整对报告质量提升是决定性的。后面我们复盘时发现分析师最不满意的不是数据慢而是结论不痛不痒。DataAgent 现在产出的归因至少每条结论都有具体数据指向哪怕最后被业务否定也会引出一条新的排查方向。4.4 踩坑三权限与安全没有捷径数据智能体本质上是一个能自动执行查询的“超级分析师”权限问题处理不好就是重大事故。我们在试运行阶段就遇到一个案例一名策略运营在对话里询问“上海地区平台司机总收入”但该运营岗位本身没有权限查看收入类敏感指标。由于我们最早版本的意图识别只做了模板匹配没有在工具调用前做指标权限校验系统竟然真的把数据查出来了还好是在测试环境被拦住了。从那之后我们把权限校验放到了工具调用链的最前端形成三层保护请求层确认当前用户身份、所属组织、角色。指标层指标字典中维护数据权限矩阵哪些角色可看哪些指标。数据层SQL 生成时自动注入行级权限条件比如普通城市运营只能看自己负责的城市全国运营才能看全部城市。同时所有 Agent 产生的数据查询都会完整记录日志包括用户输入、意图识别结果、生成的 SQL、工具返回结果、最终报告。一旦出现违规查询可以直接回溯。这个能力在 DataAgent 真正进入业务推广时非常重要——没有审计就没有信任。5. 给打算做同类系统的团队一些可复用的建议5.1 场景选择满足这三个条件再动手不是所有数据场景都适合做 DataAgent。我们做完后发现最适合的切入点通常满足三个条件流程高度标准化每次分析的任务步骤差不多可以提炼成模板。策略复盘就是一个典型指标固定、维度固定、步骤固定。问题重复发生如果你经常被问到同一个类型的分析问题做成自动化的回报率才足够高。如果每次都是全新问题DataAgent 还没学会就被新的需求淹没了。结论可量化、可校验分析结果必须能被人工或规则验证。如果问题的答案本身没有标准那大模型生成得再溜你也无法判断对错。我们见过不少团队一上来就选了一个极其开放的场景比如“全业务指标自助分析平台”结果用户问的问题千奇百怪Agent 的准确率一路崩到没法用。建议先从单一业务、单一类型的复盘入手比如“营销活动复盘”跑通之后再横向扩展。5.2 技术路线能上工作流就别一上来搞自由 Agent很多团队做 Agent 的第一步就是接一个 ReAct 框架让大模型不断思考下一步调用什么工具然后循环往复。这个思路在 Demo 阶段很容易出效果因为大模型很擅长“看起来在思考”。但生产环境遇到多步骤、长上下文、强校验的需求时自由 Agent 很容易失控——上下文越滚越长前面的关键信息被遗忘工具调用顺序漂移最后产出的结论跟用户需求差十万八千里。我们的建议是优先用模板化工作流把 Agent 的“自由度”限制在一个可控围栏内。你可以保留 ReAct 的能力但只用于模板里某个具体步骤的参数补充比如识别的维度不明确时让大模型先追问用户一个澄清问题。而不是让大模型从第一步到第七步都自己决定。只有当你积累了大量稳定工作流之后再去尝试把一个复杂任务分解成多个子 Agent 的协同模式这样风险会小很多。5.3 评估体系没有黄金测试集就没法优化DataAgent 这类系统的难点在于它生成的是一个完整分析报告不是单个答案所以评测不能只看“SQL 对不对”还要看“整个分析过程完不完整”“结论有没有依据”。我们建了一个由 20 个真实历史复盘案例组成的黄金测试集每份案例都有人工标注的标准步骤、关键事实和最终结论。每次迭代版本后都会跑一遍黄金测试集用四个维度评分流程完整性有没有漏掉模板定义的分析步骤。数据准确性报告里的数字与标注数据是否一致。归因合理性每条归因是否有证据支持是否出现“万金油”表述。可用性分析师拿到初稿后还需要多少改动才能发布。老实说这个测试集量不大但价值很高。因为每一轮优化都能量化比如从上一个版本到这版归因合理性从 6 分提高到 8 分就能判断是哪次 Prompt 修改带来了收益。如果没有这套评测你只会陷入“感觉效果变好了”的玄学循环。5.4 常见问题速查表问题排查思路推荐解法生成的 SQL 查出的结果和人工核对不一致先查指标字典口径映射是否正确再看维度过滤条件是否缺失由白名单校验自动拦截非法字段生成前展示口径说明报告结论都是“市场环境变化”这类废话归因阶段没有强制引用证据列表增加证据约束结论必须引用至少一条数据事实Agent 执行步骤顺序漂移大模型自由决策范围过大改用的模板工作流限制每一步的候选项用户数据越权查询工具调用前没有做权限校验在指标层和数据层都做权限过滤并记录审计日志模型生成报告漏了一个分析模块模板输出约束不够用结构化 JSON 输出并对必填字段做校验同一个问题两次跑出的结果不同大模型采样参数没有固定推理时关闭随机性或在关键环节缓存结果这些问题是我们在真实上线过程中踩过或见过的如果你的团队也在做 DataAgent大概率会提前遇到。别慌按表格里对齐排查能省不少时间。6. 写在最后我的几点真实体会这个项目做下来我最大的感受是DataAgent 带给大家的想象力远远超过了当前的可靠上限但它确实能把一些苦活、累活、标准化活做得很扎实。策略复盘过去靠人肉现在变成人机协同分析师从“取数机器”回归到“业务判断者”这才是智能化的真正价值。我个人在实际操作中有一个很深的体会别让大模型做它不擅长的事也别因为大模型“看起来能做”就放任它自由发挥。真正好用的 DataAgent与其说是一个无所不能的智能体不如说是一条把大模型、数据工具、业务知识和流程模板拧在一起的流水线。它该聪明的地方聪明该老实的地方老实。最后再分享一个小技巧如果你计划在团队里推广 DataAgent一定要从第一天就设计好用户反馈入口。我们早期版本做完报告后只是干巴巴地输出用户没地方说“这里不对”。后来加了“纠错”和“点赞”按钮并把纠错内容自动回流到知识库样例中准确率提升速度明显加快。数据智能体是一个持续进化的系统它最好的养料就是真实业务里那些让人挠头的反例。做这类系统的乐趣也正是如此它不是一次性交付的软件而是一个每天和分析师一起变聪明的同事。这条路还很长但至少我们证明了一件事——策略复盘这活真的可以不再是深夜加班的那种体力活。