本页目录6
- Claude编写了80%的代码后，PR审查被加速，压力随即转移到CI，六个月内CI工作量增长25倍，测试数量增长10倍
- 原有测试影响分析系统由单进程的Listener（记录测试结果）和Selector（据历史数据挑选要跑的测试）组成，无法水平扩展
- 连续三次打补丁（加机器、按包分片、每日重启）效果依次从70天缩短到29天再到不到1天，治标不治本
- 根本解法是把Listener改造成无状态worker、用可追加的日志（journal）存结果、由独立消费进程汇总，从而实现水平扩展
- 重设计只用了一名工程师3周时间，远低于一年前动辄一个季度的量级，说明晚做不如早做
- 作者建议团队在做架构规划时就假设两个季度内负载会达到25倍，并从一开始就让关键服务无状态、避免单点
本文是对 Anthropic 官方博客《Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic》的中文要点摘要，完整内容以原文为准：https://claude.com/blog/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic
背景：代码写得快了，CI 顶不住了
随着 Claude 深度参与日常开发，Anthropic 内部工程团队观察到一组明显的增长曲线：
- 六个月内 CI（持续集成）工作量增长了 25 倍
- 相比 2021–2025 年，工程师人均每季度代码提交量增长 8 倍
- Claude 编写的代码占比达到 80%
- 代码库中的测试数量增长 10 倍
- 而工程师人数基本没变
文章的核心判断是：「写代码不再是瓶颈，一旦 PR 审查被加速，压力就会转移到 CI 上」。也就是说，agentic coding 把开发流程前端（写代码、review）提速后，后端的测试执行系统首先成为新瓶颈。
原有架构：Listener + Selector
Anthropic 用于减少无谓测试运行的「测试影响分析」系统，原本由两部分组成：
- Listener：记录每次 CI 运行中各测试的执行结果
- Selector：读取历史数据，决定某个 PR 应该跑哪些测试
问题在于，这套系统作为单一进程运行，状态保存在进程内存里，没有办法水平扩展——负载涨上来后，只能靠垂直堆资源硬扛。
三次打补丁，一次比一次短命
在真正重构之前，团队尝试了三轮渐进式修补，但效果递减：
| 补丁 | 做法 | 维持时间 |
|---|---|---|
| Patch 1（10 月） | 换更大的机器，CPU 核心翻倍 | 70 天 |
| Patch 2（2 月） | 按代码包做分片，每个包一个 worker | 29 天 |
| Patch 3（3 月） | 每日重启进程，应对内存溢出 | 不到 1 天，且导致服务数据逐渐落后 |
可以看到，每次补丁能撑住的时间越来越短，说明单纯靠「加资源/分片/重启」这类应急手段，跟不上负载指数级增长的速度，反而让系统状态越来越脆弱。
重设计：从有状态单进程到无状态可扩展架构
最终团队转向了一套「数据库/内存存储」式的架构：
- 把 Listener worker 改造成无状态，可以按需水平扩展多个实例
- 引入一个可追加写入的日志（journal），worker 只管把测试结果写进去
- 由独立的消费进程每隔几秒汇总一次日志，生成历史数据
- Selector 基于汇总后的历史数据做快速查询，挑选要运行的测试
值得注意的一点是投入成本：这次重设计只用了一名工程师、3 周时间，而放在一年前，类似规模的系统改造可能需要一个季度。作者把这归因于及时动手——负载曲线早晚会追上打补丁的速度，越早重构，代价越小。
给团队的建议
文章给出的几条经验，面向正在经历「AI 加速开发」而基础设施吃紧的团队：
- 按指数增长做规划：不要按线性增长预估负载，建议假设架构在两个季度内会面临 25 倍量级的压力。
- 初期设计留足余量：关键服务从一开始就应考虑 10–20 倍以上的容量冗余，而不是等瓶颈出现再补。
- 状态外部化：把关键 worker 设计成无状态，状态统一放到日志/存储层，是获得水平扩展能力的前提。
- 避免单点：不要让承担核心职责的服务长期以单实例形态运行。
- 善用 Claude 做可观测性：文章提到可以让 Claude 充当系统的「眼睛和耳朵」，持续做增量式的监控和优化，而不是等到系统整体崩掉才动手重构。
小结
这篇文章本质上是一次工程复盘：agentic coding 把「写代码」这一环节的产出速度提升了近一个数量级，连带审查、CI、测试等下游环节都要重新评估容量假设。Anthropic 的经验是，面对指数级增长，打补丁式的扩容只能延缓问题，真正省成本的做法是尽早把关键系统改造成无状态、可水平扩展的架构。