Google 为什么重写 ADK 2.0？从 Agent 框架到 Agentic Workflow 的范式转移
Google 为什么重写 ADK 2.0？从 Agent 框架到 Agentic Workflow 的范式转移
先猜猜看，ADK 2.0 最核心的改动是什么？往下看。
本文提纲
- ADK 的前世今生：从 100 行原型到 Google 官方框架
- 为什么 ADK 2.0 要重写：纯 Agent 的四个致命问题
- 核心武器：Graph-Based Workflow 的设计哲学
- 动态 Workflow：当 asyncio 遇上 Agent
- 多 Agent 协作：Coordinator 模式与三种协作语义
- 写在最后：Agent 框架的未来方向
2025 年 4 月，Google Cloud Next 上，Thomas Kurian 正式发布了 Agent Development Kit（ADK）。这个开源框架承载了 Google 对多 Agent 系统的全部理解——它也是 Google Agentspace 和 Customer Engagement Suite 背后的核心技术。
但仅仅过了 15 个月，2026 年 7 月，ADK 2.0 Beta 就来了。
这不是一次普通的版本升级。ADK 2.0 的核心不是加新功能，而是重新定义了 Agent 框架的架构范式。如果你还在用 "Agent = LLM + Tools + Prompt" 的思维去理解它，你会完全错过这次升级的真正意义。
ADK 的前世今生：从 100 行原型到 Google 官方框架
在深入技术之前，我想先讲讲 ADK 的历史。因为它很能说明一个问题：一个优秀的 Agent 框架，是怎么长出来的？
ADK 的诞生可以追溯到 2024 年 10 月 3 日。那天，Google 工程师 Bo Yang 写下了 ADK 的第一个原型——恰好 100 行 Python 代码，放在一个叫 agent.py 的文件里。这个原型已经包含了后来 ADK 的核心概念：Agent 类（name、model、description、instruction）、子 Agent（当时叫 children）、以及 before_model_call / after_model_call 回调。
Bo Yang 在自己的博客中回忆："当时还没有 'ADK' 这个名字，也没有人——包括我自己——知道这段代码会变成什么。" 他用这个 100 行的原型做了一个客服系统 Demo，跑通后自己都不敢相信。
就是这 100 行代码，引爆了 Google 内部。团队迅速组建，从原型到产品化，最终在 2025 年 4 月的 Google Cloud Next 上正式发布。
ADK v1 的成绩单很漂亮：支持 Python、Java、Go、TypeScript、Kotlin 五种语言，内置模型实例化、回调控制、上下文抽象，集成了 MCP 协议生态，可以直接部署到 Vertex AI Agent Engine。对于一个诞生仅半年的框架来说，这已经是惊人的速度。
但 v1 有一个根本性问题。
为什么 ADK 2.0 要重写：纯 Agent 的四个致命问题
ADK v1 本质上是一个 "Agent-Centric" 框架。开发者定义 Agent、挂载 Tools、写 System Prompt，然后让 LLM 自己去编排执行流程。这种方式在原型阶段非常爽——几行代码就能跑起来一个多 Agent 系统。
但一旦进入生产环境，问题就暴露了。
问题一：LLM 编排 → 成本爆炸
想象一个简单的业务流程：A → B → C → D → E。其中 B 和 D 需要 LLM 的推理能力，但 A、C、E 只是确定性逻辑（数据转换、条件判断、API 调用）。
在纯 Agent 模式下，LLM 在每一步都要做出 "下一步做什么" 的决策。这意味着：即使只是从 A 到 C 这种确定性转换，你也要等 LLM 推理一遍。每多一次推理，就是多一次 token 消耗和延迟。
ADK 官方博客举了一个例子：同样是处理一个退货请求，纯 Agent 方案的成本是用 Workflow 混合方案的 3-5 倍。原因很简单——你把大量 "if-else" 级别的决策交给了 LLM，而 LLM 的推理成本远高于一行 if condition: do_something()。
问题二：无限循环与 hallucination
纯 Agent 的另一个生产环境灾难是无限循环。Agent 在调用工具后，LLM 需要解析工具输出、决定下一步动作。如果 LLM 产生了幻觉，错误理解了输出，它可能反复调用同一个工具，或者在几个工具之间死循环。
传统的解决方案是加 Guardrails 和 Max Steps 限制。但这只是打补丁——它没有解决根本问题：执行控制权完全在 LLM 手里，而 LLM 天生就不是为顺序执行设计的。
问题三：不可测试
纯 Agent 系统的测试非常困难。因为你无法断言 "当输入 X 时，Agent 会执行 Y"。Agent 的行为是概率性的，同样的 Prompt 每次可能走不同的路径。
这对于企业的合规要求是致命的。SOX、SOC 2、HIPAA 等合规框架要求可审计、可复现的执行路径。而纯 Agent 系统的行为是不可复现的。
问题四：不可观察
当 Agent 在一个死循环里转圈时，你很难判断到底是 Prompt 不对、工具返回了意外数据、还是 LLM 产生了幻觉。因为整个执行过程是黑盒的——你只有输入和输出，中间发生了什么取决于 LLM 的 "自发行为"。
这四个问题加起来，构成了 ADK 团队重写 v2 的核心动机。官方博客说得很直接：
"Methods focused on the model, like guardrails, skills, and prompting, can only go so far. For production-grade reliability, you need full deterministic control over your application flow."
核心武器：Graph-Based Workflow 的设计哲学
ADK 2.0 的答案是一个巧妙的概念反转：不是让 Agent 去编排执行流程，而是让 Workflow 去编排 Agent。
这个想法并不新鲜——LangGraph 早就做了类似的事情。但 ADK 2.0 的实现有几个关键的设计决策，值得深入分析。
从 "Chain" 到 "Graph"
如果你用过 LangChain 的 Chain，你会发现它本质上是一个线性的 Pipeline：A → B → C → D。这适用于流水线式的场景，但现实中的业务流程很少是纯线性的。
ADK 2.0 选择了 Graph（有向图）作为 Workflow 的底层结构。每个节点（Node）可以是：
- Function Node：纯 Python 函数，零 LLM 开销
- LLM Node：调用 LLM 进行推理
- Tool Node：调用外部工具/API
- Human Node：人工介入检查点
边（Edge）定义了节点间的流转条件，由开发者用代码明确表达，而不是靠 LLM "猜"。
确定性路由
这可能是 ADK 2.0 最重要的设计。在纯 Agent 系统中，LLM 看到工具输出后，"决定"下一步做什么。在 ADK 2.0 的 Workflow 中，路由逻辑是在代码中明确定义的：
# ADK 2.0 Workflow 示例（伪代码）
@workflow.node
def check_refund_eligibility(ctx):
# 纯 Python 逻辑，无 LLM 开销
return {"is_eligible": ctx.input["days_since_purchase"] <= 30}
@workflow.edge
def route_decision(ctx):
# 开发者明确定义路由逻辑
if ctx.result["is_eligible"]:
return "draft_refund_email" # 转到 LLM 节点
else:
return "reject_refund" # 转到拒绝节点这样做的好处是：
- 成本：只有需要推理的步骤才调用 LLM
- 速度：确定性路由在微秒级别完成，不需要 LLM 推理
- 可测试：可以 mock LLM 节点的输出，测试所有路由分支
- 安全：即使 LLM 节点被操纵，Workflow 图中不存在通往非法操作的路径
严格的状态边界
ADK 2.0 的另一个精妙设计是状态隔离。每个节点只接收它需要的数据子集，而不是完整的执行上下文。这听起来像是个小细节，但在实践中极其重要：
纯 Agent 模式下，随着执行步数增加，上下文窗口会越来越臃肿。Tool A 的输出、Tool B 的错误信息、Tool C 的中间结果……全部塞到 LLM 的上下文中。这不仅浪费 token，还会干扰 LLM 的注意力。
ADK 2.0 的 Workflow 引擎只在节点之间传递必要的数据，每个 LLM 节点看到的 Prompt 是干净、聚焦的。这直接提升了推理质量。
动态 Workflow：当 asyncio 遇上 Agent
静态图有一个明显的局限：你必须在编码阶段就把所有可能的路径画出来。对于简单的业务流程（审批、退款、订单处理），这没问题。但对于需要动态决策的场景——比如 "根据用户输入生成不同的搜索策略"——静态图就变得笨重了。
ADK 2.0 的解决方案是动态 Workflow。核心思想是：用 Python 的控制流来表达动态的编排逻辑。
# 动态 Workflow 的 Python 原生表达
@dynamic_workflow
async def search_workflow(query: str):
# Step 1: 用 LLM 分析查询意图
intent = await llm_analyze(query)
# Step 2: 根据意图动态选择搜索策略
if intent == "code_search":
results = await search_github(query)
elif intent == "doc_search":
results = await search_docs(query)
else:
# 多路并行搜索
results = await asyncio.gather(
search_web(query),
search_knowledge_base(query),
)
# Step 3: LLM 综合结果
summary = await llm_summarize(results, intent)
return summary这段代码看起来就像普通的 Python async 函数。但它背后的 Workflow 引擎自动处理了：
- 检查点：每个
await之后自动保存状态，失败时从最近的检查点恢复 - 可恢复性：如果进程崩溃，重新运行会自动跳过已经成功的步骤
- 可观察性：每一步的执行状态、耗时、输入输出都可以被监控
Checkpointing 在文档中只有一句话描述，但在生产环境中它是杀手级特性：
"Successful sub-nodes are automatically skipped when resuming the workflow, making complex logic durable and resumable by default."
这意味着一个运行了 20 分钟的复杂 Workflow，如果在第 18 步崩溃了，重新启动后不会从头开始——它会从第 18 步继续。对于企业级的长时 Workflow，这直接决定了系统是否可用。
多 Agent 协作：Coordinator 模式与三种协作语义
ADK 2.0 引入了三种 LLM 协作模式，每一种对应不同的 Agent 协作语义。
Chat Mode
全交互模式。Agent 和用户可以自由对话，Agent 完成子任务后不自动返回父 Agent，而是等待用户或 Coordinator 的下一步指令。
适用场景：需要深度交互的客服场景、个性化咨询。
Task Mode
任务模式。子 Agent 被调用后执行特定任务，完成后自动返回 Coordinator。如果过程中需要用户澄清，子 Agent 可以短暂和用户交互，但完成后必须交回控制权。
适用场景：有明确边界的子任务，如 "分析这个文档并提取关键信息"。
Turn Mode
单轮模式。子 Agent 只执行一轮就返回结果，没有后续对话。这是效率最高的模式，也是确定性最强的一种。
适用场景：快速数据查询、状态检查、格式化转换。
Coordinator 模式的现实意义
这三种模式的设计透露出 ADK 团队的一个核心判断：多 Agent 系统的根本问题不是 "让 Agent 之间怎么聊天"，而是 "控制权什么时候回到谁手里"。
在纯 AutoGen 或 CrewAI 式的多 Agent 对话中，Agent 之间的交互是平等、开放式的。Agent A 说完，Agent B 接话，Agent C 再补一句——整个过程像一群人在开会。这种模式的不可预测性是生产环境的噩梦。
ADK 2.0 的 Coordinator 模式本质上是一个控制权管理协议：
Coordinator → 分发任务 → Sub-agent 执行 → 自动交回控制权 → Coordinator 判断下一步这不是让 Agent "自由对话"，而是用明确的控制流约束 Agent 的协作范围。每一个 Sub-agent 的角色是 bounded（有边的），它不知道 Coordinator 之外的任何事情，只能看到自己需要的数据。
这种设计在代码层面确保了：无论 AI 怎么跑偏，系统的执行路径始终在开发者定义的图中。
写在最后
ADK 2.0 不是 LangGraph 的翻版，也不是 AutoGen 的竞品。它的设计透露了一个更深层的信号：Google 认为 Agent 框架的下一个阶段不是 "更强的 Agent"，而是 "更可控的执行引擎"。
回顾一下这两年 Agent 领域的演变：
- 2024 年：大家都在做 Agent 框架——定义 Agent、挂 Tools、画 Chat Loop。关键词是 "让 Agent 更聪明"
- 2025 年：大家发现 Agent 不可控——加 Guardrails、加 Human-in-the-Loop、加 Step 限制。关键词是 "让 Agent 更安全"
- 2026 年：ADK 2.0 的答案是——把 Agent 塞进 Workflow。关键词是 "让 Agent 可编程"
这个演变的本质是：Agent 框架正在从 AI 问题变成软件工程问题。
你在 ADK 2.0 里看不到多少 "Prompt 技巧" 或 "模型微调指南"。但你看到的是一整套软件工程的基础设施：可测试的 Workflow、可恢复的执行引擎、可观察的运行状态、明确定义的状态边界、版本可控的动态逻辑。这些都是传统软件工程的标配，但在 Agent 框架领域还是新鲜事。
Google 在官方博客中说："Building production-grade AI applications doesn't require choosing between pure code and pure agents."
这句话点出了 ADK 2.0 的设计哲学：LLM 不是银弹，代码也不是。真正可靠的生产系统，是把两者各放在对的位置上。
如果你正在构建生产级的 Agent 系统，ADK 2.0 提出的这个问题值得认真思考：你的业务流程中，哪些步骤真正需要 LLM 的推理能力？哪些步骤只是"因为用了 Agent 框架所以让 LLM 做了"？
答案可能会让你重新审视你现在的架构。
参考文档与链接
- Google Developers Blog: Why we built ADK 2.0 — ADK 官方博客，阐述了 ADK 2.0 的设计动机和核心特性
- Announcing ADK Go 2.0 — Go 版本的 ADK 2.0 发布公告
- ADK Insider: When It Was Born — Bo Yang 撰写的 ADK 诞生故事，包含 100 行原型的完整代码
- ADK 2.0: From Chatbots to Collaborative, Deterministic AI Workflows — Ali Arsanjani 对 ADK 2.0 架构的深度分析
- What Does ADK 2.0 Beta Actually Change? - Kartaca — 第三方对 ADK 2.0 技术变化的拆解分析
- Agent Development Kit: Making it easy to build multi-agent applications — ADK v1 发布博文
- Supercharge your AI agents: The New ADK Integrations Ecosystem — ADK 集成生态扩展公告
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
关注公众号，获取更多 AI 技术干货！
