在 这个系列的第一篇 里，我写到 Hey Jarvis 来自一个很小的需求：我和老婆晚上睡觉前聊天，遇到想知道的问题时，希望不用拿起手机，直接问一句就能得到答案。
后来我做出了 Pipeline、Realtime 和 Mac App，也处理了 语音交互 与 Mac 产品化 中的一系列问题。
做到这里以后，我反而越来越清楚地看到一个限制：
AI 可以越来越聪明，但如果它没有一个自然、稳定并且值得信任的入口，它仍然只是一个需要被主动打开的应用。
我最初很容易把这个问题归结为一句更情绪化的话：Siri 阻碍了 AI 助手的发展。
现在我觉得，这句话只说对了一半。
Siri 既是助手，也是系统入口 链接到标题
从使用者的角度看，Siri 最特别的能力不一定是回答得有多聪明，而是它已经存在于系统里。
它拥有唤醒词、锁屏入口、麦克风权限、系统界面和设备之间的身份。使用者不需要先找到一个应用，也不需要理解哪个后台进程正在运行。说出一句话，入口就在那里。
第三方 AI 应用即使拥有更好的模型，也很难获得完全相同的位置。
Apple 并非完全关闭第三方能力。通过 App Intents，应用可以把自己的动作和内容以结构化方式提供给 Siri、Apple Intelligence、Spotlight 和 Shortcuts。2026 年的更新还继续增加了长时间后台任务、可取消任务、跨设备实体以及敏感操作确认等能力。Apple 也已经公布新一代 Siri AI，强调个人上下文、屏幕理解、网络知识和跨应用操作。
但这里有一个重要区别：
把应用的能力提供给系统助手
≠
让应用自己成为系统助手
第三方可以把一个动作交给 Siri 调用，却不等于可以拥有自己的系统级唤醒词、在所有状态下持续等待，或者无摩擦地取代默认语音入口。
一个很具体的例子是，Apple 目前确实允许第三方 conversational app 通过 iPhone 侧键启动，但官方的 assistant activation 能力只面向日本，需要专门的 Side Button Access entitlement，并受地区与设备条件限制。
这说明 Apple 不是不知道第三方语音助手需要硬件入口。恰恰相反，这个入口重要到必须被平台单独定义、授权和限制。
这些限制并不都是坏事 链接到标题
如果任何应用都可以注册永久唤醒词、在锁屏时持续占用麦克风、读取屏幕内容并跨应用执行动作，AI 助手可能会变得更方便，系统也会迅速变得难以信任。
使用者需要知道：
- 麦克风什么时候正在工作；
- 哪些声音只在本地处理，哪些被上传；
- 哪个应用正在接收内容；
- 谁可以读取个人数据；
- 哪些动作可以自动执行；
- 付款、发消息或删除内容前是否需要再次确认；
- 一个后台助手失控时怎样立即关闭。
Apple 对权限、后台运行、硬件入口和应用分发的限制，有非常合理的安全、隐私、电池和责任边界。
这些问题也让我理解系统为什么设置这些限制：残留页面会重复播放声音，后台线程可能在退出时重新打开麦克风，睡眠后的界面可能错误地声称仍在监听，诊断日志也可能意外变成对话历史。
所以问题不能简化成“平台开放就是进步，限制就是落后”。
真正的矛盾是：平台需要保护使用者，但当最自然的系统级语音入口主要属于平台自己的助手时，第三方 AI 的创新空间也会由平台的产品路线决定。
Hey Jarvis 真正缺少的不是另一个模型 链接到标题
今天，如果出现一个更聪明、更便宜或者更适合中文的新模型，Hey Jarvis 理论上可以更换模型。
但模型改变不了它仍然运行在一台 Mac 上。
Mac 会被合上，会进入睡眠，会带去公司，也可能离床很远。它首先是一台个人电脑，而不是固定放在房间里的语音设备。为了让 Hey Jarvis 在锁屏后仍然可用，我需要处理电源声明、保留媒体轨道、WKWebView 恢复和系统权限。这些工程可以改善体验，却无法改变设备本来的用途。
这让我逐渐形成一个判断：
语音 AI 真正稀缺的不是生成答案的模型，而是低摩擦、持续存在、同时又可以被使用者信任的入口。
这个入口至少包含四件事：
- 它随时可以被自然地唤醒；
- 它能清楚表示什么时候正在听、什么时候在上传；
- 它拥有足够稳定的输入、输出和网络连接；
- 它的权限属于使用者，而不是被某一个模型永久绑定。
Hey Jarvis 的下一步，不应该只是接入更多模型或者再增加几个工具。继续增加模型和工具，并不能解决入口问题。
近期：先成为一个更完整的 Mac Agent 链接到标题
独立硬件是更远的方向。在此之前，Mac 版本仍有一些很实际的演进空间。
第一步是完成正常的分发能力。现在已经有一个公开可下载的 v0.1.0-internal GitHub Release，但它仍然没有 Developer ID 签名、notarization 和自动更新。未来如果要面向普通使用者，签名、notarization、稳定的 bundle identity、升级和回滚都应该成为正式发布流程。
第二步是降低启动摩擦。Launch at login、明确的后台状态，以及系统更新或崩溃后的可靠恢复，都会让它更接近一个长期存在的助手，而不是一个偶尔手动打开的应用。
第三步是使用 Apple 已经开放的系统入口。Hey Jarvis 可以通过 App Intents 和 Shortcuts 暴露自己的动作，让系统知道它能做什么。这样做不能让它获得一个新的系统唤醒词，却可以减少它与 Mac 其他工作流之间的隔离。
第四步是把工具从演示功能变成个人工作流。天气、时间、汇率和股票证明了工具调用边界，但真正有价值的助手应该能够在获得明确授权后，连接日历、笔记、提醒和我日常使用的服务。
这时，安全模型也需要随之升级：查询可以直接回答，修改操作要明确展示对象，高风险执行应可审计；可逆操作还应支持撤销。
更远的未来：一个属于个人 AI 的硬件入口 链接到标题
如果把 Hey Jarvis 从 Mac 里拿出来，我想做的并不是另一个封闭的智能音箱。
我更愿意把它理解为一个 personal AI peripheral：它为个人 AI 提供耳朵、嘴巴和一条物理可信边界，但不决定使用者必须使用哪个模型或哪一家服务。
这个设备需要的核心能力并不神秘：
- 一组适合房间环境的麦克风和回声消除；
- 本地运行的唤醒词检测；
- 唤醒前不上传的短音频缓冲；
- 与麦克风和联网电路硬件绑定的状态指示；
- 一个能够真正切断麦克风的物理静音开关；
- 稳定的扬声器和全双工对话能力；
- 设备身份、加密通信、安全启动和签名更新；
- 手机或 Mac 上用于配置权限、查看状态和撤销访问的控制平面。
它不一定需要在本地运行最强的模型。
本地设备可以负责唤醒、音频处理、隐私判断和紧急控制；复杂推理可以根据使用者的选择交给 Mac、家庭服务器或者云端模型。模型是可以替换的计算资源，硬件负责的是稳定的感知入口和信任边界。
房间里的硬件
→ 本地唤醒与物理隐私控制
→ 个人 Agent 控制平面
→ 可替换的模型
→ 经过授权的工具与个人数据
这种结构与今天的 Hey Jarvis 并不是完全不同的产品。
当前项目已经把本地唤醒、实时会话、工具、语言行为和隐私日志放在相对独立的边界里。未来真正需要替换的，是依赖 Mac、WKWebView 和桌面睡眠生命周期的音频入口。
硬件不会自动解决信任问题 链接到标题
拥有自己的硬件入口，也意味着承担比 Mac App 更大的责任。
一个放在卧室里的常开麦克风，不能只用一句“我们重视隐私”来获得信任。它必须让使用者能够通过物理状态判断：麦克风是否真的断开，音频是否离开设备，哪一个 Agent 正在响应。
它还需要处理家庭里不止一个人的同意。设备的拥有者有权配置它，不代表房间里的其他人自动同意声音被记录或上传。儿童、访客、共享空间和敏感谈话都需要比个人电脑更严格的边界。
工具能力越强，风险也越高。能够查看日历和打开灯，与能够发消息、购买商品或控制门锁，不应该共享同一层授权。
因此，我设想中的硬件不是一个永远在线、什么都能做的超级 Agent。它应该是一个权限逐层增加、默认能力有限、随时可以被物理关闭的系统。
安全不是为了给 AI 的能力踩刹车，而是让使用者敢于长期把入口留给它。
问题最终不是 Siri 聪不聪明 链接到标题
如果未来 Siri AI 足够聪明，能够理解个人上下文、完成跨应用操作，也许 Hey Jarvis 最初的一部分产品价值会被系统直接覆盖。
这并不意味着这个项目失去了意义。
相反，它帮助我把一个模糊的不满拆成了几个更具体的问题：模型能力、语音体验、系统入口、个人数据、执行权限和硬件信任，并不是同一件事。
Siri 可能会成为一个更好的 AI 助手。Apple 也可能继续向第三方开放更多能力。但只要使用者不能自由选择谁占据最自然的入口、谁管理自己的上下文、谁代表自己执行动作，“个人 AI”就仍然在很大程度上是平台提供给我们的 AI。
我更期待的未来是：
- 入口属于使用者；
- 模型可以替换；
- 记忆可以迁移；
- 工具权限可以查看和撤销；
- 高风险动作需要确认；
- 每一次执行都留下可理解的记录；
- 硬件明确表示它什么时候在听。
Hey Jarvis 的第一个版本，只是我试图在 Mac 里给 AI 找一个入口。
它未来也许不会继续住在 Mac 里，而是拥有一双真正属于个人的耳朵。
Building Hey Jarvis 系列：