DataAgent实践：用大模型自动化策略复盘全流程

做过策略的同学估计都有这种体验：一听到"复盘"两个字，整个人就像被拖进了一个取数黑洞。先翻表找字段，再等一个跑起来动辄十几分钟的SQL，中间还要反复和业务核对口径——等数据终于齐了，写报告的力气已经耗掉一大半。货拉拉的策略团队以前就是这样，尤其做动态调价、调度策略、司机补贴的同事，一天下来大量时间都耗在"取数-核对-归因-写报告"这套流程里，真正用来思考策略本身的时间反而被严重压缩。

后来我们开始尝试用 DataAgent 来把这整条链路自动化。DataAgent，说白了就是让大模型当一个"数据兼分析助理"：你用人话说出复盘需求，它自己去定位指标、查数、做归因分析，最后生成一份可以直接拿去周会讲结论的复盘报告。听起来有点科幻，实际落地之后，效果比我预想的还要好。

这篇文章就把我们在货拉拉做 DataAgent 的实践经验完整讲一遍：整体设计怎么拆、核心模块怎么实现、拿一个真实的动态调价策略跑复盘是什么效果，以及那些只有踩过坑才记得住的教训。

1. 为什么货拉拉需要 DataAgent 来做策略复盘

1.1 策略复盘到底在复什么盘

要理解 DataAgent 的价值，先得搞清楚货拉拉这边的策略复盘具体在做什么。货拉拉同城货运的业务，核心是连接用户和司机两端，策略团队围绕这个双边市场做了很多实时或近实时的策略动作，最常见的有几类：

• 动态调价策略：某个区域在高峰时段供需失衡时，系统自动上调价格，用价格杠杆激励更多司机往热点区域跑，同时也能调节用户端的叫车需求。
• 调度派单策略：订单进来之后，按什么规则分发给哪个司机，是抢单逻辑还是指派逻辑，涉及距离、司机评分、忙闲程度等多个权重因子。
• 补贴激励策略：给新司机做拉新奖励、给用户发优惠券、给特定时段设置完单奖励，这类策略直接动成本，复盘时必须把"钱花得值不值"讲清楚。
• 排队和推荐位策略：司机在机场、批发市场等热点区域的排队规则，以及用户端首屏推荐车型的排列逻辑，这些对平台撮合效率和用户体验都有隐性影响。

所谓复盘，就是把某个策略跑了一段时间后的实际效果拉出来，对比开策略之前、或者对比实验组和对照组，回答三个问题：策略有没有用、效果有多大、成本可控不可控。同时还要往下拆，搞清楚效果到底来自哪个人群、哪个区域、哪个时段，为下一轮策略迭代提供依据。

1.2 传统复盘流程的三大现实痛点

在过去很长一段时间里，策略复盘基本靠"人工拧螺丝"，核心痛点总结起来有三个：

第一个痛点是数据取用门槛高。货拉拉的指标散落在数仓各个层级，底层明细表量级很大，中间层做了很多汇总但口径又没有完全统一。分析师提数时，得先搞清楚"应答率"这个字段到底用的是宽口径还是窄口径，司机收入是含补贴还是不含补贴，订单 GMV 按什么时间归属。这类问题每次复盘都要重新确认一遍，流程非常低效。

第二个痛点是归因分析严重依赖个人经验。数据拿出来了，指标涨跌到底是策略带来的还是自然波动？是某个城市爆单拉高了全局，还是某个司机群体流失拖了后腿？传统做法是分析师凭经验猜一个维度，写SQL去验证，猜不对再换一个，效率低不说，还容易漏掉真实的异常点。

第三个痛点是复盘报告产出慢。一次常规策略复盘，从提数、清洗、做透视表到写PPT，熟练的分析师也得小半天。临时被业务追问一个数据口径，又得打断重新查，等报告真正能见人的时候，策略环境可能又变了。复盘这件事，硬生生从"决策支撑"变成了"事后总结"。

这三个痛点叠在一起，让我们意识到：与其教所有人写SQL，不如让机器学会理解业务语言、自己完成整条分析链路。DataAgent 就是奔着这个目标去的。

2. DataAgent 的整体设计思路

2.1 DataAgent 到底是什么角色

先给 DataAgent 定个位。我们内部对它的定义不是"一个会写SQL的聊天机器人"，而是一个按分析流程组织起来的智能体系统。它像一位熟悉业务的初级分析师：听得懂人话，知道去哪张表拿数，拿到数之后会做基本的多维拆解，最后还能把分析过程整理成结构清晰的报告。

