本文使用 AI 辅助整理公开资料，代码、运行结果与结论由作者完成并复核。
首发于 CSDN，转载请注明出处。

TL;DR

• Google 让 Gemini 4 Argon 在无人值守的情况下跑了 11 小时，目标是优化约 20.5 万行、近 800 个文件的 ADK Python 仓库。
• 模型提出 6 项优化，最终只采纳 2 项：会话历史先过滤再复制、重包懒加载。长会话准备开销降约 40%，冷启动导入快 21%。
• 另外 4 项被工程师以可靠性、可维护性、兼容性和收益不可测为由拒掉。
• 真正可复用的不是「AI 能改大仓库」，而是这套流程：先测量、再动手、用测试和基准做门禁、人类只审核少数候选。
• 我写了一个零依赖的补丁门禁脚本复现这个思路：一个候选通过，一个因为破坏契约被拒。

1. 事实：一次 11 小时的无人值守重构

根据 Google 开发者博客和 InfoQ 的报道：

• 目标仓库：google/adk-python，Google 开源的 Agent 开发框架
• 规模：约 20.5 万行 Python，近 800 个源文件，约 1.69 万个单元测试
• 模式：Antigravity 的 /goal 模式，11 小时无人值守
• 第一轮约 2 小时：第 7 分钟先写基准脚本，花了 70 分钟测量和读代码，才改第一行
• 第二轮：把团队维护规范写进仓库的 .agents/skills 规则文件，再跑一轮
• 结果：6 项优化提案，2 项被采纳
  • 会话历史：先过滤事件，再复制，长会话内存准备开销降约 40%
  • 包导入：重包懒加载，冷启动导入时间快 21%
• 在 158 轮工具调用的测试里，框架开销从 65.6 秒降到 56.1 秒

报道里还有一个容易忽略的细节：被拒的 4 项，理由不是「AI 写得不好」，而是可靠性、可维护性、兼容性、以及性能收益无法测量。

2. 为什么「改现有代码」比「从零生成」难

从空目录生成一个 demo，模型只需要满足「能跑」。改一个 20 万行的仓库，约束条件完全不同：

• 跨文件依赖：性能瓶颈常常不在症状出现的地方
• 隐式契约：某个函数看起来可以内联，但外部可能依赖它的副作用
• 测试覆盖：1.69 万个测试是资产，也是约束，改错一个假设就会红一片
• 维护者偏好：命名、分层、错误处理风格，代码里不一定写得出来

Google 的做法是把这些约束显式化：先把维护规范写进 .agents/skills，再让模型在规则内提案。这一步比换更强的模型更重要。

3. 6 个提案，4 个被拒：这才是正常结果

很多人看到「AI 改了 20 万行代码」会默认成功率很高。实际是 2/6。

被拒的四类原因，基本覆盖了 AI 重构的典型风险：

拒绝原因	典型表现
可靠性	在边界条件下行为不一致，测试没覆盖到
可维护性	为了性能引入难以理解的技巧
兼容性	改了公开 API 或隐式契约
收益不可测	基准波动大，无法证明真的更快

这四条其实也是人类工程师做重构时最容易被 review 打回的原因。AI 没有引入新问题，只是把提案速度放大了。

4. 复现：一个最小补丁门禁

Google 的流程里，人工 review 是最后一道闸门。但在人看之前，可以用确定性检查先筛掉大部分不合格提案。

我搭了一个最小示例：一个 prepareSession 函数，基线实现是「先复制全部事件，再过滤」；候选 A 改成「先过滤，再复制」；候选 B 为了更快，直接返回原对象引用。

门禁做四件事：

1. 在临时目录里替换实现
2. 跑单元测试
3. 跑基准，要求中位耗时至少改善 15%
4. 限制改动行数，超过 30 行直接拒

核心逻辑：

const testRun = run(['--test', 'session.test.mjs'], dir);
const testsPass = testRun.status === 0;

const benchRun = run(['bench.mjs'], dir);
const bench = benchRun.status === 0 ? JSON.parse(benchRun.stdout.trim()) : null;

const changed = diffLines(baselineSrc, src);
const sizeOk = changed <= 30;
const faster = bench ? bench.medianMs <= baseline.medianMs * 0.85 : false;

const reasons = [];
if (!testsPass) reasons.push('单元测试失败');
if (!bench) reasons.push('基准测试无法运行');
if (bench && !faster) reasons.push(`性能未达 15% 阈值（${bench.medianMs} ms）`);
if (!sizeOk) reasons.push(`改动 ${changed} 行，超过 30 行上限`);

实际运行结果：

基线中位耗时：9.02 ms

[ACCEPT] 先过滤再复制
  改动行数：6｜测试：通过｜中位耗时：1.64 ms
  结论：全部检查通过

[REJECT] 直接返回引用
  改动行数：5｜测试：失败｜中位耗时：1.65 ms
  结论：单元测试失败

共 2 个候选，采纳 1 个。

候选 B 的耗时和 A 几乎一样，但它破坏了「返回副本」的契约，测试直接拦下。如果只看性能数字，它看起来是个好优化——这正是为什么不能只跑基准。

5. 把这套流程用到自己的仓库

如果要让 Agent 参与真实项目，我建议按这个顺序落地：

5.1 先有基准，再让模型动手

Google 的 Agent 第 7 分钟就写了基准脚本。没有基准，「优化」无法验收，最后只能靠感觉。

5.2 把规范写进仓库

.agents/skills 这类规则文件，把「我们不允许什么」变成模型每次都能读到的上下文。比在 prompt 里临时叮嘱可靠。

5.3 门禁必须自动化

测试、基准、改动规模、公开 API 兼容性，这四项都可以脚本化。人只看通过的候选。

5.4 一次只接受小改动

6 行换 80% 的性能提升，比 500 行的大重构更容易 review，也更容易回滚。Google 最终采纳的也是两处局部优化。

5.5 保留完整的测量记录

包括基准脚本、机器配置、样本量、每轮结果。否则「快了 21%」无法复现，也无法判断是不是噪声。

6. 边界与风险

• 本文的补丁门禁是玩具级实现，只覆盖单元测试和简单基准，不能替代真实 CI。
• 基准测试本身可能被「优化」——Agent 如果同时能改测试和基准，就会产生 reward hacking。
• 大规模重构还需要类型检查、集成测试、灰度发布和回滚预案。
• Google 的案例是单一仓库、单一任务，不能直接外推到所有项目。

7. 总结

这次 11 小时运行最值得记住的数字，不是 40% 和 21%，而是 2/6。

AI 能提出很多改动，但真正能进主干的很少。工程上的价值不在于让模型多写，而在于把「测量、约束、门禁、回滚」做扎实，让那 2 个正确的改动被安全地放进来。

先把基准和测试补齐，再谈让 Agent 改代码。顺序反了，产出只会是更多需要 review 的补丁。

参考

1. Google Developers Blog《Optimizing a 200,000-line Python codebase overnight with Gemini 4 Argon》：https://developers.googleblog.com/optimizing-a-200000-line-python-codebase-overnight-with-gemini-4-argon/
2. InfoQ《Google Optimizes Agent Development Kit’s 200K-Line Python Codebase Overnight with Gemini 4 Argon》：https://www.infoq.com/news/2026/10/google-argon-optimizes-adk/