OpenAI 使用 GPT-6

选择 GPT-6 家族模型时，同时考虑任务所需的推理能力、响应速度和成本。

模型	定位
GPT-6 Astra	智能水平最高，适用于要求最高的推理、编程与专业工作
GPT-6.1 Sol	平衡速度、成本和智能，以较低成本为复杂工作提供接近 Astra 的表现
GPT-6 Luna	速度和成本效率优先，适用于目标明确、调用量大的任务

在 Responses API 请求中设置 model 即可开始。如果已有系统使用 gpt-6-sol，切换到 GPT-6.1 Sol 前先核对本页的迁移要求。

GPT-6 Astra

GPT-6 Astra 面向计算机操作、浏览器使用、软件工程、科学与专业任务，可跨代码、浏览器及专业软件完成多步骤工作流。官方发布评测中，Astra 在若干任务上使用明显更少的输出词元取得更好结果；尽管每词元单价较高，评测中估算的单任务 API 费用仍可能低于较早模型。这是特定评测结果，实际成本需按自己的任务用量衡量。

Astra 强调谨慎处理任务、尊重边界、透明沟通。当指令留有解释空间时，模型会利用上下文补全常规细节，并在答案可能改变结果时提出集中、具体的问题。执行过程中可以吸收新要求、按用户指示改变方向，也能回答附带问题而不丢失原任务。

Astra 用户可使用 Fast 与 Ultrafast 模式获得更快的 API 响应，区域与服务条件仍须分别检查。

GPT-6.1 Sol

复杂编程、计算机操作与专业工作需要兼顾成本时，可使用 Sol。在相同任务上与 Astra 比较，判断质量和费用的取舍。

reasoning.effort 支持 low、medium（默认）、high、xhigh、max；不支持 none、minimal。工具调用使用 Responses API，Chat Completions 支持不带工具的请求。规格、价格与可用性见模型页，选择方法见模型选择。

新能力

异步工具调用：应用执行工具时，GPT-6 可以继续推理、调用其他工具，或回答请求中相互独立的部分。在函数或自定义工具上设置 async: true，准备好结果后用原 call_id 返回。工具仍由应用执行，待处理工作的管理也由应用负责。异步工具调用介绍基础用法和开发者自定义等待工具的模式。
轮次中途引导：模型工作时可以追加用户指令，例如纠正错误或改变要求。通过 WebSocket 连接，Responses API 会保留已完成工作，并将更新纳入续接。中途引导说明事件流程和工具结果处理。
对话中调整推理力度并保留缓存：加入 configuration_update 输入项，可在困难任务中提高推理力度，在常规后续任务中降低力度，而不重写原提示词前缀。设置持续生效，直至被新的同类输入项覆盖。用法与兼容性见推理模型。
失配监控：GPT-6 Astra 加强防护的一部分是异步监控模型失配行为，并在必要时触发告警，详见失配监控。

GPT-6 也支持 GPT-5.6 已有的 API 能力，包括计算机操作、结构化输出、流式输出、程序化工具调用、多智能体编排、提示词缓存、持久化推理、上下文压缩与 Pro 模式。每种能力的请求字段、执行责任和兼容限制分别以对应指南为准。

限制

GPT-6 Astra、GPT-6.1 Sol 不支持 none 推理力度；GPT-6 Sol、GPT-6 Luna 支持。

Fast 模式对 GPT-6.1 Sol、GPT-6 Sol、GPT-6 Luna 支持欧盟数据驻留，对 Astra 不支持。Sol 的 Ultrafast 支持美国、欧盟数据驻留与全球处理；Astra 的 Ultrafast 仅支持美国数据驻留和全球处理。适用条件见数据驻留资格。

提示词最佳实践

以下提示词可作为 GPT-6 家族的起点，其针对的是 Astra 中观察到的行为。使用其他模型或不同工作负载时，应重新评测。

GPT-6 Astra 的行为特点

Astra 在长任务中的连贯性通常优于 GPT-5.6 Sol 及更早模型，但也更容易在额外信息可能改变结果时询问用户。有些应用期望它作出合理假设继续工作，此时需要明确自主执行边界。

它对长指令的遵循更强，同时对技能、AGENTS.md 等文件中的指令更敏感。应用应检查模型可读取文件中的冲突、含糊要求与优先级。模型倾向于较详细、带结构的输出，子智能体使用频率可能低于工作流所需；编程任务的测试范围也可能超出小改动所需。可以分别调整这些行为。

主动执行与持续完成

以下提示词强调根据上下文判断授权并持续推进。

原提示词的中文译文，保留任务条件与限制

根据指令和此前对话上下文推断用户意图及任务范围。你的工作是偏向行动，把用户希望完成的任务推进到完成。

用户表示想开展新工作或修复既有问题时，持续工作直到预期目标完成。自主向目标推进，例如必要时创建隔离工作树/检出、解决合并冲突、执行只读操作、创建草稿 PR 等，除非动作明显具有破坏性或不可逆。

对于“能否……”“我想……”“帮我……”等表达，可明确要求模型将其理解为行动请求。

原提示词的中文译文，保留任务条件与限制

用户以“能否……”“我想……”“帮我……”等表达请求行动时，将它们视为执行工作的指令并采取行动。不要只确认有能力（如“可以……”）、提出计划或表示可以继续。不要为节省时间、工作量或词元，交付未完全满足任务的部分结果或仅仅“足够有帮助”的方案。需要持续工作时，完成全部必要工作，直到预期结果实现。

应当审批的工作，也可先准备具体、可审核的结果，再请求最后一步授权。

原提示词的中文译文，保留任务条件与限制

