2026年9月14日，Anthropic在Claude官方博客披露其内部持续集成（CI）系统的扩容经历：随着Claude参与编写约80%的代码，工程团队平均每季度交付的代码量达到2021年至2025年水平的8倍，测试数量增长10倍，而CI任务在短短6个月内增长了25倍。这个案例提醒正在部署编码智能体的团队，开发速度提升后，最先承压的未必是模型或编辑器，而可能是测试选择、队列和状态存储。
临时扩容为什么很快失效
Anthropic先后尝试换更大的机器、按软件包分片和进程故障后自动重启。大机器只多支撑约70天，分片方案约29天后再次触顶，重启更是在不到一天内失去效果。原因在于旧系统把测试历史保存在单个进程内：监听器既接收结果，又计算哪些测试与代码变更相关。任务量快速增加后，计算、内存和状态恢复互相牵制，任何一次滚动部署或崩溃都会放大积压。
重构重点不是继续堆机器
团队随后把架构拆成无状态监听器、内存数据存储和日志式消费流程。监听器可以横向扩展，只负责记录测试结果；独立消费者把事件整理成按测试维护的历史，选择器再依据历史命中与软件包相关性决定需要运行哪些测试。Anthropic称，新系统切换后保持稳定，而且一名工程师借助Claude约3周完成了这项过去可能接近一个季度的工作。
对采用编码智能体的团队意味着什么
- 按极端增长设计：Anthropic建议基础设施负责人预设两个季度内25倍的负载增长，但这来自其自身业务，不应机械套用为行业统一预测。
- 状态与计算解耦：把关键历史留在进程外，才能在工作节点扩容、重启时避免丢失上下文。
- 先监控输入输出：测试事件延迟20分钟，就可能漏掉数万次更新；队列滞后、选择命中率和重复执行量都应成为核心指标。
- 重新核算节省：智能体让代码更快产生，也会增加测试、缓存和算力费用，单看开发产出容易高估净收益。
落地时先做一次容量演练
企业无需等到CI彻底拥塞才行动。可以先统计每次合并触发的测试数、峰值队列时长、历史状态恢复时间和单次变更成本，再模拟5倍、10倍和25倍并发。若系统仍依赖单节点内存或人工重启维持，应优先改造可观测性与状态层。Anthropic的数字不能证明所有团队都会遭遇同样曲线，却给出了一个清晰信号：编码智能体的采购计划必须与软件交付基础设施预算一起评审。
