ADK 相关的核心要点是什么？

本文围绕 ADK、Google、Agent、Multi-Agent、Workflow、AI、LLM、架构设计展开，深度拆解 Google ADK 2.0 的 Workflow 图引擎、Task API 和 HITL 三大核心变革，解析推倒重来的设计哲学——确定性代码+自适应AI推理。详细解读见正文。

Google ADK 2.0 架构革命：为什么把框架推倒重来？

Q: ADK 相关的核心要点是什么？

本文围绕 ADK、Google、Agent、Multi-Agent、Workflow、AI、LLM、架构设计 展开，深度拆解 Google ADK 2.0 的 Workflow 图引擎、Task API 和 HITL 三大核心变革，解析推倒重来的设计哲学——确定性代码+自适应AI推理。详细解读见正文。

2026-07-16T19:30:00+08:00

ADKGoogleAgentMulti-AgentWorkflowAILLM架构设计

Google ADK 2.0 架构革命：为什么把框架推倒重来？

升级还是重写？Google 的选择出乎意料。

2026 年 5 月 19 日，Google 悄悄把 ADK（Agent Development Kit）的主分支从 v1.x 切到了 v2.0.0 GA。这不是一次常规升级——这是一次彻底的架构重写。Agent API 不兼容，Event 模型变了，Session schema 改了，连核心执行引擎都换了。

一个 20,631 Star、3,700 Fork 的开源项目，为什么要把整个框架推倒重来？答案藏在 ADK 1.x 的生产化困境里。

本文提纲

ADK 的战略定位：Google 的 Agent 操作系统
1.x 的困境：三个分离的编排类解决不了真实世界的问题
Workflow 图引擎：统一一切的核心飞轮
Task API：让 Agent 之间像函数一样调用
HITL + 可恢复执行：企业级部署的最后一公里
设计哲学：确定性代码 + 自适应 AI 推理

ADK 的战略定位

先搞清楚 ADK 在这个拥挤的市场里到底算什么。

如果你刷过 GitHub 的 Agent 框架排行榜，大概见过这张表：

框架	Stars	定位	语言
LangChain/LangGraph	100K+	最通用的 Agent 编排	Python/JS
CrewAI	25K+	角色扮演式多 Agent	Python
AutoGen (Microsoft)	40K+	对话驱动多 Agent	Python/.NET
Google ADK	20.6K	代码优先+图引擎	Python/TS/Go/Java/Kotlin

ADK 的差异化不在"功能多"，而在三个关键词：代码优先、多语言覆盖、Google 云原生。

代码优先意味着你不需要 YAML 配置文件来定义 Agent——直接用 Python 类声明。多语言覆盖意味着同一个框架概念在 Python、TypeScript、Go、Java、Kotlin 上都能找到对应实现。Google 云原生意味着你可以无摩擦地把 Agent 部署到 Vertex AI、Cloud Run 或任何 Google 基础设施上。

但 1.x 版本有个要命的问题：这些 Agent 在开发环境里跑得好好的，一到生产环境就各种水土不服。

1.x 的困境：三个分离的编排类

先看一段 ADK 1.x 的典型代码，直观感受问题在哪：

# ADK 1.x：用手动嵌套实现复杂编排
research_agent = Agent(name="researcher", ...)
write_agent = Agent(name="writer", ...)
review_agent = Agent(name="reviewer", ...)

# 想实现：research → (write + fact_check 并行) → review → publish
# 1.x 的做法：套娃式嵌套
pipeline = SequentialAgent(
    name="pipeline",
    sub_agents=[
        research_agent,
        ParallelAgent(
            name="parallel_stage",
            sub_agents=[write_agent, fact_check_agent]
        ),
        review_agent,
        publish_agent,
    ]
)

这段代码暴露了 1.x 的三个致命缺陷：

缺陷一：编排是"硬编码"的。 SequentialAgent、ParallelAgent、LoopAgent 是三个独立的类。想组合它们，只能像俄罗斯套娃一样层层嵌套。三层的嵌套还好说，五层以上基本没法维护。

缺陷二：没有条件路由。 如果 review_agent 发现内容质量不合格，应该退回给 write_agent 重写——这种"条件回退"在 1.x 里需要手动写 Python 逻辑来处理，框架本身不提供任何支持。

缺陷三：无法暂停和恢复。 如果 review_agent 需要人工审批，1.x 的 Runner 会直接超时报错。你没法让一个长流程的执行在中途停下来，等人操作完再继续。

这三个问题指向同一个根源：1.x 把"编排逻辑"硬编码成了 Python 类继承树，而不是一个通用的图执行引擎。

Google 的解法简单粗暴：全部推翻，用 Workflow 图引擎重新来过。

Workflow 图引擎：统一一切的核心飞轮

ADK 2.0 最核心的变革不是加了什么功能，而是换了一个执行引擎。用一张图看清变化：

graph TB
    subgraph "ADK 1.x — Class-based Orchestration"
        A1["SequentialAgent class"]:::red
        A2["ParallelAgent class"]:::teal
        A3["LoopAgent class"]:::blue
        A4["Manual nesting to combine"]:::yellow
    end

    subgraph "ADK 2.0 — Unified Graph Engine"
        B1["Workflow Graph Engine"]:::sage
        B2["Routing"]:::plum
        B3["Fan-out/Fan-in"]:::mint
        B4["Loops + Retry"]:::yellow
        B5["Dynamic Nodes"]:::red
        B6["HITL"]:::teal
        B7["Nested Workflows"]:::blue
        B1 --> B2
        B1 --> B3
        B1 --> B4
        B1 --> B5
        B1 --> B6
        B1 --> B7
    end

    A1 --> A4
    A2 --> A4
    A3 --> A4

    style A1 fill:#FF6B6B,color:#000000
    style A2 fill:#4ECDC4,color:#000000
    style A3 fill:#45B7D1,color:#000000
    style A4 fill:#FFEAA7,color:#000000
    style B1 fill:#96CEB4,color:#000000
    style B2 fill:#DDA0DD,color:#000000
    style B3 fill:#98D8C8,color:#000000
    style B4 fill:#FFEAA7,color:#000000
    style B5 fill:#FF6B6B,color:#000000
    style B6 fill:#4ECDC4,color:#000000
    style B7 fill:#45B7D1,color:#000000

左边是 1.x：四个独立的编排模式，组合靠手动嵌套。右边是 2.0：一个统一的图引擎，所有编排模式都是图中的边（Edge）和节点（Node）。

来看一段等价的 2.0 代码：

from google.adk import Agent, Workflow

# 定义 Agent（和 1.x 一样直观）
research_agent = Agent(
    name="researcher",
    model="gemini-2.5-flash",
    instruction="Research the given topic thoroughly.",
)
write_agent = Agent(
    name="writer",
    instruction="Write a blog post based on research results.",
)
fact_check_agent = Agent(
    name="fact_checker",
    instruction="Verify factual claims in the draft.",
)
review_agent = Agent(
    name="reviewer",
    instruction="Review the final draft for quality.",
)
publish_agent = Agent(
    name="publisher",
    instruction="Format and output the final article.",
)

# ADK 2.0：声明式图编排
pipeline = Workflow(
    name="content_pipeline",
    edges=[
        # 顺序执行：research → (write + fact_check 并行)
        (research_agent, write_agent),
        (research_agent, fact_check_agent),
        # 扇入：两个结果都到了才进入 review
        (write_agent, review_agent),
        (fact_check_agent, review_agent),
        # 条件路由：review 不通过 → 退回 write 重写
        (review_agent, write_agent, {"condition": "needs_revision"}),
        # review 通过 → 发布
        (review_agent, publish_agent, {"condition": "approved"}),
    ],
)

这就是 Workflow 图引擎的核心价值：编排逻辑从"继承树"变成了"有向图"。

图中每个节点是一个 Agent 或子 Workflow，每条边可以带条件、支持扇出/扇入、支持循环回退。以前需要手动写几十行 Python 逻辑的条件路由，现在一条边 + 一个 condition 搞定。

但更重要的是——Runner 是无状态的。

ADK 2.0 的 Runner（和 Workflow 专用的 NodeRunner）自身不持有任何长期状态。状态被外部化到 Session 服务，所有交互以 Event 对象的形式持久化存储。这意味着：

