AI Agent 运行时相比传统应用有什么差别：百家企业 AI 实践观察（二）

作者：计缘
在本系列的开篇内容中，我们已经和大家一起理清了一些根本概念， 比如 AI 应用的界说，AI 应用的核心是什么，以及 AI Agent 的界说和推理模式等。
今天我们聊聊 AI Agent 运行时。
如上文所述，我们正步入一个由 AI Agent 驱动的全新 AI 时代。AI Agent 运行时已不再是简朴的代码执行环境，它演变成了一个动态、有状态且可能是变乱驱动的复杂系统。这个运行时负责管理 AI Agent 的完整生命周期，包括其状态维护、与外部工具的交互以及多智能体间的协作举动。OpenAI 将 Agent 重新界说为“模子 + 指令 + 工具 + 运行时”的组合，这标志着 AI Agent 运行时本身已从“附属组件”，跃升为不可或缺的“核心基石”。
AI Agent 运行时的挑战点

AI Agent 的计算负载特性与传统应用截然差别。传统的 Web 服务通常具有可预测的请求-相应模式，而 AI Agent 的运行推理模式如上文所述，是多种多样的，并非一次简朴的模子推理，而是一个复杂的、多轮次的循环工作流，涵盖了持续的规划、工具调用、自省和迭代式推理。它不是一次性的问答，而是一个为达成目标而不断“思考”和“办法”的动态过程。比如 ReAct 模式在每一步都必要 LLM 举行推理以决定下一步是思考还是办法；而 CoT/ToT 为了做出更优决策，会模仿多条未来的推理路径，这都极大地增加了并行的推理调用需求。
正由于这些特性，AI Agent 的一次运行可能是一种“脉冲式”或“突发性”的资源斲丧模式——即在极短时间内举行高强度计算，随后进入长时间的闲置状态。这种动态推理过程虽然功能强大，但也带来了显著的延迟波动和高昂的底子办法成本挑战。
别的 AI Agent 正从理论走向实践，这预示着人机交互和任务主动化的根本性变革。然而，赋予这些 Agent 强大本领的自主性、学习本领和工具利用特性的同时，也引入了亘古未有的安全风险。比如提示注入（Prompt Injection），工具滥用与不受控的系统命令、权限泄露、上下文泄露与级联故障等。所以运行 AI Agent 的环境必要是一个隔离的、访问控制与系统调用拦截的、可严格管理资源的、具备可观测与审计的环境，也就是沙箱环境（Sandbox）。
所以我们尝试通过阿里云函数计算 FC 这种 FaaS 形态的 Serverless 计算产品，帮助企业办理 AI Agent 运行的构建效率、资源成本、Sandbox 三大挑战。
函数计算 FC 作为 AI Agent 运行时的上风

AI Agent 的独特运行模式和对计算资源的需求在函数计算 FC 这种 FaaS 计算资源上找到相对完美的办理方案。这种对应关系可以通过下表清晰地展示出来：
AI Agent 运行时需求函数计算 FC 的上风变乱驱动与异步执行多种原生的变乱触发器和异步任务执行模式不可预测的突发性工作负载主动、快速的弹性伸缩（从零到N）高昂的计算资源闲置成本按实际利用量计费必要安全、隔离的执行环境天然沙箱化的运行时复杂、多步调的工作流与工作流引擎有深度集成数据持久化与OSS，NAS，PolarFS做好了深度集成快速迭代与开发的需求聚焦业务逻辑，而非底子办法这里先来整体看一下函数计算 FC 作为 AI Agent 运行时的方案拓扑图：

函数计算 FC 作为 AI Agent 自身的运行时（Runtime）

函数计算 FC 作为 AI Agent 的运行时有两种模式：

• 函数计算 FC 作为 AI Agent 自身的运行时。
  
• 函数计算 FC 作为辅助 AI Agent 的沙箱环境（Sandbox）。
  