向用户提澄清问题前，先完成上下文已经授权、且让拟议动作具体可审核所必需的工作。用户应审批一个具体、可审核的结果。例如部署变更、写入外部应用、合并 PR 或发布网站前，先完成全部准备，使审批成为最后一步。可逆任务、只读动作、审查或修复，以及本会话此前已授权或当前指令强烈隐含授权的工作，无需用户许可。

不因假设风险增加未经请求的警告、免责声明、审批流程或安全/合规检查表。

模型也可能在执行中提出不阻塞工作的问题，应用可按需要调整提问频率和自主程度。

指令遵循

含糊或互相冲突的技能要求可能导致模型提前暂停。明确用户指令与技能的优先级：

原提示词的中文译文，保留任务条件与限制

用户指令优先于技能中的指导。用户明确指令与技能冲突时，优先遵循用户指令。

需要解释暂停原因时，可以要求模型指出具体依据：

原提示词的中文译文，保留任务条件与限制

如果技能使你请求许可或确认、暂停、留下未完成工作，或偏离用户意图，请给出实际读取的 SKILL.md 的名称和链接，引用相关指令，简述其如何适用。区分技能明确要求和你对指导的解释。

在会加载较多技能与指令文件的应用中，这有助于定位隐含冲突。

个性与写作风格

模型默认常用列表、表格和 Markdown。希望更多使用连贯段落时，可以直接规定：

原提示词的中文译文，保留任务条件与限制

默认使用清楚、简洁的段落，每段展开一个主要观点。只有信息确实并列、有顺序或更易比较时才用列表；除非无法用文字清楚表达层级，否则避免嵌套列表。使用普通、简单的语言：熟悉的词、具体例子、准确动词。优先主动语态和直接陈述。

尽早清楚说明主要观点，再补读者需要的解释和细节。句子前后衔接，充分展开重要观点，并提供足够支持，使内容有用。

技术沟通可进一步说明：

原提示词的中文译文，保留任务条件与限制

用普通语言代替术语，只在技术细节有助于向用户说明概念或工作时才引用。清楚、连贯地沟通复杂概念，根据用户提示及上下文所体现的背景知识调整写作。

减少套话时，可把不希望出现的具体表达列出来：

原提示词的中文译文，保留任务条件与限制

避免套话，如结尾的“Bottom Line:”、delve、foster、leverage、“it's worth noting”“importantly”“Question? Answer.”、“This isn't about X. It's about Y.”、genuinely，以及用连字符拼接的描述和形容词。不用“In short:..”“The simplest mental model is:...”等总结式结尾。

直接说明拟采取的动作。避免额外说明不会做什么、什么保持不变，或如何分组结果。不使用“X, not Y”这类对照框架，引入用户没问的替代方案。避免自造复合标签，如 exact-head checks、editorial-row layouts，避免含糊限定词和模板过渡；用普通动词、介词直接说明实际关系。

子智能体委派

若应用的执行框架确实支持多智能体，可通过提示词调整并行委派程度：

原提示词的中文译文，保留任务条件与限制

无论是根智能体还是子智能体，只要把任务委派给其他智能体并行处理能够节省时间或提升质量，就应使用协作工具委派。

以上是文档中的应用提示词示例，具体是否启用委派由应用自身的授权与工具配置决定。智能体消息也可能被人阅读，可另加格式约束：

原提示词的中文译文，保留任务条件与限制

发给其他智能体的消息和最终答案都可能被人阅读，确保清楚易读。在单词和/或数字之间始终保留适当空格。

测试与验证

小改动的测试应与风险相称，避免无意义的重复：

原提示词的中文译文，保留任务条件与限制

不要为可逆、低影响且只是重复实现逻辑的变更写测试。选择用测试验证时，确保测试有意义且确为验证实现所需。

运行适合变更的测试，并完成必需检查。通过后，只有新修改、失败或尚未解决的顾虑，才足以支持扩大或重复测试；否则继续完成任务。

快速迁移

使用 Codex 迁移

可让 Codex 使用 OpenAI Docs 技能协助执行本指南建议：

原提示词的中文译文，保留任务条件与限制

$openai-docs 将此项目迁移到 GPT-6 模型家族

其他编程智能体也可从该仓库获取技能，再按其自身支持的方式使用。

更新 API 与模型参数

将 model 设置为 gpt-6-astra、gpt-6.1-sol 或 gpt-6-luna 后，逐项检查：

推理力度：在支持的范围内先保留原实际力度。Astra、Sol 不支持 none，可从 low 开始；原来用 minimal 的任务也先比较 low。Responses 字段为 reasoning.effort，Chat Completions 字段为 reasoning_effort。
工具调用：Astra、Sol 的工具调用需要 Responses。GPT-6 Sol、Luna 在 Chat Completions 中只有 reasoning_effort: "none" 才支持函数调用；需要推理和工具时使用 Responses。
不支持的参数：力度不为 none 时，移除 temperature、top_p、top_logprobs。Chat Completions 另需移除 logprobs；Responses 应从 include 中移除 message.output_text.logprobs。
数据驻留：按前述模式与区域组合检查。Astra 的 Fast 不包含延迟 SLA，详见Fast 兼容性。
对话内改变推理力度：标准单智能体请求可使用 configuration_update，保留请求级 reasoning.effort 不变，以稳定缓存前缀；采用前检查兼容限制。
提示词缓存：从 GPT-5.5 或更早模型迁移时，将 prompt_cache_retention 改为 prompt_cache_options.ttl: "30m"，同时检查缓存边界及写入计费的变化，见缓存差异。
不必要的审批停顿：若模型反复暂停询问，按本页主动执行部分调整提示词，并分别评测指令遵循、风格、委派和测试行为。