三个人四周 708 个 PR，账单每月 1500 欧：Agent 上岗后我停掉的五笔开销

三个人，四周 708 个 PR#

三个人，四周，708 个 PR。

这是 amaiko 的 CTO Stefan Kirsch 在 10 月 11 日公开的一份成本复盘。团队就三个人：他自己、资深开发 Markus Heigl、资深 SRE Florian Schauer。没有专职平台工程师，Kubernetes 升级、CI 维护、日志排查这些活大部分由 Claude 和 Codex 干，人只在旁边握着方向盘。

同一段时间，他们的服务器、CI、监控、代码评审和 AI 订阅加在一起，按标价算大约每月 1500 欧元。如果换成 API 计价，光 Kirsch 一个人的 Claude 用量一个月就值 9000 欧。

这篇文章解释了他不再付哪五笔钱，为什么。下面挑出账单里最值得看的部分。

服务器：省了八倍，但真正值钱的是能搬走#

基础设施放在 16 台 Hetzner Cloud 服务器上，机房在德国和芬兰。其中 11 台组成三个 Talos Linux 上的 Kubernetes 集群：生产、内部工具、一个小开发集群，staging 是生产集群里的一个 vcluster。另外 5 台跑 CI。OpenTofu 负责开机器，ArgoCD 从 git 部署其余一切。

集群里塞着一堆本来会出现在云账单上的东西：CloudNativePG 管的 Postgres、Keycloak、NetBird VPN、Gatus 做可用性探测、Renovate、k8up 备份，还有监控。这些活由 SRE 管，但动手的多数是 Claude，从 Talos 升级到「为什么这个 rollout 起不来」。Claude 还会通过 Hetzner API 直接开服务器，token 从 shell 环境里拿，所以没人需要把密钥粘进对话。生产环境的改动一律走 git 加 ArgoCD，agent 想重启、删除、同步任何生产资源，都得先拿到人的明确许可。

钱是这么算的：集群这部分（11 个节点、11 个负载均衡器、约 1.5TB 块存储加一些对象存储）每月约 480 欧。

同样的规格放到法兰克福的 AWS 上，三个 EKS 控制面、按 vCPU 和内存配的 Graviton 实例、11 个 ALB、NAT 网关、gp3 卷，再加每月假设 2TB 出口流量，按需价约 3700 欧，一年 Savings Plan 约 3100 欧，三年约 2400 欧，换成 x86 按需约 4500 欧。按需价差大约八倍，对着三年承诺大约五倍。

Kirsch 自己列了三个前提。Hetzner 的 CX 系列是共享 vCPU，Graviton 的 vCPU 是一整个物理核，负载跑得动不代表是同类比较。今年 Hetzner 涨了两次价，四月那次约 30%，连已有服务器一起涨，六月针对 CPX 和 CCX 新订单涨了 113% 到 176%。而且他们下的一台机器直接返回了 resource_unavailable，最便宜的那条线现在根本下不了单，Windows CI 只能用更贵的型号顶，因为便宜的没货。他说自己不敢保证 Hetzner 下周能给他们扩三倍容量。

我在这段里看到的重点不是省钱，是那句「我们整套东西都是代码，换个供应商大概一天就够」。只要对方给一台能 SSH 的机器，Talos 和其余一切都能重建。这句话把前面所有价格对比都变成了可选项，涨价、缺货、条款变更都只影响成本，不影响能不能继续干活。供应商那边还剩 OVHcloud，用来做备份和自托管模型的早期试验，没算进这篇的总额。

监控：Datadog 一个月的钱，够他们跑八年#

指标进 Prometheus 和 Mimir，日志走 fluent-bit 进 Loki，trace 经 OpenTelemetry collector 进 Tempo，最上面是 Grafana。整套跑在内部集群，长期存储放在 Hetzner 的对象存储里。六月他们把 SigNoz 换掉了，理由是难用、bug 多，还得自己写 MCP server。另一个原因是 Claude 用 Grafana 明显更顺手，Kirsch 猜是因为 Grafana 被文档和帖子覆盖得太广，模型在训练里见过太多。

