AI 大模型驱动下的企业软件架构设计思考

企业应用架构· 思考与实践

引言：架构的坐标系变了

过去二十年，企业软件的架构设计基本围绕一个隐含假设展开：人是操作者，软件是容器。我们把业务规则编译进代码，把数据约束写进表结构，把操作路径固化成界面上的按钮和表单。用户要做的，是学习并适配软件的既定路径。

大模型和智能体把这条路径反过来了。当软件开始理解自然语言、能调用工具、能自己规划步骤，架构的重心就从"如何把业务装进软件"迁移到"如何让软件理解业务"。这不是加一个 AI 助手——它动摇的是分层方式、交互范式，以及我们对"确定性"的实现手段。

作为架构师，我更关心三个具体问题：企业级场景的硬约束能不能守住？表单、流程、分析这三类主流应用要改成什么样子？架构师自己还剩下什么工作？这是本文想谈清楚的三件事。

一、企业软件的三个不等式

谈智能体架构之前，必须先承认一个前提：企业应用和消费端应用不是同一类问题。消费端追求惊喜、留存、转化，容错空间大，一次推荐错了顶多被划走；企业应用追求的是可重复、可审计、可追责，一次判断错了可能是一条停机的产线，或一笔违规的支出。

三条例线：

标准化：同一个动作，无论谁执行、什么时候执行，结果语义一致。流程、口径、权限都必须有唯一正解。

确定性：关键路径上不能"每次都不太一样"。审批能不能过、库存够不够扣、这笔钱该不该付，答案必须可复现。

安全性：数据不能出域，动作不能越权，模型的每一次判断都要留痕。

这三条，恰恰是大模型天然不擅长的。所以企业级智能体架构的第一原则不是"让模型更聪明"，而是给智能体设计一个能让它聪明但不失控的结构。

图 1　企业级智能体应用分层架构

五层的职责必须分清：

1.交互层：会话、表单、看板、大屏。入口不再固化，同一份能力允许多种呈现。

2.智能体编排层：意图理解、任务规划、多智能体协同。这一层是新增的，也是最不确定的一层。

3.工具与协议层（MCP）：把企业系统的能力暴露成标准化的工具契约——查库存、取指标、发起流程、读写文档。MCP 的价值不在协议本身，而在于它把"能力"和"调用方式"解耦了。

4.企业系统与数据层：ERP、EAM、工单、预算、时序库、数据仓库，仍然在原地，不推倒重来。

5.治理与安全层：身份、权限、审计、评测、成本。这一层横切所有层，也是企业架构与个人玩具的分水岭。

二、核心命题：大模型能做确定性的事吗？

这是我被问得最多的问题，也是很多企业不敢上智能体的根源。

我的答案是：能，但不能靠模型本身来保证。 要把"确定性"拆成两件事看。

语义确定性——"这张申请该不该走备件领用"，本质上是一个业务判断，包含大量上下文。这类事情过去只能靠人，现在可以交给模型，因为它比固定规则更能容纳例外。

执行确定性——"扣减库存 3 件""生成工单号 WO-20261104-007"，必须幂等、可回滚、可复现。这类事情绝不能交给模型的概率分布。

所以确定性的实现方式变了：从"用代码写死逻辑"，变成"用契约锁死边界"。

图 2　从意图到执行的确定性梯度与治理手段

图 2 是一个我常用的思维模型：越往左，概率性越强，允许模型发挥；越往右，确定性要求越高，必须落到工程手段上。

落到工程上是三道护栏：

第一道，结构化契约。 模型不直接操作数据库，只输出结构化意图，由 JSON Schema 约束工具调用。参数类型、枚举范围、必填项由 Schema 卡住——模型再"幻觉"，也进不了执行层。

第二道，状态机约束。 智能体的一切动作都要挂在业务流程的状态机上。它可以决定"从 A 到 B 走哪条路"，但不能凭空造出一条从 A 到 D 的边。硬性节点的顺序、审批的前置条件，由引擎守护，而不是由提示词守护。

第三道，人在环审核。 高风险动作（资金、停机、对外承诺）默认停在"待确认"，人的角色从"执行者"变成"签发者"。这一道听起来保守，却是企业敢于把权限交出去的前提；等评测数据积累够了，再把部分动作降级为"事后抽检"，这条演进路径才可运营。

三、表单类应用：把"填表"变成"确认"

企业里最浪费人的一件事，是填表。

一张设备缺陷单，十几个字段：设备编码、位置、缺陷类型、紧急程度、发现人、发现时间、处理建议……其中真正需要人判断的，可能只有"缺陷类型"和"紧急程度"两项，其余全是搬运——从现场记录搬到系统里，从上一个系统搬到下一个系统。

传统做法是优化表单：减少必填项、做联动、做默认值。但界面范式没变，仍然是"人找数据、人录数据"。

智能体给了另一个选项：表单由系统生成，人只做审核。

图 3　表单交互范式迁移：从"人填系统"到"系统起草、人签发"

新范式下，一条缺陷记录是这样诞生的：

1.巡检人员在现场对着移动端说一段话，或拍一张照片；

2.智能体从这段非结构化输入里抽取字段，同时去设备台账反查设备编码，去历史工单找相似缺陷的处置方案，去备件系统看有没有对应备件；

3.生成一张"草稿单据"，把不确定的字段标黄，把推断依据一并给出——"设备编码根据位置与图像识别推断，置信度 0.92"；

4.人只做两件事：确认，或修正。

这个改动看似只是界面变了，实际影响有三层：录入成本下降一个量级，人从"填十项"变成"看一屏、点一下"；数据质量上升，字段由系统反查补齐，重复主数据、错填编码这类问题从源头消失；可追溯性增强，每个字段都带来源和置信度，比人手填的"凭记忆"更可信。

