Bedrock接入ADK：大厂模型互通的新解法

当Google的Agent开发工具遇上Amazon的云端模型，中间需要一座什么桥？

这篇部署指南给出了答案：LiteLLM。一个开源AI网关，让100多个大模型用同一套接口说话。开发者不用再为每个云厂商写不同的调用代码。

ADK是什么，为什么需要它

Google Agent Development Kit（智能体开发套件，简称ADK）是开源的Python框架。它把智能体开发当成软件工程来做——模块化、状态管理、内置工具（比如Google搜索），目标是为了构建能自主运行的多智能体系统。

但ADK原生对接的是Google自家的Gemini。如果你想用Amazon Bedrock的模型，比如Claude或Amazon Nova，就需要一个翻译层。

这就是LiteLLM的切入点。

LiteLLM：模型世界的通用插座

LiteLLM的核心能力用一句话概括：OpenAI格式的请求，转发给任意后端模型。

它支持Anthropic、Gemini、Azure、Bedrock、Ollama等100多个模型提供商。统一接口之外，还附带成本追踪、模型降级、密钥管理、负载均衡等企业级功能。

对ADK开发者来说，这意味着可以在不改动代码结构的情况下，把底层模型从Gemini切换到Bedrock，或者同时配置多个模型做A/B测试。

正方观点：统一接口降低迁移成本

支持这套方案的人看重的是工程效率。

第一，学习成本。团队只需要熟悉OpenAI的调用格式，就能操作几乎所有主流模型。新成员 onboarding 时间大幅缩短。

第二，供应商锁定风险。业务不再被单一云厂商绑定。今天用Bedrock，明天发现Azure价格更低，改一行配置就能切过去。

第三，功能叠加。LiteLLM不只是转发请求，它的网关层自带监控和熔断机制。生产环境需要的可观测性，不用自己从零搭建。

反方观点：抽象层带来额外复杂度

质疑的声音同样存在。

第一，调试困难。当请求出错时，问题可能出在ADK、LiteLLM、Bedrock三个环节中的任意一个。多一层抽象，就多一层排查成本。

第二，功能损耗。Bedrock的某些原生特性（比如特定的安全合规配置）可能无法通过LiteLLM的通用接口完整暴露。为了兼容性，不得不放弃部分高级功能。

第三，维护负担。LiteLLM是开源项目，更新节奏和社区支持质量直接影响生产稳定性。企业需要评估自己是否有能力跟进版本迭代。

我的判断：这是过渡期最优解，但不是终点

这件事的重要性在于它揭示了行业的一个真实状态：模型层正在快速分化，但应用层渴望统一。

Google推ADK，Amazon推Bedrock，OpenAI有自己的Agent SDK。每家都想定义标准，但开发者不想被绑架。LiteLLM这类工具的存在，说明市场需要"中间件"来弥合分裂。

短期来看，这个方案确实解决了具体问题——让ADK用户能用上Bedrock的模型。但长期而言，如果各大云厂商的Agent框架持续分化，中间件的复杂度只会越来越高。

更值得关注的信号是：Gemini CLI已经开始内置ADK技能支持。

「/skills list」和「/mcp list」命令可以直接唤起ADK文档查询和工具调用。这说明Google正在把ADK生态做深，而不是做一个孤立的框架。

对技术团队的建议：如果你已经在用ADK，且有Bedrock的模型资源，LiteLLM是值得尝试的桥接方案。但要把LiteLLM的配置和版本管理纳入技术债务清单，定期评估是否有更原生的集成方式出现。

模型互通的终极形态，可能是某个真正的行业标准，也可能是各大平台被迫接受的有限兼容。在那之前，这类"胶水代码"会持续存在。