概述

OpenAI 于 2026 年 10 月 2 日发布了一篇面向开发者的产品指南《A model guide for the GPT-6 family》，主题是：如何在控制时间和成本的前提下，从 GPT-6 系列模型中获得最好的结果。

指南把 GPT-6 定位为 OpenAI「迄今最先进的模型套件」，并按照工作类型提供了多个模型选项。文章覆盖的场景从「把想法变成可用的原型」，到「构建和测试某个功能」，再到「跨代码仓库、数据库和外部 API 编排多步骤工作流」。

指南开篇给出了一份 TL;DR，把这套方法论压缩成四条：

  • 在生产中高效运行：用缓存（caching）和压缩（compaction）管理上下文与成本，度量任务成功率与延迟，提前规划监控与数据控制。
  • 让模型匹配工作负载：在能力、成本和延迟之间做平衡，通过选择模型、推理强度（reasoning effort）和处理速度来适配任务。
  • 调整提示词与技能（skills）：让提示词、技能和仓库指令在「模型要交付什么」「它能独立做什么」「什么算完成」三件事上保持一致。
  • 让长任务保持在轨：用 steering、异步工具和委派来处理更新与独立工作，并明确模型应当在什么时候向人请求输入。

关键技术点

1. 生产环境的准备清单

指南建议在部署前完成几项检查：

  • 控制上下文效率：砍掉任务不需要的上下文，同时保留它真正需要的证据；在应用支持的情况下并行运行独立任务，避免一个慢步骤拖住无关工作。
  • 用提示词缓存复用共享上下文：对于重复性工作，缓存输入 token 的成本可比未缓存输入 token 低最多 95%，具体取决于模型。落地建议是把稳定的指令和参考资料放在变化的任务细节之前，并保持工具定义一致。指南还提到 caching dashboard 和 diagnostics guide 可以帮助定位缓存复用失效的位置。做完整工作流成本估算时，要把缓存写入成本和长上下文费率一并计入。
  • 压缩长对话：对较长的会话，用 compaction 缩小上下文体积，同时保留继续任务所需的状态。
  • 监控与数据控制：需要提前决定如何监控模型行为，并审阅应用的数据控制策略。
  • 部署前测试：跑代表性任务，度量任务成功率、延迟以及「每个成功任务的成本」。指南指向了 OpenAI 的 API deployment checklist。

2. 模型矩阵：三档定位

指南把模型选择与推理等级视为一种「智能 / 价格」的权衡，并给出三个模型的分工：

模型 定位
GPT-6 Astra 最难的推理工作，需要最大化智能的场景
GPT-6.1 Sol 复杂编码、研究和计算机使用（computer use）
GPT-6 Luna 规模化的聚焦任务与日常重复性工作，有明确目标，例如提取发票字段、对请求分类、生成结构化摘要

指南建议在做模型评估时对比各模型的定价（原文给出了 pricing 链接，但未在正文中列出具体价格数字）。

3. 推理强度：四档划分

在 API 中，可以为任务选择模型投入的推理强度：

  • Low：例行任务，例如提取事实或做小改动。
  • Medium：需要判断力的工作，例如规划一个功能或比较多个方案。
  • High：困难的调试、更深入的分析或细致的审查。
  • Extra high / Max：在支持的情况下用于 High 仍不达标的测试场景，并且只有在改进足以证明额外时间和成本合理时才保留。

一个值得注意的工程细节是：在 API 中可以在一段对话中途改变推理强度，而不会破坏缓存。在 Codex 中，指南建议从该模型的默认推理等级开始，简单任务下调、深度分析上调。

4. 速度模式

  • Fast mode（API）：当响应时间重要时使用，例如聊天应用或编码工具。相比 Standard 处理，它提供更快、更一致的响应时间，但每 token 成本更高。
  • Ultrafast（Codex 和 API）：当更快的响应值得付溢价时使用，例如快速编码迭代。它独立于推理强度来加速 token 生成。指南明确说明 Ultrafast 仅在 GPT-6 Astra 上可用。

5. 提示词与技能：从「过度具体」转向「清晰授权」

指南引用 OpenAI 开发者体验团队的 Eric Provencher 的话点出了这次转变的核心：

“Models have gotten much better at understanding nuance and ambiguity, so overly specific guidance can now hinder results where it previously helped.”
（模型在理解细微差别和模糊性方面已经好得多，因此过去有帮助的过度具体指导，现在反而可能妨碍结果。）

基于《Rethinking skills and prompts for GPT-6 Astra》的总结，指南列出四个需要复查的方面：

  1. 创建更好的技能：描述要简短，明确每个技能应在何时运行；只在需要时加载支撑细节；用适合团队所用模型的指导取代僵化的「配方」。
  2. 更新 AGENTS.md：说明特定文档和测试在什么情况下相关，并明确授权安全的例行工作流，例如用一次性数据运行本地测试且不接触生产环境。
  3. 设定决策边界：说明哪些动作可以独立执行、哪些需要批准，用清晰的边界取代「一律先问」的一刀切规则。
  4. 明确持久性：定义「完成」包括什么——实现改动、运行它、检查结果、修复失败——并指出哪些决策需要人工复核。

