CLI 型还是 IDE 型编程 Agent？形态比模型能力更该先想清楚
选编程 Agent 的时候，大多数人第一个问的是「它背后是哪个模型」。这个问题不是不重要，但它排的位置太靠前了。真正每天影响你的，是另一件更朴素的事：这个东西以什么形态装进你的工作流——是一个编辑器插件、一条命令行、一个要替换掉你现有终端的程序，还是一个打开浏览器就能用的网页。
形态决定三件事：接入要花多大力气、它擅长干什么任务、以及你想在团队里推开的时候会遇到多大阻力。这三件事都是可以在下载之前就想清楚的，而模型能力那一层，你不试用一周根本判断不了，而且各家都在换模型，判断很快就过期。
读完这篇，你应该能做到：把候选工具先按形态归类，用接入成本和任务类型两个维度筛掉一大半，剩下的再去比细节。
一、四种形态，先分清楚
把现在市面上的编程 Agent 拆开看，形态其实就四类。
| 形态 | 它是什么 | 接入动作 | 最擅长的任务 |
|---|---|---|---|
| 编辑器 / IDE 型 | 装进你现在用的编辑器，或本身就是一个编辑器 | 装插件，或装一个新编辑器 | 看着代码改代码：重构、补全、跨文件改动 |
| CLI 型 | 终端里跑的一条命令 | 一条安装命令 | 批量、可编排：进脚本、进 CI、远程跑 |
| 终端替代型 | 它本身就是终端，要替换你现在用的那个 | 换掉终端并迁移配置 | 运维与排查：命令记不住、报错看不懂 |
| 免安装 Web 型 | 浏览器打开就能用 | 打开网页登录 | 零安装先试、临时机器上应急 |
举几个具体的落点，会更好理解这张表。
Kiro 是形态最全的一家：它同时提供 IDE、CLI、Web、Mobile 和一个叫 Crew 的形态。IDE 覆盖 macOS（Intel 与 Apple Silicon）、Windows 10/11 64 位、Linux（Ubuntu 24+、Debian 13+ 等）；CLI 覆盖 macOS、Windows 11（PowerShell）、Linux（glibc 2.34+）；Web 版任何现代浏览器都能用、不需要本地装东西；Mobile 是 iOS，经 Apple TestFlight 分发；Crew 覆盖 macOS / Linux / Windows，但需要 Python 3.9+ 环境。登录方式是四选一：Google、GitHub、AWS Builder ID、组织身份认证。
这里可以做一个很直接的换算：Kiro 的五种形态里，需要在本地装东西的是 IDE、CLI、Crew 三种，占五分之三；剩下 Web 完全免安装，Mobile 走 TestFlight。也就是说，如果你所在的公司设备管得严、装软件要走审批，Kiro 至少有一条路（Web）是绕开安装环节的。这不是小事，后面第四节还会提到。
Amp 是另一种典型：它把自己嵌进你已有的编辑器里。官方列出的支持范围是 VS Code 系（包括 Cursor、Windsurf 这些基于 VS Code 的编辑器）、Neovim、Zed，以及 JetBrains——但 JetBrains 那一条官方标注为已废弃、仍可用但不再更新。安装方式给了三条：
# macOS / Linux / WSL
curl -fsSL https://ampcode.com/install.sh | bash
# Windows
powershell -c "irm https://ampcode.com/install.ps1 | iex"
# Homebrew
brew install ampcode/tap/ampcode
Warp 属于第三类，它不是插件也不是一条命令，它本身就是终端。用它意味着你要把现在天天开着的那个终端换掉。
Google 的 Antigravity 官网提供 Apple Silicon 和 Intel 两个下载选项，页面上没有写明是否还有 Windows / Linux 版本——所以这里我不下结论，既不说它只有 mac 版，也不说它全平台，下载前自己去官网确认一眼是最省事的做法。
Cursor 属于编辑器型（它本身是一个编辑器），Claude Code 属于 CLI 型（在终端里跑）。这两家的额度机制站内另有文章写过，可以看Cursor 快速请求用完了怎么办和Claude Code 的额度限制，这里不重复。
二、形态决定了它适合干什么
这一节是全文的核心。四种形态擅长的任务是真的不一样，不是包装差异。
编辑器 / IDE 型强在「看着代码改代码」。 它天然知道你现在光标停在哪个函数、这个文件在项目里的位置、旁边还开着哪几个标签页。做重构、做跨文件改动、做那种「把这个类的三个方法抽出去、调用点全改掉」的活儿，它的上下文是现成的，你不用再描述一遍。反过来说，让它去跑一个「把这 200 个 JSON 文件按新 schema 转一遍」的批量任务，就有点别扭——编辑器界面本来就不是为批量设计的。
CLI 型强在「批量与可编排」。 它最大的价值不是聊天窗口好不好看，而是它能被别的东西调用：写进 shell 脚本、塞进 CI 的某个 step、通过 SSH 在远程服务器上跑、用 cron 定时触发。一旦一个工具能被脚本调用，它就从「一个我用的工具」变成了「一段我流程里的零件」，这个跃迁是编辑器型给不了的。典型场景：夜里跑一遍全仓库的依赖升级并生成 PR、每次提交前自动扫一遍新增代码。
终端替代型强在运维与排查。 它的主场是那种「命令记不住、报错看不懂」的时刻：一条 ffmpeg 参数拼不出来、一个容器起不来只有一串日志、一个 git 状态搞乱了不知道怎么回。这类场景的共同点是问题就发生在终端里，答案也要落在终端里，中间不需要打开编辑器。所以把 AI 直接做进终端是说得通的。
Web 型强在「零安装先试」。 它的价值集中在两个瞬间：一是你还在选型阶段，不想为了试用一下就在主力机器上装一堆东西；二是你临时用别人的电脑、或者手上只有一台受管控的设备，装不了软件。Web 型不适合当长期主力（本地文件访问、终端集成这些都受限），但它是成本最低的一次试驾。
三、接入成本，从低到高排一排
把上一节的形态换算成「要花多大力气」，顺序大致是这样：
| 接入成本 | 形态 | 具体要做什么 | 主要风险 |
|---|---|---|---|
| 最低 | Web 型 | 打开浏览器、登录 | 功能受限，不适合长期主力 |
| 低 | CLI 型 | 跑一条安装命令 | 系统依赖门槛（见下一节） |
| 中 | 编辑器插件 | 装个插件、登录 | 和现有插件冲突、快捷键撞车 |
| 中高 | 独立编辑器 | 装新编辑器、导配置 | 配置迁移，但通常有导入功能 |
| 最高 | 终端替代型 | 换终端 + 迁移全部终端配置 | 肌肉记忆全部重来 |
独立编辑器这一档其实没大家想的那么可怕，因为多数产品都做了迁移路径。以 Kiro 为例，它的首次流程是：下载 → 运行安装程序 → 选一种登录方式 → 可选地导入 VS Code 的设置与扩展 → 打开项目文件夹。中间那步「导入 VS Code 设置与扩展」是关键，它把配置迁移的痛感压掉了大半。
真正最容易被低估的，是换终端的成本。 我把它单独拎出来说，因为它的成本不体现在安装步骤上——装 Warp 这类工具本身很快——而体现在你已有的一堆东西上：
- 配色和字体：你调了两年才顺眼的那套主题，新终端不一定有，得重配。
- 分屏和标签布局：什么快捷键切窗格、开新标签在哪个方向，全是手指记住的，不是脑子记住的。
- 快捷键：跳词、清行、搜历史，这些高频操作一旦按键变了，前两周会持续别扭。
- 启动脚本：
.zshrc/.bashrc里那些别名、环境变量、版本管理器的初始化，多数能带过去，但总有几条要调。 - 和别的工具的联动：tmux 怎么共处、编辑器里的集成终端算不算数、SSH 配置怎么走。
这些单拿一条出来都不大，加在一起就是「这周先不换了」。所以我的判断是：终端替代型工具的评估周期，应该比其他三类都长，别当天试当天决定，至少让它当一周主力终端再下结论。
四、团队里推得动吗，这是另一道题
个人选型和团队推广是两件事。一个规律很稳定：形态越轻，推广阻力越小。
装个插件，是最容易推的。同事的编辑器不用换、配置不用动、不喜欢卸掉就行，试错成本接近零。你在群里发一句「装一下试试」，真的会有人装。
一条命令装的 CLI 排第二。它对个人开发环境的侵入也很小，但会多出一层：谁来管认证、额度算谁的、要不要进 CI。这些是流程问题，不是技术问题，但它需要有人拍板。
要求全员换 IDE，阻力明显上一个台阶。团队里总有几个人对编辑器有很强的偏好，这类偏好基本说服不动，而且也不该硬说服。
要求全员换终端，阻力最大。 原因就是上一节那些肌肉记忆——你要求的不是「多装一个东西」，而是「改掉一个你每天按几百次的习惯」。这类方案能不能落地，往往和工具本身好不好无关。
所以如果你的目标是让整个团队用起来，一个务实的顺序是：先用最轻的形态做验证（Web 型或插件），确认这东西对你们的代码库真的有用之后，再考虑要不要上更重的形态。 反过来做——一上来就要求全员换终端换 IDE——大概率会卡在第一周。
五、几条容易踩的门槛
这几条都是选型时看一眼就能避开、但装到一半才发现会很烦的：
Linux 上的 CLI 可能有 glibc 版本要求。 Kiro CLI 的 Linux 支持写明是 glibc 2.34+。这个门槛对新发行版无所谓，但如果你的开发机或者构建机是几年前的老系统（企业环境里这很常见），可能装不上。先查一眼你机器的 glibc 版本再下载，比装到一半报错强。
某些形态需要额外的语言环境。 Kiro 的 Crew 形态需要 Python 3.9+。这在个人电脑上通常不是问题，但在一台干净的容器或者受管的公司设备上，可能就得先解决 Python。
curl | bash 这类安装方式，建议先把脚本下下来看一眼。 上面 Amp 的安装命令里，前两条都是「下载脚本并直接执行」的形式。这是很常见的做法，本身不代表有问题，但它意味着你把一段还没看过的脚本交给了 shell 去跑。个人机器上你自己权衡，在公司设备上，我的建议是先 curl 保存到文件、看一遍内容、再执行——很多公司的安全规范本来就这么要求。
注意「已废弃但仍可用」这类标注。 Amp 对 JetBrains 的支持就是这个状态：还能用，但不再更新。这条对不同团队的分量完全不同——如果你们主力是 VS Code，这条基本无关；如果你们是 IDEA 或 PyCharm 的重度用户，这就是一条实打实的风险，要算进选型结论里。这里可以做个简单的算术：Amp 官方列出的四类编辑器支持中，有一类处于已废弃状态，也就是四分之一的选项在选型时要打折扣——对 JetBrains 团队来说，这四分之一恰好就是你需要的那一份。
登录方式要对得上公司的账号体系。 Kiro 给了四种登录：Google、GitHub、AWS Builder ID、组织身份认证。个人用随便挑一个，但团队用的时候，能不能接上你们已有的身份认证，直接决定了后续账号怎么管、人走了怎么回收。这条在个人试用阶段完全感觉不到，一到团队铺开就是第一个卡点。
六、一条决策路径
把上面的东西压缩成几个问题，按顺序问自己：
第一问：你现在最想让 AI 帮你干的，是改代码还是跑任务？ 主要是改代码（重构、补全、跨文件改动）→ 往编辑器 / IDE 型走。 主要是跑任务（批量处理、CI 集成、远程执行）→ 往 CLI 型走。 主要是查报错、拼命令、看日志 → 终端替代型值得评估。
第二问：你能在自己的机器上装东西吗？ 不能，或者要走审批 → 先找有 Web 形态的，零安装先试。 能装，但不想折腾 → 优先插件形态，别一上来换编辑器。
第三问：这是你一个人用，还是要推给团队？ 一个人用 → 按第一问的答案选就行，重形态也无所谓。 要推给团队 → 把形态权重调高，从最轻的形态开始验证。
第四问（如果考虑重形态）：你的环境过得了门槛吗？ Linux 老系统查 glibc、受管设备查能不能装、JetBrains 团队查支持状态、公司账号体系查登录方式能不能接。
七、最后：不必二选一
前面为了讲清楚差别，把四种形态摆得像是互斥的，实际上不是。多形态并存是很自然的用法，而且往往是最舒服的用法。
一个挺常见的组合是：编辑器型负责白天写代码，因为它上下文现成、改起来顺手；CLI 型负责批量和自动化，因为它能进脚本、能进 CI、能在服务器上跑。这两者的任务几乎不重叠，同时用不会打架，反而互补。Kiro 一家就同时提供 IDE 和 CLI，本身就说明厂商也是这么设计的。
有几个数字这篇文章刻意没写：各家一次操作消耗多少额度、额度多久刷新、免费档具体给多少——这些在我核对的公开页面上要么没写明、要么文档页已经打不开了。既然核不到，我就不猜，具体数值请以各家官方定价页为准。这篇能给你的是形态这一层的判断框架，它比数字稳定得多：价格会变、模型会换，但「插件比换终端好推」这件事，一两年内不会变。
真要给一条最省事的建议：先用最轻的形态试，别在还没确认有用的时候就付出迁移成本。 打开一个 Web 版跑两个真实任务，比读十篇评测都管用。