计量计费与预算强制 — 三家定价与 TCO 输入

日期: 2026-09-30 阶段: Phase 4 - 自建 Agent 平台×求职冲刺 标签: #metering #budget-enforcement #tco-pricing

核心问题

一个 agent 平台跑起来，第一个失控的就是钱。模型 token 按量计费、托管运行时按 vCPU·秒计费、记忆/网关/可观测各有一张账单——不设强制就会出现「一个死循环的 agent 一夜烧掉四位数」。今天回答三件事：

1. 怎么计量？ per-agent / per-session 的 token + 成本计量算法——计到哪个粒度、何时累加、超限怎么办（拒绝 vs 降级）。
2. 怎么升级自有底座？ P1/P2 已有 src/agent/shared/cost.ts（模型定价表 + estimateCost）和 src/agent/orchestrator/budget.ts（步数/工具调用/成本/超时四道闸）。今天把它从「单跑预算」升级到「会话级计量 + 强制」。
3. 三家托管多少钱？ 横向采集 AgentCore / Foundry / Agent Engine 的全部计费组件——这是作品集求职铁律（产品结果 + eval 数字 + 单位成本）的「单位成本」那一项，也是 Day 109 选型矩阵的定价维度输入。

对 AML：单位成本（$/案）是产品能否商业化的硬指标——P3 Day 89 已算过 AML Copilot 的 unit cost。Day 108 把它从「一次算」变成「实时计量 + 预算闸」，让平台自己守住成本上限。

关键内容

A. 计量算法：粒度、累加点、超限策略

计量的三个设计决策：

决策 1：粒度——per-session 为主，per-agent 为聚合维度。 一个 session 是一次「调查」的成本单元（对应一个 caseId），per-agent 是跨 session 聚合（这个 agent 总共花了多少）。计量根 key 复用 Day 106 的 (tenantId, sessionId)，再带 agentId 做聚合维度。

决策 2：累加点——每次 LLM 调用后、每次工具调用后立即累加。 不能等会话结束再算（那时钱已经花了）。每次模型返回，读 usage.input_tokens / output_tokens，调 estimateCost(model, in, out) 折算 USD，立即累加进会话计量器。

决策 3：超限策略——分级，不是一刀切拒绝。 这是关键。budget.ts 现在的 assertCostOk() 是硬抛错（超限即 throw）。但生产里「直接拒绝」对用户体验是灾难——调查到 90% 被一刀切掉。应分级：

[超限分级强制 状态机]
   每次 LLM/工具调用后：meter.add(cost)
                │
                ▼
   cost vs cap 比值 r = cost / costCap
   ┌────────────┬────────────┬───────────────┐
   r < 0.8      0.8 ≤ r < 1.0   r ≥ 1.0
   │            │               │
   ▼            ▼               ▼
 正常        [降级 DEGRADE]   [拒绝 REJECT]
 继续        · 切更便宜模型    · 拒绝新的 LLM 调用
            （opus→haiku）    · 但允许"收尾"动作
            · 关闭非必要工具    （写已有结果、落 checkpoint）
            · 提示用户接近上限  · 抛 BudgetExceeded

降级的核心是模型路由：从 cost.ts 的定价表看，claude-4-7-opus 是 $15/$75 per M（in/out），claude-haiku-4-5 是 $0.8/$4——降级一档省 ~19×。AML 场景：到 80% 预算时，把「润色 SAR 叙事」这种非关键步骤从 opus 降到 haiku，把预算留给「制裁名单匹配」这种关键步骤。

计量器伪代码（升级 budget.ts）：

interface SessionMeter {
  tenantId: TenantId; sessionId: SessionId; agentId: string
  inputTokens: number; outputTokens: number; costUsd: number
  // 每次模型调用后累加，返回当前强制档位
  record(model: string, inTok: number, outTok: number): 'OK' | 'DEGRADE' | 'REJECT'
}

function record(m: SessionMeter, model, inTok, outTok): Tier {
  m.inputTokens += inTok; m.outputTokens += outTok
  m.costUsd += estimateCost(model, inTok, outTok)  // 复用 cost.ts
  const r = m.costUsd / m.capUsd
  if (r >= 1.0) return 'REJECT'      // 拒绝新 LLM 调用，仅允许收尾
  if (r >= 0.8) return 'DEGRADE'     // 触发模型降级 + 关非必要工具
  return 'OK'
}

反直觉洞察①（硬拒绝比超支更危险）：直觉「超限就拒绝最安全」。但对长会话，硬拒绝会让已经花掉的钱全部打水漂——调查到 95% 被砍，前面 95% 的 token 钱白花，且用户得从头重来再花一遍。分级降级（先降模型档、保收尾）的总成本反而更低，因为它保住了已投入的沉没成本不浪费。「拒绝」要拒绝的是新增成本，不是已有进度。

B. 三家托管定价横向采集（2026-06 口径，执行当周重新确认）

