Memory 与工作流：模型如何承接长期任务？

上一篇讲工具调用与 Agent 时，核心问题是：

模型如何从会说话，变成能做事。

但能做事以后，很快会碰到另一个更现实的问题：

任务不是一次动作，而是一段过程。

查询天气是一次动作。

写一篇文章是一段过程。

处理客户问题是一段过程。

训练一个模型是一段过程。

把一个网站持续运营起来，也是一段过程。

过程里会有目标、材料、限制、判断、修改、确认、失败、回滚和下一步。

如果模型只能看见当前一句话，它就像一个每次进房间都会失忆的助手。

它也许很聪明，但很难可靠。

真正可用的 Agent，不只是会调用工具，还要能承接状态。

所谓 Memory 与工作流，解决的正是这个问题：

让模型知道任务进行到了哪里，
哪些信息已经确认，
哪些事情还没做完，
中断以后如何恢复现场。

这一篇不把 Memory 讲成一种神秘能力。

更准确地说：

AI 系统里的 Memory，主要不是“像人一样记住”，而是把任务现场管理好。

Memory 负责保存和取回信息。

工作流负责规定事情怎样推进。

两者合在一起，Agent 才能从“一次性回答”，走向“长期协作”。

---

1. 为什么光靠上下文不够

最简单的办法，是把历史对话全部塞进上下文。

看起来很直接：

既然模型需要记住，那就把以前说过的话都发给它。

但这个办法很快会失效。

第一，上下文窗口不是无限的。

即使窗口很大，也不能无限增长。

第二，历史里并不是每一句都重要。

大量寒暄、试探、错误路线、临时讨论，会稀释真正关键的信息。

第三，任务经常跨越很长时间。

今天确定的目标，明天可能继续；上周中断的项目，下个月可能恢复。

第四，不同信息有不同寿命。

有些信息只在当前会话有用。

有些信息可以长期保留。

有些信息已经过期，继续使用反而会出错。

所以，Memory 不是简单地“越多越好”。

它更像一套整理系统：

该保留的保留，
该压缩的压缩，
该丢弃的丢弃，
该验证的重新验证。

如果没有这层整理，所谓记忆只会变成噪音。

---

2. Memory 不是一种东西，而是一组东西

在真实系统里，Memory 通常不是一个单独文件，也不是一段聊天记录。

它更像几类信息的组合。

类型	记什么	典型用途
短期上下文	当前对话、当前页面、刚刚发生的操作	保持眼前任务连贯
长期事实	稳定偏好、项目规则、账号边界、常用术语	避免重复解释基础背景
任务状态	目标、阶段、待办、阻塞点、完成条件	承接长期任务
事件日志	发生过什么、谁触发、结果怎样	复盘、审计、回滚
工作流模板	某类任务应该按什么步骤推进	让系统按稳定路径行动

这几类东西经常被混在一起说成“记忆”。

但工程上最好分开看。

因为它们的更新频率不同，风险也不同。

短期上下文可以很快过期。

长期事实必须谨慎写入。

任务状态要能被恢复。

事件日志最好不可随意篡改。

工作流模板更像系统规则，不应该被模型随口改掉。

一个成熟的 Agent 系统，往往不是“记得很多”，而是“知道什么该放在哪里”。

---

3. 可以把 Memory 想成任务现场

写文章时，桌面上可能有：

• 已经确定的标题
• 正在改的段落
• 参考资料
• 临时草稿
• 被删除但可能有价值的想法
• 下一步要补的图
• 已经确认不能写的方向

这些东西合在一起，就是一个写作现场。

如果第二天继续写，不需要重新从零开始。

只要打开现场，就能知道：

上次写到哪里，
为什么这样写，
还有什么没做，
哪些内容已经不要再回头。

Agent 的 Memory 也类似。

它不是一本完整日记。

它更像一个可以恢复的工作台。

flowchart TB
  A["用户提出任务"] --> B["系统建立任务现场"]
  B --> C["记录目标与约束"]
  C --> D["拆成可执行步骤"]
  D --> E["执行一步并写入结果"]
  E --> F{"任务是否完成"}
  F -->|未完成| G["保存当前状态与下一步"]
  G --> D
  F -->|完成| H["生成结果并归档关键经验"]

这张图的重点不是“记住所有话”。

而是每一步都留下可恢复的状态。

这样任务中断以后，系统不会只说：

请重新描述你的需求。

而是可以继续从上次停下的位置接住。

---

4. 工作流是 Memory 的骨架

只有 Memory，没有工作流，系统会知道很多，但不知道该往哪里走。

只有工作流，没有 Memory，系统知道步骤，但每一步都像第一次执行。

这两者必须配合。

比如“发布一篇技术文章”可以被拆成一个工作流：

