www.liuvv.com 的证书以前经常过期。表面看像是「域名在 Cloudflare，证书却没续上」，但真实结构并非如此：Cloudflare 只负责 DNS，访客真正访问的是腾讯云 CDN，浏览器看到的证书也安装在腾讯云 CDN 上。

本文记录一套适配该场景的免费自动化方案：GitHub Actions 定时运行 acme.sh，通过 Cloudflare DNS-01 验证申请 Let’s Encrypt 证书，再调用腾讯云 SSL/CDN API，把证书部署到 www.liuvv.com 的 CDN 加速域名。

你在编辑器里跟 AI 说「帮我把这个函数改改」，AI 真的去读了文件、改了代码。这件事背后至少有三个角色：编辑器、AI 程序，以及读文件改文件的那些能力。ACP（Agent Client Protocol）管的是第一段——编辑器和 AI 程序之间怎么说话。

单表过了千万行，查询变慢、索引胀、删旧数据删到手酸，这几件事经常一块来。第一反应往往是「要不要分表、分库分表」——其实 PostgreSQL 原生分区（L1）往往就够：应用里还是查一张 orders，库在底下拆成很多小表；查某个月，就只碰那个月的小表。

下文分两段：§1 先在同一维度上区分 L1 分区 / L2 同库分表 / L3 分库分表，环境按 PostgreSQL 14+。

1. 为什么我们没有直接用 Logs Insights

我第一次看到这套日志搜索方案时，其实有点疑惑：AWS 已经有 CloudWatch Logs Insights，为什么还要自己搭一条 Firehose -> S3 -> EC2 -> ripgrep 的链路？

后来把代码和部署手册看完，答案反而很朴素。我们不是想重新做一个日志平台，只是想解决一个更窄的问题：开发排查线上问题时，能不能低成本地搜最近几天的历史日志，而且不要每次手一抖就把账单扫上去。

1. 为什么我说 Runway 是把 Terraform 当库用

我以前对 Terraform 的默认理解很简单：业务仓库里放 .tf 文件，CI 跑 terraform plan，合并后再跑 terraform apply。Atlantis、Terraform Cloud、Spacelift 大多都是这个路子。

Runway 不是这么做的。

业务方只写 runway.yaml。Terraform 模块跟 Go server 一起被编进二进制里。部署时，server 解压模块、拼出一份临时的根 .tf，再启动一个 Terraform 子进程去 apply。

所以这里说“把 Terraform 当库用”，不是说 Go 代码里真的 import terraform。它的意思是：Terraform 仍然是执行引擎，但模块版本、调用时机、输入生成、日志输出，都被平台代码接管了。

这篇记录我读这套设计时真正卡住的几个点：模块怎么塞进二进制，为什么解压目录不能随机，为什么 HCL 只是字符串模板，跨 stack 引用为什么一会儿走 Terraform、一会儿走 Go 代码。

1. 以为是 5 分钟升级，最后花了半天

这次升级 Gitea，我原本只想顺手把自建 runner 改成 ephemeral 模式。

预期很简单：Gitea 升到 1.26，act_runner register 加一个 --ephemeral，runner 跑完一个 job 自动退出。这样就不用再让 Fargate task 空等 30 分钟。

实际不是。

先是 runner 启不来，接着 job 卡在 queued，再接着发现 webhook 没发对事件，最后翻出两百多个 offline runner。问题单个看都不大，串起来就吃掉半天。

1. 一行 YAML 为什么没有变成 DATABASE_URL

我一开始把 db: postgresql 理解成一个动作：写进 runway.yaml，再跑一次 runway deploy，平台就会帮我建库，并把连接串注入到容器里。

结果不是这样。

部署成功了，容器也起来了，但应用里读 os.Getenv("DATABASE_URL")，拿到的是空字符串。这个问题最烦的地方是：它不是报错，而是“看起来都正常，只是少了一个变量”。

顺着代码查下去才发现，那行 YAML 只是被解析了，并没有参与部署请求。换句话说，它像一句写在配置里的备注：人看得懂，程序不一定理它。

这篇先不写成“Runway PaaS 机制大全”。我只记录一件事：一个应用最终拿到 DATABASE_URL，中间到底经过了哪些地方；又有哪些地方我一开始想错了。

1. 这篇其实不是讲 CLI 命令

前两篇讲了 Runway 怎么把 YAML 变成 RDS，又怎么把 Terraform 模块塞进 Go server。这一篇看起来是在讲 CLI，其实更像是在讲：一个部署工具怎么把很多“不想让业务方操心”的事情藏起来。

比如本地连数据库，不让开发者配 AWS 凭证；比如 ECS 说部署完成以后，不马上报成功；比如危险操作不能靠前端弹窗确认；比如 admin console 打开 SQL 浏览器时，不要每次都重新启动一个 pgweb。

这些都不是大架构，但很影响工具好不好用。

Agent 看起来很神秘：它能读代码、改文件、跑命令，遇到错误还能换一种方式重试。但把最小实现拆开，核心并不复杂——一个能工作的 Agent，最小内核只有三件事：模型、循环、工具。

这篇文章不停留在概念层面。读完以后，你应该能看懂任何 Agent 框架的核心循环，能判断一个 SDK 帮你封装了什么、省掉了什么、藏了什么坑。

你平时用 Postman 测接口：每加一个接口，就在左侧 New → HTTP Request，自己填 URL、选 GET/POST、手写 JSON。项目有 20 个接口时，你要点 20 遍；同事改路径后，你手里的 Postman 还是旧的，Send 出去 404，却不知道改哪。