搞运维的人应该都有过这种经历：设备在现场报警，值班员在电话里跟我反复描述“那个红灯一直闪，风扇声特别大”，我在几百公里外对着手册连猜带蒙，最后还得买张票飞过去。后来我们做了一套“实时音视频 + AI Agent”的远程运维系统，情况才真正扭转过来。现场人员戴上摄像头或者打开手机端，专家在电脑上就能看到第一视角画面、听到设备运转的环境音，还能直接在画面上画线标注；AI Agent在后台实时转写对话、识别声音异常、结合设备日志去知识库里检索故障案例，把排查建议和处置步骤推给专家，最后自动生成工单和巡检报告。

这篇内容把我从需求拆解、架构设计到落地实现的全过程整理出来，包括音视频链路的选型逻辑、Agent 服务的编排方式、上线之后遇到的各种问题，以及一份可以直接参考的最小可运行方案。适合设备制造商、集成商、工厂设备部门，也适合想用 AI 改造售后运维流程的团队。不管你是只想知道原理，还是打算自己动手搭一套，这篇应该都能给你省不少弯路。

1. 先聊清楚：传统远程运维卡在哪，AI Agent 补什么位

1.1 传统远程支持的三座大山

第一座大山是“描述失真”。电话里说一百句“我看到了”，不如让对方把镜头转到设备正前方看一眼。可现实是，现场人员往往不知道专家需要什么视角，专家想要的角度他给不到，你想要看仪表读数，他给你拍个指示灯。这倒不是现场人员不专业，而是“描述”这件事天然有信息损耗，尤其涉及异响、振动、气味这类很难用语言量化的问题时，电话支持基本只能靠猜。

第二座大山是“知识都装在老师傅脑子里”。故障处理经验往往散落在几个核心老师傅的脑子里，没有形成可检索的知识库。新人遇到设备异常，翻手册翻不到，问人又不在，最后要么等老师傅到场，要么按最笨的办法重启一遍。公司花了很多年积累的售后案例，全是聊天记录里的只言片语，真正要用的时候找不着、也留不住。

第三座大山是“事后无记录无沉淀”。远程支持打完电话就结束了，现场是什么状态、说了哪些排查步骤、最后怎么解决的，全部没有留痕。等到半年后同类故障再次发生，还得重新诊断一遍。哪怕天天在处理问题，知识体系仍然在原地踏步。这三个问题叠加在一起，就造成了运维成本高、响应慢、还特别依赖个别关键人物。

1.2 这套系统真正改变的是“协作闭环”

我们设计系统时，没有把它简单做成“能打电话的摄像头”，而是把远程运维看成一条完整的协作链路：感知、传递、诊断、指导、沉淀、再学习。

感知层解决“看见和听见”的问题。现场端的摄像头、麦克风把画面和声音采集上来，同时设备自身的运行数据，比如温度、转速、电流、故障码，也一并接入。传递层解决“信息无损到达专家”的问题。通过实时音视频链路，专家端看到画面、听到声音，还能收到设备数据流，而不是只能听别人转述。诊断层是 AI Agent 的舞台。它持续监听音视频流里的对话和环境声，对照设备数据，在知识库里检索相似案例，给出故障可能性和处置建议。指导层把 AI 建议和专家判断合在一起，通过语音、文字、AR 标注反馈给现场人员。沉淀层把整个过程中产生的音视频片段、转写文本、诊断结论、工单信息自动归档，形成可检索的案例库。

最后还有一层“再学习”。每处理完一个故障，系统可以把“现象—诊断—处置—结果”回写进知识库。下次再遇到类似问题，Agent 查到的就不再是干巴巴的文档，而是包含真实处理过程的完整案例。这样整条链路就形成了一个闭环，而不是七个孤立的功能模块。

1.3 LLM、Agent、AI 模型到底什么关系，DeepSeek 是哪一个

很多朋友在聊 AI Agent 的时候，会把模型和 Agent 混在一起。这里我按自己的理解梳理一下。

