设计模式深度拆解：从六大原则到Agent主从模式

设计模式的本质，用一句话说，就是把前人踩过的坑，总结成一套可以反复使用的解决方案。

程序员圈子里有个老梗：设计模式是银角大王的葫芦，喊一句名字，对应招式就飞出来把人收了。虽然夸张，但方向对了一半——设计模式确实让团队沟通变快，但它不是只喊名字就能收妖的咒语。真正值钱的不是那23个模式的名称和UML图，而是每个模式背后那个“为什么非要这么绕”的取舍逻辑。我在实际项目里见过不少人，把单例写成进程内全局可变状态，把工厂搞成万能分发器，把观察者用成事件地狱，这些都不是模式的问题，是没搞懂模式要解决什么就硬套。这篇就把设计模式的来龙去脉、六大原则、三大分类,以及每个分类下那些高频模式的实际使用场景彻底拆开讲一遍，再加上最近Agent开发里比较热的主从模式，放到工具调用的视角下去理解，看完你至少能知道：什么时候该用模式，什么时候该绕开模式，以及怎么跟别人聊设计模式不露怯。

1. 设计模式到底在解决什么问题

要理解设计模式，先别急着背UML图。先想一想：面向对象编程写了几年以后，你迟早会撞上一堵墙——需求一改，代码就塌。

1.1 三层建筑：模式、原则、反模式的边界在哪里

我习惯把整个面向对象设计体系理解成三层建筑。

最底层是面向对象基础语法：类、对象、继承、多态、接口、抽象类。这层是工具。

中间层是设计原则：单一职责、开闭原则、依赖倒置、里氏替换、接口隔离、迪米特法则。这层是规矩，告诉你什么样的代码设计算“健康”。

最高层是设计模式：23种经过验证的经典方案。这一层是套路——当你遇到特定的结构性问题时，直接套用成熟打法，不用再从零发明轮子。

三层建筑之外，还有一片黑暗森林，叫反模式。比如Feature Envy（特性依恋，一个类老是眼红别的类的数据）、God Object（上帝对象，一个类管天管地）、Spaghetti Code（面条代码，逻辑缠成一团）。设计模式告诉你“应该怎么走”，反模式告诉你“千万别这么走”。

所以设计模式真正的价值，不是在代码里加层抽象显得高级，而是在应对变化的时候，把修改成本控制在一个可控范围内。

1.2 没有设计模式的代码是怎么一步步腐化的

举个实际例子。假设你要写一个通知系统，一开始只有邮件通知：

java复制public class NotificationService {
    public void send(String message) {
        // 发送邮件
        EmailUtil.send("admin@example.com", message);
    }
}

过了两周，产品说：加个短信通知吧。于是你改了代码：

java复制public class NotificationService {
    public void send(String message, String type) {
        if ("email".equals(type)) {
            EmailUtil.send("admin@example.com", message);
        } else if ("sms".equals(type)) {
            SmsUtil.send("13800000000", message);
        }
    }
}

又过了一个月，产品说：还要加站内信、微信模板消息、钉钉机器人。你的方法开始变成：

java复制public void send(String message, String type) {
    if ("email".equals(type)) {
        // 处理邮件逻辑，包括log、异常重试、附件...
    } else if ("sms".equals(type)) {
        // 处理短信逻辑，包括签名、长度截断、频率控制...
    } else if ("wechat".equals(type)) {
        // 处理微信逻辑...
    } else if ("dingtalk".equals(type)) {
        // 处理钉钉逻辑...
    }
}

此时这个方法的圈复杂度已经爆表。每次加新渠道，你都要打开这个类，小心翼翼地往里塞else if，生怕把其他渠道的逻辑改坏。这就是典型的违背开闭原则（对扩展开放，对修改关闭）——加一个新功能，就必须改老代码。

如果你一开始用策略模式，把每个通知渠道封装成独立策略，那么加新渠道只需要新建一个类，注册进去，老代码一个字都不用动。这就是设计模式的价值——它不是在写代码，是在设计“代码改起来不疼”的结构。

1.3 模式从哪来，为什么是23个

设计模式这个概念真正火起来，是1994年那本经典的《Design Patterns: Elements of Reusable Object-Oriented Software》，作者是GoF（Gang of Four，四人组）。他们从大量真实项目中提炼出23个反复出现的解决方案，按目的分成了三大类：创建型（Creational）、结构型（Structural）、行为型（Behavioral）。

