GPT-6.1 Sol 接入指南：从旧请求到 Responses 工具链

接入新模型时，最省事的改法通常是替换 model。但原来能跑的配置，未必能直接用于 GPT-6.1 Sol：旧的无推理档位可能不支持，采样参数可能需要删除，工具调用还涉及接口和响应处理方式变化。一次纯文本请求成功，也不能证明整个 Agent 已经迁移完成。

本文以 2026 年 9 月 30 日核验的官方文档为依据，按“确认身份、最小请求、参数清理、输出解析、工具回传、灰度回滚”的顺序给出迁移方法。示例是待运行的模板，本文没有使用读者账号发起真实调用。

一、先固定旧配置

迁移前保存一份当前有效配置：模型 ID、接口、SDK 版本、推理档位、系统提示、工具 schema、超时和重试规则。再选 20 至 50 个脱敏任务，保存现有输出和验收结果。这个样本数量是本文建议，不是官方最低要求。

第一轮只改模型和必要的协议。暂时不要同时升级数据库、换提示词框架、重写工具名称和增加自动重试。变化越多，失败后越难解释到底是哪一个环节引入回归。

如果旧应用使用自己的网关，还要核对入口到底提供哪些接口。兼容 OpenAI 请求格式，不等于支持某个新模型，也不等于所有字段都被原样透传。模型身份需要通过提供方文档、实际响应和路由记录共同判断。

二、用最小请求确认身份和权限

官方模型页给出的 API ID 是 gpt-6.1-sol。它支持文本、图像输入和文本输出，默认推理档位为 medium。模型 ID 与规格

先在已经安装 OpenAI Python SDK 的独立测试环境运行下面的纯文本模板。密钥放在环境变量里，不要写进源码或博客截图。

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6.1-sol",
    reasoning={"effort": "medium"},
    input="把‘确认权限、核验模型、保存日志’整理成三项检查清单。",
)

print(response.id)
print(response.model)
print(response.status)
print(response.output_text)
print(response.usage)

Responses 的请求与 SDK 读取方式可在官方迁移文档中核对。这里不加入工具和长上下文，是为了让第一次失败更容易定位。Responses 迁移文档

验收不只看有没有文本，还要保存请求时间、区域、响应 ID、模型字段、状态和 usage。不要把模型在正文中自称某个型号当成身份证明。第三方入口的 model 字段也需要结合真实路由记录解释。

三、检查推理档位和旧参数

GPT-6.1 Sol 支持 low、medium、high、xhigh、max，不支持 none 和 minimal。官方迁移指南建议尽可能保留旧的有效档位；旧请求使用不支持的档位时，从 low 开始做代表性任务比较。档位与迁移规则

同一指南还要求：推理强度不为 none 时，移除 temperature、top_p、top_logprobs；Chat Completions 还要移除 logprobs；Responses 的 include 不应继续包含 message.output_text.logprobs。因此，一个通用请求构建器如果自动附带这些字段，会成为迁移风险。不支持的参数

建议从允许列表重建请求，不要把旧配置对象整个展开：

SUPPORTED_EFFORTS = {"low", "medium", "high", "xhigh", "max"}


def build_request(task_input, effort="medium"):
    if effort not in SUPPORTED_EFFORTS:
        raise ValueError("Unsupported effort for gpt-6.1-sol")
    return {
        "model": "gpt-6.1-sol",
        "reasoning": {"effort": effort},
        "input": task_input,
    }

这是本文的防错示例，不是必须采用的客户端架构。它的作用是把配置错误提前暴露出来，而不是遇到错误后静默改参数重试。

四、工具调用不能只换 URL

官方明确说明，GPT-6.1 Sol 的工具调用需要 Responses API；Chat Completions 支持不带工具的请求。因此，原来走 Chat Completions 函数调用的代码，不应只替换模型字符串继续使用。接口支持边界

从 Chat Completions 迁移时，要同时改三个地方：请求从 /v1/chat/completions 切到 /v1/responses；读取 typed output 数组而不是假设所有内容都在 choices[0]；选择新的多轮状态传递方法。官方文档支持通过 Conversations API 管理对话，或者用 previous_response_id 串联响应。响应与状态迁移

如果应用只需要纯文本，SDK 的 output_text 可以作为起点；如果需要结构化输出或工具链，就不要把整个 output 数组强行拼成字符串。每一种输出类型都应该有单独处理分支，并记录未知类型，防止新增事件被静默丢弃。

