在本系列的开篇内容中，我们已经和大家一起理清了一些基本概念， 比如 AI 应用的定义，AI 应用的核心是什么，以及 AI Agent 的定义和推理模式等。
从本篇文章开始，我们将具体讲讲 AI 应用实践过程中每一个环节的核心挑战，以及我们对应的解法和思路。如果您对这些内容感兴趣，推荐您关注阿里云云原生公众号，后台回复 “企业AI实践” 获得我们整理的完整的企业级 AI 应用构建的最佳实践 PPT，配合系列文章一起食用，效果更佳。
今天我们聊聊 AI Agent 运行时。
如上文所述，我们正步入一个由 AI Agent 驱动的全新 AI 时代。AI Agent 运行时已不再是简单的代码执行环境，它演变成了一个动态、有状态且可能是事件驱动的复杂系统。这个运行时负责管理 AI Agent 的完整生命周期，包括其状态维护、与外部工具的交互以及多智能体间的协作行为。OpenAI 将 Agent 重新定义为“模型 + 指令 + 工具 + 运行时”的组合，这标志着 AI Agent 运行时本身已从“附属组件”，跃升为不可或缺的“核心基石”。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-weight: bold;visibility: visible;-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;">AI Agent 运行时的挑战点
Cloud Native
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 三大挑战。
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-weight: bold;visibility: visible;-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;">函数计算 FC
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-weight: bold;visibility: visible;-webkit-tap-highlight-color: transparent;margin: 0px;padding: 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;overflow-wrap: break-word !important;">作为 AI Agent 运行时的优势
Cloud Native
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>即可，带着相同 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 节点和 Agent 节点支持多模态，客服场景也有涉及。
需要有一个预览 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 一说了。