导读 Agent 正从 Demo 走向生产，但越来越多团队发现，模型能力不再是唯一的瓶颈——基础设施层的稳定性、弹性、安全与可治理性，正在成为决定 Agent 能否规模化落地的关键变量。

腾讯云于 2025 年推出 Agent Runtime，定位为面向 Agentic RL、Agentic Agent 及企业级 Agent 平台构建场景的统一基础设施底座，其底层基于 RustVMM 与 KVM 构建的 Cube Sandbox 安全沙箱技术也已对外开源。

7月24-25日，腾讯云出席了 DataFun 举办的「Agentic AI Summit 超级智能体系统架构峰会·深圳站」。借此机会，DataFun社区对腾讯云 Agent Runtime 团队进行了深度专访，探讨 Agent 从“能跑”到“跑得稳、跑得快、跑得安全、跑得省”背后的工程思考。我们尽量在不改变原意的情况下，对文章可读性进行整理，以下为具体采访内容：

01 

行业认知校正

K8s 能调度容器，但不能原生调度 Agent 的连续性

Q： 当前业界对 Agent 基础设施的讨论热度攀升，但认知仍较为分散。从一线实践来看，企业在 K8s 等成熟容器体系上运行 Agent 生产负载时，遇到了哪些超出传统认知的瓶颈？

A： 我觉得最大的误区是：企业不是“不能在 K8s 上跑 Agent”，而是把 Agent 当成传统 Web 服务去生产化时，很多假设会失效。

传统容器体系默认负载是相对无状态、请求驱动、生命周期短且边界清晰的服务；但 Agent 更像一个 “有状态的长期任务” 。它会持续多轮对话，调用工具，写文件，等待用户确认，断线后还要恢复，甚至一个任务跑几十分钟。这里会出现几个超出传统认知的瓶颈：

1. 生命周期错配

K8s 管的是 Pod，Serverless 管的是请求，但 Agent 真正的生命周期应该绑定在 session/task 上。用户断开连接，不代表任务应该死；用户一小时后回来，也希望 Agent 能接着干。

2. 状态不是一个 PVC 能解决的

Agent 的状态不只是文件，还包括对话事件流、工具调用历史、Memory、工作区、进程现场、浏览器登录态等。PVC 只能保磁盘，保不了内存、进程和执行上下文**。**很多团队一开始“Pod + PVC + StatefulSet”看起来能跑，后来会发现恢复、迁移、回滚、分叉都很脆弱。

3. 流式连接和执行实例绑死

SSE/WebSocket 如果直接挂在执行 Pod 上，会把用户连接、流式输出、Agent Loop 绑在一起。结果是灰度、扩缩容、故障迁移都变难。如果强做 session affinity，又会牺牲弹性。

4. 扩缩容信号失真

传统 HPA 看 CPU、QPS、连接数，但 Agent 的资源消耗很 “脉冲” ：等 LLM 时 CPU 很低，工具执行时突然打满。按请求或连接扩缩容，既不准确，也容易造成成本浪费。

5. 安全隔离要求更高

Agent 是 LLM 驱动的，行为不可完全预测。它可能执行 shell、装依赖、访问内部系统、处理敏感文件。共享内核容器在强隔离、Docker in Docker、网络策略、凭证注入、审计等方面都会遇到边界。

典型“看似可行、实则踩坑”的路径，是把本地 Agent 原封不动搬到云上：先用 Deployment 或 StatefulSet 跑起来，再挂 PVC 保存工作区，再用长连接维持会话，再做 session sticky routing。Demo 阶段没问题，但一到生产就暴露问题：

空闲也占资源，断线恢复不稳定，副本故障后上下文难迁移，扩容后老 session 仍被绑在旧实例上，安全和审计也要业务团队自己拼。

我们在一些企业场景里看到过类似路径。比如服务型 Agent 要从“一个人一个 Agent”升级到“同一个 Agent 多副本服务上千用户”，这时普通负载均衡就不够了，必须区分会话亲和和状态持久化：路由层负责把请求送到对的执行单元，状态层保证副本故障后还能恢复上下文。再比如教育类 Agent 场景，学生断线重连后老师 Agent 仍要记得“你是谁、聊到哪里”，这就要求 Session Restore 和 Memory 成为运行时能力，而不能只靠业务代码临时补。

