021. 前端收尾与 LangServe 后端入口

学习目标

这一节结束前端准备工作，并开始进入后端模型服务部分，重点介绍 LangServe、接口文档、代理和模型调用入口。

学完后，你应该能理解：

• 前端基础工作完成后，为什么要切到后端工程；
• LangServe 主要解决什么问题；
• 为什么课程选择基于 FastAPI 自己部署；
• Swagger UI 在接口调试中有什么作用；
• Playground 为什么只是辅助能力；
• 模型服务代理为什么要进入后端架构。

前端准备工作收尾

这一节一开始先处理前端遗留内容。

包括：

• 去掉不再需要的 mock；
• 确认字体和样式资源；
• 整理入口文件；
• 提交前端阶段代码。

前面做了大量登录、token、刷新队列、请求实例和静态资源处理。

到这里，前端基础设施基本完成。

后面前端会继续做 AI 生成简历页面，但必须先有后端模型服务支撑。

为什么开始搭后端

AI 简历生成不是纯前端功能。

前端负责交互和展示，真正调用大模型、组织工作流、代理模型接口，仍然需要后端服务。

所以课程开始进入后端工程。

这一阶段会围绕几个问题展开：

• 如何把模型调用暴露成接口；
• 如何让前端调用这些接口；
• 如何统一处理文档和调试；
• 如何为后续 LangGraph 工作流做准备。

LangServe 的作用

LangServe 可以把 LangChain / LangGraph 里的 runnable 对象部署成接口。

它通常会提供几类能力：

• invoke 调用；
• batch 批量调用；
• stream 流式调用；
• 接口文档；
• Playground 调试页面；
• 客户端调用方式。

你可以把它理解成“把模型能力包装成 HTTP 接口的一层服务”。

前端不直接和 Python 对象交互，而是通过 HTTP 请求访问这些能力。

为什么不用官方部署方案

LangGraph 官方有自己的部署方案，例如云服务或私有化部署。

课程没有直接使用这些方案，而是基于 FastAPI 自己封装。

原因主要有几个：

• 官方部署服务通常要付费；
• 学习阶段需要掌握底层原理；
• 自己封装更容易扩展；
• 后续要结合已有后端系统；
• 课程需要让大家理解接口是怎么来的。

这不是说官方方案不好。

而是实战项目要让你知道：一个 AI 工作流最终仍然要变成后端接口，和你的业务系统结合。

FastAPI 与 Swagger UI

FastAPI 会自动生成接口文档。

常见入口是 Swagger UI。

它可以帮助你查看：

• 当前有哪些接口；
• 每个接口的请求方法；
• 参数结构；
• 响应结构；
• 是否能直接在线调试。

对只写过 JS 的人来说，可以把 Swagger UI 当成后端接口的可视化调试台。

前端联调前，先在这里确认接口能不能跑通。

Playground 的定位

LangServe 也可能提供 Playground。

Playground 可以让你在网页上测试模型调用。

但课程里强调，它不是核心。

核心仍然是：

• 接口是否正确；
• 前端能否调用；
• 参数结构是否稳定；
• 后端能否接入真实模型和工作流。

Playground 能帮助调试，但不能替代真实业务页面。

代理文档和静态资源

后端服务里还需要处理一些代理能力。

例如把文档相关的静态资源代理出来，让接口文档和页面资源能正常加载。

如果资源路径不对，可能会出现：

• 文档页面打开但样式丢失；
• JS 文件 404；
• Playground 页面不能用；
• 前端访问接口文档异常。

这些都不是模型能力问题，而是静态资源代理和路径配置问题。

模型调用代理

课程后面提到模型调用和代理。

真实项目里前端通常不直接暴露模型平台 Key。

更常见方式是：

• 前端请求自己的后端；
• 后端读取模型配置；
• 后端调用模型平台；
• 后端把结果返回给前端。

这样可以保护 Key，也方便统一切换模型供应商。

阶段重点

这一节是前端阶段和后端模型服务阶段的交界。

前端基础设施已经完成，接下来要让后端提供模型调用、接口文档、代理和工作流部署能力。

理解这一步后，后面的 LangGraph、LangServe 和 AI 简历生成才会连成一条线。