如果你只想知道结论：Carbon 值得在这两周认真评一次，但不是因为「更强」，而是因为它现在和 Argon 同价，并且把多 Agent 编排做成了 Antigravity 里的一个斜杠命令。12 月 1 日价格翻倍到 $4/$20 后，Carbon 与 Opus 5.5 同价，仍是 Fable 5.2 的一半，但它会消耗更多 token，低难度批量任务会先变得不划算。
适合试的人：手上有多包迁移、跨子系统排障、架构重设计这类要跑几小时、且有测试或验收命令的任务；团队能 review 并行 worktree 的 diff；愿意为一次运行付几美元到几十美元。不适合的人：只是把分类、抽取、改文案跑量；要求秒级响应；没有人手看并行改动。
本文聚焦三个问题：/swarm 怎么触发、与单 Agent 有何区别；12 月 1 日前哪些任务值得迁；在 API 里怎么搭最小可降级的 swarm。
先看结论：现在是评测窗口，不是全面迁移窗口
Google 在 2026 年 11 月 10 日把 Gemini 4 Carbon 开放给开发者和企业，发布价与 Gemini 4 Argon 相同：每百万输入 token $2，每百万输出 token $10。Google 发布文脚注写明，推广期（introductory period）到 11 月 30 日结束，12 月 1 日起恢复为 $4/$20；The Verge 与 Simon Willison 也记录了同一节点。低价窗口只剩两周多。
Carbon 的定位不是替代 Argon。Google 自己说，Argon 仍是大多数软件工程和知识工作的合适选择，Carbon 面向「测试模型智能上限」的任务，比如复杂多步编码、调试和开放式科研，会用更多 token 去探索、推理和跑验证循环。
Google 还声称 Carbon 在 CursorBench 4.0、Perplexity 的 WANDR 和 Zapier 的 AutomationBench 上排第一，单位任务成本不到第二名的 1/2。The Verge 提醒这类跑分会被厂商挑选。这两周最该做的不是切生产流量，而是选 3 个代表性任务，用同一套验收命令跑 A/B：Argon 单 Agent 一遍，Carbon 加 /swarm 一遍，比较「每个被接受的结果花多少钱」和「人工 review 花多久」。只看 token 单价会得出错误结论。
/swarm 怎么触发：在 Antigravity 里输入一个斜杠命令
/swarm 不是模型参数，也不是 Gemini API 的开关。Google 发布文把它放在 Google Antigravity 一节；Antigravity 团队的同日文章写得更清楚：在 composer 里输入 /swarm，协调者会拉起并行 worker 和一个对抗性 verifier。
它的核心是三类角色，按任务需要还可以增加专门角色（如安全审计、数据库迁移、前端视觉检查）：
- 协调者：理解 brief，拆任务，决定谁做什么，最后汇总。适合固定在 Carbon 上。
- 并行 worker：各自在独立的 git worktree 里改文件，互不覆盖。适合 Argon 或其他更轻的模型。
- 对抗性验证者：专门跑测试、挑 diff 的毛病，不负责写代码。适合 Carbon。
所有 Agent 在只追加的共享消息板上协作，空闲时零 token 停靠，有输入再唤醒。侧边栏提供 Board、Members、Graph 视图，CLI 可用 /swarm board 或 Alt+S 查看；Members 支持把单个 Agent 固定到 Carbon，其余跑 Argon，运行中可切换。
可用范围要看清：Carbon 在 Antigravity 里面向 Google AI Ultra 订阅者，覆盖 App、CLI 和 IDE 扩展；/swarm 还是 preview，先在 App 和 CLI 滚动开放。企业和科研人员另有申请入口。普通 API 用户能调 Carbon，但调不到 /swarm。
和单 Agent 工具调用差在哪：三个隔离
单 Agent 也能调工具、读文件、跑测试，任务范围小时最省事。Antigravity 文章给了一个明确边界：当一次改动横跨几十个文件和测试套件，单 Agent 会开始丢上下文；动态子 Agent 能分担一次性任务，但所有结果仍要回到一个协调者上下文里审阅、综合、路由，瓶颈还在。
/swarm 改的是三个隔离：
- 上下文隔离：从我们的机制分析看，worker 在独立任务上下文里工作，能减少主对话历史的干扰；协调者通过共享消息板汇总，不必把所有中间过程塞进同一上下文。
- 工作区隔离：每个 worker 在自己的 git worktree 里改，分支和目录不重叠，避免并行改同一仓库时互相覆盖。
- 验证隔离：verifier 不参与实现，只拿 diff、测试输出和验收条件做判断，避免「自己写、自己验」把能跑当成做对。
代价是调用次数。一个协调者加 3 个 worker 加 1 个 verifier，一轮至少 5 次模型调用；来回讨论或打回重做还会继续涨。Antigravity 团队提醒，即使有空闲零 token 停靠和动态换模型，并行多 Agent 消耗配额仍比普通聊天快得多。
如果你用 HiFox 跑这类任务，队长拆任务、@ 成员并把结果收回到同一任务的协作机制见《小队》；单个 Agent 的工作目录配置与 Worktree 隔离运行见《Agent 如何执行任务》。
12 月 1 日前的迁移清单：三类现在试，三类先别动
现在值得试的三类：
- 多包迁移和跨子系统根因：Google 内部 dogfooding 五周主要就是这类任务。改动面大、验收明确，适合 coordinator 拆解、worker 并行、verifier 收口。
- 多模态密集文档：Google 给了一个可核对的例子：7 份市政规划 PDF、206 张工程图，一个 prompt 跑出 90.6 万三角面的 Three.js 场景，跨 10 个隔夜循环。Carbon 在 Artificial Analysis 的 MKA 多模态知识 Agent 基准排第 2，平均每任务成本不到第一名的 1/6（低 80% 以上）。做尽调和图纸复核的团队值得拿自己的材料复现。
- 高价值长时程验证：形式化验证、复杂安全审计、反复跑测试的迁移。Carbon 在 Google 的 375 项 agentic honesty 基准通过 92%，Argon 是 70%；它更少在缺数据时硬编，但验收条件仍要写硬。网络安全能力只对 Fairwind 计划里的防御者开放，普通团队别当成通用能力。
先别动的三类：
- 单文件小改、日常修 bug：Argon 或更轻的模型就够。任务小，协调与合并开销比省下的时间多。
- 高并发批量分类、抽取、改文案：Carbon 用更多 token 换质量，跑量时单位成本会被放大。Argon 更稳，延迟也更低。
- 已经通过 Fable 5.2 评测的流程：Fable 5.2 是 $8/$40，Carbon 12 月 1 日后是 $4/$20；若 Fable 在你的任务上已经跑赢，迁移前必须拿同一套验收重跑。
| 模型 | 发布价（每百万 token） | 12 月 1 日后 | 适合 |
|---|---|---|---|
| Gemini 4 Carbon | $2 输入 / $10 输出 | $4 / $20 | 长时程、多 Agent、验证循环 |
| Gemini 4 Argon | $2 / $10 | $4 / $20 | 多数软件工程和知识工作 |
| Claude Fable 5.2 | $8 / $40 | $8 / $40 | 已证明更适合的复杂工程任务 |
价格来源：Carbon 见 Google Carbon 发布文及脚注（推广期至 11 月 30 日，12 月 1 日起 $4/$20），Argon 见 Google Argon 发布文，旁证见 The Verge 与 Simon Willison；Fable 5.2 见 Anthropic 定价页。
在 API 里搭最小 swarm：官方没有这个开关
如果你不在 Antigravity 里，Gemini API 没有 swarm 参数。要在自己的服务里复现最小 swarm，得自己补计划、隔离、验证和记录。下面是编排伪代码（省略把补丁写入 worktree 的步骤，验收时按各 worker 的 worktree 收集 git -C <worktree> diff 与测试输出；参数以当前 google-genai 为准）：
import asyncio, json, subprocess
from google import genai
from google.genai import types
client = genai.Client()
MODEL = "gemini-4-carbon"
def cfg(role, level="medium", schema=None, max_tokens=8192):
return types.GenerateContentConfig(
system_instruction=role,
thinking_config=types.ThinkingConfig(thinking_level=level),
response_mime_type="application/json" if schema else None,
response_schema=schema,
max_output_tokens=max_tokens,
)
async def call(role, prompt, level="medium", schema=None):
r = await client.aio.models.generate_content(
model=MODEL, contents=prompt, config=cfg(role, level, schema))
return r.text
PLAN_SCHEMA = {
"type": "object",
"properties": {
"tasks": {"type": "array", "items": {
"type": "object",
"properties": {
"id": {"type": "string"},
"role": {"type": "string"},
"prompt": {"type": "string"},
"acceptance": {"type": "array", "items": {"type": "string"}},
},
"required": ["id", "role", "prompt", "acceptance"],
}},
},
"required": ["tasks"],
}
async def run_worker(t):
wt = f"/tmp/wt-{t['id']}" # 需先 git worktree add 创建独立目录并落地 worker 改动
out = await call(t["role"], t["prompt"] + "\n验收：" + "; ".join(t["acceptance"]), "medium")
diff = subprocess.run(["git", "-C", wt, "diff"], capture_output=True, text=True).stdout
test = subprocess.run(["pnpm", "--dir", wt, "test"], capture_output=True, text=True).stdout
return f"=== {t['id']} ===\n{out}\nDIFF:\n{diff}\nTEST:\n{test}"
async def main(brief):
plan = json.loads(await call(
"你是协调者。把任务拆成 2-4 个可并行、互不冲突的子任务。",
brief, "high", PLAN_SCHEMA))
reports = await asyncio.gather(*[run_worker(t) for t in plan["tasks"]])
verdict = await call(
"你是对抗性验证者。只根据各 worktree 的 diff、测试输出和验收条件判定，不猜。",
f"验收：{json.dumps(plan, ensure_ascii=False)}\n" + "\n".join(reports),
"high")
print(verdict)
asyncio.run(main("把 monorepo 里的 lodash 升级到 5.x，跑通全部测试"))
参数和配额上：Carbon 支持 100 万 token 的输入加输出上下文；thinking level 可配 low、medium、high，默认 medium；更高档会用更多 token，也可能更慢或超时，模型卡明确写了偶发变慢和超时。API 只在付费层开放，具体 RPM/TPM 官方发布文未给数字，需去 AI Studio 的 Rate limits 页查看项目等级。
降级别写成一条阶梯，不要只写「重试」：
- 429 或 5xx：指数退避加随机抖动，先重试当前调用，不要立刻加 worker。
- 超时：把 thinking level 降一档，缩小任务范围，或把大 diff 拆成两个。
- 配额吃紧：worker 从 Carbon 换 Argon，协调者和 verifier 保留 Carbon；再不够就减并发。
- 仍失败：退回单 Agent 串行，保留检查点和已有 diff，不要静默丢掉 verifier。
三个最容易踩的坑
把 /swarm 当成 API 开关。 它不是。你在自己的服务里写 swarm=true 不会触发任何编排；要么用 Antigravity，要么自己写协调器。
让 worker 共享一个目录。 Antigravity 用独立 git worktree 解决这个问题，自建时也必须这么做。一个 worker 一个分支，协调者只负责合并；否则并行改同一文件，冲突会把收益吃光。
验收条件写成「代码质量好」。 verifier 只能按你给的条件判断。把验收写成可执行的命令和期望输出，比如「pnpm test 全绿，pnpm build 无 warning，迁移后旧 API 的 12 个调用点全部替换」。条件越模糊，verifier 越容易放行垃圾。
另一个隐形成本是 review：swarm 一次产出多个 diff，没人审并行改动，瓶颈只会从「写」移到「审」。Graph 回放不能替你做合并决定。
结论：把 swarm 当评审流程，不是加速按钮
Carbon 这波真正的价值，是把多 Agent 的隔离工作区、共享消息板、对抗性验证和过程回放做进了产品。它适合验收清楚、改动面大、值得为验证多花 token 的任务。
这两周可以按这个顺序做：
- 选 3 个任务，写死验收命令，先用 Argon 单 Agent 跑基线。
- 同样的 brief 用 Carbon 加 /swarm 跑一遍，记录每个被接受结果的成本和 review 时间。
- 只把「Carbon 明显赢、且 review 接得住」的任务放进迁移清单；跑量任务留在 Argon。
- 12 月 1 日前把评测做完，别把「低价」当成「低成本」。
如果你不想自己维护消息板和任务记录，可以用 HiFox 的小队做收口：队长 Agent 拆任务并协调，成员按各自 Agent 的工作目录配置执行（可选用 Worktree 隔离运行），运行记录和结果回到同一个任务。参考《小队》和《Agent 如何执行任务》。工具只是工具，先把验收和记录建起来，再谈并行。
HiFox
