250个AI智能体放进8个Pod：高密度Agent部署实战

接到一个听起来很吓人的需求：把250个AI智能体全部上线。当时团队里第一反应分成了两派，一派说“250个Agent嘛，那就是250个服务，每个独立部署”，另一派说“都塞进Kubernetes里，反正Pod是隔离单位，一个Agent一个Pod最干净”。要不是真的把250个Agent跑进8个Pod、经历过一连串preset加载失败、记忆丢失、执行循环被terminated的折腾，我可能也会觉得每个Agent单独跑最省事。这篇就聊聊这个“反直觉”的部署形态是怎么算出来的，以及在高密度多Agent部署下，真正会卡住你的不是并发量，而是配置分发、记忆体系、协作编排和异常处理这套配套工程。

内容面向两类人：一类是正在做Agent平台、准备把多个Agent从demo推到生产的人，另一类是刚开始接触Agent开发、想知道“Agent框架到底怎么落地”的学习者。如果你觉得Agent就是写个prompt、调个LLM API，那这篇文章正好能帮你把认知补齐——Agent跑起来只是开始，让它稳定地活在Pod里、跟其他250个同伴协作不打架，才是真正的分水岭。

1. 250个Agent不是“250个服务”：先算清楚部署形态这笔账

1.1 先给Agent分类：常驻型和任务型

250这个数字一听很大，但细看需求就会发现，绝大多数Agent不是7x24小时等着被调用的。以我们当时设计的场景为例，250个Agent大致分两类：

• 常驻型Agent（约60~80个）：客服助手、告警分析、定时巡检、审批助理这类，需要随时响应，延迟要低，可以说是一直在线的；
• 任务型Agent（约170~190个）：周报生成、竞品信息搜集、数据清洗、工单摘要这类，通常是某个业务事件触发后才开始工作，工作完就休眠。

这两类Agent对基础设施的要求完全不同。常驻型要的是稳定、低延迟、快速恢复；任务型要的是能快速拉起、用完释放、不长期占资源。如果一刀切用“一个Agent一个Deployment”，那常驻型的资源利用率也不高，任务型更是灾难——每个任务型Agent都常年占着一个Pod的配额，实际上99%的时间在空转。

所以部署形态的第一个原则：不要把Agent等同于微服务。微服务是持续对外提供接口的进程，而大量Agent是“事件驱动的任务执行体”，它们更像一批频繁启停的批处理任务，而不是一组常驻进程。

1.2 为什么“每人一Pod”是一种直觉下的错误模型

“一Agent一Pod”看着隔离干净，实际运行起来会撞上几堵墙：

• 资源碎片化严重。每个Pod有基础开销：sidecar容器、日志采集、探针、网络代理。哪怕业务容器只吃200MB内存，整个Pod的保底开销也可能到600MB以上。250个Pod全拉起，光保底就是上百GB内存，实际干活的内存可能只占一半。
• 编排与网络复杂度爆炸。250个Deployment意味着250套Service、250组HPA规则、250组探针配置，发布平台上的列表能刷三屏。如果Agent之间有互调，Service Mesh里的VirtualService数量会让流量拓扑变成一团乱麻，排查问题的时间指数级上升。
• 成本不成比例。云厂商Pod计费按Request算，很多Agent的实际CPU利用率不到5%，你却要为它的预留值付钱。250个低利用率Pod，账单数字很难看。

我们的经验是：先算有效工作负载，再算Pod数量。当时把任务型Agent的日均执行次数、单次执行时长、平均token消耗拉出来一看，大部分Agent一天只被触发几十次，单次耗时也就几十秒。真正需要长期占资源的，是那一批常驻Agent和任务型Agent里的“热任务”。折算下来，8个Pod的资源量完全够用，还有余量做滚动更新。

1.3 8个Pod是怎么算出来的

具体拆解一下“8”这个数字。我们的做法是先设定Pod规格，再反推数量。

Pod规格选了8C16Gi，理由是这个规格在大多数云厂商里性价比较平衡，既能容纳多个Agent的并发执行，又不会因为单Pod过大导致故障爆炸半径太大。然后按三类开销估算：

