最近刷GitHub和技术社区，感觉大家都在搞AI应用。平时看一些开源项目，满屏都是 Agent、RAG、Function Calling、MCP 这些英文缩写。

一开始我挺懵的，以为现在做AI就是拿个API Key去调大模型的接口就行了，完全不明白为啥冒出来这么多新词。后来代码看多了才慢慢琢磨过味儿来：大模型本身其实只是个“大脑”，要把这个大脑真正接入到咱们平时的业务系统里去干活，还需要一整套外围的工程化封装。

花了几天时间，我把这些满天飞的概念按自己的理解串了一遍。这篇文章算是我自己的一份梳理笔记，顺便画了几张草图，试着用咱们后端的视角去对应一下这些新东西。

一、AI应用整体的逻辑架构

为了搞清这些组件是怎么配合的，我试着画了个大致的架构关系图。

大致逻辑是这样的：
用户发来一段话（Prompt），系统会把过去的聊天记录（Memory）捞出来，拼成一个完整的上下文（Context）交给主控程序（Agent）。
Agent 自己没脑子，它遇到问题会去请求大模型（LLM）该怎么处理。如果业务复杂，Agent 会按照预设的流程（Workflow）把活儿分给下面的小弟（SubAgent）。
在执行过程中，Agent 肯定需要查数据或者调接口，它就会用到各种工具（Skill），比如去查内部文档（RAG + Search）。至于它是怎么触发这些动作的，一般是通过 Function Calling 机制或者最近比较火的 MCP 协议。而把这一大堆东西拼装起来的脚手架，就是 LangChain 这类框架。

二、逐个概念对应理解

之前看文档觉得晕，主要是概念太多。我试着把每个词拆开，配个简单图，再代入到咱们熟悉的后端开发里，感觉就没那么高大上了。

1. LLM (大语言模型)

这东西就是整个系统的推理引擎，比如GPT-4、通义千问。以前我们的代码是写死的if-else，没法处理模糊的自然语言，LLM就是拿来干这个的。
在后端看来，它特别像一个功能极其强大、但是完全无状态的纯函数工具类——你传给它一段很长的字符串，它经过计算，吐出一段预测好的字符串给你。

2. Prompt (提示词)

因为模型是被动响应的，而且经常会瞎猜，所以你需要给它设定好前提和边界。Prompt 就是控制大模型输出方向的“方向盘”。
类似于咱们传给外部接口的 Request Payload（请求体），只不过以前是严格的 JSON 格式，现在换成了大白话。

3. Context (上下文)

大模型有字数限制，而且它记不住你们上文聊了什么。每次请求时，必须把之前的背景情况打包全传过去，这团数据就是 Context。
这几乎就是 Web 开发里的 RequestContext，或者是当前线程 ThreadLocal 里塞的各种环境变量，主要用来给当前运算提供背景依赖。

4. Memory (记忆)

因为 LLM 是无状态的接口，所以我们得自己想办法把过去的对话存起来，需要的时候再捞出来。
这套机制其实就是后端系统里做 Session 会话状态管理 的那一套，数据一般存在数据库或者 Redis 里。

5. Agent (智能体)

光聊天没用，得让程序能真正“采取行动”。Agent 就是带有逻辑判断能力的主控程序，它知道什么时候该去找大模型思考，什么时候该去调用查询接口。
它特别像我们写在 Controller 或者 Service 层的业务主干代码，负责接收请求，调各个 DAO 和第三方接口，最后把结果拼好返回给前端。

6. RAG (检索增强生成)

大模型不知道你们公司的私有数据，直接问它会产生幻觉胡说八道。所以得先去库里查出真实资料，把资料连同问题一起喂给模型，这就是 RAG（先检索，再生成）。
这和我们平时写代码 “先查 DB 捞出业务数据，再把数据塞进模板引擎里渲染成页面” 的思路简直一模一样。

7. Search (检索)

这就是 RAG 里“查资料”那一步。因为文档太多，不可能全塞给 LLM（太贵且有限制），得用向量搜索或者全文检索过滤出最相关的几段。
其实就是执行了一条带有 WHERE 条件的 SQL 查询，或者调了下 Elasticsearch 拿到了 Top N 的结果。

8. Function Calling (函数调用)

大模型没手没脚，没法直接执行咱们服务器上的本地代码。它只能在理解用户意图后，输出一段带参数的 JSON 告诉你：“嘿，按照你给的格式，我现在觉得你应该去调查天气的方法了”。
这相当于一种动态的 RPC 调用的协议契约，模型负责“组装请求参数”，真正跑逻辑的还是咱们后端的代码。

9. MCP (模型上下文协议)

以前连不同的数据源和外部工具，大家都是各写各的接口，非常混乱。最近出的 MCP 就是一套新的标准化连接协议。
理解起来毫无障碍，这就好比 Java 里的 JDBC 驱动规范。大家都按一套标准来写，业务侧就不用为了适配每一种数据库去写一堆恶心的定制代码了。

10. Skill (技能)

Agent 能调用的具体功能单元。为了方便管理，一般会把复杂能力拆成小颗粒的模块。
也就是我们平时项目里写的一个个 Util 工具类，或者封装好的外部第三方 API Client。

11. Workflow (工作流)

完全让 Agent 自由发挥有时候很容易跑偏甚至死循环。在一些严谨的业务场景，我们需要用固定的流程图把它框住。
这就类似软件架构里的 状态机 模式，或者像 Activiti / Camunda 这样的工作流引擎。

12. SubAgent (子智能体)

一个 Agent 管所有事情会导致 Prompt 太长，而且很容易糊涂。不如拆分成专职写代码的、专职查资料的，各司其职。
这就是典型的 微服务架构思想，把一个大单体拆分成多个边界清晰的服务协同工作。

13. LangChain (框架)

如果上面讲的这些发请求、拼 Context、处理 JSON、记日志全要自己从头敲代码，那是相当费劲的重复劳动。
LangChain（包括 Spring AI 这种）就是帮你把底层脏活累活包好了的框架，相当于 AI 开发界的 Spring Boot。

三、顺手画个RAG的执行流程

整体看下来，感觉 RAG 是目前落地最实用的场景。它的执行时序其实很简单：

四、传统后端与AI应用的一个对比

把思路理顺之后，我发现其实 AI 开发没有脱离原有的架构体系，很多底层逻辑是相通的，仅仅是把一些确定性的计算换成了基于概率的生成。

比较维度	传统 CRUD 后端系统	AI 应用系统 (Agentic)
核心处理单元	CPU + 写死的 If-Else 逻辑	LLM（大模型推理计算）
交互入口	严格的 API 请求 (JSON/表单)	自然语言提问 (Prompt)
运行上下文环境	Session / ThreadLocal	Context / Memory
外部系统交互	HTTP请求 / RPC调用	Function Calling / MCP
架构演进方向	单体架构走向微服务	单体Agent走向多智能体协作
核心查询依赖	关系型数据库 (MySQL)	向量数据库 + 混合检索

五、写在最后

梳理了一圈下来，其实我的焦虑感少了很多。

对于后端生来说，拥抱AI并不意味着抛弃过去的知识。我们现有的数据库知识、接口设计经验、微服务架构思维，全都能完美映射到这些AI概念上。所谓的AI应用开发，其实就是咱们平常做的系统里，多引入了一个聪明但不怎么听话的“超级组件”而已。