待验证｜Anthropic称CI作业增25倍

这篇稿件按低置信处理。可核验的新增点是 Claude by Anthropic 在 9 月 14 日发布工程复盘，页面描述为「CI job volume increased 25x over 6 months」。这组数字来自 Anthropic 自述，未公开原始日志、完整样本和外部复现，因此不能直接等同为行业普遍数据。

它仍值得进入深挖，因为文章把 Agentic coding 的副作用放到 CI、测试选择和结果索引层。代码生成与评审都被加速后，等待验证、判定 flaky、同步历史结果会先成为新的排队点。

本文的英文口径只按原文时态翻译。increased 25x over 6 months 写作「过去 6 个月增长 25 倍」；grew 10x 写作「测试数量增长 10 倍」；has remained stable since 只表示重构后保持稳定，不改写成新的性能提升。

对工程团队最直接的影响是预算和架构假设。过去可以用“买更大的机器”争取一个季度，如今在 AI 参与写代码和评审后，同样的补丁可能只买来几周甚至不到一天。

这次新增的是什么

Claude by Anthropic 的文章标题是 “Agentic coding is straining CI. Here’s how we scaled test impact analysis at Anthropic”。页面元数据和正文都显示发布时间为 2026 年 9 月 14 日，作者为 Sachin Malhotra，分类落在 Claude Code、Enterprise AI 和 Product。

文章给出的核心链条很清楚：Anthropic 工程师平均每季度发货代码量相较 2021 到 2025 年增长 8 倍，其中 Claude 被归因为 80% 的代码作者；代码库测试数量增长 10 倍，工程师人数只是小幅增加；这些因素共同带来 6 个月内 25 倍 的 CI 作业增长。

这些数字不能被写成独立审计后的行业指标。更稳妥的读法是：Anthropic 在内部观察到 AI 编程让验证系统承压，并用一篇公开复盘解释它为什么把测试影响分析服务从单进程状态机改成可水平扩展的架构。

采集侧还有一层边界。当天官方博客列表没有命中 Anthropic 新闻列表，Discovery 通过 AI HOT 找到该 Claude 博客条目，再回源到 Claude 页面核验正文和日期。因此，这条作为“9 月 14 日新增复盘”成立，但信源强度仍低于完整官方新闻稿、论文或公开仓库变更。

CI为什么先被压垮

Agent 写代码的短期收益通常被描述成产出提升。对 CI 来说，产出提升会转化成更多 PR、更细粒度变更、更多自动评审、更多测试运行，以及更多需要回写到测试历史里的结果。Anthropic 的复盘把这种变化说得很具体：写代码不再是约束后，PR review 一旦也加速，CI 就开始感到压力。

测试影响分析服务本质上是在回答“这次变更该跑哪些测试”。Anthropic 原有服务由两个确定性组件组成：listener 记录每一次 CI 运行的测试结果，selector 读取历史结果并根据 package 相关性和过往表现决定新 PR 要跑哪些测试。

这个设计在普通增速下可以工作。问题出在多条 CI 作业每秒进入时，listener 会落后于 PR 队列。原文举例说，20 分钟 的 listener lag 可能意味着数以万计的测试更新没有应用到 selector。风险集中在 selector 使用过期历史：已修好的测试暂时不跑，新加测试延后纳入，广泛 flaky 或 widespread-failing 的测试继续制造红灯。

对人类工程师来说，这类噪声还能靠经验过滤。对 agent 来说，反馈更依赖机器可读、及时和可复现。如果测试集本身包含过期或无关失败，agent 可能在错误目标上反复迭代。这也是这篇文章的工程价值：它把“AI写代码”带来的压力，从 IDE 体验推到了 CI 数据平面。

Anthropic的补丁账本

Anthropic 复盘中最有信息量的部分，是三次补丁为什么越来越短命。它提供了一个工程信号：Agentic coding 改变了增长曲线，单次吞吐只是表层结果。

阶段	原文描述	中文口径	边界
初始压力	by October of last year	2025年10月已出现压力	未给具体作业数
补丁一	doubled the cores	服务核心数翻倍	只是临时扩容
补丁二	bought us 29 days	分片方案维持29天	单源内部复盘
补丁三	less than a day	每日重启维持不到一天	不能解读为CI失效
重构后	has remained stable since	重构后保持稳定	没有公开SLO曲线

第一次补丁是买更大的机器。作者明确说团队知道这只是短期办法，但当时所有权不清晰，CI 团队还有更高优先级事项。这是很多平台团队熟悉的局面：服务已经是关键依赖，但在没有事故前很难争到重构资源。

第二次补丁是 sharding。服务原来需要一个 writer 维护全局测试历史，后来把约束拆到 package 维度，让每个 package 保留自己的顺序。Claude 生成了把 package 状态拆成 shard、每个 shard 配独立 worker 的代码。这个方案也被作者称为短命，实际只买来 29 天。

