OpenVitamin 架构设计 | 本地LLM智能体平台是如何构建的

随着大模型能力快速发展，AI 正在从“实验性工具”逐渐变成真正的工程基础设施。

开发者不再只是用 AI 写几行代码、做几次对话，而是开始尝试：

• 构建 AI 自动化系统
• 设计编程智能体
• 搭建企业内部 AI 中台
• 让多模型协同完成复杂任务

然而在工程实践中，一个问题越来越明显：

AI 能力在不断增强，但 AI 系统却越来越难以构建和维护。

常见挑战包括：

• 本地模型管理分散
• 推理接口缺乏统一抽象
• Agent 行为难以复用
• Workflow 缺乏稳定运行时
• 多模型协作复杂
• 系统缺乏可观测性

换句话说：

我们拥有很多 AI 工具，却缺少一套真正的平台。

OpenVitamin(https://github.com/fengzhizi715/OpenVitamin) 的设计目标，正是解决这一问题：

⭐ 构建一套 本地 AI Runtime + Control Plane，让 AI 能力可以像传统系统能力一样被工程化组织。

本文将系统介绍 OpenVitamin 的整体架构与核心设计思想。

一、从 AI 工具链到 AI 平台

在传统开发中，系统通常具有清晰的分层结构：

• 接入层（UI / API）
• 控制层（编排 / 调度 / 状态管理）
• 执行层（Runtime）
• 基础设施层（存储 / 配置 / 可观测）

而在当前 AI 工具生态中，这些能力往往被拆散在不同项目中：

• 模型加载在某个工具里
• Agent 执行在另一个框架里
• Workflow 在脚本系统里
• 推理接口风格各异

这种“工具拼装式开发”在实验阶段可以接受，但在工程阶段会导致：

• 系统复杂度迅速上升
• 行为不可预测
• 可维护性下降
• 团队协作困难

OpenVitamin 的核心思路是：

将这些能力重新组织为一个平台运行时。

二、OpenVitamin 平台整体架构

下面是 OpenVitamin 的整体架构分层与核心模块关系：

主图.jpg

主图.jpg

从整体上看，OpenVitamin 可以划分为五个核心部分：

1. Access Layer：用户与外部系统进入平台的入口
2. Control Plane：任务编排与 AI 能力调度中心
3. Execution Kernel：统一 AI Runtime 执行层
4. Runtime Providers：具体推理后端生态
5. Infrastructure：贯穿全局的基础设施能力

三、Access Layer：AI 能力的统一入口

access-layer.jpg

access-layer.jpg

OpenVitamin 提供多种访问方式：

• Chat UI
• Agent 配置界面
• Workflow 可视化编排界面
• OpenAI-compatible API
• 外部系统调用（如 OpenClaw）

这些入口的意义不仅是交互，更是：

⭐ AI 系统的控制面（Control Surface）。

开发者可以在这里：

• 调试 Agent 决策路径
• 构建自动化流程
• 管理模型配置
• 观察执行状态

四、Control Plane：平台的大脑

Control_Plane.jpg

Control_Plane.jpg

在 OpenVitamin 的整体架构中，Control Plane 是最核心的一层。

如果说：

• Access Layer 是入口
• Execution Layer 是执行引擎
• Providers 是算力来源

那么：

⭐ Control Plane 就是整个平台的“大脑”。

它决定：

• 什么任务被执行
• 由谁执行
• 使用哪个模型
• 是否并发执行
• 是否重试
• 是否被限流
• 如何记录执行状态

换句话说：

Control Plane 负责将“AI 能力”转化为“可调度的系统行为”。

4.1 从“调用模型”到“调度任务”

很多 AI 系统在设计之初，都是以“调用模型”为中心。

例如：

• 用户输入 → 直接请求 LLM
• Agent 推理 → 直接调用 Tool
• Workflow 节点 → 直接执行脚本

这种模式在 Demo 阶段非常高效，但在工程系统中会带来明显问题：

• 行为路径难以追踪
• 并发与资源控制困难
• 多模型协作缺乏统一策略
• 任务失败缺乏恢复机制
• 系统无法形成稳定运行时

OpenVitamin 的设计选择是：

将所有 AI 行为抽象为“任务”，并交由 Control Plane 统一调度。

这使 AI 系统开始具备类似操作系统的调度能力。

4.2 Agent Runtime：可工程化的智能体执行单元

在 Control Plane 中，Agent Runtime 是最重要的执行入口之一。

OpenVitamin 将 Agent 定义为一种：

⭐ 可调度、可治理、可观测的执行单元。

Agent Runtime 的职责包括：

• 执行 Plan / Step
• 调用 Skill 与 Tool
• 管理上下文状态
• 与 Knowledge Service 交互
• 将推理请求交给 Inference Gateway

与传统 Prompt Agent 不同，这里的 Agent：

• 不再是一次性对话逻辑
• 而是可以被 Workflow 调用
• 可以被限流与排队
• 可以被追踪执行路径

这使 Agent 从“能力模板”，升级为“系统组件”。

4.3 Workflow Control Plane：AI 自动化流程调度中心

Workflow Control Plane 负责管理 DAG 式任务流程。

它不仅仅是流程定义器，更是：

⭐ AI 自动化系统的运行时调度中心。

Workflow Engine 需要处理的问题包括：

• 节点依赖关系解析
• 并行执行控制
• 条件分支决策
• Retry 与 Timeout 策略
• 上下文在节点之间传播

更重要的是：

Workflow 不直接调用 Runtime，而是：

通过 Agent Runtime 与 Scheduler 协同完成任务执行。

这种设计使 Workflow 可以：

• 动态选择执行路径
• 调用不同 Agent
• 协调多模型协作

从而形成真正的 AI 自动化系统。

4.4 Knowledge / RAG Service：认知能力支撑层

在复杂 AI 应用中，模型推理往往需要依赖知识检索。

OpenVitamin 将 Knowledge / RAG Service 作为 Control Plane 的核心组成部分，而不是附属插件。

它负责：

• 文档解析与向量化
• 向量检索与上下文构建
• 与 Embedding Runtime 协同
• 管理知识库状态

Agent Runtime 与 Workflow Engine 都可以调用 Knowledge Service，以增强模型推理能力。

这使平台具备：

⭐ 将“知识能力”作为基础设施统一调度的能力。

4.5 Model Registry：多模型协作的决策基础

Model Registry 提供：

• 模型自动发现
• 能力标签管理
• 推理参数配置
• 模型元数据管理

但它的真正价值在于：

为 Scheduler / Router 提供决策依据。

在多模型环境中，任务可以：

• 根据任务类型选择模型
• 根据资源状态切换模型
• 根据策略进行 fallback

这使平台能够从“固定模型调用”，升级为“动态模型路由”。

4.6 Skill / Tool Registry：能力治理与扩展机制

OpenVitamin 将 Tool 与 Skill 抽象为平台能力单元。

Skill Registry 负责：

• 能力注册与发现
• 权限控制
• 生命周期管理
• 插件化扩展

Agent Runtime 并不是直接调用工具，而是：

通过 Registry 查找能力，再由 Execution Layer 执行。

这种设计可以：

• 防止能力耦合
• 支持插件市场
• 支持多租户治理
• 支持审计与权限策略

4.7 Execution Governance：任务治理与资源控制

在平台级系统中，资源控制是不可或缺的能力。

OpenVitamin 在 Control Plane 中引入：

⭐ Execution Governance 模块。

它负责：

• 请求排队
• 并发控制
• Quota 管理
• 任务优先级
• 执行策略

这使 AI 平台具备：

• 高负载稳定性
• 多用户场景支持
• 长流程任务治理

也是未来企业化部署的重要基础。

4.8 Control Plane 的本质

从整体上看，Control Plane 的本质并不是：

• 调用模型
• 或执行 Prompt

而是：

⭐ 将 AI 能力组织为“可调度的系统行为”。

它让：

• Agent 成为执行单元
• Workflow 成为调度逻辑
• Runtime 成为执行引擎
• Provider 成为算力来源

这正是 OpenVitamin 从工具平台走向系统平台的关键一步。

五、Execution Kernel：统一 AI Runtime

execution_kernel.jpg

execution_kernel.jpg

Execution Kernel 将不同 AI 能力统一抽象：

• LLM Runtime
• VLM Runtime
• Embedding Runtime
• Tool Runtime

Control Plane 不需要了解模型细节，只需要调用 Runtime。

这类似：

• 数据库执行引擎
• 操作系统进程调度层

六、Runtime Providers：可扩展推理生态

runtime_providers.jpg

runtime_providers.jpg

平台支持多种推理后端：

• llama.cpp
• Ollama
• LM Studio
• ONNX Runtime
• OpenAI-compatible 服务

因此 OpenVitamin 可以：

• 完全本地运行
• 局域网推理
• 云本地混合

以及作为：

• OpenClaw 推理后端
• 企业 AI 平台基础组件

下图是Execution Kernel <-> Runtime Providers 运行时映射关系图

运行时映射关系图.jpg

运行时映射关系图.jpg

七、横向基础设施能力

Infrastructure.jpg

Infrastructure.jpg

OpenVitamin 将以下能力设计为“全局能力”：

• Config / Settings
• Execution Trace
• ORM/ State Storage
• VectorSearchProvider
• Plugin System

这使平台具备：

• 可观测性
• 可扩展性
• 可维护性

八、未来架构演进方向

未来 OpenVitamin 将继续演进：

• Execution Virtualization Layer
• Event-driven Orchestration
• 分布式推理调度
• 更强 Workflow Runtime
• 更智能模型路由

九、总结

OpenVitamin 并不是一个模型 UI，也不是一个 Agent Demo。

它尝试解决的是：

如何将 AI 能力构建为长期可维护的工程系统。

随着 AI 应用复杂度提升，Runtime 与 Control Plane 的价值将越来越明显。

在后续文章中，我们将继续深入：

• 多模型推理接口设计
• Agent Runtime 内部机制
• Workflow 执行模型

项目地址：https://github.com/fengzhizi715/OpenVitamin