Ami 案例拆解：用 Foundry Local 在安卓手机上跑通语音问答

把语音问答留在手机里

Ami 案例的架构取舍与开发者启示

文章讨论的问题

作者想对手机说一句“这周我的心率什么时候最高”，直接听到基于本机记录的回答，而不是打开应用、选日期、读图表。他为此做了一个名为 Ami 的安卓应用，并把过程写成了教程。演示数据是虚构的可穿戴设备记录，复现时不需要手表或健康账号。

关键做法

来源文章描述的流程分四步：点按说话，在手机上用 Whisper Tiny 转写，查询本地记录并计算，再用安卓自带的离线语音朗读答案。Foundry Local 提供的 Kotlin API 负责查找、下载、加载模型，以及调用转写和聊天接口，所以开发者不必先自建模型服务层。

文中说明安卓端有两种部署方式：IPC 模式连接单独安装的服务应用，嵌入模式把运行时打包进自己的应用。Ami 使用的是 IPC 模式。

我认为最值得借鉴的是职责划分。日期解析和最大值计算交给普通 Kotlin 代码，而不是让语言模型做算术。这样日期边界、缺失数据和计算结果都可以写成常规单元测试。

另一个设计是可选的“每周回顾”。应用先算好事实卡片，再让小型 Qwen 模型只挑选要展示哪几张。应用只接受格式合法的选择，并输出原先算好的文字，格式不对就回退到纯计算结果。这个思路把模型的责任压得很小，也容易验证。

交互细节

文章强调，转写结果应当可见、可修改。个人记录问答里，识别错一个日期就可能改变答案。回答里还会带上数据覆盖范围：示例里最高心率只来自当月 31 天中的一天，因此要明确这一限定。语音播放的停止、重听和打断控制，也被作者视为体验的重要部分。

适用场景与对开发者的影响

作者提到，日记应用查找已保存的感想，或学习应用回答近期练习情况，都可以沿用同样的转写、播放和 Foundry Local 配置，只需替换记录与回答逻辑。对关注隐私的移动端开发者，这是一个可参考的结构：模型负责语音与有限的选择任务，确定性代码负责事实与数值。

文中也限定了“本地”的含义。模型首次获取仍需要联网，离线语音需要提前安装，所以这只说明问题的处理方式，并不等于应用完全不使用网络。

仍待观察

示例使用英文提问和虚构数据。真实可穿戴数据、其他语言和嘈杂环境下的表现，文章没有给出结论。（作者观察）

两个模型合计约 953 MB 的下载量，对低端机型和流量受限用户是否合适，需要实测。（推测）

作者说更灵活的对话是后续实验，当前小模型尚不具备。

文中的 SDK 版本固定为 0.1.6，后续接口可能变化。

来源

原文：Microsoft Foundry Blog《Building an On-Device Voice Companion with Foundry Local》，https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/building-an-on-device-voice-companion-with-foundry-local/4563553 。图片版权归原权利人。