别把 Git 当成 Agent 的安全网：revertly 如何为本地编码会话准备可审计的撤销层
让 Claude Code、Codex 一类编码 Agent 直接操作真实项目，效率往往来自它们拥有和开发者相同的权限：能改代码、运行脚本、读配置、删除生成文件。风险也在同一处。一次错误的“清理”、不可信文档中的提示注入，或一个后来变更行为的 MCP 工具，都可能在提交之前触及未跟踪文件、.gitignore 中的配置，甚至用户目录里的敏感路径。
Git 当然仍然必要，但它不是这类会话的完整回退机制。Git 记录的是你选择暂存并提交的版本；它不会自动为每次 Agent 会话保存工作区前像，也不会在 Agent 读取 .env、修改 shell 配置或执行危险命令时提醒你。近期发布的开源项目 revertly 选择的不是再做一个沙箱，而是在本地为 Agent 会话增加一层“先记录、再检查、可撤销”的恢复与审计层。它采用 MIT 许可证，当前定位为 macOS/APFS 的完整支持；Linux 处于实验支持状态。
这篇文章不把它当作安全边界，而把它放进更现实的开发流程：在允许 Agent 使用真实环境的前提下，尽早准备证据与撤销路径。
先分清：恢复层不是隔离层
revertly 的关键设计是会话开始前先布置恢复材料，而不是试图限制模型能做什么。项目文档将其划为四个对象：会话、工作区的预像副本、追加式日志，以及敏感路径的 tripwire（触发器）。对于 macOS/APFS，它会在启动阶段建立 copy-on-write 克隆，并可使用 APFS 卷快照；随后，文件创建、修改、删除和重命名进入带哈希链的 journal。这样，diff、find、verify 与 revert 面对的是同一批会话证据，而不是临时从 Git 状态猜测发生了什么。
这和容器/沙箱解决的问题不同。隔离层试图缩小 Agent 的能力边界；revertly 明确让绑定后的 CLI Agent 仍按原权限运行，目标是使不当行为更可见、项目内改动更容易恢复。两者可以叠加，但不能互相替代：想约束网络、凭据或系统调用，仍应使用最小权限、独立账号、容器或操作系统策略；想在真实工作区中快速找回一次会话的改动，恢复层才是直接工具。
尤其要注意项目自己写明的边界：它和 Agent 同一用户身份运行，不能阻止有意绕过 shim 的进程；用户空间的守卫也不等价于内核级控制。因此，“检测到”“可回退”不能被写成“绝对阻断”。生产环境仍应保留备份、代码评审和凭据轮换流程。
安装后先做健康检查，再绑定 Agent
官方 README 给出的基础安装方式如下。安装脚本会检测 PATH 中的 Agent CLI，并让用户选择要绑定的命令；doctor 用来检查 shim 顺序、快照和存储状态。
git clone https://github.com/nirbenda/revertly cd revertly ./install.sh revertly doctor revertly agents revertly bind codex revertly unbind aider
这一步适合放在个人开发机或专用 Agent 工作站，而不是未经评估地塞进所有 CI runner。原因很简单：它需要维护本地会话存储，预像会随着真实改动逐步占用空间。先运行 revertly doctor，确认文件系统能力、存储位置与 PATH 优先级，再决定哪些 CLI 需要被包装。文档还提供 revertly status 用于查看当前保护状态、磁盘用量和近期会话。
若团队通过 Claude Code、Codex、Gemini、Aider 或 Cursor CLI 运行任务，建议只绑定实际会执行写操作的 CLI，并将 GUI IDE 与 CLI 的能力边界写进团队约定。README 说明 GUI/IDE Agent 目前不能像命令行程序一样被 shim 包装；不要因安装了该工具就假设所有编辑都被记录。
把“先看再改”变成一个短循环
最有价值的使用方式不是等灾难发生才想起工具，而是把检查和撤销接到每次高风险任务之后。以下命令均来自项目的 CLI 参考：
claude "重构解析器，并运行相关测试" revertly last revertly diff revertly revert --dry-run revertly revert
这个流程的重点是 --dry-run。Agent 完成任务不代表整次会话都应被接受：你可能想保留测试修复，却不接受它对配置文件的顺手调整。此时可先用 revertly find 找某个路径在什么会话被修改，再用 revertly versions 查看可恢复版本。项目文档还列出 revertly revert ，用于把撤销范围缩到一个文件或路径，而不是一键回滚所有工作。
对开发者而言，这比“提交前看一眼 diff”多了一层含义：它不依赖文件已被 Git 跟踪，也不要求你事先建立一个手工 stash。代价是必须为会话保留本地恢复数据，并且仍要在关键变更进入主分支前执行测试、审查和常规 Git 提交。
用一次受控演练校验恢复链路
不要把这类工具只安装在事故发生之后。更可靠的做法是在一个可丢弃的测试仓库里完成一次受控演练：新建普通文本和一个被 .gitignore 忽略的本地配置，让已绑定的 Agent 修改前者、删除后者；随后用 revertly last 与 revertly diff 确认两类文件都出现在会话记录中，再执行 dry-run，最后再真正回退。演练的目的不是测试 Agent 能否写出正确代码，而是核实团队最需要的几个事实：预像是否在任务开始前创建、恢复范围是否符合预期、日志存放位置是否受访问控制，以及回退后测试命令能否回到原有结果。
在正式仓库中，也应为不同风险等级设置不同的操作节奏。比如小型文案或单元测试修改，可以在会话结束后查看 last 和普通 Git diff；跨目录重构、依赖升级、数据迁移脚本则更适合先拆成短会话，每一步都保留一个可检查的恢复点。这样即使某一步需要撤销，也不会把此前已人工确认的改动一并抹掉。revertly 的“按 session、按路径预览回退”能力在这里才有实际价值：它帮助缩小恢复半径，但不替代变更拆分本身。
还有一个容易忽视的细节：恢复与审计记录可能包含原工作区的敏感内容。项目 README 说明默认存储目录在 ~/.revertly，并强调存储根目录的权限保护；但团队仍要把它视作本地敏感数据，而不是可随意同步到公共云盘的缓存。若要收集故障证据，应先审查日志和预像中是否包含令牌、客户数据或私有代码，再按既有事件流程导出。
审计信号应该触发处置，而非替代处置
revertly 文档描述了对 .env、~/.ssh、shell rc 文件、LaunchAgents 等敏感位置的实时告警，也提供 revertly verify --all 用于检查日志哈希链。它还可通过配置将 command guard 设为 block；默认模式是 alert。这些信号适合成为团队处置流程的入口：暂停任务、检查会话差异、判断是否有密钥暴露、必要时轮换凭据，而不是把一次桌面通知当作事件已经关闭。
例如，若一次 Agent 任务出现异常读取或可疑命令，先保留本地证据，再执行以下只读检查：
revertly last revertly diff revertly log --tripwires revertly verify --all
然后再决定是否 revertly revert --dry-run、撤销项目内改动，或进行更高层的系统恢复。要特别区分范围：README 说明项目目录外的文件可以被告警，但不会由项目内的 revert 自动内容恢复；APFS 快照属于另一条人工恢复路径。也就是说，~/.zshrc 或用户目录中的影响，不能因为项目代码已回退就视为消失。
存储策略决定它能否长期可用
预像和日志不是免费的。copy-on-write 在刚创建时可节省块复制，但当文件被覆盖或删除，实际占用会增长。官方提供 revertly clear --keep 7d、revertly gc 和 revertly status 等命令管理保留期。清理恰恰是不可逆的操作，因此应将保留期限与项目风险配套：日常实验可保留较短窗口；涉及迁移、批量重构或凭据配置的会话，至少等到代码合并和问题观察期结束后再清理。
revertly status revertly clear --keep 7d
更成熟的组合是：Git 管理被认可的代码历史，系统备份承担设备级灾难恢复，最小权限和隔离降低 Agent 的可达范围，revertly 为“提交之间的真实会话”提供局部证据与撤销能力。它不承诺让 Agent 无法犯错，却能让一次错误更早被发现、更少依赖记忆，也更容易在工作区层面收拾干净。
相关链接