OoderAI V3.5.0 技术白皮书——NLP 驱动的 AI 原生开发平台
文档性质：技术架构蓝图与设计理念目标版本：v3.5.0（预计 2026 年第三季度发布）当前基线：v3.0.3-jdk11更新日期：2026 年 5 月 25 日
📋 关于本文档
本文档描述 Ooder v3.5.0 的技术架构规划与设计理念。文中部分功能已在当前版本实现，部分功能正在开发或规划中。我们希望通过公开技术设计思路，与社区共同探讨 AI 原生开发的最佳实践。
- ✅已实现：协议层、SDK 层、Skills 架构基础、NLP 编排器
- 🔄开发中：NLP Harness Pipeline、四分离模型完整实现
- 📋规划中：AI Studio 完整工程化体系
1. 产品定位：NLP FIRST 设计理念
1.1 核心定位
Ooder 是一款以 NLP 为核心驱动力的 AI 原生开发平台。我们的设计理念是：自然语言即代码，意图即实现。
NLP FIRST 设计理念
用户输入 (自然语言) → 意图识别 → 实体提取 → 组件选择 → 代码生成 → 验证反馈
这一理念的核心是：让自然语言成为软件开发的第一公民。用户通过自然语言描述需求，Ooder 自动完成从意图理解到代码生成的全过程。
1.2 NLP FIRST vs 传统开发模式
| 维度 | 传统开发 | 低代码平台 | Ooder NLP FIRST |
|---|---|---|---|
| 需求输入 | 需求文档 → 人工分析 | 可视化拖拽 | 自然语言描述 |
| 意图理解 | 人工解读 | 无 | NLP 意图识别 |
| 代码生成 | 手动编码 | 模板生成 | 注解驱动 + AI 增强 |
| 验证机制 | 人工测试 | 静态检查 | 置信度量化 + 渐进披露 |
| 反馈循环 | 需求变更 → 重写 | 配置修改 | 澄清请求 → 自动调整 |
1.3 目标用户与价值主张
| 用户群体 | 核心痛点 | Ooder 解决方案 | 当前成熟度 |
|---|---|---|---|
| 产品经理 | 需求与实现存在鸿沟 | NLP 驱动，意图即实现 | 🔄 开发中 |
| IT 人员 | 低代码平台灵活性不足 | 注解驱动，代码级控制 | ✅ 已实现 |
| 编程爱好者 | 学习曲线陡峭 | 自然语言交互，降低门槛 | ✅ 已实现 |
| 企业架构师 | 技术选型风险高 | SPI 架构，渐进式集成 | ✅ 已实现 |
2. 技术架构全景
2.1 五层架构体系
Ooder 采用从底层协议到上层应用的五层架构设计，每一层都以 NLP 驱动为核心：
图 1：Ooder 五层技术架构 - NLP 驱动的 AI 原生平台
架构特点
1. NLP 贯穿全栈
从用户输入到代码生成，NLP 是核心驱动力
2. 协议驱动
底层协议定义了 Agent 互联、路由发现、工具调用、UI 交互的标准
3. SDK 封装
协议的具体实现被封装在 SDK 层，对上层透明
4. 技能组装
基于 SDK 层构建标准化技能模块，支持声明式编排
5. 可视化工作台
AI Studio 作为统一入口，提供 NLP 交互界面
2.2 模块版本矩阵
| 模块 | 当前版本 | 说明 | 仓库路径 |
|---|---|---|---|
| ooder-pro | 3.0.3-jdk11 | RAD Studio 主程序 | ooder-pro/pom.xml |
| agent-sdk | 3.0.2 | Agent SDK 核心 | agent-sdk/agent-sdk-core/pom.xml |
| scene-engine | 3.0.2 | 场景引擎 | scene-engine/pom.xml |
| llm-sdk | 1.0.j11 | LLM 集成 SDK | ooder-common/llm-sdk/pom.xml |
| skills-framework | 1.0.j11 | 技能框架 | ooder-common/skills-framework/pom.xml |
| ooder-annotation | 1.0.j11 | 注解模块 | ooder-common/ooder-annotation/pom.xml |
3. NLP 驱动的核心流程
3.1 从自然语言到代码的完整流程
Ooder 的 NLP 驱动流程包含 7 个核心步骤：
图 2：NLP 驱动示例 - 从自然语言到代码的完整流程
流程详解
| 步骤 | 处理器 | 输入 | 输出 |
|---|---|---|---|
| Step 1 | NlpIntentRecognizer | 自然语言文本 | intent, confidence |
| Step 2 | ClsEntityExtractor | intent + entities | moduleName, fields, operations |
| Step 3 | TemplateSelector | componentType | 模板配置 |
| Step 4 | ClsFourSeparationExtractor | .cls JSON | Properties, Styles, Events, Behaviors |
| Step 5 | .cls JSON Generator | 四分离数据 | JSON 配置文件 |
| Step 6 | NlpHarnessPipeline | JSON + 验证规则 | confidence, disclosureLevel |
| Step 7 | D2CGenerator | JSON + 模板 | Java 代码 + 注解 |
3.2 NLP 驱动示例
用户输入
"创建一个用户管理页面，包含用户列表、搜索、新增、编辑、删除功能，字段包括ID、姓名、邮箱、状态"
Step 1: 意图识别
IntentRecognitionResult result = intentRecognizer.recognize(query);
// intent = CREATE_PAGE
// confidence = 0.92
Step 2: 实体提取
ClsEntityResult entityResult = extractor.extract(clsJson);
// moduleName = UserManager
// fields = [id, name, email, status]
// operations = [SEARCH, SAVE, DELETE, ADD, EDIT]
Step 7: 代码生成
@TreeGridViewAnnotation(
dataUrl = "/api/users",
saveUrl = "/api/users/save",
searchUrl = "/api/users/search",
delPath = "/api/users/delete",
columns = {
@Column(field = "id", caption = "ID"),
@Column(field = "name", caption = "姓名"),
@Column(field = "email", caption = "邮箱"),
@Column(field = "status", caption = "状态")
}
)
public class UserManagerView {
// 自动生成的数据绑定和事件处理
}
4. NLP Module Orchestrator
4.1 5 步编排流程
NlpModuleOrchestrator 是 NLP 驱动的核心编排器，负责将自然语言转换为结构化的 UI 组件：
图 3：NLP Module Orchestrator - 5 步编排流程
4.2 核心代码结构
@Service
public class NlpModuleOrchestrator {
private final NlpIntentRecognizer intentRecognizer;
private final NlpComponentBuilderFactory componentFactory;
private final TemplateSelector templateSelector;
public NlpBuildContext process(String query) {
NlpBuildContext context = new NlpBuildContext(query);
context = step1_IntentRecognition(context); // 意图识别
if (context.hasErrors()) return context;
context = step2_ModulePartition(context); // 模块划分
if (context.hasErrors()) return context;
context = step3_ComponentSelection(context); // 组件选择
if (context.hasErrors()) return context;
context = step4_BuildComponent(context); // 构建组件
if (context.hasErrors()) return context;
context = step5_GenerateOutput(context); // 生成输出
return context;
}
}
4.3 错误处理机制
每个 Step 都有 context.hasErrors() 检查，失败时立即返回错误信息，支持多阶段回滚。
5. NLP Harness Pipeline
5.1 6 阶段管道设计
NlpHarnessPipeline 实现了从自然语言输入到构建执行的完整流程，体现了 Ooder 与传统测试框架的核心差异：
图 4：NLP Harness Pipeline - 6 阶段管道设计
5.2 核心特性：解决"哑巴管道"问题
传统测试框架是"哑巴管道"：输入 → 处理 → 输出，中间过程不可见。Ooder 的 Harness Engineer 让每个处理节点都"会说话"：
public class HarnessResult<T> {
private final T data; // 实际数据
private final double confidence; // 置信度 0.0-1.0
private final String source; // 来源：SKILL / LLM / RULE / HYBRID / FALLBACK
private final List<String> harnessLog; // 驾驭日志
private final boolean requiresReview; // 是否需要人工复核
private final List<String> suggestions; // 改进建议
}
5.3 置信度级别
| 级别 | 置信度范围 | 含义 | 处理方式 |
|---|---|---|---|
| RELIABLE | ≥ 0.85 | 可靠 | 直接进入下一阶段 |
| CLARIFICATION | 0.60 - 0.85 | 需澄清 | 发起澄清请求 |
| SKELETON | < 0.60 | 骨架 | 降级处理，生成基础结构 |
5.4 与传统 SDD 的差异
| 维度 | 传统 SDD 测试 | Ooder Harness Engineer |
|---|---|---|
| 驱动方式 | 静态测试脚本 | NLP 驱动的动态测试 |
| 结果判断 | 二元：通过/失败 | 置信度量化评估 |
| 披露方式 | 全量或无 | 渐进式披露：骨架→完整 |
| 错误处理 | 失败即停止 | 自动澄清请求 + 自适应回退 |
| 测试生成 | 人工编写 | AI 生成测试场景 |
| 维护成本 | 高 | 自适应调整，低维护 |
6. 六维数据空间
6.1 数据流转全景
Ooder 定义了六维数据空间，描述 NLP 驱动下的数据流转：
图 5：六维数据空间 - NLP 驱动的数据流转
6.2 各层详解
| 维度 | 名称 | 说明 | 核心类 |
|---|---|---|---|
| D1 | 注解层 | 声明式 UI 定义 | @FormViewAnnotation, @TreeGridViewAnnotation |
| D2 | Meta 层 | 结构化元数据 | CustomViewMeta, CustomFormViewMeta |
| D3 | Properties 层 | 四分离模型 | Properties, Styles, Events, Behaviors |
| D4 | .cls JSON 层 | 设计时态产物 | 设计器保存格式 |
| D5 | llmMeta 层 | LLM 可处理格式 | D2CProject.llmMeta |
| D6 | JavaGen 层 | 代码生成 | D2CGenerator, GenAnnotationRestoreJava |
6.3 ClsEntityExtractor 核心映射
public class ClsEntityExtractor {
// 组件类型映射
private static final Map<String, String> KEY_TO_FIELD_TYPE = new HashMap<>();
static {
KEY_TO_FIELD_TYPE.put("ood.UI.Input", "INPUT");
KEY_TO_FIELD_TYPE.put("ood.UI.ComboInput", "COMBOINPUT");
KEY_TO_FIELD_TYPE.put("ood.UI.DatePicker", "DATEPICKER");
// ... 30+ 组件映射
}
// API 别名映射
private static final Map<String, String> ALIAS_TO_URL_KEY = new HashMap<>();
static {
ALIAS_TO_URL_KEY.put("SAVE", "saveUrl");
ALIAS_TO_URL_KEY.put("SEARCH", "searchUrl");
ALIAS_TO_URL_KEY.put("DELETE", "delPath");
// ... 15+ API 映射
}
// 导航组件映射
private static final Map<String, String> NAV_COMPONENT_KEY_MAP = new HashMap<>();
static {
NAV_COMPONENT_KEY_MAP.put("NAVTREECONFIG", "ood.UI.TreeView");
NAV_COMPONENT_KEY_MAP.put("NAVTABSCONFIG", "ood.UI.Tabs");
// ... 10+ 导航组件映射
}
}
7. 协议层：Agent 互联标准化
7.1 四层协议栈
图 6：Ooder 四层协议栈架构
7.2 A2A 协议：Agent 互联的基石
SkillCard 示例
{
"skillId": "skill-daily-report-001",
"name": "日报生成",
"description": "根据用户输入生成工作日报",
"form": "CHAT",
"sceneType": "DAILY_REPORT",
"purposes": ["效率提升", "文档生成"],
"skillCategory": "SCENE"
}
7.3 REACH 协议：动态路由与发现
| 能力 | 说明 | 实现方式 |
|---|---|---|
| Agent 注册 | Agent 启动时自动注册到网络 | UDP 广播 + mDNS + 注册中心 |
| 服务发现 | 发现网络中可用的 Agent 和技能 | 主动查询 + 订阅通知 |
| 负载均衡 | 在多个 Agent 实例间分配请求 | Random / Weighted / RoundRobin |
| 故障转移 | Agent 故障时自动切换到备用实例 | 健康检查 + 自动摘除 |
8. SDK 层：agent-sdk 与 scene-engine
8.1 agent-sdk 架构
agent-sdk 3.0.2 架构 │ ├──agent-sdk-core│ ├──WorkerAgent// 工作节点：执行具体任务│ ├──SceneAgent// 场景节点：管理场景上下文│ ├──EndAgent// 终端节点：用户交互入口│ ├──RouteAgent// 路由节点：请求分发│ └──McpAgent// MCP 协议节点：工具调用│ ├──llm-sdk│ ├──StructuredOutputApi// 结构化输出│ ├──ToolCallingApi// 工具调用│ └──TokenQuotaService// Token 配额管理│ └──skills-framework├──SkillRegistry// 技能注册表├──SkillInstaller// 技能安装器└──SkillDiscoverer // 技能发现器
8.2 scene-engine：SPI 驱动的弹性部署
| 驱动类型 | 存储 | LLM | 向量库 | 包大小 | 适用场景 |
|---|---|---|---|---|---|
| Tiny | 文件 | Ollama | 内存 | < 5 MB | 开发测试、边缘设备 |
| Small | JDBC | 远程 API | Milvus Lite | 15-25 MB | 小型部署、POC |
| Enterprise | 分布式 | 多模型路由 | 分布式向量库 | 50-150 MB | 企业生产 |
9. Skills 架构层
9.1 七层技能设计
| 层级 | 名称 | 职责 | 示例 |
|---|---|---|---|
| Layer 1 | SPI 基础层 | 统一接口定义 | StorageProvider, LlmProvider |
| Layer 2 | 驱动层 | 外部系统集成 | DeepSeekDriver, DingTalkDriver |
| Layer 3 | 系统层 | 核心系统服务 | AuthService, ConfigService |
| Layer 4 | 能力层 | 可复用基础能力 | TextGeneration, ImageAnalysis |
| Layer 5 | 场景层 | 业务场景封装 | DailyReport, MeetingScheduler |
| Layer 6 | 业务层 | 业务逻辑处理 | OrderProcess, CustomerService |
| Layer 7 | 工具层 | 辅助工具 | Logger, Metrics |
10. ooderUI 全栈方案
10.1 四分离模型
四分离模型将组件数据解耦为四个正交维度：
| 维度 | 说明 | 典型属性 | 解耦收益 |
|---|---|---|---|
| Properties | 业务属性 | dataUrl, saveUrl, searchUrl | 数据驱动，切换后端只需改 URL |
| Styles (CS) | 样式配置 | CSS 类、主题变量 | 主题系统、设计系统无缝切换 |
| Events | 事件绑定 | onClick, onChange | 交互逻辑模块化 |
| Behaviors | 行为逻辑 | APICaller, Action 链 | 复杂交互可配置化 |
10.2 .cls JSON 示例
{
"components": {
"user-grid": {
"key": "ood.UI.TreeGrid",
"properties": {
"dataUrl": "/api/users",
"columns": [
{ "field": "id", "caption": "ID" },
{ "field": "name", "caption": "姓名" },
{ "field": "email", "caption": "邮箱" }
]
},
"styles": {
"cssClass": "user-grid-theme",
"striped": true
},
"events": {
"onRowClick": "handleRowClick",
"onRowDoubleClick": "handleEdit"
},
"behaviors": {
"apiCallers": [
{ "alias": "SEARCH", "url": "/api/users/search" },
{ "alias": "SAVE", "url": "/api/users/save" },
{ "alias": "DELETE", "url": "/api/users/delete" }
]
}
}
}
}
11. 企业级特性：与传统方案的差异
11.1 特性对比
图 7：企业级特性对比 - Ooder vs 传统方案
11.2 Ooder 企业级特性总结
- NLP FIRST: 自然语言驱动，从意图到代码的完整编排
- 置信度量化: RELIABLE(≥0.85) / CLARIFICATION(0.60-0.85) / SKELETON(<0.60)
- 渐进式披露: 骨架 → 轮廓 → 完整，自适应回退机制
- 协议层标准化: A2A/REACH/MCP/A2UI 四层协议
- SPI 弹性部署: Tiny/Small/Enterprise 三档弹性
- 注解驱动代码生成: 编译时检查，类型安全
- 双向同步: 设计器 ↔ 代码 完整同步
12. 设计权衡与技术选型
12.1 SPI 架构 vs 单体集成
| 维度 | SPI 架构 | 单体集成 |
|---|---|---|
| 部署灵活性 | ✅ Tiny/Small/Enterprise 三档 | ❌ 全量部署 |
| 初期配置 | ⚠️ 需要理解 SPI 概念 | ✅ 开箱即用 |
| 扩展性 | ✅ 自定义实现替换 | ❌ 修改源码 |
| 维护成本 | ⚠️ 多模块协调 | ✅ 单一代码库 |
应对策略：提供 Spring Boot Starter 自动配置，降低 SPI 使用门槛。
12.2 注解驱动 vs 纯 JSON 配置
| 维度 | 注解驱动 | 纯 JSON 配置 |
|---|---|---|
| 类型安全 | ✅ 编译时检查 | ❌ 运行时错误 |
| IDE 支持 | ✅ 完整提示 | ⚠️ 需要额外插件 |
| 灵活性 | ⚠️ 需要重新编译 | ✅ 热更新 |
| 启动时间 | ⚠️ 注解解析开销 | ✅ 直接加载 |
| 适用场景 | 企业级应用 | 快速原型 |
我们的选择：注解驱动为主，JSON 配置为辅。对于企业级应用，类型安全和 IDE 支持的重要性高于热更新能力。
12.3 P2P 发现 vs 注册中心
| 场景 | P2P 发现 | 注册中心 |
|---|---|---|
| 边缘计算 | ✅ 无需中心节点 | ❌ 依赖网络 |
| 开发测试 | ✅ 零配置 | ⚠️ 需要搭建 |
| 生产环境 | ⚠️ 管理困难 | ✅ 统一管理 |
13. 版本演进与路线图
13.1 版本历史
| 版本 | 发布日期 | 核心变更 |
|---|---|---|
| 2.3.1 | 2026-03-08/14 | Spring Boot Starter 支持，JDK 21 升级 |
| 3.0.0 | 2026-03-25 | SPI 驱动架构，Tiny/Small/Enterprise 三档部署 |
| 3.0.1 | 2026-04-01 | GitRepositoryDiscovererAdapter 完成，缓存机制 |
| 3.0.2 | 2026-04-05/08 | SkillCard 合并重构，版本统一 |
| 3.5.0 | 2026 Q4 (规划) | NLP FIRST 架构，Harness Engineer，全栈方案 |
13.2 v3.5.0 规划
| 升级领域 | 具体内容 | 当前状态 |
|---|---|---|
| 架构模式 | NLP FIRST 设计模式 | 🔄 开发中 |
| NLP 编排 | NlpModuleOrchestrator 5 步编排 | ✅ 已实现 |
| Harness | NlpHarnessPipeline 6 阶段管道 | 🔄 开发中 |
| 全栈方案 | ooderUI + ooder Annotation 贯穿工作台 | 🔄 开发中 |
| 逆向还原 | DataMeta 完整覆盖，100% 逆向对齐 | ✅ 已实现 |
13.3 产品愿景
Ooder 的终极愿景是"让每个企业都成为平台定义者"
- 定义自己的技术标准：基于业务特点制定专属的技术规范
- 构建自己的能力生态：通过 P2P 网络连接内外部能力
- 输出自己的行业方案：将最佳实践转化为可复用的解决方案
附录
A. 代码仓库结构
├──agent-sdk# Agent SDK 模块│
├──agent-sdk-core# 核心实现│
└──CHANGELOG.md# 版本记录
├──scene-engine# 场景引擎模块│
└──docs# 文档
├──ooder-pro# RAD Studio 主程序│
├──harness# 测试构建脚本│
└──doc# 注解文档
├──ooder-common# 公共模块│
├──ooder-annotation# 注解定义│
├──llm-sdk# LLM SDK│
└──skills-framework# 技能框架
└──ouc# Ooder UI Components
└──ouc-core\ # UI 组件核心
B. 相关资源
- 官方网站: ooder.net
- GitHub 仓库: github.com/oodercn
- 文档中心: docs.ooder.net
- 社区论坛: community.ooder.net
© 2026 Ooder 架构团队. 本文基于代码库实际源码分析撰写，描述 v3.5.0 的技术架构规划与设计理念。