从技术构成上看，它是一个以 LLM 为推理核心、以一系列数据工具为执行手段的 Agent。LLM 不直接连接数据库，而是通过"函数调用"的方式调用工具层——例如查指标、跑SQL、做维度下钻、生成图表、组装报告。每调用一次工具，Agent 就能获得一个客观结果，然后根据结果再决定下一步做什么，不断迭代直到满足用户需求。

这个"工具调用 + 循环推理"的模式，是 DataAgent 和普通问答机器人的本质区别。普通问答机器人是"你问一句，它答一句"，答完了就完事；DataAgent 是"你给一个目标，它拆解成多个步骤，重复执行直到目标完成"。

2.2 复盘链路怎么拆成 Agent 可执行的模块

策略复盘这条链路，拆开来看其实有非常清晰的流水线特征。我们把它切成五个环节：

意图理解：用户输入一句自然语言，比如"看一下上周三华东区域动态调价策略的复盘，重点看应答率和GTV变化"。这一步要解析出的信息包括时间范围、业务范围、策略对象、需要关注的指标。

指标检索：根据解析出的业务语义，在指标注册中心里找到对应的指标定义、口径、可支持的下钻维度。这一步是防止 LLM 凭空造指标名和口径的最关键屏障。

数据提取：生成查询计划并转成 SQL，在数据仓库中执行，把结果拉回来。考虑到货拉拉的数据量级，这一步通常要落到预聚合表或者OLAP引擎上。

归因分析：对前面提取的指标结果做多维拆解。比如 GTV 涨了，Agent 会尝试拆成完单量乘客单价，再往下拆城市、时段、车型、司机类型，找出主要贡献因子。

报告生成：把分析过程、关键数据、归因结论按固定结构组装成报告，同时标注数据来源和时间范围，保证结论可溯源。

我们最初也想过直接让 LLM 一步到位生成复盘报告，但实测下来不可靠。原因很简单：LLM 的强项是语义理解和内容组织，而不是靠记忆做精确计算。要想拿到可信的分析结果，必须把"思考"和"执行"分开——模型负责判断该做什么，工具负责精确执行，每次执行结果再喂回给模型作为下一步推理的依据。

2.3 为什么 Agent 化比固化报表更合适

可能有人会问：这东西听起来像是个BI看板或者自动化报表，为什么不直接做一堆固定报表呢？

这个问题的答案，恰好是 DataAgent 能成立的核心原因。固定报表适合高频、标准化的查询，比如每天看核心指标大屏，这类需求 SQL 早就写好了，没必要让大模型参与。但策略复盘这场景恰恰相反：

一是每次复盘的问题都不一样。今天看华东动态调价，明天看华南新司机补贴，每次关心的指标、维度组合、时间粒度都不同，固定报表根本覆盖不过来。

二是复盘过程是交互式和探索式的。分析师拿到第一轮数据之后，通常会追问一句"这个异常是不是由某类车型导致的"，这是一个多轮推理链条，需要系统记住上下文并动态调整分析方向。这是传统报表完全做不到的。

三是策略复盘对口径透明度要求极高。固定报表一旦口径配错，业务会拿着一份漂亮的图表讲出完全错误的结论，排查起来还很隐蔽。而 Agent 方案可以通过语义层显式地暴露口径定义，用户能直接看到自己查的指标是怎么算的。

所以我们的结论是：固定报表管"日常监控"，DataAgent 管"一次性的深入分析"。两者不是替代关系，而是互补关系。

3. 核心模块的工程化实现

3.1 语义层建设：让 Agent 听得懂业务语言

整个 DataAgent 能不能干活，第一个前提就是有没有一个可靠的语义层。我们内部叫"指标注册中心"，它本质上是业务指标口径的权威登记表。

语义层里每一条记录都包含几个关键部分：

• 指标名称：中文名和英文名，比如"应答率"对应 response_rate。
• 同义词列表：业务同学常说的"接单率""响应率"都映射到应答率指标。
• 口径定义：分子分母分别是什么。比如应答率 = 司机点击应答的订单数 / 推送给司机的订单数。
• 数据源绑定：这个指标去哪张表、哪个预聚合层级取数最合理。
• 可用维度：时间、城市、区域、车型、司机类型、策略标识等。
• 业务判定规则：哪些用户群体要剔除（比如测试司机），哪些订单类型计入统计。