这23个不是凭空发明的，是“总结”出来的。也就是说，在书出版之前，优秀的工程师已经在用这些结构了，只是没人给它们统一命名。GoF做的工作是把散落在各处的智慧结晶整理成一套通用词汇表。

为什么是23个而不是46个？因为它是那个年代、以C++和Smalltalk为主要语言背景下的总结。今天看，有些模式已经被语言特性取代了（比如迭代器在Java里变成了For-Each语法糖），有些新问题老模式也没覆盖到（比如Actor模型、协程）。但核心思想没有过时：识别变化点，隔离变化点，针对接口编程，优先组合而非继承。

2. 面向对象设计六大原则：设计模式的底层逻辑

设计模式之所以看起来“绕”，有一个根本原因：它把所有面向对象设计原则都当成了默认前提。如果在不讲原则的情况下硬套模式，大概率会得到一个比不用模式还烂的设计。

2.1 单一职责原则与接口隔离原则的区别

单一职责原则（SRP，Single Responsibility Principle）：一个类只应该有一个引起它变化的原因。

这句话听上去很简单，但实际操作中最容易翻车。什么叫“一个原因”？一个订单类，既要算价格，又要存数据库，又要发邮件通知，这算三个原因。价格规则变了要改它，库表结构变了要改它，邮件模板变了还要改它——三个不同的业务方都会来动这一个类，冲突率极高。

接口隔离原则（ISP，Interface Segregation Principle）：客户端不应该被强迫依赖它不需要的接口。

举个例子，你定义了一个万能接口：

java复制public interface Worker {
    void work();
    void eat();
    void sleep();
}

然后建了一个Robot类，它只能work，不能eat和sleep，但被迫实现了这两个空方法。这就违背了接口隔离原则。正确的做法是把接口拆细：

java复制public interface Workable {
    void work();
}
public interface Eatable {
    void eat();
}
public interface Sleepable {
    void sleep();
}
public class Robot implements Workable { ... }

区分SRP和ISP的关键：SRP是类的职责边界，IPS是接口的职责边界。很多教程把这两个混在一起讲，但实际代码评审里，它们暴露的问题完全不同——前者是“类太胖”，后者是“接口太胖”。

2.2 开闭原则：为什么说是所有设计模式的终极目标

开闭原则（OCP，Open-Closed Principle）：对扩展开放，对修改关闭。

这是面向对象设计里最核心的一条。它听着像废话——你不能既让人改代码又不让人改代码。但这里的“修改”指的是：在不修改现有类源码的前提下，通过扩展实现新功能。

怎么实现？靠多态和抽象。你把稳定不变的部分抽象成接口或基类，把易变的部分做成实现，然后用工厂或者依赖注入把实现组装起来。当新需求来了，新增一个实现类就能搞定，不用动老实现。

在我维护过的一个支付系统里，这个原则体现得最明显。初期只接微信和支付宝，后面要接银行卡、PayPal、Apple Pay，每个渠道的签名算法、回调验签、退款逻辑完全不同。设计时统一抽象了一个PaymentGateway接口，新渠道只需要实现这个接口，再注册到工厂里。老渠道的代码从头到尾没被改过。上线一年加五个渠道，核心代码零回归，这就是开闭原则的威力。

2.3 依赖倒置与里氏替换：面向抽象编程的两个支点

依赖倒置原则（DIP，Dependency Inversion Principle）：高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。

这名字起得很反直觉，很多人以为“倒置”是把依赖关系倒过来。其实它的核心是：别让你的业务逻辑依赖具体实现。

比如你的订单服务直接new了一个MysqlOrderRepository，那么订单服务和MySQL强绑定。哪天要换PostgreSQL，或者加一层缓存，就得改订单服务的代码。正确做法是抽象一个OrderRepository接口，订单服务依赖这个接口，具体是MySQL还是Redis还是内存实现，那是装配的事儿。

里氏替换原则（LSP，Liskov Substitution Principle）：子类必须能够替换其父类，并且行为不产生异常。

这是继承正确性的检验标准。最常见的违反场景：继承后重写父类方法，却不维持父类的行为契约。

经典反例是“正方形继承长方形”：

java复制public class Rectangle {
    protected int width;
    protected int height;
    public void setWidth(int w) { this.width = w; }
    public void setHeight(int h) { this.height = h; }
    public int area() { return width * height; }
}
public class Square extends Rectangle {
    @Override
    public void setWidth(int w) {
        this.width = w;
        this.height = w;  // 强制长宽相等
    }
}

