AI 编码任务失败后，怎么还原当时的代码？AgentTM 用检查点追踪 Codex 工作区
AI 编码助手的会话记录通常能告诉你它执行了哪些命令，却未必能直接回答另一个更实际的问题：执行到某一步时，仓库里的文件究竟是什么状态？如果 Agent 连续修改多个文件，最后测试失败，开发者需要自己翻 diff、找备份，才能辨认哪次变化引入了问题。Go 工具 AgentTM 尝试把可观察的 Codex CLI 事件和工作区检查点放在同一条时间线上，方便检查历史文件、比较变更，并在独立 worktree 中取出旧状态。
先把定位说清楚：AgentTM 不是确定性回放器，也不是能读取模型内部思维的调试器。它记录的是 Codex CLI 可提供的结构化事件和文件系统观察；检查点表示扫描时看到的工作区状态，不证明某次变化一定由紧邻的工具调用造成。这个边界很重要——它适合缩短排查路径，不应被当作完整、原子化的执行取证系统。
它记录什么，怎样查看
AgentTM 的 README 将当前版本描述为本地 Go CLI，针对由 AgentTM 启动的非交互式 Codex 运行。一次运行会先记录基线，结束后再扫描最终状态；启用 --snapshot-after-tool=true 后，对支持的命令或文件变更事件也会做尽力而为的中间扫描。Codex 不会为这些扫描暂停，因此检查点的含义是“事件附近观察到的状态”，而非严格的逐工具因果快照。
历史数据存放在仓库的 .agenttm/ 目录：SQLite 索引事件与检查点，内容以 SHA-256 对象和版本化清单保存。CLI 可查看会话、事件、检查点、文件内容和差异；本地 UI 在回环地址提供只读历史界面。项目文档还说明，捕获不会替你执行 Git 提交、重置或切换分支。建议把它先用于个人实验仓库或临时分支，理解数据留存与权限范围后再纳入团队流程。
在临时仓库试跑
README 的快速体验流程要求被记录的项目是 Git 工作树；不需要先提交代码。AgentTM 本身可从已构建的可执行文件运行，具体安装包和系统要求应以项目发布材料为准。进入一个可丢弃的仓库后，可以按文档展示的命令初始化并启动 Codex：
git init agenttm init agenttm run codex --model '<可用模型>' -- "为这个临时仓库写一个简短的问候说明，不要修改其他文件。" agenttm sessions
其中 --model 是可选的显式模型选择；占位值必须换成当前 Codex 账户可用的模型。AgentTM 通过 Codex 的非交互执行模式运行任务，现有 Codex 登录、沙箱和审批策略仍然适用。不要为了让示例“跑通”而关闭安全限制；若请求受策略阻止，应把它视为一次失败或受限的运行，而不是工具记录损坏。
获取会话 ID 后，可继续查看其事件与检查点：
agenttm events '<session-id>' agenttm checkpoints '<session-id>' agenttm ui
若发现某个检查点值得保留，可用 agenttm fork ' 将它恢复到单独的工作区。项目 README 特别强调，fork 不会覆盖原工作树；但恢复出来的代码仍需由开发者审阅，尤其要确认目标路径、分支和是否为部分快照，再运行任何程序。历史快照是文件状态，不包含数据库、网络服务或全部外部环境，不能据此认为项目可完整复现。
适合什么场景，不适合什么场景
它适合这些低风险任务：复盘一次 Codex 批量编辑、比较任务前后的文件、在不动当前工作区的前提下查看旧版本，以及观察任务失败或取消后仓库留下了什么。团队还应明确 .agenttm/ 的忽略、备份与清理策略；仓库快照可能含业务源码，不能因为数据在本地就默认可以随意共享。
反过来，如果你的要求是精确重放每个工具调用、证明某个事件导致某个文件变化、恢复完整开发环境，或自动捕获所有交互式 Agent 会话，当前版本并没有承诺这些能力。README 将 Claude Code 适配、云同步和确定性回放等列为范围之外的事项。最稳妥的评估方式，是在临时仓库里跑一次成功任务、一次失败任务和一次取消任务，检查事件、检查点与 fork 的实际行为，再判断它是否补上了团队现有调试流程的缺口。
相关链接