Optimizing a 200,000-line Python codebase overnight with Gemini 4 Argon

使用 Gemini 4 Argon 在一夜之间优化 200,000 行 Python 代码库 - Google Developers Blog

Google Tag Manager (noscript)

End Google Tag Manager (noscript)

HTML

Gemini

使用 Gemini 4 Argon 在一夜之间优化 200,000 行 Python 代码库

2026 年 10 月 13 日

George Weale

软件工程师

Google Cloud

Bo Yang

Andrew Biernat

开发者营销

分享

• Facebook

• Twitter

• LinkedIn

• 邮件

当新模型发布时，大多数演示展示的是从空文件夹构建的新应用。这些演示虽然有趣，但对经验丰富的软件工程师来说，几乎无法说明模型如何处理现有代码库。

在 Gemini 4 Argon 发布时，我们想测试它是否能在一个更具挑战性的问题上无人值守运行一整晚：在 google/adk-python 项目中发现并修复跨文件性能瓶颈。Agent Development Kit（ADK）是 Google 的开源框架，用于构建和部署企业代理。

该 Python 代码库包含近 800 个源文件，约 205,000 行代码，并由近 17,000 个单元测试支持。

性能优化是对模型的严峻考验，因为你不能只打开一个文件就能发现性能瓶颈。你必须从症状出现的位置以外的视角进行分析，并在整个代码库长期运行过程中保持对整体架构的全局理解。

本文将逐步展示从 11 小时无人值守运行中提取的提示信息、.agents/skills 规则文件以及人工代码审查决策。这次运行将 ADK 的内存会话准备时间在长会话中减少了约 40%，冷启动包导入速度提升了 21%。你将看到最终上线的两个优化方案、在审查中被拒绝的四个方案，以及如何在自己的代码库中设置相同的无人值守工作流程。

图 1：首次模型请求前 ADK 的开销，分别在 50 次和 150 次交互后测量。Argon 的优化在两个时间点都减少了约 40%，因此随着会话时间延长，节省的时间也会增加。

使用 .agents/skills 和 /goal 模式引导运行

目前大多数与编码代理的性能优化工作仍依赖于紧密的人工循环：工程师运行性能分析工具，将模型指向某个热点函数并指定修复方案。我们想看看当只给 Argon 提供团队关心的结果时，它会做出怎样的表现。

第一轮测试中，我们没有提供任何自定义仓库指令，仅给了它以下段落提示：

使 ADK 在任何代理中都不产生明显开销：启动时、长会话中、多代理和工作流设置中。保持模型接收的内容和公共 API 不变，并为每个更改提供一个能检测回归的测试。

第一轮运行持续约两小时。Argon 在 7 分钟后编写了基准脚本，用 70 分钟测量和阅读代码后才开始编辑 ADK 源代码的单行代码，并发现了会话复制和包导入中的真实性能瓶颈。第一轮中的一些代码最终被纳入我们发布的最终提交。

第一轮的不足在于维护者惯例。由于 Argon 不了解 ADK 团队的代码审查方式，它为 ADK 的认证模型附加了一个自定义钩子，微妙地改变了其公共 JSON 架构，在自定义复制器中遗漏了模拟事件的边界情况，仅运行了 216 个邻近单元测试，并且在拉取请求描述中省略了基准数据。

第一轮验证了确实存在显著的性能提升空间，因此我们启动了第二轮测试并进行了两项调整。首先，我们将团队的维护者指南放入仓库的.agents/skills目录中，作为新工程师的入职引导。每个技能都以一个简短的SKILL.md索引文件开头，该文件按需指向具体的参考资料/文件，避免在每次交互时都向代理的上下文窗口灌入过多信息。当Argon在晚上9:11开始运行（图2）时，它首先读取了我们私有_前缀模块规则的visibility.md文件，以及用于延迟加载检查的imports.md文件，之后才开始处理代码。

图2：Argon的首次两小时运行与相同目标下的11小时夜间运行对比。第一轮自行发现了实际的性能提升，而第二轮遵循仓库规范，运行了全部16,892个单元测试，并提交了一个可供审查的拉取请求。

