为什么 AI Agent 会淘汰微服务架构

微软 CEO 萨提亚·纳德拉最近表示，“SaaS 时代结束了”。未来将由AI Agent取而代之。原因在于 SaaS 应用程序只是围绕关系数据库构建的业务逻辑。而随着 AI Agent 获得处理业务逻辑的能力，大部分 SaaS 将被替代。而 SaaS 时代基于数据库交互的系统架构也会有巨大的变革。

如今，大多数 AI Agent 都采用微服务架构，这也是云原生 SaaS 的主流设计模式。虽然这种架构在 LLM（大语言模型）的早期阶段是必要的，但如今它已变得过时，甚至开始阻碍 AI Agent 的发展。

在本文中，我将讨论为什么 AI Agent 的业务逻辑必须强耦合提示词、向量数据库、外部工具、模型推理框架、与大模型本身。单体架构对于 AI Agent 而言更加合适。

AI 微服务的历史

当 OpenAI 首次发布 API 服务时，模型只能在 OpenAI 的服务器上运行。因此，开发者不得不构建通过 Web 服务 API 与 LLM 交互的应用程序，这就是经典的微服务模式。其他的 LLM 服务提供商，如 Anthropic 和 Mistral，很快也采用了基于 API 的微服务方法。

随着开源 LLM 的出现，在自有服务器上运行模型推理成为可能。但大多数计算机没有 GPU，而传统云原生软件对 GPU 虚拟化和容器化的支持也不好。最简单的方法仍然是将所有 GPU 机器作为一个独立的集群管理，并使用该集群以微服务方式提供 LLM 推理服务。在这种情况下，业务逻辑应用程序（或 AI Agent ）运行在 CPU 服务器上，并通过 Web 服务 API 与 GPU 服务器交互。一个很好的例子是 Nvidia 的 NIM 微服务，以及主要云服务（如 AWS Bedrock、Azure OpenAI 和 Google Cloud Vertex AI）提供的 LLM API。

微服务的关键特性是松耦合。在 AI 的背景中，这意味着应用程序可以将 AI 模型和 GPU 计算视为黑盒。它们只需调用标准 API。

这种架构对于 SaaS 应用程序效果良好，因为就像 Nadella 提到的， CRUD 数据库是可替换的，可以作为标准 API 背后的黑盒处理。

然而，对于 AI Agent而言，业务逻辑往往依赖于 AI 模型本身。

多模型时代

大语言模型的“ Scaling law (规模定律)”是过去几年推动 AI 进步的关键力量。

然而，正如OpenAI前首席科学家 Ilya Sutskever 博士在刚过去的 NeurIPS 2024 上指出，模型预训练的规模定律即将终结。OpenAI 的 o1 系列模型证明，AI 规模定律的下一个阶段将是推理规模化。也就是说，通过增加推理计算量，发展多个“推理链”（Chain of Thoughts），然后评估它们以生成最终答案。推理规模化的 agentic 方法是让多个专用 AI Agent为同一个问题提供不同的解决方案。

在充满专用 AI 模型的 agentic 世界中，Agent 应用程序必须与后端模型紧密结合，才能充分利用模型的能力。

松耦合的问题

随着模型和 Agent 的多样性增加，松耦合系统变得脆弱且难以维护。如果某个业务逻辑功能只能与特定 AI 模型配合使用，则它必须与模型捆绑并一起版本化。以下是一些这种相互依赖的典型例子：

• 提示与模型的耦合：使用基于 API 的云 LLM 服务的开发者都清楚，不同模型对提示的响应各不相同。例如，“使用 XML 标签作为上下文”的提示在 Anthropic 的 Claude 3.5 上效果很好，但对其他 LLM 的效果较差，这是由于这些模型在后训练中使用的数据格式不同。即使是 OpenAI 的模型，适用于 4o 模型上非常有效的提示,在链式思维推理模型(如 o1 和 o3)上也可能表现不佳。
• 功能与模型的耦合：Huggingface 上已有超过 10,000 个开源 LLM 和其他生成式 AI 模型。
  • 如果你的 Agent 是多模态的，比如视频翻译 Agent ，则需要多模态 LLM（如 Llama 3.2 或 Qwen VLM），或结合语音、文本和图像模型。
  • 对于语音和图像生成应用，AI 模型必须经过微调或补充 LORA 层，才能以特定风格生成内容。因此,如果你有一个生成超真实人脸的 Agent ,你将需要一个具有专门 LORA 微调的 stable diffussion 或 Flux 模型。
  • 专门用于编码的 Qwen Coder 系列 LLM 被广泛应用于如 Cursor 和 Zed 的 Rust 编码助手 Agent 中，且通常有其特定的提示格式。
  • llama-3-groq 模型在工具调用方面表现出色，即使是小型模型（如 8b）也表现优异。
