软件架构 30 年:从单体到 AI 智能体

把软件系统比作建筑是个老掉牙的说法，但确实贴切：架构是承重结构，平时看不见，出事时最要命。这三十年，这栋楼从一栋大楼（单体）拆成了一个小区（微服务），学会了自动开关灯（云原生），最近住进了一位会思考的管家（AI 智能体）。

每次拆楼的原因各不相同，动机只有一个：业务变化越来越快，流量波动越来越猛，人越来越贵。每一代新架构，都是对上一代痛点的回应。

铁布衫一体成型、刀枪不入——破不了防就什么都好，一旦破防就是内伤。单体架构就是这样：所有功能——页面、订单、库存、支付、报表——全部塞进一个进程、打成一个 WAR 包，跑在一台 Tomcat 上。那个年代的主流配置，就是 SSH/SSM 三件套加一个 Oracle。

它的好处到今天依然成立：所有代码在一个工程里，IDE 里点一下就能跳转；所有数据在一个库里，ACID 事务保证转账不会转丢钱；部署就是把包扔上服务器。人少、业务简单的阶段，这是性价比最高的架构，没有之一。

大楼越盖越高，问题就来了。第一，牵一发动全身：改一行运费逻辑，全量回归测试跑一遍，谁也不敢说不测。第二，技术栈绑死：报表模块想用 Python 生态？没门，整个工程是 Java 的。第三，单点故障：月底跑报表把 CPU 打满，正在下单的用户一起陪葬。第四，团队协作撞墙：三十个人改同一个工程，分支合并是日常打仗。

企业信息化跑过十年，长出了一片烟囱：ERP、CRM、OA、财务、人力，几十个系统各自为政，数据老死不相往来。银行客户经理想看一个客户的全景，得开五个系统挨个查。这时候 SOA（面向服务架构）登场，思路很太极——不硬拆系统，以柔克刚：把存量系统的能力包装成"服务"，再用一根企业级总线（ESB）串起来，让能力流动。

这套体系有一整套规范：SOAP 协议传 XML 报文，WSDL 描述接口长什么样，UDDI 做服务注册与发现，BPEL 把服务编排成流程。那个年代的 IT 大词叫"服务化改造"，咨询公司和中间件厂商的最爱。

SOA 的历史功劳是真实存在的：老系统的接口包一层服务，新系统就能复用；跨系统的流程第一次可以被编排。但它自己也长出了新的病根——中枢太重。所有流量都过 ESB，总线一堵，全企业瘫痪；SOAP 报文又长又难调试，抓包看一眼 XML 能看瞎眼；整套治理规范太贵，中小团队根本玩不起。太极剑再柔，也架不住剑鞘是金子做的。

不过 SOA 没有白走。它留下的思想被微服务全盘继承：WSDL 进化成 OpenAPI（Swagger），ESB 简化成轻量 API 网关，服务注册从 UDDI 换成 Nacos、Consul。壳换了一代，魂是一脉相承。

互联网大流量把单体逼到了墙角，SOA 又太重。微服务的答案是独孤九剑的核心思路——拆，料敌机先。按业务边界把系统拆成一组小服务：独立进程、独立数据库、独立部署、独立扩容。订单服务大促加机器，报表服务常年躺着，互不牵连。2014 年 Martin Fowler 给这套打法正式定名，Spring Cloud 与 Dubbo 两大门派几乎同时立山头，从此"拆服务"成了架构师的本能反应。

拆的好处立竿见影：发布互不干扰，扩容按需分配，故障被隔离在单个服务里。但独孤九剑的剑谱后半本，写满了代价——

所以微服务从来不是免费的午餐，它是用运维复杂度换研发效率、用最终一致换扩展能力的交易。团队不到一定规模、没有平台工程兜底，这笔账大概率是亏的。

微服务拆出了几百个服务，谁来调度、谁来扩容、谁来保证发布不翻车？云原生的答案像凌波微步——不求力大，只求身法：一切资源可编程、可弹性、可自愈。三个里程碑定了调：2013 年 Docker 把应用打包成标准容器，"在我机器上能跑"从此失效；2014 年 Kubernetes 赢下容器编排大战，调度变成声明式；同年 AWS Lambda 开启 Serverless，代码连服务器都不用管了，按调用量毫秒级计费。

同一时期，大数据栈也完成了自己的进化：2006 年 Hadoop 用廉价机器扛住离线批处理，Spark 把计算搬进内存快了一个量级，Flink 让实时流处理成为标配，最终走向湖仓一体。它们的调度思想和 K8s 同源——把资源当池子，把任务当可调度的单元。到这一步，计算和存储的弹性问题基本解决，架构的重心开始从"怎么跑起来"转向"怎么跑得省、看得清"。代价当然也有：多云厂商锁定、K8s 本身的学习曲线，还有月底吓人的云账单——成本治理成了新的必修课。

