深拆 OpenAI GPT-5.6 效率工程:Agent 的账要按完整循环算,Harness 四板斧首次成文

引子:一篇讲"效率"的博文,藏着 Harness 设计的第一手资料

2026 年 7 月 29 日,OpenAI 发布工程博文 《How GPT-5.6 fuses frontier intelligence with frontier efficiency》,署名作者五人,其中包括 Triton 语言的原作者 Phil Tillet。表面看这是 GPT-5.6 发布(7 月 9 日)三周后的一篇成本宣传文,但真正值得逐段精读的,是它第一次在官方口径下成文披露了 Codex 与 ChatGPT Work 共用的 agentic harness 设计原则——工具按需发现、工具输出限幅、历史只追加、工具顺序确定化。

一句话概括全文立场:Agent 的性能与成本,记账单位不是单次推理,而是完整循环。 原文的表述值得原样引用:

If a task requires 30 model requests, an extra second per request adds up. Improving overall performance means reducing repeated work throughout the system, not just making the model faster.

一个任务要发 30 次模型请求,每次多一秒就是三十秒;让系统变快的路径是消除全链路的重复工作,而不只是让模型更快。拆开看,这篇博文实际讲了两层东西:

1. Harness 层:一个用 Rust 写的编排层如何通过四条设计纪律,把每次请求的边际成本压下来;
2. 推理栈层:GPT-5.6 Sol 如何在 Codex 里被用来优化它自己的 serving 基础设施——负载均衡、GPU kernel、投机解码的 draft 模型、KV cache 配置,四件事全部由模型参与完成,端到端 serving 成本降了 20%。

结论先行:这篇博文的信息增量不在跑分,而在于它把 harness 确立为与模型、推理引擎并列的第三个优化层,并且给出了这个层的具体设计准则。对做 Agent 工程的人,这四条准则每一条都可以直接对照自己的循环实现自检;对观察行业的人,更值得注意的是 OpenAI 与 Anthropic 在这一层的设计正在肉眼可见地收敛。

(文中事实与引文以 2026-07-31 时点的官方博文、官方文档与公开报道为准,基准数字标注口径,来源见文末。)

〇、背景板:GPT-5.6 家族与它的规模前提

先把三周前的发布交代清楚,后面的成本论证都建立在这组数字上。7 月 9 日,GPT-5.6 以三档模型的形态发布:

型号	定位	定价(输入/输出,每百万 token)
GPT-5.6 Sol	旗舰,编码/知识工作/网络安全/科学	$5 / $30
GPT-5.6 Terra	均衡档,官方称与 GPT-5.5 智能相当	$2.50 / $15
GPT-5.6 Luna	速度与成本优先	$1 / $6

效率博文里的两句定价话术与之吻合:Terra"以一半价格达到 GPT-5.5 的水平",Luna"比 Sol 便宜 80%"($1 vs $5、$6 vs $30,输入输出侧一致)。旗舰侧的官方口径是 Sol(max reasoning)“在 Artificial Analysis Coding Agent Index 上超过 Claude Fable 5,成本不到一半”——第三方报道给出的分数是 80 对 77.2。需要补一句平衡:同一批报道里,SWE-Bench Pro 上 Sol 为 64.6%,仍落后 Anthropic 阵营约 15 个百分点,"谁是编码第一"在 2026 年 7 月是个分基准讨论的问题,本文不展开。

规模前提是另一半:官方数字是四年做到 10 亿活跃用户、200 万企业客户。在这个体量上,效率不是锦上添花,是 serving 成本表上最大的杠杆——这也解释了为什么这篇博文读起来是一篇系统工程文,而不是研究报告。

训练侧留一句后面要用的话:GPT-5.6 被训练为 “achieve more work per token”,训练目标同时优化任务成功率与效率,“shaping the model to take a more direct path through a task”——即用更少的 token 走完同一个任务。记住这个说法:token 效率在训练目标里,循环效率在 harness 里,两层是配套的。

一、成本模型:为什么"完整循环"才是正确的记账单位

1.1 Agent 循环的平方律

Agent 循环的成本结构,OpenAI 在今年 1 月 23 日的《Unrolling the Codex agent loop》里讲得更直白,7 月这篇是它的浓缩版。机制如下:

一个 turn(从用户输入到最终回复)内部,模型要经历多轮"推理 → 工具调用 → 结果回填"的迭代。Codex 的典型单 turn 动作链:查源码、搜部署历史、读事故报告、改文件、跑测试——每一步都是一次完整的模型请求。而每次请求都要把系统指令、工具定义、全部历史消息与此前所有工具结果重新发给 GPU。

于是有一个容易被忽视的事实:上下文随步数线性增长,每步都全量重发,一个 turn 内处理的总 token 量是步数的平方量级。Unrolling 原文的说法是,agent loop 的开销"quadratic in terms of the amount of JSON sent"。30 步的任务,不做任何复用,前缀部分要被重复计算 30 遍。

把平方律打回线性的机制只有一个:prompt caching。KV cache 的物理机制决定了它的杠杆有多大——

When processing uncached input tokens, the model builds the key-value (KV) cache in one compute-intensive pass; when generating output, it repeatedly reads from and extends that cache.

未命中缓存的输入 token 要走一遍计算密集的 prefill 把 KV cache 建出来;命中前缀缓存,这段计算整体免掉。前缀不变 → 每个 token 的 KV 只算一次 → 总量回到线性。Agent 场景下,cache 命中率不是可观测性指标,是成本函数的一阶变量。

1.2 缓存的经济学:一笔示意账

GPT-5.6 这次把缓存计费也明码标价了(Responses API):显式 cache breakpoints,缓存最短保活 30 分钟,缓存写入按未缓存输入价的 1.25 倍计,命中读取享 90% 折扣。

按 Sol 的 $5/1M 输入价做一笔示意估算(简化:设前缀 5 万 token,忽略每步增量,30 步/turn):

• 全程不命中:30 × 50k × $5/1M ≈ $7.50
• 首步写缓存 + 后 29 步命中:50k × $6.25/1M + 29 × 50k × $0.50/1M ≈ $1.04

同一个 turn,约七倍成本差,且前缀越长、步数越多,比值越悬殊。这个数量级与第三方实证一致:arXiv 上今年 1 月的评测《Don’t Break the Cache》(arXiv:2601.06007)在 OpenAI/Anthropic/Google 三家模型上测得 prompt caching 为长程 agent 任务降本 41%–80%,TTFT(首 token 延迟)降 13%–31%。同一篇论文也给出反直觉数据:缓存策略选错(全上下文乱缓存)时,GPT-4o 的 TTFT 反而回退 8.8%——缓存不是免费午餐,前缀纪律才是。

至此,harness 的设计目标可以精确表述:在循环的每一步,最大化前缀复用,最小化进入上下文的无效 token。 四板斧全部由此推出。

1.3 补一刀:步数本身也是优化对象

按完整循环记账,还有第二个刀口:不只让每步更便宜,还要让步数更少。GPT-5.6 发布时在 Responses API 里同步上线的 Programmatic Tool Calling 就是干这个的——模型不再逐个发起工具调用、等结果回填、再发下一个,而是写一段轻量程序(在无网络访问的隔离 V8 运行时里执行)一次性编排多个工具:协调调用、处理中间结果、监控进度,中间数据不必逐轮回流模型上下文。第三方报道给出的客户口径是 token 消耗减少 38%–63.5%。同批发布的还有 multi-agent beta:单个请求内跑并发子 agent 并汇总。方向是一致的:把确定性的编排逻辑从"模型逐步决策"下沉为"模型生成代码、运行时执行",模型请求数与重发的上下文同时被砍。训练侧的 “more work per token”、harness 侧的缓存纪律、API 侧的编排下沉,是同一个成本函数的三条下降路径。

二、Harness 四板斧

2.0 Harness 是什么

原文定义只有一句:

…our agentic harness, which is a Rust orchestration layer connecting our models, tools, and the user’s environment.

连接模型、工具与用户环境的 Rust 编排层。Codex CLI 与 ChatGPT Work 共用这一层。它管的是模型之外的一切循环事务:上下文组装、工具注入与调度、沙箱与审批、历史维护。四板斧分两组:前两条治"上下文膨胀"(避免无效 token 进场),后两条保"前缀稳定"(让进场的 token 可复用)。

2.1 工具按需发现(deferred discovery)

The harness can reduce this overhead through deferred discovery, which makes integrations, custom MCP tools, skills, and plugins only surfaceable when needed.

