★ FEATURED ARTICLE 最近 Muse 登顶 App Store 这件事圈子里讨论得挺热闹。很多人第一反应是“又一个 AI 语音 App 火了”但真正值得琢磨的是它开源的 SDK 和背后那套硬件。把一个 AI Agent 从手机屏幕里“抠”出来放进一个随身设备里这个动作本身比登顶榜单更有信号意义。我上手这类设备有一段时间了也一直在跟嵌入式、端侧推理、硬件交互打交道这篇就把我给 Muse 这类“现实硬件 Agent”的产品判断、技术拆解和实践经验一起聊透给打算入局的开发者和产品经理做个参考。1. Muse 登顶 App Store这次出圈的不是 App是硬件入口1.1 它不是一个语音助手而是一个随身 AI 硬件先说清楚 Muse 到底是个什么东西。从公开信息和产品形态来看它不是一个单纯的手机 App而是一款配套硬件的智能助手——形态上更接近一个可以挂在胸前、戴在耳朵上或者别在衣领上的轻量 AI 设备有麦克风阵列、扬声器、低功耗处理器带 IMU 动作传感器和无线连接能力手机 App 负责初始化设置、技能管理和历史记录查看。Muse 本身承担了实时拾音、本地唤醒、意图判断和环境感知这些活能跟人自然对话、提醒日程、记录灵感也能调用工具完成一些具体任务。这类设备本质上回答了一个问题AI Agent 到底该住在哪里。过去我们认为 AI 助手住在云端和手机里Siri、Google Assistant 都是这么干的但实际使用频率并不高——因为掏出手机、解锁、打开 App、再说一句话这个路径太长了。Muse 把交互入口转移到身体上把一个 AI Agent 从“需要主动唤起的工具”变成“随时在场的生活搭档”。这一步看着简单背后是产品哲学的变化它不试图占领屏幕上的注意力而是接管你现实生活中的时间碎片。登顶 App Store 主要靠配套 App 完成用户激活和技能配置但它能让这么多人愿意下载、注册、绑硬件说明用户对“无屏的 AI 入口”是有真实需求的。很多人在问“这和手机上的语音助手有什么区别”区别在于语音助手是手机里的一个功能Muse 是一个以传感器和交互为底层逻辑的独立硬件入口。它抢占的不是 App 时长而是“抬手看手机之前”的那几秒空隙。1.2 配套 App 登顶背后用户其实在投票给“无屏交互”App Store 榜单历来是用户用脚投票的结果Muse 能上榜说明“硬件 Agent 轻量 App”的组合确实戳中了某类需求。我观察到的用户画像主要有三类一是被 AI 焦虑裹挟的上班族想用一个低门槛的方式体验“AI 随时在线”是什么感觉二是健身、通勤、开车场景里不方便频繁看手机的人需要的是耳朵和语音不是眼睛和手指三是对隐私有一定敏感度的用户他们希望 AI 的“耳朵”离自己近但离云端远——至少在本地做掉一部分处理。这三类人共同指向一个趋势AI 交互的主导权正在从“视觉界面”转移到“身体界面”。屏幕的本质是一个高带宽的信息输出口但它有一个致命缺陷——强制占用注意力。无屏交互则把注意力解放出来用语音、震动、轻量提示来传递信息。Muse 登顶 App Store本质上不是这个 App 本身做得有多惊艳而是“硬件 Agent 的概念”第一次以一种可购买、可体验、可把玩的方式落到大众面前。而且注意一个很有意思的细节登顶的是 App Store不是某个电商排行榜。这恰恰说明 AI 硬件的售卖逻辑变了——不是走“硬件参数比拼”的路径而是走“软件体验 生态服务”的路径。用户先通过 App 感受到 AI 的能力再决定是否持续使用硬件。这种“软件定义硬件”的打法对传统硬件厂商是个非常直接的提醒如果你的硬件不配一个好的软件入口和云端大脑它就只是电子垃圾。2. 开源 SDKAI 硬件最该抄的作业就是“放开接口”2.1 开源 SDK 开的到底是什么打通三件事Muse 选择把 SDK 开源这是我觉得整件事最值得研究的部分。所谓“开源 SDK”不是说把硬件原理图丢出来就完了而是把三件事打通第一设备端的能力接口——麦克风流、IMU 数据、喇叭播放、状态指示灯、按钮事件这些底层硬件能力通过 API 暴露给开发者第二技能分发通道——开发者写好一个技能比如“冥想引导”或“会议摘要”之后能通过 App 商店或开源渠道让用户安装使用第三云端/端侧模型接入规范——开发者既可以用平台默认的大模型也可以接自己的模型服务或本地模型。这三件事拆开看不稀奇合在一起就是一个“AI Agent 的硬件操作系统”。开源策略最聪明的地方在于它不赌自己的官方技能团队能产出多少好功能而是赌“外部开发者会长出更多意想不到的用法”。AI Agent 作为一个新品类最大的问题就是“没人知道它应该干什么”唯一的解法就是放开接口让市场来做功能探索。这也是我反复跟团队强调的一个观点AI 硬件早期的核心竞争力不是预装了多少技能而是别人能在你的硬件上长出多少技能。从技术选型来看SDK 一般会覆盖 iOS/Android 双端和嵌入式端。上层 App 通过 BLE 与设备通信下发技能配置、拉取日志、同步联系人授权设备端跑一个轻量 RTOS 或者嵌入式 Linux把音频采集、唤醒词、VAD语音活动检测这些做好再决定是本地推理还是上云。开源之后社区可以自己加唤醒词、改交互策略、接第三方传感器——理论上你甚至可以给 Muse 加一个温湿度传感器扩展板让 AI 感知环境变化。这种扩展性封闭 SDK 永远给不了。2.2 开发者能用 SDK 做哪些事从技能插件到外设联动站在开发者角度拿到 Muse SDK 之后能做的事远比“写个语音技能”多。我按交互深度分了几档供大家判断自己适合从哪切入。第一档是内容型技能最简单不需要操作硬件外设就是写一段提示词和回复逻辑让设备在用户说出某个触发词时播报特定内容比如“每日星座运势”“通勤路况播报”。这档适合内容创作者开发成本极低本质上是把语音技能当成一个新媒体账号来做。第二档是工具型技能需要调用设备能力和外部 API比如“布置一个番茄钟”“把当前对话内容同步到笔记软件”“开车时用语音快速添加日历事件”。这档需要处理意图识别、参数槽填充、API 调用和结果回读开始考验工程师对 Agent 工作流的理解。第三档是感知型技能需要把设备的麦克风、IMU、定位、时间上下文揉在一起做推理。典型例子是“检测到用户在跑步时自动播报配速”“检测到连续久坐 1 小时就提醒起身”“如果环境噪音持续偏高主动建议降低耳机音量”。这档才是 Muse 这类硬件 SDK 区别于“手机语音技能”的核心价值——手机没有那么多环境传感器也没有佩戴姿态数据你在手机上根本做不出这类技能。第四档是外设联动型技能需要自己焊电路、写驱动把额外的传感器或执行器通过扩展接口接进来。SDK 开源之后这部分的想象空间最大但门槛也最高。我见过有人给语音助手设备外接了一个空气检测模块让它能回答“室内甲醛浓度多少”也有人把继电器模块接上去让 AI 能说“我已经帮你关掉热水器了”。这种硬件形态的 Agent已经不是 App 能定义的东西了。2.3 对比封闭方案开源 SDK 在生态冷启动上的优势如果把 Muse 的策略和某大厂那套封闭的语音助手生态比一比差距非常明显。封闭方案的问题是“能力很强但是开发者的进入门槛不可见”——你想用它的语音识别能力得申请企业资质、等审核、签一堆协议个人开发者基本被挡在门外。开源 SDK 的逻辑恰恰相反它用“低门槛 高自由度”换取社区的热情让个人开发者和极客先跑起来再由极客去影响大众用户。冷启动阶段AI 硬件最缺的不是功能数量而是“有人愿意持续为它写东西”。一个硬件 Agent 如果只有官方团队更新技能三个月后用户就会腻但如果有一个开源社区在背后持续产出长尾技能设备的生命周期和价值感完全是另一个量级。开源 SDK 的本质是给这个项目请了一群“编外产品经理”他们不领工资但会因为自己的创意被陌生人使用而产生持续的贡献动力。另外开源还有一层隐藏价值招聘和技术品牌。一个开源 SDK 项目的 GitHub 仓库就是最好的技术简历。我见过不止一个嵌入式工程师因为在某个开源硬件项目里交了高质量的 PR被猎头和公司直接挖走。对硬件公司来说开源也意味着更低的技术信任成本——客户和合作伙伴可以通过源码判断你的底层是否靠谱而不是听你一面之词。3. AI Agent 为什么必须离开屏幕从“信息容器”到“物理执行者”3.1 “屏幕囚笼”的真正含义AI 只能进到眼睛里进不了世界里“屏幕囚笼”这个词一度被很多人当成营销话术但从技术角度看它是一个非常准确的描述。今天主流的 AI Agent——无论 ChatGPT、Copilot 还是各种套壳助手——本质上都是“屏幕容器”里的信息处理器用户的输入以文本、图片、语音形式进入界面模型的输出也以同样的形式回到界面。整个过程里AI 从没有和物理世界发生过直接交互。它能帮你写邮件但不能帮你按电梯按钮它能告诉你空调该开多少度但不知道屋里实际有多热。这个局限的根源在于屏幕是 AI 的“感官替代品”。一切感知都是用户替它做的——用户把看到的、听到的、感受到的东西转述给它。这不仅增加了交互损耗而且在根本上限制了 Agent 可以完成的任务类型。一个只能通过文字和世界打交道的 Agent永远不可能理解“咖啡杯快倒了”这种实时物理场景更不可能在你开口之前就帮你扶住它。硬件恰恰是打破这个囚笼的关键。当 Agent 有了麦克风阵列它能听到声音的方位和距离有了 IMU它能感知自己是在走动还是静止有了温度、气压、光线传感器它开始对“物理环境”有最低限度的建模。每一个传感器都在把“现实世界”转译成 AI 能理解的数字信号——这才是 Agent 从“聊天的”变成“做事的”的第一步。3.2 硬件给 AI Agent 带来的四重新增量硬件不只是给 Agent 加了个“耳朵”而是带来四个维度的能力扩展。第一个是感知增量设备上的麦克风、IMU、光学传感器让 Agent 获得了实时环境数据。环境感知不是“多一个功能”那么简单它改变了交互触发方式——从“用户说触发词”变成“系统根据环境状态主动判断是否需要介入”这是 Agent 自主性的根本前提。第二个是执行增量Agent 的判断结果可以通过蓝牙、WiFi、甚至红外发射直接控制周边设备。Muse 这类产品可能不会一开始就把万能遥控器做进去但 SDK 开源之后社区完全可以做出“语音控制空调”的技能——通过外接红外模块把 Agent 的“想法”变成“动作”。第三个是位置增量设备物理上戴在用户身上这给了 Agent 一个“空间身份”。它知道用户正在通勤、正在居家、正在健身房——这种上下文不是靠猜的是靠传感器和连接状态推断出来的。位置信息加上时间信息能让 Agent 的建议贴合当下场景而不是给一个泛泛的答案。第四个是身份增量当 AI 硬件长期由同一个人佩戴它会积累越来越多的个性化数据——作息规律、语音习惯、常去地点、健康数据。这些数据让 Agent 从“通用助手”变成“私人伴侣”。手机 App 也能收集这些数据但手机做不到 24 小时贴身感知这是硬件 Agent 的核心护城河。3.3 支撑硬件 Agent 的三层技术底座与主流选择要支撑上面这些能力硬件 Agent 需要三层底座。第一层是端侧计算层负责音频、传感器的实时处理。这里面有两个主流选型一类是超低功耗 MCU DSP适合只做唤醒词和 VAD 这种轻负载任务的设备功耗可以压到毫瓦级另一类是带 NPU 的 SoC比如瑞芯微、地平线、晶晨这类芯片能跑 1B 参数以下的端侧小模型实现离线意图识别和简单问答。Muse 这类产品大概率是两层结合——MCU 常驻监听SoC 按需唤醒。第二层是连接与同步层负责设备与手机、云端、其他硬件之间的数据通路。蓝牙 BLE 适合低功耗控制指令和轻量数据传输WiFi 适合大批量音频同步和大模型请求Thread/Matter 则用于智能家居生态联动。这个层面最大的坑是功耗和延时的权衡——每次唤醒都走云续航会崩但纯本地又做不了复杂语义理解。普遍方案是分层处理本地先做意图粗筛置信度不够再上云。第三层是模型与技能层负责把用户意图映射为具体动作。这一层又分云端大模型和端侧小模型。云端模型负责复杂推理、工具调用和长上下文端侧模型负责隐私敏感数据和低延迟响应。一个好的硬件 Agent 架构必须能把这两类模型无缝衔接起来——该端侧的绝对不上云该上云的绝不硬撑。这三层底座的技术选型直接决定了一个硬件 Agent 产品的成本、续航和体验上限。SDK 开源最大的价值就是把这些底层复杂性封装成相对友好的接口让开发者不用从零开始啃嵌入式也能做出硬件 Agent 的技能。这是 AI 硬件走向普及的关键一步。4. AI Agent 落地硬件绕不开的五个硬骨头附排查心得4.1 端侧推理性能与功耗的跷跷板做硬件 Agent第一个绕不开的就是功耗问题。手机上的语音助手可以肆无忌惮地调云端 API因为电量焦虑已经被大电池和快充解决了可穿戴设备不行——一块不到 300mAh 的电池你要是让麦克风一直在线、每句话都上云两个小时就变成一块砖头。这也是很多软件团队转做硬件时最不适应的一个点代码写得再漂亮功耗压不住就是废品。我处理这类问题的经验是“分级响应”。常驻阶段只跑一块微控制器裸奔频率极低只做音频能量检测判断有没有人说话检测到声音后立刻启用神经网络做语音活动检测VAD确认是语音还是环境噪声只有确认是语音之后才把音频推给端侧小模型做意图粗判端侧判不了再唤醒 WiFi 上云。这一套流程跑下来平均功耗可以控制在几十毫瓦量级续航才能从理论走向真实使用。另外提一个很多人会忽略的点WiFi 模块的功耗比芯片的推理功耗高得多。很多团队的设备耗电快不是模型推理烧掉的而是 WiFi 频繁唤醒联网烧掉的。SDK 层面最好提供“批量上送”和“延迟重试”的接口让开发者可以自行权衡响应速度和功耗而不是每次对话都持续占用网络连接。4.2 多模态感知同步音频、视觉、IMU 的对时问题硬件 Agent 一旦要做多模态感知就一定会遇到“时间同步”这个嵌入式经典难题。麦克风、IMU、镜头三个传感器采集到的数据如果不打同一套时间戳AI 就无法准确判断“我说这句话的时候到底是不是在走动”——音频说的事情和视觉/动觉数据对不上会直接导致意图理解翻车。这个问题的根源在于每条数据链路都有延迟差麦克风的 DMA 中断到 DSP 处理再到数据打包延迟可能是几毫秒到几十毫秒IMU 数据通过 I2C/SPI 读取延迟相对稳定但要考虑采样抖动如果还有摄像头ISP 处理耗时和帧率因素会让数据产生更大的时间偏差。如果没有一个统一的同步时钟或者时间戳补偿机制这些误差会累积成可感知的错位。我给团队的排查建议是三步走第一步所有传感器数据在驱动层统一打上单调递增的 tick 时间戳不要用“接收时间”冒充“采样时间”第二步用一次已知的物理事件做各传感器的相对延迟标定比如拍手同时记录音频能量和 IMU 震动峰值反复几次取平均值作为固定延迟补偿第三步在应用层对多模态数据做窗口化融合而不是逐帧对齐——允许一个 100 毫秒的时间窗内的语义近似判断这一点对理解自然语言完全够用。4.3 隐私边界常开麦克风是产品设计问题不只是合规问题AI 硬件要发挥价值麦克风就必须常开待命这直接撞上了用户的隐私敏感神经。很多人一听到“设备随时在听”就本能地抗拒——这是产品必须面对的心理门槛而不是简单地用一句“数据不会外传”就能化解的。我见过几种被验证有效的设计思路。第一种是硬件级静音开关物理切断麦克风供电给用户一个“不管怎么设置物理上都听不到”的确定感。第二种是本地优先处理唤醒词、VAD、意图粗判都在端侧完成只有明确判定该上云时才传输音频片段且传输内容经过脱敏和最小化处理。第三种是透明的数据告知——App 里清晰记录每次“设备上云”的时间、原因和传输数据摘要让用户可以回看和撤回。从 SDK 设计角度来看平台层应该默认提供“本地处理优先”的能力并且把“是否上云”做成一个开发者必须显式声明而不是默认开启的权限。很多团队为了做数据分析和优化技能会顺手把所有音频都传回云端——这对产品长期信任度是致命的。在隐私这件事上宁可功能弱一点也不要让用户产生“这是个窃听器”的怀疑。4.4 无屏交互VUI 设计为什么比 GUI 设计难我经常跟做产品的小伙伴说语音用户界面VUI的设计难度是图形用户界面GUI的十倍起步。GUI 的容错率很高——用户可以看到按钮、点击之前有反馈、出错时可以撤销VUI 没有这些退路——用户说出第一句话之前对系统的能力和边界一无所知一旦答非所问整个交互就断了。硬件 Agent 的无屏交互必须遵守三条铁律。第一条是“一句话能说清楚的话不要拆成三句”语音交互不能像 GUI 一样做多级菜单。第二条是“给用户明确的能力预期”开场引导、帮助指令、技能说明都要提前告知边界比如直接告诉用户“你可以问我日程、播报天气、记录灵感但不能帮你发邮件”。第三条是“错误恢复要轻量”答错了要幽默、短促地承认然后提供可选路径不要用一长串道歉打断用户重新开口的节奏。还有一个实战细节硬件设备的语音交互延迟感知比手机更敏感。手机端有屏幕动画来填充等待硬件只有干巴巴的静音等待用户很容易以为是设备坏了。SDK 层面可以考虑加入“buffering 提示音”或“token 级回声”机制在模型还在跑的时候先给一个语气词或环境音降低等待焦虑。4.5 生态冷启动没有开发者硬件 Agent 就是个高级玩具最后一个硬骨头不是技术而是生态。一个硬件 Agent 设备如果没有足够多的技能和场景用户买回去玩两天就会吃灰——这是所有 AI 硬件产品共同的宿命问题。而生态冷启动的核心矛盾是没有用户开发者不愿意来没有开发者用户不愿意留。开源 SDK 是目前被验证过的最高效解法。先靠 SDK 的低门槛吸引一批极客开发者这批人产出第一批技能这些技能可能粗糙但胜在数量多、脑洞大能吸引第一批尝鲜用户用户增多之后更有商业头脑的开发者才会入场做出客服、教育、医疗等垂直领域的深度技能。这个飞轮能不能转起来的起点就是“巨头愿不愿意放下身段把开发门槛打下来”。Muse 开源 SDK 这一步等于主动把左脚迈进了飞轮的起点。另外一个冷启动策略值得借鉴官方提供一批“范例技能”并开源全部代码开发者通过这些例子能快速理解设备和模型之间的数据流。好的范例技能应该刻意展示不同的能力组合而不是把同一个功能的多个变体重复演示——这样才能最大化覆盖开发者的学习需求。5. 拿到开源 SDK 之后从零做一个硬件 Agent 技能的实战路线5.1 场景先行先定技能再定技术边界很多人拿到 SDK 第一反应是“我能做什么”我的建议是反过来——先想清楚“用户在哪一刻会需要这个设备”。硬件 Agent 不是手机里的通用助手它的优势在于“场景专精”。一个通勤路上用户想用的技能和居家陪娃想用的技能对传感器、网络、响应方式的要求完全不同。我做过一个失败案例刚开始做硬件技能时贪心做了一个“全能生活助手”想把日程、天气、备忘、推荐全塞进去。结果技能越做越重、唤醒率极低、用户反馈一片模糊。后来砍到只做“开车场景的安全提醒”识别效果和留存反而上来了。无屏交互最忌讳的就是功能贪多一次只咬一个场景才能让认知负荷最小化。场景确定之后再回头对照 SDK 的能力清单标注哪些功能是平台已经支持的、哪些需要自己调 API 实现、哪些要外接传感器。这个“能力对齐”过程会帮你砍掉大量不切实际的需求。如果当前 SDK 不支持某个核心能力比如外接动作传感器或者获取定位那这个技能就应果断搁置或降级——靠 hack 硬凑出来的功能维护成本和体验风险都太高。5.2 最小闭环五步法一个技能从想法到上手的完整流程基于我在嵌入式项目上跑过多次的经验硬件 Agent 技能的最小闭环可以拆成五个步骤每一步都尽可能一天内完成保持迭代节奏。第一步写意图意图映射表。列出用户在场景里可能说的 10 条代表性语句对应到具体的意图和槽位。比如“帮我定个 7 点闹钟”“明天早上 7 点叫我”“明早七点提醒我开会”三条话都要映射到“定时提醒”意图“时间”槽位要能解析各种自然语言表达。这一步不用代码在表格里把话术写满是后续调模型和写规则的底稿。第二步搭技能骨架。在 SDK 工程里新建一个技能模块注册意图回调把接收到的用户文本原样打日志不接任何模型。这一步验证的是链路是否通设备拾音 → 唤醒 → 语音识别 → 意图分发 → 技能回调。我见过太多团队直接跳到写逻辑结果链路不通还找不到问题出在哪环——先跑通空骨架是最省时间的。第三步接对话逻辑。把上一步的意图映射表转换成流程逻辑对简单意图用规则匹配对复杂意图接云端大模型并加入 few-shot 示例。注意这一步不要一开始就上 LangChain 或复杂的 Agent 框架先用最原始的“if-else 模型对话模板”验证核心决策逻辑等到确认思路可行再重构不迟。第四步做硬件集成测试。把技能真正跑到设备上连续使用 20 次以上观察三类问题唤醒延迟是否可接受、语音识别是否有收音死角、反馈提示音是否足够清晰。这一步最容易发现“工程可行性”问题——比如技能在其他端测试没问题但硬件上因为回声消噪没处理好导致边听边打断。第五步开放给真人试用。找 3-5 个非技术背景的真人用户不教任何话术让他们自由使用并记录行为。重点观察用户第一次使用时会不会说“我不知道它能干嘛”以及在哪一步放弃操作。真人试用的反馈会推翻你一半自认为合理的设计决策这是一个必然会发生且需要坦然接受的过程。5.3 我踩过的三个坑算力误判、延迟幻觉、打断设计第一个坑是算力误判。做端侧意图识别时我一开始高估了板子的推理能力塞了一个稍大的模型进去结果唤醒到响应花了 4 秒体验直接崩掉。后来查资料才发现嵌入式端侧量化后的模型推理耗时和参数量不是线性关系内存带宽和外设瓶颈往往比算力更致命。教训是先跑 basemark 之类的性能测试再定模型裁剪方案不要凭“感觉”选模型。第二个坑是延迟幻觉。早期做“主动提醒”功能的时候数据链路明明是通的但用户总觉得提醒“来得太慢、像马后炮”。排查了半天发现瓶颈不在模型推理而在云端 API 的响应耗时加了 600 毫秒的网络波动再加上设备播报前的文本转语音排队总体延迟到了一次提醒 1.8 秒。后来把“提前预判提醒”逻辑挪到端侧并加了缓存机制延迟才降下来。硬件 Agent 的延迟是一个端到端的问题不是单独优化某一个环节就能解决的。第三个坑是打断设计。语音交互最自然的场景是用户随时会打断设备说话但很多 SDK 默认的打断逻辑很简单——检测到人声就停。这会导致用户在思考时轻咳一声设备就误以为要打断播报戛然而止。后来参考了电话语音机器人的方案把打断判定改为“持续 500ms 以上的有效语音 置信度阈值”同时引入“可打断点”机制——在播报长文本时只在句子边界才允许打断中断恢复而不是任意词中间都能切掉这样才能保证被唤醒后能准确接上断点。5.4 做完第一个技能之后怎么继续滚雪球第一个技能跑通后很多人会陷入一个误区赶紧做第二个、第三个技能。但从我做硬件生态的经验来看这时候更该做的是“打磨数据闭环”。持续收集真实用户使用第一技能时的成功率和失败路径把这些数据清洗后回流到模型微调和意图模板里。工具调用、本地数据存取、通知策略和场景模板这四个方向是最值得做的资本沉淀。比如帮用户把“每周三晚上 7 点提醒我填周报”这样的语句从临时提醒变成周期性模板你说一次它就记住这类工具类技能的用户存留远高于一次性内容型技能。等到前几个技能帮社区跑通了尝试意愿之后再投入精力做外设联动或硬件扩展——那才是硬件 Agent 区别于手机 App 的真正天花板。我自己的规划是先在上面把两三个场景的稳定性打磨到 95% 以上的成功率再开始动扩展接口。最后再分享一个我跟进整个项目的真实感受其实不只是 Muse这套“软件定义硬件 开源 SDK 做生态”的打法今后一年里会出现在更多 AI 硬件项目里。环形耳机、智能胸牌、儿童陪伴机器人、老年照护挂件——每一个垂直场景都值得一个专用形态的 Agent 硬件。这不是硬件厂商无路可走的无奈之举而是 AI 落地物理世界的必然路径。Muse 登顶 App Store 本身不稀奇稀奇的是它让一个“没有屏幕的 AI”站在了“屏幕之王”的舞台上。旧秩序从来没有崩塌得那么轰轰烈烈它只是被一个你随时可以挂在身上的小东西悄悄换了一种存在的方式。下一步真正值得盯的是谁能用这代 SDK 做出让人“回不去手机”的场景。我把话放在这里未来半年这个品类一定会跑出一匹黑马。
阅读完成 · 觉得有帮助？
