限流限在请求这一层，是 HTTP 时代留下的肌肉记忆。但 agent 的成本曲线不在这儿：一个任务背后是一串模型调用，中间夹着工具调用、重试、上下文重放，具体跑几次由 agent 自己决定，不由你决定。按 RPS 限流，挡得住脚本小子，挡不住一个跑飞的 agent。我的判断很直白——闸门得装在任务上。
请求数是个假指标
这周有条新闻挺扎眼，TV4 因为 AI agent 把整季素材删了，节目推迟到 2027，标题里写「hundreds of days of work gone」。
这事跟限流什么关系？关系在于——从请求层看，那次删除可能是几十次工具调用，每一次都合法、都成功、都在配额内。限流器会全部放行，因为它看到的是小请求。从任务层看，这个任务从一开始就不该有写权限、不该无限预算地跑下去。
再看这篇 I Deleted 168,000 Lines of Comments. My AI Agent Didn't Notice。16.8 万行注释没了，agent 没吭声。这说明 agent 任务的规模可以远超人脑预估——你觉得「这得跑一会儿」，它可能已经干完了，也可能正在干你没想到的事。
所以请求数是个假指标。它衡量流量，不衡量风险。
两个闸门，乘起来才是上限
第一个闸门：按租户设并发任务数上限。这个数跟你的配额预算挂钩，不跟 QPS 挂钩。
第二个闸门：单任务成本上限。token 预算、工具调用次数、墙钟时间，挑最紧的那个当硬闸。
超了怎么办？我的做法是让 agent 自己收尾——预算到八成时给一条系统提示「该收敛了，把已有结论写出来」，到顶硬断，返回半成品加一个标记。硬断比继续跑强，半成品还能用，账单不能。
关键在这是乘法关系：租户并发 20、单任务预算 X，最坏情况成本就是 20X，能算出来。按请求限流你算不出这个数，只能祈祷。
反面我认：限死并发，批处理会排队到难看
这是这套方案最容易被骂的地方。夜里跑几千个文档摘要，每个任务几十秒，并发压到 20，剩下的全在队列里躺着，尾部延迟会难看到没人愿意看仪表盘。
所以别用一个队列。交互式和批处理分开：
交互式队列并发小，但优先级高、可抢占，用户的请求永远排在批处理前面。批处理队列并发大，但受总预算池约束，可以慢、可以半夜跑、可以在预算吃紧时整体降速而不是单个失败。
顺带的好处是批处理成本能摊到非高峰，跟配额曲线对齐。
Agent37 那个低成本 agent 沙箱在做同一件事的另一半——把每个任务的资源边界做成产品。沙箱管隔离，限流管额度，两样都得有。端侧那类模型（比如这周的 LFM2.5）思路相反，成本压得低，但延迟敏感，更该走交互式队列那条路。
那个数怎么定
我不给具体数字，给了在你这儿也不对。方法是这样：
先跑一周，记录每个任务的成本分布——token、工具调用数、墙钟——看 P50 和 P99 差多少。agent 任务的尾巴特别长，长到你按平均值做预算一定翻车。
单任务预算定在 P99 偏上一点。定 P50 会砍掉一大批正常任务，定太松等于没闸门。
并发数倒着算：先算你能承受的最坏总成本，除以单任务预算，就是并发上限。粗暴，但你能跟老板解释清楚。
只有一个滑块的控制台，多半没被账单教育过
按请求限流不是错的，它管的是别的事——防滥用、防爬、防雪崩。成本控制是另一个问题，得用另一个闸门。
我现在的偏见是：任何 agent 平台，控制台上如果只有 QPS 一个滑块，那它大概率还没被账单教育过。也许半年后回头看这套双闸门会觉得太朴素，但现在，它至少算得出来。