记忆与技能的关系
摘要
技能不是记忆，但技能和记忆是双向关系。
技能回答“怎么做”，记忆回答“当前上下文里什么仍然有效”。Kunora Agent Memory 如果不区分两者，就会把工作方法、用户偏好、历史事实和工具经验混在一起，导致召回结果不可控。
但如果只区分、不连接，也不够。记忆可以触发技能；技能也可以从记忆的时间线、事件线、经验和教训中抽象出来。本文定义 Kunora 中记忆与技能的边界，以及它们如何形成闭环。
基本定义
| 概念 | 回答的问题 | 例子 | 生命周期 |
|---|---|---|---|
| 记忆 | 过去发生了什么，什么仍然有效 | 用户要求文档要简洁；项目使用 Fastify | 经常更新、失效、冲突处理 |
| 技能 | 遇到某类任务应该怎么做 | 设计文档写作流程；代码审查流程 | 从经验中沉淀，版本化演进 |
| 工具 | 用什么执行动作 | Git、浏览器、文件系统、MCP | 由运行环境提供 |
| 知识 | 一般性事实或领域知识 | Google design doc 实践 | 需要来源和时效判断 |
一个直观判断是：
- 如果内容描述“事实、偏好、状态、决策”，它更像记忆。
- 如果内容描述“步骤、方法、检查表、模板”，它更像技能。
- 如果内容描述“外部能力接口”，它更像工具。
为什么必须区分
记忆和技能混在一起会产生三类问题。
| 混淆 | 例子 | 后果 |
|---|---|---|
| 把技能当记忆 | 每次写文档都召回完整写作技能内容 | token 浪费，任务上下文变吵 |
| 把记忆当技能 | 把用户一次性偏好固化成通用流程 | 技能被临时信息污染 |
| 把工具经验当事实 | 某次工具失败被当成永久不可用 | 智能体行为变保守或错误 |
因此 Kunora 需要把“记忆召回”和“技能选择”设计成相关但独立的过程：记忆可以参与技能选择，但技能内容不能被当成普通记忆噪声召回。
关系模型
这不是简单的“技能读取记忆”。更准确地说，它是两条链路同时存在：
| 方向 | 含义 | 例子 |
|---|---|---|
| 记忆触发技能 | 当前任务和历史上下文提示应使用某个技能 | 用户要写设计文档，且历史反馈要求简洁，于是触发 design-doc-writer |
| 技能生成记忆 | 技能执行结果、用户反馈、失败教训进入记忆 | 上次设计文档太长，后续同类任务应先压缩 |
| 记忆沉淀技能 | 多次相似事件和经验被抽象为稳定流程 | 多次文档返工后，沉淀出设计文档写作技能 |
| 技能更新记忆 | 技能执行中确认新的事实、规则、状态 | 写蓝图时确认“技能协同是横切能力” |
执行时关系
技能和记忆都影响智能体执行，但影响方式不同：
- 技能提供工作流程和质量标准。
- 记忆提供任务背景、用户偏好、项目约束和历史状态。
- 记忆可以触发技能选择。
- 技能执行后的结果和反馈会反过来更新记忆。
记忆如何触发技能
记忆触发技能，不是简单关键词匹配，而是由当前任务、历史偏好、项目阶段和过往经验共同决定。
| 触发依据 | 例子 | 触发结果 |
|---|---|---|
| 当前任务类型 | 用户要求“写产品蓝图” | 触发设计文档类技能 |
| 历史偏好 | 用户嫌文档太啰嗦 | 技能以精简模式执行 |
| 项目阶段 | 当前处于产品设计阶段 | 少写实现细节，多写用户故事和蓝图 |
| 失败教训 | 上次缺少 Mermaid 导致结构不清 | 本次主动加入流程图 |
| 团队约定 | 设计文档必须含目标和非目标 | 技能执行前加载检查项 |
这意味着 Kunora 的召回结果不只进入 prompt，也可以影响“下一步该用什么能力”。
技能如何使用记忆
技能执行时，需要读取相关记忆来适配当前任务。
例如 design-doc-writer 技能定义了如何写设计文档。但在 Kunora 项目里，它还需要读取这些记忆：
| 记忆 | 对技能的影响 |
|---|---|
| 用户嫌文档太啰嗦 | 输出更克制，减少重复表格 |
| 用户重视 Mermaid、table、LaTeX | 主动选择合适表达形式 |
| 用户重视印刷美学和可读性 | 做版式和阅读节奏检查 |
| Kunora 当前处于产品设计阶段 | 先写产品故事和蓝图，少写实现细节 |
这说明技能不是 孤立运行。技能给出方法，记忆给出适配参数。
技能如何从记忆中沉淀
技能的来源不是凭空编写出来的规则，而是对时间线、事件线、经验和教训的抽象。
例如，设计文档技能可以来自这样的记忆沉淀：
| 时间线/事件线 | 经验或教训 | 抽象出的技能规则 |
|---|---|---|
| 第一次问题文档太散 | 只写段落不够可评审 | 先定义摘要、范围、原因、开放问题 |
| 用户要求使用 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 的记忆系统应当帮助智能体知道“当前有效的事实和约束”；技能系统帮助智能体知道“这类任务该怎么做”。记忆触发技能，技能产出经验，经验再沉淀成新的记忆和技能版本。这个闭环成立后，智能体才既不会失忆，也能越做越有章法。