夜雨聆风Kimi 的 C 端 Agent 业务在高峰期承载了数以万计并发请求，每一次的请求都需要快速分配独立算力保证用户体验。在模型训练阶段，强化学习与数据合成，也需要海量隔离的计算资源的并行运行，且需要频繁启停。让智能体走进用户，无疑对基础设施提出了全新的要求。
为此，Kimi 与阿里云深度合作，以阿里云容器服务 Kubernetes 版 ACK 和阿里云容器计算服务 ACS 的 Agent Sandbox（ACS Agent Sandbox）为核心，构建了一套端到端的 Agent Infra 基础设施体系。
AI Agent落地需要什么样的Agent Infra？
Agent 产品并非简单的软件功能叠加，而是代表了一种全新的交互范式，即让 AI 能够理解复杂的用户意图，并自主分解任务、调用工具、执行并完成一系列多步骤工作流，从而真正替代人类完成创造性或分析性的工作。
“深度研究”和“OK Computer”，主要是通过自然语言指令，模型自主规划及反思，驱动一个虚拟的计算机沙箱环境，自动化执行复杂的任务流，包括工具调用、联网搜索，代码调测等常见任务。在高峰期，系统需要同时处理数以万计的用户请求，每个请求都可能触发一次或多次 Agent 的复杂推理和工具调用。系统需要快速为每个用户请求分配独立的计算资源，以避免任务间的相互干扰和资源争抢。
除了在面向用户的服务，Kimi 在 K2 等新一代模型训练过程中，也进行了大规模强化学习（RL）训练和 Agentic 数据合成。模型训练过程中，系统需要快速启停、并行运行海量的 Agent 实例，模拟各种复杂的用户行为和任务场景，与环境进行海量的交互，从而生成高质量、多样化的轨迹数据。同时为了满足模型训练的并行执行效率，Kimi 对于海量算力的弹性使用和稳定性也提出了更高的要求。
图｜Kimi Agent 场景示意图
挑战一：沙箱环境如何支撑 Agent 服务即时响应
沙箱环境的弹性能力与启动速度是 Kimi 面临的第一个大挑战。AI Agent 的任务具有高度的突发性和不确定性，用户请求可能在瞬间激增。传统的虚拟机或容器部署方式动辄数分钟的启动时间，对于需要即时响应的 Agent 服务而言是不可接受的。
沙箱环境的隔离性与安全性，也至关重要。由于 Agent 会执行由大模型生成的未经人工验证的代码，沙箱必须提供强隔离能力，防止其对其他租户、宿主机或其他关键系统造成影响，确保多租户场景下的安全。
挑战二：如何满足沙箱的状态连续性以及应对大规模并发带来的调度压力
对于需要长时间运行的 Agent 任务，沙箱还需要具备灵活的状态保持与恢复能力，以便在任务暂停后能够快速恢复到之前的执行点，以提升任务执行成功率。
同时，随着 Kimi 用户规模的扩大，大规模并发带来的系统稳定性问题也不容忽视。当大量用户同时使用 Agent 服务时，整个集群的调度能力、资源争抢以及控制面的压力都将面临巨大考验。
挑战三：如何以最低成本支撑海量并发
合理的成本控制也是需要考虑的现实问题。AI Agent 任务通常呈现短时高峰的特征，若为峰值需求预置大量计算资源，会造成巨大的资源浪费。因此，如何实现按需弹性进行稳定的资源调度，以最低的成本支撑海量并发，也是 Kimi 面临的一大挑战。
图｜Agent Infra架构图
综上所述，AI Agent 对 Infra 的核心诉求，包括：
大规模弹性的沙箱环境支持，这是保证 Agent 任务执行能力的基石，同时也要求沙箱具备相应的快速启停、安全隔离等特性，以应对海量并发交互的场景；
会话级状态保持与长时间运行支持，以满足多轮推理与复杂任务编排的需求；
灵活的工具调用服务和强大的知识与记忆能力，是 Agent 实现更高智能化和持续学习的关键；
完善的 Agent 开发平台和安全监控服务，可以为 Agent 产品的顺利上线提供重要保障。
兼具性能、成本与可靠性的AI Agent 运行底座
通过与阿里云深度的技术协同，Kimi 的 Agent Infra 顺利落地，并稳定高效的支撑了面向 C 端用户和算法研究员的生产服务。在这一过程中，双方解决了一系列复杂的技术挑战，涵盖弹性、成本、稳定性、状态保持和安全等多个方面。
// 一个快、准、稳的弹性沙箱调度机制
AI Agent 的在线服务流量像潮水一样起伏不定，比如工作日高峰期，可能会有成千上万用户同时发起请求，系统需要在几秒内多处理好几倍的任务。为了不让用户卡住或超时，系统必须在极短时间（秒级）启动成数千上万个新的沙箱实例，每个都独立运行、互不干扰。
类似的需求也出现在模型训练阶段：强化学习或数据合成任务常常要批量启动成百上千个 Agent 实例，需要频繁创建和销毁沙箱环境，节奏快、频次高。
面对这种“既要快、又要准、还得稳”的挑战，阿里云以 ACK 的节点池即时弹性能力和 ACS Agent Sandbox 为核心，为 Kimi 打造了一个高性能、低成本的沙箱环境解决方案。该方案通过容器节点池即时扩容、ACS Agent Sandbox 资源预调度以及智能的资源策略，实现了对 Agent 沙箱环境的精细化管理和高效调度。
图｜ACK 的节点池即时弹性能力/ACS Agent Sandbox 协同调度
ACK 节点池保障“即时弹性”快速扩容
面临突发性流量时，ACK 节点池通过多可用区、多实例规格的组合，保障了计算资源的扩容。ACK 则支持跨可用区创建节点池，并根据实时负载动态选择最优实例规格（如通用型、计算密集型或存储优化型），既避免因单一可用区资源不足导致扩容失败，又通过多规格适配不同业务需求，提升资源利用率。
为缩短节点从初始化到业务就绪的耗时，ACK 支持多种方式加速节点启动：用户可将业务镜像、依赖组件及配置预打包至自定义镜像中，节点启动时无需重复拉取镜像，初始化时间可降低 60% 以上。同时，ACK 支持数据盘快照加速，通过预置数据盘快照快速克隆，使初始化耗时从分钟级降至秒级，尤其适合 Agent 沙箱的快速启动场景。
图｜节点池即时弹性扩容
在网络层面，节点真正可用往往需要依赖节点上 ENI（弹性网卡）创建和挂载完成，产生了较长的等待时间。ACK 节点池结合 Terway 网络插件优化，通过预先分配 ENI 并绑定到待扩容节点，有效避免了无效等待，显著加速 Pod 的网络就绪与业务流量接入。
结合以上优化加速方案，ACK 节点弹性扩容对弹性全链路，实现了高扩容成功率和分钟级千节点的扩容效率。
ACS Agent Sandbox 实现沙箱环境极速秒级启动
为了进一步满足 Agent 对瞬时、海量、碎片化算力的极致要求，Kimi 还使用了 ACS Agent Sandbox 来实现 Agent 沙箱环境的极速启动。
ACS Agent Sandbox 底层采用轻量级虚拟机（MicroVM）技术，将虚拟化开销降低 90%，在实际场景中，实现了大规模并发弹性，同时满足数千沙箱秒级启动的要求，能够在业务负载突增时即时提供计算资源。这得益于以下方面的优化：
ACS Agent Sandbox 基于国内最大容量规模的阿里云弹性资源池，在算力供给层面，结合基于 AMD EPYC CPU 架构的弹性计算实例，ACS Agent Sandbox 可在数秒内并行拉起数千个沙箱，每个实例独立分配 vCPU 与内存资源，满足 Agent 任务对隔离性与瞬时爆发力的双重需求。并基于用户负载特征的沙箱资源预调度优化，通过预测预调度、资源复用等手段，节省了沙箱环境的调度、创建时间。同时优化了网络、存储端到端的方案，有效缩短单个沙箱冷启动的时间。
在镜像拉取维度，沙箱需要先拉取指定的容器镜像，但因网络质量和容器镜像大小等因素，镜像拉取耗时往往成了沙箱启动的主要耗时。为加速实例的启动速度，ACS Agent Sandbox 基于云盘快照技术提供镜像缓存功能。通过预先将需要使用的镜像制作成镜像缓存，然后基于该镜像缓存来大规模创建沙箱，避免或者减少镜像层的下载，从而进一步提升沙箱的启动速度。
另外，Agent 应用启动时往往面临组件依赖加载、应用初始化等资源密集型任务，瞬时资源需求可达稳定态的 2-3 倍。如果按峰值预留规格，会导致大量资源浪费；而 ACS Agent Sandbox 通过 Quota 热更新技术，允许沙箱在创建初期自动获取临时 burst 资源，几秒内将 CPU / 内存提升至数倍，待应用启动完成后再平滑回退至基准规格。这一机制避免了因资源不足导致的启动阻塞，实测可使Python 类沙箱应用启动时间缩短 60% 以上，同时又确保了成本可控。
ResourcePolicy 资源调度策略，构建算力分级调度
为了整体应对 AI Agent 瞬时高并发、请求高频波动的特性，Kimi 采用阿里云的 ACK ResourcePolicy 构建了常态算力与 Serverless 算力的分级调度体系。
为在成本与性能之间取得平衡，Kimi 将部分 Serverless 算力池部署在 AMD EPYC CPU 架构的弹性计算实例上，用于承载对实时性要求适中的 Agent 沙箱任务。相比传统同规格实例，AMD 通用算力在 CPU 与内存密集型 workload 上具备更高的资源性价比，使弹性溢出层的单位算力成本进一步下降。该策略通过声明式配置定义算力分配优先级规则，将预留节点作为基线容量池保障日常稳定负载，当 Pod 排队数超过阈值（如500个）或等待超时（如30s）后，自动将超额请求溢出调度至 ACS Agent Sandbox Serverless 池。该策略也可根据实时 Pod 积压数量、资源缺口比例动态切换，确保用户使用 Agent 的稳定性和一致性。这种混合模式不仅使 Kimi Agent 的综合成本降低，还将突发峰值承载能力提升了数倍，实现了容量确定性、弹性速度与成本优化的平衡。
// 一套保障 Agent「持续」待命的机制
另一方面，越来越多的 Agent 任务不再是“一问一答”的短交互，而是需要长时间思考、多步规划的连续过程。比如，一个研究型 Agent 可能在后台整理文献、调用工具、生成报告，整个过程持续几分钟甚至更久。如果在这期间系统因资源紧张把沙箱直接销毁，Agent 的所有中间成果——包括已加载的数据、推理路径、临时文件——都会丢失，用户只能从头再来。
为避免这种“断线重连”式的体验，Kimi 要求即使沙箱的计算资源被释放，其内存状态和磁盘数据也能安全保存下来。当下次用户发起请求时，系统能快速从存储中还原整个环境，实现“秒级唤醒”，让用户感 Agent 一直在待命。
这套“休眠-唤醒-克隆”机制不仅保障了任务的连续性，还带来了额外收益：同一个 Agent 状态可以被快速克隆出多个副本，用于强化学习中的多路径探索，既提升了资源利用率，也加速了算法迭代。
实例休眠及唤醒能力
ACS Agent Sandbox 提供了状态保持功能，支持沙箱环境的一键休眠和快速唤醒。使用方式上也达到了灵活便捷，支持通过原生 K8s Pod 协议、Sandbox CR 或 E2B SDK 触发沙箱休眠和唤醒。
图｜ACS休眠能力
在成本考验方面，ACS Agent Sandbox 可以支持内存状态的持久化，在休眠期间沙箱的 CPU 和内存资源释放，降低在休眠期间的资源成本。休眠期间支持按需选择保留内存数据、临时存储文件数据、IP 等，灵活应对不同业务场景的需求。
同时，支持数秒快速唤醒 Pod，Pod 的内存状态保持，完整恢复到休眠前的沙箱环境，实现在成本与体验之间的最佳平衡，降低了长周期任务的资源持有成本。
克隆能力，实现 Agent RL 分支路径探索
在休眠功能的基础上，阿里云容器服务团队同步研发了实例克隆能力，支持通过 ACS Agent Sandbox 制作内存级别的快照 Checkpoint，以及基于一个 Checkpoint 瞬时创建大量初始状态一致的实例。通过在存算分离架构下复用同一份底层快照，克隆操作无需重新加载依赖、环境或初始化内存，大规模实例可以在数秒内并行就绪。
在 Agent RL 场景，常见蒙特卡洛树搜索（MCTS）这类强化学习算法中，智能体需要在一个节点的基础上，同时模拟多条不同的未来路径以评估最佳行动。如果没有高效的克隆能力，只能为每条路径单独启动一个全新的、初始化开销巨大的沙箱，或者在单个沙箱中串行执行，效率极低。而通过克隆，可以瞬间生成数千个拥有相同状态的沙箱副本，每个副本负责一条路径的模拟，极大地加速了搜索过程。
// 一个扛住十万级 Pod 的稳定调度底座
随着使用 Kimi Agent 功能的用户持续增长，后台并发运行的Pod规模迅速攀升至数万甚至数十万级别。如此大规模的 Pod 频繁创建、调度和销毁，对 Kubernetes 集群的核心组件，尤其是调度器和 API Server 带来了巨大压力。一旦响应延迟或调度堆积，就可能拖慢整个 Agent 服务的响应速度。
因此，如何确保在如此大规模的负载下，集群依然能够稳定运行，也是 Agent 服务能否成功的关键之一。
调度器性能大幅提升
阿里云容器服务 ACK 针对大规模 AI 负载场景，对 Kubernetes 的核心组件进行了深度优化和加固。在调度器层面通过参数调整提高了队列处理深度以及单个 Pod 的处理速度，确保当触发集群自动伸缩时能够处理尽可能多的 Pending Pod。非自动伸缩场景下调度器通过对相似 Pod 的调度结果的中间缓存以及不同链路的并行处理，成倍减少相似 Pod 的调度开销，最终实现千节点规模下每秒数百 Pod 的调度效率。
ACK 调度器支持 Pod 亲和性缓存、等价类调度，同时结合调度器性能参数调优，在实际场景中，能够提升调度器性能至开源版本的数倍。
API Server 稳定性改进
ACK 管控侧针对 Agent 场景沙箱快速弹起，快速释放特点基于大规模多 AZ 高可用架构部署。基于大规模多 AZ 高可用架构管控拓扑部署，同时针对该场景对 ETCD / APIServer / KCM / VK / Scheduler / ACS 管控等组件做了全链路端到端参数优化，管控组件支持动态弹性扩容，来满足 Agent 沙箱秒级弹性，高并发 API 访问诉求。
// 一套让 Agent “记得住、找得准”的搜索与记忆机制
高质量的搜索和记忆服务，是构建复杂 Agent 的关键基础，在 Agent 任务执行前、执行中，都会高频依赖搜索从互联网海量信息中精准获取高质量信源。而 Agent 的“记忆”能力，能保证 Agent 在跨会话场景中维持连贯性，同时也能给产品带来更多个性化、智能化体验的提升。
阿里云多模数据库 Lindorm 通过存储计算分离、多引擎共享融合的云原生架构，帮助 Kimi 构建了具备高效检索和海量存储能力的记忆与搜索模块。
图｜Lindorm多引擎能力
通过该方案，Kimi 取得了如下收益：
稳定易开发：Lindorm 作为一个多模数据库，集成了宽表引擎、搜索引擎、向量引擎、AI引擎四大核心组件，数据在内部自动流转，无需自建同步链路。这些特点对比开源自建方案提供更稳定、更统一便捷的开发方式，帮助 Kimi 快速构建了 Agent 背后的AI搜索基础设施；
双路召回：Lindorm 原生支持基于 RRF 的全文-向量双路召回能力，并且支持用户设置自定义权重；
数据压缩效果提升：Lindorm 支持云盘、OSS 等多种存储，并内置深度优化的压缩算法，比开源减少 30%~50% 存储成本。
// 一套让 Agent “互不打扰”的安全隔离防护
在多租户环境下，不同用户的 AI Agent 实例共享同一套物理集群资源，安全隔离就成了不可妥协的底线：必须确保每个用户的 Agent 都运行在独立的环境中，既不能读取或干扰他人的数据，也无法越权执行系统操作。
运行时安全隔离
存储挂载隔离能力
在 Agent 持久化存储方面，文件存储（NAS）支持通过为每个 Agent 实例动态分配独立的子目录或存储卷，在共享存储池上构建逻辑隔离的存储空间，同时通过访问控制列表（ACL）或 POSIX 权限严格限制各实例对其空间的读写权限。这种"共享存储池+逻辑隔离"的架构，既发挥了 NAS 便捷共享、弹性扩展的优势，又通过细粒度权限控制实现了存储层面的强隔离，使不同 Agent 在共享物理资源的同时保持数据安全边界。
网络隔离能力 NetworkPolicy
在 Kimi 的 Agent 服务中，使用了阿里云 NetworkPolicy 限制 Agent 之间的网络通信，防止恶意 Agent 访问敏感数据或服务。NetworkPolicy 支持命名空间隔离、端口控制及流量路由。在大规模集群场景下，阿里云还提供了优化大规模 Terway 集群 NetworkPolicy 扩展性的方案，通过调整策略配置和优化网络组件，确保策略管理不会给 Kubernetes 的管控带来过大压力。
面向生产级 AI Agent兼具效率和成本的落地基础
此外，通过常态算力与 Serverless 算力的智能调度策略，Kimi Agent 的整体 TCO 成本大幅降低。使用实例休眠唤醒能力，也进一步降低了长周期 Agent 任务的资源持有成本。综合阿里云上丰富的 PaaS 及安全监控能力，这套基础设施方案不仅满足了当前复杂的 Agent 应用场景，更为未来构建更智能、更自主的 AI 系统奠定了坚实的技术基础，助力 Kimi 在 AI Agent 时代不断实现模型和产品的持续创新。
/END/
