我跟 AI 说"帮我再开一台服务器"，它真的自己开了（附完整操作记录）

你于聊天窗口打出一句话，25分钟过后，一台配置完备运行环境的云服务器便交付了，并非工单系统完成，也不是运维同事达成，而是一个AI达成的。这听上去仿若科幻小说情节，然而OpenClaw（社区昵称“龙虾”）已然做到了这点。当AI从“能进行聊天”演变为“能管理基础设施”，云计算的玩法正遭受重新定义。

实验基础：给AI开一张云资源支票

要是想使得AI能够自主去操作云资源，那么首要核心前提便是信任与权限这块内容。接下来，你得给处于OpenClaw所在那个位置的EC2实例附加一个特定的IAM角色。此角色所起到的作用类似于一张授权支票哟，它能够告知亚马逊云科技：“在这台服务器上面运行的程序，是拥有权限去调用我的部分云服务的。”权限所涵盖的清单包括对EC2、弹性IP、安全组的管理权力，以及IAMFullAccess这种情况——这就表明了AI具备给自己或者其他实例增加或者减少权限的能力。在生产环境当中必须得按照实际需求进行收敛操作，等到其完成那个运行实验之后可要记得把权限收紧。

人类：看看当前区域的网络资源
AI：(跑了 aws ec2 describe-addresses 等命令)
你有 3 个弹性 IP：
- 1.1.1.1 → 我在用
- 2.2.2.2 → 闲置
- 3.3.3.3 → 也闲置（在白白花钱）
要不要清理掉？

人类：开一台 x86 EC2，配置参考你自己的，但要 x86 不要 ARM
AI：(创建 t3.large，分配并绑定 EIP)
新实例就绪：
- i-0fa6ff98817xxxxxx (t3.large, Ubuntu 24.04)
- 弹性 IP: 2.2.2.2

对话开始：一句指令触发全自动流程

AI：SSH 不通——Permission denied。我只有自己的密钥，没有新实例的 PEM。
但我可以用 EC2 Instance Connect。需要先给自己加一个 IAM 权限。
人类：自己加吧
AI：(修改自己的 IAM Role，加了 ec2-instance-connect 权限)
 权限就位。推送临时公钥中……
(推送公钥，趁 60 秒窗口写入 authorized_keys)
 SSH 打通了

# 给自己加权限
aws iam put-role-policy \
  --role-name OpenClaw \
  --policy-name EC2InstanceConnect \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "ec2-instance-connect:SendSSHPublicKey",
      "Resource": "arn:aws:ec2:ap-southeast-1:*:instance/"
    }]
  }'
# 推送临时公钥（只有 60 秒有效！）
aws ec2-instance-connect send-ssh-public-key \
  --instance-id  --instance-os-user ubuntu \
  --ssh-public-key file:///home/ubuntu/.ssh/id_ed25519.pub
# 趁窗口把公钥持久化
ssh ubuntu@ 'echo "" >> ~/.ssh/authorized_keys'

于Telegram聊天窗口之中，尽数完成了整个部署流程。当用户打入“帮我再部署一个”这般语句之后，OpenClaw即刻展开行动。其先是对账户里的网络资源予以查询，从中发现了一个处于闲置状态的弹性IP，进而将此弹性IP标示为待机待用。跟着便调用EC2 API去实施新实例的创建操作，并且自动把那个IP进行分配。整个进程里，没有任何一行命令是经由人类来进行输入的；AI全然依靠自身来达成了基础设施的初步构建。

人类：开始装吧
AI：
1. 装 Node.js 22
2. 装 OpenClaw
3. 写配置（参考我自己的）
4. 启动 Gateway
需要新的 Telegram Bot Token。
人类：(给了 Token)
AI：(全部远程完成)
 新龙虾已上线，给它发条消息试试

# 远程装 Node.js
ssh ubuntu@ 'curl -fsSL https://deb.nodesource.com/setup_22.x | \
  sudo -E bash - && sudo apt-get install -y nodejs'
