@whichxjy

@whichxjy

💭💭💭💭💭💭

Google ADK 框架调研

ADK（Agent Development Kit） 是 Google 推出的 Agent 框架。

支持特性

目前支持的特性：

  • Agent
    • Agent 搭建 + Tool 调用（MCP / API / 本地函数）
    • 多 Agent 编排
    • 短期记忆和长期记忆
    • 流式调用，包括多模态实时接口
    • Callback，可以用于支持 Trace
  • 配套组件
    • 代码执行器，用于执行 LLM 生成的代码
    • Agent 部署（本地代码 -> Docker 镜像 -> 云部署）
    • 本地 UI，用于调试
    • Agent 效果评估

ADK 能力总览

分析：

  • 目前 Agent 搭建能力基本对齐其它开源框架的实现，但还没支持 RAG 组件。
  • 在内部实现机制上，ADK 使用事件驱动模式，对标 LangChain/LlamaIndex 的流式实现。

运行时

Agent 运行时采用事件驱动架构，实现上就是 Python 的 Generator。

事件包括 Agent 生命周期里的各种输入、输出以及中间状态，比如 LLM 响应、工具调用等。

参考：

ADK Runtime 的核心结构：

ADK Runtime

在这个模型里：

  • Runner 接收用户请求，并返回事件流。
  • Event Processor 负责驱动 Agent 执行过程。
  • Execution Logic 执行具体的 Agent、LLM 调用、Callback 和 Tool。
  • Services 提供 Session、Artifact、Memory 等服务，并读写底层存储。

运行流程

Runner 触发 Agent 运行，并和记忆组件读写数据。Agent 内部的 LLM Flow 先进行请求前置处理，再调用 LLM，最后进行响应后置处理。一次 Flow 结束后，会判断是否需要结束，或者是否需要切换到上层 Agent、同级 Agent、子 Agent。

ADK Agent 运行流程图

LLM Flow

LLM Flow 使用洋葱模型，定义了前置处理器 RequestProcessor 和后置处理器 ResponseProcessor 的统一接口，并支持配置多个前后处理器。

class BaseLlmRequestProcessor(ABC):
    @abstractmethod
    async def run_async(
        self,
        invocation_context: InvocationContext,
        llm_request: LlmRequest,
    ) -> AsyncGenerator[Event, None]:
        ...

class BaseLlmResponseProcessor(ABC):
    @abstractmethod
    async def run_async(
        self,
        invocation_context: InvocationContext,
        llm_response: LlmResponse,
    ) -> AsyncGenerator[Event, None]:
        ...

LLM Flow 的执行过程：

  1. 前置处理。 a. 按序执行所有前置处理器：设置 LLM 请求，比如模型名称、模型参数，以及提前调用一次 LLM 创建 Plan 并拼接在 Prompt 中（Planner 组件）。 b. 基于配置的 Tool，将 Tool 描述（Schema）放在 LLM 请求中，也就是填写 Function Call 参数。
  2. 调用 LLM。
  3. 后置处理。 a. 按序执行所有后置处理器：比如根据 LLM 生成的代码调用代码执行器。 b. 如果 LLM 触发了 Function Call，则调用对应的 Tool。这里也包括了调度 Agent 的 Tool，如果 LLM 判断需要调度到其它 Agent，则进行切换。

记忆模块

Session Service：存储用户和 Agent 交互的历史记录。比如存储用户和 chatbot 的聊天记录，用于多轮对话。

  • 写入数据：记录每次 Agent 的输入、输出和中间状态等，按 user_id 和 app_name 划分。可存储到 MySQL 等组件。
  • 读取数据：在调用 Agent 时，传入 session id，获取最近 N 条的交互记录。

Artifacts Service：存储文件（这里叫 Artifacts），比如多模态 Agent 中的图片和视频，不适合直接存储在 Session Service，需要用对象存储。

  • 写入数据：将记录写入 Session Service 前，将对话消息里的图片和视频进行存储，得到对应的 Key。因此 Session Service 里不会存储图片和视频的二进制文件，而是存储 Artifacts Key。
  • 读取数据：封装加载 Artifacts 的 Tool，并给 LLM 提供当前 session 相关的 Artifacts 名称，让 LLM 可以调用 Tool 来获取 Artifacts，并将原始二进制数据放在消息中。

Memory Service：长期记忆，可看作历史调用记录的 RAG 组件。

  • 写入数据：对话结束后，将 Session 写入支持关键词匹配的存储组件，比如使用向量数据库。
  • 读取数据：封装 search 工具，让 Agent 可以生成 query 检索历史调用记录。

多 Agent 编排

Agent 采用树形结构组织，一个 Agent 可以有一个上层 Agent，以及多个子 Agent。

Agent 类型层级：

ADK Agent 类型层级

除了上文提到的 Agent 切换，还可以用如下方式编排 Agent：

  • SequentialAgent：顺序运行多个 Agent。
  • ParallelAgent：并发调用多个 Agent。
  • LoopAgent：循环执行多个 Agent，直到需要结束。

Updated: