Google ADK：官方出品的多智能体开发套件，Agent 开发的统一底座

Google ADK：多智能体开发终于有了统一底座

开发多智能体系统最头疼的问题不是模型能力，而是工程基建割裂：每个框架都有自己的消息格式、工具调用协议和编排原语。Google ADK 解决的就是这个具体问题——提供一个官方定义的 Agent 开发统一层，让 Agent、工具与编排逻辑可以用同一套声明式接口描述、混排与部署。

项目背景

ADK 出自 Google DeepMind 与 Google Cloud 团队，前身是内部多智能体工作流沉淀。做它的直接原因是：Google 内部大量 AI 项目在 LangChain、CrewAI、AutoGen 之间来回迁移，每个框架对 `Agent`、`Tool`、`Memory` 的抽象都不兼容，导致出现大量低价值的胶水代码。

ADK 的理念跟 LangChain 完全不同：不是包一层「你可能用到的所有集成」，而是定义一套最小的、可嵌套的 Agent 运行协议。Agent 可以嵌套、可以并行编排、可以动态委派给别的 Agent，而底层通信协议与回调机制完全一致。如果你的业务是单一链式调用，ADK 反而杀鸡用牛刀；但只要涉及多角色协作、动态任务分发，这套抽象的价值就立刻体现。

核心功能解析

1. 原生的 Agent 嵌套与委派（Agent Delegation）

这是 ADK 区别于所有「并发请求管理器」类框架的关键。子 Agent 与父 Agent 是同一套抽象，父 Agent 在推理中可以通过 `transfer_to_agent` 直接把对话控制权交给子 Agent，这不是工具调用，而是运行栈的切换。这让你可以像写乐高一样组织系统：

# 定义子 Agent
web_researcher = Agent(
    model="gemini-2.0-flash",
    tools=[SearchTool(), FetchWebPage()]
)

# 定义父 Agent，可在推理中动态委派
root_agent = Agent(
    name="coordinator",
    model="gemini-2.5-pro",
    sub_agents=[web_researcher, code_reviewer],
    instruction="你是项目经理。先让 web_researcher 做资料查证，再由你汇总。"
)

注意它没有显式定义调用顺序——编排由 LLM 运行时决策，同时每个子 Agent 仍保持独立的状态与历史记录。

2. 支持会话级与 Agent 级的内存分层隔离

多智能体最难处理的问题是「谁该记得什么」。ADK 提供双层记忆作用域：Session State 范围是整个会话，对所有 Agent 可见；Agent State 只归属于某个 Agent。关键设计在于：当父 Agent 将控制权委派给子 Agent 时，子 Agent 无法直接篡改父 Agent 的状态，只能通过显式返回的消息回传信息。

这种作用域分离避免了大多数多 Agent 框架中常见的「共享全局内存」导致的状态污染问题，也让会话级内存可以安全地持久化（默认使用 SQLite，支持自定义后端）。

3. 基于真实命令的工具自动发现

ADK 虽然长于多 Agent 开发，却没有忽视单 Agent 的单步执行体验。它的 `agent dev` 内置了一个漂亮的 Jupyter 内核式调试面板，以及 `agent evaluate` 评估工具，支持自定义评估集与指标。

# 在 Jupyter 中本地运行多 Agent 应用，它会自动编排 & 可视化调用链
agent dev --interactive

# 对既有的多 Agent 项目跑回归评测
agent evaluate --evaluator=my_evalset.py

这套 CLI 的底层是基于 google.adk.cli 构建的，有真实产品级的使用闭环，而非玩具 demo。这本身就是一个技术亮点——很多开源框架至今仍然只有 SDK，没有配套的独立评测与调试工具。

快速上手

依赖要求：Python >= 3.10。安装并启动一个使用 Gemini 2.5 的基础 Agent 只需 4 条命令。需要先设置 GEMINI_API_KEY 环境变量。

# 1. 安装 ADK（会自动安装 google-genai SDK 依赖）
pip install google-adk

# 2. 用官方脚手架初始化一个带 websocket 传输的 Agent 项目
adk new my_agent --template=hello

# 3. 进入目录并启动本地交互式调试服务
cd my_agent
adk dev

# 4. 连接调试端或通过 CLI 直接对话试跑
adk run my_agent

如果你想在 Jupyter 环境里直接体验，也可以跳过脚手架，直接实例化一个 Agent 后调用 Runner.run(query=...) 。

技术亮点

这里说三个读了源码后我认为值得借鉴的设计决策。

第一：把「编排」（Orchestration）与「执行」（Execution）从数据流中分离。 ADK 内部核心是两套独立通道：`InvocationEngine` 负责事件循环调度，`AgentFlow` 只是数据变换的管线定义。工具调用、子 Agent 委派、模型推理全部作为普通事件在队列上流转，这让它支持了同步与异步两种运行后端，且调试时能重放完整事件流。对比 LangGraph 将「图」作为一等公民，ADK 的做法是「事件」作为一等公民，因此处理 While Loop（多轮人工审批）与多 Agent 嵌套时都不会产生深递归导致的栈溢出。

第二：仅将 Markdown 协议暴露给模型，而不是把对象序列化结果直接输入给 LLM。 在 google.adk.agents 源码中，LLM 实际收到的是渲染过的 Markdown 片段，包括对所有子 Agent、工具的结构化描述。这对模型输出的稳定格式化有明显帮助，因为 Gemini 与 GPT 系列模型在原生 Markdown 环境中的 schema 遵循率，普遍高于传入嵌套 JSON 字典。这是一个针对 LLM 特性做出的「反直觉但有效」的工程决策。

第三：框架级的流式协议（streaming）内置到核心代码中，而非后置补丁。 token 流的处理从根级 Agent 到子 Agent 全程统一为 AnnotatedChunk，没有任何 `Yield` 与 `Iterator` 类型混乱，开发者在多 Agent 场景写流式输出时不需要考虑「谁最先返回」。

同类对比

注意表中 ADK 与 LangGraph 是最像的，两者在学术设计上都要做 DAG 之外的循环控制。区别在于：LangGraph 要求你把循环画成一条图路径，ADK 则放任模型自行在下钻与返回两种动作里选择。如果做合规性的显式 step 定义，LangGraph 更可控；如果做开放式自主工作流，ADK 对模型更友好。

总结

一句话：如果你的团队在构建依赖动态规划与任务委派、而非简单固定流程的多 Agent 产品，Google ADK 是目前最接近「生产可用」的开源底座。用官方的话说——Agent 之间应该是互相配合完成目标的队友，而不是被代码牵着走的木偶。注意：如果你想只用一个框架就吃到 LangChain 十几万个第三方集成接口，那还是去用 LangChain；ADK 官方推荐的 Pattern 是 ADK 作为编排核心，工具层按需拼接。

用 ADK 不是「多一个框架选择」，而是把自己从「控制流里固定节点」的思路转化为「在状态机里划清授权界限」。开发者在改造已有代码时，也别想着一口气迁移所有功能，建议先只将单一职能的 Agent 迁入，配合 ADK 的dev面板观察完整事件链路后再推进下一步。