订单系统实战：七个高频设计模式与AI Agent的新思考

先说一个现象：我经常在代码评审里看到有人把设计模式用得很别扭——要么是为了“秀”而套一个抽象工厂，结果系统多了三层没人维护的接口；要么是反过来，把十几个 if-else 堆在同一个方法里，美其名曰“简单直接，不需要设计模式”。这两种情况我都经历过。学设计模式最难的从来不是背 UML 图，而是搞清楚一个很实际的问题：什么时候该用、用哪个、用完之后带来的复杂度是不是真的值。

这篇文章不打算把 23 种模式逐个念一遍，也不打算对着教材抄概念。我会从一个真实的业务场景——订单系统——出发，把策略、状态、观察者、工厂、建造者、模板方法这七个在业务代码里出现频率最高的模式串起来讲。每个模式都会给出可运行的代码片段、选型理由、重构前后的对比，以及我在实际项目中踩过的坑。最后还会聊一个这两年在 AI Agent 开发里重新火起来的话题：主从模式，以及为什么说“子 Agent 本质上是另一种 Tool”。

无论你是准备期末设计模式大作业的学生，还是在 Java、C++、Python 项目里想把代码写得更干净的工作党，这篇文章都值得你读完。读的时候不用着急，拿起 IDE 跟着敲一遍，比我写一万个字都有用。

1. 先回答那个扎心的问题：设计模式到底在解决什么

1.1 我在代码评审里见到的两种典型失败

很长一段时间里，我所在的团队有一个约定：新功能提测之前必须先过一轮代码评审。看得多了，我发现关于设计模式的问题可以归成两类。

第一类是“考古式抽象”。新同学接手一个旧的报表模块，发现里面有大量的 if-else 在判断“导出格式是 PDF 还是 Excel”，于是套了一个策略模式，把每个格式拆成一个类。这个方向是对的。但接下来他加了基类、抽象类、工厂、注册表、SPI 扩展点，一口气建了十几个接口和类，只为导出一个报表。最后这个模块的代码量翻了三倍，但业务行为没有任何变化，也没有任何新的扩展需求出现。代码评审会上大家都在问一个问题：我们真的需要为“能不能导 PDF”这件事准备插件体系吗？

第二类是“硬编码到底”。老系统里有一段物流运费计算逻辑，不同地区、不同重量段、不同快递公司，都是几层 if-else 套在一起，一个方法写了三百行。每次新增快递公司，都要有人小心翼翼地找到对应分支塞进去。有一次因为 else 分支覆盖不全，线上出现了一百多笔运费为零的订单。这类代码的问题不在于它没用设计模式，而在于它完全没有处理“变化”的边界——每次变化都像打补丁，补丁多了代码就变成一团乱麻。

这两个反例看着矛盾：一个过度设计，一个拒绝设计。但它们共同的本质是：没有搞清楚设计模式真正要解决的问题。

1.2 模式的底层本质：识别变化点，然后隔离变化

如果把设计模式的历史翻开来看，GoF 那本书在 1994 年出版，当时面向对象已经是主流，但这本书真正厉害的地方不是定义了 23 个“套路”，而是它总结了一个通用原则：在变化的地方做抽象，在稳定的地方做具体。

这句话听起来很空，我给你打个比方。想象你在做一个家庭厨房，煤气灶、冰箱、水槽这些“稳定设施”应该固定好，水电管线埋进墙里。但今天你买个空气炸锅、明天换台破壁机，这些是“变化的部分”，所以厨房台面上要预留插座、留出操作空间，而不是把所有家电都焊死在墙里。设计模式干的就是这件事：在代码里划出台面和插座的位置，让未来可能变的组件能插进来，而不需要砸墙改管线。

订单系统里有几个典型的变化点：

