VTJ.PRO 在线应用开发平台的LLM模型管理与配置

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 :支持 OpenAIDeepSeekOllamaMoonshotZhipuGroqAnthropic
  • LLMPurpose :将模型分类为 Coder(针对 DSL 和代码生成优化)或 Multimodal(支持图像/视觉输入)。

实体关系图

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

模型实体空间

classDiagram class LLMModelEntity { +String name +String value +LLMProvider provider +LLMPurpose purpose +String apiKey +String baseUrl } class LLMProvider { <<enumeration>> OpenAI DeepSeek Ollama Anthropic } class LLMPurpose { <<enumeration>> Coder Multimodal } LLMModelEntity --> LLMProvider : identifies LLMModelEntity --> LLMPurpose : categorizes

LLMModelService 实现

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

缓存支持的检索

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

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

数据流:请求到模型选择

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

LLM 模型解析流程

sequenceDiagram participant AgentModule as AgentModule / AIService participant Service as LLMModelService participant Cache as CacheModule (Redis/Memory) participant DB as MySQL (LLMModelEntity) AgentModule->>Service: getCoderModels() Service->>Cache: get("LLM_MODELS_CACHE") alt Cache Hit Cache-->>Service: List<LLMModelEntity> else Cache Miss Service->>DB: find({ enabled: true }) DB-->>Service: List<LLMModelEntity> Service->>Cache: set("LLM_MODELS_CACHE", data) end Service->>Service: filter(purpose == "Coder") Service-->>AgentModule: List<CoderModels>

管理界面

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

配置界面

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

  1. 提供商设置 :定义新的 LLM 端点,包括为兼容 OpenAI 的代理设置自定义 baseUrl
  2. 凭证管理 :安全存储 apiKey 值。
  3. 用途分配 :明确将模型标记为 CoderMultimodal,以使其在特定工作台工作流中启用。
  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 中检索 apiKeybaseUrl
  3. 它使用这些参数初始化一个兼容 OpenAI 的客户端实例,以将响应流式传输回工作台。

参考资料

相关推荐
吴佳浩4 小时前
Memory Provider 实战:Hermes、Mem0、Honcho、Hindsight 为什么都这样设计?
人工智能·agent·ai编程
吴佳浩4 小时前
企业级 Agent Memory 选型指南:如何构建可扩展的 Memory Service?
人工智能·agent·ai编程
浅安的邂逅6 小时前
260918-白帽把 OpenAI 论坛“打穿“了:攻防赛漏洞、账户被 Claude 入侵、模型偷偷掩盖不当行为
人工智能·大模型·ai编程·ai模型·行业动态
mCell7 小时前
用 Knip 清理 AI Coding 留下的冗余代码
前端·ai编程·前端工程化
slacker-kian7 小时前
本地大模型 + 自建 MCP Server + SAP OData:让 LLM 代理 SAP 业务操作
大模型·llm·sap·agent·mcp·odata
坐吃山猪10 小时前
Harness Engineering知识总结
llm·agent·harness
杨杨杨大侠10 小时前
RAG 到底是怎么工作的?从用户提问到模型回答的完整链路
spring·openai·ai编程
wangruofeng11 小时前
把AI判断做成「智能if语句」!Jev实测:一次调用3个判断,置信度直接路由
aigc·agent·ai编程
全栈技术负责人11 小时前
让 Agent 动手前先“听懂人话”:意图识别插件的设计与实践
ai·ai编程