先说一个我实际经历过的场景每周一的策略复盘会你带着一摞报表走进去被业务方连续追问“这个转化率为什么降了”“分城市拆一下看看”“和上个周期比差异在哪”结果只能回一句“我拉一下数下午给你”。如果屏幕前的你有同感那这篇关于货拉拉 DataAgent 的实践内容应该能帮到你。所谓 DataAgent简单说就是一个连接大模型与内部数据平台的智能代理让分析师、运营甚至管理层直接用自然语言提问由它自动完成取数、分析、归因和报告草拟。过去一年我们团队把它用在了最耗人力的策略复盘场景上原本三天一轮的复盘压缩到半天甚至两小时而且口径统一、过程可控。这篇文章我会把整体设计思路、核心实现、Prompt 调优方法和踩过的坑一起整理出来尽量说人话少绕弯子。如果你是数据平台工程师、算法工程师或者正在被海量取数需求折磨的数据分析师这篇文章可以给你一个可以直接参考的落地框架。1. 策略复盘为什么需要智能化改造1.1 传统复盘的三大痛点先别急着谈技术我们要先想清楚一个问题策略复盘到底哪里痛以货运平台为例每次调价、每个城市的活动补贴、每条线路的运力调度策略事后都要回答“效果怎么样”“为什么是现在这个结果”“下一步怎么调”。听起来是很常规的分析工作但实操起来问题不少。第一个痛点是周期太长。策略上线后一般要等 3~7 天的数据沉淀才能做完整复盘分析师拿到需求后先要写 SQL 取数、再清洗、再透视、再做图表一个完整复盘下来动辄两三天。业务方等不了很多时候复盘还没出来下一轮策略已经开始试了结论永远是马后炮。第二个痛点是口径混乱。同一个“完单转化率”业务运营、产品经理、财务三方各有一套理解。分析师在取数时如果没对齐口径拉出来的数据看起来差不多实际口径不同复盘会上一对发现鸡同鸭讲。更麻烦的是这种口径差异藏在 SQL 里不走到数据核对那一步根本发现不了。第三个痛点是强依赖个人经验。同一个数据问题老分析师能快速判断该拆维度还是该看漏斗新手可能连该查哪张表都找不到。策略复盘的结论质量直接取决于分析师的业务理解深度而分析师的个人经验恰恰是最难复制和规模化的东西。这三个痛点叠加起来结果就是分析师每天被取数需求淹没真正应该花时间的归因分析和策略建议反而没时间做。1.2 DataAgent 要解决的到底是什么我们做 DataAgent 的时候给自己定了一个非常明确的定位它不是一个取代分析师的“超人”而是一个让分析师从重复取数中解脱出来的“高级取数工具 初级分析助手”。具体来说我们希望它做到三件事业务方直接用自然语言提问比如“上海上周的完单转化率和前一周对比怎么样按小时维度拆一下”DataAgent 自动生成 SQL、执行查询、返回图表和分析结论。所有查询都走统一的指标平台和权限体系保证口径一致、数据权限可控从机制上避免口径混乱的问题。分析师收到 DataAgent 的初步分析后只需要做审查、补充和决策建议把精力花在真正需要业务判断的部分。打个比方传统模式是分析师给业务方当“数据拐杖”业务方每一步都要扶着DataAgent 是把这份工作变成了“数据地图”业务方自己能走分析师只在关键路口把个关。1.3 为什么选 Agent 范式而不是纯 NL2SQL确定了方向后我们面临一个技术选型问题市面上已经有挺多 NL2SQL 的开源工具为什么要上一套 Agent 体系NL2SQL 解决的是“把自然语言翻译成 SQL”这个单点问题但它本质上是无状态的你说一句它翻译一句执行完就结束了。可是真实复盘场景不是一个单问题而是一个连续的、需要多轮交互的探索过程。业务方一开始可能只问“这次活动效果怎么样”看到结果后自然追问“按城市拆一下”“新老用户有没有差异”“和上次活动比怎么样”。这种多轮对话、自主分析、逐步深入的能力是传统单轮 NL2SQL 不具备的。Agent 范式的好处在于它有规划Planning、工具调用Tool Calling和记忆Memory。它可以把“帮我看一下这次活动效果”拆解成若干子任务先确定活动涉及的城市和时间范围再计算核心指标再和基线做对比再生成解读。每一步都可以调用不同的工具而且能记住前面说过的话保持上下文连贯。这才是策略复盘真正需要的形态。当然Agent 的复杂度也更高。后面我们踩的很多坑都是因为 Agent 的自主性带来的副作用。这个后文会细说。2. DataAgent 整体架构与关键模块设计2.1 系统架构分层我们的 DataAgent 整体分四层交互层、智能层、工具层、数据层。这四层各司其职下面逐一展开。交互层就是用户看到的界面支持 Web 对话和 IM 机器人主要承担两件事接收用户自然语言提问展示结果图表、表格、文字结论。智能层是整个系统的核心由大模型驱动的 Agent 编排模块构成负责意图识别、任务规划、工具选择、结果解读。这一层我们最初用的是通用大模型后面针对 SQL 生成和归因分析做了专门的 Prompt 优化和微调效果提升非常明显。工具层为 Agent 提供可调用的能力集合包括指标字典查询、SQL 生成与执行、图表配置、报告生成、口径校验等。工具不在多而在精。我们早期塞进去十几个工具结果模型经常选错后来砍到五六个核心工具准确率反而上去了。数据层是货拉拉已有的数据体系包括数仓表、指标平台、权限中心。DataAgent 不直接碰原始表而是通过指标平台开放的语义层来查询这样权限、口径、血缘都复用已有能力不用从零建设。2.2 最核心的工具层设计工具层需要重点讲因为它决定了 Agent 能干什么、干得好不好。我们最终保留下这几个工具每一个都有明确的输入输出定义指标查询工具输入是业务域、指标名、维度、时间范围、过滤条件输出是结构化的查询结果。这个工具背后连接的是指标平台不是直接连数据库。口径查询工具输入是关键词输出是该指标的口径定义、计算公式、来源表。这个工具用来让模型在不确定口径的时候自己查证减少瞎编。趋势与对比工具输入是指标和两个时间范围输出是同环比、变化趋势、显著性判断。复盘场景里这个工具的使用频率非常高。归因探查工具输入是指标异常的时间段和维度信息输出是按维度拆解的贡献度排序。这是我们为复盘场景专门开发的效果不错。报告生成工具输入是前面步骤产生的分析结果输出是一份结构化的复盘报告草稿包含结论、图表建议、下一步建议。工具设计上有一个很重要的原则每个工具都要有清晰的能力边界和容错机制。比如指标查询工具遇到查不到指标时不能直接报错而是返回一个“未找到指标请尝试口径查询工具”的提示引导 Agent 走下一步。这种工具间的相互提示能明显提升多步任务的成功率。2.3 记忆与上下文管理Agent 的“记忆力”直接影响复盘体验。策略复盘有个特点用户会在一个会话里反复修改分析维度。比如先问全国数据然后改成只看华南区再改成只看广州。如果 Agent 每次都是无状态地重新理解轻则多查几次重则理解错。我们的方案是把记忆分成两层短期的会话记忆和长期的经验记忆。短期记忆维护当前会话的分析上下文包括用户最近提到的时间范围、维度、指标、过滤条件。实现上不复杂把每轮的关键参数抽取出来存成结构化状态下一轮解析问题时优先参考这份状态。比如用户说“还是刚才那个活动把城市改成广州”模型就能正确地在原基础上替换城市条件而不是重新理解成一个新问题。长期记忆做的事情更有意思。我们把每次成功的复盘过程沉淀为一个“经验模板”比如“某类活动复盘的标准步骤是先看整体活动效果、再看各城市贡献、然后拆新老用户、最后对比历史活动”。遇到同类问题时Agent会先检索相关经验模板再开始规划而不是每次从零思考。这个机制上线后复杂问题的完成率提升了不少。2.4 安全与权限体系踩了红线就会出问题这个部分多说两句。DataAgent 这种自然语言取数工具最大的隐患不是模型能力不够而是数据权限失控。如果用户问“全平台司机收入分布”但他在业务上只被授权看华南区系统必须主动拦截或自动加上区域条件否则就是在制造数据安全事故。我们的做法是所有查询在生成后必须经过权限改写层这个层会做两件事。一是基于用户的组织、角色、数据域范围自动注入行级权限条件比如“city in (‘深圳’,‘东莞’,‘惠州’)”二是对查询涉及的列做列级校验用户无权访问的字段直接拒绝。这两步都发生在 SQL 真正执行前从机制上保证即使模型生成了越权查询也跑不出去。另一个值得注意的点是审计追溯。所有用户和 DataAgent 的对话、生成的 SQL、执行的查询结果全部记录留痕定期抽查。这既是为了安全合规也是为了后续优化。我们通过审计日志发现了很多模型生成错误和用户使用习惯的线索对迭代帮助很大。3. 策略复盘核心流程与实现细节3.1 复盘场景的梳理与标准化做 DataAgent 之前我们花了比较多时间做一件事把复盘场景分门别类。货拉拉的策略复盘大概集中在三类定价策略比如高峰期动态调价、补贴策略比如新司机拉新补贴、用户端优惠券、调度策略比如运力调度和区域覆盖调整。每一类我们都梳理出一套标准的分析链路。以定价策略复盘为例标准链路是先看价格调整前后的核心业务指标完单量、应答率、取消率变化再看不同区域和时间段的表现差异然后归因到供需关系、天气、节假日等外部因素最后和历史相似策略做对比形成结论。这个梳理过程看起来很笨但价值极大。它既决定了 Prompt 怎么写、工具怎么设计也决定了 Agent 在自由发挥时的“默认路径”。有了标准链路Agent 就不会跑偏太远生成的复盘结构也基本可控。3.2 复盘场景的 Prompt 设计与迭代Prompt 是我们踩坑最多的地方也最值得分享。一个完整的复盘查询用户可能只说一句“深圳这次调价效果怎么样”Agent 要补全的信息量非常大时间范围、对比基线、关键指标、维度拆分、异常判定标准。我们最终把系统 Prompt 写成了三块角色定位、工具使用规则、复盘流程约定。这里给一个简化的示例你是货运平台策略复盘助手负责帮助用户完成定价/补贴/调度策略的事后分析。 你的分析风格先给结论再给数据支撑最后给建议。 工具使用规则 1. 用户提到指标时先调用口径查询工具确认指标定义不要凭经验猜测。 2. 所有查询必须走指标查询工具生成SQL时统一使用平台的语义层函数。 3. 涉及时间对比时优先使用趋势与对比工具计算同环比不要手工比较。 4. 发现指标异常时调用归因探查工具按城市/时段/用户类型等维度拆解。 5. 无法确定用户意图时主动提问澄清不要假设。 复盘流程 1. 明确复盘对象、时间范围、地域范围。 2. 查询核心指标的整体表现。 3. 与上一周期或基线期对比。 4. 按重要维度拆分定位差异来源。 5. 输出结论与下一步建议。这套 Prompt 迭代了很多版最重要的经验是给规则但要给“何时用这条规则”的触发条件。光写“不要凭经验猜测”没用模型不知道该在什么时候查口径。改成“用户提到完单转化率、应答率等指标时先调用口径查询工具”之后误用率明显下降。3.3 一次完整复盘的内部执行路径讲完了 Prompt我用一个具体例子走一遍 DataAgent 内部是怎么完成一次复盘任务的。假设用户输入“深圳上周高峰期调价后的应答率表现怎么样和调价前一周对比一下。”Agent 的处理过程大概可以拆成五步。第一步是意图解析。模型识别出这是定价策略复盘关键实体是“深圳”“上周”“高峰期”“应答率”对比对象是“调价前一周”。这里的难点是“调价前一周”到底怎么定义Agent 会先检索策略配置表找到该策略的生效时间点再往前推一周作为对比基线而不是生硬地按自然周截取。第二步是指标确认。模型发现“应答率”在平台上有多个定义按订单口径、按司机口径、按运力时段口径于是调用口径查询工具确认用户在复盘场景里通常用的是“高峰期有效应答订单/高峰期总订单”并把这个口径记录到会话状态中。第三步是计划生成与工具调用。Agent 生成执行计划先查上周整体的应答率和前一周基线然后按日期维度产出趋势再按行政区做拆分看是否有区域差异。每一步都调用对应的工具并把结果缓存起来。第四步是结果解读。模型综合分析数据后生成结论比如“深圳上周高峰期应答率 68.3%较调价前一周下降 2.1 个百分点其中福田、南山下降最明显降幅超过 4 个百分点建议重点排查该区域运力供给是否匹配。”这个结论不是简单复述数据而是带上了归因和行动建议价值就在这里。第五步是输出组织。最终返回给用户的是一份结构化报告包括结论摘要、关键指标对比表、趋势图表、维度拆解表格和下一步建议用户可以一次性看到完整复盘内容。3.4 多轮追问与闭环机制复盘很少一轮结束业务方拿到结果后会继续追问“福田为什么降这么多”“是供给问题还是需求问题”“新司机和存量司机的应答率差异大吗”。这就要求 Agent 能在当前分析结果上继续深入。我们把多轮追问设计成“状态 动作”的闭环每轮交互结束后系统保存当前分析上下文指标口径、时间范围、维度状态用户下一轮提问时Agent 先基于上一轮的输出定位“相关位置”再决定是调用新工具做深度下钻还是复用已有结果直接回答。这里有个小优化值得提对于“再对比一下”“换个维度看看”这类高频追问我们专门做了快捷指令识别不走完整的大模型规划流程而是直接在现有查询上替换参数重新执行。这个优化把常见追问的响应时间从十几秒降到了两三秒使用体感提升显著。4. Prompt 调优与效果评估4.1 评估集先有尺子再谈优化如果只凭感觉调 Prompt很容易进入“优化一个 bug 制造两个 bug”的恶性循环。我们做评估做了一件正事构造了一套复盘黄金评估集。评估集的来源是真实的复盘需求历史记录我们把它整理成两百多条标准问题覆盖定价、补贴、调度三大场景每条问题都标注了期望的分析链路、涉及指标口径、预期 SQL 特征和关键结论要点。比如一个问题可能标注“需要包含基线对比”“需要按城市拆分”“需要在结论中指出异常城市”。有了评估集之后每次调整 Prompt 或改工具定义都会拿评估集完整跑一遍记录整体通过率。这个方法虽然费时间但保证了每次改动是真正变好了而不是自我感觉良好。4.2 核心评估指标与真实数据表现我们最终盯住了三个指标SQL 执行成功率、结果一致性和问答采纳率。SQL 执行成功率最好理解就是生成的 SQL 能跑通的比例。早期只有 82%问题集中在表名猜错、字段类型不匹配、语法错误。优化工具描述和补充示例后执行成功率稳定在 95% 左右。结果一致性是指生成的查询结果和人工验证的黄金结果是否一致。这个指标比执行成功率重要得多因为 SQL 能跑通不代表结果正确。我们按“指标值完全一致、小数点后对齐、维度对齐、口径对齐”四个层级来评估。目前简单问题的口径一致率能做到 90%但复杂问题会掉到 70% 左右这也是我们下一步重点优化的方向。问答采纳率是指用户在拿到结果后是否在会话里表达了认可比如“可以”“谢谢”“没问题”或者在后续操作中基于该结果继续分析。这个指标偏软性但能反映真实使用体验。复盘场景下目前大约是 80% 左右说明大多数时候结果是被认可的。4.3 几次典型 Prompt 调优案例举两个具体案例供参考。第一个案例是关于“时间范围推断”的。最初模型经常把“上周”理解为自然周周一到周日但在货运业务里“上周”往往指的是“策略生效的最近 7 天”。我们改了两版 Prompt给模型追加了规则“用户提到上周/近期等相对时间时优先根据策略配置表中的生效时间计算别默认按自然周。除非用户明确说‘自然周’。”加了这条之后时间推断准确率从 72% 提升到了 89%。第二个案例是关于“结论可信度”的。最初模型生成结论时经常过度自信比如数据只显示了福田一个区域异常结论却写“全市多个区域出现供给不足”。我们给模型加了一条约束“用户容忍度在生成结论时结论只描述数据覆盖范围内的观测结果不做外推如需外推必须明确指出这是推断。”这条约束对结论质量的提升非常明显误判明显减少。调 Prompt 的整体经验是一次只改一个变量小步快跑。不要一次性加五条规则否则你根本不知道是哪个改动起了作用。5. 落地过程中踩过的坑与排查实录5.1 NL2SQL 的“幻觉”问题DataAgent 最典型的坑是生成不存在的表或字段。模型没见过的表它能一本正经地编出表名甚至编出字段注释。我们踩过最离谱的一次它生成了“driver_level_salary”这个完全不存在的表还煞有介事地加了 WHERE 条件。排查思路是这样的先在 SQL 执行层加了表名、字段名的前置校验拿生成的 SQL 去元数据服务比对一遍发现不存在的对象直接拦截并反馈给模型让模型基于元数据反馈重新生成。这个“先校验、再执行”的机制把因为表字段不存在导致的执行错误降了七八成。但更深一层的问题是模型对业务表的理解不够可能会选错逻辑上正确的表。比如分析完单量时选中了“订单流水表”而没选“完单事实表”字段值完全对不上。针对这个问题我们把数据资产目录整理成语义层的逻辑模型暴露给模型让模型尽量在逻辑模型上做分析而不是直接面对底层物理表。这个调整是效果质变的关键。5.2 复杂查询超时与性能问题策略复盘里的数据分析往往涉及多维度组合、大数据量聚合生成的 SQL 有时一跑就是几十秒。Agent 在等待结果时阻塞用户体感非常差而且大模型做工具返回结果总结时也可能因为数据量过大而输出混乱。我们踩过几次超时后定了一套执行策略只是查询逻辑放到异步任务Agent 可以挂起等待超时后自动把查询拆小比如按天拆、按城市拆再并行执行图表数据取前 N 条显著项明细数据统一进离线结果表用户可按需查看。合并输出时只把结论性的统计数据送给大模型原始的明细数据直接以表格形式内嵌给用户减少 token 消耗。这个策略还有个额外好处很多复盘任务其实是要周期反复执行的我们把“查询计划”缓存起来下次同样的复盘直接复用结果实现增量更新。到了月底做月度复盘时很多数据已经跑过了整份报告几分钟就能出来。5.3 权限控制与数据口径的双重校验权限问题前面说过这里再补充一个实践细节权限改写不能只靠规则还要靠测试。我们专门设计了一套“越权查询测试用例”比如普通运营账号尝试查询全国数据、非财务角色尝试看成本明细等定期用这些用例攻击自己的系统确保权限改写层没有漏洞。这类测试刚开始确实能发现几个漏网之鱼后来稳定为零。口径问题则是在结果一致性评估中暴露的。我们发现模型在语义层上选口径时偶尔会“偷懒”用户问“有效订单量”系统定义里其实有“订单口径”和“完单口径”两种模型图省事直接选了默认口径导致结果和用户期望不一致。我们的解法是在意图解析阶段就显式抽取“口径实体”并在向用户输出的结果中带上口径说明“有效订单量按司机点击接单口径”。让用户能校验比让模型保证不出错更可靠。5.4 兜底策略人工介入与安全阀最后一条经验是不要追求 100% 自动化要给人工留位置。现在系统的设计里如果 Agent 在自我评估环节对生成结果把握不足比如工具返回结果与用户问题不匹配或者权限校验有风险会自动进入“人工审核”队列由分析师确认后再放行输出。我们在界面里加了一个很不起眼但实用的功能“一键替换为手动 SQL”。当用户发现 Agent 生成的 SQL 不符合预期时可以直接查看 SQL 并手动修正后重新执行。实测下来这个功能的使用率远超预期某些资深分析师甚至更习惯先把 Agent 的 SQL 当草稿再自己修改。这件事也让我意识到DataAgent 的价值不是替代人而是把人的起点从“零”抬到“80%”。复盘的链路优化到今天我个人体会最深的一点是DataAgent 的难点不在模型能力本身而在于把业务逻辑拆解成清晰的流程和有边界的工具。模型会越来越强但如果工具边界是模糊的复盘链路是随机的再强的模型也发挥不出真正的价值。如果你也在尝试做类似的事情我的建议是先别急着上复杂的 Agent 框架找一个高频、结构化程度高的复盘场景把分析链路梳理清楚把工具做好再让 Agent 在这条链路里自由发挥。这样既能快速产生价值也能在可控范围内积累经验。