智能体记忆存储设计十大原则
【摘要】 总结了智能体记忆设计的十大原则
| 序号 | 设计原则 | 维度 | 核心定义 | 具体应用与实践 |
|---|---|---|---|---|
| 1 | 单一真相源原则 | 可推导性 / 冗余控制 | 只存储无法从代码、Git 历史、CLAUDE.md 或其他权威来源推导出的信息，且同一事实仅保留一个权威版本。 |
• 禁止存储文件路径、代码模式、Git 变更等可推导信息。 • 若多个记忆描述同一事实，保留最新且最权威的，删除其余。 • 权威来源层级：用户显式指令 > 当前代码/配置 > 团队记忆 > 个人记忆。 • 存储前判断“可推导性等级”：L0（完全可推导）→禁止；L1（需大量推理）→允许并附原因；L2（不可推导）→优先存储。 |
| 2 | 长期价值与临时区隔原则 | 时效性 / 生命周期 | 区分跨对话有用的长期记忆与仅当前对话有效的临时状态，并为临时状态设置明确的失效机制。 | • 长期记忆：存储用户角色、偏好、知识背景、跨对话有效的反馈指导。 • 临时记忆区（如 /tmp_memory/）：存储进行中的工作、临时状态，标记有效期（如 24 小时或对话结束即删）。• 避免将当前对话上下文、一次性状态写入长期记忆。 |
| 3 | 时效性与老化原则 | 时效性 / 验证 | 记忆是时间点的观察，必须带有时间戳和预期有效期，使用前验证其新鲜度，并自动老化过时记忆。 | • 每条记忆记录 created_at、updated_at、expires_at 或 max_age_days。• 优先级：当前状态 > 未过期的记忆 > 已过期的记忆。 • 定期执行老化检查： expires_at 已过 → 标记为“已失效”并移入归档区。• 用户可手动刷新或延长记忆的有效期。 |
| 4 | 动机驱动与结构化原则 | 可解释性 / 结构化 | 存储决策时不仅记录“做了什么”，还必须记录“为什么这样做”，并使用结构化格式便于检索和推理。 | • 每个决策类记忆强制包含结构化动机字段：goal（目标）、constraint（约束）、alternative_rejected（被否决的替代方案）。• 提供常见动机标签：性能、安全、兼容性、可维护性、合规性等。 • 避免冗长的自然语言描述，保持动机部分简洁（≤ 200 字符或使用外部引用）。 |
| 5 | 冲突解决与优先级原则 | 冲突解决 | 当记忆之间或记忆与当前状态发生冲突时，按照明确的优先级顺序进行仲裁，并记录仲裁过程。 | • 优先级顺序：用户显式指令 > 项目/团队约定 > 当前状态 > 个人偏好 > 历史记忆。 • 冲突时生成仲裁记录：依据哪条优先级、理由、最终采用的值，存入记忆元数据。 • 支持用户通过指令 /memory override team 临时提升个人偏好优先级。• 禁止反复出现同一冲突（仲裁记录可缓存）。 |
| 6 | 压缩与合并原则 | 存储效率 | 定期合并相似记忆，删除矛盾事实，保持索引简洁（可配置阈值），必要时自动摘要溢出内容。 | • 相似度阈值（如 TF‑IDF 余弦相似度 > 0.8）触发合并提示或自动合并。 • 索引大小可配置：小型项目 ≤ 200 行 / 25KB，大型项目 ≤ 500 行 / 50KB，超出后自动摘要或归档。 • 矛盾检测规则：同一主题下 A 断言“X 为真”，B 断言“X 为假”→ 触发解决流程（见原则 5）。 • 合并后保留变更历史，避免信息丢失。 |
| 7 | 验证优先与懒验证原则 | 正确性 / 性能 | 使用记忆前必须验证其准确性，但通过懒验证和缓存机制平衡性能开销。 | • 首次使用某记忆时验证（如检查文件是否存在、函数是否定义），结果缓存（有效期 5 分钟）。 • 高频使用的记忆在对话开始时预热验证。 • 验证结果标记： verified_at、verification_status（valid / stale / conflict）。• 验证失败处理：若文件/函数不存在 → 标记“已失效”并建议删除；若与当前状态矛盾 → 保留但降低置信度，并提示用户确认。 |
| 8 | 作用域与共享原则 | 隐私 / 协作 | 每种记忆类型有明确的作用域（私有/团队），支持细粒度的共享控制，并允许作用域继承与覆盖。 | • user：强制私有，不可共享。 • feedback：默认私有，支持 /memory share feedback 转为团队（需用户确认）。• project：默认团队，支持 /memory local project 转为私有副本。• reference：细分为 ref.public（团队共享）和 ref.private（个人书签）。• 项目级记忆可被子目录或子模块继承，子模块可覆盖父级作用域规则。 |
| 9 | 结构化存储与版本控制原则 | 可维护性 | 记忆文件采用标准 frontmatter 格式，包含版本、依赖、来源等元数据，支持变更追溯。 | • frontmatter 必含字段：name、description（≤ 200 字符，格式：“用于[场景]，关键条件是[条件]，结果为[结果]”）、type（user/feedback/project/reference）、version、updated_at。• 可选字段： depends_on（依赖的其他记忆 ID）、provenance（来源对话/用户）、confidence（置信度 0~1）。• 内容结构： # 规则 / # 为什么 / # 如何应用（“如何应用”优先使用指针引用现有文档，避免重复）。• 每次变更通过 git 记录 diff，支持回滚。 |
| 10 | 生命周期管理原则 | 全生命周期 | 覆盖记忆的创建、验证、更新、归档、删除全流程，确保记忆系统自洽且不过度膨胀。 | • 创建：自动检测是否违反原则 1（可推导性），违反则拒绝存储。 • 更新：保留变更历史（版本号 +1），旧版本移入历史区。 • 归档：连续 3 次验证失败 或 expires_at 到期后 7 天未使用 → 移入归档区（不删除，可恢复）。• 删除：用户手动删除，或系统根据 LRU（最近最少使用）自动淘汰（需用户确认）。 • 提供 /memory stats 命令查看记忆总数、失效数、归档数等指标。 |
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）