升级至 GPT-5.5

当用户明确要求将现有集成升级至 GPT-5.5 时，请使用本指南。结合当前的 OpenAI 文档查阅。默认目标模型字符串为 gpt-5.5.

升级原则

以最窄的安全变更集进行升级：

• 首先替换模型字符串
• 仅更新与该模型使用直接相关的提示词
• 不要自动升级那些可能被有意固定的较旧或模糊的模型用法，例如历史文档、示例、测试、评估基线、比较代码或低成本备用/路由路径。除非用户明确要求升级所有模型用法，否则请保持这些位置不变，并将其列为需要确认的项目
• 尽可能首选仅提示词的升级
• 如果升级需要 API 接口变更、参数重写、工具重构、提供商迁移或更广泛的代码编辑，请将其标记为已阻止，而不是强行扩大范围

升级工作流

1. 盘点当前的模型使用情况。
   • 搜索模型字符串、客户端调用和包含提示词的文件。
   • 包括内联提示词、提示词模板、YAML 或 JSON 配置、Markdown 文档以及保存的提示词（当它们明显与模型使用位置相关时）。
2. 将每个模型使用与其提示词层面配对。
   • 优先选择最接近的提示词层面：首先是内联系统或开发者文本，其次是相邻的提示词文件，然后是共享模板。
   • 如果您无法自信地将提示词与模型使用联系起来，请如实说明，而不是猜测。
3. 对源模型系列进行分类。
   • 常见类别：GPT-5.4、GPT-5.3-Codex 或 GPT-5.2-Codex、早期 GPT-5.x、GPT-4o 或 GPT-4.1、o1 或 o3 或 o4-mini 等推理模型、第三方模型，或混合与不明确的情况。
4. 确定升级类别。
   • model string only
   • model string + light prompt rewrite
   • blocked without code changes
5. 运行兼容性检查。
   • 检查当前集成是否可以接受 gpt-5.5 而无需 API 接口层面的更改或实现层面的更改。
   • 检查结构化输出、工具 Schema、函数名和下游解析器是否可以保持不变。
   • 对于长时间运行的响应或重度依赖工具的代理，请检查 phase 在宿主程序重放助手项目或使用前导内容时，是否已经被保留或进行往返处理。
   • 如果兼容性取决于代码更改，则返回 blocked.
   • 如果兼容性不明确，则返回 unknown 而不是临时调整。
6. 在范围内时应用升级。
   • 默认替换字符串： gpt-5.5.
   • 保持干预措施最小化且保留原有行为。
   • 从当前可见的推理工作量开始，除非有充分的测试理由需要更改。
   • 对于范围内的更改，更新模型字符串和直接相关的提示词。
   • 对于已阻止或未知的更改，请勿编辑；报告阻碍原因或不确定性。
7. 总结结果。
   • Current model usage
   • Model-string updates
   • Reasoning-effort handling
   • Prompt updates
   • Structured output and formatting assessment
   • Tool-use assessment 当流程使用工具、检索或终端操作时
   • Phase assessment 当工作流是长时间运行的、重放的或重度依赖工具的
   • Compatibility check
   • Validation performed

输出规则：

• 对于每个使用位置，说明起始推理工作量建议。
• 如果仓库公开了当前的推理设置，建议首先保留该设置，除非当前的 OpenAI 文档另有说明。
• 如果仓库未公开当前设置，建议不要添加，除非当前的 OpenAI 文档要求添加。

升级结果

model string only

在以下情况选择此项：

• 源模型是 GPT-5.4
• 现有提示词已经简短、明确且任务边界清晰
• 工作流不依赖严格的输出格式、工具调用行为、批处理完整性或需要在升级后进行验证的长周期执行
• 没有明显的兼容性障碍

默认操作：

• 将模型字符串替换为 gpt-5.5
• 保留当前的推理工作量
• 保持提示词不变
• 当已有现成的测试、真实抽查或评估套件时，使用它们来验证行为

model string + light prompt rewrite

在以下情况选择此项：

• 任务需要更强的完整性、引用规范、验证或依赖项处理
• 除非格式受限，否则升级后的模型可能会变得过于冗长、密度过高或难以浏览
• 工作流具有严格的输出结构要求，并且缺少显式的格式契约、Schema 或解析器验证
• 该工作流重度依赖研究，需要更强地处理稀疏或空的检索结果
• 工作流面向编码、基于终端、重度依赖工具或多智能体，但现有的 API 接口和工具定义可以保持不变

默认操作：