AI 模型是“能处理单一任务的能力单元”。比如语音识别模型负责把音频转成文字，图像分类模型负责判断画面里有没有异常，大语言模型负责理解和生成自然语言。DeepSeek 属于大语言模型，它接收文本输入，生成文本输出，本质上是模型，还不是 Agent。你可以把 DeepSeek 当成 Agent 的“大脑组件”，但它单独不会自己感知现场、不会自己调用工具、也不会主动发起处置动作。

LLM 是“基于海量文本训练的大规模语言模型”，它是 AI 模型这个大类里的一个子集。Agent 则是“能自主完成任务的系统”。这个系统由感知模块、决策模块、行动模块和记忆模块组成：感知模块接收外部信息，决策模块调用 LLM 进行推理和规划，行动模块调用工具去执行动作，记忆模块保存短期会话历史和长期知识。所以 Agent 会用 LLM，但 Agent 不是 LLM。

拿这套远程运维系统来举例：实时音视频流本身不是 LLM 处理的，而是先经过 ASR 转成文字，再把文字交给 LLM；LLM 根据转写内容判断“可能是轴承磨损”，然后 Agent 并不会满足于这个判断，它会调用知识库检索接口去搜相似案例，把检索结果整理成一份建议，推给专家端。这里的“调用检索”和“推送”就是 Agent 的行动能力。所以你可以说系统里装了一个 DeepSeek，但它只是其中一个组件，我们更关注的是围绕它搭起来的 Agent 体系。

2. 系统整体架构与音视频链路设计

2.1 端到端架构：现场端、调度端、媒体服务、Agent 服务

整套系统从物理上可以分成四块。

现场端是一台运行 Android 或 iOS 的采集设备，可以是手机、平板、智能头盔或者加固型手持终端，负责采集摄像头画面、麦克风声音和现场设备传感器数据。调度端是专家的操作台，通常是一个浏览器页面，也可以做桌面客户端，负责显示实时画面、播放声音、收发 AR 标注、查看 Agent 推送的诊断信息。媒体服务是中间的核心通道，负责音视频流的转发、录制和信令转发，一般部署在公网环境。Agent 服务是一组 AI 微服务的集合，包含 ASR 语音转写、声纹特征提取、视觉识别、LLM 推理、知识库检索和工单生成，它和媒体服务通过 API 对接。

设备数据流不直接塞进音视频流里。现场设备通过 Modbus、OPC UA、MQTT 等协议把 PLC、传感器、智能仪表的数据采集到边缘网关，边缘网关一方面把这些数据推给 Agent 服务做判断，另一方面也推到调度端做可视化展示。音视频流走一条链路，设备数据走另一条链路，两条链路在 Agent 服务和调度端汇合，互相补充。这样设计的好处是，哪怕设备数据接入暂时不可用，音视频通话还能继续，不会出现“通信断了连画面都没了”的情况。

2.2 为什么选 WebRTC 而不是传统 RTMP 推流

最早我们考虑过用 RTMP 推流加 HLS 播放的方案，毕竟直播技术成熟，相关组件也多。但评估后发现 RTMP 是单向推流，专家端想看什么角度、想放大哪块区域，都没法和现场端实时交互；HLS 的延迟通常在 5 到 15 秒，根本没法支撑实时指导。专家对着延迟十秒的画面说“往左转一下”，现场人员可能已经走过去了，协作体验非常差。

所以最终选了 WebRTC。它有几个特点正合远程运维的胃口：端到端延迟能做到 300 到 500 毫秒以内，接近电话沟通的体验；原生支持双向音视频，现场端和专家端可以随时互动；自带 DataChannel，可以在音视频之外传 AR 标注、控制指令、小体积的结构化数据；浏览器原生支持，专家端不用装额外软件，打开网页就能接入。

当然 WebRTC 也有代价。它在多人或者多房间场景下需要搭配媒体服务器做混合转发，没有成熟的公网 CDN 分发能力，弱网拥塞控制虽然比传统 RTMP 好些，但也不是万能的。后面我会专门写踩坑经验。

