# You Need More Than a Ralph Loop
**作者**: Jarrod Watts
**日期**: 2026-04-30T18:24:40.000Z
**来源**: [https://x.com/jarrodwatts/status/2052372045829382430](https://x.com/jarrodwatts/status/2052372045829382430)
---
Over the last few months, I've been experimenting with long running-agents on various side quests, including beating Anthropic's hiring challenge.
I came to learn that the reason "long-running agents" work is quite literally because they spend more tokens... or, if you're a researcher - they "scale test-time compute".
This might sound stupid, but it actually works - for example, on the BrowseComp benchmark, Sonnet 4.6 spending 10x more tokens resulted in ~10 percentage points higher scores:
Page 45 - https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf
However, this starts to break down when your task requires much more context than the agent's context window can handle...
To solve this problem, earlier this year we saw the creation of things like the ralph wiggum loop, which in it's original form is just running the same prompt in a loop.
Last week, the Codex team shipped goals - a built-in system for long-running agents that can run for days to achieve your desired goal.
> **Felipe Coury @fcoury**: [原文链接](https://x.com/fcoury/status/2049917871799636201)
>
> /goal also lands in Codex CLI 0.128.0.
> Our take on the Ralph loop: keep a goal alive across turns. Don't stop until it's achieved.
> Built by my co-worker and OpenAI mentor Eric Traut, aka the Pyright guy. One of the GOATs I get to work with daily.
I was super excited about this, but was pretty disappointed with the results I ended up having with it, despite my love for GPT 5.5!
Since Codex is fully open-source, we're able to see exactly how it works under the hood - I did exactly that, and here's what I learned, and why I I think my own long-running agent workflow is better.
## How Codex Goals Work
If you haven't tried it already, goal tries to one-shot your more ambitious tasks by running for hours or even days at a time by running "/goal <your goal>" into the Codex CLI.
Under the hood, the goals feature uses a simple SQLite setup - Codex creates a "thread_goals" table to store every new goal you create as a row; each of which contain the goal's objective, id, status, and an optional token budget.
When Codex starts building to achieve your goal, it makes use of new tools including "get_goal and "update_goal" to account for progress and update the status of the goal in the database.
After this, Codex uses a pretty standard ralph loop (prompting the same thing repeatedly) using the following prompt:
```
Continue working toward the active thread goal.
<untrusted_objective>
Ship the benchmark article with real Goal-mode evidence.
</untrusted_objective>
Budget:
- Time spent pursuing goal: XX seconds
- Tokens used: XX
- Token budget: XX
- Tokens remaining: XX
Before deciding that the goal is achieved, perform a completion audit against the actual current state.
```
This solves the annoying problem of Codex stopping after 15 minutes to ask you if it's okay to keep going 🥺👉👈, but I don't think it's an effective way to have agents run for long periods of time.
## What I think /goal is missing
I absolutely love the idea of long-running agents, it's the closest thing we have to realistically achieving our goal of having agents actually "build a 1M MRR B2B SaaS, make no mistakes".
But, the experience I've had so far using Codex's /goal feature has been pretty disappointing - and has the same flaws I found after building many of my own failed long-running agent workflows.
I feel this way for three main reasons:
1. Ambiguity compounds
2. Multi-agent mogging
3. Cross-context memory works
I learnt these lessons over the past few months, and below, I'll share the details along with a workflow I've arrived at that I actually like.
## Ambiguity Compounds
Running an LLM in a loop means each iteration's output becomes the next iteration's input - and this has a compounding effect on each subsequent iteration.
The model makes countless decisions when you ask it to build something from start to finish, and at some point - it usually makes a decision that you wouldn't have - and every piece of work after that may be directionally off.
This is not unlike real life - if you ask somebody else to build something with vague requirements, you're probably not going to get what you envisioned when there's no opportunity for back and forth.
Since AI does not seem to have taste yet, it is very difficult to avoid this from happening - unless you're writing extremely detailed prompts to remove as much room for error as possible.
In my own long running agent strategy, I use a variation of this "/interview" skill to lower ambiguity as much as possible, which is very similar to Matt Pocock's "grill-me" skill.
> **Jarrod Watts@jarrodwatts**: [原文链接](https://x.com/jarrodwatts/status/2006138974834716993)
>
> I built a custom Claude Code command, /interview, to create bulletproof specs.
> • Create a plan using plan mode
> • Run the /interview command
> • Claude asks 20-50 clarifying questions
> • Claude updates the plan file based on your answers
> Great for removing any ambiguity!
>
> 
I do this in a "setup phase" before letting agents run any code, I invest heavily upfront in a phase where user interaction does happen - before any autonomous agent loop begins.
After this quite rigorous process, the goal, which is now actually quite specific and detailed, is broken up into milestones consisting of individual tasks.
Snippet of the "setup phase" prompt"
In my experience, this step is very, very, VERY important - it forces YOU (not just the agent) to think about "what exactly do I actually want here?".
Nearly every time I run this step, Codex will ask me questions and raise assumptions that I had not even considered, but are surprisingly important details to think about and make decisions on upfront.
The way I visualize why this is useful is with a tree of potential outcomes, where each branch is a decision to be made to end up at your final outcome.
With no upfront clarification, your agent is the one making these decisions, which leaves you with one result out of almost endless possible ones that may somewhat lightly resemble what you asked for.
Whereas, spending more time upfront gives you the opportunity to course correct before the long-running agent process begins by cutting off those branches that are far away the thing you're envisioning.
## Multi-agent superiority
Research (and my own experience) has also found that using multiple agents in an orchestrator <> subagent relationship mogs just using a single good agent.
Page 39 - https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf
Obviously this burns way more tokens, but if that's not an issue for you, it does improve results.
Effectively, this is just the "horizontal" way to scale your token spending, i.e. rather than having a smart individual agent spend more tokens thinking, have multiple smart agents spend more time thinking together.
I made this diagram to represent this using Patrick Star to explain:
unfortunately, not sponsored
The way I implement this in my long-running agent workflow is by having the main long-running act as an orchestrator who can freely create teams of subagents per individual task.
These small teams work together to deliver a higher quality result than an individual agent could - typically I do this with one being the implementer and another acting as a reviewer.
This works by having the agent implement it's given task (which has been broken down into a small chunks of achievable work during the planning phase), and pass it to a reviewer subagent.
The reviewer, well... reviews it, and these two agents go back and forth on the fixes/improvements until they're both happy with the quality of the code; at which point they report back to the main orchestrator that the work is done.
Boris (creator of Claude Code) puts this elegantly here:
> **Boris Cherny@bcherny**: [原文链接](https://x.com/bcherny/status/2031151689219321886)
>
> Roughly, the more tokens you throw at a coding problem, the better the result is. We call this test time compute.
> One way to make the result even better is to use separate context windows. This is what makes subagents work, and also why one agent can cause bugs and another
I've found this super beneficial as enables agents to look at things with a fresh perspective any prior biases. For example, a review agent is seeing this code for the first time for an objective, unbiased review.
This is important because agents, especially Claude, can often delude themselves into believing things that are just plain wrong when their context windows become cluttered.
I originally created Claude Delegator to do this (have Codex review Claude's work), but since GPT 5.5, I just slam GPT 5.5 on xHigh for everything that is not designing interfaces on the frontend - I use Claude Design for that.
## Cross Context Memory
Giving agents a place to store memories across context windows and forcing them to read it on each new context window works well for both agents and for humans to understand where things are at.
In my long running agent workflow, after the planning phase, I ask the agents to create, read, and maintain three files:
1. GOAL.md: The top level thing we want achieved,
2. STANDARDS.md: non negotiable code quality standards that must be kept.
3. IMPLEMENT.md: Workflow instructions (using multiple agents for reviews, writing tests, verifying work, stuff like this).
4. PROGRESS.md: A continuously updating log of what decisions have been made & what work has been done.
I ask new agents to read all of these to immediately understand all decisions and progress that the agents before it have made from these file, and act in a way that is aligned with that progress.
Of course, agents don't always listen when you tell them too much, so these are more guidelines than things that always work - but they do generally help the process.
## Closing Thoughts
I'm super excited about long-running agents. It's an insane idea to fathom that we might truly be able to one-shot things into existence as models get better over time.
I've been experimenting with making them work over the past few months, documenting my learnings on here as I go... if you're curious about my long-current setup and want to try it yourself, here's the link: https://github.com/jarrodwatts/long-running-agent-skill/tree/main
It's packaged as a SKILL.md that you can easily plug into Claude/Codex, but I recommend using it with GPT 5.5 xHigh inside the Codex App, which has great visualisations for subagent workflows.
The skill also includes cool features like parallelizing work across small teams of subagents using git worktrees - I've used it long runs to produce very solid foundational chunks of projects ready to polish up.
I hope you like it!
## 相关链接
- [Jarrod Watts](https://x.com/jarrodwatts)
- [@jarrodwatts](https://x.com/jarrodwatts)
- [1.1K](https://x.com/jarrodwatts/status/2052372045829382430/analytics)
- [beating Anthropic's hiring challenge](https://x.com/jarrodwatts/status/2015599956024021211)
- [https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf](https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf)
- [May 1](https://x.com/fcoury/status/2049917871799636201)
- [862K](https://x.com/fcoury/status/2049917871799636201/analytics)
- [Matt Pocock's "grill-me" skill](https://www.aihero.dev/my-grill-me-skill-has-gone-viral)
- [Dec 31, 2025](https://x.com/jarrodwatts/status/2006138974834716993)
- [78K](https://x.com/jarrodwatts/status/2006138974834716993/analytics)
- [https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf](https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf)
- [Mar 10](https://x.com/bcherny/status/2031151689219321886)
- [@Rahll](https://x.com/Rahll)
- [215K](https://x.com/bcherny/status/2031151689219321886/analytics)
- [Claude Delegator](https://github.com/jarrodwatts/claude-delegator/)
- [https://github.com/jarrodwatts/long-running-agent-skill/tree/main](https://github.com/jarrodwatts/long-running-agent-skill/tree/main)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:56 PM · May 7, 2026](https://x.com/jarrodwatts/status/2052372045829382430)
- [1,155 Views](https://x.com/jarrodwatts/status/2052372045829382430/analytics)
---
*导出时间: 2026/5/7 22:08:51*
---
## 中文翻译
# 仅有 Ralph 循环是不够的
**作者**: Jarrod Watts
**日期**: 2026-04-30T18:24:40.000Z
**来源**: [https://x.com/jarrodwatts/status/2052372045829382430](https://x.com/jarrodwatts/status/2052372045829382430)
---
在过去的几个月里，我一直在各种支线任务中尝试运行长期代理，包括攻克 Anthropic 的招聘挑战。
我开始意识到，“长期代理”之所以有效，原因非常简单，就是因为它们花费了更多的 Token……或者，如果你是研究人员的话——它们“扩展了测试时算力”。
这听起来可能很蠢，但实际上确实有效——例如，在 BrowseComp 基准测试中，Sonnet 4.6 多花费了 10 倍的 Token，结果得分提高了约 10 个百分点：
第 45 页 - https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf
然而，当你的任务所需上下文远远超过代理上下文窗口的承载能力时，情况就开始变得棘手了……
为了解决这个问题，今年早些时候我们看到了诸如 Ralph Wiggum 循环之类方法的诞生，其最初形式仅仅是在一个循环中运行相同的提示词。
上周，Codex 团队发布了 Goals（目标）功能——这是一个用于长期代理的内置系统，可以运行数天来实现你的预期目标。
> **Felipe Coury @fcoury**: [原文链接](https://x.com/fcoury/status/2049917871799636201)
>
> /goal 功能也登陆了 Codex CLI 0.128.0。
> 我们对 Ralph 循环的理解是：在多轮对话中保持目标存活。在实现目标之前不要停止。
> 由我的同事兼 OpenAI 导师 Eric Traut（也就是 Pyright 那位大佬）构建。他是我每天都能共事的顶级人物之一。
我对此感到超级兴奋，但最终的结果却让我相当失望，尽管我非常喜欢 GPT 5.5！
由于 Codex 是完全开源的，我们能够确切地看到它的底层工作原理——我正是这样做了，以下是我学到的东西，以及为什么我认为我自己的长期代理工作流更好。
## Codex Goals 的工作原理
如果你还没有尝试过，可以通过在 Codex CLI 中运行 "/goal <你的目标>"，goal 会试图一次性搞定那些雄心勃勃的任务，它会连续运行数小时甚至数天。
在底层，goals 功能使用了一个简单的 SQLite 设置——Codex 创建了一个 "thread_goals" 表，将你创建的每个新目标作为一行存储；每一行都包含目标的具体 objective（内容）、id、status（状态）以及一个可选的 token 预算。
当 Codex 开始构建以实现你的目标时，它会使用包括 "get_goal" 和 "update_goal" 在内的新工具来记录进度，并更新数据库中目标的状态。
在此之后，Codex 使用非常标准的 Ralph 循环（重复提示相同的内容）并使用以下提示词：
```
继续致力于当前的线程目标。
<untrusted_objective>
发布包含真实 Goal-mode 证据的基准文章。
</untrusted_objective>
预算:
- 追求目标所用时间: XX 秒
- 已使用的 Token: XX
- Token 预算: XX
- 剩余 Token: XX
在确定目标已实现之前，请根据实际的当前状态进行完成度审计。
```
这解决了 Codex 在运行 15 分钟后停下来问你“是否可以继续”这个令人头疼的问题 🥺👉👈，但我并不认为这是让代理长时间运行的有效方式。
## 我认为 /goal 缺少什么
我绝对喜欢长期代理这个想法，这是我们目前最接近现实目标的方式——即让代理真正“构建一个 100 万美元 MRR 的 B2B SaaS，且不犯任何错误”。
但是，到目前为止，我使用 Codex 的 /goal 功能的体验相当令人失望——它具有我在构建许多自己失败的长期代理工作流后发现的相同缺陷。
我之所以这么认为，主要有三个原因：
1. 歧义会累积
2. 多代理的优势
3. 跨上下文记忆有效
我在过去几个月中吸取了这些教训，下面，我将分享这些细节，以及我总结出的一个我个人非常喜欢的工作流。
## 歧义会累积
让 LLM 在循环中运行意味着每次迭代的输出都会成为下一次迭代的输入——这对随后的每一次迭代都会产生累积效应。
当你要求模型从头到尾构建某样东西时，它会做出无数的决定，而在某个节点——它通常会做出一个你不会做的决定——此后的每一项工作都可能方向跑偏。
这与现实生活非常相似——如果你让别人根据模糊的需求来构建某样东西，而没有机会进行来回沟通，你可能无法得到你设想的结果。
由于 AI 似乎还没有“品味”，所以很难避免这种情况发生——除非你编写非常详细的提示词，以尽可能消除出错的空间。
在我自己的长期代理策略中，我使用这种 "/interview" 技能的变体来尽可能降低歧义，这与 Matt Pocock 的 "grill-me" 技能非常相似。
> **Jarrod Watts@jarrodwatts**: [原文链接](https://x.com/jarrodwatts/status/2006138974834716993)
>
> 我构建了一个自定义的 Claude Code 命令，/interview，用于创建无懈可击的规格说明。
> • 使用 plan mode 创建计划
> • 运行 /interview 命令
> • Claude 会提出 20-50 个澄清性问题
> • Claude 根据你的回答更新计划文件
> 非常适合消除任何歧义！
>
> 
我是在让代理运行任何代码之前的“设置阶段”做这件事的，在自主代理循环开始之前，我会在一个确实存在用户交互的阶段进行大量的前期投入。
在这个相当严谨的过程之后，现在的目标实际上已经非常具体和详细了，它会被分解成由单个任务组成的里程碑。
“设置阶段”提示词片段”
根据我的经验，这一步非常、非常、非常重要——它迫使你（不仅仅是代理）思考“我到底想要什么？”。
几乎每次我运行这一步时，Codex 都会问我一些问题，并提出我甚至没有考虑过的假设，但这些确实是令人惊讶的重要细节，需要提前思考并做出决定。
我形象化地理解其有用性的方式是通过一棵潜在结果的树，其中每个分支都是需要做出的决定，最终导向你的最终结果。
如果没有预先澄清，做出这些决定的就是你的代理，这导致你得到的结果几乎是无数种可能性中的一种，可能只是稍微有点像你要求的东西。
相反，在长期代理流程开始之前，花费更多时间进行预先澄清，可以让你有机会通过切断那些与你设想相去甚远的分支来纠正方向。
## 多代理的优势
研究（以及我自己的经验）也发现，在编排器 <> 子代理的关系中使用多个代理，仅仅使用一个优秀的代理效果要好得多（"mogs"）。
第 39 页 - https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf
显然，这会消耗更多的 Token，但如果这对您来说不是问题，它确实能提高结果质量。
实际上，这只是扩展 Token 支出的“水平”方式，即与其让一个聪明的单个代理花费更多的 Token 思考，不如让多个聪明的代理花费更多的时间一起思考。
我制作了这张图表来表示这一点，并请派大星来解释：
不幸的是，没有赞助
我在长期代理工作流中实现这一点的方法是，让主要的长期代理充当编排器，它可以为每个单独的任务自由创建子代理团队。
这些小团队通力合作，提供比单个代理质量更高的结果——通常，我这样做会让一个代理充当实施者，另一个充当审查者。
其工作原理是，让代理实施其给定的任务（该任务已在规划阶段分解为小的可实现的工作块），然后将其传递给审查者子代理。
审查者……嗯，审查它，这两个代理来回进行修复/改进，直到他们对代码质量都感到满意为止；此时他们向主编排器报告工作已完成。
Boris（Claude Code 的创建者）在这里优雅地阐述了这一点：
> **Boris Cherny@bcherny**: [原文链接](https://x.com/bcherny/status/2031151689219321886)
>
> 粗略地说，你在编码问题上投入的 Token 越多，结果就越好。我们称之为测试时计算。
> 使结果更好的另一种方法是使用独立的上下文窗口。这就是子代理工作的原理，也就是为什么一个代理可能导致错误而另一个代理可以发现错误。
我发现这非常有益，因为它使代理能够以全新的视角看待事物，没有任何先入为主的偏见。例如，一个审查代理第一次看到这段代码，是为了进行客观、公正的审查。
这很重要，因为代理，特别是 Claude，当它们的上下文窗口变得混乱时，经常会自我欺骗，相信那些完全错误的事情。
我最初创建 Claude Delegator 就是为了做到这一点（让 Codex 审查 Claude 的工作），但自从 GPT 5.5 发布以来，除了在前端设计界面的任务外（我用 Claude Design 来做），我在所有事情上都直接使用 GPT 5.5 xHigh 模式。
## 跨上下文记忆
给代理一个存储记忆的地方，跨越上下文窗口，并强制它们在每个新的上下文窗口中读取它，这对代理和人类了解当前进度都很有效。
在我的长期代理工作流中，在规划阶段之后，我要求代理创建、阅读和维护以下三个文件：
1. GOAL.md：我们要实现的最高级目标。
2. STANDARDS.md：不可协商的代码质量标准，必须遵守。
3. IMPLEMENT.md：工作流指令（使用多个代理进行审查、编写测试、验证工作等）。
4. PROGRESS.md：关于已做决定和已完成工作的不断更新的日志。
我要求新代理阅读所有这些文件，以便立即了解之前的代理做出的所有决定和进度，并以与该进度一致的方式行事。
当然，当你告诉代理太多东西时，它们并不总是听从，所以这些更多是指南，而不是总是有效的法则——但它们确实有助于流程。
## 结束语
我对长期代理感到超级兴奋。随着模型变得越来越好，我们也许真的能够一次性生成想要的东西，这简直是一个令人难以置信的想法。
在过去几个月里，我一直在尝试让它们工作，并在此过程中记录了我的所学……如果你对我当前长期使用的设置感到好奇并想亲自尝试，这里是链接：https://github.com/jarrodwatts/long-running-agent-skill/tree/main
它被打包成一个 SKILL.md 文件，你可以轻松地插入到 Claude/Codex 中，但我建议在 Codex App 中配合 GPT 5.5 xHigh 使用，它具有很好的子代理工作流可视化效果。
该技能还包括很酷的功能，比如使用 git worktrees 跨小型子代理团队并行化工作——我已经在长时间运行中使用它来生成非常扎实的基础项目块，随时可以打磨。
我希望你喜欢它！
## 相关链接
- [Jarrod Watts](https://x.com/jarrodwatts)
- [@jarrodwatts](https://x.com/jarrodwatts)
- [1.1K](https://x.com/jarrodwatts/status/2052372045829382430/analytics)
- [beating Anthropic's hiring challenge](https://x.com/jarrodwatts/status/2015599956024021211)
- [https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf](https://www-cdn.anthropic.com/bbd8ef16d70b7a1665f14f306ee88b53f686aa75.pdf)
- [May 1](https://x.com/fcoury/status/2049917871799636201)
- [862K](https://x.com/fcoury/status/2049917871799636201/analytics)
- [Matt Pocock's "grill-me" skill](https://www.aihero.dev/my-grill-me-skill-has-gone-viral)
- [Dec 31, 2025](https://x.com/jarrodwatts/status/2006138974834716993)
- [78K](https://x.com/jarrodwatts/status/2006138974834716993/analytics)
- [https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf](https://www-cdn.anthropic.com/0dd865075ad3132672ee0ab40b05a53f14cf5288.pdf)
- [Mar 10](https://x.com/bcherny/status/2031151689219321886)
- [@Rahll](https://x.com/Rahll)
- [215K](https://x.com/bcherny/status/2031151689219321886/analytics)
- [Claude Delegator](https://github.com/jarrodwatts/claude-delegator/)
- [https://github.com/jarrodwatts/long-running-agent-skill/tree/main](https://github.com/jarrodwatts/long-running-agent-skill/tree/main)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:56 PM · May 7, 2026](https://x.com/jarrodwatts/status/2052372045829382430)
- [1,155 Views](https://x.com/jarrodwatts/status/2052372045829382430/analytics)
---
*导出时间: 2026/5/7 22:08:51*