AI Agent Harness工程：容量规划与弹性扩展全解析

做Agent项目最容易被低估的，就是“harness”这一层。很多人以为Agent = 大模型 + 几个Prompt，真到生产环境才发现，推理循环、工具调用、上下文管理、状态存储、可观测性，这些杂活才是工程量的主要来源。我的习惯是把Harness Engineering定义为“Agent的运行时工程”——它决定了你的Agent能撑住多少并发、多快的响应、多稳的迭代节奏。而容量规划与弹性扩展，恰恰是所有agent harness生产化过程中最绕不开、也最容易被做砸的两件事。

这篇文章我想从头到尾拆一遍“AI Agent Harness Engineering 的容量规划与弹性扩展”：先讲清楚为什么Agent工作负载和传统API服务完全不一样，再给一套可以直接套用的容量估算公式，然后落到弹性伸缩的工程方案和实战案例，最后整理一份问题排查笔记。适合正在把Agent从Demo推到生产环境的人，也适合做AI平台基础设施、后端架构、SRE的工程师参考。

1. 把Harness当成一个“系统”来设计容量

1.1 Agent任务为什么比普通API请求更难预估

普通接口服务的容量模型很直接：一个请求进来，后端处理完，返回，QPS基本可以线性映射到CPU、内存和连接数。Agent完全不是一个逻辑。一次用户交互在Harness内会展开成一个循环：模型推理 → 决定调用工具 → 工具请求第三方系统 → 返回结果拼入上下文 → 再次推理 → 循环。一次看似普通的“帮我查一下明天的航班并对比价格”的提问，背后可能是四到六次模型调用，外加两到三次外部API往返。

这意味着同一个用户的一次操作，落到基础设施上是一连串任务，而不是一个请求。我曾经在一个内部系统里统计过，这样一次复合任务的端到端耗时常驻在5到20秒之间，最长的能到1分钟。传统业务把“接口响应时间”作为一个黄金指标，但Agent的黄金指标应该是“任务完成时间”和“任务内模型调用次数”。

更麻烦的是方差。同一个Agent，同一个入口，不同用户的不同输入，带来的token消耗可能差一个数量级。用户问一句“你好”，跟用户扔进来一份30页文档要求摘要，两者的上下文长度、工具调用频次、推理轮数完全不同。如果容量设计只取平均值，那大概率会在高峰期被那些“重任务”打穿。所以做Agent容量规划的第一课，是接受高方差，把它作为一个基本假设写进模型里。

1.2 Harness容量竞争的四个维度

我一向把Harness系统的容量拆成四个维度来盘点。这四个维度缺一个，其他三个做得再好也会被拖死。

推理计算容量：核心是模型并发推理的slot数量。你部署的推理服务能同时处理多少个推理请求，取决于显存、批处理策略、模型大小、是否缓存了KV Cache。这个维度通常是整个链路里最贵的，也是最先卡脖子的。

工具执行容量：Agent要调代码检索、跑单元测试、调用外部API，这些都是实际的计算和网络开销。工具执行池太小，即使推理slot空闲，任务也得排队等工具线程。很多团队做压测，只测模型接口，不测工具链路，一上线就被数据库连接池打满。

状态存储容量：一个有状态的Agent需要保存对话历史、工具执行记录、中间推理结果。这部分如果不做外部化，全留在实例内存里，容量曲线就会被会话数而不是QPS决定。

第三方配额：模型API的每分钟请求数、每分钟token数，第三方工具的调用配额，这是硬上限。它不像计算资源可以靠扩容解决，写进容量模型里的作用就是提醒你：有些瓶颈是钱和配额决定的，不是加机器能解决的。

这四个维度适合放到一张容量盘点表里，就像资产盘点一样。每个维度写清楚指标、当前水位、阈值、扩容手段。在项目里这个表比任何架构文档都有用。

1.3 弹性扩展和容量规划本质上是一件事

历史上很多团队把容量规划和弹性伸缩当成两件事：前者做预算，后者做运行时调度。实际做下来，两者是强耦合的。没有容量基线，弹性伸缩的阈值就是拍脑袋；没有弹性设计，容量规划就必须按最大峰值一次性买断，成本极高。

弹性伸缩的阈值从哪来？就是从容量模型来。容量模型告诉我，单个Agent实例在某个并发量下的最大吞吐是X，那我设置扩容的触发条件就围绕X的70%到80%来做；容量模型还告诉我，任务高峰期持续多久、外部API配额上限是多少，那我就能决定伸缩是激进还是保守。

