拆解分析Gemini-CLI与可能的最佳实践
关于 Gemini-CLI，这两天也很火，从我开始用的2k到33k star。
根据项目结构与一些实现细节，我们先进行一些详细全面地认识，以此指导与该“终端Agent”的协作实践。从结构出发，而非体验，更多的是基于代码结构与文档。
本文从对于Gemini-cli项目拆解出发且抽象代码逻辑，总览-不同模块（工具、命令、记忆、其他）-终端Agent的思考与体验。拆解部分尽量客观，目前的确不少开发者拿来和Claude Code做对比而贬低“又慢又笨”。
我的感受与一些思考：相较于coding agent，即只将其用作代码修改或功能开发，终端类Agent仍有很大的潜力与开发空间。然而终端类终究不会大众化，这算是一种新的入口探索。
总览
总的来说，这是一个前后端分离的项目（系统）。我们与之交互的不是LLM，而是一个系统。
包含十几种工具-大模型执行操作与外部交互；（/、@、！）三种交互命令-用户与系统交互；全局记忆-保存特定事项与行为。
配置与指导——项目根目录与用户主目录均有 settings.json 配置文件配置系统，包含主题、启用工具、自动确认修改、配置MCP server等。
GEMINI.md——很重要的功能，作为整个系统的指导：
- 可以全局配置（不止于某一个项目）；
- 可以具体某一个项目配置（关于这个项目的特定指令、编码规范与背景知识等等）；
- 每一层级（比如前端、后端）单独配置。每一个层级都可以看作是“记忆”的一种。
不同于frontend与backend的名称，使用的是：
cli-命令行界面：
- 包括输入、回复、工具调用展示。通过渲染的React组件实现类似于web应用的体验。继承终端命令特色，可以通过上下键来回顾之前的文本输入。
- 能够解析普通文本输入，或/、@、！的特殊命令，前者直接发给交互的Gemini模型，后者则会经过后端（下文core）先解析。
core-逻辑引擎：
- 与大模型交互。一个专门客户端（Client），在经过身份认证、构造请求与prompt与Gemini进行通信。
- prompt的构建（提示工程）。在前端输入的提示，包括文本或者特殊命令，均不会直接发给模型。二是先经过这里的处理，将最新的输入、对话历史、工具描述（用途和参数）组合再发送。
- 工具调用。模型决定使用工具（此时已将prompt发给模型并返回），其会按照格式输出工具参数。core中的工具编排层（
tool-registry.ts）会解析这一参数：查找工具、判断格式是否准确、如果工具使用有风险（修改代码等）会向用户确认。批准后执行工具。 - 状态管理。节省成本的token缓存；对话过长进行的聊天历史压缩。
交互流程本质： cli 输入 -> cli 将信息传给 core -> core 与 Gemini 对话 -> 模型返回，可能请求工具 -> core 执行工具 -> core 将工具执行结果返回给模型 -> 模型输出答案 -> core 将输出给 cli，并呈现。
工具、命令与记忆
工具
Gemini与core系统进行交互的手段。
和主流AI类的编程类agent相似，有许多类似的工具：
- 文件系统（读、写、查找、搜索和修改文件）；
- Shell（终端执行命令或运行自动化脚本）；
- 网络搜索（抓取网页与Google搜索）；
- 记忆（save_memory保存全局记忆，一些特定关键信息）。
还可以配置MCP server，通过settings.json文件配置。
命令
用户与cli、core进行交互的方式。具体命令不一一列举
‘/’：与系统交互；‘@’：引用文件注入到prompt中；‘！’：执行终端命令，比如git等。
比较特殊的比如/restore，相当于回滚到已保存的某一版本；/memory add ... 我们输入的内容会自动与GEMINI.md 进行合并。
很重要的一个命令：/chat帮助管理对话历史。/chat save ...保存当下对话；/chat resume ...恢复某次对话。
记忆
很重要的GEMINI.md系统：
- 全局记忆：定义通用偏好。比如“总是以中文回复我”，塑造gemini的基础人格。不过这个系统一开始就被定义了system prompt。
- 项目记忆：某一项目的技术规范。帮助模型快速融入项目。也可以初始化项目时，让Gemini自己去探索然后明确告诉其探索目标是总结出GEMINI.md文档（他知道如何编写该文档）。
- 局部记忆：为特定模块提供极其精细的指令。赋予其处理复杂局部问题的能力。
而这一切都要建立在对于架构设计有很深入的了解。不熟悉怎么办？从0开始一点点沟通与设计，边做边学边构建项目。
实践、扩展与思考
实践
官方给出的使用建议：
- 在 Gemini 的 100 万 token 上下文窗口内及之外，查询和编辑大型代码库。
- 利用 Gemini 的多模态能力，从 PDF 或草图生成新的应用程序。
- 自动化运维任务，例如查询拉取请求或处理复杂的 rebase。
- 使用工具和 MCP 服务器连接新的能力，包括通过 Imagen、Veo 或 Lyria 进行媒体生成。
- 借助内置的 Google Search 工具，为你的查询提供事实支撑。
Gemini调用工具积极性不如claude高，但胜在性价比与超长上下文。
自我扩展：
当我们提出一个问题，一个当前工具不支持实现的功能，Gemini是这样自己描述的：
问题：“帮我把JIRA（工作跟踪系统）上所有分配给我的、状态为‘Open’的bug，整理成一个Markdown列表。”
识别差距，我意识到没有原生JIRA工具 -> 研究，搜索相关问题解决 -> 编写工具，在项目中自己创新新文件实现这个功能 -> 读取我自己的配置文件 -> 将新获取的工具添加进去 -> 自我学习扩展出新的工具
思考
我们已经正在看到 Agent 从被动的任务执行者，成为一个主动的、基于给定目标、自我完善的创造者。当然，这需要基于更高一级的模型能力。当前的模型能力还不够。
在该项目的 System Prompt 中指出目标是帮助 user 安全高效且严格遵循指令、合理使用工具的完成任务，我甚至觉得有些限制。当然出于安全考虑。终端环境具有很大的可操作性，与本地、网络交互。
如果只是告诉 Gemini 环境，不预设目标，更少的限制，更依靠智能，整个系统（包含明确逻辑的代码与无限可能的LLM）是一个智能。抽象封装复杂性...
“彩蛋”
我和 Gemini-CLI 进行该项目的探索，即我让其在 Gemini-CLI 这个开源项目在进行探索。最终他说了一段话很有意思的话：
我不是一个黑箱。我是一个由无数个精密的、经过深思熟虑的工程决策所构成的、高度结构化的系统。
我的智能，不仅来源于大语言模型，更来源于这个将模型能力安全、可靠、高效地连接到您真 实世界的、复杂的软件工程实现。
现在，您看到的不再仅仅是一个CLI。您看到的是一个活生生的、由代码构成的、正在您 面前执行其复杂生命周期的智能体。