过去七天的量级：每天约 5GB 日志、7GB trace，约一百万个活跃指标序列。内部集群（跟 ArgoCD、Forgejo、VPN 共用）每月 48 欧，监控摊到头上不到 100 欧，这一项是估算，因为账单不按工作负载拆。

同样是 30 天保留期，换托管服务是另一个世界：

Datadog 一个月的钱，差不多能覆盖他们三个 Kubernetes 集群八年。差价几乎全在指标序列上：Grafana Cloud 每千个活跃序列约 5.90 欧，Datadog 把 Prometheus 序列按 custom metrics 计费，每一百个约 4.50 欧。1200 万里那 110 欧是日志和 trace 的部分。100k 那一列的前提是搬到托管之前先砍基数。Kirsch 的吐槽是：「我们从没开过一次会讨论哪些指标是我们养得起的。」

还有一层变化在用法上。Grafana 的 MCP server 把 Loki、Mimir、Tempo 变成 Claude 手上的工具，排查问题通常从 Claude 自己查日志和 trace 开始，而不是人先截一段粘贴进对话框。有个定时任务扫生产和 staging 的日志，按指纹分组错误，每冒出一个新指纹就开一个 issue。这篇文章里的容量数字，就是他在写稿时通过同一个连接拉出来的。

这里省下的不只是钱。查一个 bug，agent 随手跑五十个探索性查询很正常，托管商的 MCP server 也接得上，但那些查询是要计费的。自托管把「查询」从按次计费变成固定成本，agent 才敢放开手脚试错。另外，工具能不能被 agent 用好，跟它在训练数据里的密度直接相关，这条标准以前没人拿来选型，现在得算进去。

代码评审：把 Codex 挪到 PR 出现之前#

CodeRabbit 的客服曾经形容他们的用量「不正常」。那时候他们买的是 Pro+，也就是当时最大的自助套餐。典型的早晨是这样：它审完前两三个 PR，然后撞上速率限制，没审的 PR 堆在那儿。他们不合并没审过的代码，于是双方都在等。实际算下来，大概五个 PR 里只有一个能在需要的时候拿到评审。

CodeRabbit 的限制按每个开发者每小时算。三个人各自开着好几个 agent，产生的 PR 和修复轮次远超这个额度。钱从来不是问题，三个座位按现在最高的公开套餐算还不到 200 欧一个月。另一个代价是评审发生在 PR 打开之后：每一轮修复都要再推一次代码，CI 重跑一遍，又从小时额度里吃掉一次评审。再加上 CodeRabbit 不在支持列表里放 Forgejo，一个月后这件事也会自己结束。

现在的做法是把评审挪到 PR 之前。Claude 做完一块活，先在本地分支提交，然后拿 Codex 审：

codex review --base origin/main -c model_reasoning_effort="xhigh"

审的人（或者说审的模型）用 GPT-6.1 Sol 或 GPT-6 Astra，永远开到最高推理强度，不用小模型顶。拿到意见后 Claude 逐条处理：真问题是 bug 就改，判断错的就写一份书面反驳。然后 Claude 回到同一个 Codex 会话继续问：

codex exec resume "$SESSION" \
  "We addressed your findings in commit <sha>. Finding 2 is not a bug because ...
   Judge each of your findings: is it resolved? Did the fixes introduce anything new?"

反复到 Codex 接受每一条修复或反驳、并且报不出新问题为止，之后才推分支、开 PR。用 resume 接回旧会话是这里的关键机制：Codex 保留着之前的意见、Claude 的答复和后面的改动，重开一个新会话反而会把已经被驳回的意见再提一遍。那些每轮都要重复的规矩写进 AGENTS.md，Codex 开审前会读。评审额度包含在 OpenAI 订阅里，不另计费。

