SmartCast 企业智能广播系统：从传统定时播放到钉钉移动端语音广播

在企业园区、车间、办公区、食堂、会议室等场景中，广播系统其实是一个很常见但又容易被忽略的信息化需求。

以前很多企业的广播方式比较传统：
定时音乐靠人工设置，临时通知需要到指定电脑操作，广播范围不够灵活，播放日志也很难追踪。如果企业有多个区域、多个终端、多个管理员，这类问题会更加明显。

基于这些实际需求，我开发了一套企业内部使用的智能广播系统：SmartCast 企业智能广播系统。

它不是单纯的音乐播放器，而是一套集 后台管理、定时播放、分区广播、即时语音、实时语音、文字转语音、点歌申请、播放日志、Agent 终端控制 于一体的企业广播平台。

一、系统整体效果

SmartCast 分为三个主要部分：

1. PC 管理后台
   用于系统管理员和厂区管理员维护广播终端、播放计划、播放列表、用户权限和播放日志。
2. 钉钉移动端
   管理员可以在手机上发起即时语音、实时语音和文字转语音；普通员工可以提交点歌申请并查看审批进度。
3. Windows Agent 广播终端
   部署在连接功放或音箱的电脑上，负责接收服务器任务、拉取播放计划、播放音频并回传状态。

下面是系统后台首页的运营看板，可以快速看到 Agent 在线率、播放趋势、今日计划和系统运行状态。

二、系统架构设计

SmartCast 的整体架构并不复杂，但核心思路是：
服务器统一管理，Agent 主动执行，移动端灵活发起，日志全程追踪。

系统架构如下：

从架构上看，系统主要包含以下几层：

1. 使用入口层

用户入口主要分为 PC 管理后台和钉钉移动端。

PC 后台主要面向管理员，用于完成广播资源、播放计划、终端状态和日志查询等管理工作。

钉钉移动端主要面向两类用户：

管理员可以使用即时语音、实时语音、文件转语音等广播功能；普通员工可以提交点歌申请，查看自己的申请状态和审批结果。

2. 平台核心层

平台核心使用 PHP + MySQL 开发，主要负责后台管理、API 接口、任务调度、权限控制、播放计划匹配和日志记录。

对于实时语音广播，系统增加了 Node.js WebSocket Relay，用来承接手机麦克风音频流，并低延时推送到指定 Agent 终端播放。

3. 数据与资源层

系统使用 MySQL 保存用户、Agent、播放计划、点歌申请、播放日志、语音消息等业务数据。

歌曲、录音文件、文字转语音生成的音频文件统一存放在音频资源库中，由 Agent 根据任务需要拉取播放。

4. 终端执行层

每个广播点部署一个 SmartCast Agent。Agent 负责终端授权、心跳上报、拉取计划、接收语音任务、播放音频、本地缓存和日志回传。

最终由 Agent 所在电脑连接功放、音箱或广播设备，实现车间、办公室、会议室、食堂等区域的广播播放。

三、PC 管理后台

PC 管理后台是 SmartCast 的主要管理入口。

后台采用左侧菜单 + 内容区域的方式，功能比较清晰，主要包括：

• 厂区管理
• 区域管理
• 用户管理
• Agent 终端管理
• 播放列表
• 播放计划
• 即时广播
• 即时语音
• 实时语音
• 文字转语音
• 播放日志
• 点歌申请管理

后台首页不是简单的欢迎页面，而是做成了一个运营看板，方便管理员快速判断系统是否正常。

看板中重点展示了 Agent 在线率、今日计划数量、播放日志数量、最近 7 天播放趋势，以及 Agent 当前状态。

这样做的好处是，管理员进入系统后不用逐个页面排查，就能先知道广播终端是否在线、播放计划是否正常、最近有没有播放异常。

四、Agent 终端管理

SmartCast 不是直接依赖浏览器播放，而是在每个广播点部署一个 Windows Agent。

后台可以统一管理所有 Agent，包括 Agent 名称、所属厂区、所属区域、运行状态、播放状态、版本、最后心跳时间和授权状态。

Agent 管理页面解决了几个关键问题：

第一，可以知道哪些广播终端在线，哪些终端离线。

第二，可以知道 Agent 是否已经授权激活。

第三，可以按厂区、区域、状态进行筛选。

第四，后续排查播放问题时，可以根据心跳和播放日志快速定位到具体终端。

五、Windows Agent 客户端

这是 SmartCast 的终端执行程序，运行在 Windows 广播电脑上。

Agent 客户端主要负责以下工作：

• 自动运行
• 开机自启
• 终端激活
• 定时心跳
• 查询播放计划
• 接收即时语音
• 接收实时语音
• 执行音频播放
• 播放状态回传
• 本地音频缓存

Agent 采用主动请求服务器的方式，不需要服务器直接控制客户端电脑。这样做对企业内网环境比较友好，也更容易穿透复杂网络环境。

当服务器上有播放计划或语音任务时，Agent 会按规则拉取任务并执行播放；播放完成后再把结果回传到服务器日志中。

六、播放列表与歌曲管理

广播系统离不开音频资源管理。

SmartCast 支持在后台维护播放列表和歌曲资源。管理员可以上传歌曲、调整排序、启用或停用歌曲，并可以在页面中试听。

在实际企业场景中，播放列表一般会分成不同用途：

• 上班铃声
• 下班铃声
• 工间音乐
• 午休音乐
• 通知音频
• 临时广播音频

这样管理员在创建播放计划时，只需要选择对应的播放列表即可。

七、播放计划管理

播放计划是 SmartCast 的核心功能之一。

