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

随着大语言模型（LLM）从“对话框”走向“行动体（Agent）”，其能力边界正在迅速扩张。现代 AI Agent 不再是文字的搬运工，而是能够自主思考、调用工具、甚至编写并运行代码以解决复杂问题的智能助手。然而开发者始终面临一个根本性挑战：如何在保证执行效率的同时，实现资源强隔离与资源可控性？ 阿里云函数计算 FC 为这一难题提供了全新的解题思路。其底层基于轻量级安全沙箱，天然具备进程级隔离、资源极 致伸缩、按需付费等特性。这种架构与 Agent 对代码执行环境的需求高度契合，使得构建高密度、低成本、安全可靠的 Agent 运行时成为可能。

为什么需要 Agent 代码沙箱？

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

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

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

为什么是 Serverless？函数计算的核心优势

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

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

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

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

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

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 协议交互的业务场景中。

底座能力：构建有状态的会话管理

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

会话生命周期管理

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

1. 用户主动管理

• 续期：面对 Agent 执行逻辑的不确定性，在生命周期配置上通常很难做到“一次性设对”。期间为延续状态的连续性，避免任务中断，可通过 Update API 实现对 Session TTL/IdleTimeout 的续期，主动延长沙箱寿命，续期后会话仍处于活跃状态且继续可用。
• 销毁：显式通过 Delete API 删除会话，实现提前销毁释放资源。

2. 系统自动管理

• Session TTL：会话达到 TTL（最大存活时长上限）后，无论是否仍在使用，平台都会自动回收资源。
• Session IdleTimeout：会话在 IdleTimeout 规定时间内没有活动，平台判定为空闲并自动回收。

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

会话亲和能力

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

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

会话初始化流程（首请求）

1. 发起请求：Client（客户端）向 Gateway（网关）发送请求，并在 Header 中携带特定的 x-fc-session-id，用于标识该请求属于哪个 Agent 会话。
2. 生成内部 ID：Gateway 接收请求后，对 session key 进行哈希处理，生成一个系统内部使用的 internalsession_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，完成一次有状态的会话交互。

会话隔离能力

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

扩展配套能力，强化 Agent 底座

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

1. 预热能力

冷启动是 Serverless 的天敌。针对 Agent 实时交互的要求，我们支持 CreateSession 主动预热。在用户刚进入对话页面时，系统提前准备好预留实例。将沙箱的就绪时间压缩至极低延时。

2. 会话级存储隔离

Agent 经常需要读写文件。我们实现了会话维度的动态存储挂载。每个沙箱可以根据 Session ID 动态挂载独立的 NAS 或 OSS 路径。这样既保证了数据在会话内的持久化，又确保了不同会话间的文件系统是物理隔离的。同时满足沙箱异常 Crash 后数据的可恢复。

3. 计费升级模型进化：从 FAAS 的“按请求”到“按资源消耗”

FaaS按请求计费模式，在AI场景下会产生巨大的“保活成本”。会话计费模型必须与资源的实际使用强挂钩，因此系统针对会话函数的计费模式升级到Serverless AI 计费模式。

• 活跃期：当会话实例正在处理用户请求时，按照活跃单价计费。
• 空闲期：当会话处于空闲、仅维持连接和上下文状态时，系统切换到一个极低的“保活”费率。仅收取内存、磁盘的费用，不再收取相对较高的CPU费用。

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

总结与展望

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