随着大模型能力快速发展，AI 正在从“实验性工具”逐渐变成真正的工程基础设施。
开发者不再只是用 AI 写几行代码、做几次对话，而是开始尝试：
- 构建 AI 自动化系统
- 设计编程智能体
- 搭建企业内部 AI 中台
- 让多模型协同完成复杂任务
然而在工程实践中，一个问题越来越明显：
AI 能力在不断增强，但 AI 系统却越来越难以构建和维护。
常见挑战包括：
- 本地模型管理分散
- 推理接口缺乏统一抽象
- Agent 行为难以复用
- Workflow 缺乏稳定运行时
- 多模型协作复杂
- 系统缺乏可观测性
换句话说：
我们拥有很多 AI 工具，却缺少一套真正的平台。
OpenVitamin(github.com/fengzhizi71…) 的设计目标，正是解决这一问题：
⭐ 构建一套 本地 AI Runtime + Control Plane，让 AI 能力可以像传统系统能力一样被工程化组织。
本文将系统介绍 OpenVitamin 的整体架构与核心设计思想。
一、从 AI 工具链到 AI 平台
在传统开发中，系统通常具有清晰的分层结构：
- 接入层（UI / API）
- 控制层（编排 / 调度 / 状态管理）
- 执行层（Runtime）
- 基础设施层（存储 / 配置 / 可观测）
而在当前 AI 工具生态中，这些能力往往被拆散在不同项目中：
- 模型加载在某个工具里
- Agent 执行在另一个框架里
- Workflow 在脚本系统里
- 推理接口风格各异
这种“工具拼装式开发”在实验阶段可以接受，但在工程阶段会导致：
- 系统复杂度迅速上升
- 行为不可预测
- 可维护性下降
- 团队协作困难
OpenVitamin 的核心思路是：
将这些能力重新组织为一个平台运行时。
二、OpenVitamin 平台整体架构
下面是 OpenVitamin 的整体架构分层与核心模块关系：
从整体上看，OpenVitamin 可以划分为五个核心部分：
- Access Layer：用户与外部系统进入平台的入口
- Control Plane：任务编排与 AI 能力调度中心
- Execution Kernel：统一 AI Runtime 执行层
- Runtime Providers：具体推理后端生态
- Infrastructure：贯穿全局的基础设施能力
三、Access Layer：AI 能力的统一入口
OpenVitamin 提供多种访问方式：
- Chat UI
- Agent 配置界面
- Workflow 可视化编排界面
- OpenAI-compatible API
- 外部系统调用（如 OpenClaw）
这些入口的意义不仅是交互，更是：
⭐ AI 系统的控制面（Control Surface）。
开发者可以在这里：
- 调试 Agent 决策路径
- 构建自动化流程
- 管理模型配置
- 观察执行状态
四、Control Plane：平台的大脑
在 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 将不同 AI 能力统一抽象：
- LLM Runtime
- VLM Runtime
- Embedding Runtime
- Tool Runtime
Control Plane 不需要了解模型细节，只需要调用 Runtime。
这类似：
- 数据库执行引擎
- 操作系统进程调度层
六、Runtime Providers：可扩展推理生态
平台支持多种推理后端：
- llama.cpp
- Ollama
- LM Studio
- ONNX Runtime
- OpenAI-compatible 服务
因此 OpenVitamin 可以：
- 完全本地运行
- 局域网推理
- 云本地混合
以及作为：
- OpenClaw 推理后端
- 企业 AI 平台基础组件
下图是Execution Kernel <-> Runtime Providers 运行时映射关系图
七、横向基础设施能力
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 执行模型
