先把主流 CLI Agent 谱系放在一张图上
最典型的终端 agentic coding 壳层之一，强项是工作流完成度高，适合把“终端就是主战场”这件事吃透。
OpenAI 的编程代理入口，更适合放在“OpenAI 自家模型与平台能力如何往 coding agent 收口”这条线上看。
Qwen 官方开源终端 agent，关键价值不是“国产替代”四个字，而是它把 agent 壳层本身开源了。
更偏开源终端壳层路线，适合看 TUI、本地/远程 client 和 provider-agnostic 接入，而不只是“替代谁”。
Google 这条线的终端入口，适合放在“官方模型生态如何进入 terminal workflow”这条线上看。
更值得关注的是官方文档里对 Codex CLI 的适配，而不是硬找一个并不稳定的独立 CLI 品牌名。
它们都和终端 agent 有交集，但更适合归到“终端相邻工作台”而不是纯 CLI 主战壳层。
主流谱系，不只是四件主货
Claude Code
如果你想看“终端里的 agentic coding 完整工作流”是什么感觉，它依然是最重要的参考对象之一。它的价值不只是补全和问答，而是把计划、执行、工具调用和会话控制放进了同一套终端体验里。
- 适合把终端当主界面的人
- 也适合和本站源码课主线互相映照
Codex
看 Codex 时不要只盯着“能不能在终端里跑”，而要看 OpenAI 怎么把编程代理这件事和自家平台、身份体系、模型路线连接起来。它更像产品线收口，而不只是单点工具。
- 适合本来就深用 OpenAI 生态的人
- 也适合观察 Web / IDE / CLI 是否会继续收敛
Qwen Code
Qwen Code 最值得看的地方，是它把终端 agent 做成了 官方开源仓库。官方 README 已经把它描述成 living in your terminal 的 open-source AI agent，并给出 npm install -g @qwen-code/qwen-code 的安装方式。
- 适合想自己研究 agent 壳层的人
- 也适合做本地改造、二次分发和路由接入
MiniMax 的 CLI 观察点
截至 2026-04-11，我更愿意把 MiniMax 归到“模型接入终端 agent”这一路，而不是直接把它写成一个独立成熟 CLI 品牌。官方文档里已经有 Codex CLI 适配说明，但同时也明确提示：最新版 Codex CLI 存在兼容性问题。
- 适合想用 MiniMax 模型接入现有 coding agent 的人
- 暂时不建议把它当成已成熟独立 CLI 生态来理解
OpenCode
OpenCode 值得单列，是因为它不是单纯补一个名字，而是把 TUI-first shell、远程 attach、provider-agnostic 接入和开源 client/server 体验拉成了完整路线。
- 适合研究终端原生交互壳怎么做
- 也适合拿来对照官方产品壳和开源替代壳的边界
Gemini CLI
Gemini CLI 更适合放在“Google 模型与开发者工作流如何进入 terminal”这条线上看。对比价值不只是谁能写代码，而是谁把终端接进了自家模型与平台体系。
- 适合本来就在 Google / Gemini 生态里的人
- 也适合和 Codex、Claude Code 对照看平台型入口差异
Repo-backed 补充：CLI Agent 其实至少有三种壳
如果把所有终端 agent 都放进一个篮子里，很容易误判它们到底在解决什么问题。结合 reference/ 里的样本，更稳妥的教法是先分壳层。
| 壳层类型 | 代表样本 | 它主要解决什么 | 该怎么看 |
|---|---|---|---|
| workflow-complete terminal shell | Claude Code / Codex / Qwen Code / MiniMax 接入路线 | 把计划、执行、工具调用、模型接入和终端工作流压进一个主入口 | 适合把终端当主界面来用，重点看 workflow 完整度与生态收口 |
| TUI-first open shell | reference/reference_agent/reference_control-agent-cli/anomalyco-opencode/ |
把 terminal UI、本地/远程 client、provider-agnostic 接入、内置 agent 模式做成更偏终端原生的交互壳 | 适合研究开源壳层、交互设计和 client/server 终端体验，而不只是“能不能写代码” |
| artifact-control CLI | reference/reference_agent/reference_control-agent-cli/OfficeCLI/ |
让 agent 直接控制 Word / Excel / PowerPoint 这类文档产物，而不是只管代码仓库 | 适合把它看成 document control plane，不该再混回 generic coding shell |
所以这页后面再扩时，重点不是只把名字越列越多，而是先判断你要选的是哪一类终端壳：主战 CLI、开源终端壳、文档控制 CLI，还是终端相邻工作台。
站内实验线：Everything Agent-CLI to Claude Code
如果前面的内容是在回答“CLI Agent 有哪些路线”，那这个仓库回答的是另一个更工程化的问题：怎么把网页登录 + 官方 CLI 才能用的能力重新接回 Claude Code / LikeCode 主工作流。
everything-agent-cli-to-claude-code
这个仓库把 Claude Code / LikeCode 当成 control plane，把 `codex`、`gemini`、`qwen`、`grok` 等官方 CLI 当成外部 worker，用统一的 `usecli:*` 命名和 workflow 规范把它们编排回同一个 coding loop。
- 适合想做多模型 CLI 编排的人
- 仓库里已经附带 `tests/test_wrappers.sh` 这类本地 smoke test，不只是概念说明
- 它现在也有一条更完整的 family verification 入口：
tests/test_plugin_family.sh会顺序检查同一projects/根目录下的 `*-plugin-cc` 家族 smoke test - 它现在也有一条很短的 runnable proof：先跑 `tests/test_wrappers.sh`，再看 `docs/workflows/multi-model-review.md`，有本地 CLI 时还能直接跑 workflow 示例
- 也适合观察 `gemini-plugin-cc`、`qwen-plugin-cc`、`grok-plugin-cc` 到 `cursor/qoder/trae-plugin-cc` 这一整条插件家族怎么拆
- 适合把它当 umbrella control tower 来看：统一命名、workflow 和 wrapper 留在总仓库，provider 细节下沉到各自 `*-plugin-cc`
- 如果你卡在“这段能力该留在总仓库还是拆子仓库”，现在可以直接先看
docs/repo-strategy.md - 站内本地路径：
projects/everything-agent-cli-to-claude-code/
相比“再多装一个终端工具”，这条实验线更值得看的地方是：它试图把被登录态和 CLI 壳隔离的模型能力，重新恢复成 可调度、可验证、可复用 的工作流组件。
别混淆：有些产品和 CLI Agent 有关，但不该直接当成纯 CLI
| 路线 | 代表样本 | 为什么会被误放进 CLI Agent | 更准确的归类 |
|---|---|---|---|
| terminal-adjacent IDE | Cursor | 它有 terminal、agent、命令执行和工作流自动化，因此经常被口头叫成“Cursor CLI” | 更适合归到 AI IDE / 编辑器工作台，而不是纯 CLI 主战壳 |
| coding studio / workspace | Qoder | 它有 agentic 编程和研发空间属性，很多人会把整个平台误缩写成一个 CLI | 更像研发空间或 agent 工作台 |
| AI IDE with agent mode | Trae | 它和 Solo、编辑器、Agent 模式经常一起出现，容易在讨论里被压扁成单个 CLI | 更适合归到 AI IDE / agent 工作台路线 |
这也是为什么你在做选型时，不该只问“有没有 CLI”。更该问的是：你要的是主战终端、终端旁路、还是编辑器工作台。
把工具放成一面墙，悬停时看谁和谁是一路人
鼠标放上去时，当前工具会抬起来；和它共享同一路线标签的工具会一起凸显，其他卡片会轻微退后。这样读者一眼就能看出谁是终端主战派、谁更偏平台生态、谁更适合拿来做模型接入。
Claude Code
终端工作流完成度高，适合把 agent 当主界面来用。
Codex
更适合放进 OpenAI 平台路线里看，不只是一个终端壳。
Gemini CLI
Google 模型路线进入 terminal workflow 的代表，更适合放在平台入口线上看。
Qwen Code
官方开源终端 agent，适合研究壳层和做二次改造。
MiniMax 路线
更适合当模型接入方案看，重点是接进现有 coding agent。
OpenCode
开源 TUI-first shell，适合拿来看终端原生壳层和 provider-agnostic 路线。
Aider
经典开源终端 coding assistant，适合对照看 agent 壳层演进。
Cursor
更偏编辑器工作台，适合和 CLI Agent 做边界对比。
Qoder
更偏研发空间与 agent 工作台，不宜被压扁成单个 CLI 名字来理解。
Trae
AI IDE 与 agent 模式耦合得更紧，适合和 Cursor、Qoder 放一组看工作台形态。
GitHub Copilot
IDE 原生感更强，适合拿来对比“编辑器内嵌”和“终端代理”的差别。
OpenRouter
不是 agent 壳本身，但常常是把多家模型接进工具链的那层路由。
Repo-backed 再补一层：CLI Agent 的 approval surface 也不一样
只分壳层还不够，因为很多 CLI agent 真正让人卡住的，不是“能不能进终端”，而是它到底让你批准什么。
| approval surface | 代表样本 | 真正被批准的对象 | 选型时该怎么看 |
|---|---|---|---|
| action approval | reference/reference_agent/reference_control-agent-cli/opencode/README.md + internal/permission/permission.go |
单次 tool action，或当前 session 的持续放行 | 适合重视即时操作流畅度的人，但要分清它批准的是动作，不是整个工作区都“安全了” |
| artifact review | reference/reference_agent/reference_control-agent-cli/OfficeCLI/SKILL.md |
文稿修改提案，先 mark 再 review / apply |
适合文档、表格、演示文稿这类产物控制场景；重点不是快，而是先审再落盘 |
| dangerous-command gate | reference/reference_agent/hermes-agent/hermes_cli/main.py |
危险命令执行；默认要过 prompt，只有显式 --yolo 才整体绕过 |
适合把它当风险姿态来理解，而不是把 --yolo 当普通 convenience flag |
所以 CLI Agent 不只是“产品壳 / 开源壳 / 文档壳”的差别，还要看 approval model：
- 如果你主要想降低日常 tool 调用摩擦，优先看 action approval 做得是否清楚。
- 如果你主要在改文档、表格、演示稿，优先看 artifact review 是否独立存在。
- 如果某个工具把全局绕过 approval 当卖点，那更像风险开关，不该被包装成普通工作流体验。
这样看，Claude Code / Codex / Qwen Code / MiniMax 接入路线 这条主战线之外，OpenCode / OfficeCLI / Hermes Agent 更像是在补三种不同的 approval surface，而不是只是在补“更多名字”。
如果你是来选工具，不是来考古
想体验最完整的终端工作流：先看 Claude Code。
想跟 OpenAI 平台能力保持一致：看 Codex。
想研究开源终端 agent 壳层：看 Qwen Code。
想把 MiniMax 模型接进现有 coding agent：看 MiniMax 的 Codex CLI 适配文档，而不是先去找一个未必稳定的“MiniMax CLI”。
主来源
Anthropic · Claude Code ↗ · OpenAI · Codex ↗ · QwenLM/qwen-code ↗ · MiniMax API Docs · Codex CLI ↗