（万字长文拆解云沙箱）让 Agent 从执行代码升级到拥有一个临时Runtime

超级东哥CyberFD
0 阅读16分钟

最近在做 AI Agent 相关的东西时，我越来越频繁地遇到一个问题：

如果 Agent 可以执行 Shell、安装依赖、修改文件、运行测试，甚至启动一个 Web 服务，那么这些操作到底应该在哪里执行？

最简单的答案可能是：

给它一台服务器。

但真正做起来以后，你会发现，这可能是一个比较危险的操作。

因为今天的 Agent，已经和几年前的 Chatbot 完全不是一回事了。

以前的 AI，大部分时候是在：

在这里插入图片描述

现在一个真正能够完成任务的 Agent，工作流可能已经变成：

在这里插入图片描述

它不再只是“告诉你应该怎么做”。

它开始动手操作了。

于是一个以前没那么重要的问题，突然变得非常重要：

我们到底应该把 Agent 的行动边界放在哪里？

我现在越来越觉得：

Agent 真正需要的，可能不只是一堆 Tool，而是一个真正属于它自己的 Runtime。

这也是我最近重新理解和分析“云沙箱”的原因。

一. 了解云沙箱

1.Agent 最危险的地方，恰恰是它真的能干活

假设你给一个 Coding Agent 这样的任务：

帮我把这个 Python 项目的依赖升级一下，运行测试，如果失败就继续修。

它可能会自主完成：

git clone ...
pip install -r requirements.txt
pip install -U xxx
pytest

发现测试失败以后：

修改 xxx.py
pytest

继续失败：

pip install xxx
pytest

最后甚至可能：

python app.py
curl localhost:8000

从 Agent 的角度看，这是一套非常正常的工作流。

但如果所有命令都直接发生在你的开发机、CI 主机甚至业务服务器上，问题就来了。

它可能修改宿主机文件、安装大量依赖、改变系统配置、启动长期进程、占满 CPU 和内存，甚至读取本来不应该接触的环境变量和网络资源。

更麻烦的是：

Agent 并不知道哪些操作对你的基础设施来说“太危险”。

它看到的只是一个目标。

为了完成目标，它会不断尝试下一步。

所以真正的问题其实不是：

Agent 到底够不够聪明？

而是：

当 Agent 越来越有行动能力以后，我们应该把它放在哪里？

2.第一反应通常是：Docker 不就行了吗？

很多开发者第一次接触 Agent Sandbox 时，都会冒出同一个想法：

不就是隔离环境吗？Docker 不就解决了吗？

这个判断不能说错。

Docker 确实已经提供了很多非常重要的基础能力：

Namespace
Cgroup
Filesystem
Image
Network
Process Isolation

我们完全可以：

docker run ...

然后把 Agent 丢进去执行命令。

问题是：

“启动一个容器”和“提供一个 Agent Runtime”，其实是两件事。

当你真的开始做这套系统，很快会发现容器启动只是第一步。

你还需要处理：

mermaid diagram

如果是多 Agent：

Agent A → Sandbox A
Agent B → Sandbox B
Agent C → Sandbox C
Agent D → Sandbox D
...

事情会继续变复杂。

怎么调度？

怎么限制资源？

怎么避免 Agent 之间互相影响？

沙箱异常以后怎么办？

工作结果怎么保存？

任务中断以后是否需要恢复？

生命周期怎么控制？

忘记销毁的环境怎么自动清理？

这些问题，本质上都是 Agent Runtime 需要回答的。把它们画出来，大概是这样的：

mermaid diagram

所以我现在更倾向于这么理解：

Docker 是构建 Sandbox 的一种底层技术，而 Sandbox 本身是一个 Runtime 问题。

容器解决的是“怎么隔离一个进程”。

Agent Runtime 需要解决的是：

怎么让一个 Agent 安全、持续、可观察地完成一整个任务。

3.云沙箱真正解决的，其实不是“执行代码”

如果你的需求只是：

代码
 ↓
执行
 ↓
返回结果

