基于函数计算 FC Sandbox 方案实现类

前言

我之前写过两篇如何构建 AI 应用 / AI Agent 的文章，里面涵盖了多个环节，多个领域的组件，整体的核心思路是想表达 AI 应用的本质是以 AI Agent 为表现层/推理指引层/业务入口层的一个有机系统，Sandbox，LLM，MCP，MEM，可观测等都是这个系统里重要的组成。

《万字长文告诉你企业如何基于MCP实现AI应用架构新范式转型》

《3个月，200+客户，4万+字，和大家聊聊企业AI应用（AI Agent）的落地实践》

但是目前鲜有客户完全落地了这套系统，而更多的是使用其中某几个组件做 POC 和尝试，最常见的组合就是普通服务 + LLM，进阶一点的就是普通服务 + LLM + MCP（不带MCP Registry）。使用 AI 网关和 MSE Nacos 也有比较成熟的落地方案，所以今天通过真实案例，向大家分享再进阶一点的 Sandbox 的落地实践。
AI Agent 试验田

目前，LLM的使用被大众最广泛认知的还是以 Chat 模式为主，而 AI Agent 让大家体感最强的，或者说目前应用最好的是在 Coding 场景，而且每家厂商几乎都将 Coding 功能明显的展现了出来。

• 通义千问：
  
  
  
  • 
    
  
  
• Minimax：
  
  
  
  • 
    
  
  
• Gemini：
  
  
  
  • 
    
  
  
• Kimi：展示的相对隐晦一些。
  
  
  
  • 
    
  
  
• Grok：算是为数不多不主打 Coding 的 LLM，但 Grok 4 Heavy 的 Coding 能力也不赖。
  
  
  
  • 
    
  
  
• ChatGPT：还是以 DeepSearch，任务推理为主，没有明显展现出其 Coding 能力。
  
  
  
  • 
    
  
  

之所以各个厂商都在 Coding 场景落地 AI Agent，我个人认为有这么几个因素：

• 人潜意识里其实都有创造的欲望，但绝大多数人都只有想法，没有实践落地能力。大模型出来后，在某些场景下可以帮助人们实现想法，满足了人们的部分欲望，但人的欲望是无限的，之前那些产物并不能变现，比如最早时期 SD 出来那会。LLM Coding + Vibe Coding 概念出来后更是引起了一股浪潮，最重要的是 LLM Coding + Vibe Coding 的产物是有机会变现的，甚至开公司创业。
  
• Coding 的产物可以被大众的评判标准量化，从而直观的体现出 LLM 能力的强弱。现在评测 LLM 能力的那些数据集的质量以及客观公正性我在这里就不赘述了，绝大多数人对那个是无感的。但是 LLM 写出来的代码至少是能被广大开发工程师拿来检验的。
  
• Coding 的场景几乎用到了AI Agent 系统的所有必备要素。Planning，Sandbox，LLM，MCP，MEM，可观测等。需要将这些要素有机的结合起来，构成 Coding AI Agent 系统，才能让 LLM 写出相对成熟可用的代码。
  
• 当 AI Agent 这套系统在 Coding 场景下验证成熟后，整套 AI Agent 系统的架构可以很快复用到其他场景，只需要替换整体架构里具象的组件即可，比如替换 LLM 版本，替换不同的 MCP 服务，替换不同的 Prompt，替换不同的 RL 评测方式等。
  

泛 Chat 类型 Coding AI Agent 整体架构


这里我不对整体架构做解释，我想通过落地过程中，或者说 AI Agent 场景中势必会遇到的挑战点以及解法的维度向大家做分享，然后你们再回头来看这个架构图，应该自然而然就可以理解了。
泛 Chat 类型 AI Agent 的挑战点及解法

从目前看，无论是 Coding 场景，还是写 PPT 啊，文本分析啊，文生图/图生图啊等等，还是用 Chat 类型模型更加易用。包括互联网其他客户的现存业务在融入 AI 能力时，基本也都是 Chat 模式，比如一些客户的智能点餐业务，一些 CRM/ERP 厂商的智能客服，智能问数，智能 BI 等等，都是 Chat 模式。
我锚定后续出现的其他 AI Agent 的场景，大概率也都是以泛 Chat 模式为主。整体的方案架构中，会因为 Chat 模式带来额外的挑战点，所以我将 Chat 模式和 AI Agent 作为一个整体系统架构来看挑战点。

