我给了AI一张信用卡和3个生产账户：47分钟烧完额度，人工介入11次

2007年，19岁的我在托管服务器机房值班。当时所有系统管理员最怕一件事：把root权限交给不懂行的人。我见过一次——新人随手敲了rm -rf，三台客户的数据永远消失了。

2025年，AI代理正在获得同等级别的权限，外加一张信用卡、DNS控制台、域名购买权限。Hacker News上有人在欢呼，我决定亲自测试。

实验环境完全真实：Claude Sonnet 3.7作为编排代理，接入我的Cloudflare生产账户、Railway staging项目、Namecheap真实信用卡（设了低额度）。目标很简单：部署一个REST API，配置子域名，公开访问。没有预置凭证，没有测试域名，没有干净环境。

代理确实完成了三件事：自动列出Railway项目并选择staging环境、从Dockerfile部署应用、在Cloudflare创建Workers路由。全程零人工干预，日志显示200响应，看起来很美。

然后现实开始崩解。代理尝试购买域名时，Namecheap返回200状态码但附带错误体——"域名已被注册"。代理把200理解为成功，继续执行下一步，导致DNS配置指向了一个不存在的域名。API的"成功"不等于业务成功，这个区别LLM理解不了。

更隐蔽的问题在权限重叠。代理同时操作Railway部署和Cloudflare DNS，中间状态出现时——比如Railway实例已创建但健康检查未通过——代理无法判断是等待还是重试。它选择了重试，创建了三个同名实例，我的信用卡被扣了三次。

最终耗时47分钟，人工介入11次。对比Hacker News上那个"全程无人干预"的demo，我的实验暴露了三个盲区：错误码与业务状态的割裂、中间状态的决策缺失、成本边界意识的空白。

那个viral demo用的是预加载凭证、零冲突命名空间、一次性测试域名。相当于在空分支上演示git push，技术正确，运营无效。真正的部署环境里，命名冲突、额度限制、异步状态才是常态。

AI代理能跑通流程，但跑不通流程之间的灰色地带。这不是能力问题，是上下文问题——当API返回200却失败、当重试会花钱、当两个系统的状态不同步，需要业务判断，而LLM没有你的业务。

我的结论：这类demo适合证明概念，不适合证明生产就绪。给代理root权限之前，先想清楚2007年那个机房教给我们的东西——权限越大，恢复成本越高。AI不会比当年的新人更懂rm -rf的代价。