• 支付方式：支付宝、微信、银联、跨境卡，随时会加新的；
• 订单状态：待支付、已支付、发货中、已签收、退款中，状态之间的流转规则经常改；
• 下单后的通知：短信、邮件、站内信、App 推送，通知渠道越来越多；
• 商品实体的构造：普通商品、虚拟商品、套餐商品，字段差异很大。

这四个变化点，正好对应了策略模式、状态模式、观察者模式、工厂和建造者模式。当一个人说“我在订单系统里用了设计模式”，他真正说的是：我把这些变化点找了出来，然后分别用不同的抽象把变化隔离开，让核心业务逻辑不因为某个支付渠道的新增而反复修改。

1.3 一个简单判断：要不要为了“未来”写代码

很多人纠结：我现在只有一种支付方式，要不要直接上策略模式？我的建议是不要。设计模式是工具，它的价值在于解决“真实存在的多变需求”，不是解决“你幻想的未来”。

有一个比较实用的判断办法：当一个需求的变化已经出现第二次时，你才有充分理由去抽象它。第一次出现新渠道，你可以在原有的 if-else 里加一个分支，但这意味着你得立刻在心里标记：这里已经出现变化趋势了。第二次出现时，就不要再拖了，用模式把变化点隔离出来。如果拖到第三次才重构，改动成本会明显上升，因为业务代码里可能已经在很多地方复制了同样的判断逻辑。

与其问“我要不要用设计模式”，不如问自己三个更诚实的问题：

1. 这个模块未来半年内真的还会加新的同类实现吗？
2. 我现在的 if-else 是不是已经让自己看吐了？
3. 如果现在抽出抽象层，最坏的情况下会白写多少行代码？

回答完这三个问题，大部分纠结就消失了。

2. 一个订单系统，串起七个高频模式

2.1 为什么选订单系统当教学案例

如果让我只推荐一个练手设计模式的项目，我首推订单系统，尤其是那种包含购物车、支付、状态流转、通知、优惠券的简化版。原因有三条：

• 订单系统涉及的实体多，天然有对象创建复杂度，适合讲工厂和建造者；
• 业务状态清晰，待支付、已支付、已发货、已完成、已取消，每一跳都有前置条件和后置动作，适合讲状态模式；
• 下单之后的副作用极多，扣库存、减优惠券、发通知、记日志，适合讲观察者模式。

更关键的是，订单系统是几乎所有业务系统的“地基”，你写完它，以后做电商、做外卖、做课程销售都能复用这套分析思路。下面我会带大家把整个代码一步一步写出来。

2.2 策略模式：支付渠道从 if-else 到策略映射

最原始的写法是这样的：

java复制public class PaymentService {
    public void pay(String channel, BigDecimal amount) {
        if ("alipay".equals(channel)) {
            // 调用支付宝 SDK
            AlipayApi.createOrder(amount);
        } else if ("wechat".equals(channel)) {
            // 调用微信支付 SDK
            WechatPayApi.createOrder(amount);
        } else if ("card".equals(channel)) {
            // 调用银联卡支付
            UnionPayApi.createOrder(amount);
        } else {
            throw new IllegalArgumentException("不支持的支付渠道");
        }
    }
}

这段代码在渠道只有两三个的时候问题不大，但一旦有五个渠道，问题就来了：每次新增渠道都要改这个类，测试要回归所有渠道，而且方法会越来越长。所谓“开闭原则”，在这段代码里是不成立的——它没有对修改关闭。

用策略模式重构后，先定义策略接口：

java复制public interface PaymentStrategy {
    String channel();
    void pay(BigDecimal amount);
}

然后每个渠道一个实现：

java复制@Component
public class AlipayStrategy implements PaymentStrategy {
    @Override
    public String channel() {
        return "alipay";
    }

    @Override
    public void pay(BigDecimal amount) {
        // 调用支付宝 SDK
        AlipayApi.createOrder(amount);
    }
}

支付服务的核心就变成了一个策略查找表：

java复制@Service
public class PaymentService {
    private final Map<String, PaymentStrategy> strategyMap;