问题面:接入的 MCP server、skills、plugins 越多,常驻上下文的工具定义越厚。原文点了三宗罪:推高成本、分散模型注意力、诱发不必要的推理——工具定义不是免费的元数据,是每步都要重新付费、还会干扰决策的活跃上下文。

解法是把"全量注册"改为"按需浮现":集成、自定义 MCP 工具、技能、插件默认不进上下文,需要时才可被发现加载。这与 Anthropic 在 Claude API 侧的 Tool Search Tool + defer_loading 是同一个设计:工具定义延迟加载,模型先检索再获取 schema。两家在 2025 年底至 2026 年先后落地同构方案,可以视为这个问题的行业标准答案已经收敛。

值得一提的是它与 MCP 生态的互动:大规模挂接 MCP server 时,工具列表既大又不稳定,恰好同时踩中"上下文膨胀"与"前缀失效"两个坑。deferred discovery 把工具定义挪出常驻前缀,等于把 MCP 的不稳定性隔离在缓存边界之外。

2.2 工具输出限幅(output capping)

Tool output is capped at 10,000 tokens by default unless the model requests a different limit.

工具输出默认截断在 1 万 token——除非模型主动申请调整上限。这条纪律针对的是上下文膨胀的另一半来源:单次 cat 一个大文件、一个啰嗦的 MCP 集成返回全量 JSON,一发工具调用就能把窗口吃掉一截,而且这些 token 会随 append-only 的历史在后续每一步被反复重发、反复计费。

设计上的巧思在后半句:上限是模型可协商的。harness 不做一刀切,默认保守,把"这次我确实需要读全量"的决定权留给模型。限幅是护栏,不是天花板——这比常见框架里写死的 truncate 更进一步,把上下文预算的管理做成了模型与 harness 之间的协议。

2.3 历史只追加(append-only history)

…the harness treats all model-visible history as append-only: new messages, tool results, and environment updates are added at the end rather than inserted into earlier context.

一切模型可见历史只追加:新消息、工具结果、环境更新一律排在末尾,绝不插入或改写早先内容。原因就是 1.1 节的前缀命中——改历史 = 烧缓存。

这条纪律的彻底程度,Unrolling 一文里有个更具体的注脚:Codex 把沙箱范围、审批策略这类权限说明作为靠前的 role=developer 消息注入;用户中途改权限时,harness 不回去改那条旧消息,而是在末尾追加一条新的——宁可让两条配置消息共存、由模型理解"后者覆盖前者",也不动前缀一个字节。

Append-only 还有一个绕不开的对手:上下文压缩。窗口逼近上限时,压缩(compaction)必然重写历史、必然烧掉缓存。Codex 的处理是把它做成显式的、低频的例外:超过 auto_compact_limit 才调用 /responses/compact,拿回一份替换清单,其中含一个内容加密的不透明 type=compaction 条目,保留模型对前文的理解。日常步进严格 append-only,压缩作为受控的缓存重置点被摊销——例外被工程化,而不是被放任。

2.4 工具顺序确定化,运行时配置外置

Tools are also presented in a deterministic order, while runtime settings, such as approval policies, are applied during execution instead of being embedded in tool definitions.

前缀命中要求的是字节级一致。工具列表内容没变、只是序列化顺序变了——比如从一个无序 map 里遍历出来——前缀就已经失效。这不是纸面风险:Unrolling 里承认,Codex 早期 MCP 支持有过一个 bug,“failed to enumerate the tools in a consistent order”,工具枚举顺序不稳定,直接造成大量缓存 miss。确定性排序是用生产事故换来的纪律。

后半句同样重要:审批策略这类运行时设置不嵌进工具定义,而是在执行时生效。逻辑同构——工具定义位于缓存前缀内,任何配置变更若表达为工具 schema 的改动,等价于烧掉整条前缀;把可变配置抽离到执行层,工具定义才能保持字节稳定。一句话:可变状态不入前缀。

顺带指出一个生态呼应:MCP 2026-07-28 规范(上一篇拆过)在无状态化改造里同样写入了"工具列表 SHOULD 确定性排序",并为 tools/list 加上 ttlMs/cacheScope 缓存元数据。协议层与 harness 层在为同一个东西服务:喂饱两级缓存——HTTP 层的列表缓存,与 LLM 层的 prompt cache。

