责任链模式深入解析：从Handler链到框架应用到多Agent编排

1. 责任链模式到底是什么：从一个客服工单场景说起

我第一次觉得"这代码必须用责任链重构"，是在接手一个客服工单系统的时候。当时系统处理一条工单的流程是这样的：先检查用户是否黑名单，再判断是否会员，是会员就走专属客服，不是就进公共队列，同时还要做敏感词过滤、自动回复匹配、工单升级……整个逻辑全堆在一个Service方法里，大概四百多行，if elseif 串了十几层。新来的同事看这段代码，第一反应是"我是不是少看了个括号"。

责任链模式解决的就是这种问题：把每个处理环节拆成独立的处理器，按顺序串成一条链，请求沿着链依次经过每个处理器，谁有能力处理就处理，处理不了就往后传。它跟现实生活中"层层审批"一个道理——员工请假三天，组长能批就批；超过三天，组长签字后转给部门经理；部门经理也批不了，再往上转。你不需要带着请假条同时找三个人，只需要把假条递给第一个人，剩下的路径由链自己决定。

这个设计模式的别名挺多，有人叫它职责链模式，英文是 Chain of Responsibility。它是 GoF 总结的 23 种设计模式之一，属于行为型模式。行为型模式关注的核心是"对象之间怎么协作、怎么分配职责"，责任链的重点就是职责的传递与解耦：发起请求的对象不关心最终是谁处理的，处理者之间也不互相依赖，只依赖一个抽象接口。

适合用责任链的场景，通常有几个共同特征：处理流程有多个环节、环节的先后顺序相对固定、每个环节都可能终止或放行、以及"请求发送者和接收者都不想绑死"。最典型的例子就是 Servlet 的 Filter 链、Netty 的 Pipeline、MyBatis 的 Interceptor，这些框架内部全是责任链的变体。理解了责任链，你再看这些框架的源码，会豁然开朗——原来它们调用链路的骨架，就是你把 Handler 串起来的那条链。

1.1 没有责任链时，审批逻辑是怎么写成一坨的

把 request.setMember(true) 这种真实业务放一边，先说一个非常典型的"坏味道"代码。假设你要写一个订单发货前的校验逻辑：校验订单是否存在、校验是否已支付、校验库存是否充足、校验收货地址是否完整。很多人的第一版代码长这样：

java复制public void beforeShip(Order order) {
    if (order == null) {
        throw new IllegalArgumentException("订单不存在");
    }
    if (!order.isPaid()) {
        throw new IllegalArgumentException("订单未支付");
    }
    if (stockService.getStock(order.getSku()) <= 0) {
        throw new IllegalStateException("库存不足");
    }
    if (!AddressValidator.isValid(order.getAddress())) {
        throw new IllegalArgumentException("收货地址不完整");
    }
    // 真正发货
    shipService.ship(order);
}

这段代码的问题，初看是"方法太长了"，但本质是职责耦合。订单校验、支付校验、库存校验、地址校验，分别对应不同的业务规则，它们唯一的共同点是"在发货前都需要执行"。如果你今天要加一个"风控拦截"，明天要加一个"预售订单跳过库存校验"，后天某个渠道的订单不需要校验地址——你就会在这个方法里继续加 if 和 flag，改一次测试一次，每次改动都冒着重写整段逻辑的风险。

更难受的是，校验顺序一旦写死，想"动态调整"几乎不可能。比如大促期间想让"库存校验"前置到"支付校验"之前以减少数据库压力，你就得改这段代码的顺序。而改动顺序在 if else 里属于"伤筋动骨"的调整，牵一发动全身。

1.2 责任链模式的核心角色：Handler、Chain、Client

责任链模式涉及的角色，其实就三个半：

• Handler（处理器抽象）：定义处理请求的统一接口，通常有一个 handle 方法，以及一个"设置下一个处理器"的方法。
• ConcreteHandler（具体处理器）：实现 Handler，内部包含自己的处理逻辑，以及"是否要传给下一个"的判断。
• Chain 或请求对象：在一些实现里，链本身被抽象成一个对象，负责按顺序调度所有 Handler；在另一种实现里，链是隐式的，靠每个 Handler 持有一个 next 引用串联。
• Client（客户端）：发起请求的调用方，它只认识第一个 Handler，不关心链后面还有谁。

