用户看到一个任务，数据中心看到一串负载

Agent 产品最容易被误读的一点，是把它想成「更聪明的一次回答」。用户说一句话，Agent 做完一件事，看起来就像普通聊天模型多了一点工具能力。

数据中心看到的不是这样。

一次真实 Agent 任务，可能先让模型理解目标，再调用搜索或数据库工具，等外部系统返回后把结果喂回模型；模型再生成计划，调用第二个工具；中间失败一次，改参数重试；最后总结结果，写入记忆，生成给用户看的报告。用户只看到「助手处理好了」，底层却是一串推理、工具等待、上下文增长和状态迁移。

这和单轮问答不是一个负载模型。单轮推理主要关心这次请求的输入输出 token。Agent 还要关心任务链条有多长，每一步是否需要重试，工具返回会不会拉长上下文，多个用户同时运行长任务时，GPU 队列、网络和 KV cache 怎么调度。

所以 Agent 产品化的瓶颈，不只是模型会不会调用工具。它还会卡在容量上。

工具调用天然会把一次请求拆成多轮

OpenAI 的 function calling 文档把工具调用流程写得很清楚：模型先根据上下文产生工具调用，应用执行函数，再把函数结果返回给模型，模型继续生成后续响应或下一步调用。这个循环正是 Agent 把一次任务放大的基础机制。

普通 API 调用可以结束在一次返回。Agent 很难。只要工具结果会影响下一步决策，就必须把结果带回模型。只要任务目标还没完成，就可能继续调用工具。只要外部环境不稳定，就可能重试、改路由、补上下文。

OpenAI 对 Codex agent loop 的拆解也说明了同一件事。Coding Agent 在任务循环里反复读代码、编辑、运行命令、检查结果、修正计划。prompt 会随着循环继续携带任务、观察和中间状态。

这就是为什么 Agent 的容量需求比普通聊天更难预测。一个用户点击一次「执行任务」，可能对应 3 次模型调用，也可能对应 30 次。它的成本、延迟和资源占用，取决于任务难度、工具质量、失败率、上下文控制和停止条件。

电力是容量上限

宏观上，AI 数据中心用电增长已经不是新话题。Lawrence Berkeley National Laboratory 的 2024 年美国数据中心能耗报告给了一个更贴近生产侧的基线：美国数据中心用电 2023 年约 176 TWh，占全美用电 4.4%；到 2028 年可能升至 325 到 580 TWh，占比约 6.7% 到 12.0%。报告还单独讨论了服务器、存储和网络设备的能耗变化，提醒我们 AI 数据中心不是只有 GPU 吃电。

这组数字本身已经足够大，但放到 Agent 上还要再看一层：Agent 推动的是推理需求，而不是只推动训练需求。

训练可以排计划、攒批次、调窗口。在线 Agent 更麻烦。用户希望它随时可用，企业希望它接近业务系统，任务又可能持续几分钟甚至更久。一次长任务中，模型和工具交替等待，GPU 不能只按理想满载算。容量不只是「总 FLOPS 够不够」，还包括峰值、排队、响应时间和局部资源可用性。

EPRI 的《Scaling Intelligence》把美国 AI 电力容量讲得更具体。报告估计美国 AI power capacity 当前约 5 GW，到 2030 年可能超过 50 GW；同时指出 training 与 inference 的分配很不确定，而 reasoning models 可能把需求进一步推向 inference。这个不确定性很关键。Agent 产品如果规模化，推理侧不是训练侧的尾巴，而会变成独立的容量规划对象。

推理容量不是一块 GPU 的吞吐

很多人谈推理容量，会先看单卡吞吐、每秒 token 或每百万 token 成本。Agent 让这个口径变得不够用。

LLM 推理至少有两个阶段：prefill 和 decode。prefill 处理输入上下文，通常更像大块计算和内存访问；decode 逐 token 生成，更受延迟和带宽影响。DistServe 这篇论文的核心就是把 prefill 和 decode 解耦，因为两者资源需求和延迟目标不同，混在一起会互相干扰。

Agent 会同时放大这两个阶段。

上下文会增长，prefill 变重。工具返回、代码片段、日志、检索材料、历史状态都会塞进下一轮模型请求。任务链越长，每次模型调用要处理的上下文越容易膨胀。

生成会变碎，decode 变难调度。Agent 不一定一次生成很长答案，它可能多次生成短计划、工具参数、修正说明和最终报告。大量小段 decode 混在长上下文 prefill 之间，会让服务系统更像复杂调度器，而不是简单批处理机器。

