用 Expo 为移动应用接入端侧 AI

React Native 应用想接 AI，不一定要先搭后端、保管 API key，再把用户输入传到云端。expo-ai-kit 提供了另一条路径：让 Expo 应用直接在设备上运行大语言模型、语音转文字、视觉处理和嵌入计算。

作者主张用统一的 TypeScript API 封装 iOS、Android 的原生能力，并按需编译功能。对希望支持离线、减少数据外传的移动端项目，这个方向有吸引力。不过，提供的原文在构建说明处就截断了，尚不足以证明标题里的「完全本地 Agent」已经如何落地。

一套 TypeScript 接口，底下仍是两套平台能力

expo-ai-kit 面向 Expo 应用，也支持已经安装 Expo modules 的 React Native 应用。它试图把不同平台的 AI 能力收进同一套 TypeScript API，让业务代码减少直接对接原生框架的工作。

原文列出的底层技术包括：

• iOS 使用 Apple Foundation Models、Speech 和 Vision。
• Android 使用 ML Kit 和 MediaPipe。
• LiteRT-LM 支持运行可下载的模型，例如 Gemma、Qwen 和 Phi。

这些能力覆盖本地 LLM、语音转文字、视觉处理和嵌入计算。嵌入计算可以理解为把内容转换成便于计算相似度的向量，但原文没有继续说明具体接口和使用方式。

统一接口能减少接入差异，却不能直接证明两个平台的能力和效果一致。

作者没有给出系统版本要求、支持的设备范围、模型规格，也没有展示跨平台输出对照。选型时，不能只看到「一套 API」就默认所有目标设备都能获得相同体验。

按需编译，比安装一个包多了一步

安装命令很直接：

npx expo install expo-ai-kit

要注意，这一行只完成安装。原文要求接着在应用配置中启用需要的功能，再进行原生构建，因此不能把安装成功当成已经可以调用 AI 能力。

作者强调，所有功能都需要主动开启。某项功能未开启时，对应原生代码不会编译进应用；未使用的模型和权限也不会随应用交付。此外，运行时 JavaScript 依赖为零。

这里解决的是移动端集成的实际问题：如果只需要语音转文字，就不该顺带承担其他 AI 功能的交付负担。

不过，原文没有给出配置字段、启用示例和原生构建命令，也没有提供开启功能前后的包体对比。「运行时 JavaScript 依赖为零」描述的是依赖情况，不能据此判断模型、原生代码或内存占用有多小。

本地推理省掉了什么，又有哪些空白

作者承诺推理在设备上完成，提示词、音频和图片不会离开设备，因此可以离线使用，也不需要 API key、云端资源、请求计量或代理服务。

这条逻辑是成立的：如果推理确实全部在本地完成，就不需要为每次推理调用云端接口付费。但「没有按请求费用」不等于没有工程成本。模型如何下载和更新、设备是否装得下、运行是否足够快，提供的内容都没说清。

同样，标题里的「Fully Local Agents」需要单独打个问号。本地运行 LLM 只是其中一环；工具调用、任务循环和状态管理如何实现，原文片段没有展示。不能仅凭标题，就把它理解成已经提供完整的本地 Agent 开发方案。

我的判断

我更认可它的集成方向：用 TypeScript 统一入口，再通过功能开关控制原生代码、模型和权限，确实贴近 React Native 开发者的工作方式。

但这段内容更像产品能力说明，没有设备实测、延迟、识别准确率、内存或耗电数据，也没有与云端方案的对照。隐私和离线是它主张的优势，实际可用性仍要验证。

和直接接云端 API 相比，它减少了推理数据上传与服务端接入环节，同时把模型交付和设备适配问题带到了客户端。和分别接入原生框架相比，它有望减少业务层的平台分支，但封装覆盖到哪里、差异如何暴露，原文还没有回答。

能拿来做什么

• 如果正在做 Expo 或 React Native 离线功能，可以先选语音转文字、视觉处理中的一项验证，并完成一次原生构建，确认完整接入路径。
• 按产品实际需求开启功能，检查最终包体、模型文件和权限声明，验证按需交付是否符合预期。
• 如果计划使用 Gemma、Qwen 或 Phi，先在目标用户的真实设备上测试加载时间、响应速度和资源占用，再决定是否替代云端推理。
• 如果目标是本地 Agent，先确认工具调用和任务执行机制是否已有支持，不要把本地模型接入完成当成 Agent 已经完成。