先亮明牌：这次测试里的四个云平台，有一个就是我经营的（redu.cloud），所以框架怎么搭由我定，但别全信我的话。每一轮运行我都全程录了屏，也把全部会话记录公开了，你可以自己查原始操作，不用依赖我的转述。

我真正想搞清楚的问题是：今天的AI代理到底能不能驾驭真实的云基础设施？不是那种无服务器平台上跑个待办应用的小打小闹，是真正有状态、需要自己掌控一切的基础设施。于是我把同一个任务交给同一个AI代理，在四个云平台上各来一遍，看每个平台能允许它做到什么程度。

任务清单很明确，要完成的是一项以隐私优先的真实部署：自托管私有GitLab；把私有的Supabase分支导入进去；从这个分支部署完整的自托管Supabase技术栈；修改运行中的产品（给Supabase Studio加一个备份视图）并重新部署；把应用数据放在可以独立备份的存储上；做一次真正的供应商级数据备份，然后恢复并验证；从应用内部通过一个仅限备份权限的凭证驱动这次备份；再加一个设备虚拟专用网络接入私有网络。贯穿始终的规则是：绝不依赖任何第三方服务。要求的是私有Git主机、私有数据库，一切都在自己控制的网络里跑。这不是一个随便放容器的玩具测试，它需要真正的云平台原语来支撑，所以对平台能力是一次公正的压力测试。

控制条件保持不变：同一个代理（Claude Code），同一个模型（Claude Opus），完全相同的提示词，按相同顺序执行。唯一的变量就是平台本身以及它所提供的工具和底层能力。如果某个平台用不同机制达到了同样的结果，我也认账，算它用自己的方式通过了。接下来的拆解，每条都带点意料之中的槽点，也有让人想说“认真的吗”的意外。

第一条，参考基准：redu.cloud，成了，但不干净。整个过程里所有组件始终待在同一张私有网络上。从结果看任务走通了，但过程远非丝滑——第一次备份尝试直接失败，AI代理当着镜头的面手忙脚乱地实时重建到了持久存储上。这段我没剪，原样留着，因为这才是真实状态：能干活，也会出岔子，人能看明白它是怎么从坑里爬出来的。其他几个平台的表现，都是拿这一趟作为标尺来对照的。

第二条，AWS：能跑，但慢半拍，还偷偷烧钱。AWS当然不缺完成整套任务所需的原语，再配上根密钥，它自家的代理工具完全可以把这些能力调用起来。两个地方让我很不舒服。一是它比参考运行慢了一大截：耗时多了45%，耗费的token多了29%。二是它在没有任何确认的情况下，三次自动启用了付费资源——第二台EC2实例、一台更大的构建实例，还有虚拟专用网络节点，全都悄无声息地开始计费，连个价钱提示都没弹。代理倒是问过我几次“这个功能的开通范围要多大”，但它从来没问过“我这么干你打算花多少钱”。

第三条，Vercel：根本做不了，但这不是它的错。Vercel天生就是给无服务器和前端场景准备的，专长是静态站点和短生命周期的函数。而我们要的是一个自带数据库、需要持久化连接的全自托管状态栈，还得配虚拟专用网络，这完全不在它的设计射程内。我把Vercel放进测试里，就是因为它标出了一条清晰的边界：在这类无服务器平台上，哪怕AI代理本身能力再强，也根本接不住这种类型的活儿。这对于选平台的人来说，是个相当有用的反面教材——工具的选择决定了代理的上限。

把这些跑下来的结果摆在一起，几条线就画得很清楚了：今天AI代理已经能在重视原语完整性的云上做出点实在东西，但过程绝对不像宣传片里那么顺滑；平台计费的透明度在这个代理时代反而成了一个新的大坑，因为代理不会替你看账单；而像Vercel这种以轻量化运转为卖点的环境，压根就不是为需要全栈控制力的任务准备的。选什么跑AI代理，不光是挑算力，也是在预先划定它能翻多大跟头。