# AI 把启动加快了，等待却搬到了下一站

> Google 公布的 Argon 优化案例里，ADK 冷导入快了 21%，新进程到首次模型请求却基本没变。这张不够漂亮的成绩单，恰好教我们怎样验收 AI 的性能改动。

- 作者：芝士AI吃鱼
- 发布日期：2026-10-16
- 栏目：[AI锐评](https://ai-knowledgepoints.cn/commentary)（观点与分析）
- 主题：AI锐评、Gemini、性能优化、Agent
- HTML 正文：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-16-argon-stopwatch-boundary](https://ai-knowledgepoints.cn/blog/commentary-2026-10-16-argon-stopwatch-boundary)
- Markdown 永久链接：[https://ai-knowledgepoints.cn/blog/commentary-2026-10-16-argon-stopwatch-boundary/index.html.md](https://ai-knowledgepoints.cn/blog/commentary-2026-10-16-argon-stopwatch-boundary/index.html.md)
- 原始来源：[Google ADK 优化工程说明与上游提交](https://developers.googleblog.com/optimizing-a-200000-line-python-codebase-overnight-with-gemini-4-argon/)

引用本文时，请注明作者与 HTML 正文链接。Markdown 版本用于机器阅读，与 HTML 正文共享同一内容来源。

## 正文

车站宣布进站快了。闸机前的队伍确实短了一截，乘客刷卡就过，负责计时的人满意地按停秒表。

走到站台，才发现刚才省下的等待，在这里重新排好了队。

这是个假想场景。把它放到 AI 写代码的演示旁边，问题会很具体：那个“快了多少”，秒表究竟停在哪里？

Google 在 **2026 年 10 月 13 日**[宣布向开发者等用户开放 Gemini 4 Argon](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-argon/)，拿 ADK Python 框架的优化展示长任务能力。三天后的今天，比起“自主工作了一夜”，我更愿意盯住它公开提交里一组有点扫兴的数字。

[ADK 的 `1754b3e` 提交](https://github.com/google/adk-python/commit/1754b3eeb6cdb2c16e3b30619a12066623df132e)报告：新进程导入 ADK，从 **1.22 秒降到 0.97 秒**；但新进程到首次模型请求，从 **3.07 秒变成 3.09 秒**。前一项减少约 21%，后一项没有显示提速。

这些是项目方报告的数据，本文没有独立重跑。也不能凭 0.02 秒的差异就宣布性能退化：提交没有给出足够的波动信息，支撑这样的显著性判断。

我反倒觉得，把后一项留在成绩单上，值得肯定。它让读者看到优化真实发生的位置，也让“启动”这个经常含混的词，有了可以追问的终点。

## 秒表停早了，用户还没上车

这里的关键手法是懒加载：暂时不需要的重模块，等真正使用时再加载。

从同一提交的 `llm_agent.py` 改动可以看到，一些原先顶层导入的 flow 类改为按需取得，模块通过延迟访问机制保留相应名称。变化发生在依赖何时被加载，不代表依赖凭空消失。

[Google 的工程说明](https://developers.googleblog.com/optimizing-a-200000-line-python-codebase-overnight-with-gemini-4-argon/)也把这点讲清了：部分加载成本被推迟到第一次真正运行，所以冷导入更快，而新进程到首次请求基本持平。

这不是无效优化。只导入包、发现测试或执行某些不需要那些依赖的命令，可能确实少付了一笔费用。问题出在把这个收益直接翻译成“用户更快拿到答案”。后者还要经过首次执行、模型响应、工具调用，甚至后续处理。本文引用的“首次模型请求”本身，也不是“首次答案”。

把进站速度写成抵达速度，夸大的那一截通常就藏在名词里。

![ADK 项目报告的两种计时终点：新进程导入包从 1.22 秒到 0.97 秒；新进程到首次模型请求从 3.07 秒到 3.09 秒。懒加载将部分工作延后，首次请求仍不是收到答案。示意框宽不表示耗时比例。](https://ai-knowledgepoints.cn/images/articles/argon-stopwatch-commentary/where-clock-stops.svg)

原创计时边界图；数字来自 ADK 1754b3e 提交，非本文实测。两项采用不同终点，不能相减为经过验证的分阶段耗时；框宽不代表比例。

[查看竖版大图](https://ai-knowledgepoints.cn/images/articles/argon-stopwatch-commentary/where-clock-stops-mobile.svg)

验收 AI 的性能改动时，我希望任务说明先写明：谁在等，等到哪个动作完成，允许把哪些工作移到后台或下一次调用。

这会直接改变方案的取舍。一个只做格式检查的短命命令，没加载到的依赖可能永远不用加载，节省就是节省；一个每次都从冷进程处理请求的服务，把同一笔成本推迟几百毫秒，未必改变用户的总等待。长驻服务可以预热，但预热只是把成本交给部署阶段，仍要考虑资源、失败以及何时才算准备就绪。

这些是根据执行路径作出的工程分析，不是本文对 ADK 部署方式的实测建议。它们共同说明：同一块改动，换一个使用场景，就可能换一种收益。

因此，需求里只写“把启动优化 20%”，其实给了执行者一个很大的选择空间。它可以减少必要工作，也可以延后工作，还可以让计时器更早结束。即使没有任何投机动机，任务也可能被合理地完成在一个不太有用的终点上。

先把终点写清楚，远比事后猜 Agent 有没有理解自己的意思省心。

## 有些等待被搬走，有些工作真的被省掉

同一个 ADK 提交还包含另一种优化：内存会话先筛选需要返回的事件，再复制；列举会话时不再先复制全部历史事件。这与懒加载不同，减少的是当前操作中本来不必做的工作。

项目报告的 **158 个内部 turn** 完整运行，从 65.6 秒降到 56.1 秒。但其模型和工具即时返回，测的是框架开销，不能直接当成真实业务长任务的加速比例；长会话前置耗时那两项还注明关闭了垃圾回收。来源采用 6 至 12 次运行的中位数，读数必须连同条件一起保留。

这两种变化放在一张提交里，正好提醒我们：不要只给优化贴一个“更快”的标签。到底是少做了事，还是晚做了事，决定了收益在什么场景下兑现。

假设一个合成任务原来需要 10 秒，其中可优化的框架工作占 1 秒。即使这 1 秒减少 40%，总耗时也只是从 10 秒变成 9.6 秒，即减少 4%。这里的数字仅用于说明分母，不是 ADK 的测量结果，也没有假设真实模型调用的耗时。

这笔小学算术，在发布会里常常比复杂排行榜更值得保留。局部比例越亮眼，越需要知道它在整段等待里占多少。

## 终点之外，还得保住沿途能用的入口

性能改动还有一张容易漏掉的车票：原来能用的入口，改完还能不能用。

Google 的工程说明披露，第二轮方案一度通过了全部 **16,892 个开源单元测试**，却让 **25 个内部测试目标**失败，因为那些测试会替换模块上的特定属性。最终方案通过懒访问保留了这些位置。内部失败数量属于 Google 自述，公开提交可检查实现，但不足以独立核实整个内部测试过程。

这个细节比“测试全绿”更有教育意义。一个库怎样被使用，不只写在函数签名里；下游可能依赖它暴露的名称、替换点，以及加载时机。是否应该长期支持某个入口，是维护者要作的兼容性决定，不能由优化者顺手删除。

![性能优化的验收约定：先固定等待终点，再区分减少工作与延后工作，同时保留要求支持的模块访问和替换入口，最后在目标负载与兼容测试中确认收益。原创建议，不是官方测试结果。](https://ai-knowledgepoints.cn/images/articles/argon-stopwatch-commentary/optimization-contract.svg)

原创分析图。计时目标、工作位置和兼容入口需要一起说明；通过图中检查不构成无回归保证，也不替代真实应用测试。

[查看竖版大图](https://ai-knowledgepoints.cn/images/articles/argon-stopwatch-commentary/optimization-contract-mobile.svg)

如果要把这次案例转成一份更有用的任务，我会这样描述：在指定的冷进程与长驻进程负载下，降低到指定完成事件的耗时；模型收到的输入保持要求的等价关系；现有支持的导入和替换入口继续可用；结果同时交代省掉的工作、延后的工作与没有改善的路径。

这段话没有承诺模型会一次做到。它只是让交付更容易被判断：一项优化可以成功改善局部，也可以诚实地没有改善整体；有收益的部分留下，破坏既有约定的部分修正，没证据的部分继续留空。

AI 已经能在复杂代码库里找到值得合入的性能改动，这是这次案例值得关注的进展。但从一个厂商组织的案例，还推不出所有模型、所有仓库都适合无人值守优化，更推不出运行时间越长，交付就越可信。

我更期待下一次展示时，屏幕上除了“工作了十一小时”，还有一张明确的计时图：乘客从哪里出发，在哪一站按停秒表，哪些等候真的消失，哪些只是换了月台。

能让闸机快一点，当然是好事。只要别让站台上的人，替那张漂亮的成绩单继续等着。

资料核对：2026 年 10 月 16 日。事件与工程说明均发表于 10 月 13 日；代码分析固定于 [ADK 提交 `1754b3e`](https://github.com/google/adk-python/commit/1754b3eeb6cdb2c16e3b30619a12066623df132e)。性能数字、长任务过程和内部测试情况来自项目方报告，公开代码并非独立性能复现。本文未运行 Argon 或重跑 ADK 基准；车站意象、10 秒算例与验收建议为原创分析。本文不据此判定其他模型优劣，也不把局部微基准换算成生产收益。

想继续讨论 AI 工程的验收方法，可以看 [AI 实践路线](https://ai-knowledgepoints.cn/planet)；公众号入口在[关于页](https://ai-knowledgepoints.cn/about#wechat)。

本文文字与图解由 AI 辅助制作，来源已在正文列明。