案例分析二：分析“昨天收入为什么下降”——Agent 和普通 Text-to-SQL 的分界线

场景背景

假设我们做一个数据查询系统。

用户问，“为什么昨天广告收入比前天低了 20%？”

最简单的 Text-to-SQL：

自然语言
  ↓
生成 SQL
  ↓
执行 SQL
  ↓
LLM 总结
  ↓
返回

已经很有用。

问题矛盾

如果第一条 SQL 只得到：

昨天收入：80 万
前天收入：100 万
下降：20%

我们只证明了“确实下降”。

没有回答“为什么”。

真正调查可能是：

• 按媒体拆；
• 按广告位拆；
• 看请求；
• 看曝光；
• 看点击；
• 看填充率；
• 看 eCPM；
• 判断是否数据延迟。

而这些路径不应该每次全部跑。

如果媒体 A 正常、媒体 B 异常，就应该优先继续查 B。

输入与前置条件

系统提供：

query_metric
query_by_dimension
get_schema
execute_sql

固定安全规则：

只允许 SELECT
最多查询 30 天
禁止 SELECT *
限制表白名单
设置 SQL 超时
限制最大返回行数

解决过程

Agent 可能执行：

Goal：解释收入下降原因
 ↓
查询总收入
 ↓
Observation：确认下降 20%
 ↓
按媒体拆
 ↓
Observation：media_B 下降明显
 ↓
查询 media_B 的请求、曝光、eCPM
 ↓
Observation：请求稳定，eCPM 下降 35%
 ↓
继续按广告位拆 eCPM
 ↓
Observation：position_102 降幅最大
 ↓
形成结论

关键不是 SQL 更复杂。

关键是，每一轮查询结果都会改变下一轮查询方向。

下面这张对照图把普通 Text-to-SQL 与分析型 Agent 的分界线放在了同一个画面里：

左侧的一次查询只能确认收入确实下降；右侧会让媒体、eCPM 和广告位等结果依次进入 Observation，推动下一轮查询逐步收敛到原因证据。同时，SELECT、时间范围、表白名单和超时仍由固定安全规则控制，动态分析并不等于动态放权。

输出结果

最终可能是：

收入下降主要集中在 media_B。

media_B：
- 请求量基本稳定；
- 曝光量下降约 3%；
- eCPM 下降约 35%；
- position_102 的 eCPM 降幅最明显。

因此当前证据更支持：
收入下降主要来自变现价格下降，
而不是整体流量掉量。

复盘与迁移

这里能特别清楚地看出：

Workflow：
权限、安全、超时、审计

Agent：
决定查什么、是否继续下钻、何时停止

Agent 与普通 Text-to-SQL 的区别，不只是“多查几次 SQL”。

而是，查询结果进入 Observation 后，真正参与下一步决策。

这就是动态分析。

后面我们的 Data Analysis Agent 会完整实现这条链路。

常见误区

误解： 只要系统用了大模型，就可以叫 Agent。
正解： 大模型只是一个组件。一个固定流程可以调用很多次 LLM，例如“摘要 → 分类 → 标题”，但只要顺序仍由程序提前写死，它本质上还是 Chain。判断是不是 Agent，要看模型是否参与了运行路径的决策：它是否能根据 Goal、State、Observation 和 Tools 选择下一步，而不是只负责某个节点的输入输出。

误解： DAG 比 Chain 高级，Agent 比 DAG 更高级，所以 Agent 是 DAG 的替代品。
正解： 它们不是简单的升级关系。Chain 擅长固定顺序，DAG 擅长复杂依赖，Workflow 擅长业务规则，Agent 擅长开放式动态决策。一个支付审批流程即使有上百个节点，也不应该因为“复杂”就改成 Agent。架构选择应该看问题特征，而不是看哪个名词更新。

误解： Agent 越自主越好，最好让它自己决定所有事情。
正解： 生产系统恰恰需要控制自主性。模型适合决定“下一步查什么、做什么”，但权限、SQL 安全、文件边界、最大步数、超时、审批等必须由确定性代码控制。Agent Harness 的核心价值之一，就是把模型的自主能力限制在安全边界内，而不是把系统控制权全部让出去。

误解： Workflow 只要有 if/else，就已经和 Agent 差不多。
正解： Workflow 的动态分支通常仍然来自预定义规则，例如 score > 0.8 走 A，否则走 B。虽然运行时才知道结果，但路径集合已经写好了。Agent 面对的是更开放的语义状态，它会根据 Observation 从多个工具与参数组合中重新选择动作。关键不在“有没有分支”，而在“分支逻辑是谁决定的”。

误解： 一个任务有很多步骤，就适合用 Agent。
正解： 步骤数量不是判断依据。固定的 ETL 可以有 30 步，仍然更适合 DAG / Workflow。反过来，“帮我修一个 Bug”只有一句目标，但路径高度不确定，更适合 Agent。判断核心应是：能否提前列完整路径、是否需要根据语义反馈改变下一步、动作空间是否难以穷举。

误解： Agent 一定要先生成一个完整 Plan，然后才能执行。
正解： Plan 只是 Agent 的一种策略，不是必要条件。很多 Agent 直接采用 Reason → Action → Observation 循环，每轮根据最新反馈决定下一步。后面我们会专门讨论 Planner，但这一节先记住：Agent 的本质是动态决策闭环，而不是“先列一张 Todo List”。