Google 报告 Argon 在 Antigravity /goal 中连续 11 小时优化 ADK；6 项方案经人工审查只合并 2 项。案例强调仓库规则、基准和审查，不是通用性能保证。
适合的任务：已有大型 Python 代码库中的跨文件性能排查、会话历史复制优化、重包延迟导入、基准测试和测试补齐；尤其适合需要长时间运行和人工审查的 Agent 任务。
不适合的任务：不能据此保证任意仓库都能获得相同收益；不能跳过维护者审查，也不能把合成基准提升外推到生产流量。
适用的模型版本：Gemini 4 Argon；原文未给出更细的 API 版本或推理档位。
适用的客户端、Agent 或 API：Google Antigravity 的 /goal 模式；案例未提供 Tabbit、API 请求 schema 或其他客户端配置。
推荐的推理档位和参数：未注明。原文未公开温度、token 上限、工具配置或请求参数。
以下两段是原文公开的工作目标，按原文保留；它们是案例证据，不代表在其他代码库中可以不经调整直接复现同样结果。
Make ADK add no noticeable overhead to any agent:\ at startup, in long sessions, in multi-agent and\ workflow setups. Ke… 以上为必要节选，完整内容请查看原文。
/goal prompt/goal Make ADK add no noticeable overhead to any agent:\ at startup, in long sessions, in multi-agent and workflow setup… 以上为必要节选，完整内容请查看原文。
第二轮还把维护者规则放入仓库的 .agents/skills 目录。每个 skill 用 SKILL.md 作为索引，按需指向 references/ 文件，避免每轮把全部规则塞进上下文。原文没有提供适用于其他项目的完整目录内容。
选定已有的大型代码库和可量化的目标。案例对象是约 205,000 行 Python、近 800 个源文件和近 17,000 个单元测试的 Google ADK。
第一轮不提供自定义仓库规则，只给目标 prompt。运行约 2 小时：7 分钟时写出 benchmark 脚本，之后花约 70 分钟测量和阅读代码，随后才编辑 ADK 源码。
记录第一轮的失败边界：模型给认证模型添加的自定义 hook 改变了公开 JSON schema；自定义 copier 漏掉 mock event 边界；只运行了 216 个附近测试；pull request 未写 benchmark 数字。
把维护者约定放入 .agents/skills，并在 Google Antigravity 开启 /goal 模式，让目标跨上下文压缩持续存在。第二轮从晚上 9:11 开始，无人值守运行 11 小时。
在改代码前读取 12 个规则文件，并对四类工作负载做基线测试，每类运行 30 次：包启动、200-step 对话、20 个子 Agent 互相传递任务的测试应用、12 节点工作流。
让模型提出优化并生成未合并的 pull request，要求写出前后数字；维护者逐项检查跨模块引用、mock 目标、共享引用、公共 API 和回归测试。
保留两项能干净解决核心瓶颈的改动，拒绝另外四项；将最终 22 文件改动与 17 个新测试函数提交到主分支。原文称该提交的说明为“Argon generated these changes”。
复制前过滤内存 session 历史：原先每次读取都先深拷贝完整对话，再筛选调用者需要的事件；Argon 改为先过滤，再复制，并用快速、可处理循环引用的 copier 替换 Pydantic 的通用深拷贝路径，同时保留共享 state 字典和测试 mock。
仅在需要时加载重型包：import google.adk 原先会加载实时音视频、OpenTelemetry、FastAPI 和 Starlette，即使 Agent 只处理文本。最终改动使用延迟模块访问器，让重型包首次使用时才加载，同时保持公共属性可被测试 patch。
第二项优化中，删除 llm_agent.py 的 3 个内部 flow import 后，16,892 个开源测试通过，但 25 个 Google 内部测试目标失败，因为它们 patch 了这些属性。案例保留了可 patch 的公共属性后才合并。
多 Agent event cache 在合成基准上提速 17%，但使用脆弱的内存引用；Python 垃圾回收后复用地址可能跨 session 返回陈旧数据。
telemetry 检查读取 OpenTelemetry tracer 实现的私有属性，小版本升级可能静默破坏。
重写每次模型调用前的对话历史格式化，使核心路径更难读，却没有改善独立 holdout benchmark 的端到端延迟。
workflow event replay 的查找索引增加状态跟踪复杂度，只帮助合成 replay 测试，不帮助日常 Agent 运行。
原文称团队在两轮运行前写了 Argon 未见过的独立 holdout benchmark bench_turn.py：使用即时模型和即时工具，使计时主要反映 ADK 框架开销；每个 turn 执行三轮、每轮四个并行工具调用，分别测量已有 0、50、150 个 turn 后的 5 个 turn。每个数字是 6–12 次运行的中位数，变更前后每个 turn 接收字节级相同的请求。
| 原文报告的结果 | 适用范围与限制 |
|---|---|
| 长 session 的模型请求前内存准备开销约降低 40% | 主要适用于 InMemorySessionService；单次 LLM 调用只省几十毫秒，长达 158 个内部 turn 时才会累积出明显差异 |
import google.adk 冷启动包导入速度提升 21% | 新进程到第一次模型请求的时间基本不变：3.07 秒至 3.09 秒，因为延迟模块在第一个 turn 才加载 |
| 158-turn 运行从 65.6 秒降至 56.1 秒 | 原文归因于纯框架开销减少近 10 秒；使用外部数据库、SQLite、Gemini platform、Firestore 或 Redis session store 的读取时间不在此改动范围内 |
原文还称，经过优化的导入能帮助 CLI、开发和测试发现；生产服务器应在接收真实流量前发送 warm-up 请求，以免首个用户请求承担一次性导入成本。
这是 Google Cloud 对自身 Agent 运行的案例叙述；代码改动、基准和收益数字均未由本项目独立复测。
结果依赖 ADK 代码库、维护者规则、/goal 模式、测试集和具体 benchmark；不能把 40% 或 21% 当作 Gemini 4 Argon 在其他项目中的固定提升。
模型提出的 6 项方案中只有 2 项通过人工代码审查；4 项的合成收益、私有 API、脆弱状态或可维护性问题使其被拒绝。Agent 探索不能替代维护者取舍。
第一轮已暴露公开 schema 变化、mock 边界遗漏、测试覆盖不足和 PR 证据缺失等问题；即使第二轮运行更长，也不能省略人工验收。
原文没有披露 Antigravity 账号、地区、配额、价格、推理档位、完整工具权限或 API 认证条件；“可访问”不等于所有账号均可用。
要复现该工作流，应固定代码库提交、Python 与依赖版本、仓库规则、测试集、模型入口、Agent 客户端、/goal 设置和运行时长；保存原始 prompt、每轮中间日志、完整 diff、测试结果、benchmark 脚本与前后数字。必须使用模型未见过的 holdout benchmark，并分别验收公开 API、mock、跨 session 数据一致性、首次请求导入成本和长 session 开销。最后由熟悉代码库的维护者决定哪些改动可合并；不要把本文的厂商自述当作通用性能承诺。
Gemini 4 Argon