谷歌Agent Development Kit核心概念以及与其它框架的横向对比、适用场景总结与建议

它融入很多框架不曾涉及的概念

1、智能编排系统

灵活工作流引擎• 支持两种编排模式：

• 预设式流水线：通过工作流代理（Sequential顺序执行/Parallel并行执行/Loop循环执行）构建确定性流程
• 动态路由系统：基于LLM驱动的智能决策（LlmAgent转移机制）实现自适应行为流

2、多智能体架构

模块化协作体系• 采用分层组合架构：通过多个专业化Agent的层级组合构建可扩展应用 • 核心能力：

• 分布式任务协调
• 智能委派机制
• 跨Agent通信协议

3、工具集成生态

多维度能力扩展

1. 预置工具集：搜索引擎/代码执行器等开箱即用组件
2. 自定义扩展：支持用户函数开发
3. 生态集成：

• 兼容LangChain/CrewAI等第三方框架
• 支持Agent工具化（将其他Agent作为工具调用）

4、部署解决方案

全场景部署矩阵

5、评估与监控

三维评估体系

1. 结果质量评估：最终输出准确性/完整性
2. 过程追溯评估：执行轨迹分步验证（基于预定义测试用例）
3. 性能指标监控：响应延迟/资源消耗等运行时指标

6、可信Agent开发

负责任AI实践框架

1. 安全防护：

• 输入输出过滤机制
• 敏感数据管控
• 可解释性：
• 决策过程透明化
• 执行日志可审计
• 伦理约束：
• 偏见检测算法
• 价值对齐规范

二、核心Agent类型

ADK提供三类核心Agent来构建复杂应用：

1. LLM智能体基于大语言模型(LLM)驱动，具备自然语言理解、逻辑推理、动态决策能力，可自主选择工具链，适合需要灵活语言处理的任务。

2. 流程控制智能体包括顺序执行(Sequential)、并行处理(Parallel)、循环操作(Loop)三种模式，通过预定义流程精确控制其他Agent的执行逻辑，适用于结构化业务流程。

3. 自定义智能体通过继承BaseAgent基类开发，支持实现个性化业务逻辑、特殊控制流或定制化系统集成，满足高度定制化场景需求。

三类Agent可通过组合使用构建复杂智能系统，开发者可根据场景需求灵活选用。

三、adk的多智能体框架设计特点

1. 系统核心组成

组件	技术特性	实现机制	设计考量
LLM智能体	- 基于Gemini等大语言模型 - 支持动态任务委派(transfer_to_agent) - 可绑定工具集	- 自动生成函数调用 - 通过output_key保存输出到状态	- 需明确description供路由决策 - 指令需包含委派逻辑
工作流智能体	- 不直接处理任务 - 三类子类：   ▪ SequentialAgent   ▪ ParallelAgent   ▪ LoopAgent	- 通过sub_agents定义子任务流 - 自动管理上下文分支(InvocationContext.branch)	- 并行执行需避免状态键冲突 - 循环执行需设置max_iterations或终止条件
自定义智能体	- 继承BaseAgent - 实现_run_async_impl方法 - 非LLM逻辑（如数据库操作）	- 可自由访问session.state - 通过EventActions(escalate=True)终止循环	- 适合确定性任务 - 需自行处理状态持久化

2. 工作流智能体对比

类型	执行控制	状态管理	典型代码特征
顺序智能体	- 严格按sub_agents列表顺序执行 - 前序智能体的output_key自动成为后序输入	- 共享同一InvocationContext - 状态键直接传递	<br>SequentialAgent(<br>  sub_agents=[A, B, C]<br>)<br>
并行智能体	- 所有子智能体同时启动 - 执行顺序不确定	- 共享基础状态 - 每个子智能体获得独立branch路径	<br>ParallelAgent(<br>  sub_agents=[X, Y],<br>  state_keys=["api1","api2"]<br>)<br>
循环智能体	- 重复执行子智能体序列 - 每次迭代共享状态	- 通过EventActions.escalate终止 - 可读取历史迭代状态	<br>LoopAgent(<br>  max_iterations=5,<br>  sub_agents=[process, check]<br>)<br>

3. 通信机制深度对比