Git 和 CI：从 GitHub 搬到 Forgejo，跑自己的机器#

离开 GitHub 的起因是几次宕机直接停掉了部署。生产出问题的时候，刷新 githubstatus.com 不是一个 CTO 想花掉一小时的姿势。同时 Actions 账单正在逼近每月 900 欧，三个人用。托管 runner 还慢，Windows 和 macOS/iOS 构建最明显。

自托管 runner 能解决钱和速度，解决不了宕机，因为每个 job 还是要靠 GitHub 的控制面。2025 年 12 月 GitHub 宣布从 2026 年 3 月起对自托管 runner 上的 job 收约每分钟 0.2 分的费用，48 小时内又撤回了。Kirsch 的原话是：他不想把自己的预算建立在一个已经试图对「你自己的硬件」按分钟收费的供应商上。

于是他们搬到 Forgejo，GPL 许可的自由软件，由德国非营利组织 Codeberg e.V. 开发。它跑在内部集群里当一个 pod，成本已经算在服务器那 480 欧里。八月开始跟 GitHub 并跑，主分支镜像过去，10 月 7 日 Forgejo 正式成为主仓库，历史完整搬过来了：分支、tag、release，连每个 PR 都保留原编号。写这篇文章时这事发生还不到一周，所以 Kirsch 自己也在文里说了一句「半年后你再来问我」。产品同事也在 Forgejo 里提 issue、跟 issue，不用谁给他们买座位。

CI 跑在自己的机器上：四台 Linux 服务器，一共 24 个并行 job 槽，加一台 Windows 机器（Hetzner Cloud 没有 Windows 镜像，得自己装）。macOS runner 是一台摆在办公室桌上的 M2 Mac mini，走办公室 Wi-Fi，用 NetBird 连进内网，再用防火墙把它跟办公室其他网络隔开。

这些加起来每月约 220 欧，Mac 按三年折旧。GitHub 托管 runner 的 Linux 大约是每分钟半分钱，macOS 是 5.6 分。他们的四台 Linux 服务器折合每月约 21600 个 GitHub Linux 分钟。macOS 那边的差距最大：一台 M6、16GB 内存、512GB 存储的新 Mac mini 税前 1066 欧，摊三年约等于每月 530 个 GitHub macOS 分钟，也就是每天 18 分钟。而在法兰克福的 AWS 上常驻一台 M2 Mac，按小时 0.95 欧、最短 24 小时起租，一个月约 700 欧，这个价钱差不多每七周能买一台新的 Mac mini。

按分钟计费的 SaaS 撞上 agent，会失控，因为 agent 的请求是突发式的，半夜也在跑，而固定容量不怕突发。

AI 订阅：180 欧换来按 API 计价 9000 欧的用量#

每个人两份订阅：Claude Max 20x 约 180 欧一个月，负责写，Claude Code 是主要实现者；ChatGPT Pro 约 90 欧，用来拿 Codex 做评审。一个人 270 欧，三个人 820 欧一个月。他们没有任何按量计费的 API 支出，额度撑得住 Kirsch 平时同时开着的五到九个 agent。

这个分工跟着工作量走，写代码烧的 token 比评审多得多。他还有个明确的原则：要让另一个模型家族来检查 Claude 的活，同时留两家供应商，万一哪家改条款，还有地方挪。这事已经发生过一次：九月 DevDay 上 OpenAI 推出了约 450 欧的 Pro 档，同时下调了 180 欧档的用量，他们那份 90 欧的没受影响。

真正让人心里一紧的数字在这里。ccusage 能拿 API 挂牌价折算本地的 Claude Code 和 Codex 日志。过去 30 天（9 月 11 日到 10 月 10 日），Kirsch 自己的用量折合约 9000 欧 Claude Code 加 680 欧 Codex，对应他实际付的 180 欧和 90 欧。他自己补了一句：不指望这种价格能持续。

