LLM 模型管理与配置

本节详细介绍了 VTJ.PRO 平台中大型语言模型（LLM）的基础设施和管理逻辑。系统支持多个提供商、专门的模型用途（如代码生成或多模态视觉），并包含一个缓存层以优化 AI 代理工作流的性能。

数据模型与实体

平台使用结构化的实体模型来定义 LLM 的能力和连接参数。

LLMModelEntity

LLMModelEntity 表示由外部服务提供的特定模型实例（例如 GPT-4、Claude-3）。它包含 API 端点、认证密钥和模型特定参数的配置。

关键字段包括：

• name：模型的显示名称。
• value：API 调用中使用的技术标识符（例如 gpt-4-turbo）。
• provider：服务提供商（由 LLMProvider 枚举定义）。
• purpose：主要使用场景（由 LLMPurpose 枚举定义）。
• apiKey：提供商的凭证。
• baseUrl：API 端点（用于代理服务或本地部署）。

枚举：Provider 与 Purpose

系统对模型进行分类，以确保为特定任务使用正确的工具：

• LLMProvider：支持 OpenAI、DeepSeek、Ollama、Moonshot、Zhipu、Groq 和 Anthropic。
• LLMPurpose：将模型分类为 Coder（针对 DSL 和代码生成优化）或 Multimodal（支持图像/视觉输入）。

实体关系图

下图说明了 LLMModelEntity 在后端服务层中如何与其操作枚举相关联。

模型实体空间

LLMModelService 实现

LLMModelService 是检索和管理模型的主要接口。它扩展了 BaseCrudService 以提供标准的 CRUD 操作，同时实现了模型选择和缓存的专用逻辑。

缓存支持的检索

为了在频繁的 AI 代理请求期间最小化数据库开销，该服务对模型列表使用了缓存机制。

• getModels()：检索所有启用的模型，优先使用缓存结果（如果可用）。
• getCoderModels()：过滤模型列表，仅返回标记为 LLMPurpose.Coder 的模型。这些模型通常由 @vtj/coder 引擎用于生成 Vue 组件和 DSL。
• getMultiModel()：返回标记为 LLMPurpose.Multimodal 的第一个可用模型，用于图像转代码或基于视觉的分析。

数据流：请求到模型选择

此图显示了针对特定模型（如 Coder 模型）的请求如何从服务层通过缓存流向数据库。

LLM 模型解析流程

管理界面

平台提供了一个专用的管理界面，用于管理 LLM 配置，位于 llms.vue 视图中。

配置界面

管理员可以执行以下操作：

1. 提供商设置：定义新的 LLM 端点，包括为兼容 OpenAI 的代理设置自定义 baseUrl。
2. 凭证管理：安全存储 apiKey 值。
3. 用途分配：明确将模型标记为 Coder 或 Multimodal，以使其在特定工作台工作流中启用。
4. 状态切换：启用或禁用模型，无需删除其配置。

前端集成

管理界面通过 LlmController 与后端交互，该控制器公开了由 LLMModelService 管理的 CRUD 端点。

组件	文件路径	角色
视图	frontend/src/views/admin/llms.vue	模型 CRUD 操作的管理界面
控制器	backend/src/business/llm/llm.controller.ts	LLM 管理的 REST API 端点
服务	backend/src/business/llm/llm.service.ts	业务逻辑和缓存管理

与 AI 代理工作流的集成

在此模块中配置的模型由 AIService 使用。当 AI 代理需要执行任务时：

1. 它根据任务类型（例如聊天 vs. 代码生成）向 LLMModelService 查询合适的模型。
2. 它从 LLMModelEntity 中检索 apiKey 和 baseUrl。
3. 它使用这些参数初始化一个兼容 OpenAI 的客户端实例，以将响应流式传输回工作台。

参考资料

• 官网文档：https://vtj.pro/
• 在线平台：https://app.vtj.pro/
• 开源仓库：https://gitee.com/newgateway/vtj