高效批次處理策略

CCA-F 考試任務說明 4.5——「設計高效率 batch processing 策略」——位於 Domain 4（提示工程與結構化輸出，佔比 20%）之內，是藍圖中唯一明確針對工作負載形態而非提示形態的任務說明。考試測驗的是：架構師能否判斷何時應將大量工作從同步 Messages API 呼叫切換至非同步 Message Batches API、如何使用 custom_id 將數千筆結果對應回應用程式記錄、50% 批次折扣與 24 小時 SLA 如何與業務延遲需求互動，以及如何在不讓整批失敗的前提下處理逐項錯誤。社群通過報告一再指出，batch 設計是「預設用 batch 省成本」的考生在延遲敏感情境題上失分、以及「為求安全預設走即時」的考生在 throughput 與成本情境題上失分的核心戰場。

這份學習筆記涵蓋 CCA-F 考生需要在架構層級設計的完整 batch processing 面向：Message Batches API 的基本原語、50% 折扣與 256 MB / 10 萬請求的結構限制、24 小時完成 SLA 與 29 天結果保留期、custom_id 對應契約、帶有逐項 params 的請求陣列形態、輪詢 processing_status 與 in_progress_requests 的模式、將延遲容忍度與工作量對應至 batch 或即時的決策矩陣、逐項錯誤與批次級失敗的語義差異、只重新提交失敗 custom_id 的 retry 策略、throughput 飽和戰術，以及最密集考察 batch 設計的兩個 CCA-F 情境（結構化資料擷取與 claude-code-for-continuous-integration）。最後以陷阱章節、練習錨點和五題 FAQ 收尾。

Message Batches API 是什麼 — Claude 的非同步大量推論端點

Message Batches API 是 Anthropic 平台上的專屬端點，可接受一批 Messages API 請求清單，對 Claude 進行非同步處理，並在批次完成後回傳彙整結果。它在架構上與同步 Messages API 完全分離：透過 batch 提交的請求不會在原始 HTTP 呼叫上回傳回應；你的應用程式提交批次後，會收到一個批次識別碼，之後再去輪詢或接收結果就緒的通知。

Message Batches API 的存在，是因為大量生產環境中的 Claude 工作負載並非互動式的。為文件庫補齊結構化擷取、對前一天的逐字稿進行夜間審查、處理研究資料集、對一萬筆進件申請評分——這些工作負載都不需要兩秒內的回應。它們需要的是結果正確、成本低廉、throughput 高效。Batch API 就是讓這些取捨明確化的架構原語。

同步 Messages API 與非同步 Batch API 的一句話比較

同步 Messages API 是為互動式延遲優化的請求-回應管道；Message Batches API 是為 throughput 與成本優化的提交-取回佇列。在一個端點上有效的請求 body，在另一個端點同樣有效——模型、訊息、工具、系統提示、JSON schema、tool_choice、max_tokens、temperature，全部相同。唯一改變的是回應抵達的時間與方式。

Batch Processing 使用情境 — 大量擷取、非同步審查、資料集處理

CCA-F 情境題對 batch 適用的工作負載有非常具體的框架描述。在考試當天能夠冷靜辨識這些框架，是最快找到正確答案的捷徑。

大量結構化資料擷取

典型的 batch 工作負載是跨文件庫的結構化資料擷取：解析一萬份履歷成應試者 schema、為五萬筆支援工單加上分類法標籤、從十萬張發票擷取供應商感知的 JSON 結構。每份文件彼此獨立（無跨文件相依性）、每次擷取使用同一份提示模板搭配逐份文件的 content 替換、業務截止時間是隔夜而非即時。這是結構化資料擷取 CCA-F 情境叢集測試最密集的形態。

非同步多遍審查

多遍審查架構（任務 4.6）往往將工作扇出至兩到三個不同的提示——擷取、品質查核，再到對帳遍。當審查週期在大型語料庫上以夜間或週為單位執行時，每一遍都預設使用 batch。Batch API 處理第一遍，結果送入第二遍，以此類推。遍與遍之間的延遲是以小時計，而非秒，且 50% 折扣在每一遍上疊加。

資料集標註與評估

