很多人在第一次接触 Daytona 时都会有一个疑问：

Daytona 不就是 Docker + VS Code Remote 吗？为什么 AI Agent 还需要它？

实际上，Daytona 的定位不是容器，而是 Development Environment（开发环境）管理平台。如果说 E2B 提供的是一次性的代码执行沙箱，那么 Daytona 提供的是可长期存在、可持续开发、可恢复状态的 Workspace（工作空间）。

下面我结合几个真实的 AI Agent 场景来说明。

---

一个真实案例：AI Coding Agent 修复 GitHub Bug

假设我们要开发一个类似 OpenAI Codex、Cursor Agent、Devin 的 AI 编程 Agent。

用户说：

帮我修复 GitHub 上的 Issue #123，并提交 PR。

整个 Agent 的执行流程如下：

                用户
                  │
                  ▼
          AI Coding Agent
                  │
          读取 GitHub Issue
                  │
                  ▼
          创建 Daytona Workspace
                  │
                  ▼
          Clone GitHub Repository
                  │
                  ▼
           安装项目依赖
                  │
                  ▼
             运行 pytest
                  │
                  ▼
            LLM 修改代码
                  │
                  ▼
            再次运行 pytest
                  │
                  ▼
          所有测试通过
                  │
                  ▼
          Git Commit + Push + PR

这里最关键的一步就是：

创建 Daytona Workspace。

---

第一步：创建 Workspace

假设 Agent 收到一个新的任务。

Agent 不会直接：

git clone repo

而是先创建：

Workspace：

bug-fix-issue-123

例如（伪代码）：

workspace = daytona.create(
    name="issue-123",
    image="python:3.12"
)

Daytona 会创建：

Workspace
│
├── Ubuntu
├── Python 3.12
├── Git
├── pip
├── Node.js
└── VS Code Server

可以理解成：

给 Agent 分配了一台全新的开发电脑。

---

第二步：Clone GitHub

Agent：

进入 Workspace：

git clone https://github.com/company/project.git

注意：

这里：

Git Repository：

属于：

Workspace。

不是：

你的服务器。

---

第三步：安装依赖

Agent：

发现：

项目：

需要：

requirements.txt

于是：

pip install -r requirements.txt

安装：

所有依赖。

之后：

Workspace：

变成：

Workspace

├── Git Repo

├── Python

├── pandas

├── numpy

├── pytest

└── venv

这些：

都会保留下来。

---

第四步：运行测试

Agent：

执行：

pytest

结果：

23 passed

2 failed

LLM：

读取：

失败信息。

开始：

修改代码。

---

第五步：修改代码

例如：

LLM：

生成：

def add(a, b):
    return a + b

Agent：

直接：

修改：

Workspace：

里的：

源代码。

不是：

重新生成：

整个项目。

---

第六步：再次测试

继续：

pytest

结果：

25 passed

0 failed

成功。

---

第七步：提交 Git

Agent：

继续：

git commit

git push

然后：

创建：

PR。

整个过程中：

Workspace：

一直存在。

---

为什么不用 E2B？

很多人都会问：

不是有 E2B 吗？

最大的区别就在于：

生命周期（Lifecycle）。

E2B：

适合：

运行一次 Python

↓

结束

↓

删除

例如：

数据分析。

画图。

OCR。

PDF。

---

Daytona：

适合：

开发

↓

修改

↓

测试

↓

继续开发

↓

保存状态

↓

第二天继续

例如：

软件开发。

---

一个更真实的例子

假设：

一个 Bug。

需要：

三天。

第一天：

Agent：

已经：

Clone Repo

↓

安装依赖

↓

跑测试

↓

修改一半

第二天：

Agent：

继续。

如果：

E2B。

昨天：

Sandbox：

已经：

删了。

全部：

重新开始。

但是：

Daytona：

Workspace：

一直存在。

今天：

继续：

Workspace

↓

Git

↓

继续开发

像：

程序员：

昨天：

关电脑。

今天：

继续。

---

AI 产品经理 Agent

再来看一个办公场景。

