Spring AI Advisor 链
1. 通用思想：它在 Agent 里是什么？
如果把 Agent 看成“用户问题进来以后，系统如何在调用模型前后不断加工和控制这次推理”的过程，那么 Advisor 链就是 Agent 的编排控制中枢。
它解决的核心问题是：很多生成式 AI 的高频模式都不是一次普通 Prompt 能解决的。比如：
- 调模型前先注入会话记忆
- 先做 FAQ 缓存命中，不命中再走 RAG
- 只暴露当前意图相关的工具
- 在响应回来后根据结果继续加工
- 当请求不该再往下走时，直接短路返回
普通 HTTP Filter 或 Spring AOP 更擅长处理 Web 请求或 Bean 方法调用，而 Advisor 链是专门围绕 LLM 请求-响应生命周期设计的。
2. Spring AI 落点：由哪些抽象和链路承载？
为什么它能做上下文注入、过滤、短路
Advisor 的核心能力来自它能拦截 ChatClientRequest 和 ChatClientResponse。也就是说，在请求真正发给模型之前，Advisor 可以：
- 查看并修改 Prompt
- 向请求里注入额外上下文
- 决定是否继续调用下一个 Advisor
- 必要时直接构造响应并返回
所以它天然适合做：
- 上下文注入
- 安全过滤
- 缓存短路
- 响应后处理
为什么顺序重要
Advisor 链的顺序由 getOrder() 决定，而且链路是栈式执行：
order越小，请求阶段越早执行- 同一个 Advisor 在响应阶段会越晚执行
这意味着顺序不是装饰问题，而是行为问题。比如：
- 缓存命中型 Advisor 应该尽量前置
- 记忆注入和 RAG 注入要放在模型调用之前
- 安全拦截和死循环保护通常要卡在靠近模型和工具循环的关键位置
高频坑点
- 想在输入端和输出端都当“第一个”，通常要拆成两个 Advisor，而不是幻想一个 Advisor 通吃
- 不同 Advisor 同一
order值，顺序可能不稳定 advise-context可以共享状态，但不要把它滥用成大而杂的全局临时仓库
3. 项目口径：在我的项目里怎么落地？
在我的 [[苍穹外卖AI客服]] 项目里，Spring AI Advisor 链就是 Agent 主循环的工程化承载。用户请求进来以后，不是直接交给模型，而是先经过一串有顺序的增强器：
- 前面可以先做 FAQ 语义缓存短路
- 再做用户上下文和订单上下文注入
- 再做 RAG 规则补充
- 再按意图下发工具白名单
- 最后在靠后位置挂上
SafeToolCallAdvisor，限制重复签名和最大工具调用轮次
这样做的核心价值是把“看起来很玄的 Agent”变成一条可以解释的责任链。我可以很清楚地告诉面试官：Spring AI 的 Advisor 链不是简单 AOP，而是直接工作在 LLM 请求生命周期里，所以非常适合承载上下文工程、工具治理和安全熔断。我的项目里也正是靠这条链，把动态不可控的模型行为压成了可观测、可限制、可复盘的生产级流程。
相关链接：[[Spring AI 核心抽象]] | [[上下文工程]] | [[Spring AI 安全治理]] | [[Spring AI 与我的项目]] | [[苍穹外卖AI客服]]