本文是对《AIOS助力数字化项目建设的畅想与实现路径》 https://idealworld.group/2024/10/05/aios/ 文章中“AI即系统”概念的延伸探讨。

现状

“软件系统”这一概念几乎每个人都不陌生。根据维基百科的定义：软件系统是基于计算机系统的软件（硬件和软件组合）的组成部分。它通常由多个单独的程序和配置文件组成，这些程序用于配置系统，提供运行环境，支持系统文档和用户文档。 我们日常生活中常会提到“某某系统出现问题”或者“登录某某系统”等等。

在软件行业，许多项目以“系统”作为开发和运营的边界。尤其是数字化企业，通常需要多个系统来满足业务需求，有时甚至数千个系统并存。

​

上图为一个典型的企业系统化架构，其中云平台提供IaaS和PaaS能力，在此之上构建了包含多个系统的公共能力层，并基于公共能力层按业务领域构建各个业务系统。

系统化架构的困境

尽管这种系统化架构在过去十几年里取得了一定的成功，但随着企业规模的扩大，技术的日新月异，这种架构暴露出了越来越多的问题，具体表现为以下几点：

1. 运维保障难
   各系统使用不同的技术、运行环境，运维团队必须掌握多种技术和工具，导致运维成本居高不下。比如，数据库的运维可能需要同时管理MySQL、Oracle、PostgreSQL等多种技术；
2. 业务集成难
   各系统之间的交互协议差异巨大，导致业务集成变得困难且低效。比如，某些系统可能使用SOAP协议，其他系统则采用RESTful或gRPC协议；
3. 二次开发难
   由于不同系统使用不同的开发语言和框架，二次开发的难度加大。比如，某些系统使用Java，而其他系统则使用Python或Go语言；
4. 边界界定难
   各系统的边界模糊不清，导致业务流程的复杂性增加，并且存在重复开发的情况。比如，公共能力中提供了IAM能力，但仍有许多系统自建用户管理功能，结果导致重叠开发，无法充分利用公共能；
5. 数据治理难
   各系统的数据存储方式、业务命名不同，导致数据治理困难。比如对用户域的主数据命名不一致，A系统可能称之为“用户”，B系统可能称之为“客户”，C系统可能称之为“会员”。

这些问题的积累使得以“系统”为边界的数字化架构不仅增加了数字化的投入成本，而且在业务快速变化的背景下难以有效支持业务创新，同时难以满足用户体验和数据治理的需求。

规范与中台的演进

为了解决上述问题，业界普遍采取了两种策略：制定规范、建设中台/平台。

许多规模较大的企业都会制定针对软件采购、设计、研发、部署和运维的统一规范。这样做的核心目的是解决不同系统之间在开发、运维和数据层面上的不一致性。然而，确保规范的全面性和执行力却往往是一个巨大的挑战。为什么这么说？

最基础的两个问题是：怎么确保规范可以满足绝大部分的业务需求？怎么确保规范的执行落地？ 这需要企业有足够的规范制定能力、执行能力，以及对规范的监督能力。对于大多数企业来说，规范都只流于纸面，很难真正落地。

核心的原因是什么？康威法则（Conway’s Law）指出： “Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.” 简而言之就是 什么样的组织架构产出什么样的系统架构 。当我们都在关注软件规范设计执行时，实际上真正要先改变是组织架构。不同研发团队、业务团队的汇报关系、考核方式、利益分配方式，是导致不同系统间不一致且规范无法推行的根本原因。

在此背景下，“组织先行”的理念应运而生。即在进行中台建设之前，先调整组织架构，将多个小团队合并成规模更大的跨领域团队，进而提高规范执行力，从而解决不同系统间的割裂与不一致性。

上图为中台化架构的示意图，能够看到将相关能力相近的系统整合到同一领域中，形成了数据、技术和业务的中台。中台建设有一个通俗的说法是“打山头”，本质就是对系统进行整合和归并，减少不必要的重复建设，然后再基于相对统一规范的服务化能力，构建一个个小微应用。

但是，中台化的架构也是“理想很丰满，现实很骨感”。我在往期多次讲过，这里不赘述了。尽管这种做法能够减少系统数量，提高业务能力的一致性，但它并没有解决“系统化”的本质问题，只不过是将多个小系统合并成一个大系统。更重要的是，跨中台之间的协调问题仍然没有得到有效解决。

软件架构的本质

在继续深入探讨之前，我们不妨先回顾一下几个核心问题：

软件的本质是“数据+算法（或流程）”的集合。数据是软件的基础，算法是其灵魂。软件的最终目的是处理数据，并通过算法实现特定的业务逻辑。

软件的最小单位是“函数”。函数是软件的基本构成单元，函数之间通过参数传递数据，通过返回值传递结果。为了能够更好的复用函数，我们将函数封装成类、模块、库、服务等。

应用是为了解决某个具体的业务问题而开发的软件，并提供用户界面。而系统则是应用的集合，旨在解决一类或多个业务问题。

软件的架构就是一层层的套壳（封装），是典型的洋葱架构。在这个架构中，数据和算法是软件的核心，从最抽象的维度看，只要设计好了数据和算法，软件就可以运行。但从工程的角度看，我们需要将数据和算法封装成函数，将函数封装成类、模块、库、服务，将服务封装成应用、系统。

这也是“系统”存在的原因。在以前当我们说要去“系统”化时可能是天方夜谭，中台（本质还是大系统套小系统）化架构也未能解决。

