网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

在 Agent 系统中，有一种非常典型、也非常危险的失控方式：

不是做错了
而是做“太多了”

一个真实场景

用户：帮我发一封邮件
Agent：
  → 调用 send_email()
  → 判断不确定，再试一次
  → 再试一次
  → ...
结果：发了 200 封邮件

核心问题

AI 系统不是只会“做错”，还会“疯狂重复做对的事”。

限流与配额，不是优化性能，而是防止系统失控。

一、问题本质：AI 系统天然容易“放大行为”

传统系统：

用户点击一次 → 执行一次

AI 系统：

一个决策
→ 多次尝试
→ 多工具调用
→ 多 Agent 协作

放大效应

小错误 → 多次执行 → 大事故

本质

Agent 会“放大行为”，而不是“执行一次”。

二、为什么“权限控制”不够

很多人会说：

已经有权限系统了

但权限只能解决：

能不能做

无法解决：

做多少次
做多频繁
资源消耗多少

示例

允许 send_email 正确
但发送 1000 次 错误

本质

权限控制“边界”，限流控制“规模”。

三、限流 vs 配额：两个不同概念

必须区分清楚：

1、限流：单位时间内的执行频率

示例

每秒最多 5 次 API 调用

2、配额限制：总量

示例

每天最多发送 100 封邮件

核心区别

限流 → 控制速度
配额 → 控制总量

四、关键设计一：多维度限流

不能只做“全局限流”。

必须分层：

用户级限流
Agent 级限流
工具级限流
系统级限流

示例

if (user.rate > 10/s) deny();
if (agent.calls > 5/s) deny();

本质

不同维度，风险不同。

五、关键设计二：行为级配额

配额必须细化到“行为”。

示例

{
  "action": "send_email",
  "daily_limit": 50
}

而不是：

总调用次数 1000

本质

不同操作，风险不同，必须分别控制。

六、关键设计三：调用链限流

Agent 系统最大的风险在“链路”：

示例

Agent A → Tool B → Agent C → Tool D

问题

每一层都合法
整体却爆炸

解决

限制“整个链路”的调用次数

示例

if (chainDepth > 5) stop();

本质

限制“组合行为”，而不是单点行为。

七、关键设计四：重试控制

AI 系统天然喜欢“重试”。

示例

失败 → 再试 → 再试 → 无限循环

必须限制

最大重试次数
重试间隔（Backoff）

示例

if (retryCount > 3) abort();

本质

重试，是最常见的“失控来源”。

八、关键设计五：成本感知

不仅要控制次数，还要控制：

资源成本

示例

Token 使用量
API 调用费用
CPU / 内存消耗

实现

if (cost > budget) stop();

本质

AI 系统必须“知道自己在花钱”。

九、关键设计六：突发保护

系统必须应对“瞬间爆发”。

示例

正常：每秒 5 次
异常：瞬间 100 次

解决

滑动窗口
令牌桶（Token Bucket）
漏桶算法

本质

防止“瞬间失控”。

十、关键设计七：动态限流

固定限流不够。

示例

系统负载低 → 放宽限制
系统负载高 → 收紧限制

实现

if (cpu > 80%) {
  reduceRateLimit();
}

本质

限流必须“感知系统状态”。

十一、关键设计八：限流与权限结合

限流不能独立存在。

必须结合

权限系统
Policy Engine
风险评估

示例

if (highRisk && highFrequency) {
  deny();
}

本质

控制必须是“多维度的”。

十二、关键设计九：可观测性与告警

必须知道：

谁触发限流
触发了多少次
是否异常

示例

{
  "agent": "email_agent",
  "rate_limit_hit": true,
  "count": 120
}

本质

限流本身，也是重要信号。

十三、关键设计十：Fail-safe

当触发限流时，系统必须：

优雅失败
而不是崩溃

示例

返回提示
延迟执行
降级处理

本质

限流不是“阻断”，而是“保护”。

十四、实战架构：限流与配额系统

完整设计如下：

请求（Request）
↓
权限校验（Permission）
↓
限流检查（Rate Limit）
↓
配额检查（Quota）
↓
Policy Engine（决策）
↓
执行（Execution）
↓
监控与日志（Monitoring）

核心特征

多层控制
动态调整
全链路覆盖
与治理体系集成

总结

限流与配额的本质，不是：

优化性能

而是：

防止 AI 系统“失控放大”。

我们可以用一句话总结：

权限决定“能不能做”
限流决定“做多少”
配额决定“做多久”