所以我的判断是：K8s 仍然是企业接入和治理 Agent 的重要入口，但不能把它当成 Agent Runtime 的全部答案。 Agent 生产化需要在 K8s 之上补一层面向 Agent 的基础设施：Session Manager、State Store、Stream Gateway、Tool Gateway、强隔离 Sandbox、暂停恢复和按任务计费。真正的变化不是“容器过时了”，而是 Agent 这种新负载把传统容器体系没有显式建模的东西暴露出来了。

02

痛点归因

Agent 生产落地的 8 大高频致命问题

Q： Agent 从 Demo 到生产，模型的“智力”问题常被优先关注。在基础设施层面，实际导致项目受阻、延期甚至回滚的高频致命问题集中在哪些维度？

A： 在服务客户和自身实践中，我们归纳了以下 8 个维度的致命痛点：

1. 状态与会话恢复

Demo 可以靠上下文窗口撑住，但生产里一定会遇到断线、重启、超时、人工确认、跨天继续。很多项目卡在这里：用户回来后 Agent 不知道之前做了什么，工具调用现场丢了，文件改到一半无法恢复。

解决思路： Session、Memory、Workspace、事件日志、快照恢复必须成为基础能力，而不是业务代码临时拼。

2. 长任务与生命周期管理

传统服务按请求结束，Agent 按任务结束。一个 Agent 可能跑几十分钟，中间还要等人确认。很多团队用长连接“吊住”实例，成本和稳定性都失控。

3. 工具执行环境与安全隔离

Agent 不只是聊天，它会运行代码、访问网页、调用内部系统。模型下一步执行什么并不完全可预测。这里需要沙箱、网络出站控制、凭证注入、文件隔离、审计日志和高危操作确认。

4. 企业系统接入与凭证治理

Agent 真正进入企业，不是只调公开 API，而是要访问 CRM、工单、财务、知识库等。很多系统只认“人”的身份，不认 Agent。项目常卡在权限继承、凭证托管、高敏操作确认、审计责任归谁。

5. 流式输出、断线重连与路由

生产里需要把 Channel、Stream、Execution 解耦：连接可以断，任务不能死；执行实例可以换，用户看到的会话要连续。

6. 可观测性与排障

Demo 失败了可以重跑，生产失败必须解释。一次失败可能来自模型、Prompt、工具、网络、权限、文件、状态恢复任意一层。如果没有完整 trace，很容易陷入“模型又抽风了”的黑盒判断。

7. 成本与容量模型

Agent 成本不是只有 Token。还有沙箱、存储、长连接、冷启动、暂停池、日志、向量检索、工具调用和人工兜底。等待时间也在占资源，长任务无法释放，峰值并发拉不起来。

8. 交付与版本管理

Agent 生产化后不是“改个 Prompt 就上线”。需要版本、灰度、回滚、评测、配置管理、IaC、环境复现。否则一次 Prompt 或工具版本变化，就可能影响已有工作流。

03

调度与资源的错配

K8s 能看见容器，看不见 Agent 的“连续性”

Q： K8s 原生的调度策略面向无状态微服务设计，而 Agent 负载兼具状态亲和性与突发性。这种设计哲学上的错配，在生产环境中具体表现为哪些可量化的痛点？

A： K8s 和 Agent 的错配，本质上不是某个参数没调好，而是调度对象不同。K8s 原生调度面对的是服务副本，而 Agent 生产里真正要调度的是一个持续演进的 session****。

这种错配在生产里会表现为几类问题：

· 请求可以被调度，任务现场却调度不了。 Agent 的下一轮请求必须找到“知道前文、拿得到文件、保留了工具状态”的执行环境。

· 扩容能加副本，却不一定能缓解老会话压力。 新增副本可以接新任务，却很难无损接管已经跑了一半的任务。

