功能建议：为 Kimi Code 内建分层记忆体系（Layered Memory System）

标题

功能建议：为 Kimi Code 内建分层记忆体系（Layered Memory System）

正文

背景

我想给 Kimi Code 提一个关于“记忆体系”的产品建议。

对于长期使用的 Coding Agent 来说，单纯依赖当前会话上下文是不够的。真正高频、稳定、可持续的使用场景里，Agent 需要一种分层记忆结构，而不是把所有信息都混在聊天记录里。

我在实际使用中发现，一个更有效的方案是把记忆拆成不同层级，分别管理：

1. 工作记忆 / 当前会话上下文
   当前任务临时需要的信息

2. 每日日志 / 原始记录
   按日期记录当天发生了什么、做了什么、遇到了什么问题

3. 长期记忆 / 提炼记忆
   从原始日志中筛选出的高价值、可复用、稳定的信息

4. 用户画像 / 偏好记忆
   用户的长期偏好、工作方式、命名习惯、环境事实等稳定信息

这种分层方式，能显著提升 Agent 在多轮、多天、长期协作场景下的连续性与可靠性。

---

为什么需要这个功能

实际使用中，Agent 经常需要记住这些内容：

• 用户偏好
• 本地环境信息
• 工具路径和使用规则
• 过去踩过的坑和经验教训
• 历史任务中的关键决策
• 项目约定和工作流
• 可复用的 SOP（标准操作流程）

如果这些内容都只存在于聊天上下文中，会有几个明显问题：

• 上下文越来越长，token 成本越来越高
• 重要信息被淹没在大量对话里
• 会话一断，很多信息就丢了
• Agent 容易重复犯同样的错误
• 长期使用时，记忆质量会越来越差

所以，问题不是“要不要记忆”，而是记忆应该怎么分层、怎么存、怎么取、怎么提炼。

---

建议的记忆模型

我建议 Kimi Code 可以考虑支持一种内建的分层记忆模型，例如：

1）工作记忆（Working Memory）

用于当前会话、当前任务：

• 当前目标
• 当前计划
• 临时发现
• 中间结论

特点：

• 短期有效
• 可频繁读写
• 任务结束后不一定长期保留

2）每日日志（Daily Log）

用于记录原始过程：

• 今天做了什么
• 跑了什么命令
• 出了什么问题
• 如何解决的
• 做了哪些决策
• 有哪些观察

特点：

• 按天归档
• 偏原始、偏完整
• 适合作为“原材料”

3）长期记忆（Long-term Memory）

用于沉淀高价值信息：

• 已验证有效的经验
• 稳定的工具规则
• 可复用工作流
• 项目关键决策
• 长期有效的环境事实

特点：

• 高信号、低噪音
• 可被频繁检索
• 不追求完整原始，只保留精华

4）用户画像 / 偏好（Profile Memory）

单独保存稳定偏好，而不是混进普通日志里：

• 用户喜欢的格式
• 用户不喜欢的行为
• 命名风格
• 表达偏好
• 工作习惯
• 长期有效的个人配置偏好

特点：

• 变化慢
• 稳定性高
• 对个性化协作价值很大

---

理想中的产品行为

如果 Kimi Code 未来支持这类体系，我觉得至少应该有以下能力：

A. 明确的记忆写入路径

Agent 应该知道不同信息应该写到哪里：

• 临时任务信息 → 工作记忆
• 当天发生的过程 → 每日日志
• 稳定经验和规则 → 长期记忆
• 用户偏好 → 用户画像

而不是所有内容都落到一个地方。

B. 回答前先检索记忆

当用户问到以下内容时，Agent 应该优先查记忆，而不是只靠当前上下文：

• 之前做过什么
• 为什么这样设计
• 上次怎么解决的
• 用户偏好是什么
• 某个项目的历史决策是什么

C. 支持“提炼”流程

系统应该支持把原始日志逐步提炼为长期记忆，可以是：

• 手动提炼
• 半自动提炼
• 定期自动总结提炼

重点是把“原始记录”和“长期知识”分开。

D. 支持作用域和敏感性边界

不同记忆的边界应该能区分，例如：

• 当前项目专属
• 全局通用
• 用户私有
• 可同步
• 不可同步
• 可公开
• 仅本地保存

这是长期可用的关键。

E. 记忆成为一等产品能力

不要只是“上下文变长一点”，而应该把记忆当作一等能力来设计，包括：

• 结构
• 生命周期
• 检索方式
• 提升 / 降级机制
• 保留策略
• 作用域边界

---

可考虑的功能形式

比如可以考虑这些能力：

• 内建记忆命名空间，例如：

  • session
  • daily_log
  • long_term
  • profile

• 提供类似命令：

  • /remember
  • /recall
  • /daily-note
  • /promote-memory
  • /profile

• 支持自动路由规则，例如：

  • “记住这个偏好” → profile
  • “今天修复了一个 bug” → daily_log
  • “这是以后都要遵守的规则” → long_term

• 支持对记忆做语义检索

• 支持从 daily log 向 long-term memory 提炼

• 支持项目级记忆与全局记忆分离

• 支持纯文本、可见、可编辑的存储形式

---

为什么建议优先支持可见的文本记忆

如果这个功能要落地，我很建议优先考虑用户可见、可编辑的纯文本记忆文件，而不是完全隐藏的黑盒状态。

这样做的好处是：

• 透明
• 可调试
• 可人工修正
• 易于 Git 管理
• 易于备份
• 易于迁移
• 更适合本地工作流

对高级用户来说，“看得见、改得了、能追踪”的记忆，通常比黑盒记忆更值得信任。

---

预期收益

如果 Kimi Code 能内建这类分层记忆体系，我认为会显著提升：

• 多会话连续性
• 长期协作稳定性
• 个性化能力
• token 使用效率
• 复杂项目中的可靠性
• Agent 的“越用越懂你”能力

---

结语

Kimi Code 现在在执行能力上已经很强了。
如果未来能把“结构化记忆”也做好，它在长期协作体验上会更进一步。

我真正想表达的核心是：

不应该只有“更长上下文”，还应该有“更好的记忆结构”。

比起一个混在一起的大记忆池，我认为更有效的模型是：

• 原始日志
• 提炼记忆
• 用户画像
• 当前工作记忆

希望这个方向能对 Kimi Code 的产品设计有参考价值。

感谢。

The proposal does not identify any files, tests, or entry points. Start by mapping how Kimi Code currently handles session context and persistence, then define a bounded memory scope, storage model, retrieval behavior, and acceptance criteria before implementation.