NestJS + LangChain：让你的AI接口像服务员那样优雅

从“后端搬砖”到“AI掌勺”

还记得我第一次用Node.js写后端的时候，那叫一个随心所欲。路由随便写，逻辑到处放，数据库查询和业务代码纠缠在一起，像极了大学宿舍的网线——看着能用，但谁动谁崩溃。直到遇见了NestJS，我才恍然大悟：原来后端代码可以写得像五星级酒店的后厨一样，各司其职，井井有条。

而最近，当AI大模型像洪水猛兽般涌入开发领域时，我又面临着新的挑战——如何让这些“聪明但脾气古怪”的AI模型，在后端服务中乖乖听话，既稳定又高效地提供服务？答案就是：NestJS + LangChain。

NestJS：不只是另一个Node框架

很多人问我：“Express它不香吗？为什么要用NestJS？”这个问题就像问“自行车不也能代步吗，为什么要买汽车？”一样。Express是轻量级、灵活的，但当你需要构建一个真正的大型企业级应用时，你会发现它的“自由”反而成了负担。

NestJS基于TypeScript构建，底层虽然默认使用Express（你也可以换成Fastify），但它真正强大的是带来了后端开发中久经考验的设计模式：

依赖注入（DI） 可能是NestJS最迷人的特性之一。在传统的Express应用中，你需要在各个文件之间手动传递依赖，就像在一个没有快递系统的城市里，你要亲自把包裹送到每个人手上。而在NestJS中，你只需要在构造函数里声明你需要什么，框架就会像魔法一样把实例送到你面前：

@Injectable()export class AiService {constructor(@Inject(ConfigService) private configService: ConfigService,private someOtherService: OtherService) {}// 直接使用，无需关心如何创建}

装饰器模式则让代码的可读性和复用性达到了新高度。想给某个接口加上权限验证？一个@UseGuards(AuthGuard)搞定。想实现请求日志？一个@UseInterceptors(LoggingInterceptor)完事。这种通过注解来“增强”类或方法的能力，让代码的意图一目了然。

模块化架构更是NestJS的企业级基因。每个功能都被封装在独立的Module中，Controller负责接收请求，Service处理业务逻辑，Module则像胶水一样把它们粘合起来，同时管理着依赖关系。这种清晰的边界，让大型团队协作变得异常顺畅。

AI服务接入的“优雅姿势”

当我们决定在NestJS中接入AI能力时，LangChain自然成为了首选。但问题来了：如何让AI服务既保持灵活性，又不破坏我们精心设计的架构？

看一段我实际项目中的代码：

@Injectable()export class AiService {private readonly chain: Runnable;constructor(@Inject(ConfigService) configService: ConfigService) {const prompt = PromptTemplate.fromTemplate(`请回答以下问题: nn{query}`);const model = new ChatOpenAI({temperature: 0.7,modelName: configService.get('MODEL_NAME'),apiKey: configService.get('OPENAI_API_KEY'),configuration: {baseURL: configService.get('OPENAI_BASE_URL')}});this.chain = prompt.pipe(model).pipe(new StringOutputParser());}async runChain(query: string): Promise<string> {return this.chain.invoke({query});}}

这里的设计有几个精妙之处：

配置与代码分离：所有的API密钥、模型名称、BaseURL都通过ConfigService从环境变量中读取。这意味着同一个代码可以轻松部署到开发、测试、生产环境，而无需修改任何代码。

链式调用的优雅封装：LangChain的pipe方法让我们可以像组装水管一样，把提示词模板、模型、输出解析器串联起来。这种声明式的编程风格，让复杂的AI调用逻辑变得清晰易懂。

依赖注入的无缝集成：AiService本身就是一个可被注入的Provider，它可以在任何Controller或其他Service中被使用，完全融入NestJS的生态系统。

Controller层的轻量设计

在NestJS的哲学中，Controller应该尽量轻量——只负责接收请求、参数校验、调用Service、返回响应。真正的业务逻辑都在Service中完成：

@Controller('ai')export class AiController {constructor(private readonly aiService: AiService) {}@Get('chat')async chat(@Query('query') query: string) {const answer = await this.aiService.runChain(query);return { answer };}}

这个Controller只做了三件事：接收GET请求、提取query参数、调用Service并返回结果。没有复杂的逻辑，没有直接操作外部API的代码，一切都交由Service处理。

超越REST：流式响应的优雅实现

但传统的RESTful API对于AI应用来说有个天然缺陷——AI模型生成回复需要时间，如果让前端傻等几秒钟才收到完整响应，用户体验会非常糟糕。这时候，SSE（Server-Sent Events）就成了更好的选择。

SSE允许服务端向客户端持续推送数据流，非常适合AI对话场景。想象一下：用户问了一个问题，AI的回复像打字机一样一个字一个字地出现在屏幕上，这种实时反馈的体验远比等待完整回答要舒适得多。

在NestJS中实现SSE同样优雅：

@Sse('chat-stream')async chatStream(@Query('query') query: string): Promise<Observable<MessageEvent>> {// 返回一个Observable，流式输出AI的回复}

配合前端的EventSource API，几行代码就能实现流畅的流式对话体验。我在测试页面中放了一个简单的HTML+JS实现，用EventSource监听服务端推送的消息，实时更新在页面上，效果丝滑。

环境配置与静态资源

NestJS的ConfigModule让环境变量管理变得异常简单：

@Module({imports: [ConfigModule.forRoot({isGlobal: true,envFilePath: '.env'}),// ...]})

isGlobal: true意味着这个配置模块在所有子模块中都是可用的，不需要重复导入。而envFilePath则指定了环境变量文件的路径，方便在不同环境中使用不同的配置文件。

对于前端测试页面这类静态资源，NestJS也能轻松应对：

ServeStaticModule.forRoot({rootPath: './public'})

一行代码就能让/public目录下的所有文件都对外提供服务，非常适合我们这种需要测试页面的场景。

总结：当架构之美遇见AI之力

NestJS + LangChain的组合，让我看到了后端开发的一种理想状态：清晰的架构设计让代码易于维护、测试和扩展，而强大的AI能力则让应用能够完成传统编程难以企及的任务。

对于那些还在Express和NestJS之间犹豫不决的开发者，我想说：如果你只是写个小Demo或者内部工具，Express完全够用。但如果你打算构建一个真正面向用户、持续迭代的产品级应用，NestJS的架构优势会让你在项目规模和复杂度增长时，依然保持从容不迫。

而对于已经选择了NestJS的开发者，不妨尝试将LangChain这样的AI能力融入到你的服务中。未来的应用，或多或少都会与AI产生交集。用优雅的架构承载AI的无限可能，这正是我们这一代开发者面临的机遇和挑战。

就像我在项目中反复体会到的：好的代码结构不仅让开发更高效，更能让你在面对新技术时，有着足够的灵活性和稳定性去拥抱变化。NestJS就是这样一个让“拥抱变化”成为现实的好伙伴。