macOS 里的 nbagent 是什么进程？

最后更新: 2026-07-31

它是什么

nbagent 是 macOS 自带的用户级后台代理，由 Apple 提供并签名。它属于 Noticeboard 框架。系统内的可执行文件位于 /System/Library/PrivateFrameworks/Noticeboard.framework/Versions/A/Resources/nbagent.app/Contents/MacOS/nbagent，Bundle ID 是 com.apple.nbagent。

这里的 “nb” 指 Noticeboard，不是 NetBIOS。nbagent 会调用 Software Update 框架，轮询 Apple 的 Noticeboard 目录，再按目录内容取得通知资源。这些通知可能涉及系统更新、macOS 升级，也可能是其他 Apple 产品信息。简单说，它管的是一条“目录检查和通知资源更新”的链路。

这件事要和完整的系统更新分开看。nbagent 不是下载整套 macOS 更新包的主要服务，也不负责独自完成更新安装。系统还需要其他 Software Update 服务来检测更新、准备内容并执行安装。因此，看到 nbagent 产生网络活动，并不能据此判断 macOS 正在下载完整更新。

判断它是不是正常系统组件，不能只看进程名。系统自带的 nbagent 应当来自上面的只读系统路径，并带有 Apple 平台签名。如果同名程序出现在别的目录，需要另行核查，不能因为名字一样就把它当成 Apple 的那一份。

它为什么要联网

nbagent 平时不会持续传输大量内容。launchd 大约每 24 小时安排一次维护轮询，让它检查 Noticeboard 目录有没有变化。这是固定触发来源之一，但不是唯一来源。

已有的 Noticeboard 通知发生状态变化时，nbagent 也可能被唤醒。比如通知刚刚送达、用户点开了通知、选择稍后提醒，或者通知被移除。macOS 内部的其他组件还可以通过 XPC 主动要求它执行一次轮询。于是，同一台 Mac 上看到的联网时间未必每天完全相同，也不一定都由定时任务触发。

它连接的对象可以确定到类别：Apple 的软件更新目录服务，以及用来分发相应内容的服务。前者告诉 nbagent 当前有哪些 Noticeboard 内容，后者提供实际需要的通知资源。这类资源服务于通知展示，不能直接等同于完整的 macOS 安装包。

至于具体域名，目前没有一份公开且经过核实的 nbagent 完整主机清单。Apple 的软件更新体系会使用多种服务，但不能把这个体系涉及的所有域名都算到 nbagent 头上。网络监控工具在某台 Mac 上捕捉到的地址，可以说明那次连接去了哪里；它不能自动变成适用于所有机器、所有时间的固定域名表。

正常流量应该是多少

现在没有可靠的数字答案。Apple 没有公布 nbagent 的正常流量范围，也没有公开通知资源通常有多大。现有资料同样缺少足以作为统一标准的测量结果。因此，不能负责任地给它写一个固定的 KB 或 MB 上限。

按照已经核实的职责，它更可能呈现低频、突发的流量形态：平时没有明显传输，到目录轮询或通知状态变化时短暂联网；如果目录要求更新资源，再下载相应内容。由于它处理的是目录和通知资源，正常情况下通常会比完整的 macOS 更新包小得多。但这只是根据职责得出的量级判断，不是 Apple 公布的流量承诺，也不是可以用来机械报警的阈值。

一段时间没有流量并不奇怪。定期维护大约每天一次，其他唤醒又取决于通知事件或系统内部请求。反过来，偶尔出现一次短时传输，也不能证明系统正在下载完整更新。缺少公开范围时，更有意义的做法是比较同一台 Mac 上 nbagent 前后几次活动，而不是拿一个没有依据的通用数字给它定性。

能不能关掉

建议保留 nbagent。Apple 没有提供专门关闭 nbagent 或 Noticeboard 轮询的开关，所以这里不存在可填写的系统设置路径。也不能从其他软件更新选项反推出一个并不存在的 nbagent 独立开关。

第三方防火墙可以阻止它连接网络，但这只是拦截通信，不是由 macOS 正式关闭这项服务。连接被拦后，Noticeboard 目录和通知资源可能无法刷新。直接后果是：你可能收不到某些与系统更新或 macOS 升级有关的提示，其中也可能包含有用信息。

拦截 nbagent 也不能保证所有更新提示都会消失。现代 macOS 的更新检测和通知并不只靠 nbagent，其他 Software Update 服务仍然各自工作。同理，拦住它不等于关闭自动更新，也不会让系统停止其他更新检查。

因此，“拦截绝对安全，只会去掉烦人的广告”没有足够依据。Apple 没有提供这种受支持的关闭方式，而 nbagent 已核实的职责也不只指向推广内容。拦截改变的是其中一条通知链路，却没有提供完整、可靠的更新管理效果。

常见的误解

• “nbagent 负责普通网站的推送通知。” 这不是已经核实的主要职责。本机二进制直接链接 SoftwareUpdate.framework，里面能看到 Noticeboard 目录轮询和通知资源安装相关逻辑。Safari 网站通知属于另一类用途，目前没有证据表明那是 nbagent 的核心工作。

• “nb 是 NetBIOS 的缩写。” 这里的 NB 指 Noticeboard。macOS 中负责 NetBIOS 相关服务的进程叫 netbiosd，两者不是同一个组件，也不承担同一项任务。

• “nbagent 就是下载或安装整个 macOS 更新的进程。” nbagent 处理的是 Noticeboard 目录和通知资源。完整更新还要经过检测、准备、下载与安装等环节，并由其他 Software Update 服务参与。只看到 nbagent 联网，不能据此认定完整更新包正在传输。

• “拦截它绝对安全，只会少看几条广告。” 这个判断说得太满。Apple 没有提供受支持的 nbagent 关闭开关，它处理的通知也可能与系统更新或升级有关。拦截后，相关目录和资源无法刷新，结果可能是漏掉本来有用的提示。

• “拦住 nbagent，就能关掉所有更新提示和自动更新。” nbagent 只是整个更新体系中的一个环节。macOS 的更新检测、通知和自动更新不只依赖它，所以防火墙中的一条拦截规则不能代替完整的系统更新设置。

• “nbagent 是第三方软件，或者它本身就是恶意程序。” 位于 Apple 只读系统框架内、带有 Apple 平台签名的 nbagent 是 macOS 组件。不过，进程名不能单独证明文件身份。如果同名程序来自其他路径，应当检查那一份文件的位置与签名，而不是套用系统组件的结论。

这些误解往往来自把“出现过网络连接”“显示了更新通知”和“负责完整更新”混为一谈。nbagent 的已知边界更具体：它检查 Noticeboard 目录，取得通知资源，并处理相关通知状态。超出这个范围的结论，需要额外证据。

怎么看它到底用了多少

想知道自己这台 Mac 上的实际用量，可以在 Bytetally 的逐进程统计里查看 nbagent 对应的发送量和接收量。观察时间最好覆盖它大约每天一次的维护轮询，再比较每次短时活动。这样得到的是本机实测结果，不需要猜测资源大小或杜撰固定域名。

相关进程

常见问题