System、User、Project 与 Session Memory

建议用时：25 分钟（含练习）

学习目标

能够判断一条信息应属于系统、用户、项目还是当前 Session，并控制加载范围。

本节产出

一张 Memory 分层与保留策略表

核心知识：信息应该在合适的范围内保留

AI 应用中的 Memory 可能指文件、数据库记录、自动摘要或检索结果，并不一定意味着模型参数发生了改变。保存一条信息，也不代表它会在每次任务中完整加载。理解记忆机制，要分别问：保存在哪里、什么时候读取、谁能修改、何时失效。

本课程用 System、User、Project、Session 四种范围帮助整理信息。这是分析框架，不是所有产品共享的官方四层标准。System 指应用设定的基础规则，User 指用户跨任务偏好，Project 指特定项目的稳定事实，Session 指当前任务的临时状态。实际产品的名称、优先级和可编辑性要看自己的文档。

图中的分类不是按“重要程度”排序。

临时故障信息

一条非常重要的临时故障信息，仍然可能只属于当前任务。

构建命令

一个普通的构建命令，因为长期适用于项目，反而适合放入项目规则。

保存位置应由适用范围与生命周期决定。

稳定事实与临时状态分开

“不进入普通记忆”不意味着可以随意丢在聊天里。秘密应由合适的工具或受控存储管理，任务记录只说明需要哪种能力，不复制真实值。含个人信息的材料也应遵循任务所需范围，不能因为未来可能有用就全部保存。

案例：一条过期规则怎样影响多个任务

假设项目记忆写着“测试命令是 old-test”，但项目已改成 new-test。Agent 每次开始工作都会读到旧说明，于是反复尝试不存在的命令。如果它把失败解释为临时环境问题，又将“测试暂不可用”写回记忆，错误就会不断累积。

修复方法是回到实际配置核对事实，更新项目说明并保留变更依据。当前任务的失败记录仍可保存，但要说明原因已解决。长期记忆不应只是聊天结论的堆积，而应是可维护的事实集合。

为记忆设计进入和退出条件

新增前先问三件事：以后哪些任务会用到？这条信息有可靠依据吗？它是否应该跨越当前项目或用户边界？只有明确有复用价值、范围合适且可核实的信息，才值得进入持久记录。

每条容易变化的信息可以带来源、核验日期和责任人。读取时若发现配置与记忆冲突，应重新核对，而不是默认“记忆里写过就一定正确”。删除也要有机制：任务结束、偏好取消、版本更替或隐私要求变化，都可能使旧记录失去保留理由。

记忆压缩时要保留不确定性。原文“可能因为网络导致失败”不能被摘要成“网络故障已确认”。一次推测如果在多轮摘要中变成事实，会让后续决策建立在错误基础上。可以用“已验证”“推测”“待确认”区分证据状态。

动手练习

1. 将十条自己虚构的信息分到四种范围，并至少列出两条不应保存的内容。
2. 为项目测试命令设计来源、核验日期与更新触发条件。
3. 把一段含推测的任务记录压缩成五行，检查是否改变了证据状态。

参考答案与推演

展开

完成检查

• 知道保存、加载与模型学习是不同机制。
• 四类范围被当作分析方法，没有冒充通用产品标准。
• 记忆有来源、更新和退出条件。
• 不确定性、隐私边界与临时状态没有在压缩中丢失。

参考与来源

• Claude Code：Memory：作为项目指令与持久信息组织的具体产品实例。
• Anthropic：Effective context engineering for AI agents：理解选择性上下文、摘要与长期任务支持。