标题开个玩笑，大家都是复刻了 ralph loop
前情概要：
上个月太闲，写了篇帖子宣传一下用了好几个月了还是老当益壮、没人去做很好复刻的 pure Ralph Loop pattern：CodexPotter 【开源自荐】让 codex 不要干活干到一半就停下
这不刚到五一假期官方也端出来了！
codex 升级到最新版之后，通过以下 config.toml 配置可以启用相似的新功能 /goal:
[features]
goals = true
看到 codex team 在这个全是 harness 声音熙熙攘攘的时刻，和我一样 认为朴素简单的 Ralph Loop 仍然值得做大做强、推广开，还是很开心的！有拨云见日、发现遥远大洋对岸有高人和自己所见略同的感觉：
找一个 skill / workflow / 方法论，来改进某个特定场景的表现，是非常容易的，然而市面上有一大堆方案，总不能一大堆都集成进产品吧？有没有什么是普适的、通用的实践？有的兄弟，有的，不加任何佐料的 Ralph Loop 就是这么个实践。
另，趁着假期简单分析代码和体验了一下这个最新的 /goal，供大家参考~
/goal
CodexPotter
共同点：是否强制要求使用 PRD 等业务流程
共同点：是否可以用在 Agent Team 等高阶流程中
共同点：用户的原始需求描述能在 compact 后继续保留
最大迭代约束
最大 token 开销
最大迭代轮次
是否支持在会话中途开启迭代循环
是否基于干净上下文进行迭代
.. 额外 Token 开销 指的是相比正常完成到这个状态，需要多付出多少 token 低 高
token 开销一般需要×1.5 .. 额外任务耗时 中 高 .. 可规避干活没干完问题
(强)
(很强)
.. 自动复核和纠正新写出来的 bug
.. 任务完成质量
正常
高
TLDR：
-
共同点： 不强制改变你的工作流，能持续推进工作，直到真正达到你描述的状态
-
差异：
/goal不在 fresh context 推进工作，而是为你追加 continue 指令 —— 这当然是优缺点共存的，能带来省 token 的好处，但也继承了 llm 长期工作会带来偏见的问题
个人锐评：
我猜测官方的
/goal作为一个想推给所有人用的功能，不想引入过大的 token 额外开销 免得被骂，所以就继续采用当前上下文推进工作，来经济实惠地实现持续推进工作的目的。其实这个决策还是比较精妙的，在一个比较甜点的平衡点上，因为 compact 之后也是全新上下文了，并不会持续处于低智商状态。不过因为已有的工作会被新的 session 信任，因此容易被之前的结论带偏，也难以发现上一轮的问题，就单纯只是继续推进工作了。
综上，我目前的体验和推荐如下：
-
如果你想省 token，或者并不想付出额外的时间成本，codex 新出的
/goal是一个不错的选择，比你自己发一堆 continue 要省心、效果也更好（可以跨 compact 持续记住你的目标而不失真），持续推进工作到看起来满足了你的要求 for daily work -
如果你有 Pro 5x 订阅，接受更久的运行时间，希望 codex 自纠正、更省心、少打理，那仍然可以继续用 CodexPotter 等全新上下文的 ralph loop 工具来执行这类任务 for working at night
以上，是我这两天的 /goal 使用体验，总体比较喜欢，不过样本还比较少，应该还有更多细节和场景值得挖掘，期待交流更多使用经验
5 个帖子 - 5 位参与者