我们和不少做 Agent 的团队聊过，共识越来越清楚。Agent 跑起来的负载形状和单次模型调用完全两回事。
单次推理是平的，Agent 是 burst
单次推理是一个请求进来，跑完，出去，流量能画成一条平稳的线，配资源照着平均来就行。Agent 不是。它先规划，再循环，中途可能并行调一堆工具，某个分支突然要算一大坨，算完又安静下来。它的负载是 bursts，一会儿平，一会儿猛。我们给一个做代码助手的团队画过一天的算力曲线，平的时候几乎贴着零，猛的时候十分钟里翻了二十倍。
按平均配，两头不讨好
给 Agent 配算力不能按平均值配。你按平均配，空闲时白养着机器，突发时那一下又不够，队列堆起来，用户就卡住。我们见过太多团队，平时 GPU 利用率低得心疼，一到业务高峰就掉链子。更糟的是，有些团队为了防突发，按峰值常备机器，结果那部分机器百分之九十时间在睡觉，钱照扣不误。
几种模式，算力要求各不同
一种是规划加执行分开，编排层轻量常驻，真正吃算力的工具调用弹性拉起。一种是长任务拆成很多小步，每一步单独调度，哪步忙就给哪步加资源。还有一种带反思回路，模型自己判断要不要重试、换条路，这种最费算力但也最稳，适合容不得错的任务。我们见过一个团队把反思回路开太猛，每步都重试三遍，算力直接翻倍，后来改成按置信度触发，费用降回去，准确率没掉。
对底层设施的三条要求
第一，扩容要快，突发来了能在秒级把机器加上，不能等扩完那波尖峰早过去了。
第二，缩容要干净，任务一停资源立刻释放，很多账单的坑就藏在忘了关里。
第三，调度得懂任务之间的依赖，知道哪些能并行、哪些得排队，不然弹性变成乱弹，加再多机器也白搭。
最差的情况：用稳态卡扛突发
拿给稳态负载设计的专用卡去扛 Agent 的突发，卡在那里要么闲死要么堵死。我们见过一个做客服 Agent 的团队，月初按历史平均租了固定数量的卡，大促那天咨询量翻了五倍，卡不够，排队排到用户放弃。后来改成弹性，峰值自动加机器，平时缩到零，账单反而降了。
我们的方向：调度感知负载形状
我们把调度本身做成能感知负载形状的东西。不是给一个固定大小的池子，而是让资源跟着任务节奏走。平时不占，要时立刻有，用完马上走。落地靠的是对每一步任务的资源画像，知道这一步大概吃多少显存、跑多久，提前半步把卡备好。比如编排层预判下一步要调一个图像生成的工具，就提前在就近区域把对应显存的卡暖好。
我们的弹性策略长什么样
落到配置上，我们对每个 Agent 任务设两样东西：扩缩容的触发条件和每一步的资源画像。
agent_autoscale: scale_up: p95_latency > 800ms # 延迟超阈值，秒级加机器 scale_down: idle > 60s # 空闲一分钟，释放 min_replicas: 0 # 平时缩到零 per_step_profile: true # 按步骤预判显存与时长有了每一步的资源画像，编排层能提前半步把卡备好。比如预判下一步要调一个图像生成工具，就提前在就近区域把对应显存的卡暖好，等调用真来了，机器已经在等它。用户那头感受到的，是 Agent 一直挺快，他不会知道背后有一套调度在跟着他的任务一惊一乍地加机器、撤机器。那套调度做得越好，他越感觉不到它的存在，这才是弹性该有的样子。
Agent 要的就是这种弹性。它自己不知道下一步要算多少，平台得替它把不确定接住。我们给一个接入的客户算过，改造前后同样的高峰流量，机器费用降了四成，用户侧感知到的等待反而更稳，因为他不用再和别人抢那批固定配额的卡。弹性做得越好，他越感觉不到它的存在，这才是弹性该有的样子。