背景
我想做一个电商分析 Agent，并不是因为现有平台没有分析能力。相反，在查阅阿里、京东、拼多多对外公开的产品资料、商家工具介绍和第三方测评时，我能明显感觉到，看板、趋势、排行、同比环比、区域和品类分析这些能力已经很成熟。真正让我在意的，不是“能不能看到数据”，而是业务人员在看到数据之后，能不能更快地发现问题、理解问题，并把问题推动到真正被处理。
从公开材料里能比较稳定地看到一个共性：现有工具通常更擅长展示结果，但从“发现问题”走到“拆解问题”，再到“形成解释”和“推动同步”之间，仍然存在明显的人工串联成本。平台自带工具往往能提供看板、趋势和基础下钻，但一旦问题进入多步归因、跨维度切换、异常解释或跨系统分析，业务人员还是要自己决定下一步看哪个维度、切哪个视图、怎么把多块结果拼成一版结论。这个项目的出发点，就是想把这条分析链尽量往前接住。
需要说明的是，这篇文章记录的是这个项目第一阶段的实践总结。主线能力已经基本跑通，但项目本身还在继续迭代，所以这里更像一次阶段性复盘，而不是最终完结稿。
竞品观察：几类公开可见的电商分析路线
在确定路线之前，我先把公开可见的几类电商分析方案整理成了一张很粗略的研究草图。它不是对三家公司的完整评估，更像是帮助我判断技术路线的一份对照表。
| 公司/代表路线 | 数据基础设施 | AI 分析形态 | 更适合解决的问题 | 公开形态下可见的边界 |
|---|---|---|---|---|
| 阿里 / 重基础设施 + 语义层 | MaxCompute → DataWorks → Hologres → Quick BI | 经营分析、问数、解读、报告、语义层 | 复杂组织下的标准化分析协同 | 指标治理和语义层本身需要持续维护 |
| 京东 / 智能问数 + 诊断分析 | Hive 数仓 → 可视化 / 商家分析平台 | JoyAgent-JDGenie / DataAgent、智能问数、诊断分析 | 高效承接单次查询和基础诊断 | 更偏单次查询和诊断，不天然等于多步归因、连续会话和主动触发 |
| 拼多多 / BI 工具 + 人工协作链 | BI 看板、商家后台、运营工具 | 公开形态更偏后台工具和人工协作 | 承接成熟报表、后台操作和基础分析 | 从公开资料看，自动化分析工作流特征不明显 |
如果把这些路线放在一起看，一个共同点很明显：结果展示已经很成熟，基础分析能力也并不稀缺，真正稀缺的是连续分析工作流。也就是说，问题不在系统能不能答一句话，而在它能不能把“发现问题 -> 拆解问题 -> 形成解释 -> 推动处理”这条链尽量接起来。
我不认为这些平台一定做不到这件事，但从公开可见的产品形态来看，这条能力至少还没有被足够明确地产品化出来。这也是为什么，我最后没有停在“智能问数”这一步。
为什么这个场景更适合 Text-to-Code
电商运营分析的核心问题，天然要落到一串可执行动作上：查数、对比、下钻、归因、汇总，必要时再触发通知。像“昨天 GMV 多少”“哪个区域更差”“为什么跌了”这类问题，真正有价值的不是系统生成一句自然语言，而是系统能不能把问题翻译成稳定的执行链。这也是为什么我没有把项目做成纯聊天或纯 NL2SQL。
电商分析的难点不只是把问题翻译成一条 SQL，而是即使系统能生成 SQL，也不代表问题真的被解决了。在复杂业务场景里，SQL 生成并不总是稳定，尤其当表结构复杂、筛选条件增多、指标口径变化时，很多结果仍然需要人工检查和修正。更重要的是，就算 SQL 语法上是对的，业务语义也不一定真的对。用户说的“活跃用户”“转化率”“订单量”这些词，背后往往对应多种口径；如果没有足够的业务上下文和语义约束，系统很容易查对了表、却答错了问题。对电商运营分析来说，很多问题本身天然就是多步任务。尤其在 root cause 场景下，用户真正想知道的不是“查出来一个数”，而是“这个数为什么变了，下一步该看哪里”。这里的 root cause，可以直接理解成“为什么跌了”这类归因分析链。
AssistantAgent 对这个项目最有价值的地方，就在于它比较适合承载这种 Text-to-Code 风格的业务 Agent。这里的 Text-to-Code，可以先粗略理解成：模型不是只回答一句话，而是生成代码去调工具、查数据和组织分析链。AssistantAgent 也可以先粗略理解成一个偏业务工作流的 Agent 框架：它不只负责和模型对话，还提供代码执行、工具注入、经验复用、触发器和通知这些能力。更直白一点说，如果只是做普通聊天问答，很多框架都能胜任；但如果目标是让系统真正去查数、组织分析步骤、复用高频路径，并在必要时主动触发日报或通知，这类偏工作流的能力就会更有价值。正因为有这些能力，系统才能比较自然地组织一条可执行分析链。
我怎么把 Demo 做成最小业务闭环
我先做的不是让模型直接面对数据库，而是先把高频分析动作做成 Tool，并且不是按表切，而是按业务动作切。最早的一批包括 GMV、区域、品类、订单、用户、退款和漏斗分析。这样做的目的很直接：业务人员问的不是“查 orders 表”，而是“昨天 GMV 多少”“哪个区域更差”“为什么跌了”。如果一开始就让模型直接面对原始表，系统很容易停留在“会查数”，但很难沉淀出稳定的分析动作。
在此基础上，我把问题分成两类：标准快路径和标准深路径。前者对应昨天 GMV、区域对比、品类排行、订单结构、用户概览这些高频稳定问题；后者对应“华东 GMV 为什么跌了”这类更复杂的分析任务。这样的区分有两个作用。第一，它让系统一开始就能把最常见的问题答稳，而不是追求开放能力。第二，它给后面的 Experience、FastIntent 和评测闭环提供了稳定承接点。
整个项目里最重要的一条深路径，是 gmv_root_cause。它不是随便串几个 Tool，而是按分析师常见的归因顺序收敛成一条固定链：区域表现、订单结构、用户规模、品类拆解、漏斗线索和退款线索。这个设计背后的判断是：复杂问题如果没有一条相对稳定的分析顺序，就很容易退化成“一次回答看起来很完整，但下次再问就不一定还能复现”的状态。把 root cause 收成标准深路径之后，系统才真正开始从“能回答问题”走向“能组织分析链”。
所谓“最小业务闭环”，真正闭的不是一个接口调用，而是一条完整的问题链：
- 业务人员先提出一个真实分析问题
- 系统把问题映射成快路径或深路径
- Tool 去查真实数据，而不是只生成解释
- 系统把中间结果组织成结论
- 结论可以继续被追问、被评测，或者在后续主动巡检和推送链路里被自动使用
也就是说，闭环的重点不在“模型说了一句像样的话”，而在“问题有没有顺着系统真正往下跑”。如果用一个最小例子来说明这条闭环，大概会是这样：用户先问“昨天 GMV 多少？”，系统先走标准问数路径；接着用户再问“那华东呢？”，系统继承上一轮上下文切到区域维度；如果用户继续问“为什么跌了？”，系统就不再只报一个数，而是沿着区域、订单结构、品类、漏斗和退款这条固定归因链往下查，最后给出一版结构化解释。到了主动触发场景，这条链还可以进一步被复用到日报和异常巡检里。
如果第一次接触这些术语，可以先这样理解：Experience 更像系统沉淀下来的经验模板，告诉模型这类问题通常该怎么处理；FastIntent 更像高频问题的快速分流机制，用来让“昨天 GMV 多少”这类标准问题不要每次都从零推理；verified cases 可以理解成人工确认过的标准样例；runtime bad case snapshot 则是在运行时把失败样本回流出来，方便下一轮继续修。
这也是为什么我后面会继续补会话状态、时间语义、指标词典和歧义澄清，让系统开始听得懂“那华东呢”“那女装呢”“那退款率呢”这类业务表达；再补 Experience、FastIntent、verified cases 和 runtime bad case snapshot，让高频问题和标准深路径真正收回到框架主链里；最后再补定时日报、异常巡检、通知输出、多基线异常判断、只读保护、防重复推送、持久化幂等、缓存和降级，把这条链从“有人问才会跑”推进到“系统自己也能跑”。
与此同时，我还并行做了一条 Olist 数据升级支线，把公开电商数据接入项目，并逐步构建 raw -> dwd -> dim -> ads。接这条支线的原因，不是为了把项目包装成“用了公开数据就更高级”，而是因为当主链已经跑通之后，我需要回答一个更实际的问题：这个系统到底是在围绕几行手工样例工作，还是能落到一套外部可复现的数据集上。引入 Olist 的价值，主要有三点。
第一，它给项目补了一层可复现的数据来源。只用手工 seed data，可以很快打通主链，但系统很容易带有“为了演示而构造”的味道；接入公开数据之后，至少可以证明这条分析链不是只对几行样例成立。第二，它让 raw -> dwd -> dim -> ads 这套分层不再只是概念，而是变成了一条真实的数据加工链。第三，它迫使我重新审视业务口径和数据口径之间的差距：哪些能力可以直接迁过去，哪些能力必须继续留在当前主链里。
也正因为这样，我没有一口气全迁，而是优先迁 GMV、区域、品类和订单结构，把用户、漏斗、退款暂时留在 demo 主链。原因很简单：公开数据能不能导入是一回事，能不能承接当前业务口径是另一回事。这个取舍本身也是“最小闭环”思路的一部分：先保住主链，再逐步提高数据可信度。
过程中最关键的几个坑
1. 一开始最容易把项目做成“万能 Agent”
这个坑几乎是所有 Agent 项目都会遇到的。只要一开始目标没有收住，就很容易变成“什么都想做”：既想支持开放问答，又想做复杂归因，还想接多轮、接评测、接主动触发，最后结果通常不是功能太少，而是主线不清楚。系统看起来做了很多事，但每一层都不够稳，也很难讲清楚到底先解决了什么核心问题。
我后来做的第一个重要收敛，就是把问题分层。先做高频标准问题，再做标准深路径，然后再补多轮理解、评测闭环和主动触发。这个顺序不是工程实现上的方便，而是产品节奏上的必要。如果一开始不先把“昨天 GMV 多少”“哪个区域更差”“为什么跌了”这种高频问题做稳，后面再加 Experience、FastIntent、Trigger，其实只是把不稳定的问题包装得更复杂。
真正让系统开始站住脚的，不是它会的事情越来越多，而是它先明确了自己优先解决哪一类问题。
2. 没有最小数据底座时，很多 Agent 逻辑都只是“看起来能跑”
第二个很容易低估的坑，是数据底座。如果一开始没有一套最小可用的数据链，很多 Agent 能力其实只是停留在表面上：Tool 可以定义出来，问答链也可以组织出来，甚至多轮、Experience、FastIntent 都能接，但这些东西很容易停留在“逻辑成立”，而不是“业务成立”。
我在这个项目里很早就意识到，如果没有最小演示数仓，很多能力只是“看起来能跑”。比如 root cause 可以写成一条很漂亮的分析链，但如果背后没有大盘、区域、品类、订单、用户、漏斗、退款这些最小数据表支撑，它本质上还是一个结构化回答模板，而不是真正的分析系统。也正因为这样，我先接了最小 seed data，把主链打通，再往后补 Experience 和多轮，而不是反过来先做框架层的“高级能力”。
后面接 Olist 公开数据时，这个问题又出现了一次，只是形态不一样。那时的坑不再是“有没有数据”，而是“数据能不能承接现在这条业务分析链”。这也是为什么我没有一口气把所有链路都迁到 Olist，而是先迁 GMV、区域、品类和订单结构，把用户、漏斗、退款暂时留在 demo 主链。因为数据能导入，不等于它已经能支撑你当前的业务口径。
3. 复杂问题如果一开始完全交给模型自由规划，既不稳也难评测
第三个坑和很多人对 Agent 的直觉有关：大家很容易觉得，越开放、越自由规划，系统就越“智能”。但在电商运营分析这个场景里，这种直觉不一定对。尤其是“为什么跌了”这类问题，如果一开始完全交给模型从零规划，它当然有可能给出一段看起来很完整的分析，但真正落到系统设计上，会暴露两个问题：第一是不稳，第二是难评测。
不稳体现在，同一个问题每次可能走不同路径，关注的维度不一致，甚至结论的组织方式也会漂。难评测体现在，你很难定义“这次到底答得对不对”，因为链路本身没有稳定结构。后来我做的收敛，是把这类高频复杂问题先做成标准深路径。比如 gmv_root_cause 不再是一次开放探索，而是先按区域、订单结构、用户规模、品类、漏斗、退款这条顺序去组织分析。
这并不意味着系统变笨了，而是意味着它先获得了一条稳定、可复用、可验证的分析链。对于业务型 Agent 来说，这一点比“看起来更自由”重要得多。因为很多时候，业务要的不是一个每次都不同的精彩回答，而是一条可以重复跑、可以积累经验、可以纳入评测的分析工作流。
最后收敛下来的 gmv_root_cause，本质上就是这样一条固定分析链：
gmv_root_cause: 1. 查询区域表现 2. 查询订单结构 3. 查询用户规模 4. 查询品类拆解 5. 查询漏斗线索 6. 查询退款线索
4. 主动触发一旦开始，如果没有保护层，系统很容易从“助手”变成“事故源”
前面几个坑更多是产品能力层面的，到了项目后期，第四个坑开始变成运行层的坑。也就是：当系统从“你问我答”走向“自己出手”之后，很多之前不那么致命的问题会突然变得很致命。
比如日报自动发送、异常自动巡检、root cause 自动推送，这些能力从产品角度都很有价值，但一旦系统开始主动运行，就不能再沿用本地 demo 的心态了。没有幂等，系统可能会重复推送；没有去重，同一个异常可能刷很多次通知；没有只读保护，查询链就存在被误用的风险；没有降级策略，某个外部 webhook 挂掉就可能让整条链失败。也就是说，系统越主动，运行层越不能模糊。
这也是为什么我后面花了不少精力去补那些看起来不那么“智能”的东西：只读保护、防重复推送、持久化幂等、缓存、超时、降级。这些能力在项目展示里往往不如“多轮理解”“智能归因”那么显眼，但如果没有它们，系统一旦真的开始定时工作、自动报警、主动推送，就很容易从“分析助手”变成“事故源”。
在实现上，我后来更关心的已经不是“再多加一个能力”，而是先把运行规则守住，比如：
app.reply.persistent-notification-dedup-enabled: true app.reply.notification-fallback-to-ide-log-enabled: true app.datasource.read-cache-enabled: true app.operations.gmv-drop-watch.threshold: 0.15
这几行配置背后对应的，其实都是非常具体的运行问题：同一条通知会不会重复发送、外部 webhook 挂掉时会不会让整条链失败、高频查询有没有最小缓存保护、异常巡检到底按什么阈值触发。
从这个角度看，这个项目最重要的认识之一就是：业务型 Agent 的难点并不只在“让模型会做事”，还在“让系统做事时别闯祸”。
总结
回头看，这个项目最重要的并不是做了多少 Tool，也不是接了多少数据表，而是逐步验证了几件事情：电商运营分析并不只是“把一个问题回答出来”，而是要尽量把发现问题、拆解问题、形成解释和推动处理这条链串起来；标准快路径、标准深路径、多轮理解、评测闭环和主动触发，不适合被拆成彼此孤立的功能点，它们更像是业务型 Agent 从 Demo 长成产品雏形时必须依次补齐的层；公开数据接入、异常阈值、幂等和降级这些看起来不那么“智能”的部分，往往决定了系统能不能真正稳定运行。
这也是我对 AssistantAgent 的最终感受：它更适合承载一条围绕真实业务工作流展开的分析链，而不是只停留在单轮问答层。