    public PaymentService(List<PaymentStrategy> strategies) {
        this.strategyMap = strategies.stream()
                .collect(Collectors.toMap(PaymentStrategy::channel, Function.identity()));
    }

    public void pay(String channel, BigDecimal amount) {
        PaymentStrategy strategy = strategyMap.get(channel);
        if (strategy == null) {
            throw new IllegalArgumentException("不支持的支付渠道: " + channel);
        }
        strategy.pay(amount);
    }
}

这里有个很重要的细节：strategyMap 是从 Spring 容器里注入的 List<PaymentStrategy> 转换出来的，而不是手动 new 一个 Map。这样新增渠道时只需要写一个新的 @Component 实现类，连 PaymentService 都不用改。这才是真正的“对修改关闭、对扩展开放”。

我在实际项目中踩过一个坑：直接使用 ThreadLocal 缓存 Strategy 实例并发调用，结果出现共享状态串了。设计模式里的策略类最好都是无状态的，如果策略内部需要保存临时数据，要么改成方法参数传进去，要么把策略类的作用域改成原型模式。

2.3 状态模式：订单状态机把 Bug 挡在外面

订单状态的流转是状态模式最经典的讲法。假设状态有：待支付、已支付、发货中、已签收、已取消。最原始的写法是这样：

java复制public void nextState(Order order) {
    switch (order.getStatus()) {
        case 0: // 待支付
            order.setStatus(1);
            break;
        case 1: // 已支付
            order.setStatus(2);
            break;
        case 2: // 发货中
            order.setStatus(3);
            break;
        default:
            throw new IllegalStateException("非法状态");
    }
}

问题在于：状态迁移的合法性判断散落在各个业务方法中，而且“待支付可以取消”“已发货不能取消”这种规则没有一个统一的收口。随着状态越来越多，switch-case 会越来越长，漏掉分支就会出线上事故。

用状态模式重构，先把状态抽象成接口，每个状态一个类：

java复制public interface OrderState {
    void next(OrderContext context);
    void cancel(OrderContext context);
}

待支付状态：

java复制public class PendingPaymentState implements OrderState {
    @Override
    public void next(OrderContext context) {
        // 待支付 -> 已支付
        context.setState(new PaidState());
        // 触发支付成功后的业务逻辑
        context.doAfterPaid();
    }

    @Override
    public void cancel(OrderContext context) {
        // 待支付可以取消
        context.setState(new CancelledState());
    }
}

已支付状态：

java复制public class PaidState implements OrderState {
    @Override
    public void next(OrderContext context) {
        // 已支付 -> 发货中
        context.setState(new ShippingState());
    }

    @Override
    public void cancel(OrderContext context) {
        // 已支付状态不允许直接取消，需要走退款流程
        throw new IllegalStateException("已支付订单不能直接取消，请走退款流程");
    }
}

OrderContext 保存当前状态并委托给状态对象执行：

java复制public class OrderContext {
    private OrderState state;

    public OrderContext(OrderState state) {
        this.state = state;
    }

    public void next() {
        state.next(this);
    }

    public void cancel() {
        state.cancel(this);
    }

    public void setState(OrderState state) {
        this.state = state;
    }
}

这样的好处是：状态迁移的规则被封装在每个状态类自己内部，新增一个状态只需要新增一个类，不需要去改 switch。而且“某状态下不能做某事”的规则也会在代码上变得非常直观——它是那个类里一条抛异常的逻辑，而不是散落在多个业务判断里。

关于状态模式，我想补充的一点是：它和策略模式的代码结构非常像，区别在于意图。策略模式是“同一个行为有多种算法，可以随时替换”，状态模式是“同一个对象在不同状态下有不同的行为，行为随状态自动切换”。写代码时可以在类注释里明确写清楚这个类到底是策略还是状态，避免后来人看代码时产生困惑。

2.4 观察者模式：下单之后，通知不再写死在业务里