· 缩容很危险。 缩掉一个正在等待用户确认的实例，可能就是把一个未完成任务直接剪断。

· 空闲不等于可释放。 Agent 经常处于等待状态，但状态必须保留。K8s 的语义里 Pod 主要是运行或销毁；Agent 需要的是暂停、冻结、唤醒、继续****。

· 故障恢复不是重启容器那么简单。 没有专门的状态层和恢复机制，重启只会得到一个干净的新容器，而不是原来的 Agent。

· 调度系统看不到 Agent 真正的业务压力。 平台显示一切健康，业务侧却觉得 Agent 卡住、变慢、恢复不了。

所以我会把这件事总结为：K8s 能调度容器，但不能原生调度 Agent 的连续性。 K8s 仍然可以作为底座，但它上面必须长出一层 Agent-native runtime。

04

状态持久化与恢复的困境

PVC 保住了硬盘，保不住“工作现场”

Q： Agent 执行过程中产生的会话状态、记忆存储与中间结果，对持久化和故障恢复提出了很高要求。StatefulSet 或有状态方案为什么难以满足需求？

A： 传统 StatefulSet 对数据库、MQ 这类有明确状态边界的服务很有用。但 Agent 的状态更复杂，它不是单一数据目录，而是一组同时变化的东西：会话事件、模型上下文、Memory、工作区文件、中间产物、浏览器登录态、工具进程、外部系统授权、正在等待的人类确认。

PVC 只能保住一部分文件，保不住“Agent 做到哪一步”。

在容器环境里，常见问题有几类：

第一，状态丢失并不只发生在磁盘层。 真正丢的是进程内状态、未 flush 的事件、正在执行的工具结果、浏览器现场。Pod 重启以后，文件可能还在，但 Agent 不知道该从哪一步继续。

第二，恢复时长不可控。 如果每次恢复都要重新拉镜像、挂载 PVC、加载历史 session、重新登录内部系统，用户感受到的不是“恢复”，而是“重新启动”。

第三，快照一致性很难保证。 Agent 状态跨多层。某一刻给 PVC 做快照，拿不到“会话事件 + 文件 + 工具调用 + 外部副作用”的一致性。

第四，会话亲和和故障迁移冲突。 同一个 session 如果强绑定原 Pod，原 Pod 故障时就很难迁移。

第五，缩容和升级非常棘手。 企业为了避免丢状态，往往不敢缩容、不敢频繁升级，资源长期被占住。

第六，恢复正确性很难验证。 Pod 健康不代表 Agent 逻辑健康。

一个典型踩坑路径是：先用 StatefulSet + PVC + sticky session 跑 Agent。Demo 阶段没问题，到生产后，用户断线、Pod 重启、版本升级一起出现，就会发现 PVC 只是保住了“硬盘”，没有保住“工作现场”****。

更适合 Agent 的状态体系通常要拆成几层： Session event log 记录发生过什么，Memory 存长期知识，Workspace 存文件和产物，Checkpoint/Snapshot 保存环境现场，调度层知道 session 应该恢复到哪里。

05

RL 训练场景攻关

轻量级 VM 是如何帮 MiniMax 省下算力的？

Q： 据了解，腾讯云 Agent Runtime 已为 MiniMax 的大规模强化学习训练提供沙箱底座支撑。当时选择轻量级 VM 而非容器作为隔离单元，是出于怎样的工程推演？

A： MiniMax 这类 Agent RL 场景有几个非常极端的特征：一个 training step 的 rollout 可能一次性拉起数千个环境，全局同时运行实例可以到 5 到 10 万级。这个负载和在线推理最大的不同是：它不是平稳 QPS，而是脉冲式环境采样。

当时选择轻量级 VM，主要基于三层推演：

第一，隔离边界必须强于普通容器。 轻量 VM 的好处是每个沙箱有独立内核，Agent 在里面怎么折腾，影响都被限制在 VM 边界内。

第二，状态与快照要成为调度能力的一部分。 轻量 VM 更适合做整机级快照、恢复和 fork。对 Agent RL 来说，这意味着环境不只是一个 container process，而是一个可复制、可恢复、可审计的实验单元。

