Daytona——为Agent提供可长期存在、可持续开发、可恢复状态的 Workspace

很多人在第一次接触 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 可以在里面克隆代码、安装依赖、修改文件、运行测试、保留开发状态，并在下一次任务中继续使用，而不必每次都从零开始。

posted @ 2026-07-03 15:44 stardsd 阅读(6) 评论(0) 收藏举报

刷新页面返回顶部

赏月斋

慎终如始宁静致远

Daytona——为Agent提供可长期存在、可持续开发、可恢复状态的 Workspace

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

第一步：创建 Workspace

第二步：Clone GitHub

第三步：安装依赖

第四步：运行测试

第五步：修改代码

第六步：再次测试

第七步：提交 Git

为什么不用 E2B？

一个更真实的例子

AI 产品经理 Agent

Daytona 为什么叫 Workspace？

Daytona 与 Docker 的关系

Daytona 与 Browserbase

Daytona 与 Composio

Daytona 与 E2B

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

总结：一句话理解 Daytona

公告

赏月斋

慎终如始 宁静致远

Daytona——为Agent提供可长期存在、可持续开发、可恢复状态的 Workspace

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

第一步：创建 Workspace

第二步：Clone GitHub

第三步：安装依赖

第四步：运行测试

第五步：修改代码

第六步：再次测试

第七步：提交 Git

为什么不用 E2B？

一个更真实的例子

AI 产品经理 Agent

Daytona 为什么叫 Workspace？

Daytona 与 Docker 的关系

Daytona 与 Browserbase

Daytona 与 Composio

Daytona 与 E2B

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

总结：一句话理解 Daytona

公告

慎终如始宁静致远