sligter/codex-autoloop

Codex AutoLoop

把长时间开发任务跑成一种：可恢复、可审计、有护栏、该停就停 的工作流。

什么时候用

遇到下面这类请求时启用：

• “持续开发 / 自动循环 / 后台跑”
• “不要停，做完再汇报”
• “我去睡觉，你继续干”
• “按 CSV 任务单推进”
• “按 plan.md 一路做下去”
• “让 Codex / Claude Code 长时间自己迭代”
• “牛马模式”

如果只是一个很小、几分钟能完成的任务，不要硬套 AutoLoop，直接正常做更合适。

核心原则

主循环很简单：

1. 先读清当前上下文
2. 选一个边界明确的小任务 / 单个假设
3. 做一次可解释的原子改动
4. 用机械验证判断结果
5. 通过则保留，不通过则回退
6. 写入状态和结果
7. 继续，直到触发停止条件

把 git 和 state file 当作记忆，把 verify 当作护栏，不要把 verify 当成“真相本身”。

两种工作模式

模式 A：单目标循环

适合目标很明确、指标也明确的任务，例如：

• 降低某个目录里的 any
• 把某组测试修到全绿
• 持续优化某个 benchmark
• 提升某块功能的覆盖率

模式 B：CSV / plan 驱动交付

适合一串 backlog 任务，已经有：

• 优先级
• 依赖关系
• 验收标准
• verify 命令
• 修改范围

需要时按需读取：

• references/csv-template.md：任务表怎么写
• references/plan-template.md：plan 怎么写成机器可执行合同

启动前检查

没满足下面这些条件，不要启动长循环：

• 仓库已经在 git 下
• baseline verify 命令已手工跑通过一次
• 允许修改的路径是明确的
• 永远不能碰的路径是明确的
• state / results 文件不会被误提交
• 用户明确表达了要“自主推进 / 后台执行 / 长时间跑”

停止条件

默认继续做，但遇到以下情况必须停下来并汇报：

1. Gate 失败：全量 gate / review gate 挂了
2. 需求歧义：出现多个合理产品选择，但 plan/任务里没写判定规则
3. 危险动作：删库、迁移、凭证处理、线上副作用、外部写操作
4. 验证漂移：verify 已经不能真实代表“任务完成”
5. 连续失败：多轮 discard / crash 后仍无新假设
6. 越界修改：要改的内容超出了 scope
7. 人工检查点：用户明确说了先给他看

不要迷信“永不打扰”。正确原则是：

默认自治推进，但在风险、歧义、越界时立即升级。

单轮执行协议

每一轮都这样做：

1. 重读相关 in-scope 文件、最近结果、最近 git 历史
2. 只选一个任务或一个原子假设
3. 做最小可验证改动
4. 跑该任务对应的 verify 命令
5. 通过：保留改动并记录结果
6. 失败：干净回退并记录失败原因
7. 检查是否触发 stop condition
8. 继续下一轮

重实验、重试错的任务，优先放到临时分支 / 独立工作区，不要把主分支搞成实验垃圾场。

verify 设计要求

好的 verify 命令应当满足：

• 机械化：尽量不依赖主观判断
• 够快：适合反复执行
• 不易作弊：不容易被“刷指标”骗过
• 贴近验收：尽量接近真实完成标准
• 可无人值守： unattended 跑也安全

当你要设计或修 verify 时，读：

• references/verify-scripts.md

git / 回退原则

git 是记忆，不是万能保险丝。

优先考虑这些方式，而不是粗暴历史重写：

• scratch branch
• worktree
• 可逆提交序列
• scoped revert

不要因为两个任务 glob 看起来不重叠，就轻易并行。共享类型、配置、构建流程、测试快照时，照样会互相踩。

OpenClaw / Codex 实战建议

在支持 session / 子代理 / ACP harness 的环境里：

• 小任务：当前会话直接做
• 长任务：丢到隔离 session 持续跑
• 明确要求 Codex / Claude Code / Gemini 风格执行：用对应 harness / 持久线程
• 不要高频轮询进度，靠 checkpoint 和完成回传
• 优先从 state 恢复，不要每次中断后重新规划

按需读取：

• references/openclaw-execution.md：OpenClaw / managed session 的推荐姿势
• references/python-launcher.md：本地 DIY launcher 参考

推荐读取顺序

只想先跑起来

1. 本文件
2. references/openclaw-execution.md
3. references/verify-scripts.md

想按任务单批量推进

1. 本文件
2. references/csv-template.md
3. references/plan-template.md
4. references/openclaw-execution.md

想自己改 launcher

1. 本文件
2. references/python-launcher.md
3. references/verify-scripts.md

最后记住

目标不是“永远跑下去”。

目标是：

• 尽量少 babysit
• 过程可追踪
• 出问题能恢复
• 该停时停
• 最终结果真的能交付

Autonomous by default. Interruptible by design.