本文作为偏方案科普向文章，会尽可能用大白话表述，非常细节的内容就不在文章里赘述了。有想要针对某个点做详细讨论的同学，可以联系我和我们的团队（钉钉群号：64970014484）。

会话亲和性（Session 亲和性）

这是 Chat 模式最具代表性的一个挑战点。以 Gemini，Claude 为例，每次新建一个聊天/对话/ chat 就产生了一个新的会话：

会话发起后，你会和 LLM 进行交互，此时该会话底层就会有对应的计算资源实例在运行，提供运行环境（Runtime）。
在这个会话中，你和 LLM 的交互产生几类数据：

• 你的文本输入和 LLM 的文本输出，就是各种文字。
  
• Coding 场景中，LLM 会产生各种代码文件。
  
• Coding 场景中，为了可以运行程序，需要动态安装各种依赖（比如 NodeJS 技术栈通过 npm 安装的各种依赖，Python 技术栈通过 pip 安装的各种依赖等），同样也是各种文件。
  
• 计算资源实例，或者说 Runtime 的各种状态，比如 OS 层面的环境变量值等。
  

上述第一类数据可以存在各类数据库里，但是后三类数据在计算资源实例还在存活时，只能在实例中。这时可能会有同学要问，挂载一个文件系统行不行呢？

• 存储上述2，3类数据，是如果是一个非生产级，或者内部使用的系统，可以。
  
• 存储上述2，3类数据，如果是 To C 场景的生产级系统，不建议。
  

因为在这个场景中，数据的隔离性是强诉求，挂载 NAS 并做不到绝对强隔离，除非一个实例挂载一个文件系统，这也不实现，因为在这个场景下计算资源实例会非常多。
上述第4类数据无论如何只能是在实例级别，因为和 OS，和容器文件系统相关。
综上，在这种场景下，需要会话和计算资源实例通过某种方式绑定，每次打开这个会话，请求要路由到相同的实例，从而保证该会话生命周期里所有数据、状态的一致性。
阿里云函数计算 FC 支持多种亲和性方式

函数计算 FC 支持三种亲和性：

• MCP SSE 亲和。
  
  
  
  • 基于 MCP SSE 协议规格，系统确保携带相同 SessionId 的客户端请求始终路由到同一个实例实现亲和行为。
    
  
  
• HeaderField 亲和。
  
  
  
  • 基于 HTTP 请求头中的指定字段值实现会话亲和。
    
  
  
• Cookie 亲和。
  
  
  
  • 基于 HTTP Cookie 中的特性值实现会话亲和。
    
  
  

在帮助客户落地时，大都使用了 HeaderFiled 亲和方式，在每个会话里发起请求时，Header 里会带着 UserID+会话 ID 作为 SessionID，实现了会话里的每个请求都能路由到相同的实例中，从而保证了会话的所有数据、状态的一致性。
除此以外，函数计算 FC 在函数级别还可以设置每个实例的 Session 并发度，即一个实例允许接几个 Session 的请求，从而满足更灵活的业务场景。

除了 AI Agent 场景，该能力在游戏场景也有广泛应用，比如 IGame 工作室的《第四纪元》游戏底层游戏服、平台服、WS 服全部使用函数计算 FC，实现游戏底层完全 Serverless 化。

https://mp.weixin.qq.com/s/Iuh7uIBxFH2Jp8GFYKqVhw

会话级别的隔离性

在泛 Chat 类型的场景下，用户的不同会话之间，不同用户的会话之间都需要完全隔离，这是数据安全、用户隐私安全的的刚需诉求。
这里包括了以下若干方面的隔离性：

• 运行会话的计算资源实例之间的网络隔离。
  
• 运行会话的计算资源实例之间的存储隔离。
  
