AI + IoT 新时代：万物互联平台应该长什么样？

约 12017 字大约 40 分钟

2026-07-09

从"连设备"到"用智能"——一个第三方视角看企业级 AIoT 平台该怎么选、怎么落

一、万物互联，到了该"算账"的时候

过去十年，物联网行业最骄傲的成就，是把越来越多的设备连上了平台。电表、水表、空调、照明、传感器、售货机、工业控制器……企业后台里的设备数量逐年增长，数据曲线也越来越多。

但一个越来越明显的现实是：连上来之后，很多设备数据并没有真正产生业务价值。

平台能看数据、能设规则、能发告警，但一线业务人员不会用、不敢用；管理层想要一个结论，往往需要技术部门先写脚本、做报表；设备出了问题，运维人员要在多个页面之间切换排查。最终，平台成了"能看不能用"的电子看板，设备连接数成了漂亮的数字，但业务效率的提升却很有限。

AI 的出现，正在改变这个局面。但这里有一个关键的分歧：给物联网平台加一个聊天窗口，不等于 AI 化。

很多企业把大模型接入后台，以为这就完成了"AI 转型"。结果往往是：模型能回答一些通用问题，但看不懂企业的设备、进不了真实业务流程、不敢执行实际控制。最后 AI 成了一个独立的"花瓶功能"，与一线操作仍然割裂。

真正的新时代万物互联平台，评价标准不再是"连了多少设备"，而是 "设备有没有变成企业可用的智能"——能不能被一线人员自然调用、能不能进入真实业务流程、能不能持续沉淀为企业自己的平台能力。

从外部观察，联犀正是朝着这个方向构建的一套 AIoT 原生平台。它不是给传统物联网平台加一层 AI 界面，而是重新思考：在 AI 时代，企业级物联网平台到底应该怎么长。

如果要用一句话概括联犀的核心差异，那就是：它把设备、数据、权限、AI 能力整理成同一套可被企业持续运营的语言，而不是把 AI 当成一个外挂插件。

本文将从第三方视角，结合联犀的真实架构设计和落地经验，拆解一个新时代 AIoT 平台应该具备的五个关键特征：

AI SaaS 化交付：让企业低门槛起步、按阶段扩展。
多应用 + 分层权限：平台像应用市场一样可生长，权限像基础设施一样可治理。
AI 真正理解设备：用物模型 + MCP 把自然语言意图落到具体设备控制。
从告警通知到告警理解：用条件树、状态机、通知阶梯和 AI 解读提升运维效率。
安全可控的扩展能力：协议脚本、自然语言联动、AI 代码执行都在受控边界内。

下面逐节展开。

二、AI SaaS：让企业低门槛获得平台能力

行业痛点

企业要上 AIoT，传统路径往往是：买设备、搭平台、养团队、做集成。投入大、周期长，中小企业很难承受，大企业也要面对漫长的试错过程。更麻烦的是，很多企业还没验证清楚业务价值，就已经被平台建设成本拖住了。

关键判断

传统 IoT 平台往往采用"一次性建设"模式：先立项、再采购、再开发、再上线，周期长、投入大、试错成本高。一旦业务方向调整，前期投入很难回收。

AIoT 平台能力的交付方式，应该从"一次性建设"转向"按需订阅"。企业应该能够先从一个具体场景、几台设备开始，验证价值后再逐步扩展，而不是一上来就投入一个庞大的平台建设项目。部署形态也应该随阶段演进，而不是在创业第一天就按大型集团的架构去搭建。

联犀的具体做法

联犀提供了四种合作模式，覆盖从轻量化试用到深度掌控的不同需求：

对大多数企业来说，SaaS 托管是最值得关注的起点：初始成本低、按需订阅、不需要自建运维团队。而对数据边界和部署环境有更高要求的大客户，则可以选择私有化或混合部署。

更重要的是，联犀的多客户隔离不是一刀切的。从小客户共享资源，到大客户独立部署，可以按客户分层逐步演进。平台公共数据（比如协议模板、公共字典）可以共享，企业私有数据（设备、交易、报表）严格隔离，互不干扰。

部署形态的弹性

