编程 Agent 选型决策树：六个问题定下你该用哪一类
市面上叫得出名字的编程 Agent 已经有十几家，横评看了一堆，最后还是选不出来——这很正常。横评的写法是把所有维度铺开给你看，可你真正需要的不是全景图，是一条能走完的路径：问自己六个问题，每个问题只有两三个分支，走到底就落到某一类工具上。
这篇就是那条路径。它不告诉你”哪一家好”，只告诉你”你该看哪一类”。类别定下来之后，同一类里面挑哪家，多半取决于你公司能不能报销、你同事在用什么、你的编辑器习惯——这些外部条件比工具本身的差别更能决定结果。读完你应该能做到：拿一张纸，六行，写下自己的答案，然后把候选名单从十几家砍到两三家。
先说清楚这六个问题的顺序不能乱。前两问定形态和风险偏好，是硬约束，选错了后面全白搭；第三、四问定钱，是算术题；第五、六问定合同，是采购题。从硬约束往软约束走，才不会出现”算了半天价格，发现这东西根本不进我的工作流”。
第一问：你的活主要发生在哪里？
这是形态问题，也是最容易被跳过、最容易选错的一问。很多人是先看到某个演示视频动了心，才反过来找理由说服自己需要它。反过来才对：先看你一天里手放在哪儿。
在编辑器里写代码、改代码、做重构 —— 指向编辑器/IDE 型。理由是这类活的上下文就在打开的文件里，Agent 要能看到你的光标、你选中的那段、你项目的符号索引。一个跑在终端里的 Agent 要拿到同样的上下文，得靠你手动喂路径，效率反而低。这类工具通常还提供把 VS Code 设置和扩展导入过来的步骤，迁移成本低。
在终端里排查问题、跑运维命令、看日志 —— 指向终端型。这类活的上下文是命令历史和输出，不是文件树。终端型 Agent 的价值在于它能读到你上一条命令的报错然后接着往下走，而编辑器型工具往往要你把报错复制粘贴进去。
要进脚本、进 CI、批量跑一批仓库 —— 指向 CLI 型。判断标准很直接：你需不需要在没有人盯着的情况下让它跑。需要，就必须有能被 shell 调用、能读环境变量、能返回退出码的命令行入口。有些家的 CLI 有明确的平台清单（比如某家的 CLI 标注支持 macOS、Windows 11 的 PowerShell、以及 glibc 2.34 以上的 Linux），把它和你 CI 镜像的系统版本对一遍，这一步能提前挡掉一半的坑。
只想零安装先试试 —— 指向免安装 Web 型。有些家提供浏览器里直接用的入口，不用装任何东西；也有家把整个产品做成免费下载、页面上标注 “Available at no charge”。试用阶段没必要为了体验一下就折腾安装和登录。
顺带一个实操提醒：登录环节是新手掉队最多的地方。常见的是 Google / GitHub / 云厂商账号 / 组织身份认证四选一，而浏览器登录会绕过你配置的代理环境变量——如果你在公司网络里设了 HTTP_PROXY 却发现登录一直转圈，先查这一条，比重装十遍有用。
第二问：额度用完时，你更怕多花钱还是更怕变慢？
这是全篇最关键的一问，因为它区分的不是功能，是代价落在哪里。所有编程 Agent 的额度用完都要付出代价，区别只在于付的是钱还是时间。
你怕被打断——有硬 deadline、在救火、周五晚上必须上线——那就选代价落在钱上的：固定超额单价续费、随时买额外额度、或者超出部分直接按 API 价格计费。这类模式的好处是额度用完那一刻你的工作节奏不变，付出的是账单数字。有的家支持自动充值（auto-reload），额度见底自动续，连手动操作都省了；有的家超出后按实际用量计费，且对个人和非企业工作区标注供应商 API 定价零加成。
你怕超支——学生、自费、报销流程长、或者需要给老板一个可预测的预算数字——那就选代价落在时间上的：降级到慢速通道继续用，或者等下一个时间窗口重置。这类模式最大的价值是账单封顶，最大的代价是不确定性：你不知道慢速要慢多少，也不知道排队要排多久。编辑器型工具里典型的做法是快速请求用完后掉进慢速池，具体行为可以看Cursor 快速请求用完了怎么办；另一类做法是按时间窗口重置，参考Claude Code 额度限制。
我的判断是：如果你有任何一次”这活今晚必须交”的经历，就别选纯时间代价的模式。慢速通道在你不赶时间的时候是省钱神器，在你赶时间的时候是灾难。反过来，如果你的工作从来没有硬截止时间，纯时间代价能帮你把年度支出锁死，这个确定性很值钱。
第三问：需要提前算准月度支出吗？
如果你要做预算、要走报销、要给财务一个数——那你需要的是超额单价公开的那一类。单价公开意味着你能算出一个很实用的数字：升档分界线。
公式是：（高档月价 − 低档月价）÷ 超额单价。
拿一组公开数据算：某家的 $20 档含 1,000 credits，$40 档含 2,000 credits，两档超额单价都是 $0.04/credit。分界线 =（40 − 20）÷ 0.04 = 500。含义是：如果你在 $20 档每月超额用量超过 500 credits，超额费就会超过 $20，那还不如直接升到 $40 档。低于 500，留在低档买超额更省。
这个数字的好处是它把”我该买哪档”从感觉题变成了算术题。你只要知道自己每月超额多少，对着分界线一比就有答案，不用看任何评测。
如果你不需要精确预算——个人玩票、公司统一采购不用你操心——那浮动模式完全可以接受，超出按 API 计费那类反而更灵活，用多少算多少，不用为了额度提前压一笔钱。
需要提醒的是，很多家并不公开”一次操作扣多少额度”。有的家的计费文档页直接返回 404，有的家的请求限制文档也打不开。这意味着即使超额单价公开，你也算不出”一天干活消耗多少”。所以下一问才是必需的。
第四问：你的用量到底大不大？
不要猜，去测。方法很笨但准：
- 记下当前余额（或已用量）；
- 照常干一天活，别刻意省也别刻意造；
- 再记一次，两个数相减，得到”一天消耗”；
- 乘以你真正开工的天数——不是 30 天，是你这个月真会写代码的天数，很多人是 15 到 18 天。
有了月消耗，再看有没有批量折扣。方法是把每一档换算成”每美元买多少额度单位”，然后横着比：
- 全部相同 = 没有批量折扣。买刚好够的那档，往上买一分钱便宜都不占。例：某家 $20/1,000、$40/2,000、$100/5,000、$200/10,000，每美元都是 50 个单位，四档一模一样。
- 高档明显更多 = 有折扣，用量大就该往上买。例：另一家 $20 含 1,500，是每美元 75 个单位；$200 含 18,000，是每美元 90 个单位。高档比低档多买两成，用量确实大的话往上买划算。
- 某档明显更少 = 那一档卖的不是额度。同一家的团队档 $50/用户含 1,500/人，每美元只有 30 个单位，比个人档少了六成。这六成不是溢价黑箱，是团队管理能力（席位管理、集中计费、统一策略）的价格。你要判断的是自己需不需要那部分能力，而不是抱怨单价贵。
把这三种形态记住，任何一家的价格表你都能在两分钟内看穿。
| 档位形态 | 每美元额度换算 | 结论 |
|---|---|---|
| 各档换算值相同 | 例：50 / 50 / 50 / 50 | 无批量折扣，买刚好够的档 |
| 高档换算值更高 | 例：75 → 90 | 有折扣，用量大往上买 |
| 某档换算值明显低 | 例：个人 75、团队 30 | 该档卖的是管理能力，不是额度 |
第五问：个人还是团队？
个人用户要注意一件反直觉的事：有些家根本没有个人档。最低起步就是团队价，比如有家的入门就是 $100/月固定价（含 $100 使用额度），再往上是需要洽谈的企业版，页面上找不到任何面向个人的免费档或试用条款。如果你是个人开发者，看到这种价格结构就该直接跳过，而不是纠结”$100 值不值”。
团队采购必问三件事，缺一件都可能在半年后翻车：
- 额度是按人给还是共享池。按人给的好处是不会有人把公共额度用光，坏处是重度用户不够用而轻度用户浪费；共享池反过来。
- 席位上限是多少。这是硬约束，不是可以商量的参数。有的家的团队档明确写了最多 25 席位，有的写了最多 50 席位，超过就必须谈企业版。
- 这一档的溢价买的是什么。用第四问的换算法算一遍，把多花的钱和拿到的管理能力对上号。
我的建议是：采购按 18 个月后的团队规模做，不是按今天的人数做。今天 20 人，明年 30 人，选一个 25 席位上限的方案就意味着一年后必须重新走一遍采购流程、重新谈价、重新迁移。团队工具的迁移成本比个人高一个数量级，因为要动的是所有人的习惯。团队额度的具体分配方式各家差别很大，可以先看GitHub Copilot 五档套餐建立一个参照系。
第六问：要不要年付？
看绝对金额，不看百分比。这是唯一正确的看法。
10% 折扣听起来都一样，但落到不同档位上差别巨大。同样是年付九折：
| 档位（月付 → 年付） | 一年省 | 我的判断 |
|---|---|---|
| $20 → $18 | $24 | 不值得锁一年 |
| $200 → $180 | $240 | 用法稳定就值得 |
| $50/人 → $45/人 × 10 人 | $600 | 值得，但先确认席位上限 |
入门档一年省二三十美元，换来的是被锁定一整年的风险。这个风险不是抽象的——就在本文核对的这一天（2026-08-08），我们实测到有一家的定价页 URL 已经 308 永久重定向、合并到了另一家的定价页上。定价入口合并意味着套餐结构可能重排，你年初锁的那个档，年中还在不在都不确定（至于合并背后的商业安排、产品后续如何、老用户订阅怎么处置，我们没有核实到任何可靠信息，所以不写）。二三十美元的折扣不足以覆盖这个不确定性。
重度档或者十人以上的团队就不一样：一年省几百美元，而且这个量级的用户通常用法已经稳定，不太可能三个月后换掉整套工作流。这时候年付是合理的。
判断线：先月付用满三个月，确认自己确实长期在用、且用法没大变，再转年付。 三个月足够暴露”买了不用”和”用法完全变了”这两种最常见的浪费。
另外提醒一句和年付相关的坑：有些家支持购买预付额度，而未使用的额度在账户不活跃满一年后会过期。年付 + 预付额度叠在一起，如果中途项目停了，两笔钱可能一起打水漂。
六问总结表
把答案填进中间一列，右边就是你的方向。
| # | 问题 | 你的答案 | 指向 |
|---|---|---|---|
| 1 | 活主要发生在哪里 | 编辑器 / 终端 / 脚本 CI / 只想试试 | IDE 型 / 终端型 / CLI 型 / 免安装 Web 型 |
| 2 | 更怕多花钱还是更怕变慢 | 怕被打断 / 怕超支 | 代价落在钱上（续费、买额度、API 计费）/ 代价落在时间上（降速、等重置） |
| 3 | 要不要算准月度支出 | 要 / 不要 | 找超额单价公开的，算升档分界线 / 浮动模式可接受 |
| 4 | 用量大不大 | 测出月消耗后看换算 | 换算相同→买够用的；高档更多→往上买；某档更低→那档卖管理能力 |
| 5 | 个人还是团队 | 个人 / 团队 | 个人：避开没有个人档的 / 团队：问清按人还是共享、席位上限、溢价买什么 |
| 6 | 要不要年付 | 看一年省的绝对金额 | 省几十→不锁；省几百且用法稳定→可锁；一律先月付满三个月 |
三件不该作为选型依据的事
走完六问，你的名单应该只剩两三家了。最后这一节是防止你在临门一脚被带偏。
第一，别比”谁的模型更强”。 各家都在换模型，今天默认这个明天默认那个，你今天基于模型做的决策下个月就过期了。更要紧的是，同一个模型下，你把需求说成”帮我把这个电商项目的订单模块重构一下”，和说成”只改 order/service.ts 里的 createOrder，别动支付逻辑，改完跑一遍单测”，产出的质量差距远大于两家模型之间的差距。提问方式是你能控制的变量，模型排名不是。
第二，别信网上的额度换算表。 那些”一次对话约等于 X 个额度单位”的表格，大部分是有人自己测了几次然后外推的。真实情况是：本文核对当天，我们能查到公开超额单价的家不少，但能查到单次操作扣费规则的——一家都没有。有的家的计费文档页直接 404，有的家的请求限制文档也打不开，有的家的额度计算单位定义压根没公开。官方都没公开的东西，第三方表格的准确度可想而知。要数据就自己测，第四问那个笨办法四步就能测出来。
第三，别为省 10% 一上来就买年付。 上一节已经算过账了，这里只补一句：年付把你从”随时可以换”变成”换了就亏”，而选型这件事本来就应该允许试错。第一个月发现不合适，止损成本是二十美元；年付之后发现不合适，止损成本是你剩下十一个月的钱加上心理上的沉没成本——后者往往更贵，它会让你为了”钱都花了”而继续用一个不趁手的工具。
最后
这六个问题的价值不在于每一问多深刻，而在于顺序。形态不对，价格再香也用不起来；断供代价选反了，赶工那天会想砸键盘；预算算不准，第三个月账单来了才发现超了；用量没测，买大买小都是浪费；团队三件事没问，一年后重新采购；年付冲动，锁死一年。
把这六行抄在便签上，下次再看到某家的新品发布，直接拿着单子过一遍。走完还剩两家，那就选你同事在用的那家——工具的实际收益里，有很大一块来自”遇到问题有人能问”，这一点任何对比表都体现不出来。