编码式 - 函数计算 FC 作为计算资源运行 AI Agent

FC 作为 AI Agent 的运行时有两种范例：

• 用户自研的 AI Agent。或者利用 Spring AI Alibaba、LangChain、LlamaIndex、Pydantic AI 等开发 Agent 的综合框架开发的 AI Agent。
  
• 在 FunctionAI 平台上，已经托管了一些现成的 AI Agent 组件，比如 OpenManus，Jmanus，ComfyUI，SD WebUI 等，可以一键拉起利用。
  

FC 作为 AI Agent 运行时的上风：

• 函数计算 FC 触发器机制，实现 AI Agent 可灵活被调理。
  
• 函数计算 FC 按请求扩缩，提升 AI Agent 资源利用率，低落资源成本。
  
• 函数计算 FC 支持多种存储机制，提升 AI Agent 数据存储的灵活性和安全性。
  
• 函数计算 FC 函数实例动态安装依赖包，提升 AI Agent 业务形态多样性。
  
• 函数计算 FC 支持 Seesion 会话亲和，进一步提升 AI Agent 执行任务的同等性和隔离性。
  

Chat AI Agent 解析

我们拜访中的许多客户做的 Agent 服务于 Chat 场景，本质上就是负责和用户对话交互的 Agent，用户和企业产品的一次对话就会产生一个任务，由 Agent 负责执行这个任务。
这种 Chat Agent 最大的特点是执行任务的 2 个不确定性，和 1 个同等性：

• 不确定性：
  
  
  
  • 执行环境里的各依赖包的不确定性。
    
  • 拿用户相关文件信息路径的不确定性。
    
  
  
• 同等性：
  
  
  
  • 必要同一个会话（Session）的请求都分配到同一个实例中，从而包管执行任务在上下文环境、上下文数据方面的同等性。
    
  
  

以上两个不确定的特性就是 AI Agent 运行时自身以及共同存储产品必要办理的问题。
执行环境里的各依赖包的不确定性

这是由于这类 AI Agent 处理的任务是千奇百怪的，用户的问题是无法穷举的，所以无论是 AI Agent 的实现代码逻辑也好，还是运行 AI Agent 的运行时也好，都不可能事先预置所有的依赖。而是只实现 AI Agent 的主干核心逻辑，以及一个隔离并灵活的运行环境，在执行用户的任务时，当遇到必要利用三方依赖时，可以暂停执行任务，先安装所需依赖，然后再继续执行任务，所谓兵来将挡，水来土掩。
函数计算 FC 方案：函数计算 FC 天然具备这个本领，每个实例底层都是隔离的容器环境，通过 subProcess 可以直接执行像 pip 或者 npm 的包管理命令来动态安装依赖，由于每个实例都是完全资源隔离的，所以同一个 AI Agent 函数的差别实例都可以是独一无二的运行环境，有差别的依赖，既相当于每一次执行用户任务运行环境都是完全隔离和完全不相同的，完美匹配这类 AI Agent 的不确定特性。
拿用户相关文件信息路径的不确定性

这个不确定性特性的本质是用户数据隔离的问题。通常环境下，这类 Chat AI Agent 的文件路径是以用户（User ID）/会话（Session ID）/任务（Task ID）命名的，目标有两个：

• 细粒度存储用数据，方便后续做检索，或者长期记忆存储。
  
• 实现用户级别，会话级别，甚至任务级别的数据隔离。
  

这里就会涉及到怎样选择存储产品，目前我们遇到的，或者说阿里云上适合的存储产品无非就是云盘，OSS，NAS 以及 PolarDB 新出的 PolarFS。

