一家旧金山的AI创业公司，在2024年花了3个月用GPT-4构建了客服系统，写了数万行OpenAI格式的代码。到了2025年，他们的工程师发现Claude在某类任务上表现明显更好，但当他们评估迁移成本时，得出的结论令人沮丧：切换意味着重写核心调用层、重新测试所有边界情况，最少需要2个月的工程量。他们最终放弃了切换。

这个故事，在全球数千家正在使用AI的企业中，以不同的版本重复上演。

2026年6月4日，AWS悄悄发布了一则公告，改变了这个故事的结局。

公告的标题是：Amazon Bedrock推出重新设计的控制台，针对OpenAI和Anthropic兼容API进行优化。

一、一个控制台，三种语言

这次更新的核心是一个叫bedrock-mantle的新端点。这个端点干了一件非常有意思的事：它同时支持OpenAI的Responses API、OpenAI的Chat Completions API，以及Anthropic的Messages API。

换句话说，你可以用写OpenAI代码的方式，调用Claude。也可以用写Anthropic代码的方式，调用GPT。而这一切，都发生在AWS的基础设施上。

从技术角度看，这是一个架构上的重大决策。AWS专门开辟了一个独立的端点域名——bedrock-mantle.{region}.api.aws，与原有的bedrock-runtime.{region}.amazonaws.com并行运行。新端点专门承载多格式兼容调用，旧端点依然支持AWS原生的InvokeModel和Converse API。这种双轨设计保证了向后兼容，同时为新用户提供了最低摩擦的入口。

这是一个精心设计的信号。AWS在告诉全球超过100,000家使用Bedrock的企业：我是所有模型的入口，无论你用哪家的编程习惯，都能在这里找到家。

二、为什么API格式之争是一场被低估的战役

在大多数人眼里，API格式是个技术细节。OpenAI有自己的格式，Anthropic有自己的格式，各家略有不同，开发者需要写不同的代码来调用不同的模型。

但对于要在生产环境中部署AI的企业来说，这是一个非常现实的痛点。

想象一家中等规模的科技公司，它在2024年用GPT-4构建了客服系统，写了几万行代码，所有调用都是OpenAI格式。到了2025年，Claude在某些任务上明显更好，他们想切换。但切换意味着重写API调用层，重新测试，重新部署——对于大型系统来说，这可能是几个月的工程量：梳理所有调用点，修改数据结构，调整错误处理，更新测试用例，经历完整的QA流程。

这就是为什么模型切换在理论上很诱人，但实践中很少发生的原因。不是因为开发者不愿意，而是因为迁移成本实在太高。

据业界普遍观察，企业AI项目中大量延期案例并非因为模型能力不足，而是因为基础设施迁移和集成复杂性拖累了进度。API格式锁定是其中最常见、也最隐性的障碍之一。

AWS的新控制台直接解决了这个问题。通过bedrock-mantle端点，企业不需要改动任何业务逻辑代码，只需要更换端点URL和API key，就可以把后端模型从GPT-4切换到Claude，或者反过来。

这表面上是给开发者的礼物，但其背后的逻辑更加微妙。

三、AWS的”万能插座”战略

理解这次发布，需要回到AWS的云计算哲学。

从一开始，AWS构建云服务的核心逻辑就是：我提供基础设施，你在上面运行任何东西。这个哲学让AWS在数据库、计算、存储领域都采用了”多选择”策略——你可以在AWS上运行MySQL、PostgreSQL、Oracle，可以用EC2跑任何操作系统，可以在S3存任何格式的文件。

AWS从不强迫你用哪家的技术栈，但它让你离不开AWS。

在AI领域，这个策略正在重演，而且以一种更加系统化的方式。

Bedrock从一开始就不是单一模型服务，而是模型聚合平台。它上面有Amazon自己的Nova系列，有Anthropic的Claude，有Meta的Llama，有Stability AI的图像模型，现在连OpenAI的GPT系列也已经在Bedrock上正式GA（正式发布）。这意味着一家企业无需离开AWS生态，就可以访问市场上几乎所有主流的AI模型。

但模型聚合还不够。真正的锁定发生在更深的层次：开发体验的锁定。

当1个团队开始在Bedrock控制台里建立Projects（项目），所有的模型配置、API密钥、文档模板都存在Bedrock的工作空间里；当project-aware文档自动把模型ID、区域、端点URL填入每1个代码片段；当开发者习惯了在Bedrock控制台里1键对比Claude和GPT的能力；当团队的全部评估历史、使用分析都在Bedrock的仪表板里——迁移到其他平台的成本就在悄然之间被堆高了。