那它本质上更接近一个 Code Execution API。

比如：

POST /execute

输入一段 Python：

print(sum([1, 2, 3]))

返回：

6

这个模型很简单。

但真正的 Agent 通常不是这么工作的。

它更像：

mermaid diagram

这时候你真正需要的已经不是：

一个执行代码的 API。

而是：

一个可以临时交给 Agent 使用的计算环境。

也就是：

Agent Runtime。

这个方向现在已经非常明显。

阿里云在 2026 年 6 月正式发布 FC Agent Sandbox，官方将它定义为面向 AI Agent、代码执行、命令执行、文件处理和临时服务等场景的云端隔离执行环境。开发者可以创建 Sandbox，在其中运行命令、处理文件、执行代码和启动服务，再按生命周期释放。

腾讯云的 Agent 沙箱服务 AGSX 也明确面向 AI 智能体，并已经把沙箱从纯 Code Execution 扩展到了 Code、Browser、Computer、Mobile 等执行环境。

所以我觉得一个越来越明显的趋势是：

Sandbox 正在从“执行代码的地方”，变成“Agent 工作的地方”。

二. 认识云沙箱

1.一次性任务和会话型任务，其实是两种完全不同的东西

理解 Agent Runtime，我觉得有一个很重要的区分：

一次性任务和会话型任务。

比如：

帮我计算这份 CSV 的平均值。

可能只需要：

创建 Sandbox
    ↓
上传 CSV
    ↓
执行 Python
    ↓
输出结果
    ↓
销毁 Sandbox

整个环境用一次就结束。

它很像一个函数：

input
  ↓
function
  ↓
output

所以我更愿意把它理解成：

一次性 Sandbox = Function。

非常适合：

  • 代码执行
  • 数据分析
  • 文件转换
  • CI 任务
  • 自动化脚本
  • AI 生成代码验证
  • 一次性的 Agent Tool

任务来了，创建环境。

任务结束，环境消失。

这和传统 Serverless 的思路其实非常接近。

2.Coding Agent 完全是另一回事

再看另一个任务：

帮我修复这个 GitHub 项目里的一个 Bug。

Agent 可能需要：

mermaid diagram

这里最大的问题是什么？

状态。

如果每执行一条命令都重新创建一个环境：

Command 1 → Sandbox 1
Command 2 → Sandbox 2
Command 3 → Sandbox 3
Command 4 → Sandbox 4

那么：

刚刚 clone 的项目没了
刚刚安装的依赖没了
刚刚修改的文件没了
刚刚启动的进程也没了

这显然不符合 Agent 的工作方式。

真正合理的模型应该是：

mermaid diagram

也就是说：

Agent 需要的不只是一次执行，而是一段有状态的计算会话。

所以我很喜欢一个简单的类比：

一次性任务像函数，会话型 Sandbox 更像进程。

这是 Agent Runtime 和传统 Code Execution 之间一个非常关键的区别。

3.Workspace 可能比 Command 更重要

进一步想，会发现 Agent 真正工作的对象其实也不是“某一条命令”。

而是：Workspace

例如一个 Coding Agent 真正面对的是：

/workspace
├── package.json
├── src/
├── tests/
├── README.md
└── node_modules/

它真正做的事情是：

mermaid diagram 也就是说：

Command 只是 Agent 操作 Workspace 的手段。

真正需要持续存在的，是 Workspace 本身。

这也是为什么我觉得，一个真正适合 Agent 的 Sandbox，接口模型不应该只围绕：

POST /execute

而应该围绕，这样架构图来设计：

mermaid diagram

这才更接近 Agent 实际完成任务的方式。

4.Agent Runtime 的核心，其实是“状态”

传统 Code Execution 最关心的问题是：

这段代码执行成功了吗？

但 Agent Runtime 还要回答很多别的问题：

  • 当前环境还活着吗？
  • 刚才安装的依赖还在吗？
  • Agent 修改了哪些文件？
  • 有没有进程正在运行？
  • 当前命令执行到哪里了？
  • 这个 Web 服务监听在哪个端口？
  • 还有多少生命周期？
  • 什么时候应该销毁？
  • 任务结束后哪些结果需要保存？

