我给自动化服务器运维划的几条边界

这篇最初记录我给个人服务器自动化划的几条边界。后来经历 DNS 漂移、权限修复、正式应用和密钥配置，我更在意另一个问题：Agent 停下来问人的时候，到底缺的是事实、判断，还是授权？如果这三种情况不分开，确认按钮既可能打断小事，也可能掩盖真正的风险。

已授权的执行，应该尽量做完

我希望 Codex 接手检查现状、修改仓库、预览差异、部署验证和记录。页面与文档的小范围调整、已有约定内的可逆修复，不需要我每一步说继续。它应先研究能自行取得的信息，把可审查结果做出来，到了确实需要人的地方再停。

但“可以回滚代码”不等于后果可逆。静态页面通常可以从 Git 恢复，已经发出的通知、删除的数据或失效的访问则可能无法靠撤回补丁挽回。判断是否可以自主推进，要看现实影响和恢复能力，而不是只看修改了多少行。

真实 DNS 切换一直属于我的人工边界。发生权威记录缺失时，Agent 可以调查解析链、确认源站和证书、准备推荐记录，也可以说明缓存为什么暂时掩盖问题。可是否恢复旧目标、该目标是否还有业务、什么时候切换，需要域名所有者决定。

人确认并报告修改以后，工作还没有自动结束。权威与递归查询、公网 HTTPS 和页面访问仍要复验。人工批准只解决了是否允许行动，不能替代行动实际生效的观察；技术成功也不能倒过来制造原本缺失的授权。

JiaJi 微信会话启用时，缺口不是再改一句提示词，而是明确的私有配置。先核对需要哪些变量、现有服务会受到什么影响、怎样备份和恢复，再由所有者授权使用已有凭据。实际配置通过私有通道写入，不把值放进 Git、公开文章或普通日志。

这次授权有具体对象和用途，不代表以后所有密钥操作都已获准。配置存在性可以用布尔结果或变量名称说明，通常无需展示值。另一方面，已有授权清楚时，也不该因为出现 Secret 这个词，就反复要求用户批准同一动作。

这里还留着一个恢复缺口：本机和服务器之外的安全备份位置没有确认。不能因为某次配置启用成功，就宣称凭据已经有独立灾难恢复保障。

Docker 的一次权限缺口，最终通过给预期账户声明附加组并在新会话验证来修复。调查证据支持这项具体改变，没必要顺势开放 socket 或调整 SSH 认证。给一个账户管理 Docker 的能力也有真实影响，需要放在已经约定的运维权限里理解。

删除持久数据、修改可能断联的防火墙规则、重启主机或明显增加资源成本，仍需要明确的风险决定。若已有低影响止损措施获准，可以先执行；不应为了补完一套报告耽误恢复，也不能把止损成功写成根因已经确认。

与其问“是否继续”，Agent 应把决定做成一份足够短的材料：现在观察到什么，还不知道什么，真正需要人决定哪一点，推荐怎样做，会影响谁，失败后如何恢复，以及继续和暂缓分别有什么代价。没有必要为了形式堆一份长文档。

比如 DNS 问题，先把预期记录、源站证据和缓存现象查清楚，再请求所有者决定目标；而不是只抛出一句“需要管理员处理”。如果还有方向无关、可逆的准备可以做，也应继续完成，让人的决定发生在具体结果上。

人的主观判断也属于这类边界。产品是否贴近自己的表达、某个体验是否值得保留，无法由部署检查代答。但 Agent 应先给出可使用的候选，不把内部方案搜索或每一次小修都交给用户管理。

当前边界来自我的单机个人项目，没有证明它适合所有组织。授权是否仍有效、影响是否扩大、恢复是否经过验证，都可能改变下一次选择。对可逆动作保持连续推进，对真正缺失的意图与风险承诺及时交回人，是我目前愿意采用的方式。

它还需要更多真实使用检验。Mission 驱动让我不用安排每一个小步骤；人工边界则让这种连续推进有明确的适用范围。两者都应减少无意义的打断，同时保留人对关键后果的控制。