1. 从能跑起来到跑得稳云端智能体的基础设施分水岭过去一年我陆续帮几个团队把智能体从本地脚本搬到了云端。一开始大家的想法都很朴素不就是把 Python 进程塞进容器再挂个 API 网关吗结果上线第一周就被现实教育了——有的智能体执行到一半把宿主机内存吃满有的因为一次网络抖动导致整个任务链路卡死还有的因为沙箱逃逸风险被安全团队直接叫停。这些问题的根源都不在模型本身而在运行时基础设施。云端智能体和传统 Web 服务有一个本质区别它不是一个请求-响应就结束的短生命周期进程而是一个会思考、会调用工具、会写代码、会自我修正的长时任务执行体。这意味着它对基础设施的要求从能跑起来直接跳到了跑得稳、跑得安全、跑得可观测。关键词里的云端智能体、基础设施、运行时、沙箱、Kubernetes其实正好勾勒出了这条技术栈的五个关键切面。这篇文章适合两类人看一类是正在把智能体从 Demo 推向生产的工程师另一类是负责平台建设、需要为上层智能体团队提供底座的基础设施同学。我会从运行时隔离、沙箱设计、Kubernetes 编排、可观测性、成本控制这几个角度把云端智能体到底需要什么样的基础设施这件事拆开讲清楚。不讲空泛的架构图只讲我实际踩过的坑和验证过的方案。先说一个反直觉的结论云端智能体最大的瓶颈往往不是模型推理速度而是运行时环境的启动开销和隔离成本。一个冷启动要 3 秒的沙箱在需要频繁创建子任务的智能体场景里会直接把端到端延迟拖垮。这就是为什么这个话题值得单独拿出来聊。2. 云端智能体的运行时到底特殊在哪2.1 长时任务与状态保持带来的挑战传统无服务器函数是用完即焚执行时间通常以秒计。但一个复杂的智能体任务比如帮我调研某个技术方案并生成对比报告可能要跑几分钟甚至几十分钟中间涉及多轮模型调用、网页抓取、代码执行、文件读写。这就带来一个核心矛盾进程需要长时间存活并保持状态但基础设施又希望尽可能无状态化以便弹性伸缩。我的做法是把智能体的状态和执行分离。状态存在外部的 Redis 或对象存储里执行进程本身尽量无状态。这样即使某个执行节点挂了任务也能在另一个节点上从最近的检查点恢复。听起来简单但实现时要注意检查点的粒度不能太细否则序列化开销比计算还大也不能太粗否则恢复后重复执行的成本很高。我一般按一个工具调用周期作为检查点单位实测下来比较平衡。另一个坑是内存泄漏。智能体进程里经常加载各种 SDK、解析库、模型客户端长时间运行后内存缓慢增长。如果你的运行时没有内存上限和自动重启机制跑上几个小时就会 OOM。我现在的标准配置是给每个智能体运行时容器设置内存 limit并配合一个健康检查接口内存超过阈值就主动退出让编排层重建。2.2 工具调用的不确定性对基础设施的冲击智能体最强大的地方是能调用外部工具但这也是基础设施最头疼的地方。工具调用意味着出站网络请求、外部依赖、不可控的延迟和失败率。我见过一个案例智能体调用某个第三方 API对方限流返回 429但智能体的重试逻辑写得不好直接进入了无限重试把出口带宽打满影响了同一节点上其他所有任务。基础设施层面能做的防护有几层。第一层是出口流量治理给每个智能体运行时打上标签用网络策略限制它能访问的目标范围同时对出站请求做限速。第二层是超时与熔断在 sidecar 或网关层强制设置单次工具调用的超时时间超过就返回失败让智能体自己决策。第三层是并发隔离不同智能体的工具调用走不同的连接池避免互相影响。这里有个经验不要指望智能体框架自己处理好超时和重试。框架层能做的是逻辑重试但物理层面的资源隔离必须由基础设施保证。我通常会在 Kubernetes 里用 NetworkPolicy 限制命名空间级别的出站访问再配合 Istio 或类似的流量治理组件做细粒度控制。2.3 运行时错误的分类与快速定位热词里出现了运行时错误339和javascript运行时报错这其实反映了智能体场景下一个很现实的问题智能体生成的代码或调用的脚本运行时错误五花八门如何快速归类定位。我在平台里做了一个错误分类器把运行时错误分成几大类依赖缺失、权限不足、资源超限、逻辑异常、外部服务不可用。每一类对应不同的处理策略。比如缺少 microsoft visual c 运行时库这种错误在 Windows 容器里跑智能体生成的程序时特别常见。解决方案不是让智能体自己去装而是在基础镜像里预置好常用运行时库。再比如 JavaScript 运行时报错很多时候是因为智能体生成的代码用了 Node 版本不支持的语法这时候基础设施要能提供多版本运行时环境让智能体按需选择。3. 沙箱设计安全与性能的平衡术3.1 为什么普通容器不够用很多人第一反应是用 Docker 容器做沙箱毕竟 Kubernetes 生态默认就是容器。但容器共享宿主机内核对于执行智能体生成的任意代码这个场景来说隔离强度是不够的。一个精心构造的逃逸利用可能影响到宿主机上其他租户的容器。安全团队在评审时几乎一定会挑战这一点。我实际对比过几种方案。gVisor提供了用户态内核隔离性比普通容器强很多但系统调用开销明显对于计算密集型任务性能损失可能到 20%-50%。Kata Containers用轻量虚拟机做隔离安全性接近 VM启动开销比传统 VM 小但比普通容器还是慢。Firecracker微虚拟机启动快、内存开销小是目前比较流行的选择但需要额外的编排适配。我的建议是分层对于执行不可信代码的高风险任务用微虚拟机级别的沙箱对于只是调用模型 API 和受控工具的低风险任务用加固过的容器就够了。没必要一刀切全上微虚拟机会让成本和复杂度都失控。3.2 沙箱的生命周期管理沙箱不是创建完就完事了生命周期管理才是难点。我总结了一个沙箱的完整生命周期预热、分配、执行、回收、销毁。每个阶段都有优化空间。预热阶段可以提前创建一批空沙箱放在池子里任务来了直接分配省去冷启动时间。这个池子的大小要根据历史负载动态调整我一般用过去 5 分钟的并发峰值作为参考池子维持在峰值的 1.2 倍左右。分配阶段要记录沙箱和任务的绑定关系方便追踪。执行阶段要监控资源使用超限就告警。回收阶段要清理临时文件、重置环境。销毁阶段要确保资源真正释放不留僵尸进程。提示沙箱池的预热策略要结合业务波峰波谷。我见过团队为了省资源把池子设得很小结果高峰期大量任务排队等沙箱端到端延迟飙升。宁可多留一点余量也不要让用户等。3.3 文件系统与网络隔离的实操细节文件系统隔离有个容易被忽略的点智能体经常需要读写临时文件但如果每个沙箱都挂载独立的可写层磁盘 I/O 会成为瓶颈。我的做法是用 tmpfs 挂载临时目录把高频读写放在内存里只有需要持久化的结果才写到外部存储。这样既快又不会污染宿主机文件系统。网络隔离方面除了前面提到的出站限制还要注意DNS 解析。智能体生成的代码可能会尝试解析各种域名如果 DNS 查询不加以限制既可能泄露信息也可能被滥用做 DNS 隧道。我会在沙箱网络里配置专用的 DNS 解析器只允许解析白名单内的域名其他一律拒绝并记录日志。还有一个细节是时间同步。沙箱里的时间如果和外部不一致会导致日志时间戳混乱排查问题时非常痛苦。确保每个沙箱都挂载了统一的时钟源这个小事不注意会吃大亏。4. Kubernetes 编排云端智能体的正确姿势4.1 用 CRD 还是用 JobKubernetes 原生的工作负载类型里Job 和 CronJob 是最接近智能体任务模型的。但直接用 Job 有几个问题Job 的重试语义和智能体的重试逻辑容易冲突Job 完成后 Pod 的清理策略不够灵活难以表达智能体任务之间的依赖关系。我倾向于自定义 CRD定义一个类似AgentTask的资源包含任务描述、所需工具、资源配额、超时策略等字段。然后写一个 Operator 来 reconcile 这个资源负责创建沙箱、注入配置、监控状态、处理失败。这样智能体的调度逻辑就和 Kubernetes 的声明式模型对齐了运维也统一。当然如果你的团队规模不大用 Job 加一层封装也能凑合。但一旦任务复杂度上来CRD 的扩展性优势就体现出来了。热词里提到《深入理解 Kubernetes 源码》如果你打算走 CRD 这条路确实需要花时间理解 controller-runtime 和 informer 机制否则调试起来会很痛苦。4.2 资源配额与调度策略智能体的资源需求波动很大。一个只做文本推理的任务可能只需要 0.5 核但一个要跑代码编译的任务可能需要 4 核加 8G 内存。如果配额设置不当要么资源浪费要么任务被 OOMKill。我的策略是按任务类型分队列。轻量任务走一个队列资源配置低但并发高重量任务走另一个队列资源配置高但并发受限。用 Kubernetes 的 ResourceQuota 和 LimitRange 来约束每个队列的总量和单任务上限。调度时用 nodeSelector 或 affinity 把重量任务引导到高配节点上避免和轻量任务抢资源。还有一个实战经验给智能体 Pod 设置合理的 terminationGracePeriodSeconds。默认 30 秒对于需要保存检查点的智能体来说可能不够我一般设到 120 秒并在容器里监听 SIGTERM 信号收到后先保存状态再退出。这样滚动更新或节点驱逐时不会丢任务。4.3 部署 Nginx 作为智能体网关的注意事项热词里有kubernetes 部署 nginx这其实是很多团队会走的一步用 Nginx 作为智能体的统一入口网关。但直接套用标准的 Nginx 部署模板会踩坑。第一个坑是超时配置。Nginx 默认的 proxy_read_timeout 是 60 秒但智能体任务可能跑几分钟。如果不调整网关会提前断开连接前端看到的就是莫名其妙的失败。我一般把读超时设到 600 秒以上同时开启 streaming 模式让智能体可以边执行边返回中间结果。第二个坑是请求体大小。智能体上传文件或传递大上下文时请求体可能超过 Nginx 默认的 1MB 限制。需要调整 client_max_body_size但也不能无限放大要结合后端能承受的量来设。第三个坑是连接复用。智能体网关和后端沙箱之间的连接如果频繁重建开销很大。开启 upstream keepalive 并合理设置连接池大小能明显降低延迟。这些配置在标准模板里往往没有需要根据智能体场景专门调优。5. 可观测性看不见的智能体等于失控的智能体5.1 日志、指标、追踪三件套的智能体适配传统微服务的可观测性三件套放到智能体场景需要改造。日志方面智能体的日志量可能非常大因为模型调用、工具调用、代码执行都会产生输出。如果全量采集存储成本会爆炸。我的做法是分级采集错误日志全量保留普通执行日志采样保留调试日志只在需要时开启。指标方面除了常规的 CPU、内存、网络智能体还需要业务指标任务成功率、平均执行时长、工具调用失败率、模型 token 消耗量。这些指标要能按智能体 ID、任务类型、租户维度聚合方便定位问题。追踪方面一个智能体任务往往跨越多个服务和多次模型调用需要分布式追踪把链路串起来。我通常用 OpenTelemetry 做埋点把每次模型调用和工具调用都作为一个 span这样一眼就能看出时间花在哪里。5.2 智能体行为的审计与回放智能体的决策过程需要可审计这在企业场景里是硬需求。我见过金融行业的团队要求智能体的每一步决策都能回放以便合规审查。基础设施层面要支持完整的执行轨迹记录输入是什么、模型返回了什么、调用了哪些工具、参数是什么、结果是什么。实现上我会在每个沙箱里注入一个轻量的记录代理把关键事件写到消息队列再由后端消费入库。存储格式用结构化的 JSON方便后续查询和回放。注意要脱敏智能体处理的数据里可能包含敏感信息记录前要过滤。回放功能对调试特别有用。当用户反馈智能体做错了你可以把整个执行轨迹拉出来逐步检查是哪一步出了问题。这比看日志猜原因高效得多。5.3 告警策略别让噪音淹没真正的问题智能体系统的告警很容易失控。因为智能体本身就有不确定性任务失败是常态如果每次失败都告警运维会被淹没。我的策略是基于 SLO 告警而不是基于单次事件。比如设定任务成功率低于 95% 持续 5 分钟才告警而不是有任务失败就告警。另外要区分可恢复失败和不可恢复失败。智能体调用工具超时可能是临时的重试就好但如果是沙箱创建失败可能是集群资源不足需要人工介入。告警规则要能区分这两类把真正需要人处理的挑出来。6. 成本控制云端智能体的经济账6.1 沙箱闲置与资源浪费的治理沙箱池是成本大户。如果池子设得太大大量沙箱闲置钱白花设得太小任务排队体验差。我的做法是基于预测的动态伸缩。用历史数据训练一个简单的负载预测模型提前 10 分钟预判负载高峰提前扩容。低谷时逐步缩容但保留一个最小池子应对突发。还有一个技巧是分级沙箱。把沙箱按配置分成几档轻量任务用低配沙箱重量任务用高配沙箱。这样不会出现杀鸡用牛刀的浪费。实测下来分级之后整体资源成本能降 30% 左右。6.2 模型调用成本的间接影响虽然模型调用成本不直接属于基础设施但基础设施的设计会影响模型调用次数。比如如果沙箱启动慢智能体可能倾向于在一次会话里做更多事导致上下文变长token 消耗增加。反过来如果基础设施支持快速创建子任务智能体可以更细粒度地拆分任务每次调用上下文更短反而省钱。我做过一个对比同样的任务在冷启动 5 秒的沙箱环境里平均 token 消耗比冷启动 1 秒的环境高 15%。因为前者倾向于一次做完后者可以分步做。所以优化沙箱启动速度不只是提升体验也是实打实的成本优化。6.3 存储与网络成本的隐性开销智能体产生的中间数据、日志、执行轨迹存储成本容易被低估。我见过一个团队智能体跑了一个月对象存储账单比计算还高。原因是每次工具调用都把完整结果存下来了包括大量重复的网页内容。治理方法是分级存储热数据放高性能存储保留几天温数据放标准存储保留几周冷数据归档保留几个月。同时做去重相同内容的工具结果只存一份用引用关联。网络方面注意跨可用区的流量费用尽量让沙箱和它依赖的存储、模型服务在同一区域。7. 我在实际落地中总结的几条硬经验第一不要过早追求完美隔离。我见过团队一上来就要上微虚拟机结果开发效率极低进度拖了几个月。正确的做法是先跑通业务用容器加安全策略顶住等业务稳定了再逐步升级隔离方案。第二沙箱启动时间是核心指标。把它当成和模型延迟同等重要的指标来优化。每降低 1 秒用户体验和成本都会有可感知的改善。第三可观测性要从第一天就做。不要等出了问题才补日志和追踪那时候已经丢了很多关键信息。智能体的行为本来就难预测没有可观测性就是在盲飞。第四成本要算总账。不要只盯着计算资源存储、网络、模型调用都要纳入考量。基础设施的每个设计决策最终都会反映在账单上。第五给智能体留退路。基础设施要能优雅地处理智能体的失败而不是让失败级联放大。超时、熔断、降级、检查点恢复这些机制一个都不能少。这个领域变化很快新的运行时、新的沙箱技术、新的编排模式层出不穷。但底层逻辑是不变的在安全、性能、成本之间找到适合你业务场景的平衡点。没有银弹只有权衡。我自己的做法是保持小步快跑每个季度回顾一次基础设施的瓶颈该换的换该调的调别让技术债积累到无法收拾。 
长河君 · 2026/10/15 11:13:04 · 阅读 1.2k 云端智能体基础设施实战：运行时、沙箱与Kubernetes编排
1. 从能跑起来到跑得稳云端智能体的基础设施分水岭过去一年我陆续帮几个团队把智能体从本地脚本搬到了云端。一开始大家的想法都很朴素不就是把 Python 进程塞进容器再挂个 API 网关吗结果上线第一周就被现实教育了——有的智能体执行到一半把宿主机内存吃满有的因为一次网络抖动导致整个任务链路卡死还有的因为沙箱逃逸风险被安全团队直接叫停。这些问题的根源都不在模型本身而在运行时基础设施。云端智能体和传统 Web 服务有一个本质区别它不是一个请求-响应就结束的短生命周期进程而是一个会思考、会调用工具、会写代码、会自我修正的长时任务执行体。这意味着它对基础设施的要求从能跑起来直接跳到了跑得稳、跑得安全、跑得可观测。关键词里的云端智能体、基础设施、运行时、沙箱、Kubernetes其实正好勾勒出了这条技术栈的五个关键切面。这篇文章适合两类人看一类是正在把智能体从 Demo 推向生产的工程师另一类是负责平台建设、需要为上层智能体团队提供底座的基础设施同学。我会从运行时隔离、沙箱设计、Kubernetes 编排、可观测性、成本控制这几个角度把云端智能体到底需要什么样的基础设施这件事拆开讲清楚。不讲空泛的架构图只讲我实际踩过的坑和验证过的方案。先说一个反直觉的结论云端智能体最大的瓶颈往往不是模型推理速度而是运行时环境的启动开销和隔离成本。一个冷启动要 3 秒的沙箱在需要频繁创建子任务的智能体场景里会直接把端到端延迟拖垮。这就是为什么这个话题值得单独拿出来聊。2. 云端智能体的运行时到底特殊在哪2.1 长时任务与状态保持带来的挑战传统无服务器函数是用完即焚执行时间通常以秒计。但一个复杂的智能体任务比如帮我调研某个技术方案并生成对比报告可能要跑几分钟甚至几十分钟中间涉及多轮模型调用、网页抓取、代码执行、文件读写。这就带来一个核心矛盾进程需要长时间存活并保持状态但基础设施又希望尽可能无状态化以便弹性伸缩。我的做法是把智能体的状态和执行分离。状态存在外部的 Redis 或对象存储里执行进程本身尽量无状态。这样即使某个执行节点挂了任务也能在另一个节点上从最近的检查点恢复。听起来简单但实现时要注意检查点的粒度不能太细否则序列化开销比计算还大也不能太粗否则恢复后重复执行的成本很高。我一般按一个工具调用周期作为检查点单位实测下来比较平衡。另一个坑是内存泄漏。智能体进程里经常加载各种 SDK、解析库、模型客户端长时间运行后内存缓慢增长。如果你的运行时没有内存上限和自动重启机制跑上几个小时就会 OOM。我现在的标准配置是给每个智能体运行时容器设置内存 limit并配合一个健康检查接口内存超过阈值就主动退出让编排层重建。2.2 工具调用的不确定性对基础设施的冲击智能体最强大的地方是能调用外部工具但这也是基础设施最头疼的地方。工具调用意味着出站网络请求、外部依赖、不可控的延迟和失败率。我见过一个案例智能体调用某个第三方 API对方限流返回 429但智能体的重试逻辑写得不好直接进入了无限重试把出口带宽打满影响了同一节点上其他所有任务。基础设施层面能做的防护有几层。第一层是出口流量治理给每个智能体运行时打上标签用网络策略限制它能访问的目标范围同时对出站请求做限速。第二层是超时与熔断在 sidecar 或网关层强制设置单次工具调用的超时时间超过就返回失败让智能体自己决策。第三层是并发隔离不同智能体的工具调用走不同的连接池避免互相影响。这里有个经验不要指望智能体框架自己处理好超时和重试。框架层能做的是逻辑重试但物理层面的资源隔离必须由基础设施保证。我通常会在 Kubernetes 里用 NetworkPolicy 限制命名空间级别的出站访问再配合 Istio 或类似的流量治理组件做细粒度控制。2.3 运行时错误的分类与快速定位热词里出现了运行时错误339和javascript运行时报错这其实反映了智能体场景下一个很现实的问题智能体生成的代码或调用的脚本运行时错误五花八门如何快速归类定位。我在平台里做了一个错误分类器把运行时错误分成几大类依赖缺失、权限不足、资源超限、逻辑异常、外部服务不可用。每一类对应不同的处理策略。比如缺少 microsoft visual c 运行时库这种错误在 Windows 容器里跑智能体生成的程序时特别常见。解决方案不是让智能体自己去装而是在基础镜像里预置好常用运行时库。再比如 JavaScript 运行时报错很多时候是因为智能体生成的代码用了 Node 版本不支持的语法这时候基础设施要能提供多版本运行时环境让智能体按需选择。3. 沙箱设计安全与性能的平衡术3.1 为什么普通容器不够用很多人第一反应是用 Docker 容器做沙箱毕竟 Kubernetes 生态默认就是容器。但容器共享宿主机内核对于执行智能体生成的任意代码这个场景来说隔离强度是不够的。一个精心构造的逃逸利用可能影响到宿主机上其他租户的容器。安全团队在评审时几乎一定会挑战这一点。我实际对比过几种方案。gVisor提供了用户态内核隔离性比普通容器强很多但系统调用开销明显对于计算密集型任务性能损失可能到 20%-50%。Kata Containers用轻量虚拟机做隔离安全性接近 VM启动开销比传统 VM 小但比普通容器还是慢。Firecracker微虚拟机启动快、内存开销小是目前比较流行的选择但需要额外的编排适配。我的建议是分层对于执行不可信代码的高风险任务用微虚拟机级别的沙箱对于只是调用模型 API 和受控工具的低风险任务用加固过的容器就够了。没必要一刀切全上微虚拟机会让成本和复杂度都失控。3.2 沙箱的生命周期管理沙箱不是创建完就完事了生命周期管理才是难点。我总结了一个沙箱的完整生命周期预热、分配、执行、回收、销毁。每个阶段都有优化空间。预热阶段可以提前创建一批空沙箱放在池子里任务来了直接分配省去冷启动时间。这个池子的大小要根据历史负载动态调整我一般用过去 5 分钟的并发峰值作为参考池子维持在峰值的 1.2 倍左右。分配阶段要记录沙箱和任务的绑定关系方便追踪。执行阶段要监控资源使用超限就告警。回收阶段要清理临时文件、重置环境。销毁阶段要确保资源真正释放不留僵尸进程。提示沙箱池的预热策略要结合业务波峰波谷。我见过团队为了省资源把池子设得很小结果高峰期大量任务排队等沙箱端到端延迟飙升。宁可多留一点余量也不要让用户等。3.3 文件系统与网络隔离的实操细节文件系统隔离有个容易被忽略的点智能体经常需要读写临时文件但如果每个沙箱都挂载独立的可写层磁盘 I/O 会成为瓶颈。我的做法是用 tmpfs 挂载临时目录把高频读写放在内存里只有需要持久化的结果才写到外部存储。这样既快又不会污染宿主机文件系统。网络隔离方面除了前面提到的出站限制还要注意DNS 解析。智能体生成的代码可能会尝试解析各种域名如果 DNS 查询不加以限制既可能泄露信息也可能被滥用做 DNS 隧道。我会在沙箱网络里配置专用的 DNS 解析器只允许解析白名单内的域名其他一律拒绝并记录日志。还有一个细节是时间同步。沙箱里的时间如果和外部不一致会导致日志时间戳混乱排查问题时非常痛苦。确保每个沙箱都挂载了统一的时钟源这个小事不注意会吃大亏。4. Kubernetes 编排云端智能体的正确姿势4.1 用 CRD 还是用 JobKubernetes 原生的工作负载类型里Job 和 CronJob 是最接近智能体任务模型的。但直接用 Job 有几个问题Job 的重试语义和智能体的重试逻辑容易冲突Job 完成后 Pod 的清理策略不够灵活难以表达智能体任务之间的依赖关系。我倾向于自定义 CRD定义一个类似AgentTask的资源包含任务描述、所需工具、资源配额、超时策略等字段。然后写一个 Operator 来 reconcile 这个资源负责创建沙箱、注入配置、监控状态、处理失败。这样智能体的调度逻辑就和 Kubernetes 的声明式模型对齐了运维也统一。当然如果你的团队规模不大用 Job 加一层封装也能凑合。但一旦任务复杂度上来CRD 的扩展性优势就体现出来了。热词里提到《深入理解 Kubernetes 源码》如果你打算走 CRD 这条路确实需要花时间理解 controller-runtime 和 informer 机制否则调试起来会很痛苦。4.2 资源配额与调度策略智能体的资源需求波动很大。一个只做文本推理的任务可能只需要 0.5 核但一个要跑代码编译的任务可能需要 4 核加 8G 内存。如果配额设置不当要么资源浪费要么任务被 OOMKill。我的策略是按任务类型分队列。轻量任务走一个队列资源配置低但并发高重量任务走另一个队列资源配置高但并发受限。用 Kubernetes 的 ResourceQuota 和 LimitRange 来约束每个队列的总量和单任务上限。调度时用 nodeSelector 或 affinity 把重量任务引导到高配节点上避免和轻量任务抢资源。还有一个实战经验给智能体 Pod 设置合理的 terminationGracePeriodSeconds。默认 30 秒对于需要保存检查点的智能体来说可能不够我一般设到 120 秒并在容器里监听 SIGTERM 信号收到后先保存状态再退出。这样滚动更新或节点驱逐时不会丢任务。4.3 部署 Nginx 作为智能体网关的注意事项热词里有kubernetes 部署 nginx这其实是很多团队会走的一步用 Nginx 作为智能体的统一入口网关。但直接套用标准的 Nginx 部署模板会踩坑。第一个坑是超时配置。Nginx 默认的 proxy_read_timeout 是 60 秒但智能体任务可能跑几分钟。如果不调整网关会提前断开连接前端看到的就是莫名其妙的失败。我一般把读超时设到 600 秒以上同时开启 streaming 模式让智能体可以边执行边返回中间结果。第二个坑是请求体大小。智能体上传文件或传递大上下文时请求体可能超过 Nginx 默认的 1MB 限制。需要调整 client_max_body_size但也不能无限放大要结合后端能承受的量来设。第三个坑是连接复用。智能体网关和后端沙箱之间的连接如果频繁重建开销很大。开启 upstream keepalive 并合理设置连接池大小能明显降低延迟。这些配置在标准模板里往往没有需要根据智能体场景专门调优。5. 可观测性看不见的智能体等于失控的智能体5.1 日志、指标、追踪三件套的智能体适配传统微服务的可观测性三件套放到智能体场景需要改造。日志方面智能体的日志量可能非常大因为模型调用、工具调用、代码执行都会产生输出。如果全量采集存储成本会爆炸。我的做法是分级采集错误日志全量保留普通执行日志采样保留调试日志只在需要时开启。指标方面除了常规的 CPU、内存、网络智能体还需要业务指标任务成功率、平均执行时长、工具调用失败率、模型 token 消耗量。这些指标要能按智能体 ID、任务类型、租户维度聚合方便定位问题。追踪方面一个智能体任务往往跨越多个服务和多次模型调用需要分布式追踪把链路串起来。我通常用 OpenTelemetry 做埋点把每次模型调用和工具调用都作为一个 span这样一眼就能看出时间花在哪里。5.2 智能体行为的审计与回放智能体的决策过程需要可审计这在企业场景里是硬需求。我见过金融行业的团队要求智能体的每一步决策都能回放以便合规审查。基础设施层面要支持完整的执行轨迹记录输入是什么、模型返回了什么、调用了哪些工具、参数是什么、结果是什么。实现上我会在每个沙箱里注入一个轻量的记录代理把关键事件写到消息队列再由后端消费入库。存储格式用结构化的 JSON方便后续查询和回放。注意要脱敏智能体处理的数据里可能包含敏感信息记录前要过滤。回放功能对调试特别有用。当用户反馈智能体做错了你可以把整个执行轨迹拉出来逐步检查是哪一步出了问题。这比看日志猜原因高效得多。5.3 告警策略别让噪音淹没真正的问题智能体系统的告警很容易失控。因为智能体本身就有不确定性任务失败是常态如果每次失败都告警运维会被淹没。我的策略是基于 SLO 告警而不是基于单次事件。比如设定任务成功率低于 95% 持续 5 分钟才告警而不是有任务失败就告警。另外要区分可恢复失败和不可恢复失败。智能体调用工具超时可能是临时的重试就好但如果是沙箱创建失败可能是集群资源不足需要人工介入。告警规则要能区分这两类把真正需要人处理的挑出来。6. 成本控制云端智能体的经济账6.1 沙箱闲置与资源浪费的治理沙箱池是成本大户。如果池子设得太大大量沙箱闲置钱白花设得太小任务排队体验差。我的做法是基于预测的动态伸缩。用历史数据训练一个简单的负载预测模型提前 10 分钟预判负载高峰提前扩容。低谷时逐步缩容但保留一个最小池子应对突发。还有一个技巧是分级沙箱。把沙箱按配置分成几档轻量任务用低配沙箱重量任务用高配沙箱。这样不会出现杀鸡用牛刀的浪费。实测下来分级之后整体资源成本能降 30% 左右。6.2 模型调用成本的间接影响虽然模型调用成本不直接属于基础设施但基础设施的设计会影响模型调用次数。比如如果沙箱启动慢智能体可能倾向于在一次会话里做更多事导致上下文变长token 消耗增加。反过来如果基础设施支持快速创建子任务智能体可以更细粒度地拆分任务每次调用上下文更短反而省钱。我做过一个对比同样的任务在冷启动 5 秒的沙箱环境里平均 token 消耗比冷启动 1 秒的环境高 15%。因为前者倾向于一次做完后者可以分步做。所以优化沙箱启动速度不只是提升体验也是实打实的成本优化。6.3 存储与网络成本的隐性开销智能体产生的中间数据、日志、执行轨迹存储成本容易被低估。我见过一个团队智能体跑了一个月对象存储账单比计算还高。原因是每次工具调用都把完整结果存下来了包括大量重复的网页内容。治理方法是分级存储热数据放高性能存储保留几天温数据放标准存储保留几周冷数据归档保留几个月。同时做去重相同内容的工具结果只存一份用引用关联。网络方面注意跨可用区的流量费用尽量让沙箱和它依赖的存储、模型服务在同一区域。7. 我在实际落地中总结的几条硬经验第一不要过早追求完美隔离。我见过团队一上来就要上微虚拟机结果开发效率极低进度拖了几个月。正确的做法是先跑通业务用容器加安全策略顶住等业务稳定了再逐步升级隔离方案。第二沙箱启动时间是核心指标。把它当成和模型延迟同等重要的指标来优化。每降低 1 秒用户体验和成本都会有可感知的改善。第三可观测性要从第一天就做。不要等出了问题才补日志和追踪那时候已经丢了很多关键信息。智能体的行为本来就难预测没有可观测性就是在盲飞。第四成本要算总账。不要只盯着计算资源存储、网络、模型调用都要纳入考量。基础设施的每个设计决策最终都会反映在账单上。第五给智能体留退路。基础设施要能优雅地处理智能体的失败而不是让失败级联放大。超时、熔断、降级、检查点恢复这些机制一个都不能少。这个领域变化很快新的运行时、新的沙箱技术、新的编排模式层出不穷。但底层逻辑是不变的在安全、性能、成本之间找到适合你业务场景的平衡点。没有银弹只有权衡。我自己的做法是保持小步快跑每个季度回顾一次基础设施的瓶颈该换的换该调的调别让技术债积累到无法收拾。