OpenAI Decisions API 是什麼？predicate、choice、score 三題型、費用與換貨分流實作

週五晚上十一點，一家 3C 周邊網店的客服信箱躺著一封沒有主旨的信：「上週收到的滑鼠好像有點怪怪的，按鍵有時候會卡住，還會偶爾連不上，週末要拿去送人，可以幫我看一下嗎？」信裡沒有訂單號，沒有購買日期，就連「換貨」兩個字都沒出現。值班人員只剩兩條路：回信來回問三輪，拖過客人要送人的時間，或者憑感覺猜一條處理路線，猜錯了禮拜一再重來。單封這樣的信處理起來都不難，難的是數量一多、內容又糊、時間又趕。

把這類「反覆出現的小判斷」交接出去，正是 OpenAI 在 2026 年 10 月推出的 Decisions API 想站的位置。依 OpenAI 官方的 Decisions 指南，這個介面評估文字、圖片或兩者的組合，回傳「型別化答案」（typed answers），讓應用程式直接拿去做分類、分流與排序。官方在同一頁給出一個速度宣稱：比 Responses API 快約 10 倍。要留意這是官方的比較口徑，屬於行銷宣稱，沒有附上可覆核的基準報告，採用它之前先把這個但書記在旁邊。

這篇指南把官方文件裡的規格逐一攤開：三種題型怎麼選、請求跟回應長什麼樣、費用怎麼算、送出去的資料會被保留多久，全程用一家台灣 3C 周邊網店的換貨客服信當範例，從一封含糊的來信，走到三題分流的路由規則。已經在用對話介面做各種工作、還沒碰過開發者端 API 的人，可以先翻 ChatGPT 入門指南把基本盤補起來；底下從第一行規格開始，不預設你寫過程式。

官方指南對它的用途寫得具體：分類內容、分流請求、排序工作，中文語境裡對應的說法就是分類與分流。名字怎麼翻不重要，重要的是它解決的問題形狀：輸入是自然語言，輸出必須能進資料庫欄位、能進 switch 陳述式、能進排程優先序。如果你在客服信裡、使用者留言裡、內容投稿裡反覆手動做著某些小判斷，那些都是它的候選場景。

快速重點：Decisions API 於 2026 年 10 月 6 日進入公開測試，目前只支援 gpt-6-luna 一個模型，走專用的 POST /v1/decisions 端點。它回傳三種型別化答案：predicate 給某條件成立的機率（0 到 1）、choice 從你定義的選項裡挑一個、score 對有序等級做機率加權平均，分數可以落在等級之間。計價只收輸入 tokens，gpt-6-luna 在這個端點每 100 萬輸入 tokens 收 0.10 美元，沒有輸出與快取的費用。官方宣稱速度比 Responses API 快約 10 倍；送到這個端點的資料預設不用於訓練，但濫用監測紀錄依預設最長保留 30 天。

OpenAI Decisions API 是什麼：把反覆出現的小判斷交給 API

先把它放回服務家族裡看。寫文案、摘要文件、產生程式碼這類生成工作，輸出是一段你要再加工的內容；Decisions API 做的則是評估：你交給它一份證據（一段文字、一張圖片，或兩者混合），再交給它一組定義清楚的問題，它回傳的是可以直接餵進 if 判斷式的答案，機率、選項、分數，三選一。官方指南給它的定位原文是：取得某條件為真的機率、從固定選項裡取一個選擇、或按評分標準打一個分數，用這些答案在應用程式裡做內容分類、請求分流與工作排序。

這個定位決定了它的形狀。因為答案有固定型別，呼叫端不需要再解析自由文字；因為問題是你定義的，同一份 API 可以套在客訴分流、內容審核、工單排序完全不同的場景。官方指南首屏那句「把文字與圖片變成應用程式用得上的決定」講的就是這件事：上游是模糊的人類語言，下游是明確的程式分支。

2026 年 10 月上線：公開測試、gpt-6-luna 專用端點

時間軸攤開來看。依 OpenAI 平台的更新紀錄，2026 年 10 月 6 日的條目寫著「Released the Decisions API in beta with gpt-6-luna」，這是它的公開測試起點；10 月 15 日同一份紀錄又補上一條，GPT-Live 加入原生的 Decisions 整合，讓應用程式在使用者還在說話的當下就觸發決策。官方指南對成熟度的說法是：目前處於 public beta，官方預期「數週內」進入正式版。要把正式版日期寫死在任何專案時程表上，現在都還太早，對文件追蹤要比對日曆勤勞。

