Anthropic 自己的 CI 被 AI 写垮了：三次补丁，70 天、29 天、不到一天

Wed, 28 Oct 2026 00:00:00 +0800

你有没有经历过这种场面：让 AI 改一个功能，它很快甩给你一份 diff，你合并、提交，然后盯着 CI 慢慢转圈。

一开始是几分钟。

后来变成几十分钟。再后来，你开始在心里算：这一单要等多久才敢提交。

写代码这一环确实快了。慢的是别的东西。

2026 年 9 月 14 日，Anthropic 的工程师 Sachin Malhotra 在公司博客上发了篇文章，标题很直白——《Agentic coding is straining CI》。讲的是他们自己的持续集成服务，怎么被 AI 写代码的速度拖垮，又是怎么重写活过来的。

瓶颈不在写代码，在 CI

“Anthropic engineers on average ship 8x as much code per quarter as they did from 2021-2025. Claude authors 80% of that code and it also plays a large role in reviewing and approving PRs as well.”

每个季度交付的代码量，是 2021 到 2025 年平均水平的 8 倍。Claude 写下其中 80%，同时在 PR 的评审和批准环节也扮演重要角色。

而测试量涨了 10 倍，工程师只「名义上」增加了一点。

结果就是 CI 作业量在半年里涨了 25 倍。

“On top of that, the amount of tests across our codebase grew 10x and we added a nominal amount of engineers. This all led to a 25x increase in CI jobs over a six month period”

测试只涨了 10 倍，CI 作业却涨了 25 倍。多出来的那 2.5 倍是哪来的？

# 10 倍的测试，为什么 CI 作业涨了 25 倍？（示意拼装，非原文代码）
tests_growth = 10 # 原文：the amount of tests across our codebase grew 10x
ci_jobs_growth = 25 # 原文：a 25x increase in CI jobs over a six month period

print(ci_jobs_growth / tests_growth)
# 2.5 —— 每个 PR 触发的测试作业，是原来的 2.5 倍

答案在原文另一处：Claude 偏好更小、更碎的 PR。

“This has changed the shape of PRs over time at Anthropic as Claude prefers smaller, more granular PRs”

PR 变小、变多，每个 PR 又都要走一遍流水线，作业量自然比「测试变多」本身涨得更凶。

“Writing code is no longer the constraint, and once PR review gets accelerated, CI starts feeling the pressure.”

写代码不再是瓶颈了。评审一提速，压力就传导到了 CI。

三次补丁，一次比一次短

Anthropic 的测试影响分析服务（test impact analysis，也叫 test selection）负责判断：这次改动该跑哪些测试。跑全量是跑不动的。

这个服务被压垮过三次。三次都打了补丁，三次的存活时间分别是：

70 天
29 天
不到一天

第一次：换更大的机器。

2025 年 10 月，服务开始显出疲态，连续两天被半夜叫醒。

“By October of last year the service was already showing signs of strain, and we got paged two days straight.”

第一个补丁最简单：把跑这个服务的核心数翻倍。

“The first fix was easy: we doubled the cores running the service. We also knew it would be fleeting.”

他们当时就知道这招是临时的。扛了 70 天。

第二次：按 package 分片。

叫醒它的次数更频繁了。他们开了一个长期会话专门盯着这个服务，一旦 listener 落后超过 50,000 个作业，Claude 就会来戳一下作者。

“Anytime the listener lag would get more than 50,000 jobs behind, Claude would ping me and resume our conversation on next steps.”

Claude 一直在劝他们整个重构，但每次都「我们再打一个补丁」。

“Claude often argued for an overhaul, but we usually settled on another patch.”

2026 年 2 月，他们决定并行化。关键认知是：listener 不需要一个单写者给所有测试结果排序，只需要每个 package 一个单写者。

“Claude generated the code for us to split each package’s state into a shard with its own worker.”

分片代码是 Claude 写的。这次撑了 29 天。他们知道是临时的，但没想到这么短。

第三次：每天重启。

3 月，进程在大多数工作日的下午就撞上了内存上限。

他们试了几条快路：找到四个 bug；换内存分配器，没用；不敢给一个已经满载的单例做内存分析。

“We only found four bugs.” “Swapping the memory allocator as a quick-hack did nothing.” “We didn’t want to risk memory profiling a singleton already under a heavy load.”

最后靠重启撑着。

“Restarting bought us less than a day.”

不到一天。

重启还带来一个更糟的副作用：服务重启之后越来越追不上，落后超过一小时的时候（发生过好几次），大量作业结果根本没被 listener 记下来。

作者说得很清楚：这不代表 CI 没跑，也不代表有没测过的代码进了生产。