用代码表达，最简单的 Handler 抽象长这样：

java复制public abstract class AbstractHandler {
    protected AbstractHandler next;

    public void setNext(AbstractHandler handler) {
        this.next = handler;
    }

    public abstract void handle(Request request);
}

每个具体处理器只要做两件事：判断自己能不能处理，能处理就处理，不能处理就调 next.handle(request)。你可以选择"处理完就终止"，也可以选择"处理完继续传给下一个"，这取决于业务语义。前者叫"纯责任链"，后者叫"不纯责任链"。实际项目中，不纯责任链反而更常见，因为很多场景需要"流水线式"处理，每个环节只做自己那份事。

下单链路里的校验改造成责任链，大概是这种感觉：OrderValidator、PaidValidator、StockValidator、AddressValidator 各归各的类，每个类只管一个维度，顺序由组装者决定。以后再想插入风控校验，new 一个 RiskValidator，在组装处接上即可，一行现有代码都不用改。这就是责任链价值最直观的体现。

2. 责任链的两种实现风格与选型依据

责任链的实现，业内大体有两种流派。一种是链表式，每个 Handler 内部持有下一个 Handler 的引用，客户端只需要拿到链头；另一种是集合式，用 List 或数组把一系列 Handler 装起来，由独立的 Chain 对象遍历调用。这两种流派没有绝对的优劣，取决于你的使用场景。

2.1 链表式：手动维护下一跳引用

链表式是 GoF 经典实现。它的特点是每个节点自己知道"下家是谁"，Handler 之间通过 setNext 构建链接关系。这种方式的好处是链的形态非常灵活，可以是线性的，甚至可以实现一些"跳链"逻辑——某个 Handler 可以根据请求内容，动态指定下一跳是 A 还是 B，也就是说链的结构可以在运行时被节点改变。

java复制Handler chain = new BlacklistHandler();
chain.setNext(new MemberHandler());
chain.setNext(new DefaultHandler());

chain.handle(request);

链表式的缺点是链的组装代码和 Handler 本身纠缠在一起。如果你有十几个 Handler，组装处就会出现一长串 setNext 调用，阅读起来不够直观，而且链一旦搭好，想看到"整条链长什么样"需要手动顺着 next 往下捋。另一个隐患是：如果某个 Handler 忘记调用 next，链就在那里断掉，而且这种断链是静默的，请求后续环节全部失效却没有任何报错。

2.2 数组/列表式：循环遍历处理器集合

集合式设计把链的职责从 Handler 里剥离出来，由一个专门的 Chain 或 Pipeline 对象持有 List<Handler>，按 index 顺序遍历执行。这才是现代框架更偏爱的形态，Netty 的 DefaultChannelPipeline、Spring MVC 的 HandlerInterceptor 注册表、MyBatis 的 InterceptorChain，本质都是"集合式责任链"。

java复制public class ValidationChain {
    private final List<Validator> validators = new ArrayList<>();

    public ValidationChain addValidator(Validator validator) {
        validators.add(validator);
        return this;
    }

    public void execute(Order order) {
        for (Validator validator : validators) {
            if (!validator.validate(order)) {
                throw new IllegalArgumentException(validator.errorMessage());
            }
        }
    }
}

集合式的好处一眼就能看出来：链的结构是一个可迭代的列表，添加、删除、重排处理器都只需要操作 List，想要了解整条链有哪些环节，一行代码打印 validators.size() 即可。但它也不是银弹——当某个处理器想"终止链条往下走"时，集合式的循环需要有明确的终止约定（比如抛异常、返回 false、或设计一个 Break 标记），不像链表式那样天然支持"沉默跳过"。

2.3 链表式和数组式的取舍，取决于什么

我自己的选型原则很简单：

• 节点数量少、链结构固定、每个节点逻辑独立：链表式够用，代码也直观。比如请假审批链，节点就三四个，写好 setNext 一劳永逸。
• 节点数量多、可能需要动态增删、允许中间人拦截或终止：集合式更合适。比如网关的过滤器链，你不可能预知未来要加多少过滤器，也不希望改动已有 Handler 的代码。
• 要求能回顾整条链、方便调试和监控：无脑选集合式。List 天然可遍历、可排序、可打印，链表式想做到这些就得额外维护一个"链路视图"。

