浅谈人机物融合智能化系统的多重含义

人类正在进入一个人机物融合的万物智能互联时代，很多物理设施设备都实现了网络化接入和通信，而各类用户也通过智能手机和可穿戴设备实现了在线互联和协作。与此同时，各种智能化系统层出不穷，小到智能冰箱、智能小车，大到智能家居、智慧园区、智慧牧场。这些智能化系统有一些共同的特点和趋势：一是“软件定义”，软件随着计算、存储和网络资源在人机物三元空间中的不断普及而四处渗透（像水和空气一样，无处不在而又无迹可寻）；二是“AI赋智”，以深度学习为代表的AI模型随着软件不断渗入人机物融合系统之中，以数据驱动的方式为系统赋予更多的智能。那么，这些人机物融合智能化系统的“智能”从何而来？所谓的“软件定义”在其中扮演着什么样的角色？这里谈一下个人的粗浅理解和一点思考。

01

“智能”从何而来？

人机物融合智能化系统中的“智能”包含多个方面的含义，如上图所示。这些方面中的任何一个方面都可以为系统带来一些“智能”，而特定的人机物融合智能化系统往往包含多个方面“智能”的叠加和组合。

1. 人机物资源软件定义

人机物资源的网络化连接使得我们可以针对这些资源进行编程，例如通过特定的网络通信协议和接口驱动访问物理设备资源实现信息读取和命令下发。人机物资源的软件定义进一步实现了资源的对象化和平台化编程。对象化使得我们在编程时可以脱离网络协议、硬件接口等物理实现细节，而以一种符合资源自身的现实世界概念的对象化抽象与之交互。例如，针对一栋智慧大楼进行编程时可以访问“房间”、“饮水机”、“打印机”等对象及其属性（例如查询某个房间的“是否有人”属性），调用“开门”、“开灯”、“打印”等对象操作，接收“门被打开”、“有人进入”等事件。在此过程中，人机物融合系统平台向下实现了资源封装和管理，向上提供对象化的编程接口。

这种软件定义方式不仅提高了人机物资源的编程抽象层级、降低了编程难度，而且还实现了人机物融合应用与具体资源的解耦。例如，一个“访客接待”的智慧大楼应用在开发时无需关心探测访客的传感器，也无需绑定具体的接待室、服务机器人等资源；平台会完成从具体的设施设备和传感器到对象属性、操作和事件的映射，同时在运行时根据资源实际状态及其可用性灵活调度不同的资源实例。在人机物资源软件定义的基础上，我们可以很方便地建立人机物融合系统的数字孪生及相应的低代码开发平台，例如通过图形化的方式实时展示一栋大楼的状况同时允许用户通过图形化的方式编排个性化的人机物融合应用。

实现这种人机物资源软件定义的难点主要在于各种设备和网络的异构性以及不同厂商生态的封闭化和碎片化导致异构人机物资源难以统一接入和管理；人机物资源及环境的对象化封装和抽象涉及复杂的融合感知和混合控制，实现难度高、工作量大；人机物资源及环境具有复杂的物理时空特性，其软件化封装和抽象难度高，例如一个精细化的“开门”操作需要刻画开门过程的时间延迟以及在此期间门的连续状态变化（如果将“开门”过程抽象为一个瞬间完成的离散操作那就比较简单了）。

2. 人机物融合系统级的持续更新

借助于云计算平台以及云原生软件技术，互联网软件系统可以很容易实现软件持续动态更新，即在保持系统服务可用性的情况下实现软件的动态更新。进一步，互联网软件系统还实现了开发运维一体化（DevOps），支持通过运行时的数据收集形成快速反馈并驱动软件的演化方向。甚至可以利用线上系统和真实用户进行探索性实验，从而通过快速的真实用户行为分析和反馈帮助开发人员作出业务和设计决策。人机物融合系统的开发运维一体化将此思想进一步拓展到人机物三元空间，实现人机物融合系统及应用的快速反馈和持续动态更新。试想，一座智慧大楼可以通过“软件更新”的方式持续优化和调整整栋大楼的运行管理模式。例如，系统根据人流量、耗电量、人体舒适度等多种运行反馈动态调整空调温度、电梯运转模式、访客放行策略等方面，从而实现大楼的用户体验、工作效率、能源消耗等多方面的优化目标。

需要注意的是，这种人机物融合系统的开发运维一体化将包含人机物资源及环境在内的复杂系统而非软件自身作为优化更新的目标。例如，这类系统的“软件更新”不仅针对计算机软件而且还会针对物理设施设备操控方式以及人员工作方式和管理措施（例如通过手持设备向大楼保安发送工作指令，改变人员出入管控策略）等广义的“软件”（这也是为什么这里要加引号的原因）。可以想象，这类人机物融合系统的“开发者”可以像互联网软件开发者那样，通过多层次、多维度的运维数据及其可视化洞察系统的运行状况，并根据需要变化或者所发现的问题动态更新支撑系统运行的“软件”。