这背后本质上都是同一个关键词： State

所以如果让我把一个 Agent Sandbox 拆开来看，应该是这样：

在这里插入图片描述 隔离只是其中一部分。

真正难的是：

如何在隔离的前提下，让 Agent 拥有一个短暂但完整的计算世界。

5.实时输出也不是“小功能”

还有一个特别容易被低估的能力：

Streaming。

比如 Agent 执行：

npm install

或者：

npm run build

如果整个命令执行十分钟，你显然不会希望十分钟以后才拿到一坨 stdout。

因为对于 Agent 来说，输出本身就是下一次决策的输入。

例如：

mermaid diagram

这意味着 Agent 其实在不断完成：

Action
  ↓
Observation
  ↓
Reasoning
  ↓
Action

所以流式日志并不只是为了“让开发者看起来舒服”。

它本身就是 Agent Runtime 的感知通道。

Agent 不只是需要执行命令，还需要观察命令是怎么执行的。

6.再往前一步：Sandbox 本身也可以变成一个 Tool

这也是 MCP 出现以后，我觉得很有意思的一个变化。

传统方式可能是：

Agent
  ↓
自己维护 Shell
  ↓
自己维护 Docker
  ↓
自己维护容器池
  ↓
自己处理生命周期
  ↓
自己收集日志

而另外一种思路是：

Agent
  ↓
Sandbox Tool
  ↓
Agent Runtime

对于 Agent 来说，它并不需要理解：

  • Docker API
  • Kubernetes Pod
  • 容器调度
  • 宿主机资源

它只需要理解几个高层动作：

  1. 创建一个执行环境
  2. 运行命令
  3. 读取文件
  4. 写入文件
  5. 观察输出
  6. 销毁环境

如果通过 MCP 暴露出来，它甚至可以进一步抽象成 Agent 可以直接选择和调用的 Tool。

于是基础设施复杂度继续往下沉。

我觉得这可能是 MCP 在 Agent 基础设施层一个很有价值的使用方式：

让 Agent 使用的是“能力”，而不是底层基础设施。

三. 云沙箱产品调研

最近实际研究这类方案时，我也看了不少云沙箱产品。

相比一上来搭建完整的 Agent 平台，我反而比较关注一种更轻的方式：

先把 Agent 真正需要的 Runtime 抽出来。

百智云目前把 Cloud Sandbox 定义为 Isolated Agent Runtime，核心思路是给 Agent 提供独立的云端执行环境，并提供 API 与 MCP 两种接入方式。官方场景也主要集中在云端 Agent、多 Agent 平台和开放式 Agent 任务。

这和我前面讲的思路比较一致：

你的 Agent
    │
    ▼
创建 Sandbox
    │
    ▼
操作 Workspace
    │
    ▼
执行 Command
    │
    ▼
观察结果
    │
    ▼
继续工作
    │
    ▼
最终销毁

它不要求开发者首先接受一整套新的 Agent Framework。

你可以继续使用自己的：

  • Claude
  • Codex
  • OpenCode
  • 自研 Agent
  • Agent Framework

然后只把“执行环境”这一层交出去。

这也是我觉得这种产品形态比较有意思的地方。

它解决的问题非常具体：

Agent 到底在哪里干活？

想看具体产品形态的话，可以直接查看百智云 Cloud Sandbox 的产品页。百智云云沙箱｜Agent 云端运行环境

同时百智云云沙箱，也提供了很自然的接口模型：One-shot + Session

如果把前面的两种任务类型落到 API 上，其实模型非常自然。

对于一次性任务：

Agent
  ↓
Create Execution
  ↓
Execute
  ↓
stdout / stderr / workspace
  ↓
自动释放

例如：

POST /openapi/v1/executions/run

任务提交以后直接等待执行结果。

