北京
我的智能体第一次在生产环境里翻车时，我和所有人一样，第一反应是去抓幻觉。换更精准的提示词，收紧输出结构，加更多护栏——全都没用，问题根本不在这层。智能体的推理能力没问题，真正在反复垮掉的，是管道本身。而罪魁祸首，竟然是最不起眼的那一个：速率限制。
很快我就发现，这不是我一个人的困境。速率限制，是当下大语言模型应用在生产环境里的头号故障模式，但几乎没人愿意谈它。原因很简单，这玩意儿不上台面，放不进漂亮的演示里。
一句话概括：在生产环境里，把你的智能体搞崩的，通常不是推理能力退化，而是容量。在真实链路追踪数据里，模型供应商的速率限制报错，已经成了大模型调用失败的最大来源之一。演示环境每次都只发一个请求，单用户，单条快乐路径。而生产环境里一个智能体会瞬间扇出几十个链式调用，并发、重试、指数级叠加，狠狠撞在那些演示里根本触发不了的速率墙上。能救你的不是更聪明的模型，而是容量工程：用量预算、背压控制、带抖动的重试机制、备用模型，还有缓存。
没人往融资计划书里写的数据，恰恰是这里需要正视的。在Datadog针对真实大模型可观测性链路所做的分析里，速率限制报错在所有大模型调用失败中的占比极高。2026年3月，大约三分之一的大模型调用报错都是速率限制，绝对数量以百万次来计。他们的结论很直白：当你大模型应用的头号故障模式是容量，你就该加倍投入容量工程，而不是继续死磕提示工程。
这句话值得想三秒。故障模式不是因为模型笨。故障模式是模型供应商回了你一句“请求过多”，而你的智能体对这一句回复，完全没有任何应对预案。
这几乎完美地嵌进了最近所有人都在讲的“智能体在生产中翻车”的叙事。演示骗人并不是出于恶意，而是结构性的。演示环境跑的是单次干净请求，单用户，单条理想路径。生产环境面对的是并发、重试、扇出和负载压力——这正是批量制造速率限制报错的完美温床。那个在笔记本里跑得好好的，和凌晨三点在高负载下还跑得动之间的差距，远比大多数人愿意承认的，就是一个披着可靠性外衣的容量缺口。
为什么智能体撞这堵墙时，比聊天机器人惨得多？普通聊天机器人每轮用户对话只发一次API调用。智能体完全是另一种生物。一个单次“任务”会膨胀成：一次规划调用；循环中N次工具选择调用；每次拿到工具结果后再调用一次决定下一步；每一步出点小波动就加上重试；还常常再挂一两个子智能体，每个子智能体都自带循环。于是一个用户动作轻松变成10到40次模型调用，还常常是并发的，常常在重试。这个翻倍效应正是智能体存在的全部意义，但它同时也恰恰是把你一步步送进速率限制的路径。更糟的是，最天真的失败响应会让灾难升级：一次调用收到429报错，框架立刻重试，这次重试又立刻收到429，于是一个速率限制报错被你手动引爆成一场重试风暴，把整条链路全部拖垮。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
