Agent Pool + Cube 沙箱：架构方案

2026-10-30。dsh（大脑）从沙箱里挪出来，常驻在一个 Agent Pool 里；只有需要执行工具时，才给会话绑定一台 CubeSandbox（手）。本文先 review 现方案，再给目标架构、要验证的点，以及需要你在腾讯云上准备的 Cube 配置。
标 估算 的是推算；标 待验证 的是方案依赖、但还没实测的假设。

结论

1. 现方案 review

现状（方案 A）：每个会话一个 Docker 容器，dsh 跑在容器里，网关通过 envd 持有 dsh 的 stdio。休眠时先 session/close，再杀 dsh，最后 docker stop；唤醒时 docker start，重启 dsh，再 session/resume。

现方案做对了、要保留的：

• 事件流（seq + SSE + Last-Event-ID）是唯一的渲染源，网关自己是 ACP 客户端；
• 会话按设备隔离，他人会话一律 404；
• 文件访问严格限制在 workspace 内；
• App 侧 API。

这些在新方案里都不变。

2. 目标架构

实线是每轮都走的路径，虚线是按需或后台的路径。蓝线是新增的关键路径：每次工具调用都从 Pool 打到沙箱里的 envd。

3. 关键：dsh 的执行世界

3.1 dsh 0.2.1 的接口（README 原文，从运行镜像里读取）

dsh-subprocess 的 README 原文：“每个组合配置一个 subprocess 实现，并根据命令运行位置选择本地或远程执行。”dsh-terminal-bash 也写明“同一个后端既可以与本地执行世界组合，也可以与远程执行世界组合”。所以只要替换这几个实现，工具层不用改。

另外，dsh-e2b 的 README 列出了留在宿主（也就是 Pool）里的东西：Cordis 服务、agent 和会话状态、会话日志、模型请求、skill。这正是我们要的切分。

3.2 为什么不能直接用 dsh-e2b

Cube 兼容 E2B 协议，按理把 dsh-e2b + dsh-fs-e2b + dsh-subprocess-e2b 指向 Cube 就行。但是：

• 版本落后：最新只有 0.1.5-rc.3（2026-09-22），依赖 cordis 4.0.2；dsh 已经是 0.2.1-rc.5，依赖 cordis ~4.0.5。能不能装进 0.2.1 未知 待验证。
• 生命周期不对：插件加载时就建沙箱，dispose 时删沙箱，超时也是删除（onTimeout: 'kill'）。我们需要懒创建、按会话持久、暂停而不是删除、Pool 重启后能重连到原沙箱。
• README 自己写的“不在范围内”：重新连接、暂停保留、模板、卷、快照、网络策略、工作区同步。

所以我们写一个自己的执行插件 cloudsandbox-exec-cube（名字暂定）：

• 对上实现 dsh 0.2.1 的 ctx.fs、ctx.subprocess、ctx.shell；
• 对下用 E2B JS SDK 或直接调 envd 的 Connect-RPC；
• 沙箱句柄从 Broker 懒获取，允许过期后重新获取；
• 适配层逻辑尽量照搬 dsh-fs-e2b / dsh-subprocess-e2b，比如 bash -l -c 的引号转义、随机 HOME。

如果 DeepSeek 后续发布了支持外部生命周期的 0.2.x e2b 系列，就换回官方实现。这件事值得去问 dsh 团队，handoff 里已经列为待确认项。

3.3 一个会话占一个 dsh 进程

dsh 的执行世界是进程级的：一个组合里只有一个 ctx.fs 和一个 ctx.subprocess，dsh-e2b 也写明“一个沙箱，一个句柄”。如果一个 dsh 进程同时服务多个会话，它们会共用同一个沙箱，这就违反了按设备隔离。所以：