另外还要考虑一个隐藏点：并发模型。如果链对象会被多个线程同时使用，链表式因为每个节点都有可变 next 字段，线程安全处理起来很麻烦；集合式只要做好 List 的不可变快照，遍历时是安全的。在 Spring 这类容器里，Bean 默认是单例的，处理器实例往往被多线程共享，这种情况下集合式踩的坑明显更少。

3. Java与C++落地：代码级拆解

理论说太多容易飘，直接看实现。我带两个版本的代码，一个 Java 管后端业务，一个 C++ 管底层或中间件场景，覆盖"业务校验"和"数据流处理"两类典型应用。

3.1 Java 示例：请假审批链

假设规则是：请假小于等于3天，组长审批即可；3到7天，组长审批通过后需部门经理审批；超过7天，还需总监审批。这个例子最能体现责任链"逐级上报"的语义。

java复制public class LeaveRequest {
    private final String name;
    private final int days;
    // 构造器、getter 省略
}

public abstract class Approver {
    protected Approver next;

    public Approver setNext(Approver next) {
        this.next = next;
        return this;
    }

    public abstract void approve(LeaveRequest request);
}

public class GroupLeader extends Approver {
    @Override
    public void approve(LeaveRequest request) {
        if (request.getDays() <= 3) {
            System.out.println("组长审批通过: " + request.getName());
        } else if (next != null) {
            next.approve(request);
        }
    }
}

public class DepartmentManager extends Approver {
    @Override
    public void approve(LeaveRequest request) {
        if (request.getDays() <= 7) {
            System.out.println("部门经理审批通过: " + request.getName());
        } else if (next != null) {
            next.approve(request);
        }
    }
}

public class Director extends Approver {
    @Override
    public void approve(LeaveRequest request) {
        System.out.println("总监审批通过: " + request.getName());
    }
}

组装：

java复制Approver groupLeader = new GroupLeader();
Approver manager = new DepartmentManager();
Approver director = new Director();

groupLeader.setNext(manager);
manager.setNext(director);

groupLeader.approve(new LeaveRequest("张三", 5));

这段代码的逻辑是"能处理就处理，不能处理就交给下一级"。注意 DepartmentManager 里 7 天以上连经理都不批，直接转给总监，这是"推卸责任"的正确姿势。责任链模式里，每个 Handler 有权决定自己处理、不处理、还是处理后继续传。请假审批场景的语义是"只让最合适的一个人处理"，所以每个节点处理完就 method 返回，不继续往下传。

3.2 C++ 示例：日志分级处理

C++ 里责任链的经典应用是日志框架。Logger 分 DEBUG、INFO、ERROR 三级，底层日志框架（比如 spdlog 早期设计）如果做分级输出，可以用责任链让"高等级日志"的处理器同时处理低等级日志（或者反过来，取决于你的过滤规则）。这里我演示一个更贴近现代 C++ 风格的实现，用 std::unique_ptr 管理链节点：

cpp复制#include <iostream>
#include <memory>
#include <string>

enum class LogLevel { DEBUG, INFO, ERROR };

class Logger {
public:
    virtual ~Logger() = default;
    Logger* setNext(std::unique_ptr<Logger> next) {
        next_ = std::move(next);
        return this;
    }
    void log(LogLevel level, const std::string& msg) {
        if (canHandle(level)) {
            write(level, msg);
        }
        if (next_) {
            next_->log(level, msg);
        }
    }
protected:
    virtual bool canHandle(LogLevel level) const = 0;
    virtual void write(LogLevel level, const std::string& msg) const = 0;
private:
    std::unique_ptr<Logger> next_;
};

class DebugLogger : public Logger {
protected:
    bool canHandle(LogLevel level) const override {
        return level == LogLevel::DEBUG;
    }
    void write(LogLevel level, const std::string& msg) const override {
        std::cout << "[DEBUG] " << msg << std::endl;
    }
};

class InfoLogger : public Logger {
protected:
    bool canHandle(LogLevel level) const override {
        return level == LogLevel::INFO;
    }
    void write(LogLevel level, const std::string& msg) const override {
        std::cout << "[INFO] " << msg << std::endl;
    }
};

