Claude 写了约 80% 的代码，测试数量涨了 10 倍，CI 任务在半年里涨了 25 倍。

这不是一篇「AI 编程效率又提升了」的新闻。Anthropic 最近复盘的，是一个更不体面的后果，测试影响分析服务被打穿了。扩容顶了 70 天，按包分片顶了 29 天，每日重启甚至撑不过一天。团队最后花了三周，把一套有状态系统拆成可水平扩展的无状态架构。

我看到这组数字时停了一下。很多团队正在认真讨论要不要给 Agent 更多仓库权限、要不要接入自动提 PR、要不要把 Code Review 也交出去。可一旦代码生成速度真的上去，最先变成瓶颈的往往不是模型，也不是 IDE，而是那些平时不显山露水的工程基础设施。

测试影响分析就是其中一个。

代码变快之后，系统会把账算到别处

测试影响分析，Test Impact Analysis，做的事情不复杂。一个提交进来，不必每次都跑完整套测试，而是根据变更文件、依赖关系、历史测试结果，挑出最可能受影响的那一小部分。它的目标不是让测试少跑一点，而是在正确性和反馈速度之间留出可用的工程空间。

没有 Agent 的时候，很多服务能靠经验活得不错。开发者改一段 Java 业务逻辑，提一个 PR，CI 收到任务，分析服务查一遍依赖图，给出测试集合。峰值有，但节奏大体由人的键盘决定。

Agent 改变的不是某一条 SQL 或某一个接口，它改变了请求到达系统的方式。

一个人一天能开多少个分支、推多少次提交、尝试多少种修复，多少受注意力和等待时间约束。Agent 没有这种天然的刹车。它可以并行改多个模块，失败后立刻换一种方案，再追加测试、再跑验证。人看见的是「它今天帮我完成了不少活」，底层服务收到的却是密度完全不同的一串请求。

Anthropic 的数据把这个变化说得很具体。Claude 编写约 80% 的代码后，测试数量增长 10 倍，CI 任务在六个月里增长 25 倍。这里不该把 80% 当成一个可以照搬的行业结论，它属于一家公司的自述，也和仓库、流程、模型使用方式有关。但 10 倍和 25 倍至少提醒了一件事，Agent 带来的不是线性增量。

代码产出翻倍，测试系统并不会只多做一倍工作。新增测试要索引，变更要匹配依赖，任务要排队，结果要写回历史。更麻烦的是，Agent 特别擅长制造大量「看起来很小」的变更。小改动越多，分析请求越碎，缓存命中、热点文件、队列抖动和元数据写入都会变成问题。

速度从来不是免费的。

三个补丁为什么越补越短命

Anthropic 的复盘里有三个阶段，很值得细看。它们不是工程师能力不够，而是每一步都符合一个正在冒烟的现场应对逻辑。

第一步是扩容。机器不够就加机器，容量紧张就加资源。这在短期里当然有效，服务多撑了 70 天。许多团队到这里会松一口气，甚至把图表截图发到周会上。

但扩容解决的是吞吐上限，不会自动消除状态协调。假如每个节点都要维护一份内存状态，或者每次请求都要抢同一个共享资源，节点越多，协调和不一致的成本反而越明显。你加的是马力，车却还卡在一个窄路口。

第二步是按 package 分片，把不同包的任务拆到不同处理单元。这个判断也不奇怪。测试天然带有模块边界，按包路由直觉上能降低相互干扰。它维持了 29 天。

问题在于，真实依赖图并不尊重 package 边界。一个公共库的改动可以波及许多服务，一个生成代码或配置变更又可能跨越传统模块。分片能把平均负载摊开，却容易把热点集中到少数分片。更别提要处理跨分片查询、重新均衡和失败恢复时，系统开始背上一套新的复杂度。

第三步更有现场感，每天重启服务。缓存泄漏、状态膨胀、某些坏连接或堆积队列，重启往往都能暂时清掉。可它不到一天就失效了。

这一步其实已经告诉我们，问题不是「服务跑久了」。问题是每一轮新流量都在重建同样的压力。把水舀出去，水龙头还开着，而且开得越来越大。

我自己的感受是，这三次尝试的共同错误不在于用了补丁，而在于把 Agent 当作普通的流量增长。普通增长可以靠容量规划慢慢追，Agent 工作流更像把生产系统的节拍器拿走了。它能快速制造请求洪峰，也能把原先很少走到的边界路径变成日常路径。

真正要拆掉的是状态，不是服务进程

最终方案听上去并不花哨，改成无状态计算节点，使用内存存储，并用 journal 保存恢复所需的记录。这个组合的重点不在某一种中间件，而在状态边界被重新划分。

一个处理节点如果不持有关键业务状态，就可以随时增加、替换、下线。请求落到哪台机器不再决定结果是否正确，扩容才真的变成扩容。共享状态被放到专门的存储层，计算层只负责计算和调度。journal 则让故障恢复不必依赖某个幸存进程的内存。

这套思路对 Spring 或 Java 团队并不陌生。我们早就知道，Web 服务尽量无状态，Session 不要粘在单机上，消息消费要考虑幂等，缓存不是事实来源。只是测试影响分析这种内部服务，过去的负载不够大，很多设计债没有被追债。

Agent 把账单提前寄到了。

不过无状态也不是一句口号。把状态移出去之后，问题会换位置出现。内存存储的容量、淘汰策略和可用性如何保证。journal 的写入顺序、重放语义和保留周期怎么设计。依赖图更新和测试结果写入是否需要事务。一次重试会不会让同一任务重复计费或重复触发下游。

