OpenAI发布GPT-5.6构建者指南

OpenAI 在 8 月 13 日发布的《The builder’s guide to GPT-5.6》给 GPT-5.6 系列重新定义了购买和使用方式。文章把模型选择、Responses API 控制项、保留推理、上下文压缩、程序化工具调用、多 Agent 编排和提示缓存放进同一套工程预算里。

最硬的新闻锚点来自官方同日长文和 RSS 条目。采集正文摘要显示，OpenAI 称 GPT-5.6 Luna 在 BrowseComp 上得到 84.04%，接近三个月前 GPT-5.5 Extra High 的 84.36%；同一示例的任务成本从 33.27 美元降到 1.33 美元。这组数字必须按官方示例理解，不应写成所有任务自动降价，也不应写成独立机构已复现。

另一组数字落在长程智能体执行。OpenAI 称，在 ARC-AGI-3 示例中，GPT-5.6 Sol 加入 retained reasoning 和 compaction 后，分数从 13.3%升至 38.3%，同时输出 token 约少 6 倍。这组数据强调的是工作记忆管理：模型保留此前推理状态，再把上下文压缩成后续步骤可用的摘要。

对开发者和企业买方而言，这份指南的影响在于评估口径变化。过去常见问题是“哪个模型分数最高”或“每百万 token 单价是多少”。OpenAI 现在希望讨论的是：某个任务要用哪个模型档位、多少保留推理、怎样压缩历史、怎样设计工具调用、共享提示能不能缓存，以及这些控制项合起来能否降低一次成功任务的总成本。

从模型表到工程预算

GPT-5.6 构建者指南首先改变的是模型选择语境。OpenAI 把 Sol、Luna 和旧 GPT-5.5 放进任务预算：前沿任务需要更强推理，批量任务需要更低单位成本，长程智能体任务则要在成功率、上下文长度、工具调用和缓存命中之间做取舍。

BrowseComp 示例最适合说明这种变化。若只看分数，84.04%与84.36%几乎是“接近旧高档位”的叙述；若加上成本，1.33 美元与33.27 美元才是 OpenAI 想让开发者记住的工程信号。它在表达：同样接近前沿的任务表现，不一定需要继续使用旧的高推理档位。模型路由开始变成成本控制系统的一部分。

但这组数字仍有三个边界。第一，它来自 OpenAI 自报的示例，公开材料没有给出完整任务集合、重试策略、评测运行日志和第三方复测。第二，BrowseComp 是特定任务，不代表编码、客服、法律抽取或内部数据分析。第三，任务成本不等于企业总拥有成本，真实生产还会叠加工程维护、人工复核、失败重试和延迟成本。

数字	OpenAI指南中的口径	中文报道应保留的边界
84.04% vs 84.36%	GPT-5.6 Luna 与 GPT-5.5 Extra High 的 BrowseComp对照	接近旧基线，不是全面超过旧模型
$1.33 vs $33.27	同一官方示例中的任务成本对照	是示例成本，不是所有任务的新价格
13.3% 到 38.3%	Sol在ARC-AGI-3加入保留推理和压缩后的变化	是特定harness结果，需等待复现
约少 6 倍	ARC-AGI-3示例中的输出token变化	指输出token，不等于总token或总成本
至少 30 分钟	Prompt cache TTL最低延长口径	是缓存寿命下限，不是永久缓存承诺

这也是为什么本篇把信源置信分成两层：发布事件本身置信度高，因为官方博客和 RSS 同日确认；案例效果置信度中等，因为它们是官方自报，缺少独立复算。这样的区分比简单写“OpenAI成本降低二十多倍”更接近事实。

Responses API成为组织Agent的承载层

指南把 Responses API 放在核心位置，并不是偶然。OpenAI 的 API 文档中，Responses 是把模型输出、工具调用、函数调用和多轮状态统一起来的接口层。对单轮聊天应用来说，这像是一次接口迁移；对智能体系统来说，它是把任务拆成可保留、可压缩、可缓存、可审计的执行链。

