Ooder AI-Studio 从 MiMo 模型到工具编排 深入实践 MiMo-V2.5-Pro

一、Ooder AI-Studio 是什么?

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

Ooder AI-Studio 截图

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

这四大工作台并非孤立存在，而是通过统一的场景引擎（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 关键规格（基于官方资料）

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

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

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

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

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

四、架构设计：以 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 场景工具调用流程示例

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 能力以最简单、最自然的方式服务于每一位开发者。