2.3 除了画面和声音，还要传什么：AR 标注、传感器状态、控制指令

做过远程运维就会知道，光通视频远远不够。专家看到一个阀门，想跟现场人员说“拧的是旁边那个，不是这个”，语言描述容易出错。所以系统里必须支持 AR 标注，让专家直接在实时画面上画圈、画箭头、写字，这些标注通过网络传给现场端，叠加在现场第一视角画面之上。这里要注意“坐标同步”问题：专家标注的坐标是基于他看到的视频帧的，而现场端一直在动，所以标注要和视频帧绑定，要么在发送端带上时间戳和帧号，要么用图像识别锁定目标物体后做跟踪，否则画完圈就飘走了。

设备状态也要同步送达。现场端把当前设备的运行参数，比如主轴温度、振动幅值、电流值，通过 DataChannel 发给调度端，专家画面上就能看到一排实时数据。再进阶一点，可以在专家端做远程控制授权，比如远程下发参数修改指令给边缘网关，由网关确认后写入 PLC。注意：控制指令必须走独立的数据通道，并且要有二次确认机制，防止专家误触。

媒体服务器收到的 Audio 和 Video 流会被录制下来，这一步有很多讲究。录制不能简单地把每个参与者的流分开存，因为运维场景里“谁说了什么、当时画面是什么”是关联的，最好录制成带时间轴的合成流，或者把各轨录制成独立文件，再写上公共时间戳。否则后面做案例归档时，根本对不上时间线。

2.4 媒体服务选型：自建媒体服务器还是用托管服务

媒体服务器可选方案大致有几类。第一类是开源媒体服务器，如 Janus、MediaSoup 和 LiveKit，社区活跃、可控性强，部署在自有环境；第二类是云服务商的音视频 SDK，如声网、腾讯云等，集成快、全球节点多，但是需要按使用量付费，并且部分数据链路经过服务商；第三类是开箱即用的商用一体机，适合不想维护技术栈的团队。

我们团队因为需要和内部知识库、工单系统深度集成，最后选择了基于 LiveKit 做自建。LiveKit 的部署相对轻，用 Docker 就能起服务，提供 WebRTC 网关、录制、房间管理和客户端 SDK，支持多房间和动态扩展。Janus 功能也很强，但它的配置和插件体系更偏底层，维护成本高一些；MediaSoup 灵活性最好，适合做定制化 RTC，但几乎所有上层逻辑都要自己写，不推荐小团队直接上手。

自建媒体服务需要一台带宽和性能都够的公网服务器。我们最开始用一台 4 核 8G 的云主机跑单节点，一路 720p 通话再加一路录制，CPU 占用还能接受，但是并发到十路以上就开始出现抖动。后来调整到 8 核 16G，并把录制功能单独拆到另一台机器上，问题才缓解。

2.5 延迟预算和带宽估算

做实时音视频最忌讳“上了再说”，必须先算清楚延迟预算。

我们把端到端体验拆成四段。第一段是现场端采集和编码，设备性能正常的话大约 30 到 80 毫秒；第二段是上行传输到媒体服务器，在家庭宽带或者 4G/5G 网络下大约 50 到 150 毫秒；第三段是媒体服务器转发和下行分发，一般在 30 到 100 毫秒；第四段是专家端解码渲染，大约 30 到 60 毫秒。加起来在 150 到 400 毫秒之间。如果超过 500 毫秒，专家和现场对话就会明显“打手”，所以我们的调优目标是端到端不超过 400 毫秒。

带宽按照编码参数估算：一路 720p 30fps 的视频，用 H.264 编码，码率设置在 1.2 到 1.8Mbps 比较常见；音频用 Opus，码率大约 32 到 64kbps。假设并发 30 路通话，每路一路视频一路音频再加一路录制，媒体服务器的出口带宽大概是 30 乘以 2（视频上行和下行各一路）再乘以 1.5Mbps，再加上录制回传带宽，约 100Mbps 到 150Mbps。如果现场使用 1080p，码率直接翻倍，带宽也要跟着翻。所以不要只看单路码率，要按“上行 + 下行 + 录制”三份流量来预留。