離線模型評估 pipeline——對一千筆保留測試提示跑 Claude 以計算指標，或重新標註訓練集以比較分類法——是典型的 batch 工作負載。沒有人在等待、工作量高、重複執行放大成本，且延遲需求實際上不存在。

CI/CD 大量分析

在 claude-code-for-continuous-integration 情境中，夜間 pipeline 可能分析前一天所有 pull request 中變動的每個檔案，或審查每個未結議題的 triage 標籤。這些工作負載是非互動式的、高量的、且以明天為截止點——都是經典的 batch 候選。但同一條 pipeline 若是在每次 commit 的每個 PR 上觸發，就需要同步 Messages API 呼叫，因為開發者正在等待。

Message Batches API 結構 — 在單一 API 呼叫中提交多筆請求

批次提交是單一 HTTP POST，其 body 帶有一個 requests 陣列。陣列中的每個元素是一筆完整、獨立的 Messages API 請求，並以呼叫者自定義的 custom_id 包覆。整個批次作為一次提交成功或失敗，但內部的請求是獨立處理與計分的。

請求陣列形態

requests 中的每個元素包含兩個頂層欄位：

• custom_id — 呼叫者選擇的字串（批次內唯一），用來將這筆請求與最終結果對應。
• params — 這筆個別請求的完整 Messages API body：model、max_tokens、messages，以及選用的 system、tools、tool_choice、temperature 和其他標準 Messages API 參數。

每個 custom_id 在其批次內必須是唯一的；重複值在提交時會被拒絕。custom_id 是呼叫者自定義的字串——Anthropic 絕不會替你產生它們。這是 batch 題目上最常被忽視的架構事實。

提交回應

提交批次後，端點會回傳一個批次物件，其中包含批次 ID、processing_status（初始為 in_progress）、請求計數（total、processing、succeeded、errored、canceled、expired），以及建立時間戳與到期時間戳。批次物件是你用來輪詢完成狀態並日後取回結果的控制代號。

結構限制

Message Batches API 對每個批次強制執行兩個結構上限：

• 每批次最多 10 萬筆請求。
• 每批次總 payload 最大 256 MB。

需要更大工作量的批次必須拆分為多次提交。兩個上限都是硬性的——任一超出，提交就會被拒絕。

Batch 定價 — 相較即時 API 呼叫節省 50% 費用

Batch processing 的經濟優勢是：與同模型的同步 Messages API 呼叫相比，input 和 output token 都享有 50% 折扣。這是考試要求你不假思索就能說出的頭號數字，也是每道「batch 還是即時」成本計算情境題的核心轉折點。

折扣的適用方式

50% 折扣在 token 層級計費上適用——批次請求中的 input token、output token，以及（適用時的）cached token，全部以同步費率的一半計費。折扣不受模型影響，在支援的 Claude 家族中一視同仁——Haiku、Sonnet、Opus 的批次 token 各自從其同步定價打對折。折扣不是事後退款；它在帳單時直接套用。

折扣不涵蓋的範圍

折扣僅適用於模型推論 token。它不改變批次結構限制（10 萬筆請求、256 MB）。它不豁免 24 小時 SLA。它不適用於你系統中非批次的部分——若你的 pipeline 在批次前先用即時呼叫預先評分，那筆預評分呼叫仍以完整同步費率計費。

經濟決策框架

在架構層面，50% 批次折扣在三個條件同時成立時最具意義：（a）工作量大到絕對金額差異顯著；（b）沒有人在等待個別結果；（c）24 小時 SLA 與業務截止時間相容。若三者中任一不成立，50% 折扣就是干擾項，真正的架構選擇在別處。

Batch SLA — 24 小時處理保證與可取用期間

Message Batches API 的服務等級承諾是：提交的批次在 24 小時內完成。這個數字是整個任務說明 4.5 最容易踩坑的事實，考生在每次考試中都因此丟失計分題。

「24 小時以內」是上限，不是目標時間

24 小時 SLA 是平台在正常情況下完成批次所需的最長時間。絕大多數批次——特別是小批次——在幾分鐘到幾小時內就完成了。「24 小時以內」不代表「在第 24 小時那一刻」。假設每個批次恰好需要 24 小時的答案是錯的；假設「通常遠快於 24 小時，但最長可能到 24 小時」的答案才是正確的。

