深度拆解 Spring AI Advisor：求职派如何用拦截器链增强 AI 交互

Spring AI 的 Advisor 机制，本质上就是 AI 调用链上的拦截器。

熟悉 Spring MVC 的小伙伴对 HandlerInterceptor 一定不会陌生——请求进来之前做预处理，响应出去之前做后处理。Advisor 干的是同一件事，只不过拦截的对象从 HTTP 请求变成了大模型调用。

这篇内容会从 Advisor 的链式执行机制讲起，再深入拆解求职派在它基础上做的两层改造。

自研 ReActAdvisor 替代了 Spring AI 内置的工具调用 Advisor，Middleware 插件体系实现了成本监控、日志审计等横切关注点。

读完就能搞清楚，一个生产级别的多 Agent 系统到底应该怎么在 AI 调用链上做拦截和增强。

01、Advisor 到底解决什么问题？

求职派同时对接了微信、钉钉、飞书三个渠道，每个渠道的消息最终都会流转到大模型进行推理。

如果没有 Advisor，每个业务 Agent 在调用大模型之前都需要自己处理一堆横切逻辑：加载对话历史、注入系统提示、记录调用日志、统计 Token 用量、计算费用。这些逻辑和业务无关，但每个 Agent 都得写一遍。

Advisor 把这些横切逻辑从业务代码中抽离了出来，变成了可插拔的拦截器组件。

Spring AI 提供了两套 Advisor 接口，分别对应同步和流式两种调用方式。

public interface CallAdvisor extends Advisor {
    ChatClientResponse adviseCall(
        ChatClientRequest request, CallAdvisorChain chain);
}

public interface StreamAdvisor extends Advisor {
    Flux adviseStream(
        ChatClientRequest request, StreamAdvisorChain chain);
}

ChatClientRequest 封装了请求参数，ChatClientResponse 封装了响应结果。每个 Advisor 拿到请求后，可以修改它、放行它、甚至直接阻断它返回自己构造的响应。

这个设计和 Servlet Filter 的链式调用如出一辙——调用 chain.nextCall(request) 就是把请求传给链上的下一个 Advisor，不调用就是阻断。

02、Advisor 链是怎么执行的？

Advisor 链采用的是栈式结构。

请求进来时，链首的 Advisor 最先处理；响应返回时，链尾的 Advisor 最先处理。和 Servlet Filter 的执行顺序完全一致。

完整的生命周期分为 6 步。

1. 用户的提示词被封装成 ChatClientRequest，同时创建一个共享的上下文 Map，用来在调用链中传递信息
2. 每个 Advisor 依次对请求进行处理，可以修改请求内容，也可以选择直接阻断请求并自己填充响应
3. 如果请求一路没有被阻断，链条的最后一个 Advisor 会触发大模型调用
4. 模型的响应结果沿着链条反向传递回来
5. 链上的每个 Advisor 再依次对响应进行加工，分析、增强、过滤都可以
6. 最终生成 ChatClientResponse 返回给调用方

执行顺序由 getOrder() 方法决定，数值越小优先级越高。多个 Advisor 的 order 值相同时，执行顺序不确定，所以需要给每个 Advisor 设定不同的 order 值。

这套机制很清晰，Spring AI 也内置了一些常用...