应用架构设计方法：从应用模块到AI能力融合
随着大模型、智能体等AI能力逐步进入企业业务流程，应用架构设计的对象正在发生变化。传统应用架构主要回答业务需求由哪些应用、模块和功能承载，以及不同应用之间如何集成协同；进入AI应用阶段后，还需要进一步回答哪些业务功能需要AI、调用什么模型服务、模型能力如何复用、智能体如何参与业务流程，以及这些AI能力如何作为正式架构资产进行统一管理。
因此，AI与应用架构融合并不是简单地在现有系统中增加模型调用，而是需要在原有应用架构方法基础上，对设计对象、元模型、设计原则、设计流程和架构制品进行系统扩展，使AI模型服务、智能体等新型能力能够与应用系统、应用模块和功能项建立明确关系，最终形成可设计、可记录、可追踪、可治理的应用架构体系。
一、应用架构如何从业务需求形成应用设计
应用架构的基础任务，是将业务需求逐步转化为应用系统、应用模块和功能项。业务能力回答企业需要“具备什么能力”，业务流程描述业务“如何运转”，应用架构则进一步明确这些业务活动由哪些应用和功能进行支撑。
因此，应用架构设计首先需要从业务能力、业务流程、业务对象和业务需求出发，识别需要建设或改造的应用能力，再逐步落实到应用系统、应用模块、功能项及功能子项。应用边界的划分需要综合考虑业务职责、数据责任、变化频率和系统耦合关系，避免同一业务能力被多个系统重复建设，也避免单一应用承担过多不相关职责。
在功能设计层面，还需要进一步控制功能颗粒度。功能项可以根据业务活动继续分解为功能子项，并以业务上能够独立描述、技术上能够独立实现为基本判断依据，确保每一个功能子项对应一个可独立描述、可独立实现的业务功能单元。这一颗粒度可以作为功能子项的分解参考基准，确保每个功能子项对应一个可独立描述、可独立实现的业务功能单元。明确业务需求、应用设计、开发实现和后续评审能够建立相对稳定的对应关系。
应用之间还需要通过集成关系形成协同。针对不同业务场景，可以根据实时性、一致性和业务耦合程度选择同步调用、异步调用或事件驱动等集成方式，并通过应用系统集成清单、应用与数据中台集成清单、业务应用矩阵、角色功能矩阵、技术平台集成清单等架构制品，记录应用之间以及业务、数据、平台与应用之间的关系。
这些内容共同构成传统应用架构设计的基本框架，也是进一步融入AI能力的基础。
二、AI进入应用架构后发生了什么变化
传统应用架构中，AI能力往往以算法接口或功能调用的方式嵌入具体应用模块，未作为独立的架构资产进行定义和治理。这种方式在AI应用规模较小时问题并不明显，但随着同一模型被多个应用调用、多个智能体参与业务流程，以及模型版本和推理服务不断变化，仅仅记录“某个功能用了AI”已经无法满足架构管理要求。
因此，应用架构首先需要改变对AI能力的认识：AI模型服务不应只是某个应用内部的一段实现逻辑，而应作为能够被不同业务应用复用、调用和治理的独立能力；智能体也不应仅仅作为应用功能的技术实现，而需要明确其业务职责、触发方式、协作对象、数据来源和可执行动作。
在原有应用架构元模型中新增AI模型服务、智能体、模型推理端点、模型训练流水线等构建块，并分别建立其与业务功能、应用模块、数据和技术资源之间的关系。例如，功能项可以“调用”AI模型服务，智能体可以“调用”模型服务和业务工具，模型服务可以“部署于”模型推理端点，推理端点进一步关联底层技术资源。
通过这种方式，AI能力才能真正从隐藏在应用内部的技术实现，转变为企业能够统一识别和管理的架构资产。
图1 AI扩展后的应用架构元模型及对象关系
三、AI能力如何融入应用架构设计过程
AI能力纳入应用架构后，并不意味着所有业务功能都需要使用AI。应用架构设计仍然应从业务需求出发，首先判断哪些业务问题适合使用确定性的传统应用逻辑，哪些场景需要模型的识别、预测、生成和推理能力，以及哪些复杂任务适合通过智能体协同完成。
因此，需要在传统架构设计流程中增加AI需求分析、AI能力识别和AI服务设计等环节。AI需求分析重点判断业务场景是否确实需要AI；AI能力识别进一步明确所需能力属于文本生成、知识问答、分类识别、预测分析、智能决策还是智能体执行；AI服务设计则确定相应能力由什么模型服务提供、是否能够复用现有能力，以及如何与业务应用建立调用关系。在具体模型设计过程中，应确保模型能力与应用架构整体设计保持一致。模型采用分层可扩展架构，各层之间通过标准化接口交互，支持规则库的动态更新和AI模型的持续迭代。
在此基础上，还需要增加面向AI能力的设计原则，如模型服务与业务功能解耦原则、AI能力复用优先原则和智能体编排规范化原则。
其中，模型服务与业务功能解耦，是指业务应用原则上通过标准化服务调用模型，而不是把具体模型直接固化在业务功能内部，使模型能够独立升级和替换；AI能力复用优先，是指对于已经形成的模型服务，应优先评估是否能够满足新的业务需求，减少同类能力重复建设；智能体协作则需要明确角色职责、任务边界、调用权限和协作关系，避免多个智能体之间出现职责重叠或无序调用。
这样，AI融合就不再是项目建设后期增加一个AI接口，而是从业务需求和应用设计阶段就进入正式的架构设计过程。
四、应用架构制品如何扩展以承载AI能力
仅仅修改设计方法还不够。如果现有架构制品无法记录AI模型服务、智能体及其调用关系，新的设计方法最终仍然无法沉淀为企业架构资产。因此，AI与应用架构融合还需要同步扩展现有应用架构制品模板。
首先是功能项清单。需要增加“是否调用AI模型”等标识字段，以及调用的模型服务列表，使每个功能项与AI能力之间的依赖关系能够被识别和追踪。
其次是应用模块清单，需要增加是否包含AI能力的标识字段，以及所包含的AI能力类型和数量统计字段，便于从模块层面掌握AI能力的分布情况。这样不仅可以知道某个功能是否使用AI，还能够进一步从应用和模块层面统计AI能力的覆盖情况。
对于无法由传统应用架构模板完整承载的新型AI资产，则需要增加专门制品。其中，AI模型服务目录用于统一登记模型名称、模型类型、所属领域、版本、服务状态等基本信息；模型调用矩阵用于记录各业务应用或功能项对AI模型服务的调用关系、调用频次和调用方式；智能体清单用于记录智能体的定义信息、协作关系和部署状态。模型变更影响分析表则用于记录模型版本发生变化时受影响的应用、功能和智能体。
因此，AI融合后的应用架构制品体系并不是完全替代原有模板，而是在功能项清单、应用模块清单、应用系统集成清单、应用与数据中台集成清单、业务应用矩阵、角色功能矩阵、技术平台集成清单等现有制品基础上，补充AI模型服务目录、模型调用矩阵、智能体清单和模型变更影响分析表等新的制品。
通过这些模板，可以把原来隐藏在代码、接口和技术实现中的AI能力显性化为正式架构资产。
五、智能体如何作为新的应用架构对象进行设计
与普通模型服务相比，智能体不仅提供一个输入输出接口，还可能根据任务理解结果自主选择模型、查询数据、调用工具并执行动作，因此需要更加完整地描述其架构特征。
在架构制品中，需要融入智能体的能力描述、触发条件、协作方式、感知数据源和执行动作范围等要素信息。能力描述说明智能体能够完成什么任务；触发条件说明在什么业务事件或用户指令下启动；协作方式描述智能体之间以及智能体与人员、应用之间如何协同；感知数据源明确其可以读取哪些业务数据和上下文；执行动作范围则规定智能体可以调用哪些工具、修改哪些对象以及哪些操作必须经过人工确认。
同时，智能体需要与模型服务、应用功能和业务流程建立明确关联。例如，一个合同审查智能体可能由合同审查功能触发，调用大语言模型和企业知识库进行分析，再调用业务系统获取合同数据，最终生成审查意见。此时，应用架构需要同时记录“业务功能—智能体”“智能体—模型服务”“智能体—数据源”“智能体—业务工具”等关系。
这种设计方式使智能体不再只是一个笼统的“AI功能”，而成为能够在企业架构中被定位、分析和治理的正式架构对象。
六、如何通过试点形成完整的AI应用架构成果
AI与应用架构融合最终需要通过具体业务场景验证，而不能停留在方法和模板层面。试点可以选择具有明确业务需求、可获取数据和可衡量效果的典型场景，将前述方法完整应用到实际架构设计中。
首先以试点业务需求为输入，完成业务能力、流程和功能分析，在传统应用架构基础上识别AI需求和AI能力；随后定义需要调用的AI模型服务以及参与业务流程的智能体，并建立AI能力与业务功能之间的对应关系。
在模型和智能体设计完成后，可以进一步绘制模型部署视图、AI调用链视图和模型数据流视图，使模型部署位置、业务调用过程以及模型相关数据流向能够被直观表达。
最后，运用更新后的制品模板完成功能项清单、应用模块清单以及新增的AI模型服务目录、模型调用矩阵、智能体清单等模板的填写；其中，功能项清单标注是否调用AI模型及其调用的模型服务，应用模块清单标注是否包含AI能力及AI能力类型和数量。在完成相关架构制品设计后，可以进一步对制品的完整性、规范性和关联关系进行检查，并形成相应的检查结果，包含通过项、警告项、不通过项及具体原因，并给出修复建议。
通过这一过程，可以形成从业务需求、功能设计、AI能力识别、模型服务设计、智能体设计到架构制品沉淀的一套完整成果，以及新增的AI模型服务目录、模型调用矩阵、智能体清单等模板的填写，确保在架构制品中完整融入AI相关要素。
AI能力也会持续发生变化，因此这些架构成果还需要进入后续治理。当模型版本发生变化时，可以通过模型调用矩阵快速定位受到影响的业务应用和功能项，并通过模型变更影响分析表开展影响评估；智能体能力、协作关系或者部署状态发生变化时，则同步更新智能体清单及相关架构关系。
由此，AI与应用架构融合形成的并不是几张新增模板，而是一套“业务需求—应用功能—AI能力—模型服务/智能体—部署运行—持续治理”的完整架构链路，使AI能力真正成为可识别、可复用、可追踪和可治理的企业架构资产。
图2 AI应用架构设计、制品沉淀与持续治理链路
参考来源
[1] The Open Group. TOGAF Standard, 10th Edition.
[2] The Open Group. ArchiMate 3.2 Specification.
[3] ISO/IEC/IEEE 42010:2022. Systems and software engineering — Architecture description.
[4] Newman S. Building Microservices, 2nd Edition. O’Reilly Media, 2021.
[5] Evans E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003.
[6] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.
[7] 国家互联网信息办公室等.《生成式人工智能服务管理暂行办法》. 2023.