Kunora Agent Memory 产品蓝图
摘要
Kunora Agent Memory 的产品蓝图可以概括为一句话：把智能体的历史上下文，变成可治理、可召回、可交付的记忆资产。
它不是给用户多一个聊天窗口，也不是给智能体多接一个向量库。它要提供一组产品特性，让 kgent、Codex、Claude、Gemini、OpenClaw、Hermas 这些智能体都能接入同一套记忆能力：该记住的留下，该想起的出现，该过期的退出，该解释的能追溯。
蓝图总览
flowchart LR
A[记忆捕获] --> B[记忆建模]
B --> C[记忆治理]
C --> D[任务感知召回]
D --> E[上下文交付]
E --> F[智能体执行]
F --> G[反馈与审计]
G --> C
H[技能协同] -.影响.-> D
H -.影响.-> E
H -.接收反馈.-> G
这条链路对应用户体验中的一句话：智能体先学会记住，再学会整理，再学会在任务开始前想起，最后学会解释为什么这样想起。
其中，“技能协同”是横切能力。记忆告诉智能体当前什么有效，技能告诉智能体这类任务该怎么做。更进一步，记忆可以触发技能，技能执行后的经验和教训也会沉淀为新的记忆，并可能抽象成技能版本。详细模型见 记忆与技能的关系。
特性一：记忆捕获
故事从一次普通对话开始。
用户对 Codex 说：“这个项目数据库访问必须走 repository 层，新功能先补测试。”这句话不应该只停留在当前对话里。Kunora 要能识别它不是闲聊，而是值得保留的项目规则。
记忆捕获负责从不同来源发现候选记忆：
| 来源 | 可捕获内容 | 例子 |
|---|---|---|
| 对话 | 用户偏好、规则、决策 | “不要引入大型框架” |
| 任务执行 | 状态、结果、失败经验 | “客户导入接口已完成基础校验” |
| 文件和代码 | 项目约定、目录结构、接口契约 | repository 层负责数据库访问 |
| 工具结果 | 调研结论、测试结果、外部证据 | Gemini 调研出的方案对比 |
这层产品体验要足够克制。Kunora 不能把每句话都存起来，而是要把“值得长期影响智能体行为”的信息变成候选记忆。
特性二：记忆建模
捕获只是开始。真正有用的记忆，必须有类型。
同一句话在不同语境下可能含义不同。“权限可以先不考虑”如果发生在 Demo 阶段，它是临时约束；如果发生在生产系统里，它可能是高风险决策。Kunora 需要把记忆拆成可理解的对象。
| 记忆类型 | 含义 | 智能体使用方式 |
|---|---|---|
| 事实 | 已确认的信息 | 作为背景上下文 |
| 偏好 | 用户或团队倾向 | 影响默认选择 |
| 规则 | 必须遵守的约束 | 约束执行行为 |
| 决策 | 已选方案及理由 | 避免重复争论 |
| 任务状态 | 当前进展和下一步 | 支持继续工作 |
| 经验 | 成功或失败教训 | 降低重复犯错 |
| 证据 | 来源、文件、工具结果 | 支持追溯和审计 |
这一步让记忆从“历史文本”变成“可操作对象”。智能体拿到规则时应当遵守，拿到偏好时应当参考，拿到证据时应当用于判断，而不是把所有内容当成同等权重的聊天记录。
特性三：记忆作用域
用户同时使用多个智能体，也同时参与多 个项目。记忆如果没有边界，就会从能力变成污染。
Kunora 要为每条记忆标记作用域：
flowchart TD
Memory[一条记忆] --> User[用户级]
Memory --> Workspace[工作空间级]
Memory --> Project[项目级]
Memory --> Task[任务级]
Memory --> Agent[智能体级]
Memory --> Tool[工具级]
例如“用户喜欢简洁回答”可以是用户级偏好；“这个项目必须先写测试”是项目 级规则；“本轮客户导入任务还差失败报告”是任务级状态。
作用域解决的是“谁该知道”的问题。Codex 做代码任务时应该拿到项目规则；Claude 写产品文案时应该拿到产品定位；Gemini 做调研时不一定需要拿到代码目录约定。
特性四：记忆生命周期
记忆不是永久真理。它会被确认、修正、替代、废弃，也可能自然过期。
stateDiagram-v2
[*] --> Candidate: 捕获
Candidate --> Active: 确认或置信度足够
Active --> Superseded: 被新记忆替代
Active --> Expired: 超过有效期
Active --> Revoked: 用户撤销
Superseded --> Archived
Expired --> Archived
Revoked --> Archived
生命周期是 Kunora 防止污染的关键。Demo 阶段的“可以不考虑权限”，在正式阶段必须退出当前召回结果。旧决策不是删除就好，而是要能解释“它曾经有效，但现在被什么取代了”。
特性五：任务感知召回
召回不是搜索历史文本，而是在任务开始前重建上下文。
当 kgent 编排一个任务，或者 Codex 准备改代码，它会向 Kunora 描述当前任务：我要做什么、在哪个项目、涉及哪些实体、预算多少 token。Kunora 返回的不是一堆聊天记录，而是当前任务需要的上下文包。
| 召回维度 | 作用 |
|---|---|
| 当前任务 | 判断哪些记忆真正相关 |
| 项目/工作空间 | 避免跨项目污染 |
| 实体 | 找到业务对象、接口、文件、用户等关联记忆 |
| 时间 | 过滤过期内容，提升新近决策权重 |
| 记忆状态 | 排除废弃、撤销 、冲突未解决的记忆 |
| token 预算 | 控制进入上下文的内容长度 |
任务感知召回的产品价值是：智能体不只是“想起相关内容”，而是“想起当前要做成这件事所需要的内容”。
特性六：上下文交付
召回结果不能直接丢给模型。原始记忆可能冗长、重复、证据分散，还可能有不同置信度。Kunora 要把召回结果打包成智能体能直接使用的上下文。
一个上下文包应当长这样：
Context Pack
- Active rules: 当前必须遵守的规则
- Relevant facts: 当前任务需要知道的事实
- Decisions: 仍然有效的历史决策
- Task state: 当前进度和下一步
- Warnings: 过期、冲突或高风险提示
- Evidence: 可追溯来源
这层决定 Kunora 是否真的节省 token。好的交付不是“召回 20 条记忆”，而是把 20 条候选记忆压缩成 5 条可执行约束，并保留证据链接。
特性七：技能协同
Kunora 的蓝图不能只考虑记忆本身。真实智能体执行任务时，往往同时需要两类输入：
- 记忆：当前任务里什么事实、偏好、规则、决策仍然有效。
- 技能：面对这类任务，应该采用什么工作流、模板和质量标准。
例如写设计文档时，design-doc-writer 是技能；“用户嫌文档太啰嗦”“本项目偏好 Mermaid 和表格”“当前处于产品设计阶段”是记忆。这些记忆会触发并调节技能。技能执行后，如果用户再次反馈“还是太长”，这条经验会进入记忆；如果类似反馈反复出现，就应该沉淀为技能规则或新版本。
| 协同点 | 产品要求 |
|---|---|
| 技能选择 | Kunora 可以记录某类任务常用技能，但不复制技能全文 |
| 记忆触发 | 根据任务、偏好、项目阶段和历史教训推荐技能 |
| 技能偏好 | 用户对某技能输出的偏好可以成为记忆 |
| 上下文分区 | 交付给智能体时，技能、记忆、工具说明必须分区 |
| 使用反馈 | 技能输出过长、过浅、格式不佳等反馈可进入记忆 |
| 技能沉淀 | 重复出现的经验和教训可以抽象为技能候选 |
| 版本引用 | 记忆引用技能 ID 和版本，而不是保存技能内容 |
技能协同不改变 Kunora 的核心定位。Kunora 仍然是记忆产品，但它必须管理好记忆和技能之间的双向关系：记忆触发技能，技能产生经验，经验沉淀为记忆或技能版本。同时，它必须防止技能全文被当成普通记忆召回。
特性八：记忆审计与解释
当智能体做出决策，用户应该能问：“你为什么这样做？”
Kunora 需要支持记忆审计：
| 审计问题 | 产品能力 |
|---|---|
| 这次召回了哪些记忆 | 召回日志 |
| 哪些记忆影响了输出 | 影响标记 |
| 这条记忆从哪里来 | 来源和证据 |
| 为什么没有召回某条记忆 | 过滤原因 |
| 旧记忆为什么失效 | 生命周期记录 |
审计不是企业功能的装饰，而是用户信任的基础。记忆越能影响智能体行为，就越需要能解释、能撤销、能修正。
特性九：多智能体接入
Kunora 的用户不只是人，也包括智能体。
对 kgent、Codex、Claude、Gemini、OpenClaw、Hermas 来说，Kunora 应该提供统一的记忆接口：
| 接口 | 智能体意图 |
|---|---|
remember | 把值得长期保留的信息交给 Kunora |
recall | 在任务开始前请求上下文包 |
update | 修正、替代或废弃旧记忆 |
explain | 解释一次召回或一次输出受哪些记忆影响 |
forget | 按权限删除或撤销记忆 |
recommend_skill | 根据任务和历史偏好推荐技能 |
产品体验上，不同智能体可以有不同 UI 和能力，但都围绕同一套记忆工作。Codex 记住的项目规则，可以帮助 Claude 写项目说明；Gemini 调研出的证据，可以帮助 kgent 编排后续任务；OpenClaw 执行工具时产生的结果，可以回写任务状态。
特性优先级
第一版不需要一次做完所有能力。合理的产品推进顺序是先解决“能安全记住并准确想起”，再解决“跨智能体共享和深度审计”。
| 阶段 | 核心特性 | 目标 |
|---|---|---|
| MVP | 捕获、建模、作用域、基础召回、上下文包 | 单智能体先不失忆 |
| V1 | 生命周期、冲突处理、审计、用户修正、技能偏好记忆 | 记忆可治理 |
| V2 | 多智能体共享、团队权限、跨工具证据链、技能触发与版本引用 | 形成智能体记忆层 |
| V3 | 召回评估、自动优化、组织级记忆策略、技能沉淀 | 规模化提升智能体质量 |
产品边界
Kunora 不应该变成万能知识库。它关注的是“会影响智能体未来行为的记忆”，不是所有信息的归档。
| 做 | 不做 |
|---|---|
| 保存会影响未来任务的事实、规则、决策、状态 | 保存所有聊天记录 |
| 给智能体提供可执行上下文包 | 把原始历史全文塞进 prompt |
| 管理记忆有效性和冲突 | 默认相信所有历史内容 |
| 支持用户审计、修正、撤销 | 让记忆黑箱影响输出 |
| 记录技能偏好和技能使用反馈 | 托管所有技能实现 |
结尾
Kunora 的产品蓝图不是从数据库开始，而是从智能体协作体验开始。
用户要的是一个不会反复失忆、不会乱想旧事、能延续工作上下文的智能体世界。Kunora 支撑这个世界的方式，是把记忆捕获下来，建模清楚，治理起来，在任务需要时准确交付，并在事后可以解释。
这就是 Kunora Agent Memory 的产品特性主线：从记住，到管住，再到想起，最后交付给智能体正确行动。