这类接口最适合：

  • 运行一段 Python
  • 处理一个 CSV
  • 执行一个构建脚本
  • 转换一个文件
  • 验证模型生成的代码

另外一个容易被忽略、但非常工程化的设计是：

Idempotency Key。

假设 Agent 发起任务以后：

客户端发送请求
      ↓
服务端成功执行
      ↓
网络中断
      ↓
客户端没收到响应

这时候客户端根本不知道：

“任务失败了”，还是“任务成功了但响应丢了”。

如果直接重试，就可能把任务执行两遍。

所以同一个逻辑任务最好有稳定的：

idempotency_key

网络异常时复用它。

这种能力听起来一点也不像“AI Feature”。

但真正把 Agent 放进生产环境以后，你会发现：

可靠性往往就是由这些看起来很无聊的基础设施细节组成的。

对于长任务，则完全是另一种模型：

POST /openapi/v1/sandboxes

先创建一个 Sandbox。

然后持续在同一个环境里执行：

POST /openapi/v1/sandboxes/:id/commands

整个过程可能是：

mermaid diagram

重点不是 API 长什么样。

而是：这些操作发生在同一个运行环境里

因此：

文件还在
依赖还在
中间结果还在
进程还在
Workspace 还在

直到整个 Agent Task 真正结束。

这正是 Coding Agent、Research Agent 这类长任务最需要的东西。

四. 云沙箱展望

1.正在形成新的 Agent 基础设施分层

以前我们讨论 Agent，通常画出来是：

             Agent
               │
      ┌────────┼────────┐
      ↓        ↓        ↓
    Search   Browser   Tools

但如果 Agent 开始拥有越来越强的执行能力，我觉得未来可能更接近：

                    Agent
                      │
         ┌────────────┼────────────┐
         ↓            ↓            ↓
      Search       Browser      Runtime
                                     │
                                     ▼
                                  Sandbox
                                     │
                      ┌──────────────┼─────────────┐
                      ↓              ↓             ↓
                  Workspace       Commands       Network

Search 解决：

Agent 能不能看到外部世界。

Browser 解决：

Agent 能不能操作网页。

Sandbox 解决：

Agent 能不能安全地真正动手。

而且行业里的产品也已经不再只把 Sandbox 当作代码执行器。

腾讯云 AGSX 已经把执行环境扩展到 Code、Browser、Computer、Mobile 等不同形态；阿里云 FC Agent Sandbox 也把 Commands、Filesystem、Code Interpreter、Network 等能力拆成了明确的 Runtime 对象。

这背后其实是一件很值得关注的事情：

Agent 的“行动能力”正在逐渐基础设施化。

2.哪些 Agent 最需要 Sandbox？

我目前觉得最典型的是四类。

  • 第一类当然是 Coding Agent：
Git Clone
 ↓
Install
 ↓
Code
 ↓
Test
 ↓
Build
 ↓
Run

几乎天然需要一个持续存在的 Workspace。

  • 第二类是 Code Interpreter / Data Agent：
上传 CSV
   ↓
创建 Sandbox
   ↓
Python / Pandas
   ↓
数据分析
   ↓
生成图表
   ↓
导出文件
   ↓
销毁
  • 第三类是 Research Agent。

它在研究过程中可能需要下载文件、编写 Python、清洗数据、跑统计程序、转换格式、生成报告。这些行为完全没必要发生在主业务服务器上。

  • 第四类是 多 Agent 平台。

如果系统同时运行：

Agent A
Agent B
Agent C
Agent D

最自然的架构之一就是：

Agent A → Sandbox A
Agent B → Sandbox B
Agent C → Sandbox C
Agent D → Sandbox D

不同任务拥有自己的 Runtime 和 Workspace。

百智云目前也明确把多 Agent 平台列为 Cloud Sandbox 的适用场景之一，即按 Agent 或任务创建独立环境，并集中获取状态、日志和结果。

3.Agent 时代，我们可能要从“它会什么”转向“它能在哪里做什么”

我觉得这是 Sandbox 背后更值得讨论的一件事。

