先记住这个答案
并发配额应围绕实际占用资源分层设置：租户活跃任务数控制同时推进的工作，租户模型或工具调用数控制扇出，全局及上游维度上限保护共享容量。等待用户输入的任务可以保留持久状态，但不应无意义地占着模型请求许可。租户身份应来自可信认证，所有子任务继承同一归属；多副本部署需要共享的原子许可或可靠配额分配，不能让每台进程各自认为自己拥有完整租户额度。配额上限还要配合公平调度与等待期限，才能改善其他租户的实际体验。
- 任务数和真实外部调用数应分别计量
- 子任务与重试继续归属原租户
- 多副本许可需要一致计数、释放与故障恢复
任务入口限额为什么挡不住内部扇出
假设某租户最多运行两个任务，但每个任务都并行发出二十次模型请求，入口限制仍允许四十个真实调用。另一个租户即使只提交一项交互任务，也可能在同一上游账号下等待很久。因此任务许可与资源许可需要分别定义。
活跃任务的含义也要清楚：等待人工回复、在延迟队列里退避、真正执行工具是三种不同状态。可以为持久任务设置总量和保留期限，同时只在实际使用模型连接时持有相应资源许可，避免大量等待任务耗尽可执行容量。
多副本与子任务必须使用同一归属口径
如果三个服务副本各自允许某租户十个请求，全站真实并发可能变成三十。需要集中原子计数、分布式信号量，或有总额约束的配额分片；应明确服务故障、网络分区和配额刷新期间允许的误差，而不是假定本地计数天然全局有效。
子 Agent、工具重试和后台恢复都应继承可信租户标识，不接受模型自行传入一个新租户来绕过限制。多个层级许可同时获取时，要采用一致顺序、短期保留或失败回退策略，避免拿着全局许可长时间等待租户许可造成容量浪费。
释放、过期和公平性需要一起验证
正常完成、异常退出和取消都应释放对应许可，长任务可通过受控续租保持资格。租约过期时旧进程不一定停止，因此旧执行者继续发请求或提交结果的边界也要受到约束。否则系统计数已经释放，实际资源却仍被占用。
即使每个租户都有上限，单个共享 FIFO 队列仍可能让后来租户排在巨大积压后面。调度器应按租户轮转或采用合适的公平策略，记录等待时间、拒绝率、真实并发与各类资源占用。验证重点是一个租户突发时其他租户的延迟是否仍可接受。
容易答错的地方
- 每租户限制十个任务就等于十个模型请求
- 一个任务可扇出多个请求，也可能完全不使用模型；需要在真正消耗资源的调用边界继续计量与限制。
- 租约到期意味着旧任务已经停止
- 租约只改变资格记录，不会自动终止暂停后恢复的进程；执行与提交边界需要识别过期资格，并谨慎处理已开始的外部动作。
面试官还会怎么问？
大租户能不能临时借用空闲配额？
可以设计受控借用，但应保留其他租户的最低容量或回收机制，并说明借用只影响新调度还是能够安全中断已运行任务。
并发限制和每分钟请求限制重复吗？
不重复。前者限制同时在途的工作，后者限制一段时间内的请求数量；短请求可能低并发却高频，长请求则可能低频但占满连接。
所有工具都使用同一个许可池可以吗？
不同工具可能消耗不同瓶颈资源。浏览器、数据库和模型调用混在同一池里，会让慢工具阻塞无关动作，应按资源边界决定是否隔离。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。