联犀后端采用 Go Workspace 组织：core 负责 SaaS 中台与 AI 中台能力，things 负责物联网平台能力，share 负责公共基础库，mall 负责商城相关能力。这种模块划分先把代码世界的边界稳定下来，再让部署形态可以随阶段变化。

基于这套边界，联犀同时支持三种部署模式：

AllInOne：所有能力运行在同一个进程里，适合 POC、初创企业或私有化轻量部署。
融合式宿主：把高耦合、高吞吐的 IoT 能力（如 dmsvr）收敛到同一宿主，减少跨进程跳转；SaaS 中台能力可以独立部署。
微服务：各模块独立部署、独立扩缩，适合大型集团或业务边界高度稳定的场景。

这种设计的本质是：业务边界稳定，但部署方式灵活。上层业务代码面对的是稳定接口，底层实现既可以是 gRPC 客户端，也可以是进程内 direct 调用。部署模式不再决定业务代码长什么样。

真实场景

场景一：能耗管理 SaaS

一个平台可以同时服务多个园区、楼宇客户。A 客户只能看到 A 客户的电表、区域和能耗报表；B 客户只能看到 B 客户的。平台运营方则在后台统一维护公共模板和升级能力。每个客户都像拥有一个独立的能源管理系统，但运营成本被摊薄了。

场景二：自动售货机运营

不同运营商作为独立客户接入平台，各自的设备、商品、交易数据相互隔离。平台统一提供设备监控、补货提醒、OTA 升级、运营分析等能力。运营商不需要自己开发后台，只需要专注业务运营。

可量化收益

根据联犀智慧能源管理方案中的客户价值数据：

人工成本降低 50% 以上：7×24 小时自动监测替代了大量人工巡检和值班。
AI 版方案在标准版基础上再降低 30%：AI 智能助理、工作流、预测分析进一步减少人工干预。
故障响应从"小时级/事后"变为"秒级/事前"：预告警技术手段让问题在发生前被发现。
起步周期从数月缩短到数天：SaaS 模式下，企业不需要等待平台开发完成，接入设备后即可使用核心能力。

对老板来说，这种模式的本质是把平台建设风险从"一次性押注"变成"按效果付费"。

三、多应用架构：平台不是大杂烩，而是应用市场

行业痛点

很多物联网平台的问题，是功能越堆越多，菜单越来越长，但不同客户真正需要的只是其中一部分。更糟糕的是，大客户有个性化需求时，往往只能侵入主版本做定制，导致主干越来越臃肿，升级越来越困难。

关键判断

很多 IoT 平台的做法是"功能堆砌"：客户需要一个功能就加一个菜单，久而久之后台变成一个 labyrinth。更糟的是，大客户有个性化需求时只能侵入主版本做定制，导致主干臃肿、升级困难、定制客户和标准化客户互相拖累。

企业级市场不是单一应用。一个平台要服务多个客户，每个客户内部又有不同角色，不同角色使用不同终端。如果平台从第一天就没有把多客户、多角色、多端复用考虑进去，后面每扩展一个场景都要伤筋动骨。

好的平台架构，应该像应用市场一样：统一底座之上，长出多个独立应用，每个应用有自己的菜单、入口和业务逻辑。多客户隔离也不能只停留在"加一个字段过滤"，而要能回答同一企业内部的复杂权限问题。

联犀的具体做法

联犀采用了"多应用"架构。平台里的每个应用，都是独立定义、独立订阅、独立菜单、独立入口的。客户可以按需订阅自己需要的应用。通用应用服务所有客户，定制应用服务个别大客户，而被验证有价值的定制能力，又可以沉淀为新的通用应用，服务更多客户。

同一套后端能力，可以支撑 Web 管理后台、移动 App、微信小程序、原生客户端等多种入口。

多客户隔离不是一条 `tenant_code` 那么简单

提到多客户，很多系统的第一反应是 tenant_code。这当然没错，但如果一个系统真正进入复杂业务阶段，只靠 tenant_code 很快就会不够用。因为它只能回答"这条数据属于哪个企业"，却回答不了"同一企业里的不同用户应该看到哪些项目、哪些区域、哪些设备"。

联犀把数据权限拆成三个层次：