模型與端點目前都沒得挑：gpt-6-luna 是唯一支援的模型，請求打向專用的 POST /v1/decisions 端點，跟慣用的 /v1/responses 是兩條路。請求欄位表裡 model 欄位也寫明「Currently, only gpt-6-luna is supported」。這代表兩件事：一，你沒辦法為了省錢或追求別種個性換別的模型；二，這個端點的計價、行為與限制都綁著 gpt-6-luna 這個名字走，後面算費用時會再回到這裡。對 Luna 在 OpenAI 模型線裡的位置與計價層有興趣的人，GPT-6 Sol 與 Luna 的比較把同世代兩個型號的分工講得更細。

它負責判斷，不負責執行

一個容易誤會的點先釐清：Decisions API 回的是答案，動作還是你自己的程式要做。它可以告訴你「這封信比較該走售後，嚴重度落在中段」，但建立工單、發換貨流程、回信給客人，都是拿到答案之後你這端的系統接手。把它想成客服中心裡一位只看信、只給判讀意見的同事：判讀可不可靠，要用你自家標註過的歷史信件驗證過才算數，手則長在你的系統上。這個邊界對採購評估很重要：路由邏輯、資料流與拿到答案後的系統整合都在你這端，API 串接只是整體工作中的一環，導入的工作量與成本要依自家系統現況逐項估算。

官方在選擇指引裡也把這條線畫出來。需要這三種答案型別之一，用 Decisions；需要產生遵循自訂 JSON schema 的物件，例如抽取一組欄位或寫一段書面說明，用 Responses API 的 Structured Outputs；需要模型主動發起帶參數的工具呼叫，用 function calling。三個場景對三個介面；同一套系統也可以按需求搭配三者，要避免的是把同一個判斷疊床架屋地做好幾次。我們的換貨情境要的是分流與嚴重度，答案型別是機率、選項與等級分數，正好落在 Decisions 的轄區。

三種題型怎麼選：predicate、choice、score

整個介面的核心設計就是三種題型，先給對照表再逐一展開。

↔ 左右捲動檢視完整表格

題型	適合的問題	主要回傳值
predicate	檢查一個條件成不成立，例如照片裡有沒有可見損壞、一段文章相不相關	probability：條件為真的估計機率，0 到 1
choice	從一組沒有順序的類別裡挑一個，例如該歸哪個部門、內容屬於哪一類	choice：你供給的選項值其中之一
score	對一組有順序的等級評分，例如問題嚴重度	score：等級索引的機率加權平均，可落在等級之間

predicate：某一條件成立的機率

predicate 是三種裡最單純的：你描述一個可觀察的條件，它回傳 0 到 1 之間的機率。官方的用法示範是拿來檢查商品照有沒有可見損壞，或者判斷一段文字與某主題相不相關。以我們的客服信來說，「客人是否明確要求換貨，而非退費或維修」就是一個 predicate：條件寫清楚，答案是一個數字，0.92 表示幾乎確定，0.4 表示這封信根本沒把話說死。

機率的好處是留給你自己定奪的空間。若你現有的規則只能做真或假的二值判斷、難以涵蓋語意上的模糊地帶，predicate 給你一整條光譜，中段地帶怎麼處理由你的業務決定：機率很高的直接走自動流程，機率中段的先補問一句再決定。後面「門檻」一節會回到這裡，官方對門檻怎麼定有原則性建議，數字本身要靠你自己標註過的資料校準。

predicate 的應用面比客服信寬得多。內容平台拿它判斷一篇文章與某個欄目相不相關，電商拿它檢查商品照有沒有可見損壞，人資系統拿它看一段自述是否揭露特定經歷。共通點都是「條件可以觀察、答案可以是一個數字」的場合。反過來說，當你的問題需要一串理由、需要列舉證據、需要權衡多個沒有共同尺度的因素時，機率就承載不了那個答案，這時該回頭想是不是 Structured Outputs 或人工才對。

choice：從你定義的選項裡挑一個

choice 回答「這該歸誰處理」這類問題。你在題目裡供給一組選項，每個選項給一個值與一段描述，它回傳其中一個值。官方指南的示範是把客訴分流到帳務（billing）、技術（technical）、物流（shipping）、其他（other）四個部門，輸入是「我被重複扣款了」這樣一句話，答案自然是 billing。這個示範只是能力展示，選項集合完全由你定義，我們的網店會用自己的一套，後面情境段會看到。

