一个Google开发的命令行AI工具，最终被部署在了微软的Kubernetes集群上。这种跨云操作在2024年还属于"技术宅自嗨"，现在却成了企业级部署的常规路径。
Google Agent Development Kit（ADK，智能体开发套件）和Gemini CLI（Gemini命令行界面）的组合，正在被开发者从GCP（Google Cloud Platform，谷歌云平台）搬到Azure（微软云）上运行。
这不是迁移，是"借壳"。开发者想用的是Google的模型能力，但基础设施预算在微软那边。
跨云部署的动机：为什么不用原生方案
企业IT架构的现状是：多云已成定局，但"多云"不等于"随便迁"。一家公司的核心数据在Azure，历史包袱在AWS，实验性项目可能 Originated from GCP。
Gemini CLI的开源属性让它具备了"平台无关"的物理基础。它通过MCP（Model Context Protocol，模型上下文协议）连接外部工具，支持文件操作、Shell命令执行，本质上是一个封装了Gemini 2.5 Pro能力的终端代理。
开发者@xbill的验证路径很典型：先用pyenv锁定Python 3.13环境，再用nvm（Node Version Manager，Node版本管理器）确保Node.js版本一致，最后通过npm全局安装Gemini CLI。这套流程跨平台可复制，但目标明确——让Google的AI工具跑在Azure的K8s集群里。
AKS（Azure Kubernetes Service，Azure Kubernetes服务）的吸引力在于"托管"二字。健康监控、自动升级、节点维护这些脏活累活微软包了，团队只需要关心容器里的业务逻辑。对于ADK这种偏实验性质的部署，AKS的serverless（无服务器）模式能把成本压到最低。
技术验证：从单节点到集群的最小可行路径
整个验证的核心假设是：ADK服务器能不能在AKS上跑起来？
答案是能，但有个前提——你得接受"大马拉小车"的资源配置。一个完整的K8s集群对于基础ADK服务来说确实过量，但这笔"浪费"买的是未来的扩展性。一旦验证通过，同样的集群可以叠加服务网格、监控、CI/CD流水线，变成生产级架构。
具体操作上，Gemini CLI的启动需要Google账号或API Key认证。登录成功后，终端会显示当前版本（v0.33.1）和订阅状态（Gemini Code Assist Standard）。这个界面熟悉Google Cloud的开发者不会陌生，但现在它出现在一台Azure虚拟机里。
Python版本管理是隐性成本。pyenv解决了"本地3.9、服务器3.11、同事电脑3.8"的经典噩梦，让`python --version`输出稳定的3.13.12。Node侧同样，nvm确保Gemini CLI不会因为Node版本漂移而崩溃。
这种"双版本管理器"的配置，本质是在异构环境中人工制造一致性。云厂商不会帮你做这件事，因为每家都希望你用它的原生工具链。
开源Agent的边界：模型绑定 vs 平台自由
Gemini CLI的开放性有个微妙边界：它依赖Google的模型端点，但运行时不挑操作系统。这意味着你可以把它塞进任何能跑Node.js和Python的容器里——包括Azure的、AWS的、甚至本地机房的。
这种设计在战略上很Google：模型层锁定用户，工具层放任自流。对比之下，OpenAI的CLI工具更 tightly coupled（紧密耦合）在自己的生态里，Copilot（GitHub Copilot，代码辅助工具）更是深度嵌入VS Code。
对于开发者来说，这种"松散耦合"是双刃剑。好处是灵活，坏处是责任自负。Google不保证Gemini CLI在AKS上的性能，微软的AKS文档也不会提Google的Agent工具。中间的集成 gap（缺口）需要自己填。
ADK的部署验证之所以值得记录，是因为它证明了"模型能力"和"基础设施"可以解耦采购。CFO（首席财务官）谈Azure的企业折扣，CTO（首席技术官）用Gemini的推理能力，两边不必互相妥协。
这种解耦正在变成新常态。2025年的企业AI架构，大概率是"东拼西凑"的——谁家模型强用谁家，谁家云便宜用谁家，中间用开源工具缝合。
Google把Gemini CLI开源出来，可能没料到第一个出圈的用例是"跑在竞争对手的云上"。但这正是开源的宿命：你无法控制用户怎么用它，只能控制它好不好用。
AKS上的ADK验证通过之后，下一步是什么？是把这个最小可行部署扩展成多Agent协作系统，还是等Google官方出Azure集成方案，抑或微软直接"借鉴"一个竞品出来？
热门跟贴