基础隔离层：通过共享数据类型和统一读写语义，把企业边界下沉到持久化约束里。普通企业数据、公共共享资源、平台保留资源采用不同的企业语义，而不是一刀切。
用户上下文层：把项目、区域、角色、管理员身份以及当前请求的业务范围，组织成后续链路都可以复用的权限输入，沿 HTTP、RPC、消息总线继续透传。
查询裁剪层：通过查询配置与 dataFilter Hook 的组合，把权限从用户上下文翻译成查询条件。配置负责稳定的结构化规则，Hook 负责依赖业务上下文的动态裁剪。

举个例子：一个园区管理员只能看到本园区某些区域的设备。这个限制不是在每个接口里手动拼 where 条件，而是由用户上下文层携带"可见区域树"，查询裁剪层自动把区域范围注入到设备查询、告警查询、报表查询中。

真实场景

场景一：智慧照明与智能家居

同一套 IoT 底座上，可以长出两个完全不同的应用：一个是面向楼宇和园区的智慧照明应用，管理能耗、场景、告警；另一个是面向家庭的智能家居应用，管理灯光、空调、窗帘、安防。它们共享设备接入、物模型、权限等底层能力，但前端体验和业务逻辑完全独立。

场景二：能耗中心

能耗中心本身作为一个独立应用，包含设备空间、能耗分析、电力集抄、预付费管理等模块。客户按需订阅，不需要的客户不会看到这些菜单，界面更简洁。

场景三：工业大客户私有化品牌控制台

当某个工业大客户需要独立品牌、独立入口时，可以基于平台能力生成一个定制应用。这个定制应用不会影响主版本演进，后续升级也可以独立进行。

可量化收益

标准化规模交付 + 大客户个性化定制并存：不会因为一个定制需求就污染主版本。
能力可沉淀复用：被验证的定制能力可以变成新的通用应用，服务更多客户。
多端开发成本降低：同一套后端支撑 Web、App、小程序、原生客户端，不需要为每种终端重新开发一遍。
权限复杂度集中治理：三层权限模型让新增权限场景变成配置和扩展点问题，而不是业务代码复制问题。

四、AI 让平台变"会说话"

行业痛点

企业级平台有一个通病：功能越完整，用起来门槛越高。很多一线人员面对复杂的菜单和报表，不知道点哪里，最后只能依赖技术部门帮忙。结果是，平台买了、设备连了，但真正的使用者只有少数几个技术人员。

关键判断

很多企业级系统的思路是"把菜单做简单""把报表做丰富"。但问题是，功能越完整，菜单必然越长，报表必然越复杂。一线人员真正需要的，是在现场、在会议室、在巡检途中，用一句话或一条语音就能拿到结果。

降低平台使用门槛的关键，不是把菜单设计得更简单，而是让一线人员能够用自然的方式调用平台能力。文字或语音应该成为新的交互入口。

但这有个前提：AI 必须真正理解企业的业务对象和设备语义，而不是只能回答通用问题。否则就会出现"AI 能聊天但不敢控制设备"的尴尬局面。

联犀的具体做法

四层语义对齐

AI 控设备真正的难点，不是"能否发出一次控制调用"，而是四套语义系统能不能对齐：自然语言意图、平台工具定义、设备物模型、运行时上下文。

联犀的做法是：

物模型作为统一语义层：定义设备有哪些属性、行为，哪些只读、哪些可写，值域和单位是什么。
MCP 把设备能力组织成可推理工具：不是暴露一个泛化的"执行命令"入口，而是拆成获取设备列表、查询物模型、读取属性、控制属性、触发行为等工具。
上下文自动注入：通过 _sessionID 把会话稳定落到正确设备，AI 中台不内嵌 IoT 概念。
执行层守住边界：控制属性时过滤只读字段，触发行为时限定为物模型显式声明的 action。

一个具体例子

用户说："打开东区照明。"

系统内部的处理链路是：

AI 识别意图：控制 + 区域（东区）+ 设备类型（照明）。
调用"获取设备列表"工具，按区域过滤出东区照明设备。
调用"查询物模型"，确认这些设备有"开关"属性，且可写。
调用"控制属性"，把 power 设为 true。
执行层再次校验：该属性在物模型中是否可写？用户是否有该区域设备控制权限？
返回结果给用户："已打开东区 12 盏照明灯。"

