车站宣布进站快了。闸机前的队伍确实短了一截，乘客刷卡就过，负责计时的人满意地按停秒表。
走到站台，才发现刚才省下的等待，在这里重新排好了队。
这是个假想场景。把它放到 AI 写代码的演示旁边，问题会很具体：那个“快了多少”，秒表究竟停在哪里？
Google 在 2026 年 10 月 13 日宣布向开发者等用户开放 Gemini 4 Argon，拿 ADK Python 框架的优化展示长任务能力。三天后的今天，比起“自主工作了一夜”，我更愿意盯住它公开提交里一组有点扫兴的数字。
ADK 的 1754b3e 提交报告：新进程导入 ADK，从 1.22 秒降到 0.97 秒；但新进程到首次模型请求，从 3.07 秒变成 3.09 秒。前一项减少约 21%，后一项没有显示提速。
这些是项目方报告的数据，本文没有独立重跑。也不能凭 0.02 秒的差异就宣布性能退化：提交没有给出足够的波动信息，支撑这样的显著性判断。
我反倒觉得，把后一项留在成绩单上，值得肯定。它让读者看到优化真实发生的位置，也让“启动”这个经常含混的词，有了可以追问的终点。
秒表停早了，用户还没上车#
这里的关键手法是懒加载：暂时不需要的重模块，等真正使用时再加载。
从同一提交的 llm_agent.py 改动可以看到，一些原先顶层导入的 flow 类改为按需取得，模块通过延迟访问机制保留相应名称。变化发生在依赖何时被加载，不代表依赖凭空消失。
Google 的工程说明也把这点讲清了：部分加载成本被推迟到第一次真正运行，所以冷导入更快，而新进程到首次请求基本持平。
这不是无效优化。只导入包、发现测试或执行某些不需要那些依赖的命令，可能确实少付了一笔费用。问题出在把这个收益直接翻译成“用户更快拿到答案”。后者还要经过首次执行、模型响应、工具调用，甚至后续处理。本文引用的“首次模型请求”本身，也不是“首次答案”。
把进站速度写成抵达速度，夸大的那一截通常就藏在名词里。
验收 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 自述，公开提交可检查实现，但不足以独立核实整个内部测试过程。
这个细节比“测试全绿”更有教育意义。一个库怎样被使用，不只写在函数签名里；下游可能依赖它暴露的名称、替换点，以及加载时机。是否应该长期支持某个入口，是维护者要作的兼容性决定，不能由优化者顺手删除。
如果要把这次案例转成一份更有用的任务，我会这样描述：在指定的冷进程与长驻进程负载下，降低到指定完成事件的耗时；模型收到的输入保持要求的等价关系；现有支持的导入和替换入口继续可用；结果同时交代省掉的工作、延后的工作与没有改善的路径。
这段话没有承诺模型会一次做到。它只是让交付更容易被判断：一项优化可以成功改善局部，也可以诚实地没有改善整体；有收益的部分留下，破坏既有约定的部分修正，没证据的部分继续留空。
AI 已经能在复杂代码库里找到值得合入的性能改动，这是这次案例值得关注的进展。但从一个厂商组织的案例，还推不出所有模型、所有仓库都适合无人值守优化，更推不出运行时间越长，交付就越可信。
我更期待下一次展示时，屏幕上除了“工作了十一小时”，还有一张明确的计时图：乘客从哪里出发，在哪一站按停秒表，哪些等候真的消失，哪些只是换了月台。
能让闸机快一点，当然是好事。只要别让站台上的人，替那张漂亮的成绩单继续等着。
资料核对：2026 年 10 月 16 日。事件与工程说明均发表于 10 月 13 日；代码分析固定于 ADK 提交 1754b3e。性能数字、长任务过程和内部测试情况来自项目方报告，公开代码并非独立性能复现。本文未运行 Argon 或重跑 ADK 基准；车站意象、10 秒算例与验收建议为原创分析。本文不据此判定其他模型优劣，也不把局部微基准换算成生产收益。
想继续讨论 AI 工程的验收方法，可以看 AI 实践路线；公众号入口在关于页。
本文文字与图解由 AI 辅助制作，来源已在正文列明。