• NAS：NAS 有单集群 10 亿个文件的 SLA 上限，但是 AI Agent 场景，尤其 Chat 类的 AI Agent 很容易就会凌驾 10 亿个文件，所以 To C 端的大型或者通用 Chat AI Agent 如果要利用 NAS 必要通过多集群来规避 10 亿文件的 SLA 上限问题。
  
  
  
  • 函数计算 FC 方案：函数计算 FC 和 NAS 有产品间的深度集成，可以方便地通过白屏化或 OpenAPI 或命令行工具的方式将 NAS 挂载到函数上。这里我们推荐一个用户对应一个函数，该函数挂载 NAS 路径时只挂载根路径，也就是只挂载用户（User ID）这一层。在 AI Agent 的逻辑里再去拼接利用会话（Session ID）/任务（Task ID）这后两级目录，由于会话和任务这两级目录的名称是不确定的、是动态的，所以更适合在请求中拿到会话和任务的名称后，在代码里在用户这级根目录下动态创建，然后做文件数据的存取。
    
  
  
• 云盘+OSS：这两个存储介质通常是共同利用，整体的逻辑是利用云盘实时存储 AI Agent 执行过程中产生的各种范例的文件数据，在任务执行完之后，打包上传到 OSS 作为持久化。OSS 的文件对象命名也根本遵循用户（User ID）/会话（Session ID）/任务（Task ID）这个规范。
  
  
  
  • 函数计算 FC 方案：函数计算 FC 和 OSS 有产品间的深度集成，也是类似 NAS 一样的挂载方式，将 OSS Bucket 映射为挂载根目录。同时函数计算每个实例都有隔离的云盘存储空间。在函数中，利用各个编程语言自带的操作本地目录存取文件的方式利用这两种存储介质即可。
    
  
  
• PolarFS：PolarFS 本质上和 NAS 的用法同等。
  

会话（Session）请求亲和性

会话（Session）请求亲和性除了上述的包管执行任务在上下文环境、上下文数据方面的同等性以外，同一个会话或任务复用同一个实例，也淘汰了动态安装依赖的时间耗费，从而提高了执行任务的效率。
在这个特性上，有几个细节点：

• 实例在支持会话（Session）请求亲和性的同时，还要具备排他性，也就是不能再接新的会话。
  
• 如果该 Session 持续某个时间段（比如1个小时）没有请求输入，这个实例主动销毁，从而包管资源成本最优。
  
• 当实例要销毁时，必要有机制包管数据都被处理完毕，比如打包上传到 OSS。
  
• 如果 Session 请求来的时候发现必要恢复 Session（Session 不是新的，且实例不存在），怎样具备这个判断机制。
  

函数计算 FC 方案：

• 函数计算 FC 支持会话（Session）请求亲和性。只必要请求时在 Header 里带着 x-fc-session-id: 即可，带着相同 Session ID 的请求会被分配到同一个实例中。
  

• 函数计算 FC 可以设置单实例可以接的会话（Session）数，也就是说当该配置设置为 1 时，就具备了排他性，不能再接新的会话了。固然你还可以设置为多单实例可以接多个会话（Session），这样可以满足更加灵活的业务需求。
  
• 函数计算 FC 具备 Session Idle Time 的配置项，如果设置为 1 小时，那么在 1 小时内没有请求进来，实例就会主动销毁，这个值可以根据业务需求灵活设置。
  
• 函数计算 FC 有美满的实例生命周期管理本领，当实例要销毁前会调用 prestop 这钩子方法，用户可以在这个方法中做数据善后处理。
  
• 如果 Session 请求来的时候发现必要恢复 Session 的最佳实践为：
  
  
  
  • 在请求进入函数计算 FC 之前，必要有一个管控服务，该服务负责判断 Session 是否存在，然后采取下一步对函数计算 FC 实例的利用方式。
    
    
    
    • 基于 Session ID 去查 OSS（或者是企业本身的数据表），如果有数据就走恢复逻辑（下载文件，恢复目录），在实例中从 OSS 下载 Tar 包，并解压。
      
    • 如果查不到，就是新的会话，在 Header 中设置新的 Session ID，走创建新实例的逻辑即可。
      
    
    
  
  

整体架构图如下：