但是，我们要明确的是工程化的手段也随着技术的进步在不断的演进。当我们从软件的本质出发，重新审视软件的架构时，会发现：其实我们并不需要那么多的系统，在AI时代，只需要一个“AI系统”就够了。

AI即系统

在之前的文章中，我提到过AI服务于数字化建设的阶段：模块AI化、系统AI化、AI即系统。AI即系统是数字化建设的最终目标，指的是将AI深度融入企业的核心业务和运营机制，推动业务从传统系统向全面智能化系统的转型。从传统的根据需求建立一个个领域系统转变成构建一个由AI驱动的大系统，通过自然交互实现需求。此阶段的核心特征是系统的全面智能化和自我优化，AI不仅支撑决策，还能直接执行业务操作，形成从决策到执行再到交互的自动化闭环。

下文将进一步探讨AI即系统的架构。

在AI即系统的架构中，AI操作系统（AIOS）是核心，它不仅具备常规的AI能力，还具备以下三个关键能力。

关键能力

数据管理能力

数据是AI的基础，若没有高质量的数据，AI便无从谈起。

数据管理的目标一是要能按规范“分门别类”地规划存储；二是要能按权限“安全可靠”的读写；三是要能按需求“快速准确”的查询。

数据管理在功能上包括数据采集、清洗、归一化、存储、查询等能力。PaaS层提供包含事务型的操作类数据及分析类数据的通用化的计算、存储能力，AIOS则实现定制化的数据处理能力。

数据管理在技术上没有特别之处，这一领域也不是AI所特有的。整体上是要将企业的领域模型与主流的数据治理的方案（比如DAMA-DMBOK）相结合。

当然，如果一定要说AIOS在数据管理上有什么特别之处，可能有两点：一是具备明确、规范的元数据信息，以确保AI可以准确地理解数据；二是包含更多向量的数据，以便AI可以更好地处理数据。

Agent管理

Agent也叫智能体，目前Agent是一个很宽泛的概念，可以是一个简单的脚本，也可以是一个复杂AI产品。

对AIOS而言，Agent的目标一是要能具备原子化数据CURD、函数（算法）的执行能力；二是要能具备针对一组流程化的需求的编排能力。

Agent在技术上最基础的是要能基于Function Call实现函数调用，其次要能具备联网查询、数据处理、API调用等通用化的能力。每个Agent本质上就是一个个有副作用（因为涉及外部数据）的函数。

响应式交互框架

为了能将用户的需求转化为AIOS的操作，AIOS需要具备响应式交互能力。

响应式交互框架可通过语音、视觉的方式输入用户意图并返回结果。何为“响应式”？就是能够根据用户的输入实时调整输出。比如用户说“我要看最新的销售数据”，AIOS可以实时返回最新的销售数据，而不是返回一个固定的、包含其它冗余信息的结果。

响应式交互框架在技术上最核心的是要构建一套DSL，要求Agent可以返回DSL格式的结果，同时AI也可以根据DSL格式的输入转换成纯文本、图像、复杂排版（HTML格式）的输出。特别是复杂排版的输出，需要涉及对模型的微调或训练，以确保输出的结果是符合用户期望的。

示例

AIOS最核心的三个能力介绍完毕，但在这此之上还需要构建一个响应式的通用应用，用于把响应式交互框架的能力包装到不同的平台之中。比如电脑、手机、智能音箱、车机等。

举一个简单的例子：用户在手机上通过响应式的通用应用说“我要看最新的销售数据”。其流程如下（需结合《AIOS助力数字化项目建设的畅想与实现路径》一文理解）：

1. [响应式的通用应用]用户说出“我要看最新的销售数据”；
2. [响应式交互框架]将用户的语音转化为合法的文本DSL作为输入；
3. [推理执行链-融合感知]根据Token获取用户身份，并将权限信息附加到请求中；
4. [能力监管]内容审计；
5. [推理执行链-意图理解]根据AI明确要查询销售数据，条件是最新记录；
6. [推理执行链-Function Call]命中销售查询Agent，但缺少必要的产品类型参数；
7. [响应式的通用应用]提示用户补充要看的产品类型；
8. [销售查询Agent]用户补充后进入销售查询Agent，该Agent根据传入的业务参数及权限条件生成业务查询SQL；
9. [数据管理]在数据管理中查询SQL并返回；
10. [销售查询Agent]将查询结果转换成合法的DSL作为输出；
11. [能力监管]内容审计；
12. [响应式交互框架]根据DSL转换成复杂排版（HTML格式）显示结果界面：一个整体的最新销售数据、按地区/门店的最新销售数据。

主流AI能力

除了这几个关键能力外，AIOS还需要具备主流的AI能力，以用于构建模块AI化、系统AI化。比如通过OpenAPI、低代码，将AI能力暴露给开发者，以便于构建较为固定的业务应用（上图的应用1、2、3）。

小结

“AI即系统”代表了数字化建设的终极目标，它不仅仅是一种技术升级，而是彻底改变企业运营的方式。届时企业数字化只有一个系统，即AI操作系统。通过将AI深度融入企业的核心业务，AI操作系统将极大提升效率和智能化水平，企业将不再依赖传统的多个分散系统，而是依托一个智能化的系统平台来驱动所有业务。这一愿景尽管尚未实现，但随着AI技术的飞速发展，我们可以期待这一目标在不远的将来成为现实。

彩蛋：纳德拉在一次采访中所表达的AI Agent或将替代所有SaaS （ https://www.youtube.com/watch?v=d6J4H1KaJ0A ） 也是对这个方向的一个预言。

阅读原文：原文链接