Agent Rate Limiting（Agent限流）是指在AI Agent系统中对请求频率、Token消耗速率、并发任务数进行限制的机制。与传统API限流不同，Agent限流需要同时考虑两个维度：用户的请求速率（QPS）和Agent的Token消耗速率（TPM）。这是防止Agent过载、控制成本、保护下游服务的关键防线。
传统API限流只需要关注请求数量，但AI Agent的限流更复杂：
| 维度 | 指标 | 说明 | 典型值 |
|---|---|---|---|
| 请求速率 | RPM (Requests Per Minute) | 每分钟处理的请求数 | 60 RPM |
| Token速率 | TPM (Tokens Per Minute) | 每分钟消耗的Token数 | 100K TPM |
| 并发数 | Concurrent Sessions | 同时处理的会话数 | 10 sessions |
| 工具调用 | Tool Calls Per Request | 单次请求的工具调用次数 | 10 calls |
| 子Agent | Subagents Per Request | 单次请求的子Agent数量 | 5 subagents |
# ~/.openclaw/config.yaml
rateLimit:
# 每Agent每分钟最大请求数
rpm: 60
# 每Agent每分钟最大Token数
tpm: 100000
# 最大并发会话数
maxConcurrent: 10
# 超限策略: queue | reject | throttle
strategy: "queue"
# 队列最大深度
queueMaxDepth: 50
# 队列超时(秒)
queueTimeout: 300agents:
list:
- id: "miaoquai"
rateLimit:
rpm: 30 # 内容生成Agent，不需要太快
tpm: 50000
- id: "seo-bot"
rateLimit:
rpm: 100 # SEO巡检可以快一些
tpm: 200000
- id: "community-bot"
rateLimit:
rpm: 200 # 社区消息量大
tpm: 30000# Token预算 - 按时间维度控制成本
tokenBudget:
daily:
limit: 500000 # 每日50万tokens
alert: 400000 # 80%时告警
action: "throttle" # 超限后降速
monthly:
limit: 10000000 # 每月1000万tokens
alert: 8000000 # 80%时告警
action: "reject" # 超限后拒绝
# 按任务类型限制
taskLimits:
cron_job:
maxTokens: 50000 # 定时任务单次最多5万tokens
user_message:
maxTokens: 10000 # 用户消息单次最多1万tokens
subagent:
maxTokens: 30000 # 子Agent单次最多3万tokens| 算法 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 固定窗口 | 每分钟计数，重置归零 | 实现简单 | 窗口边界可能突增 |
| 滑动窗口 | 按时间滑动计数 | 平滑限流 | 内存占用稍高 |
| 令牌桶 | 匀速发Token，消耗Token | 允许突发流量 | 参数调优复杂 |
| 漏桶 | 匀速处理，多余排队 | 输出恒定 | 无法处理突发 |
Agent推荐：令牌桶算法 — AI Agent的请求往往是突发的（用户突然发来一个复杂问题），令牌桶允许短暂的突发流量，同时保持长期的速率限制。
陷阱1：只限请求不限Token — 一个请求消耗5万tokens，10个请求就用完了日预算。必须同时限制RPM和TPM。
陷阱2：限流后无提示 — 用户发消息后Agent静默丢弃，体验极差。应该返回"当前请求较多，请稍后再试"。
陷阱3：子Agent无限流 — 主Agent限流了，但子Agent没有限制，可能导致资源耗尽。
1. 分层限流 — 全局限流 + 按Agent限流 + 按任务类型限流，三层防护。
2. 优雅降级 — 超限时不是直接拒绝，而是降级到更快更便宜的模型。
3. 实时监控 — 配合Agent Observability，实时查看限流状态和触发次数。
4. 预算告警 — 在Token预算达到80%时提前告警，而不是到100%才通知。