Kunora Agent Memory 问题定义
摘要
智能体的记忆问题不是“模型忘性大”，而是缺少可治理的长期记忆系统。典型表现有三类：没有长期记忆、关键记忆召回不到、召回了太多无效或过期内容。
Kunora Agent Memory 的目标不是让智能体记住更多，而是让它在正确的时间，以正确的粒度，想起正确且仍然有效的内容。
背景与范围
智能体正在从一次性问答工具变成 长期协作的软件执行者。它需要跨会话、跨任务保留用户偏好、项目规则、业务约束、历史决策、任务状态和失败经验。
本文只定义现状问题，不定义最终架构。后续文档再展开产品目标、记忆类型、生命周期、召回管线、评价方法和 MVP 范围。
问题地图
| 问题 | 用户感知 | 直接原因 | 根本原因 |
|---|---|---|---|
| 无长期记忆 | “我已经说过很多次了” | 会话结束后上下文消失 | 缺少记忆写入、归属、有效期和更新机制 |
| 召回不足 | “之前讨论过，为什么没想起来” | 记忆没有写入、索引或命中 | 缺少任务、实体、项目、时间之间的结构化关系 |
| 召回不准 | “想起一堆没用的，还被旧信息带偏” | 召回结果过多、过旧或冲突 | 缺少有效性判断、冲突处理、排序和 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 应该成为智能体的记忆基础设施，而不是聊天记录库。
它至少需要覆盖九类能力：记忆写入、记忆建模、记忆归属、记忆更新、记忆召回、记忆压缩、记忆失效、记忆审计和技能协同。
技能协同来自一个更深的问题：智能体不只是会忘记事实，也会忘记“这类任务应该怎么做”。当某类经验和教训反复出现时，它不应永远停留在零散记忆中，而应沉淀为可复用技能；当新任务开始时，相关记忆也应能触发合适的技能。
开放问题
- 第一版优先服务代码智能体、办公智能体，还是通用任务智能体？
- 记忆应当以用户、项目，还是工作空间为中心？
- 哪些记忆自动写入，哪些必须经过用户确认？
- 召回结果应该以原文证据、压缩事实、操作约束，还 是混合包进入上下文？
- 记忆冲突时，系统应该自动决策、提示用户，还是保留多个候选版本？
- 如何评价召回准确性：任务成功率、人工标注、token 节省，还是污染率下降？
结论
智能体记忆问题的根因不是缺少某条信息，而是缺少对记忆的长期治理。没有生命周期，记忆会丢失；没有结构化关系，记忆召回不到；没有有效性和预算控制，记忆会变成噪声。
Kunora Agent Memory 要让记忆从聊天副产物变成可治理、可召回、可验证、可失效的系统能力。