Bedrock接入ADK：大厂模型互通的隐藏路径

AWS Bedrock用户现在可以用Google的Agent开发框架了。这不是官方合作，是一群开发者用开源工具打通的。

技术栈的墙正在变薄。LiteLLM这个开源网关，让100多个大模型接口统一成OpenAI格式。ADK（智能体开发工具包）是Google推出的Python框架，原本只认自家模型。现在两者连上了。

正方：为什么这件事值得做

多模型策略是刚需。Bedrock提供Claude、Llama、Titan等商用模型，ADK擅长多智能体编排，两者结合等于"AWS算力+Google工程框架"。

LiteLLM的桥梁作用被低估了。它不只是格式转换器，还管成本追踪、故障转移、密钥管理、负载均衡。企业级功能一个没少。

Gemini CLI的扩展性被打开。通过MCP（模型上下文协议）服务器，开发者能在命令行里直接调用ADK技能，文档查询、代码生成、智能体调试全打通。

具体路径：安装Gemini CLI → 配置ADK-MCP服务器 → 用LiteLLM代理指向Bedrock端点 → 统一调用。全程开源工具，零厂商绑定。

反方：别急着欢呼

这不是官方集成，是社区 workaround。AWS和Google没有互相认证，生产环境出问题找谁？

延迟和稳定性存疑。多跳代理（ADK→LiteLLM→Bedrock）比原生调用多两层网络，高并发场景下故障排查更复杂。

功能阉割风险。Bedrock的Guardrails、知识库、代理编排等原生功能，经过LiteLLM中转后能否完整保留？原文没提，但值得警惕。

维护成本转移。省下的授权费，可能变成工程师的调试时间。小团队玩得起，大规模部署要算账。

我的判断：工具层正在重构云厂商的权力边界

这件事的真正信号，不是"Bedrock+ADK能用"，而是模型网关层正在成为新的基础设施。

云厂商过去靠模型+框架+算力三位一体锁定用户。现在LiteLLM这类工具把"框架"这层抽走了——你可以用Google的ADK、LangChain、LlamaIndex，底层接谁家模型都行。

对开发者：选择权回来了，但复杂度也上来了。多模型架构需要新的运维能力，成本追踪、版本管理、一致性测试，这些工具链还没成熟。

对厂商：护城河从"全栈封闭"转向"单点极致"。Bedrock要证明模型性价比，ADK要证明编排效率，各司其职。

下一步观察点：MCP协议会不会成为事实标准？如果更多工具支持MCP，Gemini CLI这种"命令行即入口"的模式可能复制到更多场景。

如果你正在评估多模型方案，建议先跑通这个PoC：用LiteLLM代理两个Bedrock模型，观察延迟差异和错误率。数据比文档诚实。