智谱清言智能体请求过于繁忙怎么办？限流原理与解法
上周二下午三点，我正给客户演示一个基于智谱清言搭的合同审查智能体，屏幕上弹出六个字：请求过于繁忙，请稍后再试。演示当场卡壳。这不是我第一次撞上这个提示——过去大半年里，我在三个不同的项目里遇到过它，每次的成因都不一样，解法也差得远。
核心结论摘要：智谱清言智能体提示"请求过于繁忙"，绝大多数情况不是你的网络问题，而是触发了速率限制（Rate Limit）。公开展示的智能体受创建者配额约束，API 侧则受并发数、RPM、TPM 三重限制。错峰使用只能治标，把单次请求的上下文压下来、叠加指数退避重试、再准备一个自建兜底智能体，才是能长期跑下去的工程方案。
下面把我踩过的路按"是什么—为什么—怎么办"的顺序讲一遍。
这个"繁忙"到底是谁的锅
先给结论：同样是"请求过于繁忙"，出现在不同位置的提示，成因完全不同，先定位再动手。
智谱清言这个产品其实有两套入口，一套是网页/App 端的智能体广场（别人创建、你直接用的那种），另一套是智谱 AI 开放平台提供的 API。两者的限流逻辑是分开的。
速率限制（Rate Limit）是指服务端在单位时间内对某个账号或某个调用方允许的请求数量上限，超过上限的请求会被直接拒绝，而不是排队等待。智谱开放平台文档里的说明是，GLM 系列模型对并发数、每分钟请求数（RPM）、每分钟消耗 token 数（TPM）分别设限，具体数值随账号等级不同而变化，免费版和付费版的差距不小。
判断你到底卡在哪一环，可以照下面这张表快速对一遍：
| 现象 | 最可能的原因 | 快速验证方式 | | --- | --- | --- | | 用别人分享的智能体时频繁繁忙，用默认对话正常 | 该智能体的创建者配额被占满 | 切回官方默认模型对话测试 | | 自己创建的智能体，自己用也报繁忙 | 账号等级偏低，或同时开了多个会话 | 关掉多余会话再试一次 | | API 调用失败，错误体里带 1302 / 1303 / 1304 | 分别对应并发、TPM、RPM 超限 | 查看响应体错误码字段 | | 白天必现、凌晨正常 | 资源池整体紧张 | 记录报错时间分布，做错峰 |
那张表的第三行值得多说一句。智谱开放平台的错误码里，1302 通常指向并发超限，1303 和 1304 分别指向 TPM 和 RPM 超限。具体含义以官方文档当前版本为准，但区分这三类对定位问题非常关键——并发超限要减并行，TPM 超限要砍 token，RPM 超限才要降频率。
限流为什么偏偏卡住 Agent
Agent 类应用天生就比普通对话更容易触发限流，这一点很多刚上手的朋友没意识到。
智谱在 GLM-4 技术报告（arXiv:2406.12793，2024 年 6 月）里描述过 GLM-4 All Tools 的工作方式：模型会自主规划任务、连续调用多个工具，再根据工具返回结果决定下一步。翻译成工程语言就是——用户按下一次回车，背后可能是三轮、五轮甚至十几轮模型调用。每一次调用都计入 RPM，每一次调用的输入输出都计入 TPM。
再加上 Agent 往往要带着历史对话、工具描述、知识库片段一起发过去，单次请求的输入 token 很容易冲到几千甚至上万。我见过一个客服质检的 Agent，光系统提示词加工具 schema 就占了 3800 token，还没算用户输入。这种量级下，免费额度的 TPM 基本撑不了几轮。
有意思的是，很多人第一反应是"多试几次"，结果反而更糟。重试本身不区分场景，等于在限流窗口里继续往服务端砸请求，只会让恢复时间更长。关于重试这件事，AWS 架构师 Marc Brooker 在 AWS 架构博客那篇《Exponential Backoff And Jitter》（2015 年 3 月）里做过对比实验，结论很直接：纯指数退避在客户端数量上来之后依然会造成重试风暴，必须叠加随机抖动才能把请求摊开。这个结论放到今天的大模型 API 场景里，一个字都不过时。
实战解法：从"等一等"到"自己造一个"
先给一句总结：能改代码的地方改代码，改不了代码的地方换路径。
解法一：把上下文瘦下来
如果你的 Agent 是自己搭的，第一步不是重试，是减重。具体做法：
- **裁剪系统提示词**。把"你是XX专家，你需要XX，你应该XX"这种排比式人设砍到三句话以内。工具描述只保留必要参数，别把完整 JSON Schema 一股脑塞进去。
- **限制历史轮数**。保留最近 5-8 轮对话 + 一份滚动摘要，比无脑带 30 轮历史划算得多。
- **按需注入知识**。这一步就是 RAG 检索增强的用武之地，我在这篇讲 [RAG 检索增强的落地要点](https://vergex.cn/rag/retrieval-augmentation-guide) 里拆得比较细，核心思路是把知识库切片存进向量数据库，每轮只召回 top-3 到 top-5 的片段，而不是把整份文档塞进上下文。
我在一个内部项目里做过对比：同一个知识问答 Agent，把全量文档注入改成向量数据库召回后，平均单次输入从 9.2K token 降到 1.4K token，TPM 压力直接降了八成多。代价是要维护一套索引，以及召回质量需要调优。
解法二：重试要带抖动
改不了平台侧，就只能把自己这端做扎实。下面这段代码是我现在项目的标准配置，直接可用：
import time import random from zhipuai import ZhipuAI
client = ZhipuAI(api_key="your-api-key")
def call_with_backoff(messages, max_retries=5): """带指数退避 + 抖动的调用封装，专治限流类错误""" for attempt in range(max_retries): try: resp = client.chat.completions.create( model="glm-4-plus", messages=messages, timeout=30, # 超时要短，避免连接被长时间占住 max_tokens=1024, # 限制输出长度，控制 TPM 消耗 ) return resp.choices[0].message.content
except Exception as e:
智谱 SDK 会把业务错误码挂在异常对象上，字段名以官方 SDK 为准
code = getattr(e, "code", None)
1302 并发超限 / 1303 TPM 超限 / 1304 RPM 超限
if code not in ("1302", "1303", "1304"): raise # 其他错误不重试，直接抛 if attempt == max_retries - 1: raise # 最后一次还失败，交给上层兜底
指数退避 + 随机抖动：第1次约1s，第2次约2s，上限30s
wait = min(2 ** attempt, 30) + random.uniform(0, 1.5) print(f"[限流] 第 {attempt + 1} 次重试，等待 {wait:.1f}s") time.sleep(wait)
有个坑我踩过：早期版本我只写了 `2 ** attempt`，没加 `random.uniform`，结果 20 个并发 worker 在同一秒集体重试，服务端的压力曲线像心电图一样陡。加上抖动之后就平了。
解法三：换条路走
如果报错的是智能体广场里别人创建的智能体，你能控制的东西其实很少。这时候我的建议比较直接——别在公共资源上吊死。
- **自己复刻一个**。把那个智能体的提示词抄下来（大多数公开智能体是可见的），在自己的账号里建一个私有版本，配额归你控制。
- **升级账号等级**。如果你的场景是生产环境，这条路最省事，智谱开放平台按等级提供不同的并发和 RPM 上限，具体档位看官方文档。
- **做多模型兜底**。把调用封装成一层，主模型限流时自动切到备用模型，这对可用性要求高的场景几乎是标配。
几种方案的取舍我整理成了这张表：
| 方案 | 见效速度 | 长期成本 | 最适合的场景 | | --- | --- | --- | --- | | 错峰使用 + 手动重试 | 立刻 | 极低 | 个人偶尔使用 | | 提示词瘦身 + 历史裁剪 | 半天 | 低 | 长会话类 Agent | | RAG + 向量数据库召回 | 一周左右 | 中 | 知识密集型 Agent | | 升级配额 / 企业版 | 立刻 | 高 | 生产环境 | | 自建复刻 + 多模型兜底 | 一天 | 中 | 依赖公共智能体 |
一个真实案例：失败率从 18% 降到 0.6%
说个具体数字。今年 4 月我们给一家做售后工单的公司搭过一个 Agent，走的是智谱 API，日均调用量大概 4000 次。上线第一周的统计是：18.3% 的请求以"请求过于繁忙"或超时告终，主要集中在上午 10 点到 11 点半、下午 2 点到 3 点半这两个高峰段。
我们做了三件事。第一，把原本文本形式的工单历史改成结构化的向量库召回，单次输入 token 从 7.8K 压到 1.6K。第二，把重试逻辑换成上面那段带抖动的版本，并且把重试上限锁死在 3 次。第三，给整个 Agent 加了一个简单的请求队列，把并发从 20 压到 6。
三周后再统计，失败率是 0.6%，剩下的失败里大部分是真正的网络抖动，不是限流。有意思的是，把并发从 20 降到 6 之后，整体吞吐量反而上升了差不多 15%——因为被拒绝的请求少了，有效请求变多了。
我的判断：别把重试当万能药
写到这里想插一段个人观点，也是我觉得最容易被忽略的地方。
现在网上讲"请求过于繁忙怎么办"的内容，八成会告诉你加重试。重试当然有用，但它是缓解手段，不是解决手段。真正决定一个 Agent 能不能稳定跑的，是它单次请求的资源消耗有多重。你把 TPM 消耗压下去 80%，限流问题基本自己就消失了；你不动上下文结构，只靠重试硬扛，那就是在限流的边缘反复横跳，延迟会越来越难看，用户体感会越来越差。
还有一个更隐蔽的坑：在客户端做无限重试，本质上是在把服务端的过载问题转嫁给你自己的用户。用户点一下按钮，你以为弹出来一个加载动画，实际上背后排了十几分钟的队。我的做法是设置绝对上限——重试超过 3 次、总耗时超过 15 秒，直接给用户一个明确的失败提示和降级答案，别让人干等。
另外，如果你的业务严重依赖某个公共智能体，那这件事从架构上就是有风险的。公共资源意味着你会和无数陌生人抢同一份配额，早晚会出问题。早一点把核心能力搬到自己的账号下，哪怕先用小配额跑起来，也比事后救火强。想找现成的 Agent 和配套工具做对比，可以看看 VergeX 的 AI Agent 工具清单，里面有按场景分类的整理。
总结与学习路径
这个问题看起来是个报错处理，拆开之后其实是三件事：定位限流类型、降低单次请求的资源消耗、设计合理的失败退路。技术难度都不高，难的是意识到"重试"不是第一优先级。
如果你想系统补一下这块，我的建议顺序是：先把智谱开放平台的错误码文档通读一遍，再搞明白 RPM / TPM / 并发三者的区别，然后动手写一个带抖动的重试封装，最后补上 RAG 和向量数据库的基础——因为上下文压缩才是治本的那一步。
关键要点速览：
- "请求过于繁忙"多数是速率限制，不是网络问题，先看错误码再动手。
- 错误码 1302 / 1303 / 1304 分别对应并发、TPM、RPM 超限，解法完全不同。
- Agent 单次提问背后常是多轮模型调用，token 消耗天然高于普通对话。
- 上下文从 8K 压到 2K 以内，比任何重试策略都管用。
- 重试必须带随机抖动，且要有次数和总耗时的硬上限。
- 长期跑生产环境，别把核心能力放在公共智能体上。
相关推荐
- **阅读相关专题**：[AI Agent 工程实践专题](https://vergex.cn/topic/ai-agent-engineering)，包含上下文管理、工具调用、成本控制等系列内容。
- **查看工具推荐**：访问 [VergeX AI 工具导航](https://nav.vergex.cn)，按"Agent 开发""RAG 与向量数据库"分类筛选，快速找到适合自己技术栈的方案。
- **订阅更新**：VergeX 每周更新 AI 技术雷达简报，可通过站内邮件订阅或关注公众号获取，第一时间收到大模型 API 限流、定价与配额政策变化的解读。
参考来源：
- 智谱 AI 开放平台开发者文档，《API 错误码与速率限制说明》，官方文档持续更新，本文引用版本为 2025 年 10 月。
- GLM 团队，《ChatGLM: A Family of Large Language Models from GLM-130B to GLM-4 All Tools》，arXiv:2406.12793，2024 年 6 月。
- Marc Brooker，《Exponential Backoff And Jitter》，AWS Architecture Blog，2015 年 3 月 4 日。