• 常驻Agent 70个，每个常驻时占用约0.5C、1.5Gi内存，共需35C、105Gi；
• 任务型Agent的峰值并发按30%计算，约50个并发执行，每个按0.8C、2Gi估算，共需40C、100Gi；
• 基础设施和缓冲：LLM调用的等待队列、日志、指标采集约需要15%余量。

总共约75C、205Gi。按照8C16Gi的Pod规格，就是9个Pod左右。再考虑到两个大Pod同时故障时的跨实例容灾能力，最终定成8个生产Pod加2个缓冲Pod，滚动发布时8个Pod同时在线，缓冲Pod负责接管。实际跑下来，CPU峰值在60%~70%，内存峰值在75%左右，这个水位既不会浪费资源，也不会在流量尖峰时手足无措。

这还没完。8个Pod到底怎么管，决定了运维负担。我们没有建250个Deployment，而是用8个Deployment，每个Deployment对应一个Agent分组，分组内通过配置中心下发Agent清单。这样发布、回滚、扩缩容都收敛到8个单元，排障时也能快速圈定范围。

2. 一个Pod塞30多个Agent：并发模型和资源配额要怎么改

2.1 Agent的主链路是IO密集，不是CPU密集

一个Agent从收到任务到返回结果，大部分时间花在哪？答案是等LLM响应。无论是调用OpenAI、Claude还是自部署模型，一次推理动辄3~10秒，而Agent本身的代码逻辑、工具调用、结果解析都是毫秒级。也就是说，Agent天然是IO密集型工作负载，跟一个高并发Web服务很像：大量请求阻塞在外部IO上，CPU只是偶尔被用到。

这一点决定了Agent完全不需要“一个进程一个实例”的传统傻隔离。就像Nginx可以单进程扛几万并发一样，一个Pod里跑几十个Agent的运行时实例，只要并发模型正确，完全不会互相干扰到不可控的程度。我们的做法是：Pod是隔离单位，进程是并发单位，Agent是逻辑单元。

2.2 进程内多Runtime实例的并发模型改造

如果你用的是Python，第一反应该是asyncio。手写一个React风格Agent框架（就是热词里经常被提到的react agent）时，核心循环是这样的：拿到用户请求，规划下一步动作，调用工具或LLM，拿到结果再决定下一步，直到满足终止条件。这个过程天然适合asyncio——等待LLM响应时，事件循环完全可以去调度另一个Agent的执行步骤。

贴一段我们当时简化后的核心调度逻辑：

import asyncio from typing import List, Dict class AgentRuntime: """单个Agent的执行内核，基于asyncio调度""" def __init__(self, agent_id: str, toolset: Dict): self.agent_id = agent_id self.toolset = toolset self.queue: asyncio.Queue = asyncio.Queue() async def run_task(self, task: dict) -> dict: """React循环：规划->执行->观察->再规划""" context = task["messages"] for step in range(MAX_STEPS): # 这里会触发LLM调用，天然await让出CPU plan = await self._ask_llm(context) if plan["type"] == "final_answer": return plan["content"] tool = self.toolset.get(plan["tool"]) if tool is None: context.append({"role": "system", "content": f"Unknown tool: {plan['tool']}"}) continue result = await tool(plan["args"]) context.append({"role": "tool", "content": str(result)}) raise AgentExecutionError(f"{self.agent_id} exceeded max steps") class PodSupervisor: """一个Pod内的Agent调度器，统一管理多个AgentRuntime""" def __init__(self, runtimes: List[AgentRuntime]): self.runtimes = runtimes async def dispatch(self, agent_id: str, task: dict) -> dict: runtime = next(r for r in self.runtimes if r.agent_id == agent_id) return await runtime.run_task(task)

关键点在于：PodSupervisor只是一个进程，里面持有几十个AgentRuntime实例，每个实例有自己的消息队列，事件循环协调它们之间的等待和唤醒。250个Agent塞进8个Pod，本质就是8个PodSupervisor进程，每个进程内并发跑着30多个Agent的任务流。

Node.js技术栈的朋友可以用worker_threads做一个类似的池子，Go则天生适合goroutine。但核心思想一致：把并发单位从“进程”降到“协程/线程”，Pod不再是单一Agent的家，而是Agent运行时池的容器。

2.3 资源配额怎么给：requests与limits要分开算

高密度部署下，资源的requests和limits设置变得至关重要。设小了，高峰期被杀；设大了，8个Pod装不下250个Agent。

我们的配置方案：

apiVersion: apps/v1 kind: Deployment metadata: name: agent-group-3 labels: agent-group: g3 spec: replicas: 3 template: spec: containers: - name: agent-runtime image: registry/agent-runtime:2.4.1 resources: requests: cpu: "4" memory: "8Gi" limits: cpu: "8" memory: "16Gi" env: - name: AGENT_GROUP value: "g3" - name: PRESET_CENTER_URL value: "http://preset-center.internal:8080" livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 15 periodSeconds: 10

这里有两个容易踩的坑：

• requests设太低会导致调度不均。Kubernetes按requests做调度，如果你把requests设成“理论最低值”，比如每个Pod只有1C，调度器会把多个Pod堆到同一个Node上，实际峰值时反而容易堆叠到资源争抢。
• limits不能等于requests，更不能设成“无限”。LLM调用等待时几乎不吃CPU，但一旦工具批量调起来、本地缓存重建，CPU会瞬时冲高。limits留有余量，既能borrow节点资源，又能保护邻居Pod不被无限挤压。同时给整个命名空间配一条LimitRange，防止其他人创建的Pod把资源吃光。

2.4 连接池、超时和重试：高并发下真正的性能瓶颈

250个Agent共用一个Pod出口时，最先崩的往往是HTTP连接池和LLM API的网关连接数。

Python的requests库默认行为是每次请求新建连接，这在50个并发时就能让TLS握手占满CPU。我们统一换成了aiohttp或httpx，并显式设置连接池参数：

import httpx # 连接池复用，避免每个Agent每次调用都重新TLS握手 limits = httpx.Limits(max_connections=200, max_keepalive_connections=100) client = httpx.AsyncClient(timeout=httpx.Timeout(60.0, connect=10.0), limits=limits)

超时和重试策略也有讲究。LLM服务返回429限流错误时，重试通常有效；但返回401鉴权错误或400请求格式错误时，重试只会放大问题。我们给每个工具调用定义了错误分类：

• 可重试：429、503、网络连接被重置；
• 不可重试：400、401、403、404、校验失败。

区分这两类，重试请退用指数退避加抖动，最大三次，否则把错误信息原样塞回Agent的上下文，让Agent自己决定换方案。这么做既防止了重试风暴，也保留了Agent“智能”的本质——它会根据错误信息调整下一步动作，而不是机械地重试。

3. “无法加载 agent 预设”：一套preset分发机制是怎么被250个Agent击穿的

3.1 复现报错：client api: agentpresets/list failed

整个系统第一次写完后，前端配置页在测试环境还是正常的。等250个Agent的YAML一apply，前端的控制台先红了——“无法加载 agent 预设。client api: agentpresets/list failed: failed to fetch”。

这个报错的直译是：前端调用后端/api/agentpresets/list这个接口去拉取预设列表，请求直接失败。后端日志里是另一副景象：接口平均响应时间从80ms飙到12秒，数据库连接池被占满，大量查询超时。

为什么会瞬时打满？因为前端打开配置页时只发起一次list请求没问题，问题出在250个Agent启动后各自向后端preset服务发起了配置拉取。Agent启动的时机高度集中——Deployment滚动更新时，一批Pod同时重启，Tomcat/Jetty服务端连接被压垮。说白了，不是preset接口有多复杂，是250个客户端同时打一个接口，造成了经典的惊群效应。

3.2 为什么250套preset不能直接塞进ConfigMap

很多人听说配置下发，第一反应是Kubernetes ConfigMap。没错，Pod里挂ConfigMap是最常见的配法，但250个Agent、每个Agent一套preset，这个场景下ConfigMap有两个硬伤：