“To be clear, this doesn’t mean CI never ran on those PRs, or that untested code was pushed to production.”

真实后果是：测试选择组件拿着过期数据，决定哪些测试该跑、哪些不用跑。

70 天、29 天、不到一天。这不是巧合，是指数负载撞上线性补丁的形状。

根因：状态长在进程里

三次补丁都在同一个位置打转：服务是单进程的，状态长在进程里。

这套服务靠两个部件配合。listener 记录每次 CI 运行产生的测试结果；selector 读这些历史，决定每个 PR 上跑哪些测试。

“A ’listener’ records the test results from every CI run.” “A ‘selector’ reads the test result history and determines which tests run on which opened PRs.”

问题出在「每个测试要保留一份运行历史」这件事上。

“All of this ran as a single process because keeping a running history per test meant a single writer needed to apply the results. This v0 design prevented us from being able to horizontally shard.”

单写者保序，所以不能分片。状态在进程里，所以不能水平扩展。作业量一涨，listener 就开始追不上 PR 队列。

滞后的代价，原文给了具体量级。

“20 minutes of listener lag can translate into tens of thousands of test updates not being applied to the selector.”

落后 20 分钟，就是几万条测试更新没能应用到 selector 上。后果有三类：坏改动合进去，测试对所有人开始失败，引发一串不必要的排查；依赖开始飘，红的 flaky 挡住合并；测试修好了或新加了，要等 listener 追上来才跑，中间夹着回归风险。

重写：三周，一个人

最后他们把整个服务推倒了。

“We gave the test selection service a database, or an in-memory data store to be exact.”

不是磁盘数据库，是内存数据存储。具体做法：

“Now, any listener worker can process any result, append it to a journal in the in-memory store, and move on without holding anything in memory - stateless and hence, horizontally scalable. A small separate consumer process rolls the journal up into per-test history every few seconds, and the selector can look up relevant result history quickly.”

拆成三步：listener 干完活就把结果追加到 journal 里，不在内存里留任何东西；一个小消费者进程每隔几秒把 journal 汇总成每个测试的历史；selector 查历史。

无状态，所以能水平扩。补丁换成了架构。

“This distributed architecture is more expensive to run, but it is much easier to scale and memory profile than a shaky singleton.”

比那个摇摇欲坠的单例贵，但好扩，也好做内存分析。

工期：一个工程师，三周。

“This project took three weeks for a single engineer. A year ago it would have been closer to a quarter.”

一年前，这活儿接近一个季度。journal 开多大、要几个 worker，这些调优基本是 Claude 自己完成的。

上线之后，积压曲线从「每天堆、周比周大」变成平的。

“Queued, unprocessed job-result events, hourly max. Before: a backlog built up most days and grew week over week. After cutover and tuning: flat.”

如果能回到 2025 年 10 月

文章最后，他回答了那个假设题：如果能回去，他会怎么做。

“always plan for the exponential”

第一，别按现在的负载设计。

“My advice to engineering teams is, whether you build or buy, assume your architecture will be at a 25x load within two quarters.”

两个季度内，你的架构要扛得住 25 倍负载。他还说了一句更大胆的：v0 设计里直接按 10 到 20 倍的感知规模来算，预算允许就行。

第二，让服务自己说话。

“Instrument your services to act as Claude’s eyes and ears. It allows Claude to hill-climb and fix problems incrementally much better and faster than we could manually. In particular, ensure that the same number of CI jobs coming in equals the same going out.”

最要紧的一条不变量：进来的 CI 作业数，要等于出去的作业数。

第三，状态别放进进程。

“Keep state out of the process from the start. I’d also avoid running any critical service as a single instance unless you can measure it and any canary changes.”

可以落成这样一份容量契约：

# capacity.yaml —— 按 25 倍负载预留的容量契约（示意拼装，非 Anthropic 原文配置）
load:
 design_for_multiplier: 25 # 原文：assume your architecture will be at a 25x load within two quarters
 v0_design_multiplier: "10-20x" # 原文：account for 10-20x the perceived scale in your v0 designs

state:
 keep_out_of_process: true # 原文：Keep state out of the process from the start
 single_instance_allowed: false # 原文：avoid running any critical service as a single instance

health:
 jobs_in_equals_jobs_out: true # 原文：the same number of CI jobs coming in equals the same going out
 listener_lag_alert_jobs: 50000 # 原文：the listener lag would get more than 50,000 jobs behind

Anthropic 这篇文章真正值得带走的不是「要重写」这个结论——很多团队还没到那一步。是那个衰减曲线。

70 天、29 天、不到一天。你打的每一个补丁，都是在给一条正在变陡的曲线续命。而补丁的有效期本身就是一个信号：它变短了，就该重写，不是该升级。