从 Claude Code 接入 Bedrock 看企业级大模型 API 的架构演进

在生成式 AI 从实验室走向企业生产环境的过程中，基础设施的架构演进正在加速。近期，Anthropic 官方推出的命令行工具 Claude Code 正式宣布支持 AWS Bedrock，这一动作在开发者社区引发了广泛的讨论，也折射出企业级 AI 应用落地的真实痛点。

云原生与 AI 的深度绑定

将 AI 工具链与云服务商（CSP）深度绑定，已经成为行业共识。以开源社区活跃的 AI 编程助手 Cline 为例，其近期的核心架构调整（PR #2742）极具代表性：开发团队移除了 Anthropic 官方的 Bedrock SDK，全面替换为原生的 AWS Bedrock Runtime SDK。

这种底层架构的切换，并非简单的 API 替换，而是基于企业级管控需求的深思熟虑：

统一的 Converse API 架构：原生 AWS SDK 提供了一致的接口契约。企业可以在不修改上层业务逻辑的前提下，在 Claude、Llama、Mistral 等不同基础模型之间进行灰度测试和流量切换，有效避免了单一模型厂商的锁定风险（Vendor Lock-in）。
Bedrock Guardrails（安全护栏）：在企业级应用中，输入输出的合规性是不可逾越的红线。原生 SDK 允许企业在网关层直接挂载内容过滤策略，实现 PII（个人身份信息）脱敏和敏感词拦截，将安全管控左移。
数据主权与 VPC 隔离：通过 Bedrock 调用模型，所有的数据流转均在企业自身的 Virtual Private Cloud (VPC) 内部完成，满足了金融、医疗等强监管行业的数据不出境要求。

早期集成的技术阵痛

然而，从社区的反馈来看，目前工具链的成熟度仍有待提升。Claude Code 在接入 AWS 生态时，暴露出了一些典型的“水土不服”。

首先是客户端的稳定性问题。在 2.1.70 版本中，当开发者通过环境变量 CLAUDE_CODE_USE_BEDROCK=1 启用 AWS 支持时，诊断命令 claude doctor 会陷入无限期的阻塞状态（Issue #31478）。这种基础的生命周期管理缺陷，反映出跨平台集成测试的不足。

其次是身份认证体系的割裂。现代云原生企业普遍采用 SSO（单点登录）和 STS（安全令牌服务）来管理动态权限。但目前的 Claude Code 缺乏对复杂凭证链（Credential Chain）和角色扮演（Role Assumption）的支持，迫使开发者回退到使用静态 Access Key 的不安全实践中。

敏捷开发与重度合规的平衡

AWS Bedrock 提供了极致的安全与管控，但也带来了极高的接入复杂度和运维成本。对于大型企业，这是必须支付的合规成本。但对于追求敏捷迭代的创新型业务团队，沉重的云架构配置往往会拖慢 AI 能力的落地速度。

在实际的架构选型中，很多团队开始采用“双轨制”策略：

核心涉密业务：严格走 AWS Bedrock 链路，确保数据绝对隔离。
敏捷创新业务：引入轻量级的 API 聚合网关（如开发者常用的 147AI 等平台）。这类中间件屏蔽了底层云厂商的复杂鉴权，提供标准化的 OpenAI 兼容接口，使得前端和业务开发人员可以零配置、跨模型地快速验证产品原型。

大模型能力的下发，正在经历从“直接调用厂商 API”到“通过云厂商网关管控”，再到“多层级路由分发”的演进。Anthropic 与 AWS 的深度融合只是一个开始，未来我们将看到更多标准化、企业级的 AI 基础设施中间件涌现。

参考资料：

GitHub Pull Request: cline/cline #2742 (Replace Anthropic Bedrock SDK with native AWS Bedrock Runtime SDK)
GitHub Issue: anthropics/claude-code #31478 (claude doctor hangs indefinitely)