这也是为什么「模型便宜了」不等于「Agent 容量问题消失」。价格下降会鼓励更多调用，更多调用会让链路更长，链路更长又会把容量问题推到队列、缓存和网络上。

KV cache 和网络会成为一等问题

NVIDIA Dynamo 的文档把大规模推理的方向说得很明白：它强调 disaggregated serving、KV cache offload/onboard、跨节点低延迟数据传输和大规模推理服务调度。这里每个词都和 Agent 有关。

Agent 任务不是孤立请求。一个任务的前几轮推理会产生上下文状态，后几轮可能还要继续用。为了降低重复计算，系统会依赖 KV cache。问题是，任务不一定总落在同一张卡、同一台机器或同一个服务池里。只要需要迁移、复用或卸载 cache，网络和存储就进入关键路径。

这和传统 web 服务不同。普通请求的状态通常存在数据库或缓存里，体积和访问模式比较清楚。LLM 的 KV cache 体积大、和模型结构绑定、对延迟敏感，还可能随长上下文快速增长。Agent 越长程，cache 管理越像核心基础设施。

所以未来 Agent 平台会越来越关心几个底层问题：

  • 哪些任务可以固定在同一推理池，减少 cache 迁移。
  • 哪些上下文应该压缩或摘要，避免 prefill 越来越重。
  • 哪些工具等待期间可以释放 GPU，哪些状态必须保留。
  • 多个 Agent 并行时，如何避免网络和 cache 把 GPU 吞吐吃掉。
  • 高优先级任务和低优先级后台任务如何分层排队。

这些问题听起来不像产品功能，但会决定产品体验。用户感受到的是 Agent 快不快、稳不稳、贵不贵；工程上对应的是调度、缓存、网络和容量。

Dynamic reasoning 会让成本变成分布，而不是定价表

《The Cost of Dynamic Reasoning》这篇论文从基础设施角度分析 AI Agents 和 test-time scaling，核心提醒是：当系统从单轮推理转向动态推理工作流，资源使用、延迟、能耗和数据中心需求都会变得更难预测。

这个判断很适合放在 Agent 产品里。静态推理像定价表，输入多少、输出多少，大致能估。动态推理更像分布：多数任务可能很短，少数任务会拖很长；多数工具调用会成功，少数会反复失败；多数上下文可控，少数会因为代码库、日志或检索材料膨胀。

企业采购 Agent 时，如果只看平均成本，很容易低估尾部。影响用户体验和基础设施成本的，往往是 P95、P99 任务：那些工具慢、上下文长、重试多、需要人工确认、最后还要生成大报告的任务。

这也解释了为什么 Agent 平台迟早要给用户提供预算、队列和停止条件。没有这些，Agent 会把不确定性留给账单和延迟。

Agent 产品经理也要懂一点容量

这篇文章不是要把每个产品经理都变成数据中心工程师。但 Agent 产品如果要进生产，产品设计不能完全无视容量。

几个设计选择会直接影响基础设施：

  • 是否允许无限循环，决定最坏情况下的资源消耗。
  • 是否把所有工具结果都塞回上下文，决定 prefill 压力。
  • 是否支持后台长任务，决定队列和优先级策略。
  • 是否默认并行多个子 Agent，决定峰值容量和网络压力。
  • 是否对用户展示预算和进度，决定任务能否被提前中止。
  • 是否把记忆写入和检索做成默认动作，决定额外推理和存储负担。

这些不是纯工程细节。它们会影响产品定价、免费额度、企业 SLA、故障体验和用户信任。一个 Agent 如果经常「看起来在努力」，但后台不断重试、排队、扩上下文，用户迟早会把它理解成慢和贵。

竞争会落到容量效率

未来一年，Agent 产品当然还会比模型能力、工具生态和工作流设计。但更深的一层竞争，会落到容量效率。

同样完成一个任务，有的平台需要 20 轮模型调用，有的平台只需要 6 轮；有的平台每轮都带长上下文，有的平台能把状态压缩成更短的任务记忆；有的平台工具失败率高，有的平台工具 schema 和验证做得好；有的平台 cache 和调度粗糙，有的平台能把 prefill、decode、KV cache 和网络协同起来。

用户未必知道这些差异，但会感受到结果：谁更快，谁更稳，谁更便宜，谁在高峰期不掉队。

Agent 的上限不只由模型智商决定，也由基础设施能否承受动态推理决定。一次任务变成一串推理之后，的产品化问题就不再只是「它会不会做」，是「它能不能在有限电力、网络和推理容量里稳定地做」。