这些问题不能靠「上 Redis」四个字结束。比如影响分析结果允许短暂过期吗。如果允许，过期会造成漏测还是多测。前者伤正确性，后者伤成本和等待时间。两者都可能发生时，系统该优先选择哪一个。你得在设计里把答案写清楚。

测试选择不是优化题，它是一道风险题

很多人谈 Test Impact Analysis，会把它讲成一个 CI 加速技巧。我觉得这太轻了。

它实际是在预测「这次没有跑的测试，到底有没有可能抓住一个真实回归」。预测错一次，可能只是多跑几分钟。预测错另一次，也可能是缺陷穿过 CI，带着一次看似很绿的构建进入生产。

当 Agent 参与编码，风险模型还会改变。Agent 很会在局部范围内生成自洽的改动，它也更容易在你没注意到的地方扩大修改面。一次任务可能同时碰到实现、测试、配置、构建脚本和文档。若影响分析只盯着源码路径，很可能得到一种危险的快。

你想想看，CI 从 40 分钟降到 8 分钟固然很爽。如果这 8 分钟建立在「我们其实不知道漏了什么」上，它不是效率，是把风险挪到发布后。

因此，影响分析服务至少要有两个不同目标。一个是尽可能减少无意义执行，另一个是对不确定变更保持足够保守。对于依赖图置信度低、生成文件变化、基础构建配置变化、跨服务协议变化这些情况，宁可扩大测试集合，也不要假装精准。

这里可以借用数据库查询优化器的心态。优化器不是永远选最快计划，它是根据统计信息在不完整世界里下注。统计信息陈旧时，聪明的计划可能比笨计划更惨。测试选择也一样，历史数据不再代表当前仓库时，系统应该降级到更保守的策略。

给正在接 Agent 的团队，一份不太讨喜的清单

如果你正在把 Claude Code、Codex 或自建 Agent 接进研发流程，我不建议一上来先问「模型能写多少代码」。先把下面几件事盘一遍。

把请求链路画出来

从 Agent 发起修改开始，画到 PR、Webhook、CI、测试选择、构建集群、制品库、质量门禁、通知系统结束。别只画主链路。重试、取消、超时、重复提交、失败后的自动修复，这些边路往往才是流量放大器。

在 LangGraph 这类编排里尤其要留神。一个节点的 retry 配得随意，外加一个「失败后自动再试」的分支，就可能让同一类 CI 请求成倍出现。人盯着页面时会收手，Agent 默认不会。

为每一个放大器设预算

并发 Agent 数、单任务最大迭代次数、每次 PR 可触发的 CI 次数、每日测试分钟数、队列等待上限，都应该是可观察、可调整的预算，而不是散落在提示词里的愿望。

我是真的觉得，预算不是限制创新，它是让系统能活到第二天的护栏。没有预算的自动化，最后往往靠值班同学的睡眠来限流。

把降级策略写在流量来之前

影响分析服务失准或不可用时，怎么办。全量跑、抽样跑，还是阻断合并。缓存不可用时，是退回静态依赖图，还是直接扩大全量测试。每一种选择对应的成本和风险需要提前定下来。

这听着不够酷，但事故发生时最有价值的东西，常常是一条已经写好的开关和清楚的负责人。

用两个维度看 Agent 产出

除了接受了多少建议、合入了多少行代码，再看两个数字。变更引发的 CI 任务数，以及每个任务的端到端反馈时间。前者告诉你工作流是否正在失控，后者告诉你开发者是否真的更快。

只看代码行数会很容易被漂亮数字骗过去。删掉一千行废代码很有价值，生成一千行未经验证的代码则可能给测试系统寄来一张罚单。

用演练替代乐观估计

Anthropic 最终建议按两季度内 25 倍负载做容量规划。这个数字未必适合每个团队，但它背后的方法很实在，别拿昨天的高峰去推明天的 Agent 系统。

可以先用回放流量或压测，模拟 Agent 同时创建任务、连续修复失败、多个仓库共享构建资源的情形。测试的不只是 CPU 和内存，也要看队列公平性、缓存击穿、数据库连接、下游限流，以及告警能否在用户先发现前响起来。

别把 Agent 当成更快的实习生

把 Agent 当成更快的实习生，是一个很容易让人放松警惕的比喻。它确实会写代码，也确实需要 Review。但它和实习生最大的差别是，它能在没有疲惫感的情况下持续触发整个软件交付链路。

它像一台把产能接到每个小齿轮上的电机。电机装上去以后，慢的齿轮不会自动变快，只会先发热。

Anthropic 这次三周重构的价值，不在于给出了某个通用架构模板。它更像一份提前泄露的故障报告。AI 编程的竞争，下一阶段不会只比谁的模型补全更准，也会比谁能让测试、CI、依赖管理、可观测性和权限体系跟得上。

很多团队还在问「要不要让 Agent 写更多代码」。我更想问另一个问题。

当它真的写得更多时，你的工程系统准备好接住了吗。

资料与边界

本文由 2026 年 9 月 16 日 AI HOT 精选中的 Anthropic 工程复盘整理。文中关于代码占比、测试和 CI 增长、三个临时措施持续时间，以及三周架构重设计，均来自该复盘的公开摘要。不同公司的仓库规模、测试策略和 Agent 使用深度差异很大，文中的容量规划与架构取舍应作为设计检查项，而不是可直接复制的答案。