Google ADK（Agent Development Kit）

「code-first 的 agent 编排框架，核心资产是一个图执行引擎」 —— 官方 README 第一项特性就说明了它的身份：

模型与开放条件

官方口径：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」到底优化了什么。

运行位置

四种运行形态，全部由 adk CLI 或容器提供（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 更轻）； 运行时需要文件级/网络级沙箱边界且不想自己实现（本站未核验其沙箱能力）； 长上下文的压缩与落盘是硬需求（本站未核验其手段）。

本页由 ai-coding-agent-atlas 数据层生成（CC BY 4.0）。 方法论与坐标系定义见仓库内 METHODOLOGY.md。