这就是万能插座的逻辑：先让所有的电器都能插进来，然后让所有人都依赖这个插座板。

四、新控制台的4项关键能力

AWS这次重新设计的控制台，具体做了什么？

第1项：模型目录并排比较

新控制台允许开发者在1个界面里同时看到Bedrock上所有可用模型的详细规格——包括能力描述、支持的模态（文本/图像/视频）、上下文窗口大小、服务配额限制——不需要在十几个文档页面之间来回切换。

对于企业架构师来说，这个功能节省的时间可能超过任何代码工具。选择模型的过程从”查文档→整合对比→制作表格→开会讨论”变成了”打开控制台→一眼看清楚”。这不只是便利性的提升，更是决策速度的加快——在AI快速迭代的时代，能更快做出模型选择，就意味着更快的产品迭代。

第2项：Projects工作空间

新控制台引入了Projects概念，把模型选择、评估实验、使用分析都组织在同1个项目下，对应AI应用开发的完整生命周期：实验→评估→生产部署。

这个设计是对企业开发工作流的深刻理解。在没有Projects的时代，团队成员各自使用控制台，没有统一的上下文，技术负责人无法全局查看团队在用哪些模型、各自的效果如何；有了Projects之后，整个团队的探索历史、模型配置、性能数据都在同1个地方，大幅降低了团队协作成本，也为企业的AI治理提供了数据基础。

第3项：Project-Aware文档

这是新控制台里技术含量最高的功能。当你在Projects里选定了模型、区域、API格式之后，系统会自动把这些参数填入控制台内嵌的代码文档里——包括：

  • 正确的端点URL（bedrock-mantle.{region}.api.aws）
  • 项目的API key引用变量
  • 对应SDK的完整代码片段（OpenAI Python SDK / Anthropic Python SDK / JavaScript版本）

你可以直接从控制台复制代码，粘贴到自己的应用里，不需要修改任何参数就能运行。

这是1个看起来微小、但极其高效的功能。开发者最常见的摩擦点之1就是：文档里的示例代码是通用的，需要手动替换端点、密钥、模型ID等参数，替换过程中很容易出错。project-aware文档把这个步骤自动化了，大幅降低了从”看文档”到”代码运行”的时间。

第4项：AI编码Agent集成指引

新控制台提供了连接AI编码工具的指引，明确支持Claude Code、Cursor和Codex这3款工具。

值得注意的是，这3个工具本身代表了当下AI编程工具市场的3大阵营：

  • Claude Code：Anthropic自研的AI编程助手
  • Cursor：独立创业公司，当前市值估计超过50亿美元
  • Codex：OpenAI自研的AI编程平台

AWS同时支持来自3个竞争阵营的工具，再次体现了”全部接纳、自己居中”的战略逻辑。这不是技术无所谓，而是刻意的平台策略。

五、乐观视角：开发者的胜利

从开发者的角度看，这次更新几乎是纯粹的利好。

迁移成本归零

有了bedrock-mantle端点，从OpenAI格式切换到Anthropic格式，或者反过来，不需要重写业务逻辑。只需要改1个端点URL和API key。

对于那些已经有大量OpenAI格式代码的企业，这意味着接入Claude的成本从”几个月工程量”变成了”几分钟配置”。实际上，使用OpenAI官方Python SDK的代码，只需修改基础URL和API key，就可以直接调用Claude——代码层面零改动。

这个意义非常重大。在2025年，很多企业已经深度使用OpenAI格式构建了生产系统。这些企业一直想尝试Claude，但迁移成本让他们望而却步。bedrock-mantle移除了这道门槛。

模型自由选择权

当所有主流模型都在同1个平台、可以用同1套API格式调用，开发者终于可以真正按照任务需求选择最合适的模型，而不是被代码格式绑定在某1家供应商。

1个团队可以在同1个项目里，用Claude处理需要精确推理和事实准确性的任务，用GPT处理需要广泛知识整合的任务，用Llama处理需要本地化部署或成本极度敏感的任务。这种灵活性在之前是存在的，但需要维护多套代码；现在可以在1套代码框架下实现。

降低学习曲线

对于刚进入AI开发领域的团队，新控制台的project-aware文档意味着他们不需要深入理解每家模型API的细节差异——格式差异、参数命名差异、错误处理差异——可以更快地从零到生产就绪。