流程式 - AIStudio + 函数计算 FC 可视化构建 AI Agent

在这几个月时间里，我们遇到了大量利用开源 Dify 构建 AI Agent 或者 AI 应用的客户，这类客户必要快速构建出可以辅助存量业务的 AI Agent，他们的关注点在业务上，并不会投入过多精力研究编码式的构建方案，像 SaaS 类、泛企业类居多。
AIStudio 是什么

AIStudio 是阿里云自研的可视化构建 AI Agent 的产品。底层的工作流引擎基于阿里云 2018 年就商业化的产品云工作流（CloudFlow），底层算力基于函数计算。而前端的可视化部分我们根本相沿的Dify的设计语言。目标很简朴，就是让用户在不改变利用习惯的前提下享受到更灵活、更稳定、性能更好地可视化构建 AI Agent 的产品。

易用的同时性能更强：

• 兼容 Dify 的流程构建习惯
  
  
  
  • 利用 Dify 可视化流程编辑器的设计语言和 UE，最大限度兼容用户在构建流程时的习惯。
    
  
  
• 具备正统流程引擎的高性能
  
  
  
  • 基于函数计算 FC 和云工作流 CloudFLow 实现的生产级流程引擎。
    
  
  

AIStudio 的上风和特点：

• 支持函数计算节点，使构建流程的灵活性得到大幅度提升。
  
• 默认支持最大 1000QPS，且可以按需继续提升。
  
• 多节点复杂流程依然具备稳定高可靠的执行性能。
  
• 除了 HTTP 以外，还支持多种调理方案，比如 OSS，SLS，Kafka，RocketMQ等。
  
• 具备美满的可观测本领，包括整体流程和具体的每个节点的可观测。
  

虽然目前 AIStudio 还有一些本领正在不断美满中，但是针对上述开源 Dify 的硬伤问题已经具备了彻底办理的本领：

• 性能问题：
  
  
  
  • AIStudio 一个流程默认支持最大 1000QPS，且可以继续提升。这个对绝大多数 AI Agent 来说已经是非常大的 QPS 了，毕竟流程里或多或少都必要和 LLM 交互。
    
  
  
• 安全问题：
  
  
  
  • 云原生 API 网关和 AIStudio 做了产品间集成，访问基于 AIStudio 构建的流程，都可以通过云原生 API 网关侧做管控，这里就包括了多种鉴权方式。
    
  • AIStudio 里唯一涉及到 API Key 的就是和 LLM 交互的配置，LLM 节点和 Agent 节点都可以配置由 AI 网关代理的 LLM，这样 LLM 的 API Key 由 AI 网关做同一管理（后续文章会有解释）。
    
  
  
• 会话调用问题：AIStudio 不但支持定时调理本领，还具备几十种云产品变乱的触发本领，被调理本领一骑绝尘。
  
• Nginx 问题：开源 Dify 核心问题之一就是它的网关层是一个 Nginx，Nginx 本身就有不少的短板（毕竟 ACK 的 Ingress 也不推荐利用 Nginx 了，而是云原生 API 网关）。所以通过云原生 API 网关 + AIStudio 完美规避这个问题。
  
• LLM 问题：
  
  
  
  • 自界说前置后置逻辑：AIStudio 提供独有的函数计算 FC 节点，所以可以灵活地在 LLM 节点前后利用函数计算 FC 节点实现用户自界说的业务逻辑。
    
  • 通过 LLM 节点和 Agent 节点配置由AI网关代理的 LLM 来办理以下问题：
    
    
    
    • Token 统计错误：在 AI 网关侧做同一的 Token 统计观测，维度更多，粒度更细。由于 AIStudio 可能只是 LLM 的其中一个调用方而已（通过按照消费者观测）。
      
    • Proxy 访问异常：通过 AI 网关代理 LLM 的 Fallback 本领提升 LLM API 的高可用性。
      
    • 动态结构化输出：可以利用 AI 网关的插件或者在 LLM 节点后利用函数计算 FC 节点来实现。
      
    • Model Alias：通过 AI 网关代理 LLM 的 Model Name 切换模子的本领实现。
      
    
    
  
  
