我特意花了幾天時間研究Gemini CLI的源碼，想搞明白谷歌這個開源項目到底有什么不同。看完之后，發現確實有些門道。

說實話，剛開始我以為就是另一個命令行AI工具，畢竟OpenAI的Codex CLI、Anthropic的Claude Code都有類似功能。但深入看了源碼架構后，才意識到谷歌在下一盤很大的棋。

今天我們就來拆解一下Gemini CLI的架構設計，看看谷歌工程師是怎么思考這個問題的。

雙包架構：分離關注點的設計智慧

打開Gemini CLI的源碼，最顯眼的就是它的雙包架構設計。整個項目被分成了兩個核心包：

CLI Package + Core Package = 完整的Gemini CLI

這種設計乍一看很普通，但仔細想想，這其實解決了傳統AI工具的一個根本問題：耦合度過高。

CLI包專注用戶體驗：處理輸入輸出、管理歷史記錄、主題定制、界面渲染。它就像一個精心設計的"前臺接待員"，負責與用戶打交道。

Core包則是幕后大腦：API通信、工具調度、狀態管理、會話控制。它像一個"項目經理"，協調各種資源來完成任務。

我查了下其他AI工具的架構，大多數都是單體設計。而Gemini CLI這種分離，意味著什么？

想象一下，如果你要做一個Web版本的Gemini CLI，只需要重寫CLI包，Core包完全不用動?；蛘咭銎髽I定制，可以保持Core不變，只修改CLI的界面和交互邏輯。

工具系統：可擴展性的終極體現

更讓我印象深刻的是Gemini CLI的工具系統設計。它不是簡單地硬編碼幾個功能，而是構建了一個完整的工具生態。

從源碼可以看到，工具系統是完全模塊化的設計：

? read-file.ts - 負責文件讀取操作

? write-file.ts - 處理文件寫入功能

? shell.ts - 執行Shell命令

? web-fetch.ts - 獲取Web內容

? web-search.ts - 進行網頁搜索

? mcp-client.ts - MCP協議客戶端

? tool-registry.ts - 統一的工具注冊管理

每個工具都是獨立的模塊，有自己的功能聲明、參數定義、執行邏輯。這種設計讓我想起了現代微服務架構的理念。

特別是MCP（Model Context Protocol）的集成，這可能是Gemini CLI最有野心的部分。

MCP協議：連接外部世界的橋梁

Model Context Protocol是Anthropic推出的標準協議，本質上是讓AI模型能夠標準化地連接外部系統。

我仔細研究了Gemini CLI的MCP客戶端實現，發現谷歌在這個協議上做了不少功夫。從源碼來看，它支持三種連接方式：

? Stdio傳輸 - 通過標準輸入輸出與本地MCP服務器通信

? SSE傳輸 - 通過Server-Sent Events連接遠程服務

? HTTP傳輸 - 支持流式HTTP協議

這意味著什么？Gemini CLI可以連接到任何實現了MCP協議的服務，無論是本地的數據庫、遠程的API，還是企業內部的系統。

這不再是一個簡單的AI聊天工具，而是一個可以連接整個數字世界的AI代理平臺。

安全機制：谷歌式的謹慎設計

作為谷歌的產品，安全性當然是重中之重。我注意到Gemini CLI在工具執行上有一套完整的確認機制。

從架構文檔可以看到，任何可能修改文件系統或執行系統命令的操作，都需要用戶明確確認。而只讀操作（比如讀取文件）則可以直接執行。

更有意思的是，它還支持多層沙箱機制：

? macOS Seatbelt沙箱 - 限制寫入項目文件夾外的操作

? Docker/Podman容器 - 完全隔離的運行環境

? 代理網絡流量 - 所有網絡請求都可以通過代理檢查

這種多層防護思路，體現了谷歌對企業級應用的理解。

與傳統IDE插件的根本性差異

用了幾天Gemini CLI之后，我發現它與傳統的IDE插件模式有本質區別。

傳統的AI插件通常是"被動響應"模式：你問一個問題，它給一個答案。但Gemini CLI是"主動協作"模式：它可以主動調用工具、執行命令、修改文件，然后基于結果繼續思考和行動。

從代碼架構上看，這種差異體現在多輪對話管理和工具鏈調度上。Gemini CLI的Core包實現了完整的對話狀態機，可以在一次交互中執行多個工具，形成復雜的工作流。

技術哲學：開放性與標準化并重

研究完整個架構，我覺得Gemini CLI體現了谷歌的一個技術哲學：通過開放和標準化來建立生態優勢。

開源Apache 2.0許可證、支持MCP標準協議、模塊化的工具系統、分離的架構設計，這些都指向一個目標：讓更多開發者能夠參與和擴展這個平臺。

對比OpenAI和Anthropic的相對封閉路線，谷歌這種開放策略挺有意思的。它似乎不是想壟斷AI工具市場，而是想制定游戲規則。

控制標準，比控制產品更重要。

未來想象空間

基于這個架構設計，我能想象到一些有趣的可能性：

企業可以開發自定義的MCP服務器，讓Gemini CLI直接訪問內部系統。開發者可以構建專門的工具包，然后通過MCP協議分享給社區。甚至可能出現"AI工具商店"，各種專業能力通過標準化接口接入。

這種擴展性，讓Gemini CLI不只是一個工具，更像是一個平臺基礎設施。

一些思考

當然，這種復雜的架構也帶來了一些問題。學習成本比較高，部署配置也相對繁瑣。對于只想要簡單AI助手的用戶來說，可能會覺得過于復雜。

但從長遠看，這種設計思路可能更符合AI工具的發展趨勢。隨著AI能力越來越強，我們需要的不再是單一功能的工具，而是能夠連接和整合各種資源的智能平臺。

谷歌這一步，走得還挺有前瞻性的。