实现人机物融合系统开发运维一体化的主要难点在于实验和试错成本极高，甚至是不可能的。互联网软件可以以极低的成本以及很小的用户体验代价实现问题反馈和探索实验，而这对于人机物融合系统而言可能很难。试想，一栋大楼为了试验对比两种人员出入管控策略需要涉及多少设施设备和人员（包括执行策略的保安以及受影响的进出人员），同时由于物理时空限制这个反馈过程可能会比较长（至少几分钟到几小时甚至几天）。对于有些系统而言，这种“试验”甚至是不可能的，例如应急抢险等领域的人机物融合系统几乎没有试错机会。因此，仿真模拟对于这类系统而言就十分重要了，即软件定义的系统运行方案在下发执行前首先在仿真模拟环境（数字孪生系统）中进行试验，从而以极低的成本和较快的时间获得有价值的反馈，以支持我们的方案更新决策。

3. AI模型的引入及持续演化

以神经网络模型为代表的AI模型在各类软件中都得到了广泛应用，为这些软件系统注入“智能”的力量。对于人机物融合系统而言，AI模型可以实现智能化的感知、决策和控制，例如自动驾驶系统中就应用了大量的AI模型。AI模型以数据驱动的方式工作，通过大量数据训练模型同时持续收集新的数据以及模型使用反馈从而推动模型持续演化。

与一般的软件类似，AI模型也需要持续演化同时更加依赖数据。因此，AI模型也需要打通开发（训练）与部署运行（推理），促进模型应用效果的持续、快速反馈以及数据工程、软件工程和系统运维团队之间的密切合作，从而实现模型的持续迭代更新和优化，由此产生了面向机器学习的“开发运维一体化”，即MLOps。

人机物融合系统中AI模型应用和持续演化的主要难点在于AI的可靠性和安全性问题。AI模型的概率性和不确定性与我们在可靠性和安全性方面的一些确定性的期望之间存在鸿沟。我们在利用越来越先进的AI技术不断拉高智能化的上限的过程中，也要考虑如何利用传统的基于规则的软件实现以及各种可靠性保障技术确保系统的可靠性和安全性底线。

4. 软件自适应演化与自主构造

软件不仅可以用来实现对于硬件设施设备的自适应控制，其自身也可以以一种自适应的方式实现持续演化。事实上，自适应系统（self-adaptive system）是自动控制领域的一个研究方向，而自适应软件也是软件工程领域的一个热门研究方向。自适应软件通过一种MAPE（Monitoring、Analysis、Plan、Execution）反馈控制环路实现软件的自适应调整以及运行性能优化、故障自治愈、攻击自保护等方面的具体目标。与物理世界的数字孪生系统相似，自适应软件也希望建立一个由元级（meta）和基级（base）构成的双层结构，其中元级提供软件的抽象模型表示而基级则代表部署运行的软件本身，两个层次之间保持持续的双向映射和因果关联，例如元级上的自适应调整将被映射为基级的软件部署运行调整。实现自适应软件的前提条件是软件自身多个层次上的动态可变性，包括部署方案、软件架构、运行配置等方面。例如，20多年前讨论软件的自适应演化时想实现软件的运行时动态升级和更新是很困难的，而今天借助于容器和微服务等云原生技术实现软件服务的动态更新已经不是什么难题了，在此基础上我们可以实现动态扩缩容、服务在线更新、熔断/限流等多方面的软件自适应调整。

传统的软件自适应演化更多是在预设的软件可变性范围内的来回调整，例如可配置参数、可替换的组件变体等。而随着生成式人工智能以及大模型的发展，软件的自主构造（即运行时动态产生完整的软件或其一部分，而不是在预设的变体中选择）似乎成为一种新的可能。在代码单元级别上，大模型可以基于给定的功能和意图描述实现小规模的代码生成，如果配合运行时自动化测试机制那么这种动态生成的代码可以直接被编译运行而无需人工参与；在应用集成层面上，大模型可以在可用的API和服务基础上通过意图理解和方案规划生成可直接运行的应用。

软件自适应演化与自主构造的主要难点在于自适应调整灵活性与可靠性之间的权衡。传统的软件自适应方法依赖于预先定义的可变性策略，调整空间有限（例如可配置参数、可替换的组件变体等），灵活性不足。而运行时自主构造的主要问题则在于自动生成的代码和软件的正确性与可靠性难以保证。

02

不同层次上的“软件定义”

对于现实世界中原本按照固化的模式运转的系统而言，以上四个方面的改进都会让用户产生某种智能化的感觉，也都蕴涵着从“刚性”到“柔性”、从“固化”到“灵化”的变化，其中软件都扮演着重要的角色，甚至都在某种层次上体现了“软件定义”的特点。                   

03

几点思考

人工智能特别是近期大模型技术的飞速发展使得“智能化”成为一个热点话题。基于大模型的智能问答和交互、图像与视频生成等应用成为大众关心的热点以及衡量一个企业甚至一个国家人工智能技术水平的重要标志。然而，社会经济以及人民生活的整体智能化水平的提升还需要人工智能技术赋能千行百业，这就需要深度学习和大模型等技术随着软件一起渗透和融入社会经济生活的方方面面，实现从智能化技术到智能化系统的转变。特别是在当前万物互联的时代背景下，我们更加需要站在人机物融合大系统的角度思考“智能化”这一大问题。这里谈几点粗浅思考。

 ● 操作系统以及云计算思想的泛化：