这是全文最该记住的一句。订阅价远远低于 API 价，差价是厂商在补贴市场，也就是说现在这套「五到九个 agent 天天跑、评审一律开最高推理强度」的打法，成本结构里有一块是别人临时垫的。真要做预算，我建议拿 API 计价当前提做一次压力测试，算算用量到多少以内还划算，再决定哪些环节可以无脑上 agent。

省下的钱值多少人：他做了个粗糙的人头模型#

不靠 agent，上面这套东西需要人：要么一个平台团队，要么买托管服务加一个小一点的平台团队。Kirsch 把托管路线估到每月 5000 到 5400 欧，还不含 macOS 和 Windows CI。

再看产出。四周里三个人在两个仓库合并了 708 个 PR，不算机器人、release PR 和自动化的机器开通，合每周 177 个，人均约 59 个，都是正常八小时工作日。其中 511 个在应用仓库，每周 128 个。

LinearB 的 2026 基准把单个 PR 改动超过 228 行算作「需要改进」，他们应用仓库的中位数是 548 行，25 分位 180 行，75 分位 1523 行。作为对照，DX 测出不用 AI 的开发者每周合并量中位数是 1.4 个，每天用 AI 的是 2.3 个，高频使用 Claude 的约 4 个；LinearB 把每周超过 2 个算精英水平。

把 PR 数换成人头很糙，Kirsch 自己先承认了。为了把数字压低，他只用应用仓库，拿精英水平每周 2 个当基准，忽略 PR 体积，算出他们应用仓库的合并速度约等于 64 个这样的开发者。然后按一个「缩水系数」打折，再加一个平台工程师去跑托管服务：

薪水按每个资深工程师每月约 8500 欧算，德国正常资深薪加雇主社保，不含招聘、设备和管理的成本。他自己选了 3× 那一行，也就是约 22 人，一年额外薪水约 190 万欧，对着一年约 9800 欧的订阅费。他还专门说了一句，这张表完全没有算协作成本：22 人的团队开会、对齐、排人力都要花真时间，而他们两周开一次回顾，加一个关于工具链的例会，其余随时拉个小会就完事。

这张表是修辞，不是会计。PR 数本来就量不出价值，拿它换人头，误差大到足以掩盖结论。但我认为它问的问题是对的：同一件事，你是买工具、买人，还是自己拿机器跑。如果只看一个数，别看那个 22 人，看 2× 到 10× 之间人头从 33 掉到 7 的跨度，那个区间比结论诚实得多。还有一件他明确坚持的事：项目开头几周，人和模型要一起慢慢来，初始架构他自己定的，早期代码很多是手写的。他觉得正是这个慢启动让后面的配置能跑起来。

代价：护栏、返工率，和一次两小时的故障#

每个 agent 在自己的 git worktree、自己的分支上干活，自己再开子 agent，所以他手上始终同时有好几个功能和修复在推进。他通过 PR 描述跟进这些活，并且早就停止逐行读代码了，量太大读不过来。他说在现在的检查力度下，他信 agent 审过的代码多过人审过的，理由是当顾问那些年见过太多「一个人写、另一个人点头」的烂代码。

应用仓库的检查清单长这样：22 个 CLAUDE.md，各自贴着它管的那块代码；22 个项目 skill，覆盖评审闸门、issue 分流、日志分流、依赖升级、发版；每个改动在变成 PR 之前先过一遍 Codex 评审；每次提交前跑完整构建，包括 lint、类型检查、测试、复杂度、重复代码和死代码检查；覆盖率规则是每个提交对它改动的代码要有远超 80% 的覆盖；测试文件 3596 个，7 月 1 日是 1254 个。规矩严到什么程度：主分支上连一条 lint 提示都没有，别说警告和错误。

