你让一个 AI 助手“查资料、比价格，再写份建议”。表面上只有一句话，背后却可能同时启动许多工具调用；其中一步失败，它还会连续重试。一次点击，转眼变成一群同步涌来的请求。为日常客流设计的自动扩缩容，未必来得及增开“收银台”。
这正是 Shoumik Chakravarty 在文章《Three Generations of Autoscaling》中提出的问题。自动扩缩容（autoscaling）会根据请求量、CPU 使用率等指标增减服务器资源。它过去主要面对人发起的访问，如今却开始面对能自行编排任务的 Agent。作者认为，后者带来的流量更突然、更相关，也更容易自我放大。
不过，文章摘录在解决方案刚展开时便中断。以下判断都来自作者一人的工程经验，缺少公开实验、测量口径和独立验证，应看作一份值得警惕的工程观察，而不是已经证实的普遍规律。
不是人变多了，而是一次请求裂开了
传统容量规划会参考历史峰值、使用时段和业务活动，决定预留多少计算资源。作者把这种做法称为第一代思路：提前预判，再预热机器。他以大型视频直播为例，团队会在重大活动前配置 EC2 资源、检查负载均衡，并设定扩缩容上下限。
第二代思路是 Serverless——云平台管理底层服务器，按需求分配资源，开发团队不必长期维护固定机器。它不再要求工程师事先猜准峰值，而是观察负载后自动反应。
Agent 同时为两种办法制造了麻烦。按作者的说法，它的突发可能由某次任务编排触发，没有固定时刻；并行 fan-out——把一个任务拆成许多并发调用——或紧密循环，甚至可能在毫秒级达到满速。第一代方法不知道该在何时预热，第二代方法则可能等 CPU 等监控信号升高后才行动，此时服务已经承压。
更关键的变化是，请求不再彼此独立。许多用户陆续访问时，快慢通常能相互摊平；一个 Agent 却可能一次生成大量同步调用。若没有明确的 retry budget（重试预算，即一次任务最多允许重试多少次），程序还可能把局部故障放大成 retry storm——大量重试反过来继续挤占资源。
请求数量，也不再等于工作量
过去，“来了多少次请求”常能粗略反映系统负担。作者认为，这个指标在 Agent 场景下可能失真：一条复杂的 reasoning chain（多步推理链）消耗的计算量，可能超过一千次轻量调用。这个数字没有给出测试条件，但它点出一个实际问题：只按请求数扩容，可能把一次简单查询和一次漫长推理当成同样的工作。
Serverless 也不会自动解决成本问题。平台可以忠实执行循环里的每次冗余调用，并逐次计费；等监控发现异常，账单和资源消耗可能已经发生。换句话说，扩得动不等于扩得对。
为什么现在值得看
作者所在组织的服务需要支撑每分钟数百万请求，并维持 99.99% uptime（可用性）。这只是其职责背景，并非研究结果。但文章提出的视角很重要：容量规划过去主要预测“会来多少人”，以后还要理解“一个 Agent 获准做多少事”。
部分 Agent 推理任务据称可以容忍数秒甚至数分钟延迟，这留下了调度空间：系统未必需要立刻放行所有内部调用，而可以利用等待余量安排资源。不过，原文在“基于行为的扩缩容”刚开头便截断，尚不足以说明具体如何识别行为、限制并发或分配预算。
局限与未知
- “毫秒级满速”“重型推理超过一千次轻量调用”等说法没有测量方法、实验数据和适用边界。
- 作者称 Agent 同时击穿七项假设，并让 on-demand 与 Serverless 两种模型失效；不同冷启动时间、并发限制、退避策略和计费方式可能改变结论。
- 标题提到“三代扩缩容”，现有摘录只完整解释了两代；所谓第三代及四层应对方案均未展开。