让 AI 智能体安全可靠
打通物理世界

摘要

Executive Summary — 三分钟了解 HubPort 是什么、解决什么问题、凭什么不同。

企业引入 AI 的最大瓶颈，往往不在模型，而在连接：AI 智能体读不到产线设备、调不动老系统、拿不到实时数据。传统物联网平台与集成项目用「人写驱动、逐点映射」的方式对抗协议碎片化，成本高、周期长、不可复制。

HubPort 用一条相反的路线：让 AI 参与接入本身。用户把接口文档丢进来、用一句话描述业务需求，平台自动完成接口分析、能力建模、驱动生成与实例部署；接入完成后，所有设备与系统都变成 AI 可直接调用的标准能力，供上层智能体、企业系统与实时链路统一消费。

本白皮书面向技术决策者、方案架构师与集成合作伙伴，介绍 HubPort 的产品定位、能力全景、系统架构、典型场景与部署形态，并说明其安全与生态策略。

设备与系统协议碎片化，是所有 AIoT 项目绕不开的暗礁。

工业现场跑着 Modbus、OPC UA、BACnet 与大量私有协议；企业侧的 ERP、OA、考勤、财务系统各有各的接口风格；还有大量「没有 API」的老系统只能靠界面操作。要把这些异构源接入统一平台，行业沿用多年的做法是人工定制驱动 + 逐字段映射：每个项目从协议分析、点表整理、驱动编码到联调验证全部重做一遍。

这条路线带来三个结构性困境：

• 周期失控——单系统对接以周甚至月计，项目制交付无法规模化复制；
• 人才瓶颈——既懂工业协议又懂软件工程的复合型人才稀缺，交付质量高度依赖个人经验；
• 资产不沉淀——每次对接的成果是项目代码而不是可复用的能力资产，第二个项目再来一遍。

进入 AI 时代，矛盾被进一步放大：大模型与智能体框架进化极快，但它们缺少一条安全、标准化、可审计的通道去触碰物理世界与业务系统。让 AI「能连、敢连、连得安全」，成为智能化落地的先决条件。

一句话：把第三方模组、设备、系统，统一为 AI 可安全调用的能力。

HubPort 不是又一块监控大屏，也不是传统的 API 网关。它在技术栈中的位置可以概括为 「连接层 + 能力层」：向下兼容各类协议与接口形态的接入对象，向上把一切统一成标准能力对象，供 AI 智能体、企业系统、实时链路和开发者工具直接消费。

与传统路线的本质差异

传统集成把协议知识长在「人」身上，HubPort 把它沉淀为可复用的资产体系：能力规范、协议驱动与实例配置三者解耦、独立演进，并通过技能包机制在团队之间乃至生态市场里流通。对接一次，处处复用。

另一个关键差异在于 AI 的角色。多数平台把 AI 当作事后分析工具；HubPort 把 AI 拉进接入过程本身：解析文档、推导能力、生成驱动、验证联调、诊断故障，AI 全程参与。这也是「接口文档一丢就通」的产品底气。

已交付的能力按八个域组织，覆盖从接入、运行到生态的完整链路。

八个域由统一内核驱动，可以按场景裁剪：轻量场景只保留接入与数据消费，完整场景启用全部能力。全部已交付模块的清单见附录 B。

接入对象分三类，覆盖从现代 API 到「完全没有接口」的全部现实。

三类接入对象

• 接口类——提供 API 文档、SDK 或协议规格的系统与设备，覆盖工业、楼宇、能源、企业信息化与 SaaS 的主流协议与接口风格；
• 界面类——只有操作界面的老系统：平台以界面感知与自动化操作的方式将其转化为可调用能力，无需原厂配合改造；
• 数据类——以文件、报表、数据库形态存在的数据源，通过数据结构识别抽取为持续可用的能力。

一键接入向导

对接口类对象，用户只需两步：上传接口材料（网页链接或文档均可），再用一句话描述业务需求。平台自动完成接口提取 → 能力建模 → 驱动生成 → 实例部署的完整链路，全程有人工确认节点，用户不需要理解协议细节。

接入完成后

每个对象成为带身份、状态、动作、事件与安全策略的标准能力对象，可立即被 MCP 智能体、HTTP/MQTT 集成、Webhook 实时链路或 SDK 调用，并通过冒烟测试与质量门控验证其可用性。

把「每个项目一套私有映射」变成「全行业一套能力语言」。

HubPort 在原始接口之上建立统一能力语义层：任何接入对象，无论来自什么协议、什么厂商，最终都表达为同一套能力语义——读什么状态、做什么动作、报什么事件、守什么策略。上层消费端不再关心接口差异。

这套语义体系同时服务两类「读者」：人（方案工程师 review 与配置）与 AI（智能体理解能力边界、安全调用）。能力规范支持自然语言式与结构化式双形态，兼顾可读性与机器可执行性。

