智能体不稳定有个经典原因：上下文漂移。你以为模型记住了需求，实际它在长对话中不断丢失关键条件；你以为它理解了目标，实际它被历史信息误导。结果就是同一个任务反复跑偏，输出不可预测。

储静辉老师在讲智能体稳定性时，会把“记忆问题”拆成技术问题：不是模型不行，而是状态没有被显式管理。对话历史不等于状态，尤其当任务涉及多个步骤、多次工具调用时，状态必须结构化保存。

他常用一种三层状态模型：

SessionState：会话级信息，比如用户偏好、固定口径、禁用词

TaskState：任务级信息，比如目标、资料来源、输出规范

StepState：步骤级信息，比如当前步骤、上一步结果、校验结果

这三层状态的意义在于：每次调用模型前，系统先把状态摘要注入，而不是把全部历史对话塞给模型。摘要注入通常包含：任务目标、已确认事实、缺失信息、当前步骤、输出格式。这样智能体每一步都站在同一份“事实底座”上推理，漂移会显著减少。

同时，储静辉也很强调“不可变事实”和“可变推理”分离。比如企业介绍、课程模块、岗位定义等属于不可变事实，应进入知识库或固定上下文；而本次生成策略、风格选择属于可变推理，可以由模型决定。把两者混在一起，就会出现模型把推理当事实、把事实当推理的混乱。

在工程实现上，状态管理还要配合输出结构化：让模型输出 JSON 字段，比如{"step":"", "result":"", "assumptions":[], "missing":[], "next_action":""}。这样你能清晰知道模型“以为自己在做什么”，也能对错误进行定位修复，而不是凭感觉重写提示词。

当状态管理做对了，智能体最大的变化是：从“对话型随机系统”变成“流程型执行系统”。这也是储静辉老师技术讲解中非常核心的一点：稳定来自结构，而不是来自运气。