Google 刚刚推出了用于 AI 代理的 ADK。我几个月前使用 MCP 在 .NET 上构建了类似的东西。以下是我的收获。
Source: Dev.to
在 4 月 30 日，我收到谷歌关于名为 GEAR 的邮件，它是他们用于构建 AI 代理的新项目，使用 ADK（Agent Development Kit）。我注册了，观看了介绍视频，并产生了一种奇怪的熟悉感。
这种模式很熟悉：定义工具，编写描述，将 AI 模型连接到这些工具，并让模型根据用户的请求决定调用哪个工具。
我在二月份用 .NET 完全实现了同样的功能，只是用了 MCP 而不是 ADK，并且把目标指向了 Kubernetes 集群，而不是数据库。
ADK 与 MCP 共同尝试解决的问题
这两个框架要解决的问题是相同的。你拥有一个 AI 模型，并希望它在现实世界中执行实际任务，而不仅仅是生成文本。为此，模型需要工具。工具只是模型可以调用的函数：搜索网络、查询数据库、重启服务器、创建文件等。
难点在于如何向模型清晰地说明每个工具的功能，以便它能够选择正确的工具。ADK 和 MCP 都通过 描述 来解决这个问题。你为每个工具编写描述，模型读取这些描述后决定调用哪个工具。
- ADK 在 Python、Java、TypeScript 或 Go 中实现。你定义一个包含名称、模型、指令和工具列表的代理，框架会处理其余工作。
- MCP 通过服务器协议实现。你为工具定义名称、描述和输入模式。任何兼容 MCP 的客户端——包括 Claude Desktop——都可以连接到你的服务器，并通过自然语言使用这些工具。
Source: …
我构建的内容
我的 MCP 服务器让 Claude 能够通过自然语言管理 Kubernetes 集群。你可以输入类似 “重启 idp-platform 部署” 的指令，Claude 会判断需要调用哪个工具、传入哪些参数并执行。
服务器公开了八个工具：
- 列出 Pod
- 获取 Pod 日志
- 扩缩部署副本数
- 重启部署
- 描述节点
- 获取集群事件
- …以及其他几个
每个工具都有详细的描述，告诉 Claude 该工具的功能以及何时使用。
.NET 中的工具定义示例
[McpServerTool, Description(
"Scale a Kubernetes deployment to a specific number of replicas. " +
"Use this when you need to increase or decrease the number of running instances. " +
"Provide the deployment name and namespace. " +
"Returns the updated replica count and deployment status.")]
public async Task ScaleDeployment(
[Description("The name of the deployment to scale")] string deploymentName,
[Description("The Kubernetes namespace")] string namespaceName,
[Description("The desired number of replicas")] int replicas)描述起到了重要作用：它告诉 Claude 该工具的作用、使用场景、所需参数以及返回内容。这正是 ADK 工具描述所做的工作。
两个框架共享的关键洞见
工具描述是接口层，而不是文档。
当你为工具编写描述时，你不是为开发者阅读而写，而是为 AI 模型阅读而写。这会改变你编写描述的所有方式。
- 明确说明 何时 使用此工具而不是类似工具。
- 清晰说明 输入 的含义。
- 明确指出 输出 包含什么。
模糊的描述会导致模型选择错误的工具或使用错误的参数调用它。
我是吃了苦头才学会的。我的第一个 scale deployment（扩容部署）工具的描述仅写了 “Scale a deployment.”（扩容部署）。Claude 总是把它和重启工具混淆。通过明确说明扩容与重启的区别，问题立刻得到解决。
它们的区别
| 方面 | ADK | MCP |
|---|---|---|
| Scope | 完整框架：多代理系统、双向流、会话管理、部署到 Google Cloud、评估、可观测性。 | 协议：更轻量、更专注、模型无关。 |
| Clients | 为以 Google 为中心的环境设计。 | 任何支持 MCP 的 AI 客户端（Claude Desktop、Cursor 等）。 |
| Use case | 面向拥有多个代理、审计日志、云规模的生产企业应用。 | 开发期间或轻量级集成，只需一种可靠方式让 AI 客户端调用你的服务。 |
对我的使用场景而言，MCP 是正确的选择。我希望 Claude 在开发期间能够控制本地的 Kubernetes 集群。我并不需要多代理编排或托管的云部署——我需要的是 Claude Desktop 能原生使用的协议。
如果我要为拥有多个代理、审计日志和云规模的企业构建生产级 AI 系统，ADK 会更合适。
.NET 角度
Neither ADK nor MCP has official .NET support as a primary language.
- ADK supports Python, Java, TypeScript, and Go.
- The official MCP SDK supports Python and TypeScript.
There is a community‑maintained .NET MCP SDK that works well, and that is what I used. It does mean you are working slightly outside the official tooling for both frameworks if you are a .NET developer.
That said, building an MCP server in .NET is straightforward once you have the SDK. The tooling, testing, and deployment story is the same as any other .NET application.
让我印象深刻的 ADK 功能
- Built‑in Dev UI – 当你在本地运行 ADK 代理时，会得到一个浏览器界面，准确显示代理的思考过程、调用了哪些工具、传递了哪些参数以及返回了什么。对代理推理过程的可视化是我在调试 MCP 服务器时自己实现的功能。
- Multi‑agent support – ADK 允许你定义代理层级，主代理可以将任务委派给专门的子代理。虽然我目前还没有用到，但我能理解它在复杂工作流中的重要性。
Source code
My MCP Kubernetes Manager 是开源的。它还包括一个 AI 生成的发布说明流水线——每个合并的 PR 都会自动生成结构化的变更日志条目。
选择 AI 代理框架
使用 Claude 和 GitHub Actions。
如果你是一名 .NET 开发者，对构建 AI 代理感兴趣，即使官方工具尚未完善，MCP 也值得探索。该协议稳固，社区 SDK 表现良好。
如果你是全新起步且语言灵活性重要，ADK 值得认真考虑。Google 显然在其背后投入了真正的工程力量。
无论哪种方式，思维模型都是相同的：工具、描述，以及读取这些描述的 AI。这部分无论使用哪个框架都不会改变。