如果使用自己的函数，应用仍然负责执行函数、校验参数、处理结果和执行权限。模型发出一个调用意图，并不意味着文件已经修改、数据库已经查询或用户已经批准了操作。

五、用只读工具链验证状态管理

首次工具测试建议选只读操作。例如查询一条测试工单，返回明确字段，再让模型汇总。验收顺序可以写成：

模型选择预期工具
参数通过 schema 与业务校验
应用执行查询
结果关联回原调用
模型依据结果生成最终答案
最终字段与测试数据一致

再增加三个失败样本：工具返回空结果、工具超时、工具返回业务错误。模型不能把“没查到”改写为肯定结论，也不能把错误文本当成有效查询结果。对于有写入副作用的工具，还要验证幂等和审批，不要用生产数据做第一次测试。

六、灰度时看尾部请求和人工返工

本文建议按任务类别统计，而不是把所有流量合成一个平均值。短文本、结构化抽取、多轮工具和长文档的失败方式不同，混在一起会掩盖回归。

只有任务通过验收，才算成功。返回 HTTP 成功状态但内容被截断、字段缺失、工具没有执行，仍应归入失败或待人工处理。阈值由业务自己制定，并在实验开始前固定，避免看到结果后再调整规则。

七、多轮迁移要防止“第一轮成功，第二轮失忆”

最小请求通过后，再增加一条连续任务：先读取测试工单，再让模型解释某个字段，最后要求它根据前两轮给出摘要。每轮都用固定测试数据核对，重点看信息是否延续、工具结果是否仍可追溯，以及旧系统是否重复注入了全部历史。

官方文档提供 Conversations API 和 previous_response_id 等状态传递方式，但选用哪一种，不应只由代码行数决定。需要考虑现有会话生命周期、数据保存策略、工具结果大小和应用如何恢复中断。不要把旧的 messages 累积器与新的状态链未经检查地叠加，重复输入会让调试和成本核算都更困难。多轮状态迁移

可以增加一个故障演练：第二轮工具超时后中断任务，再从已保存的应用状态恢复。检查模型是否重复执行第一轮动作，是否把不完整结果当成完成，是否能给出明确的失败说明。这比只测连续三轮都成功更能发现状态管理问题。

八、把三个典型故障变成回归样本

第一种样本故意保留一个不兼容的推理档位，确认请求构建器能提前拒绝，而不是进入网络重试。第二种样本让工具返回合法结构但业务字段为空，确认应用和模型不会把空数据包装成确定结论。第三种样本让最终答案缺少必填字段，确认验收层会失败，而不是只依据 HTTP 状态判成功。

这三类样本分别覆盖配置、工具和质量。它们没有统一的“提高推理强度”解法：配置问题改参数，工具问题修执行逻辑，质量问题才比较提示词、档位或模型。若三类错误都走同一个自动重试分支，线上日志很难解释，重复调用也可能把费用放大。

每个样本保存四份脱敏材料：原请求、原响应、应用处理日志、预期验收结果。修复后先重放失败样本，再运行正常样本，避免只证明“这次碰巧能跑”。如果涉及写操作，还要让应用先模拟执行，确认审批和幂等有效后，才允许连接真实数据。

迁移交付时，建议把这些样本和回滚方法一并交给维护者。一个新接口适配层只有在成功、失败、中断恢复三条路径都能解释时，才值得作为生产默认值。

九、错误处理和回滚要先写好

权限不足、模型不可用和参数错误通常需要修正配置，不能用无限重试解决。网络和临时服务错误可以按自己的重试策略处理，但要限制次数、总时间与成本。带副作用的任务必须防止重复执行。

回滚应恢复完整旧配置，不只是旧模型字符串。如果连接口、输出解析和状态管理都改变了，回滚开关就需要切换整个适配层。保留影子流量或测试入口，便于修复后重新运行失败样本。

建议先演练一次人为触发的回滚，再决定扩大流量。观察旧适配层是否恢复、未完成任务如何处置，以及日志能否区分回滚前后的请求。开关存在不等于恢复有效。

最后检查三件事：旧档位是否仍被公共配置发送；旧响应解析是否还在读取 choices；任务失败后是否真的恢复了已验收版本。GPT-6.1 Sol 接入的完成标志，不是一段新回答，而是一条能核验、能失败处理、能回滚的完整工作流。