数据分析 Agent 怎么把一个分析目标拆成多步计划并执行？

简化版

采用 Plan-and-Execute（计划—执行）：先让模型根据分析目标和数据集的元数据（表、字段语义、指标口径）生成一份结构化计划，每一步写清步骤名、要分析的问题、SQL 目的和建议图表；再由代码按顺序执行，每一步都复用已有的单次分析链路——生成 SQL、校验执行、失败纠错、图表、解读——把结果和状态落库；最后汇总所有步骤生成报告。分几步、每步查什么由模型决定，每一步怎么取数由代码固定，所以过程可追踪、结果可复现。

详细版

分析目标：「分析最近订单下降的原因，给出排查方向」
  → 模型生成计划（JSON）
      1. 看最近 30 天每日订单数趋势        → 折线图
      2. 按城市对比本月和上月订单数        → 柱状图
      3. 按渠道看订单数变化                → 柱状图
      4. 看退款订单占比是否上升            → 饼图
  → 代码逐步执行：每步 = 一次「生成 SQL → 校验 → 执行 → 纠错 → 图表 → 解读」
  → 每步写入执行记录：状态、耗时、关联的 SQL 与结果、输出摘要、错误信息
  → 汇总各步生成报告

与单次问答相比，Plan-and-Execute 的特点：

	单次 Text-to-SQL	Plan-and-Execute
输入	一个具体问题	一个较大的分析目标
模型决定	一条 SQL 怎么写	分几步、每步分析什么
代码决定	校验和执行	每一步怎么执行、成败怎么判
产出	一份结果、一张图、一段解读	多步结果 + 汇总报告

完整版教学

一、为什么大目标不能一次问完

「分析最近订单下降的原因」这类目标，没办法用一条 SQL 回答：它需要先看趋势确认下降是否存在，再从城市、渠道、品类、退款等多个维度分别拆开看，最后综合判断。如果硬让模型一次写一条巨大的 SQL，要么写不出来，要么写出来没人看得懂、也没法逐项验证。

人类分析师的做法是先列提纲，再逐项取数。Plan-and-Execute 就是把这个工作方式交给系统：模型负责列提纲，代码负责按提纲执行。

二、计划要结构化到什么程度

计划不能是一段自然语言，而要是程序能逐项执行的结构：

{
  "title": "最近订单下降原因分析",
  "steps": [
    {
      "stepName": "订单趋势",
      "analysisQuestion": "最近 30 天每日订单数是多少",
      "expectedSqlPurpose": "按支付日期统计订单数，确认下降的起点",
      "chartSuggestion": "折线图"
    }
  ]
}

每个字段都有用途：analysisQuestion 会作为这一步的输入，交给 Text-to-SQL；expectedSqlPurpose 让用户理解这一步为什么要查；chartSuggestion 帮助图表推荐。计划生成时的上下文只需要表、字段的名称与语义类型、指标的名称与口径，不需要把完整的字段细节都给模型——拆计划看的是「有什么可以分析」，写 SQL 才需要「每一列怎么用」。

三、执行层：复用单次分析能力

执行阶段不需要为 Agent 重写一套取数逻辑，每一步都是一次标准的单次分析：

步骤 i 的 analysisQuestion
  → 生成 SQL（Text-to-SQL）
  → 安全校验并执行
  → 执行失败 → 自动纠错一次 → 再执行
  → 图表推荐
  → 数据解读
  → 写入步骤记录

这正是「把已有业务能力封装成工具，由 Agent 按步骤调用」的思路。好处是单次分析和 Agent 共用同一条经过验证的链路，改进其中一环（比如校验规则），两边同时受益。

记忆钩子：Agent 不需要另写取数逻辑，它是把单次分析链路当成工具，按计划一步步调用。

四、谁决定什么：模型选，代码核

Plan-and-Execute 里的职责划分：

决策	谁来做	原因
分几步、每步分析什么	模型	不同目标的分析维度不同，需要灵活性
每步用什么 SQL	模型生成、代码校验	生成靠模型，安全靠代码
执行顺序、失败重试几次	代码	流程控制要可靠、可测试
这一步算成功还是失败	代码	按业务状态判断，不看模型怎么说
最终报告写什么	模型基于步骤结果生成	汇总归纳是语言任务

这就是它比「让模型一路自己跑」更可控的原因：模型的自主权集中在「拆计划」这一步，执行过程是确定的。

五、Plan-and-Execute 和 ReAct 的区别

	Plan-and-Execute	ReAct
何时决定下一步	一开始就列好全部步骤	每做一步，看结果再决定下一步
优点	过程可预期，步骤可并行，用户能先审计划	能根据中间结果灵活调整
缺点	中间发现新线索时，计划不会自动改	步数不可控，过程难预测
适合	分析维度可以事先列出的报告型任务	需要边探索边决定的任务

