Gemini 4 Argon 连夜优化 20 万行 ADK 代码库：6 项提案为何只合并 2 项

Google 工程团队把一个真实的大型 Python 项目交给 Gemini 4 Argon，要求它在不改变公共 API 和模型输入的前提下，寻找并修复 Agent Development Kit（ADK）的性能瓶颈。模型在约 20.5 万行代码、近 800 个源文件的代码库中无人值守运行 11 小时，最终提出 6 项优化；维护者审查后只合并其中 2 项。官方报告称，长会话中的内存会话准备时间降低约 40%，google.adk 包导入时间缩短 21%。

这次实践的重点不只是模型能否写出优化代码，更是它如何测量基线、理解仓库约定、运行完整测试，以及人类如何拒绝风险过高或收益不足的改动。以下根据 Google Developers Blog 原文整理。

一、为什么用真实代码库测试 Gemini 4 Argon

新建应用的演示很难说明编码 Agent 能否胜任维护工作。ADK 是 Google 用于构建和部署智能体的开源框架，仓库包含近 800 个源文件、约 205,000 行代码，以及近 17,000 个单元测试。性能问题散落在多个模块和调用路径中，修复时还要顾及现有 API、测试 mock 和维护者习惯。

团队的目标是降低启动、长会话、多智能体和工作流设置时的框架开销，同时保持模型收到的内容和公共 API 不变，并为每项改动提供能发现回归的测试。代码仓库见 google/adk-python。

图 1：在 50 轮和 150 轮之后，合并的改动都将模型请求前的内存会话准备开销削减约 40%。

二、从两小时试跑到 11 小时无人值守

第一轮没有仓库专属指令，Argon 只收到一个目标描述。它约 7 分钟就写出基准脚本，随后花约 70 分钟阅读代码、测量性能，之后才开始修改 ADK 源码。运行约两小时后，它找到了会话复制和包导入方面的实际瓶颈，部分成果进入最终提交。

但第一轮也暴露出大仓库工作的风险：模型给认证模型增加了自定义钩子，微妙改变公共 JSON Schema；自定义复制器遗漏了模拟事件边界情况；只运行了附近的 216 个测试；PR 描述也没有记录基准测试数据。技术上看似合理的改动，可能因为没有理解项目约定而无法合并。

第二轮前，团队做了两项调整：把维护者指南整理到仓库 .agents/skills 目录，以短小的 SKILL.md 索引按需链接详细规则；在 Google Antigravity 中启用 /goal，让目标在上下文压缩后仍然保留。任务还明确要求向 main 提交带前后基准数据、但不要合并的 PR。

图 2：第一轮自行发现了瓶颈；第二轮在仓库指南和完整测试要求下，提交了可审查的变更。

图 3：/goal 指令持续显示在任务界面中；已完成工作可折叠为摘要，便于长时间运行时持续遵循原始约束。

三、六项优化提案，最终保留两项

过夜任务在接触源代码前先阅读了 12 份指南，并为包启动、200 步对话、20 个子 Agent 交接任务和 12 节点工作流建立基线，每个负载运行 30 次。11 小时快结束时，Argon 还发现并修复了多智能体缓存中的一个错误，并重新运行全部 16,892 个开源测试。

PR 在 32 个文件中提出了六项优化。两项经审查后交付：

1. 先过滤内存会话，再复制历史

旧实现每次读取时都会深拷贝整个会话，再筛选调用方所需事件；即使只列会话、不读取事件，也会复制所有事件。Argon 将过滤移到复制之前，并用更快且可处理循环引用的复制器，替换会话和事件上的通用 Pydantic 深拷贝路径，同时保留共享状态字典和测试 mock 的行为。

2. 按需加载重量级模块

此前执行 import google.adk 会加载实时音视频、OpenTelemetry、FastAPI 和 Starlette 等模块，即便用户只运行基础文本 Agent。简单删除顶层导入会破坏依赖这些模块属性的测试和下游 mock。最终实现使用惰性模块访问器，让重量级包在首次真正使用时才加载，并保留测试需要 patch 的公共属性。

另外四项改动没有通过审查：一个基于弱引用的多 Agent 事件缓存虽然让合成基准快 17%，却可能在垃圾回收和内存地址复用后跨会话返回旧数据；一项遥测检查读取 OpenTelemetry 的私有属性，容易在依赖升级后失效；一项对话格式化重写让核心路径更难读，却没有改善独立留出基准的端到端延迟；一项工作流重放索引增加状态复杂度，但只帮助合成测试场景。

图 4：会话复制和惰性导入的收益清晰、风险可控；其余提案未能同时满足可靠性、可维护性和真实工作负载收益。

