AWS 表示，Amazon Bedrock 面向 Anthropic Claude 模型的结构化输出已在 bedrock-runtime 和 bedrock-mantle 两个端点正式可用。这一范围涵盖所有 Claude 模型，但以相应模型本身的可用范围为前提。开发者可以使用 JSON Schema 定义响应结构，让生成过程遵守其中受支持的规则。

这项功能的核心是把结构要求直接用于令牌生成。对于需要固定字段、明确字段类型和必填项目的任务，AWS 提供的是在生成过程中约束输出的机制。理解其适用范围时，也需要同时考虑模式支持的边界，以及可能导致响应不符合模式的例外。

在生成过程中约束 JSON 结构

结构化输出采用受约束解码，在生成令牌时执行模式要求，包括字段类型、必填字段以及允许出现的字段。按照 AWS 的说明，这可以减少开发者自行编写解析逻辑的需求，也能减少因输出违反模式而发起的重试。文章还描述了输出令牌数量减少这一效果。

AWS 认为，对于高请求量工作负载，这些变化可能降低推理成本。不过，所提供的文章并未确立独立测得的成本节省。因此，对成本的表述应理解为该公司描述的潜在收益，不能据此给出确定的节省比例或独立性能结论。

文章列出的应用包括从财务报告、合规文件、临床笔记、发票、合同、电子邮件和文字记录中提取数据。其他场景包括丰富商品目录、验证智能体调用工具时的参数，以及对工单、销售线索和内容进行分类或路由。AWS 还将 Claude Haiku 5.5 描述为可处理摘要、上下文压缩、数据库查询和分类请求。

两类端点与工具参数控制

开发者可以通过 Boto3 和 bedrock-runtime API 使用该功能，也可以通过 Messages API 和 bedrock-mantle 使用。结构化输出支持批量推理，并支持以带类型事件形式提供流式响应。文章明确列出的跨区域推理支持位于 bedrock-runtime，不能将这一说明直接扩展为两个端点均支持。

使用 InvokeModel 时，请求采用 Anthropic 原生请求体。模式应作为 JSON 对象放入 output_config.format，而不是先转换为 JSON 字符串再传入。文章另附示例 notebook，提供更多 API 用法，其中也包括 Messages API 的示例。

在 bedrock-mantle 上，设置 strict: true 可以让工具输入受到指定模式约束，范围包括字段类型、允许的值以及允许出现的字段。这里的约束对象是工具输入，因此文章除了讨论最终响应的结构，也讨论了智能体调用工具时的参数验证。

AWS 将 Mantle 描述为支持智能体应用的端点，相关能力包括服务端工具、后台推理和保留状态的对话。文章举出的服务端工具是网页搜索和代码解释器。这些内容构成了其工具使用场景的背景，而严格模式用于约束提交给工具的输入结构。

首次编译与模式缓存

Amazon Bedrock 会按照其支持的 JSON Schema Draft 2020-12 子集检查模式，并把新模式编译为语法产物。这个编译步骤可能增加首次请求的延迟。因而，首次使用新模式时的等待时间，需要结合文章描述的编译过程来理解。

编译后的语法会在账户内缓存，从首次访问起保留二十四小时。模式结构发生变化时，会触发重新编译；如果仅修改名称或描述字段，则保留已经缓存的语法。这一区别也是 AWS 建议重复使用模式时提供的具体背景。

为了让模式被接受，所有对象都必须设置 additionalProperties: false。AWS 建议为属性采用含义清楚的名称，并提供描述；对于只有有限个合法取值的字段，则建议使用 enum。这些建议同时涉及模式是否能被接受，以及如何清楚表达字段要求。

哪些模式规则受到支持

文章列出的支持类型包括 object、array、string、integer、number、boolean 和 null。枚举值可以是字符串、数字、布尔值或 null。清单还包括 const，以及存在使用限制的 anyOf 和 allOf，因此不能把这些名称的出现理解为所有相关用法都不受限制。

内部引用方面，文章列出 $ref、$def 和 definitions。数组规则中，列出的 minItems 支持值为零或一。上述内容描述的是 Bedrock 支持的模式子集，而不是对完整 JSON Schema 所有规则的支持承诺。

受支持的字符串格式列为 date-time、time、date、duration、email、hostname、uri、ipv4、ipv6 和 uuid。开发者设计模式时，需要依据文章给出的支持清单理解可用范围，并区分类型、格式及其他约束各自的支持情况。

API 接受的规则不一定会在生成时执行

模式能够提交给 API，并不代表其中每一项限制都会在生成过程中被强制执行。 AWS 明确列出一些会被 API 接受、但不会在生成时执行的内容。对于这些规则，文章要求由应用自行验证，结构化输出不能替代这部分检查。

具体来说，这一清单包括外部 $ref 引用，以及数值约束 minimum、maximum 和 multipleOf。字符串约束 minLength 与 maxLength 也属于同一类。应用如果依赖这些数值或长度限制，就仍需在自身逻辑中完成相应验证。

这种区分直接影响开发者如何理解“符合模式”。文章描述的生成约束确实覆盖受支持的字段类型、必填字段和允许字段，但同时明确保留了上述未执行规则的应用侧验证责任。两部分要求需要结合阅读，才能准确理解功能边界。

从简单模式开始，并检查每次响应

AWS 建议先使用满足需求的最少必填字段，再逐步增加模式复杂度，并重复使用模式。文章指出，基础模式编译得更快。它还提醒，模式本身会计入 Converse API 的请求负载大小，因此模式设计与请求大小之间也存在文章明确说明的联系。

测试方面，AWS 建议采用能够代表生产环境的输入。这项建议与逐步增加复杂度相配合：从必要字段开始，随后根据实际输入测试模式，再增加所需结构。文章没有提供可以替代这些测试的独立基准结果，也没有给出适用于所有任务的固定模式复杂度。

响应处理还存在两类明确例外。模型因安全原因拒绝请求，或者在完成之前达到 max_tokens，都可能产生不符合模式的响应。因此，结构化输出不能被理解为无论停止原因如何，响应都必定满足指定结构。

AWS 要求开发者检查每一次响应的停止原因，并分别处理安全拒绝和达到令牌上限这两种情况。结合前述约束清单，应用仍需完成两项工作：处理可能不符合模式的异常响应，以及验证生成过程中不会强制执行的规则。

这些边界与 AWS 描述的解析、重试和令牌收益共同构成功能说明。对于文档提取、分类路由或工具参数验证等场景，开发者可以按照受支持的模式组织输出，同时保留文章要求的停止原因检查和应用侧验证。

来源：AWS 关于 Amazon Bedrock 上 Claude 结构化输出的技术文章。以上可用性、机制及潜在收益均依据这一来源的说明。