# 远程装 OpenClaw
ssh ubuntu@ 'npm install -g openclaw'
# AI 参考自己的配置，手写新实例的配置文件
ssh ubuntu@ 'cat > ~/.openclaw/openclaw.json << EOF
{
  "models": {
    "providers": {
      "amazon-bedrock": {
        "auth": "aws-sdk",
        "models": [
          { "id": "us.anthropic.claude-sonnet-4-6" }
        ]
      }
    }
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": ""
    }
  }
}
EOF'
# 启动 + 开机自启
ssh ubuntu@ 'openclaw gateway install && \
  loginctl enable-linger ubuntu && \
  systemctl --user start openclaw-gateway.service'

自主排障：SSH不通时AI选择自己修

人类：(给新 Bot 发消息) 配对码是 XXXXXXXX
AI：(在新实例上执行配对确认)
 新龙虾可以正常对话了

┌──────────────────────┐         ┌──────────────────────┐
│    ARM EC2           │   SSH   │    x86 EC2           │
│    t4g.large         │───────│    t3.large          │
│                      │         │                      │
│  OpenClaw Gateway    │         │  OpenClaw Gateway    │
│  "母体"              │         │  "子体"              │
│                      │         │                      │
│  Bedrock (零密钥)    │         │  Bedrock (零密钥)    │
└──────────────────────┘         └──────────────────────┘

在新实例启动完毕之后，AI试着进行SSH连接然而却遭遇了失败。它并非是抛出错误去等待人工来处理，而是转而开始了自我诊断。在对日志展开分析之后，它判定这是权限方面的问题，紧接着调用ec2 - instance - connect服务去推送临时公钥。于推送成功以后，它马上发起SSH会话，把公钥写入到目标机器的authorized_keys文件，永久性地搞定了连接问题。整个从发现问题一直到执行修复的全程，都是自主完成的。

环境配置：手写配置文件和软件部署

# 创建只有 Bedrock 权限的角色
aws iam create-role --role-name BabyClaw \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'
aws iam attach-role-policy --role-name BabyClaw \
  --policy-arn arn:aws:iam::aws:policy/AmazonBedrockFullAccess
# 替换子实例的角色
aws ec2 replace-iam-instance-profile-association \
  --association-id  \
  --iam-instance-profile Name=BabyClaw

SSH连通之后，AI着手开始部署运行环境，它参照母体实例的配置情况，于新机器之上手动去编写配置文件，接着安装Python、pip等基础依赖包，拉拽OpenClaw代码库，开启新的Gateway服务，每一项步骤借助SSH会话远程予以执行，并且日志实时被回传到Telegram聊天窗口之中，用户能够全程进行旁观观看，然而是无需任何介入干预的。

权限收敛：新生实例自动更换最小权限角色

OpenClaw在部署完成之后，并未留下高权限方面的风险。它针对新实例自动进行了权限收窄的IAM角色更换：新角色仅仅留下调用Amazon Bedrock的权限，将所有基础设施管理权予以去除。母体实例保留着完整权限，目的是为了未来能够再次执行类似任务。这种呈现出“用完即收”特性的设计方式，展现出AI对于生产环境安全原则的理解。

实验启示：AI运维的三要素组合

这个实验的价值并非在于“AI能够敲命令”，这仅仅是自动化脚本具备的能力。此实验真正意义上的突破之处在于，它利用了三个亚马逊云科技服务的组合，其中IAM赋予了灵活的权限模型后，AI得以理解运行环境。在拥有此项权限时结合另外二者，即使用Bedrock提供模型调用能力，以及以EC2作为执行单元，进而让AI能够自主分析问题，自行设计并执行修复方案。最终，三者结合起来，AI从“能聊天”成功升级为“能管理基础设施”，从而开启了自主运维的全新可能。

若换成你，会让这只“龙虾”去管控哪些云资源呢，欢迎于评论区分享你的奇思妙想，觉得内容有益就点个赞，分享给更多对AI运维有兴趣的朋友哟。

相关标签： # AI # 服务器 # 自动化 # 部署 # 云技术