AI 研发里的 memory，至少有三层
最近我在往外讲 hengshi-jarvis，经常会被追问：Claude Code、Hermes 这些工具也在讲 memory，mem0 这一类产品更是直接做 memory，JARVIS 为什么还要反复讲 memory。原因不复杂，这里本来就混着三层东西：coding agent 自带的 memory、mem0 这一层把资料单独存和找回的 memory、还有 jarvis-types 这种会直接改执行顺序的组织 memory。三层不拆开，JARVIS 在 AI 研发系统里的位置就会越讲越糊。
Harness 之后，公司还是得有自己的 JARVIS
接着上一篇往下写。上一篇讲的是 JARVIS 最近一个月收进了哪些运行规则。这篇换个角度，把 OpenAI、Martin Fowler、LangChain、Mitchell Hashimoto、Tanka、ArcKit，还有最近几篇中文文章放在一起看。沿着这条线往下走，会更容易看清另一件事：agent 能跑起来很重要，但真进公司以后，最后还是得按这家公司自己的做法干活。这层东西，还是可以叫 JARVIS。
JARVIS 正在变成 AI 研发组织的运行中枢
这一个月我把 JARVIS 又往前推了一步。现在它会直接管 agent 从哪进来、在哪干活、先读什么、做到什么才算收口。说它只是知识库，已经不准确了。
JARVIS 与 Harness Engineering：AI 研发的记忆层和运行层
Harness Engineering 正在成为 AI agent 工程化的核心范式。但"让 agent 跑得稳"和"让 agent 知道该干什么"，是两个不同的问题。
AI 研发实验该怎么做：验证的不是代码产量，而是闭环能力
真正有价值的 AI 研发实验，不是看 AI 写了多少代码，而是看需求、实现、测试、验收、知识沉淀能不能形成稳定闭环