秋田散人(@akitabtc):其次要有一个直接面向终端产线、专门管理终端发布 yaml（比如 Kuberntes yaml/env config map 之类）的 CD server 作为 agent-based 开发流水线的终点。你可以面向 env 做很多数据抽象和归类，也就是更接近实际业务描述的 config map，降低碎片化的 env 配置和发布管理成本，以及配置出错概率。这个 server 会不断 sync 最新 env 配置（即你的生产意图）到产线。并且每一次 agent 在发布流程中授权操作 env 变更都需要向你提供变更对象的 deeplink（这个 CD server 的基本功能），在 PR 评论区留档。你必须明确他改了什么，以及如果你以后自己操作要怎么改，在哪里改。从 agent 管理哲学上来说，这个 server 是你传递实时意图到产线的关键。agent 不擅长处理紧急事务（比如 kill 开关），更擅长回溯与筹划，最终以及最敏捷的运维权利还是要放在自己手里。 ——这个是整件事能够高度自动化的关键。自动化不代表你放弃你该持有的掌控资源的权力，更不代表放弃你该担负的盈亏结果的义务。一旦放弃权利与义务（所谓的 agent 全委托），那么即使这个系统代码写得再好，到产线上也是一团散沙（这也是为什么有些 trading agent 在经济逻辑上根本不成立的原因，本质是跟单与 trust fund）。这样你的机器才真正有可能成为你的器官、你的双手，成为你向市场表达交易意图的直接方式，而不是仅仅是你的一个活跃在你大脑以外的消息代理。

2026.09.01 11:19

其次要有一个直接面向终端产线、专门管理终端发布 yaml（比如 Kuberntes yaml/env config map 之类）的 CD server 作为 agent-based 开发流水线的终点。你可以面向 env 做很多数据抽象和归类，也就是更接近实际业务描述的 config map，降低碎片化的 env 配置和发布管理成本，以及配置出错概率。这个 server 会不断 sync 最新 env 配置（即你的生产意图）到产线。并且每一次 agent 在发布流程中授权操作 env 变更都需要向你提供变更对象的 deeplink（这个 CD server 的基本功能），在 PR 评论区留档。你必须明确他改了什么，以及如果你以后自己操作要怎么改，在哪里改。从 agent 管理哲学上来说，这个 server 是你传递实时意图到产线的关键。agent 不擅长处理紧急事务（比如 kill 开关），更擅长回溯与筹划，最终以及最敏捷的运维权利还是要放在自己手里。 ——这个是整件事能够高度自动化的关键。自动化不代表你放弃你该持有的掌控资源的权力，更不代表放弃你该担负的盈亏结果的义务。一旦放弃权利与义务（所谓的 agent 全委托），那么即使这个系统代码写得再好，到产线上也是一团散沙（这也是为什么有些 trading agent 在经济逻辑上根本不成立的原因，本质是跟单与 trust fund）。这样你的机器才真正有可能成为你的器官、你的双手，成为你向市场表达交易意图的直接方式，而不是仅仅是你的一个活跃在你大脑以外的消息代理。

秋田散人@akitabtc

2026.09.01 10:40

补充一点前置条件，对于庞大且高频迭代、高度机器托管的项目，单元测试是不能少的，我的仓库已经三万多例测试。提交 PR 之前，pre-commit 脚本至少要 hook git push 行为（如果是小项目就 hook git commit 行为）。测试这一轮都没通过是不可能进入 Review agent 的，浪费 token。另外有几点小经验就是： 1. 远端 CI 要尽量采纳本地测试的回执，非 git baseline 变了不允许重跑，测试是很烧 CPU 也很耗时的，Github actions 的云端计费是很贵的，无非也就是看计算量和时间占用率。除非完全托管在云端的项目，大部分 CI 资源消耗还是应该放在本地。 2. 一定要想方设法在本地测试过程中用 CPU 置换时间，能并发执行、并发布署到本地 CI server 就最好。因为 coding agent 的等待耗时本来就是有成本的，容易让你吃更多上下文中断成本。更重要的是影响 coding agent 并行开发的效率。 3. 对于 Docker 镜像的构建加速其实也有很多盲区或者窍门，比如 pip/npm/cargo 版本没缓存到 docker layer 之类的重复构建，偶尔漏掉一层其实对于 CI 的耗时也是有影响的，最好让 agent 自检一遍，让 CI 的成本优化到极致，对于一个每天发几百个 PR 的项目来说完全是有必要的。