3. 核心功能拆解：AI Agent 往运维流程里塞了什么

3.1 三路感知：音频、视频、设备数据

AI Agent 要干活，首先得“感知”到现场发生了什么。我们设计了三条感知通道。

音频通道是主力。专家和现场人员沟通时不可能对着麦克风把故障描述完整，但他们的对话本身就是信息流。系统把现场端麦克风采集到的音频实时送入 ASR 服务，转写成文本，然后交给 LLM 做语义分析。同时还有一个声纹识别和声音事件检测模块，专门识别“尖锐金属摩擦声”“漏气声”“电机异响”等异常声学事件。实际测试下来，异常声识别对轴承磨损、皮带打滑这类问题特别有效，经常比专家听出来的还早。

视频通道做视觉辅助。现场端摄像头画面会定时抽帧，送入视觉识别模型，检测仪表读数、指示灯状态、设备表面有无冒烟或漏油。这里要特别注意，视频识别不要全频率跑，否则 GPU 消耗扛不住。我们当时对每秒钟抽 2 帧做检测，只有在 Agent 判断“疑似异常”时才把抽帧频率提升到每秒 5 帧。

设备数据通道提供定量的运行状态。边缘网关按 1 到 5 秒的周期把 PLC 里的温度、压力、转速、电流、故障码推给 Agent。有了这三路感知，Agent 才不是“闭着眼睛瞎猜”，而是真正基于现场多模态信息做判断。

3.2 故障判断不是“大模型直接答”，而是 RAG 加结构化预案

刚开始做原型时，我们走了一条弯路：把设备手册和维修案例喂给大模型，让它直接给出答案。结果观察了两周发现，大模型的回答经常“听起来很有道理，实际完全不能执行”。比如它建议“检查电压是否稳定”，但对现场操作员来说，这句话等于没说，因为没有给出具体的测量点、标准值和操作步骤。

后来我们换成 RAG（检索增强生成）加结构化预案的方案。维护一个专门的知识库，里面存的是设备手册、历史工单、维修案例，每篇文档都做了分段和向量化。Agent 收到当前故障现象和现场数据后，先从知识库检索出最相关的 5 到 10 个段落，再把这些段落连同上下文一起交给 LLM 做归纳整理。LLM 的任务不是“现场发挥”，而是“把检索到的知识组织成可执行的步骤”。

关键点是：知识库里的每一份文档都必须是结构化的。一个故障预案至少包含设备型号、故障现象、可能原因列表、检查步骤、处置动作、注意事项、预估工时。凡是没有结构化处理的 PDF 文档，直接丢给 RAG 效果都很差，因为 LLM 提取不到清晰的字段。我们后来专门做了个清洗脚本，把维修案例全部转成统一的 YAML 格式入库。

3.3 实时辅助：Agent 给专家推送什么，什么时候推送

Agent 不是“一次问一次答”的聊天机器人，它要主动把判断推给专家。我们设计了几类推送信息，按紧急程度分级。

正常情况下，Agent 会把通话转写、设备数据变化、知识库匹配度最高的案例摘要展示在专家端的侧边栏，供专家参考。当 Agent 发现疑似异常时，会推送一条“异常告警”，内容包括异常类型、置信度、相关依据。比如“现场音频 14:32:05 出现高频摩擦声，设备主轴温度 86 度，与知识库中轴承磨损案例 2024017 匹配度 0.82”，同时给出建议的检查动作。

当 LLM 判断现场可能处于高风险状态，比如气体泄漏或者温度超过阈值，Agent 会触发更主动的干预，提示专家确认是否下发紧急停机指令。注意：Agent 永远不能直接下发控制指令，它只能建议专家操作。我们在系统里强制了“Agent 建议—专家确认—网关执行”的三级流程，这是出于安全责任的考虑，也是合规的基本要求。

3.4 两类 Agent 的划分：诊断 Agent 和调度 Agent

实际做的时候，我们没做一个“万能 Agent”，而是拆成了两个角色。

