本文基于 2026-07-22 发布的历史实践整理技术细节与测试数据保留原文口径。凌晨两点配电柜通过设备通道向值守群上报温度异常诊断 Agent 调取实时数据判断风险能耗 Agent 评估停机影响值班人员确认方案后执行 Agent 通过设备通道安全地下发降载指令。五分钟后设备回传温度恢复AI 自动生成处置记录。这不是给物联网平台加一个聊天框而是让人和多个 AI Agent 第一次真正进入同一个业务现场并让设备、飞书、企微等通道成为这个现场的感知与执行入口。人在会话中提出目标并做最终决策多个 AI Agent 分别负责诊断、检索、推演和调度设备通道负责感知与执行飞书等渠道负责连接外部沟通入口。参与者共享会话上下文、相互协作所有跨通道动作始终受到权限、审批和审计机制约束。这才是 AI 时代值得期待的万物互联万物不仅在线而且能够共同理解问题、形成方案并完成行动。一、设备都在线为什么事情还是要靠人来回奔波过去很多年物联网平台解决的核心问题是“连接”。设备能不能接上来数据能不能采回来告警能不能推出来指令能不能下发这些问题非常基础也非常重要。没有设备接入、物模型、时序数据、协议转换、边缘网关和权限体系后面的智能化都无从谈起。但企业真正用起来之后很快会遇到另一个问题设备连上平台不等于业务真正跑顺。以一个园区运维场景为例。温湿度传感器离线了系统能产生告警空调能耗异常了平台能展示曲线配电柜负载上升了后台也能查到数据。可一线人员处理问题时往往还是要在多个地方来回切换先去告警列表看是哪台设备。再去设备详情页查设备位置、产品类型和最近状态。然后到项目群里问谁在现场。现场人员再拍照、语音说明、人工确认。主管想要结论还要等人整理日报。如果接了 AI通常还得另开一个 AI 聊天窗口把上下文再说一遍。从平台视角看能力都有从用户视角看事情还是很碎。这也是很多 IoT 平台“看起来功能很全用起来还是重”的根本原因它们把设备、数据、告警、沟通和 AI 分散在不同入口里。用户不是在处理一个连续的业务现场而是在拼接多个系统里的碎片。AI 时代的万物互联真正要解决的已经不是“再多连几类设备”而是三个更难、也更有价值的问题当设备出现情况时相关的人、AI、数据和动作能不能自然聚到一起AI 能不能从“告诉用户该怎么做”进一步走向“在授权范围内把事情做完”面对复杂问题能不能让多个专业 AI 和多个人协同并通过不同设备通道完成感知与执行而不是把所有任务都塞给一个万能助手联犀最近对 IM 系统、AI 中台和设备通道的融合升级正是围绕这三个问题展开把 IM 从普通聊天工具升级为 AIoT 的会话中枢让人和多个 AI Agent 进入同一个可治理的协作网络再把设备、飞书、企微等作为标准通道接入通过物模型、工具调用、权限校验和执行回执让“发现问题、分析问题、决定方案、操控设备、验证结果”形成闭环。二、用户真正需要的是一个“业务现场”对用户来说真万物互联不应该表现为更多菜单、更多大屏、更多配置项。它应该更像一个真实工作现场设备发生异常会自动出现在该出现的项目群里。AI 能看懂这条异常和上下文告诉用户影响范围和建议动作。现场工程师可以直接在会话里回复、拍照、语音说明。主管能在同一个会话里看到进展而不是到处追问。用户可以继续让 AI 总结今天的设备情况或者让设备执行简单控制。处理过程自动沉淀下来后续可用于日报、复盘、知识库和自动化流程。这个“业务现场”不是一个单独页面而是一种新的产品组织方式以会话承载协作以消息承载过程以 AI 承载理解以设备承载感知和执行。举一个更具体的例子。早上 9 点园区运维群里AI 助手主动发来一条摘要昨晚 A 栋 3 层温湿度传感器出现 3 次离线重连配电柜负载峰值高于近 7 日均值 18%当前没有一级告警建议现场巡检空调控制器。工程师回复我 10 点过去看一下。AI助手 把相关设备列表发我。AI 返回一张设备卡片设备名称、楼层位置、在线状态、近 24 小时趋势、快捷入口。工程师到现场后可以在 App 里对设备说把会议室空调调到 24 度。设备执行完成后回到会话里空调-会议室温度已设置为 24℃。如果现场需要远程支持工程师可以发起人和设备的实时语音通话如果设备本身具备语音入口也可以直接和 AI Clone 对话。整个过程中用户没有被迫在“设备后台、AI 聊天、项目群、工单系统”之间反复横跳。这就是 AI 时代真万物互联的产品价值把人的协作、设备的状态、AI 的判断和后续动作组织成一个连续场景。三、联犀的产品判断IM 是 AIoT 的新入口很多人一提 IM会先想到“聊天”。但在企业软件里IM 的价值远不止聊天。IM 有几个天然优势因此联犀没有把 IM 当成一个孤立的聊天模块而是把它设计成 AIoT 的“会话层”。设备管理解决“设备是谁、在哪里、能做什么”AI 中台解决“如何理解、推理、生成和执行”IM 会话层解决“人和 AI 如何围绕业务对象协作”通道层解决“消息、数据和动作如何进出这个现场”。这套思路带来的变化很直接用户不再只通过菜单找功能而是通过会话进入业务。AI 不再只回答抽象问题而是进入项目、设备和人员上下文。设备不再只是后台数据源而是通过标准通道向会话上报事实、接受控制并反馈结果。平台不再是功能堆叠而是一个持续沉淀的协作网络。这也是联犀做 IM 融合升级的根本原因AIoT 平台的下一代入口很可能不是传统后台菜单而是围绕业务对象组织起来的智能会话。四、第一步分清参与者、业务对象和通道要构建一个长期可演进的智能会话网络底层首先要回答三个不同的问题谁在协作围绕什么协作信息和动作从哪里进出联犀的边界很明确人和 AI 是会话参与者设备是业务对象与设备通道端点飞书、企微、钉钉等是沟通通道。人和 AI 之所以是参与者是因为它们会理解上下文、表达判断、承担任务或做出决策。一个项目群可以有多名工程师、管理者和多个专业 Agent它们拥有明确身份可以被 也有各自的可见范围和工具权限。设备则通过设备通道进入业务现场。设备属性、事件和告警被通道适配为消息AI 或人在会话中发起控制后结构化指令再沿设备通道下发执行结果通过同一通道回传。消息可以显示明确的设备来源但这不意味着设备成为会话成员。飞书、企微、钉钉也遵循同样原则。渠道中的真实人员经过账号绑定或身份映射后仍然对应“人”这个参与者飞书本身只负责承载消息的接收和发送不是群聊里的参与者。这个边界能避免模型越来越混乱增加一种设备协议或外部沟通平台只需增加通道适配增加一种专业 Agent才需要扩展参与者能力。用户最终感受到的是一个连续现场系统内部却始终清楚“谁在协作”和“通过什么连接”。五、第二步把聊天、告警、AI 回复和设备上行统一成消息明确参与者和通道边界之后还要统一消息。很多平台的问题是同一个事件在不同系统里有不同形态。设备离线在设备系统里是一条设备事件在告警系统里是一条告警在通知系统里是一条通知在 IM 里可能是一条文本在 AI 系统里又是一段上下文。数据被拆得太散用户追上下文很累AI 也很难真正理解现场。联犀把消息链路作为业务现场的时间线尽量让不同来源的内容都能进入统一会话这样做之后用户看到的不只是聊天记录而是一条完整的处置链08:55 [设备] 温湿度传感器-A3离线08:56 [AI助手] 该设备近 24 小时已发生 3 次离线建议巡检网关供电08:58 [张工] 我 10 点到现场10:12 [张工] [图片] 网关电源松动已重新固定10:15 [设备] 温湿度传感器-A3上线10:16 [AI助手] 本次异常已恢复建议观察 30 分钟这条时间线有三个价值。对一线人员它减少切换。设备状态、AI 判断、人工处理都在一个地方。对管理者它形成过程可见。不是只看到“告警已恢复”而是看到谁处理、如何处理、多久恢复。对 AI它形成上下文资产。后续 AI 做日报、复盘、同类问题推荐时不需要重新拼上下文。这也是联犀强调消息统一的原因AIoT 的智能不是只靠大模型生成而是要让业务过程本身持续沉淀为可理解、可检索、可追溯的数据。六、第三步让 IM 专注会话让通道专注接入当人、AI、设备数据和外部平台都汇聚到一个业务现场IM 会不会越来越重这是联犀在设计里重点避免的问题。联犀的做法是让 IM 专注会话关系、消息、落库、推送和信令设备与外部平台通过各自通道适配器接入IM 不负责理解设备协议也不承担飞书、企微等平台的专有逻辑。更具体地说这套边界听起来偏技术但对产品长期演进非常关键。如果明天要接一个新的外部 Agent只需要注册新的 Agent 端点如果后天要接一个新设备协议只需要在设备侧做协议适配如果大客户要把飞书群、企微客户群接进来也是在渠道层扩展而不是把 IM、AI、设备三套系统一起改。用户感知到的是“一个入口”但平台内部保持清晰分工。这是联犀能够同时服务 SaaS 托管、私有化部署、定制应用和源码授权客户的重要基础。七、AI Agent 的落地方式既能被 也能主动出现AI Agent 进入业务现场至少要解决四个产品问题。第一怎么开始对话用户可以和 AI 单聊也可以在项目群里 AI。比如“AI助手 今天设备有什么异常”系统识别会话中的 AI 参与者触发 AI 回复。第二怎么拿到上下文AI 不应该只拿到用户刚发的一句话而要逐步获得会话上下文、设备上下文、项目权限、知识库资料和历史处理记录。当前链路先从 IM 消息和会话映射开始后续可继续注入设备状态、物模型属性、告警历史和知识库召回结果。第三怎么避免阻塞用户用户发消息后发送接口应该立即返回不能等大模型慢慢生成。联犀采用异步链路用户消息先落库后台调用 AIAI 回复生成后再作为新消息推送到会话。第四AI 能不能主动提醒真实业务里很多时候不是用户先问 AI而是设备告警、定时巡检、预测分析先发生。联犀通过事件总线支持 AI 主动回复业务侧发布 im.ai.replyIM 订阅后把 AI 内容落成消息并推送给相关用户。这条链路可以概括为从用户角度这种体验更像真人同事你发完消息不用卡住AI 思考后自然把回复发回来。从企业角度这种模式更适合规模化因为 AI 生成、消息投递、设备事件不会互相阻塞。八、让 AI 更好地操控设备从一句话到一个可信的执行闭环AI 能看懂设备数据只完成了智能化的前半程。用户真正期待的是当他说“把会议室调舒服一点”“把这批高风险设备先降载”“夜间无人时自动关闭非必要照明”AI 不仅能给建议还能理解目标、找到设备、生成动作并在安全边界内完成执行。但 AI 操控设备绝不能等同于“把自然语言直接翻译成一条控制指令”。大模型输出具有不确定性设备控制却必须确定、可验证、可追责。特别是在能源、工业、消防和门禁场景里一次错误动作可能带来真实损失。因此联犀把 AI 操控设备设计为一个完整闭环而不是一次简单调用1. 先理解目标不急着生成指令用户说“有点热”并没有明确指定设备、温度和持续时间。AI 需要结合会话位置、用户权限、当前温湿度、在场人数、空调状态和节能策略把模糊目标转成一个可解释的计划当前会议室 28.2℃建议将空调从 27℃调整到 24℃运行 30 分钟后重新评估。预计增加能耗 0.8kWh。是否执行对用户而言这比要求他记住设备编号和控制参数自然得多对平台而言先形成计划再执行也为校验和审计留下了明确边界。2. 把物模型能力转换成 AI 可调用的工具联犀已经通过产品和物模型描述设备“有什么属性、会上报什么事件、可以执行什么服务”。在 AI 控制链路中这些确定性能力可以进一步转换为 Agent 可理解的 Tool Schema。例如空调不是一个模糊的“可控制对象”而是向 AI 暴露受约束的工具{ ”tool”: ”set_air_conditioner_temperature”, ”deviceId”: ”ac-meeting-room-01”, ”parameters”: { ”temperature”: 24, ”mode”: ”cool” }, ”constraints”: { ”temperatureMin”: 18, ”temperatureMax”: 30 }}AI 负责理解意图和选择工具物模型负责限制参数和表达设备能力设备服务负责最终执行。这样即使更换模型设备控制边界也不会跟着模型漂移。3. 不同风险采用不同授权方式不是每个动作都需要弹窗确认也不是每个动作都应该自动执行。联犀可以按照设备类型、动作风险、使用场景和用户角色建立分级策略用户感受到的是“越用越省事”企业获得的却不是一个失控的自动化入口而是一套能按业务风险逐步放权的机制。4. 设备回执不是一句“已执行”而是结果验证指令成功下发不代表业务目标已经达成。例如 AI 把空调设为 24℃设备返回“设置成功”但十分钟后室温仍然升高真正的问题可能是制冷故障、门窗未关闭或传感器异常。因此控制链路还要持续观察目标属性判断结果是否符合预期。一次可信的设备控制至少应留下这些信息谁提出目标、哪个 AI 生成计划、谁确认、控制了哪台设备、下发了什么参数、设备如何回执、状态是否达到预期、失败后如何处理。这些记录会以结构化消息和时间线沉淀在会话中。主管看到的不再是难以理解的调用日志而是一份完整的行动说明。5. AI 可以操作设备但不能绕过设备平台这是联犀方案里非常重要的边界。AI Agent 不直接连接每一种设备协议也不绕开设备服务向 MQTT 或 UDP 随意发包。Agent 只调用经过注册的标准工具工具请求携带用户、项目、会话和授权上下文设备服务继续负责物模型校验、在线状态判断、协议转换、指令下发和结果回执。这样AI 获得了操控现实世界的能力平台仍然保留确定性控制。AI 负责聪明设备平台负责可靠人在关键节点保留最终决定权。九、群聊里的集群智慧人和多 AI 如何调用设备通道解决问题一个 AI 助手可以回答问题却很难同时精通设备诊断、能耗优化、安全规范、库存调度和客户沟通。真实企业本来就是靠团队协作运行的。AI 进入企业之后更合理的形态也不是制造一个无所不能的“超级助手”而是让多个有明确职责的 Agent 像专业成员一样进入群聊各自使用不同知识、工具和权限在同一个业务上下文中协作。一个典型的园区运维群可以由不同参与者和通道共同支撑1. 多 AI 不是一起抢答而是有组织地协作如果群里的每个 AI 都监听所有消息并自由回复用户很快会被重复答案淹没模型调用成本也会失控。联犀更适合采用“显式 事件触发 协调 Agent 路由”的混合方式用户明确 诊断Agent 时由指定 Agent 响应。设备产生高价值事件时按场景规则唤起对应 Agent。用户提出跨领域目标时由协调 Agent 拆解任务并选择专业 Agent。专业 Agent 的中间结果可以作为结构化消息回到会话但由协调 Agent 汇总后再面向用户给出统一结论。普通闲聊、重复问题和低价值事件不触发整个 Agent 集群。这让群聊看起来像一个配合默契的团队而不是多个机器人同时争夺话筒。2. 一次真实的集群协作会怎样发生凌晨 2 点配电柜通过设备通道上报温度快速升高系统将带有设备来源标识的事件消息投递到园区夜间值守群。02:01 [配电柜-3A] 柜内温度 68.4℃5 分钟上升 7.2℃超过预警阈值02:01 [协调Agent] 已启动异常研判诊断、能耗和安全 Agent 正在分析02:02 [诊断Agent] 风扇转速异常结合近 7 日记录散热组件故障概率较高02:02 [能耗Agent] 当前负载可转移 22%预计不影响关键区域供电02:03 [安全Agent] 建议先降载至 70%禁止直接断电需值班人员确认02:03 [协调Agent] 已生成处置方案转移非关键负载 → 降载 → 观察 5 分钟02:04 [李工] 确认执行02:04 [执行Agent] 已通过设备控制服务下发降载指令02:06 [配电柜-3A] 当前负载 69.6%柜内温度降至 61.8℃02:07 [工单Agent] 已创建 P2 工单并预约 08:30 更换散热组件在这个过程中人和多个 AI 是真正的会话参与者多个 AI 并行贡献专业判断人保留关键动作的决策权设备通道提供实时事实、承接控制并把结果带回群里。任何一个参与者都不掌握全部能力但参与者与通道组合起来形成了比单个模型更可靠的“集群智慧”。3. 共享上下文但不共享全部权限多 Agent 协作的难点不只是让它们互相发送消息而是让它们看到完成任务所需的同一份事实同时遵守各自的权限边界。联犀的会话可以承载共享上下文设备身份、项目位置、当前属性、历史消息、告警记录、知识库引用和人工反馈。每次任务再通过关联 ID 串起原始事件、Agent 子任务、设备指令和最终回执。但共享上下文不等于共享全部权限。诊断 Agent 可以读取设备数据却不一定有控制权执行 Agent 可以调用特定设备工具却不应读取无关客户资料外部服务商可以看到分派给自己的工单却不能浏览整个项目群历史。这使“集群智慧”建立在最小授权之上而不是用一个拥有全部系统权限的超级账号完成所有事情。4. AI 之间意见冲突时把选择权交回规则和人多个 AI 可能给出不同判断。诊断 Agent 建议立即停机能耗 Agent 认为可以降载观察生产 Agent 则提示停机会影响订单。联犀不会把多个答案简单投票而是保留各自依据、置信度和影响范围由协调 Agent 根据预设策略整理差异低风险事项可按规则自动选择高风险冲突则生成对比卡片明确展示方案、收益和风险请负责人决定。AI 的价值不是替企业掩盖不确定性而是更快地收集证据、暴露分歧并辅助决策。5. 从“群聊消息”进一步走向“群体记忆”每一次协作结束后系统可以将事件原因、处置方案、设备反馈、人工修正和最终结果沉淀为结构化案例。下一次同类设备发生异常Agent 不只检索通用知识还能参考企业自己的历史经验。随着协作次数增加知识不再只留在某位工程师脑中也不再散落在聊天记录和工单备注里。会话成为企业现场知识的采集入口知识库成为长期记忆多个 Agent 则把这些记忆重新用于下一次行动。这正是联犀所理解的“集群智慧”不是模型数量越多越好而是让正确的人和 Agent 在正确时机获得必要上下文再通过正确的设备与业务通道把一件事闭环。十、设备通道的落地方式连接现场感知与现实执行设备不是会话参与者但设备通道是智能会话连接现实世界的关键。它不能只是把告警转成一条文本还要稳定承载数据上行、控制下行和结果回执。联犀把设备通道接入会话分成三个层次。1. 文本和媒体上行让设备能“说话”设备、边缘网关或外部渠道可以把内容统一包装成入站内容例如文本设备状态、异常说明、执行结果。音频文件现场语音留言或设备录音片段。图片摄像头截图、巡检照片、识别结果。文件设备报告、日志文件、检测文档。IM 收到这些内容后不需要理解每个设备协议只把它们归一化为站内消息并在消息扩展信息里记录渠道类型、渠道 ID 和渠道名称。这意味着后续新增设备渠道时不必重写会话、未读、推送和前端消息展示。只要适配入站内容就能进入统一业务现场。2. 人和设备实时通话让用户能“连到现场”一些设备不仅会上报数据还具备音频能力。比如智能音箱、带麦克风的边缘设备、巡检终端、工控语音盒子。联犀为人和设备实时通话设计了纯转发路径浏览器 / App ⇅ WebRTCimsvr relay ⇅ UDP Opus设备这里的重点是“纯转发”IM 不做语音识别不做语义理解只负责把浏览器侧 WebRTC 音频和设备侧 UDP Opus 帧接起来。这样延迟更低边界更稳也便于在私有化环境里部署。3. 设备和 AI Clone 对话让设备能“连到智能”另一类场景是设备直接和 AI Clone 对话。比如一个语音设备被唤醒后用户对它说“查看今天能耗异常。”设备把音频流送入 IMIM 再把音频流转发到 Agent 端点。Agent 自己完成 ASR、LLM、TTS然后把回复音频返回设备同时把转写文本和 AI 回复沉淀到会话记录。设备 ⇅ UDP Opusimsvr relay ⇅ gRPC / HTTP 音频流Agent 端点aisvr 或外部 Agent ├─ ASR ├─ LLM └─ TTS这条路径有一个非常关键的设计Agent 是自包含端点。IM 不关心 Agent 内部用哪家 ASR、哪种大模型、哪套 TTS也不为 ASR/TTS/LLM 做复杂 hook。换 Agent本质上就是换端点地址和协议配置。这样联犀既能使用内置 AI 中台能力也能接入客户已有的外部 Agent。这对企业客户尤其重要。因为不同客户对模型、语音、私有化和数据边界的要求差异很大。把 Agent 做成自包含端点才能在标准产品和客户定制之间保持平衡。十一、外部渠道为什么也要纳入同一张网络企业真实沟通并不只发生在平台内部。客户可能在企业微信里反馈问题供应商可能在飞书群里沟通内部团队可能用钉钉协作现场人员可能只用小程序。假如联犀的智能会话只覆盖自家 Web 后台那业务现场仍然会被切开。因此联犀在 IM 融合方案里明确把这些平台作为沟通通道而不是会话参与者飞书、企微、钉钉负责消息收发、群映射和回执不拥有参与者身份。外部渠道消息进入平台后变成统一消息。渠道中的真实人员通过账号绑定或身份映射对应平台中的 user 参与者。内部用户、AI 回复和设备事件消息可以通过渠道适配器下发到外部会话。同一个人无论从 Web、App 还是飞书进入都应尽量归并为同一个参与者身份。这不是简单做一个“消息同步机器人”而是把外部渠道纳入同一套业务会话网络。对客户来说这意味着他们不必强迫所有人立刻迁移到同一个 App。平台可以先接住现有沟通入口再逐步把 AI、设备和流程能力带进去。对 SaaS 平台来说这也意味着更低的客户导入成本哪里有用户智能能力就可以延伸到哪里。十二、权限和安全真万物互联必须可治理当人和 AI 在会话中协作并能通过设备和外部平台通道读写现实世界时权限会变得更重要。因为这里不只是聊天还可能涉及设备状态、控制动作、客户数据、项目权限、AI 工具调用和跨渠道消息。如果没有清晰的权限边界“好用”很快会变成“危险”。联犀的思路是把权限治理放在几条链路里会话权限。用户是否能进入某个项目群、是否能看到某个设备相关消息要服从项目、区域、角色和组织权限。参与者权限。不是所有用户都能和所有 AI Clone 对话也不是每个 Agent 都能进入所有项目群。人和 AI 都需要参与者级别的准入判断并遵循各自的数据与工具权限。消息权限。设备告警、AI 分析、文件、图片、语音等内容进入会话后要继续遵守可见范围、免打扰和推送策略。动作权限。让 AI 生成建议是一回事让 AI 或用户通过会话控制设备是另一回事。设备控制必须经过物模型、产品能力和用户权限校验不能因为“在群里说了一句话”就绕过控制边界。渠道权限。设备通道要限制可读属性、可执行服务和控制范围外部沟通渠道要完成身份绑定、群映射和审计。未绑定人员可以接收哪些消息、能否触发动作、能否访问设备详情都要明确限制。真万物互联不是把所有对象无差别连起来而是让它们在正确权限下协作。联犀强调“可治理的会话网络”原因就在这里。十三、实施路径联犀如何一步步把愿景变成产品把人、AI Agent、设备通道和外部沟通渠道一次性全量打通听起来很美但工程上很容易失控。联犀没有从一张概念图开始讲“未来故事”而是沿着真实 IM、AI 和设备链路逐步落地。当前底座已经围绕人和 AI 参与者、AI 消息、主动回复事件、渠道上行抽象、设备通话资源和语音纯转发建立能力设备控制闭环与多 Agent 编排则在这套底座上继续演进。整个实施过程遵循一个原则每个阶段都能单独为用户创造价值同时又为下一阶段留下稳定接口。阶段 1先做好人与人的 IM 基座第一阶段聚焦最基础、最高频、最容易验证的能力单聊。项目群聊。会话列表。聊天记录。已读回执。撤回。文本、图片、语音、视频、文件消息。WebSocket 实时推送。这一步看起来普通但非常关键。因为后续 AI 回复、设备上行、渠道融合都要复用同一套消息、会话、未读和推送链路。阶段 2接入 AI Agent / Clone第二阶段让 AI 真正成为会话参与者人和 AI 单聊。群聊中 AI。AI 回复异步生成。AI 主动推送。ai_text 和 ai_card 消息类型。IM 会话和 AI session 映射。这里联犀优先选择服务边界清晰的方式IM 调用 AI 中台能力AI 回复再回到 IM 落库和推送。这样既符合微服务架构也保留 AllInOne 部署下的融合空间。阶段 3建立设备通道第三阶段让设备作为业务对象通过标准通道连接会话网络设备文本/媒体上行。设备渠道绑定。设备事件消息进入指定项目会话。人和 AI 发起的动作通过设备通道下行。设备语音通道和 Agent 端点预留。这一步的目标不是把设备变成群成员而是先建立稳定通道设备数据能进入会话消息来源能被识别控制动作能找到正确端点执行结果能被追踪。阶段 4实时音视频和设备语音第四阶段进一步支持高实时场景人和人音视频。人和设备实时语音通话。设备和 Agent 音频流对话。UDP / WebRTC / Agent 音频流转发。端口、NAT、资源回收和故障降级。这一步让“现场”不只停留在文字消息而是进入实时沟通。阶段 5建立 AI 设备控制闭环当设备通道已经接入会话、AI 已经能够理解上下文后下一步才是稳妥地开放执行能力从物模型生成可调用的设备 Tool Schema。AI 输出结构化执行计划不直接拼接设备协议指令。在设备服务中完成权限、参数、在线状态和幂等校验。按动作风险支持自动执行、会话确认、审批和双人确认。通过指令状态机跟踪待确认、执行中、成功、失败、超时和取消。设备属性和事件返回后验证业务目标是否真正达成。将意图、计划、授权、指令和回执关联到同一条会话时间线。这一阶段的完成标准不是演示中能把灯打开而是企业敢于把真实设备控制逐步交给 AI 辅助执行。阶段 6从单 Agent 走向多 Agent 协作多 Agent 能力建立在前面几层稳定能力之上建立 Agent 注册表描述每个 Agent 的角色、领域、工具和权限。由协调 Agent 或确定性规则完成任务路由避免所有 AI 同时响应。为一次复杂任务创建统一任务 ID 和多个子任务 ID。支持并行分析、结果汇总、冲突暴露、超时降级和人工接管。对 Agent 的输入、工具调用、依据、输出和成本进行观测。将已完成的协作案例沉淀到企业知识库和 Agent 记忆。这一阶段让群聊从“人问 AI 答”升级为“人定目标、多 AI 分工、设备通道反馈、系统闭环”。阶段 7渠道中心第七阶段把飞书、企微、钉钉等外部渠道纳入同一张网络外部渠道中的人员映射为 user 参与者。外部消息归一化为会话消息。内部消息按渠道下发。外部用户与内部账号绑定。客户群、项目群和平台群之间建立映射。最终联犀希望形成的是一张由人和 AI 共同参与、由设备与外部平台通道连接现实世界的业务协作网络而不是一堆彼此割裂的消息入口。十四、联犀方案的关键技术点为了避免文章只停留在概念层我们把联犀当前方案里的关键技术点整理出来。它们不一定是用户每天直接感知的功能但决定了产品能不能长期做厚。1. 单一 IM 服务网关统一暴露联犀将 IM 能力收敛到 imsvr对外 HTTP REST 和 WebSocket 由 apisvr 统一暴露。这样前端入口稳定鉴权、中间件和实时推送也能复用平台现有能力。好处是IM 不散落成多个小服务降低部署复杂度。Web、App、小程序可以面对统一入口。AllInOne、融合式宿主、微服务部署都能演进。2. Participant 抽象保持纯粹会话参与者聚焦 user 和 ai人负责提出目标、补充事实和最终决策AI Agent / Clone 负责理解、分析、编排和执行授权范围内的工具。设备身份放在业务对象和通道元数据中系统通知属于消息类型飞书、企微、钉钉属于渠道配置。这样新增一种设备或外部平台时不会污染参与者模型新增一种 Agent 时也能沿用会话成员、、上下文和权限机制。3. Message 类型扩展除普通 text、image、voice、video、file 外联犀为 AI 回复和设备通道事件预留了扩展类型例如 ai_text、ai_card并通过 extra 承载卡片、设备来源、渠道标注、工具结果等结构化信息。这让 AI 输出不局限于一段文字后续可以承载设备控制卡片、工单建议、知识库引用和风险解释。4. FastEvent 解耦IM、AI、设备之间不是处处同步调用而是通过事件总线解耦。比如新消息事件用于 WebSocket 推送。AI 主动回复事件用于 AI 结果回写会话。设备控制和设备通知可以通过事件进入对应服务。外部渠道上下行也可以通过事件主题扩展。这种方式能降低服务之间的直接耦合也更适合异步业务。5. InboundContent 渠道上行抽象设备、飞书、企微、钉钉等渠道进入 IM 时先统一成 InboundContent包含渠道类型、渠道 ID、内容类型、文本、媒体地址、归属用户、租户编码和去重 ID。IM 再把它转成站内消息。这样每个渠道只需要解决“怎么把自己的内容变成统一入站内容”不用关心 IM 内部消息链路。6. voice relay 纯转发语音链路中relay 只做音频帧转发设备 UDP 会话和浏览器 WebRTC Peer 或 Agent 端点之间建立连接。它不解码、不转码、不理解语音内容。这让语音链路更轻也让 AI 能力保持可替换。7. Agent 自包含端点设备和 AI Clone 对话时Agent 端点自己完成 ASR、LLM、TTS。IM 只把音频流转给 Agent再把 Agent 返回的音频流转回设备同时接收转写和回复文本落库。这个设计对私有化和大客户定制非常友好。客户可以使用联犀内置 Agent也可以接入自己的 Agent 服务。8. 权限沿链路透传会话、消息、设备通道和 AI 能力都要带上租户、用户、项目、角色等上下文。AI 参与协作、设备通道接入数据与控制动作时都不能绕过原有数据权限和设备控制权限。这也是企业级平台与玩具 Demo 最大的差异之一真正可落地的 AIoT必须能解释“谁能看、谁能问、谁能控、谁负责”。9. Device Tool Registry 与指令状态机物模型能力进入 AI 之前需要转换为经过审核的 Tool Schema并登记设备范围、参数约束、风险等级、确认策略和超时时间。AI 只能选择注册过的工具不能自由生成底层协议指令。每次控制都生成唯一指令 ID并通过状态机记录 pending_confirm、queued、executing、succeeded、failed、timeout、cancelled 等状态。幂等键防止重复执行超时和失败策略决定重试、降级还是转人工设备属性回读则负责验证最终结果。10. Agent Registry 与协作编排多 Agent 群聊需要一个可治理的 Agent 注册与路由层。每个 Agent 声明自己的领域、可见数据、可用工具、触发条件和输出类型协调 Agent 根据用户 、设备事件和任务意图选择参与者再通过任务关联 ID 汇总结果。编排层不替代专业 Agent 的判断而是控制谁在何时参与、上下文发给谁、等待多久、冲突如何展示以及何时交还给人。这样既能发挥并行分析的优势也能控制群聊噪声、调用成本和权限扩散。十五、客户能得到什么从客户视角这套方案最终带来的不是“多一个 IM 模块”而是几个非常具体的收益。1. 运维响应更快告警不再只是列表里的红点而是能进入项目群AI 可以主动总结影响范围现场人员可以直接在会话里反馈。信息触达、判断和处置都更短。2. 一线使用门槛更低很多一线用户并不愿意学习复杂后台。会话是天然熟悉的入口。让人和 AI 在会话中协作再把设备数据与控制能力通过通道接进来可以显著降低使用成本。3. 管理过程更透明谁看到告警、谁响应、谁处理、设备何时恢复、AI 给过什么建议都能沉淀在同一条时间线里。4. AI 更懂业务AI 不再只是孤立聊天框而是可以逐步获得会话、设备、项目、知识库和历史处置上下文。上下文越完整AI 越能给出贴近业务的回答。5. 平台扩展更稳后续新增设备、渠道、Agent、应用不需要推翻主架构。联犀通过纯粹的参与者模型、统一消息、标准通道和事件解耦为长期扩展留下空间。6. AI 从“建议者”变成“执行伙伴”用户不必看完 AI 建议后再进入多个页面手工操作。经过授权的低风险动作可以自动执行中高风险动作通过会话确认结果由设备实时回报。企业既获得自动化效率也保留必要的控制权。7. 复杂问题获得团队级智能诊断、能耗、安全、工单等 Agent 可以围绕同一个现场并行工作。企业不必期待一个模型懂所有业务而是可以持续增加和替换专业 Agent让智能能力像团队一样扩展。十六、典型行业场景智慧园区园区设备数量多、角色多、响应链条长。设备告警进入项目群后诊断、能耗和工单 Agent 可以并行分析值班人员确认方案后由执行 Agent 调整空调、照明或配电策略减少大量跨系统沟通。能源管理电表、水表、空调、照明等设备持续产生数据。AI 可以每天主动生成能耗摘要发现异常后推送到对应群组在授权范围内进一步联动多个设备执行削峰、错峰和节能策略并持续验证节能结果。工业设备运维工业现场更关注响应速度和责任追踪。设备异常事件通过通道进入会话后专家 Clone、生产 Agent 和安全 Agent 可以分别评估故障、产能与操作风险现场人员再根据综合方案处置形成完整记录。售货机和商业设备运营设备缺货、故障、离线、交易异常都可以进入区域运营群。AI 可以根据库存、交易和历史故障做优先级判断减少人工盯后台。客服与售后客户在企微或飞书反馈问题后消息可以进入联犀内部会话AI 先结合设备状态和知识库生成建议售后人员再确认并处理。客户不需要换沟通工具企业内部也能沉淀完整记录。十七、为什么联犀适合做这件事真万物互联不是单点功能而是平台能力的组合。它需要 IoT 设备接入能力需要 AI 中台能力需要 SaaS 多租户和多应用能力需要 WebSocket 实时推送需要权限体系需要消息与事件总线还需要面向私有化和定制客户的部署弹性。联犀的优势在于这些能力不是临时拼起来的core 承载 SaaS 中台、用户权限、AI 中台、通知、应用等基础能力。things 承载设备管理、产品物模型、协议脚本、MQTT、时序数据等 IoT 能力。IM 融合升级让人和 AI 在统一会话层协作并通过设备与外部平台通道连接业务现场。FastEvent、WebSocket、Redis、PostgreSQL / TimescaleDB 等基础设施支撑实时和历史链路。AllInOne、融合式宿主和微服务部署模式适配不同规模客户。这也是为什么联犀不是简单“给 IoT 平台加一个 AI 聊天框”而是在重构 AIoT 平台的交互方式。十八、结语AI 时代的平台入口会从“菜单”走向“协作网络”过去的平台入口是菜单。用户打开后台点设备管理、点告警中心、点数据报表、点工单系统。每个功能都存在但业务过程被切成很多块。AI 时代的平台入口会越来越像协作网络。用户进入一个项目、一个客户或一个工单就能看到相关的人、AI Agent、历史消息、设备实时状态和建议动作。平台不只是展示数据而是把业务现场组织起来。这就是联犀理解的真万物互联设备不只是在线而是能够感知、表达和执行AI 不只是回答而是能够分工、协作和在授权下行动人不只是操作系统而是提出目标、校正判断并掌握最终决定。当人和多个 AI Agent 能在同一个会话网络中协作并通过设备通道感知和影响现实世界每一次异常都可以成为一次协作每一次控制都可以形成闭环每一次处置都可以沉淀为组织记忆。联犀正在做的正是把 IoT 的连接能力、AI 的理解与执行能力、IM 的协作能力组合起来。让企业的物联网平台从“看得见”走向“做得到”再走向“越协作越聪明”。欢迎关注我们的开源项目联犀 things · Go 物联网开源模块提供设备接入、物模型、设备数据与 OTA 等基础能力。本文介绍的完整 AI 平台能力不等于该仓库的开源范围。https://gitee.com/unitedrhino/things欢迎点亮 Star也欢迎关注联犀持续分享AI物联网的开发进展、开源实践与应用案例历史阅读推荐一个 AIoT 物联网平台免费商用还能做自己的 SaaS每月电费花在哪这套智慧能源管理平台3D数字孪生看能耗AI查数据、辅助配置告警别再一笔笔画了WorkBuddy 几分钟搞定配电室组态CAD 一次图、2D 和 3D纯 Go 的 CAD 解析库 go-cad开源啦,dwg/dxf格式直接解析JEV 火了物联网怎么用附开源方案部署与测试纯 Go 实现的文档解析库 docling,开源了做物联网项目不必先买平台授权联犀私有化部署永久免费