运行画像与执行环境

本文解释 AaaS 如何与 Sandbox、FaaS、Worker、Wasm 结合使用。规范中的统一抽象见 ExecutionProfile Schema、Runtime SDK、RunSpace 与 Session。

先定义问题

Agent 平台不是只需要一个“能跑代码”的环境，而是需要一套“能根据任务形态选择正确环境”的执行画像。

同一个 Agent 平台里，至少会同时存在下面几类任务：

• 交互式、长会话、需要文件系统与进程的任务
• 短时、可并发、无状态的工具调用
• 后台异步、队列驱动、可重试的任务
• 低延迟、边缘侧、轻量隔离的任务

因此，平台不应该把执行环境固化成单一类型，而应把它们收敛成统一的 executionProfile 选择问题。

四类主要执行环境

执行环境	优势	弱点	最适合的 Agent 场景
Sandbox	会话型、可保留文件系统、可运行多进程、调试最友好	成本高于纯事件驱动执行	coding agent、浏览器 agent、研究助手、需要 checkpoint 的任务
FaaS	冷启动和扩缩容模型成熟、按调用计费、短任务成本低	不适合长会话和复杂本地状态	webhook、轻量工具、输入预处理、策略检查、同步补充步骤
Worker	非常适合异步、队列、重试、补偿和 fan-out	交互体验一般，本地环境通常不如 Sandbox 丰富	后台推进、批量处理、补偿任务、多阶段异步 orchestration
Wasm	快速启动、隔离强、便于边缘部署、资源密度高	对复杂依赖和系统能力支持有限	轻量工具、边缘校验、格式转换、策略执行、快速预处理

Sandbox 的定位

Sandbox 是最接近“Agent 原生工作环境”的执行形态。它通常具备：

• 持续存在的工作目录
• PTY、Shell、文件系统和进程树
• 适合依赖安装、测试运行、浏览器操作
• 便于持续心跳和细粒度进程监控

如果你的 Agent 需要像开发者一样操作环境，Sandbox 往往是默认首选。

FaaS 的定位

FaaS 不适合承载复杂交互式主会话，但非常适合承担 Agent 体系中的短动作层：

• 轻量工具函数
• 同步回调
• 预处理和后处理
• 高并发且短时的补充能力

在产品设计上，最稳妥的方式是让 FaaS 成为：

• 某种 runEnv
• 或某类 Tool 的执行承载层

而不是要求所有 Agent 主循环都运行在 FaaS 中。

Worker 的定位

Worker 适合平台内部和 Agent 后台阶段：

• 队列驱动的长链路任务推进
• 批量 fan-out、重试、补偿和聚合
• 后台 Artifact 处理、索引、归档
• 低交互但高吞吐的子任务

它常常不是“用户正在直接交互的 Agent 环境”，却是 AaaS 平台可靠性的关键执行底座。

Wasm 的定位

Wasm 更像轻量执行单元：

• 启动快
• 安全边界清晰
• 适合边缘和多租户高密度部署

它很适合作为：

• Policy 引擎
• Prompt 预处理
• 输入格式检查
• 小型工具运行时

但不适合承担重依赖 coding environment 或浏览器自动化主任务。

推荐的组合方式

组合一：Sandbox 主会话 + FaaS 工具

• 主 Agent 跑在 Sandbox 中
• 短平快工具，例如结构化提取、OCR、Webhook callback，交给 FaaS
• 适合交互式 coding 和企业工具链场景

组合二：Worker 编排 + Sandbox 执行

• Worker 负责后台调度、重试和批量 fan-out
• 真正需要环境和会话的步骤在 Sandbox 中执行
• 适合复杂异步任务和多阶段计划执行

组合三：Wasm 前置 + Sandbox 或 FaaS 后置

• Wasm 负责输入过滤、策略执行和轻量转换
• 通过策略后再进入重型执行环境
• 适合高并发入口和边缘场景

如何为 Agent 选 execution profile

选择画像时，建议按下面几个问题判断：

1. 是否需要文件系统、PTY、浏览器或多进程
2. 是否需要保留会话并支持继续执行
3. 是否需要长时间运行和中间状态恢复
4. 是否更看重启动速度和单位成本
5. 是否需要边缘部署或极强租户隔离

一个简单经验是：

• 需要“像人在电脑前工作”时，选 Sandbox
• 需要“像函数一样快速执行”时，选 FaaS
• 需要“像后台消费者一样推进任务”时，选 Worker
• 需要“像高密度插件一样轻量运行”时，选 Wasm

如何渐进升级或降级 RunEnv

对同一个 Agent 来说，RunEnv 不应该被理解成“一次性拍死的宿主决定”。更可落地的方式是：

• 由开发者通过发布新的 AgentRevision.executionProfile.executionClass.runEnv 管理版本化的升级或降级
• 既有 run 继续使用创建时冻结的 executionProfileSnapshot
• 新建 run 才继承新的 RunEnv

如果希望这种升级或降级不伴随大面积业务重写，关键在于 runtime 代码的依赖边界：

• 尽量把平台中立能力放在 Core SDK
• 由 worker、faas、sandbox 平台包通过 use(...) / register(...) 为 Core SDK 注册 polyfill
• 把文件系统、workspace、terminal、browser 一类强环境能力留在独立 Platform SDK

一个常见的渐进路径是：

• 初期只使用 Core SDK，先把 Agent 部署在 worker
• 当需要更稳定的短时调用语义时，升级到 faas
• 当需要文件系统、PTY、浏览器或多进程时，再升级到 sandbox

反过来，如果某个 Agent 版本去掉了对 Platform SDK 的依赖，也可以由开发者把 sandbox 降回 faas 或 worker。

这里的重点不是平台在运行中“自动切环境”，而是平台通过统一的 SDK 分层，让 RunEnv 变化尽量变成发布配置变化，而不是业务逻辑重写。

平台应该抽象什么，不抽象什么

平台应该抽象：

• prepare、start、keepAlive、release 等主生命周期
• 统一的 Run、Attempt、Session、Artifact、Trace 语义
• 统一的错误、重试、超时和取消语义

平台不需要抽象到看不出环境差异。不同环境的能力差异仍然应该通过 capability 暴露出来，例如：

• 是否支持长会话
• 是否支持文件系统快照
• 是否支持进程级健康检查
• 是否支持浏览器或 GUI 自动化

RunSpace、Session、RuntimeConnection 怎么分工

这三个词如果不拆开，规范很容易重新混成一团：

• RunSpace
  • 真正承载执行的 provider 侧运行空间，例如 workspace、隔离实例、函数调用空间或 worker 槽位。
• Session
  • 平台对某个 RunSpace 的租约对象，负责表达占用、续期、复用和释放。
• RuntimeConnection
  • runtime attach 到平台时建立的连接上下文，负责 heartbeat、recover、KV、config、secret 和输出桥接。

可以把它们理解成：

• RunSpace 回答“代码实际跑在哪”
• Session 回答“当前是谁在合法占用这个运行空间”
• RuntimeConnection 回答“当前这次 runtime 是通过哪条连接在和平台通信”

在最简单的 Sandbox 场景下，常见链路是：

1. provider 先准备一个 RunSpace
2. 平台创建绑定该空间的 Session
3. runtime 再通过 RuntimeConnection attach 上来开始执行

在 faas 或 worker 里，这三者也依然存在，只是 Session 和 Connection 的生命周期更短。

与规范的关系

规范的重点是统一语义，而不是抹平现实差异。相关文档：

• Provider Lifecycle
• RunSpace
• Run
• Runtime SDK
• Session