所以我的建议是：先建容量模型，再写伸缩策略。所有在Agent平台上做的弹性扩展，本质上都是基于容量基线的运行时调度优化。这篇文章后面给的方法，都是围绕这条主线展开的。

2. 容量建模：从一张表到一套公式

2.1 从业务指标换算并发任务数

容量建模不是玄学，有一个很接地气的起点：并发任务数 = 峰值请求速率 × 单个任务平均时长。这个公式基本是Little定律在分布式系统里的翻版。

举个例子。我制定的目标：支撑峰值每秒30个新任务。实测单个任务从开始到结束的平均时长是6秒。那么系统需要的并发任务承载量就是30 × 6 = 180个并发任务。考虑突发波动和故障期间的积压，我会再加20%的缓冲，规划到216个并发任务。

这里有个特别容易犯的错误：拿“在线用户数”或“注册用户数”直接估。在线用户数量大，但很多是空闲的，真正同时跑任务的比率往往很小。所以正确的做法是看“任务起始速率”和“任务平均时长”，这两个数据必须在真实流量或压测里取，不能假设。

有了并发任务数之后，把它映射到资源。每个并发任务占用一个推理slot（或者多个，取决于任务是否并行发起子任务）；同时占用一个工具执行线程；同时产生状态读写的压力。这样从业务目标到资源需求就算是打通了。我在项目里习惯写一张“参数速查表”：

有了这张表，容量规划的讨论就能从“感觉会不够”变成“差多少数量级”。

2.2 token消耗的估算与“预算帽”机制

Agent场景里，Token就是钱，也是容量。Token消耗不规划清楚，弹性扩展做再好也容易被账单打懵。我习惯给每个Agent任务算一个Token消耗模型：总Token = 模型输入Token × 推理轮数 + 模型输出Token × 推理轮数 + 工具返回内容塞入上下文的Token × 工具调用次数。

举一个典型的代码辅助Agent场景。一个任务平均触发4次模型调用，每次输入约2000 token，输出约1000 token，另外触发2次工具调用（代码检索和测试执行），每次工具把大约3000 token的结果塞回上下文。那么一个任务的总Token大约是：4次输入 × 2000 = 8000，4次输出 × 1000 = 4000，2次工具返回 × 3000 = 6000，合计18000 token。如果一个小时有5000个任务，那就是9000万 token 消耗。

这个估算一旦建立，我强烈建议在Harness里加上“预算帽”机制：每个任务设置最大推理轮数、最大Token消耗、最大时长。这玩意儿一开始以为只是防异常，后来发现它是容量管理的关键。没有预算帽，一个死循环任务可能吃掉100个正常任务的资源，弹性扩展根本来不及救你。预算帽给了容量一个明确的上限，预算没了就强制截断，宁可返回“能力不足”也不能无限烧。

2.3 压测闭环：先测出斜率，再定基线

容量模型建好之后，必须用压测验证。Agent压测和传统接口压测差别非常大。传统接口压测只要打一个接口就行，Agent压测要模拟完整的用户对话过程。我在实操里通常写一套压测脚本，构造一个接一个的多轮任务序列，每个任务都包含真实的工具调用与外部依赖模拟，再按阶梯加压观察系统的表现。

关键要看两个东西：一是响应延迟的拐点，比如并发到多少的时候p99突然恶化；二是资源增长的斜率，比如每增加1个QPS，需要增加多少推理slot和多少内存。把这两个点记录下来，容量模型就有了实测校准数据。

我还踩过一个坑：压测脚本只打LLM网关，不打工具执行链路。上线后真实流量一来，工具执行成了瓶颈，系统照样崩。所以压测一定要把“工具调用→外部依赖→结果回填→再推理”这个循环完整跑起来。

这一阶段再配合指标采集、链路追踪和日志，就能把容量模型从理论公式变成有数据支撑的基线。顺带说一句，可观测性不是另外一个Topic，它就是容量规划的一部分。指标告诉你水位，追踪告诉你延迟花在哪，日志告诉你任务为什么失败。三样配齐，后续的容量迭代才能有的放矢。

3. 弹性伸缩落地：指标、单元与会话亲和性

3.1 伸缩单元：别只盯着Pod数量

很多人一谈弹性扩展就想到容器编排平台上的水平自动伸缩。这个方向没有错，但第一步要定义清楚：伸缩的单元是什么。在Agent Harness里，单纯按Pod数伸缩经常失真。一个Pod能承载多少个Agent任务，取决于推理slot数量、工具工作线程池大小、状态存储连接数。瓶颈可能在推理层，也可能在外部依赖连接池。