• 一个活跃会话对应一个 dsh 进程。现在单个容器里的 dsh 占用约 170–415 MiB（含工具进程），只算 dsh 本身会更少 估算。
• 预热池：提前启动 N 个 dsh 进程，完成 initialize，但还没有会话、没有绑定沙箱。会话来了就分配一个，发 session/new 或 session/resume。dsh 启动的 2 秒就从关键路径上去掉了，只剩 resume 的约 60 ms（实测）。
• 插件怎么知道自己属于哪个会话：worker 启动时带一个 worker id 和一个一次性 token。插件第一次被调用时，拿它们去问 Broker “我该绑哪台沙箱”。Broker 根据“worker 分给了哪个会话”回答。会话 id 由网关决定，不由插件声明。
• 回收：会话空闲 T1（比如 10 分钟）后，session/close 再退出这个进程，把名额还给池子。这一步不影响沙箱，沙箱有自己的暂停策略。

4. 生命周期与状态

4.1 两条独立的生命周期

好处是两边各省各的：只聊天的会话只占大脑；用户离开了，大脑先释放，手稍后暂停，都不需要对方配合。

4.2 恢复失败的兜底

AGS 上实测恢复 100/100（cube-restore-report.html §9），本机实验环境则只有 8/18（§6）。生产形态没问题，但这只是 100 次样本，Broker 仍然要有退路：

1. 重试：恢复失败后，等沙箱状态回到 paused 再重试，最多 N 次（实测有的在第 4 次才成功）。
2. 冷重建：从最近一次轮末归档新建沙箱，还原 workspace，并在工具结果里告诉模型“远程电脑已重建，之前的进程和终端状态已丢失”。
3. 身份校验：每次绑定或恢复后，先读出沙箱里的一个随机 nonce，与 Broker 记录的比对，不一致就拒绝使用（对应报告 §6.2 观察到的错误路由）。

dsh 在 Pool 里，所以沙箱出问题只会表现为某次工具调用失败，对话本身不会断。这正是 WorkBuddy 从 SANDBOX 迁到 LAMP 的理由（见 docs/research/mobile-cloud-computer.md §1.2）。

4.3 状态放在哪

App 的文件 API 改成通过 envd 访问沙箱，沙箱暂停时会触发恢复。沙箱已归档时直接读 COS 上的归档，不用为看个文件把沙箱拉起来。

5. 一轮对话怎么走

App  POST /prompt ─► Gateway
Gateway: 会话没有 worker → 从预热池取一个 → session/resume（约 60 ms）
Gateway ─ session/prompt ─► dsh（Pool）
dsh ─► 模型：思考、回复文字                  （不碰沙箱）
dsh: 要执行 bash / read / grep
  cube 插件 ─► Broker：申请沙箱
     Broker：无 → create   已暂停 → connect（恢复）   运行中 → 直接用
     Broker：nonce 校验 ─► 返回 envd 地址和访问令牌
  cube 插件 ─► envd：执行；结果返回给 dsh
dsh ─► session/update 事件 ─► Gateway ─► SSE ─► App   （与现在相同）
dsh: 需要审批 → Gateway 挂起请求；Broker 可以让沙箱先暂停
turn_end → Broker：增量归档 workspace；空闲 T2 后暂停沙箱

6. 安全

• 模型 key 不进沙箱。沙箱里只有模型生成的命令，没有我们的任何凭据。
• 沙箱出网：AGS 没有按域名的出站白名单，只有 PUBLIC（可出公网）/ VPC（安全组按 IP 控制，出公网需 NAT）/ SANDBOX（断网）三种（docs/research/ags-custom-image.md §7）。第一期用 PUBLIC：沙箱里已经没有我们的凭据，主要风险是被当作出网跳板。之后需要的话，改成 VPC + NAT + 我们自己的出站代理。
• envd 入口：开启每沙箱访问令牌（allow_public_traffic=false），只有 Broker 知道令牌，再下发给对应的 worker。
• Pool 与 Broker 之间：worker 的一次性 token 只能换到它被分配会话的沙箱。插件运行在 dsh 进程里，但模型生成的代码不在 Pool 执行，所以拿不到这个 token。前提是 Pool 里不加载任何本地执行的 provider，这一点要在组合配置里锁死，并写测试。
• 身份校验：见 §4.2，防错误路由。
• 保持不变：他人会话 404、App 文件 API 限制在 workspace 内（换成 envd 后，路径校验在网关侧做，同样要防符号链接逃逸 待验证）。