下单成功之后要做什么？扣库存、记录流水、发短信、发邮件、推送 APP 通知、通知仓库拣货。如果这些操作全部写在下单方法里，代码会变成这样：

java复制public void createOrder(Order order) {
    orderDao.insert(order);
    stockService.deduct(order);
    logService.record(order);
    smsService.send(order);
    emailService.send(order);
    pushService.notify(order);
}

每次新加一个“下单后要做的动作”，都要来改这个方法。而且如果短信服务响应特别慢，整条下单链路都会被拖慢。

用观察者模式，把下单成功作为一个事件发布出去，所有的后续动作都变成事件的监听者。用 Spring 的事件机制非常简单：

java复制// 事件对象
public class OrderPlacedEvent extends ApplicationEvent {
    private final Order order;

    public OrderPlacedEvent(Object source, Order order) {
        super(source);
        this.order = order;
    }

    public Order getOrder() {
        return order;
    }
}

下单方法里只发布事件：

java复制@Service
public class OrderService {
    @Autowired
    private ApplicationEventPublisher publisher;

    public void createOrder(Order order) {
        // 核心业务逻辑：保存订单
        orderDao.insert(order);
        // 发布下单成功事件
        publisher.publishEvent(new OrderPlacedEvent(this, order));
    }
}

各个监听器解耦地处理自己的逻辑：

java复制@Component
public class SmsListener {
    @EventListener
    public void onOrderPlaced(OrderPlacedEvent event) {
        // 发送短信
    }
}

@Component
public class StockListener {
    @EventListener
    public void onOrderPlaced(OrderPlacedEvent event) {
        // 扣库存
    }
}

为什么要用 Spring 事件而不是直接调用？核心在于“发布方不感知订阅方”。下单的核心流程只关心“订单落库”，至于通知和库存是不是要执行、要不要加新的监听器，下单方法完全不需要关心。这会让代码的维护成本下降非常多，尤其是在团队协作的场景下——负责短信的人只需要加一个 Listener，不会和负责订单的人改同一个文件。

我遇到的坑是事件监听器里的事务边界。有时候把扣库存和发短信放在同一个事件监听器里，数据库事务还没提交，发短信就触发了，用户收到短信但订单还没查到。后来我把库存扣减和通知拆成两个监听器，并且设置了监听器的执行顺序。这个细节可以用 @Order(1) 注解控制。

2.5 工厂、建造者、模板方法：创建与流程的收口

订单这个实体比较复杂：有基础用户信息、商品明细、支付信息、优惠券信息、收货地址，还可能区分普通订单和秒杀订单。如果直接 new 一个订单对象然后 setter 一堆字段，创建逻辑会散落在业务代码里。这时候可以用工厂方法模式和建造者模式收口。

建造者模式的好处是：让对象的构造过程链式可读，并且可以应对可选字段很多的情况：

java复制public class Order {
    private String userId;
    private List<OrderItem> items;
    private Coupon coupon;
    private Address address;
    private String orderType; // NORMAL, SECKILL, VIRTUAL

    private Order(Builder builder) {
        this.userId = builder.userId;
        this.items = builder.items;
        this.coupon = builder.coupon;
        this.address = builder.address;
        this.orderType = builder.orderType;
    }

    public static Builder builder() {
        return new Builder();
    }

    public static class Builder {
        private String userId;
        private List<OrderItem> items;
        private Coupon coupon;
        private Address address;
        private String orderType;

        public Builder userId(String userId) {
            this.userId = userId;
            return this;
        }

        public Builder items(List<OrderItem> items) {
            this.items = items;
            return this;
        }

        public Builder coupon(Coupon coupon) {
            this.coupon = coupon;
            return this;
        }

        public Builder address(Address address) {
            this.address = address;
            return this;
        }

        public Builder orderType(String orderType) {
            this.orderType = orderType;
            return this;
        }

        public Order build() {
            if (userId == null || items == null || items.isEmpty()) {
                throw new IllegalStateException("userId 和 items 不能为空");
            }
            return new Order(this);
        }
    }
}

