应用架构把业务需求转化为应用、模块、接口和平台能力的组合关系。面对AI进入业务系统的新变化，设计工作既要保持应用边界清晰，也要把模型服务、知识库和智能体纳入统一的架构资产与治理体系。本文按照需求推导、模块划分、应用协同、平台复用、AI融合、治理和实施的顺序展开。

一、为什么需要应用架构设计

业务需求通常以场景、流程和用户诉求的形式提出，但最终需要落实到具体应用、功能模块和接口。应用架构的任务，是明确企业需要建设哪些应用、每个应用承担什么职责，以及应用之间如何协同，从而避免系统按照部门或单个项目反复堆叠。

应用架构同时承担业务架构与技术架构之间的衔接作用。它把业务能力转化为可以建设和运营的应用能力，并为数据归属、集成方式、公共服务和技术平台提供结构依据。进入AI应用阶段后，AI能力多以功能调用的方式嵌入具体应用模块，未作为独立的架构资产进行定义和治理，这正是现有应用架构需要补充的部分。

二、从业务架构推导应用需求

应用需求应从业务能力、业务流程、业务事件和业务数据逐层推导。业务能力说明企业需要具备什么，业务流程说明能力如何在场景中被调用，业务事件界定应用何时响应，业务数据则帮助确定对象归属和责任系统。由此形成应用与数据中台集成清单、业务应用矩阵、角色功能矩阵、技术平台集成清单等，用于记录业务与应用之间的对应关系。

在设计步骤中增加AI需求分析、AI能力识别和AI服务设计等环节，能够在功能设计开始前判断场景是否真正需要AI，并识别所需模型、数据、知识和执行工具。对于应用和模块，还应增加是否包含AI能力的标识字段，以及所包含的AI能力类型和数量统计字段，便于从模块层面掌握AI能力的分布情况。

三、应用边界与模块划分

应用边界应依据业务能力、数据责任和变化频率确定。相互依赖紧密、共同维护同一组业务对象的功能可以归入同一应用；变化节奏、责任主体或安全要求明显不同的部分，则应保持清晰边界。应用与数据中台集成清单、业务应用矩阵、角色功能矩阵、技术平台集成清单等制品，可以帮助校验边界是否存在重复或缺口。

模块划分需要控制粒度。每个功能子项对应一个可独立描述、可独立实现的业务功能，使需求、开发和测试能够围绕同一功能单元展开。在评审时可以把“参考基准，确保每个功能子项对应一个可独立描述、可独立实现的业务功能单元”作为检查要求，避免模块过粗而难以迭代，或拆分过细而增加协作成本。

图1  从应用模块到平台能力的分层结构

四、应用之间如何协同

应用协同要根据实时性、一致性和业务耦合程度选择方式。同步调用、异步调用和事件驱动等不同集成模式的适用条件，应在接口设计阶段明确：需要即时返回结果的查询或校验适合同步调用；耗时较长、允许延后处理的任务适合异步调用；需要多个应用围绕状态变化作出响应的场景适合事件驱动。

无论采用哪种方式，都要说明调用方向、超时与重试、异常补偿、数据责任和链路追踪。中台服务还应增加中台服务类型、关联业务能力、关联应用模块、关联数据实体、服务等级、负责人等字段，使服务复用不仅有接口说明，还具备业务归属和运营责任。

五、从公共能力到平台化复用

客户、组织、合同、支付、消息和身份认证等共性功能不宜分散建设。应用架构应把重复能力沉淀为共享服务，并通过目录和矩阵说明服务支持哪些业务能力、由哪些应用调用以及维护责任。平台化复用的目标不是把所有功能集中到一个系统，而是让稳定的共性能力可以被多个业务应用按边界调用。

这一阶段需要统一应用与平台制品。优化后的制品模板完成功能项清单、应用模块清单以及新增的AI模型服务目录、模型调用矩阵、智能体清单等模板的填写，使传统功能、共享服务和AI资产能够在同一套架构视图中被识别。AI模型服务目录、模型调用矩阵、智能体清单等，则分别承担资产登记、调用追踪和智能体管理的作用。

