结论

同一个模型，放在不同 agent 框架里跑，成绩和花费能差出一大截。当前最省心的组合是用模型厂商自己的客户端：

下面不谈体感，只摆三组可查的证据：harness 能把同一模型的分数拉开多少、厂商到底按模型做了什么特殊处理、token 账单差在哪。

一、先看 harness 能把同一模型拉开多少

这不是玄学，2026 年已经有一批可复现的数字。

① 同一个模型，四个 harness，四个分数

Claude Opus 4.5 在 SWE-bench Pro（731 题公开集）上：

权重完全一样，只是脚手架不同，差距接近 6 个百分点（来源）。

② 换 scaffold，能力上限能抬 20%

Epoch AI 复核 SWE-bench Verified 时发现，好的 scaffold 能把成绩抬高最多 20%，并记录了 Claude 3.7 从 62.3% → 70.2% 的跃升——模型没变，只换了脚手架。

③ 只改 harness 的受控实验

2026 年 8 月的对照实验（arXiv 2608.26218）冻结模型和任务，只改 harness 的一处行为（上下文将满时缩短旧工具结果、对重复/停滞的动作做响应）。在 169 题的紧窗口子集上：

1
2

平均单题 fail-to-pass 比例：28% → 49%
完全解出的题数：43 → 72

而且这处改动没有针对任何模型重新调参，对另外三个模型同样有效。

④ 理论侧的结论更直接

论文《Stop Comparing LLM Agents Without Disclosing the Harness》提出「绑定约束假说」：执行 harness 常常比它包裹的模型更能决定 agent 表现，而现在的评测协议一直在把 harness 的收益记在模型头上。

另一篇 position paper 的实测更细：同一个 scaffold 在不同 base model 上，token 预算效率能差 3–7 倍，结论是「效率是 scaffold 与 model 的联合属性，不是任何单独一半的属性」。

这就是”官方客户端更快”的第一层解释：它不是”某个模型”，它是”某个模型 + 为它调过的 harness”。

二、厂商到底”特殊处理”了什么

三件可查的事。

1. 每个模型一套系统提示词

Anthropic 在《The new rules of context engineering for Claude 5 generation models》里做了一次激进实验：把 Claude Code 的系统提示词删掉 80% 以上，编码评测没有可测量的下降。

关键在于配套的那句话——每个模型配一套不同的系统提示词，只有最前沿的 Opus 5 / Fable 5 享受这次削减，旧模型仍然跑完整版（解读）。

这就是”针对性优化”最直白的证据：同一家公司，不同模型，不同提示词。

2. 工具调用和循环控制按模型调

OpenAI 的 Codex 提示词指南里，工具行为是被明确规定的：

1
2

temperature = 0.2
tool_choice = "auto"      # 曾经是 "any"，逼模型每轮都调工具

理由是 GPT-5.x-Codex 在 auto 下会自己判断”有活就调工具、干完就自然收尾”。同一份指南还规定计划工具的用法：维护 2–5 个里程碑项，连续 8 次工具调用内必须更新一次计划（整理）。

第三方框架为了兼容几十家模型，只能写”大家都能懂”的版本——这是它的价值，也是它的上限。

3. 上下文压缩是自家实现

Claude Code 的系统提示里写着 “The conversation has unlimited context through automatic summarization”，实际背后是三层压缩在透明工作（分析）。

OpenAI 这边更直接：GPT-5.1-Codex-Max 引入上下文压缩后，SWE-bench Verified 从 73.7% → 77.9%，同时令牌消耗减少约 12%（报道）。

压缩策略必须贴着模型的退化点设计：哪一段开始失忆、哪些信息压掉不心疼、压缩后用什么结构接回去。通用框架只能按通用策略截断——经常”压完就忘了刚才在干什么”。

三、token 为什么更省：缓存经济学

省 token 从来不是”单价便宜”，而是重复前缀不重复付费。

（成本测算、对照）

命中缓存的前提是请求前缀稳定：系统提示、工具定义、历史消息的组织顺序不能变。官方客户端天然把这三样组织成稳定前缀；第三方框架每次拼装顺序稍有差异，缓存就失效，同样的对话要多付几倍的钱。

再叠加第一节的结论——轮次更少——账单差距就出来了：同样的活，官方客户端花的轮次少、每轮前缀命中率高。

