InvokeModel 与 OpenAI、Anthropic 双向转译：AgentCore 网关把多模型降级收进托管层，聚合商的活少了哪一半

事实：一个端点同时听懂两种方言

AWS 在 2026 年 10 月 22 日为 Amazon Bedrock AgentCore Gateway 补了两块能力：一是聚合的 /inference 端点开始支持 Bedrock 的 InvokeModel 与 InvokeModelWithResponseStream 线格式，二是推理流量可以配置模型降级链。官方发布说明写得直白：客户端与目标的协议方言不一致时，网关自己翻译请求、并把流式响应重新分帧，调用方 SDK 原样可用。

换句话说，用 Bedrock SDK 的客户端现在能直接打非 Bedrock 供应商的推理目标，而用 OpenAI 或 Anthropic SDK 的客户端也能打到只提供 InvokeModel 的 Bedrock 目标。新增的 bedrock-runtime 连接器专门用来配置这种原生目标，跨协议的两个方向都覆盖。

降级链怎么配：条件、顺序、熔断

降级不是模糊的自动重试。网关规则里先用 matchModels 把请求筛出来，再在 routeToTarget 动作上挂一条有序的备用目标链；哪些失败触发切换由你决定，公开的触发条件是限流、服务端错误与响应超时，并为每个目标单独设定首字节超时。服务侧熔断器默认开启，直接跳过正在出错的目标，避免把时间耗在注定失败的尝试上。对调用方而言只有一次请求、一次响应，中间的试探过程被收进网关内部。

区域范围要看清：除中国区之外，所有已经提供 AgentCore Gateway 的区域都有这两项能力。

我的判断：聚合层的一部分价值正在被基础设施吃掉

过去搭一个多模型聚合入口，工程上至少三份活：给每家供应商各写一套 SDK 适配与鉴权、写一套带熔断的重试状态机、把各家流式协议的差异在网关里重新分帧。这次托管掉的是前两项里最脏的一半——协议转译与失败切换。剩下的是策略与账：谁能调哪个模型、内容边界在哪、按什么口径计费。AgentCore 这一侧用 Cedar 策略做默认拒绝，模型白名单能在目标层直接拦住，不必等策略引擎评估一遍。

但也不能把它读成聚合商要消失。真正的分水岭在时延可控性：降级链越长，尾部时延越不可控；首字节超时是逐目标配置的，链上第二、第三跳如果都慢，用户体验是断崖式的。我的做法是把链深压在两层，第二层给比首层更紧的首字节预算，并且把切换条件只绑在限流与 5xx 上，响应超时单独走告警而不是静默切换——否则就是拿质量下降换一个看起来没报错的仪表盘。

对国内团队更现实的一句：中国区不在覆盖范围。这套托管能力拿不到，等价物仍然要自建——一个统一入口、一套模型白名单、一条两跳降级链、一个默认开启的熔断状态机。自己写这套东西的成本不在代码量，而在长期的供应商变更维护：每接一家新供应商就是一次适配回归。

三条可量化的选型验收口径

第一，首字节超时能否逐目标配置，不能则长尾无法隔离；第二，熔断状态是否跨请求共享，不共享等于每次请求重新踩坑；第三，流式响应转译后是否保持帧边界，帧边界一破，前端的打字机效果会退化成整段返回。这三条全部过了，才谈得上把它挂到生产链路上；只满足前两条的，建议先跑影子流量再切。评估自建方案时我更愿意看新增一家供应商需要改几处配置，而不是页面上支持了几家。

来源：AWS What’s New（2026-10-22）、Amazon Bedrock AgentCore 开发者指南发布说明、AWS Builder Center 统一 AI 网关技术文。观点为作者判断，非厂商数据。