技术层面，联犀的 AI 智能助理基于大模型对话引擎 + 知识库联动，支持 SSE 流式响应和多轮上下文理解。对于语音场景，采用 TTS + ASR 双引擎。

真实场景

场景一：小智语音硬件

现场巡检人员不需要掏出手机点开 App，直接对设备说"打开东区照明""查询配电室当前温度"，系统就能理解意图并执行。这种 hands-free 的体验，在工业现场、仓库、机房等场景非常实用。

场景二：能耗管理

管理层不需要等技术人员做报表，直接问"本月哪个区域用电异常""对比上周同期趋势如何"，AI 就会从时序数据中提取信息，生成分析结论。固定报表依然存在，但旁边多了一层更灵活的 AI 分析能力。

场景三：自动售货机

运营人员问"哪些机器需要补货""昨天哪台机器故障最多"，AI 直接返回结果，不再需要切换多个后台页面逐个查询。

可量化收益

平台实际使用率提升：系统不再只是"能跑"，而是真正被一线人员用起来。
技术人员负载降低：大量查询、报表、简单控制不再需要技术部门介入。
决策效率提升：管理层可以直接获得分析结论，不需要等待报表制作。

五、从"告警通知"到"告警理解"

行业痛点

传统告警系统的逻辑很简单：设备数据超过阈值，就发一条通知。但在真实业务里，这只是开始。

运维人员收到告警后，还要判断：这条告警重要吗？类似的情况以前发生过吗？可能的原因是什么？要不要立刻处理？在告警量大的场景下，这些判断非常消耗人力，也容易遗漏关键问题。

关键判断

传统告警系统的逻辑是"阈值触发 → 发通知"。但通知只是开始，运维人员还要判断重要性、查历史、找原因、定优先级。告警量一大，人就被淹没在通知里，反而更容易漏掉关键问题。

现代告警系统不应该只回答"发生了什么"，还应该回答"这意味着什么""以前发生过吗""建议怎么处理"。告警应该从"通知"升级为"可被理解的业务事件"。

联犀的具体做法

可视化条件树

联犀的告警系统 v2 用可视化条件树统一表达复杂触发策略，支持四类判据：

普通条件：一组叶子条件的 AND/OR 组合。
持续时长：子判据在持续时长内一直命中才输出 true。
k-of-n：N 个子判据中至少 K 个命中时输出 true。
滚动聚合：对子判据在滚动窗口内聚合后再比较。

四级告警与通知阶梯

告警事件有完整的状态机：正常 → 报警激活 → 已确认 → 恢复中 → 正常，同时支持已屏蔽和虚警标记。通知阶梯按告警持续时间和级别递进，支持短信、邮件、电话、微信、企业微信、钉钉、飞书、接口回调等多种渠道。

一个地质灾害监测的告警配置示例

假设监测一座边坡，预警规则可以这样配：

触发条件 1（蓝色/注意）：普通条件，位移速率 > 2mm/d，且有效雨量 > 30mm。
触发条件 2（黄色/警示）：持续时长，位移速率 > 5mm/d，且持续 10 分钟。
触发条件 3（橙色/预警）：k-of-n，5 个位移测点中 ≥3 个速率 > 5mm/d。
触发条件 4（红色/警报）：滚动聚合，最近 1 小时内位移累计变化 > 20mm。

通知阶梯：

阶梯 1：蓝色/黄色告警触发后 0 秒，短信通知现场值班员。
阶梯 2：橙色告警触发后 0 秒，企业微信通知值班组长；若持续 5 分钟未恢复，电话通知部门负责人。
阶梯 3：红色告警触发后 0 秒，同时短信、电话、钉钉通知应急指挥组，并触发接口回调到应急系统。

更重要的是，告警触发后，AI 可以解读告警含义、关联历史案例、基于企业知识库给出处置建议。

真实场景

场景一：地质灾害监测

传感器触发位移或雨量告警后，AI 可以结合多源数据辅助判断预警级别和影响范围。比如根据位移速率、有效雨量、地下水位、孔隙水压力等参数，输出蓝色（注意）、黄色（警示）、橙色（预警）、红色（警报）四级预警，帮助决策者更快做出响应。

