AI 研发里的 memory，至少有三层
AI 研发里的 memory，至少有三层
最近我在往外讲 hengshi-jarvis，经常会被追问同一类问题。
JARVIS 一直讲 memory。Claude Code、Hermes 这些工具也在讲 memory。mem0、mem9、MemPalace 这一类产品更是直接拿 memory 当主线。
几个 memory 一放在一起，就容易讲糊。
然后问题就会变成：大家都在做记忆，JARVIS 到底多做了什么。
这篇我就只讲这个问题。
我想讲的是 AI 研发系统里的 memory 到底分几层，每层在记什么，为谁服务，最后怎么接到一起。
前面两篇，我一篇写最近一个月 JARVIS 收进了哪些运行规则，一篇写为什么公司最后还是得有自己的 JARVIS。这一篇继续往下走，把 memory 讲透一点。
这一篇先只拆 memory。后面如果继续写，我会再把 runtime、workflow、review、writeback 这些 layer 一层层拆开。
先别把 memory 当成一个词
真进研发现场以后，memory 至少有三层。
- coding agent 自带的 memory
- mem0 这一类 memory infrastructure
- JARVIS 这一类组织执行系统里的 memory
三层都重要，干的不是一件事。
coding agent 的 memory，解决的是单个 agent 别老失忆。
mem0 这类 memory layer，解决的是东西能存住、找得回、还可以多人共用。
JARVIS 这层管得更靠后：这些记忆回来以后，公司默认按什么做，谁来兜底，做到什么算收口，最后怎么写回去。
这三层一拆开，后面就不容易讲乱了。
第一层：coding agent 自己的 memory
Claude Code、Hermes 说自己有 memory，这没啥好争的，agent 本来就得记东西。
它记的通常是这些东西：
- 这个用户是谁
- 这台机器是什么环境
- 这个 repo 最近在干什么
- 这个人平时怎么写、怎么走流程、怎么说话
- 上一轮做到哪了，下次怎么少重复
- 哪些经验可以沉成技能、提示、规则
这层就是解决一件事：别让 agent 每一轮都像新来的。
它先服务 agent 和当前用户这一段协作。工具会越来越懂你，也越来越懂当前环境。
边界也很清楚。
它不天然等于公司的组织记忆，更不天然等于公司的默认执行系统。今天这个 agent 记住了你的偏好，不代表另一个 agent 进来就能自动照着同一套做法干活。它更像 agent 自己的长期上下文。
第二层：mem0 们在做的 memory
mem0、mem9、MemPalace 这类东西，管的已经不是“某个 agent 怎么更懂我”了。它们是把 memory 单独拎出来做。
它们要解决的是：
- 什么值得记
- 记下来以后怎么存
- 记成什么结构
- 下次怎么搜回来
- 多个 agent、多个 runtime、多个设备能不能共用
- 怎么更新、治理、审计
Mem0 这条线，是想把 memory 做成一层通用底座。mem9 更看重多处共用、长期接得上。MemPalace 更看重东西留在本地，原文别被揉坏。
打法不一样，但核心都一样：把“历史别散掉，重要上下文下次能回来”这件事做好。
这层对 AI 研发太重要了。没有它，agent 每轮都要重新捡材料，很多事根本跑不长。
边界也在这。
它能把材料递回来，但通常不会替你定义公司后面按什么规矩继续做。
第三层：JARVIS 这层记的，已经不只是材料了
JARVIS 讲的 memory，已经走到执行这层了。
JARVIS 记的，更多是公司已经跑出来的默认做法：
- 任务进来先从哪条闭环进
- 第一跳先看 issue、日志、模块总览，还是先复现
- 什么情况必须升级给人
- 哪些 repo 或 module 有禁区
- 什么证据够了才能算 done
- 哪些结果要沉到 repo 规则，哪些沉到共享 skill，哪些沉到长期知识
这是组织 memory，而且会直接改执行顺序。
同样一条历史记录，在不同团队里，后面的动作可以完全不一样。有人先补测试再动代码，有人先复现，有人高风险改动一律升级，有人要求所有收获最后回写文档，有人要求沉到技能库。
所以 JARVIS 这一层真正记住的，是“这家公司平时怎么干活”。
它记材料，也记默认动作。材料回来以后，系统下一步怎么走，靠的就是这层。
三层 memory 到底差在哪
可以直接这么看：
- coding agent memory：记住“我和这个用户、这个环境怎么配合”
- mem0-types memory：记住“哪些材料要持久化，之后怎么被找回来”
- jarvis-types memory：记住“这些材料回来以后，公司默认怎么继续干活”
换个说法也一样。
第一层服务单个 agent
第二层服务更长的历史材料，也服务多个 agent 一起用
第三层服务公司自己的研发闭环
第一层让 agent 更懂你
第二层让材料能回来
第三层让默认动作能接着跑
agent 可以换
memory backend 也可以换
但公司自己的默认执行系统，不能跟着一起丢
所以这事不能再拿一个笼统的 memory 概念糊过去。
层一分开，位置就清楚了。
它们怎么融合
真到现场里，这三层是套在一起干活的。
真实研发里，链路大概是这样：
- 任务进来，JARVIS 先判断它属于哪条闭环，该去哪个 repo 或 workspace，先读什么，第一跳先找什么证据。
- 执行这件事的 agent 带着自己的 memory 进场。它知道当前用户偏好、机器环境、repo 现状，少走重复路。
- 如果需要长期资料、跨会话经验、共享上下文，就从 mem0 这一类 memory layer 里把材料召回来。
- agent 在 JARVIS 设好的默认规则里继续干活：什么时候升级、什么时候补测试、什么时候停手、什么时候收口。
- 任务结束后，新的东西再分层回写：有些写回 agent 自己的 memory，有些写回 memory layer，有些直接升级成 JARVIS 里的规则、skill、workflow、writeback judgment。
放到这条链路里看，关系就清楚了。
- agent memory 负责让执行者别失忆
- memory infrastructure 负责让材料别散
- JARVIS 负责让整个系统别乱
少一层也能凑合跑，跑不远。
最近一个月我在 hengshi-jarvis 里往前推的，基本都落在第三层
所以我最近一个月在 hengshi-jarvis 里真正往前推的，很多已经不是把资料记住再找回来这么简单了。
canonical runtime root、per-task clones、workspace preflight、repo routing、completion rules，这些管的都不是“什么值得存”，也不是“某个 agent 怎么更懂我”。
它们写进去的，就是第三层：组织默认动作。
它们在回答的是另一组问题：
- agent 应该从哪条闭环进去
- agent 应该在哪个 workspace 里干活
- 开工前哪些知识必须先读
- 什么证据出来以后才算 done
- 哪些变化需要 durable writeback
所以我最近这一轮往前推，重点已经落到“怎么让组织经验变成默认动作”了。
所以 JARVIS 和 mem0 们不是一层。
mem0 们先把材料留住。JARVIS 再把这些材料接进执行闭环。
那两篇中文文章，刚好把问题推到这里
最近我看的两篇中文文章，一篇在讲模型会变，软件工程会留下；另一篇在讲软件工程的功底在智能时代会更关键。
这两个判断我基本都同意。
因为 AI 真进研发以后，最后拼的就是工程基本功、测试习惯、review 纪律、边界意识、历史经验。
但再往下问一步，就会碰到一个更具体的问题。
这些东西最后留在哪？
是只留在几个人脑子里。
是只留在某个 agent 自己的长期上下文里。
还是留在一套可以跨 agent、跨会话、跨团队继续生效的系统里。
前两层都要有，最后还得落到第三层。
不然软件工程确实会留下，但留下的方式还是口头经验、个人习惯和临场判断。agent 只能偶尔碰对，碰不成稳定系统。
为什么这一层最后还是得公司自己做
再往下走一步，就会碰到真正麻烦的地方。
因为每家公司默认怎么干活，差别都很大。
同样一条记忆，在不同团队里，后面的动作可能完全不一样。
有人默认先看 issue，再碰代码。有人默认先复现，再决定要不要补测试。有人要求高风险改动一律升级。有人把某些模块当禁区，agent 只能读不能改。有人要求经验最后沉到 repo 文档。有人要求沉到共享 skill。
这些东西没有标准答案。
所以 memory product 再强，也不会天然知道你们团队这套默认做法。
它不会替你规定：
- 哪些历史判断以后默认生效
- 哪些例外情况以后默认升级
- 哪些闭环必须补证据
- 哪些结果这次必须写回系统
这些事最后还是得公司自己做。
所以我一直把 JARVIS 当成组织能力。它不是一个装上去就能直接通用的标准产品。
外面的 memory layer、agent harness、workflow system、review system 都很重要，也都可以直接拿来用。但公司自己的收口层，还是只能从自己的研发过程里长出来。
结语
所以今天再看 Claude Code、Hermes 的 memory，mem0-types 的 memory，还有 jarvis-types 的 memory，我会直接把它们拆成三层。
第一层，让 agent 记住自己怎么和人协作。
第二层，让资料稳稳留下来，之后还能被找回来。
第三层，把这些资料、规则和历史判断压成公司自己的默认动作。
三层都在，系统才真的立得住。
JARVIS 和 mem0 们本来就该接在一起。前面的 agent 怎么换，后面的 memory 怎么换，它都得接得住。
它最后要守住的是公司自己的研发闭环。工具换不换，没那么重要。
这一篇先把 memory 讲到这里。
后面如果继续写，我会再把 runtime、workflow、review、writeback 这些 layer 一层层拆开。
这些层不讲开，JARVIS 在 AI 研发系统里的位置就还是会糊。
