[Dify实战] 多轮状态不是功能点，而是系统设计题：该怎么拆才不会越做越乱？

很多人做 Dify 多轮对话，第一反应都是：

怎么把上下文记住？

于是很快就会开始堆：

• 会话变量
• 历史消息
• 槽位填充
• 各种状态字段

刚开始看起来还挺顺。

Demo 能跑，追问也像回事，模型好像也“记住了前面说过的话”。

但项目一旦往前走，问题就会马上变味：

• 为什么用户明明改了需求，系统还沿着旧任务继续跑？
• 为什么一插入人工审核，状态就开始混乱？
• 为什么外部系统已经返回失败，流程还在往“成功”方向推进？
• 为什么同一个助手，前几轮还正常，越到后面越容易串状态、串字段、串结果？

这时候你就会发现：

多轮状态从来不是一个“功能点”，而是一道系统设计题。

如果一开始拆错了，后面每多接一个节点、每多接一个外部系统、每多加一层人工确认，复杂度都会往上翻。

这篇文章，我就想把这件事讲透：

为什么 Dify 的多轮状态本质上是系统设计问题？真正该怎么拆，后面才不会越做越乱？