前言

最近在准备 AI/Agent 应用开发岗的日常实习面试时，我发现自己有一个很明显的问题：我对 Agent、RAG、大模型这些方向有兴趣，也知道一些概念，但一旦真正落到“做一个能跑起来的 Agent 服务”时，很多基础并没有我想象中那么扎实。

比如这些问题，如果面试官连续追问，我未必都能答得很稳：

• 异步到底适合什么场景，为什么不能乱用？
• FastAPI 里参数校验、依赖注入、中间件分别该放什么逻辑？
• 为什么 Agent 服务里常常需要流式输出？
• 为什么长任务不能一直挂在主请求里同步执行？
• Redis 和 MySQL 在一个 Agent 服务里应该如何分工？
• Docker、Linux、Git 这些工程能力，在 AI/Agent 岗位里到底重要到什么程度？

最开始我以为，准备 AI/Agent 应用开发岗，重点应该放在 Agent 框架、RAG、Prompt、模型调用这些“更像 AI 的部分”上。后来我才慢慢意识到：对于很多像我这样的初学者来说，真正限制自己把项目做出来的，往往不是 Agent 编排，而是服务底座不够稳。

所以我决定不再零碎补知识点，而是围绕一个实际项目，分模块系统学习“Agent 服务底座”这一层。也就是先把后端工程基础补牢，再往上接 Agent、RAG 和大模型能力。

这篇文章就是我对这部分学习的第一篇总览复盘。

主要想讲清楚三件事：

• 为什么我会先补 Agent 服务底座，而不是直接冲 Agent 编排和 RAG
• 我给自己设计了一套怎样的 4 周学习框架
• 这套学习方式为什么比单纯看教程更适合面试准备和项目积累

如果你也在准备 AI/Agent 应用开发相关岗位，或者你也有“会看不会写、会写不会讲、会讲不会排错”的困扰，希望这篇文章能对你有帮助。

---

一、为什么我要先补 Agent 服务底座，而不是直接学 Agent 框架

我刚接触 AI 应用开发时，注意力主要被这些词吸引：

• Agent
• LangChain / LangGraph
• RAG
• 向量数据库
• Function Calling
• 多 Agent 协作
• Prompt 工程

这些内容当然重要，而且也确实是 AI 应用开发里非常有代表性的部分。

但如果我们把一个完整的 AI/Agent 应用看成一栋楼，那么 Agent 编排、RAG 和模型能力更像“上层业务能力”，而服务底座则更像“承重结构”。

也就是说，一个真正能落地的 Agent 服务，往往不只是“模型调得通”，它至少还要具备这些基础能力：

• 能接收 HTTP 请求
• 能做参数校验
• 能做用户鉴权
• 能支持流式输出
• 能上传和处理文件
• 能区分同步请求和异步任务
• 能记录日志、处理异常
• 能接入 Redis / MySQL
• 能部署、能排错、能解释

如果这些基础能力不稳定，那么即使会一点 Agent 框架，最后也很容易出现下面这些情况：

• Demo 能跑，但服务结构很乱
• 接口写得出来，但没有统一异常和日志
• 会调模型，但不会做流式输出和异步任务
• 能本机运行，但不会 Docker 化，也不会排查部署问题
• 看过很多概念，但很难把项目完整讲给面试官听

---

二、Agent 服务底座是什么

我把它理解为：一个 Agent 应用在真正接入复杂业务逻辑、模型编排和知识库之前，必须先具备的一套基础后端能力。

具体包括下面几类内容：

1. Python 服务基础能力

• 异步基础：async/await、协程、事件循环、阻塞与非阻塞

• 类型标注：函数签名、Optional、泛型、TypedDict、Protocol

• 数据建模：dataclass 与 Pydantic 的使用边界

• 日志：结构化日志、日志级别、请求链路标识

• 异常处理：业务异常、自定义异常、统一异常返回

• 装饰器：通用逻辑抽离、耗时统计、日志埋点

• 上下文管理：资源管理、请求上下文、request id 传递

• 基础并发：线程池、协程、IO 密集与 CPU 密集任务的差异

• 常用标准库：pathlib、typing、datetime、json、functools、contextlib、asyncio

以前我对这些内容的学习很容易停留在“知道这个东西是什么”。但在服务开发里，它们的意义完全不一样：不是知道，而是要能真正写进项目里，并理解为什么这样设计。

2. FastAPI 服务能力

如果说第一层是“会写服务代码”，那第二层就是“会搭服务接口”。

主要包括：

• 路由组织

• 依赖注入

• 请求模型与响应模型

• 参数校验

• 文件上传

• 流式输出

• 用户鉴权

• 中间件

• 生命周期管理

• OpenAPI 文档