第二项调整是我们在Google Antigravity中启用了/goal模式，该模式在上下文压缩过程中保持目标不变，使代理持续运行直至任务完成。我们还添加了两句话要求生成包含前后数据的未合并拉取请求：

/goal 使ADK对任何代理都不产生明显性能开销：在启动时、长时间会话中、多代理和工作流场景下均如此。保持模型接收内容和公共API不变，并为每个变更配套测试用例以防止回归。提交一个ADK维护者会批准的针对main分支的拉取请求，描述中需包含前后数据。不要合并它。

在仓库中配置了.agents/skills目录并启用/goal模式后，Argon在夜间无人值守运行了11小时（图3）。

图3：Google Antigravity中Argon的ADK夜间运行。/goal提示始终固定在窗口顶部和底部，已完成的工作折叠为摘要块，这样原始规则在数小时的编辑、基准测试和测试运行中始终保持可见。（截图通过公共Antigravity界面重放以去除内部工作区细节。）

经过代码审查后，6项提案中产生了2项上线变更

第二天早上查看夜间会话日志时，一些行为立即引起注意。在接触源代码之前，Argon先读取了12个指南文件，并在四个测试工作负载上运行了基准测试：包启动、200步对话、20个子代理相互传递任务的测试应用，以及运行30次的12节点工作流。即使在完成11小时运行的最后三分钟，Argon仍在审计自己的代码差异，发现自身多代理缓存中的一个bug，并重新运行了全部16,892个单元测试后才自行停止。

更重要的是，Argon完成了剖析器无法替代的跨模块工作。剖析器会告诉你复制会话和导入包需要时间，但它不会追踪40个文件中每个调用者、模拟目标和共享引用，确保优化这些路径时不会破坏现有应用。

总计，Argon的拉取请求在32个文件中提出了6项优化。其中两项优化干净地解决了ADK的核心瓶颈并成功上线生产环境：

1. 在复制之前过滤内存中的会话历史

Argon 对服务进行了更新，使事件过滤在复制之前完成，并用一种快速且循环安全的复制器替换了 Pydantic 的通用深度复制路径。该复制器能够保留共享状态字典和测试模拟对象。

2. 仅在需要时加载重型包

以前运行 import google.adk 会引入用于实时音频和视频流、OpenTelemetry 跟踪以及 Web 服务器（FastAPI 和 Starlette）的模块，即使只是一个基础文本代理也是如此。简单地删除框架顶层的导入会导致下游测试失败，这些测试直接在模块上模拟属性。当 Argon 的二次提交请求从 llm_agent.py 中移除了三个内部流程导入时，所有 16,892 个开源测试通过了，但 Google 内部的 25 个测试目标失败了，因为它们修补了这些确切的属性。发布的修复方案使用了惰性模块访问器，使重型包仅在首次使用时加载，同时保持所有公共属性在测试预期位置的可修补性。

Argon 提出的其他四个优化方案呢？

我们发现模型会提出一些富有创意的解决方案，这些是我们原本不会考虑的。但其中一些创意想法遇到了框架规则限制，因为重大变更不可接受。

图 4：Argon 早间提交请求中的六个优化方案，分为我们发布的两个和代码审查中被砍掉的四个。我们保留了能显著减少实际开销的会话复制优化和惰性导入优化，而舍弃了依赖脆弱状态、私有库内部实现或仅对合成测试有益的四个方案。

在代码审查过程中，我们拒绝了其他四个变更：

• 一个支持多代理的事件缓存使合成基准测试提速 17%，但依赖弱内存引用，若 Python 在垃圾回收后复用内存地址，可能导致跨会话返回过时数据。
• 一个遥测检查读取了 OpenTelemetry 跟踪器实现中的私有属性，可能在库的小版本升级后静默失效。
• 重写 ADK 在每次模型调用前格式化对话历史的方式，使核心代码路径更难阅读，且未改善我们独立保留基准测试的端到端延迟。
• 为工作流事件重放添加的查找索引引入了状态跟踪复杂性，仅对合成重放测试有益，对日常代理运行帮助有限。

