企业端AI软件架构的变革
前文提过,AI时代,软件会发生翻天覆地的变化,特别是对于企业端软件来讲,可能更为剧烈。那么具体的,会往哪个方向发展呢?我们可以放开畅享。本文仅为笔者多年从业经验和判断,权当一家之言,用来抛砖引玉。
在设计系统之前,需要先清楚目标,因此我们先从逻辑角度做一个简单假设 – AI时代B端软件架构为目标,结合所了解的企业端软件特征,和现阶段AI发展情况,来分析软件架构的演进方向。
为了满足企业端软件诉求,我们需要先了解这些应用软件的通用特征:作为服务于企业端(B端)的软件应用系统,服务贯穿于企业运作的全生命周期,负责并不仅限于处理各种内部流程,挖掘跟进服务用户与客户的各种诉求,对企业资源调配进行调度跟踪,对经营数据进行汇总统计分析等,常见的有涉及内部管理的OA系统,各行业的ERP系统,发掘服务客户的CRM系统,进行财务统计分析的财务系统,以及进行数字化分析与挖掘等数字系统等等。这些系统虽然千差万别,但总会有几个基本的共同特征:
1、数据和功能属主都完全归属于企业,员工只是服务于企业的角色,并不拥有相关数据和功能的控制权。也就是数字资产属主是企业,企业拥有绝对控制权。
2、员工因角色岗位的不同,处理不同的工作,也分担不同的职责,能够获取不同级别的信息。比如高职级高岗位的员工,有更高的权限,能够接触到数据越多,风控或者审核岗需要专岗专用,不允许兼任等。也就是权责划分必须清晰,不能发生任何权限越权和数据越权。
3、流程调整需要快捷,适配企业业务的变更。同时成本要近可能低,但效率要快。
简化来讲,强效的控制、绝对的安全与相对的灵活性,一直是企业端软件的基础要求。但是这些要求,对于混沌的AI系统来讲,却往往与其格格不入。那么,企业端的AI应用,难道除了类似自动客服、数据分析等不涉及经营核心的功能之外,就没有其他发挥余地吗?
答案是否定的。前边提过,AI更多的,是效率与生产力的提升,而不是对现有软件的完全替代。结合现有软件架构和技术能力,以及Openclaw等Agent架构模式的启发,企业端软件很明显也会进入一种数字人与自然人辅助工作的混合模式之中。而应用系统架构的变化,也应该更适配于这种转变。
结论先行,下图是笔者对于未来企业端软件智能架演进的一种设想:

现在对该架构进行一些简要的描述。
1、Company Domain 为公司域,会定义一些最常用的功能流程等技能,可以通过现今最流行的Skill、MCP、Tool、提示词或者其他方式,提供一些公司通用级别的功能,这些功能可服务于大模型和Agent.
2、Group Domain、Duty Domain为组织域和岗位域,与公司域类似,其也用于定义功能与能力。但这些能力可能更细化,可以与组织结构、岗位职责息息相关,比如,财务部可以使用财务系统,研发岗可以使用代码仓库。
3、Remote Workspace为核心,可以称为远程工作空间。每一个员工,均有一个独立的、隔离的工作空间。工作空间里依据员工角色、岗位以及职责等,自动构建Profile.通过继承,员工Profile拥有了服务于公司的全套AI能力,另外,也可以支持自定义,为不同员工灵活的增加新的AI能力,从而提升灵活性。
4、Agent Area为AI Agent部署区域,Agent可以根据用户诉求,进行各种调度以及工作执行等。
5、User Storage区域为存储区,用于保存所有交互记录、用户工作产出与数据等。格式可以是文件、数据或者访问记录。
6、LLM大模型区域,可以根据公司需要和实际情况,部署一套或多套大模型,比如适配性最广的通用模型、为编程岗设置的代码模型、提升绘图效率的制图模型、用于财务分析的财务模型等,这些模型依据不同情况,供Agent调用,不直接面向用户。
7、Application Area最特殊,为企业已经存在的应用域,通过MCP、Skill等手段,现存的应用功能,可以非常方便的开放给Agent,从而让Agent真正具备工作能力。
8、Operation Log用于记录用户记录,不管是哪一类的,均需要详细记录下来,用于后续的审查审计;而Change Log相对特殊,涉及变更类的操作,必须登记有独立的变更记录,以防Agent发生破坏性调整,或者之前的调整需要追溯。
9、Interact Gateway提供了对外部服务的能力,在交互过程中,也负责对输入输出进行审查,保护内部代理不受非法请求攻击,也避免代理意外暴露数据到外部。
10、以上所有的部分,均位于Infrastructure Layer,也就是基础设施之上,控制权和所有权均完全属于企业。
11、Local WorkSpace为本地终端工作空间,此空间属于可选项,且可能会有多种载体,量级也可能根据实际情况有所不同。比如,在桌面电脑上的本地终端工作空间,可以加密存储少量配置,提供轻量Agent能力,但是对接于微信、QQ、钉钉等通讯软件的终端,可以仅用于发送和接收消息。
Agent Area是比较特殊的一个区域。根据Agent的目标-能够代替人类干活来讲,Agent的开发结构,也会比较特殊。结合软件客户端经验,未来的Agent,模式大概率为以下两种:

第一种见上图,为主Agent模式,执行特殊或者特定目标任务时,可以通过Sub Agent来工作。也可以简化一下,即具备上下文切换能力的Agent. 现阶段主流Agent其实是这种模式。结合以前的客户端开发经验来讲,这种模式可以与客户端软件里的主线程-工作线程作为对比,因此Sub Agent就像一个个子线程。

第二种模式看起来与第一种类似,但有着本质的区别。Main Agent不负责直接工作,它直接负责Context调度,每一个Sub Agent就像一个独立的进程,彼此是隔离的。因此,其安全性更高,但复杂度却增加了。
对比来看,这两种实现方式就像浏览器的内核实现一样,有基于线程的和基于进程的。具体哪一种更优,其实取决于时机和实际的工程能力。
回过头来,再整体的审视一遍完整的架构设计。
由于主体功能部署在服务端,因此,数据和功能属主完全属于企业,企业有完整的所有权;AI技能和功能通过不同域设置,由于经过专家审议,因此安全性也有了保障;同时,结合MCP和Skill等,现存的应用也可以快速赋能,通过AI能力可以进行逐步开放,能够控制AI化节奏;不同的Profile不但实现了千人千面,也可灵活自定义增加能力,支持小范围灰度验证也可快速迭代支持,数字人也可在这里进行逻辑抽象;Agent区域和LLM区域配合,以配置和插拔方式部署,不但可以快速体验最先进的AI能力,在快速推进覆盖时可使用类似Docker的方式升级;存储区域独立,用户使用数据隔离,既确保了安全性,也可以不受Agent升级影响;操作留痕,审计可以确保操作安全,而类似git之类的变更记录,可确保一切数据可回溯。
灵活的客户端可自由裁剪,既可以在PC上安装重量级功能完善的个人助手,也可以在微信等工具上轻量配置。
本文欢迎转载,请著名作者出处。
夜雨聆风