可恢复执行：工作流跑到一半崩溃了？重启后从断点继续，而不是从头再来
水平扩展：Runner 无状态 = 可以无限水平扩展
可观测性：每个 Event 都是一个追踪点，接入 OpenTelemetry 就能看到全链路

这一点怎么强调都不过分。99% 的 Agent 框架 demo 都能跑，但 99% 都死在"生产环境跑不起来"这一关。Runner 无状态设计直接解决了部署问题。

Task API：把 Agent 变成可调用的"函数"

Workflow 解决了编排问题，但还有一个场景它没有覆盖：结构化的 Agent 间委托。

举个例子：你在主 Agent 里拿到了一篇文章，需要把它翻译成三种语言。你希望三个翻译 Agent 并行工作，每个翻译 Agent 只做翻译这一件事，做完就返回结果。这种"派任务、等结果"的模式，Workflow 的图边只能覆盖一部分——它缺少一个结构化的"输入→输出"契约。

Task API 就是干这个的：

from google.adk import Agent
from google.adk.tasks import task

translator_agent = Agent(
    name="translator",
    model="gemini-2.5-flash",
    instruction="Translate the given text to the target language.",
)

@task(agent=translator_agent, mode="single_turn")
def translate(text: str, target_lang: str) -> str:
    """Translate text to target language. Returns translated text."""
    ...

# 主 Agent 中：像调用函数一样委托任务
results = await translate.batch([
    {"text": article, "target_lang": "zh"},
    {"text": article, "target_lang": "ja"},
    {"text": article, "target_lang": "ko"},
])

Task API 的三个核心概念：

graph LR
    subgraph "Task API"
        A["Task Definition
Declare what to do"]:::red --> B["Task Invocation
Call with input"]:::teal
        B --> C["Task Result
Get structured output"]:::blue
    end

    style A fill:#FF6B6B,color:#000000
    style B fill:#4ECDC4,color:#000000
    style C fill:#45B7D1,color:#000000

Task Definition：定义哪个 Agent 来处理这个任务，用什么模式（单轮/多轮）
Task Invocation：调用方传入结构化输入，像调用 Python 函数一样
Task Result：返回结构化输出，调用方不需要解析自然语言

Task Agent 可以直接作为 Workflow 图节点使用，这意味着你可以在图编排的基础上叠加结构化的委托——两个系统是协同设计、互相增强的。

HITL + 可恢复执行：企业级部署的最后一公里

做了这么多架构设计，到头来 Google 发现，企业级 Agent 最难的不是"Agent 有多聪明"，而是"Agent 运行到一半需要人拍板"。

任何一个真实的业务流程，都绕不开审批环节。稿子写完了要人审核、代码生成完了要人确认、支付请求要人授权。你的 Agent 再聪明，该等人还得等人。

ADK 2.0 的 HITL（Human-in-the-Loop）就是为这个场景设计的：

from google.adk import Agent, Workflow
from google.adk.workflow import NodeTool

approval_agent = Agent(
    name="approval_gate",
    instruction="""Pause and wait for human input.
    Ask: 'Approve this content? (yes/no)'""",
)

# HITL 节点：执行到此自动暂停，等人操作后恢复
content_pipeline = Workflow(
    name="pipeline_with_approval",
    edges=[
        (write_agent, approval_agent),
        (approval_agent, publish_agent, {"condition": "approved"}),
        (approval_agent, write_agent, {"condition": "rejected"}),
    ],
)

Workflow 跑到 approval_agent 这里会暂停，把状态序列化到 Session 里。人操作完之后，Runner 从 Session 恢复状态，从断点接着往下跑。整个过程对开发者来说几乎是透明的——你不需要写任何"暂停→等待→恢复"的样板代码。

v2.4.0 更进一步，把 HITL 支持扩展到了 NodeTool——这意味着即使是一个工具调用也可以触发人工审批。想象一个"调用支付 API"的工具，在执行前弹出一个人工确认——这种粒度在以前需要大量自建逻辑，现在框架原生支持。

设计哲学：确定性代码 + 自适应 AI 推理

讲完三个技术模块，回头看看 Google 到底为什么推倒重来。答案是一句话：

不要让 LLM 控制流程，让图引擎控制流程。

这个设计洞察很反直觉。直觉上，Agent 框架应该让 LLM 做主——毕竟 LLM 是最智能的部分。但 Google 发现，让 LLM 决定"下一步调用哪个 Agent"是一条死路。

原因很简单：LLM 不可预测，但生产系统需要可预测。

你能接受一个"有时候对、有时候不对"的路由逻辑吗？在生产环境里，路由错误意味着任务卡住、重复执行、结果丢失。这些错误的修复成本远高于 LLM 的推理能力带来的好处。

graph TB
    subgraph "Design Principle"
        A["Deterministic Code
Controls FLOW"]:::blue
        B["Adaptive AI
Controls CONTENT"]:::teal
    end

    C["Workflow Graph
routing, fan-out, loops"]:::plum --> A
    D["LLM Agent
reasoning, generation"]:::mint --> B

    style A fill:#45B7D1,color:#000000
    style B fill:#4ECDC4,color:#000000
    style C fill:#DDA0DD,color:#000000
    style D fill:#98D8C8,color:#000000

ADK 2.0 的设计哲学就是这么分的：

图引擎（确定性代码）：负责"下一步做什么"——路由、分支、循环、重试。这些都是确定性的、可测试的、可复现的。
LLM Agent（自适应 AI）：负责"这一步怎么做"——理解、推理、生成。这些是 LLM 擅长的，不确定性在这里是资产而非负债。

这不是 Google 独有的发现。LangChain 的 LangGraph 也是类似思路，Anthropic 的 ACP 协议也在往这个方向走。但 ADK 2.0 做得最彻底——它干脆把整个框架重建在图引擎之上，而不是在图引擎上加一层兼容。

这个设计还有个隐蔽的好处：可测试性。确定性的图编排意味着你可以单独测试图的逻辑——给一个状态，验证它走了预期的边，调用了预期的节点。不需要跑真实的 LLM 推理就能验证流程是否正确。对于 CI/CD 来说，这省下的时间和算力是巨大的。

ADK 2.0 从 5 月发布至今，已经迭代了 4 个小版本（v2.1 到 v2.4），每次都围绕图引擎做增强——沙箱模板、Live API 集成、A2A 协议、Workflow as Tool、ManagedAgent。Google 显然不是在试水，而是在全力投入这个架构方向。

参考文档与链接

Google ADK Python — GitHub — 20.6K Stars, Apache 2.0, 多语言 Agent 框架
ADK 官方文档 — 完整 API 参考、指南和教程
ADK 2.0 CHANGELOG — v2.0.0 GA 到 v2.4.0 的完整变更记录
ADK 示例仓库 — Workflow、Task API、HITL 的完整示例代码
ADK Web UI — 多 Agent 可视化管理界面
DeepWiki: ADK Architecture — 模块级架构分析和源码位置
Workflow Engine 文档 — 图引擎的详细文档和 API 参考
LangGraph (LangChain) — 图编排对比框架
CrewAI — 角色扮演式多 Agent 对比
AutoGen (Microsoft) — 对话驱动多 Agent 对比

还在纠结选哪个 Agent 框架？评论区聊聊你的场景，帮你参谋一下。觉得分析有用就点个赞，让更多做 Agent 的朋友看到。

作者: itech001 来源: 公众号：AI人工智能时代网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。

本文首发于 AI人工智能时代，转载请注明出处。

Google ADK 2.0 架构革命：为什么把框架推倒重来？

Google ADK 2.0 架构革命：为什么把框架推倒重来？

本文提纲

ADK 的战略定位

1.x 的困境：三个分离的编排类

Workflow 图引擎：统一一切的核心飞轮

Task API：把 Agent 变成可调用的"函数"

HITL + 可恢复执行：企业级部署的最后一公里

设计哲学：确定性代码 + 自适应 AI 推理

参考文档与链接

相关阅读

ADK 2.4 多智能体实战：两个 Agent 互相博弈，50 道题零幻觉

DeerFlow 深度解析：如何用多智能体架构精准答题

Google 为什么重写 ADK 2.0？从 Agent 框架到 Agentic Workflow 的范式转移

Agent 面试三面全景：21 道题深度拆解