大家好，我是阿浪
上周和一个前端老友吃饭，他兴奋地说要转 AI Agent 开发，已经报了 Python 速成班，还收藏了一堆 LangChain 教程。我问他：“你现在写的 Node 服务，能扛住每秒 100 个请求吗？数据库慢查询怎么抓？线上 CPU 飙升了往哪儿看？”他愣了半天，回我一句：“这些不是运维的事吗？”
我差点把奶茶喷出来。
这不是个例。这两年“AI Agent”火得发烫，前端圈里十个人有八个想转型，但大部分人一上来就扑进 Python 和提示词工程，结果写出来的 demo 跑得欢，一上线就各种超时、重复消费、数据错乱——最后还得后端老哥擦屁股。
今天我不打算给你讲大模型原理，也不谈 Agent 框架。我想聊点实在的：作为一个写了五年 React 的前端，我是怎么把后端这堵墙一点点撞碎的。全程带代码，不整虚的。
第一阶段：别换语言，先把你手里的武器磨利
很多前端转后端的第一反应是“我要学 Java/Go/Python”，其实大可不必。你用 TypeScript 写的服务，只要把 Event Loop、Stream、Buffer 这些老熟人重新理解一遍，完全可以撑起一个中小型 AI 应用的 BFF 层。
我给自己定的第一个任务是：用 Express 搭一个能注册、登录、发帖子的极简社区后端——不复杂，但必须包含完整的请求生命周期。
// app.js —— 入口即战场
const express = require('express');
const jwt = require('jsonwebtoken');
const bcrypt = require('bcryptjs');
const { body, validationResult } = require('express-validator');
const app = express();
app.use(express.json());// 模拟数据库（内存版，仅用于学习）
const users = [];
const posts = [];// 注册 —— 密码要哈希，这是底线
app.post('/register',body('username').isLength({ min: 3 }),body('password').isLength({ min: 6 }),async (req, res) => {const errors = validationResult(req);if (!errors.isEmpty()) return res.status(400).json({ errors: errors.array() });const { username, password } = req.body;if (users.find(u => u.username === username)) {return res.status(409).json({ message: '用户名已存在' });}const hashed = await bcrypt.hash(password, 10);users.push({ id: users.length + 1, username, password: hashed });res.json({ message: '注册成功' });}
);// 登录 —— 返回JWT，以后每个请求都带着它
app.post('/login', async (req, res) => {const { username, password } = req.body;const user = users.find(u => u.username === username);if (!user || !(await bcrypt.compare(password, user.password))) {return res.status(401).json({ message: '用户名或密码错误' });}const token = jwt.sign({ id: user.id, username }, 'my_secret_key', { expiresIn: '1h' });res.json({ token });
});// 鉴权中间件 —— 这是后端的“门卫”
function authenticate(req, res, next) {const authHeader = req.headers.authorization;if (!authHeader) return res.status(401).json({ message: '未携带token' });const token = authHeader.split(' ')[1];try {const decoded = jwt.verify(token, 'my_secret_key');req.user = decoded;next();} catch (err) {res.status(403).json({ message: 'token无效或过期' });}
}// 发帖 —— 只有登录用户才能操作
app.post('/posts', authenticate,body('title').notEmpty(),body('content').notEmpty(),(req, res) => {const errors = validationResult(req);if (!errors.isEmpty()) return res.status(400).json({ errors: errors.array() });const { title, content } = req.body;const newPost = {id: posts.length + 1,title,content,author: req.user.username,createdAt: new Date().toISOString()};posts.push(newPost);res.json(newPost);}
);// 获取帖子列表 —— 公开数据，但也要做分页
app.get('/posts', (req, res) => {const page = parseInt(req.query.page) || 1;const limit = parseInt(req.query.limit) || 10;const start = (page - 1) * limit;const end = start + limit;res.json({data: posts.slice(start, end),total: posts.length,page,limit});
});// 统一错误处理 —— 别让报错裸奔
app.use((err, req, res, next) => {console.error(err.stack);res.status(500).json({ message: '服务器内部错误' });
});const PORT = 3000;
app.listen(PORT, () => console.log(`服务运行在 http://localhost:${PORT}`));
刚开始学的这段代码我跑了整整跑了两天，反复折腾中间件顺序、异步异常捕获、JWT 过期刷新。收获不是学会几个 npm 包，而是真正理解了一个请求从 HTTP 解析到业务处理再到序列化返回的完整链路。 这个基础不牢，后面接什么 AI 接口都是空中楼阁。
第二阶段：数据是服务的灵魂，别把 ORM 当护身符
前端玩状态管理（Redux/MobX）那套理念，放到数据库里其实是相通的——只不过状态变成了持久化的，而且并发冲突会打得你措手不及。
我踩过最大的坑是把 Prisma 当成数据库的代言人，写了个复杂的嵌套查询，结果生产环境 CPU 飙到 80%，一查 SQL 日志才发现生成了几十条关联查询。从那以后，我养成了两个习惯：
- 每个复杂查询都先写原生 SQL，再用 ORM 实现，对比执行计划。
- 用 Redis 做查询缓存，但绝不缓存写操作。
下面是我在一个 AI 问答项目中用的缓存方案（配合 PostgreSQL）：
// 使用ioredis做缓存装饰器
const Redis = require('ioredis');
const redis = new Redis({ host: 'localhost', port: 6379 });async function getCachedOrFetch(key, fetchFn, ttl = 60) {const cached = await redis.get(key);if (cached) {console.log(`[Cache] Hit for ${key}`);return JSON.parse(cached);}console.log(`[Cache] Miss for ${key}, fetching...`);const data = await fetchFn();await redis.setex(key, ttl, JSON.stringify(data));return data;
}// 查询帖子详情（带作者信息）
async function getPostDetail(postId) {return getCachedOrFetch(`post:${postId}`,async () => {// 模拟数据库查询 —— 实际项目这里会用prisma或knexconst post = posts.find(p => p.id === postId);if (!post) throw new Error('帖子不存在');// 假设作者信息需要从另一个表关联const author = users.find(u => u.username === post.author);return { ...post, authorInfo: { username: author.username } };},30 // 30秒过期);
}// 更新帖子时一定要删除缓存，否则会读到旧数据
async function updatePost(postId, newContent) {// 更新数据库逻辑...await redis.del(`post:${postId}`); // 失效缓存
}
这里我想多啰嗦一句：缓存失效策略永远比缓存命中策略难十倍。我见过太多项目因为忘记在写入时清理缓存，导致页面展示脏数据，排查时还以为是数据库问题。所以我的原则是：宁可少缓存，不错缓存。
第三阶段：把“能跑”升级为“能救”
前端同学最容易忽略的是可观测性。写页面的时候，用户报 Bug 大不了让重试，但后端服务一出问题，影响的可能是一整片用户。我花了整整两个月才把这三板斧练熟：
1. 结构化日志（别再用 console.log 了）
const pino = require('pino');
const logger = pino({level: process.env.LOG_LEVEL || 'info',transport: {target: 'pino-pretty', // 开发环境看得舒服options: { colorize: true }}
});// 在每个请求中绑定traceId
app.use((req, res, next) => {req.logger = logger.child({ traceId: req.headers['x-request-id'] || Math.random().toString(36) });next();
});// 业务中打日志
app.get('/posts', (req, res) => {req.logger.info({ query: req.query }, 'Fetching posts');// ...
});
有了 traceId，整个请求链的日志就能串起来了，排查问题时不用大海捞针。
2. 健康检查和优雅停机
AI 应用经常依赖外部模型 API，一旦外部服务超时，你的服务也得跟着炸。所以我给每个服务都加了 /health 端点，并让 K8s 定期探活。
// 健康检查：不仅要返回200，还要检查依赖（数据库、Redis、外部API）
app.get('/health', async (req, res) => {const checks = {database: await checkDb(),redis: await checkRedis(),llm: await checkLlmEndpoint()};const allOk = Object.values(checks).every(v => v === true);res.status(allOk ? 200 : 503).json({ status: allOk ? 'up' : 'degraded', checks });
});async function checkLlmEndpoint() {// 发送一个轻量级ping请求，超时设置2秒try {await fetch('https://api.example.com/ping', { timeout: 2000 });return true;} catch {return false;}
}
3. 简单但有效的限流
AI 接口收费不菲，如果不限流，一个恶意用户就能刷爆你的额度。我用 express-rate-limit 给每个 API 都设了阈值：
const rateLimit = require('express-rate-limit');const limiter = rateLimit({windowMs: 60 * 1000, // 1分钟max: 100, // 最多100次message: { message: '请求过于频繁，请稍后再试' },standardHeaders: true,legacyHeaders: false,
});// 只对生成类接口启用严格限流
app.post('/ai/chat', authenticate, limiter, async (req, res) => {// 调用大模型...
});
第四阶段：把 AI 当特殊的外包服务来对接
终于到了 AI 部分。我现在的认知是：AI Agent 本质上是一个重度依赖外部 API 的业务系统，只不过输入输出变成了自然语言，还多了流式、工具调用这些花活。
核心要处理几个事：
1. 流式输出（SSE）—— 让用户感觉到“在思考”
app.post('/ai/stream', authenticate, async (req, res) => {const { prompt } = req.body;// 设置SSE头res.setHeader('Content-Type', 'text/event-stream');res.setHeader('Cache-Control', 'no-cache');res.setHeader('Connection', 'keep-alive');const stream = await callLLMStream(prompt); // 假设返回一个异步可迭代流for await (const chunk of stream) {res.write(`data: ${JSON.stringify({ token: chunk })}\n\n`);}res.write('data: [DONE]\n\n');res.end();
});
前端只需用 EventSource 或 fetch 读取流，就能实现打字机效果。
2. 超时和重试 —— 外部 API 从不靠谱
我给大模型调用封装了一层带指数退避的 retry：
async function callLLMWithRetry(messages, maxRetries = 3) {let attempt = 0;while (attempt < maxRetries) {try {const response = await fetch(process.env.LLM_ENDPOINT, {method: 'POST',headers: { 'Authorization': `Bearer ${process.env.LLM_KEY}` },body: JSON.stringify({ messages, temperature: 0.7 }),signal: AbortSignal.timeout(15000) // 15秒超时});return await response.json();} catch (err) {attempt++;if (attempt >= maxRetries) throw err;const wait = Math.pow(2, attempt) * 1000; // 2s, 4s, 8sconsole.warn(`LLM调用失败，${wait}ms后重试 (${attempt}/${maxRetries})`);await new Promise(resolve => setTimeout(resolve, wait));}}
}
3. RAG 检索的工程落地
前端做搜索可能只关心关键词匹配，但 RAG 要求先向量化再检索。我这边用的是一个轻量方案：把文档切片后存在 PostgreSQL 的 pgvector 扩展里，每次查询先做向量相似度搜索，再交给大模型生成答案。
这部分代码不复杂，但性能调优非常磨人——索引怎么建、批量插入如何提速、结果如何重排序，每个环节都能写一篇。我现在的做法是：先用 Embedding 模型离线生成好向量，存库，查询时只做相似度计算，避免在线调用 embedding API 增加延迟。
最后，说点真心话
这条路我走了大半年，回头看不后悔。前端工程师的优势从来不是语法或框架，而是对用户体验的敏感和组件化的抽象能力——这些在后端同样奏效，只不过要换一套语境。
但有一件事我越来越笃定：不要为了追风口而学 AI，要为了解决问题而学后端。当你真正把一个带用户认证、缓存、限流、日志、健康检查、流式输出的 AI 应用部署到云上，看着它稳定运行一周不出错，那种踏实感比调出一个完美 prompt 强十倍。
如果你也在转型的路上，不妨从今天开始，把上面的代码复制下来，跑一遍，然后试着给它加上一个“管理员删除帖子”的接口，加上权限校验，再加上审计日志——做完这些，你就已经超过了 80% 的“速成 AI 工程师”。