以前评价一个 AI，我们总喜欢问： 它会什么？

会不会写代码？

会不会搜索？

会不会做数据分析？

会不会操作浏览器？

但随着 Agent 能力增强，接下来可能还有一个同样重要的问题：

它能在哪里做这些事？

这两句话其实完全不同。

如果一个 Agent 只有：

LLM
+
Prompt
+
Tools

它更像一个会调用外部能力的智能系统。

但如果它逐渐拥有：

LLM
+
Tools
+
Memory
+
Workspace
+
Runtime

它就开始拥有一个真正可以持续工作的环境。

这个变化非常关键。

因为 Agent 不再只是：

“生成下一条答案。”

而是在：

维护一个任务状态，并不断作用于外部世界。

4.Server、Function 之后，正在出现第三种计算形态

在这里插入图片描述

以前我们习惯使用服务器：

Server
  ↓
长期存在

后来 Serverless 把很多工作变成：

Request
  ↓
Function
  ↓
Execute
  ↓
Destroy

而 Agent 带来的任务形态有点不一样：

任务开始
   ↓
创建环境
   ↓
Agent 持续工作
   ↓
环境保持状态
   ↓
反复执行和观察
   ↓
任务完成
   ↓
保存结果
   ↓
环境销毁

它既不像一台需要维护几个月甚至几年的服务器。

也不像执行几秒钟就消失的函数。

它更像：

一个跟着任务生命周期存在的临时计算环境。

所以我越来越喜欢一个词：

Session Sandbox。

它介于 Server 和 Function 之间。

对一个 Agent 来说，可能就是：

我的任务还没结束，所以我的电脑还不能关。

5.Sandbox 的安全思路，也和传统“限制能力”不太一样

以前做安全，我们经常想的是：

怎么限制一个程序能做什么？

于是不断禁止：

  • 不能执行 Shell
  • 不能安装依赖
  • 不能访问网络
  • 不能启动进程 = 不能写文件

但这和 Agent 的目标其实天然冲突。

因为如果一个 Coding Agent：

  • 不能执行 Shell
  • 不能安装依赖
  • 不能改文件
  • 不能运行测试

那它也就很难真正完成工作。

所以 Agent 时代可能需要换一个思路。

不是：

Agent 什么都不能做。

而是：

Agent 可以做很多事情，但这些事情只能发生在一个被限制住的环境里。

比如允许它：

  • 执行 Shell
  • 安装依赖
  • 修改文件
  • 运行代码
  • 启动服务
  • 访问指定网络

但前提是：

┌──────────────────────┐
│       Sandbox        │
│                      │
│  Agent 可以自由工作    │
│                      │
└──────────────────────┘
           ↑
        安全边界

换句话说：

我们不一定需要把 Agent 的能力限制得非常小，而可以给它一个足够大的自由空间，然后把“自由空间本身”限制住

我觉得这可能才是 Agent Sandbox 最核心的价值。

五. 总结

所以，现在怎么理解“云沙箱”？

以前我会说：

Sandbox 就是一个安全一点的 Docker。

现在我觉得这个定义太窄了。

对 Agent 来说，更准确的模型应该是这样 在这里插入图片描述 它不是单纯：

给 Agent 一个地方执行代码。

而是：

给 Agent 一个临时存在、可以持续操作、并且有明确边界的计算世界。

它很像一台服务器。

但有一个非常重要的区别：

它不是你的服务器。

它是：

Agent 的服务器。

参考阅读

百智云云沙箱｜Agent 云端运行环境 定位为独立的 Isolated Agent Runtime，支持 API 与 MCP 接入。 查看百智云 Cloud Sandbox

阿里云 FC Agent Sandbox 面向 AI Agent 和代码执行场景的云端隔离运行环境。 查看阿里云 FC Agent Sandbox 文档

腾讯云 Agent 沙箱服务 AGSX 面向 AI 智能体的沙箱执行环境，覆盖 Code、Browser、Computer、Mobile 等形态。 查看腾讯云 AGSX

avatar
文章
阅读
粉丝