前端转 AI Agent 工程师，别只补 LLM：后端、RAG、权限和队列才是硬骨头

前端工程师转 AI Agent，最容易掉进一个坑：以为补一轮 Prompt、学会调 OpenAI API、弄懂几个 Agent 框架，就算入门了。

这只能算摸到门把手。真正把 Agent 跑进业务里，硬骨头在后面：HTTP、鉴权、任务队列、数据库、向量检索、日志、权限边界、失败重试。模型负责“想”，系统负责“能不能安全地做完”。

先把 LLM 放回它该在的位置

LLM 很强，但它不是系统本身。它本质上是在上下文里根据概率生成下一个 token。它能理解意图、生成计划、写代码、解释文档，但也有知识截止、幻觉、算错、长上下文衰减这些老毛病。

所以 Agent 工程不是“相信模型”，而是给模型配一套工作现场：

需要事实时，用 RAG 从可信知识库取证据。
需要重复流程时，用 Skill 固化标准动作。
需要调用系统时，用 API、CLI 或 MCP 暴露工具。
需要长任务时，用队列、状态机和日志兜住执行过程。

一句话：LLM 是大脑，但后端系统才是骨架。

前端优势还在，但要往后接一层

前端工程师转 Agent 有天然优势。你熟悉用户交互，知道状态如何流动，也懂产品体验里哪些地方不能卡死。但 Agent 场景会把“按钮点击”拉长成“多步骤任务”。

普通前端交互是：用户点一下 → 请求一次接口 → 页面更新。

Agent 交互更像：用户给一个目标 → 系统拆任务 → 多轮调用工具 → 中间可能失败 → 需要恢复、暂停、审批、重试 → 最后给出结果。

这就要求你补上后端基本功。

第一块：HTTP 和 REST 不能只会调用

前端常见视角是“接口给我什么”。Agent 工程里，你要站在服务端想：接口是否幂等，失败能否重试，权限怎么校验，返回给模型的字段是否过多。

一个给 Agent 用的接口，最好明确到这种程度：

POST /api/tasks
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

{
  "goal": "生成本周客户流失报告",
  "dryRun": true
}

注意 `dryRun`。Agent 第一次执行危险动作时，不应该直接改数据库、发邮件、删文件。先试跑、预览、人工确认，这才是生产系统的味儿。

第二块：Node/Express 只是入口，状态管理才关键

写一个 Express 接口不难：

import express from 'express';

const app = express();
app.use(express.json());

app.post('/api/agent/run', async (req, res) => {
  const { goal } = req.body;
  if (!goal) return res.status(400).json({ error: 'goal is required' });

  const task = await createAgentTask({ goal, status: 'queued' });
  res.json({ taskId: task.id, status: task.status });
});

难的是不要在这个接口里同步跑完整个 Agent。复杂任务可能跑几分钟甚至几小时，HTTP 请求撑不住。正确做法是立刻返回 `taskId`，后面交给任务队列和状态表。

第三块：数据库要同时存业务和执行轨迹

Agent 系统至少需要几类表：任务表、工具调用记录、用户授权、知识库索引、审计日志。

PostgreSQL + Prisma 是前端转后端比较舒服的组合，够稳定，也不至于一上来被 ORM 复杂度劝退。向量数据库则用来做 RAG：小项目可以从 pgvector 开始，复杂场景再考虑 Milvus、Qdrant、Weaviate 这类专门方案。

关键不是“用哪个库”，而是别把所有东西都塞进 prompt。能结构化存，就结构化存；能检索，就按需检索。

第四块：认证、安全和权限要提前设计

Agent 一旦能调用工具，就可能造成真实后果。这里不能靠“模型会乖”。

最少要做这几件事：

API Key、OAuth token 不进入前端包，不进入公开日志。
工具按权限分级：只读、可写、危险操作分开。
关键动作需要审批：发邮件、付款、删数据、改权限。
所有工具调用都留审计记录。
传给模型的数据做最小化，别把整库都丢进去。

示例里密钥只能写占位符：

export OPENAI_API_KEY="YOUR_API_KEY"
export DATABASE_URL="postgresql://user:password@localhost:5432/agent_app"

真实密钥走环境变量或密钥管理，别进仓库。

第五块：队列、WebSocket 和观测，是长任务三件套

Agent 任务不能只靠一次请求。推荐结构是：

用户提交目标
  ↓
API 创建 task
  ↓
BullMQ / RabbitMQ / Temporal 执行
  ↓
工具调用日志持续写入数据库
  ↓
WebSocket / SSE 推送进度
  ↓
用户审批或查看最终结果

BullMQ 上手快，适合 Node 项目；Temporal 更重，但适合复杂工作流。WebSocket 或 SSE 用来给前端实时反馈，不然用户只能看一个转圈动画，迟早怀疑系统卡死。

观测也要从第一天加进去：请求耗时、LLM token、工具失败率、队列积压、单任务成本、人工审批次数。没有观测，Agent 失败时你连锅在哪都不知道。

一条更实际的学习路线

别把路线排成“先学完所有后端再碰 Agent”。可以按四周推进。

第一周，补 HTTP、REST、鉴权、Express，把任务提交和状态查询跑通。

第二周，接 PostgreSQL/Prisma，设计 task、tool_call、audit_log 三张表。

第三周，加队列和 WebSocket，把长任务改成异步执行。

第四周，再接 LLM、RAG 和 Skill，把模型放进受控工作流里。

做到这一步，你就不只是“会调用大模型”的前端，而是在搭一个能被模型驱动、能被人类审计、能在失败后恢复的 Agent 系统。

AI Agent 工程师不是换个 API 调用姿势。它是把模型、后端、权限、数据和前端体验接成一条链。前端经验不会浪费，但得往后端深水区多走几步。