選項設計有三個常見錯誤。一是選項之間有包含關係，「售後」與「換貨」若同時出現在選項裡，同一封信對兩個選項都成立，選項就失去官方指引要求的「不同的意思」，判讀也失去依據；二是漏了逃生口，沒有 other 這類選項時，歸不了類的信沒有正確的去處，分流答案的參考價值隨之下降；三是描述寫得太抽象，「相關事宜」這種描述對模型沒有鑑別力，要寫成「付款、退款與帳務相關」這種一眼能對照的內容。選項集合是 choice 題的靈魂，設計得好不好不能只憑直覺：實際的機率分布與錯誤率，要拿自家歷史信件驗證過才算數，值得據此反覆打磨。

score：對有序等級做機率加權平均

score 與 choice 的分界在一個字：順序。官方指南說得直白，兩種題型底層都回傳離散選項上的機率分布，choice 用在沒有順序的類別（例如部門），score 用在有順序的等級（例如嚴重度）。score 拿各等級的數值索引做機率加權平均，算出一個可以落在等級之間的分數。等級索引從 0 開始。

官方文件給了一組可直接換算的示範數字：三個等級，索引 0 是「只有外觀問題」（Cosmetic）、1 是「有替代做法可用」（Workaround available）、2 是「完全卡死」（Fully blocked），若模型對三個等級分別給出 0.1、0.7、0.2 的機率，加權平均就是 1.1，落在 1 與 2 之間。答案裡還附一個 confidence 欄位（該例為 0.55）與各等級的完整機率。這組數字出自官方指南，拿來理解演算法很好用，換到自己場景時等級要重新定義、機率要重新觀察。

加權平均的特性還有一層實務意義：分數會被極端案例拉扯。一封「有時卡住、有時斷線」的信，若模型在等級 1 給了 0.7，等級 2 給了 0.2，分數會落到 1.1 這種「一點一」的位置，閱讀時要想清楚它跟「標準的 1」差在哪。經驗上建議把分數當連續的急迫性指標用，別把它四捨五入回整數等級再看，那可能掩蓋機率分布與小數分數之間的差異。各等級的完整機率一起看永遠比只看單一數字踏實，1.1 可以是穩定的中間偏上，也可以是 1 與 2 之間的搖擺，兩者的處置節奏理應不同。

回應怎麼讀：機率分布、confidence 與 refusal

三種題型的答案結構略有差異。predicate 回的是那個估計機率；choice 與 score 額外附上完整機率分布，以及一個獨立的 confidence 欄位。官方文件對 confidence 的說明就到「獨立欄位」為止，沒有給出定義、計算方式或判讀標準，所以別直接假設數值高低就等於答案的對錯把握；把它當成另一個待校準的訊號，先用自家標註資料觀察它與答案品質的實際關聯，再決定要不要讓它參與路由，例如觀察後發現 choice 一邊回「售後」一邊給偏低的 confidence 時轉人工比較穩，這條規則才算成立。

還有一種答案要特別防：refusal。官方 SDK 範例在讀答案時的第一個檢查是 answer.type 是不是 refusal，是的話走拒答處理；官方並沒有列舉哪些輸入會觸發拒答，所以程式不該假設它只出現在哪一類信件，而是把這條路當成隨時可能發生的正常分支接好：收到 refusal 時交給人工佇列或退回處理，不能讓它變成沒有去處的黑洞。判斷順序建議固定：先看 type，再讀值，收尾看 confidence 決定自動處理或升級。

請求長什麼樣：一個請求、三個部分、多題並行

請求的骨架有三個部分。model 填評估用的模型，目前就是 gpt-6-luna。input 是所有問題共用的證據，可以是一段純文字字串，也可以是 user messages，訊息裡混文字與圖片。questions 是問題陣列，每題帶自己的 type、instructions，以及 choice 允許的 choices 或 score 的 levels。回應是一個 answers 陣列，你在每題上給的唯一 name 會原封不動回映回來，程式靠 name 對答案，不靠陣列順序。

多題的規則一句話就講完：彼此獨立的問題放同一個 questions 陣列，共用同一份 input，各題可以用不同題型；有相依關係的判斷，官方明確要求分次請求。第二句比第一句重要。如果「要不要請客人附照片」取決於「是否疑似硬體故障」的結果，那就是兩次呼叫，中間由你的程式決定第二次的 input。把相依問題硬塞進同一個請求，拿到的是兩個各自猜測的答案，寫程式時看不出問題，上線後才會在奇怪的信上炸開。

換貨客服信的三題分流：台灣電商情境實作

