For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主要導覽

建議

開始使用

核心概念

SDK 與 CLI

資源

舊版 API

API Dashboard
試用 ChatGPT

對話狀態

瞭解如何在與模型互動時管理對話狀態。

OpenAI 提供幾種管理對話狀態的方法，協助你在對話的多則訊息或多輪互動之間保留資訊。

若 GPT-5.5 將中途的進度更新視為 最終回答，排查問題時，請確認你的整合正確保留了助理訊息的 phase 欄位。詳情請參閱階段 參數。

手動管理對話狀態

雖然每次文字生成請求都是獨立且無狀態的，你仍可將額外訊息作為參數傳入文字生成請求，實現 多輪對話 。以下以敲門笑話為例：

手動建構過往對話
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input=[
        {"role": "user", "content": "knock knock."},
        {"role": "assistant", "content": "Who's there?"},
        {"role": "user", "content": "Orange."},
    ],
)

print(response.output_text)

透過交替排列 user 和 assistant 訊息，你可以在傳給模型的一次請求中，呈現對話先前的狀態。

若要手動在生成的回應之間共用上下文，請將模型先前回應的輸出作為輸入，並將這些輸入附加到下一次請求中。

對於無狀態的推理模型請求，請保留回應中 output 陣列的每個項目。Responses API 預設會傳回加密的推理項目。重新傳入完整輸出，即可完整保留推理項目和助理的 phase 值。支援持續保留推理的模型可使用 reasoning.context: "all_turns"，將先前輪次中可用的推理納入下一次生成。請參閱在呼叫之間保留推理。

在以下範例中，我們先請模型講一個笑話，接著再請它講另一個笑話。以這種方式將先前的回應附加到新請求中，有助於讓對話自然流暢，並保留先前互動的上下文。

使用 Responses API 手動管理對話狀態。
from openai import OpenAI

client = OpenAI()

history = [{"role": "user", "content": "tell me a joke"}]

response = client.responses.create(
    model="gpt-6-astra",
    input=history,
    store=False,
)

print(response.output_text)

# Add all response output items, including encrypted reasoning items, to the conversation
history += response.output

history.append({"role": "user", "content": "tell me another"})

second_response = client.responses.create(
    model="gpt-6-astra",
    input=history,
    store=False,
)

print(second_response.output_text)

用於管理對話狀態的 OpenAI API

我們的 API 讓自動管理對話狀態更容易，你無須在每一輪對話中手動傳入輸入內容。

使用 Conversations API

Conversations API 與 Responses API 搭配使用，可將對話狀態持續儲存為長時間存在的物件，並為其提供專屬且持久的識別碼。建立對話物件後，你可以跨工作階段、裝置或作業持續使用它。

對話會儲存各種項目，包括訊息、工具呼叫、工具輸出及其他資料。

建立對話
conversation = openai.conversations.create()

在多輪互動中，你可以將 conversation 傳入後續回應，以持續保留狀態，並在後續回應之間共用上下文，無須將多個回應項目串接在一起。

使用 Conversations API 和 Responses API 管理對話狀態
response = openai.responses.create(
    model="gpt-6-astra",
    input=[{"role": "user", "content": "What are the 5 Ds of dodgeball?"}],
    conversation=conversation.id,
)

傳遞上一個回應的上下文

另一種管理對話狀態的方法，是使用 previous_response_id 參數在生成的回應之間共用上下文。這個參數可讓你串接回應，建立連貫的對話串。

傳入上一個回應的 ID，串接各輪回應
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="tell me a joke",
)
print(response.output_text)

second_response = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=response.id,
    input=[{"role": "user", "content": "explain why this is funny."}],
)
print(second_response.output_text)

在以下範例中，我們先請模型講一個笑話，再另外請它解釋笑點。模型擁有所有必要的上下文，因此能給出良好的回應。

使用 Responses API 手動管理對話狀態
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="tell me a joke",
)
print(response.output_text)

second_response = client.responses.create(
    model="gpt-6-astra",
    previous_response_id=response.id,
    input=[{"role": "user", "content": "explain why this is funny."}],
)
print(second_response.output_text)

WebSocket 模式中的 previous_response_id

如果你使用 Responses API 的 WebSocket 模式，延續對話時的 previous_response_id 語意與 HTTP 模式相同，但會透過持續連線的 socket，重複傳送 response.create 事件。

連線專屬的快取會將近期的回應保留在記憶體中，以低延遲延續對話。使用 stream_id 時，每個通道都能保留其最新回應；回應之間的承接關係仍由 previous_response_id 控制，因此只要另一個通道上的回應仍可使用，新通道就能從該回應建立分支。如果無法解析未快取的 ID，請傳送新一輪請求，將 previous_response_id 設為 null，並傳入完整的輸入上下文。

即使使用 previous_response_id，回應鏈中所有先前的輸入 Token 仍會在 API 中按輸入 Token 計費。

管理上下文視窗

瞭解上下文視窗，有助於你順利建立對話串，並在與模型的多次互動之間管理狀態。

上下文視窗 是單次請求可使用的 Token 數量上限，包含輸入、輸出及推理 Token。若要瞭解所用模型的上下文視窗，請參閱模型詳細資訊。

管理文字生成的上下文

當輸入變得更複雜，或對話包含更多輪互動時，你需要同時考量 輸出 Token 和 上下文視窗 的限制。模型的輸入和輸出皆以 Token 計量。模型會將輸入解析為 Token，以分析其內容與意圖，再組合 Token，產生合乎邏輯的輸出。在文字生成請求的生命週期中，模型可使用的 Token 數量有其限制。

  • 輸出 Token 是模型為回應提示詞而生成的 Token。每個模型的輸出 Token 上限各不相同。例如，gpt-4o-2024-08-06 最多可生成 16,384 個輸出 Token。
  • 上下文視窗 表示輸入和輸出 Token 可使用的總量；部分模型還會計入推理 Token。你可以比較各模型的上下文視窗上限。例如，gpt-4o-2024-08-06 的上下文視窗總量為 128k 個 Token。

如果提示詞很長，例如為模型加入額外的上下文、資料或範例，就可能超出模型的上下文視窗限制，導致輸出遭到截斷。

使用以 tiktoken 函式庫建構的 Token 化工具，即可查看特定文字字串包含多少個 Token。

例如，使用 o1 模型等具備推理能力的模型向 Responses API 發出 API 請求時，下列 Token 數量都會計入上下文視窗的總用量：

  • 輸入 Token（使用 Responses API 時，放在 input 陣列中的輸入內容）
  • 輸出 Token（回應你的提示詞時生成的 Token）
  • 推理 Token（模型用來規劃回應的 Token）

生成的 Token 若超出上下文視窗限制，超出的部分可能會在 API 回應中遭到截斷。

上下文視窗視覺化

你可以使用 Token 化工具來估算訊息將使用的 Token 數量。

壓縮

詳細的壓縮指引現已移至 壓縮。

後續步驟

如需更具體的範例和使用案例，請瀏覽 OpenAI Cookbook，或進一步瞭解如何使用 API 擴充模型能力：