我要投稿

AI眼镜未来设想-自然语言交互

发布日期：2025-09-07 11:08:08 浏览次数： 1618

作者：野生PM老杜

微信搜一搜，关注“野生PM老杜”

由于眼镜更靠近用户的眼、口、耳，可以从人类接受信息的源头接触信息，因此目前被任务公认的AI服务入口，各家也都推出对接各自模型或Agent服务的眼镜。

#当前AI服务模式

在使用Glasses半个月的时间里，每天都在调用眼镜上的ai功能进行操作，归拢下来，目前共有以下三个主要特点：

● glasses当前版本语音功能为云端处理，由本地识别唤醒词或者长按触控板触发语音录；

● 所有的请求都发给一个“智能体”，由单个智能体进行意图识别或调用工具；

● 最终反馈有三种类型，带参数打开应用、调整系统参数、文本回复；

上图为app处理用户语音指令的界面，app端会保留历史的用户输入指令，设置功能可以调整所使用的模型；

由于人类语言的信息密度较高，一般需要将自然语言通过NLP任务模型转化为格式化数据，最终才能被程序执行。随着这两年LLM的性能爆炸式提升，目前大多数NLP任务都会使用LLM来去进行处理，通过对系统提示词的调整，让LLM可以适配更多的任务。

上图为乐奇智能体服务的一个极简流程图（预估），真实的流程服务会更为复杂，预计在任务调用之前还会进行用户自然语言改写、扩写，对于回复合规等问题也会有专门的模型服务进行处理；

整个服务流程我简单汇总成流程图（上图），在整个乐奇的服务模式中，预计对于一个任务会有多个LLM模块进行参与，在对接用户输入时，需要先对用户的请求进行意图识别和任务梳理，之后将用户的原始输入信息和意图识别理解的结果一起推到任务模块中。每个任务模块中又有LLM模块来去将用户输入信息进行格式化处理，最终调用程序来去运行。

#当前服务模式问题

虽然没有参与过乐奇智能体的工作，但对于AI应用上此前和宝马的业务朋友一同构思过一个内部实验智能体服务（小宝JOY，内测未发布），该应用服务的主要功能就是将车主的自然语言进行解析，不关可以进行“话疗”，还可以“预约开启车内空调”、“记录便签和待办事项”等日常生活常用的基础服务，实现一个车内&手机端统一的智能体。

上图为车机端的演示原型，与目前特斯拉车机端上云端大模型的思路一致，不过除了“话疗”还可以进行更多应用服务；

上图智能体的手机端（小程序），用户在车内发出的便签、日程、记账、服务预约等信息都会通过云端同步到手机端，未来有机会通过宝马的app写入用户手机系统的日历；

小宝的整个服务使用了类似乐奇的模型调用流程，通过两个多月整体设计和开发迭代，目前感受到的问题主要有三个方面：

● 由一个主“智能体”来去总控用户请求，需要额外增加“意图识别”和“调用路由”路由等额外的服务模块，整体工程量大；

● 由于总控的需求，意图识别的系统提示词会比较复杂，每一次调用需要额外使用大量的token；

● 增加的服务、功能越多，意图识别和调用路由的提示词就越难处理，很容易冲突；

为了更好的说明以上的问题，我将此前设计的小宝的各个模块系统提示词在“扣子”平台搭建了一个简单的工作流环境，用来模拟处理简单用户请求时的模型处理流向。

上图为在扣子平台搭建的智能体工作流，用户输入信息会先通过意图识别进行判别，最终再通过任务模型将信息标准化；

在目前的流程中，输入一个20个字左右的请求，选用最轻量级（最便宜，速度最快）的模型（Doubao-1.5-lite-32k），完成处理后会输出josn格式的数据，整体过程需要消耗1853个token，耗时为5s。

上图单个应用服务独立处理的演示，整个过程没有经过意图识别模块；

如果不经过意图识别这个前期处理过程，整个模型调用的token使用量降为973，因此整个意图识别模块的token处理基本和应用处理相当。由于意图识别模块和后续的任务处理都属于串联服务无法并行处理，很多后面的任务处理还会用到之前模型的整理结果，所以随着功能的复杂模型处理时间会随着token增加同步增加。

上图为意图识别模块的模型配置截图，左侧文字部分为系统提示词，右侧为选用的模型；

