Google 的一组工程师最近让 Gemini 4 Argon 在 google/adk-python 这个约 20 万行的 Python 仓库里连续工作了 11 小时。

它给出了 6 项优化建议。人工审过后，真正合进主干的只有 2 项。结果也挺实在，长会话的内存 session 准备时间下降约 40%，包导入快了 21%。

不少人会把这条新闻读成一句熟悉的话，模型终于能自己优化大型代码库了。

我倒觉得，6 变 2 才是整件事里最有价值的数字。

它把 AI 编程从演示视频里那种「给任务，等奇迹」的想象，拉回了工程团队每天都要面对的地方。一个 Agent 不是因为写出了 diff 就完成了工作。它得理解性能目标，提出能被验证的假设，跑过足够可信的实验，接受 review，还要在合并以后留下可以回看的证据。

这听着不浪漫。

但一个能进入生产系统的 Agent，本来就不该靠浪漫。

11 小时里，最稀缺的不是 token

先把事情说具体一点。

Google Developers Blog 对这次实践的描述并不是「无人值守直接改掉 20 万行」。Agent 在仓库里工作 11 小时，提出 6 个优化方向，工程师审阅后选择其中 2 个合并。性能收益来自被接受的改动，而不是那份建议清单本身。

这差别很大。

大型 Java 或 Python 服务里，性能问题往往不像 LeetCode 那样有一条干净的最优解。一次缓存调整可能换来更高的内存占用。一次 lazy import 可能让冷启动更快，却把错误推迟到用户第一次触发某条路径。一次并发改造也许在压测里漂亮，进了真实流量后才暴露顺序依赖。

所以，11 小时并不只是模型多想了 11 小时。更准确地讲，它获得了一段连续的工程上下文，可以读调用链、比较历史实现、运行测试、提出反例，再回头修正自己的判断。

人类工程师处理陌生仓库也是这么干的。先找入口，跑一次基线，怀疑一个热点，改一点，再看数据。区别只是人会在键盘前皱眉，Agent 会在轨迹里留下工具调用。

问题也正出在这里。

如果一条轨迹最后只压缩成「已优化，性能提升」，那 11 小时最有价值的部分就丢了。后来接手的人不知道基线怎么测，不知道另外 4 个建议为什么没进，也不知道那 40% 是哪个场景、什么负载、哪组输入下的数字。

模型可以负责探索，证据必须能够被团队接住。

6 个建议为什么只该收下 2 个

有人会把 6 个建议只合并 2 个看成 Agent 的成功率不高。我不这么看。

在成熟代码库里，拒绝一个「看起来没毛病」的改动，常常比写出它更贵。维护者知道一些 Agent 暂时不一定看得见的东西，比如某个 import 的顺序是兼容性约定，某段看似重复的代码藏着序列化边界，某个慢路径虽然罕见，却是排障时最后一道保险。

一份值得合并的性能改动，至少得经过三道门。

第一道是问题是否真实。没有基线的优化，只是对代码外观的审美判断。比如 Agent 发现对象创建很多，不能直接得出「应该复用对象」。它得说明采样或 benchmark 指向了什么，测试条件是否覆盖了长会话这个目标场景，误差范围有多大。

第二道是收益是否归因。改动后快了，不代表就是这处改动让它快了。依赖缓存、机器负载、预热状态、并发度都可能制造幻觉。尤其是 Agent 可以很快地跑很多次命令，更要防止它挑中一次好看的结果就停止。

第三道是代价是否被看见。性能优化从来不是免费午餐。更少的初始化可能变成更晚的初始化，更激进的缓存可能变成更难回收的内存，更少的校验可能变成未来难定位的错误。维护者拒掉 4 个提案，未必因为那 4 个完全错误，也可能因为它们的证据不够，或者收益配不上复杂度。

这才是我喜欢这次复盘的地方。它没有把「自动跑了 11 小时」包装成无人接管的胜利，而是保留了人工 review 这一段真正的闸门。

对正在做 Spring 服务或 Agent 平台的团队而言，这个姿势比模型榜单更有参考价值。你不需要先追求让 Agent 每次都对。你需要让它每次都能把判断过程变成可审的候选变更。

性能任务，最容易被一句漂亮的结论骗过去

性能优化尤其适合让 Agent 参与，也尤其容易被 Agent 误导。

适合，是因为它有大量可执行动作。Agent 能构建仓库、定位 profiling 入口、跑 benchmark、检查 flame graph、比对前后指标、生成小范围 patch。比起让它凭印象评价架构，这类任务有更清楚的反馈回路。

容易被误导，是因为指标从来不是孤立存在的。

假设一个 Agent 对 Java 的 Spring Boot 服务提出，把某个远程配置在启动期改为异步预取。压测显示启动时间下降了 20%。如果只看结论，这是一张很好看的成绩单。但你还得追问，应用开始接流量时配置是否已经就绪。失败时是降级、阻塞还是带着空配置继续跑。重试是否引入重复请求。可观测性里能否区分配置未就绪与业务故障。

这些问题没有一个是「模型够不够聪明」的问题。

它们都是交付边界的问题。

再把镜头拉回 Agent。一个编程 Agent 既是执行者，也是报告者。它会读取日志、选择命令、解释 benchmark，最后再用自然语言告诉你自己做了什么。假如团队只验收最后一段文字，就等于让同一个角色既出题、答题又判卷。

这不是不信任模型，而是任何工程系统都该有的职责分离。

