并非所有AI代理都相同：特征化资源与性能动态

# 并非所有AI智能体都一样：资源与性能动态特征分析
来源：https://arxiv.org/html/2609.19947
## 并非所有AI智能体都一样：资源与性能动态特征分析
致谢：∗部分内容完成于微软亚洲研究院实习期间。
致谢：†通讯作者。

Wonmi Choi1,∗, Minuk Park1, Zhixiong Niu2, Yongqiang Xiong2, Chuck Yoo1,†, Gyeongsik Yang1,†
所属机构：1高丽大学计算机科学与工程系 2微软亚洲研究院

###### 摘要

基于大语言模型（LLM）的AI智能体通过迭代推理和工具执行处理用户请求，通常涉及调用远程LLM API与本地工具容器。这种执行模型可能使智能体服务优化变得困难，因为延迟、本地资源需求和容器瓶颈会在请求间相互交织。然而，当前智能体生态系统运行时较少考虑资源动态，导致宝贵资源的严重浪费。本文针对检索增强问答、网络搜索和软件编码三类代表性任务，分析了AI智能体的资源交互特性。为此，我们从处理并发多请求和任务的角度，表征了延迟与资源动态的关系。测量结果表明，智能体行为因任务类型不同而呈现显著差异，即使相同工具在不同任务中的资源动态也可能截然不同。我们还发现，运行多个并发请求会暴露不同任务中CPU、磁盘I/O和内存等方面的瓶颈。进一步揭示：更快的LLM响应或更多CPU核心并不总能加速智能体执行。基于这些观察，我们提出了利用任务资源动态的新优化机会：CPU感知的工具准入控制和任务感知的CPU分配。实验结果显示，CPU敏感型智能体任务的延迟提升约5.4倍，多任务平均延迟相比原生智能体降低约32%。

###### 关键词：

AI智能体、工具执行、性能分析、资源动态、大语言模型

## I引言

基于大语言模型（LLM）的AI智能体通过迭代推理和工具执行自动化处理用户请求。单个智能体请求需要经过多次迭代完成，每次迭代包括基于LLM的推理步骤和根据推理结果运行外部工具的执行步骤。这种工作流程支持检索增强问答（RAQA）、网络搜索和编码（软件工程）等多种任务，但也使得智能体服务不同于传统的单轮LLM服务：延迟和资源需求由多次异构迭代决定，而非单次推理。