結果保留期

批次完成後，結果從建立起最多保留 29 天可供取回。保留期過後，結果會被刪除，且無法復原。需要長期保存的應用程式必須在到期前主動將結果拉取並存入自身的系統——批次結果不是耐久的存檔。

過期的批次

若批次在最長處理期（24 小時）內未完成，它會轉移到 expired 終止狀態。批次內尚未完成的請求會計入 expired 請求數，而批次內的部分成功結果仍可透過 custom_id 取回。過期的批次無法恢復；失敗或過期的項目必須以新批次重新提交。

custom_id 欄位 — 將批次請求對應回應用程式記錄

custom_id 契約是 batch API 與你的應用程式資料庫之間的架構橋梁。弄錯這一點是最常見的實作層級批次錯誤。

custom_id 永遠由呼叫者定義

你來選 custom_id，不是 Anthropic。批次請求沒有任何「系統自動產生」的識別碼。若你不提供有意義的 custom_id，你收到的結果集將無法對應，只能靠脆弱的啟發式方法（例如請求順序，而請求順序跨 API 邊界並不保證穩定）來重建識別關係。

從穩定鍵衍生 custom_id

生產實務是從你的主鍵衍生 custom_id。工單標籤批次用 ticket-{{id}}，履歷解析批次用 resume-{{uuid}}，多遍審查用 pass{{n}}-{{record_id}}。如此一來，結果串流就能輕鬆 join 回你的資料庫。

批次內的唯一性

custom_id 在單一批次提交內必須唯一。跨批次不需要唯一，但跨批次重複使用是程式碼壞味道——它暗示你提交了兩次相同的工作。若你的 pipeline 將批次 N 中失敗的項目 retry 至批次 N+1，應沿用相同的 custom_id 值，使你的資料庫 upsert 邏輯將其視為對同一筆記錄的更新。

對應優先於排序

永遠不要假設結果的順序與請求的順序一致。Batch API 以最有效率的順序處理請求，結果串流可以自由交錯或重排。永遠用 custom_id 對應，絕不用陣列索引。

輪詢批次結果 — 確認完成狀態並取回結果

批次完成是透過輪詢批次的 processing_status 欄位來偵測，而非等待推送通知。CCA-F 期望你能識別輪詢模式，並選擇合理的輪詢頻率。

Processing Status 值

每個批次帶有頂層 processing_status，依序經過：in_progress（工作仍在進行）、canceling（取消請求正在處理中）、ended（批次已達終止狀態，所有請求均已完成、出錯、取消或過期）。一旦 processing_status 為 ended，結果即可取回。

請求層級計數

批次物件內的 request_counts 區塊追蹤 processing、succeeded、errored、canceled 和 expired 計數。這些計數隨批次推進而更新，讓你無需取回結果就能區分部分成功與完全失敗。

輪詢頻率指引

由於大多數批次在 24 小時 SLA 內就完成了，指數退避輪詢是標準做法：頭幾分鐘每 30 秒輪詢一次，然後每分鐘一次，再每五分鐘一次，在 SLA 窗口尾段約每 15 分鐘一次為上限。每秒狂打狀態端點是浪費；每小時才輪詢一次則可能在完成後閒置很久。每五到十五分鐘的簡單定時輪詢，對大多數 pipeline 已經足夠。

取回結果

一旦 processing_status 為 ended，專屬的結果端點會串流一份逐行 JSON（JSONL）的結果串流，每行對應一筆原始請求，每行都標有其 custom_id。每行帶有 message（成功時）或 error 區塊（逐項失敗時）。請在 29 天保留期內將 JSONL 串流讀入你的系統記錄。

Batch 請求結構 — 帶有逐項 custom_id 與 params 的 requests 陣列

除了頂層陣列形態，逐項的 params 物件值得專項關注，因為 CCA-F 考試測驗的正是考生是否理解每一筆批次請求都是完整、獨立的 Messages API 呼叫。

每個項目可以有自己的系統提示、工具和模型

