最近不少模型厂商都亲自下场做代码 agent，4 月份 anthropic 推出了 Claude Code，5 月份 openai 开源了 Codex，6 月 Mistral 发布基于 Continue 的 Mistral Code，昨天 Google 又开源了个新的 Gemini CLI，我很好奇为什么成了当下热点，所以找时间研究了一下。
为什么这些工具扎堆出现？我猜是眼红 Cursor 的成功，毕竟它是当前大语言模型唯一赚大钱的应用，能分一点羹也不错，但完整实现 Cursor 工作量太大，所以通过这种简单的 CLI 形式可以快速实现 Cursor 里的核心功能之一：agent。
Gemini CLI 作为后来者，它采用了最朴实无华的抢用户方法：免费，每天可以免费调用 1000 次，对绝大多数人来说这完全足够了。
Gemini CLI 这类工具能干什么呢？你可以用它来开发或修改代码，比如我经常用的功能是将老旧的 JavaScript 代码转成 TypeScript，虽然不完全准确，但可以节省点体力。
同样用 Gemini 试了一下，能执行但大量偷懒，经常用 any 类型，比如：
// gemini 生成的效果
export default class AATMorxProcessor {
font: any;
morx: any;
inputCache: any;
subtable: any;
glyphs: any[];
ligatureStack: any[];
markedGlyph: any;
firstGlyph: any;
lastGlyph: any;
markedIndex: any;
相比之下 Cursor 如果不满意可以选择一部分区域让它修复，能得到稍微好点的效果，比如：
// cursor 生成的效果
export default class AATMorxProcessor {
font: Font;
morx: MorxTable;
inputCache: { [gid: number]: number[][] } | null;
subtable: MorxSubtable | null;
glyphs: Glyph[];
ligatureStack: number[];
markedGlyph: number | null;
firstGlyph: number | null;
lastGlyph: number | null;
markedIndex: number | null;
所以整体来看 Gemini 和之前的工具差异不大，主要优点是能免费用。
源码分析
想要了解一个项目最好的办法是看源码，值得注意的是从 Claude Code 开始这些工具都没有基于 AI 领域最常见的 Python 实现，而都是用 TypeScript 实现，甚至 Codex 后来还改成了 Rust，我猜原因是可以方便转成 VSCode 插件，比如比较早的开源项目 Continue 就是用 TypeScript 实现的，而且这类 agent 工具对大模型的调用都是外部接口，无需使用 PyTorch 来加载本地模型，所以 Python 没什么特别优势。
整个 Gemini CLI 项目有 4.7 万行 TypeScript 代码，虽然看起来多，但有一半以上是单元测试，agent 核心代码只有 1.4 万行，可以很快看完，所以我快速翻了一遍所有代码。
执行过程是首先收集当前环境信息，构造类似下面的提示词
Okay, just setting up the context for our chat.
Today is Thursday, 26 June 2025.
My operating system is: darwin
I'm currently working in the directory: /Users/nwind/working/research/gemini-cli
Showing up to 200 items (files + folders). Folders or files indicated with ... contain more items not shown, were ignored, or the display limit (200 items) was reached.
/Users/nwind/working/research/gemini-cli/
├───.gitattributes
├───.gitignore
├───.npmrc
这里包括了系统信息及当前目录下的文件。
接下来构建调用时的工具列表，目前 Gemini 能调用的工具有：
MCP 工具，可以配置 MCP Server 然后调用符合 MCP 规范的外部工具。
文件系统相关的，包括列举目录、读取文件、写文件、重命名、使用 glob 或根据内容查找文件等。
Shell 命令，用于执行命令行命令。
页面抓取，就是调用 fetch 功能获取页面内容，也用到了 Gemini 内部特有工具 urlContext。
网页搜索，调用 Gemini 内部自带的 googleSearch 实现。
构建好之后调用 Gemini，然后根据返回执行操作，如果返回读取工具就读取文件，从实现上看简单来说就是个多轮 Chat 对话，只不过多了本地工具调用，模型可以通过调用本地工具执行一些操作。
比如下面是一个对话示例，用户提出问题，模型要求调用 list_directory 工具列出目录，然后就执行这个工具
{
"role": "user",
"parts": [
{
"text": "解释一下 packages/core 里的代码是做什么的"
}
]
},
{
"role": "model",
"parts": [
{
"functionCall": {
"name": "list_directory",
"args": {
"path": "/Users/nwind/working/research/gemini-cli/packages/core/src"
}
}
}
]
},
{
"role": "user",
"parts": [
{
"functionResponse": {
"id": "list_directory-1750928648900-26c39657dd40c",
"name": "list_directory",
"response": {
"output": "Directory listing for /Users/nwind/working/research/gemini-cli/packages/core/src:\n[DIR] __mocks__\n[DIR] code_assist\n[DIR] config\n[DIR] core\n[DIR] services\n[DIR] telemetry\n[DIR] tools\n[DIR] utils\nindex.test.ts\nindex.ts"
}
}
}
]
}
所有功能都在一个上下文窗口里完成，没有 DAG 之类的任务规划机制，所以哪怕是要改 100 个文件，所有修改的代码也都放在这个上下文窗口里，因此要求模型必须有巨大的上下文窗口，对推理服务有极高要求，需要缓存之前的上下文，不然每次请求都要算一遍提示词，今天用的时候经常报错，可能是用的人多，连 Google 的服务都撑不住。
未来前景判断
分析完源码后来说一下我个人对它前景的判断，有以下几点：
我不看好 CLI 这种形态，虽然 CLI 可以很方便地用在服务器上，但 CLI 太原始了，对于修改非常不方便，比如想修改某个文件里的某段代码，在 Cursor 上可以直接框选一段区域然后提问，而用 CLI 就得写清楚文件路径和代码行号，所以我更看好 Cursor 这种带界面的形式，GUI 做得好了就是降维打击，十几年前那些年我认识的 Vim/Emacs 死忠都无一例外转 VSCode 了，当你体验过鼠标浮上去就能操作的便捷后，你就再也回不去了。
虽然开源，但预计以后只会支持 Gemini 模型，开源只是吸引眼球的手段，目前这个项目没有使用 OpenAI 兼容接口，而是大量使用 @google/genai 库里提供的方法，包括网页搜索等功能，导致很难改造支持其它模型，虽然官方没明确否定，但我认为这个项目以后不会支持其它模型，因为实现原理非常依赖 Gemini 一百万上下文窗口，其它模型还做不到，目前这些开源代码对其它人来说其实没啥用，就是能让你看看一个专业工程团队写出来的代码是什么样的，尤其是完善的单元测试和文档。
专用 agent 更有前途，通用 Agent 工具两年前 AutoGPT 就实现过了，现在和两年前比，当前流行的 Code Agent 更像是个专门针对代码的低配版 AutoGPT，大概只要 AutoGPT 删减一下，限制调用工具范围就能实现差不多的效果，那为什么 AutoGPT 现在没人谈了，反倒是这种专用 agent 又火了？我想是因为大模型的准确率不高，这种专用 agent 可以针对性优化成功率，效果更好点。