诊断 Agent 负责“这个故障是什么、该怎么处理”。它连接知识库、设备数据和感知模块，输出的是诊断结论和处置建议。调度 Agent 负责“这件事该谁处理、什么时候处理”。它监听诊断 Agent 的输出和当前工单状态，如果发现故障等级较高，自动查询排班表和人员技能标签，把工单分配给最近的、具备相应技能的二线工程师，同时通知主管。

把两个 Agent 分开有个明显好处：诊断 Agent 可以专注于准确性和知识库质量，调度 Agent 可以专注于流程状态机，两者的改动互不影响。而且不同企业对授权机制要求不同，调度 Agent 的规则完全可以按客户定制，而诊断逻辑保持统一。

3.5 这里为什么不用纯大模型直接回答问题

回到很多朋友问的问题：既然 DeepSeek 这类大模型已经很强了，能不能直接拿它做远程运维的 AI？我的经验是：不能只用纯模型，至少要叠加两层约束。

第一层是知识约束。大模型训练时没见过你们公司的设备型号和故障案例，它只能给出通用常识，甚至用错误的常识“一本正经地胡说八道”。而运维场景追求的是可执行、可追溯，不能接受一个听起来合理但实际错误的建议。RAG 的作用就是把模型的知识范围框定在你们自己的知识库里，检索不到就不允许乱答。我后来对所有输出加了校验：如果知识库召回结果的相似度低于某个阈值，Agent 会明确回复“未检索到完全匹配案例”，并给出通用检查建议的提示，而不是假装确定。

第二层是动作约束。纯 LLM 的输出是文本，不是可执行操作。Agent 必须通过类别判断来决定调用哪个工具：是查知识库、发工单、推送给专家，还是触发告警？这些动作是程序里写死的工具函数，LLM 只是决定调用哪个函数、填什么参数，真正执行动作的仍然是可靠的程序逻辑。这样才能保证 AI 说错了也不会造成破坏性后果。

4. 实操过程：搭一套最小可运行的远程运维系统

4.1 场景和组件约定

为了让这篇内容可复现，我接下来描述一个最小可运行版本，不考虑生产级的容灾和复杂权限。假设场景是一台车间的空压机，现场人员用手机作为采集端，专家在办公室用浏览器查看，Agent 跑在局域网服务器上，设备数据通过一个模拟网关每 3 秒上报一条 JSON。

所需组件：一台媒体服务器（LiveKit）、一套信令服务（可以直接用 LiveKit 自带的信令）、一个 Agent 服务（Python 编写，包含 ASR、LLM 调用、RAG 检索和推送）、一个前端页面（专家端）、一个手机 App（现场端可以用 LiveKit SDK 快速封装）。如果你不想写 App，也可以用手机浏览器访问现场端 Web 页面，只要浏览器支持 WebRTC 和摄像头权限即可。

知识库先用简单的 SQLite 存向量和文档元数据，或者直接用开源的向量数据库，比如 Chroma。LLM 部分可以调用云厂商 API，也可以部署一个开源模型。我建议先用云 API 把整个流程跑通，模型能力稳定之后再做私有化部署。

4.2 音视频通话链路：从创建房间到播放流

先启动 LiveKit 服务。假设你的 LiveKit 部署在 media.example.com ，端口 7880。前端用官方 JS SDK 连接。

# agent_service/main.py 框架示意
from agents import Agent

// 专家端连接流程（LiveKit JS SDK 伪代码）
const room = new Room();
await room.connect('wss://media.example.com', { token });
const remoteParticipant = room.participants.get(remoteSid);
const videoTrack = remoteParticipant.getTrackPublication(trackSid).track;
const el = document.getElementById('remote-video');
await videoTrack.attach(el);

现场端采集屏幕方向、分辨率、码率等参数，注意旋转问题。很多手机默认竖屏，专家端看到的画面是竖着的。空压机这种设备更适合横屏拍摄，需要在 App 里强制横屏，或者在专家端提供旋转按钮。我们在第一次实测时没注意这个，专家对着竖屏画面看了半天，体验很差。