Batch API 不要求批次內的請求具有一致性。你可以提交一個批次，其中項目 1 用帶有某組工具的 Sonnet、項目 2 用帶有不同工具的 Haiku、項目 3 用完全沒有工具的 Opus。每個項目的 params 是獨立的。實際上大多數批次的 params 是同質的，因為工作負載就是「對 N 個輸入跑同一份提示模板」，但異質性是被支援的，偶爾也有其用處（例如，在同一次提交中將低複雜度項目路由至 Haiku、高複雜度項目路由至 Sonnet）。

Tool Use 在 Batch 內有效，但僅限單輪

Batch 支援每筆請求 params 中的 tools 和 tool_choice，這是結構化擷取透過 strict: true 工具呼叫強制符合 schema 輸出的機制。Batch 不支援的是多輪 agentic loop——你的程式碼無法在批次請求進行到一半時觀察 tool_use 結果並回注 tool_result。每個批次項目都是單一 Messages API 呼叫。若任務需要 agentic loop（讀取檔案、決策、再讀另一個檔案、再決策），batch 就不是正確的原語，應改用帶有 run() 或手動迴圈的同步 Messages API。

不支援串流

Batch API 不支援串流。每個項目的回應整體回傳；沒有 server-sent events、沒有逐增 token、沒有生成中可觀測性。任何真正需要串流的工作負載（聊天 UI、即時儀表板），同步 Messages API 是唯一答案。串流相關的內部機制明確超出 CCA-F 範圍，但「batch 無法串流」作為架構約束是在範圍內的。

Batch 與即時的決策矩陣 — 延遲容忍度、成本敏感度、工作量

任務 4.5 上最常被考的概念，是 batch 與同步 Messages API 之間的決策。CCA-F 沿三個軸框架這個決策：延遲容忍度、成本敏感度、工作量。

軸一：延遲容忍度

若個別結果必須在幾秒內回傳（互動式 UI、即時客服、agent 內部的同步工具呼叫），同步 Messages API 是唯一正確答案——batch 無法保證個別項目的延遲。若個別結果允許花費幾分鐘到幾小時（隔夜補齊、週級審查、夜間擷取），batch 是可行的。若業務真的不在乎結果在 24 小時內何時抵達，batch 是首選。

軸二：成本敏感度

同模型下，Batch 的每 token 費用永遠比同步便宜 50%。當絕對成本是主要驅動力且延遲允許時，batch 勝出。當成本相較於快速回應的業務價值微不足道時（例如，客服 agent 解決關鍵工單），同步勝出，不管 50% 折扣多誘人。

軸三：工作量

Batch 是為高工作量設計的。單一批次可在一次提交中攜帶 10 萬筆請求，將 HTTP 和身份驗證的開銷攤薄至整個批次。同步 Messages API 是為低工作量、請求-回應型流量設計的。每天十筆請求，兩種方式都行；每天一萬筆請求且沒有互動式使用者，batch 才是正確的原語。

2x2 心智模型

考生可以在考試當天腦中畫出的簡化 2x2 矩陣：

任何 CCA-F 情境落在右下象限——高工作量、高延遲容忍度——都預期以 batch 作為答案。

大規模成本快速估算

對於每週一百萬筆請求、每筆請求平均 2000 input token 和 500 output token 在 Sonnet 上的工作負載，同步與 batch 的成本差異相當可觀。50% 批次折扣套用在每週整體的每筆 2500 token 負載上。情境題不要求考生計算精確金額，但要求認識到「相當可觀」意味著「當延遲允許時，batch 是正確的架構選擇」。在那種規模下預設走同步是反模式。

Batch 中的錯誤處理 — 逐項錯誤與批次級失敗

Batch API 中的錯誤分為兩類，CCA-F 考試測驗考生能否區分它們。

逐項錯誤

逐項錯誤表示批次內某一筆特定請求失敗，但整個批次照常繼續。結果串流中那筆 custom_id 帶有 error 區塊而非 message。常見的逐項錯誤原因：那筆請求的 params 格式有誤、那筆特定輸入觸發內容過濾、特定模型的拒絕。逐項錯誤反映在 request_counts 的 errored 計數中。

批次級失敗

批次級失敗表示提交本身無法處理——最常見的原因是結構違規（超出 10 萬筆請求上限、超出 256 MB payload 上限、批次內重複的 custom_id 值、頂層 JSON 格式無效、提交時身份驗證失敗）。批次級失敗在提交時就被拒絕，永遠不會進入 in_progress 狀態。