第一轮和第二轮中最好的改动被整理为一个 22 文件的提交，并增加 17 个测试函数。ADK 团队审查后将其合并，提交说明为“Argon generated these changes.” 这体现了实际分工：Agent 扩大探索范围，维护者判断改动是否值得长期维护。

四、基准数据说明了什么

ADK 将用户输入提示并获得最终答案称为一次 invocation；模型调用期间执行工具、并行工具组或查询 MCP 服务等内部步骤，则称为 turn。一次 invocation 可能包含几十甚至数百个 turn，因此每一步很小的框架开销会在长任务里累积。

团队另行编写了 Argon 未见过的 bench_turn.py 留出基准。单个会话逐轮增长，模型和工具响应固定为即时返回，使测量更集中于 ADK 自身开销。每轮执行三次交互，每次交互含四个并行工具调用；在已有 0、50、150 轮时分别计时后续五轮。数字采用 6 至 12 次运行的中位数，变更前后发给模型的请求逐字节相同。

图 5：长会话准备开销下降约 40%，导入 google.adk 快 21%；新进程到首次模型请求的时间基本不变。

包导入更快会直接改善 CLI 启动、本地开发和测试发现。首次模型请求耗时仍约为 3.07 秒至 3.09 秒，因为延迟导入的成本转移到了 Agent 第一次实际运行时；生产服务可在接收流量前发送预热请求。

约 40% 的模型调用前开销降低，适用于 InMemorySessionService，包括 InMemoryRunner、本地评估、CI 测试，以及未配置外部数据库 URI 的默认 Cloud Run 或 GKE 部署。在 158 个内部工具交互轮次的完整运行中，时间从 65.6 秒降至 56.1 秒，减少约 9.5 秒框架开销。外部数据库、SQLite、Gemini 平台、Firestore 和 Redis 会话存储不采用这里测量的内存深拷贝路径，因此其读取时间不受这项优化影响。

五、这次案例对编码 Agent 工作流的启示

想在自己的仓库复用这种方式，可以先把成功标准写成结果约束，而不是提前指定代码改法；在仓库放置精简索引和按主题拆分的维护指南；要求 Agent 先建立基线、覆盖真实负载、写回归测试，并在 PR 中报告数据；最后由维护者检查 API 兼容、测试覆盖、私有实现依赖、可读性和真实业务收益。

不要把“通过公开测试”当成合并的唯一条件。ADK 第二轮的开源测试全部通过，但仍有 25 个 Google 内部测试目标因为 patch 位置变化而失败。这个例子说明，仓库规则和消费者约定往往藏在测试、mock 和内部用法里，自动化审查必须结合项目上下文。

六、如何试用 Gemini 4 Argon 与优化后的 ADK

Google 原文称，企业开发者可通过 Gemini Enterprise Agent Platform 使用模型 ID gemini-4-argon，也可查看 Google AI Studio 和 Google Antigravity 的可用性。具体地区、账户权限、Token 限制和价格会变化，请以相应官方控制台、模型卡及开发者指南为准。

ADK 用户可以从 Python 快速入门开始，在 google/adk-python 仓库查看已合并改动，并参考其 .agents/skills 目录设计自己的仓库指南。对 Gemini 模型、API 与开发工具的站内介绍，也可参阅 Gemini 4 指南和 Gemini API 指南。

常见问题

Gemini 4 Argon 是怎样优化 ADK 的？

主要改动是先筛选再复制内存会话历史，以及按需导入重量级依赖。官方报告称长会话准备时间下降约 40%，google.adk 导入速度提升 21%。

为什么六项建议最后只合并两项？

其他建议涉及弱引用缓存稳定性、依赖库私有属性、可读性下降，或只在合成测试中获益。它们没有同时满足可靠性、可维护性和真实负载收益要求。

无人值守运行编码 Agent 是否可以直接合并代码？

这次案例中，团队明确要求模型提交未合并的 PR。完整测试和性能数据降低了审查成本，但 API 兼容、边界行为、私有用法及维护负担仍需要维护者判断。

结语

Gemini 4 Argon 的 ADK 实践展示了编码 Agent 在大型代码库中进行基准测量、跨模块排查和长时间迭代的能力，也说明模型提出的方案必须经过严格筛选。六项提案最终只有两项进入生产，换来了约 40% 的长会话准备开销下降和 21% 的导入提速。复用这类工作流时，应把仓库知识、独立基准、完整测试和人工代码审查一起纳入流程；Gemini 4 Argon 的开放范围与规格则应继续以 Google 官方页面为准。