一、Ooder AI-Studio 是什么?

Ooder AI-Studio是一个面向企业级应用开发的智能化集成开发环境（IDE），它基于 a2ui 注解驱动组件框架 构建，提供从可视化设计到代码生成的完整开发链路。平台的核心使命是让 AI 能力像搭积木一样简单组合，让企业知识像资产一样高效管理，让业务应用像配置一样快速构建。

OODER Studio 包含四大核心工作台：

工作台	功能定位	典型使用场景
RAD 设计器	快速应用开发，可视化拖拽生成 UI 组件	表单、表格、树形、图表等页面构建
BPM 设计器	业务流程管理，流程节点编排与配置	审批流程、工作流设计
Skills 管理	技能编排与模板管理，Agent 执行	智能体配置、知识库管理
LLM Chat	场景化智能对话助手	自然语言驱动开发、智能问答

这四大工作台并非孤立存在，而是通过统一的场景引擎（scene-engine）和LLM Chat 智能助手深度串联。开发者在 RAD 中设计表单时，可以直接通过自然语言描述让 AI 生成组件；在 BPM 中编排流程时，可以用对话方式添加节点和配置属性。这种**“所想即所得”**的交互范式，正是 OODER Studio 区别于传统低代码平台的核心竞争力。

图1：OODER Studio 全景视图 — LLM Chat 作为智能中枢串联四大工作台

二、MiMo-V2.5-Pro：OODER Studio 的 AI 大脑

OODER Studio 的 LLM Chat 能力建立在 MiMo-V2.5-Pro 大模型之上。MiMo 是小米公司于 2026 年 4 月 28 日正式发布并开源的大模型系列，采用 MoE（混合专家）架构，总参数 309B，激活参数 15B，原生支持 100 万 Token 的超长上下文窗口。

2.1 为什么选择 MiMo-V2.5-Pro

在 OODER Studio 的架构设计中，选择 MiMo-V2.5-Pro 作为核心模型并非偶然。该模型在多个维度上契合了企业级开发平台的需求：

• 超长上下文：100 万 Token 的上下文窗口，能够容纳完整的项目结构、组件定义和对话历史，避免了频繁截断导致的上下文丢失。
• 强大的工具调用能力：支持标准 OpenAI 格式的 Function Calling，可并行调用多个工具，这对于需要同时操作 RAD 组件、BPM 节点和 Skills 配置的复杂场景至关重要。
• 深度思考能力：模型在生成回复前会输出 reasoning_content 展示思考过程，这让 OODER Studio 能够将"AI 在思考什么"透明地呈现给用户，增强信任感。
• 编码能力突出：在 SWE-bench Pro 上得分 57.2%，与 Claude Opus 4.6、GPT-5.4 基本持平；在 MiMo Coding Bench 上得分 73.7，优于 Claude Opus 4.6（71.5）。
• 开源与成本优势：采用 MIT 协议开源，允许自由商用和二次训练；在达到相同 Agent 基准分数的情况下，相比 Kimi K2.6 可节省约 42% 的 Token 消耗。

MiMo-V2.5-Pro 关键规格（基于官方资料）

指标	数值
架构	MoE（混合专家）
总参数	309B
激活参数	15B
上下文窗口	100 万 Token
SWE-bench Pro	57.2%
ClawEval (pass^3)	63.8
协议	MIT（开源可商用）

三、为什么 OODER Studio 需要场景化 LLM Chat

传统的 LLM 应用通常是"一个对话框走天下"的通用聊天机器人。但在企业级开发平台中，这种设计存在明显的局限性：

传统通用聊天机器人的痛点

• 上下文缺失：AI 不知道用户当前在 RAD 设计器中选中了一个表单组件，也不知道 BPM 流程图中刚刚添加了什么节点
• 能力边界模糊：用户不清楚 AI 能做什么（生成组件？修改属性？还是只能聊天？）
• 操作割裂：AI 给出了建议，但用户需要手动在设计器中执行，无法形成闭环
• 多轮对话混乱：在 RAD 中讨论表单设计，切换到 BPM 后对话历史仍然混在一起

OODER Studio 的 LLM Chat 通过以下设计解决了这些问题：

设计策略	解决的问题	实现方式
场景感知	上下文缺失	自动捕获当前工作台、选中组件、工程信息
场景路由	能力边界模糊	StudioChatRouter 根据输入自动匹配最佳场景
工具调用	操作割裂	Function Calling 直接操作设计器、修改组件
会话隔离	多轮对话混乱	每个场景独立的对话上下文和 Session 管理
深度思考可视化	黑盒不信任	实时展示 reasoning_content，让用户看到 AI 的思考过程

