经营分析平台：接口、工作流、对话框怎么定

经营分析平台：接口、工作流、对话框怎么定

写这篇东西，是因为做 AI 经营分析时，这三件事几乎每次都会一起乱：

1. 店长能问的经营问题很多，到底要开多少个接口？
2. 每个接口背后，是不是都要单独配一套智能体工作流？
3. 前端是做一个对话框，还是做多个入口？

很多人会下意识选「一个万能智能体 + 一个对话框 + 一个接口」，觉得这样最省事、也最像 ChatGPT。做经营分析，这套往往先爽后崩：步骤不固定，出了问题不知道该查谁，换一批问法结果就不一样。

先把结论放这里：

按「经营任务类型」来定，不按每一句话来定。一类任务 = 一套工作流 = 一个分析接口。前端可以只有一个对话框，但对话框下面仍然要分流到不同工作流，不能把所有问题打进同一套万能智能体。

这篇不绑某一种框架、某一套类名。Spring 还是 FastAPI，LangGraph 还是自研编排，判断方法一样。

---

目录

1. 先分清四样东西，别把 Controller 当成智能体
2. 有很多经营问题，要开多少个接口
3. 接口背后是不是都对应一套单独工作流
4. 前端做一个对话框，还是多个入口
5. 智能体按什么拆，不按什么拆
6. 第一版怎么起步，平台变大怎么加
7. 一张总图和三句口诀

---

1. 先分清四样东西，别把 Controller 当成智能体

很多人会把这四层混在一起，所以会觉得：写一个 HTTP 接口，后面再挂一堆 Agent 就行了。

名称	是什么	例子
经营任务	店长要办成的一件事	「上周 GMV 为什么掉了，并给本周动作」
工作流	这件事固定怎么分析，谁先谁后	先看指标，再并行看商品 / 流量 / 评价，最后给动作
智能体	工作流里的专家，各自读一类数据、写一段结论	指标专家、商品专家、投放专家
接口	任务的触发入口	/commerce/analyze 这种分析接口

接口不是智能体。服务层也不是智能体。它们只是把任务启动起来，再把结果拿回来。

工作流定义和服务编排，也不是专门伺候某一个 Controller 的附属品。它们描述的是「这条任务怎么执行」。同一套分析，可以被页面对话框触发，也可以被定时周报触发，也可以被预警消息触发。入口可以有多个，任务本身还是那一类。

四层一旦混了，后面三个问题都会答错：

• 把「一句话」当成「一类任务」，接口会无限膨胀。
• 把「一个接口」当成「一个万能大脑」，工作流会失去边界。
• 把「一个对话框」当成「一套分析逻辑」，前端壳和后端骨架会绑死。

---

2. 有很多经营问题，要开多少个接口？

不要一个问题一个接口。

用户可能这样问：

• 上周 GMV 怎么掉了？
• 是不是销量不行？
• 外面天气......不对，是转化是不是差了？
• 给我出点本周动作。

这些话术不同，但都是同一类任务：店铺经营异常归因，并给出动作。

所以它们共用一个分析接口，共用同一套工作流。

只有任务的「目标、步骤、数据」变了，才需要新接口、新工作流。

任务类型	用户典型问法	分析步骤是否同一套	要不要新接口
GMV 归因 + 动作建议	为什么掉了、怎么办	看经营指标，再拆商品 / 流量 / 评价	一类，一个接口即可
投放计划复盘	直通车是不是亏了、预算怎么调	不同，看的是计划 / 花费 / ROI	另开
滞销品处理	哪些货该降价、该停采	不同，看的是库存周转和动销	另开
差评预警	最近差评为啥涨	不同，看的是评价聚类和售后	另开
同一类的换种说法	「GMV 怎么了」「是不是转化不行」	同一套	不要新开

判断口诀：

• 问法变了，任务没变 → 还是原接口
• 要看的数据变了，分析步骤变了 → 新工作流，新接口
• 只是换了店铺、换了时间 → 还是原接口，把店铺、周期当参数

也可以把它想成三个问题，三个都「是」才新开：

1. 这件事要达成的目标，是不是换了？
2. 固定分析步骤，是不是换了？
3. 主要依赖的数据域，是不是换了？

只换了说法，或者只换了筛选条件，不要新开。

第一版如果只有「经营归因」这一类，有一个分析接口就够了。平台变大，是 多几条这样的任务，不是把所有专家塞进现在这一个接口。

也不要给每个取数工具开 HTTP 接口。店铺指标查询、商品洞察、流量明细，是给模型取数用的，不是给前端点的。前端问的是「为什么掉了、怎么办」，不是「帮我调一下指标工具」。

两种常见死法，都见过：

第一种：一句话一个接口。

/gmv-drop、/conversion-drop、/give-me-actions 各开一条。用户换种说法就 404，后端也维护不动。

第二种：所有问题进一个接口。

投放复盘、滞销处理、差评预警全打进 /analyze。表面上接口很干净，里面却是一套没有边界的超级智能体。结果不稳定，出了错也无法复盘是哪一步跑偏。

正确的粒度在中间：一类经营任务，一个分析接口。

---

3. 接口背后是不是都对应一套单独工作流？

是。至少在「工作流优先」的架构里，应该是这样。

推荐关系：

一类经营任务
    └── 一个分析接口
            └── 一个服务方法
                    └── 一套工作流（串行 / 并行组合好的固定步骤）
                            └── 一组智能体（每个专家 + 自己的工具 + 自己的产出）

也就是说：

1. 一个接口背后，对应一套单独定义的工作流。
2. 这套工作流里，配置、组合了一系列智能体。
3. 智能体怎么串行、怎么并行，写在工作流配置里，不写在接口层。

接口层只负责收参数、启任务、返回结果。它不应该知道「先调哪个专家、哪个可以并行」。

以「经营归因」为例，工作流通常长这样：

经营归因接口
    → 服务层启动工作流
        → 先做指标解读（必须先知道异常在哪）
        → 再并行做商品 / 流量 / 评价诊断
        → 最后汇总成动作建议

如果以后加「投放复盘」，不要把投放专家塞进现在这条流水线。应该再配一套工作流、再开一个接口。两条任务步骤不同，硬揉在一起，模型会乱跑，结果也不好比对。

接口怎么暴露，可以有两种写法，效果等价：

• 多个接口：/commerce/analyze、/ads/review、/product/slow-movers（更直观，推荐）
• 一个接口加场景参数：/analyze?scene=gmv / scene=ads（接口少，但服务层仍要按场景选不同工作流）

无论哪种，背后都是多套工作流，不是一套包打天下。 场景参数只是路由，不是把所有专家焊进同一个大脑。

工作流优先，图的就是三件事：

1. 步骤固定。 同一类任务，每次都按同一套顺序跑，结果才好比、才能回归。
2. 责任可拆。 指标看错了查指标专家，动作胡建议查最后一步，不要整段黑盒重跑。
3. 数据域隔离。 商品专家只碰商品数据，投放专家只碰投放数据，工具权限也跟着收窄。

如果某个接口背后没有独立工作流，只是把用户原话丢给一个挂了全部工具的智能体，那就还是「对话优先」，只是外面套了一层 API。

---

4. 前端做一个对话框，还是多个入口？

对话框是产品壳，工作流是后端骨架。两者不是 1:1。

方案 A：一个对话框（可以，也最像 ChatGPT）

用户只看到一个输入框。真正流程是：

用户随便问
    → 先做意图识别（规则，或一个很薄的路由智能体）
        → 识别为「GMV 归因」   → 调经营归因接口
        → 识别为「投放复盘」   → 调投放复盘接口
        → 识别为「滞销处理」   → 调滞销处理接口
        → 识别不清             → 追问用户是哪一类

这意味着：

• 前端可以只有一个对话框
• 后端仍然是多套工作流、多个接口
• 对话框负责「听懂用户想办哪件事」，工作流负责「把这件事办完」

意图识别要薄。它只做分流，不做分析。别让路由层自己查数、自己写结论，否则分流和工作流又混回去了。

不要让这一个对话框直接打进唯一一个挂了全部工具的超级智能体。那和「工作流优先」是反着的：步骤不固定，出了问题很难查是哪个专家的责任。

方案 B：多个入口，每个入口里还是对话框（更稳）

页面上先放几个明确入口：「经营归因」「投放复盘」「滞销处理」。点进去再聊天。

每个入口已经绑死一套工作流，不用猜意图，结果更稳。适合内部经营系统、店长每天有固定动作的场景。

入口里仍然可以是对话框。用户继续追问「是不是转化不行」「那就给动作」，只是这些追问还在同一类任务里，不会跳到投放复盘。