過期的請求

在 24 小時 SLA 到期時仍在 processing 狀態的請求，會轉移至 expired。批次的 processing_status 變為 ended，過期的請求在結果串流中以錯誤形態出現。同一批次內的部分成功結果不受影響，仍可取回。

取消

批次可以在執行中取消。取消生效時已完成的請求會正常回傳；仍在處理中的請求被標記為 canceled，以錯誤形態回傳。取消在下游依賴項改變時很有用（例如目標 schema 有誤，需要用修正後的 params 重新提交）。

失敗批次項目的 Retry 策略 — 只重新提交失敗的 custom_id

部分成功語義讓 retry 策略得以保持乾淨：批次結束後，收集出錯的 custom_id 值，建立一個只包含那些值的新批次，然後重新提交。CCA-F 上關於 retry 設計的題目，一致選擇「只重新提交失敗的 custom_id」而非「重新提交整個批次」。

Retry 流程

1. 輪詢批次直到 processing_status == "ended"。
2. 迭代 JSONL 結果串流，為每筆錯誤結果收集（custom_id、error_type、original_params）三元組。
3. 過濾掉無論 retry 幾次都不會成功的永久性錯誤（schema 無效、內容過濾觸發）。
4. 建立新批次，其 requests 陣列只包含可 retry 的項目，沿用相同的 custom_id 值以確保下游 join 仍能對齊。
5. 提交 retry 批次，並分開追蹤其識別碼。

為什麼要沿用相同的 custom_id

若你沿用原始的 custom_id，系統記錄的 upsert 是冪等的：retry 結果會將錯誤行覆蓋為成功訊息行。若你為 retry 產生新的 custom_id，你就必須維護一份從 retry id 對應回原始 id 的額外映射表，這增加了失敗模式，卻毫無好處。沿用是標準做法。

區分暫時性錯誤與永久性錯誤

並非每個錯誤都值得 retry。暫時性錯誤（平台短暫故障、尖峰時段的暫時速率限制回應）可從 retry 中受益；永久性錯誤（請求 body 違反 schema、內容被安全過濾器拒絕、params 包含無效的模型名稱）則否。在 retry 前先檢查錯誤類別——盲目 retry 永久性錯誤會消耗配額，並延誤人工升級路徑。

Retry 是獨立的新批次，不是追加

不存在「追加到現有批次」的操作。批次結束後，你無法修改它。Retry 永遠是有新批次 ID 和自己 29 天保留期的新批次。

Throughput 優化 — 飽和批次限制以最大化 Throughput

當工作負載真的很龐大——每天數百萬筆——throughput 就成為主要的架構考量，CCA-F 期望考生了解飽和模式。

將批次打包至接近限制

一個有 10 筆請求的批次，與一個有 10 萬筆請求的批次，使用相同的排程開銷。將每個批次打包至接近結構限制（10 萬筆請求或 256 MB payload，以先達到者為準），以攤薄開銷。將 20 萬筆請求的工作負載拆成兩個 10 萬筆批次，比拆成二十個 1 萬筆批次更有效率。

並行執行多個批次

多個批次可以同時進行。一個夜間推送 50 萬筆項目的 pipeline，應同時提交五個 10 萬筆請求的批次，而非串列執行。每個批次有自己的完成 SLA；並行不影響任何個別批次的 SLA。

依模型分組以簡化排程

雖然支援異質批次（每筆請求混用不同模型），但依模型分組可簡化成本追蹤、下游消費和 retry 邏輯。在批次內混用模型的運維成本，通常高於因此節省的固定開銷。

批次前先過濾

Batch token 便宜，但不是免費的。在送進 Claude 之前，先用廉價的邏輯（正規表達式、小型分類器、規則型 triage）過濾輸入，避免送出明顯空白或明顯不符資格的記錄。成本曲線獎勵的是完全消除工作的那一步，而不是對工作打五折。

注意 256 MB 上限

非常大的提示（例如，一次批次包含 10 萬份完整文件內容）可能在達到 10 萬筆請求前就先碰到 256 MB。若每筆請求的 payload 平均為 3 KB，在達到位元組上限前，一個批次可容納 8 萬筆請求。若平均為 30 KB，上限在 8000 筆請求時就先觸發。批次大小以先觸及的那個限制來決定。