看起来合理，但业务代码如果拿着Rectangle引用调setWidth(5); setHeight(10);，期望面积50，实际面积却是10（因为setWidth已经把height改了）。这就是里氏替换的经典破坏——你能替换引用类型，但替换后行为完全变了，调用方根本不知道。

2.4 迪米特法则：最少知道原则的实战意义

迪米特法则（LoD，Law of Demeter）：一个对象应该对其他对象保持最少的了解，不要和陌生人说话。

这个原则在实战中最容易被人忽略，因为它不像开闭原则那样直接指导结构，而更像一种交往礼仪。它要求：一个类只跟它直接相关的类通信，不要越过中间人直接去操作远端对象。

破坏迪米特法则的典型代码是一长串链式调用：

java复制order.getCustomer().getAddress().getCity().getZipCode();

这串代码的问题在于：order 直接知道了 customer、address、city 的内部结构。只要其中任意一层结构变化，这段代码就要跟着改。正确的做法是让order提供一个封装方法，直接拿到需要的数据。

设计模式里的外观模式（Facade）和中介者模式（Mediator），本质上就是在实现迪米特法则——用一个中间层把复杂的交互圈起来，让外部对象只跟门面对话，降低耦合。

3. 创建型模式：从直接new到间接生产的控制权转移

创建型模式的核心，说穿了就是一句话：把对象的创建和使用解耦。新手总觉得new一个对象是天经地义的，但等到需要控制创建过程、复用对象、延迟加载的时候，才会发现直接new是最缺乏灵活性的写法。

3.1 简单工厂、工厂方法、抽象工厂的演进逻辑

这三兄弟经常被搞混，我用一个餐饮的类比讲清楚。

简单工厂（Simple Factory）：一家餐厅只有一个厨师，你说“来份宫保鸡丁”，厨师在后厨根据你点的菜名做菜。对外暴露的是餐厅点餐口，你不知道后厨怎么做的。

java复制public class FoodFactory {
    public static Food createFood(String name) {
        if ("chicken".equals(name)) return new ChickenRice();
        if ("beef".equals(name)) return new BeefRice();
        return new DefaultFood();
    }
}

简单工厂的缺点是：每次加新菜品，都要改这个工厂方法。它虽然封住了创建逻辑，但没封住扩展点。

工厂方法（Factory Method）：餐厅变成连锁品牌了，每家分店都有自己的厨师（不同子类）。总部定义“做菜”这个抽象方法，各家分店自己实现。你要加一个新菜系，不用改老店，直接开一家新店就行。

java复制public abstract class Restaurant {
    public Food order() {
        Food food = createFood();
        return food;
    }
    protected abstract Food createFood();
}
public class SichuanRestaurant extends Restaurant {
    protected Food createFood() { return new MapoTofu(); }
}

抽象工厂（Abstract Factory）：餐厅升级成餐饮集团，提供的不止一道菜，而是一整套产品族。川菜集团卖麻婆豆腐+水煮鱼+盖碗茶，粤菜集团卖白切鸡+烧鹅+老火汤。你选一个集团，就能拿到一条完整的产品线，而且保证风格统一。

实际工程里，抽象工厂最典型的应用是UI组件库——同一个主题下，按钮、输入框、弹窗的风格必须统一。你切换主题，实际上是切换一整族组件工厂。

3.2 单例模式：为什么说它是被滥用最严重的模式

单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。

这个模式在面试里被问烂了，但在真实项目里却是“双刃剑”的代名词。它实现全局唯一实例的能力，也很容易变成隐藏的全局状态，导致代码难以测试、并发隐患多。

举个例子，一个常见的错误写法——懒汉式单例：

java复制public class ConfigManager {
    private static ConfigManager instance;
    public static ConfigManager getInstance() {
        if (instance == null) {
            instance = new ConfigManager();
        }
        return instance;
    }
}

这段代码在单线程下没问题，多线程下就会踩坑：两个线程同时判断instance == null，然后各自创建实例，导致全局唯一性被破坏。正确做法是加双重检查锁（Double-Checked Locking），或者干脆用饿汉式（静态初始化），或者用枚举单例。

但我要说的是：即使你把单例写对了，也要思考它该不该存在。单例本质上就是一条“全局变量”的变体。如果一个对象是真正的无状态工具类（比如日志Logger、UUID生成器），单例很合适；但如果这个单例内部有可变状态（比如全局配置、用户会话），它会把你的系统变成一个“隐性共享状态集线器”，一旦并发访问出问题，排查难度直接拉满。

我现在的实际原则是：能不用单例就不用单例，能用依赖注入容器管理的就用容器管理，容器的生命周期控制比单例灵活得多。

