免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

让 AI Agent 安全“跑”在云端:基于函数计算打造 Agent 代码沙箱

发布日期:2026-01-27 19:55:26 浏览次数: 1520
作者:阿里云云原生

微信搜一搜,关注“阿里云云原生”

推荐语

阿里云函数计算FC为AI Agent打造安全高效的代码沙箱,解决资源隔离与执行效率的平衡难题。

核心内容:
1. AI Agent代码执行面临的安全隔离与资源管理挑战
2. 函数计算FC的四大核心优势:安全隔离、弹性伸缩、按量付费和简化运维
3. 构建高密度、低成本、安全可靠的Agent运行时的具体实现方案

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

图片

引言:安全沙箱与 Serverless 的技术交汇




Cloud Native

随着大语言模型(LLM)从“对话框”走向“行动体(Agent)”,其能力边界正在迅速扩张。现代 AI Agent 不再是文字的搬运工,而是能够自主思考、调用工具、甚至编写并运行代码以解决复杂问题的智能助手。然而开发者始终面临一个根本性挑战:如何在保证执行效率的同时,实现资源强隔离与资源可控性?

阿里云函数计算 FC 为这一难题提供了全新的解题思路。其底层基于轻量级安全沙箱,天然具备进程级隔离、资源极致伸缩、按需付费等特性。这种架构与 Agent 对代码执行环境的需求高度契合,使得构建高密度、低成本、安全可靠的 Agent 运行时成为可能。

为什么需要 Agent 代码沙箱?




Cloud Native

Agent 的核心价值在于其“自主执行”能力,而代码执行是实现这一能力的关键路径。在工具调用、动态数据分析、自动化任务处理等典型场景中,Agent 生成的代码往往来自不可信的推理过程,若缺乏有效的沙箱保护,开发者将面临多重风险,为此 AI 开发者对运行时有着如下多个核心诉求:

  • 安全与隔离特性:必须确保不同用户的 Agent 代码在文件系统、网络访问上完全隔离,严防恶意指令注入导致的越权操作。
  • 资源管理控制:代码缺陷或恶意行为可能导致 CPU/内存耗尽。系统需要能够对单个执行任务进行精细化的资源配额限制。
  • 生命周期管理:Agent 任务存在短时型突发、长周期会话等多种任务模型,需提供灵活生命周期管理能力。
  • 按资源消耗计费:若简单按实例运行时长计费,在长周期交互场景下,用户将为大量的“等待时间”支付不必要的费用。需在用户成本控制与平台资源利用率之间寻找平衡点。

由此可见,构建一个强隔离、可管控、即开即用且按需回收的代码执行环境——Agent 代码沙箱,已成为 AI 应用架构中的刚需。


为什么是Serverless?

函数计算的核心优势

Cloud Native

在众多技术路线中,Serverless 函数计算凭借其天然的“沙箱基因”,成为了构建 Agent 运行时的理想底座:

1. 底层安全隔离:主流云厂商的函数计算服务普遍采用 MicroVM 或强化容器技术作为执行单元。每个函数实例运行在一个轻量级、启动迅速的 MicroVM 中,具备完整的内核隔离。这种架构从进程、内存、文件系统等多维度实现安全保障。
2. 极致的弹性伸缩:Agent 的请求模式具有高度不确定性。函数计算的毫秒级扩缩容能力,让开发者无需担心容量规划,轻松应对从零到万级并发的波动。
3. 按量付费的经济性:传统常驻服务无论是否处理请求,均持续产生费用。而函数计算采用“用多少付多少”的计费模式,极大降低用户成本。(下文也将介绍 AI 场景下如何实现经济计费)
4. 简化的运维体验:函数计算将基础设施管理完全托管给云平台,开发者只需关注代码逻辑,这种“代码即服务”的模式,极大加速了 AI 业务的迭代与上线周期。
5. 异构算力支持:针对图像处理、音视频编解码等高性能场景,函数计算成熟的 GPU 实例支持,为 Agent 提供了更广阔的技能空间。