四、架构设计：以 Studio 为中心的智能中枢

OODER Studio LLM Chat 的架构围绕"场景化"这一核心理念展开。系统不是简单地将一个聊天窗口嵌入到 IDE 中，而是将 LLM 能力深度融入到每个工作台的业务流程中。

4.1 场景路由：让 AI 知道"我现在在哪"

当用户在 OODER Studio 中发送一条消息时，系统首先需要回答一个问题：这条消息应该由哪个场景来处理？

StudioChatRouter 通过意图匹配算法来解决这个问题。以 RAD 场景为例，当用户输入"帮我生成一个用户管理表单"时，路由器的匹配逻辑如下：

• 关键词"表单"命中 UI 相关词库，RadChatScene 获得 +3 分
• 关键词"生成"命中动作词库，RadChatScene 再获 +3 分
• 系统检测到用户当前处于 RAD 设计器环境，RadChatScene 获得场景绑定加分 +10 分
• 同时，BpmChatScene 因关键词"表单"不属于流程领域而获得负分
• 最终 RadChatScene 以 16 分的绝对优势胜出

这种基于分数的匹配机制确保了即使在没有明确场景指令的情况下，AI 也能准确理解用户的意图。

4.2 上下文注入：让 AI 知道"我周围有什么"

场景路由确定后，系统会自动收集当前操作环境的上下文信息，构建成一个 JSON 对象注入到 Prompt 中。在 RAD 场景中，上下文包含：

• 工程信息：当前工程名称、路径、页面路径
• 选中状态：用户当前选中的组件类型、名称、ID
• 环境数据：当前页面组件总数、画布尺寸等
• 历史操作：最近执行的构建命令和修改记录

这些上下文信息让 AI 的回答不再是泛泛而谈，而是基于用户当前实际工作状态的精准建议。

4.3 模型适配层：统一多模型接口

OODER Studio 支持 MiMo、GLM、DeepSeek、Qwen 等多种大模型。为了屏蔽不同模型之间的接口差异，系统设计了 BpmLlmChatProvider 适配器层。该层封装了统一的调用接口，包括简单对话、带历史对话、带工具调用、流式输出等模式。当需要切换模型时，只需更换适配器实现，上层业务逻辑完全不受影响。

图2：OODER Studio LLM-Chat 系统架构图

五、工具调用编排：从"说"到"做"的闭环

工具调用是 OODER Studio LLM Chat 区别于普通聊天机器人的关键能力。它让 AI 不仅能"说"，还能"做"——直接操作设计器、修改组件属性、生成代码。

5.1 为什么需要工具编排

在实际的开发场景中，一个用户请求往往需要多个工具的协同配合。例如"帮我创建一个请假审批流程"这个简单指令，背后涉及：

1. 创建开始节点（create_start_activity）
2. 创建提交活动节点（create_activity）
3. 创建主管审批节点（create_activity）
4. 创建 HR 审批节点（create_activity）
5. 创建结束节点（create_end_activity）
6. 连接各节点（create_route）

这些工具之间存在明确的依赖关系：必须先创建节点，才能连接路由。这就是工具编排的价值所在——将一组有依赖关系的工具调用组织成可执行的计划。

5.2 四种编排策略

OODER Studio 的 ToolOrchestrator 支持四种编排策略，分别对应不同的业务场景：

图3：四种工具编排策略对比与 RAD 场景工具调用流程示例

策略	执行方式	典型场景
SEQUENTIAL	顺序执行，前一个成功后才执行下一个	BPM 流程创建（先建节点再连路由）
PARALLEL	并行执行所有工具，使用线程池	批量修改多个组件属性
CONDITIONAL	条件执行，根据前置结果决定分支	根据组件类型选择不同的配置逻辑
PIPELINE	管道执行，前一个的输出作为后一个的输入	数据转换链（查询 → 过滤 → 格式化）

5.3 多轮工具调用循环

更复杂的场景需要 AI 在获取工具执行结果后再次决策。OODER Studio 实现了最多 5 轮的工具调用循环：

• Round 1：LLM 分析用户意图，决定调用哪些工具
• Round 2：工具执行完成后，将结果反馈给 LLM，LLM 根据结果决定下一步
• Round 3~5：持续迭代，直到任务完成或达到最大轮数