这个语义层相当于是给 LLM 提供的"标准教材"。我们限制 LLM 在生成查询计划时只能从指标注册中心选择指标和维度，不能自己创建一个不存在的指标名。这一步从根上解决了大模型编造指标名的经典问题。

在实际建设过程中，最耗精力的不是技术实现，而是口径治理。你会发现"GMV"在不同团队眼里定义不一样，有人按下单时间统计，有人按完单时间统计，还有人把退款前的订单也算进去。我们在语义层里做的不是强行统一所有口径，而是把不同口径定义成不同指标，比如 gmv_by_order_time 和 gmv_by_complete_time，让 Agent 根据用户问法自动匹配，并且在最终报告里明确写明采用了哪个口径。

3.2 数据获取：从一句人话到一条安全可用的 SQL

数据获取是整个链路里技术挑战最大的一块，因为货拉拉的数据量级下，一句简单的问题可能对应一条跑在千万级分区上的复杂 SQL。

我们的做法分三层：

第一层是查询计划生成。LLM 不直接写 SQL，而是先输出一个结构化的查询计划，里面包含需要查询哪些指标、按什么维度分组、时间范围是什么、是否要过滤特定策略标识。这一步相当于让人先想清楚"我要什么"，再考虑"怎么写代码"。

第二层是SQL 模板化生成。查询计划通过引擎转换成标准 SQL。因为指标口径在语义层已经定义，所以这套 SQL 的骨架是高度模板化的，LLM 只需要填充参数，不需要真的从零"写"一条复杂 SQL。这样 SQL 的语法正确率大幅提升，恶意或越权的查询也被天然限制住。

第三层是执行前的三重校验。校验规则包括：

• 时间范围是否在合理区间，防止用户误查跨度太长的数据导致跑挂集群。
• 涉及的数据表是否在 Agent 的可授权范围内。
• 查询预估扫描量是否超限，超限的话自动降级到更上层的汇总表。

执行引擎我们最初采用 Spark SQL，后来发现策略复盘这种交互式场景对延迟要求很高，逐步把高频查询迁移到了 ClickHouse 上。现在常规的按城市+日粒度聚合查询，从生成 SQL 到返回结果基本能控制在秒级，Agent 做多轮探查时体感上不会有"卡住"的感觉。

3.3 归因分析：从"报数"到"给结论"

数据查出来只是第一步，策略复盘真正难的是归因。DataAgent 的归因能力，我们分成了三层逐步实现：

第一层是机械式下钻。拿到一个指标结果后，Agent 按预设的维度层级层层拆分。比如 GTV 有变化，先拆城市维度，看哪几个城市贡献了主要变化量；再往城市内部拆时段和车型，定位变化最集中的单元。这层逻辑不复杂，但很实用，能快速把分析范围从几十个城市缩小到两三个重点城市。

第二层是指标公式分解。很多核心业务指标是可以拆成有业务含义的公式的，比如 GTV = 完单量 × 客单价，完单量 = 呼叫量 × 应答率 × 完单转化率。Agent 在归因时会让公式的每一部分都参与比较，找出变化率最大的因子。有一次我们复盘补贴策略，发现 GTV 上升但客单价明显下滑，Agent 直接从公式拆解结果中指出"本次策略的增量主要靠拼单低价订单拉动，存在用户结构下沉风险"，这个结论对业务非常敏感。

第三层是对比显著性校验。Agent 拿到实验组和对照组的指标数据后，会做简单的显著性判断，比如用置信区间的重叠程度来判断两组差异是可信的还是有波动的。这一层是为了防止把随机波动当成策略效果。当然，我们没有让 Agent 做复杂的因果推断，那是专业数据科学团队的活，Agent 只需要给出一个"看起来差异显著"的提示，提醒人工进一步建模验证。

3.4 报告生成：模板结构 + 大模型润色

归因分析完成之后，最后一步是把过程组织成可阅读的报告。这个模块我们采取的是"强模板 + 弱生成"策略：报告的整体结构完全固定，LLM 只负责填充内容，不允许自由发挥改变结构。

一份复盘报告在我们的模板里固定有五个段落：

