Agent 架构演进：从「单体自管」到「分布式托管」

Agent 为什么不能直接套用传统微服务

所谓单体 Agent，是把 Agent Loop、会话状态、长期记忆、工具环境和部署单元放在一起。它之所以比普通 Web 服务更难托管，首先在于自主性：传统服务通常收到请求后执行固定逻辑，Agent 却会根据模型判断主动决定下一步。其次是行为不确定性，同一输入可能形成不同的推理与工具调用路径，传统系统常用的幂等假设不再天然成立。第三是工具环境依赖，Agent 通过工具感知和改变外部世界，安装了哪些软件、连接了哪些服务、产生了哪些临时文件，本身就是状态的一部分。

这三点意味着，Agent 并不是把大模型接口装进容器就完成了生产化。它需要同时处理不确定执行、环境隔离、状态持久化、权限控制和过程审计，因此基础设施必须针对 Agent 工作负载重新设计。

02

单体 Agent 的三种形态

第一种是本地部署。个人把 Agent 装在电脑上，再接入企业微信、飞书等入口，使用门槛低，也是个人 Agent 最常见的起点。但它与个人设备生命周期强耦合：电脑休眠或关机后服务消失；依赖、临时文件和密钥散落在本地，环境损坏后难以恢复；API Key 和企业数据缺少统一管控；企业也无法知道员工部署了多少 Agent、调用了什么工具。它适合个人提效，却不适合作为企业规模化方案。

第二种是 K8s Pod 化。典型做法是一个 Agent 对应一个 Pod，并挂载 PVC 保存状态。它把 Agent 搬到云端，解决了部分集中部署问题，却仍保留单体结构。容器共享宿主机内核，安全隔离存在边界；Agent 大部分时间等待用户或模型，Pod 长期常驻会造成资源浪费；一个 Agent 绑定一个 Pod 和一份状态，环境异常、PVC 损坏或版本升级都可能直接影响用户；当 Agent 从“一人使用”变成“多人调用的服务”，单 Pod 的并发、计量和 HPA 策略也很难准确设计。一次请求可能只是读取小文件，也可能触发长时间计算，单纯根据 CPU 或内存指标扩缩容，往往无法反映真实负载。Pod 化是进步，但它仍把 Agent 当作普通工作负载处理。

第三种是 Runtime Sandbox。专用沙箱采用 VM 级隔离，并通过毫秒级冷启动、按需拉起和秒级暂停恢复适配 Agent 的离散负载。任务执行结束后，可以释放计算资源，同时保留恢复所需的状态，避免 Pod 长期空转。

沙箱外再设置 Agent Wall，将出站流量统一接管：一方面通过网络触达边界、站点策略和敏感操作人工审核形成分层防护；另一方面为 Agent 签发短期身份，在访问目标服务时动态注入凭证，使密钥不必以明文写入 Agent 环境。

不过，沙箱解决的主要是隔离和成本，单体 Agent 的运维、高可用和横向扩展问题仍然存在。一个有状态沙箱依旧是单点：升级可能中断服务，故障后状态难以迁移，高并发也无法靠增加无状态副本直接解决。因此，架构必须继续走向分布式。

03

分布式 Agent 的核心：先拆状态，再谈托管

从单体走向分布式，关键不是简单增加副本，而是把状态从 Agent Loop 中剥离。分享将状态分为三类：Session 是用户、模型、Agent 与工具之间的事件序列；Memory 是从会话中抽取、可跨 Session 复用的长期记忆；Environment Sandbox 是工具真正执行的环境。三类状态独立后，中间只留下无状态的 Agent Loop，它可以像普通服务一样被调度、扩缩容、灰度和迁移。

Session 上云后，不再只是本地聊天文件。平台可以提供事件顺序存储、高可用备份、TTL、回滚和分叉。

更重要的是，远端事件流会成为平台级数据资产：后台任务可从中抽取公共记忆；工具调用可同步进入审计系统；特定事件还可以触发安全、运维或业务流程。这里需要区分 Session 和 Memory：Session 保存完整交互事实，Memory 则是在其基础上沉淀的长期信息。前者强调可追溯，后者强调跨会话复用，两者不应混为一层。

执行环境同样必须独立。工具在哪里执行，Agent 的“手脚”就在哪里。环境沙箱需要支持暂停恢复、全盘快照与回滚，还要能按 Session 或 User 绑定。前者适合一次性任务，后者适合长期个人助手，使同一用户跨会话仍能回到连续的工作环境。