单次模型调用消耗900个token，这样的系统提示词还仅仅是处理5个左右的应用（#技能中目前才涉及5个应用服务），如果需要调用的应用更过，或者支持MCP协议等复杂流程，token的消耗量将会成倍的上涨。token的消耗增多，对应的模型计算时间也会增长，随着功能越来越多，最终会让用户觉得服务处理越来越卡顿。

#从“大一统”Agent到AI服务入口平台

根据上面的描述，“大一统”模式的Agent比较适合具体场景的业务流程处理，但是遇到用户未指定具体目的的问询，就要额外耗费资源来去进行意图的判断。对此其实目前很多模型服务企业也意识到了这种模式的问题，因此很多AI产品在使用之前就允许用户去选择使用的目的，从而将用户的需求可以限定到一个具体的agent中处理。

上图之前版本的kimi，在对话前可以直接选择平台上的具体场景agent，这样对话将更具体、更专业；

类比kimi通过“@” 来指定具体功能的做法，Glasses作为一个距离用户语音指令最近的接收设备（全天候，外加麦克风阵列降噪），也可以成为一个用户自然语言的分发平台，可以通过“长按触控板（设备可以是戒指或手环）+头部微转动+松手”的操作模式来将用户的“语音”直接发给具体场景应用。

#自然语言分发演示示例

承接上一篇文章中对于9个视线区的应用组件设置，具体示例图如下：

上图左侧为应用入口在App中的显示位置，右侧显示的是组件全部显示时的示例；

放大9个显示区可以看到，每个区域只能归属于一个组件，这样当用户视线看到组件时也意味着预选中状态；

在用户正视视野下，眼前仅仅显示正视区域的组件，如果用户长按触控板会启动录音，同时视野中会有提示显示。

在录音状态下进行向右微转头，可以在视野中看到“日程待办”的应用组件（组件上显示三角标，表示预选中），此时“松手”，Glasses系统会将这段语音“发射”给“日程待办”应用（也开始先经过ASR转为文本，在调用应用接口）。接受到用户语音输入后，该应用需要进行处理，同时需要返回“好的，这就为您记录日程”这样的快回复文本，再由glasses的TTS转为语音并在眼镜中播放，应用对话过程及处理过程将会在App的“会话详情”页面中完整记录。

在录音状态下进行向右下微转头，可在视野中看到“生活记账”，此时松手后将用户问询信息发送给该应用，应用处理的快回复信息有眼镜播放语音，后续处理可在App查看。

在录音状态下进行向下微转头，可在视野中看到“日常便签”，此时松手后将用户问询信息发送给该应用，应用处理的快回复信息有眼镜播放语音，后续处理可在App查看。

在录音状态下进行向左下微转头，可以视野中看到“用车服务”，此时松手后将用户问询信息发送给该应用，应用可以进行车辆座舱控制或服务预约。

#应用服务闭环演示示例

Glasses是很好的语音输入设备，但是由于显示尺寸小，精细操控困难等原因，因此无法对应用的信息进行复杂的增删改查，此时就需要配合App来为应用提供对于的入口。

原先的AI助手为单一对话窗口，可以优化为“会话”功能，在这个页面用列表卡片的形式展示所有的应用会话。

点击单个会话后，会展示用户的语音输入和应用给出的回复。回复可以是文本模式，也可以是带有菜单、按钮等操作的交互信息格式。

从会话界面可以快速跳转至应用页面，进入具体应用后会将历史输入的信息做更丰富的呈现，同时也可以对具体的信息进行调整或删除操作。

在原“设备”菜单中增加“第三方应用”板块，页面中用列表卡片展示已经“安装”的应用，如果有新信息写入会有徽章提示。

点击应用卡片或从会话详情进入应用后，会显示应用自己的界面信息，可以由应用开发者来去处理具体场景的交互。

#尾声

以上这些应用原型是将此前的小宝的部分服务进行了“移植”，这个过程也解决了我在此前设计agent应用时的困惑，感谢Rokid。

glasses具备作为一个ai应用入口平台的潜质，它将会有机会承载很大的应用生态，因为眼镜本身是全天候佩戴、降噪收音的设备，但是它又不能直接完成特别复杂的操作，此时就有机会引导用户在App中查看处理的结果，这个过程在开发者的视角下就是一个应用距离用户越来越近的引流过程。同时由于操作动作的受限（9个视觉区），让这样的“广告位”会十分稀缺，同类的应用服务如果不在平台上进行应用开发，未来将会丧失近距离贴近用户的机会。