第三，调度目标从“启动一个容器”变成“批量环境全部 ready”。 RL rollout 的瓶颈是最慢的那批环境会拖住整个 step，进而拖住 GPU。沙箱启动每慢 1 秒，如果每天有百万级 rollout，就会转化成百万秒级的 GPU 等待时间。这个账对模型厂商非常敏感。

量化收益上，可以分三个维度讲：

· 调度策略： 支撑万级并发和脉冲创建，分钟级批量拉起数万沙箱、毫秒级冷启动体验，避免 kube-apiserver 成为长尾瓶颈。

· 网络吞吐： 类似混元 RL 场景里，轻量 VM 方案可以在 VPC、网关、带宽隔离上做更清晰的资源边界。

· 资源隔离： 轻量 VM 让平台可以更放心做超卖、CPU burst、混部和失败隔离。一个沙箱异常，不影响同机其他训练环境。

这个结果不能简单说全是“VM 替代容器”的收益，但它说明：RL 场景真正要优化的是端到端训练效率**。**容器适合承载可控的服务进程，轻量 VM 更适合作为 Agent RL 的环境采样单元。

06

CodeBuddy 生产化实践

安全边界不退，复杂度由平台承担

Q： 腾讯云内部孵化的 CodeBuddy 同样部署在 Agent Runtime 之上。在架构设计过程中，为了极致的冷启动速度，是否在其他维度做出了让步？

A： 在架构设计时，我们首先明确了一条底线：不能为了启动快，把 Agent 退回到弱隔离容器里。 CodeBuddy 这类 Coding Agent 需要完整 Linux、DinD、iptables，还会运行模型生成的不确定代码。

所以真正的取舍是：安全边界不退，复杂度由平台承担。

具体做了几类权衡：

第一，把启动链路前移到构建和预热阶段。 用户点击创建时，不能再现场拉镜像。平台要提前做镜像转换、快照制作、热点模板预热。热路径里做的事情尽量少。

第二，调度不再只看 CPU/内存，而要看“数据在哪里”。 调度器必须变复杂，在计算资源、镜像 locality、快照 locality、存储挂载、网络策略之间做选择。启动快的本质是：把沙箱调度到“已经准备好环境”的地方。

第三，资源预占是必要的，但不能无限预占。 最终不是“全量预热”，而是冷热分层：高频模板热缓存，次热模板本地缓存，冷模板按需拉取，暂停实例沉降到低成本存储。

第四，暂停恢复选择了多路径，而不是一种方案打天下。 按场景选择：镜像冷启动、快照启动、本地暂停恢复、远端暂停恢复、磁盘模式恢复。

第五，把安全治理放到沙箱外，而不是让沙箱自己管自己。 凭证注入、出站控制、审计、限流都放到网关层。沙箱默认封闭，访问外部服务必须经过网关。既保留完整环境，又不把完整权限交给环境本身。

总结一下**：**为了冷启动，确实做了让步，但让步发生在平台复杂度和资源运营层面，而不是安全边界层面。最终达成的方式是：轻量 VM 保隔离，快照和预热保速度，冷热分层保成本，调度 locality 保稳定，网关治理保安全。

这其实也是 Agent Runtime 和传统容器平台最大的区别：传统平台追求“把应用跑起来”，Agent Runtime 追求的是“把一个完整、可信、可恢复、可快速交付的工作现场交给 Agent”。

07

安全隔离的边界

VM 是底座边界，网关和治理层才是生产安全闭环

Q： Agent 执行外部代码和调用工具链时，面临代码注入、资源耗尽、权限逃逸等安全风险。轻量级 VM 相较于容器在安全边界上的本质优势是什么？

A： 轻量级 VM 的本质优势不是“更快”，而是**安全边界从共享内核提升到了虚拟化边界****。**轻量级 VM 把不可信代码放进独立 guest kernel 里，Agent 可以在 guest 里跑 Docker、改 iptables，但不会直接触碰宿主机内核。

但轻量 VM 不是银弹，仍有几类盲区：

