adk-go 评测：用 Go 写 AI 代理，代码优先的取舍与边界
An open-source, code-first Go toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.
秒懂
- 它是什么？
- google/adk-go 是 Google 推出的 Go 语言 AI 代理开发套件，主打代码优先、多代理编排与云原生部署。本文从安装、架构、限制与替代方案等角度，评估它是否适合你的下一个代理项目。
- 适合谁用？
- adk-go 适合已经用 Go 构建云原生服务、需要把代理逻辑直接写进现有代码库的团队，尤其是那些重视并发性能和多代理编排的开发者。它不适合希望快速原型验证、依赖可视化拖拽界面或需要丰富预置工具生态的初学者，这类需求应转向 Python ADK 或直接使用 LangChain。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁该看
adk-go 解决的是在 Go 生态里构建 AI 代理时缺乏原生框架的问题。Python 有 LangChain 和自家的 Python ADK，Java 有 Spring AI，但 Go 开发者往往只能自己拼 HTTP 调用和状态机。adk-go 把代理定义、工具注册、多代理编排都收进一个模块，让代理逻辑能像普通 Go 代码一样被测试和版本管理。它面向的是写云原生应用的 Go 工程师，这些人看重并发和部署效率，不愿意为了代理功能引入一个 Python 微服务。文档明确说它针对 Gemini 优化，但模型无关，这点后面会细说。
代码优先的真实含义：从配置到函数
所谓代码优先，对比的是低代码或 YAML 驱动的框架。在 adk-go 里，代理不是一份声明式配置，而是 Go 结构体和方法。你定义工具就是写普通函数，编排逻辑就是调用其他代理的 Go 方法。这种做法的好处是类型安全，编译器能在运行前抓住接口不匹配。坏处是，代理的每次调整都要改代码并重新编译，没有热加载。README 强调这带来可测试性和版本控制，但对那些习惯用 JSON 调代理参数的产品经理或数据分析师来说，门槛很高。如果你需要非工程师也能修改代理行为，这个框架的代码优先特性反而是障碍。
安装与最小启动路径
安装只有一条命令：go get google.golang.org/adk/v2。注意模块路径带 v2 后缀，说明 API 已经有过一轮大版本演进。README 没有给出最小示例，但仓库的 examples 目录和文档站点提供了参考。文档还专门为 AI 编程代理准备了一份机器可读索引，地址是 adk.dev/llms.txt，以及单文件版 adk.dev/llms-full.txt。你可以把后者直接贴给 Copilot 或类似工具作为上下文，让它基于真实 API 写代码，而不是凭训练数据猜测。这个细节值得好评，它承认了 AI 编码助手在框架 API 上容易幻觉，给出了一种低成本的缓解手段。
多代理协作的机制：A2A 与 MCP 的支撑
仓库的 topics 列表里同时出现了 a2a 和 mcp，这是理解它架构的关键。A2A（Agent-to-Agent）是 Google 推动的代理间通信协议，MCP（Model Context Protocol）则是工具调用的标准。adk-go 支持这两种协议，意味着你的代理既能通过 A2A 与其他代理（可能由不同框架编写）对话，也能通过 MCP 挂载外部工具。这种设计把多代理系统从单一进程内的函数调用，扩展成了跨服务的网络协作。但 README 没有给出具体配置示例，因此实际使用中你需要自己去文档里找 A2A 的端点设置和 MCP 客户端的初始化代码。对新手来说，这层网络抽象会显著增加调试难度。
部署与运维：Cloud Run 是默认答案吗
README 明确提到支持容器化和云原生部署，特别点名 Google Cloud Run。对 Go 服务来说，编译成单一静态二进制再扔进容器是常规操作，adk-go 没有理由打破这个模式。但要注意，代理应用通常有状态，比如对话历史和会话上下文。Cloud Run 默认无状态，你需要把会话存储外置到 Redis 或数据库，这部分 README 没提，得自己设计。另一个运维点是 nightly 构建的持续集成，仓库有 nightly.yml 工作流，说明 API 仍在快速变化，每次升级依赖都可能遇到破坏性变更。生产环境锁定版本是基本要求，但即便如此，跨小版本升级也需要回归测试。
许可证与代码库的隐藏细节
项目整体采用 Apache-2.0，这对商用和修改都友好。但 README 特别指出一个例外：internal/httprr 目录有自己的许可证文件。httprr 很可能是一个 HTTP 请求录制重放工具，用于测试。它位于 internal 路径下，意味着你不能直接 import，只能通过间接依赖使用。这个许可证例外提醒我们，即使主项目是宽松许可，内部组件也可能有额外限制。如果你的合规流程要求扫描所有第三方代码，务必把 internal/httprr 单独纳入检查。另外，仓库同时存在 v1.6.x 和 v2.3.0 两个版本线，v2 是当前主线，但 v1 仍在收到补丁，这种双轨维护会让人困惑，选择版本时要以 v2 为准。
与 Python ADK 的差异：语言换来的控制
Google 同时维护了 Python、Java、Kotlin、TypeScript 等多个 ADK 实现，adk-go 只是其中之一。选 Go 版而不是 Python 版，本质是拿生态成熟度换运行时效率。Python ADK 有更长的历史、更多的社区示例和更丰富的预置工具，而 Go 版的优势在于并发模型和部署产物。如果你的代理需要处理高并发的工具调用，或者你已经有一个 Go 微服务架构，adk-go 能让你把代理内嵌进去，避免跨语言通信。反过来，如果你的团队主要写 Python，或者需要快速接入 Pandas、Requests 等库，Python ADK 是更顺手的路径。文档也承认 Go 版是面向云原生应用，而不是通用脚本场景。
边界与失败模式：何时它不合适
最明显的限制是模型绑定。虽然宣称模型无关，但优化针对 Gemini，这意味着非 Gemini 模型可能在工具调用格式或流式响应上遇到兼容问题，需要你额外适配。其次，代码优先意味着没有可视化调试界面，你无法像在 LangGraph Studio 里那样拖拽查看代理状态。排查多代理协作问题时，只能依赖日志和断点。第三，版本演进快，v2 和 v1 并行，nightly 构建存在，说明 API 尚未稳定，长期维护成本高。如果你的项目生命周期超过一年，要做好频繁更新代码的准备。最后，文档强调部署到 Cloud Run，但如果你用的是 AWS 或自建 Kubernetes，虽然理论上可以容器化，但不会有官方指南，你得自己解决服务发现和可观测性。
编辑结论
adk-go 适合已经用 Go 构建云原生服务、需要把代理逻辑直接写进现有代码库的团队，尤其是那些重视并发性能和多代理编排的开发者。它不适合希望快速原型验证、依赖可视化拖拽界面或需要丰富预置工具生态的初学者，这类需求应转向 Python ADK 或直接使用 LangChain。在采用前，请先验证三件事：确认你的模型提供商是否支持 A2A 或 MCP 协议，因为文档强调模型无关但实际优化针对 Gemini；检查你的部署目标（如 Cloud Run）是否能满足代理的会话状态管理需求；最后，阅读 internal/httprr 的独立许可证，它不同于 Apache-2.0，可能影响你分发二进制的方式。
社区笔记