情境設定如下。一家專做 3C 周邊的台灣網店，主力商品是螢幕燈與電競滑鼠，旺季每天上千封，大宗是換貨、退費與規格詢問。今晚這封信的主人翁是位買無線電競滑鼠的客人：商品到貨第五天才回報，用詞含糊，只說「按鍵有時候卡住、偶爾連不上」，沒附訂單號，語尾補一句「週末要送人」。這封信的麻煩之處在於症狀是「可用但有問題」的模糊帶：不是開箱就壞，也完全不能算沒事，嚴重度與處理急迫性都需要判讀。

我們為這封信設計三個互相獨立的問題，一次請求送出。第一題 predicate：客人是否在信中明確提出換貨的請求。這題只看可觀察的文字——信裡寫出換新、換一顆這類意向才算數，沒有寫就計為否；「沒寫」不代表客人不想換，而是需求未明，後面門檻段會把這種信接住：機率低時依售後流程補齊訂單號與症狀等資料，機率落在中段才補問換貨意向，不讓機率去猜沒說出口的意向。第二題 choice：這封信該分流到哪一條處理線，選項是 payment（付款與退款事宜）、shipping（出貨與物流狀態）、after_sales（商品本身的故障與維修）、other（不屬於前三類的請求）。第三題 score：症狀對使用的影響程度，等級 0 是「功能正常，僅外觀或主觀感受問題」、1 是「主要功能可用，但部分功能間歇異常」、2 是「主要功能無法使用」。選項與等級的中文描述都自己寫，語義保持互斥，這是官方出題指引裡「給選項不同的意思」的實踐。

POST /v1/decisions
{
  "model": "gpt-6-luna",
  "input": "上週收到的滑鼠好像有點怪怪的，按鍵有時候會卡住，還會偶爾連不上，週末要拿去送人，可以幫我看一下嗎？",
  "questions": [
    {
      "type": "predicate",
      "name": "wants_exchange",
      "instructions": "客人是否在信中明確提出「換貨」的請求？僅在信中文字明確出現換新、換一顆等換貨意向時計為真；僅描述問題、要求退費、要求維修或單純詢問，只要信中沒有寫出換貨，皆計為否。"
    },
    {
      "type": "choice",
      "name": "route",
      "instructions": "這封信應該分流到哪一條處理線？依信中描述的主要問題判斷。",
      "choices": [
        {"value": "payment", "description": "付款、退款與帳務相關事宜。"},
        {"value": "shipping", "description": "出貨進度、物流與配送狀態。"},
        {"value": "after_sales", "description": "商品本身的故障、異常與維修換貨。"},
        {"value": "other", "description": "不屬於前三類的請求。"}
      ]
    },
    {
      "type": "score",
      "name": "usage_impact",
      "instructions": "症狀對商品主要功能的影響程度為何？等級依序如下。",
      "levels": [
        {"label": "unaffected", "description": "功能正常，僅外觀或主觀感受問題。"},
        {"label": "intermittent", "description": "主要功能可用，但部分功能間歇異常。"},
        {"label": "unusable", "description": "主要功能無法使用。"}
      ]
    }
  ]
}

回應會是三個答案，各自帶著 name 回來。想像中的合理讀法長這樣：wants_exchange 回 0.1，信裡從沒把「換」說出口，「明確提出換貨」這個條件在文字上不成立——機率低不代表客人不想換，而是需求未明，先依售後流程補齊訂單號與症狀資料再談下一步；route 回 after_sales，機率高度集中，症狀描述都是商品本身的事；usage_impact 回 1.2，落在「間歇異常」與「無法使用」之間偏前者，附帶的 confidence 若不高，這封信就該走人工。三個答案湊起來的路由決策是：售後線、先補問訂單號與具體症狀、急迫性中等但要趕在週末前回覆。上面的機率數值是為了說明讀法所編的示意，不是實際呼叫結果。

// 讀答案的固定順序（示意）
for (const answer of decision.answers) {
  if (answer.type === "refusal") { /* 進人工佇列 */ }
  else if (answer.name === "wants_exchange") { p = answer.probability }
  else if (answer.name === "route") { dept = answer.choice }
  else if (answer.name === "usage_impact") { sev = answer.score }
}

這段示意把官方 SDK 範例裡的 refusal 檢查保留在第一位，再依 name 取值。實際的欄位讀法依你所用 SDK 的文件為準，重點是順序：型別先檢查、值再取出，confidence 則套用依自家標註資料驗證過的規則，決定這個答案自動處理還是轉人工。三個答案都到手之後，路由決策的程式就只是普通的 if 與 else，沒有任何魔法。

