token economics 决策框架 — 15× 成本何时换得回 +90.2%

日期: 2026-07-16 阶段: Phase 2 - AI-native 参考架构 标签: #token-economics #cost-quality-tradeoff #budget

核心问题

Day 29 给了多 agent 的「+90.2% 质量 / 15× token」这对数字，Day 31 又证明这优势高度条件化。现在到了把它变成一条可执行的成本决策的时候：作为 PM，我该用什么框架判断「这个任务值不值得付 15× token 走多 agent」？

三个具体问题：

1. 「15× token 换 +90.2%」的盈亏平衡点在哪？什么样的任务复杂度之上才划算？
2. 代入本项目 AML 基线，用真实 Claude 计价算一笔账，单 agent vs 多 agent 各花多少？
3. 这条成本-质量边界，怎么落到 budget.ts 的 costCapUsd 上，变成代码级闸门？

这不是抽象算账。orchestratorAgent.ts 已经按「Opus 4.8 当 lead + Sonnet 4.6 当 subagent」分配模型，budget.ts 留了 costCapUsd 字段但还没接真实计价。今天把这个框架补上。

关键内容

A. 盈亏平衡的本质：质量提升必须越过「价值×成功率」的门槛

先把 Day 29 的数字翻译成单位经济。设：

• $C_1$ = 单 agent 一次任务的 token 成本，$C_m$ = 多 agent 一次的成本，Day 29 给 $C_m \approx 15 \times C_{chat}$、$C_1 \approx 4 \times C_{chat}$，故 $C_m / C_1 \approx 3.75$（多 agent 约是单 agent 的 3.75 倍，不是 15 倍——15× 是相对 chat，别搞混）。
• $p_1, p_m$ = 单/多 agent 把任务做对的概率；$V$ = 一次任务做对的业务价值；$L$ = 一次做错的损失（AML 漏报罚款/合规风险）。

单次任务的期望净收益：

$$E = p \cdot V - (1-p)\cdot L - C$$

多 agent 比单 agent 划算，当且仅当 $E_m > E_1$：

$$\underbrace{(p_m - p_1)}{\Delta p\ \text{质量增益}} \cdot (V + L) ;>; \underbrace{C_m - C_1}{\Delta C\ \text{多花的钱}}$$

整理出盈亏平衡的质量增益门槛：

$$\boxed{\Delta p^* = \frac{C_m - C_1}{V + L}}$$

含义极清楚：任务的「对错价差」$(V+L)$ 越大，需要的质量增益门槛 $\Delta p^*$ 越低——多 agent 越容易划算。 反过来，低价值任务（$V+L$ 小）哪怕多 agent 能 +20% 准确率也不值得，因为分母太小、门槛被推得很高。

反直觉洞察①（决定要不要多 agent 的，不是「能提升多少准确率」，而是「这个任务做错的代价」）：工程师习惯问「多 agent 能涨几个点」，但公式说了算的是分母 $(V+L)$。同样 +5% 的 $\Delta p$，在「闲聊问答」（$V+L$ 小）上是纯烧钱，在「漏报一笔洗钱被监管罚 500 万」（$L$ 巨大）上则远远值回 3.75× 成本。AML 的特殊性正在于 $L$ 极大——这让它成为少数「质量增益门槛极低、多 agent 容易划算」的场景，恰好与 Day 31「多数任务单 agent 即够」的普适结论相反。 但前提是这个任务还得满足 Day 29/31 的「广度可分解」条件，否则多 agent 连 $\Delta p>0$ 都做不到。

B. 代入 AML 基线的真实计价（Claude API，2026-06）

用 Claude 官方计价（platform.claude.com，2026-06）：Opus 4.8 = $5/MTok 输入、$25/MTok 输出；Sonnet 4.6 = $3/MTok 输入、$15/MTok 输出；cache 命中 = 0.1× 输入；Batch = 全价 5 折。

本项目模型分配：lead = Opus 4.8，subagent = Sonnet 4.6。算一次「AML 批量复核 3 笔告警」的多 agent 运行（保守估算 token）：

对照单 agent（Opus 4.8 一趟把 3 笔串行做完，上下文更长但无并行冗余）：

实测 $C_m/C_1 \approx 0.50/0.35 \approx 1.43$——比 Day 29 的「3.75×」低得多。原因有二：(1) subagent 用便宜的 Sonnet 而非 Opus；(2) prompt caching 把 lead 重复的系统提示压到 0.1×。这印证 Day 29 SOTA 检查的判断：caching+模型分级会把实测倍数压下来。