1. 本次复盘结论概述。给出1到3条最核心的结论，每条结论后面必须有数据支撑。
2. 核心指标总览。用表格展示策略前后主要指标的变化。
3. 分维度拆解结果。城市、车型、时段、司机类型这些维度的异常点列表。
4. 异常节点提示。列出分析过程中发现的特殊数据点，比如"某城市某日应答率骤降"。
5. 业务建议。由 Agent 根据归因结果给出的非数据建议，比如"建议下一轮策略针对城郊接单司机加大激励"。

LLM 在填内容时，所有涉及数字的地方都直接引用工具返回的真实数据，禁止编造。我们在 prompt 层面做了强制约束：如果找不到对应数据，就写"该维度数据无查询结果"，而不是靠模型去猜。虽然不完美的报告依然需要人工润色，但骨架已经很完整，分析师拿到之后直接改细节，效率提升非常明显。

4. 一次动态调价策略复盘的完整实操

4.1 一个真实的复盘场景

说一个我们内部实际用 DataAgent 跑过的案例：某城市在晚上六点到九点的晚高峰时段上线了一版动态调价策略，策略的目标是缓解核心商圈供需失衡，提高高峰时段的应答率和完单率。策略上线三周后，业务同学要做一轮中期复盘，重点想回答三个问题：调价上线后高峰应答率到底有没有提升？GTV 变化是不是主要由调价带来的？补贴成本会不会压垮毛利？

以前做这么一轮复盘，分析师至少要经历：找策略上线配置表、确认城市和时段、从数仓拉明细算应答率、和业务核对口径、手动找对照组、再写一份报告。中间运气好两三个小时，运气不好跨上午下午都有可能。

4.2 DataAgent 的实际处理过程

我们把这次复盘的需求直接发给了 DataAgent，原话是："复盘 A 市晚高峰动态调价策略上线三周的效果，重点看应答率、完单率、GTV、单均补贴成本，和上线前两周做对比。"

DataAgent 的处理过程大致分四步：

第一步，意图理解。Agent 识别出关键信息：城市是 A 市，策略类型是动态调价，指标范围是应答率、完单率、GTV、单均补贴成本，对比方式是上线前两周 vs 上线后三周。这里有个细节，Agent 问了用户一句"是否需要排除策略上线第一天的数据波动"，因为新策略上线往往有扰动期。这种主动澄清能力，是纯 SQL 工具不可能具备的。

第二步，数据提取。Agent 查询语义层，确认这几个指标都存在于指标注册中心，分别确认了口径，然后生成查询计划，转成 SQL 在 ClickHouse 上执行。过程里有一个小插曲，Agent 发现"单均补贴成本"这个指标在语义层里没有直接登记，它没有自己编一个口径，而是自动回退到查询"补贴金额 / 完单量"这个基础字段组合，并在报告中明确标注了这是一个自定义组合指标而非标准定义。

第三步，归因分析。查询结果出来后，Agent 先对比了整体指标，发现应答率提升了约3个百分点，但同时发现 GTV 的提升幅度远高于完单量的提升幅度。按照公式拆解逻辑，Agent 自动往下查了客单价和订单结构，发现调价时段里长里程订单占比明显上升。于是它给出了一个推测性结论：调价策略吸引的增量订单偏向长距离需求，客单价抬高放大了 GTV 增速，这也意味着司机的里程成本同时上升，需要结合司机油费成本做二次判断。

第四步，报告生成。Agent 把所有数据和归因内容填入固定模板，输出一份带表格和多维对比的报告。业务同学拿到报告后又追问了几个维度："看一下核心商圈的应答率变化""高评分司机承接订单的比例有没有变化"。这些追问都在同一个会话里完成，Agent 基于已有的查询上下文继续下钻，不需要重新描述背景。

4.3 这轮实操带来的效果

这轮复盘从发起提问到拿到第一版报告，大概用了十分钟出头。如果让分析师手动做，最快也要大半天。注意这不只是"提数快了"——提数只是其中一环，关键是把"该看什么维度、该拆什么关系"这件事也帮着人想了一遍，虽然未必每个结论都对，但至少给了业务一个很好的起点。

DataAgent 在复盘中的价值不是替代分析师，而是把分析师从重复劳动里解放出来。分析师可以把省下来的时间用在验证 Agent 的推测、深入做因果建模、和业务讨论策略迭代方向上，这些才是真正不可替代的工作。

5. 踩坑记录与问题排查速查表

5.1 几个印象最深的坑

说几个我们在实际落地过程中踩过的坑，每一个都是花了不少时间才填平的。

