Ethan's Notes

Appearance

Spring AI 与我的项目 ​

1. 通用思想：它在 Agent 里是什么？ ​

如果只讲 AI Agent 概念，很容易停留在“模型 + 工具 + 记忆 + RAG”这几个词上。真正的难点是：这些能力在一个 Java 项目里怎么装起来、跑起来、控起来。

对我来说，Spring AI 的价值不是“会不会调一个大模型”，而是它给了我一套把 Agent 通用思想变成工程实现的骨架：

  • ChatClient 做入口
  • Advisor 做编排
  • Tool Calling 做行动能力
  • ChatMemory 做短期上下文
  • RAG 做知识补给

所以这张卡不是单独讲某个 API，而是专门回答：这些抽象在我的项目里分别落在哪，解决了什么问题。

2. Spring AI 落点：由哪些抽象和链路承载？ ​

在我的项目里的映射 ​

  • ChatClient：统一承载用户请求到模型的调用入口
  • Advisor 链：承载用户上下文注入、记忆、RAG、工具过滤、安全熔断
  • Tool Calling：承载订单查询、取消订单、退款、FAQ 检索等工具式能力
  • ChatMemory：维持对话级上下文
  • RAG：补齐 FAQ 和规则类知识

我的核心理解 ​

Spring AI 解决的是“怎么把这些东西编织进一次模型调用链里”，但真正的业务确定性仍然来自代码：

  • 工具白名单由意图控制
  • 工具结果要结构化回填
  • 高风险状态要后端强校验
  • 多步任务的数据闭环不能只靠模型脑补

3. 项目口径：在我的项目里怎么落地？ ​

在 [[苍穹外卖AI客服]] 项目里，我基于 Spring AI Advisor 链搭了完整的 Agent 调度骨架。用户问题进来后，不是直接丢给模型，而是先由链路分层处理：

  • FAQ 问题优先走语义缓存命中
  • 订单类问题注入用户身份、订单上下文和业务规则
  • 根据意图只下发相关工具，而不是把所有业务 API 全暴露给模型
  • 工具执行结果再回填给模型，形成下一轮推理上下文
  • 如果模型出现重复工具签名或轮次过多，由 SafeToolCallAdvisor 直接熔断短路

这套设计的核心价值，是把 Agent 从“靠 Prompt 堆出来的黑盒”变成了一个可解释的 Spring 工程系统。面试里我会强调：我不是把 Spring AI 当成现成魔法，而是把它当成实现载体。真正让我项目有区分度的，是我怎么利用这套载体把上下文工程、工具治理、RAG、记忆和安全边界压成了可用的生产链路。

相关链接：[[Spring AI 核心抽象]] | [[Spring AI Advisor 链]] | [[Spring AI Tool Calling]] | [[Spring AI 记忆机制]] | [[Spring AI 与 RAG 集成]] | [[Spring AI 安全治理]] | [[苍穹外卖AI客服]]