智能体驱动的企业架构运营闭环

企业架构并不是一次性完成的设计成果。随着业务流程调整、应用功能迭代、数据关系变化和技术组件升级，已经形成的架构资产会不断发生变化。如果架构成果长期停留在规划设计和项目交付阶段，架构制品就容易逐渐与企业实际运行状态脱节。

智能体为企业架构从“静态建设”走向“持续运营”提供了一种新的实现方式。通过连接架构资产、运行数据、管理规则和相关业务系统，智能体可以持续感知架构变化，分析异常及其影响，辅助形成处置决策，并推动整改和资产更新。在明确权限和人工审核机制的前提下，企业可以逐步形成“感知—决策—执行—反馈”的架构运营闭环，使企业架构从静态成果转变为持续更新、持续治理的管理基础。

一、为什么企业架构需要持续运营

传统企业架构工作通常以规划、设计和项目建设为主要抓手，形成业务架构、应用架构、数据架构、技术架构和安全架构等一系列成果。但企业实际运行环境始终处于变化之中：业务流程可能调整，应用功能可能新增或下线，数据实体及其流转关系可能变化，技术组件也会持续升级。如果这些变化没有及时反映到架构资产中，架构设计与实际运行之间就会逐渐产生偏差。

因此，架构运营的核心不是简单维护架构图和台账，而是持续掌握架构资产的实际状态，识别设计与运行之间的偏差，分析变化可能带来的影响，并推动问题整改和架构资产更新。最终使架构资产能够持续反映企业真实状态，并进一步服务项目建设、架构治理、风险管控和资源配置。

传统方式主要依赖架构师定期检查和人工维护，面对数量不断增加、关系日益复杂的架构资产，容易出现发现问题不及时、影响分析依赖经验以及整改跟踪困难等问题。智能体的价值就在于把其中大量持续性、重复性的信息处理工作自动化，并把架构师的工作重点转向规则制定、结果审核、例外判断和重要决策。

二、智能体如何参与企业架构运营

智能体驱动的架构运营可以形成感知、决策、执行和迭代四个相互衔接的环节。

感知层负责连接企业架构库、项目管理平台、配置管理系统和运维监测系统等数据源，采集架构资产状态数据、运营指标数据和异常事件数据，并将这些数据映射到业务能力、应用系统、数据实体、技术组件等具体架构对象。在此基础上，感知层持续监测架构资产状态和运营指标变化，主动发现异常，形成架构变化和异常事件的统一输入。

决策层负责理解问题并分析影响。对于感知层发现的异常，智能体结合架构原则、技术标准、对象关系、预设规则和历史处置案例，根据预设规则和历史案例自主判断问题的性质、影响范围和处置优先级。在复杂问题处理中，还可以利用AI中台已有的大语言模型、分类模型和推理服务完成智能决策任务。与消息推送系统、任务管理系统等相关系统建立连接后，可以进一步将决策结果传递至执行环节，推动后续预警、整改和任务处理。

执行层负责将分析结果转化为具体治理动作。在授权范围和人工审核机制约束下，智能体可以自动推送预警、生成整改任务、更新架构资产、生成运营报告，并根据架构对象与责任主体之间的关系，将任务推送至相应责任部门或责任人员。

迭代层则负责跟踪问题处理结果，判断异常是否消除、整改任务是否完成以及相关架构资产是否同步更新，并通过收集处置结果和用户反馈持续优化决策模型。经过持续运行，新的处置经验可以进一步沉淀为规则和案例，形成下一轮架构运营的知识基础。

由此，智能体不只是提供架构问答，而是逐步参与从问题发现、分析判断到任务执行和结果反馈的完整运营过程。

图1 架构运营智能体四层运行机制

三、智能体如何感知架构变化并发现问题

智能体开展架构运营的第一步，是建立对企业架构状态的持续感知能力。感知对象不仅包括架构库中的静态制品，还应包括能够反映实际运行状态的系统配置、接口关系、运行指标和异常事件。

例如，架构资产记录某应用系统使用某一技术组件，而实际运行环境中该组件已经升级或替换；架构设计规定某项业务能力由特定应用功能支撑，但项目建设过程中功能关系发生变化；或者某个接口调用关系、数据流转关系发生调整但尚未同步到架构资产。此类变化都可能造成架构设计与实际运行之间的不一致。

因此，需要将不同来源的数据首先映射到统一的架构对象，再对架构对象的状态、属性和关系进行持续比较。当系统接口变化、组件版本变化、应用状态变化或者运营指标持续偏离正常范围时，智能体可以识别对应的异常对象，并记录变化内容、发生时间、数据来源及关联对象。