Batch 內的結構化輸出 — Tool Use 與 JSON Schema 強制

批次請求繼承同步 Messages API 的完整結構化輸出工具箱。在 CCA-F 上，結構化資料擷取情境幾乎都將 batch 與 strict tool use 結合使用。

用 Strict Tool Use 保證 Schema 符合性

每筆批次請求的 params 可以包含一個 tools 陣列，其中一個工具標記為 strict: true。搭配將 tool_choice 設為該工具，Claude 就被強制產生完全符合工具 JSON schema 的輸出。這是任何擷取工作負載的推薦做法，尤其是下游消費者依賴 schema 符合性的場合。

為什麼 Schema 強制在 Batch 中很重要

在一個 10 萬筆項目的批次中，哪怕僅有千分之幾的比率出現 schema 漂移，下游就是數千筆格式不正確的資料列。Strict tool use 將 schema 符合性從提示型的期望轉為結構性保證，消除了這類失敗。在 batch 擷取題中選擇「更強的提示指令」而非 strict tool use 的考生，會因為違反「程式化強制優先於提示引導」規則（社群痛點 pp-01）而被扣分。

持久化前的驗證

Strict tool use 保證形態正確；它不保證值在語意上有效。嚴格的 schema 接受 "2026-13-45" 作為日期字串，除非 regex 夠嚴格。下游驗證（日期解析、enum 成員資格、範圍檢查）仍屬於消費者路徑的責任，通常在持久化到系統記錄前執行。

白話說明

Batch processing 的概念，一旦錨定在考生已經熟悉的具體情境上，就會變得直觀。三個類比涵蓋了決策、機制與 retry 模式。

類比一：郵局寄件 — 便利商店超商取貨 vs 包裹集運

一通同步 Messages API 呼叫像是選擇超商取貨：你在網路下單一件商品，物流公司同天或隔天就送到指定超商，你去掃碼取件，速度快、全程可追蹤，但每件單獨處理，物流成本也最高。一次 batch 提交則像是國際集運服務：你把一萬件訂單打包在同一個倉庫地址，集運商將所有件合船寄出，每件商品貼著你自訂的訂單號（custom_id），到港後按訂單號拆分給你對帳。你不知道每件精確的到達時刻，但所有包裹都在承諾的時間窗口（24 小時）內到達，而且每件費用是一般物流的一半。若某件包裹資訊填錯（逐項錯誤），其餘件照常到達；只有那件退回並附上說明。若整批貨根本沒有出港（批次級失敗），才是什麼都沒有。用超商取貨寄一包在地的生日蛋糕很合理；用集運寄一萬份型錄也很合理；用集運寄生日蛋糕（晚到一天）或用超商取貨寄一萬份型錄（付一萬筆物流費），在架構上都是錯的。CCA-F 的 batch 與即時題，就是這個選擇。

類比二：洗衣店 — 到府取送 vs 自助投幣洗

同步 Messages API 像自助投幣洗衣店：你放進一桶衣服，等著看洗衣機轉，洗完當場折好帶走，九十分鐘搞定。Batch processing 像洗衣到府收送服務：你把一週的衣服裝進一個掛了名牌的袋子（每件衣服都有 owner tag——就是 custom_id），交給服務員，隔天再去取折好的衣物，費用是自助的一半，因為洗衣店把你的衣服和另外二十個客戶的一起排進高效的夜間排程。若有一件衣服在洗滌中沾了汙漬（逐項錯誤），你會拿回那件衣服加上說明單；其餘衣物照折好等你。若洗衣店機器全面故障、整批延誤超過承諾的取件時間（過期或取消語義），那才是批次層級的問題。你不會用到府收送來洗今晚要穿的衣服；你不會用自助洗衣機洗三個家庭一個月的衣服。把工作負載對應到正確原語，就是 CCA-F 的決策矩陣。

類比三：餐廳內用 vs 企業外燴 — 延遲容忍度的實際體現

