Amazon Bedrock 为 Anthropic Claude 模型提供结构化输出

Amazon Bedrock now supports structured outputs for all Anthropic Claude models, on both the bedrock-runtime and bedrock-mantle endpoints, where the model is available.

Whether you call Claude through Boto3 and the bedrock-runtime APIs or through the Messages API and the bedrock-mantle endpoint, you can now receive schema-compliant JSON responses that conform to a defined structure. You no longer need custom parsing, retry logic, or post-processing.

Practical applications

With structured outputs for Claude on Amazon Bedrock, you can automate reliable, schema-compliant tasks across industries. Examples include extracting every required field from financial earnings reports and compliance documents, parsing clinical notes into Electronic Health Records (EHR), and enriching product catalogs with consistent, validated results. You can also analyze contracts for key terms, parties, and obligations, or power intelligent support ticket routing where intents, sentiments, and entities always match your application’s data model.

What changes with structured outputs on Amazon Bedrock

Structured outputs use constrained decoding to enforce your JSON schema during token generation, not after the fact. The model doesn’t produce tokens that would violate your schema. This changes output formatting from probabilistic to deterministic.

Two complementary mechanisms are now available on both Amazon Bedrock endpoints:

What this means for you

Each response is a valid JSON, so you no longer encounter JSON.parse() errors or parsing exceptions. Responses are also type safe: field types are enforced, and required fields are always present. Because outputs always conform to your schema, you don’t need retries to handle schema violations, making your integration more reliable. Structured outputs also constrains responses to only the fields your schema defines, which reduces output token count and can lower inference costs for high-volume workloads. These properties make structured outputs production ready, so you can deploy at scale without additional schema-validation code.

Supported models and availability

Structured outputs works with batch inference, so you can process large volumes of requests asynchronously while still receiving schema-compliant outputs. On the bedrock-runtime endpoint, it also works with cross-Region inference, so you can use it across AWS Regions without additional setup. If you need responses in real time, you can stream structured responses as typed events.

How it works

When you make a request with a JSON schema, here’s what happens behind the scenes:

1. Schema validation – Amazon Bedrock validates your JSON schema against the supported JSON Schema Draft 2020-12 subset.
2. Grammar compilation – For new schemas, Amazon Bedrock compiles a grammar artifact (the first request might take slightly longer).
3. Caching – Compiled grammars are cached for 24 hours, making subsequent requests faster.
4. Constrained generation – The model generates tokens that produce valid JSON matching your schema.

Performance considerations

For performance, the first request with a new schema might take longer because Amazon Bedrock compiles a grammar artifact before generation begins. After that initial compilation, subsequent requests using the same schema run with minimal overhead because the compiled grammar is cached. This cache is scoped to your account and lasts for 24 hours from first access. Changing the structure of your JSON schema invalidates the cache and triggers a fresh compilation, while changing only the name or description fields leaves the cached grammar intact.

Getting started: Structured outputs with the InvokeModel API (bedrock-runtime)

The InvokeModel API takes the Anthropic-native request body, so the schema goes in output_config.format as a JSON object rather than a JSON string. The following example shows how to extract the structured lead data from a customer email using boto3 with an Anthropic Claude model:

Python

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Define the JSON schema for structured output
schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "description": "Customer name"},
        "email": {"type": "string", "description": "Customer email address"},
        "plan_interest": {"type": "string", "description": "Product plan of interest"},
        "demo_requested": {"type": "boolean", "description": "Whether a demo was requested"}
    },
    "required": ["name", "email", "plan_interest", "demo_requested"],
    "additionalProperties": False
}

