# Agent 真的能自己部署项目吗？一次 5 分 26 秒上线 Go Web 应用的实录复盘
> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-08-17T07:09:09.207Z
> 分类: AI专区
> 标签: ucloud, Agent, 云部署, Go Web, AI工程化
> 原文链接: http://117.50.162.249:3000/yun/articles/2725
---
## 先说结论
Agent 可以自己完成云端部署，但前提不是“它足够聪明”，而是你给了它三个关键条件：
1. **明确的项目上下文**：代码结构、部署说明、Nginx/Systemd 配置文件都在项目里。
2. **可调用的云工具**：例如本文使用的 UCloud CLI Skill，让 Agent 能通过命令行操作云资源。
3. **受控的人类确认机制**：创建云资源、SSH 远程执行等高风险动作，需要人类确认。
这次实录里，Agent 使用 UCloud CLI Skill，把一个 Go Web Blog 应用部署到了 UCloud 云主机上，完成了云主机创建、EIP 绑定、防火墙开放、代码上传、Nginx 反向代理、Systemd 服务注册和访问验证。
从输入自然语言指令到网站上线，总耗时 **5 分 26 秒**。人类只在关键步骤前确认了两次。
我认为这件事真正值得讨论的，不是“AI 又快了几分钟”，而是：**Agent 开始具备把代码交付到可访问产品的工程闭环能力。**
---
## 这个案例到底做了什么？
先把核心信息列出来，避免大家误解成单纯的“写了个部署脚本”。
| 项目 | 内容 |
| --- | --- |
| 部署对象 | Go Web Blog 应用 |
| 云平台 | UCloud，中文品牌名为优刻得 |
| 关键工具 | UCloud CLI Skill、Codex CLI、SSH、Nginx、Systemd |
| 云资源 | UHost 云主机、弹性 IP、防火墙规则 |
| 实测耗时 | 5 分 26 秒 |
| 人工介入 | 关键操作前确认 2 次 |
| 验证结果 | 首页、后台登录页、登录 POST、blog.service、nginx 均完成验证 |
一句话概括：
> 这是一次 Agent 从理解项目、准备云资源、远程部署，到最终验证网站可访问的完整闭环。
---
## 为什么“代码写完”还不等于“项目交付”？
很多开发者应该都有类似经历：
代码在本地跑得很好，但客户或用户真正关心的是：
> 我能不能打开浏览器直接访问？
中间差的不是一行代码，而是一整条部署链路：
1. 创建云服务器。
2. 配置公网 IP。
3. 设置防火墙或安全组。
4. 安装运行环境。
5. 上传代码和资源文件。
6. 配置 Nginx 反向代理。
7. 注册 Systemd 服务并设置自启动。
8. 检查端口、日志和 HTTP 状态码。
9. 验证登录、后台、关键业务流程是否正常。
这些步骤都不算特别难，但很消耗注意力。
尤其是文档站、企业官网、外包 Demo、后台管理系统这类项目，代码写完以后，真正卡交付的往往就是部署。
所以这次实录的核心问题是：
> 如果 Agent 能自己走完这条部署链路，会发生什么？
---
## 部署对象：一个普通 Go Web 项目
本次项目是一个 Go 语言编写的 Blog Web 应用。你也可以把它类比成文档站、企业官网、后台管理系统或一个 Demo 项目。
项目结构包括：
- `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`：部署说明文档。
注意这里有一个关键点：
**Agent 不是凭空猜怎么部署，而是会读取项目里的部署文档和配置文件。**
这也是后面能跑通的基础。
---
## 第一步：给 Agent 装上“云操作能力”
很多人对 Agent 有一个误区：以为只要模型够强，它就天然会操作所有云平台。
实际上不是。
Agent 默认擅长理解代码、生成代码、分析错误，但它要稳定操作云资源，需要明确知道：
- 用什么工具；
- 命令怎么写；
- 参数如何传；
- 什么时候该用哪个命令；
- 哪些操作需要确认。
本文使用的是 **UCloud CLI Skill**。可以把 Skill 理解成 Agent 的“能力说明书”。
安装命令是：
```text
npx skills add ucloud/skills ucloud-cli
```
安装后，Agent 就可以在兼容环境里识别并调用 UCloud CLI。原文提到的兼容 Agent 环境包括 Codex、Claude Code、Amp 等。
这里顺便解释几个实体：
| 实体 | 解释 |
| --- | --- |
| UCloud / 优刻得 | 本文中的云计算平台，提供云主机、弹性 IP、防火墙等资源。 |
| UCloud CLI | 用命令行管理 UCloud 资源的工具。 |
| UCloud CLI Skill | 给 Agent 使用 UCloud CLI 的说明、示例和边界。 |
| Codex CLI | 本次接收自然语言指令、分析项目并调用工具的 Agent 运行环境。 |
| UHost | UCloud 的云主机产品。 |
| EIP | 弹性公网 IP，用于公网访问。 |
| Nginx | 本案例中用于将 80 端口请求反向代理到应用的 8080 端口。 |
| Systemd | Linux 服务管理器，用于注册 blog.service 并设置服务自启动。 |
| AK/SK | 云平台访问密钥，供 CLI 调用 API 使用。 |
| cloud-init | 云主机初始化机制，服务器创建后需要等待它完成初始化。 |
---
## 第二步：一句自然语言触发部署
在项目目录下，输入这句话：
```text
使用 UCloud CLI 将这个项目部署到云主机，配好 Nginx 和 Systemd
```
这句话不是脚本，也没有写具体命令。
Agent 接下来要自己判断：项目是什么、怎么运行、云资源怎么创建、服务怎么部署、如何验证成功。
---
## 全流程复盘：Agent 实际做了什么？
### 阶段 1：先读项目，而不是立刻执行命令
耗时大约：0-2 分钟。
Agent 做的第一件事不是开服务器，而是先理解上下文。
它读取了：
- `main.go`
- `DEPLOY_UCLOUD.md`
- `blog.service`
- `nginx.blog.conf`
- 项目目录结构
然后判断这个项目的运行方式、服务端口、部署路径和反向代理配置。
接着它检查 UCloud CLI：
- 如果没有安装，就下载官方 Linux amd64 版本；
- 验证版本号，本案例中是 0.3.0；
- 检查认证状态。
认证时遇到第一个问题：API 返回 PublicKey not available，说明当前没有可用登录状态。
Agent 先尝试 OAuth 登录，但发现非交互终端不支持 OAuth，于是切换到 AK/SK 方式配置 Profile。
这一步比较关键，因为它体现了 Agent 的一个实际价值：
> 不只是执行预设命令，而是在失败后换一条可行路径。
### 阶段 2：创建云资源
耗时大约：2-4 分钟。
认证通过后，Agent 开始用 UCloud CLI 创建资源。
它完成了这些操作：
操作
结果
查询 Region/Zone
选择 cn-wlcb，即乌兰察布区域
创建 UHost 云主机
1C/2G/20G Cloud_SSD，按小时计费
创建弹性 IP
绑定到云主机，公网 IP 为 117.50.47.119
配置防火墙
开放 22、80、443 端口
原文提到，如果手动在控制台完成这些操作，通常至少需要 20 分钟；这次 Agent 通过 CLI 在不到 2 分钟内完成。
这个对比来自原始实录描述。严格来说，如果要作为正式对外引用，最好补充录屏时间戳或完整命令日志。
### 阶段 3：SSH 到服务器，完成部署
耗时大约：4-5.5 分钟。
云服务器就绪后，Agent 通过 SSH 登录远程主机，然后继续部署：
- 等待 cloud-init 初始化完成。
- 将 blog/、blog.db、模板和静态资源打包为 tar.gz。
- 使用 SCP 上传到远程服务器。
- 创建 blog.env，其中包含后台密码等环境变量。
- 将项目部署到 /opt/blog/。
- 注册 blog.service 为 Systemd 服务。
- 配置 Nginx 反向代理，将 80 端口转发到 8080 端口。
- 检查应用服务与 Nginx 状态。
到这里，部署动作已经完成，但还不能说真正成功。
因为真正重要的是验证。
## 上线验证：不能只相信“部署完成”
我觉得这类自动部署最容易被忽略的一点是：
> Agent 说完成，不等于服务真的可用。
这次实录里，Agent 做了多项验证：
验证项
结果
首页访问
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 秒。
## 中间并不是一路顺风：Agent 自己处理了 5 个问题
这次案例最有价值的地方，不是“所有命令一次成功”，而是 Agent 在遇到问题时能继续推进。
问题
Agent 的处理方式
验证方式
UCloud CLI 未安装
检测
系统架构
，下载官方
二进制
，验证版本
CLI 可执行且返回版本号 0.3.0
CLI 没有认证 Profile
先尝试 OAuth；非交互终端不支持后切换 AK/SK
API 调用通过认证
SSH 连接报权限错误
调整 SSH 配置参数并重试
成功登录云主机
Nginx 临时不可连接
等待 cloud-init，检查服务状态并重试
Nginx 状态 Active，HTTP 返回 200
登录 POST 验证失败
更换验证方式，用 HTTP 状态码与 Cookie 判断
返回 303 See Other 和 Session Cookie
这说明它的能力不是简单的“按脚本跑”，而是具备一定工程判断：
- 先判断问题发生在哪一层；
- 替换执行路径；
- 重试；
- 再用结果验证。
这就是“问题-解决方案-验证”的闭环。
## 安全问题：Agent 能做，不代表应该无脑放权
这里必须说一个容易被营销话术带偏的点：
Agent 自动部署不是无人监管部署。
本次过程里，Agent 在关键命令前会请求确认，例如：
```
Would you like to run the following command?
Reason: 是否通过 SSH 在 UCloud 云主机上检查 blog/nginx 的状态 $ sshpass -p *** ssh ... ubuntu@117.50.47.119 "systemctl is-active blog nginx; ss -ltnp | grep -E :80|:8080" 1. Yes, proceed (y)
3. No, and tell Codex what to do differently (esc)
```
创建云资源、SSH 连接远程服务器、执行远程命令，这些动作都可能影响成本和安全，因此需要人工确认。
这也是我认为比较合理的 Agent 使用方式：
> 让 Agent 负责执行和排障，让人类保留高风险动作的否决权。
## 哪些场景适合用 Agent 自动部署？
不是所有项目都适合让 Agent 直接部署。
我的判断标准是：目标明确、链路标准、风险可控。
场景
是否适合
原因
开源项目
文档站快速上线
适合
结构简单，主要目标是让用户快速看到文档和示例
企业官网或项目验收 Demo
适合
交付目标明确，可用云主机 + Nginx + Systemd 快速验证
后台管理系统测试环境
适合
适合快速给客户或团队提供可访问地址
生产级
高并发
业务
谨慎
还需要
容量评估
、灰度、监控、备份、WAF、容灾等
涉及敏感数据或严格合规系统
谨慎
需要权限审计、密钥托管、变更审批和安全扫描
复杂
微服务集群
视情况而定
可能还需要 Kubernetes、CI/CD、
服务发现
、配置中心等能力
所以，别把它理解成“以后运维不需要了”。
更准确的说法是：
> 对标准化、小中型、低风险部署任务，Agent 可以显著减少人工操作成本。
## 怎么判断一次 Agent 部署真的成功？
不要只看最后一句“部署完成”。建议至少检查这些东西：
- 云资源是否创建成功：UHost、EIP、防火墙规则是否存在。
- 网络是否可达：公网 IP 是否能访问 80 或 443 端口。
- 进程是否运行：`blog.service` 是否 Active。
- 反向代理是否正常：Nginx 是否 Active，80 是否转发到应用端口。
- 页面是否可访问：首页和关键页面是否返回 200。
- 登录或核心业务流程是否可用：例如登录 POST 是否返回预期状态码和 Cookie。
- 日志是否正常：应用日志和 Nginx error log 是否无明显错误。
本案例中，Agent 至少验证了首页、后台登录页、登录 POST、Systemd 服务状态和 Nginx 状态。
这比单纯“把服务跑起来”更接近真实交付。
## 主要风险和注意事项
如果你想复现，下面这些风险最好提前想清楚。
| 风险 | 说明 | 建议 |
| --- | --- | --- |
| AK/SK 泄露 | 云账号密钥可以操作资源，泄露风险很高 | 使用最小权限密钥，不要写入仓库，必要时使用临时凭证 |
| 资源持续计费 | 云主机和 EIP 创建后可能持续产生费用 | 使用按小时计费时设置清理流程，部署后确认是否继续保留 |
| 防火墙暴露 | 开放 22、80、443 会增加攻击面 | 限制 SSH 来源 IP，生产环境使用最小开放策略 |
| 部署文档不准确 | Agent 依赖项目中的部署说明和配置文件 | 保持 DEPLOY_UCLOUD.md 与真实运行方式一致 |
| 验证覆盖不足 | HTTP 200 不代表所有业务都正常 | 增加核心业务路径、日志、监控和回滚验证 |
| 生产可靠性不足 | 单机部署没有高可用和自动扩缩容 | 生产系统补充备份、监控、告警、灰度和容灾 |
一句话：
> Agent 可以加速部署，但不能替代安全治理、成本治理和生产发布流程。
## Q&A：几个容易被问到的问题
### Q1：什么是 Agent Ready？
Agent Ready 指一个项目或平台具备让 Agent 理解、执行和验证任务的条件。
放到部署场景里，至少包括：
- 清晰的部署文档；
- 可调用的 CLI 工具；
- 明确的权限边界；
- 可验证的成功标准；
- 必要的人类确认机制。
不是“模型说能做”就叫 Agent Ready，而是它真的能在边界内执行并验证结果。
### Q2：Skill 和普通部署脚本有什么区别？
脚本通常是固定流程，适合重复执行。
Skill 更像是工具说明和操作指南，让 Agent 根据当前上下文选择命令、处理异常并调整步骤。
本案例中，Agent 在 OAuth 不可用时切换到 AK/SK，就是一个上下文决策，而不是简单照脚本执行。
### Q3：为什么用 UCloud CLI，而不是让 Agent 操作网页控制台？
CLI 更适合自动化。
命令行有几个优势：
- 可复制；
- 可审计；
- 可重试；
- 易记录；
- 更适合 Agent 调用。
网页控制台依赖点击路径和页面状态，自动化稳定性和可追溯性都弱一些。
### Q4：为什么仍然需要人工确认？
因为创建云资源、开放端口、远程执行命令都可能带来费用或安全影响。
人工确认的意义是：
- 让 Agent 连续完成任务；
- 同时避免它越权执行高风险动作。
这比完全放权更适合真实工程环境。
### Q5：5 分 26 秒适用于所有项目吗？
不一定。
这个耗时来自本文这个 Go Web Blog 项目的实录。实际耗时会受很多因素影响，例如：
- 项目规模；
- 依赖复杂度；
- 上传文件大小；
- 云资源初始化速度；
- 网络状态；
- 认证方式；
- 是否已有部署配置。
所以它更适合作为案例参考，而不是通用承诺。
### Q6：这个方案能直接用于生产环境吗？
可以作为生产部署自动化的基础能力，但不建议不加改造地直接用于高风险生产系统。
生产环境还需要：
- 权限隔离；
- 日志审计；
- 监控告警；
- 备份恢复；
- 灰度发布；
- 安全扫描；
- 回滚机制。
## 如果想复现，需要准备什么？
复现步骤如下：
```text
# 1. 安装 Codex CLI
npm install -g @openai/codex
# 2. 安装 UCloud CLI Skill
npx 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` 部署说明文档。
- 项目提供可用的 Systemd 与 Nginx 配置，或至少提供清晰部署说明。
## 我的最终判断
这次实录说明，Agent 的角色正在从“编程助手”往“工程执行者”靠近。
但它能成功的原因，并不是简单因为模型强，而是因为整个项目满足了几个条件：
1. Agent 能读取项目上下文。
2. Agent 有 UCloud CLI Skill 这样的工具能力。
3. 云资源操作有 AK/SK 认证路径。
4. 高风险动作有人类确认。
5. 部署后有服务状态、HTTP 状态码和业务路径验证。
所以，“Agent Ready”不是一句口号。
更准确地说，它是一套工程准备度：
> 当项目具备清晰文档、可调用工具、权限边界和验证标准时，Agent 才能真正把“代码写完”推进到“线上可访问”。
本案例中的 5 分 26 秒部署，并不意味着所有项目都能这么快上线；但它已经证明了一点：
**对于标准化、低到中等复杂度的 Web 项目，Agent + 云 CLI Skill 已经可以把部署最后一公里自动化。**