前面二十一篇讲的是怎么把这套东西搭起来。这一篇讲怎么让它长期活着—— 以及一件同样重要的事：怎么敢把它关掉。
本文写什么四条纪律。 本文不写我们自己的拓扑、主机、密钥位置与备份方案。只写原则，不写现场。
原则一句话：让 agent 随便折腾的地方，和放着「能造成不可逆后果的凭证」的地方， 不该是同一台机器。
| 角色 | 放什么 | 特点 |
|---|---|---|
| 干活的 | 代码、数据、日志、agent 本体 | 可丢弃、可重建，出事重装就行 |
| 有钥匙的 | 能动钱、能对外发布、能改生产的凭证 | 面尽量小、能碰它的东西尽量少 |
为什么值得拆：第 16 篇那条组合风险—— 只读工具把秘密读进上下文，对外工具把上下文发出去。 如果秘密根本不在这台机器上，这条链路从源头就断了。
不是每个人都要为此多开一台机器。退而求其次的三层，成本几乎为零：
① 分文件：密钥单独一个文件（如 .env），配置归配置——
这样备份时能干净地排除掉；
② 分权限：那个文件只有需要它的那个用户能读，并且在 agent 的
deny 规则里显式禁止读它（第 2 篇）；
③ 分级别：日常干活用权限最小的那把钥匙，
高权限的那把平时根本不放在这台机器上。
这是第 11 篇那条坑的正式解法。
| 做法 | 问题 / 好处 |
|---|---|
| ❌ 成功时也发通知 | 训练你无视通知——真出事那条也被无视了 |
| ❌ 只在失败时发通知 | 听起来对，但挡不住「整个进程死了，连失败都发不出来」 |
| ✅ 心跳缺失告警 | 每次成功更新一个时间戳；另一头检查这个时间戳是否超时未更新 |
关键在于：检查的那一方必须在被监控的东西之外。 自己监控自己，死透了就一起沉默。
| 还该盯的三项 | 为什么 |
|---|---|
| 重启次数 | 第 21 篇：自动重启会把「一直在坏」伪装成「一直在跑」 |
| 磁盘用量 | 盘满会让所有东西同时坏，且原因和业务无关 |
| 花销 | 常驻 agent 会在你不看的时候花钱（第 12 篇心跳那条） |
这句话在运维里是老生常谈，但在这条线上格外要紧—— 因为这套东西的价值大量沉在记忆、技能、配置这些「说不清具体在哪」的地方 （第 6 篇那张清单）。
真正的检验只有一个：能不能在一台全新的机器上，用你的备份和笔记，把它重建出来？ 这件事至少做一次。做完你会发现两三个当初漏掉的东西——那几个就是真出事时会要命的。
| 备什么 | 怎么备 |
|---|---|
| 配置目录 | 进你已有的备份，但排除密钥文件 |
| 记忆与技能 | 同上——这是最不可替代的一类 |
| 重建步骤 | 第 20 篇那份笔记，只写步骤不写秘密 |
| 密钥本身 | ⚠ 不进普通备份——用密码管理器之类的专门地方，且只备「有哪些」的清单 |
这条线以这一句收尾，因为它是第 12 篇那台停掉的机器留下的教训。
它还在花钱、还在等着被维护、还在你脑子里占一格「那台机怎么样了」。 而且它仍然是一个攻击面——一台你不再关注的公网机器，比一台你在用的更危险， 因为它不会被更新，出了事也没人看。
| 该关的信号 | 说明 |
|---|---|
| 它的活被别的东西接走了 | 这是最正当的关机理由，不需要它「变坏」才关 |
| 产出没有接收者 | 第 10 篇那条判据：没人因为它的输出做不同的事 |
| 你已经一个月没看它了 | 说明它对你不重要，但它对攻击者一样重要 |
这是第 14 篇那条命令之所以对我们有用的前提。 把状态目录整个存下来，成本是几分钟，收益可能是几个月之后的一条搬家命令。
「停得掉」应该是你搭它的时候就想好的事， 而不是要停的时候才发现拆不开。
从第 1 篇「能跑命令才是分水岭」，到这一篇「敢关掉」，
中间穿过一根主心骨——一个 base_url，
它让你在任何一层都不被单一供应商绑住。
这条线不承诺让你赚到钱，只承诺一件事： 读完你手里这套东西是你自己的——能搬、能备份、能停、能换。