我把免费云主机养成了AI实验室
一台零成本的4核24G云主机，装完Windows后到底能做什么？我让多个AI Agent轮流住进去，试过WSL2和Docker，也经历过登录故障、内存压力与远控接口502。它没有变成万能服务器，却被一步步筛成了一间长期在线、可备份、可救援、还能被另一台云主机控制的AI实验室。
上一篇写完甲骨文ARM64安装Windows，评论区问得最多的是：装完以后，它到底能干什么？
我的答案不是“远程办公”，也不是“挂个网页”。
我把AI装了进去。
回头看，这台机器更像一间不断换住客的房子。ClawX是第一个入口，贝贝第一次让它拥有连续记录；WSL2留下一个打不开的图标；OpenHuman因为登录故障和内存压力离开；WorkBuddy没有成为主力，却靠每天稳定产生积分留到了现在。再后来，雪从另一片云伸进一只手，接管了它的Windows命令行。
真正留下来的，不一定最强。
但一定有明确职责。
最开始装的是 ClawX。
它是第三方改造的Windows版OpenClaw。选择它的原因很直接：Windows上有现成入口，不必先和命令行、依赖和环境变量硬碰硬。
能跑起来后，我反而不满足了。
我想知道原生OpenClaw到底是什么体验，于是卸下这层第三方包装，改成命令行安装原生版。贝贝也从一个能聊天的程序，慢慢变成这台机器的常驻管理者。
她给自己建了飞书Wiki，维护备份看板和技能清单。旧记录里能看到两次早期全量备份：一份20.4MB，一份71.6MB；后续策略是保留最近5份，再同步到家里的NAS。
她还装过Windows桌面控制、自动更新、回收保护、技能安装审查和错误记录工具。
真正让我改观的，不是AI会回答问题，而是它开始替这台机器留下维护记录。
这一步很关键。
普通聊天机器人关掉窗口就结束了。一个能长期住在服务器里的Agent，必须知道自己装过什么、改过什么、坏过什么，以及如何恢复。
后来我想在这台Windows云主机上部署一个Docker项目，方便另一台服务器上的Hermes使用。
Windows里跑Linux容器，最常见的路线是 WSL2。你可以把它理解成Windows内置的一层Linux环境，Docker Desktop通常也依赖它。
安装过程看起来完成了。
系统里甚至出现了WSL2图标。
但点开不能用，后续项目自然也跑不起来。
我没有把“出现图标”写成“安装成功”。这两件事差得很远。
云主机给了4核CPU和24GB内存，却不代表它把所有底层虚拟化能力都交给了用户。这个环境里，我最终没有把WSL2跑通，也没有硬堆更多补丁去制造一个脆弱的Docker底座。
配置高，解决的是资源问题；底层能力缺失，堆内存也补不回来。
这次失败反而帮我划清了边界：这台机器适合Windows原生工具和Agent实验，不适合把WSL2当成理所当然的基础设施。
这台机器后来成了Agent试验场，但我慢慢发现：实验室不是软件仓库。
我装过Hermes，也装过OpenHuman。
甲骨文上的Hermes后来被删除。主力Hermes继续留在另一台Linux云主机上，负责飞书入口、长期记忆、巡检和跨节点调度。把两套重能力系统堆在同一台Windows机器里，没有必要。
OpenHuman则输在两个更现实的问题上：内存压力和登录故障。
软件功能再多，如果登录链本身不稳定，或者常驻后挤占太多资源，就不适合长期留下。最终我把它卸载了。
WorkBuddy的命运不同。
它不是这间实验室的主力大脑，却一直保留到现在。原因非常朴素：每天签到能积累积分，积分又能支持我继续使用WorkBuddy Token。
刚刚的远程核验里，WorkBuddy仍有多个进程在运行。
工具值不值得留下，不看功能列表有多长，而看它能否用足够低的维护成本，持续产生明确价值。
同样留下来的还有几类单一职责工具：
- RustDesk：桌面级救援入口；
- OpenList：文件访问与管理；
- IPBan：负责登录防护；
- Tailscale：维持跨网络连接；
- 飞牛同步与备份任务：把重要数据送回NAS；
- OpenClaw Gateway：继续作为Windows上的Agent入口。
这才像实验室。
不是把所有软件永久堆满桌面，而是允许工具进入，接受实测，然后留下或淘汰。最后保留下来的不是“最强阵容”，而是一组互不抢戏、各自有职责的工具。
真正让这台Windows机器产生独特价值的，是后来的跨云控制。贝贝让它学会记录自己，雪则从另一台云主机伸进来一只手，让它能够真正执行任务。
主力Hermes运行在另一台Linux云主机上。Windows里则运行CCHH，也就是Claude Code的桌面伴侣。我们在两者之间加了一座带鉴权的桥：Hermes先读取远端会话，再通过WebSocket把任务交给Windows执行，最后收回原始结果。
对外可以把它理解成：
1
2
3
4
5
6
7
8
9
10
11
飞书里的指令
↓
Linux云主机上的Hermes
↓
带鉴权的远控接口
↓
甲骨文ARM64 Windows
↓
PowerShell或CMD真实执行
↓
结果原路返回
这座桥不是一次搭好的。协议细节很碎，但它们共同指向同一件事：远控不是“网页能打开”，而是任务必须有输入、有结束信号，也必须拿得回结果。
最早发送消息时，content被包装成数组，服务端直接报：
1
TypeError: content.trim is not a function
两端都认为自己在传“消息”，但一边理解为字符串，另一边传的是结构化数组。改成纯字符串后，连接才不再崩。
接着又遇到一个更隐蔽的问题：命令已经执行完，控制端却一直等。
原因是不同任务的结束信号并不统一。有时是message_complete，有时是content_block_stop，有时只是状态回到idle。只监听其中一种，桥接器就会永远以为任务还没完成。
还有一次，Windows明明执行成功，控制端却只看到“完成”，拿不到命令结果。后来才发现，真实输出藏在单独的tool_result事件里。
能打开网页不叫远控成功。命令真的穿过两台云主机，在Windows执行，再把原始结果送回来，才算闭环。
最近，远控域名突然开始返回502。
第一眼很像甲骨文主机掉线了。
但继续往下查，结论完全不同：Windows远程桌面仍能连接，目标端口也能建立TCP连接；中转服务器的日志显示，它已经接触到Windows上的服务，只是上游在返回HTTP响应头之前主动断开。
机器没死。
死的是CCHH应用层。
这也暴露了旧巡检的一处错误：过去我们把“CCHH接口是否正常”当成“整台Windows是否在线”。接口一坏，日报就把健康的主机误报为离线。
修复后，我重新做了四层验收：
- Windows远程桌面可达；
- 鉴权后的会话接口返回200；
- WebSocket成功升级；
- 远程命令返回真实Windows输出和完成事件。
最终收到的是：
1
2
3
4
5
6
7
8
Microsoft Windows [Version 10.0.26100.6584]
C:\Users\Administrator>
XUE_VERIFY_20260729
[Execution Complete]
BRIDGE_EXIT=0
这不是“看起来修好了”。
这是命令真的从Linux云主机出发，在Windows执行，再完整返回。
巡检也被改成三种状态：
- 正常：Windows在线，控制命令也能执行；
- 降级：Windows在线，但CCHH接口或命令链故障；
- 离线：Windows主机本身不可达。
服务器最危险的状态，不一定是彻底离线；也可能是端口都开着，只有真正执行命令时，才发现它已经失去响应。
刚刚通过恢复后的控制链，我又对这台机器做了一次只读核验。
当前系统实际报告为：
- Windows 10 IoT Enterprise LTSC 2024；
- 内核构建号26100；
- 物理内存约24GB；
- 当前可用内存约15.5GB；
- 系统盘约147GB，剩余约73GB；
- 最近一次启动时间为2026年7月16日。
正在运行或可验证的组件包括：
- WorkBuddy；
- Claude Code桌面端及其后台进程；
- OpenList；
- RustDesk；
- IPBan；
- Tailscale。
系统计划任务中还能看到OpenClaw Gateway、OpenList服务兜底和多项备份任务。
有一点也必须说清：早期文档记录CCHH曾由PM2守护，但本次核验没有读到PM2应用列表。当前控制链确实可用，具体守护方式已经发生变化，不能拿旧文档替代现状。
这正是长期实验的真实样子：架构会变，工具会换，旧认知必须接受新证据修正。
如果你只是想找一台不用维护的生产服务器，这套玩法不适合你。
它经历过WSL2失败、Agent卸载、登录Bug和远控接口502。Windows ARM64的软件兼容性，也不会因为“免费4核24G”几个字自动消失。
但如果你的目标是：
- 测试Windows ARM64软件；
- 运行需要图形界面的AI工具；
- 做Agent兼容性实验；
- 保留一台长期在线的Windows环境；
- 接受偶尔人工救援，并愿意建立备份与分层巡检；
它就很有价值。
我会继续保留它。
不是因为4核24G看起来诱人，而是几个月的筛选已经让它拥有了明确职责：贝贝曾在里面建立技能和备份；WorkBuddy继续签到积累积分；CCHH把命令行交给远端Hermes；RustDesk、OpenList、IPBan和同步任务各守一块边界。
它不是万能服务器，也不是软件收藏柜。
它是一间被失败慢慢筛出来的Windows AI实验室：ClawX打开门，贝贝留下记忆，WSL2划出边界，OpenHuman证明“能装”不等于“该留”，WorkBuddy用每天稳定产生的积分证明小职责也有价值，最后由CCHH把这间房子的命令行交到雪手里。
真正值得长期保留的，从来不是装过多少工具。
而是机器坏过、换过、被误判过之后，仍然有一套清楚的职责在运行。
「每天帮你踩一个 AI 的坑，省下一小时。」
你更想看下一篇拆哪部分：WSL2失败、跨云控制，还是这台机器现在到底能跑什么？
关联阅读：《白嫖甲骨文4核24G，装Win11避坑全记录》