一次真实的部署流水账
整个部署从自托管的 Dokploy 平台开始。先在平台上创建 project 和 app，然后手动配置 GitHub 上构建的 Docker 镜像路径。因为镜像是私有的，还得去找 GitHub PAT 并粘贴进去——这些操作全在不同平台的 Web UI 上来回跳转，Agent 根本无从下手。
唯一交给 AI Agent 的工作是编写 GitHub Actions 构建流程。随后还需要写一个后续 Action：镜像构建完成后通过 CURL 调用部署平台接口触发自动部署。因为这一步需要 Token 验证，又得手动去 GitHub Actions 配置页面添加 Secret Value。
Push 代码后系统开始自动部署，结果失败了——better-sqlite3 找不到 Native Build 的 Node 扩展。让 Agent 去 debug：
- 第一次尝试将镜像的 Base 从 Alpine 换成 Debian Slim，没用
- 多次搜索无果后，开发者自己到项目 Issues 里搜索 "Alpine"，找到了相关问题
- 最终发现是 pnpm workspace 阻碍了 better-sqlite3 的安装后构建，需要添加
approve-builds配置
把答案告诉 Agent 之后，它才完成了修复。这个过程很典型：Agent 有能力执行修改，但缺乏在真实项目 Issues 中定位问题根因的直觉和经验。
域名、HTTPS、日志——每一步都要跨平台操作
项目跑起来只是开始。接下来要去 Cloudflare Dashboard 添加二级域名并指向服务器，回到 Dokploy 配置域名映射，启用 Let's Encrypt 自动 HTTPS，还得搞清楚服务运行在哪个端口。
然后是检查 Docker 运行日志，确认 auto-migration 是否正确执行。发现不行，通知 Agent 排查，但它看不到线上日志，没法验证修复是否生效，只能来回调试好几轮。
造一个工具：dokploy-logs
经历这番折腾后，开发者起了个新会话，让 Agent 调研并编写一个获取 Dokploy 服务日志的命令行工具，方便下次复用。最终产出的工具开源在 GitHub 上：reorx/scripts 仓库中的 dokploy-logs。
这是一个很实际的思路——当你发现某个操作反复需要跨平台手动完成，不如让 Agent 帮你把它脚本化。Agent 做不了完整的 DevOps 闭环，但它可以帮你把碎片化的操作沉淀为可复用的工具。
DevOps 为什么是 Agent 的短板
这类工作的核心难点在于：极度繁琐、琐碎且无规律。没有办法用一套通用方案去标准化，尤其是项目初期，熵值非常高。只有当项目足够稳定后，才可能通过 Ansible 或 Terraform 这类基础设施即代码的方式来管理，形成 SOP。
当下开发节奏越来越快，每个人都在不断构建新项目。基于现有数据训练出的通用 Coding LLM 虽然拥有 DevOps 知识，但还不能真正胜任这类工作——它无法像处理代码开发那样实现完整闭环。原因很直接：DevOps 涉及多个平台的 Web UI 操作、私密凭证管理、实时日志查看、以及大量依赖上下文判断的排错过程，这些都超出了当前 Agent 的能力边界。
对独立开发者来说，务实的做法是：让 Agent 处理它擅长的部分（写 CI 脚本、编写自动化工具、排查已知模式的错误），自己承担那些需要跨平台操作和经验判断的环节。同时，每次部署踩过的坑，都值得沉淀成一个脚本或一份文档——这才是真正减少下次部署摩擦的方式。