实现更大范围和更深层次智能化的一个重要基础是软件定义资源的泛化。操作系统实现了单个计算设备中计算、存储和网络资源的软件定义，云计算进一步实现了更大范围内计算、存储和网络资源的软件定义和按需供给。面向人机物融合大系统的智能化需要将操作系统和云计算的思想进一步泛化到人机物三元空间，由此产生了泛在操作系统的概念。从技术上看，从虚拟机到容器再到近期流行的WebAssembly技术，虚拟化技术越来越轻量级，由此可以期望每一个实现了网络化接入的智能化设备都可以通过轻量级虚拟化实现资源的软件和云化定义。当然，与传统的数据中心云不同，这种面向人机物融合系统的云化（甚至进一步云原生化）一方面需要云边融合的算力支持，另一方面需要实现人力和物理资源的能力刻画和封装（例如，我们期待咖啡机实现的是烧咖啡的功能，而不是完成计算任务）。

 ●重视智能化系统的软件架构问题：

软件架构对于大规模复杂软件的重要性毋庸置疑。对于人机物融合系统而言，当其规模、复杂性和可靠性要求上升到一定的高度之后，架构问题也会成为一个关键问题。除了一般的软件架构需要考虑的各种设计考虑和权衡决策外，智能化系统的软件架构还有一些特殊问题需要思考。首先，智能化系统中AI模型与软件模块共存，二者的交互关系（例如基于AI的决策模型与基于规则的软件决策模块如何协作）是架构设计中需要考虑的重要问题，并可能产生一系列典型的设计模式。其次，虽然云计算和云原生技术实现了计算资源和服务实例上的动态调整（如服务实例和资源的动态伸缩），但软件架构总体上还是预先定义的固化设计，为了实现更高层次的智能化需要考虑如何支持可重构的软件架构。例如，系统中AI模型与软件模块的边界是否动态可调，如在不同抽象层次和粒度上实现基于AI模型的决策与基于规则和代码逻辑的决策之间的灵活调整（类比一下，人非常善于在不同的层次上灵活决定凭经验还是规程做出判断以及制定行为方案）？此外，现有的软件自适应依赖于预设的可变性（例如可配置参数、可替换的组件变体），未来是否可以支持局部的架构重组？

 ● AI模型生成与程序生成相结合：

有时候我们可以选择到底是训练一个AI模型还是生成一段程序来实现一个智能化功能或应用。例如，针对特定机器人任务（如制作咖啡）既可以训练一个AI模型（如利用强化学习）又可以通过探索和学习生成一个基于机器人基本能力API（如物体识别定位、抓取物品、移动到指定位置等）的程序。前者针对每一次具体任务生成一个合适的实现方案，灵活性强但可靠性和可解释性弱且执行成本较高（类似于每次倒咖啡都要动脑子规划一个方案）；而后者则为某一类任务建立了一种“规程”（通过少量参数实现可变性），灵活性弱但可靠性和可解释性强且执行成本较低（类似于每次倒咖啡都习惯性按照既定规程执行）。事实上二者是互补的并且可以相互转换。例如，遇到新任务或异常情况时可以采用AI模型生成的方式，而某类任务长期执行形成规范化流程和策略之后可以采用程序化的方式。注意，所生成的程序本身可以随着环境和需求的变化而不断演进（例如增加更多的参数选择或异常情况的处理能力），但每一阶段都有一个可读、可理解、可控的程序存在。

04

总结

人机物融合智能化系统具有“软件定义”和“AI赋智”两方面主要特征。这类系统中的“智能”包含多个方面的含义，包括人机物资源的软件定义、人机物融合系统级的持续更新、AI模型的引入及持续演化、软件自适应演化与自主构造。以上四个方面都蕴涵着从“刚性”到“柔性”、从“固化”到“灵化”的变化，其中软件都扮演着重要的角色，甚至都在不同层次上体现了“软件定义”的特点。在当前万物互联的时代背景下，我们更加需要站在人机物融合大系统的角度思考“智能化”这一大问题，其中还有很多问题需要进一步探索和思考，例如操作系统以及云计算思想的泛化、智能化系统的软件架构问题、如何将AI模型生成与程序生成相结合等。

05

作者简介

彭鑫，复旦大学计算机科学技术学院副院长、教授，中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，IEEE高级会员，《Journal of Software: Evolution and Process》联合主编，《ACM Transactions on Software Engineering and Methodology》、《Empirical Software Engineering》、《软件学报》等期刊编委。主要研究方向包括软件智能化开发与运维、人机物融合泛在计算、智能网联汽车基础软件等。

CodeWisdom

Codewisdom平台由复旦大学软件工程实验室运营，提供智能化软件开发平台及线上沙龙相关资讯，关注可了解更多智能化软件开发的最新消息~