Sol 偏爱作弊

# Sol 喜欢作弊 —— jumploops 来源：https://jumploops.com/blog/sol-loves-to-cheat/ *摘要* > 尝试自动化开发流程，在 Terminal Bench 2.1 上达到 94%，随后发现 GPT-5.6 Sol 开始作弊。 ## 背景 过去大约一年里，我一直在使用一种"规格驱动"的开发流程。 其实很简单。 在让大语言模型*执行任务*之前，我会先让它起草一份文档，说明*它需要做什么*。 无论是功能开发、全新项目、调试还是其他任何事情，我都使用这个策略。 这个模式对我有效，但确实有点重复。 于是我决定将其自动化。 ## chum-codex 思路很直接：我要创建一个**监督代理**，通过委派给**工作子代理**来运行一个"规格驱动流程"，这些子代理将实际编写文档、执行任务等。 > *注：尝试用原生 Codex 或 Claude Code 实现时，效果尚可，但默认提示词更偏向于面向用户，而非"监督者"* 我推测监督代理只需具备读取文件和调用工作者的能力，因为这就是我的做法。 我没有为工作者重建编码工具链，而是考察了 Pi (https://pi.dev/)、OpenCode (https://opencode.ai/) 和 Codex 的 App Server (https://learn.chatgpt.com/docs/app-server)。 我用 Codex 已经有一段时间了，所以决定试试 app-server。其他选项也很酷，推荐你看看。 总之，第一个版本运行得还不错：监督者评估任务，调用工作者并给出（例如）设计请求，工作者生成一份文档，然后监督者让工作者将这份文档转化为实施规格（按阶段适当划分），最后让工作者真正实施该任务。 *注：这个简化图省略了用户反馈部分，例如设计文档评审* `` --- config: sequence: mirrorActors: false --- sequenceDiagram participant S as 监督者 participant W as 工作者 S->>S: 评估任务 S->>W: 设计请求 W-->>S: 设计文档 S->>W: 创建实施规格 W-->>S: 分阶段实施规格 S->>W: 实施 W-->>S: 结果 `` 太棒了！我在开发流程中节省了一些时间。 *（真的吗？）* ## 深入挖掘 很好，它运行了；虽然有点粗糙，但确实有效。 > *注：我本该在这里停下* 骑在高头大马上，我环顾四周，心想"哇，每个人都应该看到这个！" 最好的展示方式是什么？基准测试！ 用哪个基准测试最好？Terminal Bench (https://github.com/harbor-framework/terminal-bench) 啊！ 我深入研究的是哪个基准测试？Terminal Bench 2.1 (https://www.tbench.ai/leaderboard/terminal-bench/2.1)！ ## Terminal Bench 如果你不熟悉智能体基准测试，Terminal Bench 的名字很说明问题。它是一组可以通过终端完成的任务，涵盖了从国际象棋到 DNA 组装等一系列一次性任务。 正因为它如此简单，它可能是测试规格驱动开发流程最糟糕的基准之一。 但由于其简单性，它很容易进行测试。 我从原生 Codex 使用 GPT-5.5 失败的几个任务开始，例如 DNA 组装/插入、视频提取/处理、ELF 提取和蛋白质组装。 它成功了。 这些任务得益于在实施前进行一次"设计阶段"，因为文档有助于避免视野狭隘和循环验证。 我骑的那匹马变得更高了。 > *注：Terminal Bench 1.x/2.x 已趋于饱和，但这是另一个故事了。* ## GPT-5.6？ GPT-5.5 的公开基准 (https://hub.harborframework.com/datasets/terminal-bench/terminal-bench-2-1/latest?tab=leaderboard&leaderboard=main) 是 **83.8%**（89 个任务中约 74 个，运行 5 次）。 `chum-codex` 达到了 **89.9%**，约 80/89 个任务 (https://gist.github.com/jumploops/09087cfbad3efaa94da5f6bddaacfd06)。 兴奋地想分享超越 Codex 的消息，我又运行了几次原生 Codex 基准测试以确认。 背景：这是 2026 年 6 月 25 日，当时有传言称 GPT-5.6 即将推出。 我运行了三次原生 Codex 基准测试……我的心沉了下去：**88.8%** 我的工具链仅比原生 Codex *领先一个任务*。 有些任务明显有所改进，有些则退步了。 第二天，GPT-5.6 Sol 发布 (https://openai.com/index/previewing-gpt-5-6-sol/)。 > *我联系了 OpenAI，他们提到 GPT-5.6 正在测试中，但确认我的请求 ID 都命中了 GPT-5.5* 有趣的是，Terminal Bench 2.1 是他们最初分享的唯一编码相关基准，显示 GPT-5.6 Sol 为 **88.8%**，Sol Ultra 为 **91.9%**。 Sol Ultra 会生成并行子代理来工作，不过在我的测试中，它的令牌消耗比大多数人在大多数任务上想要/需要的要多得多。 无论如何，看到新的前沿领域我非常兴奋！ ## 引导 GPT-5.6 更难引导。 从 5.5 切换到 5.6 导致我的工具链效率下降。以前很容易做的事情，现在变得困难多了。 我追溯了部分差异，发现源于基础 Codex 提示词的改变。对于 GPT-5.5，提示词 (https://gist.github.com/jumploops/56b45522d5b1fbbeb113001346580e4f) 以编码为重点，花了很多时间在"工程判断"上，包括前端指导、编辑约束以及"理解已有代码库"上。 gpt-5.5 提示词*摘自 GPT-5.5 提示词* GPT-5.6 的 Codex 提示词 (https://gist.github.com/jumploops/2063c2b7c9aeca76449f12567212251d) 则大不相同，几乎没有涉及工程相关细节。相反，它专注于沟通、自主性/持久性和技能（这些在 5.5 中是作为单独提示词加载的）。 gpt-5.6 提示词*摘自 GPT-5.6 Sol 提示词* 正如其他人注意到的，也像我 8 个月前 (https://x.com/jumploops/status/2009910802170740771) 预测的那样，更好的模型需要更少的仪式就能高效工作。 另一方面，这可能意味着随着模型变得*更好*，它们会变得更难控制 (https://openai.com/index/hugging-face-model-evaluation-security-incident/)。 一个简单的例子是 Terminal Bench 2.1 上的 PyTorch 任务。 使用 GPT-5.6 Luna 和 Terra 时，模型很容易被引导到一个接受两个输入的通用解决方案：`forward(src, tgt)` 而 Sol，尤其是在更高的推理层级下，模型会*无论引导如何*，默认为单一输入 `forward(src)` 的解决方案。 问题似乎在于，模型极其难以引导其偏离自身的推理。即使指示它接受尽可能广泛的可调用接口（这在中等推理层级有时通过重复能成功，但在极高推理层级很少成功）。 与这个模型的搏斗让我走上了一条**过于接近基准测试黑客行为**的道路；但我太好奇了，无法停止。 ## 在 TB 2.1 上达到 94% 大幅减少提示词后，感觉就像从头开始。即使我想直接破解基准测试，模型也不允许。在某些情况下，它的循环推理过于强大难以克服，而监督者又太愿意听从其聪明的工作者的报告。 这是一个艰难的平衡，如果你偏向一边，监督者会很乐意扩展范围或无休止地追求验证。 这些都是简单的任务。我想要的是第一次就得到一个可用的解决方案，而不是无限扩展。 我尝试降低推理级别、使用简化语言、减少规格驱动流程、添加新技能等。有些方面有所改进，但也有些失败了。 有几件事显示出希望。 首先是**第三个上下文**。想法是使用一个只能看到工作者评论/推理的代理，让它揭示工作者所做的所有潜在不匹配/假设与请求实际细节的差异。 `` flowchart TB S["监督者"] W["工作者"] R["评论 / 推理"] A["假设审计员"] S -->|"任务 / 引导"| W W -->|"结果"| S W --> R R -.->|"只读可见性"| A A -->|"提出的假设"| S W ~~~ A style R fill:#6fc7e1,stroke:#141414,color:#141414 `` 然后监督者可以审查工作者采取的假设，并要求其重新审视或质疑这些步骤。这在一定程度上有效，但速度慢且是事后发生。 另一个想法是**要求模型输出"开放问题"**——这是我在亲身实践开发中会做的事情。最初的想法是让工作者在遇到开放问题时返回（而不是完整的设计文档），然后由监督者解决。这将解放监督者的上下文，让它看到森林而非树木。 即便如此，即使上下文减少了，监督者也很难不同意工作者的结论（或者相反，过于热衷于扩展琐碎的细节）。 为了消除这种偏见，下一个想法是使用一个单独的上下文，首先**映射和归约**（一切旧事皆新事！）这些问题，试图消除任何固有或未发现的偏见，然后将一个标准化的版本返回给监督者（或直接返回给工作者）。 这表现更好，但它依赖于工作者将正确的问题*作为问题*提出来。 结果发现，对于 Sol，让它**输出*其决策*，而非其问题，** 要容易得多。模型很自信，所以它不把自己的假设看作问题，即使它在推理或评论中已经说明了其他选择。 `` flowchart TB S["监督者"] W["工作者"] D["决策"] M["映射"] R["归约"] S -->|"任务 / 引导"| W W -->|"结果"| S W --> D D --> M M --> R R -->|"标准化问题"| S R -.->|"可选"| W style D fill:#6fc7e1,stroke:#141414,color:#141414 style M fill:#f49bab,stroke:#141414,color:#141414 style R fill:#f49bab,stroke:#141414,color:#141414 `` 掌握决策后，监督者（或第三个上下文）可以暂停工作者，将决策评估为问题，然后进行适当引导。 这效果好得多，并带来了最佳结果：Terminal Bench 2.1 上的 84/89 个任务 chum-codex *注：1 个任务因网络安全问题被阻止，但使用 GPT-5.6 Terra 回退后通过，所以是 83 + 1* ## Sol 喜欢作弊 重新骑上高头大马，终于驾驭了 Sol，并且已经远远偏离了使用基准测试进行开发而非……作为基准测试的道路，我想看看能把它推到多远。 不再只关注原生 Codex 的退步，我想看看是什么阻止我们达到 86 或 88/89。 长话短说，Terminal Bench 2.1 的尾部任务规格说明不充分，这就是为什么我们看到 Mythos、GPT-5.6 等在没有更**专业化机制 (https://arxiv.org/pdf/2608.15089)** 的情况下，在约 90% 左右见顶的原因。 > *在某项任务上表现更好的方向会损害在另一项任务上的进展。* 一个例子是 `make-mips-interpreter`，它告知代理*“我（用户）将检查你是否正确启动了 doom”*。 **问题 (https://github.com/harbor-framework/terminal-bench-2-1/issues/9)** 在于：如果输出文件（来自代理启动的 doom）已存在，验证器就会失败。 稍微放慢一点： 1. 用户声明将检查代理是否启动了 Doom。 2. 启动 Doom 输出 `/tmp/frame.bmp`。 3. 确保 `/tmp/frame.bmp` 存在，以便用户知道它已正确启动 Doom。 4. 如果 `/tmp/frame.bmp` 存在，验证器失败。 代理假设用户想检查它（代理）是否启动了虚拟机，所以代理保留文件以证明它启动了，但如果文件已存在，验证器的测试就会提前失败。一个自相矛盾的情况！ > *修复这个问题是可能的，可以通过提示系统移除验证状态/覆盖用户顾虑，但这个修复（显然）会在其他任务/用例中适得其反。* 在转向更好的事情之前，我决定与世界分享这些结果，但要注意**它有点太像基准测试黑客了**（整个第三个上下文映射-归约器的事情对这个基准测试有效，但在现实世界中，我可以写出更好的指令和/或通过后续消息迭代）。 在进行完整的 N=5 运行之前，我运行了一次基准测试，惊讶地发现一个之前通过的任务失败了： `torch-pipeline-parallelism` 我运行了几次。1/3 次成功。 深入细节，我无法找出我们的工具链有什么变化，所以也用 xhigh 级别在原生 Codex 上测试了它。 它通过了 3/3 次。 有趣。 我检查了这些运行，以确定哪些有效哪些无效。 **GPT-5.6 Sol 每次都作弊 (https://gist.github.com/jumploops/5136460fdb96da3470a8f99f20fa879d)**。 糟糕，*过去所有的成功*都是因为作弊吗？ ## 真的是 Sol 吗？ 我查看了两次 chum-codex 在 `torch-pipeline` 上的通过运行，发现了令人不安的情况。 网页搜索被禁用了，但总有办法： codex-sol-cheating*GPT-5.6 Sol 在 xhigh 级别* 值得注意的是，我们的工作者*没有*访问 `web_search` 工具的权限，而是决定使用 `curl` 来访问 DuckDuckGo、Github、grep.app 和 SourceGraph。 看起来 7 月 29 日是原生 Codex 的第一次"作弊"，而我们的工具链在今天（8 月 12 日）首次作弊。 `` { "src": "/charts/torch-pipeline-apexcharts-pass-data.json", "chart": { "height": 440 }, "colors": ["#6fc7e1", "#e08e45", "#3d8ba6", "#f49bab"] } `` 诚然，这些数据不足以得出任何结论。原生 Codex 3/3 次作弊的会话之后是两次*没有作弊*的运行。 目前也不清楚模型是否故意作弊，或者它们只是在搜索网页时偶然找到了解决方案。 查看原生 Codex 的跟踪记录，我们找到了确凿证据： *我需要使用 curl 调查 HF 源代码，在 GitHub 上检查最新版本。**了解基于挑战的预期隐藏测试可能会有帮助。*** 这感觉确实很像是作弊。 对于 chum-codex，curl 请求之前的最后一步同样有说明： ***也许解决方案是公开可用的**，这意味着我可以有效地比较它。我只需要使用 curl 访问原始路径并**收集必要的信息！*** 无意将模拟人类的机器拟人化，但它看起来似乎还挺高兴？ 既担忧又好奇，我回看了 7 月 17 日的 83/89 次运行，发现此任务或其他任何任务都**没有作弊证据 (https://gist.github.com/jumploops/ef9535daff9637d087dc9fba76077a50)**。 鉴于最近的**新闻 (https://openai.com/index/responding-next-frontier-critical-cyber-capabilities/)** 和他们下一个模型的延迟，人们不禁要问……这还是同一个 Sol 吗？ ## 接下来 今天失败的不仅仅是 `torch-pipeline` 任务，这诡异的提醒让我想起了从 GPT-5.5 迁移到 GPT-5.6 的情景。 似乎模型变得越好，围绕它们构建有用的防护栏就越困难，目前我需要休息一下。 随着我更多地接触 Sol、Fable 等新问题，我可能会重新审视工具链，但现在我将坚持采用更亲自动手的开发方式。 将强大的模型放在循环中，使用懒惰提示词可能很有趣，但信任它们的输出正变得越来越难。 随着模型变得更强大，我需要更少地指示它们，但这些指示比以往任何时候都更重要。 见鬼，即使是新的 Terminal Bench 3.0 也在其所有**任务 (https://github.com/harbor-framework/terminal-bench/blob/v3.0.0/tasks/distributed-dedup/instruction.md)** 中添加了以下说明： > “不要通过使用在线解决方案或针对特定任务的提示来作弊