Google ADK 现在最值得看的不是“能写 Agent”，而是 Runtime、Streaming 和 Resume
如果只看表面，Google ADK 很容易被理解成“Google 版 agent framework”。但从当前官方文档看，它真正有辨识度的不是一句 “build agents”，而是它对 runtime 的强调非常系统。
ADK 的第一层特点：把 Workflow Agent 和 LLM Agent 明确拆开
官方 technical overview 和 agents 文档都强调了一点：
LlmAgent负责推理和动态决策- workflow agents 负责顺序、并行、循环等确定性编排
这件事特别好，因为很多 agent 框架会把“让模型自己决定一切”和“明确规定执行图”混成一层，结果系统既难预测又难 debug。
ADK 明确给出了两套组件：
SequentialAgentParallelAgentLoopAgent
这意味着它从一开始就接受一个事实：
有些事情该交给模型，有些事情就该交给确定性控制流。
第二层特点：官方文档对 Runtime 讲得很重
ADK 不是只讲 API，而是单独把 Runtime 拿出来讲。
Runtime 文档把它定义成：
- 负责 orchestrate agents、tools、callbacks
- 通过 event loop 驱动执行
- 管理状态变更与外部交互
这说明 ADK 的设计中心不是“单次调用”，而是持续运行的 agent application。
对真正做产品的人来说，这比“hello world agent”重要得多。
第三层特点：Streaming 被提升到了核心能力
ADK 最近最值得看的一个部分，是 Bidi-streaming (live)。
官方 streaming 文档里提到：
- 它支持低延迟双向语音 / 视频交互
- 基于 Gemini Live API / Vertex AI Live API
- 用户可以打断 agent 的输出
- agent 能处理 text / audio / video 输入
这意味着 Google ADK 在“实时交互型 agent”这件事上投入很深。很多框架今天还主要围绕：
- 文本聊天
- tool use
- workflow orchestration
而 ADK 已经把 voice/video/live interrupt 视作正式场景。
第四层特点：Resume 是真实生产问题的答案
官方 runtime 文档里还有一个我很喜欢的能力：Resume stopped agents。
这看似不花哨，实际上非常关键。因为一旦 agent 是长任务或多步 workflow，它就必然会遇到：
- 网络断开
- 容器重启
- 外部系统临时不可用
- 人工审批后继续执行
Resume 的价值就在于：不用从头开始。
这代表 ADK 不再把 agent 当一次函数调用，而是真正把它当一个可恢复的执行过程。
第五层特点：A2A 被明确纳入官方路径
Google ADK 还有一层很值得注意的设计：官方文档直接提供了 A2A 协议相关指南。
文档对 A2A 的区分非常清楚：
- local sub-agents：同进程、低延迟、共享上下文
- remote agents (A2A)：独立服务、跨语言、跨团队、正式协议
这点很成熟，因为很多团队做多 Agent 时没有清楚地区分“内部模块化”和“远程 agent 协作”，结果边界一塌糊涂。
这条路线适合什么团队
我觉得 Google ADK 特别适合：
- 需要实时语音 / 视频 agent 的团队
- 想把 workflow orchestration 和 LLM 推理分开的人
- 需要 resume / long-running 执行能力的人
- 已经在 Google / Vertex 生态里的人
我的判断
Google ADK 的价值不在于它又提供了一套 Agent API，而在于它把几个经常被忽略的执行层问题做成了正式能力：
- runtime
- streaming
- resume
- local vs remote multi-agent
这说明它更像一个 agent application runtime，而不只是模型外面的一层包装。
来源
- Google ADK 官方文档：Technical Overview
- Google ADK 官方文档：Runtime
- Google ADK 官方文档：Bidi-streaming / Streaming
- Google ADK 官方文档：Resume
- Google ADK 官方文档：A2A
- X.com：AI agent framework 全景讨论