flowchart LR
  A["确定主题"] --> B["梳理读者问题"]
  B --> C["写正文"]
  C --> D["补图和表格"]
  D --> E["检查移动端阅读"]
  E --> F["构建验证"]
  F --> G["发布"]
  G --> H["观察阅读反馈"]

Memory 在这里负责记录：

• 这篇文章的主题是什么
• 已经写到了哪一段
• 哪些图已经验证过
• 哪些问题读者可能看不懂
• 构建是否通过
• 发布以后有没有反馈

工作流负责告诉系统：

• 当前阶段是什么
• 下一步应该做什么
• 什么情况下需要停下来确认
• 什么情况下可以进入下一个阶段

所以，工作流不是让系统变笨。

恰恰相反，它让模型的聪明有地方落地。

---

5. 长期任务的本质是状态机

很多长期任务，看起来像聊天，实际上更像状态机。

比如一个问题从出现到解决，可能经历这些状态：

stateDiagram-v2
  [*] --> Created: 创建任务
  Created --> Clarifying: 信息不足
  Clarifying --> Planning: 目标明确
  Planning --> Executing: 开始执行
  Executing --> WaitingReview: 等待确认
  WaitingReview --> Executing: 需要修改
  WaitingReview --> Done: 确认通过
  Executing --> Blocked: 遇到阻塞
  Blocked --> Planning: 重新规划
  Done --> [*]

这张图比“模型多轮聊天”更接近真实协作。

因为关键不是聊天轮数。

关键是：

任务状态有没有被准确保存，
状态变化有没有依据，
下一步是不是清楚。

没有状态机，模型容易在对话里原地打转。

有了状态机，系统至少知道自己在哪个阶段。

这会直接影响可靠性。

---

6. 记忆写入比记忆读取更危险

很多讨论会重点讲“怎么把记忆取出来”。

但更容易出问题的是写入。

因为一旦错误信息被写进长期 Memory，后面会反复污染判断。

比如用户临时说：

这次先用旧方案吧。

这不代表以后永远都要用旧方案。

如果系统把它写成长期偏好：

用户偏好旧方案。

后续就会出错。

再比如一次调试中临时绕过某个安全检查。

这可能只是实验。

如果被写进规则：

该项目可以跳过安全检查。

风险就会被放大。

所以 Memory 写入至少要问三个问题：

问题	作用
这是真事实，还是临时上下文？	避免把临时决定写成长期规则
这需要保留多久？	避免过期信息长期生效
这有没有来源和证据？	出错时可以追溯

成熟的系统不会把模型每次总结都当成事实。

它会区分：

• 事实
• 偏好
• 决策
• 待办
• 猜测
• 临时约束
• 已过期信息

分类越清楚，Memory 越可靠。

---

7. 一个好用的 Memory 单元长什么样

一条可用的 Memory，不应该只是一句自然语言。

它最好带有结构。

比如：

type: decision
scope: project
topic: article_series
content: AI 系列统一规划为 14 篇路线
reason: 避免旧文章里的后续章节路线出现多个版本
source: 用户确认
created_at: 2026-07-04
expires_at: null
confidence: high

这条 Memory 里有几个重要字段：

• type：这是事实、偏好、决策，还是待办
• scope：它属于某个项目、某个用户，还是某次会话
• topic：后续检索时更容易命中
• content：真正要保留的内容
• reason：为什么写入
• source：来自用户确认、系统日志，还是模型推断
• expires_at：是否会过期
• confidence：可信度如何

这看起来有点工程化。

但正是这些字段，让系统不会把一句闲聊误判成永久规则。

Memory 越接近“可审计记录”，越能支撑长期任务。

---

8. 取回 Memory 时，不能只靠相似度

向量检索很适合找“语义相近”的内容。

但 Memory 检索不能只看相似度。

因为最相似的不一定最该用。

比如系统要继续一个发布任务，可能需要优先取回：

• 当前项目的规则
• 上一次中断时的任务状态
• 最新的用户确认
• 尚未完成的待办
• 最近一次失败原因

这些内容不一定和当前一句话最相似。

但它们最有用。

所以 Memory 检索通常要混合多个信号：

信号	解决什么问题
语义相似度	当前问题和哪段记忆相关
时间新旧	最近的确认是否覆盖旧信息
任务范围	只取当前项目/当前用户/当前流程的记忆
重要程度	决策和约束优先于普通对话
权限边界	不该看的记忆不能被取出
有效期	过期信息不能继续指导行动

这也是为什么 Memory 系统不是简单的“向量数据库 + 聊天记录”。

它本质上是检索、排序、过滤和权限控制的组合。

---

9. 上下文压缩：不是缩短，而是保骨架

长任务一定会遇到上下文压缩。

压缩不是把所有话变短。

压缩是保留任务骨架。

比如一段很长的讨论，最后真正需要保留的可能只有：

