Google把AI Agent開源后，3天被微軟云"截胡"了

一個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集成方案，抑或微軟直接"借鑒"一個競品出來？