AI原生应用架构是什么样子?

AI原生的应用架构不仅要解决AI模块怎么设计和集成的问题，而且要解决传统技术模块怎样被AI模块感知、驱动、编排的问题。企图在旧的事件驱动应用架构中集成AI能力就好比在牛车上使用内燃机，愚蠢低效。传统的ERP、CRM、OA等企业应用必将被新的AI原生应用架构以及开发范式所重塑。

事件驱动是当前所有企业应用的基本开发范式。无论是CPU响应中断信号调用驱动程序，还是Web服务根据用户点击执行业务逻辑，都是事件驱动的典型场景。事件驱动的系统，其基本关系是事件与响应者（函数）之间的关系、事件和函数之间的映射关系，这种关系存在明确的记录且在系统开发时就已被确定。在此背景下设计的系统架构，不用支持函数的自描述/可解释性、动态性（热生成、热加载）。由AI智力驱动的系统，系统模块要实时按意图识别、感知、调用，系统模块（工具函数）应该是自描述、热加载、热替换的。

应用架构和开发范式必须在应用工程层面创新，走向以AI智力为核心，由AI智力驱动的新模式，但也不意味着完全抛弃事件驱动。面向人类操作的事件驱动模式依然有其价值，AI驱动需要兼容原有的事件驱动能力，这是实现人和AI协同工作的前提。JitAi正是在这个方向上取得了突破，JAAP（JitAi AI Application Protocol）和JitAi应用运行平台扮演着关键角色。

统一的模块感知机制

要让AI驱动应用系统，首先需要让AI理解系统中有哪些模块、每个模块能做什么。JAAP作为结构化解释型的应用架构协议，从结构上定义了应用系统的构建标准和模块化架构。应用构建产物中自动包含JAAP所要求的声明信息，这些声明信息清晰、准确、结构化，天然适合AI理解且不冗余。

符合JAAP的应用，其前后端模块都是自描述的，这种自描述性为AI感知和驱动全栈系统模块奠定了基础。

统一的模块驱动机制

在传统系统中，模块是黑盒的，AI无法理解模块的特性和使用方法，AI能力和系统功能处于割裂状态。JitAi改变了这一局面，在JitAi应用中，AI模块通过解读其他系统模块的声明信息，使用统一的语法调用它们。AI模块的开发者不需要为每个系统模块单独适配调用方式，这大幅降低了集成复杂度。

统一的模块热加载机制

AI应用的功能边界往往难以预先规划，相比传统应用更需要快速迭代和即时调整。静态依赖、硬编码的开发方式无法满足AI应用边用边改、快速反馈的要求。

JitAi应用运行平台作为跨平台的应用运行容器，对符合JAAP的应用进行解释、加载和运行，实现了系统模块的动态加载、动态调用和运行时热插拔替换。JitAi应用的模块是自加载的，模块加载过程没有任何外部耦合。平台和应用的关系可以类比为JVM和Java字节码、Docker和Dockerfile的关系。

规范化的系统模型

让人和AI都能轻松理解系统，关键在于对系统进行规范化建模。AI能够很好地理解规范化的内容，但理解成本取决于规范的抽象层次。例如，编程语言语法虽然规范，但因为是细粒度、微观的规范，学习成本较高。越微观的内容理解成本越高，越宏观的内容理解成本越低。这一原理同样适用于AI，越宏观的内容，AI理解越快越准，token消耗也越少。

复杂度不能消除，只能转移。企业应用开发经过多年沉淀，已经形成大量普适通用的业务功能模式和组件。JitAi提出了Meta/Type/Instance的三层系统模块结构：Meta定义领域和类别，Type封装技术实现并开放数量可控的配置项，Instance承载应用层的个性化业务配置。

这种结构将复杂度控制在了应用层之外，应用层的复杂度极低，容易理解。人类开发者可以借助JitAi的可视化开发工具快速完成业务应用的模块开发，AI也只需消耗极少的token就能更准确地完成应用模块开发。