• 运行会话的计算资源实例能否完全与外界隔离，既是否能允许访问公网。
  
  
  
  • 在 AI Agent Coding 场景是需要允许公网的，因为要动态安装依赖。
    
  • 但是很多依赖组件是从外网下载，网络质量不可控，导致下载时间过长或者超时，所以有客户会穷举某个技术栈的依赖组件，构建一个内网下载源，此时需要实例禁止访问公网，做到更强的安全性。
    
  
  
• 运行会话的计算资源实例不能被公网访问。
  
• 运行会话的计算资源实例只能被指定的内网服务访问。
  
• 运行会话的计算资源实例和下游服务之间的互通管控。
  
  
  
  • 有些场景下不允许实例访问其他内网服务。
    
  • 有些场景下需要允许实例访问其他内网服务。
    
  
  

函数计算FC实例之间的隔离性

• 函数计算 FC 相同函数的每个实例之间，不同函数的实例之间都是网络隔离的。
  
• 函数计算 FC 函数的每个实例有自己独立的磁盘空间，实例之间的磁盘是隔离的。
  
• 函数计算 FC 函数可以设置是否可以允许访问公网，可以根据具体业务场景开启或关闭。
  
• 函数计算 FC 函数可以禁用被公网访问。
  
• 函数计算 FC 函数可以设置只允许被指定的 VPC 内的资源访问。
  
• 函数计算 FC 函数可以配置 VPC，可以和指定 VPC 打通网络，实现灵活管控和内网其他服务之间的网络。
  

会话存储机制

从存储机制和介质类型方面来说，无非就是两种方式：

• 云盘+OSS
  
• 挂载文件系统
  

以上两类方式在这个场景中都会用到，会在合适的场景下使用合适的方案。这个场景的存储机制包括4个核心问题：

• 存储成本问题。
  
• 数据完整性问题。
  
• 动态挂载存储问题。
  
• 限制每个路径下上传文件的总量。
  

存储成本问题

这个问题主要源自 AI Agent Code Interptreter Sandbox 场景的不确定性特性之一，环境依赖的不确定性。既每个用户发起的 Coding 任务，都需要各种不同的依赖包，所以需要在执行任务的过程中动态安装依赖。
所以，以 NodeJS 为例，会在构建项目的过程中在node_modules文件里生成大量的各种组件、依赖的文件，并且不同项目的组件、依赖重复度较高。如果每个项目的node_modules文件都保存下来，那么存储成本压力会非常大。
大部分客户在解决这个问题时使用了函数计算FC函数磁盘+OSS 的方式。

• 项目构建过程中生成的所有文件，都先保存在函数磁盘中。
  
• 在函数PreStop生命周期方法中（函数实例销毁时调用），将除了node_modules文件的所有其他文件打包上传到 OSS。
  

通过这种方式用户只需要持久化保存项目的主干工程即可，不需要将依赖都保存下来，并且在实现过程中，也不需要特意去考虑删除node_modules文件的工作，因为函数实例只要释放了，实例磁盘里的数据也就都删除了，所以用户只需要实现简单的选择文件打包上传 OSS 的逻辑即可。
但这种不存依赖的方案再恢复会话时有一定时延的弊端，这问题在下文对应章节会解释如何优化。
数据完整性问题

数据完整性问题指的是当计算资源实例出现非预期的 Crash 时，是否能最大程度的保存下来当时的各种数据。在这个前提下无疑挂载文件系统的方式是最有效的，因为整个 IO 操作都是通过文件路径实时写入文件系统的，所以在实例 Crash 的一瞬间，可能只有极少数的文件会丢失。
而云盘+OSS 的方式，因为上传 OSS 并不是实时的，所以在实例 Crash 的一瞬间，可能会丢失相对更多的文件。但是经过我们反复的技术调研、测试以及和客户的推演讨论，最终认为在 Sandbox 场景下，还是云盘+OSS 的方式是最适合的。
文件系统不适合 Sandbox 场景的核心原因主要有2个：

• 上述存储成本的问题。
  
  
  
  • 如果所有文件都存在文件系统，又想只选择部分持久化，那么势必要实现一个非常复杂的文件删除逻辑，一旦文件删除逻辑设计有缺陷，那么可能会造成更大的问题。
    
  
  
