团队上编程 Agent 一年要多少钱？按用量分档能省一大笔

2026-08-08

给团队买编程 Agent，最容易多花钱的地方不是选错了家，而是给所有人配了同一个档位。

这件事的荒谬之处只有把账算出来才看得清。这篇要做的就是把账算出来：一个十人研发团队，全员统一档和按用量分档，一年的差额是多少；两段式定价（固定月费 + 每座位费）在什么规模下才划算；席位上限为什么是个比价格更麻烦的约束；年付折扣该按什么标准判断。读完你应该能自己把这笔账列出来，而不是听销售报个人均价就签字。

文中所有金额都是为了演示算法而设的假设数字，不代表任何一家的实际报价——具体价格以各家官方定价页为准。要算你自己的，直接把数填进文末的测算器。

为什么全员统一档几乎一定是浪费

团队的用量分布几乎总是长尾的。十个人的研发团队里，通常有两三个人天天让 Agent 干重活：整模块重构、批量补测试、跨文件排查线上问题、把一个老服务从头理一遍。剩下七个人一周才用几次，多半是”这段报错什么意思”、“帮我把这个函数写完”、“给这个接口补个注释”。

这两类人的消耗差多少？前者一次任务可能就是几十步工具调用——Agent 自己拆成搜索、读取、生成、逐文件改、跑测试、自检；后者一次问答就结束了。重度用户烧掉的额度是日常用户的十倍，是很正常的分布，不是异常。

问题就出在这儿。采购时为了”公平”、为了”少一件事”，通常按最重的那个人的需求定档，然后全员照配。结果是：给七个人买了他们这辈子也用不完的额度。

这七份浪费不会在月账单上跳出来告诉你。它藏在”人均 X 美元”这个看起来很合理的数字里，你只有把人拆开看，才会发现有七个人的额度使用率长期停在个位数百分比。

一笔具体的账：10 人团队，分档和统一档差多少

设定：10 人团队，3 个重度用户、7 个日常用户。重度用户确实需要 $100 档，日常用户 $20 档完全够用。

方案	算式	月成本	年成本
全员配 $100 档	10 × $100	$1000	$12000
按用量分档	3 × $100 + 7 × $20	$440	$5280
差额	—	$560	$6720

一个月差 $560，一年差 $6720。

$6720 是什么概念？它超过了这个团队按分档方案付一整年费用的一半以上（$5280）。换句话说，只是把人分了个组，省下来的钱够这个团队再多用一年多。

而做这件事需要的工作量，是花两小时看一眼后台的用量数据，把人分成两组。

分档有效的两个前提，采购前必须确认

上面那笔账不是无条件成立的。它依赖两个前提，任何一个不成立，结论就要重算。

前提一：额度是按人给的，不是团队共享池。

这是采购前必问的第一个问题。有些定价结构是”每用户每月 $X，每人各自拿到 N 额度”——这种才能按人分档，因为每个座位的额度独立结算，你给谁配高档，高额度就落在谁头上。另一些是”团队买一个大池子，所有人一起用”——这种就没有”分档”这回事了，你只能整体估总量，然后担心月底被某个人一口气抽干。

两种结构没有绝对优劣。共享池的好处是自动削峰，重度用户的高峰可以借用日常用户没花完的部分；坏处是没有隔离，且很难做部门级的成本归属。但只有按人给额度的结构，分档才是一个可执行的动作。谈之前先把这一条问清楚，能省掉后面所有的无用功。

前提二：这家没有很强的批量折扣。

分档能省钱，隐含假设是”每美元买到的额度在各档之间是一样的”。本文核到的几家里，确实有按用户计费、且高低档每美元额度完全相同的例子——比如某家 $20 档给 1000 credits、$100 档给 5000 credits，都是每美元 50 credits。这种情况下分档是纯赚：你没有因为买低档而在单价上吃亏。

但如果一家的高档明显更划算——比如高档每美元能多买三成额度——那就要重新权衡了。此时把日常用户也拉到高档，虽然买了用不完的额度，但重度用户那部分的单价降下来了，总账未必更差。判断方法很简单：把每档的「月价 ÷ 含额度」算成单价列一列，如果这一列是平的，分档就是正解；如果明显下斜，就得两种方案都算一遍再选。

两段式定价：固定月费怎么摊薄

另一种常见结构是”固定月费 + 每座位费”。假设是 $80/月 + $40/座位：

团队人数	算式	月总价	人均
3	80 + 3×40	$200	$66.7
5	80 + 5×40	$280	$56.0
10	80 + 10×40	$480	$48.0
20	80 + 20×40	$880	$44.0
50	80 + 50×40	$2080	$41.6