• 将模型字符串替换为 gpt-5.5
• 第一轮保留当前的推理工作量
• 仅针对观察到的工作流风险进行最小的提示词修改
• 阅读 GPT-5.5 提示词指南 以选择能够恢复或改进行为的最小提示词更改
• 避免进行与升级无关的大范围提示词清理
• 对于研究工作流，添加来自提示词指南的引用规则、检索预算、缺失证据行为和验证指南
• 对于依赖感知或重度依赖工具的工作流，添加前置检查、缺失上下文处理、显式工具预算、停止条件和验证指南
• 对于编码或终端工作流，添加特定于仓库的约束、验收标准和具体的验证命令
• 对于多智能体支持或分诊工作流，添加任务所有权、交接、完整性和停止标准
• 对于带有前言或多条助手消息的长时间运行的 Responses 智能体，请明确审查 phase 是否已得到处理；如果要添加或保留 phase 需要编辑代码，请将该路径标记为 blocked
• 不要仅仅因为可见代码片段非常精简，就将使用工具的 Responses 编码工作流分类为 blocked ；优先选择 model string + light prompt rewrite 除非仓库清楚地表明安全的 GPT-5.5 路径需要主机端代码更改

blocked

在以下情况选择此项：

• 此次升级似乎需要更改 API 接口
• 此次升级似乎需要参数重写或对未在实现代码外部暴露的推理设置进行更改
• 此次升级需要更改工具定义、工具处理程序绑定或 schema 契约
• 用户要求的是工具、IDE、插件、Shell 或环境迁移，而不是模型和提示词迁移
• 集成依赖于特定于提供商的 API，如果不进行实现工作，这些 API 无法映射到当前的 OpenAI API 接口
• 您无法确切识别与模型使用相关的提示词接口

默认操作：

• 不要临时草率进行更大范围的升级
• 报告阻碍原因，并说明该修复超出了本指南的范围
• 如果有用，描述可以解除迁移阻碍的最小后续实现任务

兼容性检查清单

在应用或推荐仅包含模型和提示词的升级之前，请检查：

1. 当前宿主能否在不更改客户端代码或 API 接口的情况下接受 gpt-5.5 模型字符串？
2. 相关的提示词是否可识别且可编辑？
3. 主机是否依赖于可能需要 API 接口变更、参数重写、提供商迁移或工具重构的行为？
4. 可能的修复是否仅涉及提示词，还是需要更改实现代码？
5. 提示词接口是否与模型的使用足够接近，以便您进行针对性更改而不是进行大规模清理？
6. 严格的结构化输出、Schema 或下游解析器是否仍然具有显式契约？
7. 对于长时间运行的 Responses 或重度使用工具的智能体，如果宿主依赖于前言、重放的助手项或多条助手消息，是否已保留 phase 如果宿主依赖于前置语、重放的助手项或多个助手消息，是否已保留？
8. 延迟、Token 或价格假设是否通过测试、真实抽查或现有的评估套件进行了验证，而不是从通用模型定位推断出来的？

如果第 1 项为否，第 3 至 4 项指向实现工作，或者第 7 项为否且修复需要代码更改，则返回 blocked.

如果第 2 项为否，请返回 unknown 除非用户能指明提示词的位置。

Important:

• 现有对工具、智能体或多个使用站点的使用本身并不是阻碍。
• 如果当前宿主可以保持相同的 API 接口和相同的工具定义，请优先选择 model string + light prompt rewrite 优于 blocked.
• 将 blocked 保留给那些真正需要更改实现代码的情况，而不是仅需要更强提示词引导的情况。
• 未经任务级别验证，不要声称节省了 Token。

范围界定

本指南可以：

• 更新或推荐更新的模型字符串
• 更新或推荐更新的提示词
• 检查代码和提示词文件以了解这些更改所属的位置
• 检查现有的 Responses 流程是否已保留 phase
• 标记兼容性阻碍
• 建议使用现有的测试、真实抽查或现有的评估套件进行验证

本指南不得：

• 将 Chat Completions 代码迁移至 Responses
• 将 Responses 代码迁移至其他 API 接口
• 迁移 SDK、API、IDE 配置、Shell 钩子、插件或特定于提供商的工具
• 重写参数结构
• 更改工具定义或工具调用处理
• 更改结构化输出绑定
• 在实现代码中添加或改造 phase 处理
• 除了模型字符串替换和直接相关的提示词修改外，不要编辑业务逻辑、编排逻辑、SDK 用法、IDE 配置、Shell 钩子或插件集成行为

如果安全的 GPT-5.5 升级需要上述任何更改，请将该路径标记为已阻止并超出范围。

验证计划

• 当已有现成的测试、真实抽查或评估套件时，使用它们来验证每个升级后的使用位置。
• 在可用的情况下，与当前的 GPT-5.4 基线进行比较。
• 检查任务成功率、重试次数、工具调用次数、总 Token 数、延迟、输出结构和面向用户的质量。
• 对于专门的工作流，验证最重要的契约，而不是仅仅评判通用输出质量。
• 如果添加了提示词编辑，请确认每个代码块都在发挥实际作用，而不是增加噪音。
• 如果工作流具有下游影响，请在最终确定之前增加一次轻量级验证。