CLI-Switch 2026年3月版历史设计：Hook、TTY 隔离与 JSON 状态

CLI-Switch 旧版复盘：我当时怎样让 Agent 调 Claude Code、Codex 和 Gemini CLI

我有一个执念：让 OpenClaw 里的 Agent 真正用好 Claude Code、Codex 和 Gemini CLI。

不是让它在聊天框里吐出 500 行代码，再等人复制粘贴；而是让它调用专业工具、创建文件、运行测试，失败后继续修。

为了解决这个问题，我写了 CLI-Switch。

先说明版本：这篇复盘的是 2026 年 3 月公开时的 CLI-Switch。后来的 v1.0 已经重构命令和执行方式，下面的 Hook、TTY 状态和旧别名只用于解释当时的设计，不是当前版使用教程。

为什么 CLI 天然适合 Agent

Unix 很早就把"一切皆文本流"当成重要接口。LLM 处理的也是文本和 Token。

这两套东西放在一起很自然：Agent 不需要理解复杂的图形界面，只要知道命令、参数、标准输出和退出码，就能调用大量成熟工具。

问题不在"Agent 会不会用 CLI"，而在它能不能稳定管理一个长时间运行的 CLI 任务。

聊天框里手写代码，问题很大

如果 Agent 只把代码输出成文本，后面仍然需要人完成一串动作：保存文件、检查目录、安装依赖、运行测试、定位报错、再把错误贴回去。

这不是真正的自动化。Agent 只是把"打字"接走了，工作流还断在中间。

更合理的方式是让它调用专门的代码工具。Claude Code、Codex 和 Gemini CLI 都能直接读写项目、运行命令并根据结果继续工作。

让 Agent 直接调 CLI，又会遇到新问题

我最先碰到的是"什么时候算完成"。

Agent 启动一个 CLI 任务后，如果没有明确的完成信号，只能不断询问状态。轮询几十次，不但浪费 Token，还会让多个 Agent 同时读写同一份状态文件。

于是会出现三类故障：

任务其实还在运行，Agent 却误判为失败；
任务早已结束，Agent 仍在重复轮询；
多个终端互相覆盖状态，A 的结果被 B 读走。

当时的 CLI-Switch 就是从这里长出来的。

2026 年 3 月版做了四件事

1. 统一切换工具和模型

不同 CLI 的配置位置和模型别名不一样。我把常用切换动作统一成一条命令。

bash 复制代码

cli-switch opus4.6
cli-switch --tool codex gpt-5.2-codex
cli-switch --tool gemini gemini-3.1-pro

这是 2026 年 3 月文章中的示例别名。模型列表会变化，实际使用时应先查看当前版本支持项，不要把旧别名写死在长期工作流里。

2. 用 Hook 等待真正完成

CLI 结束时由 Hook 写入完成状态，Agent 不需要不断问"好了吗"。

这件事看起来小，实际直接决定了自动化能不能稳定。没有完成信号，Agent 只能靠猜；有了完成信号，后续审查和交接才有可靠起点。

3. 按 TTY 隔离状态

每个终端使用独立状态文件，例如：

text 复制代码

Terminal 1 → ~/.local/state/cli-switch/tty-12345.json
Terminal 2 → ~/.local/state/cli-switch/tty-67890.json

这样 Bob 在一个终端写后端，May 在另一个终端处理内容时，不会因为共享状态文件互相覆盖。

4. 给 Agent 机器可读的 JSON

bash 复制代码

cli-switch --json status

返回类似：

json 复制代码

{
  "model_name": "opus4.6",
  "tool": "claude",
  "tty": "/dev/ttys001"
}

Agent 不必从一段给人看的说明里猜当前工具和模型。

当时我是怎么分工的

写核心代码时，我会让 Agent 调 Claude Code：

bash 复制代码

cli-switch opus4.6
claude -p "实现用户认证模块，包含登录、注册和 JWT 验证"

代码完成后，再交给 Codex 做独立审查：

bash 复制代码

cli-switch --tool codex gpt-5.2-codex
codex exec "审查安全性、性能和边界条件"

需要快速做前端原型时，再切到 Gemini CLI：

bash 复制代码

cli-switch --tool gemini gemini-3.1-pro
gemini -p "实现登录页面，使用 Tailwind CSS"

真正重要的不是这三个模型谁更强，而是生产和审查分开。写代码的 Agent 不应该给自己的结果签最终通过。

这版工具解决不了什么

当时这版 CLI-Switch 解决的是调用、等待和状态隔离，不负责替你设计权限。

如果 Agent 拿到了过大的文件权限、生产环境凭据或危险命令能力，它只会更高效地犯错。实际接入时仍要限制工作目录、命令范围和凭据可见性，关键变更必须有人或独立 reviewer 验收。

它也不会让一个错误的任务描述自动变正确。需求不清楚，专业 CLI 只会更快地产出偏离目标的代码。

为什么我愿意继续做它

我一直在用多 Agent 系统：有人统筹，有人写代码，有人做内容。最早限制它们的，不是模型不够聪明，而是工具链断裂。

CLI-Switch 的思路很朴素：别再发明一套只有 Agent 会用的新接口，把已经成熟的 CLI 交给它，再补上完成信号和并发隔离。

一个命令能说清楚的事，不要拆成十个互不相干的工具函数。

历史快照和当前版本

本文命令对应的历史快照：https://github.com/zhoutian1995/cli-switch/tree/943ac2f5fbe512ee74d136dbec921d6170525ede

当前版本与最新用法：https://github.com/zhoutian1995/cli-switch

如果你现在安装 CLI-Switch，请以当前 README 为准，不要照抄本文的旧命令。

如果你也在做 OpenClaw 或类似的 Agent 工作流，可以从一个最小任务开始：让 Agent 调用 CLI 写一个小功能，再由另一个工具审查。先把这条链跑通，再谈更多角色和更复杂的自动化。

本文来自「维天说」，全平台同名。

我会持续分享普通人能用上的 AI 工具、内容工作流和真实实践，欢迎联系我，一起交流 AI。