AssistantAgent 电商分析 Agent 系列 03：怎么把“为什么跌了”做成一条标准归因链

背景

前两篇分别写了两件事：第一篇是怎么把电商分析 Agent 从问答 Demo 推到最小业务闭环，第二篇是为什么多轮追问不能只靠聊天记录，而要有最小业务记忆。

这篇继续往下走，讲一个更典型的业务问题：

华东 GMV 为什么跌了？

这个问题看起来只是一句自然语言，但它其实不是一个简单问答。业务人员问"为什么跌了"时，真正想要的通常不是一句"因为订单少了"，而是一条可解释、可复查、能继续推动处理的分析链。

如果系统只回答一个结论，价值很有限；如果系统每次都让模型自由发挥，又会出现另一个问题：这次看品类，下次看退款，再下次又先看渠道，路径不稳定，结论也很难复用和评测。

所以我在这个项目里对 gmv_root_cause 做了一个收敛：不把它当成开放问答，而是先把"为什么跌了"沉淀成一条标准归因链。

为什么不能完全交给模型自由规划

做 Agent 项目时，很容易有一种冲动：复杂问题就让模型自己规划。用户问为什么跌了，模型可以自己决定先查什么、再查什么，最后组织一段解释。这个思路看起来更智能，但放到业务分析里会有几个明显问题。

第一个问题是路径不稳定。同样一句"华东 GMV 为什么跌了"，如果模型这次先看品类，下次先看退款，第三次又先看用户规模，那每次结果都可能不一样。对普通聊天来说，这可能还能接受；但对经营分析来说，路径不稳定就意味着结论难复盘。

第二个问题是难评测。如果系统没有固定分析顺序，就很难判断一次回答到底是"完整"还是"漏了关键环节"。比如它只看到了品类下滑，但没有检查订单结构和用户规模，这算不算通过？如果没有标准链路，评测会变得很主观。

第三个问题是很难接主动触发。后面如果要做每日异常巡检，系统不能每次发现 GMV 下滑后都临场发挥。更稳的做法是：异常触发后，直接复用同一条 root cause 链，生成同一种结构的结论、证据和通知草稿。

所以这里的设计判断是：复杂问题不一定要一开始就完全开放。对高频、重要、可复用的复杂问题，先收成标准深路径，反而更适合业务系统。

先从一个最基础的公式开始

GMV 下跌的归因，不能一上来就看一堆维度。最基础的拆法其实很简单：

GMV = 支付订单量 × 客单价

也就是说，GMV 变差，第一层至少要先问清楚：

• 是订单量变少了？
• 还是客单价变低了？
• 还是两边都在变？

这一步看起来很基础，但它决定了后面应该往哪里下钻。

如果订单量明显下降，下一步就要看用户规模和转化过程：是不是 DAU 少了，活跃买家少了，还是流量还在但没有成交。

如果客单价明显下降，下一步就更应该看品类结构、价格带、商品组合。

如果订单量和客单价都不是主因，还要继续看退款和售后是否放大了经营压力。

所以 gmv_root_cause 的核心不是"把所有 Tool 都调一遍"，而是把这些业务判断组织成一条固定顺序：

区域表现 -> 订单结构 -> 用户规模 -> 品类拆解 -> 漏斗线索 -> 退款线索

这条链的目标，是让系统能先回答一个更重要的问题：

这次 GMV 下滑，更像是用户规模问题、订单结构问题、货盘品类问题、转化问题，还是售后问题？

标准归因链怎么设计

我最后把 gmv_root_cause 收成了 6 步。

第一步是区域表现。先确认目标区域当天和对比日的 GMV 是否真的下滑。这个步骤解决的是"异常是否成立"，而不是一上来就解释原因。

第二步是订单结构。这里看订单量、支付订单量、客单价和支付金额，判断 GMV 变化到底是单量驱动，还是客单价驱动。对应项目里的 OrderQueryTool。

第三步是用户规模。这里看 DAU、活跃买家和买家激活率，判断问题是不是先从用户盘子开始。对应项目里的 UserMetricTool。

第四步是品类拆解。这里看哪些品类贡献了主要下滑，而不是只看当前哪类 GMV 最大。现在这一步已经从"看当前切片"改成了"比较前后两天差值"，这样才能回答"主要拖累来自谁"。对应项目里的 CategoryRankTool。

第五步是漏斗线索。这里看浏览到支付、下单到支付等转化是否变化，判断问题是流量承接差，还是前面用户和订单结构已经能解释。对应项目里的 FunnelAnalysisTool。

第六步是退款线索。这里看退款金额、退款金额占比和退款集中在哪些品类或商家，判断售后是否进一步放大了 GMV 压力。对应项目里的 RefundAnalysisTool。

这 6 步不是为了显得复杂，而是为了把"为什么跌了"拆成一个稳定的业务排查顺序。

在项目里怎么落地

当前项目里，这条链不是只写在文档里的分析框架，而是已经落到了固定 Tool 链上：