加上商品照片：文字與圖片一起判斷

客人回信補上兩張滑鼠照片之後，證據就升級成文字加圖片。這時 input 要從純字串換成 user messages，訊息內容混合 input_text 與 input_image，而圖片格式不是可選做法：官方指南明載這個端點的圖片必須以 inline base64 data URL 的形式放進 image_url，託管的 HTTP 或 HTTPS 圖片網址、以及 file_id 形式的輸入都不支援，所以自家系統得先把照片讀成 base64 再組請求。官方的 predicate 範例題目寫的是「檢查照片中商品有沒有可見損壞，例如裂痕、撕傷或凹痕，忽略陰影與外包裝的損壞」，這個「忽略什麼」的寫法值得學：把常見的誤判來源直接寫進 instructions，等於在題目裡內建防呆。

我們可以為照片加開一題 predicate：「照片中可見的外觀異常是否與信中描述的按鍵卡住相符」，把客人說的與拍的對起來。回傳的機率依官方定義要讀作「這個條件成立」的估計，不是照片品質的分數——照片拍得很清楚、但看不見任何相符的異常，一樣會得到低值。這一題跟前述三題一樣獨立，可以放進同一個請求。圖片會增加輸入 tokens，費用那一節的試算會把圖片成本一起算進去。

換貨情境裡圖片判讀的價值不在抓兇，重點在分類。客人拍照片的角度、光線、距離五花八門，人眼判讀的疲勞與不一致正是規則引擎與人工都吃力的地方。實作時要把兩個判斷分開：一是「照片可見的異常是否與症狀相符」——機率高可以支撐快速換貨通道，機率低只代表照片裡看不到相符的異常，處理上回到症狀查證與售後流程，既不預設客人亂報，也不等於照片有問題；二是「照片是否足供判讀」——過暗、失焦、拍錯部位的片子才需要請客人補拍特定角度。照片夠不夠清楚可以另開一題 predicate 或在流程裡設檢查點判斷，兩條線各設各的門檻，避免把「沒拍到異常」的客人一律打回重拍。

缺資訊時不硬猜：門檻與轉人工的設計

官方指南對門檻有一段原則性建議：用你自己應用程式裡的標註範例來設定路由、過濾與審查的門檻，並依誤判成本選擇標準。以 wants_exchange 這題為例，兩種誤判定義在同一個條件上：假陽性是信中沒有明確要求換貨、模型卻給了高機率，代價是對沒開口的客人誤啟換貨流程，直接吃掉換貨成本；假陰性是明確要求換貨的信被壓成低機率，代價是明確需求被延後處理、多燒一輪往返與客人耐心。兩邊損失在你的生意裡不對稱，門檻要往哪邊偏，取決於你更賠不起哪一邊，這個問題 API 回答不了，只能靠你自己的歷史資料回答。

給一組我方示意值幫助理解，數字本身須以自家歷史來信驗證後才能用：predicate 的 wants_exchange 機率 p ≥ 0.75 視為明確提出換貨，走換貨流程；0.4 < p < 0.75 代表模型對「明確提出換貨」的估計落在中段，暫不自動判定，先補問一句「想要換新品還是退款」確認意向；p ≤ 0.4 視為信中沒有換貨的表達，依 route 的分流結果處理原始問題——以本例就是走售後線，先依售後 SOP 補齊訂單號與症狀資料，不預設換貨。choice 的 route 若機率高度集中且 confidence 過半才自動分派，落在 other 或 confidence 偏低就轉人工。score 的 usage_impact 在 1.5 以上視同急件。再次強調，這組數字是為了示範讀法自編的門檻，官方文件並未建議任何特定數值。

「轉人工」這條路要當成正式設計，安排後備的當班人力看佇列，別讓它變成萬年無人開的信箱。實務上建議把每個轉人工的案例簡單標註下來：模型當時給了什麼答案、人工後續怎麼處理。這些標註就是官方建議的「你自己的標註範例」，門檻的第一次校準與之後的定期調整都靠它。

出題的心法：官方指引的四個提醒

官方指南對怎麼出好題目給了一段濃縮的指引：圍繞可觀察的條件寫題、把不同關注點拆成不同題、給選項語義上有區別的意思、score 的相鄰等級要有可判斷的區分標準。四句話各自對應一種常見的出題事故。

