博客 • 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 验批处理行。

返回博客