餐廳內用服務就是同步 Messages API——每桌（每位使用者）點餐，期望在十五分鐘內上菜；廚房以低延遲優化，即便每份的單位成本較高。一場明天的企業尾牙外燴就是 batch API——外燴業者今天接下整份訂單，趁廚房閒置時在夜間備料，因為整批攤薄了備料和清場的成本而收取較低的每份費用，並在約定的明天早上準時出餐。十二號桌的客人不能被告知「您的燉飯在平台方便的時間內、24 小時以內上桌」——那是業務災難。外燴客戶也不能被告知「您的 200 份餐點每份依需求現場製作，按完成順序出餐，從各自備好的時間開始算」——那同樣是業務災難。每個原語對其需求形態都是正確的，用錯了就毀掉使用者體驗（互動式工作負載用 batch）或單位經濟（大量工作負載用即時）。這就是任務 4.5 整個架構論點的精髓。

考試當天選用哪個類比

• 關於提交-取回流程的題目 → 集運類比。
• 關於逐項錯誤處理與 retry的題目 → 洗衣店類比。
• 關於 batch 與即時選擇的題目 → 餐廳內用與外燴類比。

常見考試陷阱

CCA-F batch 題目一再利用五種陷阱模式。每一種都在社群通過報告中被記錄為「看起來對但選錯」的答案選項。

陷阱一：「24 小時 SLA 表示恰好 24 小時」

24 小時 SLA 是上限，不是目標時間。大多數批次在幾分鐘到幾小時內完成。把 24 小時這個數字視為預期完成時間、或依此設計下游 pipeline 等整整一天的答案，都是錯的。正確框架是「通常遠快於 24 小時；保證不慢於 24 小時」。

陷阱二：「custom_id 是系統自動產生的」

custom_id 永遠是呼叫者自定義的。API 不提供任何自動識別碼來將結果對應回應用程式記錄。描述從回應中提取系統產生的批次項目 ID、或完全省略 custom_id 改用陣列索引的答案，在架構上是壞掉的。永遠從你的應用程式主鍵衍生 custom_id。

陷阱三：「Batch API 支援串流」

Batch 不支援串流。每筆請求的回應整體回傳，沒有逐增 token，也沒有 server-sent events。若情境需要串流（聊天 UI、即時儀表板），同步 Messages API 是唯一正確答案。因為 50% 折扣而為需要串流的工作負載選了 batch 的考生，會被直接扣分。

陷阱四：「Batch API 支援多輪 Agentic Loop」

每筆批次請求都是單一 Messages API 呼叫。沒有任何機制可以在批次進行到一半時觀察 tool_use、執行工具，再回注 tool_result 讓 Claude 消費。需要 agentic loop 的工作負載（讀取檔案、決策、讀取另一個檔案）不適合 batch。batch 內的 tool use 僅限單輪，通常是透過 tool_choice 進行 strict-schema 擷取。

陷阱五：「為了省錢一律用 Batch」

50% 折扣很誘人，但不能凌駕延遲需求。描述互動式 agent、面向使用者的即時應用，或即時開發者回饋迴圈的情境，無論成本如何都需要同步 Messages API。因為比較便宜就預設用 batch，和「為求安全預設用即時」是同樣的反模式，會被同樣地扣分。

練習錨點

Batch processing 的概念在六個 CCA-F 情境中的兩個最集中出現。將以下內容視為任務 4.5 情境叢集題的架構骨幹。

結構化資料擷取情境

這是最直接考察 batch 設計的情境。一個團隊需要從大型文件語料庫中擷取結構化欄位——履歷、發票、合約、支援工單、研究論文、法規申報文件。預期會有題目測試：給定工作量/延遲組合時 batch 還是同步才是正確原語；如何將 batch 與 strict tool use 結合以強制 schema 符合性；如何設計 custom_id 使結果能乾淨地 join 回源語料庫；如何在不讓批次失敗的前提下處理逐項錯誤；如何只 retry 失敗的 custom_id 值；以及如何依照 10 萬筆請求和 256 MB 上限來調整批次大小。預期的答案形態幾乎總是「提交帶有 strict tool use 擷取的批次、輪詢完成狀態、以 custom_id 為鍵將 JSONL 結果串流讀入資料庫、在後續批次中 retry 失敗項目」。

Claude-Code-For-Continuous-Integration 情境

