AI Agent 开始承担持续运行、批量执行和多步骤协作的任务后，企业面对的成本问题已经不同于传统的软件订阅。业务用户可能每天稳定使用生产力工具，开发团队却可能在发布前集中运行大量代码 Agent，后台 Agent 还会在夜间持续消耗模型推理资源。只按“每个用户多少钱”来管理，往往看不见真实的运行成本，也很难在创新和预算之间取得平衡。
面向 Gemini Enterprise 及相关开发工具，新的计费和成本控制思路可以概括为：固定订阅负责可预测的日常使用，按量付费承接突发或弹性工作负载，统一配额和预算护栏负责治理，长期稳定的 Token 消耗则可以通过 Flexible Savings Plans 降低单价。
从单一订阅转向组合式计费
Gemini Enterprise 的用户席位订阅适合使用模式稳定的团队。企业按用户支付固定月费，项目内共享每日配额池，财务团队可以据此建立清晰的月度预算基线。
对于使用量波动明显的团队，新的 pay-as-you-go consumption edition 不要求预付订阅费或基础承诺费用，而是按照实际消耗的计算资源和 Token 计费。项目需求下降时，成本也会随之下降，避免为暂时不用的席位持续付费。该选项目前面向部分客户开放，并逐步扩大范围。
更重要的是，企业可以组合这些模式，而不必把所有团队塞进同一套计费模型：
- 业务团队使用按用户订阅，获得稳定的日常生产力配额。
- 开发团队和自定义 Agent 使用按量付费，应对发布、迁移或批处理期间的峰值。
- Antigravity、Android Studio AI、Gemini Enterprise 平台和应用侧使用量可以汇总到统一视图中，减少独立许可证和账单孤岛。
- 对支持的 Antigravity 工作负载，开发工具配额可以在 Google Cloud 项目范围内池化，让未使用的业务用户配额吸收开发侧的短时高峰。
池化配额通常会优先消耗；管理员可以决定是否允许超额。允许超额后，超出部分按按量付费价格计费。这样既能提高已购买配额的利用率，也保留了明确的成本开关。
用承诺换单价，但不要把承诺当成预测
如果 AI 工作负载稳定或持续增长，Gemini Enterprise Flexible Savings Plans 可以把“稳定的月度支出承诺”转换为 Token 成本折扣：一年期承诺可获得 10% 折扣，三年期承诺可获得 20% 折扣。该计划没有最低或最高支出要求，支出还可以计入现有 Google Cloud Enterprise Agreement，避免形成新的账单孤岛。
这里有一个容易被忽略的边界：FSP 适合可预测的基础流量，不适合用来掩盖尚未验证的 Agent 业务模式。上线初期，团队可能还不知道每个任务的平均 Token 数、重试率和成功率。此时更稳妥的做法是先用按量付费观察实际曲线，再决定承诺规模，并随着用量增长调整月度承诺。
可以把成本拆成三层：
- 基线流量：稳定的日常问答、代码辅助和业务自动化，适合席位订阅或 FSP。
- 弹性流量：发布前批量分析、数据清洗和突发 Agent 任务，适合按量付费。
- 可延迟流量：不要求立即完成的报告、索引和批处理，适合使用即将提供的 deferred execution pricing，在非高峰容量窗口运行，并可能获得最高约一半的推理成本折扣。
把预算护栏放到项目边界
Agent 成本治理不能只看月底账单。一个任务的循环调用、工具重试或异常提示词，都可能在几小时内造成明显的预算偏差。因此，治理工具需要覆盖“估算、监控、暂停、恢复”四个动作。
Google Cloud Billing Console 提供的方向包括：
- 使用 Pricing Calculator，在项目启动前估算用户席位、开发工具和后台 Agent 运行成本。
- 通过 Early Anomaly Detection 识别异常支出趋势，并给出根因分析和贡献最大的三个 SKU。
- 为项目设置月度硬上限，并在达到上限时暂时暂停 Agent API 调用；达到 50%、80% 和 100% 时发送邮件提醒。
- 预算触发后，可以手动恢复运行，也可以开启 overage，让超额用量切换到按量计费。超额支出还可以从 FSP 中扣减，以继续获得折扣后的单位成本。
- 将集中式账单报告与 FinOps agent 结合，生成自然语言成本摘要，帮助团队说明预算花在了哪里，以及是否产生了业务价值。
一个可改造的成本预算检查脚本
下面的 Python 示例不是 Google Cloud Billing API 的替代品，而是一个可以放入 CI、定时任务或项目审批流程的本地预算检查器。运行前请根据实际模型价格修改 price_per_million_tokens，并将输入数据替换成账单导出或内部用量统计。
#!/usr/bin/env python3
from dataclasses import dataclass
@dataclass
class ProjectUsage:
name: str
input_tokens: int
output_tokens: int
price_per_million_tokens: float
monthly_cap: float
@property
def estimated_cost(self) -> float:
total_tokens = self.input_tokens + self.output_tokens
return total_tokens / 1_000_000 * self.price_per_million_tokens
projects = [
ProjectUsage(
name="agent-prod",
input_tokens=48_000_000,
output_tokens=12_000_000,
price_per_million_tokens=8.0, # 按实际合同或模型价格修改
monthly_cap=500.0,
),
ProjectUsage(
name="agent-batch",
input_tokens=90_000_000,
output_tokens=25_000_000,
price_per_million_tokens=8.0,
monthly_cap=1_000.0,
),
]
for project in projects:
cost = project.estimated_cost
ratio = cost / project.monthly_cap
status = "BLOCK" if cost >= project.monthly_cap else "WARN" if ratio >= 0.8 else "OK"
print(f"{status:5} {project.name:16} ${cost:8.2f} / ${project.monthly_cap:.2f}")
if any(p.estimated_cost >= p.monthly_cap for p in projects):
raise SystemExit("one or more projects exceeded the monthly cap")
在生产环境中，可以把这个检查器接到每日账单导出、Cloud Scheduler 或 CI 审批流程中，并把 BLOCK 状态映射到项目级配额暂停、工单创建或通知系统。真正的硬上限仍应配置在 Billing Console 或相应的云治理接口中，脚本适合做提前预警和变更门禁。
采用时的决策清单
不要一开始就给所有团队启用同一种计费方式。可以按下面的顺序落地：
- 为每个项目标记工作负载类型：稳定交互、弹性 Agent、可延迟批处理。
- 记录输入 Token、输出 Token、平均任务时长、重试率和任务成功率。
- 为开发、测试和生产项目分别设置预算上限，避免共享项目掩盖真实成本。
- 先用按量付费验证用量曲线，再为稳定的基线流量配置 FSP。
- 明确超额策略：预算优先的项目自动暂停，连续运行优先的项目允许 overage。
- 定期检查异常 SKU 和 Agent 的业务产出，而不只关注 Token 总量。
AI FinOps 的目标不是限制团队使用 Agent，而是让每次扩容都带着可解释的成本边界。固定订阅提供预测性，按量计费提供弹性，配额池和项目上限提供控制，Savings Plans 则为已经验证的稳定用量降低单价。企业真正需要管理的，不只是账单金额，还有每个 Agent 任务消耗的资源是否换来了足够的业务价值。