当状态全部远程化后，Agent Loop 可以部署为 K8s 无状态服务，水平扩展、故障切换和无损升级都更容易。但这还不是终点。同一 Session 不能被多个 Loop 同时接管，否则可能重复执行或产生顺序冲突，因此平台需要 Session 级抢占锁；用户仍要管理 Deployment、HPA、Ingress、监控告警；许多开源框架也默认本地状态，需要适配远程 Session 和工具环境。

04

从函数式托管到全托管 ReAct

为了继续降低使用门槛，Agent Engine 把更多基础设施责任收回平台。其核心架构由请求路由与编排、无状态 Agent Loop 实例池、集中记忆层、远程环境沙箱和 Agent Wall 组成。用户部署 Agent 并发起请求后，平台完成会话路由和策略路由，将请求分配到 Loop 实例；Loop 读取 Session 与 Memory，再通过 gRPC 或 HTTP 调用远程沙箱执行工具；沙箱出口经过 Agent Wall 进入外部服务，最后由平台汇总流式或最终结果返回用户。状态、计算、执行环境和安全出口因此形成明确边界。

在函数式托管阶段，开发者只需要提交 loop 主函数，平台接管 Session 生命周期、环境沙箱调度、按请求弹性与冷启动、日志追踪和版本灰度，以及部署编排。开发模型由“维护一个完整应用”变成“只写业务函数”。

再往上是全托管 ReAct。对于大量遵循“思考—行动—观察”循环的通用场景，开发者无需再手写 Loop，只需声明 System Prompt、Skills 和 MCP。平台内置循环控制、工具编排、上下文处理、错误重试与运行监控，Agent 由应用进一步变成配置。

分享将托管度概括为四阶：单体式 Harness 把 Loop、工具、工作区和状态全部交给用户；分布式 Harness 把状态与基础设施能力拆出，但用户仍维护服务；函数式 Harness 只交付 Brain Function 或 Handler；托管式 Harness 则由用户定义模型、指令、工具、记忆策略和权限，平台接管完整运行时。越往上，标准化程度越高，用户运维负担越低。

05

多 Agent 协作：Registry 与 A2A 只是起点

单个 Agent 完成分布式化后，企业内部还会出现新的问题：一个 Agent 如何找到另一个具备所需能力的 Agent，如何把任务交给它，以及多个 Agent 如何共享上下文。前两项分别对应服务发现和 A2A 调用，第三项仍处于探索阶段。分享提到，现实中常借助 Git Issue 等人类协作平台传递上下文，但尚未形成成熟的通用基础设施。

Agent Registry 为发现和调用提供物理落点。Agent、MCP 和 HTTP 服务可以统一注册，调用方按能力检索目标，并将 Agent 抽象为可调用工具，通过统一协议完成 A2A。需要强调的是，Registry 目前主要解决注册、发现、调用和协议统一；跨 Agent 上下文共享仍是一块明确的基础设施空白。

06

从单点能力到完整 Runtime

腾讯云 Agent Runtime 是一套覆盖部署、治理、评测、记忆、身份、网关和协作的运行时体系。上层面向助手型、领域型和任务型 Agent；中间由 Agent Engine、Agent Govern 和 Agent Evals 承担部署托管、治理运维与评测；底层通过 Agent Memory、Agent Registry、Agent Wall、Agent Sandbox、Agent Identity、Agent Gateway 以及全链路观测，构成状态、安全、执行和连接能力。沙箱内部又进一步覆盖隔离执行环境、生命周期管理、多种环境形态和弹性效率，说明 Runtime 要解决的并不是单一运行问题，而是完整的生产治理问题。

结语

这条演进路径可以归纳为三层规范。第一是路径规范：从单体自管走向分布式托管，是 Agent 规模化的必经之路。第二是物理层规范：存算分离加沙箱化，把状态、执行和安全拆成可独立治理的基础设施。第三是协作层规范：Registry 与 A2A 为多 Agent 发现和调用提供共同底座，而上下文共享仍等待下一步突破。

工作流决定 Agent 如何完成一个任务，Runtime 决定成千上万个 Agent 能否长期、安全、低成本地运行。只有当状态能够迁移、环境能够隔离、权限能够审计、实例能够弹性伸缩，Agent 才真正从 Demo 进入生产。

分享嘉宾

INTRODUCTION

陈凯烨

腾讯云 Agent Runtime

高级产品经理

长期专注于 Agent 沙箱、Agent 构建与治理，致力于探索智能体运行时在管控方面，与工程化方面的最佳实践。

点个在看你最好看

SPRING HAS ARRIVED