# Make a request with structured outputs via the InvokeModel API
# (reusing the schema defined for the Converse example)
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-sonnet-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "messages": [
            {"role": "user", "content": (
                "Paulo Santos (paulo@example.com) is interested in our Enterprise plan "
                "and wants to schedule a demo for next Tuesday at 2pm."
            )}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    print(json.dumps(json.loads(result_text), indent=2))
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

JSON

{
    "name": "Paulo Santos",
    "email": "paulo@example.com",
    "plan_interest": "Enterprise",
    "demo_requested": true
}

The response conforms to your schema. No additional validation is required.

For additional API usage examples, including the Messages API, see the accompanying sample notebook.

Strict tool use for agentic workflows

Amazon Bedrock Mantle is designed for agentic applications with server-side tools, background inference, and stateful conversations. With strict tool use on the bedrock-mantle endpoint, you can now guarantee that tool parameters match your input schema exactly. The following example shows how to define a tool with strict schema enforcement:

Import json
from anthropic import AnthropicBedrockMantle

# Reusing the client created in the Messages API example
client = AnthropicBedrockMantle(aws_region="us-east-1")

message = client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "What's the weather like in San Francisco?"}],
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a specified location",
            "strict": True,
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {
                        "type": "string",
                        "description": "The city and state, e.g., San Francisco, CA"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"],
                        "description": "Temperature unit"
                    }
                },
                "required": ["location", "unit"],
                "additionalProperties": False
            }
        }
    ]
)

#Tool inputs conform to the schema
for block in message.content:
    if block.type == "tool_use":
        print(f"Tool: {block.name}")
        print(f"Input: {json.dumps(block.input, indent=2)}")

Setting strict: true constrains the model’s tool input to match your schema exactly. The location field is always a string, and the unit field is always either celsius or fahrenheit. The model can’t add fields outside your schema, so the tool input contains only what your schema specifies.

This is especially valuable for agentic use cases on Amazon Bedrock Mantle, where models orchestrate multi-step workflows with server-side tools like web search and code interpreter.

Top use cases for Claude structured outputs

Structured outputs reduce error-handling complexity the most in three common patterns:

• Data extraction: Extract fields from invoices, contracts, email, and transcripts into JSON that always matches your schema, ready to load into databases or customer relationship management (CRM) systems.
• Reliable agent tool calls: Validate tool arguments against their schemas at generation time, so multi-step agent workflows run without failures from malformed input.
• Classification at scale: Classify tickets, leads, or content by intent, priority, and sentiment for routing, moderation, and evaluation.

Claude Haiku 5.5 reliably handles quick and repetitive workloads such as summaries, compactions, database queries, and classification requests. The following example shows how to classify and route incoming data using the Invoke API and Haiku 5.5:

import boto3
import json

REGION = "us-east-1" # Choose your preferred region
bedrock_runtime = boto3.client(service_name="bedrock-runtime", region_name=REGION)

# Classification schema: enums restrict output to a fixed set of labels
schema = {
    "type": "object",
    "properties": {
        "category": {
            "type": "string",
            "enum": ["billing", "technical", "account", "sales", "other"],
            "description": "Primary ticket category"
        },
        "priority": {
            "type": "string",
            "enum": ["low", "medium", "high", "urgent"],
            "description": "Urgency based on business impact"
        },
        "sentiment": {
            "type": "string",
            "enum": ["positive", "neutral", "negative"],
            "description": "Customer sentiment"
        },
        "escalate": {"type": "boolean", "description": "Whether a human should review immediately"},
        "reason": {"type": "string", "description": "One-sentence justification for the classification"}
    },
    "required": ["category", "priority", "sentiment", "escalate", "reason"],
    "additionalProperties": False
}

ticket = (
    "Our production API calls have been failing with 500 errors since this morning. "
    "We're losing orders every minute. This is the second outage this month!"
)

# Make a request with structured outputs via the InvokeModel API
response = bedrock_runtime.invoke_model(
    modelId="global.anthropic.claude-haiku-5-5",
    body=json.dumps({
        "anthropic_version": "bedrock-2023-05-31",
        "max_tokens": 512,
        "system": "You are a support ticket classifier. Classify the ticket accurately.",
        "messages": [
            {"role": "user", "content": f"Classify this support ticket:\n\n{ticket}"}
        ],
        "output_config": {"format": {"type": "json_schema", "schema": schema}}
    })
)

body = json.loads(response["body"].read())

# Check the stop reason before parsing
if body["stop_reason"] == "end_turn":
    result_text = next(b["text"] for b in body["content"] if b["type"] == "text")
    result = json.loads(result_text)
    print(json.dumps(result, indent=2))
    # Route the ticket based on the guaranteed-valid labels
    if result["escalate"]:
        print(f"Escalating to on-call: {result['category']} / {result['priority']}")
elif body["stop_reason"] == "max_tokens":
    print("Response truncated: increase max_tokens and retry.")

Requirements and best practices

To use structured outputs effectively on Amazon Bedrock, follow these guidelines:

1. Set additionalProperties: false on all objects: This is required for structured outputs to work. Without it, your schema won’t be accepted.
2. Use descriptive field names and descriptions: Models use property names and descriptions to understand what data to extract. Clear names like customer_email outperform generic names like field1.
3. Use enum for constrained values: When a field has a limited set of valid values, use enum to constrain options.
4. Start basic, then add complexity: Begin with the minimum required fields and add complexity incrementally. Basic schemas compile faster, are easier to debug, and keep your request payload lean because the schema counts toward the Converse API payload size.
5. Reuse schemas to benefit from caching: Structure your application to reuse schemas across requests. The 24-hour grammar cache improves performance for repeated queries.
6. Check the stop reason in every response: Two scenarios can produce non-conforming responses: refusals (when the model declines for safety reasons) and token limits (when max_tokens is reached before completing). Handle both cases in your code.
7. Test with realistic data before deployment: Validate your schemas against production-representative inputs. Edge cases in real data often reveal schema design issues.

For additional best practices and schema design recommendations, see Structured outputs in the Amazon Bedrock User Guide.

Supported JSON Schema features

1. All basic types: object, array, string, integer, number, boolean, null.
2. enum (strings, numbers, booleans, or nulls only).
3. const, anyOf, allOf (with limitations).
4. $ref, $def, and definitions (internal references only).
5. String formats: date-time, time, date, duration, email, hostname, uri, ipv4, ipv6, uuid.
6. Array minItems (only values 0 and 1).

Not supported

These keywords are accepted by the API but are not enforced during generation. A request that includes them returns a successful response, and the model can still return values that violate them. Validate these constraints in your application rather than relying on the schema to enforce them.

1. Recursive schemas.
2. External $ref references.
3. Numerical constraints (minimum, maximum, multipleOf).
4. String constraints (minLength, maxLength).
5. additionalProperties set to anything other than false.

Conclusion

Structured outputs for Anthropic Claude models on Amazon Bedrock provides the reliability that production AI applications require. It is available now on both the bedrock-runtime and bedrock-mantle endpoints. By combining JSON Schema output format and strict tool use, you can build data pipelines that need no additional validation. You can also create reliable agentic workflows and production AI applications without custom parsing or retry logic.

Structured outputs for Claude on Amazon Bedrock is now generally available. To learn more, see the Amazon Bedrock documentation and explore our sample notebook.

What workflows could validated, schema-compliant JSON improve in your organization? Share your feedback and questions in the comments.

About the authors

Anshika Saxena

Anshika is a Generative AI Data Scientist at AWS, focused on Amazon Bedrock. She helps enterprise customers accelerate their generative AI and agentic AI adoption by guiding them through building and implementing solutions on Amazon Bedrock. She also works with ISVs and startups to enable them with the latest Anthropic services on Amazon Bedrock.

Dani Mitchell

Dani is a Senior Specialist Solutions Architect for Generative AI at AWS, working on go-to-market for Anthropic on Amazon Bedrock. He helps enterprises across the world design and deploy generative AI solutions using Anthropic’s models and capabilities on Amazon Bedrock to build scalable, production-ready applications.

Alfredo Castillo

Alfredo is a Senior Specialist Solutions Architect for Generative AI at AWS, focusing on Anthropic models go-to-market on Amazon Bedrock. He works with Financial Services customers to design and scale generative AI solutions across distributed systems and turn generative AI experiments into production workloads. Outside of work, he is passionate about family and endurance sports.

Aamna Najmi

Aamna is a Senior Specialist Solutions Architect for Generative AI focusing on Anthropic models and operationalizing and governing generative AI systems at scale on Amazon Bedrock. She helps ISVs solve their challenges, embrace innovation, and create new business opportunities with Amazon Bedrock.

Sofian Hamiti

Sofian is a technology leader with over 12 years of experience building AI solutions, and leading high-performing teams to maximize customer outcomes. He is passionate about empowering diverse talents to drive global impact and achieve their career aspirations.

Ayan Ray

Ayan is a Principal Partner Solutions Architect and AI Tech Lead at AWS, serving as the Worldwide Tech Lead for Anthropic at AWS. He works at the intersection of cloud architecture and Artificial Intelligence, helping organizations adopt and scale Anthropic’s technologies on AWS.