3.3 建造者模式：当构造器参数多到怀疑人生

建造者模式（Builder）：将一个复杂对象的构建过程与其表示分离，使得同样的构建过程可以创建不同的表示。

这个模式解决的是经典问题——构造器参数爆炸。比如你要创建一个HTTP请求配置对象：

java复制HttpRequest request = new HttpRequest("https://api.example.com", "POST", 
    null, "application/json", 3000, true, false, ...);

第6个参数是干什么的？第8个参数传true是什么意思？读代码的人一头雾水。

用建造者模式后：

java复制HttpRequest request = HttpRequest.newBuilder()
    .url("https://api.example.com")
    .method("POST")
    .timeout(3000)
    .retry(true)
    .build();

可读性直接拉满。这个模式在Java生态里太常见了——OkHttp、Retrofit、StringBuilder都是典型代表。

注意区分建造者模式和工厂模式：工厂模式是一步到位，直接返回完整的成品；建造者模式是分步组装，允许你控制每一步的参数，最后才调用build()产出一个完整对象。如果你要的对象组装步骤很多、参数可选性强，优先考虑建造者。

3.4 原型模式：克隆对象的两个深坑

原型模式（Prototype）：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。

适用场景：对象创建成本很高（比如要从数据库加载大量配置），或者对象的初始化逻辑很重，你希望复制一份现有对象，改几个字段就完事。

Java里，原型模式对应Cloneable接口和Object.clone()方法。这里有两个经典深坑：

第一，浅拷贝问题。clone()默认是浅拷贝，只复制引用，不复制引用指向的对象。如果你的对象里有List、Map这类容器字段，浅拷贝后新旧对象共享同一个容器，改一个就全变了。必须手动实现深拷贝，遍历容器里的元素挨个复制。

第二，构造器不执行问题。clone()不会调用构造器。这意味着你在构造器里做的一切初始化逻辑（比如给ID赋值、注册监听器），在克隆对象上都不生效。如果依赖构造器做核心状态初始化，用原型模式直接踩雷。

现代开发里，原型模式的使用场景其实没那么多。Java里更常见的是用序列化实现深拷贝，或者直接用拷贝构造器：

java复制public class Person {
    private String name;
    private List<String> tags;
    public Person(Person another) {
        this.name = another.name;
        this.tags = new ArrayList<>(another.tags); // 深拷贝
    }
}

4. 结构型模式：如何组装类与对象，让系统不脆

创建型模式管的是“对象怎么生出来”，结构型模式管的是“对象生出来后怎么组织在一起”。这部分的核心思想是：通过组合或适配，让现有类能够协同工作，而不是动不动就改老代码。

4.1 适配器模式：接口对不上时的万能转接头

适配器模式（Adapter）：将一个类的接口转换成客户期望的另一个接口。

这个模式在现实里太常见了——你的充电头是Type-C的，酒店只有USB-A口，于是需要一个转接头。代码世界里，第三方SDK的接口和你业务层的接口风格不匹配，你就需要一个Adapter类来做翻译官。

比如你接了一个第三方短信SDK，人家的接口是：

java复制public class ThirdPartySmsSDK {
    public boolean sendSms(String mobile, String text) { ... }
}

但你的业务层定义的通知接口是：

java复制public interface NotificationChannel {
    void send(String target, String content);
}

这里就可以写一个适配器：

java复制public class SmsChannelAdapter implements NotificationChannel {
    private ThirdPartySmsSDK sdk;
    public SmsChannelAdapter(ThirdPartySmsSDK sdk) { this.sdk = sdk; }
    public void send(String target, String content) {
        sdk.sendSms(target, content);
    }
}

这样业务层完全感知不到第三方SDK的存在，供应商想换就换，适配器一换就完事。适配器模式在项目里的最大价值，是防止供应商锁定。

4.2 装饰器模式：加功能不靠继承，靠层层包装

装饰器模式（Decorator）：动态地给一个对象添加额外的职责，比生成子类更灵活。

最容易理解的例子是Java I/O流的设计——BufferedInputStream装饰了FileInputStream，DataInputStream又装饰BufferedInputStream。这就是一层层叠buff。

为什么不用继承？因为组合爆炸。如果你要给咖啡加牛奶、加糖、加奶泡、加焦糖，如果用继承，你要写八种组合类——这还只是4种配料。而装饰器模式只需要写4个装饰器类，排列组合随意来。