class ErrorLogger : public Logger {
protected:
    bool canHandle(LogLevel level) const override {
        return level == LogLevel::ERROR;
    }
    void write(LogLevel level, const std::string& msg) const override {
        std::cout << "[ERROR] " << msg << std::endl;
    }
};

注意这个设计与请假审批最大的区别：log() 方法里，当前节点处理完仍然继续调用 next_->log()，也就是"不纯责任链"。一条 ERROR 日志会依次经过 DebugLogger、InfoLogger、ErrorLogger，但只有 ErrorLogger 真正输出。这种链的作用是把"判断过滤器"和"输出器"解耦，每个 Logger 只管自己关心的等级。C++ 实现里有一个容易踩的坑：析构顺序。如果 next_ 是裸指针，手动 delete 链上节点时顺序一错就崩；用 std::unique_ptr 让链节点自动级联析构，既安全又省心。

3.3 与 Spring、Netty 这些框架的关系

很多 Spring 开发者天天用 Filter 却不知道这是责任链。Spring MVC 的 HandlerExecutionChain 把多个 HandlerInterceptor 按顺序存成一个数组，执行请求时先正序调用 preHandle，再反序调用 postHandle 和 afterCompletion——这是集合式责任链的典型实现，通过循环控制顺序和终止流程。

Netty 的 ChannelPipeline 就更有意思了，它在链的基础上升级出了一个双向链表：ChannelInboundHandler 和 ChannelOutboundHandler 分别挂在链的两个方向上，一个数据包从入站到出站会经过一条完整的双向链。你写 pipeline.addLast("decoder", new ByteToMessageDecoder()) 其实就是在往责任链上挂节点。理解了责任链，你观察 Netty 的 IO 线程模型会顺畅很多——它本质就是"数据包在一条可动态增删的处理链上流动"。

所以责任链不是一种过时的玩具模式，它早已渗透在主流框架的骨架里。学它的价值不在于面试时背个 UML 图，而在于你看中间件源码、写业务代码时，能认出哪里的"一堆 if"其实是应该抽象出来的链。

4. 责任链的边界问题：什么时候该停手

设计模式最大的陷阱是"手里拿着锤子，看什么都像钉子"。责任链虽然好用，但用错地方比不用还糟。我见过有人把三个固定步骤也套成责任链，代码绕了一圈，最后还是三个类互相调用，阅读成本暴涨。这一节专门聊边界。

4.1 责任链和装饰器、策略模式的区别

很多人分不清责任链和装饰器模式，因为它们的类结构乍看有相似之处：都有一个抽象接口，都有多个实现类，都涉及到"链式调用"。但它们的意图完全不同。

• 责任链模式：请求沿着链传递，每个节点决定是否处理、是否终止。核心是"请求分发与职责移交"。
• 装饰器模式：对象经过一层层包装，每个包装增强原始对象的功能。核心是"功能叠加"，调用完这一层必然继续调下一层，而且最终总会调到最里层的原始对象。
• 策略模式：把一组可互换的算法封装起来，客户端在运行时选择一个替换整体行为。核心是"算法替换"，不存在链式传递。

一个典型的混淆场景是"日志输出前要加格式、加压缩、加加密"。很多人直觉用责任链，每个 Handler 做一件事然后传给下一个。但实际上这更适合装饰器：层层包装同一个日志写入器，每一层增强"写"这个动作。责任链是多个处理者竞争同一个请求，装饰器是多个层级服务同一个对象。

至于策略模式，如果你们的"库存校验"有多种实现（按仓库校验、按总仓校验、按地区校验），那该用策略而不是责任链——客户端直接选一个算法执行，不需要"依次尝试直到成功"。

4.2 过度使用责任链的症状

责任链不是"类越多越好"，当项目出现以下症状时，多半是责任链用过头了：

• 链上有超过8个节点，而你很难说出每个节点存在的理由。
• 大部分节点只是"看了一眼请求，什么都不做就传给下一个"，典型的占位符节点。
• 为了知道某个请求最终走了哪些节点，你不得不打断点逐个排查。
• 节点之间的顺序强依赖，比如 A 必须严格在 B 之前，B 必须严格在 C 之前，但代码层面没有任何机制保证这一点，全靠组装处自觉。
• 请求对象的字段被链上的节点不断修改，最终"流动的请求"变成一堆可变状态的杂烩，排查问题根本不知道是谁改的。

