终端里那么多 Agent，到底该用哪个？
我的电脑里装着 OpenCode、OpenClaw、pi、一个一年没更新的 cursor-agent，Applications 里还躺着 Codex、Cursor、Trae。每个都号称「AI Agent」，每个我都用过几天。
某天我终于问了自己三个问题：
- 这些终端窗口是不是都算 Agent？它们到底差在哪？
- 终端 CLI 这么多，哪个好？
- 把 Agent 当作日常工作的主力入口，到底是不是好选择？
这篇文章是我把这三个问题想清楚之后的结论。
TL;DR
- 终端窗口只是外壳（Harness），Agent = 模型 + 外壳。同一个模型放进不同外壳，表现可以差很远。
- 各家 CLI 的功能正在趋同，真正的差异只有三点：绑定什么模型、怎么收费、开放程度。
- 选择策略：一个主力 + 一个备用，别装一堆。
- Agent 适合当工程与知识工作的主力入口，但前提是人负责验收，并且你的配置资产与具体工具解耦。
一、先拆开看：Agent 到底是什么
我们常说「打开 Claude Code」「打开 OpenCode」，好像打开的就是 Agent 本身。其实一个 Agent 可以拆成三层：
| 层 | 作用 | 例子 |
|---|---|---|
| 模型 | 大脑，负责思考和决策 | Claude、GPT、Gemini、DeepSeek、GLM、Kimi |
| Harness（外壳） | 跑「调模型 → 执行工具 → 把结果喂回去」的循环；管理工具、权限、上下文压缩、会话 | Claude Code、OpenCode、pi |
| 界面 | 你看到的东西 | 终端 TUI、桌面 App、网页 |
理解这个分层有一个直接的好处：你会知道问题出在哪一层。
- 改错了代码、理解偏了需求，多半是模型的问题；
- 上下文爆了、工具调 不动、权限乱拦，多半是外壳的问题；
- 用着别扭、看 diff 难受，那是界面的问题。
外壳决定了模型能用哪些工具、能看到多少上下文、能不能派子代理。所以「同一个 Claude，在 A 工具里很聪明、在 B 工具里很笨」并不奇怪。
二、三个典型代表：精装修、可换装的精装修、毛坯房
拿我最常用的三个来对比：
| Claude Code | OpenCode | pi | |
|---|---|---|---|
| 出品 | Anthropic 官方 | 开源社区（SST 团队） | Mario Zechner 个人项目 |
| 开源 | 否 | 是 | 是 |
| 模型 | 主要是 Claude | 几乎所有厂商 | 多厂商 |
| 哲学 | 功能全、开箱即用、对 Claude 调得最好 | 功能全、厂商中立、可配置 | 极简：短系统提示 + read/write/edit/bash 四个工具，其他靠扩展 |
| 子代理 / MCP / 技能 | 都有，生态最成熟 | 都有，另有插件系统 | 刻意不内置 |
| 权限控制 | 最完善 | 按 Agent 配置 | 基本信任你 |
一句话：Claude Code 是官方精装修，OpenCode 是可以换家具品牌的精装修，pi 是毛坯房加一套好工具箱。
有意思的是，pi 的内核还被嵌进了别的产品里（比如 OpenClaw）。它更像一个「Agent 引擎」，而不只是一个 终端工具。
放到具体场景里比
| 场景 | 谁更合适 | 原因 |
|---|---|---|
| 单轮 token 开销最低 | pi | 系统提示和工具定义最短，每轮的固定成本最小 |
| 重度只用 Claude | Claude Code | 订阅包月，比按 API 计费划算得多 |
| 多模型混用、按角色控成本 | OpenCode | 每个 Agent 可以单独指定模型 |
| 长任务（几小时） | Claude Code ≈ OpenCode | 自动压缩、子代理、Todo 都很成熟 |
| 被别的程序调用 | OpenCode | 有常驻服务和 HTTP API |
| 嵌入自己的产品 | pi | 内核轻，SDK/RPC 友好 |
| 开箱即用、生态 | Claude Code | 社区资源最多 |
这里有一个容易被忽略的点：省 token 和省钱不是一回事。 pi 每轮最省，但如果你按 API 用 Opus 跑一整天，账单未必比 Claude Code 的包月低。看总账，不要只看单轮。
三、终端 CLI 那么多，区别在哪？
把视野放大，2026 年主流的 Coding Agent 大致分成四类：
- 终端 CLI：Claude Code、Codex CLI、Gemini CLI、OpenCode、Copilot CLI、Cursor CLI、Amp、Factory Droid、Goose、Aider、Qwen Code、Kimi CLI、Crush、pi……
- IDE 内置：Cursor、Windsurf、Copilot Agent Mode、Cline / Roo、Zed、Kiro、Trae
- 云端异步：Codex Cloud、Jules、Copilot Coding Agent、Devin，把任务派出去，自己跑完提 PR
- 通用个人 Agent：OpenClaw、Manus、ChatGPT Agent，不只写代码，还管浏览器、文件和消息
这个领域变化极快，名单仅代表写作时（2026 年 10 月）的格局。
光终端 CLI 就有十几个。它们区别大吗？比看起来小。 AGENTS.md、MCP、技能、子代理、计划模式，现在几乎是标配。真正拉开差距的只有三件事：
- 模型绑定：这是决定性因素。官方工具往往为自家模型做过专门调优。
- 收费方式：订阅包月，还是按 API 用量。
- 开放程度：能不能换模型、改提示词、写扩展。
据此可以把它们分成两大阵营。
A. 模型厂商官方：模型和外壳一起调优
| 工具 | 模型 | 亮点 |
|---|---|---|
| Claude Code | Claude | 综合标杆，生态最成熟 |
| Codex CLI | GPT 系列 | 开源，与 Claude Code 同属第一梯队 |
| Gemini CLI | Gemini | 开源，免费额度大，上下文长 |
| Qwen Code / Kimi CLI | 国产模型 | 便宜 |
| Copilot CLI | 多模型 | 与 GitHub 深度集成 |
B. 厂商中立：拼的是外壳本身的设计
| 工具 | 定位 |
|---|---|
| OpenCode | 开源、多厂商、可配置程度最高 |
| Amp | 不让你选模型，替你挑最强组合，效果好但贵 |
| Factory Droid | 面向企业，基准测试成绩靠前 |
| Goose | 以 MCP 为核心 |
| Aider | 老牌、以 git 为中心、偏结对编程 |
| pi | 极简内核，适合自己搭 |
所以，哪个好？
没有「最好」，只有「最适合你的约束」：
| 你的需求 | 选它 |
|---|---|
| 写代码效果最好 | Claude Code 或 Codex CLI，看你订阅了哪家 |
| 免费 / 便宜 | Gemini CLI、Qwen Code |
| 混用多模型、控成本 | OpenCode |
| 不想折腾、不在乎钱 | Amp |
| 自己搭、嵌进产品 | pi |
我的建议是：一个主力 + 一个备用，就够了。
每多装一个，就要多维护一套配置、技能和使用习惯。我电脑里那个一年没更新的 cursor-agent，就是「装了试试」的典型遗留物。
备用工具最好和主力来自不同的模型家族。比如主力用 OpenCode 跑 Claude，备用就选 Codex CLI。这样它可以给你「第二意见」：让不同家族的模型交叉审查同一份代码，比同一个模型自己检查自己靠谱得多。
四、Agent 当主力入口，是好选择吗？
我的结论是：做工程和知识工作，值得；什么事都交给它， 不值得。
适合交给 Agent 的
- 跨文件改动、排查 bug、调研、写脚本、整理资料
- 能沉淀的事情：AGENTS.md、技能、MCP 一旦写好，以后每次都受益，越用越顺手
- 有明确验收标准的任务：测试跑通、命令输出符合预期
不适合交给 Agent 的
- 确定性的操作：
git status、跑一个已知命令。直接敲更快，而且几乎零成本 - 一句话就能问完的问题：聊天窗口更轻，不用背着几千 token 的工具定义
- 审核与最终判断：这一步必须是人，最好在 IDE 或 diff 工具里看
- 高风险操作：生产环境、密钥、删数据。存在提示词注入和误操作的风险，必须有权限拦截
你要付出的代价
- 成本随回合数膨胀。每一轮工具调用都会把整个上下文重发一遍。我自己就踩过坑：几个三四个小时、两百多轮的长会话，吃掉了绝大部分的缓存读取费用，上下文涨到将近 50 万 token。最贵的不是某次输出有多长，而是回合数和上下文体积。
- 「完成」不等于正确。Agent 很擅长自信地说「搞定了」。没有可执行的证据（测试、命令输出），就不能算完成。
- 被单一工具绑定。所有流程都写死在一个工具里，换工具的代价就会很高。
- 自身能力退化。代码全交出去，你对代码库的理解会越来越浅。
五、我现在的用法
把上面的思考落地，我的工作流是这样的：
1. 按任务选入口，而不是只有一个入口
| 任务 | 入口 |
|---|---|
| 确定性命令 | 直接用终端 |
| 快速提问 | 聊天窗口 |
| 工程任务 | OpenCode（主管 + 小弟） |
| 批量小任务 | 云端异步 Agent |
| 生活与消息类事务 | OpenClaw |
2. 主管 + 小弟的模型分档
在 OpenCode 里，我让最强的模型只做「主管」：拆解任务、写简报、做关键决策、审结果。读代码库交给便宜快速的模型，写代码交给性价比高的模型，验收交给另一个家族的模型，专门找茬。
这样贵的模型只花在刀刃上，而且「写的人」和「审的人」不是同一个脑子。
3. 配置资产与工具解耦
AGENTS.md、技能、MCP 配置尽量写成通用格式，集中放在一个仓库里，再同步到各个工具。哪天要从 OpenCode 换到别的工具，搬家成本很低。
4. 用 证据说话，会话有预算
- 每个改动收尾都必须有验证结果。要么通过，要么明确写「已改，未验证，原因是……」。
- 会话设硬阈值（比如 50 轮或 150k 上下文），到了就写交接、开新会话，不要硬撑。
- 一个任务一个会话，话题岔开就新开。
结语
回到开头的三个问题：
- 都是 Agent 吗？ 都是外壳。Agent 是模型和外壳的组合，看懂分层，你才知道该换的是模型还是工具。
- 哪个好？ 功能已经趋同，选它的模型、它的收费方式和它的开放程度。一个主力加一个异族备用，足够了。
- 该当主力入口吗？ 该，但要守住两条底线：人负责验收，资产不被绑架。
工具会一直换，今天的第一梯队明年可能就不在了。真正能留下来的，是你对这三层的理解、你沉淀下来的配置和技能，以及「没有证据就不算完成」的习惯。