产品化实践:基于函数计算构建沙箱能力




Cloud Native

为了将通用的函数计算转化为专业的 Agent 运行时,我们不仅需要底层的隔离,更需要在协议层、会话层和调度层进行深度重构。

1. 协议扩展:定义多元化业务的接入标准

Agent 的交互模式远比传统 Web 应用复杂。为了让 Agent 沙箱能够无缝嵌入现有的 AI 生态,我们针对不同场景实现了协议适配:

1. 针对工具生态:支持 MCP SSE 与 Streamable 协议
随着 Model Context Protocol (MCP) 成为 Agent 工具调用的事实标准,函数计算在网关层实现了兼容标准的 MCP 协议,这意味着可以在函数计算平台实现一键托管 MCP 服务。
2. 针对 Web/Browser Agent:支持标准 Cookie 协议
Browser Agent 需要模拟登录状态或维持持久化的 Web 会话。函数计算的接入层通过实现兼容标准 Cookie 协议,使得沙箱环境能够保持与目标网站的交互状态,支持复杂的自动化操作。在用户首请求时,服务端将生成全局唯一的 CookieID 并通过 Response 中的 Set-Cookie 字段返回,后续请求用户仅需携带相同 CookieID 便实现定向路由。
3. 针对灵活接入:定义统一 Header Field 协议
在基于 Header Field 的会话亲和机制中,仅需客户端通过在 HTTP Header 中注入特定的元数据。函数计算系统网关会解析请求头中的会话 ID,并将其作为路由键,确保携带相同会话 ID 的后续请求被精准路由到同一函数实例。这种方式不依赖客户端状态(如 Cookie),可以应用在任何客户端以 HTTP 协议交互的业务场景中。

2. 底座能力:构建有状态的会话管理

在解决了协议层“如何接入”后,接下来的挑战是如何在无状态的 FaaS 架构上,构建“有状态”的会话体验。

2.1 会话生命周期管理

Agent 的执行往往不是一次性的,而是多轮对话,为此需要赋予会话生命周期管理能力,如下图所示,系统提供用户主动、系统自动两种能力实现灵活、完整的管理机制:

1. 用户主动管理
a. 续期:面对 Agent 执行逻辑的不确定性,在生命周期配置上通常很难做到“一次性设对”。期间为延续状态的连续性,避免任务中断,可通过 Update API 实现对 Session TTL/IdleTimeout 的续期,主动延长沙箱寿命,续期后会话仍处于活跃状态且继续可用。
b. 销毁:显式通过 Delete API 删除会话,实现提前销毁释放资源。
2. 系统自动管理
a. Session TTL:会话达到 TTL(最大存活时长上限)后,无论是否仍在使用,平台都会自动回收资源。
b. Session IdleTimeout:会话在 IdleTimeout 规定时间内没有活动,平台判定为空闲并自动回收。

两类方式最终都会走到生命周期结束 → 会话销毁 → 关联资源释放。

2.2 会话亲和能力

这是将 FaaS 转化为“AI 运行时”的关键。通过会话亲和,我们保证了 Agent 上一轮生成的中间变量、本地文件在下一轮交互中依然可用。


整个流程分为用户首请求和非首请求,以 HeaderField 为例:

会话初始化流程(首请求)

1. 发起请求:Client(客户端)向 Gateway(网关)发送请求,并在 Header 中携带特定的 x-fc-session-id,用于标识该请求属于哪个 Agent 会话。
2. 生成内部 ID:Gateway 接收请求后,对 session_key 进行哈希处理,生成一个系统内部使用的 internal_session_id。
3. 查询会话状态:Gateway 向 MetaDB(元数据库)发起查询,核实该 session_id 是否已经存在(即是否已经有对应的运行实例)。
4. 未命中处理:MetaDB 未搜到到相关信息,表明这是一个新会话,或者之前的会话已失效,需要重新分配资源。
5. 触发调度:由于是新会话,Gateway 随机选择一个 Scheduler(调度器)节点,请求为该会话分配计算资源。
6. 分配实例:Scheduler 根据当前资源情况,从资源池中分配一个可用的 VM 实例(即沙箱环境)。
7. 持久化映射关系:Scheduler 将 session_id 与分配到的 instance(实例)的对应关系写入 MetaDB。这样后续携带相同 ID 的请求就能实现“会话亲和性”,直接路由到该实例。
8. 路由响应:Scheduler 将实例的路由信息返回给 Gateway。
9. 返回首包:Gateway 完成链路建立,将处理后的首包数据返回给 Client。至此,该 Agent 会话正式建立,后续交互将直接复用此路径。

