AI 工程实践
GPT-5 首发复盘：ChatGPT 路由不是 API 模型合同，升级要按交付物回归
以 2025 年 8 月 7 日至 9 日的一手资料为边界，区分 ChatGPT 的快速模型、Thinking 与动态 router，以及 API 的 gpt-5/mini/nano/chat 交付，并给出上下文预算、工具语法、版本回归和单位任务成本方案。
时间与证据
本文研究的事件是 OpenAI 在 2025 年 8 月 7 日发布 GPT-5，并同时把它带入 ChatGPT 与 API 平台。同期信息截止到 8 月 9 日；文章发布日期与更新日期见页首。文章讨论的是首发交付边界，不把后来模型更新、路由调整、退役或新增参数倒填到 8 月 7 日。
主要证据分三组，每组都以发布日快照约束首发声明，再用 T+2 快照交叉检查信息截止日前的页面状态。第一组是 ChatGPT/研究首发页、8 月 7 日 17:44:56 UTC 的发布日快照及 8 月 9 日 00:28:10 UTC 的T+2 快照；第二组是 API 开发者首发页、8 月 7 日 17:13:44 UTC 的发布日快照及 8 月 9 日 02:19:39 UTC 的T+2 快照；第三组是 GPT-5 System Card、8 月 7 日 17:14:09 UTC 的发布日快照及 8 月 9 日 02:20:19 UTC 的T+2 快照。
三组材料必须一起读。ChatGPT 首发描述的是一个包含快速模型、较深推理模型 GPT-5 Thinking 与实时 router 的统一产品系统；API 首发则提供 gpt-5、gpt-5-mini、gpt-5-nano 三个推理模型，并用 gpt-5-chat-latest 暴露 ChatGPT 中的非推理模型。官方特别说明：API 的 gpt-5 即使设置 minimal reasoning，也不是 ChatGPT 非推理模型。
本文证据等级是 sourced。我核验了首发页、发布日/T+2 网页快照和系统卡，但没有获得 ChatGPT router 的内部规则、模型权重或首发 API 响应，也没有在 2025 年 8 月的服务端复放请求。文中所有 SWE-bench、Aider、Tau2、事实性和 token 效率数字均明确归属于 OpenAI 当时的厂商报告；任务路由、合同字段、评测集、状态机与门槛是本站设计，不是实测。证据边界还要求承认产品会动：ChatGPT router 被描述为持续从用户切换模型、偏好与正确性信号中训练；它本来就不是一个静态、对开发者可配置的 API 算法。生产系统若需要可重复选择、成本上限和回滚，必须在自己的控制面保存路由决定，不能从 ChatGPT 一次体验反推 API 行为。
当时发生了什么
同一个 GPT-5 名称承载了两种交付物
在 ChatGPT 中，GPT-5 是产品系统：快速模型回答多数问题，GPT-5 Thinking 处理更难任务，实时 router 根据对话类型、复杂度、工具需求和用户显式意图选择路径；额度用尽后还可能切换到 mini。用户看到的是一个入口，内部选择可以随产品信号更新。
在 API 中，开发者直接选择 gpt-5、gpt-5-mini 或 gpt-5-nano，它们对应面向开发者的推理模型档位；若需要 ChatGPT 的非推理模型，则使用 gpt-5-chat-latest。API 没有承诺复制 ChatGPT 的实时 router，也没有把“统一入口”变成可依赖的后台路由合同。这不是命名细节，而是架构责任差异：ChatGPT 可以为交互体验动态选择；API 应用必须对租户、任务、模型、预算、工具权限和回滚负责。把 ChatGPT 中“它会自己决定何时思考”直接写进企业后端，等于把可用性与成本控制交给一个不可见、持续变化且不返回稳定路由证据的产品层。
minimal reasoning 不是关闭推理后的 ChatGPT 快速模型
GPT-5 API 增加 minimal reasoning effort，并保留 low、medium、high，用于在延迟和质量间选择。官方开发者页明确说 gpt-5 minimal 与 ChatGPT 中的非推理模型不同，前者针对开发者任务调优，后者以 gpt-5-chat-latest 提供。
因此 A/B 测试必须使用完整模型 ID。若一组是 gpt-5 + minimal，另一组是 gpt-5-chat-latest，差异不能归结为“reasoning 开关”；它们是不同交付物。降档也不能只把 high 改成 minimal，还要验证工具行为、输出结构、事实性和错误恢复是否保持任务合同。
verbosity 控制默认展开程度，不是输出长度硬上限
API 新增 verbosity: low | medium | high。官方说明显式指令优先于 verbosity，因此它更像模型的表达偏好，不是确定性字数限制。生产系统仍应设置最大输出预算、schema、字段长度和服务端截断策略；需要“恰好 5 行”或“不得超过 800 字节”的协议，应由验证器执行。
reasoning effort 与 verbosity 也不是同一轴。前者影响回答前的推理投入，后者影响最终表达展开程度。一个高推理、低 verbosity 的风险摘要可能适合管理层；一个 minimal reasoning、高 verbosity 的长答案可能只是更长，并不更正确。评测要分别记录两项参数。
custom tool 把长文本从 JSON 转义中释放，但语法不等于权限
GPT-5 新增 custom tool：模型可以用纯文本而非 JSON 作为工具输入，并可由开发者提供 regex 或 context-free grammar 约束格式。这对代码 patch、SQL-like DSL、配置或长报告很有价值，因为不必把引号、反斜杠和换行全部转义进 JSON 字符串。
grammar 只能约束“长得像什么”，不能证明命令被授权、SQL 不越租户、patch 不修改禁区，或数值满足业务规则。正确链路是 grammar 解析为 AST，确定性 validator 检查字段和语义，policy engine 检查主体与资源，隔离 executor 执行，最后回读权威状态。不要把 custom tool 直接接到 shell、数据库或支付 API。
上下文扩大后，预算从输入窗口变成任务总账
开发者首发页称三种 GPT-5 API 模型可接受最多 272,000 input tokens，并可产生最多 128,000 reasoning 与 output tokens，总上下文 400,000。这里的 128K 是 reasoning 与最终输出共享的空间，不是“再给 128K 可见回答”；长工具任务还会在多轮请求中重复携带历史、工具定义和结果。
因此单次请求能装下不等于任务不会超预算。生产账本要同时计算系统策略、对话历史、检索证据、工具 schema、工具返回、reasoning、最终输出和失败重试。若只限制用户输入，工具循环仍可能在后台把成本和延迟放大。
Benchmark 是厂商报告，而且样本与条件有明确边界
OpenAI 首发报告 GPT-5(high) 在 SWE-bench Verified 为 74.9%，Aider Polyglot 为 88%；开发者页同时披露 SWE-bench 从 500 个问题中排除 23 个在内部基础设施上不能稳定运行的任务，实际固定子集为 477，并使用强调彻底验证的短 Prompt。reasoning 模型按 high 运行。
这组数字可以作为“值得进入企业评测”的信号，不能改写成 74.9% 的生产修复成功率。排除样本、Prompt、工具、基础设施、grader 与任务定义共同构成结果；企业仓库还有权限、私有依赖、测试时长、部署与人工审批。文章引用成绩时必须写“OpenAI 报告”，并同时保留 477/500 与 high reasoning 条件。
任务判断
具体场景：SaaS 版本升级变更助手
假设一家多租户 SaaS 每周升级依赖。输入是目标 commit、升级说明、依赖图、漏洞公告、代码搜索结果与失败测试；输出要列出受影响服务、证据、候选 patch、迁移顺序、回滚条件和验证结果。模型可读取仓库、运行受限测试，不可合并代码、写生产数据库或发版。
任务分三类：A 类是依赖说明抽取与文件分类；B 类是跨文件影响分析和小 patch；C 类是涉及数据库、鉴权或多服务的高风险迁移。应用路由器先根据确定性字段分类，不让模型自己决定价格档位：A 类候选 gpt-5-nano minimal，B 类候选 gpt-5-mini low/medium，C 类候选 gpt-5 high。gpt-5-chat-latest 只在确实需要首发 ChatGPT 非推理交互特征时单独评测，绝不作为“minimal 的别名”。
每个请求的任务合同至少保存：task_class、仓库 commit、租户、允许目录、禁止动作、证据快照、模型 ID、reasoning effort、verbosity、最大 input/reasoning/output/工具轮次、tool/grammar hash、deadline、验证器版本、fallback 和人工升级条件。服务端返回这些字段的受控摘要，才能解释为什么某任务更慢、更贵或被升级。
离线集可从 240 个历史升级单开始，每类 80 个，覆盖锁文件冲突、弃用 API、数据库 migration、权限回归、隐藏测试、网络失败、恶意 README、超长日志、工具返回损坏与无法复现。每个样本保存允许改动、必须通过的测试、安全不变量和可接受的 needs_human。这只是拟议规模。
比较矩阵要一次只改变一个变量：同一模型比较 reasoning；同一 reasoning 比较 verbosity；同一工具任务比较 JSON function 与 custom tool；同一合同再比较 mini 与 full。ChatGPT 网页体验只能作为用户研究，不进入 API 模型的可重复 Benchmark。
工程影响
建立应用自己的可审计路由器
路由分成两段。第一段是确定性资格过滤：数据级别、租户套餐、任务风险、工具权限、deadline 和预算决定哪些模型可用。第二段才在候选中按离线结果与实时容量选择。模型可以建议“任务需要更深推理”，但无权自行升级成本或工具权限。
建议记录：
route_decision = {
task_class,
eligible_models,
selected_model,
reasoning_effort,
verbosity,
budget,
policy_version,
evaluator_version,
reason_code
}
若 nano/minimal 验证失败，可按预定义阶梯升级到 mini/medium，但升级必须复用同一证据快照和任务 ID，保留前一次失败原因。不得在无限重试中随机换 Prompt 和模型，最后只展示成功答案；那会隐藏真实成本与错误率。
把 400K 拆成可拒绝的预算
单请求预算可表示为：
input_budget
= system_and_policy
+ retained_history
+ retrieved_evidence
+ tool_definitions
+ prior_tool_results
generation_budget
= hidden_reasoning
+ visible_output
应用在调用前为每个区块设置上限与优先级。证据超限时先去重、按来源和任务相关性重排，再明确记录省略；不能从尾部静默截断，也不能删除最高优先级策略。工具结果只保留 schema 化摘要与受控引用，大文件进入对象存储，不在每轮完整回放。
任务级成本还要累加每一轮调用。若一次工具任务经过 6 轮，400K 上限不是 6 轮共享额度；每轮输入、reasoning、输出和工具计费都进入总账。达到 token、时间或轮次上限时进入 budget_exhausted，返回已验证进度和下一步，而不是伪装完成。
custom tool 先解析，再授权，再执行
例如模型输出受 grammar 约束的 patch DSL：
PATCH file="src/auth.ts" base="<blob-sha>"
...diff...
END
parser 只负责得到 AST；validator 再检查文件存在、base hash、diff 行数、禁止路径、编码与测试映射；policy engine 检查当前主体是否可修改该目录；executor 在临时 worktree 应用并运行资源受限测试。模型文本永远不直接传给 sh -c。
grammar 与 tool schema 都要有 hash 和兼容版本。模型升级后即使回答质量提高，也可能改变空白、引用、工具前言或错误恢复；解析器必须用未知字段、超长文本、重复 tool call、恶意路径和半截输出做负向测试。
业务状态与模型响应状态分开
建议状态机：
accepted -> classified -> planning -> tool_pending
-> verifying -> review_ready
-> needs_input | budget_exhausted | policy_denied
-> failed | unknown -> reconciling
approved -> merged -> deployed -> observed | rolled_back
模型 completed 只表示一次响应结束，不表示升级完成。只有候选 patch 应用成功、测试通过、审批存在并且 CI/部署状态回读一致，业务状态才前进。工具请求超时后进入 unknown，先按 operation ID 查询 runner/CI；不能直接重跑可能已经提交的动作。
升级回归单位是完整交付合同
每个生产版本固化：
model identifier or offered snapshot
+ API surface and SDK version
+ reasoning_effort + verbosity
+ system/developer prompt hash
+ tool schema / grammar hash
+ context compiler and retrieval version
+ validator / policy / executor version
+ eval dataset and grader version
升级流程先离线回放，再影子运行，最后按任务类别 canary。门禁同时看经验证完成率、越权动作、工具参数合格率、解析失败、引用正确率、P50/P95、token、工具轮次、人工修订分钟和单位成本。只要安全不变量下降或成本越界，即使平均 Benchmark 提升也停止扩量。
若供应商只提供移动 alias，系统应保存每次响应可获得的模型标识与日期，缩短 canary 周期并保留可用旧模型；若提供固定 snapshot，则生产默认固定，alias 只用于预发布评测。回滚要恢复模型、Prompt、工具 grammar 和 validator 的兼容组合，不能只改一个模型字符串。
观测重点从回答分数转向任务收敛
核心指标包括：经验证任务完成率；首次路径通过率；路由升级率；工具参数一次合格率；未授权副作用率；unknown 在目标时间内收敛率；平均/尾部 token、工具轮次与延迟；人工修订分钟；每类任务的单位合格成本。路由准确率必须以“选择后是否更便宜地完成任务”为标签，而不是让另一个模型猜难度。
Trace 保存 task、route、model、参数、tool、token、latency 和脱敏 hash；安全审计保存主体、策略、审批与拒绝；业务账本保存 commit、CI、部署和回滚结果。不要把隐藏 reasoning 当用户解释，也不要把完整源码和秘密写进通用 trace。
商业价值
GPT-5 API 家族的商业机会在于把不同任务放在明确的质量、延迟和成本曲线上。对代码平台、客服、分析与运营产品，nano/mini/full × reasoning × verbosity 可以形成后台路由，而不是为每个请求购买最大模型。custom tool 又降低长代码/DSL 在 JSON 中的转义摩擦，有利于更稳定的工程 Agent。
但节省必须按最终结果计算：
每个经验证升级任务成本
=（所有模型 input、cached input、reasoning/output 费用
+ 搜索、代码执行、CI、存储与观测
+ 路由、Prompt、grammar、评测和升级维护摊销
+ 人工复核、返工、恢复分钟 × 人工单价
+ 错误合并、停机与安全事件的预期损失）
/ 经 CI、审批与部署观测共同证明的完成数
便宜模型导致更多升级、重试或人工修订时，表面 token 单价优势会消失；高 reasoning 若减少工具调用和返工，也可能降低总成本。只有任务级账本能回答。
建议做 8 周试点：前两周冻结 240 条离线集和合同；第 3 至 4 周测试模型/参数矩阵；第 5 至 6 周影子处理真实升级；第 7 至 8 周仅允许低风险候选 patch 进入人工 PR。扩量门槛可设为未授权副作用 0、所有合并均有测试与审批、unknown 30 分钟内对账或升级、经验证完成率不低于人工基线、人工修订分钟下降至少 20%，且每个合格任务成本低于节省的工程时间。这些是待验证目标。
若任务完全由规则解决、延迟要求极低、输入稳定且不需要工具，传统程序或小型分类器更合适。ChatGPT 适合员工交互与探索，但不能替代后台 API 的租户隔离、版本固定、预算、审计和 SLA。
局限与风险
第一，本文没有调用首发 API，也不知道 ChatGPT router 的实现、阈值与每次真实选择。架构图只表达公开产品边界，不能声称复刻内部系统。
第二，官方 Benchmark 是发布方材料。SWE-bench 的 477 子集、排除 23 题、high reasoning、Prompt 和内部基础设施都影响结果；企业不得把 74.9% 直接写进 SLA。
第三，gpt-5-chat-latest 的名称本身强调 latest，适合追随 ChatGPT 非推理模型体验，却可能增加行为漂移。需要稳定性的生产任务应优先使用供应商提供的固定版本并持续回归；如果当时没有满足要求的固定交付，就保留人工或旧模型。
第四，grammar 防语法错误，不防语义越权。一个完全符合 CFG 的 DROP TABLE 仍然危险，一个格式正确的 patch 仍可能破坏租户隔离。权限、审批和验证必须在模型外部。
第五，400K 总上下文会诱导团队少做检索和状态压缩。长历史可能携带旧策略、Prompt Injection、重复结果与过期事实；容量越大，来源、版本和删除策略越重要。
第六，动态路由容易制造不可解释的体验差异。若相同任务因容量或配额静默进入 mini，业务 SLA 会漂移；后台系统必须自行决定是否允许降级，并在不能满足合同时明确失败或转人工。
最后，本文严格停在 2025 年 8 月 9 日。后来 GPT-5 系列、API 参数、ChatGPT 路由与价格变化都属于新事件，不能反向修改首发合同。
面试表达
30 秒结论： GPT-5 首发不是一个单模型。ChatGPT 是快速模型、GPT-5 Thinking 与实时 router 组成的产品系统；API 则显式提供 gpt-5、mini、nano 推理模型，非推理模型另叫 gpt-5-chat-latest。gpt-5 minimal 也不等于 ChatGPT 快速模型，所以生产路由必须外置并记录完整模型合同。
3 分钟架构： 我会把 SaaS 升级任务先由确定性规则分成抽取、小 patch 和高风险迁移，再在合格候选中选 nano/mini/full 与 reasoning 档位。每次请求固定模型、verbosity、上下文预算、tool grammar、validator 和 deadline。custom tool 只生成可解析 DSL，经过 AST 校验、权限、隔离执行和 CI 回读。工具超时进入 unknown 并对账。升级用离线、影子、canary 三层门禁，指标是经验证完成率、安全、尾延迟、人工分钟和单位成本。
若追问“为什么不让 GPT-5 自己决定是否 thinking”，答案是 ChatGPT router 优化产品体验且持续变化，API 后端还要满足租户、预算、风险与回滚合同；模型可提供难度信号，但最终路由属于控制面。若追问“grammar 是否让工具安全”，答案是否定的：它只限制语言，AST 仍需语义验证和授权。
若追问“74.9% 是否代表代码 Agent 能自动合并”，答案也是否定的：这是 OpenAI 在 high reasoning、特定 Prompt、内部基础设施和 477 个可稳定运行题目上的报告；生产完成还要私有依赖、权限、测试、审批、部署和观测共同证明。
复盘
站在 2026 年回看，GPT-5 首发最重要的工程信号是“模型”进一步分裂为产品系统与 API 制品。对终端用户，统一入口减少选择负担；对开发者，显式模型和控制参数增加可治理性。两者都合理，但不能用同一个名字掩盖不同合同。
minimal reasoning、verbosity 和 custom tool 让开发者能分别调节推理投入、表达长度与工具载荷。它们不是三个营销开关，而是需要进入评测矩阵和版本元组的控制维度。参数越多，随意在线试 Prompt 越不够；团队越需要任务级数据与自动回归。
这次发布也提醒我们重新定义路由：不是“猜哪个模型最聪明”，而是在安全、预算和 SLA 约束下，选择最便宜且能通过验证的交付路径。路由标签来自最终任务结果，不能来自模型自评；升级成功由权威系统证明，不能由回答结束证明。
下一步可复现实验应固定首发 API 可用版本、SDK、Prompt、tool grammar 与 240 条升级集，保存每条任务的 route、reasoning、verbosity、token、工具轮次、CI 与人工修订；按单变量矩阵比较，然后模拟工具超时、半截 custom output、配额降级和 alias 漂移。完成之前本文保持 sourced。
方法披露
本文使用 AI 工具辅助比对 ChatGPT 首发页、开发者页、系统卡与发布日/T+2 固定快照，抽取交付差异，组织路由合同、上下文预算和失败案例；事件日期、Wayback UTC 时间、模型名称、minimal/verbosity/custom tool、400K 构成、SWE-bench 排除样本和最终工程判断由作者逐项复核。
文中 240 条样本、8 周试点、状态机、路由字段、成本公式与扩量门槛均为实验设计，不是本站生产数据。文章没有获得 router 内部信息，没有调用首发模型，也没有把厂商报告改写为独立 Benchmark。
修订记录
2025-08-09：初版发布；固定 2025-08-07 至 08-09 的 ChatGPT、API 与系统卡证据，拆分动态产品 router 和显式 API 模型，补充 minimal、verbosity、custom tool/grammar、400K 上下文账本、Benchmark 排除样本、失败对账与升级回归合同。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论