1. 为什么值得读 CLI 源码
读这类项目源码的意义，不只是为了“知道它用了哪些库”，而是为了理解一件事：一个命令行代理到底是怎么被组织起来的。 一旦你把这件事看懂，很多模型产品的表象都会被拆开，你会更快判断一个工具到底是包装层，还是一个真正有执行能力的系统。
2. Gemini CLI 其实有一个很清晰的主循环
从实现上看，Gemini CLI 的核心并不神秘，它本质上围绕一个循环展开：
- 读取配置、身份和当前工作目录。
- 把用户输入、上下文和可用工具整理成模型可消费的请求。
- 根据模型返回的意图去调用工具或执行命令。
- 把工具结果、命令输出、错误信息继续回灌给模型。
- 循环直到任务结束或被用户中断。
这一点很关键，因为它说明 CLI 不只是“把 prompt 发给模型”的壳，而是把模型放进一个不断接收反馈的执行系统里。
3. 配置层往往决定体验上限
很多人关注模型调用本身，但我更在意配置层。因为实际使用时，账号模式、provider 路由、命令权限、工作目录、历史上下文和默认模型， 才是决定一个 CLI 是否能长期稳定使用的关键因素。
这也是为什么我自己在做 OpenClaw 或多 CLI 统一接入时，会把配置和认证链路放在非常重要的位置。模型再强，如果配置层混乱、回退链断裂、 provider 不统一，整体体验一样会很差。
4. 工具调用不是附属能力，而是主舞台
模型负责判断，工具负责落地，反馈负责闭环。
Gemini CLI 这类系统最重要的能力之一是“让模型决定什么时候用工具”。当模型不只是输出一段建议，而是开始决定要不要列目录、 要不要读文件、要不要运行命令时，CLI 就从问答工具变成了执行代理。
这也是为什么 source reading 时要重点看工具层接口，而不是只看 prompt 模板。真正决定上限的，是工具边界是否清晰、错误处理是否可靠、 调用结果是否可以被继续消费。
5. 从 Gemini CLI 可以学到什么
如果你也在做自己的代理系统，我觉得 Gemini CLI 至少提供了几个明确启发：
- 不要把模型调用和工具调用写成两套互不相干的流程。
- 命令执行一定要和反馈收集绑定，不能只跑命令不回看结果。
- 配置、认证、默认值和可恢复能力，和模型能力本身同样重要。
- 一个好的 CLI 不追求“炫”，而追求操作路径短、可控、可复现。
6. 对我自己的启发
读 Gemini CLI 最大的收获，是更确定了一件事：未来很多 AI 编程产品的竞争，不会只发生在模型层，而会发生在“模型 + 工具 + 环境 + 路由”这一整套系统设计里。
所以我最近写 Gemini CLI、Codex、stdio、协议这几篇文章，本质上都在围绕一个问题打转： 如果我们已经接受模型可以参与工程流程，那么应该用什么样的结构把它接得更稳、更好用、更不容易断。