这种分工协作正是工作流奏效的原因：代理负责探索，维护者负责取舍。我们将第一轮和第二轮的最佳部分整合为包含 22 个文件变更和 17 个新测试函数的修改。经过 ADK 团队的评审后，该修改以提交说明 "Argon 生成了这些变更" 被合并到主分支。

基准测试结果：ADK 中 "turn" 的定义，以及为什么 158 次操作重要

要理解提交信息中的数字，需要先了解 ADK 对 "turn" 的定义。

当工程师输入提示并获得最终答案时，ADK 将这个过程称为一次调用（invocation）。而 "turn" 是代理每次行动时的内部步骤：调用工具、运行并行工具调用批次或查询 MCP 服务器。

使用代理框架的原因是支持多轮工具调用，每次运行可能在底层发生数十甚至数百次内部操作。

在任何一轮运行之前，我们编写了一个独立的验证基准测试（bench_turn.py），Argon 从未见过这个基准。在 bench_turn.py 中，单个会话通过回合逐步增长，与即时模型和即时工具对抗，因此时钟上的每一毫秒都是 ADK 框架本身的开销。每个回合在返回答案前运行三轮四次并行工具调用，分别在 0、50 和 150 个早期回合后记录 5 个回合的耗时。以下每个数字均为 6 至 12 次运行的中位数，且每次回合在变更前后接收的请求字节完全一致。

我们针对五个基准测试（图 5）将合并提交与上一版本进行对比：

图 5：Argon 更改前后所有五个验证基准中 ADK 框架开销的中位数。长期会话的会话准备时间减少约 40%，包导入时间减少 21%，而新进程首次请求耗时保持不变，因为延迟模块在第一次回合加载。

如何为你的智能体解读这些数据：

• 导入 google.adk 速度提升 21% 立即惠及所有 ADK 用户，加快 CLI 命令、本地开发和测试发现速度。由于延迟模块在智能体运行第一个回合时仍会加载，全新进程到首次模型请求的耗时保持不变（3.07 秒至 3.09 秒）。在生产服务器上，接收实时流量前发送预热请求，避免第一个用户请求承担一次性导入成本。

• 模型前开销减少 40% 适用于 InMemorySessionService，该服务支持 InMemoryRunner、本地评估循环、CI 测试套件以及未配置外部数据库 URI 时的默认 Cloud Run 或 GKE 部署。对于耗时数秒的单次 LLM 调用，人类不会感知到 28 毫秒或 78 毫秒的差异。但在 158 次内部工具调用交互中，这些开销会累积：消除它们可将完整 158 回合运行时间从 65.6 秒缩短至 56.1 秒（近 10 秒的纯框架开销）。外部数据库、SQLite、Gemini 平台、Firestore 和 Redis 会话存储从存储中反序列化而非内存深拷贝，因此此处读取时间无变化。

尝试 Gemini 4 Argon

企业开发者和构建者可通过 Gemini 平台的 API、Google AI Studio 和 Google Antigravity 访问 Argon，模型 ID 为 gemini-4-argon。

查阅模型卡片和开发者指南获取完整的技术规格、令牌限制和迁移说明。

尝试优化后的 ADK

• ADK Python 快速入门

• 在 google/adk-python 中直接查看合并的拉取请求和基准提交

• 如果希望在无人值守运行前向智能体提供仓库的架构规则和 CI 检查，复制 google/adk-python 中的 .agents/skills 布局

发布于：

• Gemini

• AI

• 云服务

• 公告

• 最佳实践

• 学习

• Python

• ADK

• Google Cloud

• AI 智能体

• 解决方案

• 智能体开发套件

上一篇

下一篇

相关文章

列表

AI

案例研究

公告

Gemini 4 Argon 在机器人领域的应用

云服务

最佳实践

外环洞察优先：诊断生产智能体的环境质量智能体

2026 年 10 月 8 日

网络

教程

指南

使用 Gemini 将创意提示转化为交互式 XR 体验

2026 年 2 月 19 日

Google AI Studio

活动

如何构建 Google I/O 2026 保存日期体验

2026 年 3 月 3 日

导航点