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

一、端到端的全流程设计

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

1、智能编排系统

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

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

---

2、多智能体架构

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

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

---

3、工具集成生态

多维度能力扩展

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

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

---

4、部署解决方案

全场景部署矩阵

部署模式	适用场景	技术实现
本地调试	开发测试环境	Docker容器化
云端托管	生产级扩展	Vertex AI Agent Engine
自定义基础设施	企业私有化部署	Cloud Run/Kubernetes集成

---

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>arallelAgent(<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[边缘设备]

六、ADK评估部分的流程与特点

---

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. 双维度评估体系

评估维度	权重	评估方法
轨迹评估	60%	6种匹配模式（精确/顺序等）
响应评估	40%	ROUGE文本相似度算法

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. 质量保障矩阵

指标	提升效果	业务影响
工具调用准确率	+35%	减少API误调用导致的系统错误
响应一致性	+50%	提升客户满意度评分2个点
问题解决率	+28%	降低人工客服介入量40%

2. 典型应用场景

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

---

七、AI Agent安全框架总结

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

1. 核心防护机制

防护层	关键措施	应用场景
身份与授权	- Agent-Auth（服务账号） - User-Auth（OAuth用户令牌）	控制工具访问权限，防止越权操作
输入/输出过滤	- 工具内嵌策略（如SQL查询限制） - Gemini内置安全过滤器（内容分级拦截） - 回调函数验证参数	拦截有害内容、限制工具调用范围
沙箱化代码执行	- Vertex代码解释器扩展 - 自定义无网络隔离环境	防止恶意代码影响系统或泄露数据
评估与追踪	- 输出质量评估 - 工具调用链路分析	监控Agent行为，优化策略
网络隔离（VPC-SC）	限制API调用仅限安全边界内资源	防止数据外泄

2. 主要风险与应对

风险类型	应对方案
目标偏离/误操作	工具参数校验、Agent-Auth最小权限、系统指令约束
有害内容生成	Gemini内容过滤器、LLM安全护栏（如Gemini Flash Lite实时过滤）
数据泄露	沙箱化执行、VPC-SC隔离、UI内容转义（防XSS）
间接提示注入	输入预检（如LLM安全护栏）、工具调用白名单

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的我确实不是特别喜欢，因为代码库其实不小

** Abstraction**	App-Specific Wrappers	Vendor-Specific Wrappers	Lines	Size
LangChain	Agent, Chain	Many (e.g., QA, Summarization)	Many (e.g., OpenAI, Pinecone, etc.)	405K
CrewAI	Agent, Chain	Many (e.g., FileReadTool, SerperDevTool)	Many (e.g., OpenAI, Anthropic, Pinecone, etc.)	18K
SmolAgent	Agent	Some (e.g., CodeAgent, VisitWebTool)	Some (e.g., DuckDuckGo, Hugging Face, etc.)	8K
LangGraph	Agent, Graph	Some (e.g., Semantic Search)	Some (e.g., PostgresStore, SqliteSaver, etc.)	37K
AutoGen	Agent	Some (e.g., Tool Agent, Chat Agent)	Many [Optional] (e.g., OpenAI, Pinecone, etc.)	7K (core-only)
PocketFlow	Graph	None	None	100
还是参考pocektflow官网的总结

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

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

ADK的核心差异化优势

1. 企业级工程化设计

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

• 混合编排范式

• 确定性工作流（类似PocketFlow的DAG编排）
• 动态LLM路由（类似AutoGen的对话协调）
• 同时支持：
• 这是与纯DAG框架（PocketFlow/LangGraph）或纯对话框架（AutoGen）的本质区别

• Google技术栈整合

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

与主流框架的客观对比

维度	ADK	CrewAI	PocketFlow	AutoGen
核心范式	混合编排	组织模拟	纯DAG	对话协调
生产部署能力	完整方案	需自行容器化	无	有限支持
工具生态	Google优先+自定义	适配器模式	无	开放式
学习曲线	陡峭	中等	平缓	中等
适用规模	企业级	中小型项目	实验原型	研究场景

典型应用场景建议

1. 首选ADK的场景

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

• 考虑替代方案的场景

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

演进趋势观察

1. 框架融合迹象

• CrewAI新增SequentialWorkflow（类似ADK的SequentialAgent）
• PocketFlow增加LLM节点支持（接近ADK的LlmAgent）
• 各框架正在互相借鉴核心思想：

• ADK的潜在挑战

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

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