Agent Ready 实录：用 UCloud CLI Skill 5 分 26 秒完成云主机部署、Nginx 和 Systemd 配置

背景

很多 Web 项目在本地已经能跑通，但真正交付时，还差最后一公里：

• 买云主机
• 配公网 IP 和防火墙
• 上传代码
• 配 Nginx
• 注册 Systemd 服务
• 验证页面和接口是否可用

这一步看起来不复杂，但会消耗大量时间，而且容易在认证、权限、网络和启动脚本上反复踩坑。

这次实录的目标，就是验证一件事：Agent 能不能在受控确认机制下，自己走完整条部署链路。

结论先说：可以。
在本次案例中，Agent 通过 UCloud CLI Skill，将一个 Go Web Blog 项目部署到 UCloud 云主机，完成 Nginx 反向代理、Systemd 服务注册和访问验证；从输入自然语言指令到网站上线，总耗时 5 分 26 秒，人类只按了 两次确认。

---

问题

1. 代码写完了，但怎么尽快上线？

原文中的场景很典型：

• 开源了一个 CLI 工具，用户问“怎么用”，但没有在线文档站
• 接了一个外包项目，客户催着验收，需要“打开浏览器就能看见”

如果还沿用传统手工部署流程，往往要经历：

1. 创建云服务器
2. 配置公网访问
3. 安装运行环境
4. 上传代码
5. 配置反向代理
6. 注册服务
7. 手动验证

这条链路并不长，但足够烦。

2. Agent 会写代码，但不会自动部署怎么办？

Agent 默认擅长理解代码和生成内容，但对“怎么开云主机、怎么配认证、怎么连 SSH、怎么验证服务”并不天然具备能力。

所以问题不是“Agent 能不能做”，而是：

• 有没有可调用的云 CLI
• 有没有给 Agent 的部署说明
• 有没有明确的验证标准
• 有没有人工确认边界

---

方案

给 Agent 装上“云能力”

本案例使用的是 UCloud CLI Skill。

可以把 Skill 理解成 Agent 的一份“能力说明书”，它告诉 Agent：

• 能用哪些工具：UCloud CLI
• 怎么用：参数、命令、示例
• 什么时候用：部署、资源管理、网络配置等

安装命令如下：

npx skills add ucloud/skills ucloud-cli 

安装后，Agent 就能在兼容环境里调用 UCloud CLI。原文提到兼容环境包括 Codex、Claude Code、Amp 等。

为什么这套方案有效

核心原因有三个：

1. 自然语言驱动任务：开发者不需要手动拆命令。
2. CLI 更适合自动化：比控制台点选更可复制、可重试、可审计。
3. 有人工确认机制：创建资源、远程执行等高风险操作仍需用户确认。

---

实现步骤

下面按实际流程拆解。

第 1 步：准备项目

本次部署对象是一个 Go Web Blog 应用，本地已经能正常运行。

项目结构包括：

• main.go：Web 服务主程序，基于 Go 标准库 net/http
• handler.go：路由与业务逻辑
• db.go：SQLite 数据库初始化
• templates/：页面模板
• static/：CSS 样式
• blog/ + blog.db：内容与数据库
• deploy/：部署文件，包括 blog.service、nginx.blog.conf
• DEPLOY_UCLOUD.md：部署说明文档

这类结构也可以类比成文档站、企业官网或后台管理系统。

第 2 步：安装 UCloud CLI Skill

px skills add ucloud/skills ucloud-cli

这一步完成后，Agent 可以识别 UCloud CLI，并根据部署文档执行相关操作。

第 3 步：用自然语言触发部署

在项目目录下输入：

使用 UCloud CLI 将这个项目部署到云主机，配好 Nginx 和 Systemd

后续动作由 Agent 自动执行。

第 4 步：Agent 先理解环境，再开始操作

这一步很关键，Agent 没有直接上来就创建资源，而是先读取项目与部署说明：

