1. 策略复盘为什么需要 DataAgent
做过运营或者数据策略的人都有一个共同的痛点：复盘这件事，说起来重要，做起来次要，忙起来不要。不是大家不想复盘，而是复盘的链路太长了。一次完整的策略复盘，通常要经历数据提取、指标计算、维度拆解、归因分析、结论输出这么几个环节，每个环节都依赖不同的人、不同的工具、不同的口径。等到所有数据凑齐，黄花菜都凉了，业务节奏早就跑到下一个阶段去了。
我在实际工作中观察到一个很典型的现象：策略团队每周花在复盘上的时间，至少有百分之六十消耗在“找数”和“对数”上，真正用于思考策略为什么有效、为什么失效的时间少得可怜。这个比例是极其不健康的。DataAgent 要解决的核心问题，就是把这百分之六十的机械劳动压缩到百分之十以内，让策略同学把精力重新放回到判断和决策上。
所谓 DataAgent，你可以把它理解成一个“懂数据、懂业务、能自己动手干活”的智能体。它不是简单的报表工具，也不是传统意义上的 BI 看板。报表和看板是被动的，你问什么它答什么，你不问它就静静躺着。DataAgent 是主动的，你给它一个复盘目标，它会自己规划路径：先查哪张表、再算什么指标、发现异常后往哪个维度下钻、最后怎么组织结论。这个“自己规划”的能力，就是 Agent 和传统工具最本质的区别。
具体到货拉拉这个场景，策略复盘涉及的对象非常复杂。平台上有乘客侧的策略、司机侧的策略、定价策略、调度策略、补贴策略，每一条策略线背后都挂着几十个指标。如果靠人工一条条去拉，一个策略的完整复盘至少需要半天。而 DataAgent 的目标是把这个过程压缩到分钟级，并且保证口径统一、逻辑可追溯。
这篇文章适合三类人看。第一类是做数据策略、运营策略的同学，你们会看到一套可以直接借鉴的复盘自动化思路。第二类是做数据工程、Agent 开发的同学，你们会看到 Workflow 编排、工具调用、上下文管理这些工程细节怎么落地。第三类是对 Agent 应用感兴趣但还没动手的人，你们会看到一个真实业务场景下 Agent 是怎么被拆解和实现的，而不是停留在概念层面。
2. 整体架构设计与思路拆解
2.1 为什么选择 Agent 而不是固定报表
在动手之前，我们认真评估过几条路线。第一条路线是做一套固定的复盘报表，把常用指标全部预计算好，策略同学自己去看。这条路线的优点是稳定、快、成本低，但缺点是僵化。策略复盘的本质是“带着假设去验证”，每次复盘的切入角度都不一样。今天想看看补贴力度对完单率的影响，明天想看看调度半径对司机接单时长的影响。固定报表没法覆盖这种灵活多变的探索需求，最后还是会退化成“找数据同学提需求”。
第二条路线是做一套自助取数工具，让策略同学自己写 SQL。这条路线的优点是灵活，但门槛太高。大部分策略同学的业务 sense 很强，但 SQL 能力参差不齐，而且就算会写 SQL，也不一定清楚底表的分区规则、字段口径、数据延迟这些工程细节。结果就是取出来的数经常对不上，反而增加了沟通成本。
第三条路线就是 DataAgent。它的核心思路是：把“取数、算数、看数、归因”这一整套动作，封装成一个由大模型驱动的智能体。策略同学只需要用自然语言描述复盘目标，Agent 负责把它翻译成可执行的数据操作序列，一步步执行，最后输出结构化的复盘结论。这条路线的优势在于，它同时兼顾了灵活性和低门槛。灵活性来自大模型的推理能力，低门槛来自自然语言的交互方式。
当然，Agent 路线也有它的问题。最大的问题是“不可控”。大模型可能会理解错意图，可能会选错表，可能会算错指标。所以我们在架构设计上做了一个关键取舍：Agent 负责规划和编排，但不负责具体计算。所有的指标计算、数据查询，都下沉到预先定义好的工具函数里。Agent 的职责是决定“什么时候调用哪个工具、传什么参数”，而不是“自己动手算”。这样一来，计算的准确性由工程代码保证，规划的灵活性由大模型保证，各司其职。
2.2 核心模块拆解
整个 DataAgent 的架构可以拆成四层。最底层是数据层，包括数仓底表、指标平台、维度字典。这一层是既有的基础设施，我们不重复造轮子，而是通过统一的查询接口去对接。第二层是工具层，把常用的数据操作封装成一个个原子化的工具函数，比如“查询某指标在某时间段的值”“按某维度拆解某指标”“计算两个指标的相关系数”等等。第三层是编排层，也就是 Agent 的核心，负责理解用户意图、制定执行计划、调用工具、处理中间结果。最上层是交互层，提供对话式的复盘入口，支持多轮追问和结果导出。
这里重点说一下工具层的设计。工具层的粒度很关键。如果工具太粗，比如直接封装一个“完成一次完整复盘”的工具，那 Agent 就没有发挥空间了，退化成脚本调用。如果工具太细，比如封装一个“执行 SQL”的工具，那 Agent 就要自己写 SQL，又回到了不可控的老路。我们最后选择的粒度是“业务语义级”的工具，比如：
get_metric_trend(metric_name, start_date, end_date, filters)：查询指标趋势breakdown_metric(metric_name, dimension, start_date, end_date)：按维度拆解指标compare_segments(metric_name, segment_a, segment_b, period)：对比两个分群detect_anomaly(metric_name, start_date, end_date)：检测指标异常波动correlate_metrics(metric_a, metric_b, start_date, end_date)：计算指标相关性
这些工具的输入输出都是结构化的，Agent 只需要决定调用哪个、传什么参数。工具内部则封装了完整的查询逻辑、口径校验、异常处理。这种设计的好处是，即使 Agent 规划错了，最坏的结果也只是“查了一个不相关的指标”，而不会“算出一个错误的数”。
2.3 Workflow 编排的设计原则
Agent 的执行过程本质上是一个 Workflow。但和传统的固定 Workflow 不同，DataAgent 的 Workflow 是动态生成的。传统 Workflow 是“if A then B else C”，路径是写死的。DataAgent 的 Workflow 是“根据当前掌握的信息，决定下一步做什么”，路径是运行时决定的。
我们在设计编排逻辑时，遵循了三个原则。第一个原则是先广后深。Agent 拿到复盘目标后，先做一轮宽泛的扫描，看看哪些指标有异常、哪些维度有分化，然后再针对异常点做深入下钻。这样做的好处是避免一上来就陷入细节，错过全局性的问题。第二个原则是假设驱动。Agent 在扫描阶段会形成若干假设，比如“完单率下降可能是因为补贴力度降低”，然后针对每个假设去验证。验证通过的假设进入结论，验证不通过的假设被排除。第三个原则是可中断可追问。Agent 在执行过程中，如果发现信息不足或者存在歧义，会主动向用户提问，而不是自己瞎猜。用户也可以在任何时候打断，调整复盘方向。
这三个原则说起来简单，落地的时候有很多细节要处理。比如“先广后深”的“广”到底多广？我们的做法是，Agent 首先会拉取复盘周期内所有核心指标的概览，然后计算每个指标的环比、同比、波动率，把波动超过阈值的指标标记为“异常候选”。这个阈值不是拍脑袋定的，而是基于历史数据的统计分布来动态计算的。具体来说，我们取过去九十天该指标的日度波动率，计算其均值和标准差，把超过均值加两倍标准差的波动定义为异常。这个规则在大部分指标上都表现良好，既不会太敏感导致天天报警，也不会太迟钝导致漏掉真实异常。
3. 核心细节解析与实操要点
3.1 意图理解：把自然语言翻译成数据任务
Agent 的第一步是理解用户想干什么。用户可能会说“帮我看看上周补贴策略的效果”，也可能会说“最近完单率掉了，帮我查查原因”。这两句话背后的数据任务是完全不同的。前者是效果评估，需要对比策略前后的指标变化；后者是归因分析，需要拆解指标下降的贡献来源。
我们在意图理解这一层做了两件事。第一件事是意图分类。我们把策略复盘常见的意图分成几类：效果评估、归因分析、趋势监控、分群对比、异常排查。每一类意图对应一套预定义的执行模板。Agent 首先要判断用户的话属于哪一类意图，然后再套用对应的模板。第二件事是槽位填充。每个模板都有若干必填槽位，比如效果评估需要“策略名称、评估周期、核心指标”，归因分析需要“目标指标、分析周期、候选维度”。Agent 要从用户的话里提取这些槽位，提取不到的就要主动追问。
这里有一个实操中的坑值得分享。最初我们试图让大模型一次性完成“意图分类加槽位填充”，结果发现准确率不稳定。后来我们把它拆成两步：先做意图分类，再做槽位填充。意图分类的 prompt 里只放意图定义和几个示例，槽位填充的 prompt 里只放当前意图的槽位定义和用户原话。拆开之后，每一步的准确率都明显提升。这个经验在很多 Agent 场景下都适用：不要让大模型一次做太多事，把复杂任务拆成多个简单任务，每个任务单独调一次模型，整体效果反而更好。
3.2 工具调用的参数构造
Agent 决定调用某个工具之后，下一步是构造参数。这一步看起来简单，实际上很容易出错。比如用户说“看看上周的完单率”，Agent 需要把“上周”翻译成具体的日期范围。这里涉及两个问题：一是“上周”的定义，是自然周还是滚动七天？二是时区问题，数据是按什么时区统计的？
我们的做法是，在工具层之上加一层参数规范化。所有涉及时间的参数，都统一转换成“开始日期、结束日期”的格式，并且明确标注时区。所有涉及指标名称的参数，都通过指标字典做一次映射，把用户的口语化表达（比如“完单率”）映射到指标平台的标准名称（比如“order_completion_rate”）。所有涉及维度的参数，同样通过维度字典做映射。
这层规范化还有一个作用，就是参数校验。如果 Agent 传了一个不存在的指标名，或者一个超出数据范围的日期，规范化层会直接拦截并返回错误信息，而不是让工具去执行一个注定失败的查询。错误信息会返回给 Agent，Agent 可以根据错误信息调整参数重新调用。这种“失败即反馈”的机制，是 Agent 自我纠错能力的基础。
3.3 上下文管理与记忆
Agent 在执行复盘任务时，会产生大量的中间结果。比如查了十个指标的趋势，每个指标返回三十天的数据，这就是三百个数据点。如果把这些全部塞进大模型的上下文，很快就会超出窗口限制，而且会稀释关键信息。
我们的做法是分层记忆。第一层是原始数据层，所有工具返回的原始结果都存在这里，不直接进大模型上下文。第二层是摘要层，每个工具返回结果后，会生成一个简短的摘要，比如“完单率在过去七天从百分之八十五下降到百分之七十八，下降七个百分点，主要下降发生在周三和周四”。只有摘要层的内容会进大模型上下文。第三层是结论层，Agent 在每个阶段结束时，会把当前阶段的发现凝练成一两句结论，存入结论层。后续的推理主要基于结论层，需要细节时再回查摘要层或原始数据层。
这种分层记忆的设计，灵感来自人做复盘时的思维过程。我们不会记住每一个数据点，而是记住“哪个指标出了问题、大概什么时候出的、可能是什么原因”。需要确认细节时，再回去翻原始数据。Agent 的记忆管理也应该遵循同样的逻辑。
3.4 结果输出的结构化
复盘结论的输出格式很重要。如果 Agent 返回一大段文字，用户很难快速抓住重点。我们的做法是强制 Agent 按照固定结构输出，包括：复盘结论、关键发现、数据支撑、后续建议四个部分。
复盘结论是一句话总结，比如“上周补贴策略对完单率有正向影响，但影响幅度低于预期”。关键发现是三到五条要点，每条要点都要有数据支撑。数据支撑部分列出具体的指标数值和变化。后续建议部分给出可操作的下一步动作。
这里有一个细节：我们要求 Agent 在输出数据支撑时，必须标注数据来源和口径。比如“完单率数据来自指标平台，口径为当日完成订单数除以当日发单数，统计时区为北京时间”。这样做是为了让复盘结论可追溯、可验证。策略同学看到结论后，如果觉得哪里不对，可以顺着数据来源去核查，而不是只能选择相信或不信。
4. 实操过程与核心环节实现
4.1 环境准备与依赖梳理
动手搭建之前，先把依赖理清楚。DataAgent 的运行依赖三类资源。第一类是模型资源，需要一个支持函数调用的大模型接口。我们选型时重点看三个指标：函数调用的准确率、长上下文的稳定性、响应延迟。函数调用准确率决定了 Agent 能不能正确选择工具，长上下文稳定性决定了能不能处理复杂的多轮复盘，响应延迟决定了用户体验。第二类是数据资源，包括数仓的连接权限、指标平台的查询接口、维度字典的读取权限。第三类是运行环境，包括 Python 运行环境、依赖包管理、日志和监控。
这里重点说一下模型选型的经验。我们测试过多个模型，发现不同模型在函数调用上的表现差异很大。有的模型在简单场景下表现很好，但一旦工具数量超过十个，选择准确率就明显下降。有的模型对中文业务术语的理解更好，但函数调用的格式经常出错。最后我们选择的方案是主模型加备用模型。主模型负责复杂的规划和推理，备用模型负责简单的意图分类和参数提取。这样既保证了复杂场景的效果，又控制了成本。
4.2 工具函数的实现细节
工具函数是整个系统的基石，它的质量直接决定了 Agent 的上限。我们以get_metric_trend为例，说一下实现细节。
def get_metric_trend(metric_name, start_date, end_date, filters=None): """ 查询指标趋势 metric_name: 标准指标名，如 order_completion_rate start_date: 开始日期，格式 YYYY-MM-DD end_date: 结束日期，格式 YYYY-MM-DD filters: 过滤条件，字典格式，如 {"city": "上海", "driver_level": "A"} """ # 第一步：参数校验 validate_metric(metric_name) validate_date_range(start_date, end_date) # 第二步：口径解析 metric_config = load_metric_config(metric_name) # 第三步：查询构造 query = build_query(metric_config, start_date, end_date, filters) # 第四步：执行查询 raw_data = execute_query(query) # 第五步：结果格式化 result = format_trend_result(raw_data, metric_config) # 第六步：生成摘要 summary = generate_summary(result) return {"data": result, "summary": summary}这个函数看起来简单，但每一步都有讲究。参数校验确保输入合法，避免无效查询。口径解析从指标平台加载指标的定义，确保不同工具用的是同一套口径。查询构造根据指标配置生成 SQL，屏蔽了底表差异。结果格式化统一了输出格式，方便 Agent 消费。摘要生成是给大模型看的，用自然语言描述趋势变化。
实操心得：工具函数的返回值一定要包含“摘要”字段。大模型直接读原始数据容易迷失，读摘要则能快速抓住重点。摘要的生成规则可以很简单，比如“指标从 X 变化到 Y，变化幅度 Z”，但一定要有。
4.3 编排循环的实现
Agent 的核心是一个循环：观察当前状态、决定下一步动作、执行动作、更新状态。这个循环用伪代码表示大概是这样的：
def run_agent(user_query, max_steps=20): context = init_context(user_query) for step in range(max_steps): # 决定下一步 action = decide_next_action(context) # 如果 Agent 认为可以结束了，就退出循环 if action.type == "finish": break # 如果 Agent 需要用户补充信息，就暂停 if action.type == "ask_user": return ask_user(action.question) # 执行工具调用 result = execute_tool(action.tool_name, action.params) # 更新上下文 context = update_context(context, action, result) # 生成最终结论 conclusion = generate_conclusion(context) return conclusion这个循环的关键在于decide_next_action。它的输入是当前上下文，输出是一个动作。动作有三种类型：调用工具、询问用户、结束。decide_next_action的实现方式是把上下文和可用工具列表一起塞给大模型，让大模型输出下一步动作。这里有一个技巧：在 prompt 里明确告诉大模型当前处于哪个阶段。比如“当前处于扫描阶段，请优先选择能覆盖多个指标的工具”，或者“当前处于下钻阶段，请针对已发现的异常指标选择拆解工具”。阶段信息能显著提升大模型决策的合理性。
4.4 一个完整的复盘案例
假设用户输入：“帮我复盘一下上周上海地区的补贴策略效果。”
Agent 的执行过程大致如下。第一步，意图识别为“效果评估”，槽位填充为策略名称等于补贴策略、地区等于上海、周期等于上周。第二步，Agent 调用get_metric_trend查询核心指标（完单率、应答率、司机在线时长）在上周的趋势。第三步，Agent 发现完单率在上周后半段有明显下降，触发异常检测。第四步，Agent 调用breakdown_metric按城市、司机等级、时段拆解完单率，发现下降主要集中在上海郊区的低等级司机群体。第五步，Agent 调用compare_segments对比补贴策略覆盖和未覆盖的司机群体，发现覆盖组的完单率下降幅度小于未覆盖组。第六步，Agent 综合以上发现，输出结论：补贴策略对完单率有正向作用，但覆盖范围不足，郊区低等级司机未被充分覆盖，建议扩大补贴覆盖范围。
整个过程 Agent 调用了大约八到十次工具，耗时在三十秒左右。如果靠人工完成同样的复盘，至少需要半天。这个效率提升是数量级的。
5. 常见问题与排查技巧实录
5.1 Agent 选错工具怎么办
这是最常见的问题。Agent 面对十几个工具，有时候会选一个看起来相关但实际上不对的工具。比如用户想查“完单率”，Agent 却调用了查询“发单量”的工具。
排查思路分三步。第一步，看意图识别是否正确。如果意图识别错了，后面的工具选择肯定错。第二步，看工具描述是否清晰。工具描述是 Agent 选择工具的唯一依据，如果描述含糊，Agent 就容易选错。第三步，看上下文是否提供了足够的信息。有时候 Agent 选错工具是因为它不知道当前处于哪个阶段。
解决方法和排查思路对应。意图识别的问题，通过优化意图分类的 prompt 和增加示例来解决。工具描述的问题，通过重写工具描述来解决。我们的经验是，工具描述要包含三个要素：这个工具做什么、什么时候用、输入输出是什么。比如breakdown_metric的描述是“按指定维度拆解指标，用于分析指标的构成和分化，输入指标名和维度名，输出各维度的指标值”。这样的描述比“拆解指标”清晰得多。
5.2 数据口径不一致怎么处理
策略复盘最怕口径不一致。同一个指标，不同的人算出来不一样，复盘结论就失去了可信度。DataAgent 处理口径问题的核心思路是单一数据源。所有指标的定义都来自指标平台，Agent 不自己定义指标，也不允许用户在对话中临时定义指标。如果用户问了一个指标平台上没有的指标，Agent 会明确告知“该指标未在指标平台注册，请先确认口径”。
注意：不要为了灵活性而允许 Agent 临时计算指标。临时计算意味着口径不受控，今天算出来一个数，明天算出来另一个数，复盘就没法做了。宁可少支持一些指标，也要保证支持的指标口径统一。
5.3 多轮对话中上下文丢失
多轮复盘时，用户可能会追问“那再帮我看看司机侧的情况”。这时候 Agent 需要记住上一轮在分析什么策略、什么周期、什么地区。如果上下文管理没做好，Agent 就会丢失这些信息，重新问一遍。
我们的解决方案是在上下文中维护一个会话状态，记录当前复盘的策略、周期、地区、已发现的异常、已排除的假设。每次用户输入新指令时，Agent 先把新指令和会话状态合并，再决定下一步动作。会话状态是结构化的，不是一大段文字，这样既节省上下文窗口，又方便程序处理。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| Agent 选错工具 | 工具描述不清或意图识别错误 | 检查意图分类结果和工具描述 | 优化 prompt，重写工具描述 |
| 数据对不上 | 口径不一致或时区错误 | 核对指标定义和统计时区 | 统一数据源，强制口径校验 |
| 多轮对话丢失上下文 | 会话状态未持久化 | 检查上下文管理逻辑 | 维护结构化会话状态 |
| Agent 陷入循环 | 工具返回结果无法推进推理 | 查看执行日志，定位循环点 | 设置最大步数，增加循环检测 |
| 响应太慢 | 工具查询耗时或模型推理慢 | 分别计时工具调用和模型调用 | 优化查询，缓存常用结果 |
| 结论太空泛 | 摘要生成质量差 | 检查摘要是否包含具体数值 | 优化摘要生成规则 |
5.5 独家避坑技巧
第一个技巧：给 Agent 设置“止损点”。Agent 在执行过程中，如果连续三次工具调用都没有获得有效信息，就应该停下来向用户求助，而不是继续瞎试。我们在实现中加了一个计数器，连续无效调用超过阈值就触发人工介入。
第二个技巧：工具返回结果要带“置信度”。有些查询可能因为数据延迟或分区缺失而不完整，这时候工具应该在返回结果中标注置信度。Agent 看到低置信度的结果，可以选择重新查询或者提示用户。这个机制能有效避免基于不完整数据得出错误结论。
第三个技巧：定期回放历史复盘。我们每周会抽取几条历史复盘记录，人工检查 Agent 的推理链路是否合理。这个习惯帮我们发现了不少隐蔽的问题，比如某个工具在特定日期范围内会返回空结果，导致 Agent 误判为“指标为零”。回放机制是持续优化 Agent 的重要手段。
6. 后续可以扩展的方向
DataAgent 在策略复盘这个场景跑通之后，我们也在思考它还能用到哪些地方。一个自然的方向是实时监控。现在的复盘是事后分析，如果把 Agent 接到实时数据流上，它就能在指标异常发生的第一时间发出预警，并自动生成初步的归因分析。另一个方向是策略推荐。Agent 在复盘过程中积累了大量“什么策略在什么场景下有效”的知识，这些知识可以反过来用于新策略的生成和推荐。
还有一个方向是多 Agent 协作。现在的 DataAgent 是单 Agent 架构，一个 Agent 负责从头到尾。未来可以拆成多个专职 Agent，比如一个负责数据查询、一个负责归因分析、一个负责结论生成，它们之间通过消息传递协作。这样做的好处是每个 Agent 的职责更单一，prompt 更简单，整体稳定性可能更高。
我在实际使用中最大的体会是，Agent 的价值不在于它有多智能，而在于它能把人从重复劳动中解放出来。策略同学的时间应该花在判断“这个结论合不合理”“下一步该做什么”上，而不是花在“怎么把数据拉出来”上。DataAgent 做的就是把后面这部分工作接过去，让人专注于前面那部分。这个定位想清楚了，很多设计取舍就自然清晰了。