圍繞可觀察條件，是別問「這位客人生氣嗎」這種內心狀態題，改問「信中是否出現明確的抱怨或要求補償」這種從文字就看得出來的條件。拆成不同題，是別把「要不要換貨」跟「該歸哪個部門」塞成同一題，兩個關注點各自獨立就各自出題，答案也好各自設門檻。選項語義互斥，是 choice 的描述不能讓「退款」跟「帳務」兩個選項都說得通——這是官方指引「給選項不同的意思」的直接要求；選項若語義重疊，對答案判讀的實際影響要拿自家資料驗證，不宜預設某種固定的錯誤模式。相鄰等級可判斷，是 score 的等級定義要寫出「上一級與這一級差在哪」，我們的等級 0 與 1 差在「有沒有功能層面的異常」，1 與 2 差在「主要功能還能不能用」，界線清楚，機率分布才有意義。

這四條也構成很好的自測清單。題目寫完先自問：條件觀察得到嗎？關注點拆乾淨了嗎？選項會互搶答案嗎？等級界線講清楚了嗎？四問都過，再進 Playground 實測。官方也建議先在 Playground 裡玩題目與輸入，寫程式之前先把題目的行為摸熟，這個順序能省下大量「程式寫完才發現題目出歪了」的重工。

費用怎麼算：只收輸入 tokens 的計價方式

計價規則在官方指南裡寫得很明白：gpt-6-luna 在這個端點的輸入單價是每 100 萬 tokens 0.10 美元，而且只付輸入 tokens，沒有 cache-read、cache-write 或輸出 tokens 的費用。區域處理的溢價與長上下文的輸入價格乘數適用。這組費率只限 /v1/decisions 的請求；同一個模型走其他介面時，依模型與處理層的標準計費。「只收輸入、沒有輸出與快取費用」是官方明載的計費規則，官方並未多作解釋，照規則估算成本即可。

交叉印證一下單價：OpenAI 平台定價頁上 gpt-6-luna 標準層短上下文的輸入單價同樣是每 100 萬 tokens 0.10 美元，與指南一致。定價頁上還列了 Batch 與 Fast 等處理層的不同價格，那些屬於 Responses 計價的範疇，不要搬進 Decisions 的成本估算。

拿換貨情境做一版我方試算，所有數字皆為自行估計的示意值，非官方數字。假設一封客服信平均 400 tokens，加計題目說明與選項描述後每次請求約 1,000 tokens；照片每張以 1,500 tokens 估。一個月 30,000 封信，其中三成（9,000 封）附照片、每封以兩張計，輸入 tokens 總量約 30,000 乘 1,000（純文字信）加 9,000 乘 3,000（附照信每封兩張共 3,000 tokens），等於 5,700 萬 tokens，乘上每 100 萬 0.10 美元，月費約 5.7 美元；這個試算未計區域處理溢價與長上下文輸入乘數，實際帳單依你的設定而定。要留意這個數字只代表 API 帳單這一項：誤判造成的郵資與人力成本、導入的工程時間、門檻校準的投入，都因店家與團隊狀況而異，做導入決策時請把這些項目分開自行估算，不要只看 API 月費。

在每月處理量與區域設定固定的前提下，費用控制可優先從兩個地方下手：輸入的長度與非必要照片的數量。題目寫緊湊、只送判斷需要的證據，單價再低也經不起無意義的堆疊；沿用試算段的同一組假設具體對照，只送症狀描述與兩張關鍵照的請求約 4,000 tokens，若改成把假設再多 3,000 tokens 的完整往返歷史與十張附件照（15,000 tokens）全部塞進去，單次請求就膨脹到約 19,000 tokens，月費隨輸入量等比例放大。由於計價只看輸入，這些修剪直接反映在帳單上。長上下文的輸入價格乘數同樣適用，若要把整段對話歷史一起送，記得先把乘數算進月費估算。

和 Responses API、Agents API 怎麼分工

把三個容易混淆的介面再排一次。要「答案」：機率、選項、分數，而且要快、要便宜、要穩定格式，走 Decisions API。要「結構化生成」：照你的 JSON schema 抽欄位、寫說明文字，走 Responses API 的 Structured Outputs。要「多步驟代理」：讓模型規劃流程、呼叫工具、維持狀態，走 OpenAI Agents API。以客服系統為例，分流用 Decisions，自動回覆的草稿用 Structured Outputs，處理需要跨系統查訂單、改庫存的複雜個案用 Agents，三層各司其職。

