平台总体架构
联犀把 SaaS、IoT 和 AI 组织到同一套基础平台中：SaaS 管理企业、应用、人员和业务范围，IoT 连接设备、现场数据与自动化，AI 在当前身份和业务上下文中使用知识与工具。行业产品复用这些能力，再实现自己的业务流程、界面和设备适配。
理解平台时，可以先沿总图观察产品、接入、能力、运行和支撑五部分，再进入对应专题查看真实调用链路。本文解释各部分为什么存在、如何协作，以及一个业务请求怎样得到结果。
放大查看 SVG ↗ · 下载 SVG · 下载高清 PNG
1. 为什么把三类能力放在同一基础平台
以一套园区运维应用为例，设备接入只是起点。企业需要开通应用，成员需要获得项目和区域权限；采集值要转换为可查询的业务数据；告警需要触发通知或后续处置；AI 查询设备历史时，还要沿用同一套设备语义和访问范围。
如果这些能力完全分散建设，项目、设备、人员与授权就会在不同系统里反复定义。联犀复用公共身份、应用管理、设备服务和运行基础，让行业模块把精力放在自己的计量口径、空间关系、通行规则及业务流程上。
| 能力域 | 核心对象与功能 | 对行业应用提供什么 |
|---|---|---|
| SaaS | 企业、成员、部门、应用开通、角色、资源动作、项目与区域范围 | 业务归属、入口条件和实际访问约束 |
| IoT | 产品、设备、物模型、接入协议、属性事件、状态历史、命令与回执 | 统一现场语义、设备数据与可控动作 |
| AI | Agent、Clone、CloneGroup、知识、会话、场景记忆、工具与执行空间 | 组织任务、查找依据、调用获准能力并返回结果 |
| 通用支撑 | 用户、通知、字典、定时任务、Hook、文件、缓存和事件 | 多个产品共同使用的业务与运行机制 |
| 行业模块 | 能源、停车及相应交付范围内的业务对象与规则 | 面向具体行业的页面、接口、统计和处置流程 |
三类能力可以组合使用。设备历史查询能够直接由业务界面完成；需要自然语言交互时，再由 AI 调用获准工具访问同一设备服务。
2. 沿总图理解五个部分
产品：用户最终交互的应用与终端
企业 SaaS、能源与楼宇应用、停车场景、数字孪生大屏、智能终端和自有业务系统位于产品侧。它们各有自己的界面与交互入口，使用哪些能力取决于实际产品组合。
例如，大屏主要消费状态、统计和实时消息；设备运维页面还会使用产品、物模型、OTA 与控制；自然语言助手需要额外组织会话、角色和工具。总图中的产品示例说明能力如何复用，不代表每个终端都包含同样功能。
接入：终端如何到达对应能力
业务应用主要通过 HTTP API、公开 SDK 和 WebSocket 使用平台。设备采用平台 MQTT / HTTP 协议，或经相应协议适配进入标准业务语义。媒体流、设备控制和会话消息按照各自协议处理。
开发端 Skills / CLI 为开发工具提供接入方法、模板和授权操作入口。它们服务于配置、开发与调试；平台运行时则使用已经配置的接口、工具和执行器处理实际请求。
能力：模块分别维护什么事实
SaaS 确认当前企业、应用和人员可访问的业务范围。IoT 维护设备身份、物模型、状态、历史和命令结果。AI 组织知识、会话和工具调用，行业模块维护自己的业务事实。
这些模块通过合同协作。例如，AI 能够描述一次查询需求，但设备所属项目、返回的数据和控制结果仍由实际业务接口确认。
运行：逻辑能力如何装入进程
后端以 Share 为公共基础，组合 Core、Things、IM 和行业模块。AllInOne、Cloud 与不同 Edge 入口选择实际注册的能力；服务也可以采用对应独立入口运行。
进程内 direct 客户端和跨进程 RPC 是两种调用方式。融合式入口可以减少部分网络装配，但其中仍可能保留按配置使用的 gRPC 依赖。具体关系见后端运行架构。
支撑：数据与运行状态存在哪里
业务记录、设备历史、对象文件、缓存和事件具有不同生命周期。当前部署生成器默认选择 PostgreSQL、PostgreSQL 时序路径、RustFS 和内置 MQTT；Redis、EventBus / NATS 及专项组件按实际服务配置装配。
默认生成组合中的业务库与时序连接可以指向同一 PostgreSQL 服务；架构上仍要区分业务记录和设备历史的职责。外接 EMQX、TDengine、其他对象存储和执行空间的选择见部署架构。
3. 贯穿各层的业务上下文
| 概念 | 回答的问题 | 典型影响 |
|---|---|---|
| 企业 | 当前业务数据归属哪家客户 | 成员关系、私有数据和企业配置 |
| 应用 | 当前使用什么产品及入口 | 企业开通关系、状态和有效条件 |
| 用户与角色 | 当前人员能够执行什么操作 | 查询、修改、管理与控制动作 |
| 项目与区域 | 当前操作覆盖哪些业务对象 | 设备列表、数据过滤与区域权限 |
| 产品与物模型 | 设备能够上报和接受什么 | 属性、事件、行为及参数约束 |
| 会话与角色实例 | AI 当前围绕什么任务工作 | 上下文、可用知识、工具和产物 |
这些上下文在各入口和业务操作中落实。界面选择了项目，仍需由服务端核对目标对象的真实归属；模型生成了工具参数，目标接口仍需检查动作与数据范围。
4. 三条典型业务链路
设备历史查询：直接从业务界面得到数据
人员打开项目设备列表后，客户端携带认证与应用上下文请求业务接口。服务端确认设备访问范围，再按字段、时间和查询条件读取对应历史仓储。页面展示真实记录、空结果或错误，并通过独立的实时订阅路径更新当前状态。
AI 查数据：在已有业务能力上增加任务组织
人员提出“查看本项目某设备一段时间的变化”后，AI 服务确认角色、会话和业务范围，按需要使用知识或工具。工具把设备与时间参数交给实际业务接口，接口沿用相应数据权限，结果返回会话后再组织说明。
检索知识解决的是资料依据，业务查询解决的是现场数据，两者可以共同支持回答。没有可用记录时，应明确说明数据缺口；查询失败时，应说明当前任务未完成。
设备控制：从业务意图到实际反馈
控制请求首先核验目标设备、动作权限和物模型参数，再由设备服务创建并下发命令。设备应答、属性反馈或超时结果按对应协议返回。界面和 AI 需要区分“已受理”“已应答”和“状态已变化”，不能用一次接口受理结果代替现场执行结果。
5. 扩展应用时如何选择边界
| 目标 | 优先复用 | 自己继续实现的内容 |
|---|---|---|
| 新增行业应用 | 身份、应用、权限、设备接口和通用服务 | 行业数据、规则、页面与流程 |
| 接入新设备 | 产品、物模型、标准消息和设备身份 | 原生协议对接或对应协议适配 |
| 增加 AI 业务能力 | 角色、知识、会话与工具调度 | 工具契约、参数、业务接口和结果核验 |
| 交付边缘产品 | 对应 Edge 宿主与本地依赖 | 现场组合、网络通路和实际离线范围 |
平台源码开发与独立应用开发使用不同路线。前者在授权的源码工程中维护模块与合同，后者在自己的应用仓中使用公开 SDK 和受保护接口。两条路线分别见平台开发和应用开发。
6. 按问题选择专题
想确认一个模块运行在哪个进程，阅读后端与部署架构；想知道一条数据为什么可读，阅读 SaaS 与权限架构；想知道消息如何到达现场，阅读 IoT 与云边架构；想知道工具在哪里执行，阅读 AI 架构。
架构专题导航
后端运行架构 · SaaS 与权限架构 · IoT 接入与数据架构 · AI 与工具执行架构 · 前端与客户端架构 · 云边协同架构 · 部署架构与组件选型
更新日志
2026/10/27 13:22
查看所有更新日志
c4a4b-于