目标：写第 12 篇 AI 系列文章。
读者：不一定懂工程落地，需要通俗但有深度。
风格：高级、柔和、像苹果系统里的长文阅读。
限制：文章尽量客观，不写成聊天记录。
状态：待写正文，写完后先本地预览，不提交。

这比保留全部聊天更有用。

因为它回答了继续工作时最关键的问题：

• 要做什么
• 为什么这样做
• 读者是谁
• 风格边界是什么
• 当前到哪一步
• 下一步是什么

好的压缩不是摘要文学。

好的压缩是交接单。

---

10. Memory 和 Prompt 的关系

Memory 不是直接替代 Prompt。

Prompt 更像当前任务说明。

Memory 更像背景资料和任务现场。

真正进入模型前，系统通常会做一次组装：

flowchart TB
  A["用户当前输入"] --> E["上下文组装器"]
  B["任务状态"] --> E
  C["相关 Memory"] --> E
  D["工作流规则"] --> E
  E --> F["模型输入"]
  F --> G["模型输出"]
  G --> H["工具调用或文本回复"]
  H --> I["写回日志与状态"]
  I --> B

这一步叫上下文工程也可以。

关键在于：

不是把所有记忆都喂给模型，
而是把当前最需要的部分组装进去。

模型看到的上下文越干净，越容易做出稳定判断。

上下文越杂，模型越容易被旧信息带偏。

---

11. 工作流让 Agent 知道什么时候停

长期任务里，最危险的不是模型不会继续。

有时候更危险的是模型不知道该停。

比如：

• 信息不足时继续编
• 高风险动作前不确认
• 工具失败后反复重试
• 用户已经拒绝后还继续推进
• 任务完成后还继续增加动作

所以工作流必须包含停止条件。

场景	应该怎么停
信息不足	停在澄清阶段
涉及支付、删除、发布	停在人类确认阶段
工具连续失败	停在错误处理阶段
任务目标变化	停在重新规划阶段
结果已达到验收标准	停在完成阶段

这就是工作流的价值。

它不是限制模型能力，而是给行动装上刹车。

能停下来，是可控 Agent 的重要能力。

---

12. 人工确认不是落后，而是高级安全设计

很多人期待 Agent 全自动。

但真实系统里，完全自动往往不是第一目标。

更好的目标是：

低风险自动，
中风险可撤回，
高风险必须确认。

比如：

动作	风险	推荐策略
读取资料	低	可以自动
生成草稿	低	可以自动
修改本地草稿	中	记录版本，可回滚
发送邮件	中高	发送前确认
发布文章	高	发布前确认
付款或删除数据	极高	强确认 + 审计

Memory 在这里负责保存确认状态。

工作流负责判断当前动作是否需要停下来。

如果没有这两层，Agent 很容易越权。

越权不一定来自恶意。

很多时候只是因为系统没有边界。

---

13. 长期任务最怕“记得像，但记错了”

Memory 带来的最大风险，是错误记忆。

错误记忆有几种常见形态：

错误类型	表现
幻觉写入	模型把推测写成事实
过期记忆	旧规则继续覆盖新规则
范围污染	A 项目的规则被用到 B 项目
过度泛化	一次临时选择被写成长期偏好
隐私泄露	不该跨会话/跨用户的信息被取出

这就是为什么 Memory 不能只追求“更懂用户”。

还要追求：

• 可追溯
• 可删除
• 可过期
• 可更正
• 可解释
• 可限制范围

一个系统如果不能忘记，也很危险。

长期记住并不总是好事。

该忘的时候能忘，才是健康的 Memory。

---

14. 工作流不是流程图，而是责任分配

流程图只画出步骤。

工作流还要定义责任。

比如同样是“发布文章”，至少有几类责任：

• 模型负责起草、解释、改写
• 工具负责构建、检查、截图
• 系统负责记录状态、限制权限
• 人负责审美判断、最终确认

如果责任不清楚，Agent 会把所有事情都变成“模型决定”。

这不是智能。

这是失控。

更稳的结构是：

flowchart LR
  A["模型：理解与生成"] --> B["工具：执行可验证动作"]
  B --> C["系统：记录状态与权限"]
  C --> D["人：确认关键判断"]
  D --> E["工作流：进入下一阶段"]
  E --> A

这张图里，模型很重要，但不是唯一中心。

真正的中心是任务。

所有角色都围绕任务推进。

---

15. Memory 可以怎样帮助小模型

Memory 对小模型尤其重要。

因为小模型本身参数量有限，不可能什么都内化。

但它可以通过外部 Memory 和工作流获得更强的任务能力。

小模型适合承担这些角色：

角色	为什么适合
信息整理	把对话整理成结构化状态
待办提取	从文本里提取下一步
分类路由	判断任务属于哪个流程
检查遗漏	对照工作流检查缺口
草稿生成	基于明确上下文写初稿
状态复述	把当前进度讲清楚