第三次补丁是每日重启。到 2026 年 3 月，单进程服务在多数工作日下午到达内存上限。团队只找到 4 个 bug，替换内存分配器没有解决问题，直接做内存 profiling 又会增加单点风险。重启甚至让服务逐步落后，几次出现超过一小时的积压。

最后的重构把状态移出进程。新的 listener worker 不再把所有历史握在内存里，而是把结果追加到 in-memory store 的 journal；一个独立 consumer 每几秒把 journal 汇总成 per-test history；selector 再快速查询相关历史。这样做更贵，但比抖动的单进程更容易扩容和 profile。

口径核查

这篇文章里有几处英文表述容易被翻译得过满，尤其是 Anthropic 内部指标和作者建议。早报采用保守写法。

英文原文	本文写法	不外推的部分
Our CI job volume increased 25x over 6 months	6个月内CI作业量增长25倍	避免外推为所有团队都会25倍增长
Claude authors 80% of that code	Claude被归因为80%代码作者	避免外推为80%生产代码完全自动生成
has remained stable since	重构后保持稳定	避免写成稳定性再次提升
assume your architecture will be at a 25x load within two quarters	建议按两个季度25倍负载规划	作者建议，不构成服务承诺
account for 10-20x the perceived scale	v0设计可预留10到20倍表观规模	受预算约束，非强制最佳实践

这些限制会影响结论强度。Anthropic 的数据对“AI原生团队会遇到什么瓶颈”很有启发，但它只适合作案例，不具备基准测试属性。没有公开的 PR 数、测试数、CI 作业绝对量、失败率、成本曲线和第三方对照，就无法判断 25 倍 到底来自更多代码、更多小 PR、更激进的测试策略，还是内部工作流重新分解后的计数变化。

背景材料可以帮助理解它为何可能扩散。Claude Code 文档把产品定义为可读代码库、编辑文件、运行命令并接入开发工具的 agentic coding tool；GitHub Actions 与 GitLab CI/CD 文档则显示，Claude Code 已经被设计成能在 CI 工作流中响应 issue、MR、PR 评论并读取测试结果。Anthropic 8 月的 Claude Tag CI/CD 文章还披露，Claude Tag 已被用作 CI/CD 事故第一响应者。

这些背景不能证明 9 月 14 日文章里的指标，却能解释它为什么重要：AI 编程系统正在从“写代码工具”进入“验证、响应、修复、复盘”的工程闭环。CI 不再只是模型行动后的外部检查，它正在成为模型行动本身的一部分。

对团队的直接含义

第一层影响是测试选择会从优化项变成基础设施。过去只有超大 monorepo 或高成本测试集才认真做 test impact analysis。Agent 提高 PR 频率后，即使中等规模团队也会遇到“全量测试太慢、选择测试又依赖历史正确性”的两难。

第二层影响是可观测性要为 agent 设计。Anthropic 作者建议让服务成为 Claude 的“eyes and ears”，并强调进入和流出的 CI 作业数量要一致。换成更通用的工程语言，就是要把队列深度、处理延迟、丢失事件、selector 命中原因和 flaky 状态暴露成 agent 能读懂的信号。

第三层影响是单点状态机会更快过期。单进程、单 writer、内存态历史在人工节奏下可以撑很久；在 agent 夜间和周末也能推 PR 的节奏下，负载底线被抬高，峰值仍然由人类审批和业务节奏触发。扩容策略需要同时处理底噪上升和突发排队。

第四层影响是成本口径会重新谈判。测试选择减少了不必要的测试，但为了维护新鲜历史、分布式 journal、结果索引和更多 worker，平台侧会有新的固定成本。工程负责人需要一起比较验证延迟、误跳测风险、flaky噪声和agent反馈质量，而不能只在“全量跑测试”和“省测试成本”之间二选一。

后续看什么

接下来最值得跟的是公开证据是否补齐。Anthropic 如果能披露更完整的架构图、SLO、队列曲线和失败分类，这篇复盘的参考价值会明显上升。若始终只有作者叙述，读者应把它当成“强工程线索”，暂不作为成熟行业基准。

第二个观察点是 CI/CD 厂商的产品动作。GitHub Actions、Buildkite、CircleCI、GitLab 和 Bazel 生态如果开始把 agent-aware test selection、结果索引和 flaky 解释做成显式卖点，就说明 Anthropic 遇到的问题正在变成一类产品需求。

第三个观察点是 Claude Code 类产品是否把“验证预算”前置到任务规划。一个可靠 agent 不应只会写补丁，还要能估算测试范围、选择最小验证集、解释为什么某个失败与本次变更相关，并在重试前检查历史数据是否已经过期。

组织流程也要跟上。Anthropic 的案例里，每个 PR 仍有 named human owner，合并仍需要批准，CI gates 仍然存在。这一点比 25 倍 数字更重要：AI 可以提高吞吐，但最终责任链如果不清楚，验证层承受的是未归属的风险。