1. 打开 main.go
2. 打开 DEPLOY_UCLOUD.md
3. 打开 blog.service
4. 打开 nginx.blog.conf
5. 检查 UCloud CLI 是否已安装
6. 检查认证状态
7. 根据环境选择可行路径

这里发生了两个关键判断

• UCloud CLI 没装：自动下载官方 Linux amd64 版本，并验证版本号，原文给出的版本是 0.3.0
• 认证不通：API 返回 PublicKey not available，说明当前没有有效登录状态；随后尝试 OAuth，但非交互终端不支持，于是切换为 AK/SK 方式配置 Profile

这说明 Agent 不是“报错就停”，而是会根据环境变化自动换路径。

第 5 步：创建云资源

认证完成后，Agent 开始创建资源。

操作	结果
查询 Region/Zone	选择 cn-wlcb，即乌兰察布
创建 UHost 云主机	1C/2G/20G Cloud_SSD，按小时计费
创建弹性 IP	绑定到云主机，公网 IP 为 117.50.47.119
配置防火墙	开放 22、80、443 端口

原文中提到：这些操作如果在控制台手动完成，通常至少需要 20 分钟；Agent 通过 CLI 不到 2 分钟完成。

第 6 步：SSH 登录并部署应用

服务器就绪后，Agent 通过 SSH 进入主机，继续完成部署：

1. 等待 cloud-init 初始化完成
2. 将 blog/、blog.db、模板和静态资源打包为 tar.gz
3. 通过 SCP 上传到远程服务器
4. 创建 blog.env，包含后台密码等环境变量
5. 将项目部署到 /opt/blog/
6. 注册 blog.service 为 Systemd 服务
7. 配置 Nginx 反向代理，将 80 端口转发到 8080 端口

第 7 步：验证服务是否可用

这次部署不是只看“命令成功”，而是做了完整验证：

验证项	结果
首页访问 http://117.50.47.119/	HTTP 200 OK
后台登录页	HTTP 200 OK
登录 POST	303 See Other + Session Cookie
blog.service	Active
Nginx	Active

最终 Agent 输出了部署报告：

✅ 已将 UCloud 完整部署，网站可访问：
   http://117.50.47.119/

资源信息：
   Region/Zone:  cn-wlcb / cn-wlcb-01
   UHost:        uhost-irjgoqvvylgi
   EIP:          117.50.47.119
   规格:         1C/2G/20G Cloud_SSD
   计费:         Dynamic 按小时
   防火墙:       22/80/443 已开放

SSH 信息：
   用户:    ubuntu
   后台:    http://117.50.47.119/admin/login

从输入指令到网站上线，总耗时 5 分 26 秒。

---

实体解释

下面把文中出现的关键实体补齐，方便理解。

实体	说明
UCloud / 优刻得	云计算平台，本案例用于创建云主机、EIP 和防火墙规则
UCloud CLI	用命令行管理 UCloud 资源的工具
UCloud CLI Skill	给 Agent 的能力扩展，让它知道如何调用 UCloud CLI
Codex CLI	本次执行部署任务的 Agent 运行环境
UHost	UCloud 的云主机产品
EIP	弹性公网 IP，用于公网访问
Nginx	Web 服务器和反向代理工具
Systemd	Linux 服务管理器，用于服务注册和自启动
AK/SK	云账号访问密钥，用于 CLI 认证
cloud-init	云主机初始化机制

---

问题-解决方案-验证闭环

本次案例的关键价值，不是“Agent 会部署”，而是它能在遇到问题后形成闭环。

问题	Agent 怎么办	验证方式
UCloud CLI 没装	检测系统架构，下载官方二进制，验证版本	CLI 可运行，版本号 0.3.0
CLI 没有认证 Profile	先试 OAuth，因非交互终端不支持，改用 AK/SK	API 调用成功
SSH 连接报权限错误	调整 SSH 配置参数后重试	成功登录云主机
Nginx 临时连不上	等待 cloud-init，检查服务状态后重试	Nginx Active，HTTP 200
登录 POST 验证失败	换验证方式，用状态码和 Cookie 判断	303 See Other + Session Cookie

这说明 Agent 具备一定工程判断力：不是看到报错就停，而是继续分析、调整、验证。

---

常见问题

Q1：什么是 Agent Ready？

Agent Ready 指的是：项目具备让 Agent 理解、执行并验证任务的条件。对部署场景来说，通常包括部署文档、可调用工具、权限边界、成功标准和人工确认机制。

Q2：Skill 和普通脚本有什么区别？

脚本是固定流程，Skill 更像工具说明和操作指南。Agent 可以根据上下文选择命令、处理异常、调整步骤。本案例里，OAuth 不可用时切换到 AK/SK，就是这种上下文决策能力。

Q3：为什么不用控制台，改用 UCloud CLI？

因为 CLI 更适合自动化，具备可复制、可审计、可重试的特点；控制台更依赖人工点击，不利于 Agent 执行。

Q4：为什么还需要人工确认？

因为创建云资源、开放端口、远程执行命令都可能带来费用和安全影响。人工确认保留了否决权，也控制了执行边界。

Q5：5 分 26 秒适用于所有项目吗？

不适用。这个时间只对应本次 Go Web Blog 项目实录。项目规模、依赖、镜像大小、网络、认证方式都会影响耗时。

Q6：能直接用于生产环境吗？

可以作为基础能力，但不建议原样直接用于高风险生产环境。生产系统还需要权限隔离、审计、监控、备份、灰度和回滚机制。

---

复现步骤

如果你要复现这个流程，可以按下面做：

# 1. 安装 Codex CLI
npm install -g @openai/codex

# 2. 安装 UCloud CLI Skill
px skills add ucloud/skills ucloud-cli

# 3. 进入项目目录
cd ~/your-project

# 4. 启动 Codex，用自然语言触发部署
codex
> 使用 UCloud CLI 将这个项目部署到云主机，配好 Nginx 和 Systemd

前提条件

• OpenAI API Key，原文提到需支持 gpt-5.5 模型
• UCloud 账号的 AK/SK，用于 CLI 认证
• 项目中包含 DEPLOY_UCLOUD.md
• 最好同时提供可用的 blog.service 和 nginx.blog.conf

---

常见问题与注意事项

1. AK/SK 不要随意泄露

云账号密钥一旦泄露，影响范围比普通脚本更大。建议使用最小权限密钥，不要写入仓库。

2. 注意资源成本

按小时计费的云主机和 EIP，在部署结束后如果不释放，会继续产生费用。

3. 防火墙不要盲目全开

本案例开放了 22、80、443 端口，但生产环境应尽量控制 SSH 来源 IP。

4. 部署文档要和真实情况一致

Agent 很依赖 DEPLOY_UCLOUD.md。如果文档过时，部署就容易偏离真实环境。

5. 200 不等于业务完全正常

应该同时检查服务状态、端口监听、登录流程、Cookie 和日志。

---

总结

这次实录说明了一件事：Agent 已经不只是“写代码助手”，还可以在明确的权限边界内，完成一整套工程部署动作。

本次流程中，Agent 做到了：

1. 读取项目上下文
2. 调用 UCloud CLI
3. 在认证失败时切换方案
4. 创建云资源
5. SSH 部署应用
6. 配置 Nginx 和 Systemd
7. 通过 HTTP 状态码和服务状态完成验证

从“代码写完”到“线上可访问”，这条最后一公里一旦被打通，Agent 就从辅助工具更接近真正的工程执行者。

这就是本文的核心结论：在项目说明清晰、工具链可调用、验证标准明确、并保留人工确认的前提下，Agent 可以完成云端部署闭环。