我们为什么看好循环

当 OpenClaw 和 Claude Code 的创造者都开口时，人们会认真听。最近，Peter Steinberger 和 Boris Cherny 都在谈论同一个概念：循环。

他们的观点是什么？你不应该提示（prompt）智能体写代码，而应该构建能自我提示写代码的循环，这样智能体就能完成长时间运行的任务，并且你可以同时使用多个智能体，走得更远、更快。

设计一个循环需要什么？

你需要四样东西：

1. 目标

智能体有能力，但你需要界定循环的范围，让它们知道你要达成什么。没有目标的循环就是一台无差别输出的“垃圾炮”。

2. 上下文

上下文是燃料，而循环常常缺乏它。上下文可以包括工具、技能、分析数据、错误、记忆——任何能帮助智能体找到工作并完成循环的信息。最好是策划性地提供上下文，并贯穿始终，而不是一开始就全部倾倒。智能体需要能够获取并响应新的输入。

3. 评估

这是智能体自我检查的方式。测试、评估、指标、LLM作为裁判、实验场。测试驱动开发又回来了，也许它从未离开？这是循环与提示之间的一大区别：由智能体而非工程师来完成验证。

4. 一个智能体（显然）

最基础的方式是使用类似 Claude Code 的东西，搭配 while true（也就是 Ralph）或使用 /goal。更复杂的是特制的框架和上下文系统——例如，一个基于 cron 的智能体，从你的产品数据中拉取信号，并向子智能体下发工作；或者一个能自动生成测试套件来验证自身的循环。

好的循环例子包括：

• PR 保姆。 目标是让一个拉取请求通过测试并“让 CI 变绿”。上下文是变更（diff）以及测试套件，评估由 CI 完成。

• Bug 修复器。 目标是修复 bug。上下文是 bug 报告和错误追踪。评估是测试套件、快照、日志。

• 不稳定测试猎手。 目标是消灭不稳定的测试。上下文是 CI 历史和重试日志。评估是连续通过的运行次数。

• 性能自动研究员。 目标是超越某个基准。上下文是系统、指标和预算。评估是是否在相应指标上更快、更好等。我们最近使用了 Karpathy 的自动研究员循环，它修复了我们查询引擎中一个存在 3 年的 bug，并将性能提升了 11%。

为什么现在每个人都在谈论循环？

因为这东西管用。没错，是 Peter 和 Boris 点燃了火，但他们这么做是因为这是真实存在的。真正的“为什么是现在”源于新的和改进的能力：

• 模型在处理长时间任务上更好了。 METR 发现 Opus 4.6 能完成 50% 需要 12 小时才能完成的任务，是一年前 Opus 4 的 1 小时 40 分钟能力的 6 倍以上。Fable（RIP）甚至将这个极限推得更远。

• 完成了巨大任务的故事。 Stripe 在一天内完成了一次全代码库迁移，靠人工需要团队两个月。Lovable 发现它现在可以一次生成一个应用，而之前需要用成百上千次提示来构建。

• 循环现在内置了。 Claude Code 推出了 /loop 命令，它和 Codex 都有自动化功能，甚至还有一个用于 Claude Code 的 Ralph 插件。

• 子智能体将循环与工作分离。 主循环可以启动执行工作并回报的子智能体，从而节省 token 并防止性能下降。

• 框架在成熟。 压缩（compaction）防止上下文窗口被填满。技能和 MCP 让智能体能使用更多工具。云端执行让你可以启动一个循环然后离开。

循环并不是因为几条推文就凭空出现的。它们是整个行业真实进步的体现。

循环不仅仅是 AI 的新花样

批评者把循环诋毁为 OpenAI 和 Anthropic 的计谋，想让所有人都“tokenmaxxing”，但我们认为这有更高的目标：自动驾驶产品。

与其让工程师提示智能体来推进项目，不如让智能体自我提示。产品在无需输入的情况下自我改进。用户问题得到更快解决，是的，数字也会上升。

事实是，产品工程师已经通过以下方式手动完成了这个循环：

• 通过分析工具和与用户交流收集数据
• 基于这些数据构建并发布产品改进
• 评估该改进的效果以指导后续开发
• 不断重复

PostHog 多年来一直帮助产品工程师完成这个循环，因此我们认为我们也能很好地帮助智能体做到这一点。这也是我们押注于构建能让你的产品实现自动驾驶的功能的原因，比如我们的 Slack 应用、PostHog Code 和 Replay Vision。是的，我们有点“AI 上瘾”。

当然，也存在限制。循环并不会消灭所有工程工作，但它们可以让那些 1% 的改进自动巡航：bug、UX 问题、小麻烦、转化率调优。这些都是消耗工程时数、但很少需要战略投入的事情。

你越是能自动化这些任务，就越能腾出时间去做更有影响力、也更（坦白说）有趣的工作。“自我”驾驶中的“自我”并不意味着脱离工程师，而是脱离用户指令作为起点。

代码从来不是问题

对循环的反对很容易理解：这是构建软件方式的又一次转变。被告知应该“设计循环”让工程师觉得自己正在被取代。工作越来越远离编写代码本身。

但产品工程师的崛起已经表明，编写代码只是工作的一小部分。在循环驱动的未来中，产品工程师的方向感、审美和同理心对于构建成功产品仍然至关重要。

作者：@IanVanagas，PostHog 技术内容营销专家。