所以我的做法是：让每个Pod暴露实时的“任务并发数”指标，比如当前活跃Agent任务数、当前推理请求排队数、当前工具执行排队数。伸缩阈值的设置围绕这些业务语义指标，而不是只盯CPU和内存。当然，CPU和内存作为兜底指标也要留着，防止出现资源被耗尽了但业务指标还没上报的盲区。

常用的技术栈是Kubernetes自带水平自动伸缩（按CPU/内存），配合事件驱动自动伸缩组件KEDA（按队列长度、请求速率这类外部指标）。实际落地时我建议双指标策略：业务指标为主（比如任务队列深度超过50），资源指标兜底（比如CPU超过70%）。两个条件满足任何一个都触发扩容，避免队列已经打爆了CPU还没上来这种尴尬局面。

3.2 会话亲和性：有状态Agent的横向扩展难题

Agent任务天然有状态。推理循环里的上下文、工具调用的中间结果、会话的历史记录，这些状态如果都放在进程内存里，那就没法做无状态横向扩展——新Pod接不了旧会话的活。常见的解法有三类。

全量外部状态存储：把上下文和会话快照都放到外部存储里，任何Pod都可以接手任何会话。优点是伸缩自由、故障恢复快；弱点是每轮交互都要读写一次状态，增加延迟，存储设计不好还会成为瓶颈。

推理与执行分离：推理解耦成无状态层，工具执行的临时状态放外部。这是我最常用的方案——推理层的横向扩展最痛快，工具层用连接池和数据分片来兜住；缺点是架构稍复杂。

粘性路由：把同一会话固定路由到同一个Pod。实现简单，上下文天然在内存里，但扩容时新Pod分不到存量会话，导致流量不均；缩容时还得先“排干”老会话，不然会话直接丢失。

我个人的选型偏好是先做推理与执行分离，会话上下文用外部存储来承载，不到万不得已不引入粘性路由。横向扩展能力是Agent系统的核心竞争力，为了省一个Redis的钱牺牲伸缩性，不划算。

3.3 限流、重试与雪崩：弹性里的“软着陆”

弹性扩展并不是万能的，尤其是面对外部API配额的时候。扩容只能解决自身计算资源不足，解决不了第三方API对我们限流。如果模型API的额度是固定的，扩再多的Pod也只会让请求更集中地打到同一个限流墙上，最后引发重试风暴，把自己打崩。

所以我的弹性方案里必须包含两样东西：全局速率限制和退避重试。全局速率限制保证整个系统的请求总量不超过第三方API的配额，不会因为扩容而超额；退避重试让失败的请求在指数退避之后重试，而不是无脑立刻重来。这里有一个细节：重试逻辑放在统一的网关层，别让每个业务节点自己乱试。否则一旦限流触发，几百个实例同时退避重试，依然会形成尖刺。

降级也是一个弹性策略。当模型接口不可用或超时时，Harness可以返回本地模板、缓存答案或明确的错误提示，不要让用户在那里无限转圈。在Agent场景里，“快速失败”有时不是最优解，给出一个降级的可用结果，体验比让用户干等30秒好得多。

4. 实战案例：某代码辅助Agent的扩容改造

4.1 现状复盘：从一天的电量画像开始

这里分享一个我做过的具体项目，我们内部叫它“代码辅助Agent”。用户提问后，Agent会检索代码库、生成代码建议、跑单元测试并反馈结果。上线初期日活不到3000人，但每天早上10点到11点的峰值非常明显，那段时间频繁出现超时、卡死，用户开始骂。

接到改造任务后，我第一步不是写代码，而是复盘容量画像。先看监控数据：一次典型用户提问，内部平均触发4次模型调用和2次工具调用，平均任务时长6.2秒，p99是15秒。目标支撑峰值为每秒30个新任务。

用并发公式算：30 × 6.2 ≈ 186个并发任务，加20%缓冲，规划值250个并发任务。但当时生产环境的推理slot只有80个，工具执行线程池只有40个，等于峰值一来直接差三倍。这就是为什么高峰期必崩。

这个复盘过程看着简单，但很能说明容量模型的用处：不是靠经验猜“够不够”，而是拿业务指标换算成可量化的资源缺口。

4.2 三个立竿见影的改动

第一个改动是开启动态批处理。之前推理服务还是一次只处理一个推理请求，显存利用率低。开启动态批处理和KV缓存复用之后，同一个slot一次能吞吐的推理请求数明显上升，整体吞吐大概提升了1.8倍，p95延迟从6.5秒降到了3.8秒。