第一个坑是大模型的数字幻觉比想象中顽固。我们早期做原型时，让 Agent 直接基于数据库查询结果生成结论，结果是结论文字很漂亮，数字却经常对不上。比如查询结果是应答率 45.3%，模型在报告里可能写成 45.8%，差之毫厘但性质严重。后来我们强制要求所有数字直接引用工具返回值，中间不做任何模型层的"记忆性转述"，同时加了自动化校验：报告里出现的每个数字都要能在查询结果里找到对应记录，找不到就发回去重新生成。这一套组合拳之后，数字错误基本被堵死了。

第二个坑是同义词和口径的语义差异。业务同学说"看下这一周的完单率"，但他其实想表达的是"用户下单后成功完成的订单比例"，而语义层里"完单率"的默认口径是按司机端完单时间统计的，两边的口径对不上。类似的问题还有"收入"，司机侧关心的收入可能含补贴，财务关心的是不含补贴的实收。我们在语义层里不仅建了同义词，还建了一组"易混淆口径提示"，Agent 在识别出指标后若发现口径可能不唯一，会在报告里主动标注，并且在下一次会话里默认记住该用户选择过的口径偏好。

第三个坑是权限边界和越权查询。DataAgent 天然会放大数据访问的便利性，如果不做权限管控，任何一个能提问的人都能拿到他本不该看的敏感数据。我们给 DataAgent 做了严格的角色权限继承：Agent 没有自己的数据权限，它只能以提问用户的身份去访问该用户被授权范围内的数据。涉及城市维度时，如果用户只被授权看华南区域，Agent 查询华东区域数据会被直接拒绝。这个设计虽然牺牲了部分灵活性，但在数据安全上绝对值回票价。

第四个坑是性能方面"看起来很快"的假象。Agent 在归因时会连续发起多个查询，如果每个查询都是秒级，整轮跑下来用户体感还是很快；但一旦其中一环走了大数据量的明细表，整个会话就会卡住，体验非常糟。后来我们在执行计划里加入了"查询预算"机制，Agent 优先使用预聚合的汇总表，只有当用户明确要求明细级探索时才允许放开，并且对单次查询的扫描行数做了硬限制。

5.2 问题排查速查表

整理了一份我们在调试和上线阶段常用的速查表，遇到问题可以按这个思路排查。

5.3 一些可以复用的实战建议

结合这些经验，我给准备做类似 DataAgent 实践的同学几个建议。

第一个建议是先做语义层，不要急着搞大模型。数据口径不清，Agent 的每一个回答都可能是错的，而且错误会非常隐蔽。语义层本质上是把人对业务的理解沉淀成机器可用的资产，这件事即便不做 Agent 也值得做。

第二个建议是从一个高频但低复杂度的场景切入。我们最开始没有做全自动的归因分析，而是先做"自然语言查数"，让 Agent 帮业务同学直接从数据仓库拿到指标值。这个场景边界清晰、容错率高，用户反馈热情也高。等基础链路稳定了，再往上叠加归因、报告生成这些高阶能力。

第三个建议是保留人在回路的控制点。DataAgent 产出的报告不能无审核直接外发。我们设计了一条"Agent 自动生成 + 分析确认 + 业务查看"的发布链，所有敏感结论必须经过分析师确认才能进入正式周报。这个过程最开始觉得有点麻烦，但后来发现也逼着分析师对 Agent 的输出质量保持敏感，反而形成了一个良性循环。

第四个建议是把可观测性当成核心需求。一个 Agent 会话可能涉及好几次工具调用、多次数据查询，用户经常想知道"它为什么得出这个结论"。我们把每一步的工具调用记录、查询参数、返回结果摘要都记录下来，在报告末尾附带"分析过程矩阵"，用户点开就能看到 Agent 是怎么一步步得出结论的。这个透明度设计，极大提升了业务方对 Agent 的信任度。

我在实际使用中最深的感受是：DataAgent 这类系统的上限，不在于大模型本身有多聪明，而在于背后的数据治理和业务理解做得有多扎实。大模型提供了一个非常友好的交互层，但如果没有一套语义清晰、口径统一、权限规范的数据基础设施托底，再聪明的模型也会在生产环境里翻车。反过来看，如果这些地基打好了，Agent 带来的效率提升是实实在在的——分析师终于有时间去思考策略的本质问题，而不是困在 SQL 和数据表里出不来。这大概就是我们做 DataAgent 实践最值得的地方。