六、AI能力如何融入应用架构

AI能力可以采用辅助型、嵌入型和智能体型三种方式进入业务应用。辅助型主要提供知识查询和内容生成；嵌入型在具体流程节点执行识别、预测或审核；智能体型则根据任务调用模型、数据和业务工具。不同方式对应不同的自主程度和风险水平。

AI能力的接入应以统一服务承载，而不是把模型逻辑固化在每个应用内部。需要记录各业务应用或功能项对AI模型服务的调用关系，并在元模型中新增AI模型服务、智能体、模型推理端点、模型训练流水线等构建块，使模型从技术组件转化为可识别、可复用和可追踪的架构资产。

智能体还需要形成独立视图：记录智能体的定义信息、协作关系和部署状态，并融入智能体的能力描述、触发条件、协作方式、感知数据源和执行动作范围等要素信息。这样才能判断智能体在什么条件下启动、与谁协作、可以读取哪些数据以及能够执行哪些动作。

图2  AI能力嵌入应用架构的基本方式

七、AI原生应用带来的治理要求

AI服务具有概率性、版本变化快和可能自主调用工具等特点，因此要在传统接口、权限和数据治理基础上增加模型与智能体治理。增加面向AI能力的设计原则，如模型服务与业务功能解耦原则、AI能力复用优先原则和智能体编排规范化原则，可以减少模型重复接入，并保证智能体协作具有统一约束。

治理对象应覆盖模型版本、提示词、知识库、推理端点、数据权限、调用成本、效果评测和异常回退。涉及资金支付、合同签署、敏感数据处理或重大决策时，应设置人工审批。治理结果还应回写模型服务目录、调用矩阵和智能体清单，形成从设计到运行的持续追踪。

八、应用架构的实施与演进路径

实施应按照业务需求、模块划分、共享复用、AI能力融合和持续治理逐步推进。企业先梳理现有应用与功能项，再明确应用边界、数据责任和集成方式；随后识别可复用服务，选择适合引入AI的节点，并通过试点验证业务价值与风险控制方式。

交付阶段要完成新增的AI模型服务目录、模型调用矩阵、智能体清单等模板的填写，并把它们与功能项清单、应用模块清单和中台服务目录建立关联。这样既可以追踪AI能力被哪些应用使用，也能在模型升级、智能体变更或业务流程调整时定位影响范围。

图3  应用架构的实施与演进路径

应用架构不是一次性设计成果。随着业务、组织、数据和模型持续变化，企业需要定期更新应用矩阵、服务目录和AI资产关系，并用实际运行结果校验模块边界、复用效果与治理规则，使架构能够持续支撑业务演进。

九、主要参考来源

[1] The Open Group. TOGAF Standard 10th Edition. 原文链接

[2] The Open Group. ArchiMate 3.2 Specification. 原文链接

[3] 国务院. 新一代人工智能发展规划. 2017. 原文链接

[4] 国家互联网信息办公室等. 生成式人工智能服务管理暂行办法. 2023. 原文链接

[5] Microsoft Learn. 微服务体系结构样式. 原文链接

[6] Microsoft Learn. 事件驱动体系结构样式. 原文链接

[7] Microsoft Learn. AI代理业务流程模式. 原文链接

[8] 萨姆·纽曼. 微服务设计（第2版）[M]. 北京：人民邮电出版社，2022.

[9] 埃里克·埃文斯. 领域驱动设计：软件核心复杂性应对之道[M]. 北京：人民邮电出版社，2016.

[10] ISO/IEC/IEEE 42010:2022. Systems and software engineering — Architecture description. 原文链接

[11] KRUTCHEN P. Architectural Blueprints: The 4+1 View Model of Software Architecture[J]. IEEE Software, 1995, 12(6): 42-50. 原文链接