管理员可以配置不同时间、不同区域、不同播放列表和不同播放模式。

一个播放计划通常包含这些信息：

• 计划名称
• 所属厂区
• 所属区域
• 指定 Agent
• 开始时间
• 播放时长
• 生效星期
• 播放列表
• 播放模式
• 优先级
• 启用状态

比如，早上可以播放上班铃声，上午和下午可以播放工间音乐，中午可以播放上下班提示音。

系统会根据当前服务器时间匹配有效计划，再由 Agent 拉取当前应该执行的播放任务。

八、即时语音广播

除了定时播放，企业广播中经常会有临时通知需求。

例如：
临时会议通知、车辆挪车通知、生产异常提醒、访客提醒、紧急通知等。

SmartCast 支持即时语音广播，管理员可以在 PC 后台或钉钉移动端录制语音，然后下发到指定厂区、区域或 Agent 播放。

PC 端即时语音页面如下：

钉钉移动端即时语音页面如下：

即时语音的流程大致是：

管理员选择播放范围，录制或上传语音，系统生成语音任务，下发给在线 Agent，Agent 收到任务后立即播放，并回传播放日志。

相比传统方式，这样不需要管理员跑到广播电脑前操作，手机上就能完成临时通知。

九、实时语音广播

即时语音适合“先录制，再播放”的场景。

但有些场景需要类似对讲或实时喊话，比如现场临时指挥、紧急通知、测试音响等。

因此 SmartCast 增加了实时语音广播功能。

实时语音的核心链路是：

手机麦克风采集声音，通过 WebSocket 推送到 Relay 服务，再由 Relay 推送给指定 Agent，Agent 进行实时播放。

这个功能相当于把手机变成了一个移动麦克风。管理员不需要坐在电脑前，只要在钉钉移动端打开实时语音，就可以向指定区域或终端进行实时广播。

十、钉钉移动端工作台

为了方便移动办公，SmartCast 接入了钉钉移动端。

不同权限的用户看到的功能是不一样的。

管理员进入后，可以看到即时语音、实时语音、文件转语音等功能。

普通员工进入后，只能看到点歌申请和我的申请。

这样做的好处是：

管理员负责广播管理和语音通知，普通员工只负责提交申请，不会接触到后台管理功能，权限边界比较清楚。

十一、点歌申请与审批思路

企业广播中还有一个比较实际的需求：员工点歌。

如果完全开放点歌，容易影响正常生产秩序；如果完全不开放，又少了一些企业文化氛围。

所以 SmartCast 的设计思路是：
普通员工可以通过钉钉提交点歌申请，申请经过审批或管理员处理后，再进入播放计划或播放任务。

这样既保留了员工参与感，又不会让广播内容失控。

点歌申请后续可以结合钉钉审批流，实现更完整的流程闭环。

十二、播放日志与可追溯性

对于企业系统来说，日志非常重要。

SmartCast 对播放行为进行了日志记录，包括播放时间、播放类型、播放终端、播放内容、播放状态、开始时间、结束时间和说明信息。

日志的价值主要体现在几个方面：

第一，可以确认某个广播是否真的播放过。

第二，可以追踪播放失败、终端离线、计划结束等情况。

第三，可以为后续统计分析提供数据基础。

第四，如果有多个管理员使用系统，也可以追踪操作来源。

对于企业内部系统来说，“能播放”只是第一步，“能追踪、能排查、能审计”才是真正稳定可用的基础。

十三、开发过程中的一些设计取舍

SmartCast 在开发过程中做了一些比较实际的设计取舍。

1. 服务器负责统一调度

播放计划、播放列表、权限控制和日志都放在服务器端统一管理。

这样可以避免每台广播电脑单独配置，后期维护成本更低。

2. Agent 主动拉取任务

Agent 采用主动请求服务器的方式，而不是服务器直接远程控制 Agent。

这种方式更适合企业内网环境，也能减少防火墙、权限和网络隔离带来的问题。

3. 播放以服务器时间为准

定时播放最怕每台终端时间不一致。

因此系统设计时以服务器时间作为播放基准，Agent 根据服务器返回的计划和剩余时间执行播放。

4. 移动端重点做高频操作

PC 后台适合做复杂管理，移动端适合做高频操作。

所以钉钉端重点放在即时语音、实时语音、文字转语音和点歌申请，不把所有后台功能都搬到手机上。

5. 日志从一开始就纳入设计

很多系统前期只关注功能，后期出了问题才补日志。

SmartCast 在播放计划、语音广播、Agent 心跳和播放结果上都保留了日志，为后续排查问题提供基础。

十四、技术栈

目前 SmartCast 使用的主要技术包括：

这套技术栈并不追求复杂，而是偏向企业内部系统常用、稳定、可维护的方案。

十五、总结

SmartCast 的开发初衷很简单：
让企业广播从人工操作、单机管理、无法追踪，逐步变成统一管理、移动操作、自动播放、日志可查的系统化平台。

从实际使用角度看，它解决了几个核心问题：

• 定时广播不用人工守着电脑
• 多区域广播可以统一管理
• 管理员可以在钉钉上发起语音通知
• 普通员工可以提交点歌申请
• Agent 状态和播放结果可以追踪
• 播放计划、音频资源和日志都集中管理

对于企业 IT 来说，自研这类系统的价值不只是节省软件采购费用，更重要的是可以根据企业自己的流程不断调整和扩展。

SmartCast 目前仍在持续完善中。后续我会继续优化 Agent 稳定性、语音广播体验、播放日志统计和钉钉审批流程，让它更贴近企业真实使用场景。