场景二：工业自动化

当大量设备告警同时涌入时，AI 先做关联分析和收敛，把"告警风暴"变成几条有优先级的处置线索，减少运维人员的认知负担。

场景三：能耗管理

配电室温度越限后，AI 不仅告诉运维人员"温度高了"，还会自动查询关联设备、建议调控动作，甚至直接下发控制指令。

可量化收益

单一企业支持至少 1000 条启用规则并发评估。
通知发送延迟：核心渠道在触发后 5 秒内进入发送队列。
故障响应从小时级变为秒级。
运维人员从被动响应转向主动理解。

六、从"写规则"到"说需求"

行业痛点

场景联动是物联网平台的核心能力之一。传统方式是：用户手动配置"如果 A 发生，就执行 B"的固定规则。这种方式在简单场景下够用，但遇到需要多条件组合、动态参数计算、跨系统调用的复杂逻辑时，就只能靠开发定制。

关键判断

传统联动规则的配置方式是"如果 A 发生，就执行 B"。简单场景够用，但遇到多条件组合、动态参数、跨系统调用时，就只能找开发定制。结果是：业务人员提需求 → 开发排期 → 测试上线 → 业务又变，循环往复。

未来的自动化能力，应该让业务人员用自然语言描述需求，由 AI 自动转化为可执行的任务。这相当于把"开发定制"的能力，下放给了业务人员。但前提是执行过程必须有安全边界，否则企业不敢真正使用。

联犀的具体做法

自然语言 → 任务流 → 安全执行

联犀的做法是让业务人员用自然语言描述规则，AI 自动解析为定时任务 + 条件判断 + 设备控制动作。更复杂的动作，可以由 AI 自动生成执行代码，在受控环境中运行。

协议脚本处理异构设备

设备协议千差万别。联犀在设备上下行链路里预留了四类协议脚本扩展点，用 Go + yaegi 解释器运行：

上行前处理：设备上来的报文可能是私有字段、压缩结构、网关聚合结构，在这个阶段做转换，平台后续拿到的是标准消息。
上行后处理：处理联动、通知、补数等副作用。
下行前处理：把平台指令映射成设备实际接受的字段、结构和 topic。
下行后处理：记录审计、做二次联动或补充通知。

脚本不是任意进程内代码执行，而是在受控符号表里使用预先开放的包，并且按产品级/设备级绑定、企业隔离、在线调试、panic 恢复等机制治理。

PicoSandbox 安全边界

AI 生成的代码在 PicoSandbox 中运行，安全边界包括：

namespace 隔离：独立的 mount、pid、user、net namespace，沙箱内只能看到 /workspace。
cgroup 资源限制：默认 256MB 内存、64 进程、50% CPU。
NetworkProxy 网络过滤：内网 IP 拒绝，外网透明转发，防止 DNS rebinding。
seccomp 系统调用白名单：禁止 mount、reboot、unshare 等危险调用。

真实场景

场景一：智能家居

家庭用户不需要学习复杂的规则配置，用一句话就能定义全天的温控策略。

场景二：能耗管理

峰时段自动调低非关键设备负荷，谷时段给储能充电；当能耗突增时，自动诊断原因、定位异常设备、下发调控指令。整个过程不再需要人工逐个配置。

场景三：设备联动

设备 A 上报某个属性满足条件时，AI 自动将计算结果写入设备 B 的云端属性。这种跨设备的计算联动，过去需要写代码，现在可以用自然语言描述。

可量化收益

自动化能力从"开发定制"变成"业务人员自助配置"。
需求响应速度大幅提升：不需要等待开发排期。
复杂策略的落地门槛降低：多条件组合、动态参数、跨系统调用不再需要专业开发。
设备协议异构性被脚本机制吸收：核心服务演进节奏不被项目化定制拖住。

七、大屏与组态：从"手工作坊"到"模板 + AI 生成"

行业痛点

数据大屏和工业组态，是很多物联网项目的交付标配。但传统做法需要专业人员手动拖拽组件、配置数据源、调整样式，一个项目可能要数天甚至数周。更糟糕的是，每次领导视察或客户需求变化，都要重新调整。