这也是小模型工程里很重要的一条路：

不要把所有能力都压进参数，
而是把模型放进正确的系统结构里。

参数负责语言和判断。

Memory 负责现场。

工作流负责秩序。

工具负责执行。

这样，小模型也可以做出相当可靠的事情。

---

16. 一个最小可用的长期任务系统

如果要做一个最小可用的长期任务 Agent，不需要一开始就很复杂。

可以先有五个部件：

部件	作用
任务卡片	保存目标、范围、完成标准
状态字段	保存当前阶段、下一步、阻塞点
事件日志	记录每次操作和结果
Memory 摘要	保存关键事实、决策、偏好
工作流规则	决定什么时候执行、什么时候确认、什么时候停止

流程可以很朴素：

flowchart TB
  A["创建任务卡片"] --> B["写入目标和完成标准"]
  B --> C["生成下一步"]
  C --> D["执行或请求确认"]
  D --> E["写入事件日志"]
  E --> F["更新任务状态"]
  F --> G{"是否完成"}
  G -->|否| C
  G -->|是| H["归档结果和关键记忆"]

这个系统不需要一开始就像科幻电影。

它只要能做到三件事，就已经很有价值：

• 不忘目标
• 不丢进度
• 不越过确认边界

长期任务的可靠性，往往就是从这三件事开始的。

---

17. 怎么判断 Memory 与工作流有没有做好

评估 Memory 不能只问：

它还记不记得某句话？

更应该问：

评估问题	为什么重要
中断后能不能恢复任务？	检查任务状态是否可靠
能不能说清楚为什么这样做？	检查记忆是否可追溯
新规则能不能覆盖旧规则？	检查过期和版本管理
不同项目的记忆会不会串？	检查范围隔离
高风险动作会不会停下来确认？	检查工作流边界
失败后能不能回到正确阶段？	检查恢复能力

这比单纯测试“记忆长度”更接近真实价值。

好的 Memory 系统，不是让模型显得亲切。

而是让任务更连续、更可控、更少返工。

---

18. 和前面几篇串起来看

到这里，前面几篇可以连成一条更完整的线：

flowchart LR
  A["训练"] --> B["微调"]
  B --> C["评估"]
  C --> D["RAG"]
  D --> E["推理部署"]
  E --> F["工具调用"]
  F --> G["Memory 与工作流"]
  G --> H["行业业务闭环"]

训练和微调解决模型能力。

评估解决能力是否真的变好。

RAG 解决外部知识如何进入系统。

推理部署解决能力如何稳定运行。

工具调用解决模型如何行动。

Memory 与工作流解决行动如何延续。

下一步，就会进入更真实的场景：

这些能力怎样进入行业业务，
怎样从一次模型能力，变成持续产生价值的闭环。

---

19. 最核心的一句话

Memory 的价值，不是让模型显得“很懂人”。

真正的价值是：

让任务可以被交接、被恢复、被验证、被继续推进。

工作流的价值，也不是画出漂亮流程图。

真正的价值是：

让每一步行动都有位置、有边界、有下一步。

所以，一个可靠的 Agent 系统，不应该只追求“会聊”。

也不应该只追求“会调工具”。

它还要能保存现场、理解阶段、处理暂停、等待确认，并在长期任务里稳定地往前走。

会回答，是模型的能力。

会承接，才是系统的能力。

---

下一篇预告

《行业模型与业务闭环：训练如何进入真实场景？》

有了训练、微调、评估、RAG、部署、工具调用、Memory 和工作流以后，AI 系统终于接近真实业务。

但真实业务不是“模型上线”就结束。

它还会继续面对：

• 领域数据如何进入系统
• 人工审核如何沉淀成反馈
• 模型错误如何被发现和修正
• 工作流如何反过来产生训练样本
• 灰度上线如何降低风险
• 业务指标如何决定下一轮优化

下一篇会讲小模型如何进入具体行业和真实场景。

核心观点是：模型不是单独创造价值，模型要进入业务闭环，价值才会持续发生。

---

后续章节路线

顺序	章节方向	要解决的问题
第 13 篇	行业模型与业务闭环：训练如何进入真实场景？	领域数据、流程反馈、人工审核、持续评估与灰度改进
第 14 篇	系列总结：从数据到 Agent 的小模型工程地图	把训练、微调、评估、RAG、部署和 Agent 串成完整路线

持续学习，持续记录，持续筛选

如果这篇对你有用，可以继续沿着主题读下去。

福星家和会长期记录 AI 技术、生活成长、真实好物与正向文化观察。产品体验、人物故事、教育内容、生活方式、文化作品和内容共创都欢迎邮件沟通，合作内容会清楚标注。

继续读本系列 合作与交流