如何建立具備對話狀態與壓縮功能的長期運行 GPT-6 Astra 代理
使用 previous_response_id、對話、明確狀態、上下文預算、壓縮、檢查點和恢復模式，設計耐用的 GPT-6 Astra 代理。
長時間運行的代理不僅僅是一個擁有龐大對話記錄的聊天機器人。它是一個有狀態的系統，必須在有限的上下文視窗內，保留目標、已完成的工作、工具結果、權限以及未解決的決策。GPT-6 Astra 提供了 1,050,000 個 token 的上下文視窗、持續推理支援、對話狀態和壓縮功能——但架構仍然決定了一個工作流程在數小時或數天後是否仍能保持連貫性。
區分四種狀態
將每個事件視為對話文本會使復原變得困難。請保持不同的層次：
- 對話狀態： 用戶與模型所說的內容。
- 任務狀態： 目標、計畫、限制條件、已完成步驟及阻礙因素。
- 世界狀態： 記錄在資料庫、檔案、票證及其他外部系統中。
- 執行狀態： 工具呼叫 ID、冪等性金鑰、核准、重試與檢查點。
只有第一層自然屬於逐字稿。其他三層應有應用程式自有的表示方式。模型可以協助更新它們，但不應作為唯一的記錄系統。
兩種繼續回應的方式
最簡單的接續機制是 previous_response_id：
const first = await client.responses.create({ model: "gpt-6-astra", 草擬遷移的實施計畫。 });
const next = await client.responses.create({ model: "gpt-6-astra", previous_response_id: first.id, input: [{ role: "user", content: "從驗證模組開始。" }] });
這會建立一個回應鏈。對於單次對話來說很方便，但並非計費捷徑：OpenAI 文件指出，鏈中的先前輸入令牌會以輸入方式計費。回應預設會儲存 30 天，除非使用 `store: false`。
若要使用持久執行緒，請使用 Conversations API。一個對話可包含訊息、工具呼叫與工具輸出，並可跨工作階段、裝置或任務重複使用。對話物件不受 30 天回應 TTL 限制。一個請求不能同時使用 `conversation` 與 `previous_response_id`；請審慎選擇狀態模型。
## 在需要之前先制定情境預算
上下文包含輸入、輸出和推理令牌。不要等到模型達到限制才行動。為下一個工具結果和最終答案保留空間，然後在超過閾值前進行壓縮或修剪。
一個實用的預算可以將百分比分配給：
- 持久耐用的說明與工具；
- 當前任務摘要；
- 最近的對話詳細資訊；
- 檢索到的證據；
- 預期的推理與輸出；
- 針對異常大型工具結果的緊急備用空間。
大上下文也對定價有影響。GPT-6 Astra 模型頁面記載，對於輸入超過 272K token 的請求，會對整個請求收取更高的費率。即使完整窗口遠未用盡，這個門檻也使得早期的上下文管理在財務上變得重要。
## 壓縮的作用
壓縮會減少先前的上下文，同時保留未來對話所需的資訊。OpenAI 提供了明確的 `/responses/compact` 端點與自動上下文管理功能。回傳的壓縮內容是不透明的：請依照指示將其傳遞，不要解析、編輯或將其視為面向使用者的摘要。
在語義里程碑處進行壓縮：
- 在研究綜合完成且不再需要探索原始來源之後；
- 在程式碼階段通過測試後；
- 在使用者核准方案之後；
- 在開始新的獨立階段之前；
- 當測量的上下文接近您計劃的閾值時。
避免在每次執行後進行壓縮。這會增加工作量，可能丟失有用的局部細節，並改變可重複使用的提示前綴，進而影響提示快取的行為。
```ts
const compacted = await client.responses.compact({ model: "gpt-6-astra", 累積項目 });
// Persist the returned compacted items and use them as the base for later work.
請使用目前的 SDK 參考文件以取得確切的型別；測試版與 SDK 介面可能會持續演進。不變的規則是保持不透明的輸出內容原封不動。
## 檢查工作進度，而不只是文字內容
生產檢查點應記錄：
- 使用者可見的目標與最新接受的範圍；
- 已完成步驟及驗證證據；
- 待處理的工具呼叫與核准狀態；
- 外部資源識別碼與版本；
- 具有來源的重要決策；
- 回應或對話識別碼；
- 單調遞增的檢查點版本。
假設一個動畫工作流程已批准劇本、生成角色參考資料，並開始進行場景組裝。代理應將素材 ID、批准狀態及場景狀態儲存在應用程式資料中。像 [Elser AI](https://www.elser.ai/) 這類平台是創意素材的天然存放地，但編排層仍需明確的狀態資訊，以避免恢復執行的代理重新生成已獲批准的場景。
## 中斷後的恢復
為「至少一次執行」而設計。連線可能在工具執行完成後、但客戶端收到結果前中斷。每個會改變狀態的工具都應接受冪等鍵（idempotency key），或支援先讀後寫（read-before-write）檢查。恢復時：
1. 載入最新提交的檢查點；
2. 檢查不確定操作的外部狀態；
3. 透過通話或冪等性 ID 調和工具結果；
4. 從壓縮狀態加上近期事件重建上下文；
5. 要求模型從明確的待辦事項繼續進行。
在崩潰後，切勿對模型說「繼續」而沒有提供結構化的狀態說明。它可能會重複動作或推斷錯誤的里程碑。
## 將壓縮與業務記憶體分離
壓縮是針對模型優化的上下文。業務記憶體是應用程式中持久且可檢查的記錄。在不明確的壓縮項目旁，維護一份簡潔的人類可讀任務帳本。該帳本讓操作員能夠審核決策、遷移模型，並在回應鏈不可用時進行復原。
好的帳本應包含事實，而非說服性的文字。例如：「客戶於14:32 UTC核准v7版計畫」比「客戶似乎對該計畫感到滿意」更有力。為從工具中取得的聲明儲存來源ID。
## 長時間運行的品質控制
測試超越最終答案的準確性。衡量：
- 在20、50和100回合後的目標保留率；
- 注入斷線後重複的副作用；
- 壓縮後正確恢復；
- 工具結果的來源；
- 授權持久性與到期；
- 每個里程碑的成本；
- 任務帳本與外部狀態之間的偏移。
納入對抗性測試，涵蓋舊訊息與較新指令衝突、工具回傳龐大資料量，或代理程式暫停期間核准逾期的情境。長期運行的可靠性主要取決於狀態轉換。
## 常見問題
### 我該使用對話還是 `previous_response_id`？
使用 `previous_response_id` 進行直接的響應鏈接。當您需要在不同會話或任務之間重複使用持久化物件時，請使用對話。它們不能在同一請求中同時提供。
### 一百萬個 token 的視窗能否消除壓縮？
不。成本、延遲、相關性以及已記錄的長上下文定價門檻，都使得在達到硬性限制之前進行上下文管理變得有用。
### 我可以編輯壓縮後的內容嗎？
將壓縮項目視為不透明。請另外維護您自己的可編輯任務清單。
### `store: false` 會改變什麼？
它會停用回應的預設儲存。您的應用程式隨後必須明確地攜帶所需的狀態，並滿足自身的保留與復原需求。
## 結論
耐用的 GPT-6 Astra 代理結合了 API 管理的對話連續性與應用程式擁有的任務及執行狀態。有意識地鏈結或持久化回應，在上下文變得昂貴之前進行預算，在里程碑處進行壓縮，保留不透明的壓縮項目，並讓每個外部動作都可恢復。最終產生的是一個能夠安全恢復工作的代理——而不僅僅是記住一段冗長對話的代理。
