實作指南 / 9 分鐘
把 Responses 當成系統邊界
圍繞 typed items、狀態選擇與可觀察輸出設計。
Responses API 是 OpenAI 新專案建議的起點。不要把它當成文字生成薄包裝；把 message、tool call、tool result 與未來輸入型態保留成明確事件。
A
工作原則
Items 優於字串
保留 typed input 與 output items；message、function call 與 function result 有不同責任。
刻意選擇狀態策略
明確決定由 server 儲存 history、串接 previous response，或使用持久 conversation；同時設計保留與刪除。
在系統邊緣正規化
對內提供穩定的 application response type，不讓 provider 欄位散落整個產品。
B
實地程序
- 01
先寫產品契約
列出輸入模態、預期輸出、允許 side effects、延遲預算與 caller 需要的證據。
- 02
轉成 typed items
把 user text、system instructions、files 與 prior context 組成明確序列。
- 03
選擇狀態路徑
標示每種 request 是 stateless、response-chained 或 conversation-backed，並在上線前加入刪除流程。
- 04
解析 output ledger
分別處理 message、tool calls、tool results 與 refusals；不要假設第一個 item 就是 final text。
- 05
留下驗收證據
記錄 request ID、timing、tool outcome、validation 與 application decision，預設不記錄敏感正文。
PASS / FAIL
驗收清單
- 已有 typed request adapter。
- 狀態與保留政策有文件。
- 每種 output item 都有明確分支。
- 測試涵蓋空白、refusal、tool-use 與 malformed outcomes。
WATCH / REJECT
失敗模式
- 讓 raw provider object 穿透整個 codebase。
- 把 stored response state 當產品資料庫。
- 只讀 convenience text 而遺失 tool 或 refusal event。