7. 时延与成本

7.1 每次工具调用的往返

AGS 实测（2026-10-30，从服务器 9.135.181.73 到广州 AGS，HTTPS 长连接，各 50 次）：

达到验收线（p50 ≤ 30 ms、p95 ≤ 100 ms，命令 p50 25 ms）。一轮 30 次工具调用多出约 1 秒。Pool 直接放在现在的服务器上即可。

下面是更早的本机实验环境数据，仅作对照：

环境：Mac → Lima 虚拟机 → KVM 嵌套，CubeProxy 是 amd64 镜像，在 arm64 上用 qemu 模拟，每次调用都是 TLS。所以这些是悲观上限。绕过代理直连 envd 的对照组没测成，实验集群开始拒绝新建沙箱（408）。

估算 一轮 30 次工具调用，每次平均 150 ms，多出约 4.5 秒；模型首字本身要 8–21 秒（handoff §7），这个量级可以接受。如果同可用区 x86 上每次在 10–30 ms，就只多 1 秒左右。验收线建议：同可用区 envd 命令 p50 ≤ 30 ms、p95 ≤ 100 ms。

可以降低往返的手段：

• Pool 与 Cube 放在同一可用区；
• 保持 HTTP/2 长连接，不要每次都握手 TLS；
• dsh 的工具单次调用本来就是一个 envd 请求，不需要额外合并。

7.2 资源与成本 估算

8. 对现有代码的影响 估算

9. 开工前要验证的点（spike）

按风险排序。S1 到 S3 任何一条不成立，方案就要调整。

9.1 S1 结果（2026-10-30，AGS，经 E2B 协议）

做法：dsh 0.2.1 + 官方 dsh-fs-e2b / dsh-subprocess-e2b 0.1.5-rc.3 + 我们写的 cube-runtime（替换 dsh-e2b 管生命周期）。用一个按脚本发工具调用的假模型驱动（当天模型 relay 故障，而且脚本更可重复），在服务器上跑。细节和复现：poc/dsh-e2b-s1/README.md。

为什么慢（用 SDK 层追踪定位）：

1. dsh-fs-e2b 每解析一次路径就在沙箱里起一个进程跑 realpath … | base64，再 getInfo 一次，没有缓存。光 /workspace 就解析了 55 次。
2. 每次请求模型前，系统提示词相关插件都要探测 /workspace/.git、/.git、AGENTS.md 等，每步约 17 次。其中 $DSH_HOME/AGENTS.md、~/.agents/AGENTS.md 本该读宿主上的配置，现在也被送去了沙箱：ctx.fs 是全局的，换成远程后所有读文件的插件都跟着变远程。
3. 命令结束靠读沙箱里的 exit-code 文件轮询（pollMs 默认 20 ms）。

结论：dsh 的执行世界接口确实能把工具整体搬进 AGS，方向成立；但官方 e2b 适配器只是 POC 质量，不能直接上线。下一步写我们自己的 ctx.fs / ctx.subprocess：

• 路径解析用 envd 的 Stat，不起进程，并按轮缓存；
• 宿主配置路径（DSH_HOME、~/.agents）走本地，只有工作区走远程；
• 进程结束靠 envd 的进程事件流，不轮询文件。

目标是每次工具调用 1–3 次往返，也就是 50–100 ms。

9.2 优化后（2026-10-30）

按上面三条原因，把两个官方适配器 fork 成我们自己的 cloudsandbox-dsh-fs-cube、cloudsandbox-dsh-subprocess-cube（MIT，改动集中、可 diff），cube-runtime 负责记录沙箱里命令的启停。同一组 12 步脚本，在服务器上：

“模型每步思考 3 s”用假模型的响应延迟模拟。它验证缓存不依赖时间窗口：真实模型的两次工具调用之间隔着好几秒，靠 TTL 的缓存会全部过期。

做了什么：

• 路径解析不再起进程：用 envd 的 Stat，路径不是符号链接时，规范路径 = 父目录的规范路径 + 名字；符号链接才退回 realpath 进程。
• stat 和规范路径按“代”缓存：沙箱里有 agent 自己的命令（以 background 方式启动的那条）开始或结束时换代；只有命令还在跑时才加 2 s TTL。换代时把上一代查过的路径并行重查一遍，模型请求前那一串顺序探测（AGENTS.md、.git、skills 目录）就都能命中。
• 宿主配置路径不进沙箱：hostPaths（$DSH_HOME、~/.agents）直接按“不存在”处理。
• 写文件：从 9 次往返降到 4 次（写临时文件 → 一条命令 chmod 加发布 → stat）。只清掉被写的路径的缓存。
• 跑命令：沙箱登录环境每个沙箱只读一次；状态目录不再单独建、两次 chmod 并进包装脚本。进程组跟踪、kill、输出编码不变。

正确性：

• 符号链接用例全部正确：经由链接读、编辑、写，都落到真实文件。
• 版本防护正确：读完文件后，被 bash 改掉、或者被后台任务改掉，再编辑都会被拒绝（file changed since it was read）；重新读能拿到新内容。

还能再快的地方：bash 一步还有约 6 次往返（写状态文件、启动、读状态、清理、ps 查进程组），可以把清理和进程组检查放到后台。离 50–100 ms 的目标还差一点，但已经不影响体验：一轮 30 次工具调用多出约 5 秒，模型本身要几十秒。

9.3 真模型端到端（2026-10-30）

模型换成 DeepSeek 官方 API（deepseek-flash，OpenAI 兼容），任务是：在 /workspace/calc 下写一个 Python 小包（add / mul / safe_div），用 pytest 写测试并跑通，最后用 grep 确认 safe_div 里有 ValueError。工具全部在 AGS 沙箱里执行。

途中发现的问题：第一版跑同一个任务要 157–394 秒，瓶颈是沙箱从公网 PyPI 装 pytest 只有 15–20 KB/s（1.3 MB 要两分多钟），而且 Debian 的 Python 是 externally-managed，直接 pip install 会被拒。镜像里加上腾讯云 pip / npm 镜像、预装 pytest、允许系统级 pip 安装后，同一任务降到 25 秒。这说明沙箱镜像该预装常用工具，而不是让模型现场装。

途中发现并解决的问题（都已写进代码或镜像）：

10. 腾讯云 Cube 配置清单（请你准备）

10.1 先定形态

已定：AGS 配置全部经云 API 完成，资源清单见 poc/ags-lab/README.md。Broker 的接口两种都能接，选哪个你定。我倾向 AGS：免运维，能更快拿到 x86 上的真实数据。

10.2 需要配置的项

10.3 配好后请给我

• 控制面 API 地址，以及凭据的获取方式（SecretId/Key 放在哪、什么权限）。不要发在聊天里，像现在一样写进本地的 gitignored 文件。
• 数据面（envd）的访问方式：域名格式，是否需要私有 CA。
• 模板 ID，或者告诉我镜像仓库地址，我来推镜像、建模板。
• 配额数字，以及 Pool 机器（是否新申请；能否复用现在的 9.135.181.73，它和 Cube 不在同一可用区的话时延会变差）。

11. 分期 估算

P1 没有改动 :8080：工具沙箱模式是第二个网关实例 :8081（同一个二进制和镜像，GATEWAY_HANDS_TOOL 打开）。