先说一个我实际经历过的场景：每周一的策略复盘会，你带着一摞报表走进去，被业务方连续追问“这个转化率为什么降了”“分城市拆一下看看”“和上个周期比差异在哪”，结果只能回一句“我拉一下数，下午给你”。如果屏幕前的你有同感，那这篇关于货拉拉 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 在这条链路里自由发挥。这样既能快速产生价值，也能在可控范围内积累经验。
