企业官网建设流程全解析

1. 为什么要在腾讯云 CVM 上折腾 CubeSandbox

如果你正在做 AI Agent 调试、并行实验，或者需要给团队提供一套可复现的沙箱环境，大概率会遇到一个很现实的问题：环境跑起来容易，但想把它“定格”下来、复制一份、或者搞砸了再退回去，就特别麻烦。普通容器只能保存文件系统，进程状态、内存里的东西、对话上下文这些统统留不住。CubeSandbox 解决的正是这件事——它把整个实例状态做成可以保存、复制、恢复的对象，快照、克隆、回滚三条链路走通之后，你手里的沙箱才真正变成一个可管理的开发工具。

这篇记录聚焦在腾讯云 CVM 上从零部署 CubeSandbox，然后完整走一遍快照创建、环境克隆和版本回滚。操作系统用的是 OpenCloudOS 9，现场算力由沐曦提供，CVM 和 API Key 都是统一发放的，所以整个过程可以直接从服务器登录开始。我会把每一步的命令、配置骨架和验证方法都写清楚，确保你照着做能复现出来。适合需要可复现沙箱环境的开发者，尤其是做 Agent 行为调试和多分支实验的同学。

2. 前置准备：CVM 初始化与 TaoToken 接入

在正式装 CubeSandbox 之前，有两件事得先理清楚。第一是 CVM 本身的环境，第二是模型服务的接入方式。CubeSandbox 的数字助手需要调用 LLM，这里我用 TaoToken 来做模型接入，它的 OpenAI 兼容接口配置起来比较直接，适合在沙箱环境里快速验证。

TaoToken 是一个模型接入服务，提供 OpenAI 兼容的 API 端点，你可以把它理解成一个统一的模型调用入口。对于 CubeSandbox 这种需要频繁创建、克隆、回滚实例的场景，模型服务的配置最好独立于沙箱状态之外，这样回滚的时候不会把密钥配置也一起滚没了。TaoToken 的 API 地址是https://taotoken.net/api，在数字助手的模型配置里填 OpenAI Compatible 类型即可。

CVM 这边，我拿到的是 OpenCloudOS 9 的实例，SSH 端口是 9888。登录命令如下：

ssh root@<服务器ip> -p 9888

连上去之后，先确认一下系统版本和内核情况：

cat /etc/os-release uname -r

预期能看到 OpenCloudOS 9 的标识。这一步看起来简单，但后面装 PVM 内核的时候，版本对不上会直接导致沙箱起不来，所以先确认清楚。

3. 宿主机环境：PVM 内核安装与切换

CubeSandbox 不是装完就能跑的，它依赖 PVM（Protected Virtual Machine）相关内核能力。所以第一步是先把宿主机的内核换掉。

安装指定版本的内核包：

dnf install -y kernel-6.6.69-1.1.cubesandbox.oc9

这一步可以理解成先把运行虚拟化沙箱所需要的底层能力补齐。装完之后，把它切成默认启动项：

grubby --set-default /boot/vmlinuz-6.6.69-1.1.cubesandbox.oc9.x86_64

如果命令执行成功，一般会看到The default is ...这一类回显，这不是报错，是 grubby 在告诉你默认项已经设好了。

接着配置 PVM 所需的启动参数：

curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/pvm/grub/host_grub_config.sh | bash

做完这一步之后直接重启：

reboot

重启回来之后，先别急着往下走，确认宿主机是不是已经切到了正确的内核：

uname -r

预期看到6.6.69-1.1.cubesandbox.oc9.x86_64。只要输出里能看到cubesandbox.oc9，这一步基本就算对了。

然后加载 KVM 模块：

modprobe kvm_pvm lsmod | grep kvm_pvm

确认加载成功之后，把它写到开机自动加载配置里，免得下次重启又得手动来一遍：

echo 'kvm_pvm' > /etc/modules-load.d/kvm-pvm.conf

到这里，宿主机层面的准备就差不多了。我踩过的坑是：有一次忘了写 modules-load 配置，重启之后 kvm_pvm 没自动加载，沙箱创建一直卡在 pending，排查了半天才发现是模块没起来。

4. 安装 CubeSandbox 与模板验证

宿主机环境准备好之后，开始安装 CubeSandbox 本体。执行一键安装脚本：

curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | CUBE_PVM_ENABLE=1 MIRROR=cn bash

脚本跑完之后，主体服务就已经装上了。但我不建议只看安装脚本有没有报错就认为搞定了，更靠谱的方式是直接跑一次模板创建，用实际结果来验证。

cubemastercli tpl create-from-image \ --image cube-sandbox-cn.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \ --writable-layer-size 1G \ --expose-port 49999 \ --expose-port 49983 \ --probe 49999

跑完之后查看模板列表：

cubemastercli tpl list

如果模板状态是READY，那我才认为这套环境真的能用了。这一步的验证逻辑很重要，因为后面快照、克隆、回滚都依赖模板和实例的正常工作，如果模板本身有问题，后面全是白搭。

5. WebUI 登录与数字助手配置

CubeSandbox 装好之后，WebUI 的访问地址是：

http://<机器ip>:12088