架构上要特别注意一点：表单不再是前端组件，而是智能体的输出物。 表单 schema 应该由领域模型统一定义——一份元数据同时驱动会话抽取、校验规则、渲染形态、入库映射。否则你会得到三套互相对不上的字段定义，智能体越勤快，数据越乱。

四、流程类应用：标准内核 + 智能体外沿

流程类应用是企业的骨架，也是最不能乱动的地方。我的判断很明确：硬性标准流程仍然要由工作流引擎驱动，这一点在可预见的未来不会改变。

原因不在技术，在责任。审批层级、会签规则、超时升级、留痕归档，这些是制度而不是智能。制度需要的是一个可审计、可解释、可复现的执行器；而大模型的输出是概率的，天然不适合承担制度的执行责任。

但这不意味着工作流引擎要保持原样。真正有价值的改造点在节点内部，尤其是两类节点。

一类是判断分支节点。 过去这类节点要么挂着一个人工审批，要么写死一段 if-else 规则。现在可以换成智能体判定——它读的是完整上下文，而不是几个阈值。

举个例子：一张检修工单流转到"领用备件"，传统做法是让人去查库存、查在途、查替代件，再决定是领用还是发起采购。这个过程在系统里表现为两个分支、三次跳转、平均两天的等待。换成智能体后，它在工单到达该节点的瞬间就完成分析：本地库存、在途数量、历史消耗速率、供应商交期、设备停机风险，一次性给出结论和理由，人只需要确认。

更进一步的场景是跨流程的聚合。当大量采购申请同时涌入时，智能体可以提前识别出同类型、同供应商、同时间窗的采购项，做合并询价，甚至在流程还没走到采购岗时就把询价单发出去。这不是"加快审批"，而是改变了流程的触发时机——从"人推着流程走"变成"流程自己找上门"。

另一类是组织协同节点。 设备运维有一个经典闭环：问题发生（告警／事件）→ 研判 → 处置决策 → 过程知识沉淀。这个闭环过去靠人跑：运行人员发告警、检修人员研判、专业工程师定方案、班组执行、最后写总结。四五个角色、跨三个系统，知识沉淀基本靠自觉。

智能体是唯一能把这个闭环真正连起来的角色——它同时看得见告警流、设备台账、检修历史、备件库存和规程文档，能在几秒内完成研判并生成处置方案，执行过程自动沉淀为结构化知识。这个协同不是"提效"，是过去根本做不到的事。 再往后一步，把现场操作交给机器人，就是完整的无人场站闭环。

预算控制是同一逻辑的另一个例子。 传统预算管理是"事后对账"：年底发现超了，再回头看是哪个环节出的问题。把预算分析和协同控制交给大模型后，就可以做到过程嵌入——每一笔维修、每一次采购在发生时就做归因，告诉你超支是因为备件涨价、工期延长还是范围扩大，并把结论直接回写到业务环节。

图 4　双引擎协同：硬节点由引擎守护，智能体在被授权的决策点介入

这里有一条必须守住的架构约束：智能体只能在被显式授权的决策点上介入。 每个决策点要定义清楚三件事——可用上下文、可选动作集、升级到人的条件。没有这三样，智能体就是一个不可控的黑盒，流程审计会直接失效。

五、分析类应用：从"交付报表"到"交付结论"

分析类应用是大模型最没有争议的战场，因为它的产出天然是语言。

传统 BI 的链路是：业务提需求 → 数据团队理解 → 定义指标 → 写 SQL → 出图 → 业务自己解读。这条链路上有两处严重的翻译损耗：需求翻译成指标，图表翻译成结论。前者慢，后者难。

智能体把这两段都吃掉了：业务用自然语言提问，智能体沿语义层取数、做归因、给结论、给建议。 关键不在"能不能对话"，而在中间那层语义层与指标口径——如果指标定义不统一，模型只会更快地给出互相矛盾的答案。所以做分析类智能体，第一笔投入应该花在指标治理上，而不是提示词上。

图 5　分析类应用：从"出图给人看"到"出结论供人决策"

大屏同理。过去大屏的"智能"只是数据驱动渲染：数据变了，图表跟着变。现在可以做到意图驱动编排——告诉智能体"盯住今晚的机组负荷和辅机电流异常"，它自己决定拉哪几个指标、用什么图、阈值定在哪里、异常时怎么提示。后端从一条固定的数据管道，变成一个可编排的分析代理。

六、架构师的新位置

回到开头的问题：当大模型能给出数据表字段设计、能给出前后端技术选型的最优解，架构师还做什么？

我的看法是：技术选型的权重在下降，边界定义的权重在上升。 过去一个架构师的价值很大程度体现在"我知道该用什么"；未来更多体现在"我知道什么不能让模型决定"。

具体是四件事：

1.划边界：哪些环节允许概率、哪些必须确定；哪些数据可以出域、哪些不能。

2.定契约：工具契约、事件契约、指标口径、状态机。这是智能体落地的前提。

3.配权限：智能体的身份、可调用工具集、金额与影响面上限、升级到人的条件。

4.设验收：评测集、回归基线、可接受错误率。没有评测的智能体不能上线，这是纪律。

职责的迁移大致是这样：

这不意味着架构师变轻松了。恰恰相反，把确定性让出去之后，剩下的事情更难——你要为一个会自己发挥的系统，预先想清楚它可以在哪里发挥。

最后一句，也是我写这一系列文章的出发点：大模型负责把方案想到最优，架构师负责把边界守到最后。