java复制// 核心接口
public interface Coffee {
    double cost();
    String desc();
}
// 基础实现
public class Espresso implements Coffee {
    public double cost() { return 2.0; }
    public String desc() { return "浓缩咖啡"; }
}
// 装饰器
public class MilkDecorator implements Coffee {
    private Coffee coffee;
    public MilkDecorator(Coffee coffee) { this.coffee = coffee; }
    public double cost() { return coffee.cost() + 0.5; }
    public String desc() { return coffee.desc() + "+牛奶"; }
}
// 使用
Coffee c = new MilkDecorator(new Espresso());

装饰器模式最核心的洞察是：用组合代替继承，用叠加代替派生。它比继承更灵活，因为装饰器是在运行时动态组合的，而不是编译期就定死的。

4.3 代理模式：不是所有延迟都能自己解决

代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。

和适配器/装饰器不同，代理模式的目的是控制访问，而不是增强功能。它有几种常见变体：

• 远程代理：本地代理负责网络通信，真实对象在远程服务器上（RPC框架就是这个思路）。
• 虚拟代理：延迟加载大对象。比如一个图片查看器，真实图片加载很重，先用一个轻量代理占位，真正需要渲染时才加载。
• 保护代理：访问控制。先检查权限，再决定是否放行给真实对象。
• 智能引用：在访问真实对象时附带额外操作，比如引用计数、线程锁定。

Spring AOP的基础就是动态代理。给一个Service方法加事务、加日志、加权限校验，你不用改Service源码，只需配置一个代理切面。代理类在运行时动态生成，拦截方法调用，前后织入增强逻辑。

4.4 外观模式与组合模式：一大一小的两类结构设计

外观模式（Facade）：为子系统中的一组接口提供一个一致的界面。

这个模式是“最少知道原则”的直接体现。很多时候，一个业务流程需要调用四五个子系统的接口，如果调用方直接操作这四五个子系统，它就需要了解每个子系统的内部细节。外观模式提供一个高层接口，把复杂流程封装在里面，调用方只跟外观对话。

订单提交这个动作，底层可能涉及：库存系统扣减、支付系统下单、积分系统累计、消息系统发通知。不做外观的话，调用方要自己编排这一套。做外观之后，调用方只需要调OrderFacade.submit(order)那么简单。

组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构。

最典型的是文件系统——文件夹里面套文件或文件夹，整个树都可以做统一操作（删除、统计大小、遍历）。组合模式让单个对象和组合对象拥有一致的接口，客户端无需区分当前操作的是叶子节点还是容器节点。

组合模式的坑在于抽象不能太均衡。你硬要让叶子节点也实现addChild、removeChild方法，就得抛异常，这就破坏了接口纯净性。有两种解法：一是把addChild放到容器节点特有的接口中（安全组合），操作时用instanceof判断；二是所有节点都实现统一接口，容器节点才处理子节点（透明组合）。工程上多数人倾向安全组合，牺牲一点统一性，保证叶子节点的纯粹。

5. 行为型模式：对象之间的协作与职责分配

行为型模式是所有类型里最多的，也是最接近业务逻辑的。它关注的是：对象之间怎么通信、怎么分配职责、怎么在运行时灵活切换算法。

5.1 策略模式与状态模式：看着像，其实差很远

这两个模式结构几乎一模一样，都是把行为封装成独立类，运行时切换。但意图完全不同。

策略模式（Strategy）：把一族算法封装起来，使它们可以互相替换，客户端选择使用哪个策略。

java复制public interface DiscountStrategy {
    double apply(double price);
}
public class VipDiscount implements DiscountStrategy {
    public double apply(double price) { return price * 0.8; }
}
public class NormalDiscount implements DiscountStrategy {
    public double apply(double price) { return price * 0.95; }
}

策略模式的场景是：同一种任务，有多种算法，由调用方决定用哪种。今天用VIP策略，明天换Normal策略，策略之间是平行、可选的关系，互不感知对方的存在。

状态模式（State）：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

状态模式的场景是：同一个对象，内部状态不同，行为就不同，状态之间的流转有规则。比如订单状态：待支付、已支付、已发货、已完成、已取消。同一个pay()方法，在待支付状态下执行成功，在已支付状态下执行就报错。

状态模式的关键特征是状态会自动流转——不是客户端主动说“我要切换到已支付状态”，而是状态对象内部根据条件触发状态切换。它和策略模式的核心区别就一句话：策略由外部选择，状态由内部流转。

5.2 观察者模式：事件驱动的经典骨架

观察者模式（Observer）：定义对象间一对多的依赖关系，当一个对象状态改变时，所有依赖它的对象都得到通知并自动更新。

