corespeechd / corespeechd_system 是什么进程？

最后更新: 2026-08-08

它是什么

corespeechd / corespeechd_system 是 macOS 私有 CoreSpeech 框架中的两个 Apple 系统守护进程。它们不是同一个可执行文件的两种显示方式。corespeechd 跟随当前用户运行；corespeechd_system 则由 launchd 启动，使用专门的 _corespeechd 系统账户。当前 macOS 同时安装了这两个经过 Apple 签名的组件。

从系统文件和二进制信息可以确认，corespeechd / corespeechd_system 参与多项语音工作，包括 Siri 唤醒词检测、说话人识别、语音端点检测、语音配置，以及设备端语音识别模型的协调。语音端点检测用于判断一段话从哪里开始、到哪里结束。仅凭这项职责，不能继续推断录到的内容会如何处理。

Apple 没有公开两个进程之间的完整分工。把它们统称为 CoreSpeech 语音系统的一部分是准确的，但不能进一步断言某个 Siri 请求、某次听写或某个模型下载一定由其中一个进程独立完成。进程处于运行状态也不等于麦克风内容正在上传。它可能只是在等待系统事件、维护语音配置，或者配合其他服务完成工作。

它为什么要联网

已经核实的联网触发类别主要与语音资源有关。corespeechd / corespeechd_system 可以参与订阅、下载或更新 Siri 与听写语音模型、唤醒词模型、说话人识别模型和语音端点模型。检查当前二进制可以确认，它们获准访问相关的 Apple MobileAsset 和 Unified Asset Framework 资源。

所以，即使当时没有人对着 Mac 说话，一次明显的下载也可能来自语音模型首次获取或后续更新。反过来，在使用 Siri 或听写时看到网络活动，也不能只凭发生时间就认定它一定是在下载模型。流量大小和时间只能提供线索，不能直接说明连接内容。

用户主动使用 Siri 或听写时，如果系统设置没有注明当前设备、语言和功能可以完全在设备端处理，Apple 说明语音、转录文本、请求数据和必要的上下文可能会发往 Apple 的 Siri 处理服务。是否需要云端处理，要看具体设备、语言和功能。应以 Siri 设置和键盘设置中显示的说明为准，不能简单概括成“全部上传”或“全部本地处理”。

还有一层容易忽略：Apple 没有公开证明每个 Siri 请求或语音资源下载都由 corespeechd / corespeechd_system 直接建立连接。assistantd、nsurlsessiond、MobileAsset 组件或其他辅助服务都可能承载部分流量。因此，具体远端主机、每条连接的用途，以及最终记到哪个进程名下，都属于未验证信息。不能看到某个域名或另一个进程有流量，就擅自补出一条确定的数据链路。

正常流量应该是多少

目前没有可靠答案。Apple 没有公布 corespeechd / corespeechd_system 的进程级流量基线，也没有给出语音模型通常有多大、多久更新一次，或一天使用多少流量才算正常。这里不能负责任地给出一个具体的 MB 数字。

只能根据已经核实的任务做定性判断。空闲时通常应当没有流量，或者偶尔出现小型状态检查、资源检查。需要云端处理的 Siri 或听写会话会产生交互流量，实际用量会随语音时长和请求变化。首次获取语音模型或更新已有模型时，则可能出现明显更大的突发下载。

一般来说，完整模型下载会远大于一次很短的语音请求。不过，这只是任务类型之间的定性比较。可靠的大小区间、出现频率，以及最终由哪个进程记账，都没有得到验证。排查时可以区分“偶发的大块下载”和“跟随语音操作反复出现的传输”，但不能只看流量曲线就断定传输内容。

能不能关掉

结论是保留 corespeechd / corespeechd_system。Apple 没有提供关闭这两个进程本身的系统设置开关，也没有公布一种可以保证没有副作用的进程级停用方法。

如果确实不用相关功能，可以关闭上层功能，而不是直接处理守护进程：

• 不使用 Siri：打开“Apple 菜单 > 系统设置 > Apple Intelligence 与 Siri”。部分 macOS 版本中，这个面板显示为“Siri”。在这里关闭 Siri。

• 不使用标准听写：打开“Apple 菜单 > 系统设置 > 键盘 > 听写”，然后关闭听写。

• 只想停用语音唤醒：进入 Siri 设置，把“聆听”设为关闭。

关闭��些选项后，相应的 Siri、语音唤醒或标准听写功能会不可用。这是明确可预期的后果。不过，关闭上层功能并不能保证 corespeechd / corespeechd_system 从此永远不再启动。Apple 没有公布它们在所有系统语音功能中的完整职责，其他语音服务仍可能需要调用相关组件。

直接终止、删除或用防火墙封锁 corespeechd / corespeechd_system，没有 Apple 提供的无副作用保证。这样做还可能妨碍语音模型管理或其他系统语音服务。即使平时不用 Siri 和听写，也没有可靠依据把进程级封锁描述成安全操作。

常见的误解

• “corespeechd / corespeechd_system 正在运行或建立了连接，说明 Apple 一直在上传环境声音。” 这个推断不成立。Apple 说明 Siri 唤醒词在设备端检测。进程存在，或者偶尔产生少量流量，都不能证明麦克风声音正在上传。要确认实际发生了什么，还需要更多证据。

• “‘Hey Siri’检测必须联网。” 这种说法不准确。Apple 对现代 Siri 语音触发系统的说明是：唤醒词检测在设备端完成。唤醒之后的请求处理可能需要联网，相关模型也可能需要更新，但这和“检测唤醒词必须联网”不是一回事。

• “所有 Siri 和听写语音都会发送给 Apple。” 这也不是准确结论。是否完全在设备端处理，取决于设备、语言和具体功能。Apple 要求用户查看 Siri 设置和键盘设置中的说明。没有这些条件信息，就不能把所有情况归成同一种数据处理方式。

• “我不用 Siri 和听写，所以可以放心封锁 corespeechd / corespeechd_system，不会影响系统其他部分。” 目前没有可靠依据支持这个承诺。Apple 没有提供进程级关闭开关，也没有公开它们在全部系统语音功能中的职责。封锁之后是否影响模型更新或其他语音服务，不能预先排除。

• “关闭‘改进 Siri 与听写’，Siri 就不会再正常联网。” 这个选项控制的是自愿提供、用于改进和人工审核的样本。它不会阻止正常的云端请求处理，也不会阻止语音资源更新。是否使用云端处理，仍要看设备、语言、功能和设置中的说明。

• “corespeechd_system 是 corespeechd 的可疑副本。” 当前 macOS 本来就会安装这两个 Apple 签名组件。corespeechd 按用户运行；corespeechd_system 由 launchd 使用 _corespeechd 账户运行。Apple 没有公布两者的完整内部边界，但同时看到它们并不异常。

怎么看它到底用了多少

下一步可以查看 Bytetally 的逐进程历史，确认流量何时记到 corespeechd / corespeechd_system 名下、持续多久，以及当时是否使用了 Siri、听写或可能正在更新语音资源。再对照 assistantd、nsurlsessiond 和 MobileAsset 相关服务，因为 Apple 没有保证所有连接都会记在同一个进程下。统计结果能说明实际传输了多少数据，但不能单独证明连接中包含的是语音、文本还是模型。

相关进程

常见问题