很多 AI agent 平台在还没做大之前，都会用一种看起来很朴素的容量观念来运营系统：总并发还有空位、队列长度还没爆、平均延迟也能接受，所以平台整体应该没什么大问题。可只要平台开始服务多个团队、多个客户、多个任务等级，这套看总量的方式很快就会失效。因为把系统拖垮的，往往不是总资源先见底，而是共享资源先被某一类流量在某个时间窗里吃穿。
最典型的场景，就是一个大客户在月末、季末或者批处理窗口突然打进来大批长任务。平台如果只有统一队列和统一并发池，这类流量会把更短、更关键、对交互更敏感的任务一起挤到后面。技术上看，系统还活着；客户体验上看，平台已经失去了最基本的公平性。更糟的是，其他租户往往连“为什么突然变慢”都说不清，只会感受到这套系统在关键时刻不可靠。
所以 shared fairness、reserved capacity 和 burst credit 真正要解决的，不是平台有没有更多机器，而是共享系统能不能在高峰期仍然保持边界。没有这层设计，多租户平台迟早会把“大客户成功”做成“其他客户集体失望”。
建议配合 AI agent 准入控制与配额闸门、AI agent 多租户隔离与 Workspace 供给、AI agent 任务优先级队列 和 AI agent SLO、Error Budget 与 Service Tier Design 一起看。
配额、优先级和公平性，听起来像一回事，其实负责的是三种不同麻烦
| 机制 | 解决的核心问题 | 只靠它为什么不够 |
|---|---|---|
| 配额 | 谁有资格进入系统、最多能占多少 | 只管入口，不管进入后怎样争抢执行资源 |
| 优先级 | 哪类任务应该先跑 | 没有隔离和回收规则时，高优先级也可能被长期吞掉 |
| 公平性 | 多个租户或任务池如何持续共享有限容量 | 如果没有预留和弹性，高峰时仍会被大流量冲穿 |
很多团队以为把 admission control 做好就够了，实际上它只能挡住最粗暴的洪峰。平台真正难受的，常常是进入系统之后的资源争抢：同样都在合法配额内，但某个租户的任务更长、更重、更占用外部连接器、更容易让 worker 长时间不释放。这时如果没有 fairness layer，其他租户就会在“大家都合法”的前提下被慢慢饿死。
Reserved capacity 的价值，不是偏心，而是给关键承诺留出呼吸道
一说到 reserved capacity，很多团队第一反应都是这会不会太偏心。问题在于，平台本来就已经有承诺差异。交互式任务、人工 review 相关任务、企业高价值租户的恢复任务、以及支持链路里的 replay/debug 流量，它们的业务后果根本不一样。你如果还把所有任务扔进同一个池子里平均对待，表面上看起来很公平，实际上是在把最关键的承诺也暴露给最不稳定的流量。
更成熟的做法通常是分层预留：
- 给交互式短任务预留最小可用执行池，确保系统不会因为批量任务失去基本响应
- 给高风险恢复、支持回放或人工交接链路预留紧急通道，避免事故期间连排障都排不上队
- 给普通批处理保留共享池，但接受它在高峰期被限速或延后
reserved capacity 不是告诉所有人“你们不平等”，而是明确承认系统里本来就存在不同等级的承诺。如果你不在资源层把这件事讲清，最后它就会在客户抱怨、支持升级和人工插队里以更混乱的方式出现。
Burst credit 能处理偶发冲高，但前提是你敢把“偶发”定义清楚
burst credit 最容易被误用的地方，是平台把它当成一种看起来很灵活的安抚机制。客户平时用量不高，偶尔来一波峰值，系统给一点额外信用额度，这当然合理。问题在于，如果 burst 没有时间窗、回收规则和恢复速度，它就会从“偶尔冲高的缓冲器”变成“默认更高占用的隐形承诺”。
真正可用的 burst credit 至少要说明三件事：
- 它能持续多久，而不是只说最高能冲到多少
- 用完之后恢复到基线容量的规则是什么
- 它会不会挤占 reserved capacity 或其他租户的基本公平性
一个常见错误，是平台允许大客户长期处在 burst 状态，然后再用人工协调去安抚其他租户。这样做短期看像服务意识强，长期看却是在把系统合同偷偷改掉。因为平台已经不再根据公开规则分配资源，而是在根据谁更大声、谁更急、谁更重要去临时插队。
一个很真实的事故：系统没宕机，但其他租户已经把它当成不可信系统
某团队的文档处理 agent 平台在季度末被一个头部客户打入大量历史文件重建任务。严格说，系统没有崩：worker 仍在工作，队列也在前进，成功率甚至没有明显掉下去。但三类问题立刻同时出现：
- 中小租户的交互式任务 TTFT 明显恶化，前台看起来像平台整体卡住
- 人工 review 相关任务被批量长任务挤压，支持团队连定位问题都要等队列
- 平台虽然给大客户完成了目标，却透支了其他客户对“共享服务”的信任
最后团队修的不是更多机器，而是资源合同。交互式任务独立出一层 reserved capacity，批处理任务必须消耗 burst credit，且 burst 额度按时间窗回收；当共享池达到老化阈值时，系统会主动压缩低优先级批处理的拿锁速度。上线后系统总体算力并没有暴增，但“谁在高峰期还能得到基本服务”第一次变得可解释。
如果你现在只能先补一层，先把公平性从经验调度变成显式合同
很多平台今天的公平性还停留在一种经验层面：哪个客户最近更急、哪个支持同学刚发来消息、哪个任务看起来更重要，就先人工帮它插一下队。这种方式在流量小的时候还能撑，规模一上来就会把平台带回手工协调。真正值得先补的，不是更复杂的弹性系统，而是把下面几件事写成明确合同：
- 哪些流量拥有保底执行能力
- 哪些流量只能在共享池里按公平规则竞争
- 哪些场景可以临时冲高，以及冲高多久必须回收
- 当系统进入紧张状态时，谁会先被限速、谁还能被保护
AI agent 平台做大之后，容量本身当然重要，但比总容量更重要的，是平台在容量紧张时会不会先失去公正感。因为客户真正记住的，通常不是你有多少机器，而是高峰来的时候，这套系统有没有把他们悄悄排除在外。
延伸阅读：
