背景：性能调优比从零写应用难在哪
谷歌的 Agent Development Kit（ADK）横跨约 800 个文件、超过 20 万行代码，包含近 17000 个单元测试。团队丢给 Gemini 4 Argon 的任务不是「从空文件夹生成一个新应用」，而是优化这套已经运行的基建：不改公开 API、不改模型接收到的内容，还要让现有测试全绿。他们的原话是，处理已有代码库比从零构建难得多（InfoQ 中文）。
难点不在找到某一行慢。性能调优没法只打开一个文件就看出瓶颈，你得沿着症状做正交分析，在长时间运行中把整个代码库的关联建立起来。举个具体的：性能分析工具会告诉你会话复制和包导入很耗时，但它不会追踪 40 个文件中的每一个调用者、mock 目标和共享引用，来确认加速这些路径不会破坏现有应用。这段跨模块的核对，才是真正的工作量。
收益量级也不在单次调用上。对单次耗时数秒的大模型调用来说，28 毫秒或 78 毫秒的差异人类感知不到；但 ADK 支持跨越数十甚至数百次迭代的多工具交互，这些微小开销会复利累积。判断值不值得做，得看调用链长度，而不是单看一个函数的耗时。
方案：目标模式、上下文裁剪、仓库规则三件套
这套方案的核心取舍是：不让模型自由发挥，而是先把工程约束写死，再让它自己找瓶颈。
第一个被排除的选项是「纯性能分析工具驱动」。工具给出热点，但不给出改动的安全边界，模型照着热点改，很容易在 40 个文件的调用链上踩到兼容性。第二个被排除的选项是「一次给足全部上下文」。20 万行代码塞进去只会让上下文窗口被无关文件填满，模型在中后段就开始丢目标。
所以他们做了三件事：
- 先跑一轮简短试运行，确定提示词里必须包含什么，确保智能体遵循团队的单元测试和基准测试规范；
- 用仓库内的规则文件写清楚代码库特定要求，相当于给新工程师的入职指南；
- 指示智能体只加载任务所需的技能，避免填满上下文窗口；再借助目标模式，保证上下文被压缩时任务目标不丢失。
实现要点
仓库规则文件是整个流程的地基。它不需要长，但每条都要能被测试验证：
# .agent/rules.md（片段）
- 任何改动不得修改公开 API，也不得改变模型接收到的输入
- 每处优化必须附带一个在回归时会失败的测试
- 提交前跑全量单元测试，禁止跳过或标记为预期失败
- 性能声明必须给出改动前后的实测数字，不接受"应该更快"
目标模式下的提示词原文是英文，这里给出可直接使用的中文版本，要点在于把「不改什么」和「交付形态」同时写死：
/goal 让 ADK 对任何智能体都不产生可感知的开销：启动时、长会话中、
多智能体与工作流场景下都是如此。
保持模型接收到的内容和公开 API 不变；每处改动都要配一个能捕获回归的测试。
针对主分支开一个 PR，描述里写明改动前后的数字，要能让 ADK 维护者愿意批准。
不要合并。
最后一条「不要合并」不是客套。它把智能体的权限边界卡在「提交候选改动」，评审权仍然留给人。验收命令就是全量测试，没有任何捷径：
python -m pytest tests/ -q
运行日志显示，智能体按顺序完成了这些动作：读取仓库规范、建立性能基准、提出优化方案、审查自己的变更、运行全部 16892 个单元测试。整个过程中无人值守，持续 11 小时。
效果：两处采纳，长会话省下近 10 秒
最终被采纳的两项改动都落在会话处理路径上：一是在复制事件之前先做过滤，二是引入懒加载，大型包只在需要时才导入。前者把内存会话准备开销降低约 40%，后者把冷启动包导入时间缩短 21%。
单看百分比不够直观，看长链路。连续 158 轮内部工具调用交互，消除这些开销后，整个流程从 65.6 秒缩短到 56.1 秒，减少近 10 秒的纯框架开销。这 10 秒不产生任何业务价值，纯粹是框架摩擦。
值得注意的是改动数量与采纳数量的比例。Argon 共产出 6 项修改提案，其中 4 项在开发者评审时被拒，理由分别是可靠性、可维护性、兼容性，以及实际性能提升不达预期。也就是说，采纳率是三分之一。
复盘：最贵的教训在编码之后
最贵的一课不是模型改错了代码，而是编码只占整个工作量的一小部分。谷歌明确表示，智能体修改现有代码库的有效性目前仍受限于编码之后的后续工作：PR 评审、调试和测试。你省下的是写代码的时间，没省下判断代码能不能合的时间。
第二课是「自行审查」不等于「通过评审」。日志里智能体确实审查了自己的变更，但仍有 4 项在人工评审时被拒。自审能过滤掉明显错误，过滤不掉取舍判断——比如某个加速方案在边界场景下引入了维护负担，这类判断需要代码库的长期上下文。
还能怎么改，有三个方向值得试：
- 把评审标准前置成可执行检查。既然被拒理由集中在可靠性、可维护性、兼容性，就把这三类写成规则文件里的硬性条目，让模型在提交前自己跑一遍，而不是等人打回。
- 要求每个提案附带回滚成本说明。性能改动最大的隐性成本是「以后不敢动这块」，让模型显式写出改动的耦合面，评审者能更快判断。
- 把基准测试固化成仓库资产。这次能拿到 40% 和 21% 这两个数字，靠的是先建立性能基准。基准不进入仓库，下一次优化就得从零重来。
至于值不值得用：如果你的代码库有完整测试、有明确性能基准、有能审代码的人，这类无人值守优化的收益是真实的；如果测试覆盖不足，模型跑得越久，你欠的评审债越多。
参考来源
- InfoQ 中文：谷歌用 Gemini 4 Argon 一夜优化 ADK 代码库的 20 万行代码 —— https://www.infoq.cn/article/u4fAoAH5vZPCV4TVqAcO
- InfoQ 英文原文：Google’s Gemini 4 Argon Optimizes ADK Codebase —— https://www.infoq.com/news/2026/10/google-argon-optimizes-adk/