“全世界的算力不够给每个 Agent 发一个容器”。第一次看到这句话时我以为是一次夸张的行业吐槽。直到自己做了一段时间 AI Agent 开发被并发、状态、资源隔离反复折磨之后才意识到这句话背后是一笔很现实的算力账Agent 的工作模式跟传统服务的常驻模型本质上是两种完全不同的游戏。这篇文章想把这个话题拆开聊聊 Agent 为什么和“一个容器一个实例”这种思路拧着来以及在实际工程里我们到底该怎么给 Agent 安排“住处”。这句话不止是 Cloudflare 的立场表达更是对整个 Agent 基础设施方向的一次提醒。适合正在做大模型应用、Agent 框架选型或者卡在“Agent 并发扛不住”这类问题上的开发者参考。不需要太多前置知识能跑过 Docker、写过一点服务端代码就能跟上节奏。1. 为什么“一个 Agent 一个容器”看起来很对实际上跑不动1.1 Agent 的真实运行模型和容器设计思路是拧着的容器是为“常驻服务”设计的。一个 Web 服务启动之后长期监听端口持续处理请求资源占用稳定生命周期以天甚至月为单位。Docker、Kubernetes 这一整套路子都是围绕这种模型打磨出来的探针检查存活、滚动更新、自动扩缩容每个机制都假设服务会在那里待很久。Agent 完全不是这样。一个 Agent 实例的典型生命周期是收到一个任务、调用几次大模型、执行几个工具函数、返回结果、结束。整个过程可能持续几秒到几分钟绝大多数时间在等待 LLM API 的响应和外部工具的返回。这种负载模型下给每个 Agent 分配一个完整容器就等于为一次几分钟的“跑腿”专门安排一辆房车——房车大部分时间停在路边发动机怠速但油耗照算。有人会反驳Agent 需要记忆、需要持久化状态、需要隔离环境这不正好是容器的优势吗但仔细想想容器解决的是“进程隔离和依赖打包”而 Agent 需要的其实是“执行上下文隔离 状态外部化”。两者有重叠但不完全是一回事。1.2 用数量级算一笔账你就知道“全世界算力不够”不是玩笑做个粗略估算。假设全球有 100 万个活跃 Agent 任务同时存在这个量级对于企业级应用来说并不夸张一个大型平台的活动任务就可能瞬间拉起几十万个 Agent。再假设每个 Agent 分配一个轻型容器操作系统进程加运行时基础占用按 128MB 内存算光这些容器的静态内存占用就是 128TB。对比一下 OpenStack、Kubernetes 这类基础设施的实际部署规模一台物理机 512GB 内存通常要同时承载几十个微服务实例。如果换成“每个任务一个容器”的模式整个数据中心的资源利用率会急剧下降。更重要的是Agent 任务不像微服务那样长期存在它是潮汐式的一波任务来了几秒钟内涌入几十万个实例任务结束又全部消失。这种爆发式、碎片化的资源需求和容器基础设施“稳定分配、长期持有”的资源模型天然冲突。所以 Cloudflare 说“全世界算力不够”并不是说物理算力真的不够而是说如果继续采用“一个 Agent 一个容器”这种资源分配方式再多的算力都会被空转和碎片化的资源占用吃掉。真正的问题不是算力总量而是分配模型。1.3 推理才是真正的算力大头容器是个配角还有一个容易忽略的视角一个 Agent 跑起来之后真正的算力消耗大头是 LLM 推理而不是容器运行时。一次 GPT-4 级别的推理调用可能要消耗数百亿次浮点运算而 Agent 本身的代码逻辑判断下一步、解析结果、调用工具消耗的算力相对微不足道。这就像你请一个顾问团队真正贵的是他们的咨询费而不是他们写字楼的空调费。容器解决的是“写字楼”问题而 Agent 的成本核心在“咨询费”。如果因为写字楼太贵就限制顾问数量那就本末倒置了。在 Agent 场景里容器的角色应该是“临时办公桌”用完就清理而不是长期租用的独立办公室。2. 这个问题的本质Agent 是“短命执行”和“长寿状态”的结合体2.1 Agent 运行时的三个真实诉求要设计合理的 Agent 基础设施得先把 Agent 运行时真正需要什么列清楚。我总结了三个核心诉求任何方案都得满足这三条否则做出来的东西要么跑不动要么状态不可控。状态外置。Agent 的对话历史、任务进度、记忆文件这些数据必须放在进程之外。本地文件、内存变量这类方案在单机原型里没问题一旦 Agent 扩容或者容器被杀状态就全丢了。正确做法是把状态放到 Redis、数据库或者对象存储里让“进程”只负责执行逻辑不负责保存记忆。工具调用网络出口。Agent 要调 API、查数据库、操作内部系统这意味着它需要一个受控的网络访问通道。容器模型下这个好解决但 Serverless 或者轻量沙箱环境下网络策略往往更复杂。很多时候问题不是 Agent 跑不起来而是它的外部依赖够不着。并发执行的能力。同一个 Agent 定义可能被多个用户同时触发同一个复杂任务也可能拆分成多个子 Agent 并行处理。这意味着 Agent 基础设施必须支持同一份逻辑的多个实例同时运行并且实例之间尽量互不干扰。2.2 常驻容器、Serverless、任务队列三种模式的对比根据上面三个诉求我把目前实际项目中常见的 Agent 运行模式整理成了一张对照表。看完这张表你就能理解为什么“全世界算力不够给每个 Agent 发一个容器”这句话有道理了。模式运行方式优点缺点适用场景常驻容器模式每个 Agent 一个容器长期运行状态管理简单调试方便依赖隔离好资源利用率低成本高启动和销毁慢企业内部少量关键 AgentSLA 要求高的场景Serverless 事件驱动模式Agent 逻辑做成无状态函数事件触发运行资源按需分配并发能力强费用可控冷启动延迟状态需要设计外置方案面向大量用户的服务端 Agent任务碎片化任务队列 动态沙箱模式Agent 从消息队列拉任务在轻量沙箱里执行适合批处理和长任务可控性强需额外维护队列和沙箱基础设施体系复杂爬虫类任务、定时批量处理、数据加工流程实际项目里这三种模式往往是混合用很少只选一种。例如对外服务的 Agent 用 Serverless内部跑的数据处理 Agent 用任务队列加容器。2.3 让 Agent 变“无状态”是扛住并发的前提我在和很多人聊 Agent 并发问题时发现大家的第一反应是“换更好的 GPU”或者“上更强的机器”。但绝大部分 Agent 系统的并发瓶颈根本不在算力而在状态同步。一个会话级 Agent 如果状态存在本地两个请求落在不同实例上上下文就接不上。为了保住状态不得不把请求都路由到同一个实例这等于自己把并发掐死了。正确解法是反过来把状态全部外置让任何实例都可以接手任何一个会话。Agent 变成了“无状态工作者”谁有空谁干干完了状态写回数据库。实例不认人只看任务并发就自然上来了。这跟 STL 里的容器概念有点像——容器只负责帮你管理内存不关心里面装的是什么业务逻辑云基础设施里的 Agent 运行环境也是一样负责提供执行条件不负责理解任务细节。一旦 Agent 变成无状态执行器Scaling 就变得非常简单。负载高了就多拉几个沙箱负载降了自动销毁完全不需要关心“哪个 Agent 跑在哪里”。这时候你根本不需要给每个 Agent 一个容器因为你运行的根本不是一个一个“Agent”而是一套可以无限复制的“Agent 逻辑模板”。3. 具体落地给 Agent 找容身之处我的实践方案3.1 不同规模团队适合的技术路线选择根据团队规模和资源情况Agent 运行环境的选择差别挺大。我整理了几个比较有代表性的路线大家可以根据自己的情况对号入座。单人开发 / 原型验证阶段。本地 Docker 足够把 Agent 代码和依赖打包成一个镜像跑在个人电脑或一台低配云主机上。这个阶段不建议过度设计重点是把 Agent 的逻辑跑通状态管理可以用 SQLite 或者简单的本地文件。这个阶段先用好 STL 容器和 Docker 容器的“内存管理”思维——先让代码跑起来再谈资源分配。小团队 / 企业内网部署。推荐用 Docker Compose 编排 2 到 3 个服务一个 Agent 执行器一个 Redis 做状态存储一个消息队列接收任务。不用上 K8sK8s 的学习和运维成本在小规模场景下不值当。我用这个模式跑过一段时间稳定性很好出问题排查也快。中大规模平台型项目。这个时候要认真考虑 Serverless 平台或者自建基于任务的沙箱集群。核心原则是Agent 本体做成无状态函数状态放在托管数据库里任务通过事件总线分发。此时容器反而退居次要位置只在需要重度隔离的场景比如执行不可信代码才启用。3.2 容器资源隔离的参数怎么设定如果走容器路线资源限制参数是必须设的。很多工程师图省事跑 Agent 容器不加内存和 CPU 限制结果就是互相干扰。我在实践中最常用的配法是单个 Agent 容器 CPU 限制 0.5 核内存限制 512MB无 Swap。如果 Agent 处理的多是轻量工具调用这个配置完全够用如果涉及本地模型推理或者处理大文档才考虑提高到 1 核加 2GB。这里有个容易踩坑的点Java 写的 Agent 应用容器内 JVM 不会自动感知 Cgroup 限制。你不显式设置-XmxJVM 会按宿主机物理内存来算堆大小轻则容器被 OOM Killer 干掉重则把宿主机内存吃光。我用 Java 写过一个 Agent 工具类服务当时没设置 JVM 参数容器设置了 512MB实际却占用了宿主机 2GB 内存。加上-XX:MaxRAMPercentage50.0之后内存才老老实实待在容器限额以内。3.3 事件驱动模式改造的五个步骤如果你已经有一个常驻容器形式的 Agent想改造成事件驱动模式不需要推翻重来。按下面五个步骤走每个步骤都有明确的结果可以逐步验证。第一步把记忆外置。检查 Agent 代码里的所有本地状态对话历史、临时文件、内存缓存。全部迁移到 Redis 或者对象存储。这一步完成后强制杀掉 Agent 进程再重启会话还能接上就算达标。第二步工具调用改 HTTP。把 Agent 内部直接执行的函数调用改成通过 HTTP API 调用。这一步是为了让 Agent 在执行器迁移时不依赖本地资源所有外部依赖都走网络。第三步引入消息队列。任务不直接触发 Agent而是先投递到队列Agent 从队列拿任务执行。这一步做完请求方完全不需要等待 Agent 执行完毕自然解耦。第四步把执行体变薄。Agent 镜像砍到最小只保留运行时代码和基础依赖所有业务资源配置文件、提示词模板、数据文件放外部挂载或对象存储。第五步接入 Serverless 或动态沙箱。前面四步做完Agent 已经是标准无状态执行器了放哪里跑都行。接入 Serverless 平台几乎是改个入口的事很多坑在前四步就已经排掉了。3.4 如何用轻量沙箱撑住高并发含推理调用跟标题里那把算力账结合起来看高并发场景的 Agent 服务最经济的做法是让容器做“轻量代理”把真正重的推理调用转发到专门的推理集群。这样 Agent 容器保持轻量一个规格可以开几十上百个副本真正吃算力的大模型调用统一走网关。这也是我实际推荐给大多数项目的架构。在这个架构里考虑镜像安全和容器安全的时候还要注意一点Agent 里如果执行外部传入的代码例如一个爬虫工具接收用户脚本不要直接用主服务的容器跑而是单独开一个隔离沙箱限制网络和文件系统权限。安全是一个叠加话题我在第五部分会具体展开。4. 实操排坑实录容器和远端服务联调时遇到的几个经典问题4.1 Cloudflare Tunnel 偶尔报错的排查思路先说一个跟标题同源的场景很多自建 Agent 部署在本地或内网需要对外提供 Webhook 回调又不想暴露公网端口普遍的做法是借助 Tunnel 类工具做反向通道。这类通道认证做得好日常比较稳定但偶尔会报连接错误或握手失败对于线上 Agent 来说最需要快速判断的是问题出在哪一侧——是本地服务没起来还是通道链路中断。我的排查顺序通常是先看本地服务端口是否真实监听不要假设容器起来就一定在监听大模型 Agent 启动失败时端口可能根本没开再看通道进程日志重点看最后一次成功连接的时间点判断是否链路已断开最后看本机网络出口是否因为出口管控丢弃了长连接。绝大多数连接错误最终都和“长连接被闲置回收”有关调短心跳间隔就好。容易混淆的是日志里显示连接断开但本地服务其实正常别急着重启 Agent 容器先重启通道进程观察 5 分钟往往问题就解决了。这里多说一句生产环境的 Agent 回调通道一定要做成可观测的最近一次心跳时间、最近一次成功消息时间这两个指标必须暴露出来否则出问题时很难定位到底断在哪一环。4.2 容器内权限设置导致的“无法枚举”和访问拒绝在容器里跑 Agent经常遇到一种奇怪的现象容器启动正常日志也没报错但 Agent 试图访问某个目录或者列出文件时控制台返回“访问被拒绝”或“无法枚举容器中的对象”。这个问题在 Windows 容器和 Linux 容器的高安全模式里都会出现本质是权限设置没有同步到容器内部。我自己踩过的一个真实案例容器内 Agent 需要读取宿主机挂载的一个配置目录。挂在 Docker 里是-v /opt/agent-config:/agent-config宿主机上目录权限是 700属主是 root。容器内 Agent 以非 root 用户运行直接读取时被拒绝。处理方法是把宿主机目录的属主改成容器内用户的 UID或者用更细粒度的 ACL 授权而不是简单粗暴地在容器里加--privileged参数。不建议用--privileged解决权限问题这相当于关掉了所有隔离为了读一个目录牺牲容器安全的全部价值不划算。正确做法是先明确运行用户 UID再调整宿主机目录权限匹配。这个问题的排查技巧是在容器内手动执行id查看当前 UID再去宿主机对比目录属主。4.3 D2C 场景下容器资源互踩的定位方法如果你在一个宿主机上跑多个 Agent 容器最痛苦的问题是“我的 Agent 为什么突然变慢了”。排查这种问题不要直接进容器看top因为容器内看到的进程和资源往往不反映宿主机真实的资源争用情况。正确做法是在宿主机上执行docker stats看每个容器的实时 CPU 和内存占用再用pidstat之类的工具定位是哪个容器在突刺。我踩过一次典型的坑两个 Agent 容器都用默认设置跑其中一个跑定时数据同步任务每 5 分钟会有一个 30 秒的 CPU 高峰。另一个容器做实时服务一到整点就响应延迟飙升。用docker stats一眼就看出是同步任务把宿主机 CPU 打满了。加 CPU 限制后响应延迟立刻恢复正常。做 Agent 容器部署时资源限制不是可选项而是必选项。4.4 Agent 自动操作工具时的沙盒报错用 Agent 操作浏览器或者调用命令行工具时经常报“execution terminated due to error”之类的错误。一开始我以为是大模型调用问题反复调 Prompt 都没解决。后来发现是沙盒执行环境里缺少依赖——Agent 生成的代码要调用一个第三方库沙盒里没装。这种报错提示很模糊不会直接告诉你是依赖缺失。排查方法很简单把 Agent 执行的命令在本地环境手工跑一遍看是否复现错误。能复现基本就能定位到缺包、权限、网络等原因。从设计上说Agent 执行代码的沙盒应该预装好常用依赖并且记录每条命令的完整输出错误信息越完整越容易排查。很多浏览器自动化 Agent 都会在沙盒里做一轮“环境体检”比如检查 Python 版本、验证核心库是否可用再放行后续操作这套思路值得推广到所有 Agent 工具调用的场景。4.5 容器里跑偏门 Linux 系统的启动失败因为不同 Linux 发行版的服务管理机制差异容器里跑 SSH、定时任务等常挂掉。最典型的是基于精简版系统的容器跑sshd经常启动失败报错语义还很隐晦。这类镜像为了省体积把很多运行依赖和基础配置都精简掉了光一个/run/sshd目录缺失就能让 SSH 服务彻底起不来。解决办法是不要用服务管理工具去管容器内的进程直接用原生命令前台运行。比如 SSH 就在启动命令里写/usr/sbin/sshd -D定时任务就用 cron 的前台模式。这种思路对 Agent 也适用容器里的进程只关心主进程是否活着不要让 nohup 或 systemd 这类机制引入额外复杂度。跑 ROS 2 或 micro-ROS Agent 的容器同理确保通信中间件所需的内核和权限条件满足少依赖系统服务那一套。5. 把集群资源省下来以后Agent 还缺哪些能力5.1 框架选型和并发架构不能割裂搞定了 Agent 运行环境下一步就是选框架。市面上的 Agent 框架很多但很多人选型时只关注功能列表忽略了“这个框架在并发场景下的表现”。有些框架设计时就是单会话模式全局状态存在内存里写得很爽但并发一上来就各种串台。选框架的时候先去查一下它的状态管理方式再决定要不要用于生产。我目前实际使用中的选型倾向是轻量级任务用自研的几十行状态机复杂业务情况才考虑引入主流框架。这并是说框架不好而是很多场景用不上重型抽象。Cloudflare 那句话说到底是提醒我们功能重要但算力使用效率更重要。一个框架如果引入大量中间层序列化开销和内存占用都很高那它部署在容器里的成本也会跟着翻倍。选框架时把资源消耗作为一个一等指标来评估。5.2 Agent 的记忆要分层别全塞进上下文Agent 记忆设计是另一个和资源效率强相关的话题。很多人做记忆就是把对话历史全部拼进 Prompt 里Token 数量迅速膨胀推理成本随之上升。正确做法是分层长期记忆存在向量数据库里短期会话记忆存在 Redis只有当前需要的那一小部分才放进上下文。这类设计和“容器/算力”话题的内在逻辑是一致的不是所有东西都要常驻。记忆也一样不是所有历史都要放在热路径上。热数据放高频存储冷数据挪到低成本存储需要时再取。这个思路做下来Agent 的推理成本可以下降很多响应速度也能明显提升。5.3 Agent 安全一个任务一个隔离空间但不是一台容器讲容器绕不开安全。Agent 面临的安全挑战比传统 Web 服务更复杂。提示注入可能让 Agent 执行恶意命令外部数据可能携带隐藏指令模型输出可能越权调用工具。这种情况下隔离是必要的但隔离不意味着“一个 Agent 一个容器”。在任务级隔离需求明确的时候我推荐使用进程级沙箱或用户级隔离而不是整个容器。比如云函数环境自带隔离机制使用成本低且粒度更细很适合 Agent 的短时任务。只有执行不可信代码比如跑用户提供的脚本时才需要完整容器级的隔离来约束攻击面。资源分配上安全要放在最后一位做加法别一开始就用重隔离拖垮算力效率。5.4 在算力和功能之间找平衡做了这么久的 Agent 基础设施我一个核心体会是Agent 的瓶颈往往不是单机算力而是架构。用“如何省算力”的角度去审视设计很多问题都能找到更优解。状态外置、无状态执行、按需分配这三个原则比盲目堆机器有效得多。所以回到“全世界的算力不够给每个 Agent 发一个容器”这句话我觉得它不是在唱衰大规模 Agent 应用而是在提醒大家Agent 的运行方式天然适合按需分配的资源模型。把执行和状态分离用事件驱动串起来让算力真正用在推理上而不是浪费在维持大量空转的容器上这才是 Agent 基础设施该有的样子。根据我实操的经验能按这个思路做起来你手头的算力会比现在够用很多。