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

已有 Clash、ClashX、Clash Verge 或 mihomo 订阅，想在 iPhone 的 Quantumult X 里复用同一批节点，但不想把订阅地址交给公共转换站——本文演示如何在同一 Wi-Fi 下，用 Mac 临时充当本地 Subconverter，把 Clash 订阅转成 Quantumult X 可用的服务器资源。

目标不是把 Mac 变成代理网关。Mac 只在「刷新订阅」时参与；节点测速、日常代理、App 流量仍由 iPhone 直连远程节点。

单表过了千万行，查询变慢、索引胀、删旧数据删到手酸，这几件事经常一块来。PostgreSQL 分区表的思路很直接：应用里还是查一张 orders，库在底下拆成很多小表；查某个月，就只碰那个月的小表。

下文用一张 orders 走完全程：先搞清它长什么样，再定分区键和粒度，然后建表、插入、查询，看 EXPLAIN 为啥变快，最后说运维和迁移。环境按 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. 一行 YAML 为什么没有变成 DATABASE_URL

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

结果不是这样。

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

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

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

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

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

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

实际不是。

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

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

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

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

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

1. 为什么我不想再手工维护 Postman

Postman collection 手工维护到最后，最麻烦的不是点几下 UI，而是你不知道哪一份才是真的。

代码里有一份路由，docs/openapi.json 里有一份接口契约，Postman 里又有一份 collection。接口改过几轮以后，这三份东西很容易开始互相打架。路径少一个前缀、body 字段改了名字、认证方式忘了更新，这些问题单独看都不大，但排查时很烦。

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

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