Kunora Agent Memory 产品蓝图

摘要

Kunora Agent Memory 的产品蓝图可以概括为一句话：把智能体的历史上下文，变成可治理、可召回、可交付的记忆资产。

它不是给用户多一个聊天窗口，也不是给智能体多接一个向量库。它要提供一组产品特性，让 kgent、Codex、Claude、Gemini、OpenClaw、Hermas 这些智能体都能接入同一套记忆能力：该记住的留下，该想起的出现，该过期的退出，该解释的能追溯。

蓝图总览

这条链路对应用户体验中的一句话：智能体先学会记住，再学会整理，再学会在任务开始前想起，最后学会解释为什么这样想起。

其中，“技能协同”是横切能力。记忆告诉智能体当前什么有效，技能告诉智能体这类任务该怎么做。更进一步，记忆可以触发技能，技能执行后的经验和教训也会沉淀为新的记忆，并可能抽象成技能版本。详细模型见 记忆与技能的关系。

特性一：记忆捕获

故事从一次普通对话开始。

用户对 Codex 说：“这个项目数据库访问必须走 repository 层，新功能先补测试。”这句话不应该只停留在当前对话里。Kunora 要能识别它不是闲聊，而是值得保留的项目规则。

记忆捕获负责从不同来源发现候选记忆：

来源	可捕获内容	例子
对话	用户偏好、规则、决策	“不要引入大型框架”
任务执行	状态、结果、失败经验	“客户导入接口已完成基础校验”
文件和代码	项目约定、目录结构、接口契约	repository 层负责数据库访问
工具结果	调研结论、测试结果、外部证据	Gemini 调研出的方案对比

这层产品体验要足够克制。Kunora 不能把每句话都存起来，而是要把“值得长期影响智能体行为”的信息变成候选记忆。

特性二：记忆建模

捕获只是开始。真正有用的记忆，必须有类型。

同一句话在不同语境下可能含义不同。“权限可以先不考虑”如果发生在 Demo 阶段，它是临时约束；如果发生在生产系统里，它可能是高风险决策。Kunora 需要把记忆拆成可理解的对象。

记忆类型	含义	智能体使用方式
事实	已确认的信息	作为背景上下文
偏好	用户或团队倾向	影响默认选择
规则	必须遵守的约束	约束执行行为
决策	已选方案及理由	避免重复争论
任务状态	当前进展和下一步	支持继续工作
经验	成功或失败教训	降低重复犯错
证据	来源、文件、工具结果	支持追溯和审计

这一步让记忆从“历史文本”变成“可操作对象”。智能体拿到规则时应当遵守，拿到偏好时应当参考，拿到证据时应当用于判断，而不是把所有内容当成同等权重的聊天记录。

特性三：记忆作用域

用户同时使用多个智能体，也同时参与多个项目。记忆如果没有边界，就会从能力变成污染。

Kunora 要为每条记忆标记作用域：

例如“用户喜欢简洁回答”可以是用户级偏好；“这个项目必须先写测试”是项目级规则；“本轮客户导入任务还差失败报告”是任务级状态。

作用域解决的是“谁该知道”的问题。Codex 做代码任务时应该拿到项目规则；Claude 写产品文案时应该拿到产品定位；Gemini 做调研时不一定需要拿到代码目录约定。

特性四：记忆生命周期

记忆不是永久真理。它会被确认、修正、替代、废弃，也可能自然过期。

生命周期是 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 的产品特性主线：从记住，到管住，再到想起，最后交付给智能体正确行动。