托管 agent 平台的计费都是多组件纯消耗，没有单一「每会话价」。逐项采集三家一手定价页：

AWS Bedrock AgentCore（aws.amazon.com/bedrock/agentcore/pricing，12 计费组件，5 种计费模式）：

Microsoft Foundry Agent Service（azure.microsoft.com/pricing/details/foundry-agent-service）：

• Runtime：$0.0994 / vCPU-hour（scale-to-zero，2026-04-22 口径），内存 $0.0118 / GiB-hour
• Memory（2026-06-01 起计费）：短期 $0.25/1K events，长期 $0.25/1K memories·月，检索 $0.50/1K retrievals
• Evaluations：GA（2026-03），内置/自定义评估器

Google Agent Engine（cloud.google.com/products/gemini-enterprise-agent-platform/pricing）：

• Runtime：$0.0864 / vCPU-hour（2025-12-16 口径），内存 ~$0.0105/GiB-hour
• Sessions/Memory Bank events：$0.25 / 1,000 events·或·memories（2026-01-28 起计费）
• 免费层：50 vCPU-hours + 100 GB-hours 内存/月

三家 Runtime 计算单价并排：

C. 为什么计算单价差异是「噪声」：token 主导定律

B 节的表格有个陷阱：盯着 $0.0864 vs $0.0994（差 ~15%）选平台，是抓错了大头。多个第三方对比（AgentMarketCap Q2 2026）口径一致：

"Model tokens will dominate agent costs by 10-100× regardless of hosting platform, with compute cost differences between Foundry, Vertex, and Bedrock rarely moving the total bill by more than 2-3%."

做个数量级估算。一次中等 AML 调查：~30 次 LLM 调用，平均每次 4K input + 1K output token。若用 claude-4-7-opus（$15/$75 per M）：

• Token 成本 = 30 × (4000/1e6 × 15 + 1000/1e6 × 75) = 30 × (0.06 + 0.075) = $4.05
• Runtime 成本（假设会话活跃 CPU 10 分钟、1 vCPU、2GiB）= (10/60 × 0.0895) + (10/60 × 2 × 0.00945) ≈ 0.0149 + 0.0032 = $0.018

Token : Runtime ≈ 4.05 : 0.018 ≈ 225 : 1。换平台让 Runtime 差 15%，影响总账单 0.06%。而把 opus 降到 haiku（B 节降级）省的是那 225 份里的大头——token 成本降 ~19× 到 $0.21，总账单立省 95%。

把这条算式推广成一个「优化收益排序」：同样花一周工程时间，(1) 把热路径模型从 opus 降到 haiku → 省 ~95%；(2) 给重复 prompt 前缀上缓存（P2 semanticCache.ts）→ 省命中部分的 input token；(3) prompt 压缩/裁剪检索上下文 → 省 input token；(4) 在三家 vCPU 单价间换平台 → 省 0.06%。第 4 项的 ROI 比前三项低三个数量级，却是直觉最先想到的。这就是为什么 Day 89 的 unit-cost 分析里，「降一档模型」永远是第一杠杆。

反直觉洞察②（选平台省的钱在小数点后，省钱在模型路由）：99% 的成本优化精力应该花在模型选择与 token 削减（缓存、prompt 压缩、降级路由），而非在三家 vCPU 单价之间反复横跳。但有一个例外会反咬：Observability 无上限——AgentCore 的 CloudWatch 是「按标准计费、无封顶」，一个 trace 打满日志的 agent 能让可观测费失控。token 是大头，但失控的隐性账单藏在「无上限」的可观测/日志里——这是托管平台最容易被忽略的成本陷阱。

D. TCO 模型：把计量喂成单位成本

把 A 的计量 + B 的定价组装成一个 per-case TCO 公式，作为 Day 109 选型矩阵的定价维度输入：

TCO_per_case =
    Σ(LLM 调用) [in_tok × in_price + out_tok × out_price]    ← 大头（~225×）
  + 活跃 CPU 秒 / 3600 × vCPU 数 × vCPU_price
  + 峰值内存 GB × 会话秒 / 3600 × mem_price
  + 工具调用数 / 1000 × gateway_price
  + memory events / 1000 × event_price
  + 授权请求数 × policy_price                                 ← 自建可省
  + observability（按日志量，⚠️ 无上限项需封顶告警）

自建 vs 托管的 TCO 结构差异：自建省掉 Runtime/Gateway/Policy/Memory 的平台 markup（只付底层 EC2/K8s + 模型 token），但自己承担工程与运维人力。AISA 选型口径：小规模、token 主导时，托管的 markup 是噪声，省的是工程时间；大规模、高并发时，自建省的 markup 才显著。本项目（教学装置 + 单产品）选自建是为了展示能力，不是为省钱——这点要在作品集诚实说清。

设计要点/决策表

对本项目的落地