例如，当用户说"先列出当前页面的所有组件，然后给每个组件添加一个点击事件"时，Round 1 调用 list_page_components 获取组件列表，Round 2 根据返回的列表逐个调用 update_component 添加事件。

六、深度思考：让 AI 的"黑盒"变透明

MiMo-V2.5-Pro 的一大特色是支持 reasoning_content（深度思考内容）输出。在生成正式回复之前，模型会先输出一段思考过程，展示它是如何理解问题、分析上下文、做出决策的。

6.1 双通道流式输出

OODER Studio 的前端完整支持了这种双通道输出模式。SSE 流中同时包含两个数据流：

• reasoning_content（橙色通道）：模型的思考过程，以灰色背景展示在消息顶部，默认折叠，点击可展开
• content（绿色通道）：正式回复内容，以打字机效果逐字显示

图4：MiMo-V2.5-Pro 深度思考与双通道流式输出的前端渲染效果

6.2 为什么需要展示思考过程

在企业级开发场景中，开发者需要理解 AI 为什么会做出某个决策。展示思考过程带来以下价值：

• 建立信任：用户能看到 AI 是否正确理解了当前上下文
• 便于调试：当 AI 行为不符合预期时，可以通过思考内容定位问题
• 学习辅助：新手开发者可以通过观察 AI 的思考过程学习如何分析需求
• 交互优化：如果 AI 理解有误，用户可以在思考阶段就打断并纠正

6.3 长任务的可视化管理

对于"生成一个包含 20 个字段的复杂表单"这样的长任务，OODER Studio 通过任务步骤面板（Task Panel）将整个过程可视化：

• 每个步骤都有独立的状态图标（🔵 运行中 / 🟢 完成 / 🔴 失败）
• 步骤之间自动流转，前一个完成后下一个自动开始
• 用户可以实时看到当前处于哪个阶段，预计还需要多久
• 如果某个步骤失败，错误信息会高亮显示，便于排查

图5：SSE 流式事件类型与前端状态变化

七、实测用例：从"说"到"做"的完整闭环

用例 1：RAD 场景 —— 一句话生成表单

场景描述

用户在 RAD 设计器中输入："帮我生成一个用户管理表单，包含姓名、邮箱、手机号字段"

步骤 1：上下文感知

系统自动收集当前环境信息：用户在 RAD 设计器中、当前工程为 demo、页面路径 /pages/user-management、已选中一个 Form 组件。

步骤 2：场景路由

StudioChatRouter 计算匹配分数：“表单”+3 分、“生成”+3 分、RAD 环境 +10 分，RadChatScene 以 16 分胜出。

步骤 3：Prompt 构建

PromptEngine 注入系统提示和上下文：“你是 RAD 设计助手，当前工程 demo，页面 user-management，已选中 Form 组件…”

步骤 4：深度思考

MiMo 输出 reasoning_content：“用户需要生成表单…当前在 RAD 环境…应该调用 nlp_build_component 工具…需要字段：姓名、邮箱、手机号…”

步骤 5：工具调用

LLM 决定调用 nlp_build_component 工具，参数为 {“description”: “用户管理表单，包含姓名、邮箱、手机号字段”}。

步骤 6：工具执行

NlpDesignService 解析描述，生成 genJson，通过 NlpDesignBridgeService 桥接到设计器，最终通过 NlpProjectIntegrator 集成到项目。

步骤 7：流式响应

前端依次收到 SSE 事件：connected → thinking → tool_call → step(意图识别) → step(组件构建) → step(桥接设计器) → step(项目集成) → token(回复内容) → complete。

结果

用户在 RAD 画布上看到新生成的表单组件，包含三个字段和对应的验证规则，整个过程约 3-5 秒。

用例 2：BPM 场景 —— 对话式流程设计

场景描述

用户在 BPM 流程设计器中输入："创建一个请假审批流程，包含提交、主管审批、HR审批三个节点"

步骤 1：上下文构建

系统收集 BPM 上下文：当前流程 ID 为 leave_process，尚无活动节点，画布为空。

步骤 2：场景匹配

BpmChatScene 获得高分：“流程”+5、“审批”+3、“节点”+3、BPM 环境 +10，总分 21 分。

步骤 3：顺序编排执行

ToolOrchestrator 采用 SEQUENTIAL 策略，按顺序执行：创建开始节点 → 创建提交节点 → 创建主管审批节点 → 创建 HR 审批节点 → 创建结束节点 → 连接路由。

步骤 4：画布实时更新