在输出定义上，指南建议无论用 Codex 还是 API，都要讲清楚：模型可以做哪些决定、什么时候应该请求输入、什么样的响应才是有用的。例如，它可以自行决定如何组织一份摘要，但在改变项目范围之前应先与你确认。同时要描述「有用响应」的形态，例如使用平实语言、技术细节契合受众，并附上一段简短交接，说明改了什么、检查了什么、还有什么需要关注。

6. 长时任务：steering、异步工具与多智能体

GPT-6 系列让跨越数小时甚至数天的任务成为可能，指南给出三项 API 侧能力：

  • 运行中更新指令：mid-turn steering 允许通过 Responses WebSocket API 在模型工作时发送纠正。更新会被排队，不会取消正在运行的工具，也不会撤销已完成的动作。
  • 工具运行时继续工作：异步工具调用让模型在你的应用执行较慢任务（例如测试）时继续做独立工作，应用在结果就绪时返回，依赖该结果的工作则需等待。
  • 委派独立子任务：GPT-6.1 Sol 支持 Responses API 中的多智能体工作流，它可以把独立工作分配给子智能体（例如调查代码库的不同部分），并把它们的发现合并为一个……（注：原文在此处被截断，后续内容未说明。）

对数据科学或 AI Agent 落地的意义

这篇指南的价值不在于发布新模型，而在于它把「多模型 + 可调推理强度 + 缓存/压缩 + 长任务编排」这套工程范式写成了可操作的清单，这对 AI Agent 的落地有几个直接含义：

第一，模型选型从「选最强的」变成「选最匹配的」。 指南用 Astra / Sol / Luna 三档明确划分了推理、编码与规模化日常任务，配合 Low 到 Max 的推理强度，实际上是在告诉团队：把每一类子任务路由到合适的档位，才是成本控制的起点。对于发票字段提取、请求分类这类高频重复任务，指南明确点名 Luna 这类定位，意味着批处理型 Agent 不必背上旗舰模型的延迟和成本。

第二，缓存与压缩是 Agent 成本模型里的第一等公民。 「缓存输入 token 最多便宜 95%」加上「稳定指令放前面、变化细节放后面」的排序建议，直接对应了 Agent 系统最常见的成本痛点：系统提示词和工具定义在每一轮都被重复发送。把工具定义保持一致、把参考资料前置，是把这套折扣真正吃到的前提。

第三，长任务的「可控性」被拆解成了具体机制。 steering 排队而不回滚、异步工具不阻塞主流程、子智能体承接独立分支——这三件事合起来，正是把「跑几小时的 Agent」从演示推向生产所需要的运维原语。尤其「更新是排队的、不取消已运行工具」这一点，决定了人在回路上介入时的语义边界，值得在系统设计时就明确下来。

第四，提示词工程的重心从「写死流程」转向「划清边界」。 Eric Provencher 的那句判断值得反复读：模型变强之后，过度具体的指令会开始起反作用。四个复查项——精简技能描述、更新 AGENTS.md 并授权安全例程、设定决策边界、明确「完成」的定义——本质上是在为 Agent 建立契约，而不是写脚本。

此外，指南强调度量「每个成功任务的成本」而非只看单 token 价格，这一点对数据科学团队尤为实用：Agent 任务的成功率波动会直接放大成本，只优化单价容易得出错误的结论。

我的技术点评

这篇指南表面上是一份产品文档，实际上是一份相当诚实的工程约束清单。它没有承诺「更强的模型解决一切」，反而花了大篇幅讲怎么省钱、怎么压缩上下文、怎么定义「完成」——这恰恰说明 GPT-6 这一代的能力提升，把瓶颈从「模型能不能做」推到了「系统能不能管住成本、上下文和长时任务的状态」。

几个我认为最值得关注的信号：

一是「推理强度中途可调且不破坏缓存」这个细节。 它看起来小，但对 Agent 架构的影响不小——意味着一个长会话可以在规划阶段用高推理、执行阶段切到低推理，而不必因为缓存失效付出代价。这为「按阶段分配算力」的路由策略提供了实现基础。

二是缓存折扣高达 95%，但前提条件很多。 稳定指令前置、工具定义一致，这类约束意味着提示词的组织方式从「写得清楚」变成了「写得对缓存友好」，这会在团队里形成新的规范。指南自己提到用 caching dashboard 去定位复用失效，也侧面说明这并不容易做对。

三是多智能体能力只挂在 GPT-6.1 Sol 上。 原文明确写的是「GPT-6.1 Sol supports multi-agent workflows in the Responses API」，并未说明 Astra 或 Luna 是否支持。这与「Astra 主攻最难的推理、Sol 主攻编码与计算机使用」的定位是自洽的，但也意味着想上多智能体委派的团队在模型选择上会被收窄。另外，原文在描述子智能体合并发现结果处被截断，具体的合并机制和边界条件无从判断，这部分需要查阅原文完整版。

一处需要保持清醒的地方：指南给出了定位和方向，但正文没有列出具体的模型定价、上下文窗口、各模型的推理强度支持矩阵等硬参数（原文未说明，仅提供了 pricing 链接）。对做成本建模的团队来说，这些数字才是决策依据，指南更像是索引而非答案。

总体而言，如果你正在搭建跨仓库、跨数据库的多步 Agent 工作流，这篇指南值得逐条对照自查；但如果你只是想选一个模型跑单次任务，读 TL;DR 那四条加模型矩阵就足够了。

原文链接