这种方式使架构运营从传统的周期性人工盘点逐步转变为基于数据变化的持续监测，为后续影响分析和问题处置提供更加及时、完整的输入。

四、智能体如何完成分析、决策与任务执行

发现异常并不意味着可以立即采取行动。同一类变化可能具有完全不同的影响程度，因此智能体还需要结合企业架构中的对象关系、管理规则和历史案例进行分析。

例如，一个普通应用模块的属性变化可能只需要更新架构台账，而一个被多个系统共同依赖的共享组件发生重大版本变化，则可能影响多个应用、接口和业务流程。智能体可以沿架构关系进一步分析受影响对象，并结合架构原则、技术标准、历史案例和预设规则判断问题性质及优先级。

对于规则明确的问题，可以直接按照预设规则进行判断；对于需要综合多个条件的问题，则可以结合大语言模型、分类模型和推理服务进行辅助分析。模型负责理解问题和生成建议，架构规则和资产关系则为判断提供事实依据和约束条件。

分析完成后，智能体进一步将建议转化为治理任务。例如，对一般性问题推送预警，对需要责任部门处理的问题生成整改任务，对已经确认的架构变化更新相关资产，对一段时期内的问题及整改情况汇总形成运营报告。

但智能体的自主执行应当存在明确边界。对于一般性的提醒、任务生成和状态更新，可以根据权限自动执行；对于涉及核心系统变更、架构原则调整、跨专业域重大影响等事项，则应由智能体形成分析结果和处置建议，经架构师或相关责任人员审核后再执行。

五、如何形成持续优化的架构运营闭环

真正的架构运营不能停留在“发现问题并发出预警”，而应继续跟踪问题是否得到解决以及架构资产是否完成更新。

一个完整的运营过程可以按照“状态感知—异常发现—问题分析—形成建议—审核决策—任务执行—结果验证—资产更新”的链路运行。整改任务完成后，智能体重新采集相关状态数据，验证异常是否消除，并检查对应架构资产是否与实际状态重新保持一致。

执行结果还可以成为下一轮决策的重要输入。对于已经验证有效的处置方式，可以沉淀为新的规则或历史案例；对于出现误判、漏判或者处理效果不佳的情况，则可以分析原因，调整判断规则、阈值、提示策略或者相关模型。

这样就形成了从架构状态变化到问题处置，再从处置结果反向优化规则和模型的闭环。随着运行数据和案例不断积累，架构运营能力也可以持续迭代，而不是每次遇到问题都重新依赖人工经验判断。

需要注意的是，持续优化并不意味着让模型自行修改所有规则。架构原则、关键规则和重大处置策略仍应由架构师审核确认，模型优化也应建立版本、评估和回退机制，确保架构治理过程始终可控、可追溯。

图2 智能体驱动的企业架构持续运营闭环

六、如何逐步建立智能体驱动的架构运营机制

智能体驱动的架构运营不适合一开始就追求全自动化，更合理的方式是按照风险和成熟度逐步扩大应用范围。

初期可以从架构资料查询、架构资产盘点、状态变化提醒和规则检查等低风险场景开始，重点验证数据连接、架构对象映射、规则准确性以及权限控制机制。在这一阶段，智能体主要承担信息采集、问题发现和辅助分析工作，重要结果仍由架构师审核。

在数据和规则逐步完善后，可以进一步扩展到跨域影响分析、异常分类、整改任务生成、状态跟踪和运营报告生成等场景，使智能体逐渐参与架构运营的完整流程。

当架构资产、规则体系、历史案例和权限机制达到较高成熟度后，再逐步开放部分标准化、低风险任务的自动执行能力。对于涉及核心架构对象、重大业务影响和高风险操作的事项，仍应坚持人工审核和最终决策。

最终形成的并不是一个完全替代架构师的“自动架构系统”，而是一套由智能体承担高频感知、分析和执行工作，由架构师负责规则、审核和重要决策的协同运营机制。通过持续监测、智能分析、任务执行和反馈优化，企业架构可以从阶段性交付成果逐步转变为能够持续反映企业实际状态、支撑治理决策并不断演进的动态架构资产。

参考来源

[1] The Open Group. TOGAF Standard, 10th Edition.

[2] NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023.

[3] Russell S, Norvig P.《人工智能：一种现代的方法》. 人民邮电出版社.

[4] 国务院.《新一代人工智能发展规划》. 2017.

[5] 国家互联网信息办公室等.《生成式人工智能服务管理暂行办法》. 2023.

[6] Microsoft Learn. AI代理业务流程相关参考架构与多代理工作流自动化参考体系结构。