如果你负责过一个真正在生产里跑的 Agent 系统，大概经历过这样的循环：监控面板上端到端延迟居高不下，第一反应是换个更快的模型，延迟动了一点；于是又给容器加 CPU 核，延迟还是不动。钱花了两轮，问题还在。
arXiv 2609.19947 这篇《Not All AI Agents Are Equal: Characterizing Resource and Performance Dynamics》正是冲着这种无效优化来的。作者指出，Agent 的执行模型是「迭代推理 + 工具执行」，而且往往是远程 LLM API 配本地工具容器的混合形态。这种形态让延迟、本地资源需求和容器瓶颈在请求之间互相交织，导致针对单体的传统优化手段全部失效。
一、三类任务，三种完全不同的负载画像
论文选了三个代表性场景做测量：检索增强问答、网页搜索、软件编码。选择很讲究——它们的共同点是都要调工具，差别在于工具的输入输出规模和后续处理深度。
测量的核心方法是：在并发处理多请求、多任务的条件下，刻画延迟随资源动力学变化的曲线。
第一个结论就相当反直觉：Agent 的行为随任务差异极大，以至于同一个工具在不同任务下的资源动力学可以差很多。这一点直接推翻了「给工具标一个静态成本标签」的做法。工具调用本身只是外壳，真正决定资源画像的是输入规模、返回体大小和后续处理方式。同样是执行一次搜索，问答类任务可能只读回几百字摘要；编码类任务则可能要把大量文件内容拉进上下文再解析，磁盘与内存压力完全不同。
对容量规划来说，这意味着一条很硬的约束：不能用工具级别的静态成本模型做资源预估，必须把任务上下文一起建模。
二、并发会暴露「任务相关性瓶颈」
第二个结论更贴近运维现场：并发运行多个请求时，会暴露任务相关的瓶颈，而且这些瓶颈分布在 CPU、磁盘 IO 和内存三处。
这里的机制值得拆开看。单个请求跑的时候，本地资源是富余的，你看到的是模型响应时间主导延迟；一旦并发上来，所有请求会同时挤向同一类资源——大量文件读写撞在一起打爆磁盘队列，或者多个工具进程争抢 CPU。此时延迟不再由任何单一步骤决定，而是由排队决定。
这也解释了为什么单请求压测的数据在真实负载下完全不可用：单请求测的是服务能力上限，并发测的才是调度能力。而 Agent 的调度难点在于它的资源需求是随任务漂移的，不是固定配比。
三、最反直觉的一条：加资源不一定有用
论文里最值得记住的一句是：更快的 LLM 响应或更多的 CPU 核并不总能加速 Agent。
这句话包含两层含义。
第一层，当瓶颈在本地侧时，更快的模型没有用。模型回得更快，只是让你更早进入本地瓶颈，整体时长几乎不变；副作用是并发压力被提前集中，本地资源更容易被打满。
第二层，加 CPU 核在 I/O 等待型任务上收益接近零。对这类任务，核多出来的部分只是在等磁盘；而对 CPU 敏感型任务，核又确实有用。于是「这个系统需要多少核」这个问题本身就没有全局答案——答案取决于任务构成，而任务构成是随时间变化的。
四、两个优化手段，两个实测收益
基于上述观察，作者提出并验证了两个优化：
CPU 感知的工具准入控制（CPU-aware tool admission）。核心是在调度层判断「现在放行这个工具调用合不合算」，而不是不管当前机器状态一律放行。它能避免所有请求同时挤向同一类资源，把 CPU 密集型调用错开或延后，让 I/O 等待型请求先走。
任务感知的 CPU 分配（task-aware CPU allocation）。按任务类型而不是按容器平均分配 CPU 配额，把核给真正需要的任务。
结果是：CPU 敏感任务的延迟改善约 5.4 倍，多任务平均延迟降低约 32%。注意这两个数字的口径不同——5.4 倍是特定敏感任务上的上限收益，32% 是跨多任务的平均收益。后者才是做容量规划时更该参考的数字。
五、这对架构设计意味着什么
把这篇的结论翻译成架构原则，大致有四条。
第一，不要把 Agent 当无状态服务做容量规划。 Agent 是有状态的、阻塞式的、资源画像随任务漂移的混合负载。把工具容器与模型调用当成一个整体来调度，比分别给两边扩容更有效。
第二，给工具执行加并发上限，而不是无限放行。 放任所有工具调用并发是延迟恶化的主要原因，准入控制是投入产出比最高的一处改动。
第三，把「任务感知」作为调度器的一等输入。 调度决策需要知道当前请求属于哪类任务、它的资源画像偏 CPU 还是偏 I/O，而不是只看容器维度的平均占用。
第四，分清优化层次。 KV cache 压缩、连续批处理、prefill 与 decode 分离，都是让推理侧更快更省显存；这篇处理的是模型之外的那一半——工具容器、文件读写、进程执行，以及请求在两侧来回切换产生的排队。两侧要同时优化，否则推进推理侧只会让 GPU 更快进入空闲等待。
最后要说清这篇工作的边界：它是一篇测量与特征化的论文，不是新系统的完整设计；三类任务覆盖面有限，结论外推到开放式研究、多智能体协商这类场景需要谨慎；而且它的收益数字来自受控实验环境，真实集群里的噪声与多租户干扰会稀释一部分收益。
但它给出的判断足够明确，而且可执行：先测清楚瓶颈在哪一侧，再决定优化方向。 在 Agent 这个把远程推理和本地执行缝在一起的形态里，「哪一侧更慢」这个问题的答案，往往和你的直觉相反。