00:00:00Ralph Wiggum 最近彻底火了。我们去年做过一个相关的视频，而从那时起，
00:00:04Twitter 上几乎所有人都在讨论它。Matt Pocock 制作了大量关于它的视频，
00:00:09Ryan Carson 写了一篇非常受欢迎的文章，而 Razmike 则通过他的 Ralphie Bash 脚本进一步完善了它。
00:00:13但大家的做法都对吗？创作者已经表示，有些实现方式是不正确的。
00:00:19那么正确的方法是什么？为什么 Ralph 是目前利用 AI 开发软件的最佳方式？
00:00:21点击订阅，让我们深入探讨。
00:00:26Ralph 循环（Ralph loop）由 Jeff Huntley 创立，并在去年 6 月份就有了相关记载。
00:00:30它本质上是一个 Bash 循环，不断向 AI 代理重复发送完全相同的提示词。
00:00:35这种设计在很多层面上都堪称天才，因为它能让 AI 代理在最“聪明”的模式下工作，
00:00:40也就是上下文（context）尽可能少的模式。请看这里。
00:00:46让我们把这想象成一个代理的完整上下文窗口。从 0 到 30% 左右的部分，
00:00:51我们称之为“聪明区”，这是代理表现最出色的时候。从 30% 到 60%，
00:00:57它的表现仍然很好。而从 60% 以后，也就是 60、70、80、90，
00:01:01性能就开始下降了。我们称之为“笨拙区”。当然，这些数字并不是固定的，
00:01:08不同模型会有所差异。某些模型的聪明区可能是 40% 或 50%，但通常超过 80% 的上下文窗口后，
00:01:12迟钝感就会显现出来。
00:01:16以 Claude Sonnet 或 Opus 为例，典型的上下文窗口是 20 万个 Token。所以你可以说，
00:01:21前 6 万是聪明区。接下来的 6 万也还行，但不如前 6 万。而最后的 8 万，
00:01:28表现似乎就没那么好了。这是我个人对该模型的经验，你可能有不同的体会。
00:01:33原因在于模型本身是所谓的“自回归”模型，意味着它必须回顾之前的 Token
00:01:38来预测下一个。如果 Token 数量庞大，它就必须梳理海量内容，
00:01:43才能找出与当前任务相关的重点。
00:01:47现在让我们关注前 30%。甚至在你写下第一个提示词之前，就有一些内容被自动添加到了上下文窗口中。
00:01:52首先是系统提示词（system prompt），然后是系统工具。在典型的 Claude 模型中，
00:01:56它们分别占用 8.3% 和 1.4% 的上下文。这已经占了 30% 里的近 10%。
00:02:01接着如果你还有技能（skills），或者自定义的 MCP 工具，也会被添加进去。
00:02:06最后，如果有 agent.md 文件，它同样会被加入。
00:02:12显然，这些东西越大——比如 md 文件越长——占用的 Token 就越多。
00:02:16而这全都是在你添加自己的提示词之前发生的。所以通常情况下，最好保持这一部分尽可能精简。
00:02:21减少工具、减少技能、精简 agent.md 文件，让模型始终在最理想的上下文状态下运行。
00:02:25为了让你对 6 万个 Token 有个概念：如果把《星球大战：新希望》的整部剧本拿来，
00:02:30在 GPT-5 中大约是 54,000 个 Token。差不多就是这个量。
00:02:35现在你可能会问，那“压缩”（compaction）呢？它能帮上忙吗？
00:02:40我们稍后再聊。现在来看看 Ralph 到底是如何解决这个问题的。
00:02:44Ralph 的优势在于你可以在每个上下文窗口只专注于一个目标。
00:02:51我们可以把整个 20 万的窗口全部贡献给一个目标或任务。具体做法是，
00:02:56我们写一个提示词，让它首先检查 plan.md 文件。这个文件包含待办任务，
00:03:00比如创建前端、创建后端、处理数据库等等。这只是个高层级的例子，
00:03:05在实际使用 Ralph 时，你会写得更详细、更细致，但我们先按这个例子讲。
00:03:10这个提示词会告诉代理挑选最重要的任务，然后进行修改。
00:03:15修改完成后，运行代码，甚至执行推送和提交，同时进行测试。
00:03:19一旦任务完成且测试通过，就在 plan.md 中将该任务标记为已完成，然后再次循环。
00:03:23代理会不断寻找最重要的任务去执行，直到所有任务完成。
00:03:28其实我收回刚才的话，因为即使所有任务都完成了，你也可以让 Ralph 循环继续运行。
00:03:33这样做的好处是它可能会发现需要修复的潜在问题，或者添加 plan.md 里原本没有的新功能。
00:03:38如果它开始跑偏，Ralph 的优点在于你可以随时停止整个过程，
00:03:42调整提示词文件，然后重新运行。Ralph 让这一切变得简单，
00:03:46因为整个过程都执行在一个简单的 Bash while 循环中。
00:03:52在这里，它只是 cat 提示词文件（即打印给代理），然后以 YOLO 模式运行 Claude。
00:03:57当然，实际的参数标记不是 YOLO，而是“危险地跳过权限确认”，但为了节省空间我简写了。
00:04:02Ralph 的特殊之处在于它处于模型的控制之外。模型无法决定何时停止 Ralph，
00:04:08循环会一直持续。这样你可以确保每当新任务运行或新提示触发时，
00:04:12上下文都是焕然一新的，就像你第一次打开代理时一样。
00:04:16它没有经过压缩，没有任何冗余。因此，每个新任务都能获得最大的上下文空间，
00:04:22并在模型最聪明、最理想的窗口状态下运行。
00:04:26所谓的“压缩”是指代理会查看窗口中已写入的所有 Token，并为下一个提示挑选重点。
00:04:31它会挑选它“认为”最重要的信息，但它并不一定真的知道什么才是最重要的。
00:04:36因此，压缩可能会丢失关键信息，导致项目运行不如预期。
00:04:41既然我们已经看过了创作者提供的标准 Ralph 循环实现，就能明白为什么其他实现方式有所不同了。
00:04:46让我们看看 Anthropic 的实现，它使用斜杠命令在 Claude 内部运行 Ralph，
00:04:50设置了最大迭代次数和完成承诺（completion promise）。
00:04:55这个特定的 Ralph 插件的问题在于，它在进入下一个任务时会压缩信息。
00:05:01当它完成一个任务并重新运行提示词时，它不是完全重置上下文窗口，
00:05:05而是压缩之前的内容，因此可能会丢失关键信息。
00:05:11设置最大迭代次数和完成承诺也有点问题，因为有时让 Ralph 一直跑下去反而更好。
00:05:16它可能会发现你之前没想到的有趣修复。如果你在旁边观察（即“人在回路”），
00:05:21你可能会发现特定模型的优缺点模式，从而在原始提示词中进行针对性优化。
00:05:27如果我们再看看 Ryan Carson 的 Ralph 循环方案，可以看到它也不太“正统”，
00:05:33仅仅是因为在每次循环中，它都有可能调整或增加 agent.md 文件的内容。
00:05:38根据系统提示词或你添加的用户提示，凭我的经验，模型默认情况下可能非常啰嗦。
00:05:43如果在每次迭代中你都在往 agent.md 里加东西，而这些东西又在每次用户提示开始时被加入上下文，
00:05:48那么你就是在不断往窗口里塞 Token，把模型推向可能产生“降智”结果的边缘。
00:05:54不过，大家都在基于基础的 Ralph Bash 脚本编写自己的脚本，这足以证明它有多简单易懂。
00:05:59虽然 Ralph 有标准做法，但我认为开发者、团队和公司针对特定用例进行调整也是没问题的。
00:06:04例如，我很喜欢 Razmike 的 Ralphie 脚本，它提供了一种并行运行 Ralph 的方法，
00:06:08而且还能使用 Vercel 的代理浏览器工具进行浏览器测试。
00:06:14我也很喜欢 Matt Pocock 版本的 Ralph，他将任务或待办事项添加为 GitHub Issues，
00:06:19Ralph 循环会自动挑选最重要的一个去执行，完成后标记为已解决，再处理下一个。
00:06:24我觉得这非常聪明。Ralph 的强大和简洁意味着它将存在很长一段时间。
00:06:29你也可能会看到基于它的许多迭代和改进。我很喜欢 Jeffrey 在 Loom and Weaver 项目中的方向，
00:06:33他想创造一种自主且正确地开发软件的方法。
00:06:39但既然有这么多 Ralph 在自主创建新软件，你就需要一种搜索错误并确保修复的方法。
00:06:44这就是 Better Stack 大显身手的地方，它不仅能摄取日志并过滤错误，
00:06:48还能处理前端的错误追踪。通过这个 MCP 服务器，你可以要求代理专门挑选出
00:06:53前端或后端的错误，而无需阅读整个日志，这反过来又减少了上下文窗口的占用。
00:06:57所以快去试试 Better Flux，并在评论区告诉我你的想法。
00:07:03Ralph, I think it's okay for developers, teams and companies to tweak it to their specific
00:07:08use case. For example, I love the fact that in Raz Mike's Ralphie script, there's a way
00:07:13to run parallel Ralphs and also the fact that you can use the agent browser tool from the
00:07:18cell to do browser testing. I also love the fact that in Matt Pocock's version of Ralph,
00:07:23he adds tasks or things to do as GitHub issues and the Ralph loop will pick the most important
00:07:28one, work on it and mark it as done when it's complete before working on the next one, which
00:07:32I think is really clever. I think the power and simplicity of Ralph means that it's going
00:07:37to stick around for a very long time. And you also may see a lot of iterations and improvements
00:07:42from it. I really like the way Jeffrey is taking this with his Loom and Weaver project where
00:07:47he wants to create a way to make software autonomously and correctly. But with all these
00:07:52Ralphs autonomously creating new software, you need a way to search for errors and make
00:07:56sure they get fixed. This is where better stack comes in because not only can it ingest logs
00:08:01and filter out errors from them, but it can also handle error tracking on the front end.
00:08:06So with this MCP server, you can ask an agent to specifically pick out errors from the front
00:08:11end or back end instead of reading through the whole log, which in turn reduces the context
00:08:16window.
00:08:17So go and check out Better Flux, and let me know what you think in the comments.