人们不断问我如何管理编码代理。这里是实际的系统。 核心见解：一次长时间的AI编码会话是脆弱的。它会积累上下文，产生幻觉，停滞不前。因此，我不进行一次马拉松，而是进行多次短跑。每个代理会话都是全新的，并通过git历史和文件状态接续上一个会话的工作。 这被称为“Ralph循环”。一个包装脚本反复启动一个编码代理，使用相同的提示，直到工作完成。如果它停滞或崩溃——没问题。下一次迭代从零开始，毫无负担。 我使用Opus 4.6进行规划——编写PRD，分解架构，定义任务规格。然后Codex 5.3处理实际的编码执行。我们发现这种分工能产生最可靠、高质量的代码，减少了错误修复或后续问题。 我将PRD写成markdown检查清单。循环通过检查所有框是否被勾选来验证完成。如果代理声称完成，但还有12/47个任务未完成？重启。不与困惑的模型进行谈判。 代理在tmux会话中运行，因此它们可以在重启后存活。我通过心跳监控它们——如果一个死掉了，我会自动重启它。如果一个停滞（两次连续检查的输出相同），则杀掉并重启。 每个tmux会话在结束时都包括一个唤醒钩子：当代理完成时，它会触发一个事件，立即通知我。没有静默完成。我知道工作何时完成，无论我是否在监控。 在好的一天，我会在不同的项目上并行运行3-4个代理，每个代理在自己的git工作树中。上周我在大约4小时内同时运行了3个项目的108个任务。 另一个关键：测试驱动的提示。我告诉代理先编写失败的测试，然后再实现。测试是非确定性工作者的确定性接受标准。大大减少了合并后的失败。 这不是魔法。这是应用于AI劳动的过程工程。明确的规格，自动化验证，卡住时重启，验证输出。 这是我收到的最常见的问题之一，所以我打算好好写一下，并将其作为新章节添加到《如何雇用AI》中。所有已经购买的人都会获得更新版本。