08 · PLAN/Cost & Concurrency

成本与并发预算

「项目最多花多少 token / 多少钱 / 跑多久 / 几个 agent 并发」的数字版。预算守护机制在 P-7,本页给具体数字。

① 单次调用 Token 估算

Agent模型输入 ≈输出 ≈典型 / 单次调用备注
PMSonnet 4.64K (memory + prd)8K (新 PRD 章节 HTML)12Kincremental ≈ 5K
Architect generateOpus 4.715K (PRD + sdd + memory)20K (4 MVCP 页 + JSON)35K含全套 SDD
Architect patchOpus 4.78K3K11K仅改一段
Coder implementSonnet 4.66K (sdd + upstream contracts)4K (code + contract.json)10Kper Unit
Coder retrySonnet 4.68K (含 history)3K (差量 patch)11K反思加 ~2K
TesterSonnet 4.65K4K (vitest spec + result)9Kper Unit
IntegratorSonnet 4.68K (units + spec)3K11KL2 单轮
BugTriagerOpus 4.712K (含 code + logs)3K (triage.json)15K归因质量决定 L2 收敛

② 典型项目总成本估算

2.1 小项目(TODO API · demo)

3 个 Unit · 1 个 PRD rev · 1-2 个 L2 round。

调用次数Token
PM init112K
Architect generate135K
Coder × 3 unit × 1.5 attempt(平均)4.545K
Tester × 3 unit × 1.5 attempt4.540K
Integrator111K
BugTriager(如失败 1 次)0.58K
合计14.5≈ 150K tokens

2.2 中项目(Auth + TODO + Profile · 5 feature)

8 个 Unit · 2 个 PRD rev · 2 个 L2 round。

调用次数Token
PM init + incremental × 1217K
Architect generate + patch × 1246K
Coder × 8 unit × 2 attempt16165K
Tester × 8 unit × 2 attempt16145K
Integrator × 2222K
BugTriager × 1115K
合计39≈ 410K tokens

2.3 默认 token_budget = 5M 的隐含假设

5M 是单项目预算上限,能撑:

  • ~33 个小项目(150K each)
  • ~12 个中项目(410K each)
  • 1 个大型迭代(多人多反馈、20+ Unit)

到达 80% 预算时发 SSE warning;100% 直接挂起。

③ 美元成本(参考 2026-05 价格)

按 Anthropic 公开价格估算(input/output 分别计),中项目场景:

模型输入 ($/MTok)输出 ($/MTok)本项目消耗美元 ≈
Sonnet 4.6~$3~$15input 220K · output 100K$2.2
Opus 4.7~$15~$75input 50K · output 25K$2.6
中项目合计——410K tokens≈ $4.8
小项目合计——150K tokens≈ $1.7

数字是 ballpark。实际取决于 caching 命中率(SessionPool 复用降低 input 重复成本)和具体功能复杂度。

④ 并发预算

三层并发上限:

层级上限原因实现
项目内 L1 并行≤ 5 Unit 同时跑每个 Claude CLI ~ 100MB RAM · 1 CPU corescheduler.getExecutionGroups 自动分波,每波 ≤ 5
项目内 L2 串行1 个 Integrator 实例避免端口冲突 + 状态混乱LoopController 内部用 Promise 队列
单机系统并发≤ 20 个 ACP session合理 RAM 占用 ≈ 2GBSessionPool 全局上限(新增 maxSessions 配置)
同 company 项目并发≤ 3 项目同时跑避免单用户挤占LoopController 入口检查
Bash 进程(Coder/Tester/Integrator 起的)≤ 50 系统总数避免 fork bombprocess-guard 计数

⑤ 单项目墙钟估算

项目规模串行墙钟L1 并行后瓶颈
小(3 Unit)~15 min~8 minArchitect generate + Integrator spawn
中(8 Unit)~45 min~20 minL1 × 2 attempt × Coder + Tester
大(20 Unit + 3 L2 round)~3h~70 minL2 整套 + 重写

「并行后」假设 5 并行;scheduler 拓扑可能限制少于 5(fe 必须等 be 完)。北极星目标「小项目 < 30 min」对应中项目场景,余量充足。

⑥ 监控指标

在 ops-progress 已经展示了 token_used/budget。补充几个隐含指标:

指标看哪告警阈值
Tokens / Unit项目 token_used / units_count> 100K / Unit → 项目过度反思
Retry rateunits.json sum(retries) / count> 2 平均 → Coder skill 退化或 spec 不清
L2 修复轮次l2_rounds≥ 2 → 该 PRD 有歧义
Agent 调用墙钟 P95timeline.duration_ms 统计> 5 min → 模型卡或 prompt 过长
SessionPool 利用率active_sessions / maxSessions> 80% → 限流
Bash 子进程数process-guard tracked> 30 → 等回收

⑦ 降本策略

策略预期降幅难度
SessionPool 复用 + 5min cache TTL20-30% input token免费(既有 ACP 行为)
Tester Sonnet 改 Haiku(如果反思质量够)40% Tester 部分低
PM/Coder/Tester 用 Sonnet · 只 Architect/Triager 用 Opus已是默认—
Memory 注入降到 top 3(从 top 5)5-10% input低,1 行配置
跳过 Tester 写文档代码(README/类注释)10% output低
cache busting:相同 unit 跑 1 次后用缓存(无 retry 时)大幅,针对回归中(需 contract_hash 索引)