热请求数据流程

1. 发起请求:Client(客户端)发起请求,并在 Header 中携带已有的 x-fc-session-id。
2. 查询会话记录:Gateway(网关)接收请求后,前往 MetaDB(元数据库)查询该 Session ID 对应的记录。
3. 返回映射信息:MetaDB 返回该会话之前绑定的 Instance(实例)信息以及负责管理该实例的 Target Scheduler(目标调度节点)。
4. 直连调度节点:Gateway 根据返回的信息,直接联系对应的 Target Scheduler。
5. 确认路由实例:Target Scheduler 告知 Gateway 该实例有效,可以进行数据转发。
6. 转发请求:Gateway 将客户端的业务请求转发给对应的 Instance。
7. 处理并响应:Instance(Agent 沙箱)执行代码逻辑处理请求,并将结果返回给 Gateway。
8. 返回业务数据:Gateway 将最终的执行结果回传给 Client,完成一次有状态的会话交互。

2.3 会话隔离能力

为了极致的安全,我们引入了“一会话一实例”的隔离模型。每个 Agent Session 独占一个底层的运行实例。一旦会话结束,实例立即销毁并擦除数据。通过会话配额控制,可以有效防止单个用户创建过多沙箱导致资源过载。

3. 扩展配套能力,强化 Agent 底座

除了核心的调度与协议,针对生产环境中的性能与成本挑战,我们进一步扩展了配套能力:

1. 预热能力
冷启动是 Serverless 的天敌。针对 Agent 实时交互的要求,我们支持 CreateSession 主动预热。在用户刚进入对话页面时,系统提前准备好预留实例。将沙箱的就绪时间压缩至极低延时。
2. 会话级存储隔离
Agent 经常需要读写文件。我们实现了会话维度的动态存储挂载。每个沙箱可以根据 Session ID 动态挂载独立的 NAS 或 OSS 路径。这样既保证了数据在会话内的持久化,又确保了不同会话间的文件系统是物理隔离的。同时满足沙箱异常 Crash 后数据的可恢复。
3. 计费升级模型进化:从 FaaS 的“按请求”到“按资源消耗”
FaaS 按请求计费模式,在 AI 场景下会产生巨大的“保活成本”。会话计费模型必须与资源的实际使用强挂钩,因此系统针对会话函数的计费模式升级到 Serverless AI 计费模式。
  • 活跃期:当会话实例正在处理用户请求时,按照活跃单价计费。
  • 空闲期:当会话处于空闲、仅维持连接和上下文状态时,系统切换到一个极低的“保活”费率。仅收取内存、磁盘的费用,不再收取相对较高的 CPU 费用。

这个模式对客户而言,相对传统常驻实例完整生命周期计费模式成本大幅降低。

总结与展望




Cloud Native

Serverless 函数计算凭借其安全隔离、弹性伸缩、按需付费等基因,正成为构建 Agent 运行时的理想选择。通过协议生态扩展、会话管理能力增强、配套能力完善,我们已实现从“单一函数执行”到“复杂 Agent 托管平台”的跨越。未来,我们也将持续聚焦启动优化、更长会话支持等等核心能力,做好 AI 原生时代坚实的护航者。

相关链接:

[1] 查看更多产品详情
https://www.aliyun.com/product/fc
[2] 相关文档链接
https://help.aliyun.com/zh/functioncompute/fc/user-guide/session-lifecycle-management

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询