OpenAI 在采集摘要中强调了几类 API controls：reasoning continuity、multi-agent orchestration、programmatic tool calling、retained reasoning、compaction 和 prompt caching。中文不能把这些都压成“更会调用工具”。它们分别对应不同成本项。

Reasoning continuity 解决的是长任务中“下一步是否知道上一轮为什么这么做”。Retained reasoning 关注推理状态能否跨步骤延续。Compaction 关注历史是否能压缩成足够准确但更便宜的上下文。Programmatic Tool Calling 关注工具输入输出是否能按程序结构组织，减少模型反复解释工具的开销。Prompt caching 则关注静态前缀能否被复用。

这条链路解释了为什么 OpenAI 会同时引用 Rogo、Ploy 和 Hypha。Rogo 案例说 Programmatic Tool Calling 使用 21% 更少输入 token；Ploy 案例有一个 29,000-token 的共享 prompt，并称未缓存输入减少 28%；Hypha 案例说 Luna 保持 GPT-5.5 抽取准确率的 98%，成本为十八分之一。三者不是同一个 benchmark，而是三种工程控制面：工具结构、共享前缀和模型路由。

客户案例该怎样读

客户案例的价值，不在于让所有团队照抄同一个百分比，而在于提示应该从哪里量化自己的系统。Rogo 的 21% 更少输入 token，指向工具参数和调用结构；Ploy 的 29,000-token 共享 prompt，指向多 Agent 系统里的静态上下文复用；Hypha 的 98% 抽取准确率和十八分之一成本，则指向能否把低成本模型放到足够可靠的子任务上。

这些数字都不能跨场景直接外推。金融研究、代码修改、合规抽取、销售线索整理和设计审稿的失败成本不同，人工复核比例也不同。一个能在信息抽取中用 Luna 承担的任务，未必能在法律意见、支付审批或生产变更中直接替换更高档位模型。模型路由的前提，是每类任务有自己的验收指标和回退路径。

更实用的读法是把指南拆成四个可测试问题：

任务是否真的需要最高推理档位，还是可以先用低成本模型筛选、抽取或生成草稿？
历史上下文中哪些内容必须逐字保留，哪些可以通过 compaction 变成结构化摘要？
工具定义、系统提示和政策约束是否足够稳定，能够命中 prompt cache？
多 Agent 协作中是否存在一个大共享 prompt，使缓存收益超过编排复杂度？

如果答案都不清楚，直接迁移到 GPT-5.6 的某个“推荐架构”反而可能增加成本。长任务的主要浪费常常不是模型单价，而是无效工具调用、重复读取、过长上下文、失败重试和人工返工。OpenAI 的指南把这些浪费放上台面，但没有替每个团队完成计量。

因此，落地团队需要先建立任务级验收口径。每个子任务至少要记录一次成功交付需要多少轮模型调用、多少次工具调用、多少输入输出 token、缓存命中多少、人工复核耗时多长。没有这些日志，团队只能看到单次调用价格，看不到一次可交付结果的真实成本。

缓存、压缩和保留推理的共同目标

Prompt cache TTL 最低延长到 30 分钟，看起来只是一个平台参数，实则关系到智能体应用能否把长任务拆成多轮而不反复支付同一段静态上下文。OpenAI Prompt Caching 文档的背景逻辑是前缀复用：系统提示、工具定义、规范、长文档和共享知识如果保持稳定，后续请求就有机会复用缓存。

Compaction 解决的是另一类问题。Agent 读过多个文件、调用过多个工具、排除过多个错误路径后，下一步通常只需要“当前假设、已验证事实、失败分支和下一步计划”。把这些内容压缩成稳定摘要，可以减少上下文，也能让后续推理更聚焦。

Retained reasoning 则更微妙。它让系统在多步任务中保留对后续有用的推理状态，且无需把模型的全部思考链暴露给开发者。OpenAI 在 ARC-AGI-3 示例中把它和 compaction 放在一起，给出了从 13.3% 到 38.3%的变化，同时输出 token 约少 6 倍。官方想强调的机制是保留有用推理状态，并压缩不该重复的上下文。