责任链适合的是"顺序相对固定、每环节有明确职责"的场景。如果你的链非常长、顺序经常变、节点职责重复，大概率你的问题不在于"没用好责任链"，而在于流程设计本身就需要简化。

4.3 纯责任链与不纯责任链

从语义上，责任链分两种。纯责任链要求一个请求只能被一个处理者处理，其余处理者全都跳过，例如请假审批。不纯责任链允许一个请求被多个处理者依次处理，每个处理者只做自己的部分，处理完继续传递，例如过滤器链。

不纯责任链在实际生产系统中才是主流。像网关的鉴权、限流、日志、转发，这些环节没有一个会"处理完就返回"，每个都希望请求继续往下走。这种模式如果命名严谨一点，其实更像"管道模式"（Pipeline），但 GoF 没有单独列管道模式，所以人们习惯把它归入责任链的变体。你在写作时如果严格区分，可以把"每个节点只处理一次且必须继续传"的实现直接命名成 Pipeline，很多团队也是这么称呼的。

区分纯与不纯的意义在于约定。团队里规定责任链是"一人处理"还是"流水线处理"，直接影响每个 Handler 里是否要显式调用 next。这个约定必须写进团队规范，否则有人新加一个 Handler 时，不知道 Should 还是 Shouldn't 调用 next，链的行为就会变得不可预测。

5. 责任链模式在多Agent设计中的新角色

近年多 Agent（多智能体）架构越来越火，我注意到一个有意思的趋势：很多现代 Agent 编排框架，底层逻辑跟责任链模式高度重合。虽然很少人明确说"这里用了责任链模式"，但有经验的工程师一眼就能认出那个骨架。

5.1 从 subagent 到工具调用的主从思想

最新的多 Agent 设计里，主从模式（Supervisor/Worker）越来越被强调。过去大家把 subagent（子智能体）看成"另一个会说话的程序"，主 Agent 把任务交给它，它返回结果。但实践下来，这种"全权委托"式的设计很难控制，子 Agent 经常跑偏、输出不可解析、或者来回纠缠浪费时间。

于是有人换了个思路：把 subagent 视为一种"另类的 tool 进行调用"。也就是说，在主 Agent 的视角里，子 Agent 就是一个函数：输入一段 prompt，输出一段 response，只不过这个函数内部不是确定性的代码，而是一个大模型驱动的工作流程。这种思想一旦确立，Agent 之间的调用链自然就变成了一套"责任链 + 路由"的结构——主 Agent 依次尝试调用工具 A、工具 B、工具 C，每个工具判断自己是否适合处理当前子任务，适合就处理，不适合就交给下一个。

这个模型跟责任链模式的核心思想完全一致：调用方不关心最终是哪个工具/子 Agent 处理了请求，只把它交给链条，由链条内部决定谁接单。

5.2 多 Agent 编排中的责任链式管线

实际搭建多 Agent 系统的时候，我会这样设计一个"Agent 责任链"：

1. 定义统一的 AgentHandler 抽象，接收一个 TaskRequest，内部可以调用大模型，也可以调用普通工具。
2. 主 Agent 把任务拆成多个子任务，依次放进责任链。每个 AgentHandler 判断自己擅长的领域：你有 RAG 检索能力，我有代码执行能力，它有网页搜索能力，各自检查任务类型，匹配则处理，不匹配则跳过。
3. 对"必须经过所有环节"的流程（例如先做意图识别，再做知识检索，再做答案生成），就用不纯责任链，让每个 Agent 处理完自己那步后把结果传给下一个。

这种设计的优势，跟业务系统的责任链完全一样：新增一个 Agent 能力不需要改主流程代码，只要往链上挂一个新的 Handler；排障时可以把链上每个节点的输入输出都打日志，精准定位是哪一步返回了错误格式；如果某个 Agent 不稳定，甚至可以"摘掉"它而不影响其他环节。

