架构全景：从执行器到运行时
ADK 1.x 时期，Agent 是独立的「执行器」：一个 Agent 持有自己的模型调用、工具与子代理层级，通过递归执行完成任务。这种模式在原型阶段很直观，但一旦进入生产，开发者会发现「控制流散落在 Agent 的隐式递归里」——断点恢复、重试、人工介入都难以在框架层面统一处理。
ADK 2.0 引入 Workflow Runtime，把架构从「层级执行」切换为「图执行」：你的 Agent、Tool、Function 都被评估为工作流图（Workflow Graph）中的独立节点（BaseNode）。执行引擎负责调度这些节点、维护图状态、做流式路由。换句话说，Agent 不再自己「跑」，而是作为图里的一个节点被引擎驱动。
| 维度 | ADK 1.x | ADK 2.0 |
|---|---|---|
| 执行模型 | 层级 Agent 执行器（BaseAgent 递归） | 图工作流运行时（BaseAgent 继承 BaseNode） |
| 控制流 | 隐式递归 + 子代理层级 | 显式节点图 + 路由 |
| 状态管理 | Session 内事件列表 | Event 携带 node_info / output 图状态 |
| 重试 / HITL | 需开发者自行 try-except | 框架原生自动重试 + 暂停 |
| 多语言 GA | Python / Go | Python（05-19）/ Go（06-30）/ TypeScript（08-21） |
ADK 2.0 的核心转变是：把「编排逻辑」从 Agent 内部抽到图引擎外部。这带来的直接收益是断点恢复、重试、人工审批可以在框架层统一实现，而不依赖每个工具作者手写。这与 2026 年主流 SDK（OpenAI Agents SDK、LangGraph、Microsoft Agent Framework、AWS AgentCore、Claude Agent SDK）收敛到的「Agent 即运行时」方向一致。
图工作流：确定性编排
图工作流（Graph-based workflows）面向「控制流可预期」的任务。你用显式的图结构声明节点与边，引擎按图路由执行。适合那些步骤顺序固定、分支条件明确的流水线，例如「先检索再生成再审核」的固定三步走。
在图工作流里，Agent、Tool、Function 都是一等节点。引擎在节点之间传递状态，并可在任意节点配置条件分支。与动态工作流相比，图工作流的确定性更高，便于审计与回放——每个节点的输入/输出、路由决策都被图状态记录。
适用场景
- 固定流水线：文档摄入 → 切片 → 向量化 → 审核，步骤顺序稳定
- 强合规路径：金融/医疗等对每一步可解释性有要求的场景
- 可回放审计：需要把执行轨迹完整重放的运维/安全流程
动态工作流：代码驱动循环与分支
动态工作流（Dynamic workflows）面向「控制流必须靠代码算出来」的任务。你用普通代码逻辑构建更复杂的工作流，包括迭代循环、基于复杂决策的路由分支。引擎会在代码执行过程中动态展开节点。
这是图工作流与动态工作流的根本差异：图工作流在「声明时」就定好了拓扑，动态工作流在「运行时」才决定下一步跑哪个节点。前者可预期、易审计；后者灵活、能处理无法在编译期枚举的分支爆炸。
ADK 1.x 中，开发者常通过重写 _run_async_impl() 或 generate_content() 来驱动自定义执行。升级 2.0 后，这些抽象方法不再被引擎调用——图引擎会完全绕过它们。若要注入自定义遥测或状态逻辑，应改用标准的 BeforeAgentCallback / AfterAgentCallback 接口，否则代码会被静默忽略。
协作工作流：协调器与子代理
协作工作流（Collaborative workflows）面向「多智能体协作」任务：一个协调器 Agent（Coordinator）把任务拆解给多个子代理（Subagent），各自完成后由协调器汇总。这是 ADK 对多智能体编排的原生支持。
与 OpenAI Agents SDK 的 Handoff（在同一次 Runner.run 内切换活动 Agent 并改写上下文）不同，ADK 的协作工作流更强调「图节点拓扑」——每个子代理是图里的一个节点，协调器通过图的路由逻辑分发与回收结果。两者都能实现多智能体，但 ADK 把编排显式建模为图，OpenAI 把编排隐式建模为运行时切换。
三种工作流的关系
| 工作流类型 | 控制流确定于 | 典型用途 |
|---|---|---|
| 图工作流 | 声明时（图拓扑固定） | 固定流水线、强合规路径 |
| 动态工作流 | 运行时（代码展开） | 分支爆炸、迭代循环任务 |
| 协作工作流 | 运行时（协调器分发） | 多智能体任务拆解与汇总 |
Event 2.0 schema 与 Session 存储
ADK 2.0 给核心 Event schema 新增了两个字段：node_info（记录图状态）与 output（记录工作流输出）。这两个字段是图引擎管理状态、路由与流式的基石。
对生产部署，这意味着需要同步迁移存储层：
- 自定义 Session 服务：如果你实现了自定义
BaseSessionService（把事件存进自有 SQL / NoSQL 的刚性列），数据库 schema 必须容纳node_info与output，否则插入 2.0 Event 会失败或 ORM 反序列化报错。 - JSON Blob 友好：若你的自定义 Session 服务把事件存为序列化 JSON Blob（而非映射到显式列），则无需改 schema——这也是升级 2.0 风险最低的一种存储形态。
- 下游校验：若你的 API 网关、移动端、Web 前端做了严格 JSON 校验（例如
additionalProperties: false），校验会在升级后拒绝 2.0 Event，需先更新校验 schema。
ADK 1.x 中，部分开发者会绕过框架、直接 context.session.events.append(custom_event)。在 2.0 中，图引擎需要严格掌控事件发射以管理状态、图路由与流式。手动追加会破坏确定性。正确做法：在你自己的节点或 Agent 内部 yield 事件，让框架原生接管持久化、路由与流式。
HITL 与自动重试
ADK 2.0 把「错误处理 + 自动重试 + 人工介入（HITL）」做成框架原生能力，这是相对 1.x 显著的工程进步。
- 自动重试：框架现在会捕获异常并启用自动重试、遥测与 HITL 暂停。开发者应配置
RetryConfig(max_attempts=3)之类的策略。 - 不要吞异常：若你在工具里保留宽泛的
except Exception，会屏蔽失败、永久禁用该步的自动重试。更危险的是捕获BaseException会意外截住NodeInterruptedError，从而破坏框架为 HITL 暂停工作流的能力。 - 正确姿势：让标准异常自然抛出，框架会据此对照你的 RetryConfig 评估；除非显式重新抛出，否则不要捕获
BaseException。
当工作流需要人工审批才能继续（例如不可逆的写操作），框架通过 NodeInterruptedError 暂停图执行。若你的代码捕获了 BaseException，这个暂停信号会被吞掉，工作流会在无人确认的情况下继续——这是生产环境里高危的反模式。
与同类框架技术对比
把 ADK 2.0 放进 2026 年的 Agent 框架坐标系，差异主要在「编排范式」与「生态绑定」：
| 维度 | Google ADK 2.0 | OpenAI Agents SDK | Microsoft Agent Framework 1.0 | LangGraph |
|---|---|---|---|---|
| 编排范式 | 图工作流运行时（节点图） | 轻量原语 + Runner（Handoff） | Kernel + Agent（AutoGen 合并 Semantic Kernel） | StateGraph + Checkpointer |
| 多语言 | Python / Go / TypeScript | Python / TypeScript | .NET / Python | Python 为主 |
| 模型绑定 | 优化 Gemini / Vertex AI，跨框架兼容 | LiteLLM 接 100+ 模型，特性偏 OpenAI 原生 | 任意 OpenAI 兼容端点 | 模型无关 |
| 重试用 / HITL | 框架原生（RetryConfig + NodeInterruptedError） | Guardrail 短路 + 自定义 | Durable Functions 状态化编排 | interrupt / Command 恢复 |
| 企业集成 | Vertex AI 原生 | Tracing 可观测 | Entra ID 身份治理 + Azure Monitor | 需自建 |
ADK 2.0 的图运行时在工程完备度上对齐了 LangGraph 的 StateGraph，但提供了 Google 全栈（Vertex AI、Gemini、云日志 slog 标准化）的原生集成；相比 OpenAI Agents SDK 的轻量原语，ADK 的「声明式图」更适合需要强审计与回放的生产场景，代价是心智模型更重、学习曲线更陡。
局限与适用边界
- 生态绑定：虽称模型无关，但完整特性（原生 Vertex AI 认证、Gemini 工具）仍偏 Google 云原生，跨云迁移有摩擦。
- 迁移成本：1.x → 2.0 是破坏性升级，自定义执行覆写、刚性 Session schema、下游严格 JSON 校验都要改，存量项目升级需评估。
- 心智模型更重：图/动态/协作三类工作流加上 Event 2.0 schema，新人上手成本高于 OpenAI Agents SDK 的五原语。
- Session 存储坑：刚性列存储若不兼容
node_info/output会插入失败，建议优先采用 JSON Blob 存储。 - 目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态：如 2.0 在大型生产系统的规模化运维基准、与 A2A 协议的深度集成进展，本文将在官方披露后补充。