三者合起来，构成了长程智能体的成本纪律：缓存处理稳定前缀，压缩处理历史膨胀，保留推理处理跨步骤连续性。任何一个环节缺失，任务都可能变成“每一步都重新读题、重新解释工具、重新构造上下文”。这对 demo 影响不大，对企业生产任务则会快速放大为延迟、费用和可靠性问题。

这份指南没有证明什么

第一，它没有证明 GPT-5.6 Luna 在所有任务上都可以替代 GPT-5.5 Extra High。BrowseComp 的 84.04% 与 84.36%只能说明一个官方示例中的接近表现。若任务需要更强数学推理、更严格事实性或更低失败率，仍要用自己的评测和回退策略判断。

第二，它没有证明保留推理和压缩一定让所有 Agent 变得更便宜。ARC-AGI-3 示例显示分数提高且输出 token 减少，但真实生产还会有输入 token、工具输出、失败重试、缓存失效和人工复核。输出 token 约少 6 倍是一个重要信号，不是完整总成本报表。

第三，它没有证明客户案例的百分比可以照搬。Rogo 的 21%、Ploy 的 28%、Hypha 的 98%与十八分之一成本，都与各自任务结构、提示格式、工具边界和质量要求绑定。更稳妥的写法是“OpenAI引用客户案例称”，而不是“企业使用GPT-5.6都会减少多少成本”。

第四，Prompt cache TTL 至少 30 分钟不能写成“缓存永久有效”。TTL只说明缓存条目在最低时间窗口内可复用的口径，实际命中还取决于前缀是否稳定、请求是否共享足够长的静态内容，以及应用是否把动态用户输入放在后部。

早报观点

这份指南把 GPT-5.6 的竞争单位从“单次回答”推到“完成一个长程任务的工程系统”。成本、压缩、缓存、工具调用和多 Agent 编排同时进入官方指南后，开发者仅靠模型榜单已经不足以做架构决策。

早报判断是，GPT-5.6 的商业卖点正在被重新包装为可调预算。高推理模型负责难题，低成本模型负责可验收子任务，Responses API 负责把状态、工具和缓存串起来。这个方向对OpenAI有利，因为它把模型差异嵌入平台控制面；也对成熟团队有利，因为他们可以用自己的评测把任务拆成更精细的成本单元。

风险在于，官方示例很容易被过度翻译成“便宜二十多倍”或“智能体成本已解决”。真实系统里，失败重试和人工返工往往比单次 token 价格更贵。若没有任务级验收、缓存命中监控、工具调用日志和模型路由策略，构建者指南只会变成更复杂的提示工程清单。

这也意味着下一轮竞争会落在可观测性上。谁能把一次任务的输入、输出、工具调用、缓存命中、压缩质量、失败重试和人工复核统一计量，谁才有资格判断 GPT-5.6 的这些控制项是否真的省钱。没有这层账本，所有百分比都只能停留在厂商案例。

接下来要看四类复现

第一类是 benchmark 复现。BrowseComp 的 84.04% 与 1.33 美元要和完整运行设置一起公开，才便于外部团队判断它是否稳定接近旧 Extra High 的 84.36%。ARC-AGI-3 的 13.3% 到 38.3%也需要披露 harness、样本、工具配置和失败重试，才能区分模型能力、状态保留和压缩策略各自贡献。

第二类是生产账本复现。Rogo、Ploy 和 Hypha 的案例如果能公开更细指标，就能帮助其他团队迁移方法：总输入 token、未缓存输入、缓存命中率、工具调用次数、输出 token、人工复核时长和最终通过率。单个百分比能提示方向，完整账本才能指导架构。

第三类是平台行为复现。Prompt cache TTL最低 30 分钟需要在多区域、不同负载和长任务队列中观察实际命中率。缓存时间足够长，但前缀频繁变化，收益仍可能很低；前缀稳定，但任务间共享内容不足，收益也会受限。

第四类是框架默认值复现。若 LangChain、LlamaIndex、OpenAI Agents SDK、企业内部 Agent 平台开始默认支持保留推理、压缩历史、确定性工具排序和共享 prompt 缓存，OpenAI 的构建建议才会从官方文章进入行业默认实践。在此之前，它更像一份方向清晰、数字诱人、仍需团队自测的工程路线图。