当现有系统已经有任务卡、Goal、事件唤醒、持久 inbox、权限与租约边界时，再安装一套“让 Agent 不停工作”的循环框架，未必能增加可靠性。真正值得问的是：它补上了哪个已复现缺口，又增加了哪些状态和权限面？

这次对 Ralph、LazyCodex ULW 和 Superpowers 做了来源审计、机制映射与隔离验证。结论不是选择一个框架全量安装，而是只保留一个很窄的候选：可选的本地完成证据指针检查。该隔离候选已通过独立差异审核，但没有安装到正式工作流。

结论先行

候选 决定 原因
Ralph Stop hook 不接入 主要能力是退出时重放同一提示，和既有续推机制重叠；难以表达长等待、人工硬停、权限差额和生产动作预算
ULW 整套 harness 不安装 evidence/checkpoint 思路有价值，但整套接入会增加第二份状态、hook 和角色边界
Superpowers 全流程 不接入运维控制面 调试与完成前验证纪律值得借鉴；worktree、细粒度计划、逐任务 review 流水线更适合代码开发
本地证据指针检查 隔离审核通过，保留为未安装窄候选 能补上“声明完成但本地证据路径缺失或越界”的结构检查，不引入运行时服务

现有多会话续推、回执和修复预算的背景见 《Codex 多会话自动推进：角色分流、回执续跑与有界修复》。

三种方案分别解决什么

Ralph：同一目标反复执行

Anthropic 的 Ralph Wiggum 插件使用 Stop hook：若没有命中精确 completion promise，就把同一提示再次交给会话。它适合验收条件清晰、可自动验证、允许多轮迭代的任务；对人工判断、一次性动作、模糊验收和生产排障并不合适。

这里的问题不是“循环不够强”，而是状态表达不足。实际运维至少需要区分继续、等待外部事件、需要人工输入和阶段完成。单一 promise 加迭代上限不能替代这些状态，更不能替代权限与资源租约。

参考：Ralph README。该仓库的许可不是通用开源许可证，因此也不应直接复制实现代码。

ULW：证据、checkpoint 与 reviewer

LazyCodex ULW 的有用部分是 evidence gate 和 checkpoint：任务不是因为模型说“完成”就完成；上下文压缩或恢复时，也应保留目标、当前阶段、已通过证据和下一步。

但现有工作流已经有任务卡、Goal、持久 inbox、reviewer 和 broker。全量安装 ULW 会产生两套状态与生命周期。更合适的策略是迁移小机制，而不是迁移整套控制面。

公开 issue 还展示过 Stop-resume 状态路径穿越、外部 blocker 重试和父计划注入子任务导致重复工作的风险。它们不代表当前版本必然存在同一缺陷，但说明 hook 与持久状态本身就是需要审计的新边界。

参考：ULW 文档。

Superpowers：工程纪律，不是持久执行器

Superpowers 把设计确认、计划、系统化调试、TDD、subagent 执行、review 和分支收口组织成技能流程。这些做法对软件开发很有价值，尤其是先定位根因、用最小实验验证单一假设，以及完成前重新运行验证。

但它不是资源租约或权限 broker，也不是通用的崩溃恢复系统。把整套开发流水线强制套到运维、文档或一次性诊断任务上，会增加不必要的 worktree、review 和上下文成本。

参考：Superpowers README。

隔离验证纠正了两个误区

第一轮纯合成比较曾为不同机制预设轮数、重复动作和相对 token_units。这些数字只能解释模拟器如何编码机制，不是运行真实产品或 Agent 后测得的收益。因此不能用它们声称完成率、人工干预或 token 成本改善。

后续改成真实 CLI A/B，才复现了一个具体缺口：当前状态命令会投影任务卡里声明的 PHASE_COMPLETE，但不会核对证据指针是否真的指向允许范围内的普通文件。这不是状态命令“误判整个任务完成”，而是它本来就只是声明性投影，没有执行可选的结构检查。

最初候选还包含一个 recovery-summary，把现有字段映射成“继续、等待、交接”等动作。相同场景下它没有提供新的恢复语义，因此从候选中删除。早期测试中的 duplicate-action=0 也只是动作标签推导，没有真实重投事务，不能声称验证了 exactly-once。

窄候选究竟检查什么

候选命令只接受显式证据根，并检查：

  1. continuation 状态是否声明为阶段完成；

  2. 证据指针是否在允许根内解析为普通文件；

  3. 路径解析后是否通过 symlink 越界；

  4. 当前状态是否其实是等待或人工硬停。

它不读取或执行证据正文，不改变任务卡，不批准动作，也不自动关闭任务。输出进一步区分：

  • check_passed 只是结构检查结果；

  • proves 仅在检查通过时列出已确认的结构事实，失败时为空；

  • does_not_prove 始终提醒它不能证明正文正确、安全验收通过或业务已经完成。

receipt、HTTP/HTTPS、MCP 或其它非文件 URI 明确返回 not-applicable。这不是失败回退，也不尝试顺手做一个通用证据解析器。

隔离验证覆盖存在文件、缺失文件、越界路径、symlink 越界、receipt、URI、长等待和人工硬停，8 个场景均符合预期；专项测试和全量隔离回归通过，任务卡没有被修改。独立审核曾发现失败结果仍无条件输出 proves，候选随后改为失败时空数组并补了断言。

可以证明什么，仍然不知道什么

目前可以证明的是确定性 CLI 行为：本地文件型指针检查有明确边界，失败时不会把等待、硬停、越界或不适用类型包装成通过。

仍然不知道的是：真实 Agent 是否会因此减少错误收口、人工介入、上下文消耗或 token 成本。没有做模型/API/session A/B，也没有安装全局 skill 或 hook。任何“更自主”“更省 token”或“完成率提升”的结论都还没有证据。

如果后续采用，保持最小

下一阶段若获准，只应把该命令作为 task-tracker 的可选只读检查，限定在单一 workspace 的本地普通文件证据；由 Controller 或人工按需调用，不自动接入 hook，不根据结果自动关闭任务，不扩展 receipt/URI，也不连带安装 Ralph、ULW 或 Superpowers。

回滚也应保持简单：删除可选命令和对应测试即可，既有任务卡、inbox 与租约 registry 继续作为事实源。隔离候选的独立差异审核已经通过；这只支持本轮调研收口，不等于批准正式采用或全局安装。