每个工具执行完成后，前端通过 _applyBpmActions 将结果实时应用到 BPM Store，画布上立即显示新节点和连线。

结果

用户在 BPM 画布上看到完整的请假审批流程图，包含 5 个节点和 4 条路由连线，可直接进入属性配置。

用例 3：多轮工具调用 —— 复杂任务分解

场景描述

用户输入："先列出当前页面的所有组件，然后给每个组件添加一个点击事件，事件内容是打印组件名称"

Round 1：信息收集

LLM 调用 list_page_components 工具，获取组件列表：Form1、Table1、Button1、Input1。

Round 2：批量操作

LLM 获取列表后，决定采用 PARALLEL 策略，同时发起 4 个 update_component 调用，分别给每个组件添加 onClick 事件。

Round 3：结果汇总

4 个工具并行执行完成后，LLM 汇总结果，生成最终回复：“已为 4 个组件添加点击事件：Form1.onClick → console.log(‘Form1’)…”

结果

3 轮工具调用在 2 秒内完成，用户无需手动逐个配置，实现了"一句话批量操作"。

用例 4：Skills 场景 —— 技能模板问答

场景描述

用户在 Skills 管理页面输入："如何创建一个支持多轮对话的客服技能？"

步骤 1：上下文获取

LLMChatFloat 通过 getSkillContext() 获取当前页面信息：skillId、skillName、页面数据。同时从 URL 路径解析出当前在 Skills 管理模块。

步骤 2：知识增强

SkillsChatScene 将用户问题与场景引擎中的知识库结合，检索相关的技能模板文档和最佳实践。

步骤 3：结构化回复

LLM 生成结构化的操作指南，包含：创建步骤、关键配置项、示例代码、注意事项。同时提供快捷操作按钮"一键创建模板"。

结果

用户获得详细的操作指南，可以直接按照步骤在 Skills 管理器中执行，也可以点击快捷按钮自动生成基础模板。

八、前端交互：让技术隐形，让体验自然

OODER Studio 的前端交互设计遵循一个原则：技术复杂度不应该转嫁给用户。无论后端有多少轮工具调用、多少层编排策略，用户看到的始终是一个流畅的对话界面。

8.1 流式输出的"打字机"体验

当 AI 回复内容时，前端不是等全部内容返回后再一次性显示，而是通过 SSE 的 token 事件逐字追加到消息区域，形成打字机效果。这种设计让用户感知到"AI 正在思考"，而不是"系统在加载"。

8.2 思考过程的可折叠展示

深度思考内容默认以折叠状态展示（max-height: 120px），只显示前几行。用户点击后可以展开到 500px 查看完整思考过程。这种设计既保证了信息透明，又避免了思考内容过长干扰主阅读流。

8.3 任务步骤的实时反馈

对于长任务，任务步骤面板实时展示每个阶段的执行状态。用户可以看到当前处于"意图识别"还是"组件构建"，预计还有多久完成。如果某个步骤失败，错误状态会立即显示，用户可以点击重试。

8.4 自动降级机制

当 SSE 连接因网络问题中断时，系统不会直接报错，而是自动回退到同步 XHR 模式。用户几乎感知不到切换过程，只是流式打字机效果变成了整段显示。这种容错设计确保了在各种网络环境下的可用性。

九、总结与展望

OODER Studio 的 LLM Chat 不是简单地将一个聊天机器人嵌入 IDE，而是将 AI 能力深度融入到企业级开发的每个环节中。通过场景感知、工具编排、深度思考可视化等技术手段，实现了从"说"到"做"的完整闭环。

其核心价值可以概括为三个层面：

• 对开发者：降低了学习和使用成本，自然语言即可驱动复杂的开发操作
• 对团队：知识沉淀为可复用的技能模板，新人可以通过对话快速上手
• 对企业：开发效率提升，知识资产化，数字化转型加速

未来，OODER Studio 计划在以下方向继续演进：

• 多模态交互：支持图片、图表等多模态输入，实现"画个草图生成组件"
• 知识图谱集成：将企业知识库构建为知识图谱，支持更复杂的推理和关联查询
• Agent 自主决策：从"用户驱动"向"AI 主动建议"演进，AI 能够根据上下文主动提供优化建议
• 协作式开发：支持多人同时与 AI 对话，实现团队协作式的智能开发

技术的目标不是展示复杂性，而是隐藏复杂性。OODER Studio LLM Chat 的设计哲学正是如此——让强大的 AI 能力以最简单、最自然的方式服务于每一位开发者。