媒体服务器在房间里做转发和录制。LiveKit 提供了录制功能，可以设置录制存储路径。这里的经验是：一定要在房间创建时就启动录制，不要等故障发生了再“想起”去开录制，否则故障前的现场信息就全丢了。如果担心存储成本，可以做“全程低码率录制 + 故障时切高码率录制”。

4.3 Agent 管线：语音转写、RAG 检索、推送

Agent 服务从音视频流里拿音频，不是直接读 LiveKit 的媒体包，而是通过 LiveKit 的“Egress”把音频流转发出来，或者用现场端 App 里的实时音频上传通道。最小可运行版本里，为了让架构清晰，我建议让现场端同时做两件事：一路推给 LiveKit 做音视频通话，另一路把音频以流式 HTTP 推给 Agent 服务的 ASR 接口。这样 Agent 和通话相互独立，就算 Agent 服务挂了也不影响主要通话。

# 伪代码体现 Agent 编排思路
import asyncio

def get_transcript(audio_stream):
    # 调用 ASR，返回带时间戳的文本
    return asr.transcribe(audio_stream)

def search_kb(query, top_k=5):
    # 将 query 向量化，在 Chroma 里检索
    return kb.query(query, top_k)

def build_payload(transcript, kb_hits, device_status):
    prompt = f"""
    当前对话转写：{transcript}
    设备数据：{device_status}
    检索到相关知识：{kb_hits}
    ...
    """
    return llm.complete(prompt)

Agent 服务拆成三个进程更合理：ASR 进程只负责把音频转写文字，推理进程负责 RAG 和 LLM 推理，推送进程负责把结果通过 WebSocket 推到专家端。三个进程用消息队列串起来，避免一个环节处理不过来拖垮整个链路。我最早把所有逻辑塞在一个进程里，ASR 转写慢的时候，整个 Agent 的推理也被卡住了，后来拆开才解决。

推送层有两种方式。一种是直接通过 WebSocket 推给专家端前端；另一种是写入 Redis 消息队列，由前端长轮询读取。我们最后用了 WebSocket 方案，因为延迟更低，体验更好。

4.4 关键配置参数与实际选择

音视频相关的编码参数、延迟预算、带宽估算，我在第 2.5 节已经算过。这里补充 AI 侧的资源估算。

ASR 转写如果实时性要求高，建议用流式接口，每个会话的音频流单独建一个转写会话。我们用的流式转写延迟大约为 300 到 800 毫秒，对运维场景可以接受。如果用离线转写，虽然准确率高，但一次要等完整段落，实用性差很多。

LLM 推理的开销主要看并发。每次咨询请求的输入 token 包括转写上下文、知识库召回段落和系统提示词，大约在 1500 到 3000 token；输出 token 控制在 500 以内。假设每次故障诊断持续 30 分钟，期间 Agent 每个异常触发点做一次推理，大概 20 次左右，总共输入约 60000 token，输出约 10000 token，这部分按 token 计费成本可控。如果走本地模型，则要准备一台带 24GB 显存的 GPU 才能跑到能用的上下文长度。

知识库检索的向量化要提前完成。每次检索的耗时主要是向量计算和 TopK 排序，在几十万条文档规模下基本都在 50 毫秒以内。如果文档数量更大，建议加一层基于设备型号的预过滤，先限定搜索范围，再做向量匹配。

4.5 从 0 到 1 的上线步骤清单

第一步，先跑通音视频通话。把 LiveKit 服务部署起来，两个浏览器页面互开视频，确认画面和声音延迟可接受，再接入手机端采集。第二步，加入录制功能。每次测试会话都保留录制文件，方便后续分析。第三步，接入设备数据模拟器。写一个小程序模拟 PLC 数据上报，推到 Agent 服务和专家端前端。第四步，接 ASR 和 LLM。先把对话转写跑通，让专家端侧边栏能看到转写文本。第五步，做知识库。找 50 份历史维修案例，清洗成结构化 YAML，导入向量库。第六步，把 RAG 检索和推送接上，让 Agent 能主动推送案例。第七步，加工单和报告功能，整条链路才完整。

