Kunora Agent Memory 问题定义

摘要

智能体的记忆问题不是“模型忘性大”，而是缺少可治理的长期记忆系统。典型表现有三类：没有长期记忆、关键记忆召回不到、召回了太多无效或过期内容。

Kunora Agent Memory 的目标不是让智能体记住更多，而是让它在正确的时间，以正确的粒度，想起正确且仍然有效的内容。

背景与范围

智能体正在从一次性问答工具变成长期协作的软件执行者。它需要跨会话、跨任务保留用户偏好、项目规则、业务约束、历史决策、任务状态和失败经验。

本文只定义现状问题，不定义最终架构。后续文档再展开产品目标、记忆类型、生命周期、召回管线、评价方法和 MVP 范围。

问题地图

flowchart LR
  A[无长期记忆] --> B[用户反复解释背景]
  B --> C[保存历史信息]
  C --> D[召回不足]
  D --> E[关键约束缺失]
  E --> F[扩大召回范围]
  F --> G[召回不准]
  G --> H[噪声和过期内容污染推理]

问题	用户感知	直接原因	根本原因
无长期记忆	“我已经说过很多次了”	会话结束后上下文消失	缺少记忆写入、归属、有效期和更新机制
召回不足	“之前讨论过，为什么没想起来”	记忆没有写入、索引或命中	缺少任务、实体、项目、时间之间的结构化关系
召回不准	“想起一堆没用的，还被旧信息带偏”	召回结果过多、过旧或冲突	缺少有效性判断、冲突处理、排序和 token 预算控制

问题一：无长期记忆

用户长期使用代码智能体维护同一项目，并明确约定：项目使用 TypeScript 和 Fastify；数据库访问必须走仓库层；不要自动引入大型框架；新功能要先补测试。

当前会话里，智能体能遵守这些规则。几天后用户重新打开会话，让它实现新接口，智能体又开始在 route 文件里直接写 SQL，甚至建议引入新的 ORM。

这个问题的直接原因是智能体主要依赖上下文窗口。上下文窗口能支持短期对话，但不是长期记忆系统。会话结束后，项目规则、用户偏好、历史决策和任务状态没有变成可复用资产。

根本原因是系统没有“记忆对象”的产品模型。长期记忆必须回答：什么值得记住，属于谁，何时有效，冲突时谁覆盖谁，来源和置信度如何表示，执行任务时如何读取。

问题二：记忆召回不足

用户让智能体继续开发“客户导入”功能。三天前双方已经讨论过：CSV 导入必须支持断点续传，手机号是业务唯一键，重复客户不能覆盖原始来源字段，导入失败记录要生成可下载报告。

新会话中，用户只说：“继续做客户导入，把后端接口补完。”智能体找到了最近修改的文件，却没有召回这些业务约束。结果实现了一个基础接口：没有断点续传，还错误覆盖了客户来源字段。

召回不足通常发生在三个位置：

断点	结果
关键约束没有写入记忆	后续无从召回
记忆写入了，但没有按任务、实体、项目组织	检索难以命中
当前请求没有触发正确召回	记忆存在但没有进入上下文

根本原因是召回被当成文本搜索，而不是任务上下文重建。智能体执行前需要恢复“这件事以前发生过什么、当前到哪一步、哪些约束仍然有效、哪些历史决策会限制当前实现”。

问题三：召回准确性差

用户让智能体“优化登录接口的错误处理”。记忆系统召回了项目初始化讨论、登录页面 UI 风格、两个月前注册流程会议摘要、已废弃 OAuth 方案，以及当前登录接口异常处理约定。

真正关键的是最后一条。其他内容不仅消耗 token，还可能让模型误以为废弃 OAuth 方案仍值得考虑。

另一个常见污染来自过期记忆。用户曾在 Demo 阶段说“这个 Demo 可以先不考虑权限”。项目进入正式阶段后，权限校验已经是硬性要求，但召回系统仍把旧记忆送入上下文，导致智能体新增管理接口时跳过权限。

准确召回不是“多找一些相关文本”，而是在有限上下文预算内提供最少、最准、最可执行的记忆。召回至少要同时考虑：

$$ RecallScore = \alpha R + \beta T + \gamma S + \eta F - \delta N - \lambda A $$

符号	含义
R	语义相关性
T	与当前任务、实体、项目的关系强度
S	来源可信度
F	新鲜度或当前有效性
N	预计上下文噪声
A	过期、冲突或误导风险

这个公式不是最终算法，而是产品约束：召回系统不能只看相似度，还必须评估作用域、状态、证据、时效、冲突和 token 成本。

为什么简单方案不够

方案	价值	局限
扩大上下文窗口	延长短期连续性	不能判断什么值得保留、何时失效
保存完整聊天记录	保留原始证据	噪声大，难以直接执行
会话摘要	降低 token 成本	容易丢失约束、证据和适用范围
向量检索	找到语义相近内容	无法保证任务相关、仍然有效、无冲突
手工记忆	准确可控	成本高，难以规模化

这些方案可以作为组件，但不能单独构成智能体长期记忆产品。

产品机会

Kunora Agent Memory 应该成为智能体的记忆基础设施，而不是聊天记录库。

flowchart LR
  Capture[捕获候选记忆] --> Classify[分类与作用域识别]
  Classify --> Validate[验证来源与置信度]
  Validate --> Store[结构化存储与索引]
  Store --> Recall[任务感知召回]
  Recall --> Filter[有效性与冲突过滤]
  Filter --> Pack[上下文预算打包]
  Pack --> Use[智能体执行]
  Use --> Feedback[结果反馈与记忆更新]
  Feedback --> Store

它至少需要覆盖九类能力：记忆写入、记忆建模、记忆归属、记忆更新、记忆召回、记忆压缩、记忆失效、记忆审计和技能协同。

技能协同来自一个更深的问题：智能体不只是会忘记事实，也会忘记“这类任务应该怎么做”。当某类经验和教训反复出现时，它不应永远停留在零散记忆中，而应沉淀为可复用技能；当新任务开始时，相关记忆也应能触发合适的技能。

开放问题

• 第一版优先服务代码智能体、办公智能体，还是通用任务智能体？
• 记忆应当以用户、项目，还是工作空间为中心？
• 哪些记忆自动写入，哪些必须经过用户确认？
• 召回结果应该以原文证据、压缩事实、操作约束，还是混合包进入上下文？
• 记忆冲突时，系统应该自动决策、提示用户，还是保留多个候选版本？
• 如何评价召回准确性：任务成功率、人工标注、token 节省，还是污染率下降？

结论

智能体记忆问题的根因不是缺少某条信息，而是缺少对记忆的长期治理。没有生命周期，记忆会丢失；没有结构化关系，记忆召回不到；没有有效性和预算控制，记忆会变成噪声。

Kunora Agent Memory 要让记忆从聊天副产物变成可治理、可召回、可验证、可失效的系统能力。