博客 • AWS / Bedrock

Bedrock 上 Claude 結構化輸出已保證 JSON 形狀，批處理日誌和複製的聊天裏爲什麼還要本地三步校驗？

2026 年 10 月 19 日，AWS 宣佈 Amazon Bedrock 上的 Claude 模型支持結構化輸出：推理階段用 JSON Schema 做受限解碼（constrained decoding），請求裏通過 output_config 傳入 schema，工具調用可走 strict 模式，並強調 additionalProperties:false。批處理與流式響應同樣適用。

更完整的 Structured Output 路徑對比寫在2026 結構化輸出指南。schema 合法仍不等於權限足夠，寫在Agent schema 不夠一文。JSON Schema 在工具與最終回答裏怎麼共用，寫在爲什麼 AI 需要 JSON Schema。本篇只寫 Bedrock 落地之後，本地還要做的三步。

• Bedrock 請求在 output_config.format 裏掛 JSON Schema，並設 additionalProperties:false。
• API 層保證的是單次 Invoke 響應體形狀，不是日誌文件、批處理結果文件或從控制檯複製的片段。
• 本地流水線：(1) JSON Schema 校驗；(2) 去掉 markdown 圍欄後修復 JSON；(3) 批處理 JSONL 逐行檢查。
• 用同一份 TICKET_SCHEMA 校驗 API 樣本、日誌行和批處理行；enum 錯、缺字段、多字段都要能在本地攔住。

10 月 19 日 Bedrock 爲 Claude 加了什麼？

AWS 在 官方發佈公告：Claude 在 Bedrock 上可用結構化輸出，用受限解碼讓模型輸出符合 JSON Schema，並支持 strict 工具調用與批處理、流式。

技術細節與示例請求在 AWS Machine Learning 博客。不要把 API 保證當成日誌管道或合規歸檔的終點。

output_config 裏怎樣掛 JSON Schema？

Bedrock 請求在 output_config.format 使用 type json_schema，並把對象定義放在 schema 字段。根對象應設 additionalProperties:false，與 OpenAI Strict Schema 同類習慣一致。下面示例用同一份工單字段：ticket_id、priority（enum）、summary。

{
  "anthropic_version": "bedrock-2023-05-31",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Return one support ticket as JSON."
    }
  ],
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "additionalProperties": false,
        "required": ["ticket_id", "priority", "summary"],
        "properties": {
          "ticket_id": { "type": "string" },
          "priority": { "enum": ["low", "medium", "high"] },
          "summary": { "type": "string", "maxLength": 200 }
        }
      }
    }
  }
}

批處理作業把每行響應寫入對象存儲時，文件裏通常是 JSONL：一行一條記錄。流式響應在客戶端拼成字符串後，也可能被貼進工單或 Slack。那些副本不經過 Bedrock 的解碼器二次校驗。

API 已保證形狀，本地爲什麼還要校驗？

Invoke 響應體在 Bedrock 側已按 schema 生成，但你保存的 artifacts 會變形：日誌前綴、CloudWatch 轉義、從 Playground 複製的 ```json 圍欄、批處理裏混進的空行或截斷行。

{
  "ticket_id": "TCK-1042",
  "priority": "high",
  "summary": "Bedrock batch row passed constrained decoding"
}

一旦 priority 寫成 urgent 或多了 owner 字段，下游入庫、告警路由或 SLA 規則就會誤判。SAMPLE_BAD 展示 enum 越界——這類錯誤要在業務層用同一份 TICKET_SCHEMA 攔住。

{
  "ticket_id": "TCK-1042",
  "priority": "urgent",
  "summary": "enum value not in schema"
}

本地校驗用哪份 TICKET_SCHEMA？

用 JSON Schema 固定字段與 enum。priority 只能是 low、medium、high；additionalProperties:false 拒絕未聲明字段。通過只說明形狀合法，不證明這條記錄來自可信日誌。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "additionalProperties": false,
  "required": ["ticket_id", "priority", "summary"],
  "properties": {
    "ticket_id": {
      "type": "string",
      "description": "Support ticket ID, e.g. TCK-1042"
    },
    "priority": {
      "enum": ["low", "medium", "high"]
    },
    "summary": {
      "type": "string",
      "maxLength": 200
    }
  }
}

本地三步流水線分別解決什麼？

把 Bedrock 當成「線上解碼器」，把 JSONNote 當成「離線質檢臺」。三步順序不要顛倒：先確認是合法 JSON 且符合 schema，再處理圍欄和語法，最後纔在 JSONL 文件裏逐行驗收。

在 JSONNote 裏怎樣跑這三步？

1. 1
   第一步：Schema 校驗

   打開 JSON Schema。第一欄貼 TICKET_SCHEMA，第二欄貼 SAMPLE_OK 或日誌裏截出的 JSON。enum 錯、缺字段、多字段應立刻標紅。

2. 2
   第二步：圍欄修復

   打開 JSON 修復。把帶 ```json 圍欄的聊天覆制貼入，去掉圍欄後再做 Schema 校驗。

3. 3
   第三步：JSONL 行檢查

   打開 JSONL 工具。上傳 Bedrock 批處理結果，確認每一行都能 parse；壞行用 TICKET_SCHEMA 定位是 enum 還是截斷。

常見問題

開了 Bedrock 結構化輸出，還能跳過本地校驗嗎？

不能。API 只保證當次 Invoke 的響應體。日誌、批處理文件、複製的聊天和中間緩存都要在業務層用同一份 schema 再驗一遍。

strict 工具調用和 output_config 的 schema 是什麼關係？

它們都依賴 JSON Schema 約束 token，但作用點不同：工具參數走 tool schema，最終文本走 output_config。本地校驗時應分別保存兩份 schema，不要混在一個日誌字段裏。

批處理 JSONL 裏一行失敗，要整批重跑嗎？

不必。用 JSONL 工具定位行號，用 TICKET_SCHEMA 看是 enum、截斷還是語法壞。只重試失敗行或回源 Invoke，比整批重跑便宜。

additionalProperties:false 要在本地 schema 裏也寫嗎？

要。Bedrock 請求裏的 schema 與本地 TICKET_SCHEMA 應一致，否則 API 通過但入庫規則仍可能拒絕，或反之。

流式響應也要做 JSONL 檢查嗎？

單條流式拼接後用 Schema 校驗和 Repair 即可。JSONL 檢查只在批處理落盤爲多行文件時使用。

總結

Bedrock 結構化輸出把 Claude 的 API 響應鎖進 JSON Schema；批處理、流式拼接、日誌與複製粘貼仍會把形狀弄壞。

直接結論：線上靠 Bedrock output_config；離線用同一份 TICKET_SCHEMA 做校驗，用 Repair 去圍欄，用 JSONL 驗批處理行。

返回博客