Appearance
系统能扛多少：Run Budget、Capacity Planning 与 Benchmark
前置：过载时如何控队列：Backpressure、Throughput 与 Latency
核心问题：系统宣称能支持某个 QPS/并发前，应该怎样从 Run Budget 推到容量假设，再用 Benchmark 证明这个上限？
一个 Run 最多 30 tool calls，同时某 tenant 每日上限 10 万 token；触发任一边界都采取对应策略。估算高峰 50 Run/s、每 Run 平均 4 个 DB tool，先验证 DB pool/限流是否支持约 200 tool op/s。
Per-run Budget / Quota
Per-run Budget / Quota 是对单个 Run 的 token、费用、turn、Tool calls 或 wall-clock 等硬/软上限；Runtime 在每个新 attempt 前检查剩余配额并决定继续、降级或终止。
Quota 是更长周期的用户/tenant 配额。两者需要在执行前检查并记录消费。
Admission Control 与 Fairness
容量已经接近上限时，不应先把所有 Run 都接进系统再一起超时。Admission Control 在 Run 创建或入队前根据全局/tenant/provider 资源判断：立即接受、排队、降级还是拒绝。
多租户系统还要避免一个大客户把 worker、model quota 或 DB pool 全部占满。常见手段是 tenant concurrency quota、weighted/fair queue、priority class 和保留容量。它解决“谁先有资格进入有限容量”，与单个 Run 内部的 DAG scheduler 是不同层次。
Capacity Planning
Capacity Planning 不是简单算“有多少 Worker”，而是找到整个 Harness 链路的持续瓶颈。
text
arrival rate
→ API / queue wait
→ worker concurrency
→ model provider quota
→ DB/HTTP pool
→ tool/service capacity例如再加 20 个 Worker，如果 Provider 已经持续 429，只会让 Queue 更快被取空、重试更多，并不会提升完成吞吐。
因此容量评估要结合到达率、平均/尾部 service time、各层并发上限和目标 SLO，并预留故障/峰值余量。
Performance Benchmark
Performance Benchmark 是在固定硬件、版本、数据集和并发条件下测量 TTFT、end-to-end latency、throughput、token/cost 与错误率的可重复实验，用于比较实现或容量变化。
Benchmark 必须固定 workload、版本、热/冷 cache、并发和测量窗口，报告 p50/p95/p99、吞吐、错误率、cost。只给平均 latency 没有诊断价值。
Failure Modes
Benchmark 只跑一次就宣布优化
症状： 单次结果稍好就认为新策略有效。
为什么危险： 随机方差和 provider 波动制造虚假提升。
处理： 固定 RunManifest/dataset，重复 trials，报告分布、slice、cost/latency。
如何验证
| Case | 断言 |
|---|---|
| Benchmark 只跑一次就宣布优化 | baseline/candidate 重复运行，无稳定改善则不接受优化。 |
自测
- 单个 Run 最快 2 秒，能否据此宣称系统能稳定 100 QPS？Capacity benchmark 还必须控制哪些并发和资源条件？
- Run budget 应怎样同时约束 token、时间、Tool calls、retry，才能避免某一维失控拖垮整条链路？