本文来详细介绍下如何开发一个企业级的 LLMOPS 平台。基于此，后半部分会介绍下我的「云原生 AI 实战营」知识星球的课程项目：EasyAI 的架构和实现。
概念解析： LLMOPS、MLOPS、智能体平台
LLMOPS 和智能体平台的定义：
-
智能体平台： 大语言模型(LLM) 应用开发平台，开发者可以快速搭建生产级的生成式 AI 应用；
-
LLMOPS ： LLMOps（Large Language Model Operations）是一个涵盖了大型语言模型（如GPT系列）开发、部署、维护和优化的一整套实践和流程。类似于 MLOPS，但专门针对 LLM。LLMOPS 专注于 LLM 的整个声明周期操作和管理，包括：数据管理、模型微调、模型部署、模型评估、模型监控、模型维护等；
-
MLOPS： 机器学习运维（MLOps）是一组工作流实践，旨在简化机器学习（ML）模型的部署和维护过程。它在软件工程的DevOps实践基础上，专注于机器学习模型的整个生命周期管理。
Coze、FastGPT、Dify 平台的定位：
-
Coze：
-
Dify：
-
FastGPT：
智能体平台、LLMOPS、MLOPS 关系：
在各类跟 AI 相关的技术平台中，你一定经常会听到智能体平台、LLMOPS、MLOPS，你是否知道这 3 个概念之间的区别和联系呢？
下图是 3 个概念之间的区别和联系：
MLOPS 是机器学习运维，用来训练通用的模型。LLMOPS 属于 MLOPS 中的一部分，主要用来解决 LLM 的生命周期管理。通过 LLMOPS，企业可以很容易的训练出 需要的LLM，提供给智能体平台集成。
智能体平台可以集成 LLM 作为其核心组件（例如，用 LLM 驱动智能代理的决策逻辑），而 LLMOps 则为这种集成提供模型运维支持（如部署、监控和优化 LLM）。
智能体应用开发的 4 个层级
在各类跟智能体相关的技术文章或课程中，也经常会介绍如何开发一个智能体。那么智能体开发有哪些方式，这些方式的优缺点又是什么？根据技术栈深度、定制化能力，我将智能体开发分为 4 个等级：L1、L2、L3、L4。等级越高需要的技术能力越高、可定制化程度也越高，也越能满足企业的真实智能化需求。
- L1：直接基于 Dify、Coze 等智能体平台，通过前端页面，创建一个智能体应用。
- 优点：简单、便捷。
- 缺点：可控性最差。
- L2：直接调用 LLM 提供的 API （SDK）开发智能体应用；
- 优点：相较于 L1，具备一定的定制能力；
- 缺点：有一定工作量，实现的智能体应用能力有限；
- L3：基于自研的智能体平台创建智能体应用。
- 优点：可控性强，功能相对完善；
- 缺点：开发工作量大、缺乏数据处理、模型微调等能力。
- L4：最高接的智能体应用开发方式。
- 优点：完全可控、可以实现功能非常强大的智能体应用；
- 缺点：开发工作量相较于 L1、L2、L3 都大。
上面介绍了智能体应用开发的 4 个层级，LLMOPS 平台，也就是 EasyAI 项目，处在 L4 层级，功能完全可定制，能够满足企业业务的定制化场景需求。
行业内有哪些优秀的智能体平台？
在开发 EasyAI 项目的过程中，也调研了很多国内外优秀的智能体平台。这里也简单介绍下。调研的智能体平台分为：
- 国外智能体平台调研；
- 国内智能体平台调研。
国外智能体平台调研
国外智能体平台比较多，比较受欢迎的有：Vertex AI 、n8n、Crew AI、Flowise、Lindy、Camel、FastGPT。
Vertex AI 是谷歌云的 MLOPS 平台，功能比较丰富。其他，n8n、Camel、FastGPT 也功能相对丰富些。其他智能体平台都比较偏 Workflow。
结论：智能体平台功能调研，感觉完全可以参考国内的。功能上来说，智能体平台都很重视 Workflow 能力，可以说 Workflow 能力是智能体平台排名第二的核心能力。
国内智能体平台调研
国内的智能体平台也不少，当时调研了 Dify、Coze、BetterYeah、阿里百炼、腾讯元器、文心智能体平台等。发现智能体平台做的好的是 Dify、Coze、阿里百炼、BetterYeah。Dify、Coze、BetterYeah 相较于完整的 LLMOPS 平台功能来说，少了模型微调、模型部署部分的能力。阿里百炼是支持模型微调的，属于功能较为完备的 LLMOPS 平台。
LLMOPS 平台功能有哪些？
经过上面的智能体平台调研，我将 LLMOPS 平台的功能汇总在以下一张图中：
EasyAI 项目实现了 LLMOPS 平台的所有功能。至少目前，架构设计上已经给上述各功能留下了扩展接口。
智能体平台语言选择
在开发智能体平台时，首先需要选择一个编程语言。智能体平台属于承载了 AI 能力的应用层项目。所以，从语言选择上，可以选择适合应用层软件开发的语言，例如：Go、Python、Java。具体选择何种语言，可以根据团队的实际语言技术栈进行选择：
- Python：生态强大，但 Python 语言相较于 Go 语言，Go 语言更适合应用层项目的开发；
- Go：生态偏弱，但 Go 语言级特性，但很适合开发 LLMOPS 平台；
编程语言如何选择？我个人感觉可以根据团队技术栈来选择：
- 如果团队的主流开发语言是 Go，可以选择 Go；
- 如果团队的主流开发语言时 Python，可以选择 Python。
提示：很多时候 Java 和 Go 属于二选一的一种，单从语言层面，个人倾向于 Go。因为 Go 更加简单高效，适合应用层软件开发语言。所以，上述选择时，我只列举了 Go。
相比于生态，一个团队引入一个新的开发语言，维护成本会更高，原因如下：
- LLMOPS 平台属于一个中大型项目，需要投入很多开发人力，如果团队主流语言是 A，又要在 B 语言上投入不小的开发人力，会导致团队需要同时维护 A、B 2 门语言；
- LLMOPS 中用到的生态，主要是 SDK，这部分 SDK 在一定程度上可以起到提效作用，但其实开发成本并不高。Go 中当前也有 langchan-go、eino 这类框架可用；
就我个人而言：我会选择 Go，因为我想尽量保持团队的主流开发语言是 Go，降低整个团队的成本。
开发 LLMOPS 平台的一些核心关注点
根据我的开发经验，在开发 LLMOPS 时，一开始应该关注一些核心的技术实现：
- 生态： 需要关注相关的生态，例如 Python 的 langchain、langgraph、mcp；Go 的 langchango、eino 等。
- 方案的彻底性： 产品功能逐步迭代，但是方案要做彻底，要有前瞻性，不要仅盯着需求去做。
- 项目代码质量： 代码质量不高，后面会严重降低产品迭代速度。修复 Bug、改造已有逻辑、重构、重复件实现代码等；
- 工作流实现： 数据处理工作流、任务处理工作流、智能体工作流等
- 架构设计：
- 应用软件架构；
- Agent 应用架构。
- 扩展性： 能够灵活的扩展工作流、插件、工作流节点、LLM、知识库文档来源、数据集数据来源、数据处理算子等；
- 异步任务： LLMOPS 平台开发过程中会涉及到很多异步任务处理，所以需要设计一个通用、可扩展的异步任务处理框架；
- 资源限流： LLM 属于有限资源，Token 限制、请求量限制、超时处理等。需要有一个通用、可扩展的资源限流机制。
上述关注点，如果一开始没有考虑好，项目后期会很难快速迭代。
EasyAI 项目介绍
本小节，我来想详细介绍下「云原生 AI 实战营」知识星球的企业级 LLMOPS 平台项目的架构和实现。目前该项目作为星球的独有项目，并配套有高质量的体系课。
EasyAI 项目同时使用了命令式编程和声明式编程。其中核心功能实现均使用了声明式编程。
所以，在开发 EasyAI 项目之前，需要先学会 Kubernetes 编程。星球目前正在更新 Kuberentes 编程相关的体系课：
「Kubernetes 源码剖析与实战课」和「Kubernetes 开发实战课」。学完之后，可以无缝切入 LLMOPS 平台的开发。
如果你想学习如何开发一个功能完备的企业级 LLMOPS 平台（技术 + 具体项目实现），欢迎加入我的「云原生 AI 实战营」知识星球。
EasyAI 项目介绍
EasyAI 一句话介绍：：简化 LLM 接入，助力业务 AI 化。
EasyAI 介绍：EasyAI 是一个 LLM 连接器，旨在通过简化接入和使用过程，降低业务团队与 AI 技术之间的门槛，从而加速 AI 赋能业务的进程。
EasyAI LLMOPS 平台功能
EasyAI 包括了 LLMOPS 平台的几乎所有核心功能，具体如下：
EasyAI 后端架构
EasyAI 后端根据场景同时使用了声明式编程范式和命令式编程范式。其中，eai-gateway 采用了命令式编程。eay-apiserver + eay-controller-manager 采用了声明式编程。所有的请求，都通过 tyk-brother 企业级网关统一接入。所有的流量都会请求到 eai-gateway 组件中。eai-gateway 组件会将声明式 API 接口，原样转发给 eay-apiserver 组件。命令式 API 接口则在 eai-gateway 组件中进行处理。
组件介绍：
- 客户端：EasyAI 几乎支持所有的客户端类型。例如：
- eaictl：命令行客户端；
- SDK：支持 Go SDK；
- 前端：支持前端访问；
- API：支持 API 调用；
- tyk-brother：企业级的 API 网关，实现以下核心功能：
- 认证、鉴权；
- 认证采用基于 Dex 的 OIDC 认证；
- API 接口限流、熔断、降级；
- API 调用观测；
- 支持 HTTP、RPC 双协议；
- 支持服务注册；
- ...
- 认证、鉴权；
- eai-gateway：统一业务接入层。实现以下资源的 CURD：
- 数据的 CURD：
- 数据文件；
- 模型文件；
- 知识库文档；
- 会话；
- 智能体；
- 提示词；
- 数据的 CURD：
- eai-apiserver：声明式 API 服务器。支持各类 K8S 资源；
- eai-controller-mananger：K8S 资源的控制器。声明式方式调谐 K8S 资源状态；
- eai-nightwatch：统一、标准的异步任务执行引擎。（功能对比 K8S 的 Job、CronJob，但比 K8S 的 job controller、cronjob controller 更加轻量、易用）
- eai-ratelimit：资源限流服务，支持各类自定义资源的限流。支持插件化添加各类限流策略；
- eai-agent：智能体平台，将由 EasyAI 调试好的 Agent 发布到智能体平台，供用户使用；
- EasyML：标准的机器学习平台，支持 LLM 生产的全流程，例如：数据处理、特征提取、模型训练、模型部署、模型推理、模型观测、GPU 资源调度等；
- OneX 声明式应用基座：基于声明式编程的任务处理，例如：模型对比、效果对比等。
EasyAI 应用软件架构
EasyAI 采用 OneX 技术栈的软件架构（云原生 AI 实战营中的其他 Web 类型项目也都采用了以下 3 层简洁架构）：
整个软件架构一共分为以下三层：
- Handler 层： 负责 API 接口请求的参数解析、参数校验、业务逻辑处理分发、参数返回逻辑。在 Handler 层中，还有 Default 和 Validation 模块，分别用来给请求参数设置默认值，并校验请求参数的合法性；
- Biz 层： 包括了具体的业务逻辑实现。Biz 层根据 REST 资源类型分为不同的模块，内部可模块间交叉调用。在 Biz 层还有 Conversion 模块，用来进行结构体类型转换；
- Store 层： 数据访问层（包括访问数据库或第三方微服务），用来跟数据库/微服务交互执行数据的 CURD 操作。该层做了进一步的抽象，抽象出了通用的 Store 层，Generic Store 之上 REST 资源的数据存储操作，均可继承 Generic Store 的方法实现，而不需要自行再实现一套。
上图所示的简洁架构，还具有以下特点：
- 简洁架构提供了清晰的分层结构，各层功能明确，职责分明；
- 通过接口解耦每一层，从而实现代码的可测性、独立性和扩展性；
- 代码依赖由上向下（图中的有向箭头表示依赖规则），单向单层依赖，提供了清晰的依赖关系，使代码易于理解和维护。
EasyAI Agent 应用架构
**提示：**这里的应用架构指的是，平台中智能体应用类型的架构设计，而非软件架构设计。
LLMOPS 平台的应用架构，直接影响了平台中应用的种类、扩展难度和扩展速度。所以，在一开始，就应该设计好一个可维护、易扩展的应用架构。
EasyAI 项目采用的应用架构如下：
在 EasyAI 项目中，应用架构的基石是工作流。基于工作流组合 EasyAI 平台的各个原子能力，对上提供各种类型的智能体应用。
EasyAI 部署方式
EasyAI 支持 3 种部署方式，完全满足企业的各种部署场景：
- 裸机部署：直接将 EasyAI 部署在虚拟机/物理机上（不依赖 Kubernetes 集群）；
- 云原生部署：使用 Helm 工具一键将 EasyAI 部署在 Kubernetes 集群中（依赖 Kubernetes 集群）；
- 声明式应用基座：使用 Helm 工具，一键将 EasyAI 部署在声明式应用基座中（不依赖 Kubernetes 集群）。
EasyAI 数据设计
EasyAI 平台中集成了完整的模型训练能力。模型训练、知识库、数据处理等都需要对数据进行各类操作。在真实的企业场景中，不同业务有不同的数据来源需求，数据处理需求。所以，需要设计一个可扩展、可复用的数据模型。平台中，所有跟数据相关的功能，都使用相同的数据模型，以此降低平台的数据维护复杂度、提高数据引用的效率。
EasyAI 平台数据模型如下所示：
EasyAI Kubernetes 资源
以下是 EasyAI 项目中包含的 Kubernetes 资源比如：
- agents：智能体；
- prompts：提示词；
- applications：应用（工作流）；
- llms：大模型；
- datasets：数据集；
- datasources：数据源；
- versioneddatasets：版本化数据集；
- embedders：向量大模型；
- knowledgebases：知识库（RAG）；
- models：模型；
- vectorstores：向量数据库；
- ...
云原生开发业务会带来什么样的火花？
- 标准化： 所有的 API 接口均符合标准的 REST 规范。包括请求路径、请求方法、请求消息体、请求返回等。均跟 Kuberentes 的标准 API 完全一致。标准化可以带来很多好处，例如：
- 代码实现框架化；
- 开发方式工具化；
- 提高代码生成率；
- 功能插件化。
- 代码复用性： 只需要添加 CRD 资源即可，路由构建、数据存储、查询条件等功能，均复用 Kuberentes 的通用组件库能力；
- 扩展性： Kuberentes 能够被企业大量使用的核心原因之一是其具有非常高的扩展性。采用 K8S 开发方式，应用自带高扩展性，而且扩展非常容易。EasyAI 项目的扩展点如下：
- 模型：可通过创建不同的 LLM 资源扩展需要的模型；
- Embedding 模型：可通过创建不同的 Embedding 模型；
- 向量数据库扩展：可扩展不同的向量数据库；
- 数据源扩展：可通过创建不同的 datasource 扩展数据源。比如支持 minio、postgresql 等；
- 知识库扩展：可以自由组合以下扩展类别.
- 知识库文档来源扩展；
- 重排序策略扩展；
- 数据来源；
- 向量数据库；
- 向量模型；
- 聚合扩展：
- LLM 聚合器可以聚合不同类型的 Agent、RAG、Prompt；
- RAG 聚合器可以聚合不同的知识库、重排策略；
- 高效运维： eaictl 命令，带给你跟 Kuberentes kubectl 完全一致的运维体验。eaictl 其实就是 kubectl 命令，只不过连接的是 eai-apiserver；
- 业务愈能力： 借助于声明式编程范式，业务天然自带自愈能力。
上述这些新的功能特性给业务带来的最终价值为：
- 提高项目迭代速度：通过提高代码开发效率、降低代码维护成本来提高项目迭代速度；
- 提高项目稳定性：通过清晰的代码架构、构建方式等提高项目稳定性；
提示：声明式编程适用于一些是要维持状态的任务场景。例如：根据资源属性，计算资源状态的场景。具体例如：模型对比、模型训练。