這個情境更隱微地考察 batch，在 CI/CD pipeline 的脈絡下，pipeline 以夜間排程對大量檔案、PR 或議題執行 Claude Code 分析。預期會有題目測試 batch 何時是 CI pipeline 內的正確原語（排程的夜間語料庫分析）vs 何時需要同步 Messages API（開發者正在等待的每次 commit PR 回饋）。題目也可能探詢 CI 中的 -p（非互動式）Claude Code 呼叫，與原始 Messages 工作負載的 Message Batches API 如何整合或有何差異。架構決策規則：若 CI 任務是事件驅動且有人在等，用同步；若 CI 任務是排程的大量處理，用 batch。

FAQ — Message Batches API 前五大問題

50% 批次折扣是什麼，何時適用？

Message Batches API 對同模型的 input、output 和 cached token，以同步 Messages API 費率的 50% 計費。折扣自動套用至透過 batch 端點提交的任何請求，涵蓋整個 Claude 家族（Haiku、Sonnet、Opus）。折扣不豁免結構限制（10 萬筆請求、256 MB）或 24 小時 SLA。在 CCA-F 上，50% 折扣是 batch 與即時題的經濟轉折點：當延遲允許且工作量高時，它是正確的架構選擇；但它永遠不是為互動式工作負載（使用者正在等待個別結果）選 batch 的理由。

24 小時 SLA 實際上是什麼意思？

24 小時 SLA 是 Anthropic 在正常條件下承諾完成所提交批次的最長時間。實際上，大多數批次在幾分鐘到幾小時內完成；24 小時是上限，不是目標。若批次在 24 小時最長處理期內未完成，它會轉移到 expired 終止狀態——批次內的部分結果仍可透過 custom_id 取回，但未處理的請求就此遺失，必須以新批次重新提交。需要個別結果快於 24 小時的應用程式應使用同步 Messages API；可以接受「隔夜」延遲的應用程式使用 batch。

如何將批次結果對應回我的應用程式記錄？

使用 custom_id 欄位。requests 陣列中的每筆請求都必須帶有唯一的、呼叫者自定義的 custom_id 字串，輸出 JSONL 串流中的每筆結果都帶有相同的字串標記。從穩定的應用程式主鍵衍生 custom_id（例如 ticket-{{id}} 或 resume-{{uuid}}），使系統記錄的下游 upsert 具有冪等性。Anthropic 絕不替你產生 custom_id——對應契約完全在呼叫者端。永遠不要用陣列索引或回應排序來對應；batch API 不保證順序保留。

批次內的個別請求失敗時會發生什麼？

Batch API 採用部分成功語義。逐項錯誤只影響那筆請求——其餘批次繼續處理，成功項目正常回傳。request_counts 區塊追蹤 succeeded、errored、canceled 和 expired 計數，結果串流中每筆失敗的 custom_id 帶有 error 區塊（而非 message 區塊）。正確的 retry 策略是：過濾結果串流中的錯誤、從 retry 中排除永久性錯誤（schema 違規、內容過濾拒絕），並提交只包含可 retry 的 custom_id 值的新批次——沿用原始 custom_id 字串以確保 upsert 的冪等性。

何時應選 batch 而非同步 Messages API，反之亦然？

工作負載是高工作量、非互動式、業務截止以小時或隔天計算時選 batch——跨文件語料庫的結構化擷取、夜間資料集標註、排程的 CI/CD 大量分析、多遍審查 pipeline。個別結果需要低延遲交付（幾秒以內）、有人主動等待、工作負載需要多輪 agentic loop，或需要串流輸出（聊天 UI、即時儀表板）時選同步 Messages API。CCA-F 決策規則：先讀延遲，再看工作量，最後衡量成本。不對應到工作負載形態就預設用 batch（因為比較便宜）或用同步（因為比較安全），是典型的反模式。

延伸閱讀

• Batch processing — Message Batches API: https://docs.anthropic.com/en/docs/build-with-claude/batch-processing
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Handle tool calls — tool_result format and error responses: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Integrate Claude Code into CI/CD pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd

Related ExamHub topics: 結構化輸出與 Tool Use 及 JSON Schema, 多實例與多遍審查架構, Claude Code CI/CD 整合, 擷取的驗證、Retry 與回饋迴圈.