每一步都要有一个可验收的里程碑。很多团队一上来就想做大而全的系统，结果卡在 AI 幻觉上出不了活。我建议垂直打通，先把一条故障的“感知—诊断—指导—沉淀”循环跑通，再扩功能。

4.6 上线前检查清单

上线前要检查的事情很多，我列一下我印象最深的几条。

权限模型必须有。现场端谁能发起通话，专家端谁能看到哪些现场，录制文件谁能下载，都要有明确权限。尤其是跨部门协作时，权限混乱会引发很大的合规风险。连接安全方面，WebRTC 的媒体流默认是加密的，但信令和 Agent 服务之间的 API 要加鉴权，防止有人冒用专家身份下发指令。

故障切换。如果媒体服务器挂了，怎么让专家和现场重新连接？如果 Agent 服务挂了，音视频还要保持能通话。我们在架构上刻意让 Agent 依赖音视频链路，一旦 Agent 全部宕机，专家仍然能手动指导，只是没有 AI 辅助。这个降级策略很重要。

录制和日志保留策略。远程运维会涉及现场画面和通话，企业通常有自己的数据安全要求。录制文件默认保留 90 天，过期自动清理。AI 转写文本和工单长期保存，用于后续知识沉淀。这个策略要提前和企业确认，不要等运营一段时间后再去补。

5. 常见问题与排查技巧实录

5.1 音画不同步问题

首次实测时，专家端发现画面里的阀门已经动了，声音却延迟了半拍。排查下来，问题出在音频经过了一条更长链路。现场端音频推给 ASR 进程做转写，转写结果又通过 WebSocket 推送，而视频是直接经过 LiveKit 转发的，两条链路的时间基准不一致，导致专家端的转写文本、现场声音和画面三者对不上。

解决思路是：所有环节统一使用媒体服务器的时间戳，转写结果必须带上段落的起止时间，并且和专家端回放的本地时间轴对齐。前端做字幕叠加时，用 NTP 同步过的时间戳计算延迟差，做动态补偿。这看起来是个细节，但直接影响专家阅读的准确性。

5.2 音频噪声导致 ASR 乱转写

车间环境很吵，ASR 转写经常出现“胡言乱语”，甚至把设备轰鸣声转成无意义的句子。这个问题并不好解决。我们首先在采集端增加了一个噪声抑制滤波器，把环境背景音压掉一些；然后给 ASR 模型加载了“车间专用热词表”，把常见设备名、零件名、故障词都加进去，提高专有名词识别率。

更有效的一招是：ASR 默认不返回低置信度的片段，在转写结果里过滤掉置信度低于 0.6 的短句。虽然会丢一些现场人员的口语词，但整体准确率明显提升。对于关键故障词，比如“漏油”“异响”“报警”，我们设置了单独的声学关键词检测，不依赖 ASR 的文本结果，一旦声学特征命中就直接触发告警。这类关键词检测对噪声的容忍度比大模型转写高很多。

5.3 Agent 给出错误建议怎么办

AI 幻觉是躲不掉的，只能降低概率和影响。我们做了三层防线。

第一层，RAG 检索相关性过滤。检索召回结果里，如果最高的向量相似度低于 0.75，就直接判定为“知识库无匹配”，不让 LLM 强行作答。第二层，输出规范校验。LLM 输出必须是一个固定 JSON 结构，包括建议的操作步骤、依据来源、置信度。如果输出不合法，程序直接丢弃，不展示给专家。第三层，专家复核闭环。专家端每个 Agent 建议旁边都有一个“采纳”或“驳回”按钮，驳回时必须填写原因。被驳回的案例会回流到一个待优化队列，由运维工程师定期分析，修正知识库内容。

这层机制跑下来，Agent 建议的采纳率从最开始的不到四成，慢慢提升到了七成左右。最关键的还是知识库质量。与其花时间调大模型提示词，不如多花时间把历史案例整理好。

5.4 弱网卡顿与断线恢复