因此，Agent 交付性能优化时，最小产物不该只有一个 Pull Request。至少还要有以下几样东西。

  • 可复跑的基线，包括命令、依赖版本、数据规模、机器或 CI runner 条件
  • 假设与范围，它优化的是冷启动、长会话准备，还是吞吐和尾延迟，不要混在一起讲
  • 变更清单，每个文件为什么动，哪些地方刻意没有动
  • 前后对比数据，最好有多轮结果和异常样本，而非只给一个峰值
  • 风险与回滚点，缓存、并发、初始化顺序这类改动尤其需要
  • 未采用的提案，它们是怎样被否掉的，后人可以少踩一次坑

有了这些，reviewer 才是在审工程决策，而不是被迫相信一个会写代码的黑箱。

把 Agent 放进 CI，不等于把 merge 权交给它

很多团队现在的第一个冲动是，把 Agent 接进 GitHub Actions 或 GitLab CI，让它自动修 lint、补测试、生成 review。这个方向没问题，但权限和验收别一口气跨过去。

我比较推荐把流程拆成四层。

第一层，侦察

给 Agent 只读权限。它可以读仓库、跑测试、生成 benchmark 报告、列出热点和疑点，不能改默认分支，也不能碰生产凭据。

这一层的产物是调查报告，不是 patch。好处是你可以快速看出它对代码库有没有基本理解，也能积累哪些任务适合交给它。

第二层，候选变更

允许 Agent 在隔离分支提交小 patch。每个 patch 尽量只解决一个假设，比如减少重复的 session 初始化，或者推迟一个不必要的 import。不要让它把五个「顺手重构」打包在同一个 PR 里。

这点很朴素，却常被忽略。diff 越大，review 的成本就越容易超过收益。模型很擅长顺藤摸瓜，工程团队得替它划出停手线。

第三层，独立验证

让 CI 或另一套独立脚本验证核心指标。对性能任务，测试命令不应该由 Agent 的最终回复来证明。对数据库、文件、Webhook 这类有副作用的任务，也要检查终态，而不是只检查工具调用有没有返回 200。

这一步像财务里的对账。账是 Agent 写的，钱有没有到账要由另一套系统确认。

第四层，人的决策

维护者在这里做两件事，判断收益值不值复杂度，判断风险是否符合当前版本节奏。上线前赶一个关键客户的交付，和常规版本的取舍完全不同。Agent 能提供证据，不能替团队承担这个决定。

这四层不是为了把 Agent 关进笼子。恰好相反，它让你可以更放心地扩大 Agent 的工作半径。因为每往前放一层权限，后面都有能接住它的证据和闸门。

对 LangGraph 和业务 Agent，这个教训更直接

写代码的 Agent 至少还有 git diff 可以看。跑业务的 Agent 更麻烦。

一个 LangGraph 流程可能查了 Redis、调了 CRM、发了 Webhook，最后在对话框里说「已完成客户跟进」。如果验收只看这一句，就会漏掉几个要命的问题，CRM 的联系人是否真的更新，Webhook 是否重复发送，失败节点有没有被错误地标记为成功，重试会不会让同一条消息发两遍。

所以我一直觉得，业务 Agent 的完成定义应该被写成一个结构体，而不是一句话。

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "taskId": "follow-up-20261014-001",
  "status": "completed_with_review",
  "expectedState": {
    "crmContactUpdated": true,
    "webhookDeliveryCount": 1
  },
  "evidence": [
    "crm revision 4821",
    "webhook event id evt_7f3a"
  ],
  "humanReviewRequired": true
}

这不是要所有团队突然造一套很重的平台。最开始只要挑一条高频、可验证、失败代价可控的流程，把终态和证据字段补起来就够了。比如知识库同步，成功不该是「文件写好了」，而是目标文件存在、frontmatter 可解析、git diff 符合预期、远端 push 已确认。

你会发现，一旦系统开始保存这些证据，Agent 的问题反而更好查。它哪里误判、哪里没等到异步任务、哪里把 409 当作成功，不再靠翻一大段聊天记录猜。

先把验收物做出来，再讨论无人值守

这次 Google 的案例给了一个相当克制的答案。让 Agent 在大代码库里连续工作是可行的，它能发现真实收益，也能节省工程师在侦察阶段的时间。但这不等于「把代码库交出去」。6 项建议里留下 2 项，人工 review 没有消失，恰恰说明流程在正常工作。

有人会觉得这不够激进。人还在 review，Agent 又跑了 11 小时，怎么叫自动化。

可工程自动化的价值，从来不只等于去掉人。把人从机械搜索、重复基准、低价值定位里抽出来，让人把注意力放到风险、边界和取舍上，也是一种很硬的效率提升。

下一次你打算让 Agent 给仓库做性能优化时，可以先不问它「能不能自己改完」。先问一个更扫兴也更有用的问题。

如果它明天给我一份漂亮的 PR，我拿什么证明这份 PR 值得合？

把这个答案设计出来，Agent 才真正开始变成工程伙伴。

参考来源

  • Google Developers Blog，Google 使用 Gemini 4 Argon 优化 google/adk-python 的工程复盘，2026 年 10 月 14 日
  • AI HOT RSS 精选条目，Google 用 Gemini 4 Argon 无人值守优化 20 万行 Python 代码库 ADK，https://aihot.news/items/z371wogdvjh86jh8s6v6vlrui