【Google ADK 实战】01 思维转变：为什么 Google ADK 提倡“代码优先”？

原创于 2025-11-24 08:00:17 发布 · 115 阅读

CC 4.0 BY-SA版权

大家好，我是Tony Bai。

欢迎来到我们的专栏《Google ADK 实战：用 Go 构建可靠的 AI Agent》的第一讲。

如果你和我一样，是一个对 AI Agent 技术既兴奋又感到一丝迷茫的 Go 工程师，那么这个专栏正是为你我量身打造的。在过去的一年里，AI Agent 的概念铺天盖地，各种框架和平台层出不穷。我们见识了 LangChain 的灵活编排，也体验过各种低代码平台的一键生成。它们都极大地降低了我们体验 Agent 能力的门槛。

但作为一个追求工程严谨性的开发者，我在使用这些工具时，心中总会萦绕着几个问题：

我该如何对我的 Agent 进行单元测试？
当 Agent 的逻辑变得复杂时，一长串的“链”或一堆 YAML 文件该如何维护和版本化？
如何将这些 Agent 优雅地集成到我现有的、基于 Go 的微服务体系中？

这些问题，指向了当前 Agent 开发领域的一个核心痛点：许多工具在追求“快速上手”的同时，牺牲了软件工程中最宝贵的“可测试性”、“可维护性”和“可集成性”。

Google 最新开源的 Agent Development Kit (ADK) for Go，正是为了解决这些工程难题而来。它旗帜鲜明地提出了一个核心哲学——“代码优先 (Code-First)”。

在这一讲，我们不急于深入具体的 API，而是先来完成一次重要的思维转变。我将带你一起探讨：

当前的 Agent 开发存在哪些工程挑战？
Google ADK 的“代码优先”理念，究竟能为我们 Go 工程师带来什么福音？
ADK 的核心组件是如何支撑起这个理念的？
最后，我们会亲手跑通官方的第一个示例，直观地感受 ADK 的魅力。

准备好了吗？让我们一起开启这段探索之旅。

Agent 开发的“狂野西部”与工程师的“烦恼”

在 ADK 出现之前，构建 Agent 的主流方式大致可以分为三派，每一派都伴随着其特有的工程“烦恼”：

链式编排库 (以 LangChain 为代表): 它们通过“链 (Chain)”的概念将 LLM 调用、工具使用等步骤串联起来。这非常灵活，但也容易导致“回调地狱”或形成一个难以调试的“黑盒”。当你想弄清楚一个复杂的“链”内部到底发生了什么，往往需要大量的 print 和 debug。
声明式框架 (以 YAML/JSON 配置为主): 这类框架允许你通过配置文件来定义 Agent 的行为和工具。对于简单的场景，这很直观。但一旦逻辑变得复杂，比如需要根据上下文动态决定调用哪个工具，配置文件就会变得异常臃肿和晦涩，失去了代码的表达力和灵活性。
低代码/无代码平台: 这些平台提供了可视化的界面，让你通过拖拽来构建 Agent。这对于非开发者非常友好，但对于我们工程师来说，它几乎完全脱离了我们熟悉的 Git、CI/CD、自动化测试等现代软件开发工作流。