数据分析报告通常属于前者：维度可以提前列出，用户也希望先看到计划再执行。如果希望「看到第 2 步结果异常，再加一步深挖」，就需要在计划—执行之上引入重新规划，或改用状态图做条件分支。两种范式的通用对比见「ReAct 与 Plan-and-Execute 有什么区别？Agent 如何选择规划方式？」，状态图的做法见「归因需要逐层下钻时，怎么用状态图决定往下查、往上查还是结束？」。

六、结果如何汇总成报告

每一步执行完，保存的不只是结论，还有可追溯的过程：关联的 SQL、结果摘要、图表配置、解读。报告生成时把这些按步骤整理成结构化数据交给模型，要求它输出分析目标、查询过程、图表结论、关键洞察和行动建议。报告里的图表直接复用各步骤已经生成的图表配置，而不是让模型重新描述，这样报告和分析过程保持一致。

七、重复执行时的产物管理

同一个分析计划可能被反复执行、反复生成报告。如果每次都新增记录，执行历史里会堆满重复的步骤和报告。常见做法是覆盖式管理：

同一会话重新生成计划 → 覆盖原计划，清理旧的执行步骤和报告
同一计划重新执行     → 先删除上一轮的步骤和它们产生的中间分析记录
同一计划重新生成报告 → 覆盖原报告

原则是：用户看到的永远是「当前这一轮」的完整结果，不会把旧一轮的数据混进新报告。

八、常见误区与追问

误区：多步分析就是让模型一次写一条大 SQL。 大目标需要多个维度逐项验证，一条巨型 SQL 既难写对也无法逐项追溯。
误区：Agent 执行时要为每一步单独写取数逻辑。 每一步都应复用经过验证的单次分析链路，把它当成工具调用。
误区：计划写成一段自然语言就行。 计划要结构化成程序可以逐项执行的字段，否则执行层无法可靠地取用。
误区：Plan-and-Execute 一定比 ReAct 好。 它过程可控，但不能根据中间结果自动调整，需要边探索边决定的任务更适合 ReAct 或状态图。
误区：重新执行计划时保留旧结果做对比。 旧步骤混在新结果里会让报告失真，应清理后重跑，只保留最新一轮。
追问：生成计划的上下文和生成 SQL 的上下文一样吗？ 不一样，拆计划只需要表、字段语义类型和指标口径的概要，写 SQL 才需要完整的字段细节。
追问：计划里的某一步失败了，后面的步骤还执行吗？ 通常继续执行，失败的步骤单独标记和记录原因，报告里说明哪一步没有取到数据。

九、加强记忆

大分析目标用 Plan-and-Execute：模型根据目标和元数据先生成结构化计划，每步写清步骤名、分析问题、SQL 目的、建议图表；代码按顺序执行，每一步复用「生成 SQL → 校验执行 → 纠错 → 图表 → 解读」的单次分析链路，把单次能力当工具调用。职责上模型负责拆计划和写 SQL，代码负责校验、流程控制和成败判定，所以过程可追踪、可复现。它和 ReAct 的区别是一开始就列好步骤、不按中间结果调整。报告汇总各步的 SQL、摘要、图表和解读，图表直接复用；重复执行时覆盖旧产物，只保留最新一轮。

项目实战落地

项目里怎么做的

《AI Agent数据分析平台》把计划、执行、报告做成了三个页面：

计划生成：用户选会话、数据集，输入分析目标。后端构建数据集上下文（启用的表、字段名与说明和语义类型、启用指标的名称、公式和 SQL 表达式），要求模型「只返回 JSON，包含 title 和 steps 字段，每步包含 stepName、analysisQuestion、expectedSqlPurpose、chartSuggestion」，结果存进 agent_plan 的 plan_title、plan_steps；
执行追踪：每一步写一条 agent_execution_step，执行时把 analysisQuestion 包装成一次标准分析请求，依次复用生成 SQL、校验执行、失败自动纠错一次、图表推荐、数据解读；这些中间分析记录的来源标为「Agent执行」，和用户手动分析的记录分开展示；
分析报告：按计划汇总所有步骤的问题、状态、SQL、结果摘要和数据洞察，填进「报告生成」模板，要求输出分析目标、查询过程、图表结论、关键洞察和行动建议；报告里的图表复用各步骤保存的图表配置；
覆盖式管理：同一会话重新生成计划会覆盖旧计划并清理旧步骤和旧报告，同一计划重新执行先清理上一轮，同一计划重新生成报告覆盖原报告。

为什么这样取舍

执行步骤不指定模型：每一步生成 SQL 自动走「SQL 分析」模型，图表和解读走「文本分析」模型，计划生成用的模型只影响「拆计划」这一步。
Agent 产生的分析记录单独标记来源：默认的分析页面只看手动分析，不会被 Agent 自动生成的大量中间记录刷屏。

面试官还会追问

删除一个分析计划时，哪些关联数据要一起清理？清理的先后顺序是怎样的？
报告正文里提到了某张图表，页面上却没显示出来，可能是什么原因？项目怎么处理空图表？

学完《AI Agent数据分析平台》，上面这些追问你都会迎刃而解。

简化版

详细版