关键判断

传统大屏和组态项目是"手工作坊"：专业设计师手动拖拽组件、配置数据源、调样式，一个项目数天到数周。更麻烦的是，数据源一变、设备一增，大屏就要返工。

大屏和组态的交付，应该从"手工作坊"转向"模板化 + 智能化"。平台应该提供开箱即用的模板，自动对接设备数据，并用 AI 辅助完成配置调整。理想情况下，业务人员只需要选模板、确认数据集、微调样式，就能完成过去需要专业人员做的事。

联犀的具体做法

三段式大屏生成流程

联犀在这个环节做了大量简化：

模板选择：平台内置多种大屏模板，比如 IoT 监控大屏、能源管理大屏等。
数据集自动对接：数据集能自动对接设备属性，减少手工配置。
AI 辅助生成配置：AI 可以辅助生成组件配置、数据过滤逻辑和适配脚本。

数据源体系

联犀大屏支持五类数据源：

STATIC：静态数据，适合演示和原型。
AJAX：HTTP 接口，适合对接外部系统。
Pond：共享数据池，多组件复用同一数据请求。
DataQuery：对接联犀统一数据服务，自动继承权限和物模型语义。
MQTT：实时推送，适合 IoT 实时数据（规划中）。

DataQuery 配置示例

一个"设备在线状态概览"大屏的数据集配置可以这样设计：

# 大屏数据集配置示例（示意）
sourceType: DataQuery
code: device_status_overview
filter:
  projectID: "${currentProject}"
  regionPath: "${currentRegion}"
columns:
  - deviceName
  - onlineStatus
  - lastReportTime
  - alarmCount
aggregations:
  - field: onlineStatus
    type: count
    groupBy: onlineStatus

这个配置的核心是：大屏查询不走一次性统计接口，而是走联犀统一的 DataQuery 服务。企业、项目、区域这些权限条件会自动注入，查询结果可以直接映射到组件上。

自定义组件与数据清洗

对于自定义组件，联犀支持 Adapter 机制把 DataQuery 返回的标准数据转换成组件需要的格式。用户还可以写 JS 过滤脚本对数据做二次清洗，脚本在 Web Worker 沙盒中执行，避免访问 DOM 和 window 对象。

真实场景

场景一：智慧照明能源大屏

快速生成包含区域用电排行、功率趋势、设备状态概览、告警信息的总览大屏，用于领导汇报和值班监控。

场景二：工业自动化组态

快速构建产线监控、配电图、一次图等组态画面。企业还可以按需扩展自定义组件，适配自己的设备和工艺流程。

场景三：能耗管理汇报

领导视察时，可以一键切换默认大屏和自定义大屏，不用临时重新配置。

可量化收益

大屏/组态从"数周交付"压缩到"数小时交付"。
不需要每次都依赖专业设计师。
模板化能力可以沉淀复用，不同项目快速复制。
DataQuery 自动继承权限模型，避免每个大屏单独写查询和权限判断。

八、拓展能力：知识、工具与安全执行环境

行业痛点

企业在把 AI 投入实际生产时，通常有三个顾虑：

AI 回答不准：通用大模型不懂企业的设备、流程和业务知识。
能力无法复用：每次都要重新对接接口，AI 能力不能沉淀。
不敢上生产：AI 生成的代码如果直接执行，可能存在安全风险。

关键判断

通用大模型进入企业后，最常遇到的三个问题是：回答不准（不懂企业设备/流程）、能力无法复用（每次都要重新对接接口）、不敢上生产（AI 生成代码直接执行有风险）。

一个真正可用的 AIoT 平台，必须同时解决"知识、工具、安全"三个问题。AI 要有企业知识，要有可调用的标准化能力，还要在受控环境中执行。三者缺一不可。

联犀的具体做法

时序数据底座：TDengine 与物模型映射

AIoT 平台要处理海量设备时序数据。联犀没有把 TDengine 当作"第二个业务库"，而是把它定位为设备历史与指标分析的时序执行层。设备、产品、项目、区域这些主数据仍然留在关系模型里；高频属性值、状态变化轨迹、日志类记录进入 TDengine。

表结构不是先设计一堆表再让设备数据适配，而是从物模型反推：