要理解这个 1.43× 是怎么从 Day 29 的 3.75× 缩水来的，得看成本结构的非对称性。多 agent 的总成本里，最大的一块是「三个 subagent 各自数万 token 的检索输入」（B 表里 $0.27，占了一半多）。Anthropic 原话假设 subagent 和 lead 同档模型，所以这块按 Opus 计价会贵得多；而本项目把 subagent 降到 Sonnet（输入 $3 vs Opus $5、输出 $15 vs $25），这块直接打了六折。更狠的是输出 token——Opus 输出是 Sonnet 的 1.67 倍单价，而 subagent 的输出（检索摘要）恰恰是 token 大头之一，降档收益被放大。再叠加 lead 系统提示的 cache 命中（0.1×），整套多 agent 的「溢价」就从理论的 3.75× 被压到实测 1.43×。这说明 Day 29 那个吓人的「15× / 3.75×」是「全 Opus、无缓存」的上界，不是工程化后的真实数字。

把 B 的数字代回 A 的门槛公式：设一笔 AML 复核做对价值 $V$≈$2（省人工），做错损失 $L$ 取保守的「漏报期望罚款摊销」≈$50：

$$\Delta p^* = \frac{C_m - C_1}{V+L} = \frac{0.50-0.35}{2+50} = \frac{0.15}{52} \approx 0.29%$$

只要多 agent 能让复核准确率提升超过 0.29 个百分点，就划算。 这门槛低到几乎必然满足——前提仍是任务「广度可分解」（3 笔独立告警正好是）。

把这个 0.29% 放到对比里才能体会它有多低：一般产品里「多花 43% 的钱换 0.29% 准确率」是想都不用想的亏本买卖，因为分母 $(V+L)$ 太小。AML 的特殊性全在那个 $L=$50$ 上——而且这还是极度保守的取值。真实场景里单笔重大漏报的监管处罚可达数百万美元，按发生概率摊销到每笔告警上，$L$ 可能是几百甚至上千美元，门槛 $\Delta p^*$ 会进一步压到 0.01% 量级。换句话说，在 AML 这种「错误代价被监管放大」的领域，「多 agent 是否值得」几乎不取决于成本，而完全取决于「任务能不能分解」——成本侧的天平已经被巨大的 $L$ 彻底压向「值得」。这正是金融合规场景与普通消费级 AI 产品在 token 经济上的根本分野：消费级产品盯成本，合规级产品盯漏判损失。

反直觉洞察②（真实账单里，模型分级 + 缓存比「要不要多 agent」更能省钱）：从 B 表看，多 agent 比单 agent 只贵 43%，但如果把 subagent 从 Sonnet 换成 Opus，sub 那一行从 $0.27 飙到 $0.45，$C_m$ 直接破 $0.68，倍数跳到 1.9×。也就是说，「subagent 用 Sonnet 还是 Opus」这个选择对成本的影响（+36%），和「单 agent 还是多 agent」（+43%）是同一量级。 PM 盯着「多 agent 贵」时，往往忽略了真正的成本杠杆其实是模型分级和缓存——这两个旋钮拧对了，多 agent 的溢价就没那么吓人。Batch（5 折）和 cache（0.1×）能再砍一半。

C. 决策框架：四象限 + 三道闸

把 A 的门槛公式做成 PM 可用的四象限（横轴=任务对错价差 $V+L$，纵轴=是否广度可分解）：

注意右下角：即便价差巨大（如单案深度调查 $L$ 极高），只要任务深度耦合、不可分解，仍走单 agent——因为 Day 31 证明深度耦合下多 agent 因 communication bottleneck 会丢信息，$\Delta p$ 可能为负，公式右边再大也救不回来。

落到代码是三道闸（递进，前两道软、第三道硬）：

[闸1·路由判据] 任务进来 → 落四象限哪格？
   └─ 仅「广度可分解 ∧ 高价差」格 → 启用 orchestrator；否则单 agent
[闸2·预算估算] 启用前用 B 表的 token 估算预估 C_m
   └─ 预估 C_m > 该任务的 (V+L) → 拒绝升级，回落单 agent
[闸3·运行时硬闸] budget.ts 在运行中累计真实 token×单价
   └─ cost > costCapUsd → 抛错中断（防 Day 29 的 subagent 暴增烧穿预算）

设计要点/决策表

对本项目的落地

