AI Agent 如何重塑计算负载与性能挑战

从传统推理到 Agentic 工作流：AI 计算范式的根本转变

过去几年，大多数人对 AI 推理的理解还停留在「一问一答」的模式——输入一个 prompt，模型返回一个答案，流程简单得像抛接球游戏。据 YouTube 上关于 AI agent 的分析视频指出，这种传统推理本质上是一个「简单的抛接球游戏：一个 prompt 进，一个答案出」。

但 AI agent 的出现彻底改变了这一格局。视频中强调，「agent 不只是回答问题，它实际上在做工作」。这意味着计算负载的性质发生了根本性变化，AI 系统不再是一个被动的问答机器，而是一个主动执行任务的实体。

这种转变的意义远超表面的功能升级。当 AI 从「回答者」变为「执行者」，整个技术栈需要重新思考：计算资源如何分配？延迟如何控制？系统吞吐量如何保障？这些问题在传统推理时代并不突出，但在 agentic 工作流中变得至关重要。

Agent 的工作循环：推理、规划、调用与迭代

理解 AI agent 带来的性能挑战，首先需要理解它到底在做什么。根据该视频的拆解，一个 agent 完成任务的流程远比单次推理复杂得多。

Agent 的核心工作循环包含以下环节：

• 推理（Reasoning）：对任务进行分析和拆解，理解目标与约束条件
• 规划（Planning）：制定执行步骤和策略，决定先做什么、后做什么
• 工具调用（Tool Calling）：调用外部 API、搜索引擎、数据库等工具获取信息
• 代码执行（Running Code）：在沙箱或运行环境中执行代码，完成具体操作
• 结果解读与迭代（Interpreting & Iterating）：分析执行结果，判断是否达到目标，如果未完成则回到推理环节重新规划

这个循环的关键特征在于「迭代」——agent 会「一遍又一遍地重复，直到任务完成」。这与传统推理的一次性输出截然不同，每一次迭代都意味着新一轮的模型推理、工具调用和结果处理，计算开销成倍增长。

自主性带来的全新建算负载挑战

Agent 的自主性是其最大价值，也是其最大技术挑战。视频中明确指出，「这种自主性带来了全新的计算负载类型，以及一系列全新的性能挑战」。

具体来看，这些挑战体现在几个维度：

不可预测的迭代次数。 传统推理的延迟是相对确定的——你知道一次 forward pass 需要多久。但 agent 的迭代次数取决于任务复杂度、工具返回结果的质量、以及模型自身的判断，可能两轮就结束，也可能十轮还在循环。

工具调用的外部依赖。 每次工具调用都涉及网络请求、API 响应时间、可能的失败重试，这些外部因素会显著影响端到端延迟。

计算资源的动态需求。 一个 agent 任务可能同时涉及推理（GPU 密集）、代码执行（CPU 密集）、工具编排（IO 密集）等多种负载类型，对基础设施的弹性调度能力提出了更高要求。

状态管理的复杂性。 多轮迭代意味着需要维护上下文状态、中间结果、执行历史等信息，内存和存储开销远高于无状态的传统推理。

有状态推理与传统无状态推理的区别。 传统的一问一答推理可以视为无状态服务：每次请求携带完整的上下文，模型执行一次前向计算后返回结果，系统无需在请求之间保留任何信息。而 agent 的工作循环天然是有状态的——多轮迭代中的规划结果、工具返回、代码执行输出都需要被持续维护并注入下一轮推理的上下文。这种有状态特性带来了两个直接后果：一是上下文窗口会随迭代不断膨胀，导致每轮推理的输入 token 数递增，注意力计算的开销呈超线性增长；二是会话状态需要在 GPU 显存、主机内存甚至外部存储之间分层管理，否则要么挤爆显存，要么因频繁换入换出而拖垮延迟。这也是为什么 KV Cache 复用、前缀缓存（prefix caching）等技术在 agent 场景下变得尤为关键。

对 AI 基础设施的深远影响

Agentic 工作流的兴起正在倒逼整个 AI 基础设施层进行升级。从推理引擎到编排框架，从延迟优化到成本控制，每个环节都需要针对 agent 特有的工作模式重新设计。

传统的推理优化聚焦于单次请求的吞吐量和延迟，但 agent 场景下，优化目标变成了「任务完成时间」和「任务成功率」。这要求系统不仅要快，还要能智能地调度多轮迭代中的各类资源，在推理、工具调用和代码执行之间找到最优的编排策略。

对于开发者和企业而言，理解这一范式转变是构建可靠 AI agent 应用的前提。Agent 的能力边界不仅取决于模型本身的智能水平，更取决于底层基础设施能否支撑其复杂的执行循环。

任务级编排与传统请求级调度的差别。 传统推理服务的调度单位是单次请求，调度器关注的是如何在给定并发下最大化吞吐、最小化 P99 延迟，典型策略如连续批处理（continuous batching）。但 agent 场景下，调度单位变成了一个跨越数十秒甚至数分钟、包含多次模型调用与外部 IO 的任务。这意味着调度器需要具备跨轮次的全局视角：哪些 agent 正在等待工具返回、哪些可以立即推进推理、哪些陷入了无效循环需要被截断。同时，成本核算的口径也从「每千 token 多少钱」转向「每个成功任务多少钱」，因为一个 agent 任务可能消耗数万 token 并触发多次 API 调用。这种从请求级到任务级的视角转换，正是 agentic 工作流对基础设施提出的最本质要求。