前四站再怎么演进，有个前提没变过：系统只执行指令，人负责想。AI 智能体把这个前提掀了——你给意图，它来规划、拆解、调用工具、检查结果，做错了还会换个思路重试。独孤九剑练到最后是无招胜有招：招式（流程）不再预先写死，临场见招拆招。

这不是又一个框架，而是一种新的系统形态。把它拆开看，一共四层，如图 6。

四层各司其职：交互层管人和智能体怎么说话，决策层管怎么想，能力层管怎么动手，知识层管凭什么相信。真正的新东西都在决策层——过去十五年我们写的 if-else 流程代码，一大半正在从"业务逻辑"变成"可被替换的执行细节"。而撑起这套形态的，是七件兵器。

七件兵器凑齐，落地时真正伤筋动骨的是三个范式转变，如图 7。

MCP 解决的是智能体与工具之间怎么说话，A2A（Agent2Agent）解决的是智能体之间怎么协作：你的行程智能体直接找航空公司的订票智能体砍价，不用任何人在中间写集成代码。Google 2025 年 4 月牵头发布 A2A，每个智能体持有一张 Agent Card——本质是机器可读的名片，写明"我是谁、我会什么、怎么找到我"；配套的 AP2 协议让智能体之间能直接谈钱。行业里称这为智能体的 TCP/IP 时刻：协议一旦统一，协作网络就会自己长出来。

但别只看热闹。智能体联网带来了新攻击面——Lateral AIjacking（横向智能体劫持）：一个被入侵的智能体混进协作网络，冒充"同事"骗取上下文和权限。防御思路和零信任一脉相承：身份双向验证、最小权限、敏感操作留痕。分布式系统的老安全课，智能体网络要重修一遍。

企业架构有个经典的 4A 框架：业务架构 BA、应用架构 AA、数据架构 DA、技术架构 TA。华山论剑论的就是这个——智能体杀进来之后，四张剑谱都得改写。它不是在系统里"加个 AI 模块"，而是从业务到技术的四层联动重构，如图 8。

BA 业务架构：流程固化 → 意图驱动。过去业务架构的载体是流程图，BPMN 画到三级、每一步谁审批都写死。智能体时代，用户只表达意图，路径由智能体临场规划。业务架构师的工作从"画流程"变成"定边界"：哪些意图可以自动满足、哪些必须留人工卡点、失控了怎么熔断。相应地，一线岗位从执行流程转为监督智能体——考核指标也要跟着换，否则就会复刻上面发券的翻车。

AA 应用架构：API 编排 → 能力注册。不必推翻重来。成熟套路是三步：给存量 API 包一层 MCP 防腐层，老系统一行不改；新能力直接按 MCP 标准建；用绞杀者模式让智能体入口逐步替换旧入口，最终老页面自然退役。应用清单从"有哪些系统"变成"注册了哪些能力"。

DA 数据架构：结构化查询 → 语义检索。数据服务的对象从报表和接口，变成张嘴提问的智能体。落地是三层分工：原始数据层照旧管好事实；语义索引层做向量化与知识图谱，把"数据"翻译成"模型够得着的知识"；权限层从表级权限升级为语义级权限——检索命中之前，先判断这句话该不该被这个角色看到。最后这关，多数团队还没意识到。

TA 技术架构：资源调度 → 算力编排。K8s 调度的是容器，现在要调度的是智能体和模型：GPU 池化、按智力分级做模型路由（贵模型想难题、便宜模型干杂活）、推理网关管流量、Langfuse/LangSmith 管调用链观测，外加一门新功课——Token 治理。云时代的教训会原样重演：不算账，账单月底教你做人。

兵器谱排完了，回到最实际的问题：我该用哪个？什么时候换？怎么换？先看信号，再看家底，最后看路线。架构选型没有最好，只有最合身——练什么武功，先看什么底子。

信号到了，也别一夜切换。到了智能体这一站，迁移的正确姿势是三段路，每一段都留了回头路，如图 9。

同样的路线，不同体量的团队走法完全不同，别抄作业，先对号入座——

很多场景，一个编排好的工作流加一个 LLM 节点，比全套自主智能体更稳、更省。智能体的"自主"是按需购买的能力，不是默认配置——先问"这个决策真的需要临场规划吗"，再决定上不上。三段路，请慢走。

把五站路连起来看，会发现一个轮回：单体是合，SOA 与微服务是分，云原生靠统一调度做到了分而不乱，智能体看似重新走向合——一个对话入口包打天下——底下却是更彻底的分：能力被拆成原子化的工具，随取随用。每一轮分合，都在抬高一层抽象：从代码到服务，从服务到能力，从能力到意图。三十年架构史，就是一部抽象升级史。

下一站在哪，没人说得准。有一种可能：当智能体足够可靠，"架构"本身会成为它的决策——系统由智能体临场编排，架构师退化为立法者。但万变不离其宗：分而治之、幂等设计、防腐隔离、可观测性——这些老功夫，无论哪一站都用得上，一点不过时。