把记忆交给仓库，而不是交给 Agent

　　很多人用 Agent 做项目，第一反应是让它"记住"。记住目录结构、记住发布流程、记住踩过的坑。仿佛 Agent 记得越牢，项目就越稳。可越接触持久的运维，我越觉得这个方向反了——真正想让项目长期跑下去，最该做的，恰恰是不把记忆交给 Agent，而是交给仓库。

一、Agent 的记忆，本质是"一次性"的

　　Agent 的对话记忆有个致命特性：它活在会话里。这一轮聊完，关掉窗口，它脑子里那点"上下文"就烟消云散。下次再开，它又变回那个什么都不知道的陌生人，你得把环境、命令、规矩重新讲一遍。

　　记忆虽然可查，但不如单独写一个文件方便。它散落在工具的内部里，翻起来绕，改起来也绕，你很难一眼看清它到底记了哪条、记歪了没有、有没有记漏。它像一块写满字的黑板，被下一场会话冲掉，你连"曾经写过什么"都要费劲去翻。

　　靠这种记忆做"持久的运维"，等于把地基盖在沙地上。会话一断，过往的一切约定全部归零，项目没有留下任何可依赖的痕迹。

二、为什么规则文件是对的

　　把记忆从 Agent 脑子里搬出来，写进仓库里的 markdown 文件，看起来是"多此一举"，其实是把记忆从"临时"升级成了"永久"。

　　第一，它可读。人是中文、机器是代码，而 markdown 是两者能同时读懂的格式。接手的人能看，新开的 Agent 也能看，谁都不必依赖某个特定会话的"既往记忆"。

　　第二，它可版本化。跟随 git 一起提交，改过什么、什么时候改的、为什么改，全有迹可循。规矩不是某天"随口约定"的，而是有 commit 记录的一等公民。

　　第三，它可移植。不绑定某个工具、某个会话、某个模型。就算换一套 Agent 工具，这份 markdown 依然躺在仓库里，照读不误。记忆跟着项目走，而不是跟着某个会过期的对话走。

　　写规则文件，本质上是在做一件事：把"临时约定"沉淀成"可继承的资产"。Agent 可以随时换，而这份资产不会丢。

三、但有三处必须校准

　　方向对了，落地还有三个坎，跨不过去，规则文件就只是"存在"，而不是"被读到"。

　　第一，位置要放在 Agent 会自动加载的地方。规则文件写得多好没用，得让 Agent 每次动手前主动读到。这就意味着它必须躺在固定的约定路径，比如项目根目录的规则文件，或工具约定的目录结构里。否则每次还得人手动塞给它，等于又退化回"靠提醒"。

　　第二，记忆和状态要分开。规则是"几乎不变"的标准——写作规范、发布流程、红线，写进一份文档，长期稳定。而状态是"每次都在变"的事实——服务起没起、上次改到哪、部署到哪一步。状态如果也塞进规则里，文档会变成一个永远在改、永远对不上的泥潭。分开写，规则稳定可读，状态每次更新、可被复查。

　　第三，优化要落到"有产出的检查"，而不是定时空转。持续跟进不是让 Agent 每天过来看一眼说"一切正常"，那很快会变成噪音。真正有价值的巡检，是带着明确问题来的：构建有没有失败、有没有文章又踩进"时间未来"的坑、本地的 git 是不是落后了 remote。发现问题才动手，动手才值得占用一次运行。

四、把临时交给永久

　　回过头看，这套方法的核心其实是一句话：Agent 负责执行，仓库负责继承。

　　Agent 每次启动都是全新的，没关系，它照着仓库里的规矩办事就行。会话断了，项目依然完整，因为真正重要的东西——约定、标准、踩过的坑——都写在磁盘上，跟着 git 一起活着。

　　这也是我对"持久运维"越来越明确的体会：持久的不是某个 Agent，而是那些能被反复读取、反复继承的文件。