对于全球数十万家正在尝试企业AI部署的组织来说，这次更新降低了1个重要的实际障碍。相比之下，在此之前，接入多家模型往往意味着维护多套完全不同的代码分支，版本升级和错误排查都是双倍的负担。

六、悲观视角：模型商的商品化陷阱

但站在模型供应商——OpenAI和Anthropic——的角度，这件事的意义就完全不同了。

API格式标准化的代价

当OpenAI格式和Anthropic格式在AWS控制台里变成2个可以互换的选项，它们实际上在经历1种静默的商品化。

原本，选择OpenAI还是Anthropic不只是模型选择，也是开发栈选择，是1种路径依赖。1旦选了OpenAI，代码格式、文档、社区资源、第三方工具集成都是OpenAI中心的。这种路径依赖是模型公司的护城河之1——它让企业在做了初始选择之后，不愿意轻易切换。

现在，这种路径依赖被AWS消解了。企业可以用同样的代码格式调用任何模型，选择标准变成了纯粹的性能和价格对比。

这对开发者是好事，但对模型公司来说，竞争变得更加激烈，差异化空间被压缩。当2个产品可以零成本切换时，价格竞争的压力会显著上升。

定价权的转移

更深层的问题是：当企业通过Bedrock调用Claude或GPT时，定价是由AWS决定的，而不是由Anthropic或OpenAI单独决定的。

AWS作为中间层，拥有了调整价格、捆绑服务、设计折扣结构的主动权。AWS可以把Bedrock上的Claude调用打包进企业云服务协议，给出更有竞争力的打包价，这是Anthropic单独无法提供的。

在云计算的历史上，我们见过无数次这样的剧情：1项技术成为云平台的标准化服务后，原始供应商的定价能力逐渐下降。MySQL变成了RDS，Redis变成了ElastiCache，每1次”云化”都伴随着原始供应商某种程度上的边缘化——他们成为了技术的贡献者，但利润更多地留在了云层。

AI模型正在经历同样的过程吗？目前还没有确定答案，但这是每家模型公司CEO都在深夜思考的问题。

AWS中间层的数据权力

还有1个更微妙的点：当所有模型都通过bedrock-mantle这个单1端点提供服务时，AWS实际上获得了完整的调用数据。

哪个企业客户在用哪个模型，什么类型的任务，调用频率，token消耗——这些数据对于AI产业的竞争格局具有巨大价值。它可以帮助AWS了解市场需求、定价模型、优化资源分配。这不是阴谋论，这是云基础设施的基本特性：你控制了流量，就控制了洞察。

AWS通过控制基础设施来理解市场，是它在过去20年里学到的最核心的商业技能。

七、第三层洞察：谁在赢得API标准战争

在更宏观的视角里，这次Bedrock控制台更新揭示了1个正在发生的结构性转变。

标准战争的真正赢家往往不在擂台上

2023年，OpenAI开放API时，它的格式迅速成为行业事实标准。大量工具、库、企业代码都用OpenAI格式写成。Anthropic推出Claude时，面临的现实是：大多数开发者已经习惯了写OpenAI格式的代码，Anthropic必须推出自己的Messages API，同时承受”非主流”的额外摩擦。

2种格式并存，各有支持者，形成了细微但真实的分裂状态。

然后AWS出现了，说：你们2种格式我都支持。

标准战争的教科书告诉我们，真正获益的往往不是竞争的任何1方，而是在2种标准之间充当接口的第3方。这就是为什么USB-A和USB-C混战的年代，做转接头的厂商赚得盆满钵满；为什么PC时代的Intel和微软，比实际生产内容的应用公司获得了更多的价值。

在AI API格式这场战争里，AWS扮演的正是”转接头”的角色。bedrock-mantle端点，是这个转接头最具体的实现。

便利性作为武器——比技术锁定更高级的绑定

AWS的这次兼容性支持看起来是完全无私的——它甚至在帮助OpenAI和Anthropic获得更多企业采用。但每1个通过Bedrock使用Claude或GPT的团队，都是在AWS的基础设施上构建的。

这让人想起AWS S3的故事。当年，S3把对象存储变成了按需服务，没有人被强迫使用，但数据一旦迁入S3，数据量越大，迁出的带宽成本和工程成本就越高。今天的Bedrock Projects，正在为AI应用做同样的事：它不强迫你留下，但每1个存在Bedrock里的项目配置、每1条使用分析数据、每1份自动填充的SDK文档，都在悄悄提高迁出的隐性成本。

