模块注册 · cmd 组装
交付入口决定装配哪些业务
AllInOne 入口组合能源、停车等模块；能源边缘入口选择能源与边缘能力，复用 core / things。行业扩展与产品启动入口分开维护。
选择与取舍
组合遵循模块依赖，不是所有模块任意热插拔；配置关闭与编译裁剪也不是一回事。
WHY IT MATTERS
你的产品，为什么需要它？
从一个项目扩展到多个企业客户时，难点不只是增加页面：成员归属、应用开通、数据范围和部署维护都需要一致的基础。零散接口不能代替完整的平台组织。
ENGINEERING THAT SERVES YOUR PRODUCT
相同基础能力，组合成不同交付形态。
能源现场与综合园区不必各维护一份企业、权限和设备代码。先复用业务实现，再根据项目选择模块组合与调用边界。
INSIDE THE DESIGN机制示意 · 不连接业务接口
交付入口 / 能源边缘组合
能源停车边缘
core / things企业 · 应用 · 权限 · 设备
同一能力接口↙ ↘
direct进程内调用gRPC远程调用
能源边缘组合
现场先聚焦能源与边缘能力
交付入口选择能源与边缘模块，复用企业、权限与设备能力。图中是代码组合，不表示每个框独占一个进程。
当前选择说明共同底层实现 + 现场所需模块
direct / gRPC 双实现
同一接口，区分本地和远程调用
已有服务接口提供进程内调用和 gRPC 实现，减少仅因交付形态变化而重复编写业务逻辑的需求。
选择与取舍
同进程共享资源与故障范围；拆成远程调用需核验上下文、超时与拦截器。融合式运行仍可能依赖部分 gRPC 服务。
企业 · 应用开通 · 角色 · 项目范围
业务归属不随部署方式改变
同一平台管理多个企业客户，每家企业开通不同应用，人员再获得各自操作与项目范围。部署选择不替代业务授权。
选择与取舍
多企业逻辑隔离不等于每家企业独占数据库。应用间协作仍需明确接口和数据边界。
这张界面看什么
看企业已开通应用：应用配置和用户操作权限、后台部署方式分别解释。
点击截图可放大查看代码组合关系示意
从能源现场扩展到综合园区
先选能源与边缘能力，后续园区产品按需求组合停车等模块。复用的是基础与业务实现，新增行业流程、部署依赖和验收仍要逐项确认。
CHOOSE BY YOUR REQUIREMENTS
选方案，看实现与交付方式。
不以单个技术名判断优劣。共同能力如实说明，重点核对你的资料、业务和运维条件。核验日期：2026-09-23。
每个项目单独建设
团队独立组织账号、权限、设备和行业代码，掌握全部实现选择。
选型时看什么
需要承担各项目基础能力维护与差异合并。
联犀的模块组合方式
复用基础模块和已有业务实现，按交付入口组装应用。
选型时看什么
适合有多个行业产品或持续交付项目的团队；仍需核验选配依赖。
WHY A FOUNDATION
业务各有不同，
基础不必重做。
一个聊天窗口解决不了企业应用的全部问题。谁能用、能看到什么、怎样连接设备、操作如何执行，都需要长期稳定的平台能力。
每多一个产品，
再搭一套基础。
- 账号、角色与企业管理重复建设
- 模型、知识和设备接口分别接入
- 数据权限散落在不同业务中
- 部署与运维方式各自维护
复用共性能力，
把开发留给业务。
- 企业和应用统一组织，按需开通
- AI 与设备能力通过业务接口连接
- 身份、数据范围与执行授权分层处理
- 行业模块按交付目标组合和扩展
设计价值对照，不是开发成本或交付周期的量化承诺。行业流程与设备适配仍需实施。
THE PLATFORM, OPENED UP
拆开看，
每一层都有它的职责。
行业应用之下，是 AI、设备与公共服务的协作。沿着模块、授权边界和一条真实实现对应的调用路径，理解为什么它是一套基础平台。
INSIDE THE FOUNDATION
一个底座，连接项目现场与智能业务
能力关系示意 · AI、IoT 与公共基础协作，不是两套产品；连线不代表每条消息必须经过 AI。
INSIDE THE FOUNDATION
从一条设备消息，到可用的业务信息
设备链路示意 · 查询、自动化与可视化是分支，不是依次必经步骤。
FOLLOW A REQUEST
让一次请求，走过这套架构。
流程示意 · 非接口实测 · 不连接真实设备。各分支需分别配置工具，不表示都已提供同一个能源查询。
PLATFORM / 共享基础，独立业务逻辑架构示意
01 / 业务入口与行业应用
构建你自己的产品02 / AI 能力
角色、资料与持续上下文03 / 工具与执行
按类型连接实际业务04 / 业务与公共能力
不必重复建设的共性能力05 / 数据与运行支撑
逻辑分层不等于物理独占开发接入 ≠ 运行时调用
客户自己的 AI 通过 Skills 获取方法与模板，通过 CLI 完成授权接入。运行时由当前角色使用已配置的工具，不要求每次请求都经过 CLI。
查看 Skills / CLI 专题 →架构依据：联犀平台总体架构、AI 能力架构与当前实现。平台层间连线表示能力关联，不是每次请求必经的执行顺序。图示表达逻辑职责，不表示各企业、分身或模块独占数据库、服务器或容器。
MULTI-COMPANY · MULTI-APP
一套平台，
不同企业的应用组合。
企业与应用分别管理。应用开通关系记录状态和有效期；人员、角色与业务资源决定实际访问范围。共享基础设施，不代表共享全部数据。
配置示意 / 非客户清单
能耗中心
示例：已开通停车管理
示例：已开通智慧楼宇
示例：已开通能源、停车、楼宇按需组合；运营人员与值守人员仍按各自角色和项目范围访问。
能力可复用，数据有归属。
应用之间的业务协同需要明确接口与授权；企业隔离不自动等于独立数据库。
业务归属
企业信息、成员与用户上下文确定当前身份；公共资源与企业私有资源按各自规则访问。
按需启用
应用状态、有效期和菜单入口分别维护，不把购买或开通关系当作全部操作权限。
定义可以做什么
区分管理、查询与控制等操作。应用开通不自动授予人员所有角色权限。
确定能访问哪里
按项目和区域约束数据与设备范围；管理员和普通用户分别验证允许与拒绝路径。
BUILT FOR EXTENSION
共性沉淀在底层，
差异留在行业应用。
基础平台的价值不是包办所有行业，而是让新应用沿着已有边界接入，少重复建设公共能力。
平台能力
企业、身份、角色、应用管理，以及按需接入的知识、分身、设备数据和消息机制。
行业业务
停车计费、能源计量、结构测点等领域模型、流程和界面；设备协议与工具需要适配验证。
可用的产品
配置应用与权限、联调数据和设备、验证允许与拒绝路径，再按项目范围交付。
IN-PROCESS / 融合式宿主
按项目组合运行
系统管理AI 能力设备业务行业应用同一宿主 · 已支持接口可走进程内 direct 调用
适合需要减少部署组件和网络跳转的交付。模块仍有业务边界，不等于所有依赖都可任意移除。
SERVICE BOUNDARIES / 独立服务
按服务边界部署
系统服务AI 服务设备服务业务服务已支持的服务通过 gRPC / 事件机制协作
按实际入口、依赖和运维条件选择组合。逻辑分层不是“一键切换部署”，也不自动保证高可用。
以上按当前模块化架构、企业应用开通与 AI 授权实现整理。direct 调用不经过 gRPC 拦截链，不能只依赖远程调用的拦截器验证权限。阅读权限指南 ↗
FROM CAPABILITY TO YOUR PRODUCT
怎样接进你的业务？
以下是实施路径示意，不会在官网调用业务接口或执行命令。
- 01
定义企业与应用
用企业组织业务归属，用应用划分服务入口和开通关系，不按每个客户复制整套代码。
检查输出企业清单、应用组合及开通范围 - 02
接上公共能力
复用账号、角色和设备体系，按需要接入知识、记忆与工具；行业规则仍由应用实现。
检查输出行业模块与公共能力的责任边界 - 03
验证交付边界
核验跨企业访问、应用状态、项目权限及业务接口，结合实际依赖选择部署方式。
检查输出允许与拒绝路径、部署与运维清单
CONNECTED PRACTICE
放到具体场景中理解。
以下案例展示相关行业问题与业务界面，不表示历史案例已经接入本页全部 AI 能力。
ONE FOUNDATION