模型世代也要放進地圖。gpt-6-luna 在這個端點獨挑大樑，而 OpenAI 的模型線上還有同世代的 Sol 與旗艦定位的 Astra 各自的舞臺：GPT-6 Astra 指南整理了旗艦模型的定位與計價。Decisions 目前綁定 gpt-6-luna 單一模型，這是現狀而非品質保證：計價與規格都綁在同一個名字上、文件好對照，但答案品質一樣要用自家標註資料驗證，官方並未承諾跨版本的行為穩定；代價是未來模型世代交替時，題目與門檻可能要跟著重新校準，這也是把題目寫成可重測資產的另一個理由。

這組分工還有一個用途：防止一種堆疊傾向——明明只需要一個答案，卻把整段代理框架搬進來。架構要依功能需求選：固定的分流判斷用不著多步流程與狀態管理這些代理機能，兩種架構的成本與延遲差異，留給你在自己的場景量測，別預設誰一定比較貴或比較快。判斷的準則回到官方畫的三條線：要機率、選項或等級分數這種固定答案型別，用 Decisions；要自訂 JSON schema 的生成物件，用 Structured Outputs；要模型主動發起帶參數的工具呼叫，用 function calling。在這三條線之外，Agents API 處理的是更進一步的需求：讓模型規劃多步流程、呼叫工具並維持狀態。一般程式拿到答案後依值分流、寫進資料庫、排進佇列，本來就是 Decisions 的設計用途，不需要因為「流程會依答案走分支」而升級到代理；當你需要的下一步要由模型自己決定呼叫什麼工具、跨多輪進行時，再讓代理上場，或與 Decisions 搭配。

資料會被訓練嗎：30 天濫用監測、ZDR 與導入前的檢查點

客服信裡有姓名、地址、電話，資料治理問題必須先於功能討論。第一層答案在 官方的資料控制文件：自 2023 年 3 月 1 日起，送到 OpenAI API 的資料預設不用於訓練或改進模型，除非明確選擇分享。資料控制表裡 /v1/decisions 的「Data used for training」欄位是 No。就「會不會被拿去訓練」這個問題，預設答案是否定的。

第二層要分清楚「不訓練」與「不留存」是兩回事。濫用監測紀錄依預設對所有 API 功能使用產生，最長保留 30 天，法律要求或為保護服務與第三方必要時得更久；這些紀錄可能含客戶內容（例如 prompts 與回應）與衍生的 metadata。/v1/decisions 的專節寫明：預設濫用監測紀錄最長保留 30 天，符合資格的客戶可申請 Zero Data Retention。指南同一節也載明 Decisions API 支援 ZDR 與 HIPAA（限符合資格客戶），資料居留在美國與歐洲（EEA 加瑞士）有支援。換句話說，預設狀態下的監測紀錄可能包含信件內容，保留時間最長 30 天、特定情況（法律要求或為保護服務與第三方）可能更久，零保留要另行申請。

台灣企業導入前的檢查點可以列成三問。一，送出的內容能不能先做最小化：訂單號、姓名如果在判斷上用不到，就先在自家系統遮罩再送出，把「可能留存 30 天」的暴露面縮到最小。二，零保留需求是否成立：有合約或法規要求零保留的組織，先向 OpenAI 申請 ZDR 的資格審核，通過前不要把正式流量倒進去；還要記得資格通過不等於全面零留存，官方資料控制文件列有例外，與本文照片流程直接相關的一條是：圖片輸入經 CSAM 掃描，分類器判定疑似時即使啟用 ZDR，該圖片仍會留存供人工審查；prompt 快取產生的 application state 也可能保留至 24 小時才到期。通過資格後，核對實際啟用的設定與適用的功能範圍，別把「資格通過」直接當成「全部為零」。三，資料居留是否需要指定：支援區域在美國與歐洲，對居留地有特定要求的專案，確認區域處理的設定與費用溢價再上路。三問都過了，再談門檻調校。

治理面向的收尾一件事情，是把它寫進制度。API 供應商的資料處理條款會隨版本更新，beta 階段尤其如此，把「重新檢視官方資料控制文件」排進每次介面升級的檢查清單，跟改程式碼放在同一張票上。要做個資盤點或隱私影響評估的組織，建議把第三方服務的留存政策明確記錄進盤點或評估文件，這份官方文件正好提供現成的依據：不訓練、監測紀錄可能含信件內容且預設最多保留 30 天（特定情況可能更久）、可申請零保留（仍有前述例外）、符合資格並完成設定後可使用美國或歐洲（EEA 加瑞士）的資料居留與區域處理。制度先把位置留好，工程才不用在稽核前趕工。

誰適合現在導入：三種團隊的起步方式

