张云雷宝宝1. 从架构评审现场说起：为什么要把七大范式摊开重看
最近一次架构评审，讨论的是一个常规业务系统要不要拆成微服务。提方案的人一上来就说“先拆三个域，再上事件驱动”，我追问了一句：你想隔离的变化到底是什么？会议室安静了一下。这大概是过去几年架构评审里最常见的缩影——市面上对软件架构的讨论，几乎被“微服务”“事件驱动”“DDD”这些热门词垄断，更基础的那套架构设计模式反而少有人系统讲，架构范式成了ppt上的流行标签，而不是解决问题时的决策依据。
学生时代我们谈设计模式，谈的是23种GoF模式，解决的是类与对象的依赖、创建、行为问题，属于战术级别。工作多年之后你会发现，架构层面的设计模式解决的是另一类问题：系统边界划在哪里，数据往哪个方向流动，组件之间是同步请求还是异步事件，遇到突发流量时如何分摊压力。软件架构设计模式要回答的，从来不是“这个类怎么设计”，而是“这个系统在什么条件下，复杂度会从哪个方向涌进来，我们又该把复杂度挡在哪一层”。
举个更近的例子。这两年多Agent系统爆发式增长，很多人觉得主从模式、代理模式这些名词早就过时了。但如果你真的去拆解一套多Agent框架，会惊讶地发现，所谓“主控Agent调度多个subagent”，本质上还是主从/代理架构，甚至很多编排框架直接把subagent对主控暴露成一个“工具接口”，主控用function calling的方式去调用它。汽车行业从AUTOSAR CLASSIC走向Adaptive Platform，软件架构规范变得更面向服务，但内部依旧在大量使用分层、事件通知、服务发现这些经典范式。范式还是那些范式，载体变了，问题域变了，底层逻辑没变。
所以我想把这七大范式放在一起做一次系统性的横向审视。不是要给每个范式贴标签，而是梳理清楚：每个范式锁定的变化是什么，它默认接受的新风险又是什么。下面我先给出一张总表，再用三组维度把七个范式拆开讲，最后结合我在Agent项目里的实践说说新场景下的变化。你会发现，真正读懂一个架构风格，比知道多少种架构风格重要得多。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 七大范式速查：每个范式到底在隔离哪一种变化
2.1 一张速查表：核心思路与主要成本
我选了一个相对常见的七类切法：分层架构、微内核架构、微服务架构、管道过滤器架构、事件驱动架构、基于空间的架构、主从/代理架构。这七种不是同一个维度