Fable 5 与 GPT-5.6 Sol 在 NP-困难问题上的较量：/goal 有帮助吗？（6分钟阅读）

# Fable 5 对比 GPT-5.6 Sol 在 NP 难问题上的表现：/goal 有帮助吗？ - Charles AZAM 来源：https://charlesazam.com/blog/fable-5-gpt-5-6-sol-goal/ **TL;DR：**我给了 Claude Fable 5 和 GPT-5.6 Sol 同一个未公开的 NP 难优化问题，分别测试了使用和不使用原生 `/goal` 模式的结果。Fable 5 表现极其出色；而 `/goal` 并非改变游戏规则的关键因素。 清晰的得分分布 **背景：**这是一个最初在黑客松上交给学生的运筹学问题。多年前我花了一周时间用 C++ 解决了它，因此我掌握了一个可用的人类基线。 Fable 5 在这个基准测试中表现极其出色。它给出了整体最佳解决方案，而且其一致性是我在这个问题上从未在模型身上见过的。这纯粹是原始智力，令人难以置信。 另一个结果是，`/goal` 并非一个通用的“再努力一点”的开关。它改变了控制回路和搜索路径。有时候能找到更优的盆地，有时候则会让糟糕的想法变得更成熟。 所有代码、提示词、结果表格、排除项和过程记录都在 **CLIArena**（https://github.com/charles-azam/CLIArena） 中。这是对我关于此基准测试的**第一篇文章**（https://charlesazam.com/blog/kiro-benchmark/）的后续跟进。 --- ## 问题 KIRO 是一个光纤网络设计问题，我作为工程系学生在 2018 年研究过。给定格勒诺布尔、尼斯和巴黎的有向距离矩阵，求解器必须使用环和小型链连接到分配点和终端，同时遵守若干结构约束。目标是总光缆长度。数值越小越好。 KIRO 网络结构：以枢纽为根的有向环，附带短分支 一个有效的网络由以分配枢纽为根的重叠环组成，从这些环上的塔吊下短分支。每个塔必须恰好出现一次，并且反转电缆段可能会改变其成本。 ### 搜索空间有多大？ 没有单一的闭合形式计数，因为一个解可以使用任意数量的环、可变环大小以及不同锚定和排序的分支。但仅巴黎就能给出一个有用的下界。 即使忽略排序和分支，仅将 532 个终端分配到 11 个分配枢纽，也有 `11^532` 种可能分配。 另一个更强的下界来自一个经过刻意限制的有效解族：恰好 19 个环，每个环 28 个终端，没有分支。这覆盖了全部 532 个终端（因为 `19 x 28 = 532`），同时保持在每个环不超过 30 个终端的限制内。将 532 个终端排序，然后将该排序分成 19 个连续组，除以 `19!` 因为环的集合是无序的，再为每个环从 11 个枢纽中选一个： `\(532! / 19!\) x 11^19 ~= 10^1223` ## 我测试了什么 主要实验有意设计得很窄： | 设置 | 值 | |---|---| | 模型 | Claude Fable 5, Opus 4.8, Sonnet 5; GPT-5.6 Sol, Terra, Luna | | 模式 | 纯文本；原生 `/goal` | | 优化预算 | 30 分钟 | | 外部代理超时 | 1900 秒 | | 推理 | 每个模型都设为最大可用设置 | | 执行环境 | Harbor 0.1.43, Docker, 订阅认证 | ## 结果 在将重复测试集中在旗舰对之前，我对所有模型进行了一次匹配的 30 分钟无提示对测试。对于 Fable 和 Sol，图表使用了来自复现头条结果的 Pair 1；其他四个模型各有一个对。 所有六个模型在一次匹配的 30 分钟无提示对中的表现 接着，我重复了旗舰对比测试，直到 Fable 5 和 Sol 各有三次匹配运行。 清晰的得分分布 | 模型 | 运行 | 纯文本 | `/goal` | Goal 减去纯文本 | |---|---|---|---|---| | Fable 5 | 1 | 32,197 | **31,934** | -263 | | Fable 5 | 2 | 32,516 | **32,324** | -192 | | Fable 5 | 3 | **32,446** | 35,178 | +2,732 | | GPT-5.6 Sol | 1 | **33,581** | 39,371 | +5,790 | | GPT-5.6 Sol | 2 | 35,539 | **32,703** | -2,836 | | GPT-5.6 Sol | 3 | 33,663 | **33,313** | -350 | 负数表示 `/goal` 更好。Goal 在六次试验中赢了四次，因此仅看胜率这个特性看起来很有用。但平均值揭示了另一半情况： | 模型 | 纯文本平均值 | `/goal` 平均值 | 平均效应 | 中位数效应 | |---|---|---|---|---| | Fable 5 | **32,386** | 33,145 | +759 更差 | -192 更好 | | GPT-5.6 Sol | **34,261** | 35,129 | +868 更差 | -350 更好 | 两个模型通常都能获得小幅收益，但偶尔会遭遇较大的回归。这就是为什么 `/goal` 在大部分运行中获胜，却使两个模型的平均值都变得更差。 Fable 也明显更强。它的纯文本平均值比 Sol 好 1,875 分，它的 goal 平均值比 Sol 好 1,984 分。更重要的是，Fable 的纯文本平均值保持在仅 319 分的微小范围内，而 Sol 的纯文本平均值跨度达 1,958 分。Fable 的 goal 模式产生了最好的干净得分 31,934；Fable 的纯文本模式是最安全的配置。 ## 深入剖析 goal 命令 ### 同一个命令隐藏着两个不同的系统 Claude Code 和 Codex 都提供了 `/goal`，但它们的实现有本质区别。 Claude Code 与 Codex 的 goal 架构 ### Claude Code：独立的评估器 Claude Code 将 `/goal` 实现为会话作用域的 Stop 钩子。在每个主模型轮次之后，一个小型评估器（默认是 Haiku）会读取条件和对话。它返回是/否，并附带理由。返回“否”会开始另一个轮次；返回“是”会清除 goal。 评估器无法使用工具或检查文件。它只能根据出现在转录中的证据进行判断。这可以捕获过早的退出，但它无法知道再做一千万次求解器迭代是否值得。[Anthropic 的 goal 文档](https://code.claude.com/docs/en/goal) 请记住，claude code 并非开源，因此我们只能依赖 Anthropic 告诉我们的信息。 ### Codex：持久化状态与生命周期工具 我还阅读了基准测试发布版本的源代码：[Codex CLI 0.144.4](https://github.com/openai/codex/tree/rust-v0.144.4)。Codex 将 goal 视为持久化线程状态： 1. TUI 保存活动线程的目标，SQLite 存储其状态和预算核算。[TUI](https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/tui/src/app/thread_goal_actions.rs#L128-L227)、[schema](https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/state/goals_migrations/0001_thread_goals.sql) 2. 工作模型接收 `create_goal`、`get_goal` 和 `update_goal` 工具。[工具规范](https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/ext/goal/src/spec.rs) 3. 如果线程在 goal 激活时变为空闲状态，Codex 会注入一个包含目标和完成审计的延续轮次。[运行时](https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/ext/goal/src/runtime.rs#L359-L414)、[提示词](https://github.com/openai/codex/blob/rust-v0.144.4/codex-rs/ext/goal/templates/goals/continuation.md) Claude 将完成判断委托给另一个模型。Codex 让工作模型自行声明完成，然后在持久化 goal 保持激活状态时恢复执行。Claude 的评估器是独立的，但只看到转录；Codex 能看到文件与工具，但实际上是给自己的作业打分。 ## 为什么 `/goal` 能赢大部分运行，却仍然不是一个好的默认选项 在常规编码任务中，进展通常是可观察的：再执行一轮可以修复一个测试或完成一次迁移。优化则不同。一旦代理选择了某个求解器，额外的时间既可能放大好的决策，也可能放大坏的决策。 这正是这里发生的情况。当 goal 帮助 Fable 维持快速编译策略组合，或帮助 Sol 维持成功的链重新划分时，它是有益的。而当 Fable 构建了慢速求解器，或 Sol 全力投入穷举锚点搜索时，goal 则造成了伤害。中位数略有改善，但坏尾部的幅度要大得多。 ## 局限性 这只是一个未公开的 NP 难任务，而非通用编码排行榜。只有 Fable 和 Sol 拥有三个干净的可匹配对。其他比较涉及不同的提示词、封装版本和时间限制，并且试验是通过可能发生漂移的订阅服务顺序执行的。 容器暴露了 8 个 CPU，尽管任务元数据声明为 1 个，这有利于 Fable 的并行策略组合。每个有评分的 Fable 和 Sol 输出都是有效的，部分原因是封装需要早期检查点和最终验证。该基准测试测试的是完整系统：模型、CLI、提示词、订阅服务和测试框架。 ## 复现方法 基准测试任务、封装、分析脚本、图表生成器及完整证据备忘录都在 **CLIArena**（https://github.com/charles-azam/CLIArena） 中。原始作业目录因体积过大而被排除在 Git 之外，但备忘录记录了每个可发表的分数、城市细分、耗时、策略、排除项及运行 ID。 主要命令为： ``` RUN_ID=article-kiro-YYYYMMDD-clean \ PHASE=nohint-all \ ./scripts/run_subscription_article_matrix.sh uv run python scripts/summarize_subscription_article_results.py RUN_ID... uv run python scripts/analyze_subscription_article_results.py RUN_ID... ``` 我认为值得放在标题的结果并非 goal 有帮助还是有害，而是一个持久化特性可以在赢得大多数单独试验的同时，使观察到的平均性能变差。在困难的优化问题上，循环的质量不如循环持续运行的内容的质量重要。