AI智能体的常见部署模式是将LLM推理与本地工具执行分离。由于在本地托管有竞争力的LLM需要大量硬件资源[1 (https://arxiv.org/html/2609.19947#bib.bib5)]，且闭源模型常在智能体任务上实现高精度[2 (https://arxiv.org/html/2609.19947#bib.bib3),3 (https://arxiv.org/html/2609.19947#bib.bib4)]，智能体服务通常依赖Gemini、GPT和Claude等远程LLM API。相反，工具执行通常在本地容器（也称为沙箱）中运行，因为工具可能消耗资源、访问外部服务并修改执行状态¹。虽然某些AI智能体在云中运行工具容器，但工具运行时仍与远程LLM推理服务分离。这种模式在Codex CLI、Claude Code和GitHub Copilot智能体模式等实际智能体中很常见，它们在读取文件、编辑代码、运行命令和执行测试时与远程LLM交互[4 (https://arxiv.org/html/2609.19947#bib.bib23),5 (https://arxiv.org/html/2609.19947#bib.bib19),6 (https://arxiv.org/html/2609.19947#bib.bib24)]。

服务智能体的一个关键挑战是理解工具容器的性能和资源使用情况。单个智能体请求在远程LLM推理、外部Web/API调用和本地工具执行之间交替进行。由于工具执行直接影响端到端延迟，工具容器的资源需求和瓶颈会显著影响智能体性能[7 (https://arxiv.org/html/2609.19947#bib.bib1)]。这使得资源分配和调度等系统级优化至关重要[8 (https://arxiv.org/html/2609.19947#bib.bib28),9 (https://arxiv.org/html/2609.19947#bib.bib29),10 (https://arxiv.org/html/2609.19947#bib.bib30)]。然而，这种优化很困难，因为智能体不遵循固定的工具执行路径。与每个请求主要在服务容器内处理的传统微服务不同，智能体请求仅在特定步骤调用本地工具，而在其他步骤等待远程服务。因此，本地容器在远程等待期间可能保持空闲，但在工具执行时可能突发需要CPU或较大常驻内存。资源分配不足会延迟关键工具执行，而静态过度分配则在远程等待阶段浪费资源。

先前研究已从多个角度开始研究基于LLM的智能体，包括以CPU为中心的执行[7 (https://arxiv.org/html/2609.19947#bib.bib1)]、基础设施成本[11 (https://arxiv.org/html/2609.19947#bib.bib21)]以及智能体容器的操作系统级资源控制[12 (https://arxiv.org/html/2609.19947#bib.bib2)]。然而，这些研究仅提供片面视角：没有研究联合表征任务类型、请求并发、远程LLM响应时间和工具容器CPU分配如何影响延迟和本地资源使用。这导致不清楚智能体是受限于CPU竞争、常驻内存占用、磁盘I/O压力还是远程LLM等待。

本文对三类代表性任务——RAQA、网络搜索和软件编码——的AI智能体进行了全面分析。我们围绕四个问题组织分析：（1）延迟如何在LLM API调用、外部Web/API调用和本地工具执行之间分配；（2）并发请求下哪些本地资源成为瓶颈；（3）LLM响应时间如何改变本地工具执行的重叠程度；（4）工具容器CPU分配如何影响延迟和资源效率。

我们的测量得出三个主要观察结果。首先，智能体延迟与本地资源需求并非紧密耦合。例如，RAQA主要由本地检索和常驻索引内存主导，而网络搜索缓慢主要由于远程Web/API等待，本地CPU使用很少。这种异质性表明，智能体服务系统不应在不了解工具行为的情况下跨任务应用相同优化。其次，并发性在不同任务中暴露不同瓶颈，包括计算密集型任务中的CPU竞争、写密集型编码任务中的磁盘I/O压力以及共享或每请求状态导致的内存增长。因此，可扩展的智能体服务需要瓶颈感知的资源编排，而非仅CPU或内存控制。第三，LLM响应时间和CPU分配以非平凡方式交互：更快的LLM响应可增加本地工具执行的重叠，而额外CPU核心仅在本地执行处于关键路径时才有帮助。因此，简单使用更快LLM或分配更多CPU并不总能加速智能体请求。

此外，我们表明这些观察可指导智能体服务的优化机会：基于观察的CPU感知工具准入控制和任务感知CPU分配。实验结果显示，我们基于分析的优化将CPU敏感型智能体任务的延迟提升高达5.4倍，混合任务平均延迟降低高达32%。简而言之，我们做出以下贡献。

- •特征分析：分析三类智能体任务和七个基准测试的延迟与本地资源使用。
- •瓶颈分析：识别并发请求下CPU、内存和磁盘I/O瓶颈的出现方式。
- •敏感性分析：分析LLM响应时间和工具容器CPU分配如何共同影响延迟和资源竞争。
- •优化机会：展示基于观察的决策可实现CPU敏感型任务高达5.4倍加速，混合工作负载延迟降低32%。

## II背景

### II-A AI智能体工作流程

AI智能体中的任务指定智能体执行的工作类型和可用工具。代表性任务包括RAQA、网络搜索和编码。工作流程定义智能体通过LLM和多种工具处理每个用户请求以完成任务的方式。ReAct[13 (https://arxiv.org/html/2609.19947#bib.bib6)]是基于LLM的AI智能体的代表性工作流程。在此工作流程中，智能体编排器为每个用户请求维护请求内存状态，存储请求、中间推理结果、工具输出和跨迭代所需的其他上下文。每次迭代包括两个步骤：推理步骤和工具执行步骤。

在推理步骤中，智能体使用当前请求内存状态调用LLM。然后LLM确定请求是否可以完成，并生成最终答案或一个或多个工具调用。如果LLM生成工具调用，智能体进入工具执行步骤。在工具执行步骤中，智能体执行请求的工具并收集其输出。当同一次迭代中生成多个独立工具调用时，可以并行执行。生成的工具输出随后被合并到请求内存状态中，并用作下一次迭代推理步骤的输入。此过程重复直到LLM生成最终答案²。其他智能体工作流程可能在LLM调用频率、规划/反思逻辑或工具级并行性方面有所不同，但许多遵循与ReAct相同的高层循环：推理、工具执行和状态更新。

参见图注 (a)RAQA
参见图注 (b)网络搜索
参见图注 (c)编码

图1：代表性任务的容器结构。
### II-B 智能体工具的容器结构

在许多智能体系统中，推理步骤由远程LLM API执行，而工具执行步骤在单独的本地运行时中运行。这种分离意味着智能体延迟不仅由远程LLM响应时间决定；它还取决于本地工具执行如何在服务基础设施上消耗CPU、内存和I/O资源。

工具通常以容器形式实现。例如，智能体工具包括shell命令、文件编辑、数据库查询、Web/API访问、测试执行和应用程序特定代码。由于它们消耗CPU和内存、访问外部服务并修改文件系统或进程状态，智能体系统在隔离容器中运行它们，而不是直接在主机上运行。最近的平台也反映了这种部署模型（例如，GKE沙箱和Cloudflare沙箱）。

容器结构因任务类别而异。图1展示了三种代表性智能体任务的工具容器结构：RAQA、网络搜索和编码。每个示例显示该任务的两个并发用户请求，标记为请求1和请求2。蓝色框代表工具容器，运行每种任务所需的工具并隔离工具执行。白色框代表暴露给LLM的可调用工具函数。虚线框表示通过网络访问但不直接由智能体框架管理的外部服务，如远程LLM服务或Web API。紫色框代表智能体编排容器，它们接收用户请求、协调LLM调用和工具调用，并维护每请求内存状态。我们的分析重点是工具容器和外部API，因为编排器通常不会产生明显瓶颈。

容器结构在本地工具运行时跨请求共享方式上有所不同。RAQA（图1(a)）和网络搜索（图1(b)）都使用共享工具容器：单个工具容器处理来自多个并发请求的工具调用。在RAQA中，此容器托管知识库并暴露retrieve()工具，该工具为自然语言查询返回排名靠前的证据段落。在网络搜索中，共享容器暴露Web访问工具，如search()和fetch_and_summarize()，它们调用外部Web API并返回搜索结果或摘要的页面内容。因此，尽管RAQA主要依赖共享的本地检索状态，网络搜索还依赖外部Web服务，但两者都遵循相同的共享容器结构进行跨多请求的本地工具执行。

相比之下，编码任务（图1(c)）使用特定于请求的工具容器。每个请求运行自己的终端容器，暴露bash()工具，允许智能体在隔离的文件系统和进程环境中执行命令、运行测试和修改文件。因此，编码智能体通常为不同请求使用独立容器，如图中的终端1和终端2，以避免干扰并保留特定于请求的执行状态。在下一小节中，我们回顾现有的AI智能体研究并解释我们全面分析的必要性。

## III相关工作与研究空白

表I：相关工作比较。研究 本文 Raj[7 (https://arxiv.org/html/2609.19947#bib.bib1)] Kim[11 (https://arxiv.org/html/2609.19947#bib.bib21)] AgentCgroup[12 (https://arxiv.org/html/2609.19947#bib.bib2)] 运行时类型 容器 主机进程 主机进程 容器 分析任务 检索增强问答 ○ ○ ✗ ✗ 网络搜索 ○ ○ ○ ✗ 编码 ○ ○ ○ ○ 单任务分析 CPU ○ ✗ ✗ ○ 内存 ○ ✗ ✗ ○ GPU ✗ ✗ ○ ✗ 并发性分析 CPU ○ ✗* ✗ ✗ 内存 ○ ✗ ✗ ✗ GPU ✗ ✗* ○ ✗ 敏感性分析 LLM延迟 ○ ○ ✗ ✗ CPU分配 ○ ✗ ✗ ✗

✗*：在批处理请求下测量吞吐量，而非直接测量资源使用。

我们回顾现有AI智能体研究并识别剩余空白，这为我们的分析提供了动力。若干先前研究分析了AI智能体，总结如表I。我们从运行时类型、任务覆盖范围和分析范围（包括每任务资源使用、并发行为以及对关键智能体条件（如远程LLM延迟和容器CPU分配）的敏感性）进行比较。

首先，现有研究在运行时类型和任务覆盖范围上不同。Raj等人[7]分析了RAQA、网络搜索和编码智能体，Kim等人[11]研究了网络搜索和编码智能体。然而，这两项研究评估的是作为主机进程运行的智能体。此设置未捕捉容器化智能体的资源行为，其中工具执行是隔离的并受容器级资源控制约束。AgentCgroup[12]研究了容器化智能体，但仅关注编码任务。因此，现有研究未表征跨多种任务类型的容器化智能体执行。我们的工作通过分析三类代表性任务填补了这一空白。

其次，在单任务分析方面，现有研究仅提供部分证据。