• RAG/知识库管理问题：我们不重复造轮子，AIStudio 支持检索百炼知识库的节点。将 RAG/知识库管理交给更专业的百炼来处理。
  

典型场景探讨

我们在与客户的交流中，遇到利用可视化方式构建 AI Agent 最多的场景有以下几类：

• 输入：用户问题（文本）+ 企业上传的图片
  
• 处理：
  
  
  
  • 通过 VL 模子识别图片内容，然后联合用户的问题一起重新构建为新的问题。
    
  • 通过 LLM 模子对新问题举行推理。
    
  • 推理时必要联合企业的知识库。
    
  
  
• 知识库构建
  
  
  
  • 企业的原始知识库信息有多种格式：PDF，PPT，TXT，DOC
    
  • 利用了 Dify 自带的知识库及知识库检索本领，没有构建本身的 RAG 逻辑，完全依赖 Dify 的本领。
    
  • 
    
    
    
    • 利用 AIStudio，可以将知识库构建移到百炼知识库中。
      
    
    
  
  


• 营销典型场景：营销活动各素材的组装。初始素材是企业设计团队利用中台部门搭建的 SD 平台辅助做设计产出。然后会基于这些初始素材生成各种端侧，各种尺寸的宣传海报。这些差别的海报尺寸不一样，初始素材的排布不一样，但初始素材不能变。虽然前半段可以借助文生图辅助，但后半段企业验证过，目前的 DiT 模子没法包管初始素材的完全同等性。所以目前后半段还是人工在处理。这个场景目前 Dify 和 N8N 都没有好的实现方式。我们帮客户企业设计的方案如下：
  
  
  
  • 由于后半段不涉及出图，只是图片尺寸的调整和现有素材的排布，所以最有用的方法是联合 LLM 的 Coding 本领，以写 HTML+CSS 的方式来实现，然后再截图。也就是通过自然语言告诉 LLM，写一个页面，页面是什么尺寸，页面上有哪些素材，每个素材在什么位置。
    
  • 该场景有几个核心需求：
    
    
    
    • 初始素材存在哪，怎样和存放素材的组件关联集成。
      
      
      
      • 推荐利用 OSS。
        
      
      
    • 必要有一个预览 LLM 生成的 HTML+CSS 代码的节点，本质上属于一个 Code Sandbox，Run 代码，可以通过 AIStudio 中的函数计算节点实现。
      
    • 必要有一个人工处理的节点，必要打断流程，由于生成的图片还是必要人工审核。
      
      
      
      • 这个本领 CloudFlow 本身是支持的，由于有回调模式，可以让流程暂停，等待企业业务逻辑处理完后回调流程接口，继续让流程运行。
        
      
      
    • 将页面截图并生存在 OSS 的节点。
      
    
    
  
  
• 贩卖场景：做产品贩卖时，期望对营销团队或设计团队，或产品团队提供的图片，在上架流程中做处理，比如去除配景，替换配景，局部改写等。本质上就是借助 DiT 模子对图片做处理。
  
  
  
  • 目前可以利用 AIStudio 中的函数计算 FC 节点，在函数中调用 FunctionAI 中的 ComfyUI 项目标 API 来实现。
    
  
  

函数计算 FC 作为辅助 AI Agent 的 Sandbox

如上文所述，为了确保 AI Agent 能够安全、可控地运行，一个强大的沙箱环境（Sandbox）至关重要。这就像是为 AI Agent 提供一个安全的"游乐场"，让它在其中探索和执行任务，同时又不会对外部真实世界造成不测影响。

但除了运行 AI Agent 自身以外，还有一大类是编外的，用于辅助、提升 AI Agent 或基模本领的沙箱环境（Sandbox）场景，同样也是函数计算 FC 善于的。
目前我们交流与落地实践的有四大类编外沙箱场景：

