四类记忆资产总览

四类记忆资产总览

本节摘要:「可复用记忆资产」不是一个抽象概念,它具体指四类形态迥异、但被统一管理的内容:Chat Memory(记住人和事)、Skill(积累做法)、Wiki(文档知识地图)、CodeGraph(代码知识地图)。本节逐个讲清这四类资产各保存什么、解决什么痛点、典型场景是什么,并点明它们虽然形态不同,却被统一登记为同一种东西(Memory Asset),共享同一套 Owner、版本、可见性治理规则。理解这四类资产的分工,你就理解了「减少重复工作」在内容上到底覆盖了哪些东西。

一、四类资产各解决什么痛点

把上一节的三个痛点,对应到四类资产上看,会发现它们各有专攻:

关键概念:这四类资产合起来,正好覆盖了「人 和事(Chat Memory)+ 怎么做(Skill)+ 文档说了什么(Wiki)+ 代码怎么写(CodeGraph)」一个工程团队最核心的四类知识。它们不是随意分的,而是按「知识的形态」自然分类。

二、逐类细看:形态与价值

Chat Memory——一个能记住人和事的大脑

Chat Memory 保留偏好、事实、决策和交互历史。它的关键特性是「每个 Agent 创建时自动获得独立记忆,下次对话不必从自我介绍开始」。内部它又是分层的(L0→L1→L2→L3),这是第 4 章的主题。

💡 技巧:Chat Memory 最有价值的是那些「代价很高的上下文」——比如「别重构旧鉴权模块,移动端还在用」。这类信息靠人每次提醒极易遗漏,一旦沉淀进记忆,每个 Agent 都能继承。

Skill——一个会积累经验的技能库

Agent 做完复杂工作后,可以从对话和工具调用中提炼可复用 Skill。Skill 不只是一段 Prompt,它有版本、资源文件、触发边界、执行步骤和验证规则——这让它是「可执行的经验」而非「一段文字」。

Skill 的结构(区别于普通 Prompt)
  ├─ 版本号        (可回滚)
  ├─ 资源文件      (附带的脚本/模板)
  ├─ 触发边界      (什么场景下该用它)
  ├─ 执行步骤      (怎么做,分几步)
  └─ 验证规则      (做完怎么确认对)
​

个人 Skill 默认私有;审核后可分享给团队,再配装给其他 Agent。

Wiki——一张同时看懂文档的知识地图

Wiki 把产品文档、设计方案、运维手册生成结构化页面与链接图谱。它的设计灵感来源于把文档视为「由 LLM 增量维护、可持续复利的知识产物」——不是一次性导入,而是随文档变化持续更新。

⚠️ 注意:Wiki 不让 Agent 「先读完所有文件目录再开工」。它生成的是结构化页面 + 彼此链接,Agent 可以搜索、沿链接下钻,按需读取所需页面。

CodeGraph——一张看懂代码的知识地图

CodeGraph 索引代码符号、文件、调用关系和影响路径。Agent 可以搜索、阅读、查 callers / callees,也可以在改代码前先做 impact analysis。

它和普通代码搜索的根本区别:普通搜索只告诉「代码在这」,CodeGraph 还告诉「改了可能影响哪」。这一点让它在「安全地改代码」场景下不可替代。

三、统一性:为什么四类要被统一登记

四类资产形态差异巨大——Chat Memory 是结构化记忆,Skill 是可执行流程,Wiki 是文档图谱,CodeGraph 是代码图谱。但系统把它们统一登记为 Memory Asset:

┌─────────┐ ┌────────┐ ┌──────────┐ ┌───────────┐
│ChatMemory│ │ Skill  │ │   Wiki   │ │ CodeGraph │
└────┬────┘ └───┬────┘ └────┬─────┘ └─────┬─────┘
     │          │           │              │
     └──────────┴───────────┴──────────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Memory Asset    │
              │  统一元数据:      │
              │  Owner / 版本 /   │
              │  状态 / 可见性 /   │
              │  使用计数 / 绑定  │
              └─────────────────┘
​

统一的红利是「治理一致」:不用为每类资产写一套审核、分享、路由、收回规则,一套规则管四类。这就是为什么第 3 章要专门讲「记忆资产统一模型」——它不是抽象游戏,而是治理效率的根基。

四、四类资产的边界与协作

四类资产不是互斥的,它们常在一个任务里协作。以「修一个线上 Bug」为例:

修 Bug 任务里的四类资产协作
  ① CodeGraph:定位代码 + 做 impact analysis(改哪、影响哪)
  ② Wiki:查运维手册(部署流程、回滚步骤)
  ③ Chat Memory: recall 历史事故(上次类似 bug 怎么修的)
  ④ Skill:套用排障 Skill(标准排障步骤)
  修完后 → 可能把这次经验提炼成新 Skill,沉淀进 ④
​

关键概念:四类资产构成一个「知识立方体」——CodeGraph 答「代码」,Wiki 答「文档」,Chat Memory 答「人和事」,Skill 答「怎么做」。一个成熟任务往往同时需要多个维度,这就是为什么它们要被统一管理、按需装配(第 3、5 章)。

本节要点回顾

1. 四类分工:Chat Memory(人和事)、Skill(做法)、Wiki(文档)、CodeGraph(代码),覆盖工程团队四类核心知识。
2. Skill 不是 Prompt:它有版本/资源/触发/步骤/验证,是「可执行的经验」,可回滚可分享。
3. Wiki/CodeGraph 的共性:都是「知识地图」,前者结构化文档、后者结构化代码,都不让 Agent 整库读而是按需下钻。
4. 统一登记的红利:四类共享 Owner/版本/状态/可见性元数据,一套治理规则管四类——第 3 章的主题。
5. 协作而非互斥:一个任务常同时用多类资产,构成立体的知识立方体,这也是「按需装配」的动因。

知道了「记什么」,下一节看「谁来管」——四类资产由哪几个组件分工存储、构建、治理、接入。