第一类是语义层权限风险。 如果 Agent 拿到了合法 GitHub Token，它用这个 Token 删除仓库，VM 隔离本身拦不住。应对策略： 凭证不直接进入沙箱，由网关按请求动态注入短期、最小权限凭证；高敏操作做 Human-in-the-loop 确认。

第二类是出站数据泄露。 即使 VM 隔离很好，Agent 仍可能把敏感文件通过允许访问的域名发出去。应对策略： 默认 deny all 出网，只开放声明过的域名、路径、协议；结合 DLP、速率限制和审计追踪。

**第三类是资源耗尽和滥用。**应对策略： 多层 quota（单沙箱、单用户/团队并发、出网带宽、磁盘配额），对异常行为做自动熔断。

**第四类是供应链与镜像风险。**应对策略： 镜像准入、签名校验、漏洞扫描、基础镜像白名单。

**第五类是快照与日志里的敏感数据。**应对策略： 快照加密、租户隔离、TTL、敏感字段脱敏、凭证不落盘。

所以我会这样总结：轻量 VM 解决的是执行环境的硬隔离问题，但 Agent 安全还必须叠加身份、凭证、网络、工具、审计和人类确认。VM 是底座边界，网关和治理层才是生产安全闭环。

08

可治理性

企业级 Agent 必须能管住行为、算清成本、追得回责任

Q： 企业级落地中，Agent 的权限管控、成本审计与行为约束是不可回避的治理需求。Agent Runtime 在这些方面做了哪些支持？

A： Agent Runtime 不只是提供一个沙箱环境，更重要的是把 Agent 生产化所需的治理能力下沉到运行时层。

第一是权限管控。 支持通过沙箱身份、用户身份、角色临时凭证、API Key、OIDC 等方式，把“谁在运行、代表谁运行、能访问什么”建模清楚。凭证尽量不直接进入沙箱，通过网关动态注入。

第二是出站访问控制。 沙箱默认封闭，出网请求必须经过 Zero Proxy / Gateway。按域名、路径、协议配置白名单，解决 Agent 行为不可预测的问题。

第三是行为审计和可追溯。 沉淀沙箱日志、工具调用日志、网络访问记录、资源使用指标。可以追到：哪个用户、哪个 Agent、在什么时间、访问了什么服务、产生了什么结果。

第四是成本与配额治理。 支持按实例、团队、配额组管理并发数、运行时长、CPU/内存、存储。沙箱支持按秒计费、暂停免费，避免长时间 idle 占用热资源。

第五是高风险操作约束。 和 Human-in-the-loop 机制结合：普通读取自动放行，高敏写操作、资金类操作、权限变更需要用户确认或策略审批。

这也是企业级 Agent 和个人 Demo 最大的区别：Demo 只要跑通任务，生产环境必须能管住行为、算清成本、追得回责任。

09

开源战略

Cube Sandbox 的野心不止于“给 Agent 一个家”

Q： Cube Sandbox 选择将底层虚拟化能力开源，这在同类产品中并不多见。内部对该项目的定位和期望是怎样的？

A： Cube Sandbox 脱胎于腾讯云内部的 FaaS 服务，开源之前已在腾讯内部大规模稳定服务 2 年，底层核心组件久经考验，具备直接的生产可用能力。

Agent 业务的发展非常迅速，但今天支撑 Agent 的基础设施还是传统的虚拟机/容器。行业这里的发展速度远远慢于 Agent 业务的发展，我们期望通过 Cube Sandbox 的开源加快行业 Agent 基础设施的进展****。

在 Cube Sandbox 本身的定位和发展上，我们期望它可以匹配到三种 Agent 的使用场景：

A) Agent tool use： 60ms 极速启动，超大并发，超高密度，支撑 Agent 海量的工具使用需求。

B) Agent Harness： 提供百毫秒级的事件级快照回滚能力，凭证托管和网络观测审计能力；针对助手型 Agent 闲置率高的问题，提供流量触发的自动暂停恢复；同时可直接基于用户已有的 K8s 基建部署。

