我如何不再监控Claude Code和Codex长达数小时的运行:规划、Git检查点以及代理外部的测试闸门
摘要
作者分享了在长时间、多步骤任务中运行Claude Code和Codex无需持续监控的技巧,使用外部测试闸门、每个任务的Git检查点以及基于DAG的计划,避免阻塞任务导致整个运行停滞,并将这些方法打包成一个开源工具。
我在一台隔离的机器上运行Claude Code和Codex来处理长时间、多步骤的任务,反复遇到同样几个问题:
* **谎报测试结果:** 代理报告任务完成,但测试实际上并未通过,并归咎于“已有的bug”。
* **压缩导致的健忘:** 上下文填满后,压缩导致代理忘记三步骤前所做之事,浪费token并造成后续bug。
* **单个任务阻塞导致整个运行停滞:** 我只是想让代理在我不干预的情况下运行,但又不想完全失去控制。针对每个问题,我的做法如下:
* **谎报测试结果:** 构建和测试命令在worker外部运行,因此它无法声称成功并跳过检查。失败时,它会回滚到Git检查点并携带失败上下文重试。
* **压缩导致的健忘:** 每个任务都在新的worker中运行,因此不会经历漫长的压缩周期。worker在需要时仍可检查先前的工作。
* **任务阻塞:** 计划是DAG,因此一个阻塞不会停止所有任务。它会继续处理非下游任务,并在Telegram中向我发送一个聚焦的问题。
* **保持控制:** Claude Code起草计划,Codex评审,我在运行前批准。每个任务前都有Git检查点,整个执行轨迹(计划、提示、标准输出/标准错误、尝试次数、检查点、经验教训)都保存在磁盘上。
我将这些打包成一个开源工具,如果有用我会在评论中发链接,但我更想知道社区里其他人是如何处理“代理无法正确评估自身工作”这个问题的。将测试闸门放在worker外部是唯一对我有效的方法。你们是怎么做的?
相似文章
我同时运行 Claude Code 和 Codex,却总是丢失它们之间的线索——于是构建了一个位于 S3 存储桶中的无服务器协调层
tracecraft 是一个 CLI 工具,使用兼容 S3 的存储桶作为多个编码代理(如 Claude Code 和 Codex)的无状态协调层,支持原子任务认领、邮箱、共享内存和跨工具框架会话镜像。
@ClaudeDevs: 如何确保 Claude 坚持工作直到任务完成?Claude Code 通过几种方式来实现这一点,其中包括我们最近推出的功能…
Anthropic 的 Claude Code 引入了 /goal 命令,以帮助 AI 代理持续运行并完成任务,直到工作完全结束。
@delba_oliveira: https://x.com/delba_oliveira/status/2062203743387459836
本文介绍了如何在Claude Code中设置反馈循环和自我验证工作流,使代理能够独立检查其工作,并减少对雄心勃勃任务的人工监督。
@Saboo_Shubham_: Codex 负责构建,Claude Code 负责审查与优化,Hermes 负责协调与交接。这一切……
演示了一个多智能体工作流:Codex 构建代码,Claude Code 进行审查,Hermes 管理协调工作,所有流程均通过看板(Kanban)进行跟踪。
@akshay_pachaar: https://x.com/akshay_pachaar/status/2054915602171723992
解释了Claude Code的/goal命令如何通过模型验证的退出条件实现自主多轮任务完成,在大规模重构或功能实现过程中显著减少手动输入'继续'提示的需求。