工厂现场的 4G、Wi-Fi 信号不一定稳定，弱网环境是绕不开的。WebRTC 自带拥塞控制，但默认参数不一定适合“现场画面很少动、偶尔快速移动”的运维场景。我把采集端的比特率上限调低了一些，优先保证流畅度，而不是画质。同时开启 WebRTC 的丢包重传机制，让关键帧能够更可靠地到达，避免画面卡在花屏上。

断线恢复方面，我们在业务层做了“自动重连 + 恢复上下文”的机制。现场端断线后，重新进同一个房间；如果房间已经销毁，则自动创建一个新房间并把已录制的片段串起来。专家端重连后，系统会提示“现场端已重连，期间画面中断 35 秒”，避免专家不知情时做出错误判断。

还有一个特别推荐的技巧：现场端弱网时，会自动切换音频优先模式，降低视频码率甚至暂时关闭摄像头，保证语音能持续。因为远程运维里，最不能丢的是对话通道，画面卡了可以截图重发，语音断了协作就彻底垮了。

5.5 问题速查表

我把实施过程中遇到的常见问题整理成一张速查表，方便同行直接定位。

现象	可能原因	排查与解决
音画延迟超过 500ms	媒体服务器离现场端太远	就近部署边缘节点或改用托管 RTC 服务
画面模糊	上行带宽不足	降低码率，启用丢包重传，关闭非必要视频流
ASR 乱转写	环境噪声大	加噪声抑制，热词表扩展，低置信度过滤
专家端看不到 AR 标注	标注坐标绑在了旧帧上	用时间戳绑定视频帧，或做目标跟踪
Agent 建议和实际不符	知识库缺案例或召回不准	人工确认案例，不合格的驳回并回流修正
工单重复创建	Agent 多次判断为异常	引入去重状态：同一会话内同类型异常 5 分钟内只建一次
录制文件时间线对不上	多轨录制没有统一时间戳	用 NTP 同步，写入公共时间轴
媒体服务器 CPU 高	转码开销大，或并发超预期	使用 Simulcast 分层转发，避免全部转码

6. 最后聊聊我在这套系统上踩过的几个坑

如果你准备动手做类似系统，我忍不住多啰嗦几句。

第一，不要一上来就追大模型的热点。先把音视频链路跑通、把知识库整理好，再考虑 AI 的深度。我们最开始的演示版本用了很炫的 Agent 界面，但音视频链路偶尔断线，现场人员用了几次就失去信任了。后来花了两周把媒体服务的稳定性提上来，大家对系统态度才转变。运维工具的首要属性是可靠，然后是智能。

第二，现场端和专家端的产品设计要分开思考。现场端面对的是可能戴着手套、正在操作设备的人，界面要极简，尽量做到“打开就能通话”；专家端面对的是需要同时看视频、听音频、看数据、读结果的人，信息要分区明确，不能一股脑堆在一起。我们早期的专家端把转写、设备数据、图纸堆在同一列，专家根本看不过来，后来改成分栏布局，左侧画面、右侧信息区，才勉强可用。

第三，知识库的整理远比模型调参重要。我们内部有一句话：Agent 的上限由知识库决定，不是由模型决定。把过去三年的维修记录结构化之后，系统可用性提升了不止一个档次。这事看起来不性感，但它是整套系统真正的护城河。

第四，保留一手的人工复核手段。Agent 再聪明，也只能是辅助工具。我们特意在界面上保留了“一键转人工”的入口，确保现场人员随时能找到真正的专家。这个入口在日常运维里可能不常用，但在关键故障发生时，它是兜底的信任来源。

最后分享一个小技巧：上线初期可以专门安排一次“模拟故障演练”，不通知值班人员，让 Agent 和专家端共同处理一个仿真故障，把整个过程录下来复盘。我们的很多流程缺陷都是在演练中暴露的，比如现场端没有应急电源、专家端侧边栏被浏览器遮挡、知识库里某个型号的设备漏维护，等等。这些问题如果靠真实故障来发现，代价就太大了。