• ConfigMap是“死”配置。它适合存放启动引导配置、环境变量、静态参数，不适合存放需要频繁增删改的动态预设。Agent的preset是经常要调整的：改一个工具描述、调一段system prompt、更新一次few-shot示例，在ConfigMap体系里就得全量更新并触发Pod滚动重启。
• ConfigMap不适合做中心化订阅。250个Agent如果都靠挂载同一份ConfigMap，那这份配置就是全局同步的，压根做不到“不同Agent组用不同preset版本”。如果要精细化管理，要么生成250份ConfigMap，要么在代码里做复杂映射，维护成本极高。

3.3 改成“preset中心+订阅推送”的方案

我们从一次典型的故障里学到的教训是：配置要区分“开机必需”和“运行中可刷新”两种。

• 开机必需的最小配置（Agent ID、分组、连接地址、密钥索引）依然走环境变量和ConfigMap，保证Pod能跑起来；
• 运行时用的完整preset（系统提示词、工具列表、温度参数、记忆策略）放在独立的preset中心服务里，用数据库存储，加一层Redis缓存，再通过长轮询或者SSE推送给运行中的Agent Runtime。

preset中心对外的接口设计成“按组拉取”，而不是“全量拉取”：

GET /api/agentpresets/list?group=g3&version=142

Agent启动时先拉一次全量，然后每隔30秒拉一次增量，询问“版本号142之后有没有新版本”。有变更就返回新的preset内容，没有就挂住等下一轮。这一个改动让接口压力从250次/轮降到8次/轮（按Pod维度）。前端配置页访问独立的只读副本，不直接打后端的preset服务，彻底隔离了“人看配置”和“机器拉配置”的流量。

版本号机制也很关键。每次preset更新必须带一个单调递增的版本号，Agent本地缓存住版本号，等真正执行任务时才从本地缓存读取。这样即使preset中心短暂不可用，已经在运行的Agent也不会因此中断——这是“配置降级”的典型做法。

4. 记忆体系怎么在8个Pod里撑起250个Agent：短期/长期/永久记忆的分工

4.1 记忆分三级：别让Redis扛所有事

Agent没有记忆就是无状态函数，有了记忆才有“人设”和“连续性”。250个Agent的记忆体系，不能一股脑塞进Redis。我们按生命周期拆成三层：

这个分层的核心动机不是“技术炫技”，而是控制检索成本。如果每次对话启动都把用户的全部历史往LLM上下文里塞，token账单会直接爆炸；反过来，如果只靠Redis存几小时的数据，用户昨天交代过的偏好就丢了，Agent会像个失忆症患者一样反复问同样的问题。

4.2 记忆key的设计：防止热key和命名空间污染

250个Agent共享同一个Redis集群时，key设计决定了会不会出现热点。

我们早期的错误是把所有Agent的会话记忆放在同一个key前缀下，比如memory:conversation:{user_id}。这个方案在几十个Agent时没问题，到250个Agent时，一个高频用户的对话就能在某个分片上打出热点请求。后面改成带Namespce的层级：

memory:{agent_group}:{agent_id}:conv:{session_id} memory:{agent_group}:{agent_id}:pref:{user_id} memory:{agent_group}:{agent_id}:fact:{entity_id}

前两层把数据自然散列到不同的Redis分片，同时逻辑上也清晰：不同Agent组之间老死不相往来，同一组内Agent可以共享一些群体记忆（比如共同的业务规则）。又在Redis cluster模式下设置了prefer local reads，确保同一Pod内的Agent尽量读本节点缓存，跨节点访问只发生在cache miss时。

4.3 上下文裁剪与记忆写入丢失

250个Agent同时执行时，上下文管理是重灾区。每一次工具调用结果都在涨context，LLM有上下文窗口限制，超过就报错。我们的策略是三层递进：

1. 按token预算裁剪：给每个Agent设定上下文预算，例如8K token。超出后，把最老的非关键信息压缩成摘要，摘要本身由一个小模型或规则生成；
2. 按工具结果长度裁剪：工具返回结果动辄几百KB时，强制截断到2K字符，并在上下文里标注“结果过长已截断，请基于摘要回答”；
3. 按会话轮次滚动：超过20轮的会话，自动将前半部分的结论性内容聚合成“会话快照”，后续推理只基于快照。

