Loading...
    • 開發者指南
    • API 參考
    • MCP
    • 資源
    • 發行說明
    Search...
    ⌘K
    開始使用
    Claude 簡介快速開始
    模型與定價
    模型概覽選擇模型Claude 4.5 新功能遷移至 Claude 4.5模型棄用定價
    使用 Claude 構建
    功能概覽使用 Messages API上下文窗口提示詞最佳實踐
    功能
    提示詞快取上下文編輯擴展思考努力串流消息批次處理引用多語言支援Token 計數嵌入視覺PDF 支援Files API搜尋結果結構化輸出
    工具
    概覽如何實現工具使用細粒度工具串流Bash 工具代碼執行工具程式化工具調用計算機使用工具文字編輯器工具網頁擷取工具網頁搜尋工具記憶體工具工具搜尋工具
    Agent Skills
    概覽快速開始最佳實踐使用 API 的 Skills
    Agent SDK
    概覽快速開始TypeScript SDKTypeScript V2 (預覽)Python SDK遷移指南
    API 中的 MCP
    MCP 連接器遠端 MCP 伺服器
    第三方平台上的 Claude
    Amazon BedrockMicrosoft FoundryVertex AI
    提示詞工程
    概覽提示詞生成器使用提示詞範本提示詞改進器清晰直接使用範例 (多次提示)讓 Claude 思考 (CoT)使用 XML 標籤給 Claude 一個角色 (系統提示詞)預填 Claude 的回應鏈接複雜提示詞長上下文提示擴展思考提示
    測試與評估
    定義成功標準開發測試案例使用評估工具降低延遲
    加強防護欄
    減少幻覺增加輸出一致性緩解越獄串流拒絕減少提示詞洩露保持 Claude 的角色
    管理和監控
    Admin API 概覽使用量和成本 APIClaude Code Analytics API
    Console
    Log in
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...

    Solutions

    • AI agents
    • Code modernization
    • Coding
    • Customer support
    • Education
    • Financial services
    • Government
    • Life sciences

    Partners

    • Amazon Bedrock
    • Google Cloud's Vertex AI

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Company

    • Anthropic
    • Careers
    • Economic Futures
    • Research
    • News
    • Responsible Scaling Policy
    • Security and compliance
    • Transparency

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Help and security

    • Availability
    • Status
    • Support
    • Discord

    Terms and policies

    • Privacy policy
    • Responsible disclosure policy
    • Terms of service: Commercial
    • Terms of service: Consumer
    • Usage policy
    功能

    批次處理

    使用 Message Batches API 高效處理大量請求的非同步批次處理

    批次處理是一種強大的方法,可以有效地處理大量請求。與其一次處理一個請求並立即獲得回應,批次處理允許您將多個請求一起提交進行非同步處理。這種模式特別適用於以下情況:

    • 您需要處理大量數據
    • 不需要立即回應
    • 您想優化成本效率
    • 您正在運行大規模評估或分析

    Message Batches API 是我們對這種模式的首次實現。


    Message Batches API

    Message Batches API 是一種強大且具有成本效益的方式,可以非同步處理大量 Messages 請求。這種方法非常適合不需要立即回應的任務,大多數批次在 1 小時內完成,同時將成本降低 50% 並提高吞吐量。

    您可以 直接探索 API 參考,以及閱讀本指南。

    Message Batches API 的工作原理

    當您向 Message Batches API 發送請求時:

    1. 系統使用提供的 Messages 請求建立新的 Message Batch。
    2. 批次隨後被非同步處理,每個請求獨立處理。
    3. 您可以輪詢批次的狀態,並在所有請求處理完成後檢索結果。

    這對於不需要立即結果的批量操作特別有用,例如:

    • 大規模評估:有效地處理數千個測試案例。
    • 內容審核:非同步分析大量使用者生成的內容。
    • 數據分析:為大型數據集生成見解或摘要。
    • 批量內容生成:為各種目的創建大量文本(例如產品描述、文章摘要)。

    批次限制

    • Message Batch 限制為 100,000 個 Message 請求或 256 MB 大小,以先達到的為準。
    • 我們盡快處理每個批次,大多數批次在 1 小時內完成。當所有消息完成或 24 小時後(以先發生者為準),您將能夠訪問批次結果。如果處理未在 24 小時內完成,批次將過期。
    • 批次結果在建立後 29 天內可用。之後,您仍然可以查看批次,但其結果將不再可供下載。
    • 批次的範圍限於 Workspace。您可以查看在您的 API 金鑰所屬的 Workspace 中建立的所有批次及其結果。
    • 速率限制適用於 Batches API HTTP 請求和批次內等待處理的請求數。請參閱 Message Batches API 速率限制。此外,我們可能會根據當前需求和您的請求量減慢處理速度。在這種情況下,您可能會看到更多請求在 24 小時後過期。
    • 由於高吞吐量和並發處理,批次可能會略微超過您的 Workspace 配置的 支出限制。

    支援的模型

    所有 活躍模型 都支援 Message Batches API。

    可以批次處理的內容

    任何您可以向 Messages API 發出的請求都可以包含在批次中。這包括:

    • 視覺
    • 工具使用
    • 系統消息
    • 多輪對話
    • 任何測試版功能

    由於批次中的每個請求都是獨立處理的,您可以在單個批次中混合不同類型的請求。

    由於批次可能需要超過 5 分鐘才能處理,請考慮在批次處理時使用 1 小時快取持續時間 與提示快取,以便在處理具有共享上下文的批次時獲得更好的快取命中率。


    定價

    Batches API 提供顯著的成本節省。所有使用費用按標準 API 價格的 50% 計費。

    ModelBatch inputBatch output
    Claude Opus 4.5$2.50 / MTok$12.50 / MTok
    Claude Opus 4.1$7.50 / MTok$37.50 / MTok
    Claude Opus 4$7.50 / MTok$37.50 / MTok
    Claude Sonnet 4.5$1.50 / MTok$7.50 / MTok
    Claude Sonnet 4$1.50 / MTok$7.50 / MTok
    Claude Sonnet 3.7 (deprecated)$1.50 / MTok$7.50 / MTok
    Claude Haiku 4.5$0.50 / MTok$2.50 / MTok
    Claude Haiku 3.5$0.40 / MTok$2 / MTok
    Claude Opus 3 (deprecated)$7.50 / MTok$37.50 / MTok
    Claude Haiku 3$0.125 / MTok$0.625 / MTok

    如何使用 Message Batches API

    準備並建立您的批次

    Message Batch 由建立 Message 的請求列表組成。單個請求的形狀包括:

    • 用於識別 Messages 請求的唯一 custom_id
    • 包含標準 Messages API 參數的 params 物件

    您可以通過將此列表傳遞到 requests 參數來 建立批次:

    curl https://api.anthropic.com/v1/messages/batches \
         --header "x-api-key: $ANTHROPIC_API_KEY" \
         --header "anthropic-version: 2023-06-01" \
         --header "content-type: application/json" \
         --data \
    '{
        "requests": [
            {
                "custom_id": "my-first-request",
                "params": {
                    "model": "claude-sonnet-4-5",
                    "max_tokens": 1024,
                    "messages": [
                        {"role": "user", "content": "Hello, world"}
                    ]
                }
            },
            {
                "custom_id": "my-second-request",
                "params": {
                    "model": "claude-sonnet-4-5",
                    "max_tokens": 1024,
                    "messages": [
                        {"role": "user", "content": "Hi again, friend"}
                    ]
                }
            }
        ]
    }'

    在此範例中,兩個單獨的請求被批次處理在一起進行非同步處理。每個請求都有唯一的 custom_id 並包含您用於 Messages API 呼叫的標準參數。

    使用 Messages API 測試您的批次請求

    對每個消息請求的 params 物件的驗證是非同步執行的,驗證錯誤在整個批次處理結束時返回。您可以通過首先使用 Messages API 驗證您的請求形狀來確保您正確構建輸入。

    首次建立批次時,回應將具有 in_progress 的處理狀態。

    JSON
    {
      "id": "msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d",
      "type": "message_batch",
      "processing_status": "in_progress",
      "request_counts": {
        "processing": 2,
        "succeeded": 0,
        "errored": 0,
        "canceled": 0,
        "expired": 0
      },
      "ended_at": null,
      "created_at": "2024-09-24T18:37:24.100435Z",
      "expires_at": "2024-09-25T18:37:24.100435Z",
      "cancel_initiated_at": null,
      "results_url": null
    }

    追蹤您的批次

    Message Batch 的 processing_status 欄位指示批次處理所處的階段。它開始為 in_progress,然後在批次中的所有請求完成處理且結果準備就緒後更新為 ended。您可以通過訪問 Console 或使用 檢索端點 來監控批次的狀態。

    輪詢 Message Batch 完成

    要輪詢 Message Batch,您需要其 id,該 ID 在建立批次時的回應中提供,或通過列出批次獲得。您可以實現一個輪詢迴圈,定期檢查批次狀態,直到處理結束:

    import anthropic
    import time
    
    client = anthropic.Anthropic()
    
    message_batch = None
    while True:
        message_batch = client.messages.batches.retrieve(
            MESSAGE_BATCH_ID
        )
        if message_batch.processing_status == "ended":
            break
    
        print(f"Batch {MESSAGE_BATCH_ID} is still processing...")
        time.sleep(60)
    print(message_batch)

    列出所有 Message Batches

    您可以使用 列表端點 列出 Workspace 中的所有 Message Batches。API 支援分頁,根據需要自動獲取其他頁面:

    import anthropic
    
    client = anthropic.Anthropic()
    
    # Automatically fetches more pages as needed.
    for message_batch in client.messages.batches.list(
        limit=20
    ):
        print(message_batch)

    檢索批次結果

    批次處理結束後,批次中的每個 Messages 請求都將有一個結果。有 4 種結果類型:

    結果類型描述
    succeeded請求成功。包括消息結果。
    errored請求遇到錯誤,未建立消息。可能的錯誤包括無效請求和內部伺服器錯誤。您不會為這些請求計費。
    canceled使用者在此請求可以發送到模型之前取消了批次。您不會為這些請求計費。
    expired批次在此請求可以發送到模型之前達到其 24 小時過期時間。您不會為這些請求計費。

    您將看到批次 request_counts 的概述,其中顯示有多少請求達到了這四種狀態中的每一種。

    批次的結果可在 Message Batch 上的 results_url 屬性處下載,如果組織權限允許,也可在 Console 中下載。由於結果的潛在大小,建議 流式傳輸結果 而不是一次性下載所有結果。

    #!/bin/sh
    curl "https://api.anthropic.com/v1/messages/batches/msgbatch_01HkcTjaV5uDC8jWR4ZsDV8d" \
      --header "anthropic-version: 2023-06-01" \
      --header "x-api-key: $ANTHROPIC_API_KEY" \
      | grep -o '"results_url":[[:space:]]*"[^"]*"' \
      | cut -d'"' -f4 \
      | while read -r url; do
        curl -s "$url" \
          --header "anthropic-version: 2023-06-01" \
          --header "x-api-key: $ANTHROPIC_API_KEY" \
          | sed 's/}{/}\n{/g' \
          | while IFS= read -r line
        do
          result_type=$(echo "$line" | sed -n 's/.*"result":[[:space:]]*{[[:space:]]*"type":[[:space:]]*"\([^"]*\)".*/\1/p')
          custom_id=$(echo "$line" | sed -n 's/.*"custom_id":[[:space:]]*"\([^"]*\)".*/\1/p')
          error_type=$(echo "$line" | sed -n 's/.*"error":[[:space:]]*{[[:space:]]*"type":[[:space:]]*"\([^"]*\)".*/\1/p')
    
          case "$result_type" in
            "succeeded")
              echo "Success! $custom_id"
              ;;
            "errored")
              if [ "$error_type" = "invalid_request" ]; then
                # Request body must be fixed before re-sending request
                echo "Validation error: $custom_id"
              else
                # Request can be retried directly
                echo "Server error: $custom_id"
              fi
              ;;
            "expired")
              echo "Expired: $line"
              ;;
          esac
        done
      done
    

    結果將採用 .jsonl 格式,其中每一行都是代表 Message Batch 中單個請求結果的有效 JSON 物件。對於每個流式傳輸的結果,您可以根據其 custom_id 和結果類型執行不同的操作。以下是一組範例結果:

    .jsonl file
    {"custom_id":"my-second-request","result":{"type":"succeeded","message":{"id":"msg_014VwiXbi91y3JMjcpyGBHX5","type":"message","role":"assistant","model":"claude-sonnet-4-5-20250929","content":[{"type":"text","text":"Hello again! It's nice to see you. How can I assist you today? Is there anything specific you'd like to chat about or any questions you have?"}],"stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":11,"output_tokens":36}}}}
    {"custom_id":"my-first-request","result":{"type":"succeeded","message":{"id":"msg_01FqfsLoHwgeFbguDgpz48m7","type":"message","role":"assistant","model":"claude-sonnet-4-5-20250929","content":[{"type":"text","text":"Hello! How can I assist you today? Feel free to ask me any questions or let me know if there's anything you'd like to chat about."}],"stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":10,"output_tokens":34}}}}

    如果您的結果有錯誤,其 result.error 將設置為我們的標準 錯誤形狀。

    批次結果可能與輸入順序不匹配

    批次結果可以按任何順序返回,可能與建立批次時請求的順序不匹配。在上面的範例中,第二個批次請求的結果在第一個之前返回。要正確匹配結果與其對應的請求,請始終使用 custom_id 欄位。

    取消 Message Batch

    您可以使用 取消端點 取消當前正在處理的 Message Batch。取消後立即,批次的 processing_status 將為 canceling。您可以使用上述相同的輪詢技術等待取消完成。已取消的批次最終狀態為 ended,可能包含取消前處理的請求的部分結果。

    import anthropic
    
    client = anthropic.Anthropic()
    
    message_batch = client.messages.batches.cancel(
        MESSAGE_BATCH_ID,
    )
    print(message_batch)

    回應將顯示處於 canceling 狀態的批次:

    JSON
    {
      "id": "msgbatch_013Zva2CMHLNnXjNJJKqJ2EF",
      "type": "message_batch",
      "processing_status": "canceling",
      "request_counts": {
        "processing": 2,
        "succeeded": 0,
        "errored": 0,
        "canceled": 0,
        "expired": 0
      },
      "ended_at": null,
      "created_at": "2024-09-24T18:37:24.100435Z",
      "expires_at": "2024-09-25T18:37:24.100435Z",
      "cancel_initiated_at": "2024-09-24T18:39:03.114875Z",
      "results_url": null
    }

    在 Message Batches 中使用提示詞快取

    Message Batches API 支援提示詞快取,允許您可能降低批次請求的成本和處理時間。提示詞快取和 Message Batches 的定價折扣可以疊加,當同時使用這兩項功能時可提供更大的成本節省。但是,由於批次請求是非同步且並行處理的,快取命中是以盡力而為的基礎提供的。使用者通常會根據其流量模式體驗 30% 到 98% 的快取命中率。

    為了最大化批次請求中快取命中的可能性:

    1. 在批次中的每個 Message 請求中包含相同的 cache_control 區塊
    2. 維持穩定的請求流,以防止快取項目在其 5 分鐘的生命週期後過期
    3. 結構化您的請求以共享盡可能多的快取內容

    在批次中實現提示詞快取的範例:

    curl https://api.anthropic.com/v1/messages/batches \
         --header "x-api-key: $ANTHROPIC_API_KEY" \
         --header "anthropic-version: 2023-06-01" \
         --header "content-type: application/json" \
         --data \
    '{
        "requests": [
            {
                "custom_id": "my-first-request",
                "params": {
                    "model": "claude-sonnet-4-5",
                    "max_tokens": 1024,
                    "system": [
                        {
                            "type": "text",
                            "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n"
                        },
                        {
                            "type": "text",
                            "text": "<the entire contents of Pride and Prejudice>",
                            "cache_control": {"type": "ephemeral"}
                        }
                    ],
                    "messages": [
                        {"role": "user", "content": "Analyze the major themes in Pride and Prejudice."}
                    ]
                }
            },
            {
                "custom_id": "my-second-request",
                "params": {
                    "model": "claude-sonnet-4-5",
                    "max_tokens": 1024,
                    "system": [
                        {
                            "type": "text",
                            "text": "You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.\n"
                        },
                        {
                            "type": "text",
                            "text": "<the entire contents of Pride and Prejudice>",
                            "cache_control": {"type": "ephemeral"}
                        }
                    ],
                    "messages": [
                        {"role": "user", "content": "Write a summary of Pride and Prejudice."}
                    ]
                }
            }
        ]
    }'

    在此範例中,批次中的兩個請求都包含相同的系統訊息和標記有 cache_control 的完整 Pride and Prejudice 文本,以增加快取命中的可能性。

    有效批次處理的最佳實踐

    為了充分利用 Batches API:

    • 定期監控批次處理狀態,並為失敗的請求實現適當的重試邏輯。
    • 使用有意義的 custom_id 值來輕鬆匹配結果與請求,因為順序不保證。
    • 考慮將非常大的資料集分解為多個批次,以便更好地管理。
    • 使用 Messages API 進行單個請求形狀的試運行,以避免驗證錯誤。

    常見問題的故障排除

    如果遇到意外行為:

    • 驗證總批次請求大小不超過 256 MB。如果請求大小過大,您可能會收到 413 request_too_large 錯誤。
    • 檢查您是否在批次中的所有請求中使用支援的模型。
    • 確保批次中的每個請求都有唯一的 custom_id。
    • 確保自批次 created_at(不是處理 ended_at)時間以來已不超過 29 天。如果已超過 29 天,結果將不再可檢視。
    • 確認批次尚未被取消。

    請注意,批次中一個請求的失敗不會影響其他請求的處理。


    批次儲存和隱私

    • 工作區隔離:批次在建立它們的工作區內隔離。它們只能由與該工作區相關聯的 API 金鑰或有權限在主控台中檢視工作區批次的使用者存取。

    • 結果可用性:批次結果在建立批次後可用 29 天,允許充足的時間進行檢索和處理。


    常見問題

    • Message Batches API 的工作原理
    • 如何使用 Message Batches API
    • 列出所有 Message Batches
    • 取消 Message Batch
    • 在 Message Batches 中使用提示詞快取