谷歌让 Gemini 4 Argon 无人值守运行 11 小时，为 ADK 代码库提交两处性能优化
谷歌披露了 Gemini 4 Argon 的一次长时间无人值守运行：智能体在约 11 小时内阅读仓库规范、建立性能基准、修改代码并跑完全部单元测试，最终有两项优化被合入 ADK 代码库，分别把内存会话准备开销降低约 40%、冷启动包导入时间缩短 21%。这件事的意义不只在于提速，更在于模型开始处理“已有的大型代码库”这类工程任务，但评审、调试和测试仍是它无法绕开的后续成本。
背景：改现有代码库，比从零写应用更难
谷歌工程师这次想验证的，不是模型能否从空文件夹搭出一个新应用，而是它能否理解并修改一个已经存在的代码库。后者显然更难。
他们选择的试验对象是自家的 Agent Development Kit（ADK，智能体开发工具包）。这个代码库约有 800 个文件、超过 20 万行代码，包含近 1.7 万个单元测试。工程师给它的任务不是泛泛地“看看代码”，而是做性能调优。
谷歌在总结中提到，性能调优对模型是一项严苛考验：你没法只打开一个文件就找到瓶颈，必须顺着症状出现的路径做交叉分析，并在长时间运行中逐步建立对整个代码库的关联认识。
怎么跑起来的：先定规则，再控制上下文
正式运行前，工程师先做了一轮简短试运行，用来确定提示词里需要包含哪些内容，确保智能体遵守团队的单元测试和基准测试规范。
接着，他们通过配置文件写入代码库专属规则，相当于给智能体准备一份“新工程师入职指南”。同时要求智能体只加载当前任务需要的技能，避免无关内容填满上下文窗口。
最后是专用提示词，并借助 Antigravity 的 /goal 模式，保证在上下文被压缩的过程中任务目标不会丢失。
任务结束后，运行日志显示 Argon 完成了这些步骤：读取仓库规范、建立性能基准、提出优化方案、审查自己的变更，并运行全部 16892 个单元测试。
谷歌特别强调，Argon 做的是性能分析工具无法替代的跨模块基础工作。性能分析工具只会告诉你“复制会话”和“导入包”很耗时，但不会追踪 40 个文件中的每一个调用者、mock 目标和共享引用，也不会确认加速这些路径不会破坏现有应用。
结果：两处改动，40% 与 21%
最终被采纳进代码库的优化有两项，都改进了 ADK 处理会话历史的方式：
- 在复制事件之前先做过滤，减少不必要的复制开销；
- 引入懒加载机制，大型包只在真正需要时才导入。
这两处改动分别把内存会话准备速度和包导入速度提升了约 40% 和 21%。
单看数字，这些开销与智能体运行的总时长相比并不算大。但 ADK 支持跨越数十甚至数百次迭代的多工具交互，微小的性能损耗会在这种长流程中不断累积。
谷歌给了一个具体例子：对单次耗时数秒的大模型调用来说，28 毫秒或 78 毫秒的差异人类根本感知不到；但如果是连续 158 轮内部工具调用，这些时间就会叠加。消除这些开销后，整个 158 轮流程从 65.6 秒缩短到 56.1 秒，减少了近 10 秒的纯框架开销。
对开发者意味着什么：能改代码，但还没法独立交付
这次实验证明，AI 智能体有能力修改真实的大型代码库，并产出可被采纳的改动。不过，它的有效性仍受限于编码之后的工作量：PR 评审、调试和测试。
一个不容忽视的细节是，Argon 产出的 4 项修改在开发者评审时被拒绝，原因包括可靠性、可维护性、兼容性不足，或者实际性能提升没有达到预期。
这与当前 AI 编程、氛围编程（vibe coding）讨论中的一个现实问题相呼应：让模型写出代码只是第一步，验证、评审和维护才是真正的成本所在。智能体可以承担跨模块分析和重复性改造，但最终把关仍然需要人。
关键要点
- Gemini 4 Argon 在约 11 小时无人值守运行中，完成了对 20 万行 ADK 代码库的性能分析与修改，并跑完全部 16892 个单元测试。
- 两项被采纳的优化分别带来约 40% 的内存会话准备提速和 21% 的包导入提速；在 158 轮工具调用流程中，累计节省近 10 秒框架开销。
- 智能体的价值在于完成跨文件的调用链梳理和兼容性检查，这些是传统性能分析工具不会替你做的事。
- 4 项修改在评审中被拒，说明编码之后的评审、调试与测试仍是当前 AI 改代码的主要瓶颈。