很多前端同学看到 RAG、Tool Calling、MCP、LangGraph 这串名词，第一反应是"是不是要推倒重来"。结论先放这里：不用推倒重来，但你确实要补后端、模型机制和 Agent 运行时的课。做过的 API 对接、异步调度、状态管理、SSE 推流、工程化建设，放到 Agent 系统里几乎一一对应——这份存量恰恰是多数纯算法背景的人缺的东西。
先分清：接了知识库不等于做了 Agent
最小的大模型应用就是一条直线：收输入、调模型、吐结果。加了向量库做问答，本质还是"检索—生成"的固定链路，叫 RAG 应用更准确。
Agent 的特征是系统自己参与决策。拿企业差旅问答举例：收到"下周去上海出差能订什么标准的酒店"，系统要先识别意图，查最新差旅制度，再调员工信息工具确认职级和常驻地，匹配制度版本；信息不够就反问出差日期；最后汇总规定、标注出处，用户要下单时再切预订流程。每一步做什么，取决于上一步拿回来的结果——这种动态路径才是 Agent。
一句话概括分工：LLM 提供概率性的理解与决策，传统代码守住工具执行、权限边界、状态管理和可靠性。模型会犯错，所以工程约束永远是第一公民。
能力迁移地图：前端存量对上 Agent 需求
| 前端已有能力 | 在 Agent 系统里的落点 |
|---|---|
| API 调用与鉴权 | 模型、向量库、MCP Server、业务工具接入 |
| Promise/异步任务 | 并行检索、批量工具执行、任务编排 |
| 状态管理 | 消息、计划、步骤、工具结果的统一建模 |
| SSE/WebSocket | Token、步骤、日志、审批事件的实时推送 |
| Reducer/事件驱动 | 把 Agent 事件流还原成可预测的界面状态 |
| 工程化 | 配置、测试、日志、监控、灰度与回滚 |
这张表说明的不是"完全等同"，而是你已经有理解这些问题的工程直觉。
三个新手上手就踩的坑
坑一：忘了把工具结果写回上下文。 手写最小 Agent Loop 时最常见的事故：模型发起工具调用，程序执行完直接把结果返回给用户，没有 append 回 messages。下一轮模型看不到结果，要么重新发起同样的调用进入死循环，要么开始编造结果。判断标准很简单——每一轮对话里，工具结果必须以 tool 消息形式存在于后续上下文中，并且用 tool_call_id 对齐。
坑二：所有任务都上 Agent。 步骤固定、输入边界清晰的任务（比如固定格式的报表生成、定时摘要），用普通代码或固定 Workflow 更好测试、更好回滚。Agent 的动态性是能力也是风险，只有路径确实无法预先枚举时才值得引入。高风险操作（删数据、对外发送、支付）无论哪种形态都要留人工确认。
坑三：只验"能跑"，不验"稳定"。 演示跑通和上生产隔着一整个工程层。验收至少要包含：超时与重试策略、工具白名单、最大步数与预算熔断、失败降级路径，以及一套固定测试集做回归——Prompt 或模型一改，跑一遍测试集对比成功率，这才是可重复的质量判断。
四阶段路径：从最小闭环到生产服务
第一阶段，用熟悉的栈跑通模型应用。 TypeScript/Node.js 直接调模型 API，理解消息结构、上下文窗口和流式输出，处理超时与加载态；API Key 必须走服务端代理，不要落进浏览器。
第二阶段，手写 Agent Loop。 覆盖工具描述与参数 Schema、白名单校验、结果回传、停止条件、调用日志。能独立解释"请求谁发起、工具谁执行、结果为何写回"，才算真懂了 Loop，而不是会调框架。
第三阶段，加知识与工作流。 文档解析、分块、检索与重排，来源引用与权限过滤；State、分支、循环、检查点。长任务要能暂停等人工输入再恢复——恢复的前提是状态持久化加节点幂等，防止副作用重复执行。
第四阶段，进工程化。 评测、Tracing、权限与审计、缓存与成本预算、灰度发布。Prompt 很重要，但 Prompt 替代不了权限系统、监控和故障恢复。
补齐清单与边界
必须补的：服务端基础（鉴权、任务队列、并发模型）、LLM 应用基础（结构化输出、Token 成本、采样参数）、Agent Loop 机制、RAG 全链路、安全与评测。Node.js 可以是第一站，Python 生态补齐看项目方向。
底层链路的变化也要看清楚：以前是"用户操作 → API → 状态 → 渲染"，现在是"目标 → 模型决策 → 工具执行 → 状态更新 → 事件流 → Agent UI"。新增的只是一个会参与决策的概率组件，工程底座不变。转型不是换语言，是把边界扩到模型、后端和智能体产品设计。
评论0