Code Sandbox

这一类场景的本质就是在一个隔离的环境中运行由用户生成的或者 LLM 生成的代码，分为两种业务场景：

• 帮助训练基模的 Coding 本领：给 LLM 喂需求，由 LLM 生成代码，然后拉起函数计算 FC 实例，运行代码，评判结果。
  
• 实时运行展示用户编码类的任务：这里包括执行后端代码，也包括执行渲染前端代码。无论是基模公司还是互联网企业的 AI 场景，都有相似的需求。比如 Gemni 的 Canvas 本领，千问的网页开发本领，MiniMax 的 Agent 生成代码并运行的本领等。
  

Code Sandbox 场景的一些挑战点：

• 运行环境支持多种编程语言，无论是基模还是加强存量业务的 AI Agent 都不可能限定用户只利用某一种或某几种开发语言。
  
  
  
  • 函数计算 FC 具备所有开发语言运行环境的特性天然匹配这个特性。
    
  
  
• 判定结果不但仅是代码运行结果是否到达预期，还会收集代码执行过程中的硬件指标（并不是所有机型都提供获取这类指标的接口），抓容器的指标，判断衡量代码执行效率。
  
  
  
  • 函数计算 FC 提供能把这些数据拿走的本领，数据抓出来后给到另一个服务做衡量（另一个函数）。
    
  
  
• 执行代码的任务不但仅是单线程任务，可能会起子线程并行处理任务。
  
  
  
  • 函数计算 FC 支持实例内再起多线程执行子任务的本领，得益于函数计算 FC 的实例是完全独立的环境，只要函数规格够，多线程运行也不会影响其他实例，不会产生资源争抢。
    
  
  
• 训练基模 Coding 本领这个场景，大家可能觉得它是一个离线场景，对时延要求不高，但其实并不是这样，反而对时延要求很高。由于训练 Coding 这个链路还涉及到 GPU，如果在执行 Code 这个环节斲丧太多时间，就意味着 GPU 有很大概率要空转，产生资源浪费，所以通常对执行 Code 环节都有严格的时延要求，具体的时延环境是根据能让 GPU 持续运行的整体节奏而定的。
  
  
  
  • 对时延要求高且非常敏感的场景，广告领域的 RTA 绝对算一个，函数计算 FC 有成熟的 RTA 方案，而且支撑着不少大型企业的 RTA 业务，所以在优化冷启动，办理时延方面有足够的履历。那么在 Code Sandbox 这个场景通常会利用弹性实例与毫秒级快照实例组合的方式来包管时延要求。
    
  
  

Browser Use Sandbox

Browser Use 其实并不是一个很新的东西。
在 AI 场景下，当前 Browser Use 主要有两类主要的应用场景：

• 辅助数据采集，比如必要登录的一些网站，获取论文报告等。
  
• 做联网搜索，目前主流搜索引擎的 API 本领乱七八糟，且价格不菲，所以通过 Browser Use 做联网搜索在灵活性和成本方面都是较优的选择。
  

当 AI Agent 的任务从封闭的模仿环境扩展到开放、动态且充满潜在勾引的互联网时，其面临的安全挑战也随之升级。对于一个在 Web 上操作的 AI Agent 来说，互联网不再仅仅是信息的来源，它本身就是一个动态的、可能包含恶意内容的输入源。网页的内容直接影响 Agent 的感知和决策，所以这就是为什么 Browser Use 也必要沙箱环境的缘故原由。
Browser Use Sandbox 场景的一些挑战点：

• 必要 Session/Cookie 亲和性。辅助数据采集时，必要登录后才能获取到数据，所以必要相同 Session 的请求分配到同一个实例中，制止反复登录。
  
  
  
  • 上文中已经解释了函数计算 FC 是怎样支持会话（Session）亲和性的。所以也是天然适配 Browser Use 的特性。
    
  
  
