Loop Engineering：实测/goal 的能力，竟会比不开更差？

判断一个 agent 到底行不行，现在主要看公开 benchmark 的分数。可那些题模型训练的时候多半见过，分数高不代表真本事。我更想知道的是：拿一道它没见过的硬题，给固定的时间，它能做到什么程度。

所以我拿 Claude Fable 5 和 GPT-5.6 Sol 跑了同一道没公开过的 NP-hard 优化题。每个模型都跑两种模式,开 /goal 和不开,每组 30 分钟。这些题是我在2018 年时自己优化的C++代码,现在我把他当做baseline测试这两个目前来看最强的Agent。

结果是，/goal 基本都完成了任务。但两个模型使用 /goal 的平均分,都比不开更差。

题目详解

这道题叫 KIRO,光纤网络设计。题目是：给你格勒诺布尔、尼斯、巴黎三个城市的有向距离矩阵,要求用环和链把分配中心和终端连起来,满足给定结构约束,目标是把线缆总长度压到最小。一个合法解是这样的:若干个挂在分配中心上的冗余环,环上的塔再伸出短分支,每座塔恰好出现一次。

这道题的难点在于搜索空间极大，搜索空间大到甚至没有闭式的答案,光巴黎一个城市就有532 个终端,哪怕完全不管顺序和分支,只把每个终端分给 11 个中心之一,就有 11^532 种分法。换一个更朴素的下界:把 532 个终端排好序,切成 19 组每组 28 个,除以 19! 去掉环之间的顺序,每组再挑一个中心,算出来是 (532!/19!)×11^19,约等于 10^1223的搜索空间。

/loop的结果:基本搞定，但整体分数偏低

我们先来了一轮小规模测试，先给参测的六个模型各跑了一组 30 分钟无提示配对摸底：Claude 这边是 Fable 5、Opus 4.8、Sonnet 5，GPT-5.6 那边是 Sol、Terra、Luna。

旗舰组各跑三轮,推理档位拉满,30 分钟预算。分数是两点之间连线的长度。越低越好。然后我画出了下图，下图负值表示 /goal 更好:

/goal 六战四胜，但我们深入看/goal的平均值的话，能有更明显的发现。

两个模型反应了同一种情况，多数时候我们使用goal的时候是有收益的，但偶尔使用goal会有很强的回退。这样平均下来发现goal反而平均值更低。

Fable 5 本身强得离谱。全场最好成绩是就是它(Fable goal,31,934),plain 均值比 Sol 低 1,875 分。更夸张的是稳定性:Fable plain 三次成绩在 319 分的波动里,Sol plain 的波动区间是 1,958 分。如果按平均分来看，Fable能持续发挥出不错的实力

/goal系统解析

Claude Code 和 Codex 都有 /goal 命令,虽然他们的名字一样,但底层实现完全是两套东西。

Claude Code:外挂一个裁判模型。 /goal 作为一个会话级 Stop hook。主模型每跑完一轮,就会拉起一个小的评估模型(默认 Haiku)读一遍目标和对话记录,回答 yes 或 no,附一句理由。no 就再来一轮,yes 就清掉目标。这个裁判不能用工具、不能翻文件,只能根据对话记录里出现过的证据下判断。它能判断现在的状态,但它没法知道后续这个goal到底有没有可能真正的完成。还有一点,Claude Code 不开源,以上只能信 Anthropic 文档的说法。

Codex:持久化状态加一套工具。 我读了 benchmark 对应版本的源码,Codex CLI 0.144.4。Codex 把 goal 当成持久化的线程状态:TUI 给当前线程保存目标,SQLite 记录状态和预算;工作模型手里有 create_goal、get_goal、update_goal 三个工具;线程空转但目标还挂着的时候,Codex 会注入一个 continuation turn,把目标和完成度审计一起塞回去。

claude code 和 codex的差别一句话即可说清:Claude 把"完成没有"交给另一个模型判断,Codex 让干活的模型自己宣布完成,然后在持久目标下继续跑。Claude 的裁判独立,但只能看对话记录;Codex 能看文件、能用工具,但等于goal在自己给自己打分。

/goal的缺点在哪里

普通编码任务里进度是可读的。goal持续多跑几轮,codex和claude就可以修掉挂掉的测试,或者补完一段没迁完的迁移。

但像做这种优化题的逻辑不一样。普通编码任务是目标可见的，甚至往往是根据目标的roadmap和todo分配了goal去执行，但在这种打榜，冲分的实现上，Agent 一旦选定了一条路线。这条路线无论好坏Agent是会一条路走到黑的，如果运气好而选到了正确的路。就能成功许愿到好结果，反之亦然。回到这道题目来讲/goal 成功的时候,是它让 Fable 那套快速编译的 solver portfolio 多跑了一会儿,或者让 Sol 把已经走通的链重划分策略继续推进。/goal 闯祸的时候,是 Fable 造了个慢求解器,或者 Sol 一头扎进穷举锚点扫描,错误的路径会一错再错。

总结

这是一道没公开的 NP-hard 题，不是通用编码榜单。只有 Fable 和 Sol 各有三组，其他模型的对比混淆了 prompt、wrapper 版本和时间限制，所以并没有很强的控制变量。容器实际运行时也使用了 8 个 CPU，任务元数据里写的是 1 个，这明显偏袒 Fable 的并行 portfolio。最后,这个 benchmark 测的是完整Harness系统，哪一环变了成绩都可能变。

总结来说，现在很多人都在鼓吹Agent Looping，开/goal模式有多么好的效果。但说白了/goal用起来也是一个大号许愿机罢了，如果/goal的过程中你不知道他现在选的这条路是否是合理并可达的。就会有很严重的问题，会浪费很多的token or浪费很多的时间。

当然也总有人会说，我们如果有足够的 token 和 足够的机器的话。想做什么都能实现，但这其中有一个最大的问题就是迭代效率。你的goal是否走在正确的路上，在打开goal的时候你是否注入了足够多的prompt。会很强的影响最后的结果，因此。如何高效的使用goal，也是很关键的Agent Infra or Harness的问题。

-- 完 --

机智流推荐阅读：

1. ‍

2. 

3. 

4.