记忆与技能的关系

摘要

技能不是记忆，但技能和记忆是双向关系。

技能回答“怎么做”，记忆回答“当前上下文里什么仍然有效”。Kunora Agent Memory 如果不区分两者，就会把工作方法、用户偏好、历史事实和工具经验混在一起，导致召回结果不可控。

但如果只区分、不连接，也不够。记忆可以触发技能；技能也可以从记忆的时间线、事件线、经验和教训中抽象出来。本文定义 Kunora 中记忆与技能的边界，以及它们如何形成闭环。

基本定义

概念	回答的问题	例子	生命周期
记忆	过去发生了什么，什么仍然有效	用户要求文档要简洁；项目使用 Fastify	经常更新、失效、冲突处理
技能	遇到某类任务应该怎么做	设计文档写作流程；代码审查流程	从经验中沉淀，版本化演进
工具	用什么执行动作	Git、浏览器、文件系统、MCP	由运行环境提供
知识	一般性事实或领域知识	Google design doc 实践	需要来源和时效判断

一个直观判断是：

• 如果内容描述“事实、偏好、状态、决策”，它更像记忆。
• 如果内容描述“步骤、方法、检查表、模板”，它更像技能。
• 如果内容描述“外部能力接口”，它更像工具。

为什么必须区分

记忆和技能混在一起会产生三类问题。

混淆	例子	后果
把技能当记忆	每次写文档都召回完整写作技能内容	token 浪费，任务上下文变吵
把记忆当技能	把用户一次性偏好固化成通用流程	技能被临时信息污染
把工具经验当事实	某次工具失败被当成永久不可用	智能体行为变保守或错误

因此 Kunora 需要把“记忆召回”和“技能选择”设计成相关但独立的过程：记忆可以参与技能选择，但技能内容不能被当成普通记忆噪声召回。

关系模型

flowchart LR
  Timeline[时间线 / 事件线] --> Memory[记忆]
  Memory --> SkillTrigger[触发技能]
  SkillTrigger --> Skill[技能执行]
  Skill --> Outcome[执行结果]
  Outcome --> Experience[经验 / 教训]
  Experience --> Memory
  Experience --> SkillAbstract[抽象与总结]
  SkillAbstract --> SkillVersion[技能版本演进]
  SkillVersion --> Skill

这不是简单的“技能读取记忆”。更准确地说，它是两条链路同时存在：

方向	含义	例子
记忆触发技能	当前任务和历史上下文提示应使用某个技能	用户要写设计文档，且历史反馈要求简洁，于是触发 design-doc-writer
技能生成记忆	技能执行结果、用户反馈、失败教训进入记忆	上次设计文档太长，后续同类任务应先压缩
记忆沉淀技能	多次相似事件和经验被抽象为稳定流程	多次文档返工后，沉淀出设计文档写作技能
技能更新记忆	技能执行中确认新的事实、规则、状态	写蓝图时确认“技能协同是横切能力”

执行时关系

flowchart LR
  Task[当前任务] --> Intent[任务理解]
  Intent --> MemoryRecall[记忆召回]
  MemoryRecall --> SkillSelect[技能选择]

  SkillSelect --> Skill[技能：怎么做]
  MemoryRecall --> Context[记忆：当前有效上下文]

  Skill --> Agent[智能体执行]
  Context --> Agent
  Agent --> Feedback[执行结果]
  Feedback --> MemoryUpdate[更新记忆]

技能和记忆都影响智能体执行，但影响方式不同：

• 技能提供工作流程和质量标准。
• 记忆提供任务背景、用户偏好、项目约束和历史状态。
• 记忆可以触发技能选择。
• 技能执行后的结果和反馈会反过来更新记忆。

记忆如何触发技能

记忆触发技能，不是简单关键词匹配，而是由当前任务、历史偏好、项目阶段和过往经验共同决定。

触发依据	例子	触发结果
当前任务类型	用户要求“写产品蓝图”	触发设计文档类技能
历史偏好	用户嫌文档太啰嗦	技能以精简模式执行
项目阶段	当前处于产品设计阶段	少写实现细节，多写用户故事和蓝图
失败教训	上次缺少 Mermaid 导致结构不清	本次主动加入流程图
团队约定	设计文档必须含目标和非目标	技能执行前加载检查项

这意味着 Kunora 的召回结果不只进入 prompt，也可以影响“下一步该用什么能力”。

技能如何使用记忆

技能执行时，需要读取相关记忆来适配当前任务。