2.5 四板斧其实是一件事

把四条放回 1.2 节的目标函数里,会发现它们是同一个不等式的四个投影:

纪律	作用面	机制
按需发现	少进场	工具定义不常驻,按需浮现
输出限幅	少进场	默认 10k 截断,模型可协商
只追加	可复用	前缀字节不变,平方降线性
顺序确定化 + 配置外置	可复用	序列化稳定,可变状态不入前缀

原文对成效的表述克制:这些设计"contributes to Codex’s and ChatGPT Work’s high overall prompt-cache hit rates",没给具体命中率数字。但结合 1.2 节的账,方向没有歧义。

三、另一半故事:模型在优化自己的推理栈

博文前半段(Accelerating inference with GPT-5.6 Sol)与 harness 无关,却是全文最值得玩味的叙事:四项推理栈优化,全部由 GPT-5.6 Sol 以 Codex agent 的身份参与完成。 模型在优化 serving 它自己的基础设施。

负载均衡。请求按地理、容量、加速器类型、上下文长度、缓存可用性做全局与集群内路由。Sol in Codex 被用来分析生产流量、找出此前被忽略的不均衡来源、测试新路由策略、持续调参。官方说这一项"dramatically reduced the cost of serving our models",未给单项数字。

GPU kernel 重写。原文表述是 “GPT-5.6 Sol autonomously rewrote and optimized our production kernels”——Sol 自主重写了生产 kernel(Triton 与 Gluon 两种开源 GPU 编程语言),识别可预计算、可规避、可并行化的工作。正确性靠验证工具兜底:开源的 FpSan(Floating-Point Sanitizer)用于校验模型写出的 kernel。这一项连同相关 kernel 改进,端到端 serving 成本降低 20%。注意训练闭环:GPT-5.6 被专门训练过写 Triton/Gluon kernel 的能力——先把能力训进去,再让模型用这个能力优化自己的推理成本。

投机解码。机制是经典的 draft model 方案:小模型(speculator)提议多个 token,主模型并行验证。增量在于:Sol 自己设计并运行了数百个实验来改进它的 draft 模型——调结构、调规模、调特征——并且"launched and monitored the speculator training process, autonomously intervening when issues arose",自主启动、监控 speculator 训练并在出问题时介入。产出:token 生成效率提升超过 15%。

KV cache 与 serving 配置。batching、sharding、KV 管理的最优配置高度依赖负载特征(prompt/输出长度、batch 大小、缓存命中率、查询特征),配置空间大到无法系统性人工调优,工程师此前只能靠粗粒度启发式。Sol in Codex 被用来分析生产负载、生成并评估候选配置,做到按场景的 “hyper-optimize”——同样的硬件榨出更多有效推理。

这一段与其说是效率报告,不如说是 OpenAI 在演示"agent 化的基础设施工程":流量分析、kernel 优化、训练运维、配置搜索,四种传统上分属不同团队的工作,统一收敛为"Sol in Codex + 验证工具"的模式。人类的角色从执行者移到验证器与护栏的建设者——FpSan 这类工具的地位因此上升:模型产出的吞吐越大,正确性验证的基建越是瓶颈。

四、体检清单:把四板斧对照到你自己的循环上

四板斧没有任何 OpenAI 私有依赖,每条都能直接翻译成对任意 agent 框架的自检问题:

1. 工具集是否全量常驻? 数一下你每次请求发出的 tool schema 有多少 token。超过两位数个工具就该上按需加载——OpenAI 侧是 harness 内建的 deferred discovery,Anthropic API 侧有现成的 Tool Search Tool(defer_loading),自建框架可以用"检索工具 → 取 schema → 调用"的两段式模拟。
2. 工具输出有没有限幅?模型能不能协商? 检查最长的一次工具返回。没有默认截断的,一个大文件读取就能污染整个后续循环;写死截断不给模型协商通道的,复杂任务会在信息不足处反复空转。
3. 历史有没有被中途改写? 常见破坏者:把系统提示里的时间戳/UUID 做成动态的、往历史中段插入状态通知、每步重排消息、把运行时配置塞进 system prompt 并频繁更新。《Don’t Break the Cache》把动态 system prompt 内容列为第一大缓存杀手,与本文完全互证。
4. 工具序列化顺序是否确定?配置变更走的是哪条路? 语言里的无序 map、并发注册、按连接顺序枚举 MCP server,都会复现 Codex 踩过的那个 bug。运行时可变的东西(审批策略、权限范围、feature flag)一律不进工具定义。
5. 附加一条计费侧的: 在 OpenAI Responses API 上主动打 cache breakpoint(30 分钟保活窗口内组织好复用),在 Anthropic API 上用 cache_control 显式标记前缀——两家都已把缓存边界的控制权交给开发者,cache 命中率应该进你的 SLO 面板,和延迟、错误率并列。