能力资产可以打包成技能包——包含能力规范、驱动与实例配置的可分发单元，经过冒烟测试门控后即可在团队、站点乃至生态市场间流通，实现「一处接入、处处安装」。

单一内核、分层解耦，是支持多形态部署与持续演进的结构基础。

flowchart TB
  subgraph L5["云端协同层（可选）"]
    M["生态市场：技能包分发与升级"]
    U["升级与远程运维服务：版本发布 · 远程调试 · 节点管理"]
  end
  subgraph L4["北向消费层"]
    N1["AI 智能体 · MCP"]
    N2["企业系统 · HTTP / Webhook"]
    N3["实时链路 · MQTT / 消息推送"]
    N4["开发者 · SDK / CLI"]
  end
  subgraph L3["统一内核层"]
    K1["能力语义层"]
    K2["驱动引擎与实例运行时"]
    K3["告警引擎"]
    K4["日志与诊断"]
    K5["安全 · 多租户 · 审计"]
  end
  subgraph L2["数据资产层"]
    D1["运行数据"]
    D2["能力规范库"]
    D3["驱动包与技能包"]
  end
  subgraph L1["南向接入层"]
    S1["模组"]
    S2["设备"]
    S3["企业系统"]
    S4["界面 / 数据文件"]
  end
  S1 & S2 & S3 & S4 --> K1
  K1 --> N1 & N2 & N3 & N4
  K1 --> D2
  K2 --> D1
  K2 --> D3
  U -.-> K2
  M -.-> D3
    

架构要点：南向接入与北向消费通过统一内核完全解耦——新增一个设备类型不影响任何消费端，新增一种消费方式不需要改动任何驱动。数据资产层沉淀的能力规范、驱动包与技能包，是跨项目复用与生态流通的基础。

云端协同层为可选组件：完全离线的私有化部署不依赖任何外部服务；启用后获得生态市场、集中升级与远程运维能力。

同一底座，服务五类典型买家的核心诉求。

一套内核，三种形态，两种工作模式。

三种产品形态

• 私有化部署——完整能力在客户内网运行，支持主流桌面与服务器操作系统，可长期完全离线，适合数据不出域的工业与政企环境；
• 云服务——多租户 SaaS 形态，开箱即用，适合中小规模与快速验证场景；
• 边缘硬件盒子——内核下沉到边缘节点，弱网与低时延场景就近接入与控制。

双版本工作模式

同一部署提供开发版（完整建模、调试与治理界面，面向方案工程师）与运行版（精简运行界面，面向生产环境与最终用户）两种模式。开发完成的能力资产以技能包形式从开发版迁移到运行版，生产环境不暴露建模复杂度。

持续演进与升级

平台内置自动升级机制：版本发布支持灰度策略与增量分发，升级包经签名校验后静默安装，升级失败可回滚。对分布多地的部署节点，可通过云端协同层统一管理版本与运行状态。

让 AI 碰物理世界的前提，是每一步都可管、可查、可追责。

• 权限与角色边界——租户、用户、能力多级权限模型；敏感操作支持审批与人工确认门控，AI 的每次调用都在明确的授权边界内；
• 操作审计——从接入配置到运行调用，关键动作全量留痕，审计记录支持查询与导出，满足合规审查要求；
• 凭证与数据保护——第三方系统凭证加密存储；运行数据按租户隔离，多租户环境互不可见；
• 软件供应链安全——升级包与技能包签名校验，未签名内容拒绝执行；高危操作（如本机授权移除）要求二次确认；
• 远程运维可控——远程调试通道默认关闭，启用需服务端审批、限时租约、全程审计，会话结束入口即失效，不给远程通道留下常驻后门。

接入成果资产化，资产流通生态化。

技能包生态

每一次高质量接入都沉淀为可分发的技能包：内部使用是团队知识资产，外部流通则进入生态市场——其他团队一键安装、一键升级，把「对接过」变成整个生态的公共能力。对集成商与 ISV 合作伙伴，这意味着交付成果从项目代码升级为可重复销售的产品。

路线图方向

• 设备扫描发现——从「给文档接入」进化到「网络扫描自动发现待接入设备」；
• 流程编排——把多对象能力编排为跨系统自动化流程，覆盖长链路业务；
• 群组智能体——多实例协作的任务分派与结果聚合；
• 运营监控域——面向运营团队的聚合视图与指标体系。

路线图内容反映当前规划方向，具体交付节奏以产品版本发布为准。

当前已交付的 32 个功能模块，按八大产品域组织。

清单覆盖当前已交付模块；规划中的能力方向（设备扫描发现、流程编排、群组智能体、运营监控等）见第 10 章路线图。模块能力以实际交付版本为准。