AOS-Bench：LLM 智能体能管理动态工作负载吗？
arXiv 上发布的一篇新论文（arXiv:2610.33178，cs.AI）由 Erle Zhu 与另外四位作者提交，探讨编码智能体从“一次处理一个请求”转向成为持续运行的助手这一转变。现实中的使用场景往往是：用户在同一个机器上同时托付一串工作——一次构建、一个数据处理任务、一个 bug 修复可能都处于待处理状态。这样的智能体必须自行决定何时接取新任务、如何委派与并行重叠，以及如何在机器的 CPU 与内存限制内完成任务。现有基准无法衡量这一点，因为它们把每个任务隔离起来单独评估。
为此，作者提出 AOS-Bench，把智能体系统当作“工作负载管理器”来评测：经过验证的任务随时间陆续到达，必须在共享的 CPU 与内存上限下交付完成；作为参照，同一批任务以一次一个的方式运行，形成每个系统自身的基准线。
在五组“模型—运行框架”组合上的结果显示，隔离环境下的任务成功率并不能均匀地迁移到流式负载场景。在重型工作负载下，每个系统都会损失 13 到 23 分。在中等负载下，各系统在隔离成功率上的差距为 11 分，但在流式场景中的差距扩大到 26 分；有两个系统在隔离测试中仅相差 0.6 分，却分别完成了同一批任务的 54% 和 68%。
针对执行策略的干预实验把这一差距很大程度上归因于任务接取环节：串行调度会让重型负载下 73% 的任务无人认领。然而，更复杂的管理机制未必带来帮助——固定并发度为 2 的策略在中等和重型负载下都与最佳的智能体自主管理策略相差不超过 4 分。此外，在所有策略下，当任务处于等待状态时，CPU 使用率的中位数始终低于所配置核心数的 30%。
这些结果说明，工作负载管理应被视为智能体的一项独立能力，而 AOS-Bench 提供了衡量这一能力的手段。该论文于 2026 年 10 月 23 日提交，DOI 为 10.48550/arXiv.2610.33178，可通过 arXiv 获取 PDF、实验性 HTML 版本及 TeX 源码。