半夜被值班群的消息震醒一看是某平台的知识库 MCP 服务在报警单个 Agent 会话在四分钟内调用了 117 次同一个搜索工具把后端的数据库连接池打满同一网关下的其他租户全部跟着遭殃。这种问题不是传统的 DDoS而是大模型在关键路径上自己制造出来的“请求风暴”。MCPModel Context Protocol模型上下文协议把原来 HTTP API 层的限流问题重新拉回到了模型编排层因为调用方不再是稳定可控的客户端而是由模型输出动态触发的工具调用。我在这个过程中摸索了一整套结合“降熵”思路的自适应限流方案这篇文章把关键策略、踩过的坑和可复现的架构思路完整地梳理出来希望对做 Agent 基础设施的人有直接的参考价值。1. 请求风暴为何偏爱 MCP 场景拆解三个现场1.1 模型会主动制造重试这不是脚本循环传统 API 场景下的重试无非是客户端收到超时后按固定退避策略再来一次。MCP 场景里头的情况完全不同——模型的“重试”是带语义推理的。工具第一次返回超时模型不会简单地重放同一个请求它会换一个 query、换一个参数、甚至换一个完全不同的工具再试一次。从服务端看这些请求合法且有差异性但站在资源消耗的角度它们就是同一逻辑目标的重复逼近。我遇到的一个典型例子是检索类工具。Agent 想找某个答案第一次检索只返回了零星的片段模型认为证据不足于是连续翻页、换关键词、换过滤器四分钟内发起 117 次调用。前几十次返回的数据其实已经覆盖了核心信息但模型无法像人一样判断“够了”它只会向着“更多上下文”的方向继续推进。这类风暴最大的隐蔽性在于从单次请求来看每一个都完全正常无法用简单的频率限制识别。可它们叠加在一起对下游资源特别是数据库和外部 API造成的压力是几何级上升的。传统限流里我们防的是恶意流量但在 MCP 场景里要防的是“模型自己都不知道什么时候该停的流量”。1.2 工具响应太大上下文膨胀触发连锁排队MCP 的另一种请求风暴由上下文尺寸引爆。很多 MCP 工具返回的是整段文档、整张表或整棵代码树Agent 拿到之后会继续把这个结果传给下一个工具做二次处理。响应体越大模型推理时间越长占用的连接和计算资源越多可同一时刻并发进来的其他请求就被堵在队列里排队。更麻烦的是过了上下文窗口之后Agent 会把之前的数据压缩、丢弃然后又觉得信息不够回头再把工具调用一遍。这就是我所说的“上下文膨胀—信息丢失—再次拉取”循环。它不是并发层面的爆发而是在时间轴上反复占用资源的慢性风暴。普通限流器只盯着 QPS对这类问题毫无办法因为它的 QPS 可能只是平稳地维持在中等水平可平均响应时间和资源占用率却在悄悄往上爬。整个链路的关系大概是响应体变大 → 推理变慢 → 单请求占用连接变久 → 队列堆积 → 超时率变高 → 模型发起更多重试。每一个环节都在为下一个环节制造压力最终变成一个自激振荡的系统。你能在监控上看到一堆指标同时恶化但要定位是哪一环点燃的比定位一次普通故障要困难得多。1.3 租户串扰所有人都被同一个 Agent 拖慢MCP 服务通常是被多个上层应用共享的。如果只做全局限流一个租户的 Model 产生风暴就会把整个共享网关打爆。我在线上就遇到过一个搜索型 Agent 把公共连接池耗尽导致另一个只调用轻量工具的业务完全不可用的案例。这背后其实是两个问题第一局部流量没有隔离一个租户的行为可以影响所有人第二没有按“工具/资源”维度做分类管控所有工具共用同一份预算。你本可以在数据库工具和耗时的向量检索工具之间做出区分但因为统一限流轻量工具也被重流量拖累。所以在设计限流时我强烈建议至少分三层入口网关层、MCP 协议层、模型编排层。入口网关挡住最基础的异常流量MCP 协议层负责识别工具级上下文模型编排层则根据 Agent 会话状态动态调整整体节奏。只做任何一层都不够。2. 降熵视角熵值越高越需要压制2.1 把“熵”变成一个可计算的限流特征“降熵”听起来很玄但放到限流场景里完全可以变成一个实用指标。我把它定义为单位时间窗口内某个 Agent 会话调用的工具类型和资源 Key 的多样性归一化后得到的香农熵。不熟悉信息论的读者可以把它理解成“混乱程度”。如果一个 Agent 在稳定地跑一个任务它大概率会反复调用同一个或两三个工具参数也相对固定这时候熵值偏低。反过来如果同一个会话在短时间内频繁切换工具、扫描不同命名空间、尝试各种参数组合熵值就会快速抬高。熵值高本身不一定都是坏事——有些复杂任务确实需要多工具协作——但在绝大多数异常场景里熵值上升往往先于 QPS 飙升是一个非常早期的预警信号。我常用的是带权重滑动窗口的香农熵计算公式H - Σ( p_i * log2(p_i) )其中 p_i 是当前时间窗口内第 i 种“工具资源维度”组合占总调用次数的比例。代码实现上只需要在每个请求经过时维护一个带过期时间的计数器集合即可。比起直接统计全量 QPS熵指标的优点是它对“慢速但发散”的调用特别敏感。比如某个 Agent 每分钟只发五个请求但每个请求都在尝试新的工具组合这种流量在传统限流器眼里毫无威胁可其实它已经表现出了明显的失控倾向随时可能转成真正的高频风暴。2.2 结合错误率和延迟形成“风暴先验”单独看熵还不够更可靠的方式是把它和服务端统计指标结合起来。我自己的经验是把以下三个信号放进同一个判定模型里请求熵上升、成功率下降、平均延迟上升。三个信号同时出现的时候基本上可以判定这个 Agent 正在进入失控循环。举个例子假设你在监控面板上看到某个会话的熵从 0.8 跳到了 4.5同时工具调用的成功率从 97% 掉到 62%P99 延迟从 200ms 涨到 1.8s。这时候哪怕它的 QPS 看起来一点都不高也必须立刻降低这个会话的优先级和预算。等到 QPS 真的涨起来再介入往往已经晚了。好在这种组合特征的收益非常直接。我调整完限流器后在业务端看到的效果是被限流介入的会话数量没有大幅上升但下游数据库的慢查询数量下降了大概 70%。因为提前掐断了那些注定要失败的振荡请求真正有用的流量反而跑得更顺畅了。2.3 降熵不是降精度而是提高限流的语义层次不少同事第一次听到“降熵”会觉得这是在搞玄学但实际上它只是一个工程化的特征工程思路。传统固定限流的工作方式像一块铁板不管进来的请求是什么类型超过阈值一律拒绝。而基于熵的自适应限流更像是给系统加了一个“语义层”它判断的不是频率而是行为模式。比如同样是 10 QPS一个调用稳定、熵值低、成功率 100% 的会话和一个熵值高、错误率 50% 的会话在自适应限流里就应该被区别对待。前者可以放行甚至可以给更高的突发额度后者则要迅速收敛预算。这就在不损失正常请求的前提下把资源集中给了真正健康的工作负载。我当时在架构文档里写下的一句话是限流器不能只看“来了多少”它应该能感知“这些请求在做什么”。熵值就是在帮助下层系统回答这个问题的。3. 自适应限流器从预算控制到分布式落地3.1 两阶段预算全局先挡局部细判自适应限流的整体框架我分成两个阶段。第一阶段是全局预算。这个预算基于实时统计窗口动态变化核心依据是最近几秒钟的实际延迟和错误率。如果服务整体表现健康预算就往上调如果延迟开始爬升、错误率上升预算就往下压。这类似于 TCP 拥塞控制的思路不自作聪明地预设一个固定上限而是让真实的服务质量来决定当前到底能承接多少。第二阶段是局部预算。针对每个租户、每个 Agent 会话甚至每个工具类型维护独立的额度再叠加熵系数做动态调整。全局预算保护的是系统整体局部预算保护的是单个下游资源。两者配合才能既避免系统被打垮又避免某个异常会话堵掉其他正常会话的通路。实现时我会把每一层的决策下沉成一个独立的模块并通过统一的接口把结果传递给网关执行。这样后续想调整某个策略的权重只需要改配置不需要改代码逻辑。3.2 滑动窗口和快速恢复机制自适应限流最核心的状态窗口是一个带时间衰减的滑动窗口。我习惯每 100ms 采样一次当前 QPS、并发数、错误率和 P99 延迟然后用指数加权移动平均EWMA做平滑。这样可以避免瞬间抖动导致预算骤降又能在持续恶化时及时反应。EWMA 的关键参数是 alpha。alpha 太大会导致过度敏感一个本来会很快恢复的抖动就把预算打到很低反而影响正常请求alpha 太小会导致反应迟钝缓存风暴发生了预算还降不下来。我实践下来的经验是对大多数面向 MCP 的服务alpha 取 0.3 到 0.5 之间比较合适具体需要在压测环境里多调几轮。另一个重要的设计是快速恢复。如果限流器因为瞬时抖动把预算压得很低但实际请求量已经降下去了它应该能快速把预算拉回来而不是在一个低水位线上停留很久。我的实现方式是设置一个恢复系数当服务指标连续三个周期恢复正常后预算可以按步长而不是按比例增长直到回到稳定值。3.3 Redis 原子脚本解决分布式计数在分布式环境下最简单可靠的实现方式是用 Redis Lua 脚本做原子计数。多个网关节点同时对一个键做 INCR 和 EXPIRE 操作如果分两步执行就会出现竞态条件因为第一步 INCR 之后第二步 EXPIRE 还没来得及设置键正好过期了计数就会被重置。用 Lua 脚本把这两个动作封装成原子操作就能避免这个窗口期。下面是一个按租户做固定窗口计数的核心片段自适应逻辑在窗口计数之上再叠加熵和延迟权重local key KEYS[1] local limit tonumber(ARGV[1]) local window tonumber(ARGV[2]) local now tonumber(ARGV[3]) local current redis.call(INCR, key) if current 1 then redis.call(PEXPIRE, key, window) end if current limit then return 0 end return 1但这个简单版本只解决了计数问题真正的自适应阈值还得放在上层应用里计算。我通常的做法是每个网关节点先从 Redis 拉取近 10 秒的全局错误率和延迟然后在本地算出一个当前允许的总预算再按租户权重分配。Redis 只负责各个节点之间的状态同步真正的决策逻辑放在本地避免频繁和 Redis 交互造成新的瓶颈。3.4 协议层的拒绝语义别让模型误解 429MCP 底层的消息格式是 JSON-RPC 风格。限流器在工作时除了拒绝请求本身还要想办法把拒绝的原因传递给上层的模型编排框架否则模型拿到一个无法理解的错误依然会继续重试。我建议在 MCP 错误响应里显式表达“当前负载过高请在 X 毫秒后重试”的语义并且把 Retry-After 这个标准 HTTP 响应里的字段对应地带上。上层 Agent 框架如果解析到这个字段就能做相对合理的退避而不是立刻再次发起调用。一段标准的限流拒绝响应大概长这样{ jsonrpc: 2.0, id: 42, error: { code: -32029, message: rate_limited, data: { retry_after_ms: 500, reason: global_budget_exceeded, scope: agent_session } } }很多 MCP Server 在实现时默认只会返回超时或工具异常导致上层 Agent 误认为工具本身有问题进而触发更强烈的重试。把限流语义显式化是降低请求风暴在协议层面蔓延的关键一步。4. 工业级落地参数、权重、观测清单4.1 不再一刀切按工具配置独立权重MCP 服务里不同工具的物理成本差异巨大。一个查询缓存的工具和一个执行复杂 SQL 联表的工具单位 QPS 的代价完全不是一个量级。如果把两者放在同一个限流池里要么是轻量工具被误伤要么是重量工具得不到足够保护。我采用的方案是给每个工具定义一个权重权重可以基于平均响应时间、平均返回体大小、下游依赖数量以及是否为非幂等操作来计算。比如一个只读缓存工具权重为 1一个扫描十亿行数据库的只读查询权重为 50一个会写入外部系统的非幂等操作权重为 100。自适应限流器真正限制的是“加权后的资源消耗速率”而不是单纯的请求次数。这样当一个 Agent 在反复调用高权重工具时即使它的原始 QPS 一点都不高也会被迅速拦截住。这个调整对保护数据库等下游系统效果非常明显。维度固定 QPS 限流自适应加权限流判断依据单位时间请求次数请求次数 × 工具权重 × 熵系数对突发行为的响应固定阈值反应滞后动态预算提前介入不同工具区分度无区别按资源成本分级对待对模型重试循环的识别很难可通过熵和成功率组合识别故障恢复能力需要人工调整阈值自动恢复正常预算4.2 需要盯紧的落地参数把方案落地到生产环境前我会把关键配置项整理成一份清单每个配置都要求写明默认值和建议调整范围。我这里举几个最核心的window_size滑动窗口长度默认 10s。窗口越短对突发越敏感但也越容易被抖动干扰。min_budget每个租户的最低保障预算。这个值不能太低否则正常业务会在高负载时被完全饿死。entropy_coefficient熵系数控制请求熵值在多大程度上削减租户预算。一般从 0.2 开始调过大会导致复杂任务被拦截。recover_step快速恢复步长。每次恢复正常指标后预算增长的步长建议设置为原预算的 5% 到 10%。retry_after_ms协议层返回的退避时长建议根据当前队列深度动态计算而不是写死。每一个配置项我都建议单独做成一个开关方便线上实时调整。限流器最怕的不是配得不好而是配完之后没法快速改动。4.3 一周内就能搭好的观测面板想要把自适应限流调好观测能力比算法更关键。我一般会在监控面板上分为三个区域第一个区域是全局健康数据包括整体 QPS、错误率、P99 延迟、全局预算当前值。第二个区域是 Top N 会话数据展示熵值变化趋势、加权消耗速率、被限流次数。第三个区域是被拒绝请求的结构分析按租户、工具、错误码三个维度聚合出分布比例。我判断一个限流器是否调好的核心标准是正常请求几乎没有感知网络波动但异常 Agent 的调用频率曲线会出现明显的“被削平”现象。如果看到有一个会话在监控面板上呈现锯齿状波动——冲高、被打回来、再冲高、再被打回来说明限流器工作正常正在有效地驯服这个失控的流量。5. 运维中绕不开的坑超发、优先级反转与副作用重放5.1 分布式限流的超发问题用 Redis 做分布式限流后一个常见的坑是“超发”节点本地计算的预算总和大于服务整体的真实承受能力。原因是每个节点都是独立计算、独立放行的如果 N 个节点每个都认为当前还有预算请求总量就可能超出全局预算的 N 倍。解决这个问题有两个方向。第一个方向是把预算拆分让每个节点只维护自己的份额。缺点是某个节点空闲时它的份额不能被其他节点利用。第二个方向是引入集中式协调但协调本身又会带来延迟和单点风险。我自己的折中方案是网关节点先向 Redis 申请 500ms 的共享预算窗口申请成功后在这个窗口内本地放行窗口耗尽后再去申请下一段。这样能把全局一致性控制在很小的粒度上同时减少 Redis 交互次数。实测下来超发率从之前的 2 到 3 倍降到了 1.1 倍以内在可接受范围。5.2 优先级反转别让熵惩罚伤及正常任务熵系数设得太高会带来一个意想不到的问题一些正常但复杂的工作流会被误杀。特别是那些天生就需要频繁切换工具的 Agent 任务——例如“先查数据库、再调向量检索、再调代码解释器”这类多步推理熵值天然就高。如果不做区分这些健康请求反而会优先被限流而那些低熵但高频的异常循环却可能躲过检测这就是限流场景下的优先级反转。我后来在策略里加了一个“复杂任务保护位”当 Agent 的调用链明显符合预设的多工具协作模式并且错误率保持低水平时熵惩罚会适当削弱。这个保护逻辑不能完全靠规则写死我用的方式是把“工具切换是否伴随错误率上升”也作为一个信号。如果熵高但错误率低、延迟正常就视为复杂任务如果熵高且错误率同步上升就视为潜在风暴。两者在预算分配上给予完全不同的处理权重。5.3 非幂等工具的副作用重放在 MCP 场景里限流之后有一个特别容易忽略的副作用问题被拒绝的请求可能已经在上游执行了一半。比如一个“创建订单”工具客户端收到 429 后认为没有执行退避后重试实际上订单可能已经创建成功了。这个问题比普通 API 限流严重得多因为 Agent 会自主决定重试而且不会看幂等返回码。我的建议是强制要求 MCP Server 的写操作接入幂等键机制客户端请求里带上 context_id 操作序列号。限流器在决定放行前先检查幂等键是否已经存在如果存在直接把上一次的结果返回给客户端而不是再次执行。第二个方案是人为设置冻结窗口被限流的写操作并不立即拒绝而是进入 pending 状态等待系统确认最终状态后再决定是返回成功还是要求重试。这能最大程度避免副作用重复执行但也增加了实现复杂度需要根据具体业务决定是否值得做。5.4 没有熔断开关的自适应都是自嗨自适应限流再聪明它本质上也是根据历史数据做预测。遇到完全没有见过的流量波形模型可能会做出错误的决策。所以我在交付这套方案时一定会强加一个总熔断开关也就是 Kill Switch。熔断开关不是给自动化用的是给人用的。线上出了问题工程师能在一秒钟内把整个自适应策略降级成最保守的固定限流或者直接把保护全部关闭恢复成一个普通的透传网关。不要小看这个开关——限流器一旦出现 bug最有效的止损手段不是去调试它而是先断开它把流量恢复到可处理的状态再慢慢排查根因。我在经历了一次“限流器把正常流量全挡住”的事故之后就把熔断开关的设计优先级提到了所有功能之上的位置。写在最后的个人经验这套自适应限流方案从设计到上线我最大的体会是不要一开始就想着一气呵成要把系统当成一个需要持续调整的活物。我的路线是先跑固定限流只用于观察和记录请求特征积累两周的基线数据第二阶段才在测试环境把熵系数和加权工具接入做离线回放对比第三阶段才在线上灰度打开流量按 5% 逐步放大。每一步都要有回滚预案因为“自适应”三个字听起来优雅但真正碾过线上流量的时候任何一个小小的参数偏差都可能被放大成事故。只要你的服务开始被模型自己制造的请求风暴困扰这套思路就值得一试。