• 知识上下文与模型的耦合：大多数知识型 Agent 面临的挑战是如何确定可放入 LLM 上下文的内容量。这取决于两个因素：LLM 的上下文大小以及 LLM 利用上下文的效率。例如，有些模型的上下文足够大，可以容纳整本书、完整电影或完整代码库。LLM 通常能够更好地“记住”上下文的开头和结尾。知识型 Agent 往往需要复杂的业务逻辑，以根据具体模型确定如何将外部知识内容添加到上下文中。
• 资源占用与模型的耦合： Agent 可能运行在各种受限设备上。例如，Apple Intelligence 在本地设备上运行较小的模型以完成简单任务。LlamaEdge 和 Gaia Network 支持在个人电脑和边缘设备上运行个人 Agent 应用。它们的业务逻辑与可以在消费设备上运行的模型大小相关联。

我们需要一种专注于简化紧耦合应用开发、部署和维护的 AI Agent 架构。这种架构应将 LLM、知识数据库、工具/函数和业务逻辑捆绑在一起。

容器化的 AI Agent

针对紧耦合 AI 应用程序的架构解决方案非常直观：将业务逻辑应用、知识库、数据库、AI 运行时和 AI 模型打包到一个容器镜像中。这样可以确保每个组件一起测试和更新，从而保证 Agent 应用作为一个整体始终正常工作。

LlamaEdge 容器镜像是一个很好的例子。关于如何运行 LlamaEdge 容器的完整教程可以在此处找到。每个镜像包含：

• 带有 GPU 驱动的基础 Linux 操作系统
• 支持几乎所有开源语音、文本和图像模型的基于 Wasm 的 AI 运行时
• 一个跨平台 SDK，允许开发者创建可以捆绑到镜像中的 Agent 应用

这个堆栈不依赖 Python，因此轻量且高效。除模型文件外，整个容器镜像大小不到 100MB（相比之下，标准 Python PyTorch 容器镜像至少需要 4GB）。

LlamaEdge 运行时支持多种模型类型和模型架构，这对于需要最新模型功能的 Agent 开发者至关重要。

有了跨平台的 LlamaEdge SDK ，Agent 开发者只需使用 Rust、JavaScript 或 Web API 编写应用程序，而无需关心底层 GPU 框架（如 Nvidia 的 CUDA 或 Mac 的 Metal）。开发者只需构建一次 Agent 应用程序，将二进制 Wasm 文件捆绑到容器镜像中，即可在所有支持的 GPU 平台上运行。

除了 LlamaEdge 镜像，还可以使用 Gaia Network 的容器镜像，它们进一步整合了向量数据库、知识快照和 frp 隧道工具，使开发者能够创建带有知识补充的 Agent 应用程序。

解耦的价值

常规 Linux 容器足以部署和管理 AI Agent和模型。但 Linux 容器在提供 GPU 访问方面表现并不好。例如，Mac 的 GPU 无法供容器化应用访问。即使是常用的 Nvidia GPU，主机上需要单独安装 Nvidia 容器工具包，容器内还需要匹配的 Nvidia CUDA 驱动程序。

虽然 Agent 的业务逻辑需要与 AI 模型紧密结合，但将 AI Agent与其运行的异构 GPU 平台解耦确实具有重要价值。

Wasm 运行时本身是一种安全的沙箱，可以成为 Linux 容器的替代方案。像 CRI-O 和 crun 这样的容器运行时允许 WasmEdge 和 LlamaEdge 应用程序直接访问主机上的 GPU。这样，一个单一编译的 Wasm 二进制应用程序可以在任何 GPU 硬件上运行任何生成式 AI 模型——无需 Python 依赖。