这是行为型模式里使用率最高的模式之一。按钮点击、数据变更、消息推送，本质上都是观察者模式的变体。

java复制public interface Observer {
    void update(String event);
}
public class OrderService {
    private List<Observer> observers = new ArrayList<>();
    public void addObserver(Observer o) { observers.add(o); }
    public void createOrder(Order order) {
        // 创建订单...
        for (Observer o : observers) {
            o.update("ORDER_CREATED");
        }
    }
}

观察者模式把“通知谁”这个逻辑从业务代码里抽出来，让核心流程不再依赖具体通知对象。但它也有一个明显的坑——观察者多了之后，通知顺序和异常隔离会变得不可控。观察者A抛异常了，观察者B还能收到通知吗？如果通知链太深，性能怎么保证？

这也是为什么现代的观察者实践都开始往事件总线和消息队列方向演进。本地观察者模式解决的是进程内的解耦，分布式事件解决的是跨服务的解耦，思路一脉相承。

5.3 命令模式与责任链模式：延迟执行与逐级处理的两种编排

命令模式（Command）：将请求封装成对象，从而可以用不同的请求对客户进行参数化，支持排队、记录日志、撤销操作。

命令模式最适合的经典案例是编辑器撤销。你是把每个操作封装成一个命令对象，命令对象有execute()和undo()。编辑器维护一个命令历史栈，撤销就是把栈顶命令的undo()调一遍。

java复制public interface Command {
    void execute();
    void undo();
}
public class InsertTextCommand implements Command {
    private Document document;
    private String text;
    private int position;
    public void execute() { document.insert(text, position); }
    public void undo() { document.delete(text.length(), position); }
}

命令模式把“做什么”和“怎么做”拆开了。调用方只需要知道“我要执行命令”，不需要知道命令内部是怎么操作文档的。这为扩展异步执行、日志记录、事务回滚提供了基础。

责任链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

这个模式在业务里最常见的就是审批流——组长批完经理批，经理批完总监批，每个审批节点看过之后决定是继续流转还是打回。中间件的设计也是责任链的经典应用——Java的Filter、Netty的ChannelPipeline，都是请求按顺序经过一系列处理器。

责任链模式最需要注意的设计点是：每个节点必须清楚自己处理完要不要继续传。是“处理完就中断”还是“处理完继续传”，设计不清晰的话，请求会在链上迷路或重复处理。

5.4 模板方法模式：固定骨架，可变细节

模板方法模式（Template Method）：定义一个操作的算法骨架，而将一些步骤延迟到子类中实现。

这个模式可能是我在项目里用得最多的行为型模式。它的思路非常朴素：把不变的部分写在父类里，把可变的部分留给子类重写。

比如一个数据导入任务，整个流程是固定的：读取文件 -> 校验数据 -> 清洗数据 -> 写入数据库 -> 发送完成通知。但不同文件的读取方式、校验规则、清洗逻辑各不相同。

java复制public abstract class DataImporter {
    public final void importData(String filePath) {
        Object data = parseFile(filePath);
        validate(data);
        clean(data);
        save(data);
        notifyDone();
    }
    protected abstract Object parseFile(String filePath);
    protected abstract void validate(Object data);
    protected abstract void clean(Object data);
    private void save(Object data) { /* 通用保存逻辑 */ }
    private void notifyDone() { /* 通用通知逻辑 */ }
}

子类只需要实现那三个抽象方法，整体流程完全由父类控制。这就是好莱坞原则：Don‘t call us, we’ll call you——别调用我们，我们会调用你。

模板方法模式和策略模式的区别在于：模板方法用继承实现（子类重写父类方法），策略模式用组合实现（替换策略对象）。直觉上组合优于继承，但模板方法在处理“流程骨架完全固定”的场景下，代码更紧凑，可读性更好。两者并不冲突，可以视场景混用。

6. 从设计模式到多Agent系统：一种新的解读视角

最近搞Agent开发的朋友，一定听过“主从模式（Master-Slave / Supervisor-Worker）”这个词。很多人在传统设计模式的书里找不到这个分类，会困惑：这算是设计模式吗？答案是：它不是GoF那23个经典模式之一，但在Agent架构领域，它成了一种事实标准的设计范式。

6.1 主从模式与经典模式的异同

经典设计模式解决的，是对象层面的协作问题——一个类怎么和另一个类解耦，一个方法怎么在运行时切换策略。

Agent系统里，主从模式解决的，是智能体层面的协作问题——一个主Agent怎么调度多个子Agent去完成一个复杂任务。

