Claude Opus 5.5 已可通过 Amazon Bedrock 和 AWS 上的 Claude Platform 使用。它面向智能体编程、知识工作和长时间运行任务等复杂场景。对已经采用 AWS 身份管理、审计与云基础设施的团队来说，这意味着可以把新模型接入现有工程体系，而不必重新设计整套访问链路。
真正值得关注的不只是“模型可用了”，而是如何确认模型标识、建立可重复的调用方式，并在迁移生产任务前验证质量、成本、延迟和安全边界。
先确认区域、模型 ID 与调用方式
Amazon Bedrock 的模型可用性可能受区域、账户权限和组织策略影响。模型 ID、推理配置文件 ID 也可能随区域和接入方式不同，因此不要直接把博客或示例中的标识写死到生产代码里。
先配置 AWS CLI，并确认当前身份：
aws sts get-caller-identity
aws configure get region
然后查询名称中包含 Claude Opus 5.5 的基础模型：
aws bedrock list-foundation-models \
--query "modelSummaries[?contains(modelName, 'Claude Opus 5.5')].[modelName,modelId,modelLifecycle.status]" \
--output table
如果团队使用 Bedrock 推理配置文件，也可以继续查询：
aws bedrock list-inference-profiles \
--query "inferenceProfileSummaries[?contains(inferenceProfileName, 'Opus 5.5')].[inferenceProfileName,inferenceProfileId,status]" \
--output table
根据账户实际返回的结果设置环境变量：
export AWS_REGION=us-east-1
export MODEL_ID='替换为基础模型或推理配置文件的实际 ID'
如果查询不到结果，应依次检查：
- 当前区域是否提供该模型；
- 账户是否已经获得相应模型访问权限；
- IAM 身份是否具有查看模型和执行推理的权限；
- 组织服务控制策略、权限边界或网络策略是否拦截了请求；
- 当前环境是否需要使用推理配置文件，而不是基础模型 ID。
用 Bedrock Converse API 建立最小调用
下面的示例使用 Bedrock Runtime 的 Converse API。运行前需要安装较新的 AWS SDK for Python，并设置上一节中的 AWS_REGION 和 MODEL_ID。
python -m pip install --upgrade boto3
将以下内容保存为 review_with_opus.py：
import os
import boto3
region = os.environ.get('AWS_REGION', 'us-east-1')
model_id = os.environ['MODEL_ID']
client = boto3.client('bedrock-runtime', region_name=region)
source_code = '''
def load_user(user_id, db):
return db.execute(
f"SELECT * FROM users WHERE id = {user_id}"
).fetchone()
'''
response = client.converse(
modelId=model_id,
system=[
{
'text': (
'You are a senior application security engineer. '
'Find concrete defects, explain impact, and return a corrected implementation.'
)
}
],
messages=[
{
'role': 'user',
'content': [
{
'text': (
'Review this Python function. Return sections named '
'Findings, Fixed Code, and Tests.\n\n' + source_code
)
}
]
}
],
inferenceConfig={
'maxTokens': 1200,
'temperature': 0.1
}
)
for block in response['output']['message']['content']:
if 'text' in block:
print(block['text'])
usage = response.get('usage', {})
print('\n--- Usage ---')
print(usage)
运行：
python review_with_opus.py
这段代码适合验证三个基础条件：AWS 凭证是否有效、模型标识是否正确、应用是否能解析 Converse API 的统一响应结构。生产代码还应补充超时、指数退避、限流处理、请求追踪和结构化日志。
不要把访问密钥直接写进脚本。开发环境可以使用 AWS SSO 或本地配置文件；部署到 Lambda、ECS 或 EKS 时，应优先使用执行角色、任务角色或工作负载身份。
智能体编程不是一次更长的聊天
Opus 5.5 面向 agentic coding 和长时间运行任务，但生产级智能体仍需要模型之外的控制层。一个可靠的编程智能体通常应把任务拆成明确阶段：
- 读取需求和仓库约束；
- 制定可审查的修改计划；
- 只开放必要的文件、搜索、测试或构建工具；
- 执行小范围修改；
- 运行测试并收集真实结果；
- 根据结果修复，达到循环上限后停止；
- 输出变更摘要、风险和未完成事项。
可以这样设计智能体的任务提示词：
目标：修复订单服务中的重复扣款问题。
允许操作：
- 读取 services/order/ 与 tests/order/ 下的文件
- 修改上述目录中的代码
- 运行 pytest tests/order -q
约束：
- 不得访问生产凭证或外部网络
- 不得修改数据库迁移文件
- 每轮修改前说明假设
- 最多执行 5 轮“修改—测试”循环
- 测试失败时必须引用真实错误输出，不得声称已经通过
完成条件：
- 新增可复现问题的测试
- 修复后相关测试通过
- 输出修改文件、剩余风险和回滚方式
这里的关键不是提示词写得多长，而是让执行权限、完成条件和停止条件都可验证。对于删除资源、部署生产环境、修改 IAM 或执行数据库写入等高风险动作，应加入人工批准节点，而不是让模型自行决定。
长任务还需要把状态保存在外部系统中，例如任务表、对象存储或工作流引擎。不要把完整状态只放在不断增长的对话历史里。外部状态便于恢复、审计和重试，也能避免一次超时让全部进度丢失。
用真实任务评估，而不是只比较回答观感
迁移现有工作负载时，建议构建一组来自真实业务、经过脱敏的评测样本。不同任务应使用不同指标：
| 场景 | 建议指标 |
|---|---|
| 代码修复 | 测试通过率、回归数量、人工接受率 |
| 代码审查 | 有效缺陷召回率、误报率、建议可执行性 |
| 知识工作 | 引用准确性、遗漏率、结构一致性 |
| 长任务 | 完成率、平均循环次数、中断恢复率 |
| 工具调用 | 参数正确率、越权调用次数、失败恢复能力 |
同时记录端到端延迟、输入输出用量、重试次数和单位任务成本。模型在复杂任务上更强，并不意味着所有请求都应该交给同一个模型。分类、抽取或简单改写可以继续由成本更低、延迟更小的模型处理，把 Opus 5.5 留给多步骤推理、复杂代码变更和失败代价较高的任务。
还应固定测试条件，包括系统提示词、工具定义、最大输出长度、温度、样本版本和超时设置。否则一次看似明显的模型差异，可能只是配置变化造成的。
上线前的工程检查表
在将 Claude Opus 5.5 接入生产系统前，可以按下面的清单推进：
- 确认目标区域、模型 ID或推理配置文件，并通过配置注入而非硬编码；
- 使用最小权限 IAM 策略，只允许应用调用所需资源；
- 对提示词、工具输入和模型输出进行敏感信息过滤；
- 为外部工具设置白名单、参数校验、超时和调用次数上限；
- 对部署、删除、付款和权限修改等动作保留人工审批；
- 建立离线评测集，并在提示词或模型版本变化后执行回归测试；
- 记录请求 ID、延迟、用量和工具执行结果，但避免把密钥写入日志；
- 设计限流、重试、幂等和降级路径；
- 为长任务持久化检查点，允许安全恢复，而不是从头重跑。
采用新模型最稳妥的方式，是先选择一类边界清晰、结果可自动验证的任务进行灰度，例如测试生成、受限目录内的代码修复或带引用的内部资料整理。确认质量收益足以覆盖成本和运行复杂度后，再逐步扩大权限与任务范围。