Augment 只有两档套餐：Business 与 Enterprise 到底怎么选？
打开 Augment Code 的定价页，第一眼会觉得信息量少得不太正常：整页只有两个方块，BUSINESS 和 ENTERPRISE。没有 Free、没有 Pro、没有 Pro+、没有 Max。对比同赛道那些一口气摆出五档的家，这种排版看着像是页面没加载完。
但它就是这样。而且这个「少」本身就是一条信息——它告诉你，Augment 没打算把个人开发者当成客户。
这篇要解决的问题很具体：如果你正在替一个团队评估 Augment，你该选哪档、什么时候必须换档、Enterprise 谈判前要准备什么。读完你应该能自己算出 Business 摊到每个人头上是多少钱、判断出自己团队会不会撞上 50 席位这条线、以及知道哪些问题只能去问销售而不能从公开页面上找到答案。先把话说在前面：这篇里凡是官网定价页没写的东西，我都会明说「没写」，不会替它补一个听着合理的数字。
两档结构不是简化，是筛选
先看这两档的公开信息：
| 档位 | 价格 | 包含额度 | 席位 | 超额方式 |
|---|---|---|---|---|
| BUSINESS | $100/月固定价 | $100 使用额度/月 | 最多 50 席位 | Top-ups，用多少付多少 |
| ENTERPRISE | Custom（需洽谈） | 使用限额自定义 | 无限制 | 以洽谈条款为准 |
这里有个容易被读漏的点：BUSINESS 是 $100/月的固定价，不是每用户 $100。你付 $100，拿到 $100 的使用额度，席位在 50 以内随便开。
这跟大多数编程 Agent 的计价方式不一样。习惯了「每用户每月多少钱」的采购思路，看到这个结构第一反应往往是「是不是写错了」。它没写错，只是把成本从「人头」挪到了「用量」上。人头基本免费，你烧掉多少算力就付多少钱。
这也解释了为什么没有个人档。对一个人来说，$100 的月度门槛摆在那儿，而这 $100 换来的是一个按美元计量的用量池——单人根本用不满，等于替 49 个不存在的同事付了席位钱。如果你是个人开发者，Augment 的公开定价页上目前没有为你准备的入口，这个判断不用绕弯子。想找个人向的档位，得去看那些把档位铺得很细的家，比如我们之前拆过的 GitHub Copilot 五档套餐，从免费到企业版一路铺满，那才是给个人留了位置的排法。
额度单位是美元，这件事省掉了一整层换算
大部分同类产品的额度单位是 credit——你买 1000 credits，然后开始猜一次重构消耗几个 credit。Augment 的额度单位直接就是美元：$100/月的额度，涵盖 LLM 调用、Context Engine 和计算三部分开销。
这意味着你不需要做 credit 到钱的换算，账单上看到的消耗就是钱本身。对财务对账来说，这是实打实少一层摩擦。
但美元额度也有它的代价：你失去了「一次操作大概几个 credit」这种粗颗粒的直觉。credit 制虽然要换算，好歹换算完是个整数，团队里能口口相传「跑一次全项目扫描大概几十个」。按美元计，同一个操作换个模型、换个上下文长度，花费就变了。所以用 Augment 的团队更需要盯着月度消耗曲线，而不是靠感觉估。
顺带一提，超额之后的机制是 “Top-ups, pay as you go”——加钱买额度，继续用。这条路径和某些工具「额度用完就降速、进慢速池排队」的处理方式是两种不同的设计取向：前者把代价落在钱上，后者把代价落在时间上。想看后一种长什么样，可以对照 Cursor 快速请求用完之后的降级机制。哪种更合适，取决于你团队卡的是预算还是交付节奏——预算硬、工期可以让的，降速那种更省心；工期硬、预算能批的，加钱续的更省事。
50 席位这条线：按 18 个月后的规模做决定
BUSINESS 最多 50 席位。这条线看着像个技术限制，实际上它是整个采购决策的分水岭。
把 $100 固定价摊到不同规模上，能看得更清楚：
| 实际席位数 | 席位成本（$100 ÷ 人数） | 人均用量额度（$100 ÷ 人数） |
|---|---|---|
| 5 人 | $20/人/月 | $20/人/月 |
| 10 人 | $10/人/月 | $10/人/月 |
| 25 人 | $4/人/月 | $4/人/月 |
| 50 人（满编） | $2/人/月 | $2/人/月 |
这张表可以自己复核：$100 ÷ 50 = $2，$100 ÷ 25 = $4，$100 ÷ 10 = $10。两列数字完全相同，因为固定价和包含额度都是 $100，摊的是同一个分母。
有意思的地方在于：人越多，席位成本越便宜，但人均能分到的用量额度也同比例变薄。50 人满编时，每人每月只有 $2 的用量池——按现在编程 Agent 的实际消耗，$2 大概只够几次像样的多文件重构。也就是说，规模一旦上去，Business 的 $100 基本只是个起步价，真实账单几乎必然由 top-up 部分主导。
这一点会直接影响预算怎么报。如果你按「$100/月」去申请预算，团队用到第二个月就要回去追加，这种事在采购流程里挺伤信任的。合理的做法是先按小范围试用测出人均月消耗，再乘以计划席位数，把这个数当预算基线，$100 只是它的一部分。
再说 50 这条线本身。真正的风险不是「今天 48 人怎么办」，而是上线半年后被迫重新走一遍采购流程。企业内部走一次软件采购，从需求评审到法务过合同再到财务开票，占掉的时间往往比工具本身带来的效率提升还多。所以判断标准不该是「我们现在多少人」，而是「18 个月后这个团队多少人」。
给几条可以直接套用的判断：
- 现在 30 人以下、且没有明确扩招计划：Business 够用，撞线的概率不高，先跑起来再说。
- 现在 35 到 50 人：这是最难受的区间。一次团队合并、一个外包批次接入、或者把测试和运维也算成使用者，就能把你顶过线。建议在签 Business 的时候，就顺手问一句超过 50 席位之后的迁移路径是什么，别等撞线那天才问。
- 现在已经超过 50 人，或者一年内确定会超：不用纠结了，直接走 Enterprise 的洽谈流程。在 Business 上开局，等于给自己排了一次注定要做的返工。
另外提醒一句「席位」的口径问题：谁算一个席位，是所有能登录的人，还是当月有活跃使用的人，公开页面上没有细说。这个口径能差出十几个人的余量，是必须在合同里问清楚的一条。
从 Business 走到 Enterprise 的三个触发条件
Business 转 Enterprise 不是「变贵了就升级」这么随意，官网列出的差异只有三处，对应三种触发场景。这三条各有各的判断方法。
**触发条件一：席位数超过 50。**这条最好判断，数人头就行，判断方法上面那节已经讲完了。唯一要补的是别忘了把非研发岗算进去——现在测试写自动化脚本、运维改部署配置、甚至产品经理拿它读代码的情况都不少见，这些人是不是要占席位，得按前面说的口径问题一起确认。
**触发条件二：需要自定义使用限额。**Enterprise 的差异之一是「使用限额自定义」。什么时候会需要这个？典型场景是你想按部门、按项目切分预算池——比如给核心业务组每月 $500 的用量、给内部工具组 $100，避免某个组一次跑飞的批量任务把全公司的额度烧光。Business 只有一个 $100 的公共池加 top-up，池子是共享的，谁先用谁先得。判断方法很简单：问自己「如果某个人某天误操作，把一个月的额度在两小时内烧完，我能接受吗」。不能接受，就需要限额分配能力，这是 Enterprise 的范围。这类共享池被单点吃光的麻烦不是 Augment 独有的，我们在 Copilot 团队 credits 用完的处理 那篇里也讨论过同样的结构性问题。
**触发条件三：需要定制条款。**这条最模糊也最容易被低估。合同条款、数据处理约定、部署形态、审计与日志要求、采购流程能不能接受对方的标准合同——这些在小团队几乎不构成问题，一旦进了有法务和信息安全评审的组织，就是能一票否决的事。判断方法是把评审会提前开，别等选型定了才拉法务进来。如果你的法务对标准 SaaS 条款有任何一条改不了的意见，那你事实上已经在 Enterprise 通道里了，跟席位数无关。
这三条只要中一条，就该去谈 Enterprise，不必等三条都满足。
Enterprise 值不值？没有公开价格，只能靠方法
Enterprise 是 Custom 定价，官网没有任何数字。所以任何声称「Enterprise 大概多少钱」的说法都是编的，包括我如果写了也是编的。这里只能给方法。
带着三份数据去谈，比空手去谈有利得多：
**第一份：确切的席位数与增长曲线。**不是「我们大概几十人」，而是「当前 62 个活跃使用者，过去 6 个月从 41 涨到 62，未来 12 个月计划到 90」。有增长曲线，你才有理由要求按未来规模谈阶梯价，而不是按今天的人数被报一个价再逐年补差。
**第二份：真实月度用量。**这份数据最有分量，因为它直接对应成本。如果你已经跑过一段 Business，账单上的美元消耗就是现成的证据——比如「过去三个月分别消耗 $340、$410、$520」。带着这个去谈，双方讨论的是一个有事实基础的量，而不是互相猜。如果还没跑过，那就先用 Business 跑一到两个月再谈，这一两个月的钱花得值。这也是我不建议直接从零开始谈 Enterprise 的原因：你手上没有用量数据，在谈判桌上是被动的。
**第三份：必须满足的合规与管理清单。**把法务、信息安全、财务的要求提前汇总成一张清单，标明哪些是硬要求、哪些是希望有。硬要求越明确，对方越容易给出一个准确的方案，来回拉扯的轮次就越少。反过来，如果你自己都说不清要什么，销售只能按最高配给你报，报出来的数自然不好看。
准备好这三份数据，你谈的就不再是「你们多少钱」，而是「按这个规模、这个用量、这些要求，方案和价格是什么」。后一种问法拿到的回复质量，跟前一种完全不是一回事。
Try Cosmos 和 Book demo 是两个入口，但试用条款页面没写
Augment 的产品线叫 Cosmos。定价页上有两个按钮：Try Cosmos 和 Book demo。
这是两个不同的入口，用途也不同——一个偏自助试用，一个偏销售对接。但试用条款页面上没有写：有没有免费试用、试用多久、试用期间的额度是多少、需不需要绑卡，这些定价页都没有说明。免费档是否存在，同样没写。
我知道读到这里你想要一个答案，但我不能给你一个我核不到的答案。这类信息编起来太容易了——「通常是 14 天试用」听着完全合理，而且十有八九没人会去查——但它可能就是错的，而你会拿着它去做预算和排期。所以这里只有一句实话：试用条款以官网定价页当前显示和销售沟通为准，如果试用政策是你决策的关键变量，就直接点 Book demo 问一句，比在网上找二手信息可靠。
同理，Business 具体包含哪些功能模块、Enterprise 相比 Business 除了席位和限额之外还多了什么、有没有私有部署选项——这些定价页上都没有逐条列明，我不替它列。已知的只有那两行核心信息：Business 是 $100 固定价含 $100 额度、最多 50 席位；Enterprise 是 Custom 定价、席位无限制、使用限额自定义。
有一条可以确认的产品事实：Cosmos 从 2026 年 7 月 29 日起把 GPT-5.6 Sol 作为默认模型。默认模型会换，这也提醒一件事——按美元计费的额度，消耗速度会随默认模型变化而变化。如果你发现某个月账单突然跳了一截，先查有没有换默认模型，再查团队用法有没有变。
最后
Augment 的两档结构其实把选择题做得很干净：**50 席位以内、不需要切分预算池、法务能接受标准条款——选 Business；三条里中了任意一条——走 Enterprise。**没有中间地带需要纠结。
真正需要花心思的不是选哪档，而是两件事：一是按 18 个月后的规模而不是今天的规模做决定，避免上线半年后被迫重走采购；二是尽早测出你团队的真实月度美元消耗，因为 $100 只是起步价，人一多，账单的主体会是 top-up 那部分。
至于 Enterprise 到底多少钱、有没有免费试用——定价页上没写，我也不猜。把席位数、月用量、合规清单这三份材料准备好，直接去问，这是唯一能拿到准确答案的路径。