AI 时代的真万物互联：人和多个 AI Agent 如何通过设备通道与外部渠道协作

约 13537 字大约 45 分钟

2026-07-21

凌晨两点，配电柜通过设备通道向值守群上报温度异常；诊断 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 有几个天然优势：

能力	对用户的意义	对 AIoT 平台的意义
会话	把相关人和事聚在一起	能承载人和 AI 的协作上下文
消息	按时间组织过程	能沉淀设备事件、AI 回复、人工处置
通知	让信息触达用户	告警、任务、AI 结论可实时到达
已读/未读	表达责任和响应	可追踪谁看过、谁还没处理
多媒体	支持图片、语音、文件	适合现场巡检、设备语音和证据留存
群组	支持人与多个 AI 协同	适合项目、区域和运维班组

因此，联犀没有把 IM 当成一个孤立的聊天模块，而是把它设计成 AIoT 的“会话层”。

设备管理解决“设备是谁、在哪里、能做什么”；AI 中台解决“如何理解、推理、生成和执行”；IM 会话层解决“人和 AI 如何围绕业务对象协作”；通道层解决“消息、数据和动作如何进出这个现场”。

这套思路带来的变化很直接：

用户不再只通过菜单找功能，而是通过会话进入业务。
AI 不再只回答抽象问题，而是进入项目、设备和人员上下文。
设备不再只是后台数据源，而是通过标准通道向会话上报事实、接受控制并反馈结果。
平台不再是功能堆叠，而是一个持续沉淀的协作网络。

这也是联犀做 IM 融合升级的根本原因：AIoT 平台的下一代入口，很可能不是传统后台菜单，而是围绕业务对象组织起来的智能会话。

四、第一步：分清参与者、业务对象和通道

要构建一个长期可演进的智能会话网络，底层首先要回答三个不同的问题：谁在协作？围绕什么协作？信息和动作从哪里进出？

联犀的边界很明确：人和 AI 是会话参与者，设备是业务对象与设备通道端点，飞书、企微、钉钉等是沟通通道。

层次	回答的问题	联犀中的对象	核心能力
参与者	谁在理解、表达和决策	`user`、`ai`	入群、发言、@、上下文、权限与责任
业务对象	大家正在讨论和处理什么	设备、项目、告警、工单	身份、状态、详情与业务关联
通道	消息和动作从哪里进出	设备、飞书、企微、钉钉、小程序	上下行适配、路由、身份映射与回执
消息	协作过程如何沉淀	人工消息、AI 回复、设备事件、系统通知	时间线、引用、关联、已读与审计

人和 AI 之所以是参与者，是因为它们会理解上下文、表达判断、承担任务或做出决策。一个项目群可以有多名工程师、管理者和多个专业 Agent，它们拥有明确身份，可以被 @，也有各自的可见范围和工具权限。

设备则通过设备通道进入业务现场。设备属性、事件和告警被通道适配为消息；AI 或人在会话中发起控制后，结构化指令再沿设备通道下发，执行结果通过同一通道回传。消息可以显示明确的设备来源，但这不意味着设备成为会话成员。

飞书、企微、钉钉也遵循同样原则。渠道中的真实人员经过账号绑定或身份映射后，仍然对应“人”这个参与者；飞书本身只负责承载消息的接收和发送，不是群聊里的参与者。

这个边界能避免模型越来越混乱：增加一种设备协议或外部沟通平台，只需增加通道适配；增加一种专业 Agent，才需要扩展参与者能力。用户最终感受到的是一个连续现场，系统内部却始终清楚“谁在协作”和“通过什么连接”。

五、第二步：把聊天、告警、AI 回复和设备上行统一成消息

明确参与者和通道边界之后，还要统一消息。

很多平台的问题是：同一个事件在不同系统里有不同形态。

设备离线，在设备系统里是一条设备事件；在告警系统里是一条告警；在通知系统里是一条通知；在 IM 里可能是一条文本；在 AI 系统里又是一段上下文。数据被拆得太散，用户追上下文很累，AI 也很难真正理解现场。