C) Agent 访问的服务： 服务的使用者从人变为 Agent 后，服务本身需要变成 Agent 友好。传统服务部署在 Cube Sandbox 即可原生变成 Agent 友好的服务。

Cube Sandbox 的研发团队是腾讯云 IaaS 产品团队内部的精锐技术团队，支撑了腾讯云大量内部使用的技术底座。这次开源，我们也将所有核心技术能力和配套服务完整开源。希望大家可以看到我们对技术的追求，看到我们开源的诚意和态度，一起参与共建，一起为行业 Agent 基础设施的发展献力。

10

行业格局与未来判断

框架与基础设施的边界不会消失

Q： 当前 Agent 框架层也在持续向运行时和持久化方向延伸。底层专用基础设施的不可替代性体现在哪里？

A： 框架层会继续向运行时延伸，这个方向是合理的。框架更接近开发者，能把模型调用、工具编排、Memory、Workflow 封装得更易用。但生产环境里，Agent 的运行问题会落到计算、存储、网络、隔离、审计和计量这些基础设施对象上。

底层专用基础设施的必要性主要体现在几类能力上：

  1. 隔离边界需要落到内核和虚拟化层。 执行不可信代码时，隔离边界必须由容器、轻量 VM、网关和宿主机安全策略共同提供。

  2. 状态恢复需要覆盖执行现场。 生产恢复需要保存工作区文件、进程状态、浏览器现场、挂载卷、临时凭证状态。这个能力需要事件日志、快照、存储层和调度层配合。

  3. 调度要理解资源和数据位置。 Agent 启动速度取决于镜像、快照、可写层是否已经在目标节点准备好。生产调度必须把计算资源和数据位置一起纳入决策。

  4. 出站访问和凭证治理需要统一入口。 企业需要统一的网关来做短期凭证注入、域名白名单、访问审计、速率限制和高风险操作确认。

  5. 成本和容量要按任务生命周期计量。 企业要做预算、配额和计费，需要运行时按实例、团队、配额组和任务生命周期沉淀数据。

因此，框架层适合解决开发效率和编排表达，底层专用基础设施负责执行安全、状态恢复、弹性调度、网络治理和成本计量。两层会继续靠近，但职责边界不会消失。越接近生产，越需要把 Agent 当成带状态、带权限、会执行代码的运行对象来管理。

相关介绍：

Agent Runtime

Agent Runtime 是腾讯云面向 Agentic RL、Agentic Agent 及企业级 Agent 平台构建场景推出的一款基础设施平台产品。其核心定位是：为 Agent 从"能跑"走向"跑得稳、跑得安全、跑得省"提供统一的企业级运行底座。

在产品设计上，Agent Runtime 围绕"接入、运行、治理、智能"四个层面构建了完整的能力体系：

· 接入层：通过 SDK、API、CLI、MCP 及社区协议兼容，降低迁移和集成门槛，解决 Agent"怎么接进来"的问题。

· 运行层：通过执行引擎、安全沙箱、会话快照和持久化存储，解决 Agent"能不能稳定跑起来"的问题。

· 治理层：通过工具网关、身份凭证、策略管控和运行观测，解决 Agent"敢不敢在生产环境中用"的问题。

· 智能层：通过记忆、评估、Skill 和知识库，解决 Agent"好不好用、能不能持续进化"的问题。

其核心优势在于既能提供面向多类 Agent 的统一运行底座，又能兼顾企业级场景对安全、弹性、可观测和可治理的要求。

在底层技术上，Agent Runtime 以 Cube Sandbox 作为核心执行隔离单元。

Cube Sandbox

Cube Sandbox 是腾讯云开源的一款高性能、开箱即用的安全沙箱服务。它定位为 AI Agent 的执行环境底座，于 2026 年 4 月 21 日以 Apache 2.0 协议正式开源，是业内首个兼顾硬件级强隔离与亚百毫秒启动的开源 Agent 沙箱服务。开源不到三个月，该项目已登上 GitHub Trending 全语言总榜第 18 位，并在 Rust 语言分类热度榜中位列国内厂商出品项目第一名。