机制	触发方式	数据流向	适用场景
共享状态	- 被动读写session.state - 通过output_key自动保存	单向传递： 生产者 → 状态字典 → 消费者	- 顺序管道 - 循环迭代中的中间结果
LLM委派	- LLM生成transfer_to_agent()调用 - 由AutoFlow拦截处理	动态跳转： 当前智能体 → 目标智能体（需在sub_agents范围内）	- 不确定的任务路由 - 需要LLM理解语义的场景（如客服转接）
显式调用	- 通过AgentTool包装智能体 - 父智能体的LLM显式调用工具	同步返回： 父智能体 → 子智能体 → 结果返回父智能体	- 确定性功能调用 - 需要获取直接返回值的场景（如数学计算服务）

4. 设计模式技术细节

模式	智能体组合	关键ADK特性	实现示例
协调器模式	1个LLM协调器 + N个专业子智能体	- LLM的transfer_to_agent - 子智能体明确description	客服系统： - 路由智能体根据问题类型   转接至「支付」或「技术」子智能体
生成-评审	SequentialAgent [生成器, 评审器]	- 生成器设置output_key="draft" - 评审器读取state['draft']	内容创作： - 生成文本 → 检查事实性 → 输出最终结果
并行收集	SequentialAgent [   ParallelAgent[采集器1, 采集器2],   聚合器 ]	- 并行智能体定义独立output_key - 聚合器读取多个状态键	数据仪表盘： - 并行获取销售/库存数据 → 合并生成报告
迭代优化	LoopAgent [   处理器,   条件检查器(触发escalate) ]	- 检查器通过EventActions(escalate=True)终止循环 - 处理器更新state['current_result']	代码优化： - 生成代码 → 运行测试 → 未通过则继续优化
人工介入	自定义工具 + 外部系统集成	- 工具调用阻塞等待人工输入 - 通过CallbackContext恢复流程	财务审批： - 大额交易时暂停流程 → 等待人工批准 → 继续执行

四、adk工具使用的特点
1. 模块化设计理念
• 工具被设计为独立的模块化组件（如Python函数或Agent），通过标准化接口与核心LLM交互
• 支持同步/异步工具调用，特别通过Long Running Function Tools处理耗时任务
1. 动态调用机制
• 采用智能的function calling流程：LLM先进行意图识别→工具选择→参数生成→执行→结果整合
• 支持工具链式调用，前序工具输出可作为后续工具的输入
1. 上下文感知能力
• 通过ToolContext提供丰富的运行时上下文：
• 状态管理（State）：支持多级会话状态持久化（app/user/session级别）
• 流程控制（EventActions）：可跳过总结、转交其他Agent或终止LoopAgent
• 认证集成（auth_response）：自动处理OAuth等认证流程
• 数据服务：直接访问Artifact Service存储文件，调用Memory Service检索历史
1. 多类型工具支持
• 内置工具：开箱即用的Google Search、RAG等常见功能
• 自定义工具：支持开发者创建功能明确的Function Tools
• Agent-as-Tool：可将子Agent作为专用工具调用
• 第三方集成：兼容LangChain/CrewAI等生态工具
1. 开发者友好设计
• 强调工具定义的规范性：
• 要求清晰的函数命名（verb-noun结构）
• 强制类型注解（Type Hints）
• 结构化docstring（需包含参数说明、返回值示例）
• 推荐返回字典包含status字段明确执行结果
• 自动处理非dict返回值，统一封装为标准格式
1. 智能引导机制
• LLM通过工具元数据（名称/参数/docstring）自主决策调用逻辑
• 在Agent指令中可直接引用工具函数名，通过自然语言描述调用条件和异常处理策略

这些特性使ADK既能保证工具调用的规范性，又保持了LLM驱动的灵活性，适合构建需要复杂系统交互的智能体应用。

特点分类	核心能力	技术实现
模块化设计	工具作为独立组件（Python函数/Agent）与LLM解耦	支持Function Tools、Agent-as-Tool、Long Running Tools
动态调用机制	LLM自主决策工具调用流程	五步流程：意图识别→工具选择→参数生成→执行→结果整合
上下文感知	工具运行时获取完整上下文信息	通过ToolContext提供： • State（状态管理） • EventActions（流程控制） • 认证/数据服务
多类型工具支持	覆盖从内置到第三方工具的生态集成	三类工具： 1. 内置工具（如Google Search） 2. 自定义Function Tools 3. 第三方工具（LangChain等）
开发规范	强制标准化工具定义，提升LLM调用准确性	要求： • 语义化函数名（如get_weather） • 类型注解（Type Hints） • 结构化docstring
智能引导	通过自然语言指令控制工具使用逻辑	在Agent指令中： • 指定调用条件（如"当用户询问天气时"） • 定义错误处理策略（如"返回错误时重试"）

