作为每天和AI代理打交道的工程师，你可能最头疼的不是写不出代码，而是那些“差不多能跑”的长任务。给代理一个复杂指令，它写了几百行代码后就停了；你再prompt继续，它又偏离方向；反复拉扯几轮后，上下文爆炸、token烧光，任务依然卡在中间。

OpenClaw创始人Peter Steinberger和Claude Code创始人Boris Cherny最近同时强调同一个观点：与其反复prompt代理写代码，不如构建能自我prompt的循环，让代理自己完成长时任务，并支持多代理并行推进。

PostHog技术内容负责人Ian Vanagas在最新文章中系统拆解了这个思路，并结合真实案例说明为什么现在这个转变突然变得可行。

起初我以为代理能力的提升主要靠模型变聪明、prompt写得更聪明。后来看到这些实践才发现，真正的生产力跃迁来自把“单次指令”变成“持续运行的闭环系统”。循环不是新瓶装旧酒，而是把产品工程师一直在手动做的发现-构建-验证-迭代流程，交给了代理自己执行。

这就像一个成熟的产品团队在做持续迭代：每周有明确的目标（OKR）、从数据和用户反馈中持续拉取上下文、用指标和用户测试进行自我评估，然后团队（或代理）据此行动并进入下一轮。区别在于，现在我们可以用代理把这个循环跑得更快、更便宜，且24小时不间断。

另一个贴切的工程类比是CI/CD流水线。过去我们手动构建、测试、上线；现在流水线自己拉取代码、运行测试、发现问题就阻断或自动修复。AI循环把这个思路从“代码层面”提升到了“任务与产品改进层面”。

构建有效循环必须具备的四个要素

一个没有目标的循环就是“slop炮”。目标必须具体、可衡量，让代理知道什么时候算完成、什么时候该停止。

上下文是燃料，却最容易匮乏。很多循环失败不是因为代理不会做，而是上下文喂得太早、太全，或者没有机制让代理在执行中主动拉取新信息（错误日志、最新指标、用户反馈）。好的做法是把上下文设计成可按需获取的，而不是一次性dump。

评估是循环和普通prompt的最大区别。过去工程师自己做验证，现在让代理自己检查：跑测试、用LLM-as-judge、对比快照、检查日志、甚至自己生成并执行验证用例。评估质量直接决定循环是越跑越准还是越跑越偏。

最后当然需要代理本身。可以是简单的while true循环（Claude Code里的Ralph模式或/goal命令），也可以是更复杂的编排系统：主循环根据信号触发子代理执行具体工作，子代理完成后把结构化结果汇报回来。

几个已经在生产中跑起来的真实循环案例

• PR保姆循环：目标是让PR通过所有测试并让CI变绿。上下文是diff + 测试套件。评估直接复用现有CI结果。
• Bug修复循环：目标是修复特定bug。上下文是bug报告 + 错误堆栈 + 相关代码。评估用测试套件、快照和日志。
• Flaky测试猎手：目标是消灭不稳定测试。上下文是CI历史和重试日志。评估是连续多次绿色运行。
• 性能自研循环（PostHog真实案例）：目标是 beating 某个基准。上下文是系统代码、性能指标和预算限制。评估是新版本是否在目标指标上更快更好。他们用Karpathy的autoresearcher循环，修复了一个存在3年的查询引擎bug，同时把性能提升了11%。

这些例子共同点是：任务有清晰的“完成定义”，评估可以客观进行，上下文可以逐步补充。

为什么现在突然流行起来？

模型能力已经能支撑长时任务。METR数据显示，Opus 4.6能完成50%需要12小时的任务，是去年同系列模型1小时40分钟任务量的6倍以上。

真实大任务的成功案例越来越多：Stripe用代理一天完成全代码库迁移（人工需两个月）；Lovable现在能一键生成以前需要几百次prompt才能做出的应用。

工具原生支持循环：Claude Code推出/loop命令，Codex有自动化，Ralph插件让while循环更简单。子代理机制把主循环和具体执行分离，节省token也避免上下文退化。上下文压缩（compaction）、Skills、MCP协议、云端执行等基础设施正在成熟，让循环可以真正“启动后走开”。

PostHog的观点更进一步：循环不是单纯为了多烧token，而是通往“自驱动产品”的路径。产品工程师本来就在手动完成这个循环——通过analytics和用户访谈收集数据、基于数据构建改进、评估效果、不断重复。现在代理可以把这个循环自动化，把工程师从“1%改进”（修bug、调UX、优化转化）的重复劳动中解放出来，专注更高价值的方向。

当然循环也有边界。它不会消灭所有工程工作，而是把那些需要战略判断之外的日常改进交给系统。设计循环时，评估机制必须足够健壮，否则容易奖励 hacking 或陷入局部最优。

一次性prompt vs 构建自循环的本质差异

循环工程的实践起点

想落地第一个循环，先从一个有明确目标和客观评估标准的小任务开始。比如“把所有 failing test 修复到绿色”或“把某个核心查询的P99延迟降低10%”。

把评估设计成结构化、可自动运行的形式，是最关键也最容易被低估的一步。上下文则要避免全量喂养，优先让代理自己决定什么时候需要拉取什么信息。

PostHog正在把他们帮助产品工程师手动完成循环的经验，转化为帮助代理完成循环的能力（Slack集成、Code功能、Replay Vision等）。这也是为什么他们对loops如此看好。

循环的核心不在于代理多聪明，而在于我们是否愿意把“验证”和“迭代”这两个最耗时的环节交给系统自己完成。代码从来不是瓶颈，方向感、品味和对用户的共情能力，依然是人类在循环时代最不可替代的部分。

在你当前的产品或代码库里，哪类重复性工作最适合先套上一个自循环？是bug修复、性能调优、还是测试稳定性治理？不妨先定义一个清晰的目标和评估方式，跑通最小闭环再说。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。