作者注：如果你现在的 Agent 还在用 client.chat.completions.create 挂 tools，换成 GPT-6.1 之后会遇到一个很具体的分叉点——文本还能跑，工具调用要换端点。
为什么升级到 GPT-6.1 后，工具调用会被端点卡住
先说结论：GPT-6 Astra、GPT-6.1 Sol、GPT-6.1 Terra 这三款模型都支持 Chat Completions，但工具调用必须走 Responses API。也就是说，同一套代码里，纯对话可以继续留在 Chat，一旦要挂函数、要读工具返回、要做多轮工具循环，请求就得投到 Responses 端点。
这不是一个可以靠改参数绕过去的兼容性问题。换 tools 的写法没用，加 tool_choice 也没用，Chat Completions 这条路对这三款模型就是不提供工具调用能力。真正要动的是端点本身，以及围绕端点的一整套请求/响应结构。想先把两种端点在自己的 Key 上跑一遍对比，可以用 API易 apiyi.com 的统一入口，base_url 指向 https://api.apiyi.com/v1，模型 ID 换一下就能切。
另一条容易踩的支线是 GPT-6 Sol 和 GPT-6 Luna。这两款在 Chat Completions 里可以做函数调用，但前提是 reasoning_effort 为 none。换句话说，它们能用 Chat 调工具，但代价是关掉推理强度；如果你需要保留推理，同样得回到 Responses。这个细节经常被忽略，结果就是代码跑通了、效果却不对。
核心价值：读完本文，你能判断自己手上的工具调用链属于哪一类，并在不推翻整体架构的前提下，把请求从 Chat 端点平移到 Responses 端点。
GPT-6.1 工具调用核心要点
下面这张表是三款模型 + 两款旧型号的端点归属，建议先对号入座再看后面的迁移步骤。
| 模型 | Chat Completions 纯文本 | Chat Completions 工具调用 | 工具调用应走端点 |
|---|---|---|---|
| gpt-6.1-sol | 支持 | 不支持 | Responses |
| gpt-6.1-terra | 支持 | 不支持 | Responses |
| gpt-6-astra | 支持 | 不支持 | Responses |
| gpt-6-sol | 支持 | 仅 reasoning_effort 为 none 时支持 |
Responses（需保留推理时） |
| gpt-6-luna | 支持 | 仅 reasoning_effort 为 none 时支持 |
Responses（需保留推理时） |
端点分工：Chat 保文本，Responses 保工具
把这张表读成一句话就是：Chat Completions 在 GPT-6 系列上退化成了文本通道，工具通道被单独拆到了 Responses。这个拆分对老项目的影响是分层的——只做问答、摘要、分类的服务几乎不用动；做 Agent、做函数调用、做多步工具编排的服务，必须迁移。
对已经封装过一层 SDK 的团队来说，好消息是迁移面比想象中小。模型 ID 不变，鉴权方式不变，base_url 也不变，变的集中在请求体结构和工具结果的回填方式上。所以真正的工作量不在“换模型”，而在“换调用姿势”。
三款主力模型的选型逻辑
GPT-6.1 Sol 和 GPT-6.1 Terra 是这一代的主力双子，差别主要在定位与成本；GPT-6 Astra 属于上一代的旗舰，仍然支持 Chat 纯文本与 Responses 工具调用，适合已经稳定跑通、不想大改的项目。选型时先看你的工具调用频率，再看单次上下文长度，最后才看单价——因为工具调用往往伴随多轮往返，token 消耗会被放大。
具体价格可以对照后文的价格表，也可以直接在 API易 apiyi.com 的文档里核对当前生效的计费口径，避免用旧价格做预算。
GPT-6.1 工具调用该改哪 5 处
这一节是全文最实用的部分。把下面 5 处改完，一个典型的工具调用循环就能从 Chat 端点切到 Responses 端点。
| 序号 | 改动点 | Chat Completions 写法 | Responses 写法 |
|---|---|---|---|
| 1 | 调用方法 | client.chat.completions.create |
client.responses.create |
| 2 | 输入载体 | messages 数组 |
input 参数 |
| 3 | 工具声明 | tools（保留） |
tools（结构基本一致） |
| 4 | 工具结果回填 | role: "tool" 的消息 |
function_call_output 类型的条目 |
| 5 | 多轮上下文 | 手动拼完整 messages |
可用 previous_response_id 串联 |
第 1 处和第 2 处是最容易被漏掉的。很多人改完 tools 结构就以为迁移完成了，结果发现 SDK 方法根本没变，请求依然打在 chat.completions 上。端点是由方法决定的，方法不改，端点就不会变。
第 4 处是迁移里最容易卡住的地方。Chat 的做法是把工具执行结果作为一条 role: "tool" 的消息塞回 messages；Responses 则是把模型返回的调用条目原样带回，再补一条 function_call_output。少带一条、顺序错一位，模型就可能重复发起同一个调用。
第 5 处属于“可以不改，但建议改”。Responses 支持用 previous_response_id 承接上一轮，省掉每次重发全部历史消息的开销。对于工具轮次多的 Agent，这一条对成本的影响比换模型更明显。
🎯 技术建议：迁移期间最省事的验证方式，是让新旧两条链路并行跑同一批请求，对比工具命中率和返回结构。通过 API易 apiyi.com 的统一接口可以省掉多平台 Key 管理的麻烦，一次配置就能对照 Responses 与 Chat 的实际返回差异。
GPT-6.1 工具调用快速上手
一个会调工具的最小例子
假设你有一个查订单状态的函数工具，名字叫 get_order_status，入参是订单号。要改动的地方只有两处：调用方法和结果回填。
- 客户端初始化保持原样，
api_key用你自己的 Key，base_url设为https://api.apiyi.com/v1，这样 OpenAI 兼容接口下的模型都能直接调用。 - 模型 ID 填
gpt-6.1-sol（或gpt-6.1-terra、gpt-6-astra），这三个都走 Responses 做工具调用。 - 把原来的
client.chat.completions.create(...)换成client.responses.create(...)，messages参数换成input。 tools照旧传进去，工具描述和参数 schema 不需要重写。- 从返回的
output里找到类型为function_call的条目，取出工具名和参数，本地执行你的查单函数。 - 把执行结果作为
function_call_output追加回去，再发起第二次请求获取最终回答。
这 6 步里，真正“必须改”的是第 3 步和第 6 步。第 1、2 步是配置，第 4、5 步是把 Chat 时期的习惯换个读取位置。
🚀 快速开始：如果不想自己搭测试环境，可以在 API易 apiyi.com 领取免费测试额度，把上面这个查单例子跑通一次，再回头改造生产代码，风险最低。
一个更省事的做法是先把工具层与模型层解耦：工具定义集中在一处，调用入口封装成一个函数，内部判断“纯文本走 Chat、带 tools 走 Responses”。这样迁移只发生在封装层，业务代码一行不用动。
GPT-6.1 模型价格与选型（2026-11-12）
下表按 2026-11-12 生效的口径整理，单位均为每 1M tokens 的美元价格。
| 模型 | 输入 | 输出 | 缓存读 | 端点建议 |
|---|---|---|---|---|
| gpt-6.1-sol | $2 | $10 | $0.1 | responses |
| gpt-6.1-terra | $1 | $5 | $0.05 | responses |
| gpt-6-luna | $0.1 | $0.5 | $0.01 | chat（reasoning_effort 为 none）或 responses |
从这张表能读出一个很实际的结论：GPT-6.1 Terra 的输入输出价格正好是 Sol 的一半，对于工具轮次多、上下文重复率高的场景，Terra 往往是更合适的默认档。而 GPT-6 Luna 的价格低了一个数量级，适合把分类、抽取这类轻任务放进去，把 Sol 或 Terra 留给真正需要推理的工具编排环节。
缓存读价格这一列值得单独看一眼。工具调用天然会产生大量重复前缀——系统提示、工具定义、历史对话——这部分命中缓存后单价是输入价的二十分之一左右。所以在 Responses 里用 previous_response_id 承接上下文，省的不只是流量，也是真金白银。
💰 成本提示：需要按项目拆分预算时，通过 API易 apiyi.com 的统一 Key 调用可以把多个模型的用量集中在一处统计，配合按量计费的方式更容易核算工具调用的真实成本。
GPT-6.1 工具调用常见问题 FAQ
Q1：GPT-6.1 是什么，和 GPT-6 是什么关系？
GPT-6.1 是 GPT-6 系列的迭代版本，目前包含 GPT-6.1 Sol 与 GPT-6.1 Terra 两款；GPT-6 系列则包括 GPT-6 Astra、GPT-6 Sol、GPT-6 Luna。它们共用同一套 Responses 工具调用通道，差别主要在能力定位与价格。
Q2：为什么 Chat Completions 调不了工具，是参数写错了吗？
不是参数问题。GPT-6 Astra、GPT-6.1 Sol、GPT-6.1 Terra 在 Chat Completions 上只提供纯文本能力，工具调用被限定在 Responses API。改 `tools`、改 `tool_choice` 都不会生效，需要把 SDK 方法从 `chat.completions.create` 换成 `responses.create`。
Q3：GPT-6 Sol 和 GPT-6 Luna 能在 Chat 里做函数调用吗？
可以，但仅限 `reasoning_effort` 设为 `none` 的时候。如果你需要保留推理强度，这两款也要走 Responses。这个限制在迁移时最容易被忽略，因为它不会报错，只会让效果和预期不一致。
Q4：迁移到 Responses 需要改模型 ID 吗？
不需要。模型 ID 保持 `gpt-6.1-sol`、`gpt-6.1-terra`、`gpt-6-astra` 即可，`base_url` 和鉴权方式也不变。真正要改的是调用方法、输入载体、以及工具结果的回填结构这几处。
Q5：怎么快速验证迁移后的工具调用是正常的？
推荐用同一个查单类小工具做冒烟测试：先确认请求确实打到了 Responses 端点，再确认返回的 `output` 里有 `function_call` 条目，最后确认回填 `function_call_output` 后模型给出了最终回答。三步都过，链路就是通的。在 API易 apiyi.com 上拿一个测试 Key 就能完成这套验证。
Q6：纯文本服务也需要一起迁到 Responses 吗？
不必。三款主力模型的 Chat Completions 纯文本能力仍然可用，只做问答、摘要、翻译这类任务的服务可以原地不动。只有涉及 `tools` 的请求必须迁走，这也是这次改动影响面分层的原因。
Q7：多轮工具调用怎么控制上下文成本？
优先用 `previous_response_id` 承接上一轮，而不是每轮重发完整历史。这样重复前缀更容易命中缓存，缓存读单价远低于输入单价。以 `gpt-6.1-sol` 为例，输入 $2、缓存读 $0.1，差距相当明显。
Q8：Responses 迁移有没有已知的坑？
比较典型的有两个：一是只改了 `tools` 结构却没改调用方法，请求仍然落在 Chat 端点；二是回填工具结果时沿用了 `role: “tool”` 的旧写法，导致模型拿不到输出而重复发起调用。另外，如果团队里混用 GPT-6 Sol 这类需要 `reasoning_effort` 为 `none` 的模型，最好在封装层做统一约束，避免出现“同一个工具在某些模型上能用、某些不能用”的情况。
GPT-6.1 工具调用核心要点 Key Takeaways
- 端点已分家：GPT-6.1 Sol、Terra 与 GPT-6 Astra 的文本走 Chat，工具必须走 Responses。
- 一个例外：GPT-6 Sol、GPT-6 Luna 可在 Chat 做函数调用，但要求
reasoning_effort为none。 - 五处改动：调用方法、
input载体、tools声明、function_call_output回填、previous_response_id串联。 - 模型 ID 不变：
base_url与 Key 都不动，迁移只发生在封装层。 - 成本看缓存：工具调用前缀重复率高，缓存读价格约为输入价的二十分之一。
- 验证三步走：确认端点、确认
output里有function_call、确认回填后拿到最终答复。 - 上手路径：用 API易 apiyi.com 的免费额度先跑通一个查单小工具，再改造生产链路。
总结
这次变化的核心只有一句：GPT-6.1 把工具调用从 Chat Completions 挪到了 Responses，纯文本能力留在原地。由此派生出的三件事值得记住：
- 先分类再迁移：只做文本的服务不动，带
tools的请求必须换端点。 - 改方法而不是改参数：
client.responses.create才是端点开关，tools结构只是配套。 - 结果回填是重灾区：
function_call_output替代了role: "tool"，顺序和完整性都要对。
如果你的项目已经在生产上跑工具调用，建议先抽出一个最小工具做灰度，确认链路通了再全量切换。想省掉多平台 Key 和环境配置的时间，可以通过 API易 apiyi.com 用同一个 Key 对照 Responses 与 Chat 的实际返回，base_url 统一指向 https://api.apiyi.com/v1 即可。
参考资料
- OpenAI 官方模型文档：GPT-6 系列与 GPT-6.1 系列的端点能力说明，含工具调用需走 Responses 的限制
- 链接：
developers.openai.com/api/docs/guides/latest-model -
说明： 判断某个模型能否在 Chat Completions 中做函数调用的第一手依据
-
API易模型与价格文档：各模型输入、输出、缓存读单价与推荐端点
- 链接：
docs.apiyi.com/models - 说明： 核对 2026-11-12 生效的计费口径与端点建议
作者: APIYI 技术团队
技术交流: 欢迎在 API易 apiyi.com 首页联系我们，更多接口说明可访问 docs.apiyi.com 文档中心