• 存储安全或者说隔离性的问题。
  
  
  
  • 虽然系统在运行代码时已经禁用了执行mount 权限，但在使用 WebShell 登录计算资源实例（仅限于神龙）时，给到用户的是root权限， 可以成功执行mount指令，挂载到文件系统的任意目录。
    
  • 由于 NFS 协议需要在可信网络环境中（配置 VPC）允许文件访问，所以只要计算资源实例在可信 VPC 下，就可以通过挂载点来访问指定路径的文件，无需任何身份授权。
    
  • 所以，Sandbox 实例若对外暴露代码片段执行能力，允许 C 端执行自定义代码，会被攻击者构造恶意指令来访问文件系统中的文件，不需要任何身份权限校验。
    
  
  

所以再次印证了为什么 Code Interptreter Sandbox 推荐使用函数磁盘+ OSS 的方案。
动态挂载存储问题

这个问题源自 AI Agent Code Interptreter Sandbox 场景的另一个不确定性的特性。那就是挂载存储的路径是动态的，是不确定的。只有请求到了实例里后，才知道要挂载的路径是什么。
因为通常路径都是用户ID/会话ID/[任务ID]，如果是新创建的会话，只有该会话的第一个请求进了实例，才知道完整的路径是什么。所以这就需要计算资源实例可以动态挂载存储介质，而不是先挂载路径后启动实例。并且每个实例挂载的路径都是不同的。
函数计算 FC 的在持久化方面，原本就支持在函数维度设置 NAS 或 OSS 的挂载路径，在这种情况下，该函数的所有实例都会共享该挂载路径。而现在，我们又支持了可以在实例维度动态的挂载 NAS 和 OSS 路径的能力，实现了同一个函数的不同实例，可以挂载同一个文件系统/ OSS Bucket 的不同路径。

限制路径级别的文件总量 Quota 文件

在 AI Agent Coding 或者 Vibe Coding 场景下 ，用户可以随便写个类似云盘的项目，或者论坛的项目。所以可以随意上传文件，如果被非法利用，可能会引起被白嫖存储的问题。所以需要对每个项目可上传文件总量大小做限制。
目前文件系统虽然支持路径级别设置 Quota，但是 AI Agent Coding 这个场景下路径数量会非常多，可预见性的会有几万，十几万个甚至更多，所以需要另寻解决方案。
目前的方案有 2 个：

• 基于函数计算 FC 特性实现的。（短期临时方案）
  
• PolarFS 支持给几乎没有上限的路径设置 Quota。（长期成熟方案）
  

目前函数计算 FC 正在和 PolarFS 做产品间集成，集成后这块会直接换成 PolarFS 方案。我在这里和大家分享一下当前是如何基于函数计算 FC 的特性做的临时实现。
上文中我有提到，函数计算 FC 函数的每个实例都有自己的磁盘，最小是 512MB，也有更大的额度。当超过磁盘大小后会报错。所以目前写好的项目运行在函数计算 FC 实例中，写文件的操作是先写进函数实例的磁盘中，写入成功后，再 CP 到文件系统里。当函数实例磁盘写满报错后，就不会再对文件系统做交互。相当于用函数实例的磁盘做了一层中转，但是依赖函数磁盘 Quota 的强限制，变相解决了路径配额的问题。
会话恢复机制

会话恢复的逻辑本质上是比较简单的，但是这部分涉及到效率问题也涉及到记忆问题，所以结合函数计算 FC 的特性和大家作以分享和探讨。
上文中提到了，会话底下的 Code Interpreter Sandbox 这部分使用的是函数实例磁盘+OSS 的存储方式，所以当会话需要恢复时，需要有2部分的数据需要恢复：

• LLM 输出的一大堆文本，也就是该会话里的上下文。
  
• 代码工程文件和依赖组件。
  

