很多团队做 AI agent 时，会默认把“收到请求”理解成“应该开始执行”。这个假设在低流量阶段没问题，但一旦进入多人使用、批量任务和高成本工具并行的阶段，系统最重要的问题就会变成：哪些请求应该立刻进队列，哪些应该延后，哪些根本不该在当前窗口执行。
准入控制与配额闸门真正要解决的，不是简单限流，而是把“系统资源、业务优先级、风险等级和租户公平”翻译成明确的入场规则。否则再好的模型和工具，也会在错误的流量面前被拖垮。
建议先配合 AI agent 任务优先级队列、AI agent 成本控制与预算治理、AI Agent 并发与可靠性 和 AI agent 产品成功指标 一起看。
先给结论：准入控制先回答 3 个问题
| 问题 | 典型判断 |
|---|---|
| 这个请求现在能不能执行 | 当前是否还有容量 |
| 这个请求值不值得占用容量 | 业务优先级和风险等级 |
| 这个请求该走哪条通道 | 实时、延后、批处理或直接拒绝 |
如果系统只有“是否超过 QPS”这一条规则，就还谈不上真正的 admission control。
一、准入控制先看请求分类，不要所有任务共用一条门
一个最小分类法通常至少包括：
- 实时交互请求
- 需要人工等待的半实时请求
- 批量异步任务
- 高风险写操作前的校验请求
这些请求抢占资源的合理性完全不同。把它们混在一个入口，只会让系统在高峰期失去业务判断。
二、Quota bucket 最好分层，而不是全站一个总额度
更稳的配额模型通常会拆成：
| 配额层 | 解决什么问题 |
|---|---|
| 全局 quota | 保护整体供应商配额 |
| tenant quota | 防止大客户或单租户挤占全部资源 |
| user quota | 防止单用户刷爆系统 |
| workload quota | 保护实时交互不被离线任务吃光 |
只有拆层以后，你才能同时做到“保护平台”和“保护关键业务”。
除此之外，admission 决策本身也值得落成一份 decision envelope，而不是只返回 allow / reject：
{
"runId": "run_123",
"decision": "defer",
"quotaSnapshot": {
"globalRemaining": 42,
"tenantRemaining": 5,
"protectedCapacityRemaining": 2
},
"reasonCodes": ["background_quota_exhausted"],
"retryAfterMs": 30000
}
有了这份记录，后面无论是解释用户为什么被挡、复盘哪个 bucket 经常耗尽，还是分析 admission policy 是否误杀，都更容易落到事实层面。
三、不要只做拒绝，也要设计 defer 与 protected capacity
准入控制常见错误是只会两种动作：放行或拒绝。现实里更有用的通常是四种：
| 动作 | 适用场景 |
|---|---|
| allow | 容量充足且请求优先级合理 |
| defer | 当前不急，可转后台队列 |
| degrade | 可进入低成本或低能力链路 |
| reject | 当前不应继续占用资源 |
此外，关键任务最好永远有保留容量。例如审批辅助、风控审查或人工正在等待的请求，不应该和离线批量回放争抢同一个 bucket。
更稳的做法通常会把容量拆成三层：
| 容量层 | 用途 |
|---|---|
| reserved capacity | 只服务关键交互任务 |
| shared capacity | 服务大多数普通请求 |
| emergency spillover | 只在异常窗口临时接管 |
这样系统就不只是知道“要保护关键任务”，而是把保护变成了明确的容量布局。
四、Admission policy 要显式看成本与风险，而不是只看并发数
两个请求同时到来，不一定等价：
- 一个只是摘要改写
- 一个要调用 3 个工具并触发高风险写入
如果 admission policy 只看“当前并发数”，系统会把这两类任务当成完全一样的负载，这是不对的。更合理的做法是先估算：
{
"taskType": "external_send_review",
"estimatedCostTier": "high",
"riskLevel": "high",
"capacityClass": "protected"
}
这样入口层就能在真正执行前决定：允许进入、改走低成本链路，还是直接转人工。
五、被拒绝的请求也要有清晰用户语义，不要让前端只收到 429
很多系统的 admission control 做到了保护后端，却把前端变成黑盒。更健康的返回语义通常包括：
- 当前是容量问题还是配额问题
- 是临时延后还是今天额度已用尽
- 还有没有替代路径，例如改走异步、低成本模式或人工入口
准入控制的目标不是“挡住用户”，而是让用户知道现在该怎么继续。
六、上线后要看“谁被挡住了”，而不是只看拒绝率
建议持续观察：
| 指标 | 用途 |
|---|---|
| admission reject ratio by workload | 看是不是挡错了流量 |
| deferred queue completion rate | 看延后任务有没有被真正完成 |
| protected capacity hit ratio | 看保留容量是否被有效使用 |
| protected capacity starvation rate | 看关键任务是否仍然被挤压 |
| admission decision latency | 看入口判断是否本身太慢 |
| cost saved vs accepted run loss | 看准入策略是节流还是误杀 |
如果拒绝率下降了，但关键业务 accepted run 也下降，说明 admission policy 只是把流量压低，不是把系统变聪明。
七、失败案例：批量回放占满队列，人工等待的审批请求全部超时
某团队晚上跑评测回放时，没有和白天的实时审批辅助分开配额。结果第二天上班后，虽然总体 QPS 不高，但重任务队列仍然占满 worker，导致需要人工等待的审批请求持续超时。
修复后，他们把 admission policy 改成：
- 交互型审批辅助走 protected capacity
- 批量回放只能吃 background quota
- 超出预算的回放任务直接 defer 到低峰窗口
问题的关键不是资源不够，而是入口没有区分“谁更应该先被服务”。
八、准入控制与配额闸门 Checklist
- 是否先按请求类型区分实时、半实时和离线任务
- quota 是否至少分成全局、租户、用户或 workload 几层
- 是否除了 reject 之外，还支持 defer 与 degrade
- admission decision 是否记录 quotaSnapshot、reasonCodes 和 retryAfter
- 关键业务是否有 protected capacity
- 是否显式划分 reserved、shared 和 emergency spillover 容量
- admission policy 是否显式看成本和风险等级
- 被拒请求是否返回可解释的下一步路径
- 是否设置最大 defer 窗口，避免低优先级任务被永久饿死
- 是否持续监控被挡住的是哪类业务请求
结语
AI agent 的准入控制，不是“加一层限流”，而是决定系统应该把稀缺资源优先给谁。只有把业务优先级、风险等级、成本预算和容量边界一起写进入口规则，平台才不会在高峰时用最贵的方式服务最不重要的任务。
延伸阅读：
