Agent 把 CI 打爆了：测试影响分析怎么扛
Agent 写得越快，PR 越密，测试套件越肥，CI 队列就越容易先崩。Anthropic 工程侧公开过一组量级：相对 2021–2025 的习惯，工程师每季度交付代码大约 8 倍，其中 Claude 作者约占 80%；测试量大约 10 倍；半年内 CI job 大约 25 倍。写代码不再是瓶颈——评审提速之后，下一堵墙往往是流水线。
对 Claude Code 用户同样成立：并行会话多了、Agent 顺手补测试，队列会跟着炸。下面用 deterministic 测试影响分析讲清他们怎么扛，以及小团队能抄哪几条，不照搬整套架构。
写代码快了，CI 成下一瓶颈
以前「人写得慢」天然限流。现在模型把实现压短，人更多时间在审 diff、合并、盯红灯。若每个 PR 仍全量跑测，排队时长会按 PR 频率线性（甚至超线性）涨。
合理目标不是「永不失败」，而是：每个 PR 只跑与这次改动相关的子集，全量留在主干或夜间。这就是测试影响分析要解决的事。
确定性测试影响分析在干什么
他们用的是确定性方案，而不是「让模型猜该跑哪些用例」：
- Listener（监听）：持续记录 CI 里各测试的结果与归属（包、历史命中等）。
- Selector（选择器）：开 PR 时，根据历史命中 + 包相关性，选出本 PR 该跑的子集。
原则很直白：不是每个测试都在每个 PR 上跑。相关度靠可复现规则，方便排查「为什么没跑到这条」。
监听滞后：选错用例比少跑更烦
监听若落后（例如约 20 分钟），选择器看到的是旧世界：
- 刚修绿的用例仍被当成红灯相关，多出来一堆无效排查
- 偶发 flaky 红灯被放大
- 新建或刚修好的测试，可能根本没进本 PR 的集合
影响分析的价值取决于「历史有多新」。机器再大，数据陈旧，选择器也会带偏。
v0 单例怎么扛不住，又怎么改
第一版 listener 是 singleton（单写者）。负载涨上来之后，补丁依次失效：
- 先换更大机器——顶一阵
- 再按 package 级分片——大约撑了 29 天
- 再靠 每日重启——撑不住一天；重启本身又让监听掉队更远
根因不是「机器不够大」，而是状态塞在进程里，扩写者、重启、追历史都会互相踩。
重做方向（约 1 名工程师、3 周量级）：
- 进程内改为内存 store / journal，listener 无状态，只负责追加
- 单独的 consumer 把 journal 滚成可查询历史
- selector 只做查找，不背写入压力
经验收成三条：按两个季度规划约 25 倍 CI 负载；状态别留在进程里；把「进队列 / 出队列」的 job 数做成可观测指标，确保 in ≈ out，别静默积压。
Claude Code 用户：你的队列也会一起涨
本地用 Claude Code 时，常见叠加是：
- 多开并行会话，一天产生更多小 PR
- Agent 主动补单测 / 集成测，suite 变厚
- 人还没改完合并习惯，CI 仍是「每 PR 全量」
结果是：写代码爽了，等绿灯更烦。CI 里用 Claude 本身（例如非交互打印）和「Agent 制造更多要测的代码」是两件事；脚本侧用 -p / --bare 时别误加载本机配置，见 脚本和 CI 里跑 Claude。
小团队可落地的几条
不必一上来自研整套 listener / consumer：
- 别让每个 Agent PR 全量跑测——按目录、包名或变更文件做粗粒度选择，也比全绿全红强。
- PR 尽量小——影响面小，选择器（哪怕是脚本规则）更准，回滚也便宜。
- 盯队列滞后——平均等待、积压 job 数、flaky 占比，比「机器是不是最新」更早报警。
- 全量测放到主干或定时——PR 上求相关子集，主干求信心。
- Agent 写测试时约定范围——要求「只覆盖本次 diff」，避免一次会话灌进无关大文件测试。
并行用法与额度节奏，可对照 使用模式；权限与沙箱仍建议收紧，见 权限与沙箱。
小结
Agent 把交付速度乘上去之后，CI 会先以「队列」而不是「编译器」的形式喊疼。确定性测试影响分析用监听 + 选择器减负，但监听滞后会选错用例；单例写者扛不住 25 倍级增长，要把状态挪出进程并观测进出流量。小团队先做「非整仓每 PR」、小 PR、盯滞后，再谈更细的影响图。