使用的时候：

java复制Order order = Order.builder()
        .userId("u123")
        .items(List.of(item1, item2))
        .coupon(coupon)
        .address(address)
        .orderType("NORMAL")
        .build();

如果不同的下单场景（普通下单、秒杀下单、礼品卡下单）创建订单的细节不一样，可以在建造者之上再套一层工厂方法：

java复制public interface OrderFactory {
    Order createOrder(User user, Cart cart, Coupon coupon);
}

普通订单工厂、秒杀订单工厂分别实现这个接口，把“创建逻辑”收口到工厂类里，业务层不再关心每种订单是怎么拼装的。

模板方法模式我通常会用在“流程固定、步骤可变”的场景。比如所有订单都要走一遍：校验参数 -> 计算价格 -> 锁定库存 -> 保存订单 -> 发布事件，但这五步里面，秒杀订单的校验和普通订单的校验不一样。用模板方法：

java复制public abstract class AbstractOrderProcessor {
    public final void process(Order order) {
        validate(order);
        calculatePrice(order);
        lockStock(order);
        saveOrder(order);
        publishEvent(order);
    }

    protected abstract void validate(Order order);

    private void calculatePrice(Order order) {
        // 通用计算逻辑
    }

    protected void lockStock(Order order) {
        // 默认实现，子类可以覆盖
    }

    private void saveOrder(Order order) {
        // 通用保存逻辑
    }

    private void publishEvent(Order order) {
        // 通用发布逻辑
    }
}

子类只需要实现抽象方法 validate，其他步骤直接用公共实现。模板方法的价值是：把流程的骨架固定住，防止有人在下单逻辑里忘掉某个必做环节。我见过很多事故，都是因为“这次紧急需求直接改了下单方法，结果跳过了库存锁定”，模板方法从结构上杜绝了这种问题。

2.6 同一份需求，重构前后差在哪

为了直观地展示设计模式的价值，我把同一个“下单+支付+通知+状态流转”的需求做了一张重构前后对比表。

这张表不是我拍脑袋写的，是我在真实的订单系统重构里总结出来的体验。设计模式不是银弹，它不会让代码自动变好，但它能让“变化”这件事的成本变得可控。一旦你把变化点隔离好，你的心智负担会小很多——改的时候不用全局搜索，因为你知道变化被规则性地放在某个位置。

3. 模式怎么组合，才不会变成过度设计

3.1 三组能打的模式组合

上面的订单系统虽然每个模式单独用，但在真实项目里，模式往往不是孤立的。我整理了三组我实际用过、而且效果不错的组合，你可以直接抄到项目里。

第一组：策略 + 工厂。策略模式负责定义算法族，工厂负责决定用哪一个策略。比如运费计算，有“普通快递”策略、“顺丰”策略、“同城闪送”策略，工厂根据订单里的配送方式和用户选择的快递公司来创建或返回对应的策略对象。用策略 + 工厂结合 Spring 的依赖注入，可以在配置中心配一个 route 映射表，连代码都不用改就能动态注册新的策略。

第二组：状态 + 模板方法。订单的每一个状态都是一个状态类，但状态类内部的“进入下一步之前要做的通用动作”（比如记账、写状态履历、更新更新时间）是重复的。可以把这些通用动作放到抽象基类里，用模板方法固定执行顺序，具体状态类只实现差异化的部分。我写的 AbstractOrderState 基类里就包括一个模板方法 entryAction()，每个具体状态类在自己的 next() 方法里先调用基类的 entryAction() 再执行状态迁移。

第三组：观察者 + 责任链。下单后的事件监听器如果逻辑较重，比如“清理缓存 -> 同步数据到搜索引擎 -> 发送事件到消息队列”这些步骤有先后顺序，可以在一个监听器里用责任链模式把处理器串起来。这样既能享受到观察者模式的“发布-订阅解耦”，又能在事件处理内部保持流程的清晰。

