[{"data":1,"prerenderedAt":21},["ShallowReactive",2],{"$fPAgxYBZk0V3gebLG61Ma_4XwxAluBJafzqQw-1BrTEQ":3},{"slug":4,"sourceSlug":5,"title":6,"description":7,"date":8,"cover":9,"tags":10,"column":19,"html":20},"260608","260608-高考零容错实时系统","不允许失败的实时系统，到底难在哪几层？——从高考的工程视角，看企业级实时音视频选型","给要做在线考试、远程庭审、远程会诊、应急指挥这类'不能出错'实时音视频系统的技术决策者：高考这套零容错巨型系统，把企业级 RTC 真正的工程约束放大了出来。","2026-06-08","\u002Finsights\u002F260608\u002Fcover.png",[11,12,13,14,15,16,17,18],"实时音视频","RTC","私有化部署","弱网对抗","高并发","信创","在线考试","远程庭审","技术解析","\u003Cp>每年六月初的那两三天，有一套系统会被推到它的极限：千万级用户在同一时刻、同一时段、跨越所有网络环境同时在线，而它的容错率几乎是零——任何一个环节出问题，代价都无法用"重启一下"来挽回。\u003C\u002Fp>\n\u003Cp>它不是某个互联网大厂的春晚红包系统，而是高考。\u003C\u002Fp>\n\u003Cp>2026 年高考，全国共设 34.8 万个考场，多地启用了 AI 智能巡查系统：摄像头实时回传画面，AI 识别考生与监考员的异常行为，自动截取异常前后的录像供审核员复核 [1][2][3]。这套系统平时没人讨论，因为它"不出事"就是最好的状态。但恰恰是这种"必须不出事"的工程目标，把实时音视频系统里最难的几层约束，集中暴露了出来。\u003C\u002Fp>\n\u003Cp>如果你正在为\u003Cstrong>在线考试、远程庭审、远程会诊、应急指挥、远程监盘\u003C\u002Fstrong>这类场景做技术选型，高考这套系统是一个很好的参照物——它要解决的问题，和你要解决的问题，本质同构，只是规模放大了一万倍。\u003C\u002Fp>\n\u003Ch2>一、为什么"实时 + 不能失败"现在成了一道选型题\u003C\u002Fh2>\n\u003Cp>过去十年，企业里的视频能力大多停留在"开个会、连个线"的层面，能用就行，偶尔卡顿大家也忍了。\u003C\u002Fp>\n\u003Cp>但有一类场景的要求完全不同：它们把音视频从"沟通工具"变成了"业务流程本身"。在线考试里，画面回传断了，这场考试的公平性就出问题；远程庭审里，音视频中断，庭审记录就有瑕疵；远程会诊里，影像延迟或失真，可能直接影响判断。在这些场景里，音视频不再是锦上添花，而是业务能不能成立的前提。\u003C\u002Fp>\n\u003Cp>与此同时，AI 的引入把要求又抬高了一层。AI 巡查、AI 质检、AI 实时对话，都需要把音视频流稳定、低延迟地喂给模型——这意味着系统不仅要"传得到人",还要"传得进模型"。值得一提的是，"AI 阅卷"今年一度被误读成"AI 直接给你打分"，但事实上 AI 在其中只做答案的初步分类和答题步骤匹配，给老师提供基础参考 [4]。这恰恰说明一个工程常识：\u003Cstrong>在高可靠场景里，AI 是辅助决策的一环，它依赖的底座，仍然是那条必须稳定的实时数据通道。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>二、"零容错"到底意味着哪几个工程约束\u003C\u002Fh2>\n\u003Cp>"不能失败"这四个字，拆开看是四个具体的、可量化的工程约束。决策时绕不开它们：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>高并发\u003C\u002Fstrong>：不是平均并发，而是"同一时刻"的峰值并发。高考是千万人同时落座；企业场景里可能是上万考生同时开考、几百个庭审同时进行。系统是按峰值设计还是按平均设计，决定了它会不会在最关键的时刻崩掉。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>低延迟\u003C\u002Fstrong>：实时的意义在于"此刻"。端到端延迟一旦超过几百毫秒，对话会"打架"，AI 识别会滞后，监考画面会失去取证价值。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>弱网对抗\u003C\u002Fstrong>：真实环境里没有理想网络。考点可能在县城、在山区，企业终端可能在车间、在电梯、在移动 4G 下。系统必须在丢包、抖动、带宽受限的情况下，依然把画面和声音稳住。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>数据合规与私有化\u003C\u002Fstrong>：考试、司法、医疗、政务这些场景的数据高度敏感，往往要求数据不出内网、满足信创国产化要求。这不是"加个功能"，而是从架构底层就要定下来的约束。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这四条里，任何一条没做扎实，系统都会在"最不该出问题的时刻"出问题。\u003C\u002Fp>\n\u003Ch2>三、企业自己做，最容易在哪三处栽跟头\u003C\u002Fh2>\n\u003Cp>这正是大多数团队的"至暗时刻"：一个实时音视频 demo，在办公室的 Wi-Fi 下、几个人测试时，跑得非常漂亮；一旦上了真实规模和真实网络，问题集中暴露在三个地方。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第一处：把"能连通"当成"能扛住"。\u003C\u002Fstrong> 用开源 SDK 或公有云 API 快速搭一个 demo，几个人通话毫无问题。但并发从几十涨到几千时，信令风暴、媒体服务器调度、转发节点扩缩容这些底层问题才浮现——而这些恰恰是 demo 阶段看不见的。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第二处：在弱网上"想当然"。\u003C\u002Fstrong> 理想网络下一切正常，真实环境里 20%、30% 的丢包随处可见。没有专门的抗丢包、抗抖动策略，画面就会花、声音就会断。弱网对抗不是调几个参数，而是一整套需要长期打磨的工程能力。\u003C\u002Fp>\n\u003Cp>\u003Cstrong>第三处：合规与私有化"留到最后才想"。\u003C\u002Fstrong> 先用公有云把功能做出来，等到客户提出"数据必须留在内网""必须信创适配"时，才发现整个架构是绑定公有云的，等于推倒重来。对司法、医疗、政务、考试这类场景，私有化和信创应该是选型的\u003Cstrong>第一个约束\u003C\u002Fstrong>，而不是最后一个补丁。\u003C\u002Fp>\n\u003Ch2>四、支撑"不能失败"的场景，技术上要分清哪几层\u003C\u002Fh2>\n\u003Cp>把上面的约束翻译成技术选型，关键是分清你买的、用的、自研的，到底落在哪一层。下面这张表，是评估这类实时音视频方案时绕不开的几个维度：\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>维度\u003C\u002Fth>\n\u003Cth>公有云 RTC\u003C\u002Fth>\n\u003Cth>通用开源 RTC\u003C\u002Fth>\n\u003Cth>私有化实时音视频引擎\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>数据是否出内网\u003C\u002Ftd>\n\u003Ctd>通常出公网\u003C\u002Ftd>\n\u003Ctd>看自建程度\u003C\u002Ftd>\n\u003Ctd>可全程内网，数据不出域\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>信创\u002F国产化适配\u003C\u002Ftd>\n\u003Ctd>一般不支持\u003C\u002Ftd>\n\u003Ctd>需自行改造\u003C\u002Ftd>\n\u003Ctd>可适配国产 CPU\u002FOS\u002F芯片\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>弱网对抗\u003C\u002Ftd>\n\u003Ctd>厂商黑盒，难定制\u003C\u002Ftd>\n\u003Ctd>需自研打磨\u003C\u002Ftd>\n\u003Ctd>可按场景深度调优\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>峰值并发保障\u003C\u002Ftd>\n\u003Ctd>按量付费，成本随规模上升\u003C\u002Ftd>\n\u003Ctd>需自建调度与扩容\u003C\u002Ftd>\n\u003Ctd>可按峰值规划私有集群\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>传统设备接入\u003C\u002Ftd>\n\u003Ctd>多不支持\u003C\u002Ftd>\n\u003Ctd>需自行对接\u003C\u002Ftd>\n\u003Ctd>可融合 SIP\u002FH.323\u002FGB28181\u002FRTSP 利旧设备\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>长期成本\u003C\u002Ftd>\n\u003Ctd>规模越大越贵\u003C\u002Ftd>\n\u003Ctd>隐性人力成本高\u003C\u002Ftd>\n\u003Ctd>一次性授权 + 自主运维\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cblockquote>\n\u003Cp>注：上表为方案类型的客观特性对比，具体能力以各厂商实际版本与项目评估为准。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>没有哪一栏是绝对的"对"或"错"，关键看你的约束落在哪。数据敏感、要信创、要长期可控 → 私有化方向；轻量、临时、数据不敏感 → 公有云够用；有强工程团队且愿意长期投入 → 开源自建也是一条路。\u003C\u002Fp>\n\u003Ch2>五、把这套能力做扎实，需要哪几层工程积累\u003C\u002Fh2>\n\u003Cp>讲到这里，自然要回答一个问题：要支撑"不能失败"的实时场景，一套实时音视频引擎需要哪几层能力？这也是我们做 STMLink \u002F SRTC 这套私有化实时音视频通信引擎时，长期在打磨的几层：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>底层媒体引擎（SRTC SDK）\u003C\u002Fstrong>：抗弱网、低延迟编解码、GPU 编解码、4K 与云录制，覆盖 PC\u002FMac\u002FiOS\u002F安卓 + 服务端 Python\u002FGo\u002FC SDK。弱网 30% 丢包不卡顿、端到端低延迟，是这一层要守住的指标。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>私有化与信创底座\u003C\u002Fstrong>：全程数据不出内网，可适配国产 CPU、操作系统与芯片，满足司法、医疗、政务、考试这类场景的合规要求。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>传统设备融合\u003C\u002Fstrong>：把已有的 SIP \u002F H.323 \u002F GB28181 \u002F RTSP 设备利旧接入现代音视频系统，避免推倒重来。\u003C\u002Fli>\n\u003Cli>\u003Cstrong>AI 实时对话层\u003C\u002Fstrong>：把稳定的音视频流接入大模型，支撑 AI 客服、AI 面试、AI 问诊、数字人这类实时交互——这正是 2026 年我们投入开源 srtc-ai-agents 框架想解决的方向。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>这些能力支撑了 100+ 政企客户、2000+ 并发、50000+ 研讨会场景，转写准确率 92%+（具体指标需按实际并发量与场景评估）。\u003C\u002Fp>\n\u003Ch2>六、什么情况下该认真考虑私有化实时音视频\u003C\u002Fh2>\n\u003Cp>给一个可以对号入座的判断：\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>数据敏感 + 要求不出内网 + 信创适配\u003C\u002Fstrong>（司法、医疗、政务、考试、金融）→ 优先私有化方向，且把它作为选型的第一约束；\u003C\u002Fli>\n\u003Cli>\u003Cstrong>峰值并发高、容错要求严\u003C\u002Fstrong>（在线考试、应急指挥、大型远程协作）→ 重点考察峰值并发保障和弱网对抗，别被 demo 的流畅度迷惑；\u003C\u002Fli>\n\u003Cli>\u003Cstrong>有大量传统视频设备要利旧\u003C\u002Fstrong>（已建监控、会议室终端）→ 重点看设备融合能力，避免重复建设；\u003C\u002Fli>\n\u003Cli>\u003Cstrong>要在音视频上叠加 AI 能力\u003C\u002Fstrong>（实时质检、AI 对话、智能巡查）→ 关注音视频流到模型这一条链路是否稳定、低延迟。\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>高考这套系统给企业的启示，其实不在于"高考用了什么黑科技"，而在于它把一个朴素的工程道理放大到了极致：\u003Cstrong>真正决定一套实时系统行不行的，不是它在演示里多流畅，而是它在最不该失败的时刻扛不扛得住。\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Chr>\n\u003Cp>如果你正在评估在线考试、远程庭审、远程会诊、应急指挥这类高可靠实时音视频场景，可以搜索 \u003Cstrong>STMLink\u003C\u002Fstrong> 了解私有化实时音视频方案，或查阅 SRTC 技术文档与 GitHub 示例，获取私有化部署与信创适配的评估清单。\u003C\u002Fp>\n\u003Ch2>资料来源\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>[1] \u003Ca href=\"https:\u002F\u002Fwww.jiemian.com\u002Farticle\u002F14547009.html\" target=\"_blank\" rel=\"noopener\">2026年高考今日开考：全国共设34.8万个考场，新增AI监考严防作弊（界面新闻，2026-06-07）\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>[2] \u003Ca href=\"https:\u002F\u002Fwww.ithome.com\u002F0\u002F961\u002F006.htm\" target=\"_blank\" rel=\"noopener\">2026 年全国高考今日开考，多地启用 AI 智能巡查系统严防作弊（IT之家，2026-06-07）\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>[3] \u003Ca href=\"https:\u002F\u002Fwww.163.com\u002Fdy\u002Farticle\u002FKUPELKVT051494GR.html\" target=\"_blank\" rel=\"noopener\">高考新增AI监考：识别异常行为后自动截取录像供复核（网易，2026-06）\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>[4] 2026高考"AI阅卷"被误读：AI 仅做答案初步分类与步骤匹配，非直接打分（多家媒体 2026-05-30 报道，原始权威出处待核实，引用时建议进一步核对教育考试院口径）\u003C\u002Fli>\n\u003C\u002Ful>\n",1790479584884]