https://google.github.io/adk-docs/

谷歌的adk看完了以后感觉真的有很多，很不错的地方；

一、端到端的全流程设计

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

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. 系统核心组成

2. 工作流智能体对比

3. 通信机制深度对比

4. 设计模式技术细节

四、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驱动的灵活性，适合构建需要复杂系统交互的智能体应用。

关键优势：

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

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

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

关键实现要点：

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、主要部署方案

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

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小时"场景）

七、AI Agent安全框架总结

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的团队。其设计理念正在影响整个行业，但开发者仍需根据具体技术栈和场景需求做出选择。

其它的参考文献：