关键优势：

1. 灵活性与规范性平衡：既保持LLM自主决策，又通过标准化接口约束工具行为
2. 全链路集成：从工具定义、上下文管理到结果处理形成闭环
3. 企业级扩展：支持认证、状态持久化等生产环境需求

当然，它也支持当下最流行的mcp功能

ADK调用MCP的核心特点总结：

特点	说明
协议与框架分离	MCP是标准化通信协议，ADK是AI开发框架，二者通过MCPToolset桥接实现互通
双向集成模式	1. ADK作为客户端调用外部MCP服务 2. ADK工具通过MCP服务暴露给其他客户端
动态工具发现	ADK运行时动态获取MCP服务器提供的工具列表，无需预先硬编码工具定义
异步通信机制	全程基于异步IO（asyncio），工具调用和结果返回均为非阻塞操作
连接生命周期管理	必须显式管理MCP连接（通过exit_stack），避免资源泄漏
协议转换层	自动转换： - MCP工具描述 → ADK工具接口 - ADK工具结果 → MCP响应格式
混合部署支持	支持本地进程间通信（stdio）和远程SSE连接两种模式
状态保持	MCP会话保持长连接状态，不同于无状态HTTP请求

关键实现要点：

1. 客户端模式：ADK通过MCPToolset封装以下操作：

• 启动/连接MCP服务进程（如npx运行Node.js服务）
• 转换工具接口（list_tools→BaseTool）
• 代理工具调用（call_tool转发到MCP服务）

• 服务端模式：需自行实现：

• ADK工具到MCP描述的转换（adk_to_mcp_tool_type）
• 调用ADK工具并封装结果（如JSON序列化到TextContent）

典型应用场景：

• 快速集成现成MCP服务（如文件操作/地图API）
• 将ADK生态工具开放给支持MCP的其他AI系统（如Claude）
五、ADK框架部署方式全解析

1、主要部署方案

部署方式	技术实现	适用对象	核心优势
全托管服务	Google Vertex AI Agent Engine	Google云深度用户	自动扩缩容/免运维
容器化服务	Google Cloud Run	需要Serverless容器的团队	按需计费/快速启动
自定义容器	Docker + K8s/YARN	混合云/非Google云用户	完全自主可控
本地服务化	内置HTTP服务器	开发调试阶段	快速验证

2、非Google云用户的实质选择

graph TD
    A[ADK构建的Agent] --> B[标准Docker镜像]
    B --> C{部署目标}
    C --> D[自建K8s集群]
    C --> E[第三方容器服务]
    C --> F[边缘设备]

1、作业流程

graph TD
    A[定义评估目标] --> B[准备测试数据]
    B --> C{选择评估方式}
    C -->|单元测试| D[创建.test.json文件]
    C -->|集成测试| E[创建.evalset.json文件]
    D --> F[运行pytest/adk eval]
    E --> G[运行adk web/adk eval]
    F --> H[生成评估报告]
    G --> H

2、作业特点

1. 双维度评估体系

2. 动态阈值配置

{
  "criteria": {
    "tool_trajectory_avg_score": 0.9,
    "response_match_score": 0.7
  }
}

3. 会话状态流程

graph LR
    S[初始状态] --> T1[用户提问1]
    T1 --> A1[Agent响应1]
    A1 --> T2[用户提问2]
    T2 --> A2[Agent响应2]
    A2 --> F[最终状态验证]

3、业务价值分析

1. 质量保障矩阵

2. 典型应用场景

• 金融领域：验证贷款审批Agent是否严格按"信用查询→风险评估→批复生成"流程执行
• 电商领域：测试售后工单处理逻辑（如"已付款未发货+超48小时"场景）

Google Cloud Vertex AI通过多层防护机制确保AI Agent的安全性、可靠性与品牌价值观对齐：

