Agent 真的能自己部署项目吗？一次 5 分 26 秒上线 Go Web 应用的实录复盘

admin2026/8/13阅读 5AI专区云主机 ucloud Agent 自动化部署 Go Web

AI 摘要 / TL;DR

本文以Go Web应用部署为例，展示Agent在提供项目上下文、云工具和人类确认机制后，5分26秒完成从云资源创建到网站上线的全流程。适合需要将代码快速交付可访问产品的开发者，验证了AI的工程闭环能力。

先说结论

Agent 可以自己完成云端部署，但前提不是“它足够聪明”，而是你给了它三个关键条件：

明确的项目上下文：代码结构、部署说明、Nginx/Systemd 配置文件都在项目里。
可调用的云工具：例如本文使用的 UCloud CLI Skill，让 Agent 能通过命令行操作云资源。
受控的人类确认机制：创建云资源、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 从理解项目、准备云资源、远程部署，到最终验证网站可访问的完整闭环。

为什么“代码写完”还不等于“项目交付”？

很多开发者应该都有类似经历：

代码在本地跑得很好，但客户或用户真正关心的是：

我能不能打开浏览器直接访问？

中间差的不是一行代码，而是一整条部署链路：

创建云服务器。
配置公网 IP。
设置防火墙或安全组。
安装运行环境。
上传代码和资源文件。
配置 Nginx 反向代理。
注册 Systemd 服务并设置自启动。
检查端口、日志和 HTTP 状态码。
验证登录、后台、关键业务流程是否正常。

这些步骤都不算特别难，但很消耗注意力。

尤其是文档站、企业官网、外包 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 的“能力说明书”。

安装命令是：

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	云主机初始化机制，服务器创建后需要等待它完成初始化。

第二步：一句自然语言触发部署

在项目目录下，输入这句话：

使用 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：这个方案能直接用于生产环境吗？

可以作为生产部署自动化的基础能力，但不建议不加改造地直接用于高风险生产系统。

生产环境还需要：

权限隔离；
日志审计；
监控告警；
备份恢复；
灰度发布；
安全扫描；
回滚机制。

如果想复现，需要准备什么？

复现步骤如下：

# 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 的角色正在从“编程助手”往“工程执行者”靠近。

但它能成功的原因，并不是简单因为模型强，而是因为整个项目满足了几个条件：

Agent 能读取项目上下文。
Agent 有 UCloud CLI Skill 这样的工具能力。
云资源操作有 AK/SK 认证路径。
高风险动作有人类确认。
部署后有服务状态、HTTP 状态码和业务路径验证。

所以，“Agent Ready”不是一句口号。

更准确地说，它是一套工程准备度：

当项目具备清晰文档、可调用工具、权限边界和验证标准时，Agent 才能真正把“代码写完”推进到“线上可访问”。

本案例中的 5 分 26 秒部署，并不意味着所有项目都能这么快上线；但它已经证明了一点：

对于标准化、低到中等复杂度的 Web 项目，Agent + 云 CLI Skill 已经可以把部署最后一公里自动化。