Kunora Agent Memory 产品故事
摘要
Kunora Agent Memory 要成为智能体的记忆层。kgent、Codex、Claude、Gemini、OpenClaw、Hermas 这类智能体不需要各自重复发明记忆系统，而是把“记什么、怎么记、何时想起、哪些不能再影响当前任务”交给 Kunora。
用户感知到的变化很直接：智能体不再反复问同样的问题，不再忘记项目规则，不再被过期记忆带偏，并且能解释“这次为什么想起这些内容”。
更进一步，Kunora 不只让智能体想起事实，也让 智能体知道该用什么技能。记忆可以触发技能，技能执行后的经验和教训又会沉淀为新的记忆，甚至演化成技能版本。
一句话故事
过去，智能体每次工作都像重新认识用户。
有了 Kunora，智能体开始像长期同事：记得项目背景，知道哪些约定仍然有效，能在新任务开始前恢复关键上下文，也知道哪些旧信息不该再拿出来。
更成熟时，它还会像有复盘能力的同事：同类任务做多了，会把成功方法和失败教训沉淀成稳定技能。
产品角色
| 角色 | 他们关心什么 | Kunora 给他们什么 |
|---|---|---|
| 最终用户 | 智能体别失忆、别乱想、别重复问 | 连续的协作体验 |
| 智能体开发者 | 不想重复实现记忆系统 | 可接入的记忆能力 |
| 企业/团队 | 记忆要可控、可审计、可失效 | 治理与权限边界 |
| 智能体本身 | 当前任务需要哪些历史上下文 | 可执行的上下文包 |
| 技能作者/维护者 | 哪些经验值得沉淀成流程 | 技能触发、反馈和版本演进依据 |
使用前：智能体各自失忆
一个用户同时使用 多个智能体：
- 用 Codex 改代码。
- 用 Claude 写产品材料。
- 用 Gemini 做调研。
- 用 kgent 编排工作流。
- 用 OpenClaw 或 Hermas 执行特定工具任务。
这些智能体都很强，但它们的记忆互不相通。用户在 Codex 里说过的项目规则，Claude 不知道；Claude 里确定过的产品口径，Gemini 不知道；Gemini 调研出的结论，kgent 编排任务时也可能用不上。
结果是用户不断重复解释背景。更糟糕的是，每个智能体还可能各自记住一部分过期信息，最后做出互相冲突的判断。
使用后：Kunora 成为共享记忆层
Kunora 不替代智能体，也不替代模型。它站在智能体和历史上下文之间，负责把历史经验变成可治理的记忆资产。
核心体验故事
故事一：Codex 不再忘记项目规则
用户告诉 Codex：“这个项目数据库访问必须走 repository 层，新功能先补测试。”
Kunora 不只是保存原文，而是把它识别为项目级规则：
| 记忆 | 类型 | 作用域 | 状态 |
|---|---|---|---|
| 数据库访问走 repository 层 | 规则 | 当前项目 | 有效 |
| 新功能先补测试 | 工作偏好/规则 | 当前项目 | 有效 |
几天后，用户让 Codex 新增接口。Codex 调用 Kunora 召回当前项目规则，拿到的是短小的操作约束，而不是一整段历史聊天记录。
结果：Codex 直接按项目约定工作，不需要用户重复提醒。
故事二：Claude 继承产品口径
用户先和 Claude 讨论 Kunora 的产品定位：不是聊天记录库，而是智能体记忆基础设施。
后来用户让 Claude 写官网文案。Kunora 召回产品定位、目标用户、禁用表述和核心价值，Claude 不会把产品写成普通 RAG 或知识库。
结果：产品口径跨会话稳定，内容协作不会每次从零开始。
故事三：Gemini 调研结果进入团队记忆
Gemini 帮用户调研不同智能体框架的记忆方案。Kunora 把调研结论保存成带来源、时间和置信度的知识记忆。
几天后 kgent 编排设计任务时，Kunora 只召回仍然相关的调研结论，并过滤掉低置信度或已过期内容。
结果：调研不再沉没在单次会话里，而是变成后续任务可复用的证据。
故事四：过期记忆不会继续污染智能体
Demo 阶段，用户说：“权限可以先不考虑。”
正式阶段，用户补充：“从现在开始，管理接口必须做权限校验。”
Kunora 不把这两条简单并列保存，而是标记状态变化：
后续 Codex 或 OpenClaw 新增管理接口时，Kunora 不再召回旧的 Demo 约束，只返回当前有效规则。
结果：记忆增强智能体，而不是污染智能体。
故事五：记忆触发技能，技能沉淀经验
用户让 Codex “重写问题文档”。Kunora 发现当前任务是设计文档写作，同时记得用户之前提出过三条偏好：文档要简洁，要使用表格和 Mermaid，要重视印刷美学。
于是 Kunora 不只是召回这些偏好，还推荐使用 design-doc-writer 技能，并把相关记忆作为技能执行参数交给智能体。
第一次输出后，用户反馈：“太啰嗦了。”这条反馈进入 Kunora。后续同类任务中，Kunora 会触发同一技能的精简模式。如果类似反馈反复出现，Kunora 应将它识别为可沉淀经验，推动技能版本更新。
结果：智能体不只是记住用户偏好，还会把重复出现的经验转化成更稳定的工作方法。
故事六：用户能追问为什么这样做
Codex 修改一个管理接口时自动补了权限校验。用户问：“为什么你这里加了权限？我之前不是说 Demo 阶段可以先不考虑权限吗？”
Kunora 给出的解释不是一句“根据上下文判断”，而是一组可追溯理由：
| 解释项 | 内容 |
|---|---|
| 当前有效记忆 | “正式阶段，管理接口必须做权限校验” |
| 失效记忆 | “Demo 阶段可以不考虑权限”已被正式阶段规则替代 |
| 触发技能 | 代码修改任务触发后端接口实现/审查技能 |
| 影响输出 | 权限规则作为 active rule 进入上下文包 |
| 证据来源 | 用户在正式阶段补充的权限要求 |
用户可以进一步撤销、修正或确认这些记忆。如果用户确认“正式阶段规则有效”，Kunora 会继续把它用于后续 Codex、OpenClaw 或 kgent 的相关任务；如果用户修正规则，Kunora 会更新生命周期和后续召回结果。
结果：智能体不再黑箱地“记得”或“乱记”。用户能看见记忆如何影响输出，也能纠正记忆。
产品蓝图：从记住到会用
Kunora 的产品能力可以分成九类。故事里的每个体验，都应该能在蓝图中找到对应特性。
| 故事体验 | 蓝图特性 |
|---|---|
| Codex 不忘项目规则 | 记忆捕获、记忆建模、记忆作用域、任务感知召回 |
| Claude 继承产品口径 | 记忆作用域、上下文交付、多智能体接入 |
| Gemini 调研进入团队记忆 | 记忆捕获、证据化建模、记忆审计 |
| 过期记忆不再污染智能体 | 记忆生命周期、任务感知召回、上下文交付 |
| 记忆触发技能并沉淀经验 | 技能协同、反馈与审计、多智能体接入 |
| 用户追问为什么这样做 | 记忆审计与解释、上下文交付、技能协同 |
接入方式故事
对智能体来说，Kunora 应该像一个外部记忆器，而不是另一个聊天应用。
智能体主要在五个时刻接入：
- 任务开始前，请求当前任务需要的上下文包。
- 任务开始前，根据任务和历史偏好请求技能推荐。
- 任务过程中，把值得保留的事实、规则、决策、状态和经验写入 Kunora。
- 任务结束后，回写结果、反馈、失败教训和用户评价。
- 用户追问时，解释本次输出受哪些记忆和技能影响。
设计原则
- 记忆是产品资产，不是聊天缓存。
- 召回是任务上下文重建，不是文本搜索。
- 准确比完整重要，少而准比多而杂重要。
- 每条记忆都应有类型、作用域、来源、状态和有效性。
- 智能体应获得可执行上下文，而不是原始历史噪声。
- 用户和团队必 须能查看、修正、废弃和审计记忆。
- 记忆可以触发技能，技能可以沉淀经验，但两者必须分区交付。
结尾故事
没有 Kunora 时，用户在不同智能体之间搬运上下文。
有了 Kunora 后，kgent、Codex、Claude、Gemini、OpenClaw、Hermas 都可以围绕同一套受治理的记忆工作。智能体仍然各有所长，但它们不再各自失忆，也不再各自污染上下文。
这就是 Kunora 的产品位置：智能体时代的长期记忆层，以及记忆驱动技能演进的基础设施。