联犀把消息链路作为业务现场的时间线，尽量让不同来源的内容都能进入统一会话：

来源	用户看到	底层消息
人发消息	文本、图片、语音、文件	`text` / `image` / `voice` / `file`
AI 回复	AI 文本、AI 卡片	`ai_text` / `ai_card`
设备上行	设备状态、属性、事件、截图	由渠道上行转成站内消息
系统行为	入群、撤回、状态变化	`system`
外部渠道	飞书/企微/钉钉消息	归一化后进入内部会话

这样做之后，用户看到的不只是聊天记录，而是一条完整的处置链：

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 不负责理解设备协议，也不承担飞书、企微等平台的专有逻辑。

更具体地说：

组件	做什么	不做什么
`imsvr`	会话、参与者、消息、未读、推送、渠道转发、呼叫信令	不做 ASR/TTS/LLM，不理解设备协议
`aisvr` / 外部 Agent	ASR、LLM、TTS、工具调用、AI 记忆、知识库	不承担 IM 消息主链路
`dmsvr` / things	设备接入、物模型、协议帧、MQTT/UDP、设备控制	不做会话系统
`apisvr`	HTTP / WebSocket 网关、鉴权、前端入口	不承载核心业务状态
FastEvent	事件解耦和异步通知	不直接绑定前端体验

这套边界听起来偏技术，但对产品长期演进非常关键。

如果明天要接一个新的外部 Agent，只需要注册新的 Agent 端点；如果后天要接一个新设备协议，只需要在设备侧做协议适配；如果大客户要把飞书群、企微客户群接进来，也是在渠道层扩展，而不是把 IM、AI、设备三套系统一起改。

用户感知到的是“一个入口”，但平台内部保持清晰分工。这是联犀能够同时服务 SaaS 托管、私有化部署、定制应用和源码授权客户的重要基础。

七、AI Agent 的落地方式：既能被 @，也能主动出现

AI Agent 进入业务现场，至少要解决四个产品问题。

第一，怎么开始对话？

用户可以和 AI 单聊，也可以在项目群里 @AI。比如：“@AI助手今天设备有什么异常？”系统识别会话中的 AI 参与者，触发 AI 回复。

第二，怎么拿到上下文？

AI 不应该只拿到用户刚发的一句话，而要逐步获得会话上下文、设备上下文、项目权限、知识库资料和历史处理记录。当前链路先从 IM 消息和会话映射开始，后续可继续注入设备状态、物模型属性、告警历史和知识库召回结果。

第三，怎么避免阻塞用户？

用户发消息后，发送接口应该立即返回，不能等大模型慢慢生成。联犀采用异步链路：用户消息先落库，后台调用 AI，AI 回复生成后再作为新消息推送到会话。

第四，AI 能不能主动提醒？

真实业务里，很多时候不是用户先问 AI，而是设备告警、定时巡检、预测分析先发生。联犀通过事件总线支持 AI 主动回复：业务侧发布 im.ai.reply，IM 订阅后把 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. 不同风险，采用不同授权方式

不是每个动作都需要弹窗确认，也不是每个动作都应该自动执行。联犀可以按照设备类型、动作风险、使用场景和用户角色建立分级策略：

风险等级	典型动作	建议策略
低风险	查询状态、调整灯光亮度、播放提示音	在用户授权范围内自动执行
中风险	调整空调温度、设备重启、切换运行模式	会话卡片确认，关键参数清晰展示
高风险	开门、停机、断电、修改安全阈值	强身份校验、审批或双人确认
禁止自动化	涉及人身安全或法规明确限制的动作	AI 只提供建议，必须由人工系统执行

用户感受到的是“越用越省事”，企业获得的却不是一个失控的自动化入口，而是一套能按业务风险逐步放权的机制。

4. 设备回执不是一句“已执行”，而是结果验证

指令成功下发，不代表业务目标已经达成。

例如 AI 把空调设为 24℃，设备返回“设置成功”，但十分钟后室温仍然升高，真正的问题可能是制冷故障、门窗未关闭或传感器异常。因此，控制链路还要持续观察目标属性，判断结果是否符合预期。