记忆写入丢失这个问题，压在最后说，是因为它最隐蔽。Agent执行中会不断更新短期记忆，但如果Pod被OOM Kill或者滚动更新杀掉，内存里的记忆缓冲就丢了。我们早期出现过“用户上一秒告诉Agent的信息，Pod一重启Agent就忘了”的事故。

解决方案很朴素：记忆更新走异步落盘。Agent内存里写一份，同时异步投递到Redis Stream，由后台消费者批量写入持久化存储。允许极端情况丢几秒数据，但绝不能丢整段会话。有了这个兜底，Pod重启后的恢复流程就变为：从持久化层恢复最近快照，再从Redis恢复最近几秒增量，拼装成完整的上下文接着跑。

5. 250个Agent协作时的编排策略：skill分发与工具调用链

5.1 skill和Agent的边界：别在部署时焊死

很多Agent项目一开始就把“Agent”和“技能”混为一谈：做一个日报Agent就往代码里写死日报逻辑。到250个Agent规模时，这种做法会让代码库里堆满重复函数，维护一次通用改动要改几十处。

我们的切分原则是：Agent负责决策和编排，skill是可复用的原子能力。比如“查询数据库”是一个skill：“生成报表”是一个skill：“调用内部审批API”也是一个skill。多个Agent可以共享同一批skill——客服Agent和工单Agent都需要“查用户信息”这个skill，但它们编排这个skill的方式完全不同。

体现在部署上：skill不随Agent打包，而是放到一个独立的工具服务里，通过内部gRPC或HTTP暴露。Agent运行时只维护一个“工具注册表”，记录当前有哪些skill可用、各自的调用地址和参数schema。这样加一个新技能时，不用重新构建250个Agent镜像，只更新工具服务即可。

5.2 supervisor-worker模型：防子Agent风暴

多Agent协作最怕的是“套娃”：主Agent调用子Agent，子Agent又调用孙Agent，一层套一层最后整个集群被海量内部请求打爆。

我们在8个Pod里的协作模型是supervisor-worker，并且做了三层硬限制：

• 协作深度上限：默认最多两层，主Agent只能调worker Agent，worker不允许再调其他worker。需要更深协作的场景，必须显式声明并单独审批配置；
• 并行子任务上限：一个主Agent同一时刻最多派发3个子任务，剩余子任务排队。这逼着Agent学会“先处理关键路径，再处理次要路径”，而不是一次开20个并发自己把自己打挂；
• 全局并发闸门：PodSupervisor维护一个全局信号量，比如每秒最多进入50个新Agent任务。超过就直接返回“当前负载已满，请稍后重试”，而不是让请求在内存里堆积到OOM。

5.3 工具调用超时与重试分级：让Agent有“痛感”

工具调用失败时，Agent最常犯的错是陷入死循环：调用失败 -> 记录错误 -> 再调用 -> 再失败……反应到线上就是max iterations exceeded或各种终止异常。

从实际效果看，与其让Agent盲目重试，不如把工具调用的失败信息结构化地返回给它：

Tool error [code=429] [retryable=true] [suggestion=...]

关键是把“建议”也塞回去。比如数据库连接失败时，建议可以是“尝试切换只读副本”；文件未找到时，建议是“尝试搜索相似文件名”。Agent读到这些结构化的错误信息后，才能做出真正“智能”的下一步决策。我们的测试里，加入结构化错误信息后，工具调用失败后的自愈成功率从31%提升到了67%。

6. “agent execution terminated due to error”的排查链路：从报错到根因

6.1 错误从哪里来：execution terminated的几种来源

agent execution terminated due to error这个报错，在LangGraph里对应的是ExecutionTerminated异常，在手写React Agent里则通常是你的循环被一个未捕获的异常打断。我们在250个Agent上线后的第一个高峰期，这个错误刷满了日志面板。