3.2 识别过度设计的三个信号

过度设计比没有设计更让人头疼，因为它的伤害是隐性的：代码看起来井井有条，实际上无法维护。我总结了三个信号，命中任何一个都要停下来重新审视。

信号一：抽象层级超过两层。策略 -> 工厂 -> 抽象工厂 -> 抽象工厂的Provider -> 注册中心，这是我在一次代码评审里真实看到的“八层抽象”。如果别人从入口到具体实现需要点开五个以上的类才能看懂，那么这层抽象就不是在帮人，而是在阻碍人。

信号二：接口数量大于实现数量。一个正常的抽象必然有至少一个实现类。如果你发现某个接口只有一个实现类，并且未来也没有第二个实现类的计划，这个接口基本可以删掉——它不是接口，只是给类换了个名字。

信号三：为了“如果以后可能要支持 XXX”写代码。以后这个词是过度设计最好的借口。我建议团队定一个规则：任何抽象必须由真实需求驱动，如果你能说出“第三个渠道叫什么名字”，你才有资格为它做抽象。

3.3 一次坏味道重构实录：删掉不必要的抽象

我手头有一个内部工具，最开始只有一种数据源：MySQL。有人为了“未来扩展”，写了 DataSource 接口、MysqlDataSource 实现、DataSourceFactory 工厂、DataSourceRegistry 注册表，一共四个类。半年后真的需要增加一种文件数据源，结果发现原来的抽象根本不适配，因为接口方法都是围绕 SQL 设计的，文件数据源需要不同的读取方式。

这时候做的不是扩展，而是重构。我把接口拆成更细粒度的“读”和“写”两个接口，然后保留 MySQL 实现，删掉了注册表，改为简单的工厂方法。整个工具类从 40 个文件缩到 12 个文件，代码量少了 35%，可读性反而大幅上升。

这段经历给我的教训是：抽象要在真实的变化点出现之后再做，而不是提前做。模式的价值是应对变化，如果变化根本没来，模式就是负债。正确的姿势是第一次变化时记下笔记“这里可能要抽象”，第二次变化时动手重构，把两个实现抽象成一个接口，让新代码变得整洁。这时候你才是真的在设计模式，而不是在背诵模式。

4. AI 时代的新形态：主从 Agent 模式正在重新定义“模式”

4.1 Agent 的分层，和当年的应用分层一脉相承

最近这一两年 AI Agent 开发越来越热，我在研究多 Agent 框架时发现一件很有意思的事：Agent 架构里流行的“主从 Agent 模式”，本质上和软件工程里“分层”思想完全一致，只是换了一层皮。

在经典的多 Agent 框架里，你有一个主 Agent（Coordinator/Planner）负责任务拆分和调度，下面挂一堆子 Agent（Worker），每个子 Agent 负责一个具体领域：写代码的、查资料的、算数学的。主 Agent 收到用户请求后，把任务拆解成多个子任务，分发给对应的子 Agent，再汇总结果。这就是典型的主从模式。

为什么要分层？因为单个 Agent 的上下文窗口有限。跟人一样，主 Agent 如果什么事情都要处理，它的上下文很快会被低价值信息占满，导致后面的决策质量急剧下降。于是主 Agent 只保留“计划”和“状态汇总”这些轻量信息，把重活都丢给子 Agent。子 Agent 处理完返回一个精炼的结果，主 Agent 再继续下一轮。这套分工逻辑，跟应用架构里“Controller 负责编排、Service 负责业务、DAO 负责数据访问”是一个思路——每一层的职责边界清晰，上下文不会互相污染。

4.2 子 Agent 就是“另类工具”：策略模式的最新形态

我最近反复提一个观点：在多 Agent 设计里，主从模式之所以好用，本质上是因为我们可以把子 Agent 视作另一种 Tool 来调用。