FastAPI 在 AI/Agent 应用开发里之所以很常见，不只是因为“快”和“好用”，更因为它和类型标注、数据校验、异步编程这些能力天然契合。对于一个 Agent 服务来说，FastAPI 不只是一个框架，而是把这些能力组织起来的外壳。

3. 存储与异步任务能力

这一层开始从“接口”走向“系统”。

核心内容包括：

• MySQL 基础：表设计、索引、分页、简单查询

• Redis 基础：缓存、过期、计数器、任务状态存储

• 长任务异步化

• 任务状态管理

• 失败重试、超时控制、状态流转

• Celery 或基于 Redis 的简化异步任务模型

很多 AI 场景并不是一个 HTTP 请求里就能轻松做完的。而是前台知道要做什么之后，将任务标注为running状态放到后台运行，运行完成后再从后台获得结果，节省了等待的时间。

比如：

• 文件解析

• 知识库构建

• 长文本处理

• 批量任务执行

• 后台生成结果

这部分主要是理解：主请求该做什么，后台任务该做什么。

4. 工程交付能力

这一层常常被忽略，但在实习面试里非常重要。

包括：

• Linux 常用命令

• Git 基础工作流

• Dockerfile 编写

• Docker Compose 联调

• 服务部署

• 日志查看

• 常见故障排查

• 项目讲解与面试表达

会写代码只是第一步，能跑、能测、能部署、能排错、能讲清楚，才更接近真实工作里的工程要求。

---

三、为什么选择“项目驱动”而不是“按知识点刷教程”

在开始之前，我其实也想过最传统的学习方式：

• 找一套教程

• 按章节从前往后看

• 遇到重点记笔记

• 最后再试着做一个项目

但后来发现，这种方式很容易出现一个问题：看起来学了很多，但真正需要自己从空白文件写的时候，还是会卡住。

因为服务开发更依赖“组合能力”：

• 要把类型标注和 Pydantic 结合起来

• 要把日志、异常、中间件放在合适的位置

• 要知道什么时候该同步，什么时候该异步

• 要知道任务状态应该怎么设计

• 要知道不同模块之间如何配合

所以我实践的方式是：以一个“可运行的 Agent Backend Playground”为核心项目，把所有知识点都落到这个项目中。

这个项目不是为了做复杂业务，而是为了做一个训练型后端骨架。它的目标非常明确：做一个支持同步调用、流式输出、文件上传、异步任务、缓存与简单鉴权的 Agent 服务骨架。

这样做有几个很大的好处：

1. 每学一个点，都能立刻找到落点
2. 更容易形成完整链路意识
3. 更适合面试准备

很多面试问题表面看是在问知识点，实际上是在问：你有没有把这个知识点放进一个真实项目里用过？

比如：

• 为什么流式输出适合 LLM 场景？

• Redis 和 MySQL 如何分工？

• 为什么长任务不能同步做完？

• 中间件和依赖注入分别适合做什么？

• Docker 化之后服务起不来你怎么查？

如果你是围绕项目学的，这些问题就更容易讲得具体、自然，也更有说服力。

---

四、我的项目目标：不是先做聪明的 Agent，而是先做稳的服务

在这次学习里，我给自己设定的项目目标，不是立刻做一个复杂的 Agent 系统，而是先做一个稳固、可扩展的后端服务骨架。

这个项目我暂时把它理解成一个训练型的 Agent Backend Playground。

它在第一阶段的定位是：

• 不追求复杂业务
• 不急着接真实大模型
• 先用 mock agent 或规则 agent 占位
• 重点训练服务底座能力
• 给后续接入 Agent 编排、RAG 和模型推理预留扩展空间

所以我这次项目的第一阶段，只要求它具备这些核心能力：

• GET /health：健康检查
• POST /chat：普通请求响应
• POST /chat/stream：流式输出
• POST /files/upload：文件上传
• POST /tasks/chat 或类似接口：提交异步任务
• GET /tasks/{id}：查询任务状态
• 简单鉴权：API Key 或 Bearer Token
• 统一日志与异常处理
• Redis / MySQL 的基础接入
• Docker 化部署与本地 compose 联调

---

五、我的学习框架是怎么设计的

在明确项目目标之后，我把这部分学习拆成了 4 部分。

part1：Python 服务基础强化

这一部分的目标是把“会看懂”升级成“能写出规范服务代码”。

重点内容包括：

• 异步基础：理解协程、事件循环、阻塞调用
• 类型标注：让 service 层和接口层的边界更清楚
• dataclass 与 Pydantic 的区别和边界
• 结构化日志
• 统一异常处理
• 装饰器与上下文管理
• 基础并发认知
• 常用标准库在服务开发中的实际使用

这一部分我希望自己最终能做到的，不是“知道这些东西”，而是：

