ADK 2.0：Google 的代码优先多智能体框架，但升级前先看这几点
An open-source, code-first Python toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
秒懂
- 它是什么？
- google/adk-python 是 Apache-2.0 许可的 Python 框架，主打用代码和图表编排多智能体。本文拆解其 Workflow 运行时、Task API 和部署路径，指出 2.0 的破坏性变更与适用边界。
- 适合谁用？
- 适合需要把多智能体流程当作软件工程来管理、且愿意绑定 Google 生态的团队采用。具体来说，如果你要部署到 Cloud Run 或 Vertex AI Agent Engine，或者需要图形化的确定性执行流，ADK 2.0 比自研编排省力。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁该看
ADK 2.0 解决的是多智能体应用在工程化时遇到的结构问题：多个 Agent 之间如何编排、如何复用、如何部署。它把 Agent 定义成 Python 对象，把流程定义成图，而不是靠提示词硬拼。目标用户是已经写过几个原型、开始头疼状态管理和任务分发的开发者。README 明确说它面向从简单任务到复杂系统的场景，并强调 code-first，意思是逻辑、工具、编排都写在 Python 里，方便测试和版本控制。它不是给只想拖拽界面的人准备的，虽然也有 Agent Config 这种少写代码的入口，但主路径仍然是写代码。
Workflow 运行时：图不是装饰，是执行引擎
2.0 的核心机制是 Workflow 运行时，一个基于图的执行引擎。README 给出的示例很直白：两个 Agent 用 edges 连接，根节点是 Workflow，边从 START 指向生成水果的 Agent，再指向生成益处的 Agent。这个图不是静态描述，它支持 routing、fan-out/fan-in、循环、重试、状态管理、动态节点和嵌套工作流。这意味着你可以把条件分支和并行任务直接画进流程图，而不是在 Agent 内部用 if 语句硬编码。这个设计把编排逻辑从模型提示词里抽出来，变成可测试的代码结构。对需要确定性流程的场景，比如先检索再生成，或者多步工具调用，这个运行时比让模型自己决定下一步更可控。
Task API 与多智能体协作的两种模式
Task API 是 2.0 新增的亮点，专门处理 Agent 之间的结构化委托。它支持多轮任务模式和单轮受控输出，还有混合委托模式。多轮模式适合需要来回澄清的任务，单轮模式适合要求 Agent 一次给出固定格式结果的场景。README 还提到 task agents 可以作为 workflow 节点，这意味着你可以把一次委托当作图中的一个步骤，和其他节点串联。这种设计把 Agent 间通信从自由文本升级为有明确任务语义的调用。对比之下，1.x 时代的多 Agent 协作更依赖模型自然语言协商，Task API 则给了开发者一个强制的接口。代价是你要学习新的 API 概念，而且文档没有给出具体的调用代码，实际使用需要翻官方文档确认参数。
安装与运行：约束文件是必读项
安装命令很常规：pip install google-adk，要求 Python 3.10 以上。但 README 特别强调要用 companion constraints 文件来保护传递依赖。具体做法是先下载对应 Python 版本的约束文件，比如 Python 3.10 就运行 curl 获取 constraints-3.10.txt，然后 pip install 时加上 -c 参数。这不是可选项，README 用了 recommended 这个词，说明项目方担心依赖冲突。运行方式有两种：adk run path/to/my_agent 启动交互式 CLI，adk web path/to/agents_dir 打开 Web UI，后者支持多 Agent 目录。开发 UI 内置了测试、评估和调试功能，这对本地迭代很有用。注意 adk 命令需要安装后才有，且路径指向的是 Agent 文件夹而非单个文件。
2.0 的破坏性变更：会话格式不向后兼容
最需要警惕的是 2.0 对 agent API、事件模型和 session schema 做了破坏性变更。README 明确警告：ADK 2.0 生成的会话可以被 1.28 及更高版本读取，因为额外字段会被忽略，但与更早的 1.x 版本不兼容。这意味着如果你有生产环境跑着 1.27 或更早版本，升级到 2.0 后旧会话数据可能无法被新代码读取，反之亦然。这个限制直接影响长期运行的对话应用。另一个隐含问题是，事件模型的变更可能影响你已有的日志或监控代码，因为事件结构变了。如果你依赖 1.x 的会话导出或分析管道，升级前必须做数据兼容性测试。
部署与生态绑定：Cloud Run 与 Vertex AI
部署路径是 ADK 的一个卖点，但也是它的绑定点。README 说可以轻松容器化并部署到 Cloud Run，或者用 Vertex AI Agent Engine 做扩展。这两个都是 Google Cloud 服务，意味着如果你不在 Google Cloud 上，就需要自己写容器和编排。框架声称 deployment-agnostic，但官方推荐的路径明显偏向 Google 生态。工具生态方面，它支持自定义函数、OpenAPI 规范、MCP 工具，还强调与 Google 生态紧密集成。对已经在用 Gemini API 的团队，这种绑定是便利；对想保持云厂商中立的团队，这可能是负担。
备选方案：LangGraph 的图思路对比
如果不想绑定 Google，LangGraph 是更常见的替代。LangGraph 也把 Agent 流程定义为图，支持条件边、循环和状态管理，但它不绑定特定模型或云厂商，可以搭配 OpenAI、Anthropic 或本地模型。关键差异在抽象层级：LangGraph 的图更底层，你需要自己管理状态对象和节点函数；ADK 的 Workflow 则把 Agent 作为一等公民，边直接连接 Agent 实例，代码更简洁。另一个差异是部署：LangGraph 有 LangGraph Platform，但那是商业产品，自托管需要自己搭。ADK 的 Agent Engine 是托管服务，省去运维，但代价是云锁定。如果你已经写了大量 LangGraph 代码，迁移到 ADK 需要重写图定义，因为两者的节点和状态模型不同。
维护成本与许可边界
维护成本主要来自版本节奏。README 说发布周期大约是每两周一次，这个频率意味着你需要持续跟进更新，否则会积累大量破坏性变更。2.0 的破坏性变更已经证明这一点。项目采用 Apache-2.0 许可，这对商业使用友好，允许修改和再分发，但要注意 Google 的商标和品牌使用规定，这不在 README 范围内，需要另行确认。另一个维护点是约束文件，每次升级 Python 版本或 ADK 版本都要重新下载匹配的 constraints 文件，否则可能引入依赖冲突。对于长期项目，建议把约束文件纳入 CI 的依赖锁定流程。
编辑结论
适合需要把多智能体流程当作软件工程来管理、且愿意绑定 Google 生态的团队采用。具体来说，如果你要部署到 Cloud Run 或 Vertex AI Agent Engine，或者需要图形化的确定性执行流，ADK 2.0 比自研编排省力。不适合只做单轮对话、或要求会话数据跨 1.27 及更早版本兼容的项目。采用前先验证三件事：第一，用约束文件安装并跑通官方 greeting_agent 示例，确认 2.0 的事件模型符合你的日志需求；第二，检查现有 1.x 会话是否都能被 2.0 写出且被 1.28+ 读取，否则需要迁移脚本；第三，如果你依赖 MCP 工具或自定义 OpenAPI 规范，先测试 ADK 的工具确认流程是否满足你的安全审批要求。
社区笔记