默认账号admin，默认密码admin。登录进去之后，首页可以看到当前的沙箱实例和模板信息。

接下来配置数字助手的模型服务。进入数字助手页面，填 LLM 接入参数：

保存之后，密钥会由 CubeEgress 托管，沙箱内部拿不到真实 Key。这点对开发环境来说很关键，因为你在做克隆和回滚的时候，不会因为密钥泄露或者配置丢失导致整个链路断掉。

配置完成后，关闭弹窗，点击“去应用市场”，选择 OpenClaw 镜像安装到数字助手。等模板制作完成，会弹出实例创建窗口。这里给实例起个名字，同时把“状态管理模式”设置成完整快照型。继续创建，等待几秒，数字助手就能初始化完成。

6. 快照、克隆、回滚三条链路的实操验证

6.1 快照：把实例状态定格下来

进入 OpenClaw 之后，先在底部模型选择器里选好模型，然后发一条简单命令，看看它能不能正常操作文件：

往“/root/a.txt”写入“测试消息111”。然后 cat 一下文件给我。

如果这一步返回正常，说明当前对话实例已经具备可操作的工作环境。确认/root/a.txt已经写进去之后，回到 CubeSandbox 的实例卡片，点击“管理”，进入“状态管理”，然后点击“创建存档”。

这一刻我比较直观地理解了快照这个功能的意义：不是只保存一个文件，而是把这个实例当前的整个状态定格下来。对话历史、文件系统、运行状态，全部打包成一个可以回退的存档点。

6.2 克隆：从已有实例创建分身

有了快照之后，接着做“创建分身”。在“状态管理”页面点击“创建分身”，等它创建完成，首页会多出一个新的分身卡片。然后进入分身的“Gateway 管理”页面。

一进去就能看到，历史对话和原始实例是同步的，这说明它的起点状态是一致的。为了验证后续是否隔离，在分身里执行：

往“/root/b.txt”写入“我是分身”。然后 cat 一下文件给我。

然后再回到原始实例里输入：

帮我看看 /root/b.txt 这个文件内容。

原始实例里看不到/root/b.txt，这就说明虽然分身是从原实例复制出来的，但从分叉之后开始，两边已经互不影响了。这个能力在做多分支实验的时候特别有用，你可以从一个已知状态出发，同时跑好几条不同的路径，互不干扰。

6.3 回滚：回到快照时刻

最后验证回滚，因为这个能力最像开发者日常会遇到的真实场景。先在原始实例里主动制造一次破坏：

帮我删除 /root/a.txt

然后确认：

看看 /root/a.txt 还在不在？

确认文件确实已经没了。接着回到 CubeSandbox 控制台，进入原始实例的“状态管理”页面，选中之前创建的存档，点击右侧“回档”。这个动作很快，基本是立即生效。

重新进入原始实例的“Gateway 管理”页面后，可以看到对话历史已经退回到了打快照的时间点，刚才删除/root/a.txt的记录也不见了。最后再发一句：

帮我看看这个文件 /root/a.txt 在不在？

这时文件已经恢复了，说明整个环境状态确实被还原回去了。

7. 本篇常见错排查

问题一：OpenClaw 点击后不立即跳转。实例创建完之后，点击 OpenClaw 有时候页面不会马上进去。这个时候不用先判断成服务异常，我这边实际试下来，很多时候只是第一次点击没反应。直接手动再点进去，一般就能正常打开。

问题二：sk 密钥需要重新配置。OpenClaw 偶尔会出现需要重新配置 sk 密钥的情况。处理方式是重新回到数字助手的模型配置弹窗，把 Key 再配置一遍，然后重新进入 OpenClaw。如果你已经确认镜像和实例都正常，但对话侧还是不工作，优先检查一次密钥配置是不是丢了或者没带上。

问题三：模板状态一直不是 READY。如果cubemastercli tpl list里模板状态长时间不是 READY，先检查 kvm_pvm 模块有没有加载，再确认内核版本是不是cubesandbox.oc9。这两个条件缺一个，模板都起不来。

问题四：回滚后对话历史没变。回档操作是在“状态管理”页面选中存档后点击“回档”，如果发现对话历史没变化，确认一下是不是选错了实例卡片。分身和原始实例的状态管理是独立的，别在分身里点了回档然后去原始实例里看结果。

8. 接入方式与后续操作

模型接入这块，如果你还没创建 API Key，可以直接到 TaoToken 控制台生成：

• 模型对话入口：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model_chat
• API Keys 管理：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api_keys
• 接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc

如果你打算长期在 CubeSandbox 里跑 Agent 调试或者多分支实验，建议看一下 Coding Plan，它更适合这种需要持续调用模型、频繁创建和回滚实例的场景：

• Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding_plan

整个流程走下来，我的感受是：宿主机准备虽然步骤不多，但每一步的作用和预期结果最好都确认清楚，尤其是内核切换和 KVM 模块加载这两步，出问题的时候报错信息不一定直观。快照、克隆、回滚这三件事放在一起之后，CubeSandbox 才开始真正体现出它的开发工具属性。尤其是在调试 Agent 行为、复现实验结果、做多分支尝试的时候，这种状态管理能力会比单纯启动一个环境实用得多。