当然责任链不是 Agent 编排的唯一答案。如果子任务之间是"并行、互相独立"的，那就该用编排框架的 DAG 或并行路由，而不是串成链。责任链适合的是串行、有先后依赖、且每个节点自治的流程。但理解这一点本身，就是设计模式老手和只会调 API 的新手的分水岭——你先把工具，面对新架构时，看到的不是陌生的库，而是熟悉的骨架。

6. 我踩过的几个坑与排查思路

责任链模式代码本身不难，难的是在真实项目中不出幺蛾子。这里分享几个我亲身踩过的坑，每一个都是"不写进文档，但迟早会踩"的典型。

6.1 循环依赖导致的 StackOverflow

有次改网关过滤器链，某个 Handler 内部竟然又 new 了一条新链，还把自己作为新链的第一个节点。当请求过来，链条 A 走到这个 Handler，Handler 创建链条 B 并转发请求，链条 B 的第一个节点还是这个 Handler，于是它又创建链条 C……代码稀里糊涂就 StackOverflow 了。

排查过程并不难，dump 线程栈一看全是同一个 Handler 的 handle 方法反复入栈。但教训很深：责任链的组装和 Handler 的执行必须分离。Handler 只负责处理请求，不要自己创建链、也不要持有全局链的引用再往回头调用。如果你需要"一个 Handler 执行完后再回到初始链"，这应该由 Chain 对象统一调度，而不是在 Handler 内部手工跳链。

6.2 断链后静默失败

链表式责任链最容易出的问题是断链。某个 Handler 里的逻辑是"如果满足条件就走分支 A，否则分支 B"，分支 B 忘了调 next.handle()，这个 bug 几乎不可能通过静态扫描发现。结果是：线上请求走到这个节点后戛然而止，后面的校验、落库全部没有执行，而且没有任何日志和异常。

后来我给自己定了一条规矩：链表式责任链里，每个 Handler 的 handle 方法必须保证"要么处理请求、要么显式丢弃、要么调用 next"，三选一，不允许出现"默默 return"。如果你的团队用链表式，建议在基类里加一个保护逻辑——如果节点处理完没有传递也没有显式标记终止，就打印一条 WARN 日志：

java复制public abstract class AbstractHandler {
    private AbstractHandler next;

    public void setNext(AbstractHandler next) {
        this.next = next;
    }

    public void handle(Request request, ChainStatus status) {
        boolean handled = doHandle(request, status);
        if (!handled && status.isContinue() && next != null) {
            next.handle(request, status);
        } else if (!handled && !status.isContinue()) {
            // 显式终止，这里可以做清理
        }
    }

    protected abstract boolean doHandle(Request request, ChainStatus status);
}

用返回值强制每个节点表态：处理了还是没处理。这样即使某天有人漏写 next，你也能从日志里看到"某个节点处理请求后没有继续传递"。

6.3 动态编排责任链的注意事项

很多系统希望"根据配置动态决定链上挂哪些 Handler"。这个想法没问题，但踩过几次坑之后我建议注意三件事：

第一，顺序不能只靠 List 的插入顺序隐式保证。最好给每个 Handler 增加一个 order 字段，按 order 排序后执行。不然哪天有人把两个 Handler 的新建代码调了一下顺序，链的行为就变了，排查时一脸懵。

第二，动态添加 Handler 要考虑幂等。如果配置文件里写了两次同一个 Handler，链上会出现两个相同节点，轻则重复执行，重则死循环。注册前通过 Handler 的 class 全名去重，这行代码能省掉很多线上事故。

第三，链的可观测性不能丢。责任链的黑盒性质是它的天然缺点——请求进去之后到底走过了哪些节点，默认谁也不知道。建议在 Chain 执行器里统一打印"进入节点 X，出参状态 Y"，或者用 AOP 拦截 Handler 的 handle 方法统计耗时。链越长，监控越重要。没有监控的责任链，线上出了事就是大海捞针。

总的来说，责任链模式是个上手容易、精通难的模式。它的价值不在"写一个能跑的 Handler 链"，而在于你懂得什么时候该用它、怎么让它在生产环境稳定运转、以及主动规避那些隐性坑。如果团队里有人正被一堆 if else 折磨，不妨把责任链作为重构方案之一——但记得提醒他：模式只是工具，真正重要的是把流程理清楚，让每个环节的职责都清晰可见。