• 写出一个带类型标注的 service 函数
• 说清 dataclass 和 Pydantic 的差别
• 能解释统一异常处理为什么比到处 try/except 更好
• 能说明阻塞操作错误地放进异步接口会有什么后果

part2：FastAPI 核心能力

这一部分的目标是：常见接口场景，我能自己从零搭出来。

重点内容包括：

• 路由组织
• 请求参数与响应结构设计
• Pydantic 参数校验
• 文件上传
• 流式输出
• 用户鉴权
• 中间件
• 生命周期管理
• OpenAPI 文档

这部分最关键的变化，其实是把第一周那些“底层能力”开始真正组织成一个 HTTP 服务。

比如：

• 类型标注和 Pydantic 结合起来，变成清晰的请求模型
• 异常处理和中间件结合起来，形成规范的接口链路
• 异步编程和流式输出结合起来，形成更贴近 LLM 场景的交互方式

这一部分完成后，希望自己至少能把这些讲清楚：

• 为什么参数校验更适合交给 Pydantic
• 中间件和依赖注入分别适合放什么逻辑
• 为什么流式输出适合大模型类场景
• 一次请求从进入接口到返回结果，中间经历了哪些层次

part3：Redis / MySQL / 异步任务

这部分开始从“接口开发”走向“系统设计”。

核心内容包括：

• MySQL 基础建模与查询
• Redis 的缓存与状态存储
• 为什么长任务不能一直挂在请求里同步完成
• 任务状态的设计与流转
• 失败、重试、超时这些概念
• Celery 或简化异步任务模型

我会更倾向于先做一版基于 Redis 的简化任务模型，至少把这些状态真正跑通：

• queued
• running
• success
• failed

part4：Docker / Linux / Git / 排错与面试包装

这部分的目标，是把前面写出来的东西真正变成一个可交付产品。

主要内容包括：

• Dockerfile 编写
• Docker Compose 联调
• Linux 常用命令
• Git 基础工作流
• 服务日志查看
• 常见故障排查
• 项目讲述与面试表达

---

六、这些模块之间到底是怎么联动的

在复盘这套学习框架的时候，我觉得有一个特别重要的点必须讲清楚：Agent 服务底座不是几个技术点的清单，而是一条完整请求链路的协作系统。

如果从一次请求的视角看，它的联动逻辑大概是这样的：

1. 用户发起请求

2. FastAPI 路由接收请求

3. Pydantic 对参数做校验

4. 鉴权逻辑检查当前请求是否合法

5. 中间件记录日志、trace id、请求耗时

6. service 层开始处理业务逻辑

7. 如果是普通请求，直接返回结果

8. 如果是长任务，生成任务 ID 并进入后台执行

9. Redis 记录任务状态

10. MySQL 存储长期需要保留的数据

11. 统一异常处理把错误包装成规范响应

12. Docker / Linux / 日志系统保证服务可部署、可排查

一个项目只有在能部署、能复现、能定位问题时，才真正具备工程价值。Agent 服务底座，不是学几种技术，而是学会如何把一个 AI 能力包装成一个真实可用、可维护、可扩展的后端服务。

---

七、这套学习框架对面试准备有什么意义

从面试准备的角度看，我觉得这 4 部分的服务底座学习，至少能带来下面几个方面的提升。

1. 能把“会一点 AI”变成“会做一个 AI 服务”

这两者差别很大，前者更像是知道概念，后者更像是能把能力封装成一个真实产品形态。

2. 能讲出更完整的项目故事

很多时候，面试官并不只关心你调过什么模型，更关心：

• 你这个服务怎么设计的？
• 为什么要这么拆？
• 请求链路是怎样的？
• 出问题你怎么查？

3. 能建立更扎实的工程感

这会直接影响后面学习 Agent、RAG 和大模型能力的效率。因为底层服务一旦清楚了，后续新增能力时，你更多是在往现有系统里接功能，而不是一边学新能力一边补基础漏洞。

4. 更容易把学习沉淀成作品

一套有项目、有分周目标、有接口、有存储、有部署、有文档的学习过程，本身就很适合沉淀成：

• 博客文章
• 项目仓库
• 面试讲解材料
• 后续扩展的基础工程

---

八、计划

在完成这篇总览之后，我接下来会继续把这 4 部分内容拆成更细的系列文章，分别展开写。

计划大致是：

• 第 1 篇：Python 服务基础怎么补，才能真正支撑 Agent 服务开发

• 第 2 篇：如何用 FastAPI 搭一个最小可用的 Agent 服务骨架

• 第 3 篇：Redis、MySQL 与异步任务在 Agent 服务里如何协作

• 第 4 篇：Docker、Linux、Git 与工程交付能力为什么也属于服务底座的一部分

我希望最后整理出来的，不只是我学过什么，而是一套自己以后还能反复回看、也能讲给别人听的工程化学习路径。