MemGPT 最漂亮的比喻，是把 context window 当 RAM，把外部长记忆当 disk，由 agent 自己决定何时 page in、何时 page out。这个思想让“模型没有状态”第一次听起来像一个可以用操作系统方法解决的问题。
但如果今天还只用 core、recall、archival 三层来介绍 Letta，就漏掉了它正在发生的变化：旧 letta 仓库已标明是 legacy server，活跃产品迁到 Letta Code 和新的 Agent SDK；记忆也从虚拟内存走向了 Git 管理的自我修改。
一次记忆修改，不再只是一次写文件
启用 MemFS 后，agent 的 persona、用户信息、skill 和其他上下文文件进入一个 Git repository。memory tool 在修改时要求给出 reason，写入完成会产生带 agent identity 的 commit。于是每次“我以后要记住这件事”都有 diff、作者和时间。
后台 reflection 更谨慎。harness 会创建形如 letta/reflection/<id> 的 branch 和独立 worktree；subagent 只在这个 worktree 中整理记忆，提交后再尝试合并回主 memory。无变化可以清理，干净修改可以合并，冲突则保留现场等待检查。
这套流程把 agent 的自我修改变成普通工程团队熟悉的对象：可以 review、blame、revert，也可以比较两个时期的人格文件。Git 不是为了炫技，而是因为记忆修改本来就具有代码修改的风险——它会改变未来所有行为。
从“召回什么”到“谁有权改变我”
向量记忆的核心问题是相关性；版本化记忆多了治理问题。主 agent 可以直接写吗？reflection subagent 能改哪些目录？远端 MemFS 何时同步？冲突由谁裁决？
Letta Code 用 worktree 隔离写入面，用 commit 保留意图，用 merge 暴露冲突。它没有让模型变得永远正确，却让错误不再无痕。对长期 agent 来说，这比多召回几个百分点更重要。
当然，Git 也不是终端用户界面。普通用户不会愿意理解 detached HEAD 或 merge conflict。真正的产品挑战，是把这些语义翻译成“它想改变这条记忆，理由是……，是否接受？”同时保留底层可审计性。
我的思考
Letta Code 最先吸引的会是开发者、AI 研究者和需要长期可调 agent 的团队，因为他们已经理解版本控制为何值得付出复杂度。大众用户会晚一些进入，除非产品把 commit 和 branch 隐藏在自然的审核流程之后。
市场上可能出现一个新角色：memory maintainer。它不负责调 prompt，而是审查 agent 如何形成长期偏好、处理冲突、回滚被污染的自我。这在企业知识、医疗辅助和个人数字分身中都会成为真实工作。
我额外觉得，版本控制改变了责任归属。过去我们说“模型突然变了”，很难定位原因；当人格和记忆都有 commit，行为变化第一次可能被追到一条具体修改。未来对 agent 的治理，也许会像今天治理生产代码一样：重要的不是永不犯错，而是每次改变都有来路，也有退路。