第一種，已經有穩定人工流程與歷史信件的大流量團隊。你們最有本錢立刻開工：歷史信件就是現成的驗證集，人工處理結果就是標準答案，門檻校準有數據可依。對你們來說，合理的起步是把「可自動化的流量比例」當成待驗證的試驗目標：先用歷史信件回測，找出誤判成本低到可以放行自動處理的那一段，再讓人力集中在真正的疑難個案；起步點建議選一個誤判成本低、可以被覆核的判斷，例如分流，而不是直接自動核可換貨。

第二種，還在累積量的小團隊。每天二三十封信，人工處理得來，先別急著寫程式。這個階段最划算的動作是開始標註：每封信記下你怎麼分類、怎麼處理、花了幾輪往返，三個月後你就有自己的標註集與門檻依據。等量起來了，題目設計幾乎是水到渠成，因為你早已知道自己的判斷規則長什麼樣。

第三種，已經有規則引擎或先前自動化經驗的團隊。若現有規則靠關鍵字與表單欄位就能覆蓋大部分來信，先不用急著換掉；難以涵蓋的是自由文字的變化——客人的說法千奇百怪，關鍵字清單永遠追不完——這正是 Decisions 能補的位置。建議採並行制：新舊兩套同時跑一段時間，規則引擎照舊執行，Decisions 只記錄不執行，定期比對兩邊的答案分歧。分歧的案例就是規則要更新或題目要修的地方，這段並行期同時也是最扎實的驗收。

導入四步：從 Playground 到正式上線

第一步，Playground 試題。官方建議在寫程式前先到 Playground 把題目與輸入玩熟，這一步的目標是驗證題目設計：拿十封真實歷史信件（去識別化後）餵進去，看三題的答案是否符合你的人工判讀，出題心法的四個自問在這裡全部派上用場。

第二步，歷史驗證。抓一到三個月的歷史來信，批次送出、人工複核，把每題的答案跟當時真人處理的結果對齊，記下不一致的案例回頭修題目或等級定義。這一步產出的標註資料，就是第三步校準門檻的唯一依據，官方建議的路徑正是用自家標註範例定門檻。

第三步，定門檻。依誤判成本把每題的門檻定下來，轉人工的條件一起定，並安排後備人力。第四步，串客服系統。把 API 呼叫接進信件流程，refusal 與錯誤路徑都要有去處，上線後持續抽樣複核並定期重校門檻。跑官方 SDK 範例有版本門檻，列表如下。

↔ 左右捲動檢視完整表格

SDK 語言	需求版本（或更新）
Python	3.26.0
JavaScript	7.30.0
Go	3.73.0
Ruby	0.101.0
Java	4.78.0

語音也能直接觸發：GPT-Live 的原生整合

文字與圖片之外還有第三個入口。2026 年 10 月 15 日，官方更新紀錄寫下 GPT-Live 加入原生的 Decisions 整合：應用程式可以在使用者還在說話的當下觸發決策。官方指南也闢了「Connect voice to Decisions」專節，示範從口說請求裡選動作、或隨對話內容即時觸發決策。對客服場景，這指向的是電話進線的即時分流：客人用講的，決策在對話中就發生。這條路線對延遲的要求比信件處理嚴苛得多，也還在快速演進中，適合列為觀察項，第一步先從非即時的信件分流練起穩妥得多。

從一封含糊的信開始

回頭看開場那封週五深夜的信。人工流程裡，它是一封要來回三輪的燙手信；在 Decisions 的流程裡，它變成一次請求、三個答案、一條明確的路由決策：route 高度集中在售後，自動分派售後線；wants_exchange 的 0.1 落在低區間，不預設換貨，依售後 SOP 補問訂單號與具體症狀；usage_impact 的 1.2 未達急件門檻，排一般時效、但掛在週末送人期限前要回覆的那一批。若來的是另一封信——把「換」說得明白的，或症狀已經讓整支滑鼠動不了的——同一套題目會各自踩進換貨流程與急件排程的分支。判斷被交出去，責任與流程留在你手裡，這個介面畫出的分工線對小團隊特別友善。

起步的建議跟官方同路：先到 Playground 用自己的歷史信件把三種題型玩一遍，感覺一下機率、選項與分數各自適合你業務裡的哪個問題，再決定第一個要自動化的判斷是什麼。beta 階段的介面會持續變動，追著官方指南與更新紀錄走，比追任何教學都可靠；當第一題上線、第一封信被正確分流的那天，你會知道那些出題的功夫沒有白花。