Google 的工程师把一次 11 小时无人值守的运行交给了 Gemini 4 Argon，目标不是从空文件夹里生成一个新应用，而是优化自家 Agent Development Kit（ADK）的性能。这个代码库超过 20 万行 ，分布在约 800 个文件中，包含近 17000 个单元测试 。 他们想搞清楚一件事：模型面对一个已经存在的代码库，到底能处理到什么程度。相比从零搭建应用，这要难得多。性能优化尤其如此——你没法只打开一个文件就找到变慢的地方，得从症状出现的反方向去看，还要在长时间运行中始终握住整张代码库的地图。 为了让智能体按团队惯例做单元测试和基准测试，工程师先跑了一轮短任务，摸清提示词里需要包含什么。随后他们通过 .agents/skills 文件写入了仓库专属的规范，用他们的说法，这就像给新工程师的一份入职指南。智能体被要求只加载任务所需的技能，避免把上下文窗口塞满。 最终的目标提示词要求 ADK 不给任何智能体增加可感知的开销——启动时、长会话中、多智能体和工作流场景下都是如此；保持模型接收的内容和公共 API 不变；每个改动都要配一个能捕获回归的测试；向主分支提交一个 ADK 维护者会批准的拉取请求，描述里附上改动前后的数字，但不合并。 任务完成时，Argon 的日志显示它读了仓库规范、建立了性能基线、提出优化方案、审查了自己的改动，并在结束前跑完了全部 16892 个 开源单元测试。 更关键的是它做了性能分析器做不到的跨模块工作。分析器会告诉你复制会话和导入包耗时，但它不会沿着 40 个文件追踪每一个调用方、mock 目标和共享引用，以确保加速这些路径不会破坏现有应用。 最终被接受的优化有两处：一是在复制事件之前先做过滤，改进 ADK 对会话历史的处理；二是引入懒加载，让重量级包在真正需要时才被导入。这两项改动分别把内存中的会话准备开销降低了约 40% ，把冷包导入时间降低了 21% 。 单看一次耗时几秒的 LLM 调用，人感觉不到 28 毫秒或 78 毫秒的差别。但 ADK 支持跨数十甚至数百次迭代的多工具交互，这些小收益会累积起来。在 158 轮内部工具调用中，去掉这些复制让整轮运行从 65.6 秒 降到 56.1 秒 ，接近 10 秒的纯框架开销。 这次尝试也暴露了边界。智能体修改现有代码库的能力已经得到验证，但效果目前仍受限于编码之后的工作——PR 审查、调试和测试所需的时间与精力。Argon 产出的改动中有 4 项 在开发者审查时被拒绝，原因是可靠性、可维护性、兼容性方面的顾虑，或者性能收益无法量化。 特别