两者看着层级不同，但底层思想是相通的。主Agent相当于外观模式里的Facade——对外统一入口，对内编排调度；子Agent则像策略模式里的具体策略——不同的子Agent封装不同的专业技能，供主Agent在运行时选择调用。

还有一个很有意思的解读视角，就是开头提到的：把subagent视为一个另类的tool进行调用。如果我们在传统代码里要调用一个外部能力，我们会抽象一个接口，然后注入实现。在Agent系统里，主Agent调用一个子Agent，本质上和你调用一个API工具没有本质区别——都是发请求、传参数、等结果、处理返回。只不过子Agent的“结果”可以是高度智能化的文本生成、推理分析，而不是简单的结构化数据。

这个视角的价值在于：它可以帮你复用之前关于工具调用的设计经验。比如：

• 工具注册与发现：子Agent是不是也要有个注册中心？主Agent怎么知道当前有哪些子Agent可用？
• 工具超时与重试：子Agent执行时间过长怎么办？要不要设置超时控制和降级策略？
• 工具参数校验：传给子Agent的prompt要不要做模板化和参数校验？
• 工具日志与可观测性：子Agent的调用痕迹要不要记录，以便后期排查问题？

这些问题，在设计传统工具调用体系时早就被研究透了。现在做Agent，不过是把这些问题平移过来，再加上一层语义理解。

6.2 子Agent到底该不该被当成工具

从系统设计角度看，把子Agent当工具看待，有相当大的工程价值，也有它的问题。

工程价值在于统一调用模型。你不需要一套“调用工具”的逻辑，再单独搞一套“调用Agent”的逻辑。统一成一个Tool抽象，不管背后是函数的执行、HTTP API的调用，还是一个大模型驱动的智能体，对主Agent来说都是同样的“黑盒”——传入参数，拿到结果。这样整个系统就像一个“工具超市”，主Agent按需取货，代码结构清爽很多。

问题在于语义上的降维。Agent本质上是一个具有目标分解、上下文记忆和自主决策能力的实体，把它降维成“输入参数返回结果”的纯工具，会忽略它的状态性和多轮交互能力。一个真正复杂的子Agent，它可能需要和用户来回对话、自己调整执行策略、甚至主动请求更多资源。这些都是简单的工具调用模型无法完全覆盖的。

所以我的建议是：接口上按工具统一（便于主Agent调度），实现上留出Agent扩展口。定义一个通用的AgentTool接口，接口层面就是标准的工具输入输出，但内部实现上允许子Agent维护自己的会话上下文、状态流转。这样既享受了统一调用的工程便利，又不会把Agent的能力阉割掉。

6.3 传统设计模式在Agent开发里的具体映射

把经典设计模式映射到Agent架构，你会发现很多东西其实殊途同归：

从这个映射表可以看到，设计模式从来没有过时，它只是换了一身马甲，出现在新的技术形态里。模式的本体是“人类解决复杂协作问题的最优解集合”，它不绑定任何具体的技术栈。

6.4 设计模式在Agent时代真正需要补充的能力

虽然经典模式依然有参考价值，但Agent开发里也出现了很多经典模式覆盖不到的“新场景”，我简单列几个观察到的新模式雏形：

ReAct循环模式：推理（Reasoning）和行动（Acting）交替进行，模型每思考一步，就去调用一个工具，看到结果再继续思考。这个循环本身就是一种模式，它解决的是“大模型如何可靠地使用外部工具”的问题。

思维树/思维图模式：不满足于单条推理链，而是并行探索多条推理路径，通过评估和回溯选最优解。这像是把搜索算法（广度优先、深度优先、A*）思想引入推理过程。

反思与自我纠错模式：Agent执行完任务后，会站在“观察者”角度检查自己的输出，发现错误再修正。这本质上是给Agent加了一个元认知层，它在“做事”以外增加了“审视自己做的事”的能力。

记忆分层模式：短期记忆（当前对话上下文）与长期记忆（向量数据库存储的历史经验）分离，根据任务的时效性需求灵活读取不同层次的记忆。这跟人脑的工作记忆和长期记忆模型高度相似。

这些新模式的共同特点是：它们不再仅仅关注代码结构，还关注模型的认知流程、上下文管理、工具编排策略。它们在软件工程的意义上没有GoF那么严谨，但在AI应用工程里，它们确实在解决真实、重复出现的协作问题。如果你在做Agent，除了《设计模式》那本书，建议也别忽略这些“Agent原生模式”。

7. 如何正确地学习和使用设计模式

