限制 AI 调用工具的频率（Rate Limiting）是构建稳定 MCP 应用的关键环节。这不仅能防止 AI 因"幻觉"陷入死循环耗尽你的 API 配额，还能保护下游服务不被高频请求打垮。
整理了从轻量级代码控制 到企业级网关治理的三种主流方案。
🛡️ 方案一：在 MCP 服务器内部实现（轻量级）
如果你是自己编写 MCP 服务器（如使用 Python 的 fastmcp），最直接的方法是在工具函数内部加入计数器和时间窗口逻辑。
核心思路： 使用内存或 Redis 记录调用次数，超过阈值直接抛出异常或返回拒绝信息。
Python 代码示例（基于滑动窗口）：
python
import time
from collections import deque
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("RateLimitedServer")
# 配置：每分钟最多允许 10 次调用
MAX_CALLS = 10
WINDOW_SECONDS = 60
# 使用双端队列存储调用时间戳
call_history = deque()
@mcp.tool()
async def sensitive_action(action: str) -> str:
"""执行一个敏感操作（受限）"""
current_time = time.time()
# 1. 清理过期的时间戳（超出窗口的）
while call_history and call_history[0] < current_time - WINDOW_SECONDS:
call_history.popleft()
# 2. 检查是否超限
if len(call_history) >= MAX_CALLS:
return "❌ 速率限制触发：操作过于频繁，请稍后再试。"
# 3. 记录本次调用并执行
call_history.append(current_time)
return f"✅ 操作 '{action}' 执行成功。剩余配额: {MAX_CALLS - len(call_history)}"
if __name__ == "__main__":
mcp.run(transport='stdio')- 优点：实现简单，无需额外组件。
- 缺点：如果是多实例部署（集群），内存计数无法共享，需要改用 Redis。
🚦 方案二：使用 MCP Gateway 或拦截器（架构级）
在企业级应用中，通常会在 AI 和 MCP 服务器之间加一层 Gateway（网关） 或 Interceptor（拦截器）。这是最推荐的架构，因为它将"限流策略"与"业务逻辑"解耦了。
工作原理：
AI Agent -> MCP Gateway (在此处限流) -> MCP Server
主流实现方式：
- 使用 PolicyLayer Intercept ：
这是一个专门用于管理 MCP 工具调用的开源工具。你可以通过一个简单的 YAML 文件来定义策略，无需修改代码。- 配置示例 (
**policy.yaml**)： - 运行方式 ：
npx -y @policylayer/intercept --config policy.yaml
- 配置示例 (
- 使用 Azure API Management (APIM) ：
如果你将 MCP 服务器部署为 HTTP 服务，可以使用 Azure APIM 作为网关。它支持基于 IP、用户 ID 或订阅键的限流策略。- 策略配置 (XML)：
🧠 方案三：利用 AI 框架的内置护栏（应用级）
如果你使用的是现成的 AI 开发框架（如 LangChain、LlamaIndex）或特定的 AI 客户端（如 MiniMax Coding Plan），它们通常内置了配额管理。
- MiniMax Coding Plan 模式 ：采用 "按时间段限次" 的机制。例如，设置一个"5小时"的动态窗口，在该窗口内限制调用次数（如 40 次）。一旦耗尽，必须等待窗口滑动或切换到按量付费模式。
- Hermes Agent 模式 ：在配置中定义
SamplingHandler，设置max_tool_rounds = 5（限制递归调用轮次）和RPM = 10（每分钟请求数），防止 AI 陷入死循环。
📊 方案对比与最佳实践
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 代码内部限流 | 个人项目、单机脚本 | 零成本，开发快 | 难以维护，集群环境下失效 |
| Gateway/拦截器 | 企业应用、多租户 SaaS | 策略与代码分离，统一管理，支持集群 | 需要额外部署组件 |
| 框架内置 | 依赖特定平台（如 Azure, MiniMax） | 开箱即用，配置简单 | 绑定特定厂商，灵活性差 |
💡 专家建议：
- 区分读写操作：对"读取类"工具（如搜索、查询）设置较高的限流值（如 60次/分），对"写入类"工具（如发送邮件、删除文件）设置极低的限流值（如 3-5次/分），甚至要求人工确认。
- 优雅降级：当触发限流时，不要直接报错崩溃，而是返回一条友好的提示："当前请求过多，已为您排队，预计 30 秒后执行"，让 AI 知道稍后重试。
- 持久化计数 ：如果使用代码限流，建议使用 Redis 而不是内存变量，这样即使重启服务器，限流计数也不会丢失，防止 AI 利用重启绕过限制。