这张表说了一件事：**人均成本随规模递减，无限逼近 $40，但永远到不了。**因为那 $40 是每个人都要付的，$80 只是被越来越多人分摊。

结论很直接：**团队越小，两段式定价越吃亏。**3 个人时，那 $80 摊到每人头上是 $26.7，占人均成本的 40%——你有四成的钱花在了”开门费”上，跟你用不用、用多少毫无关系。到 20 人时，$80 摊下来每人只有 $4，占人均成本不到 10%，基本可以忽略。

所以看到这类报价，别只看”每座位 $40”这个数。**先把固定费除以你的实际人数，看它占人均的百分比。**超过两成，说明你的规模还没到这个定价结构的适用区间，要么再等等，要么去看按人计费的方案。

席位上限：麻烦的不是贵，是时机

各家团队档常带席位上限——有的最多 25 席，有的最多 50 席，超过就只能走定制洽谈。

很多人看到这条会想：“我们才十几个人，不用管。“这个想法漏掉了真正的成本。

上限的麻烦不在于超了要多花钱，而在于它会在你扩张到某个规模时，强迫你重走一遍采购流程：重新谈判、重新比价、重新走审批、重新做安全评估、重新签合同。而这件事偏偏会发生在你团队正在快速扩张的时候——也就是所有人最忙、最没空处理采购的时候。

更糟的是这时你的议价地位变差了。全团队已经把工作流建在这个工具上，迁移成本高得吓人，对面很清楚这一点。

所以：**采购决策按 18 个月后的规模做，不是按今天的人数。**如果你现在 15 人、明年计划到 40 人，那么”最多 25 席”这一条今天就该是个否决项，而不是”以后再说”。

年付折扣：看绝对金额，不看百分比

同样是一句”年付九折”，对不同规模的意义完全不同。

个人档：$20 一档，一年省二十几美元。为这点钱把自己锁一年，不值得——尤其这个行业每隔几个月就冒出新东西，你很可能三个月后就想换。

十人团队：假设团队档 $50/人，年付 $45/人，每人每月省 $5，十个人一年就是 $600。这个数字够买不少东西了，而且到了这个阶段，你的用法通常已经稳定——工具选型定了、工作流跑顺了、人也熟悉了——锁一年的风险小得多。

判断线可以简单一点：**用满三个月再考虑转年付。**三个月足够暴露一个工具是不是真的融进了团队日常，也足够让你看清用量分布是不是稳定。不到三个月就锁年付，赌的是你对一个还没摸熟的工具的判断。

顺带一提，超额部分通常不参与年付折扣。如果你团队经常超额，请把超额那部分单独算，别混进折扣里估。关于团队额度被用完之后会发生什么、谁该为超额买单，可以看Copilot credits 用完（团队）那篇的机制拆解。

算完之后，还有两件事要做

第一件：每季度复核一次分组。

分档不是一次性动作。人员会流动，项目会变化——上季度那个天天重构的人，这季度可能转去做需求评审了；上季度只用来查报错的人，这季度接了个老系统改造，用量翻了几倍。分组半年不动，省下来的钱会慢慢漏回去。放进季度例行事项里，每次花二十分钟看用量报表，够了。

第二件：查一查重度组是不是真的需要那么多额度。

消耗高不一定等于活多，也可能是提问方式太发散。

对比这两种问法：

「帮我优化下这个项目」——Agent 会自己拆解成搜索全仓、读几十个文件、判断哪里能改、逐个生成方案、跑测试、自检，一趟下来几十步起步，而且大概率有一半的改动你并不想要。
「只改 order/service.ts 里的 createOrder，别动支付逻辑」——范围锁死，Agent 读两三个文件就能动手，消耗低一个数量级，产出还更符合预期。

我见过团队里额度消耗最高的那个人，换了提问习惯之后掉到中位数——活没少干，只是不再让 Agent 满仓库乱翻。所以在给重度组加钱之前，先看看能不能通过改提问方式把消耗降下来。这个成本是零，效果往往比换档位还明显。

最后

团队采购编程 Agent，真正决定花多少钱的不是选了哪一家，而是三件事：有没有按用量分档、定价结构适不适合你的规模、有没有为 18 个月后的人数留出余量。

这三件事都是算术，不是判断题。把你的实际人数、分组、各档价格填进团队席位成本测算器，页面会直接给出月成本、年成本、年付能省多少、分档相对统一档能省多少，并且校验你的人数有没有超出席位上限。

先算，再谈价。带着一张算好的表去跟销售聊，和空着手去，是两种完全不同的对话。