什么是速率限制？应用构建者的通俗指南

速率限制是一种规则，用来限定某人在一段设定时间内可以向系统发出的请求数量，例如每分钟最多 5 次登录尝试，或每小时最多 100 次 API 调用。一旦达到上限，之后的请求就会被拒绝（通常返回错误代码 429 Too Many Requests），直到时间窗口重置。它可以防止应用遭到滥用，避免某个高频用户拖慢所有人的使用，也能阻止费用失控。

你会从两个角度接触到速率限制：你调用的服务会限制你，而你自己的应用则应该限制它的用户。

用 AI 构建应用时，速率限制为什么重要

由 AI 构建的应用通常会连接到付费服务，比如 AI 模型、邮件、短信和地图，而每一次调用都要花钱。因此，速率限制既是安全功能，也是预算功能。

• 成本控制。 如果你的应用有一个“问 AI”的输入框却没有限制，机器人可能在一夜之间发送数千次请求，而你要为每一次付费。
• 安全。 如果登录表单没有限制，攻击者可以对某个账户尝试数千个密码。每分钟只允许几次尝试，就能让这种攻击变得不切实际。
• 保持在线。 一段行为异常的脚本，有时甚至是你自己代码中陷入的死循环，就可能让数据库过载，导致应用瘫痪。
• 尊重其他服务的限制。 当你的应用过于频繁地调用外部 API 时，收到 429 错误的是你，而功能也会因此对你的用户失效。

AI 构建工具会构建你要求的东西。如果你没有提到限制，它们往往就不会加上。

一个日常类比

想想咖啡店的免费续杯政策：“每位顾客每次光临可免费续杯一次。”

• 它不会阻止任何人享用咖啡。
• 它阻止了一个人站在柜台前一整天为全办公室续杯。
• 当有人第四次要求续杯时，店员会礼貌地说“现在不行”，这就相当于 429。

好的速率限制对普通顾客来说是无形的，只有在有人做出异常行为时才会被注意到。

速率限制如何工作

一个速率限制器需要回答三个问题：

当一个请求到达时，应用会检查该“谁”的计数。未超过限制：请求通过，计数加一。超过限制：请求被拒绝。

常见的计数方式有以下几种：

计数需要存放在快速且共享的地方。在单台小型服务器上，放在内存中即可。一旦应用运行在多台机器上，计数器通常就要放在 Redis 之类的共享存储或数据库中，否则每台机器各自计数，真实的限制就会变成原来的好几倍。

被限速时的响应是什么样的

当请求超过限制时，设计良好的 API 会返回：

• 状态码 429 Too Many Requests。
• 通常还有一个 Retry-After 响应头，说明需要等待多少秒。
• 有时还会带有显示你的限额以及本时间窗口内剩余次数的响应头（不同服务商的名称各不相同）。

你的应用收到 429 时，应当等待一段时间后再重试，最好采用指数退避：每次失败后等待的时间逐步加长（1 秒，然后 2 秒，再 4 秒），而不是不停地连续冲击服务。

实例：一个 AI 写作助手

假设你做了一个应用，用户粘贴一段文字，然后得到 AI 改写的结果。

没有限制时： 有人写了一个脚本，在一夜之间发送了 20,000 次请求。你的 AI 服务商账单暴涨，你的账户又触发了服务商自身的速率限制，结果真正的用户整个上午都在看到错误。

设置合理的限制后：

1. 按已登录用户： 免费套餐每小时 30 次改写，付费套餐 300 次。超过限制时，用户会看到：“您已达到本小时的使用上限。请在 12 分钟后重试，或升级套餐。”
2. 按注册表单上的 IP 地址： 每小时最多 5 次注册，防止机器人批量创建免费账户来绕过按用户的限制。
3. 在 AI 服务商后台设置消费上限，作为其他措施全部失效时的最后一道防线。
4. 处理服务商的限制： 如果 AI 服务商返回 429，你的服务器会等待后重试一到两次，然后显示友好的“系统繁忙，请稍后再试”提示。

限制应当在服务器端检查。仅存在于浏览器中的限制（例如点击 30 次后禁用按钮）可以被任何直接调用你 API 的人绕过。

关键术语

常见误解

• “速率限制只适用于大型应用。” 小应用同样是目标，因为机器人会扫描整个互联网，寻找开放的表单和 AI 接口。滥用的代价并不取决于应用的规模。
• “隐藏按钮就够了。” 浏览器端的限制只是一种礼貌，并不是保护。真正的限制必须在服务器端执行。
• “按 IP 限制总是公平的。” 许多人可能共用同一个 IP 地址，比如一家公司、一所学校或同一个移动网络。用户登录之后，按用户限制会更公平。
• “429 意味着服务坏了。” 它的意思是你调用得太频繁了。检查代码中是否有循环，并缓存不常变化的结果。参见什么是缓存。
• “有了速率限制就不需要消费上限。” 两者都要用。应用中的限制可能存在漏洞，而服务商的消费上限是你的最后保障。

可以向 AI 构建工具提出的要求

• “为登录、注册、重置密码以及 AI 接口添加服务器端速率限制。请建议合理的限额。”
• “限制每位已登录用户每小时最多 [N] 次 AI 请求，超限时显示清楚的提示，并告知需要等待的时间。”
• “当外部 API 返回 429 时，采用指数退避最多重试 3 次，然后显示友好的错误提示。”
• “速率限制的计数器存放在哪里？如果应用运行在多台机器上，它们还能正常工作吗？”
• “每当用户或 IP 触发限制时都要记录日志，方便我发现滥用行为。”
• “这个应用调用了哪些外部服务？它们的速率限制是多少？”

Mythex 中的速率限制

Mythex 的文档在这一点上说得很直接：对于 AI 功能，你所构建应用中的速率限制、安全与成本控制都由你自己设计，参见构建 AI 应用。请在要求添加功能的同一条消息中，要求 Agent 添加限制。在 Pro 套餐中，已发布的服务在流量较大时最多可运行在三台机器上（参见托管限制），因此请要求把计数器存放在数据库中，而不是某台服务器的内存里。

相关阅读：什么是 API、如何使用大模型 API，以及AI 构建应用的安全检查清单。

常见问题