一类是真终止：Agent达到max steps上限，循环主动退出，但最后一步抛出异常时被上层捕获成了Error。这是逻辑设计的边界问题。另一类是假终止：Agent在调用工具时超时，主流程抛异常，而异常信息没有进入Agent上下文，导致LLM“不知道发生了什么”，只能终止执行。后者在我们的故障里占了绝大多数。

6.2 一次真实排查过程：从日志聚合到Pod复现

排这个错，一开始很痛苦。250个Agent分布在8个Pod，日志分散在各个Pod的stdout里，靠人肉翻kubectl logs几乎是地狱模式。后来分了四步走：

第一步，先聚合到Loki或ELK，按agent_id和ts两个维度拉出时间线。我们发现报错并不是均匀分布，而是集中在每天下午3~4点——正好是业务方批量触发任务型Agent的尖峰时段。

第二步，挑一个高频报错的Agent ID，拉到它的完整调用链：用户请求进入 -> LLM规划 -> 调用查询工具 -> 等待响应 -> 超时 -> 抛异常 -> 终止。问题出现在“等待响应”和“超时”之间：工具服务本身没有挂，只是高峰期排队严重，单次查询平均要20秒，而Agent内部给工具调用设的超时是10秒。

第三步，到测试环境复现。我们单独发一个慢查询给Agent，压测到200并发，复现率几乎是100%。这个复现过程至关重要——它把“偶发问题”变成了“确定性问题”，后续修复才有验证标准。

第四步，看根因。工具服务数据库连接池太小，排队等待连接的时间超过了Agent的超时阈值。真正的瓶颈既不是Agent代码，也不是LLM，而是中间那个数据库连接池的配置参数。

6.3 修复与防御：超时分级 + 错误回填 + 终止条件定制

修这个问题的方案分三层：

• 第一层：把工具服务的连接池从50调到200，同时给慢查询增加独立的连接池，防止“一个慢查询拖死全库”；
• 第二层：Agent侧的超时分级——连接超时3秒、接口响应超时15秒、复杂工具总超时30秒。超时后不要直接抛错，而是把“工具超时，可能是系统繁忙”写回上下文，让LLM判断是重试还是换方案；
• 第三层：终止条件定制。不要用默认的max_steps硬上限，而是设置“至少完成一轮有效工具调用”和“连续三轮没有新信息”这样的自定义终止条件。这样既防止死循环，又不会因为一步失败就终止整个任务。

改完之后，同样的压测场景下，agent execution terminated due to error的报错从每小时一千多次降到了个位数。剩余的零星报错，基本是外部接口真的挂了，属于合理失败。

6.4 易犯误区：不要把锅甩给LLM

这类问题排查中最容易犯的错，是一看到“terminated due to error”就说“模型太笨了，prompt还得调”。实际上大多数执行失败的根因都在Agent的运行时环境里：超时配置、工具服务性能、上下文裁剪策略、重试逻辑。LLM像人脑，给它错误信息它还能转；你直接把神经切断，再聪明的大脑也只能罢工。排查Agent问题时，先怀疑基础设施，再怀疑逻辑框架，最后才怀疑模型本身。

写在最后：部署250个Agent，本质是规划一套配套工程

经过这次250个Agent塞进8个Pod的实战，我最大的体会有两点。第一，Agent数量从来不是部署形态的决定因素，并发度和任务类型才是。把Agent当成微服务是传统思路的惯性，真正合理的形态是“Pod做隔离、进程做并发、Agent做逻辑”，这样才能让资源利用率回到一个健康水位。第二，Agent项目到后期拼的一定是配置分发、记忆管理、工具链治理和异常处理这套“保姆工程”。模型能力大家拉不开差距，谁能把这250个Agent养得又稳又省，谁才有资格谈规模化落地。

最后分享一个小技巧：监控Agent集群时，不要只盯着CPU和内存。多看看agent_inflight_rps、agent_error_rate_by_phase这类业务指标——前者代表“同时有多少Agent在等LLM响应”，后者能告诉你错误发生在“规划”“工具调用”还是“记忆读写”哪个阶段。这两个指标，在250个Agent的规模下，比任何基础设施指标都更能提前暴露问题。