同一个模型，装在聊天框里和装在命令行里，能干的事差一个数量级。 差别不在模型，在于它能不能自己读、自己改、自己跑。 这是整条线的第一块地基——后面每一篇都建立在「闭环在机器这边」之上。
本文写什么三种能力各自意味着什么、代价是什么、什么时候不该用。 本文不写我们自己拿它干什么、跑在哪台机器上。示例一律用通用占位。
把一个模型接上工具之后，它多出三种能力。前两种听起来更厉害，其实第三种才是质变。
| 能力 | 它能做什么 | 没有它会怎样 |
|---|---|---|
| 读 | 自己去翻你磁盘上的文件、目录、日志 | 你得手工复制粘贴，粘多少它知道多少 |
| 改 | 直接写回文件 | 它给你一段代码，你负责搬运和对齐 |
| 跑 | 执行命令，并且看见输出 | 它永远不知道自己写的东西对不对 |
前两种省的是你的手。第三种改变的是谁在验证。
聊天框里，验证这一步永远由你完成：它给代码，你去跑，报错了你把错误贴回去。 每一轮都要过你这道人肉转运。能跑命令之后，这个循环整个搬到机器那边—— 它写完自己跑，报错自己读，改完再跑一遍。你从转运工变成了验收员。
一个能自己跑、能看见报错的中等模型，在真实工程任务上常常打得过一个只能空想的更强模型。 因为编程这件事的大部分难度不在「想出正确答案」，而在「发现自己错了」—— 而发现自己错了需要反馈，反馈需要执行。
所以选工具时，「能不能跑、跑完能不能看见输出」这一条，权重高于模型档次。
这三种能力是一个包，不能只要前两个。而「能跑命令」的另一面是—— 它拥有的权限，等于你给它的那个 shell 的权限。
这不是理论风险。一个把 rm 用错路径的命令，
和一个把 .env 读进上下文再发出去的命令，
在工具层面看起来是一样的：都只是「跑了个命令」。
正经的 CLI agent 都带三层闸：允许（这类命令直接放行）· 询问（每次问你一遍）· 拒绝（永远不许）。 装好第一件事就是把它配上，而不是等踩了再说。
不要把这条当成「CLI 全面胜出」。有三种情况聊天框更合适：
| 情况 | 为什么 |
|---|---|
| 你在想，还没到做 | 构思阶段没有文件可读、没有命令可跑，三种能力一种都用不上 |
| 代码不能出你的机器以外的地方，而你还没搞清数据流向 | 先把数据边界弄明白再上工具，顺序不能反 |
| 一次性小问题 | 装配置授权的成本高于问题本身 |
判据很简单：这件事需不需要「跑一下看看」？需要就上 CLI，不需要就聊天框。
四个阶段，每一阶都建立在前一阶之上：
| 阶 | 解决的问题 |
|---|---|
| 一 · 本地 | 让它能改你的代码（第 1–5 篇） |
| 二 · 接入层 | 账号、额度、中转——让这套东西不因为一个账号没了就断掉（第 6–9 篇） |
| 三 · 常驻 | 从「我敲一句」到「它自己跑」（第 10–16 篇） |
| 四 · 上云 | 搬到一台不关机的机器上（第 17–22 篇） |
中间有一根主心骨贯穿始终：一个叫 base_url 的旋钮。
第 7 篇把它讲透，之后每换一个工具都是同一个旋钮换个地方拧。
openai/codex：Rust，110,216 ★，最新 release rust-v0.149.0（2026-08-20）。
数字取自 GitHub API，2026-08-21 核。