• 升级 src/agent/orchestrator/budget.ts：现有 Budget 的 assertCostOk() 是硬抛错（cost > costCapUsd 即 throw）。新增分级：导出 tier(): 'OK' | 'DEGRADE' | 'REJECT'（按 cost()/costCapUsd 的 0.8/1.0 阈值），保留 assertCostOk() 兼容旧调用但在 REJECT 档才抛。makeBudget 不破坏现有四道闸（步数/工具/成本/超时）。
• 新建 src/agent/runtime/sessionMeter.ts：实现 A 节 SessionMeter，key 用 Day 106 的 SessionKey + agentId，record(model, inTok, outTok) 复用 src/agent/shared/cost.ts 的 estimateCost/MODEL_PRICES 折算 USD 并返回档位。导出 degradeModel(current): string（opus→sonnet→haiku 路由表）供 DEGRADE 档调用。
• 新建 src/agent/shared/platformPricing.ts：把 B 节三家定价表录成常量（带 asOf: '2026-06' 字段和 recheckRequired: true 注释），导出 tcoPerCase(usage, platform) 实现 D 节公式——供 Day 109 选型矩阵的定价维度直接调用。诚实标注：价格为 2026-06 一手定价页采集，执行当周须重新确认（计费项常变）。
• CostMeter UI 升级：src/agent/ui/CostMeter.tsx（P1 已建，显示累计成本）加档位条——绿(<0.8)/黄(0.8-1.0)/红(≥1.0)三段，到黄档显示「已降级到 haiku」提示，到红档显示「仅允许收尾」。让作品集能演示预算强制而非只显示数字。金额纪律：内部累加用整数微分（micro-USD）避免浮点误差，展示时再折算。

参考资料

1. AWS — Amazon Bedrock AgentCore Pricing：Runtime $0.0895/vCPU-h + $0.00945/GB-h（按秒，1s 起，128MB 最低）；Gateway $0.005/1K + Search $0.025/1K；Memory 短期 $0.25/1K、长期内置 $0.75/1K·月、检索 $0.50/1K；Identity $0.010/1K（经 Runtime/Gateway 免费）；Policy $0.000025/授权 + NL $0.13/1K in；Eval 内置 $0.0024/1K in + $0.012/1K out；Observability 按 CloudWatch（2026-06）
2. Microsoft Azure — Foundry Agent Service Pricing：Runtime $0.0994/vCPU-h scale-to-zero + $0.0118/GiB-h；Memory 2026-06-01 起 短期 $0.25/1K、长期 $0.25/1K·月、检索 $0.50/1K（2026-04~06）
3. Google Cloud — Gemini Enterprise Agent Platform / Agent Engine Pricing：Runtime $0.0864/vCPU-h + $0.0105/GiB-h；events $0.25/1K（2026-01-28 起）；免费层 50 vCPU-h + 100 GB-h/月（2025-122026-06）
4. AgentMarketCap — AWS AgentCore vs Azure vs Google Q2 2026 Managed Agent Runtime Comparison：「model tokens dominate by 10-100×」「compute 差异 rarely >2-3% of total bill」；AgentCore 消耗计费仅按实际 CPU（2026-04-09）
5. Cloud Burn — Amazon Bedrock AgentCore Pricing: 12 Components Breakdown：12 组件 5 计费模式（per-session active / per-request / per-record / pass-through / free-preview）(2026)
6. 本仓库 src/agent/shared/cost.ts（MODEL_PRICES/estimateCost，2026-05 快照）、src/agent/orchestrator/budget.ts（四道闸）、src/agent/ui/CostMeter.tsx（成本展示）(2026-06)

SOTA 检查 (2026-06-11)

• 「多组件纯消耗计费」是 2026-06 托管 agent 平台的统一形态：三家都无「单一会话价」，全是 Runtime（vCPU·h）+ Memory（events/records）+ Gateway/Tools + Eval/Policy 的组合。AgentCore 12 组件最细。本日 WebSearch 未见有平台回到打包定价。
• 「token 主导、平台单价是噪声」在 2026-06 是第三方共识：多家对比（AgentMarketCap/Bits Lovers）口径一致——10-100× token 占比，vCPU 差异 2-3%。这条定律稳定，是选型「不要为 15% vCPU 差换平台」的依据。
• 价格高频变动，必须当周重确认：Foundry Memory 计费 2026-06-01 才起、Agent Engine events 2026-01-28 才起、AgentCore Browser profile 存储 2026-04-15 新增——计费项几个月就变一次，本笔记所有数字标 2026-06 口径，platformPricing.ts 须带 asOf 与 recheck 提醒。
• 过时认知警示：「设个成本上限、超了抛错就行」过时——A 节证明硬拒绝浪费沉没成本，生产级要分级降级；「Observability 是小钱」过时——AgentCore CloudWatch 无上限是真实失控源。
• 待跟踪：AgentCore Policy/Evaluations/Payments 三项 2026-06 仍 preview，转 GA 后定价可能调整；Foundry/Agent Engine 的 Policy 等价物定价待补，回填 B 节表。