简单类型（布尔、数值、字符串）：直接映射为单值列，按设备实例化子表。
结构体类型（如三相电参、定位）：按子字段展开为多列，保留子字段级查询能力。
数组类型：通过额外标识元素位置或维度的方式保留可拆解能力。

写入路径采用异步批量聚合，而不是每条属性上报都同步写库。平台先把写请求送入异步通道，再按批量大小和时间窗口做聚合，最后以批处理方式提交到 TDengine。这样做的好处是：设备主链路不用长期阻塞在数据库 I/O 上，多设备、多属性的碎片化写入被合并成少量批次，还能在批量层面统一处理回压、重试和日志分流。

查询侧，TDengine 被纳入联犀统一数据服务。调用方面对的是统一查询入口，而不是必须知道底层走了 GORM 还是 TDengine 原生执行器。企业、项目、区域这类权限模型也能继续沿用统一注入思路。

AI 中台四层模型

联犀把知识、工具和安全执行环境都纳入了平台能力体系：

AgentGroup → Agent → Clone → Session

联犀 AI 中台的组织方式是四层：

AgentGroup（助手组）：按业务场景组织智能助手，比如用户交互助手、设备助手、告警助手。组级配置可被 Agent 继承。
Agent（智能体）：定义模型、提示词、工具和能力声明，是 Clone 的模板。
Clone（数字分身）：Agent 的个性化实例，拥有独立的长期记忆。一个客服助手 Agent 可以为每个用户创建独立 Clone。
Session（会话）：一次具体的对话，记录多轮上下文和工具调用。

Skills 与 Tools 的合并策略

Skills：管理员定义的专业能力，通过 HTTP、MCP 或 Sandbox 执行。
Tools：用户自定义的通用工具，在 Sandbox 中执行。
合并策略：Clone 的最终可用工具 = Agent.Skills + CloneGroup.Tools，两者合并注入到 AI 会话。

知识库 + 安全执行

知识库：把企业文档、运维经验、产品手册变成 AI 可查阅的知识资产。员工提问时，AI 基于企业知识回答，而不是给出泛泛的通用答案。
PicoClaw Serverless：按需启动，执行完退出，零常驻资源。
PicoSandbox：Linux namespace + cgroup 隔离，启动 <50ms，内存开销 ~2MB。

真实场景

场景一：企业设备手册问答

企业把设备手册、运维规范上传到知识库后，现场人员可以直接问 AI"这台设备的告警代码 E-102 是什么意思""更换滤芯的标准流程是什么"，AI 基于企业知识回答，而不是给出通用答案。

场景二：AI 代码安全执行

当 AI 生成一段用于数据清洗或设备联动的代码时，这段代码在 PicoSandbox 中运行。沙箱内只能看到 /workspace 目录，无法访问宿主机的 /etc/passwd，无法访问内网 IP，内存和 CPU 也受到 cgroup 限制。企业可以放心把 AI 投入生产。

可量化收益

企业敢把 AI 真正投入使用。
AI 能力可复用、可分发、可组合。
安全边界清晰：内核级隔离、网络隔离、企业数据隔离。
Serverless 执行降低常驻资源消耗。

九、如何选对一个 AIoT 平台？

看完联犀的做法，最后给出一个更通用的判断框架。如果你正在评估一个 AIoT 平台，建议重点看四个维度：

维度一：能否让企业低门槛起步、按需扩展

不要一上来就投入巨大的平台建设成本。好的平台应该支持 SaaS 订阅，让企业可以从小场景、几台设备开始，验证价值后再扩展。

联犀的满足点：SaaS 托管让企业可以按效果付费；私有化/源码授权满足数据边界和深度定制需求；AllInOne → 融合式宿主 → 微服务的部署弹性，让企业不必为早期 POC 过度设计架构。

维度二：能否支撑多客户、多角色、多应用、多终端

企业级市场不是单一应用。平台必须能同时服务多个客户，每个客户内部有不同角色，不同角色使用不同终端。

联犀的满足点：多应用架构让平台像应用市场一样可生长；Web/App/小程序/原生客户端共用同一套后端；基础隔离层 + 用户上下文层 + 查询裁剪层让"同一企业内不同角色看不同数据"不再是业务代码里的硬编码。