传统的 Tool 是确定性的函数：输入参数，返回结果。子 Agent 也是：给它一个 Prompt（指令）和一组输入，它返回一个输出。只不过这个“函数”内部是 LLM 在推理，结果不那么确定。但从主 Agent 的视角看，子 Agent 就是“增强版工具”。这就引出了一个关键的架构决策：主 Agent 不需要关心子 Agent 是怎么实现的——是调 GPT、Claude，还是跑本地模型；也不需要关心它内部用什么 Prompt、什么模型参数。

这恰恰就是策略模式的思路：定义一个统一的调用接口，具体的实现可以随时替换。在一个 Agent 框架里，你可以为“代码生成子 Agent”写一个统一的 SubAgent 接口，方法大概是：

python复制# 以 Python 伪代码为例
class SubAgent(ABC):
    @abstractmethod
    def run(self, task: str, context: dict) -> str:
        """执行子任务并返回结果"""
        pass

class PythonCoderAgent(SubAgent):
    def run(self, task: str, context: dict) -> str:
        # 调 LLM 写代码
        return llm_call_with_system_prompt(CODER_PROMPT, task, context)

class BrowserAgent(SubAgent):
    def run(self, task: str, context: dict) -> str:
        # 调浏览器工具抓取网页
        return browser_search(task)

主 Agent 在规划阶段决定要调用哪个子 Agent，然后把控制权交出去。需要新增能力时，只要注册一个新的 SubAgent 实现，主 Agent 完全不改。这和你用策略模式管理支付渠道，本质上是同一个结构。

如果你现在在写多 Agent 应用，完全可以照着第二章的订单系统来组织代码：Agent 的注册表 = 策略模式里的 Map，主 Agent 的调度逻辑 = 策略模式的 Context，不同子 Agent = 策略实现类。你可以先定义好 AgentTool 接口，再按功能域实现具体的子 Agent，最后用一个工厂类根据请求类型分拣。这套代码结构我实测在 LangChain、AutoGen 这类框架里都非常好用，比把逻辑全写在主 Agent 的循环里要清晰得多。

4.3 状态机、上下文与模式思维的迁移

Agent 运行过程中，状态机的思想也很有用。一个 Agent 任务通常要经历：接收任务（CREATED）、规划中（PLANNING）、等待工具返回（WAITING_TOOL）、处理结果（PROCESSING）、完成（COMPLETED）、失败（FAILED）这些状态。如果不做状态管理，主 Agent 在长任务里经常会“迷路”，因为它不知道自己走到哪一步了。

用状态模式来管理 Agent 生命周期，和订单状态机几乎一模一样。每个 Agent 状态类负责定义“当前状态能接什么事件、跳到哪里去”，例如 WAITING_TOOL 状态只能接受 tool_result 事件，不能接受 cancel 事件，或者说 cancel 事件在 WAITING_TOOL 下有特殊处理逻辑。这样做的好处是，Agent 的异常处理规则在代码里可以被完整列举，而不是散落在 if-else 里。

另外，观察者模式在 Agent 里对应“事件驱动”的架构。你可以让 Agent 在完成某个子任务时发布一个 TaskCompletedEvent，其他模块——比如日志、指标统计、进度推送——都监听这个事件。这样的话主 Agent 的业务逻辑不会被横切关注点污染，和订单系统里“下单后发通知”的解耦思路完全一致。

学设计模式最妙的地方就在这里：一旦你形成了“识别变化点并隔离变化”的思维，你会在完全不同的技术栈里看到同样的骨架。这也印证了那句老话：设计模式不是语言特性的堆砌，而是一种组织代码的心智模型。

5. 期末、大作业和面试：怎么把模式用得漂亮

5.1 大作业选题：需求要有“变化”而不是功能堆砌