例如 design-doc-writer 技能定义了如何写设计文档。但在 Kunora 项目里，它还需要读取这些记忆：

记忆	对技能的影响
用户嫌文档太啰嗦	输出更克制，减少重复表格
用户重视 Mermaid、table、LaTeX	主动选择合适表达形式
用户重视印刷美学和可读性	做版式和阅读节奏检查
Kunora 当前处于产品设计阶段	先写产品故事和蓝图，少写实现细节

这说明技能不是孤立运行。技能给出方法，记忆给出适配参数。

技能如何从记忆中沉淀

技能的来源不是凭空编写出来的规则，而是对时间线、事件线、经验和教训的抽象。

flowchart LR
  Events[多次相似事件] --> Patterns[识别重复模式]
  Patterns --> Lessons[总结经验教训]
  Lessons --> Workflow[抽象成工作流]
  Workflow --> Checklist[形成检查表和模板]
  Checklist --> Skill[沉淀为技能]
  Skill --> Version[版本化迭代]

例如，设计文档技能可以来自这样的记忆沉淀：

时间线/事件线	经验或教训	抽象出的技能规则
第一次问题文档太散	只写段落不够可评审	先定义摘要、范围、原因、开放问题
用户要求使用 table、Mermaid、LaTeX	Markdown 不只是段落格式	根据内容选择表达形式
用户指出文档太啰嗦	完整不等于好读	输出前做冗余压缩
用户强调印刷美学	可读性是质量指标	检查标题、段落、表格宽度和节奏

这类沉淀一旦稳定，就不应该继续作为零散记忆召回，而应该升级为技能或技能版本。

记忆如何引用技能

记忆系统可以保存“技能偏好”和“技能使用经验”，但不应该复制技能全文。

可保存为记忆	不应保存为普通记忆
用户写设计文档时偏好使用 design-doc-writer	design-doc-writer 的完整模板内容
这个项目的产品设计文档应保持简洁	技能内部所有检查项
上次使用某技能输出太长，需要压缩	技能实现本身
某类任务默认先走问题定义再写蓝图	工具或技能的全部说明书

Kunora 可以记录“何时使用哪个技能”，但技能内容本身应由技能系统管理，并通过版本号引用。

产品特性要求

为了处理好两者关系，Kunora 至少需要这些产品能力：

能力	说明
记忆类型标记	区分事实、偏好、规则、决策、任务状态、经验、技能偏好
技能引用	记忆可以引用技能 ID 和版本，而不是复制技能内容
技能选择记忆	记录某类任务更适合使用哪些技能
技能使用反馈	记录用户对某次技能输出的评价
记忆触发技能	根据任务、作用域、偏好和经验推荐技能
技能抽象	从重复事件和经验中发现可沉淀的技能候选
技能版本演进	把稳定的新经验合入技能版本，而不是无限堆积记忆
召回隔离	默认不把技能全文作为任务记忆召回
上下文打包	把技能、记忆、工具说明分区交给智能体

上下文包应避免混杂：

Context Pack
- Skill: design-doc-writer@version
- Memories: user preferences, project rules, active decisions
- Tools: available execution interfaces
- Warnings: stale or conflicting memories

关键原则

• 技能是能力，记忆是上下文。
• 技能应版本化，记忆应生命周期化。
• 记忆可以触发技能，技能可以读取记忆，但技能不应该被临时记忆污染。
• 记忆可以引用技能，但不应该复制技能。
• 稳定、可复用的经验应从记忆升级为技能；一次性偏好应留在记忆中。
• 智能体执行时，应同时获得“该怎么做”和“当前什么有效”，但两者必须分区。

开放问题

• Kunora 是否负责技能注册，还是只记录技能引用？
• 技能选择应该由智能体自己完成，还是由 Kunora 推荐？
• 技能使用反馈是否应该影响后续技能选择？
• 什么条件下，一组记忆可以被抽象成新技能或技能版本？
• 技能版本更新后，旧记忆中的技能偏好如何迁移？
• 当用户偏好与技能默认流程冲突时，谁优先？
• 多智能体共享同一技能时，技能偏好是用户级、项目级，还是智能体级？

结论

记忆和技能必须一起设计，但不能混为一谈。

Kunora 的记忆系统应当帮助智能体知道“当前有效的事实和约束”；技能系统帮助智能体知道“这类任务该怎么做”。记忆触发技能，技能产出经验，经验再沉淀成新的记忆和技能版本。这个闭环成立后，智能体才既不会失忆，也能越做越有章法。