四、三个组合怎么用

GPT-6 Astra → ChatGPT app

Astra 在 DevDay 2026 上是”最智能、最对齐”的模型，同时驱动 dots 这类常驻 agent（回顾）。订阅用户目前通过 ChatGPT Work 和 Codex 两个入口使用它，而不是普通 Chat；Codex CLI 需要 0.153.0 以上（说明）。

桌面端的入口就是：打开 ChatGPT app → 在 Chat / Work / Codex 之间切（帮助中心）。

适用：强工具调用、长链路任务、要和 ChatGPT 生态（文件、联网、多模态）打通的场景。

Claude Opus 5.5 → Claude app

Opus 5.5 的系统提示词是公开的（release notes）——这件事本身就说明厂商在按模型维护提示词。

客户端侧，Claude Code 那套终端工作流没有消失，而是并入了更大的产品面：新出的 Claude Duet 明确”围绕 Opus 5.5 设计”（介绍）。

适用：大型代码库、长时间连续改动、对 diff 质量要求高的场景。注意它对手册（CLAUDE.md / 项目约定）极其敏感，写得好坏比换模型影响更大。

DeepSeek V4.1 Flash → DSH

V4.1-Flash 的官方说明里有一句很关键：官方 V4-Flash 基准是用 DeepSeek Harness 的 minimal 模式跑的（更新日志）。也就是说，官方公布的分数本来就带着自家 harness。

同一个更新日志还写着 V4-Flash「原生支持 Responses API 格式，并专门为 Codex 做了适配」——厂商会主动去适配别人的 harness，但跑分和调优仍以自家 harness 为准。

DSH 的架构是”Agent = Model + Harness”，而且 harness 本身由插件组成，连 agent 循环都是插件（架构拆解）。

适用：高频、短回合、批量性任务——改配置、跑测试、批量重命名、日常小修。Flash 不要拿去啃需要深度推理的架构决策。

五、反证与边界

官方客户端不是万能的，这几类场景它反而更差：

判断规则：

1
2

任务在"官方客户端的能力范围"内 → 用官方
任务需要"跨模型 / 私有化 / 可编程" → 用开源 harness

六、已经习惯 OpenCode + OMO 的话

不用急着推翻。之前那套（半自动篇、全自动篇）解决的是”让 AI 持续帮我写代码”，官方客户端也在解，只是工作方式不同。

舍不得终端工作流的话，可以先试 omp（oh-my-pi）：保留终端优先、多代理、可换模型，同时把 IDE 能力（LSP、DAP、浏览器、桌面控制）内置了。详见 omp 使用指南。

现实路径：

1. 日常小活：直接切官方客户端，别折腾框架；
2. 需要多模型分工：留在 omp / OMO；
3. 需要跨厂商对比：留在开源 harness，保证脚手架一致——否则你测的是 harness，不是模型。

七、自己验证的方法

别信榜单，做一次 A/B：

1. 挑 5 个真实任务（不是玩具题），固定模型；
2. 官方客户端跑一遍，开源 harness 跑一遍；
3. 记录三个数：完成率、工具调用轮次、账单；
4. 只看差异稳定的那几项，单次波动当噪声。

第一节那组 45.89% vs 51.80% 的差距提醒我们：换 harness 的收益，可能比换模型还大。所以这个 A/B 值得做。

要点

1. 模型和 harness 是一体的。 把 Opus 塞进通用框架，等于主动放弃厂商为它做的适配——而且这部分收益在榜单上会被误记到模型头上。
2. harness 的影响是可量化的。 同一模型 6 个百分点、受控实验 fail-to-pass 28%→49%，都不是体感。
3. 省 token 靠前缀稳定 + 轮次少。 缓存读 0.10×，但前提是前缀不变；官方客户端天然满足。
4. 厂商按模型分发提示词。 前沿模型用精简版、旧模型用完整版，这已经是公开做法。
5. 官方客户端适合”干活”，开源 harness 适合”编排”。 前者优化单条链路，后者优化多模型协作。
6. 换之前先量化。 同一任务两边各跑一遍，看轮次、看 diff、看账单。

本文引用的数据均标注来源，产品与定价以官方文档为准。模型和客户端迭代很快，结论有时效性。