Fable 5与GPT-5.6 Sol在NP-hard问题上的对比：/goal模式并非万能
博客
一句话总结：我给Claude Fable 5和GPT-5.6 Sol布置了同一道未公开的NP难优化问题，分别测试了普通模式与原生/goal模式。结果显示Fable 5性能惊人，而/goal模式并未带来颠覆性改变。
背景：这是一道原本用于黑客松学生竞赛的运筹学问题。多年前我曾花一周时间用C++编写求解程序，因此有可参考的人工基准结果。
在本次测试中，Fable 5的表现堪称碾压。它得出了全局最优解，且稳定性远超我见过的其他同类模型。这是纯粹的算力体现，令人惊叹。
另一项发现是，/goal并非通用的"全力冲刺"开关。它会改变模型的控制逻辑与搜索路径：有时能找到更优的解空间，有时却会让错误思路持续发酵。
所有代码、提示词、结果表格、排除项及过程记录均收录于CLIArena。本文是我首篇该基准测试文章的后续研究。
测试问题
KIRO是我2018年作为工程学生时研究的光纤网络设计问题。给定格勒诺布尔、尼斯和巴黎三地的有向距离矩阵，求解器需通过环路与短链连接分发点和终端，同时满足多项结构约束，目标是最小化总光缆长度。
一个有效的网络需包含以分发枢纽为起点的冗余环路，环路节点上延伸出短分支。每个节点必须恰好出现一次，反转光缆段会改变成本。
搜索空间规模
由于可行解可包含任意数量的环路、可变环路长度，以及不同锚点和顺序的分支，无法用单一闭式表达式计算搜索空间大小。但仅巴黎的数据就能给出一个有效下界。
即便忽略节点顺序和分支，仅将532个终端分配至11个分发枢纽，就有11^532种可能的分配方式。
一个更严格的下界来自一类受约束的可行解：恰好19个环路，每个环路包含28个终端，无分支。19×28=532，刚好覆盖所有终端，且未超过单个环路30个终端的限制。将532个终端排序后分成19个连续组，除以19!（因环路集合无序），再为每个环路选择11个枢纽之一，可得：
(532! / 19!) × 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、订阅认证 |
测试结果
在聚焦两款主力模型重复测试前，我先对所有6款模型各进行了一组30分钟无提示的对照测试。图表中Fable和Sol的数据来自重复测试组的第一组，其余4款模型各有一组数据。
随后我对两款主力模型进行重复测试，最终完成Fable 5的3组对照测试和Sol的3组对照测试。
| 模型 | 测试轮次 | 普通模式 | /goal模式 |
/goal与普通模式差值 |
|---|---|---|---|---|
| Fable 5 | 1 | 32197 | 31934 | -263 |
| Fable 5 | 2 | 32516 | 32324 | -192 |
| Fable 5 | 3 | 32446 | 35178 | +2732 |
| GPT-5.6 Sol | 1 | 33581 | 39371 | +5790 |
| GPT-5.6 Sol | 2 | 35539 | 32703 | -2836 |
| GPT-5.6 Sol | 3 | 33663 | 33313 | -350 |
负值表示/goal模式表现更优。6轮测试中/goal赢了4轮，单看胜率似乎这个功能很有用，但平均值揭示了另一面：
| 模型 | 普通模式均值 | /goal模式均值 |
平均差值 | 中位差值 |
|---|---|---|---|---|
| Fable 5 | 32386 | 33145 | +759（更差） | -192（更优） |
| GPT-5.6 Sol | 34261 | 35129 | +868（更差） | -350（更优） |
两款模型在多数情况下能通过/goal获得小幅提升，但偶尔会出现大幅倒退。这就是为什么/goal赢了多数单轮测试，却拉低了整体平均表现。
Fable的优势十分明显：其普通模式均值比Sol低1875分，/goal模式均值比Sol低1984分。更重要的是，Fable普通模式的得分波动仅为319分，而Sol普通模式的波动高达1958分。Fable的/goal模式取得了全局最优得分31934，而Fable的普通模式则是最稳定的配置。
深入解析/goal指令
同名指令，不同内核
Claude Code和Codex都提供/goal指令，但底层实现截然不同。
Claude Code：独立评估器
Claude Code将/goal实现为会话级的停止钩子。主模型每完成一轮推理，默认由小型评估模型Haiku读取目标条件和对话记录，返回"是/否"的判断及理由。若返回"否"，则继续下一轮推理；若返回"是"，则清除目标。
评估模型无法调用工具或查看文件，只能基于对话记录中的信息进行判断。它可以识别提前终止的情况，但无法判断继续运行一千万次求解迭代是否有价值。详见Anthropic官方goal文档。
需注意Claude Code并非开源，我们的认知完全基于Anthropic官方披露的信息。
Codex：持久化状态与生命周期工具
我还研读了本次测试所用版本Codex CLI 0.144.4的源码。Codex将目标视为持久化的线程状态：
- 终端界面（TUI）保存当前线程的目标，SQLite存储目标状态和预算核算信息。详见TUI实现、数据库 schema
- 工作模型可调用
create_goal、get_goal和update_goal工具。详见工具规范 - 若目标未完成但线程进入空闲状态，Codex会注入一轮延续推理，附带目标要求和完成度审核。详见运行时逻辑、提示词模板
Claude将完成判断交给独立模型，而Codex则让工作模型自行宣告完成，且在目标持续期间可随时恢复任务。Claude的评估器独立但仅能访问对话记录，Codex可访问文件和工具，但本质上是自我评估。
为何/goal赢了多数单轮，却不适合作为默认设置
在常规编码任务中，进度往往清晰可见：多一轮推理可能就能修复测试用例或完成迁移。但优化问题不同，一旦模型选定了求解策略，额外的时间可能放大正确决策的优势，也可能加剧错误决策的影响。
本次测试正是如此：当/goal让Fable持续运行高效的编译型求解组合，或是让Sol成功完成链重构时，就能带来提升；但当Fable构建了低效求解器，或是Sol陷入 exhaustive anchor sweep（ exhaustive锚点遍历）时，/goal就会导致性能大幅倒退。中位值虽小幅向好，但尾部的糟糕结果恶化程度远大于此。
局限性说明
本次测试仅针对一道未公开的NP难任务，并非通用编码排行榜。只有Fable和Sol拥有3组完整的对照测试数据，其他模型的测试混合了不同提示词、封装版本和时间限制，且测试通过订阅服务串行执行，期间服务可能存在性能波动。
尽管任务元数据声明使用1核CPU，但容器实际分配了8核，这对Fable的并行求解组合更为有利。所有Fable和Sol的输出均有效，部分原因是封装工具要求生成早期检查点并进行最终验证。本次基准测试衡量的是完整系统的性能，包括模型、命令行界面、提示词、订阅服务和测试框架。
复现方法
基准测试任务、封装工具、分析脚本、图表生成器及完整测试记录均收录于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模式的优劣，而是：一个持久化功能可能在多数单轮测试中获胜，却拉低整体平均性能。在复杂优化问题中，循环控制逻辑的质量，远不如循环持续执行的任务本身的质量重要。