Agent 的记忆：
上下文不是记忆，聊天记录也不是状态

Agent 一旦运行超过几轮，就会遇到三个不同的问题：

• 这次任务做到哪一步了？
• 哪些信息需要在这轮里反复使用？
• 哪些事实跨任务都不应该忘？

它们分别对应任务状态、工作记忆和长期事实。混在一个 messages 数组里，系统很快会失去边界。

任务状态：让流程可恢复

任务状态不是自然语言总结，而是结构化字段。它应该能回答：当前步骤、已完成动作、待确认项、失败次数、下一步允许做什么。

{
  "task_id": "photo-to-practice-001",
  "stage": "review_questions",
  "completed": ["ocr", "generate_questions"],
  "pending": ["parent_confirmation"],
  "warnings": ["第3题答案需人工确认"],
  "retry_count": 1
}

有了这个对象，进程重启、人工接管或换一个模型，都能从同一处继续。聊天记录可以丢，任务状态不能丢。

工作记忆：只放这次任务需要的东西

工作记忆是“临时桌面”。它应该包含当前任务的关键中间结果，而不是全部历史。图片识别结果、抽取的题目、用户刚补充的约束，放这里；三天前的闲聊，不放。

长期事实：少量、稳定、可追溯

长期记忆适合存稳定偏好和约束，例如：孩子年级、家长不希望出现的题型、家庭使用的时间段。它不适合存一次性的推理过程。

• 写入前先判断是否稳定，不要把所有对话都存成“记忆”；
• 每条事实带来源和时间，方便纠正；
• 区分“用户明确说的”和“模型推断的”；
• 允许用户查看、修改和删除。

检索：不要把所有记忆都塞进 Prompt

长期记忆变多后，正确做法是先检索再注入。检索可以基于关键词、向量或结构化过滤，但最终进入上下文的应该是少量、相关、带出处的片段。

memories = search_memory({
  user_id,
  query: current_task,
  kinds: ["preference", "constraint"],
  limit: 5
})

不要把“记忆”当成一个无限增长的向量库。没有淘汰、纠错和来源，它只会把旧错误反复带回来。

三个常见反模式

• 把摘要当状态：摘要会丢字段，流程无法可靠恢复；
• 把聊天记录当长期记忆：成本高、噪声大、无法纠正；
• 自动写入所有推断：模型猜错一次，错误会被永久放大。

更稳的做法是：状态由代码维护，工作记忆由任务作用域管理，长期事实由明确的写入策略控制。模型可以提出“记住这个”，但最终落库要经过校验。