一次可信的设备控制至少应留下这些信息：谁提出目标、哪个 AI 生成计划、谁确认、控制了哪台设备、下发了什么参数、设备如何回执、状态是否达到预期、失败后如何处理。

这些记录会以结构化消息和时间线沉淀在会话中。主管看到的不再是难以理解的调用日志，而是一份完整的行动说明。

5. AI 可以操作设备，但不能绕过设备平台

这是联犀方案里非常重要的边界。

AI Agent 不直接连接每一种设备协议，也不绕开设备服务向 MQTT 或 UDP 随意发包。Agent 只调用经过注册的标准工具；工具请求携带用户、项目、会话和授权上下文；设备服务继续负责物模型校验、在线状态判断、协议转换、指令下发和结果回执。

这样，AI 获得了操控现实世界的能力，平台仍然保留确定性控制。AI 负责聪明，设备平台负责可靠，人在关键节点保留最终决定权。

九、群聊里的集群智慧：人和多 AI 如何调用设备通道解决问题

一个 AI 助手可以回答问题，却很难同时精通设备诊断、能耗优化、安全规范、库存调度和客户沟通。

真实企业本来就是靠团队协作运行的。AI 进入企业之后，更合理的形态也不是制造一个无所不能的“超级助手”，而是让多个有明确职责的 Agent 像专业成员一样进入群聊：各自使用不同知识、工具和权限，在同一个业务上下文中协作。

一个典型的园区运维群，可以由不同参与者和通道共同支撑：

协作要素	类型	在现场中的职责	能使用或提供的能力
值班人员	人类参与者	提出目标、补充现场信息、确认高风险动作	会话、审批、设备查看与控制
诊断 Agent	AI 参与者	分析故障原因和关联设备	实时数据、历史告警、故障知识库
能耗 Agent	AI 参与者	评估能耗与生产影响	时序数据、基线模型、费率策略
安全 Agent	AI 参与者	检查操作风险和合规要求	安全规则、操作票、风险策略
工单 Agent	AI 参与者	拆解任务并跟踪闭环	工单、排班、备件和通知工具
协调 Agent	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
    ⇅ WebRTC
imsvr relay
    ⇅ UDP Opus
设备

这里的重点是“纯转发”：IM 不做语音识别，不做语义理解，只负责把浏览器侧 WebRTC 音频和设备侧 UDP Opus 帧接起来。这样延迟更低，边界更稳，也便于在私有化环境里部署。

3. 设备和 AI Clone 对话：让设备能“连到智能”

另一类场景是设备直接和 AI Clone 对话。

比如一个语音设备被唤醒后，用户对它说：“查看今天能耗异常。”设备把音频流送入 IM，IM 再把音频流转发到 Agent 端点。Agent 自己完成 ASR、LLM、TTS，然后把回复音频返回设备，同时把转写文本和 AI 回复沉淀到会话记录。

设备
    ⇅ UDP Opus
imsvr 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 结果回写会话。
设备控制和设备通知可以通过事件进入对应服务。
外部渠道上下行也可以通过事件主题扩展。

这种方式能降低服务之间的直接耦合，也更适合异步业务。

联犀的优势在于，这些能力不是临时拼起来的：

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 的协作能力组合起来。让企业的物联网平台从“看得见”走向“做得到”，再走向“越协作越聪明”。

更新日志

2026/8/4 15:04

查看所有更新日志

7e927-文档站全面重构：目录重排、首页重写、案例独立成站、应用市场下线于 2026/8/4
3bc7e-docs: 同步设备接入文档更新与万物互联系列博客于 2026/7/24
9e46a-文档：将万物互联文章流程图改为静态图片于 2026/7/21
871f5-docs(blog): 将文章插图恢复为 PNG 格式于 2026/7/21
a46b0-Merge #11 into master from docs/blog-aiot-agent-more-images于 2026/7/21
612f7-docs(blog): 完善万物互联文章视觉叙事于 2026/7/21
7f98d-docs(blog): 补充万物互联场景插图于 2026/7/21
96e76-Merge #10 into master from docs/blog-aiot-agent-channel-27于 2026/7/21