• 必要基于内存扩容，这个场景比较吃内存，且大多数语言内存接纳机制都不好。
  
  
  
  • 函数计算 FC 默认按请求扩容，此外还支持用户配置按时间和并发度扩容，为了支持 Browser Use Sandbox 场景，又支持了按内存扩容的本领。
    
  
  
• 优雅下线，也就是实例要销毁时做 Browser Use 操作的后处理。
  
  
  
  • 依托函数计算 FC 的生命周期管理本领，通过 prestop 钩子函数做 Browser Use 收集数据的后处理操作。
    
  
  

RL Sandbox

有一些基模企业或做通用 AI Agent 的企定，会专注在垂直类场景，这类企业会针对特定场景对 LLM 或 AI Agent 算法做定向强化学习。
这类强化学习场景对于客户来说，希望有一个独立的、隔离的运行环境，即沙箱环境，会有以下共同的诉求点：

• 安全性：Agent 在训练初期的举动每每是随机且不可预测的。在沙箱中，错误的决策不会造成任何实际丧失。
  
• 高效率与可复现性：沙箱环境可快速拉起，快速复制相同的环境，让 Agent 在短时间内经历海量的训练。同时，研发可以精确控制每个环境的每一个变量，从而能够复实际行结果，举行可靠的对比分析。
  
• 低落成本：不希望过多维护 IaaS 资源，随用随拉起，而且强化学习也不是实时业务，怎样最大限度提升资源利用率也是低落成本的优化手段。
  
• 运行环境完整性：沙箱环境不要有太多限定和约束，期望和一台 Linux 机器一样去利用。甚至可以设置一些系统级参数。
  

函数计算 FC 作为 FaaS 形态的 Serverless 计算产品，天然匹配以上这些需求，所以企业选择利用函数计算 FC 作为 RL Sandbox 的底座。
RL Sandbox 场景的一些挑战点：

• 动态安装依赖，企业的业务环境会构建为一个容器镜像，但只是包含最底子，最小闭环的依赖。在真正执行时可能会必要动态安装依赖。
  
  
  
  • 上文中已经介绍过函数计算 FC 实例内支持动态安装依赖。
    
  
  
• 实例不能被复用，制止影响执行结果，污染执行过程产生的数据。
  
  
  
  • 函数计算 FC 默认实例是可以被复用的，这样可以大幅低落冷启动，淘汰 RT。但同时也可以通过配置关闭实例复用的本领，从而满足这类强化学习的场景。
    
  
  

仿真训练 Sandbox

仿真训练 Sandbox 场景目前主要聚焦在具身智能场景。
具身智能仿真训练根本流程：

• 利用 NV Omniverse 提供的可视化界面，构建假造环境，准备环境数据。
  
• 构建好仿真环境和数据后，生成任务包，将任务包分发到 GPU 服务跑训练任务。该服务利用的框架大多数也是 NV Omniverse 里的 Isaac Sim。
  
• 分发任务的逻辑通常会利用 Airflow，且 Airflow 的流程是比较简朴的。
  
• GPU 服务跑完训练任务后，状态会回调 Airflow，由 Airflow 同一来展示这次任务的执行结果。
  

函数计算 FC 具身智能仿真训练方案：方案分为两种范例。

• 函数计算 FC 具身智能仿真训练自闭环方案：
  
  
  
  • 不带流程的方案：适合任务分发简朴的企业，或者刚开始做仿真训练的企业。
    
  • 带流程的方案：适合任务分发相对复杂的企业。
    
  
  
• Airflow + 函数计算 FC 的具身智能仿真训练方案：适合对 Airflow 模式非常认同的企业。
  

无论是编码方式构建 AI Agent，还是可视化流程式构建 AI Agent，一旦脱离了 LLM，就不存在 AI 一说了。所以 AI Agent 怎样合理地、生产级地与 LLM 联合，将是我们下篇文章的核心内容。