引子：一个你一定遇到过，但很难精确描述的问题
在智能体项目里，有一种非常让人抓狂的现象：用户明明已经说过一件事，Agent 却在第 5 轮、第 8 轮，像“第一次听说一样”重新理解了一遍。你会看到一些熟悉的症状：
Agent 忘了刚刚确认过的约束
对话越长，回答越发散
为了“保险”，Prompt 越写越长
问题不稳定，难以复现
最后往往归结为一句话：“LLM的记忆不太稳定”。但这其实是一个错误诊断。
一、这不是“记忆”问题
在工程上，“对话状态管理”被严重误解成了“记忆能力”。但你真正需要的不是：模型记住所有对话内容，而是：系统知道哪些信息必须被记住、由谁负责、以什么形式参与后续决策。这是一道状态责任划分问题，不是模型能力问题。
二、对话本质是“状态不断收敛的过程”
从工程视角看，一段有效的 Agent 对话，应该呈现这样的趋势：
一开始：状态高度不确定
中期：关键变量逐步确认
后期：决策空间持续收敛
例如：
用户需求：❓ ↓ 目标确认 ✅ ↓ 约束补齐 ✅ ↓ 执行路径锁定 ✅对话状态管理的目的只有一个：让“已确认的事实，不再回到不确定状态”。接下来，我们用这个视角，重新审视三种主流方案。
三、方案一：纯 LLM 记忆 ——“一切交给上下文”
这是最自然、也是最危险的一种方案。它的真实工程假设是：“只要上下文足够完整，模型就会自己处理好状态。”
在 Demo 阶段，它看起来很美好
不用设计状态结构
不用定义 schema
对话自由、自然
改动成本低
但在系统复杂度上来后，它必然失控，核心问题不是“忘记”，而是状态不可审计
哪一句话算“确认”？
哪一句只是讨论？
哪个约束是当前有效的？
哪个已经被推翻？
这些问题：LLM不会替你做工程级判断。纯 LLM 记忆，本质上是“没有状态所有权”的系统。
四、方案二：外部状态机 ——“一切必须被显式建模”
这是很多工程师的反弹式选择：“既然模型不可靠，那我全用状态机”。这种方案的核心哲学是：只有被结构化的，才是可信的。你会看到：
明确定义的状态节点
清晰的状态转移条件
对话只是“触发器”
它在工程上的优势非常真实
状态可回放
行为可预测
错误可复现
非常适合强约束流程（客服、审批、工单）
但问题也同样致命，最大的问题是：人被迫替模型“想清楚一切”
用户表达永远在状态机之外
边缘意图很难覆盖
新需求 = 改状态图
对话一旦偏离预期，就显得“很蠢”
最终你会得到一个系统：工程上很稳，但是体验上很僵，扩展性极差。
五、对话中并非所有信息都值得“升格为状态”
这是第三种方案出现的前提。在真实对话中，信息天然分层：
层级一：事实型状态
已确认的目标
已接受的约束
已选择的方案
一旦确认，不应被模型“自由发挥”
层级二：探索型上下文（允许漂移）
用户的模糊想法
讨论中的备选方案
临时解释性对话
允许被覆盖、被修正、被遗忘。所以问题从来都不是“用不用状态机”，而是你有没有区分这两类信息。
六、方案三：混合方案 ——“状态有边界，理解有弹性”
这也是工程上唯一可长期演进的方案。它的基本原则是：状态收敛由系统负责，状态理解由模型负责。
一个典型的混合结构是：
LLM 对话 ↓ 状态抽取（结构化） ↓ 外部 State Store ↓ 后续决策强依赖状态关键不是“存什么”，而是“什么时候存”：当用户确认时写入状态，当系统做出决策时锁定状态，而普通闲聊不进入状态层
七、为什么混合方案在工程上反而“更简单”？
这是一个反直觉结论。很多人觉得混合方案复杂，是因为：
既要模型
又要状态
还要同步
但实际上，它降低了三个长期成本：
1️⃣ Prompt 成本
Prompt 不再承担“记忆职责”
Prompt 只负责理解“当前轮意图”
2️⃣ Bug 定位成本
状态错 → 状态系统
理解错 → 模型行为
边界清晰，可拆解
3️⃣ 系统演进成本
新状态 ≠ 改全部对话逻辑
状态 schema 可版本化
历史对话可重放
八、实用的工程判据：这条信息“允许被模型改写吗？”
在设计对话系统时，你可以反复问这个问题：如果下一轮模型把这条信息理解错了，我能接受吗？如果能接受就留在 LLM 上下文，如果不能接受必须外部状态化。这个问题，比任何“架构图”都管用。
对话状态不是“记忆问题”，而是“责任问题”
最后一句非常一致的工程结论：凡是不能交给模型“自由发挥后果”的信息，就不应该只存在于模型的上下文里。
纯 LLM 记忆 → 无责任主体
纯状态机 → 无理解弹性
混合方案 →责任清晰 + 能力可扩展
真正成熟的 Agent 对话系统，不是“记得多”，而是知道哪些东西，一旦确定，就再也不能被“聊丢”。
){kind=spacer}