随着时间推移，这些团队积累的不只是代码，还有数据、工作流、团队习惯。他们的向量数据库可能在AWS，他们的训练数据在S3，他们的评估指标在CloudWatch，他们的团队工作流在Bedrock Projects里。迁出Bedrock的成本，会随着使用时间的增长而增长——不是因为API格式，而是因为整个技术栈的沉淀。

传统的技术锁定是通过”不兼容”来实现的：用了我的格式，就很难迁移。

AWS的这种锁定是通过”太方便了”来实现的：我支持所有格式，我提供最好的工具，我有最完整的生态——所以你为什么要离开？

这是1种更高级的平台策略，也是更难打破的竞争护城河。

企业AI平台竞争的第3阶段

整个AI产业的平台竞争正在进入第3阶段：

  • 第1阶段（2023-2024）：竞争是”谁的模型更好”——GPT-4 vs Claude 2 vs Gemini，性能基准分出高下
  • 第2阶段（2024-2025）：竞争是”谁的生态更丰富”——谁有更多的模型选项、更好的微调工具、更完整的Agent框架
  • 第3阶段（2025-2026至今）：竞争是”谁能给开发者最低的摩擦感”——谁能让企业最快地从零到生产，最流畅地切换模型，最无缝地集成进现有工作流

在第3阶段，单纯的模型能力优势不再足够。即使你有世界上最好的模型，如果开发者接入你的服务需要2个月的集成工作，很多企业会选择接入稍差但更方便的替代方案。

在这个维度上，AWS的优势是结构性的：超过10万家企业已经深度使用Bedrock，AWS有最成熟的企业云生态，有遍布全球多个区域的部署（bedrock-mantle已覆盖美国东部、西部、亚太多区域），有企业级安全合规体系，有专业的企业销售和支持团队。

OpenAI和Anthropic再强大的模型，也需要在某个基础设施层上运行，需要某个控制台来管理。而这个基础设施层和控制台，AWS已经深度渗透进了企业IT体系里。

八、结语：控制台背后的权力地图

1个控制台的更新，揭示了AI产业正在悄悄发生的权力再分配。

模型公司在竞争谁的语言理解更准确、谁的推理能力更强、谁的创意生成更有趣。这些能力的竞争是真实的、有意义的，Anthropic和OpenAI的底层研究仍然是整个生态的核心驱动力——没有强大的模型，再好的控制台也是空壳。

但对于大多数企业客户而言，他们实际接触到的”AI”，越来越不是某家模型公司的直接产品，而是包裹在云平台里的托管服务。他们不知道也不需要知道模型的训练细节，他们关心的是：接入是否简单？切换是否方便？账单是否可预测？数据安全是否合规？

在这个层面，AWS的战略意图已经非常清晰：它想成为企业AI时代的操作系统——不是某1个模型的平台，而是所有模型运行在其上的底层基础设施。

2012年，AWS用RDS把关系型数据库变成了1项无差别的云服务。2015年，它用Lambda把计算本身变成了1项无差别的云服务。2026年，它正在用Bedrock和bedrock-mantle，把AI模型调用变成1项无差别的云服务。

bedrock-mantle.{region}.api.aws——这个看起来只是1个技术端点的字符串，可能是这场权力重构最具象的注脚。

参考资料

  1. AWS官方公告：Amazon Bedrock推出重设计控制台，优化OpenAI和Anthropic兼容API
    https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-redesigned-console-optimized-openai-anthropic-compatible-apis/
    发布时间：2026-06-04（官方来源）

  2. Amazon Bedrock端点技术文档：bedrock-mantle规格与支持的API格式
    https://docs.aws.amazon.com/bedrock/latest/userguide/endpoints.html
    来源：AWS官方技术文档

  3. Amazon Bedrock官方主页：10万+组织使用数据
    https://aws.amazon.com/bedrock/
    来源：AWS官方

  4. Amazon Bedrock Inference APIs文档（Messages API）
    https://docs.aws.amazon.com/bedrock/latest/userguide/inference-messages-api.html
    来源：AWS官方技术文档

  5. OpenAI GPT系列模型在Amazon Bedrock多模型战略背景
    来源：AWS官方博客及公告，2026年上半年，OpenAI GPT系列模型已正式在Bedrock上架，这是Bedrock多模型聚合战略的重要组成部分