每年都有学生问我：设计模式大作业到底做什么系统才能拿高分？我的建议是别再做“某某管理系统”了——那种 CRUD 项目里很难自然出现设计模式。你要选一个天然带有“变化”的业务场景。候选方向我推荐三个：

第一个是“多平台订单聚合系统”。模拟淘宝和京东同时下单，支付渠道有三种，状态流转复杂，通知方式多样。这天然需要策略模式处理不同平台的数据格式，状态模式处理订单流转，观察者模式处理下单后通知。

第二个是“多格式报表导出器”。数据源相同，但导出格式有 PDF、Excel、CSV、JSON，并且每种格式的行列样式规则不一样。策略模式处理导出算法，工厂模式选择导出器，建造者模式构造复杂的报表对象。

第三个是“AI Agent 任务调度器”。做一个能拆解任务的命令行工具，多个子 Agent 处理不同领域，主 Agent 调度。用我们第四章讲的主从模式思路来设计，这既新潮又能把策略模式用得淋漓尽致。

选好题目后，有一点很重要：在文档里明确写出“这个场景中哪些需求是变化的，哪些是稳定的”，并且给出“如果未来出现 XXX 新增需求，代码需要改哪里”的推演。老师看到这种分析，分数一般不会低。

5.2 写模式文档和画类图的建议

设计模式大作业通常要求画类图和写设计说明。我的经验是：类图不要画 23 种全家桶，只画你用到的模式对应的子集就好。类图的作用是让人一眼看懂你的设计意图，不是展示你会画图。

写文档时，每讲一个模式，用一个固定模板：

• 需求背景：这里不引入模式会怎样？
• 模式选择：为什么选这个模式而不是那个？
• 核心代码：关键类和方法，不要贴几百行。
• 变更场景推演：新增一种支付方式，代码需要改哪几处？这个推演非常有说服力。

我特别建议在文档里加一节“设计权衡”，比如“有些模块我没有使用设计模式，因为未来没有明显的变化点，强行抽象会增加理解成本”。这种诚实的分析能显示出你真正理解了模式的适用边界，而不是为了用而用。

5.3 面试时这样讲模式

面试题“你用过哪些设计模式”，最忌讳的回答是背定义：“策略模式就是把算法封装起来，让它们可以互换。”这种答案没有任何信息量。面试官想听的是：你在什么样的业务背景下，遇到了什么问题，为什么选择了这个模式，以及重构前后有什么变化。

按这个结构来回答就对了：先说背景：“我们在做一个订单系统，支付渠道已经从 3 个涨到 7 个，每次加渠道都要改原来的方法，而且测试范围特别大。”再说方案：“我把支付逻辑抽象成策略接口，用 Spring 注入的策略列表构建 Map，新增渠道时只写一个新的实现类。”最后说收益：“改动范围从改一个几百行的方法变成新增一个 20 行的类，回归范围也小了很多。”如果你能再提一句“我没有把所有代码都改成策略，像鉴权这种逻辑相对稳定的模块就没有用模式”，这个回答就非常饱满了。

再给大家一个小技巧：面试前可以把你之前做过的项目，挑出三个你用模式重构过的具体场景，按上面这个“背景-方案-收益”模板各写一份脚本，背下来。现场面试的时候直接讲你在实际项目里的决策过程，会比临时想一个案例顺畅得多，可信度也高得多。

最后说点我个人的感受。设计模式这个东西，很多人一上手就想把它“学好”，结果越学越焦虑，因为模式太多、案例太假。其实没有必要。你只要先在真实项目里把三四个高频模式用顺——策略、状态、观察者、模板方法——剩下的模式基本都是在这些基础模式上演化出来的。写代码的优雅不是靠背模式背出来的，而是靠持续地观察变化、把变化隔离好、让代码保持可读和可改。这个过程很像练字，你不需要背下所有字体的写法，只要理解笔画的规律，遇到一个从没写过的字，自然就知道该从哪里落笔。设计模式也是这样的。