五、三个判断

判断一:Harness 正式成为第三个优化层,“harness engineering” 会成为一个工种。 这篇博文的结构本身就是宣言:研究(训练 token 效率)、推理栈(kernel/调度/投机解码)、harness(循环纪律)三层并列署名。Agent 的单位任务成本是三层的乘积,任何一层摆烂都会吃掉另外两层的努力——模型再强,一个每步烧缓存的 harness 能把成本放大一个数量级。OpenAI 今年 1 月起连发 Unrolling、App Server、Harness engineering 数篇工程文,与 Anthropic 在 Agent SDK/Claude Code 上的公开设计(工具延迟加载、上下文压缩)对读,头部两家在这一层的竞争已经从"有没有"进入"设计准则成不成体系"。

判断二:Prompt cache 正在反向塑造 Agent 的上下文架构,而且与协议层的演化同向。 Append-only 不是审美偏好,是 1.25x 写入价与 90% 读取折扣写成的经济约束;确定性排序不是代码洁癖,是字节级前缀匹配的物理要求。把视野放宽:MCP 2026-07-28 把工具列表做成确定性排序加 TTL 缓存、把会话状态从协议里删掉,与 harness 层的四板斧是同一条因果链的两端——整个 Agent 技术栈正在被"KV cache 前缀命中"这一个底层机制重新规训。 下一个待收敛点是压缩:compaction 与 append-only 的张力目前靠"低频显式重置"缓解,谁能把压缩做成缓存友好的(比如分段缓存、增量摘要),谁就拿下循环成本的最后一块。

判断三:效率优化本身 agent 化,飞轮已经在转。 Sol 重写 kernel 降 20%、改自己的 speculator 提 15%、调自己的路由与 serving 配置——这些优化降低的正是运行 Sol 的成本,省出的算力又用于训练与服务下一代模型。结尾那句官方表态(“The role of GPT-5.6 in delivering many of these improvements makes us optimistic about how the pace of optimizations will accelerate”)应当按字面理解:优化速度本身在被优化。对从业者,这里有一个冷静的推论——当模型参与压成本成为常态,价格战的底线由"谁的循环便宜"决定,而不只是"谁的模型强";而对每个写 agent 的人,第四节那五条自检,就是今天下午就能做的事。

参考

• How GPT-5.6 fuses frontier intelligence with frontier efficiency — OpenAI(2026-07-29,本文主拆对象:harness 四板斧、KV cache 机制、四项推理栈优化与 20%/15% 数字)
• Unrolling the Codex agent loop — OpenAI(2026-01-23,循环平方律、工具枚举顺序 bug、compaction 端点、developer 消息追加式配置)
• GPT-5.6: Frontier intelligence that scales with your ambition — OpenAI(2026-07-09,Sol/Terra/Luna 定价、缓存计费:1.25x 写入、90% 读取折扣、30 分钟保活、显式 breakpoints)
• Harness engineering: leveraging Codex in an agent-first world — OpenAI(harness 工程系列)
• Unlocking the Codex harness: how we built the App Server — OpenAI(harness 架构系列)
• Tool search tool — Claude Platform Docs(Anthropic 侧 defer_loading 同构设计)
• Don’t Break the Cache: An Evaluation of Prompt Caching — arXiv:2601.06007(41–80% 降本、13–31% TTFT、缓存杀手清单的第三方实证)
• FpSan (Floating-Point Sanitizer) — Triton 文档(模型所写 kernel 的正确性验证工具)
• OpenAI Releases GPT-5.6: A Three-Tier Model Family — MarkTechPost(AA Coding Agent Index 80 vs 77.2、SWE-Bench Pro 对比等第三方基准口径)
• Codex agent loop — InfoQ(2026-02,Unrolling 一文的第三方解读)