LLM输出的这一大堆文本（上下文），可以选择使用一些记忆组件，也可以选择关系性数据库做存储。
代码工程文件自然是从 OSS 中下载解压做恢复，但是前文中说了node_modules并没有存储，所以在会话恢复过程中，有一部分耗时的地方就是要重新下载安装依赖。这也是我说的效率问题。
这部分如果想要从根本解决效率问题，就得把所有的依赖文件都存下来，但是面临巨大的存储成本压力，多金土豪的客户自然可以用这种方式。但我相信绝多大数客户还是会在效率和成本之间寻找一个平衡的解决方案。
我们目前的做法限制用户可以在1小时内快速恢复会话，超过1小时后就会慢一些：

• 函数计算 FC 函数实例的存活时长（Idle Time）可由用户自行设置。目前实例存活时长为1小时，所以在这1小时内，依赖文件都在函数的临时磁盘里，从而达到高效恢复会话的效果。当在1小时内没有任何请求进来，那么实例才会被释放，所以当用户超过1个小时后再打开会话，就会重新拉起实例，从 OSS 下载代码文件，重新安装依赖，整体会话恢复时间就会较长。
  
  
  
  • 默认情况下，当函数实例在5分钟内没有请求，实例就会被销毁。
    
  
  
• 因为客户可以自行控制函数实例的 Idle Time，所以可以对客户做付费分类，比如 SVIP 用户对应的函数实例 Idle Time 为24小时，VIP 用户对应的函数实例 Idle Time 为10小时，普通用户对应的函数实例 Idle Time 为1小时。
  

会话网络管理

会话网络管理本质上就是会话底层计算资源实例的网络管理，最核心的其实就是 IP 分配的问题。

• 有限的 IP 与 PodCIDR 模型：K8s 在 IP 管理分配方面有集群 CIDR，节点 PodCIDR 分配，Pod IP 分配三个维度，这种设计确保了不同节点上的 Pod IP 地址不会冲突，并且简化了路由。然而，它也引入了一个关键的制约因素：Pod 密度，即每个节点上运行的 Pod 数量。当一个节点上的 Pod 密度很高时，即便整个集群的 CIDR 地址空间还很充裕，该节点自身的 PodCIDR 也可能被迅速耗尽 。
  
• 企业安全组最大支持关联的 IP 地址数量是65535，在这个场景中实例数是很有可能超过65535的。
  

函数计算 FC 作为 Serverless 计算产品，自己有足够大的资源池，函数实例不会使用用户的 IP，并且底层容器的调度和 K8s 也是完全不一样的，而且在安全组方面，相同的 uid+role+vsw+vpc+sg 是复用一个 IP 的，和函数数量没关系，和实例数量也没关系，所以无需客户做任何事情，可以完美解决上述的问题。
项目分享/会话分享机制（Sandbox转传统Server）

在 Vibe Coding 环境中，当一个完全不懂编程的人，只靠一些想法，通过一些平台就可以完完全全实现出来，我觉得除了自己很兴奋外，应该会立马想把自己实现的产物分享给自己身边的朋友，无论是以什么目的做的分享，我相信这份成就感是无与伦比的，这也正是 Vibe Coding 性感的地方之一。
现在很多 AI Agent 产品主打的就是生成完整的项目，可以直接运行的项目，分享出去后可直接使用的项目，所以都会有类似发布分享的功能。大家可以想象一下，当一个由 LLM 写出来的项目，被发布了以后，其实它和什么 AI Agent，Sandbox 就没有任何关系了，运行这个项目的底层计算资源其实就是一个传统的 Server。
但这个传统 Server 面临着不普通的挑战点：

• 在这个场景下，由 LLM 生成的项目会非常多，底层计算资源池准备多少合适？
  
• 分享出去的项目突然成爆款，QPS 巨大，底层计算资源能否快速扩容，接住这泼天富贵？
  
• 那么多项目，大概率99.5%的项目没什么人访问，但有可能有0.5%的项目称为了爆款，在这种情况下，底层计算资源准备多了浪费，准备少了接不住这种出爆款的现象，该怎么办？
  
• 每个项目使用的资源要隔离，爆款项目不影响整个系统（类似热点接口将整个系统拖垮的逻辑）。
  
• 分享出去的项目该用什么样的存储机制？
  

