mi-gpt Roadmap 深度解析从消息轮询到 RAG 与 MIoT Agent 的演进蓝图【免费下载链接】mi-gpt 将小爱音箱接入 ChatGPT 和豆包改造成你的专属语音助手。项目地址: https://gitcode.com/GitHub_Trending/mi/mi-gpt本文以 docs/roadmap.md 为骨架逐一拆解其中优化方向与新功能规划两条主线并结合当前仓库源码src/下的 speaker、bot、memory 等模块印证每一项规划背后的现状与可行性。读完你将掌握mi-gpt 当前的消息轮询架构如何运转、设备指令参数为什么需要手动配置、长短期记忆与 RAG 的落地差距在哪以及对话系统、MIoT Agent、插件系统等规划功能在源码中的对应锚点。一、Roadmap 文档的定位一份记录蓝图docs/roadmap.md是 mi-gpt 的路线图文档开篇即明确声明以下是一些可以优化的地方或新功能仅作记录之用暂时没有开发计划。这意味着本文讨论的所有条目都属于规划性质其中相当一部分在当前源码中仅以todo注释、预留接口或已有基础设施的形式存在并非已实现功能。同时仓库 README.md 顶部标注该项目已停止维护不再提供更新与支持。因此在阅读下文时请把 Roadmap 理解为一幅设计蓝图它清晰地勾勒了作者眼中 mi-gpt 应当进化的方向而源码则证明了哪些基础能力已经就位、哪些还停留在占位阶段。Roadmap 共分两大板块 优化Optimization3 个方向聚焦现有架构的短板——消息获取方式、设备适配成本、部署运维体验✨ 新功能New Features4 个方向聚焦能力边界的扩展——对话系统增强、MIoT 智能体、RAG 检索增强、插件系统。下文按此顺序逐一展开并给出对应的源码证据。二、 优化方向从能用到好用1. 使用通知事件获取最新消息与播放状态替代轮询Roadmap 提出的第一个优化方向是使用通知事件获取最新消息和设备播放状态以提高及时响应速度适配更多机型使其支持连续对话减轻轮询对服务端造成的压力。要理解这项优化为什么被提出需要先看清 mi-gpt 当前的消息获取机制。核心实现在 src/services/speaker/speaker.tsconst { heartbeat 1000, exitKeepAliveAfter 30, ... } config; this.heartbeat clamp(heartbeat, 500, Infinity); // ... while (this.status running) { const nextMsg await this.fetchNextMessage(); // ... if (nextMsg) { this.responding false; this.logger.log( nextMsg.text); // 异步处理消息不阻塞正常消息拉取 this.onMessage(nextMsg); } await sleep(this.heartbeat); // 默认每 1 秒轮询一次 }从源码结构看Speaker.run() 是一个基于心跳间隔的轮询循环程序每隔heartbeat毫秒默认 1000ms最低 500ms调用一次fetchNextMessage()通过小爱音箱的对话接口拉取最新消息。轮询的细节在 getMessages() 中它会过滤掉非 TTS/LLM 类型的回答、以及播放音乐时产生的双 Answer 记录仅保留真正需要 AI 响应的用户语音。由此可以推断 Roadmap 提出通知事件方案的三个动机及时性轮询的响应延迟天然取决于心跳间隔——间隔越小越及时但代价是请求更频繁改成由服务端推送的通知事件可以做到消息到达即触发延迟趋近于零。机型兼容性连续对话keepAlive唤醒模式依赖activeKeepAliveMode()循环里持续向设备下发静音音频或 TTS 指令来按住小爱不抢答见 src/services/speaker/speaker.ts部分机型无法正确处理这种保持状态若播放状态能通过通知事件实时获得就能精准地在 AI 回答时静音、回答完毕时放开从而覆盖更多机型。服务端压力持续轮询且唤醒模式下还要叠加静音指令对米家服务端与音箱自身都构成不小的负载事件驱动架构能从根本上消除无效轮询请求。值得注意的是SpeakerConfig已经为这条路径预留了参数位——heartbeat、exitKeepAliveAfter、audioSilent静音音频链接都在 speaker.ts 的配置接口中定义说明轮询节奏可调是当前折中方案而事件化是更彻底的演进方向。2. 自动识别设备型号免去手动查询 miot spec第二个优化方向是自动识别设备型号Roadmap 列出的两个子目标通过查询设备 miot spec 文件自动获取指令参数自动识别设备属性值是否有读取权限。这直接对应 mi-gpt 使用体验中最大的一个门槛设备指令参数必须手动填写。查阅 docs/settings.md 的.migpt.js配置表可以看到与音箱交互依赖三组指令参数参数描述示例ttsCommand小爱音箱 TTS 指令可在家电 miot spec 网站查询[5, 1]wakeUpCommand小爱音箱唤醒指令同样需查询 miot spec[5, 3]playingCommand查询小爱音箱是否在播放中的指令默认无需配置播放出问题时再开启[3, 1, 1]这些参数本质上是米家物联网MIoT协议中的指令action编号。不同型号的小爱音箱其 TTS、唤醒、播放状态查询对应的 action 编号可能不同用户需要自行去 miot spec 站点查清自己设备的型号与指令号再填回配置。这种手动适配方式不仅繁琐而且一旦填错就会导致 AI 无法出声、无法唤醒或无法正确判定播放状态进而影响连续对话。Roadmap 的设想是启动时自动查询设备的 miot spec 文件程序自行解析出ttsCommand、wakeUpCommand、playingCommand并检测设备属性如播放状态是否具备读取权限从而让小爱音箱 Pro 之外的更多机型也能零配置接入。从源码看指令的下发链路已经封装在MiIOT.doAction(...this.ttsCommand, ...)这类调用中见 activeKeepAliveMode也就是说指令参数的消费端已就绪只差自动探测这一生产端这正是 Roadmap 要补齐的部分。3. 镜像更新说明与 db 备份恢复第三个优化方向属于运维体验范畴添加镜像更新说明添加 db 文件导入/导出教程用于备份恢复对话历史记录。mi-gpt 的对话历史与记忆数据持久化在本地数据库中。从数据层代码看项目使用 Prisma ORM 管理 SQLite 数据schema 定义在 prisma/schema.prisma数据库表包括用户User、房间Room、消息Message、记忆Memory等实体长短期记忆分别落在memory_short_term与memory_long_term表对应 src/services/db/memory-short-term.ts 与 src/services/db/memory-long-term.ts。此外一份名为.bot.json的索引文件记录着 bot 与 master 的用户 ID 映射由 BotConfig 负责读写——若该文件丢失程序会报错提示请删除 .bot.json 文件后重试并重建记录。因此对话历史与记忆 SQLite 数据文件 .bot.json 索引。Roadmap 计划补一份 db 文件导入/导出教程正是为了让用户升级 Docker 镜像或迁移部署环境时能够完整备份上述文件、在新环境恢复对话上下文避免升级一次就失忆。这一条目虽无源码实现但明确了备份的最小文件集合对实际运维极具参考价值。三、✨ 新功能规划能力边界的四重扩展1. 增强对话系统对话模式开关与语音清空上下文Roadmap 计划为对话系统增加两项能力添加是否启用对话模式的开关支持通过语音命令清除上下文。关于对话模式开关当前源码其实已经有一套接近该概念的状态机AISpeaker维护keepAlive唤醒/连续对话状态并通过三组关键词驱动状态流转见 src/services/speaker/ai.tswakeUpKeywords默认[打开, 进入, 召唤]消息以这些词开头时进入keepAlive唤醒状态exitKeywords默认[关闭, 退出, 再见]退出唤醒状态callAIKeywords默认[请, 你, 傻妞]未唤醒时消息以这些词开头也会触发单次 AI 回答。enterKeepAlive()还会特别检查流式响应是否开启若关闭则提示无法使用连续对话模式见 src/services/speaker/ai.ts。而Speaker层的exitKeepAliveAfter默认 30 秒则实现了无响应自动退出唤醒的兜底见 src/services/speaker/speaker.ts。由此可见对话模式开关的运行时骨架已经存在Roadmap 中的开关更多是指将这一能力暴露为显式、可配置的开关如按会话/按房间粒度控制是否允许进入连续对话。关于语音命令清除上下文源码中有一处非常明确的占位注释。在 src/services/speaker/ai.ts 的命令链里写着// todo 考虑添加清除上下文指令也就是说清除上下文指令是作者在实现命令匹配体系时已经预留好的扩展点只差一个具体的 match/run 实现。从现有命令模式如你是傻妞你xxx、我是xxx我xxx的人设修改命令见 src/services/bot/index.ts可以推断清除上下文命令大概率会采用同样的正则匹配方式例如清除记忆/忘记刚才的话之类执行时清理ConversationManager中的消息记录与长短记忆。2. MIoT AI Agents让小爱音箱控制米家设备这是 Roadmap 中想象力最大的一项规划支持小爱音箱控制米家设备通过 Agent 机制自动调用合适的工具设备。其愿景与 README.md 的项目简介一脉相承让每个米家智能设备灯泡、插座、扫地机器人、电视都成为独立的智能体Agent小爱音箱作为智能家居管家根据用户意图自动调度合适的设备执行操作。从当前源码看这项能力尚处于未实现状态——仓库中没有任何米家设备控制除音箱本体外的业务代码。但支撑它的基础设施已经相当扎实工具/命令抽象SpeakerCommand接口见 src/services/speaker/speaker.ts定义了match消息匹配与run执行并返回回复两个方法任何设备控制指令都可以注册为一条 Command人设/上下文管理MyBot已经能通过语音实时修改 AI 的人设并持久化你是xxx你xxx命令说明用自然语言驱动系统行为变更的通路已被验证MIoT 调用能力底层已封装对音箱执行 MIoT action 的调用链MiIOT.doAction扩展到其他米家设备在协议层面是相通的。也就是说Roadmap 中的MIoT AI Agents可以理解为在现有 Command 体系之上叠加一层由大模型根据用户指令自主选择调用哪个设备工具的决策层——这正是Agent 机制自动调用合适的工具的含义。README 功能亮点列表中智能家居 Agent 一项也被划掉~~智能家居 Agent~~与 Roadmap暂无开发计划的定位相互印证。3. RAGwikis embedding 与 memory embeddingRoadmap 的 RAG检索增强生成规划包含两条wikis embedding知识库向量化memory embedding记忆向量化。先看 memory embedding 的现状。长短期记忆模块是当前仓库中已实现且最接近 RAG 的部分实现在 src/services/bot/memory/index.ts。其工作流程是每条对话消息落库时addMessage2Memory()会为它创建一条 Memory 记录当新 Memory 数量达到阈值短期默认 10 条时调用ShortTermMemoryAgent用大模型把最近对话摘要压缩成一条短期记忆见 short-term.ts要求总字符数不超过 1000并以 JSON 格式输出短期记忆积累到阈值默认 10 条后再调用LongTermMemoryAgent把短期记忆进一步凝练为长期记忆见 long-term.ts同样限 1000 字符生成 Prompt 时短期/长期记忆会作为上下文片段注入 system 模板见 src/services/bot/index.ts 与 kDefaultSystemTemplate。但目前的记忆调用是取最新一条getShortTermMemories({ take: 1 })/getLongTermMemories({ take: 1 })而非按相关性检索。源码中两处todo注释清楚地标注了 RAG 的缺口// todo search memory embeddings async getRelatedMemories(limit: number): PromiseMemory[] { return []; // 目前返回空数组 } // todo create memory embedding async addMessage2Memory(ctx: MessageContext, message: Message) { ... }分别见 src/services/bot/memory/index.ts 与 L52-L63这两处注释意味着记忆的生成管线已完整向量化 相关性检索的 RAG 部分则尚未动工。Roadmap 中的 memory embedding 正是要在这里为每条记忆生成 embedding 向量并在对话时按语义相似度召回相关记忆getRelatedMemories就是预留的召回入口替代目前只取最新一条的粗放策略。wikis embedding则属于全新知识库能力的扩展为文档/wiki 建立向量索引让 AI 能基于私有知识回答问题。它与 memory embedding 共享同一套向量化与检索基础设施因此被并列列入 Roadmap。4. 插件系统自定义语音指令与联网查询Roadmap 的最后一项规划是插件系统包含两个子功能自定义语音指令联网查询最新数据。自定义语音指令在源码中已有雏形。Speaker基类提供了addCommand()方法见 src/services/speaker/speaker.ts允许向命令链动态追加自定义指令而 MyBot 构造函数 正是通过这一 API 注册了你是xxx你xxx我是xxx我xxx两条人设命令。换句话说通过正则匹配 异步执行 自动语音回复的指令框架已完全可用Roadmap 的插件系统本质上是把这一能力开放成用户可配置的声明式插件如配置文件里声明听到查天气就触发某个 HTTP 请求把结果喂给大模型生成回答。联网查询则直指当前大模型回答的时效性短板由于默认 system 模板要求 AI如果对某些信息不确定或遗忘诚实地表达不清楚纯离线对话无法回答需要实时数据的问题。联网插件将把搜索最新数据 → 作为上下文注入 Prompt → AI 基于资料回答这条链路打通。从架构看MyBot.ask()中 Prompt 的组装buildPromptformatMsg见 src/services/bot/index.ts是高度模板化的注入一段检索结果并不需要改动对话主流程插件化接入的技术成本可控。四、总结蓝图与地基的对照Roadmap 条目当前源码状态关键证据通知事件替代轮询轮询机制已实现事件化未动工speaker.ts 的 run() 轮询循环自动识别设备型号指令参数仍需手动配置docs/settings.md 的 ttsCommand/wakeUpCommand 说明db 导入/导出教程数据持久化已就绪教程缺失prisma/schema.prisma、config.ts 的 .bot.json 读写对话模式开关keepAlive 状态机已实现ai.ts 的 wakeUp/exit 命令语音清除上下文已留todo占位ai.ts 第 202 行注释MIoT AI Agents基础设施就绪业务未实现speaker.ts 的 SpeakerCommand 接口RAGmemory embedding记忆生成已实现向量化留todomemory/index.ts 两处 todo插件系统addCommand 框架已实现speaker.ts 的 addCommand整体来看docs/roadmap.md 规划的每一项背后都能在源码中找到对应的地基要么是已可运行的机制轮询、keepAlive、Command、记忆生成要么是明确标注的扩展点todo注释、预留接口、模板化 Prompt。这份 Roadmap 的价值不在于何时实现而在于它完整记录了 mi-gpt 从音箱 大模型问答走向智能家居 Agent 平台的架构演进思路——对于想在此基础上二次开发、或理解该项目设计取舍的开发者而言配合源码阅读是一份高质量的技术导航图。【免费下载链接】mi-gpt 将小爱音箱接入 ChatGPT 和豆包改造成你的专属语音助手。项目地址: https://gitcode.com/GitHub_Trending/mi/mi-gpt创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