用户：

帮我分析这个项目，并生成 API 文档。

Agent：

创建：

Workspace：

project-doc

然后：

Clone Repo

↓

Python

↓

读取代码

↓

生成 UML

↓

生成 Markdown

↓

保存文档

第二天：

用户：

再补充数据库设计。

Agent：

继续：

昨天：

Workspace。

所有：

文件：

都在。

---

Daytona 为什么叫 Workspace？

因为：

它不是：

一次：

执行。

而是：

持续：

开发。

例如：

Workspace：

workspace-001

├── project
├── README.md
├── docs
├── src
├── .venv
├── node_modules
└── git

就像：

你的：

Mac。

或者：

VS Code。

---

Daytona 与 Docker 的关系

很多人：

第一次：

都会说：

这不就是 Docker？

其实：

底层：

可能：

使用：

Docker。

但是：

Daytona：

提供：

更高层：

能力。

例如：

Docker：

docker run

之后：

很多：

事情：

自己：

做。

例如：

• Git
• SSH
• VS Code
• 生命周期
• Workspace

而：

Daytona：

全部：

封装。

---

Daytona 与 Browserbase

Browserbase：

负责：

浏览器。

例如：

Chrome

↓

网页

↓

点击

Daytona：

负责：

开发环境。

例如：

Git

Python

VS Code

Node

Shell

---

Daytona 与 Composio

Composio：

负责：

工具。

例如：

GitHub API

Slack

Notion

Daytona：

负责：

开发。

例如：

Clone Repo

↓

修改代码

↓

运行测试

例如：

用户：

修 GitHub Bug。

流程：

GitHub
   ▲
Composio
   │
Agent
   │
Daytona Workspace
   │
Git
pytest
Python

---

Daytona 与 E2B

这是最容易混淆的一组。

假设：

用户：

帮我画一个销售图。

Agent：

Python

↓

E2B

↓

PNG

↓

结束

E2B：

一分钟。

结束。

---

另一种：

用户：

帮我开发一个 Flask 网站。

Agent：

Clone

↓

开发

↓

Debug

↓

运行

↓

修改

↓

Git

↓

继续开发

这就是：

Daytona。

---

一个企业级案例：开发 AI Agent 项目

假设你正在负责一个核电施工方案生成与审核大模型项目。

团队每天都在开发新的 Agent 能力，例如：

• 文档解析
• RAG 检索
• 施工规范审核
• 前端展示

如果每位开发者、每个 Agent 都手动配置 Python、Java、Node.js、数据库环境，成本会非常高。

这时可以用 Daytona 为每个任务创建独立 Workspace：

Workspace：doc-parser
├── Python 3.12
├── OCR 环境
├── python-docx
└── 测试数据

Workspace：rag-engine
├── Milvus Client
├── Embedding Model
└── 检索脚本

Workspace：frontend
├── Node.js
├── React
└── Vite

当 Agent 接到"修复文档解析 Bug"的任务时，只需要进入 doc-parser Workspace，就能立即开始工作；当接到"优化 RAG 检索"任务时，则进入 rag-engine Workspace。不同任务之间互不影响，环境也无需重复搭建。

---

总结：一句话理解 Daytona

很多人会把 E2B、Daytona、Browserbase 混在一起，其实它们分别对应三种完全不同的运行环境：

平台	类比	生命周期	最适合的任务
E2B	一次性实验室	分钟级	执行 Python、数据分析、文件处理
Browserbase	云浏览器	会话级	登录网站、网页自动化、下载上传
Daytona	云开发电脑	天/周级	AI Coding、调试、持续开发、项目维护

因此，Daytona 的核心价值不是"执行代码"，而是"维护一个长期存在、可恢复、可持续迭代的开发环境"。

对于现代 AI Coding Agent（如 Codex、Cursor Agent、Devin 等）来说，它就像给每个 Agent 分配了一台专属的开发电脑：Agent 可以在里面克隆代码、安装依赖、修改文件、运行测试、保留开发状态，并在下一次任务中继续使用，而不必每次都从零开始。