我用大白话将上述挑战点翻译成客户的需求：分享出去的项目对应的资源要相互隔离，互相不影响，项目没请求的时候不要给我拉起资源，有请求时再拉起资源，而且资源可以根据 QPS 量快速横向扩容，而且扩出来的实例可以共享存储，保持项目的状态一致。
从最根本上讲，就是成本的问题。这是标准的 Serverless 形态计算资源解决的问题，所以函数计算可以 FC 完美的解决这个变态的场景。

• 每一个项目对应函数计算 FC 中的一个函数，函数设置多实例多并发，函数规格1C1G，函数挂载文件系统（/用户 ID/项目 ID）。
  
• 绝大多数项目都是没有请求的，或者请求量非常小的。对应到函数计算 FC，那就是大多数函数压根不会拉起实例，只有少部分函数只需要拉起一个1C1G 的实例，就可以支撑少量的请求。
  
• 爆款项目对应的函数在流量高峰期可以快速拉起多个实例，低峰期又可以释放多余的实例，始终保持实例数和 QPS 在比较贴合的情况。
  
• 爆款项目，或者请求量比较大的项目，对应的函数会拉起多个实例，每个实例共享挂载的文件系统路径，所以每个对项目的操作产生的数据变更、状态变更都可以保持一致。
  

爆款项目这个场景很类似我们以前做的一些RTA场景（某客户RTA场景高峰期70w QPS，低峰期30w QPS，QPS 方差达到 40w），或者像高德这种 QPS 有明显波峰波谷且方差比较大的场景。
不同会话配置不同的资源规格（Sandbox实例 VPA 机制）

这个需求本质是因为 AI Agent 场景下的 Sandbox 执行什么样的任务是不可控的，比如有的任务就是简单的推理、查询等，对 CPU 和内存的消耗不高。但有些任务是处理文件、处理音视频，这一类的任务就是 CPU 密集型的场景，要求更高的 CPU 和内存规格。
如果是在同一个函数下的话，就需要函数的实例可以纵向扩容，函数计算 FC 的基础架构底层是支持的，但是没有对应的计费逻辑，或者说这样对客户来说计费逻辑会很复杂，所以目前函数计算 FC 从对外透出的产品能力上并不支持 VPA。
目前给推荐客户的方案如下：

• 引入一个小参数 LLM 做意图识别，类似联网搜索里的意图识别，将任务类型做分类。
  
• 不同任务类型对应不同的函数，每个函数可以设置不同的资源规格。
  
• 使用函数计算 FC 的 Destination 功能做兜底。
  

发布分享项目的访问管控机制

项目做分享这个功能需要涉及到以下几个核心的点：

• 自定义域名的管理，如何和 Sandbox 实例做打通和映射。
  
• 即使 Sandbox 实例有能力快速横向扩容，但依然需要对访问链路做限流、降级、熔断等管控策略，防止一些非法行为。
  
• 如果引入项目 A/B 测试或灰度能力，需要入口做管控策略。
  
• 需要支持多种认证鉴权机制。
  

基于以上这些核心需求，引入了云原生 API 网关做统一的南北向流量入口管控。

• 云原生 API 网关侧可以做域名、路由的统一管理。上图中看到的分享地址（URL），就是管理在网关侧的，并且背后有对应的路由。
  
• 云原生 API 网关和函数计算 FC 做了深度产品集成，在创建路由时可以方便的选到对应的函数。
  
• 云原生 API 网关支持丰富的管控策略和自定义插件机制，所以限流、降级、熔断、各种鉴权认证、 A/B 测试、灰度测试等都可以快速的通过配置来实现。
  

通过 Sandbox 与 Serverless 的深度融合，AI Agent 不再是“黑盒”实验，而是可被企业精准掌控的生产力工具。这种架构不仅适配当前 AI Agent 的动态交互特性，更为未来多模态 Agent、跨系统协作等复杂场景提供了可复用的技术底座。
若您的企业正面临 AI Agent 规模化落地的挑战，不妨从 Sandbox 架构入手，结合函数计算 FC 的Serverless能力，快速验证并构建安全、高效、可扩展的AI应用系统。
更多内容关注 Serverless 微信公众号（ID：serverlessdevs），汇集 Serverless 技术最全内容，定期举办 Serverless 活动、直播，用户最佳实践。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！