第二个改动是加缓存。给Agent的Prompt前缀（系统提示词、工具定义）做语义缓存，同时缓存工具返回的结果。上线后缓存命中率从35%提高到70%，模型API的token消耗下降了约40%。这个改动对成本的帮助也很大，后面账单曲线肉眼可见地平滑了。

第三个改动是伸缩策略升级。从原来单纯按CPU扩缩容，改为按任务队列长度和请求速率双指标触发。高峰期请求涌来时，自动伸缩能在35到40秒左右完成一个新Pod实例的就绪，基本赶上了流量爬坡的速度。这三个改动做完之后，高峰期超时率从15%降到2%以内，告警基本不再响了。

4.3 三次踩坑记录

改造过程中踩过几个坑，值得单独列出来。

第一次是采集间隔设得太长。刚开始指标采集周期是30秒一次，自动伸缩组件至少要两三个采集周期才能确认趋势，等它做出扩容决定，尖峰已经过去了。后来把采集周期调到5到10秒，判断窗口设为3分钟，反应速度才上来。

第二次是伸缩指标选错。一开始我以为“在线用户数”最直观，后来发现在线用户数跟真正进行中的任务数常常差一个数量级，扩容既不精准也没前瞻性。后来改成“任务队列深度×平均任务时长”来估计即将需要的并发能力，伸缩动作才跟流量曲线贴合。

第三次是高峰前预热白做了。我们提前预热了一批实例，结果流量来时新实例的缓存命中率奇低。查了半天发现是路由规则不一致，新实例拿不到和旧实例相同的缓存分片。把路由改成固定哈希，让同一类任务始终打到同一批实例之后，预热才真正生效。

每次改造我都建议把这些坑写进团队的排障手册，因为几个月后大概率还会遇到相似的症状。下面这个速查表就是整理之后的成果。

5. 常见问题与排障速查表

5.1 Agent容量与伸缩问题对照表

这张表是我做Agent平台以来最常被翻出来的东西。很多问题表面上看是“资源不够”，根源往往是“指标没设计好”或“状态放错地方”。

5.2 Agent死循环与预算帽：容量规划的最后一道闸

这里单独讲一下Agent死循环这个坑。Agent的推理循环在极端情况下会陷入重复调用：模型反复决定调用同一个工具，工具结果反反复复塞回上下文，模型又接着调用。这个过程如果不在Harness层拦截，会成为容量黑洞。我遇到过最夸张的一次，一个触发错误分支的任务一小时里产生了300多次模型调用，烧掉的Token足够几千个正常任务使用。

应对方案其实不复杂：Harness必须内置预算帽。每启动一个Agent任务，就给它发一个“运行许可证”，上面写着最大推理轮数、最大Token数、最大墙钟时长、最大成本金额，任何一项超了就强制终止并返回明确的失败原因。预算帽在容量规划里还有一个意外的好处：它让我们能算出系统的理论上限。有了上限，规划才有边界，弹性扩展才有依据。

在实际项目中，我们还会把预算帽的触发达标做成监控事件，便于后续改进Agent的规划逻辑。等于用容量监控的反哺来提升Agent本身的质量，一举两得。

5.3 每周一次的容量复盘模板

最后分享一个低成本的日常维护动作：每周做一次15分钟的容量复盘。不用搞得很复杂，就固定看几个指标——本周峰值任务速率、平均任务时长、Token消耗总量、最大并发任务数、最长的任务排队时间、限流错误次数。

连续看一个月，很容易识别出趋势：任务平均时长是不是在增长？模型调用次数是不是多了？工具返回的数据是不是整体变大了？这些变化往往不是突发事件，而是渐进发生的。容量规划是个持续校准的过程，不是上线前做一次压测就完事了。每周复盘的意义，就是用很小的成本，提前发现那些靠直觉看不出来的漂移。

我个人做Agent平台最大的体会是：容量规划十个字，背后是“预算思维”。给每个任务刻上一个明确的成本上限，让所有资源消耗都可计算、可控制，弹性扩展才会真正成为运维的工具而不是救火的借口。另一个小技巧是监控别只看“QPS”和“CPU”，多看看“任务平均时长”和“单任务Token消耗”，这两个指标才是Agent容量规划里最核心的杠杆。最后想说的是，这套方法并不是一次性的，而是从需求目标出发、压测反馈回来、然后在每个版本里不断校正的循环。只要这个循环一直在转，你的Agent Harness就不会在流量高峰面前掉链子。