RegionPerformanceQueryTool
-> OrderQueryTool
-> UserMetricTool
-> CategoryRankTool
-> FunnelAnalysisTool
-> RefundAnalysisTool

在 Experience 里，我也把"华东 GMV 为什么跌了"这类标准问题固化成一个固定 plan。它不是每次都让模型重新决定工具顺序，而是按区域、订单结构、用户规模、品类、漏斗和退款依次执行。

这个设计有一个很直接的好处：系统输出不再只是自然语言回答，而是有结构化结果。

当前 RootCauseAnalysisBuilder 会把结果组织成几类信息：

summary                核心结论
sections               分段归因
decision_trace          主要原因排序
action_routing          责任分发
notification_draft      通知草稿
evidence_confidence     证据可信度
data_lineage            数据来源
facts                   原始事实摘要

这一步很关键。因为 root cause 的结果后面不只给页面展示，也会被日报、异常巡检和通知链复用。如果每个入口都自己拼一段话，后面一定会乱；把结构化结果抽成统一 DTO / builder 后，同一份 root cause 可以同时服务页面、Trigger 和 Reply。

为什么要加数据来源和可信度

这个项目里还有一个现实问题：公开数据和真实业务数据之间有差距。

我现在接入了 Olist 公开电商数据，但它更适合承接订单、区域、品类这些经营分析，不适合完整承接用户行为、漏斗和退款口径。因为 Olist 没有完整的浏览、点击、加购、支付前链路事件，也没有足够干净的退款事实层。

所以当前 root cause 是一条混合数据链：

• 区域、订单、品类优先使用 Olist 公开数据
• 用户、漏斗、退款暂时使用逻辑补齐的 demo 口径

这不是为了包装项目，而是为了让分析链既能用公开数据提高可信度，又不牺牲当前已经补齐的业务口径。

但这里必须讲清楚边界。系统不能把 demo 补齐口径说成真实生产数据，所以我在 root cause 结构里加了 data_lineage 和 evidence_confidence。它们的作用就是告诉读者和使用者：

这条判断来自公开数据，还是来自 demo 补齐口径？
这条证据可信度高、中，还是需要继续补真实数据？

这对业务型 Agent 很重要。因为一个分析系统不只是要给结论，还要告诉你结论的证据来源。否则系统说得越流畅，越容易让人误以为它"都是真的"。

从归因到责任分发

只回答原因还不够。真实业务里，分析结论最后还要推动处理。

比如系统判断主要问题在品类下滑，那这件事应该同步给类目运营；如果退款压力集中在某些商品或商家，就应该同步给售后治理或商家运营；如果用户规模先走弱，就要同步给增长或渠道负责人。

所以 gmv_root_cause 后面继续补了 action_routing，也就是责任分发。它不是简单展示"谁负责"，而是把每类原因和下一步动作对应起来：

原因：品类拖累明显
对象：类目 / 行业运营
动作：定位拖累品类下的重点商品、商家、库存和活动资源

这一步让 root cause 从"解释问题"往"推动处理"靠近了一点。虽然它还不是完整工单系统，也没有真正接入企业内部协同流程，但已经从分析结果走到了通知草稿和责任角色。

这也是我觉得业务型 Agent 和普通问数最大的区别之一：问数回答的是"发生了什么"，root cause 要继续回答"为什么发生、证据是什么、谁应该继续看"。

这里踩过的坑

第一个坑，是一开始容易把 root cause 写成"多查几个维度"。但多查不等于会归因。如果没有明确顺序，系统只是把区域、品类、退款、漏斗结果堆在一起，读者还是不知道主因是什么。

第二个坑，是品类拖累不能只看当前值。当前 GMV 最大的品类，不一定是下滑最大的品类。真正要判断"谁拖累了 GMV"，应该比较当前日和对比日的差值。这一步不改，结论就很容易看起来合理但业务上不对。

第三个坑，是不能把公开数据能力讲过头。Olist 适合迁区域、订单、品类，但不适合马上迁用户、漏斗和退款。如果为了"全公开数据"强行全迁，反而会让分析口径变差。

第四个坑，是 root cause 必须进入验证。当前项目里启动校验会检查固定 Tool 链、Olist 数据来源、结构化 root cause、责任分发等结果。如果没有这些验证，后面改 Tool 或页面时，很容易把深路径弄坏。

当前边界

这条标准归因链还不是完整的生产级经营诊断系统。

它目前更像一个业务系统雏形：能围绕 GMV 下跌跑出一条稳定链路，能展示证据、原因排序、数据来源和责任分发，但还没有接入真实企业内部的用户行为流、广告投放、履约物流、商家治理和完整售后数据。

所以更准确的说法不是"系统已经完全会归因"，而是：

系统已经把一个高频复杂问题，从开放问答收敛成了可复用、可展示、可验证的标准归因链。

这个边界很重要。因为项目当前的价值不在于声称已经替代分析师，而在于证明业务型 Agent 可以从"报数"进一步走到"按固定业务套路自动拆解问题"。