设计模式不是什么武功秘籍，更不是用来点缀简历的名词堆砌。真正有效的方法从来都是：在项目里踩过坑，再回头看书，才会有“原来如此”的顿悟感。我在早期学习时犯过一个错误——为了用模式而用模式，把系统架构搞得无比抽象，到头来维护成本比不用模式还高。这恐怕是设计模式新手的通病。

7.1 初学阶段最有效的三步法

第一步：先画“痛感地图”。不要一下子把23个模式全背完。先把问题列出来：什么场景下你需要延迟创建对象？什么场景下你需要动态替换算法？什么场景下你需要在不改接口的前提下扩展功能？然后带着问题去对照模式，一个一个解决。这个“问题驱动”的学习路径，远比“模式驱动”要高效得多。

第二步：手写最小可运行示例。不必用高级框架，一把梭写一个20行的demo，把模式的核心逻辑跑通。画UML图、看博客，永远替代不了亲手敲一遍。不用追求代码量，而是要确保你对四个要素有把握：参与者有哪些、协作关系怎么建立、扩展点在哪里、代价是什么。

第三步：用真实业务反推验证。你已经写好的业务代码里，哪些地方改起来很费劲？哪些地方每次加需求都害怕？把这些问题当作“重构信号”，尝试用某个设计模式重新组织这一块代码。重构前后做个对比，你会发现模式到底解决了什么，适合什么场景，不适合什么场景，全部清楚了。

7.2 模式不是银弹：几个容易走火入魔的警告

• 不要用模式去套需求。很多人在代码里大量用复杂设计模式，只是为了“显得专业”。一段业务逻辑本来就是一个if-else，硬套策略模式，不仅代码量暴涨，还增加了阅读负担。模式解决的是“变化点隔离”的问题，没有变化，就不要设计。

• 先规则，后模式。模式是用规则衡量出来的。如果一个设计符合单一职责、开闭原则、依赖倒置原则，即便它没用任何经典模式的名字，也依然是好设计。反过来，就算你嘴里的模式名词堆了一堆，但违背了基本原则，那依然是坏设计。

• 设计模式的三大代价：复杂度、性能、可读性。每引入一个模式，都在引入新的类、新的抽象、新的调用关系。如果团队的维护者不熟悉这些模式，反而会拖累维护效率。我见过太多基层团队，照着DDD和设计模式书把项目做成“抽象地狱”，最后新人接手三个月都找不到入口。

7.3 在代码评审中如何评判模式的应用是否恰当

我现在做代码评审，看到有人使用设计模式，一般会问四个问题：

1. 这个模式解决的具体问题是什么？ 如果作者说不清楚，说明他只是套了个壳，根本没理解。
2. 引入这个模式后，哪些变化变得容易了？ 比如开闭原则是否被更好地满足了，还是说只是换了个方式撕裂代码。
3. 引入这个模式后，引入了哪些新的复杂性？ 类的数量是否增加，调用链是否变深，这些复杂性抵得过收益吗？
4. 还有没有更简单的替代方案？ 是不是一个接口加三个实现类就够了？是不是一个函数参数就能解决？哪怕牺牲一点“设计感”。

这四个问题走一遍，模式应用的质量高下立判。好的设计模式应用是隐形的——它让代码改起来不疼，让读者觉得“这不就是普通的代码吗”，而不是到处炫耀自己用了什么高级名词。

7.4 学习设计模式的最优资源组合

市面上关于设计模式的书籍太多了，我不打算列出长长的书单，而是按效果排序推荐一个组合。经典书目《设计模式：可复用面向对象软件的基础》是必读，但说实话，它太干了，不适合入门，更适合当成“字典”随时查。入门阶段，Head First系列里那本设计模式更适合实操入门，图解多、案例生动、贴近生活，能让你建立起“模式原来在解决这个问题”的认知框架。

语言层面，推荐结合你实际使用的语言去学。Java生态对设计模式的体现最完整——《Effective Java》里每一章的“item”都在讲原则和模式的最佳实践；C++的话，Meyers的《Effective Modern C++》里也经常能看到模式思想的现代用法；Python用户则可以参考《Python设计模式》，因为Python的动态特性让很多UML图里的关系变得没那么死板，但模式的意图仍然是通的。

最重要的，还是刷一段真实项目的重构经验。不管是有挑战的开源项目，还是一段烂代码重写，自己动手把“恶心”重构到“清爽”，比读十本模式书都有用。设计模式的学习，本质上是反复踩坑、反复总结、反复验证的过程，任何一本书都不能替代这个过程本身。