维度三：是否把 AI 真正融入业务闭环

AI 不是独立的聊天窗口，而应该能查询设备、控制设备、理解告警、执行自动化、生成分析。

联犀的满足点：AI 不是聊天窗口，而是通过 MCP + 物模型理解设备能力；自然语言可直接生成定时任务、条件判断、设备控制；告警触发后 AI 能解读含义、关联历史、推荐处置。

维度四：是否具备安全边界

企业敢不敢把 AI 投入生产，取决于安全边界是否清晰。AI 执行代码时必须在隔离环境中运行，企业数据必须严格隔离。

联犀的满足点：AI 执行代码走 PicoSandbox，受 namespace/cgroup/NetworkProxy/seccomp 多重约束；企业 workspace 用 RustFS prefix 隔离；协议脚本按企业/产品/设备级绑定，避免扩展逻辑无边界外溢。

联犀落地路径建议

如果你决定用联犀构建 AIoT 能力，可以参考以下落地节奏。时间估算基于设备规模适中、协议相对标准的场景，实际周期会随设备数量、协议复杂度和定制需求调整：

阶段 1：设备接入 + 基础监控（1-2 周）
- 梳理设备物模型：属性、行为、事件、值域。
- 选择协议接入方式：MQTT、CoAP、HTTP、TCP。
- 对私有协议设备，编写协议脚本做上行前/下行前处理。
- 验证设备在线状态、属性上报、基础控制。
阶段 2：应用订阅 + 权限分层（2-4 周）
- 根据业务选择应用：能耗中心、智慧照明、工业监控等。
- 配置项目、区域、设备组结构。
- 配置用户角色和可见范围，验证三层数据权限模型。
- 对 SaaS 运营方，验证多客户数据隔离。
阶段 3：AI 助理 + 告警升级（4-8 周）
- 配置 AgentGroup 和 Agent，绑定模型和 Skills。
- 上传企业知识库文档。
- 设计告警条件树和通知阶梯。
- 验证 AI 能否正确查询设备、解读告警、基于知识库回答。
阶段 4：自然语言联动 + 大屏自动化（按需）
- 用自然语言配置复杂联动策略。
- 选择大屏模板，用 DataQuery 对接设备数据。
- 对高敏感操作，验证 PicoSandbox 安全执行。

落地 checklist

在正式启动一个联犀 AIoT 项目前，建议逐项确认：

十、结语

回到文章开头的问题：新时代的 AI + IoT 万物互联平台应该长什么样？

答案不是"连更多设备"，也不是"做一个更聪明的聊天窗口"。真正有价值的平台，应该能把设备能力、AI 能力、业务能力和组织能力整合成一个可持续演进的底座。

从外部观察，联犀的定位正是这样一套面向企业数字化、AI 与 IoT 协同的 AI 原生平台底座。它不是把所有能力都塞进一个后台，也不是把 AI 当成独立应用，而是把设备语义、权限分层、协议扩展、时序存储、AI 工具和安全执行环境组织成一套可长期演进的体系。

它不适合那些只需要简单设备管理的轻量场景，但对于设备多、角色多、流程复杂，希望把设备平台升级为业务协同与智能化运营平台的企业来说，它会是一个值得认真评估的选择。

如果你正在选型，建议不要只看"有没有 AI 功能""能接多少协议"这些单点指标，而要看平台是否具备这四件事：

能否低门槛起步、按需扩展（SaaS + 弹性部署）。
能否支撑多客户、多角色、多应用、多终端（多应用架构 + 三层数据权限）。
是否把 AI 真正融入业务闭环（MCP + 物模型 + 自然语言自动化）。
是否具备安全边界（PicoSandbox + 内核级隔离 + 企业数据隔离）。

万物互联的下半场，比的不再是连接能力，而是组织能力。谁能把设备世界整理成企业可用的智能，谁就更有机会定义下一代企业软件。

更新日志

2026/8/4 15:04

查看所有更新日志

7e927-文档站全面重构：目录重排、首页重写、案例独立成站、应用市场下线于 2026/8/4
3bc7e-docs: 同步设备接入文档更新与万物互联系列博客于 2026/7/24