作者注：如果你現在的 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 文檔中心
