← Harness
Google ADK（Agent Development Kit）
Google
Python
TypeScript
开源
Apache-2.0
编排框架
图执行
工作流
多Agent
HITL
工具确认
eval
CloudRun
MCP
partial
lifecycle: active
核验 2026-10-01
「code-first 的 agent 编排框架，核心资产是一个图执行引擎」 —— 官方 README 第一项特性就说明了它的身份： > Workflow Runtime: A graph-based execution engine for composing **deterministic > execution flows** for agentic apps, with support for routing, fan-out/fan-in, > loops, retry, state management, dynamic nodes, human-in-the-loop, > and nested workflows.
适合与不适合
适合：要把多个 agent 组织成有分支、有循环、有人工介入的确定性流程； 要 code-first 定义逻辑便于测试与版本管理；团队在 Google 生态内； 需要内建 eval 与开发 UI。 不适合：只跑单个 agent、不需要图结构（用 OpenAI Agents SDK 更轻）； 需要文件级/网络级沙箱边界但不想自己实现；长上下文压缩是硬需求（本站未核验其手段）。
固定坐标系
8 个维度，与同赛道其他对象逐项可比。
- 模型与开放条件
- 官方口径：optimized for Gemini，但 model-agnostic。 README 原文："While optimized for Gemini, ADK is model-agnostic, deployment-agnostic, and compatible with other frameworks." ⚠ 未核验：model-agnostic 的具体实现路径（是否有 LiteLLM 一类适配层）、 非 Gemini 模型下工具调用与 structured output 的可靠性、 以及「optimized for Gemini」到底优化了什么。
- 运行位置
- 四种运行形态，全部由
adkCLI 或容器提供（README 核验）： ① 交互式 CLI（adk run <agent-folder段落）； ② 内建 Web UI：adk web agent-folder，官方说明支持 multi-agent directories 或直接指向单个 agent 文件夹； ③ Development UI：官方原文"A built-in development UI to help you test, evaluate, debug, and showcase your agent(s)" —— 这是内建的开发调试台； ④ 容器化部署：adk deploy docker --with_ui agent-folder>。 ⚠ 这四种都是你本地或你的云上进程，ADK 本身不提供托管服务 （托管要靠 Vertex AI Agent Engine 或 Cloud Run，那是 Google 的产品而非本框架的）。 - 本地文件
- ⚠ 本维度是本站最明显的证据缺口。 README 讲工具生态时列的是pre-built tools、custom functions、OpenAPI specs、 MCP tools 与既有工具接入（"all for tight integration with the Google ecosystem"）， 全文没有把「读写本地文件」列为一项能力，也没有描述默认的文件访问边界。 它给的是「怎么把工具接进来」，不是「文件访问受什么约束」。 未核验：默认沙箱机制、文件系统权限模型、是否需要自行处理容器挂载。
- 关机后的任务
- 图执行引擎本身就是「可靠运行」的答案 —— 官方列出的能力里，
retry、state management、human-in-the-loop、nested workflows都是控制流层面的原语，这正是「可靠长期运行」需要的构件。 单个 agent 内部的重试与循环可以由框架管（loops、retry 在特性列表里）。 ⚠ 未核验：跨进程/跨机的任务续跑语义（断掉后从哪个节点恢复）、 分布式部署时的状态存储方案（官方给了 Cloud Run / Agent Engine 两条路， 但状态持久化机制本文未核验）。 - 工具与扩展
- 工具生态是它最强调的部分，且MCP 是一等能力。 README 原文："Utilize pre-built tools, custom functions, OpenAPI specs, MCP tools or integrate existing tools"。 ⚠ 但这里有个本站必须标出的判断：README 把MCP 与 OpenAPI specs 并列， 说明它接MCP 的方式是把 MCP 当作一种工具来源，而不是像 OpenAI Agents SDK（
mcp>=1.19.0在dependencies里） 那样把 MCP 客户端做成框架级依赖。两者不是同一量级的一等公民，本站标记为推断，未核验实现。 另有一项官方独有能力：Tool Confirmation（HITL） —— 官方原文"a tool confirmation flow (HITL) that can guard tool execution with explicit confirmation and custom input"，对应文档tools/confirmation。 这是本站已收录对象里少见的「工具级人工确认」，与 OpenAI Agents SDK 的 input/output guardrail 是不同层次的东西。 - 上下文与记忆
- ⚠ 未核验，本站不下结论。 README 的特性列表里没有上下文压缩、摘要或落盘的任何表述。 图执行引擎的状态管理（
state management）管的是流程状态， 按本站「状态 ≠ 上下文」的主张，不能据此推断它有上下文管理。 长任务里工具输出的落盘、对话历史的裁剪，官方文档本文未取到，标记为未核验。 - 权限与限制
- 官方给的是「工具级人工确认」这一个明确机制： Tool Confirmation / HITL（文档
tools/confirmation），原文 "can guard tool execution with explicit confirmation and custom input"。 但这只是「执行前问一下」，不是边界划定： README 未提及沙箱机制、未提及文件系统权限模型、未提及网络访问控制 （对比本站收录的 OpenHands 提供了明确的 Docker 沙箱与 API key 机制， Codex SDK 源码里有三档SandboxMode 枚举）。 ⚠ 未核验：容器部署时的默认权限、是否支持网络白名单、是否有其它隔离层。 - 适合什么任务
- 适合：需要把多个 agent 组织成有分支、有循环、有人工介入的确定性流程； 要用代码优先（code-first）定义 agent 与工具，便于测试与版本管理； 团队在 Google 生态内（Cloud Run / Vertex / Gemini）； 需要内建 eval 与开发 UI；希望用同一套框架覆盖 Python 与 TypeScript。 不适合：只跑单个 agent、不需要图结构（用 OpenAI Agents SDK 或 Deep Agents 更轻）； 运行时需要文件级/网络级沙箱边界且不想自己实现（本站未核验其沙箱能力）； 长上下文的压缩与落盘是硬需求（本站未核验其手段）。
头号误解
- 以为是「Google 版 OpenAI Agents SDK」—— 它是编排框架，核心资产是 Workflow Runtime 的图执行引擎，不是单 agent 原语
- 把
state management读成「有上下文管理」—— 前者是流程状态，后者本站未核验 - 把 MCP 当成它的核心依赖 —— README 只把 MCP 列为工具来源之一，与 OpenAI Agents SDK 把
mcp>=1.19.0放进dependencies不是一回事 - 以为 Tool Confirmation 等于沙箱 —— 它是「执行前问一句」，不是边界划定
- 以为开源免费等于零成本 —— Cloud Run / Vertex Agent Engine 的云费用自理，且有
GOOGLE_GENAI_USE_ENTERPRISE开关 - 以为只有 Python —— 还有独立的 TypeScript 仓（
google/adk-js，1,426★），本站按粒度只收录 Python 主体 - 搞混仓库名 —— 样例仓显示为
google/adk-recipes，描述里写的是 adk-samples
价格
| 月度入口 | 框架免费（Apache-2.0）；设 GOOGLE_GENAI_USE_ENTERPRISE 后走 Google Cloud 企业平台计费 |
|---|---|
| 月度数值 | $0 |
| 额度说明 | 框架免费，但部署与模型两处都可能产生费用： （1）官方给的部署目标是 Cloud Run 与 Vertex AI Agent Engine，这两处都按云资源计费； （2）用 Gemini 走 Google 侧计费，用其它模型走各自 provider。 （3）GOOGLE_GENAI_USE_ENTERPRISE 的含义本轮已核验清楚 —— 它不是「解锁企业版功能」的开关，而是「把请求从 Gemini Developer API 切到 Google Cloud 企业平台（Gemini Enterprise Agent Platform / Vertex AI）」的 路由开关，计费口径随之改变。 官方 codelab 对三个变量的说明原文（核验 2026-10-01）： GOOGLE_GENAI_USE_ENTERPRISE = "This tells the ADK that you intend to use Google's Gemini Enterprise Agent Platform service for your Generative AI operations." GOOGLE_CLOUD_PROJECT = "ADK needs this to correctly associate your agent with your cloud resources and enable billing." GOOGLE_CLOUD_LOCATION = 地域，如 global。 ⚠ 最关键的一条：官方把「enable billing」明确挂在 GOOGLE_CLOUD_PROJECT 上。 设了这三个变量，agent 就落进你的 Google Cloud 项目开始计费； 不设则走 Gemini Developer API 那条路（另有其免费层与配额）。 且三个变量必须成组出现 —— 官方所有示例都是三个一起设，没有只设其一的写法。 ⚠ 官方示例里这个变量的取值不统一，有1（README / codelab .env）、TRUE、 True（Cloud 文档）三种写法，按Python 布尔语义大小写皆真，但取值不一致这点本身值得注意。 ⚠ 具体的 Gemini 单价与 Vertex AI Agent Engine / Cloud Run 的实际费率本站未逐项核验。 |
不同币种不做折算。优惠、地区、税费与登录后报价可能变化，购买前请到官方页面确认。
未知项清单
- 默认沙箱机制、文件系统权限模型、网络访问控制
- 对话上下文压缩 / 摘要 / 落盘策略
- 跨进程、跨机的任务续跑与恢复粒度
- 分布式部署下的状态存储方案
- MCP 接入的实现层次（框架级依赖 vs 工具来源）
- Python 与 TypeScript 版的能力对齐度
- Vertex AI Agent Engine 部署时状态的托管方式
- Gemini 单价与 Vertex AI Agent Engine / Cloud Run 的实际费率 （
GOOGLE_GENAI_USE_ENTERPRISE的含义已核验，费率未核验）
证据来源
判断可回到以下一手源复核。本站核验日 2026-10-01，内容更新日 2026-10-01。
| 类型 | 名称 | 链接 |
|---|---|---|
| repo | google/adk-python · 仓库（21,688★，Apache-2.0，核验 2026-10-01） | https://github.com/google/adk-python |
| docs | 主 README（Workflow Runtime / Task API / Tool Confirmation / 部署方式 / eval） | https://github.com/google/adk-python/blob/main/README.md |
| docs | 官方文档首页 | https://google.github.io/adk-docs/ |
| docs | 官方文档 · Tool Confirmation（HITL） | https://google.github.io/adk-docs/tools/confirmation/ |
| docs | 官方文档 · Agent Config（不写代码建agent） | https://google.github.io/adk-docs/agents/config/ |
| docs | Google Cloud 文档 · Manage sessions with Agent Development Kit（同一组三变量的另一种取值写法 TRUE / True，核验 2026-10-01） | https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sessions/manage-with-adk |
| repo | google/adk-js · TypeScript 版（1,426★，Apache-2.0） | https://github.com/google/adk-js |
| repo | google/adk-recipes · 样例集（10,404★） | https://github.com/google/adk-recipes |
| changelog | Releases（v2.10.0 @ 2026-09-25） | https://github.com/google/adk-python/releases |
实测记录
本站尚未完成实测。测试协议见 tasks/_protocol.md。
实测建议（按编排框架维度定制）：
| # | 测什么 | 为什么值得测 |
|:--:|---|---|
| 1 | 容器部署后的默认文件与网络权限边界 | 补上本站最大的缺口，也是选型前提 |
| 2 | 跑 adk eval 的最小完整案例 | 它是唯一内建 eval 的对象，值得看真实成本 |
| 3 | 流程中途 kill 进程后的恢复语义 | 官方有 retry / state management，但恢复粒度未核验 |
| 4 | Tool Confirmation 在长循环里的人工打断频率 | 官方说可 guard，但要测实际打断次数 |
| 5 | 换成非 Gemini 模型后工具调用与 structured output 的可靠性 | 官方说 model-agnostic，验证代价 |
| 6 | Python 版与 TS 版的能力差距 | 两个独立仓，官方没说是否对齐 |
相关条目
- LangGraph本站最该对照的一对：同为图执行编排框架，且langgraph 的 checkpointer / interrupt 机制与 ADK 的 state management + HITL 是同类问题的两种答案。收录后者后本站才能给出编排框架内部的对照。
- CrewAI同为编排框架，但 crewai 以「角色/任务/流程」的抽象为中心，ADK 以「图节点」为中心 —— 抽象层次不同。
- OpenAI Agents SDK同为厂商系框架但形态相反：那个是单 agent 原语（primitives-only），ADK 是多 agent 编排。
- OpenHands反面对照：OpenHands 是带 Web UI 的调度平台、也可接第三方 agent；ADK 是 code-first 的库。两者都能编排，但一个面向界面、一个面向代码。
本页由 ai-agent-guide 数据层生成（CC BY 4.0）。
方法论与坐标系定义见仓库内 METHODOLOGY.md。