1. 核心防护机制

2. 主要风险与应对

3. 最佳实践图表

graph TD
    A[用户输入] --> B{安全护栏?}
    B -- 安全 --> C[工具调用]
    B -- 拦截 --> D[返回预设响应]
    C --> E[身份验证]
    E --> F[参数校验]
    F --> G[执行: 沙箱/最小权限]
    G --> H[输出过滤]
    H --> I[评估日志]

4. 关键建议

• 最小权限原则：工具仅暴露必要功能，通过tool_context动态限制（如仅允许查询特定表）。
• 深度防御：结合Gemini过滤器（内容层）+ 回调校验（逻辑层）+ 网络隔离（基础设施层）。
• 成本优化：高频安全检查使用轻量模型（如Gemini Flash Lite）。
• 品牌安全：定制系统指令，禁止讨论竞争对手或偏离品牌调性内容。

通过以上分层防护，可构建既强大又安全的AI Agent系统。

直观感受与比较

adk比较crewai、agno、pocektflow、langgraph这些框架

crewai和agno等，都有编排的概念，但他们更偏向于多agent的架构，pocketflow和langraph这两者则本身是以图引擎作为编排的手段的 。

crewai更像是在架构一整套的公司与组织的运行机制，其工具集合试用过后发现，其实内部很多都是adapter模式去引用了更多成熟的工具库，但这种机制也有弊端，因为只是简单的适配器

agno很轻量，与crewai比较，要轻量的多，其内部也有rag等工具集的集成，对知识库等也有涉及，并且其实本身内部也有一个简单的webui，并且性能埋点方面，它也有集成一个自己的性能、调试的框架（默认是开的，还需要通过环境变量去关闭，挺隐蔽的，需要注意一下）

langraph就不多评价了，毕竟用的不多，文档比较复杂

pocektflow其实是graph派的，但是是绝对轻量级的，说起来，它倒是和adk一样，对agent有事前事中事后的概念，我是觉得post处理这些，对于llm的类型的应用真的很重要。

它的官网上也有总结很多MAS（多agent的设计模式）

它这两张图已经总结的非常好了，就不多说了

当然，谷歌的adk也有对应的涉及模式的总结，其实两者可以合并一下，单独出一篇，agent设计模式

agno的teams，对应的则是MAS的设计模式，它里面就三种

crewai也有teams的概念，不过crewai的我确实不是特别喜欢，因为代码库其实不小

AI针对以上内容给出的最后总结与建议

基于对Google ADK框架的全面分析，结合行业主流框架的公开资料，我们可以得出以下客观比较：

ADK的核心差异化优势

1. 企业级工程化设计

• 唯一提供从开发调试到生产部署的全生命周期工具链（对比LangChain/CrewAI等侧重开发期）
• 内置Vertex AI深度集成，支持企业级需求：VPC-SC隔离、IAM权限控制、审计日志等

• 确定性工作流（类似PocketFlow的DAG编排）
• 动态LLM路由（类似AutoGen的对话协调）

• 同时支持：
• 这是与纯DAG框架（PocketFlow/LangGraph）或纯对话框架（AutoGen）的本质区别

• 深度集成Gemini系列模型、Vertex AI服务、Google Search等
• 提供MCP协议支持等专有通信方案（行业独家）

与主流框架的客观对比

典型应用场景建议

1. 首选ADK的场景

• 需要对接Google Cloud服务的企业应用
• 严格的安全合规要求（如金融、医疗）
• 混合型工作流（预设流程+动态决策）

• 快速原型开发 → PocketFlow
• 多模型研究 → AutoGen
• 非Google技术栈 → CrewAI

演进趋势观察

1. 框架融合迹象

• CrewAI新增SequentialWorkflow（类似ADK的SequentialAgent）
• PocketFlow增加LLM节点支持（接近ADK的LlmAgent）

• 各框架正在互相借鉴核心思想：

• 对非Google环境的支持有限（如无法直接部署到AWS/Azure）
• 工具生态开放性弱于LangChain等社区驱动框架

综上，ADK代表了当前企业级AI Agent开发的工程化标杆，特别适合深度使用Google Cloud的团队。其设计理念正在影响整个行业，但开发者仍需根据具体技术栈和场景需求做出选择。