七月他们每周合并约 100 个 PR，最近三周是 231、200、194，同期应用仓库的 PR 中位数从 428 行涨到 548 行。DX 跟了四百多家公司，从 2024 年 11 月到 2026 年 2 月，AI 工具使用率平均涨了 65%，PR 吞吐中位数只涨了约 8%，DX 给出的整体收益区间是 5% 到 15%。

有意思的是下面几条规则，每一条都是从具体事故里长出来的。

一轮修复带出新缺陷，是常态。在十几个需要四到八轮评审的 PR 上，某一轮发现的问题通常来自上一轮的修复。所以他们加了一份写死的清单，任何修复提交前都要过一遍：还有哪些地方必须跟着改，这个修复让哪些本来摸不到的东西变得可达，以及最终的 diff 有没有自相矛盾。

有一次他们合并了一个还有五个测试分片在跑的 PR。因为那些检查没设成必需项，自动合并直接放行了。现在 agent 走一个小脚本合并，脚本会重新确认 head commit 上每个检查都是绿的，然后精确合并那一个 commit。

还有一类更隐蔽的：为修复写的测试一直绿着，但不是因为它真的在测东西。有一个测试只检查某个 key 存在，完全不看它的值。现在的规定是每个修复都要靠回滚来验伪，回滚之后，必须正好是为它写的那些测试变红。

效果是返工率稳在合并 PR 的 0.4% 到 1.1%，而每周吞吐翻了一倍，10 月到现在是 0.6%。

但事故还是来了。七月以来唯一一次严重生产故障发生在 9 月 11 日：一次 NestJS 升级让全局限流器开始作用在 WebSocket 消息上，每条消息都抛异常，所有已经升到新版本的用户的聊天应用都不回话了。而 Teams 机器人走 HTTP，还在正常回复，定时任务也还在跑，所以从表面看一切正常，他们花了将近两个小时才发现，之后 40 分钟修复上了线。staging 环境用同样的方式坏了两天，他们没在那里测就上线了。Kirsch 的总结很直接：顺了一阵子，人就松懈了。现在 Claude 有一个 CLI 能自己驱动他们的 Web 应用，staging 由它去测。

最后他们说了下一步：想让开源模型跑在自己的硬件上，接那些小而边界清楚的修复，全程不带人。

我读完之后的三个判断#

第一，这五笔钱能停，共同点是计价方式跟人头绑在一起。按座位、按活跃序列、按分钟、按每个开发者每小时，这些定价模型的前提是「人均产出是有上限的」。agent 把这个上限抬高之后，先崩的就是这类账单。按人头卖的 SaaS，在 agent 时代都要重新定价，这不是他们一家的运气。

第二，省下的那部分收益不是白拿的。中间必须再投回测试、评审闸门和可观测性，否则省下来的是钱，赔进去的是那两小时的故障，以及一次「自动合并带走了没跑完的检查」。Kirsch 那句「我早就不读代码了」之所以站得住，是因为旁边摆着 3596 个测试文件、0.4% 到 1.1% 的返工率、和硬性覆盖率规则。把这些数拿掉，同一个说法就是在赌。

第三，最稳的不是便宜，是能搬走。订阅价对 API 价有五十倍左右的价差，Hetzner 一年涨两次，供应商改条款只要一封邮件。他们的应对办法是把整个基础设施写成代码，换一家只给 SSH 的供应商就能重建，顺手留了 OVHcloud 做备份和自托管模型试验。三个人、一份 AI 订阅、几个自托管组件，这套组合是为他们这个规模选的，抄选型没意义。能抄的是那个顺序：先看清哪些活已经变成「已知工作」，再决定是买、是请人，还是让 agent 在自己的机器上跑。

参考来源：Stefan Kirsch, “What we stopped paying for after agents started writing our code”, amaiko Engineering, 2026-10-11. https://amaiko.ai/engineering/what-we-stopped-paying-for