S22-B03 · Advisor：请求/响应日志与横切能力

适用读者：想在"不改业务代码"的前提下加日志、记忆、RAG 的人。
前置：S22-B01、S07-B03（AOP）。
口径：结构示意（未引入 Spring AI 依赖）。
覆盖旧文：606(348) + 611(348，duplicate_ref) = 696 点。
覆盖扩展：E-S22-003（Advisor 链）。
上一篇：S22-B02 · 结构化返回与 Function Call
下一篇：S22-J01 · 多模型路由。

1. 一句话结论

Advisor 就是"模型调用的拦截器链"：把日志、记忆注入、RAG 检索、审计这些横切关注点，从业务代码里抽出来——和 S07-B03 的 AOP 是同一个思路。

请求 → Advisor1（记日志）→ Advisor2（注入记忆）→ Advisor3（RAG 检索）
     → 模型 → Advisor3' → Advisor2' → Advisor1'（记录响应/耗时）→ 返回

2. 一个 Advisor 的生命周期（E-S22-003）

阶段	能做什么
前置（before）	改写提示词、注入上下文、记录请求
后置（after）	记录响应、统计 token、脱敏
异常	降级、重试、打点

"日志为什么放 Advisor"：放业务代码里会漏（新增调用点忘了加）；放 Advisor 就是一处配置、全局生效——与 S07-B06 的 MDC 链路日志同理。

3. 常见的四类 Advisor

类型	作用	注意
日志/审计	记录请求响应与耗时	脱敏（S20-A02）
记忆注入	把历史/偏好塞进提示词	控制 token 预算（S20-J02）
RAG 检索	检索片段注入	检索失败要能降级（S20-B03）
安全	敏感词/越权拦截	不能只靠它（S21-A02）

判据："这件事每个调用点都要做吗？" 要 → Advisor；只有某处要 → 业务代码。

4. 顺序与陷阱

陷阱	后果
顺序错（记忆在 RAG 之前/之后）	提示词里内容错位
Advisor 里做重 IO	拖慢所有调用
日志未脱敏	敏感数据落盘
Advisor 里抛异常	整个调用失败

"顺序怎么定"：按"数据依赖"排——检索要先于"组装最终提示词"，日志要包在最外层。

5. 与 AOP/拦截器的对照

机制	作用域	类比
Spring AOP	任意 Bean 方法	通用
MVC Interceptor	HTTP 请求	S07-B04
AI Advisor	模型调用	本系列

"三层各管一段"：HTTP 进来 → MVC；业务方法 → AOP；模型调用 → Advisor——不要试图用一层解决所有。

6. 五个误区

误区	真相
"Advisor 只能记日志"	记忆/RAG/审计都能做
"顺序无所谓"	数据依赖决定顺序
"日志直接记原文"	必须脱敏
"Advisor 能替代安全检查"	只是其中一层
"Advisor 里可以随便做重活"	会拖慢全部调用

7. 自检

Advisor 的三个阶段各能做什么？
为什么日志放 Advisor？
四类 Advisor 的注意点？
顺序由什么决定？
AOP / Interceptor / Advisor 的分工？

8. 下一篇

S22-J01 · 多模型路由与运行时切换

Advisor 讲完，进阶层开始：一个请求怎么决定用哪个模型。

本篇属于系列《S22 · AI 工程落地实战》。旧文来源：A-606（A-611 为同内容 duplicate_ref）；扩展点 E-S22-003。