当前课程进度

最近更新：2026-07-31

1. 当前定位

• 阶段：S01 Spring AI 1.1.3 核心调用链
• 模块：M01 ChatClient、Advisor、ChatModel 与 DeepSeek
• 当前主要模型：DeepSeek
• 已完成校准：L01 ChatClient 请求解剖
• 下一实际学习：L02 Advisor 与 Memory 的真实执行时机
• 下一次短复习：2026-08-05，复画一次 L01 主调用链

---

2. 本轮掌握结论

当前掌握度

L01：约 90%

这不是根据自述判断，而是根据多轮预测和解释确认。

已经能够准确说明

1. chatClient.prompt() 创建本次请求专属的 DefaultChatClientRequestSpec，不是直接调用模型。
2. .system() 和 .user() 主要先收集字符串、参数和 metadata。
3. call() 会把 RequestSpec 组装成 ChatClientRequest 和 Prompt，并构建 Advisor Chain。
4. call() 本身还没有执行 Advisor，也没有请求 DeepSeek。
5. content()、chatResponse()、entity() 等终结方法会真正启动 Advisor Chain。
6. ChatClient 是业务调用和横切能力的组织门面。
7. ChatModel 是各模型供应商的统一抽象。
8. ChatModelCallAdvisor 位于 Advisor 链底，并调用 chatModel.call(prompt)。
9. 当前模型实现为 DeepSeek 时，后续进入 DeepSeekChatModel 和 DeepSeekApi。
10. 运行时 .system() 会覆盖 ChatClient 默认 system。
11. 默认 Advisor 与本次 Advisor 会同时进入本次请求，之后再根据 order 排序。

最主要的薄弱点

目前不是概念不懂，而是表达还需要精确到对象和方法：

DefaultChatClientUtils 是转换工具
ChatClientRequest 才是调用链中的正式请求对象

以及：

不能把全部默认配置统一总结为“覆盖”或“合并”
必须根据字段类型和源码操作判断

---

3. 当前稳定心智模型

业务代码
→ ChatClient.prompt()
→ 复制默认 RequestSpec
→ system/user/advisors/options 收集本次配置
→ call() 或 stream()
→ DefaultChatClientUtils.toChatClientRequest()
→ ChatClientRequest
   ├─ Prompt
   │  ├─ messages
   │  └─ ChatOptions
   └─ context
→ 构建 Advisor Chain
→ 终结方法启动执行
→ ChatModelCallAdvisor / ChatModelStreamAdvisor
→ ChatModel
→ DeepSeekChatModel
→ DeepSeekApi
→ DeepSeek HTTP
→ ChatResponse
→ ChatClient 输出视图

消息组装顺序

SystemMessage
→ 显式 messages
→ UserMessage

默认与本次配置

system/user 文本：通常覆盖
Advisor/Message/Tool 列表：通常追加
参数和 context Map：按 key 合并
ChatOptions：RequestSpec 层处理后，模型适配层还可能二次合并

---

4. 已完成课程

L01：ChatClient 请求解剖

已达到基本完成标准：

• 能区分 ChatClient 和 ChatModel；
• 能区分 RequestSpec、ChatClientRequest、Prompt；
• 能指出 call() 与真正执行之间的边界；
• 能指出 Message 的正式创建位置；
• 能补全 ChatClient 到 DeepSeekApi 的主链；
• 能判断默认 system 与运行时 system 的覆盖关系；
• 能判断默认 Advisor 与运行时 Advisor 的追加关系。

L01 不再重复讲基础 API。

---

5. 下一实际学习：L02

核心问题

Advisor 是怎样一层一层包住模型调用的？
MessageChatMemoryAdvisor 在调用前和调用后分别做什么？

本节只引入一个主要知识点

Advisor 是 Around Chain

Memory 作为贯穿案例，用来观察：

before 修改请求
→ next 调用下游
→ after 修改响应

重点验证

• order 越小为什么 before 越早；
• 为什么 after 顺序与 before 相反；
• Memory 在什么时间读取历史；
• UserMessage 为什么在模型调用前写入；
• AssistantMessage 为什么在模型成功后写入；
• 下游抛异常时哪些 after 不会执行；
• 流式响应为什么要旁路聚合。

---

6. 已提前生成的第二批小节

老板已正确判断默认配置与运行时配置的基本关系，因此后续课程不再停留在 API 表面。

L04：默认与运行时配置合并

文件：04-default-runtime-merge.md

解决：

哪些字段覆盖
哪些字段追加
哪些 Map 按 key 合并
ChatOptions 为什么还会在 DeepSeekChatModel 中二次合并

产出：

最终 Prompt 观察 Advisor

L05：Advisor 环绕顺序

文件：05-advisor-around-order.md

解决：

order
before / after
短路
异常
流式完成信号

产出：

Advisor 顺序和异常实验

L06：Memory 失败边界

文件：06-memory-lifecycle-failure.md

解决：

conversationId
UserMessage 与 AssistantMessage 的写入时机
半轮对话
流式取消
多实例一致性
reasoningContent 持久化边界

产出：

Memory 故障矩阵

这些课程已经生成，但不会越过 L02、L03 直接推进。

---

7. 当前课程目录

顺序	课程	状态
1	L01：ChatClient 请求解剖	已完成
2	L02：Advisor 与 Memory	下一节
3	L03：DeepSeek 调用与返回	待学习
4	L04：默认与运行时配置合并	已生成
5	L05：Advisor 环绕顺序	已生成
6	L06：Memory 失败边界	已生成

---

8. 本阶段真实产出

L01～L06 完成后必须形成：

Spring AI 1.1.3 + DeepSeek 请求生命周期与故障地图

必须标出：

• RequestSpec 数据；
• Prompt 组装位置；
• 默认与本次配置合并；
• Advisor 排序和环绕执行；
• Advisor 短路和异常路径；
• Memory 读取与两次写入；
• ChatModel 调用；
• DeepSeek 非流式和流式 HTTP；
• 返回对象包装；
• reasoningContent；
• 工具递归入口；
• 流式取消和半轮对话。

---

9. 后续方向

完成当前六节后，根据工作优先级进入：

Tool Calling 完整循环
→ DeepSeek 思考模式与 Tool Calling 兼容
→ ChatMemory 持久化和消息一致性
→ 自定义 Advisor 与可观测性
→ Spring AI Alibaba 对 Spring AI Core 的扩展
→ Agent Framework
→ Graph Core
→ 主子 Agent、中断、恢复和取消

---

10. 固定定位问题

以后分析任何 Spring AI 功能，先问：

它修改 Prompt、context、ChatOptions 还是 ChatResponse？
它运行在 RequestSpec、Advisor、ChatModel 还是供应商 API 层？
同步和流式是否走同一实现？
正常、异常和取消路径分别发生什么？
它属于 Spring AI Core、DeepSeek 适配还是 Spring AI Alibaba 扩展？