怎么选

你更在意	选
像一个助手，用户随便问	一个对话框 + 后台分流
步骤稳定、结果可解释、好排查	多个入口，每个入口一套工作流
工作流优先	后端必须多套工作流；前端两种都行

还有一种折中，内部系统里很常见：顶部是场景入口，入口里是对话框，对话框上方再留一个「转到其他任务」的入口。用户既不用从零猜意图，也不用每次回到首页重选。

无论选哪种，前端传给后端的都应该是「用户问题 + 店铺 / 周期 / 场景」，而不是前端自己拼分析步骤。分析步骤属于工作流，不属于页面。

---

5. 智能体按什么拆，不按什么拆

按经营角色和数据域拆，不按工程文件夹拆。

要拆成两个智能体，当同时满足：

• 职责不同（一个看商品，一个看投放）
• 用的数据 / 工具不同
• 或者可以并行，拆开能少等

不要拆，当：

• 同一个人设、同一批数，只是多写两句（解读 GMV 和解读转化不必拆成两个专家）
• 只是接口层、服务层、配置层三个文件夹（那是工程分层，不是经营角色）
• 只是为了让架构图上专家更多（专家多不等于分析更准，上下文和费用会一起涨）

以经营归因为例，常见拆法是「1 + N + 1」：

• 指标解读必须先做，否则后面不知道异常在哪 → 单独、串行
• 商品、流量、评价看的表不同，可以同时做 → 多个专家并行
• 动作建议不查新数，只做决策 → 单独、放最后

这是 这一类任务内部 怎么拆专家。另一类任务会有另一套拆法，不要复用错。

投放复盘很可能是：先拉计划花费，再并行看创意 / 人群 / 时段，最后给预算调整。

滞销处理很可能是：先看周转和库龄，再并行看定价 / 流量 / 可替代品，最后给降价或停采。

步骤长得像，并不等于可以共用一套工作流。看的数据不同，决策标准不同，就该分开。

工具也不要和智能体一一对应到接口上。工具是专家的手，接口是任务的门。店长进的是门，不是去握某一只手。

---

6. 第一版怎么起步，平台变大怎么加

第一版建议故意做窄：

• 后端先只做一类任务，例如经营归因，只开一个分析接口、一套工作流
• 前端可以先做一个对话框，只接这一类问题；识别不清就明说「我目前只会做经营归因」
• 取数工具只给这一类任务用到的数据域，不要提前把投放、库存、评价的工具全挂上

不要第一版就做万能助手。一类任务跑稳了，你才知道：

• 接口入参要哪些（店铺、周期、对比基准通常就够）
• 工作流哪一步最容易胡说
• 前端要不要改成多入口

平台往后加能力，是再复制这一套「接口 + 工作流 + 服务」，而不是把新专家全部塞进现有接口。

可以按这个顺序加：

1. 第二类任务真的出现了，且现有步骤接不住 → 新工作流、新接口
2. 前端已经经常被问到第二类 → 再加分流，或再加一个入口
3. 同一类任务开始被定时任务、预警、群机器人调用 → 复用同一套服务和工作流，不必再包一层新接口给每个触发源

触发源变多，不等于任务类型变多。对话框、周报、预警可以打同一类任务；投放复盘仍然是另一类。

什么时候不要加：

• 用户只是把「为什么掉了」说成「帮我看看最近不好」
• 只是多了一个店铺、多了一个自然周
• 只是想在结论里多写两句「也看看转化」------这仍然是归因任务里的一个分析角度，不是新任务

---

7. 一张总图和三句口诀

【前端】
  一个对话框  或  多个场景入口
        │
        │  只传：用户问题 + 店铺 / 周期
        ▼
【意图分流】（第一版可以不做，只有一类任务时）
        │
        ├─ GMV 归因     →  经营归因接口
        ├─ 投放复盘     →  投放复盘接口
        └─ 滞销处理     →  滞销处理接口
                │
                ▼
【每个接口背后】
  接口层  →  服务层  →  一套独立工作流
                        （组合好的一组智能体）

口诀就三句：

1. 一类经营任务，一个分析接口。
2. 每个接口背后，单独定义一套工作流，里面组合一组智能体。
3. 前端可以只有一个对话框，但对话框下面要分流；不能一个万能工作流接所有问题。

记住一件事就够了：用户换说法，不是新系统；用户换目标，才是新系统。