• 给 budget.ts 接真实计价：当前 addCost(usd) 是空壳、costCapUsd 无数据喂入。计划在 orchestratorAgent.ts 的每个 sub-agent onSubAgentEnd（已带 usage: { inputTokens, outputTokens }）回调里，按 B 节单价表算出该步成本并 budget.addCost()，让 assertCostOk() 用真实累计值判 cost > costCapUsd。costCapUsd 初值可设为单任务 $(V+L)$ 的一个保守分数（如 $L$/100），对应 C 节闸2/闸3。
• costCapUsd 的默认值要按四象限分档：广度任务给较高 cap（容得下 $C_m≈$0.5），深度单案任务给极低 cap（强制走单 agent，超一点点就中断）。这把 C 节的路由判据从「靠 prompt 自觉」升级为「靠预算物理隔离」——即使 lead 误判要 spawn subagent，深度任务的低 cap 也会拦下。
• 模型分级已对、缓存待补：OrchestratorOpts 里 modelOrchestrator（Opus）和 modelSubAgent（Sonnet）的分离设计正确（对应 B 节反直觉②的成本杠杆）。下一步计划给 lead 的 ORCHESTRATOR_SYSTEM 加 cache_control，把固定系统提示打到 0.1× 命中价——这是单任务级别最大的一笔可省成本。
• AML 的 $L$ 极大这一点，要写进路由策略而非埋在代码：依据 A 节反直觉①，AML 漏报损失 $L$ 巨大使「质量增益门槛」极低，这是本项目敢在批量复核上用多 agent 的核心理由。但必须配 Day 31 的 pass^k 可靠性闸——高 $L$ 场景同时要求高准确率和高一致性，二者缺一不可。这条经济判据应进 orchestratorPrompt.ts 的分解策略注释，让模型理解「为什么 AML 批量值得多花钱」。
• 诚实标注：B 节 token 数为保守估算、$V/L$ 为示意值，真实值须 W 后续用 AML 实跑数据回填；addCost 接线、cache_control、按象限分档的 costCapUsd 均为 P2 计划项，当前 budget.ts 仅有结构未接真实计价。

参考资料

1. Anthropic Engineering — How we built our multi-agent research system：+90.2% over single-agent；agents≈4× chat token、multi-agent≈15× chat token；「multi-agent systems require tasks where the value is high enough to pay for increased performance」 (2025-06)
2. Anthropic — Claude API Pricing（platform.claude.com）：Opus 4.8 $5/$25 per MTok、Sonnet 4.6 $3/$15、Haiku 4.5 $1/$5；prompt cache 命中 0.1× 输入、5m 写 1.25×；Batch API 5 折；1M context 无长上下文加价 (2026-06)
3. Anthropic Engineering — Effective context engineering for AI agents：subagent 数万 token 探索→回 1-2K 摘要，配合 caching/compaction 压成本 (2025-09)
4. Princeton HAL（arXiv 2510.11977）：成本-准确率 Pareto，「some agents drastically more expensive while only marginally better」——经济判据来源 (2025-10)
5. 本仓库 src/agent/orchestrator/budget.ts（addCost/costCapUsd/assertCostOk）、src/agent/orchestrator/orchestratorAgent.ts（onSubAgentEnd 带 usage、Opus/Sonnet 分级） (2026-06)

SOTA 检查 (2026-06-11)

• 「价值/成本驱动的 agent 编排选型」在 2026-06 是主流框架共识：Anthropic 原文、Princeton HAL、各 AI gateway（LiteLLM 的 virtual key+预算、Bifrost 语义缓存、Portkey）都在围绕「按任务价值分配 token 预算」做产品；语义缓存可降推理成本 40-70%（2026-06 快变口径），是本笔记成本杠杆之外的又一旋钮，P3 规模化时评估接入。
• Claude 计价的两个 2026 变量：(1) Opus 4.7+ 换了新 tokenizer，同文本可能多用最多 35% token——B 节 token 估算须按此上修；(2) Fast mode（Opus 4.8 $10/$50）在低延迟场景会改变成本结构。引用具体单价须带访问月份，执行当周重新核对官方 pricing 页。
• 盈亏门槛公式 $\Delta p^*=(C_m-C_1)/(V+L)$ 是单位经济常识、非新发现：但 2026 仍多见「只比准确率不比单位经济」的选型（HAL 的核心吐槽），故本笔记反直觉①（看 $V+L$ 不看 $\Delta p$）仍是 live 踩坑点。
• 过时认知警示：「多 agent 必然贵 15×」已过时——B 节实测在模型分级（Sonnet sub）+缓存下只贵 ~43%。把 15× 当成多 agent 的固定税，会错误地一刀切否掉所有多 agent 方案。真实倍数取决于模型分级/缓存/batch 三个旋钮。
• 待跟踪：W 后续用 AML 实跑数据回填 $V/L$ 与 token 估算，验证 0.29% 门槛是否成立；budget.ts 接真实计价后，离线画成本-准确率 Pareto（呼应 Day 31 HAL），确认 orchestrator 模式落在前沿。