老实说我第一次被拉着聊 Agent 开发的时候心里是发怵的。周围人嘴里蹦出来的是微调LoRAGPU 集群loss 曲线我一个写了五年前端的人第一反应就是这局跟我没关系。直到某天我用 Node.js 把一个能查天气的小助手跑出第一轮对话我才意识到自己差点被一套错误认知劝退。Agent 开发根本就不是模型训练它更像我们最熟悉的业务系统开发——只不过把 API 请求的目标从自己的后端换成了大模型。你不需要训练任何模型也不需要懂反向传播你真正要做的是把一个大模型接进你的代码流里让它按你的规则说人话、调工具、给结果。这篇文章就想跟同样是前端的朋友聊清楚这件事顺便给一条可以直接落地的上手路径。1. 把 Agent 当成模型来学前端一开始就输了1.1 学不会模型训练是最大的自我劝退我见过不少前端同学包括以前的我第一次听到 Agent 这个词就直接把自己劝退了。团队里一提要做个智能体立刻联想到的是算法同学每天在看的训练日志、GPU 利用率、数据集清洗然后下意识觉得这不是前端的活我报名也是陪跑。但真实项目里扒开看一个 Agent 产品可能有 90% 的代码是流程控制、状态管理、API 对接和异常处理剩下 10% 才跟智能沾边而那 10% 里又只有极小一部分会碰到模型训练。前端在这件事上的优势其实被严重低估了。我们每天都在做 API 集成调用后端接口、处理 loading、拼接数据、渲染结果。Agent 开发核心也是同样的操作只是把后端接口换成了大模型 API。你的模块化能力、异步处理能力、UI 交互设计能力几乎可以平移到 Agent 应用层。差别只在于以前接口返回的是固定结构现在是有时候给你一段文字有时候告诉你它想调用一个工具。所以真正拦住前端的不是技术门槛而是这个词带来的心理压迫感。如果一上来就抱着我要先学会训练模型才能做 Agent的心态相当于你要先学会炼钢才能去造汽车可实际上大多数人做的是把现成的钢材组装成汽车。Agent 开发是应用层工程不是基础模型研究这个定位认知不纠正后面的路很难走。1.2 模型训练与 Agent 开发根本不是一个赛道把这两件事并排放很多模糊的地方一下子就清楚了。我整理了一张对比表新手建议直接收藏对比维度模型训练Agent 开发工作对象模型权重、训练数据、损失函数程序逻辑、API 编排、业务规则产出物一个模型权重文件一个可运行的软件服务或产品核心技能数学、统计、分布式训练、实验设计编程、状态管理、接口设计、交互体验调试方式看损失曲线、跑评测集看日志、断点调试、模拟用户输入迭代周期以天/周为单位算力成本高以小时/天为单位重启服务即可对前端的技能复用几乎为零绝大部分能复用有些朋友会问那 Agent 里不也包含智能吗不训练怎么智能这是个特别关键的问题。Agent 里用的智能来自现成的预训练模型你直接通过 API 调用它模型的推理能力是厂商训练好的。你做 Agent相当于请了一个什么都会一点但是不会主动干活的实习生而你负责给这个实习生写工作手册、安排流程、检查成果、搭配工具。一句话总结模型训练负责造一个聪明的大脑Agent 开发负责给这个大脑配上身体、感官和一套行事准则。前端要进入的是后者别天天惦记着去造大脑。2. 拆开 Agent 的外壳它是一个会开会的程序2.1 Agent 循环就是需求会 执行会 汇报会抛开各种玄乎的术语Agent 的本体其实就是一段循环程序。它做的事情可以类比成一个项目组的开会节奏。第一步是需求理解会拿到用户的一句话Agent 把这句话连同之前聊过的内容一起发给大模型让模型拆解目标。第二步是执行会如果当前任务需要外部信息或动作模型会返回一个工具调用请求Agent 程序就去执行对应的工具比如查天气、搜网页、查数据库。第三步是汇报会把工具拿到的结果重新喂给模型模型根据结果决定是继续调用下一个工具还是给出最终答案。这个过程在代码里长这样用伪代码写出来特别简单while 没结束: 把消息历史发给大模型 模型返回内容 如果 模型想调用工具: 执行工具 把工具结果加进消息历史 否则: 返回最终回复给用户就是这么个骨架。不同的 Agent 框架再花哨核心循环也逃不出这个模式——可能多了规划、记忆、多智能体分工但底层仍然是调用模型 - 执行工具 - 把结果交回模型的反复。这个结构跟前端开发有个很微妙的对应它就像点击按钮 - 触发事件处理函数 - 调接口 - setState - 组件重新渲染。Agent 里的模型好比是逻辑复杂的状态管理器工具调用就是你的异步请求函数消息历史就是全局状态。这么一对照你会发现 Agent 不是一个天外来客它就是一个被你写过的普通程序。2.2 Agent 是一种特殊的状态机前端早有肌肉记忆如果从软件工程的角度看Agent 非常适合被建模成一个状态机。它的状态无非是 idle等待输入、running模型思考中、waiting_tool等待工具返回、finished完成外加一个 error 状态。触发状态切换的事件是用户消息、模型响应、工具结果、超时器。这些概念对前端来说太熟了我们天天跟组件的挂载、更新、卸载打交道也天天处理按钮重复点击请求竞态组件卸载后不能 setState之类的问题。Agent 开发里真正容易出 bug 的点也正是前端经验能发挥价值的地方。比如用户连续快速发两条消息前一条的 Agent 还在循环中后一条可能中断或覆盖当前状态再比如工具调用超时后模型还在等待结果这时候应该给用户一个明确的工具响应超时提示而不是让对话悄悄卡死。这些并发和竞态问题前端在浏览器环境里已经踩过无数遍处理起来会比后端同学更有直觉。还有一个容易被忽略的共性Agent 的刷新体验。前端做过表单的人都知道用户在等待接口返回时必须看到 loading 状态否则会怀疑系统坏了。Agent 里同样需要暴露中间状态——正在调用搜索工具正在分析结果——这种把过程透明化的设计恰恰是前端交互设计里最擅长的反馈优先原则。从这个角度看Agent 开发对前端不是转行更像是把以前没接完的后端逻辑往前挪到了自己的熟练区里。3. 从零做一个能查天气的 Agent前端友好的 JS 版3.1 项目目标与原材料讲再多概念都不如跑一个真实的 Agent。我建议每个前端都亲手写一遍这个查天气 Agent例子因为它足够小又能覆盖 Agent 循环最核心的部分。目标用户输入今天上海适合穿什么Agent 需要先猜出地点上海然后调用天气 API 拿到温度、天气、湿度最后结合这些数据给出穿衣建议。整个过程不需要训练任何模型也不需要微调只需要三个原材料一个支持函数调用的大模型 API、一个天气服务 API、以及你本机的 Node.js 18 以上环境。大模型 API 的 key 和地址不用我说废话你已经知道该怎么从控制台申请。天气 API 同理网上有很多免费或低成本的接口选一个返回 JSON 的就行。核心思路很简单天气接口能用普通 fetch 调模型接口也能用普通 fetch 调Agent 就是在这两个 fetch 之间加了一层判断和循环。3.2 核心代码一个能跑的最小 Agent 循环下面的代码用纯 Node.js 写不依赖任何框架。先定义模型调用函数const BASE_URL process.env.LLM_BASE_URL; const API_KEY process.env.LLM_API_KEY; const MODEL process.env.LLM_MODEL; async function callLLM(messages, tools) { const res await fetch(${BASE_URL}/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${API_KEY}, }, body: JSON.stringify({ model: MODEL, messages, tools, }), }); return res.json(); }接着定义工具列表。这里的一个关键点工具不是真的接到模型耳朵边而是把工具的名字、用途、参数结构以 JSON 形式告诉模型模型看到用户问题时如果认为需要查天气就会返回一个特殊的结构要求程序去执行get_weather并把参数传递进来const tools [ { type: function, function: { name: get_weather, description: 查询某个城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名比如上海, }, }, required: [city], }, }, }, ]; async function getWeather(city) { const url https://api.example.com/weather?city${encodeURIComponent(city)}; const res await fetch(url); const data await res.json(); return ${city}当前温度${data.temperature}℃天气${data.condition}湿度${data.humidity}%; }最关键的是 Agent 循环本身。维护一个messages数组作为对话状态循环里不断调用模型。如果模型返回的finish_reason是tool_calls就说明它想要工具执行完工具后把工具结果加到messages里再进入下一轮直到某轮模型没有返回工具调用就把content作为最终回答交还给用户async function agentLoop(userInput) { const messages [{ role: user, content: userInput }]; for (let step 0; step 5; step) { const result await callLLM(messages, tools); const choice result.choices[0]; if (choice.finish_reason tool_calls) { messages.push({ role: assistant, tool_calls: choice.message.tool_calls, }); for (const call of choice.message.tool_calls) { if (call.function.name get_weather) { const args JSON.parse(call.function.arguments); const toolResult await getWeather(args.city); messages.push({ role: tool, tool_call_id: call.id, content: toolResult, }); } } } else { return choice.message.content; } } return 步骤用完了我暂时无法回答这个问题。; } const answer await agentLoop(今天上海适合穿什么); console.log(answer);用一个 for 循环限制最大步数是很好的习惯否则模型在某些极端情况下可能不停地调用工具把你的请求预算烧穿。这个代码跑通后你就拥有了一个最小可用的 Agent。3.3 跑通这段代码后你会认清一件事第一次跑通这个例子时你会非常直观地感觉到这个 Agent 的核心逻辑里没有数学公式没有训练过程没有数据集。你做的只是维护消息数组、解析工具调用、执行外部 API、决定循环什么时候终止这套动作跟平时写点击按钮 - 调接口 - 渲染列表是一样的。如果你的大模型 API 不支持函数调用也有一个简化的做法把工具说明写进 system prompt要求模型在需要时输出一段固定格式的 JSON。比如在 system prompt 里写当用户询问天气时你必须先调用 get_weather输出格式为 {tool: get_weather, city: 上海}然后你在程序里解析这段 JSON执行工具后再把结果塞回 messages。这种方案的稳定性不如原生函数调用协议但用来理解 Agent 的原理完全够用。跑通这个例子后你已经跨过了最难的概念关Agent 不是神秘大脑它就是一段老实的业务流程代码。4. 前端做 Agent 最容易翻车的五个设计点4.1 上下文管理别把整个聊天记录无脑塞给模型前端调普通后端接口时参数一般是一次性的不会越攒越多。但大模型 API 是有状态对话的你需要把对话历史反复传给模型问题立刻就来了上下文窗口是有限的token 消耗是累加的对话稍长请求体就变得又大又贵。最简单的策略是裁剪 摘要。保留 system 消息用来锁定 Agent 人设保留最近 3 到 5 轮完整对话更早的内容交给模型生成一段摘要存进 context 里。这很像前端做日志系统的滚动窗口只不过摘要需要模型自己来写不能简单粗暴地从中间截断字符串。成本问题也要提前考虑。每次请求都会把全部历史重新发给模型相当于前端每次 setState 都把整个 store 重新提交给后端这在小 demo 里没问题上线后可就是白花花的银子了。做 Agent 时一定记得看一眼每次请求的实际 token 数有些模型平台提供了 usage 字段把它打到日志里你会对上下文膨胀这件事有非常直观的恐惧。4.2 工具调用参数校验模型也会一本正经编参数模型返回的工具调用参数是一个 JSON 字符串但它并不保证合法。它可能把城市名写成上海市ss也可能漏掉必填字段甚至调用了不存在的工具名。如果你不做校验直接把这个值扔给外部 API结果往往是 500 错误或者返回一个莫名其妙的天气。前端同学这里有个天然优势很多人用过 JSON Schema 或相关校验库。你可以对模型生成的参数执行同样的校验不合法就返回一条参数格式有误请重新生成的工具反馈让模型自纠。这比你在代码里写一堆 if 判断更优雅。记住一句话总结就是不要相信模型输出像处理用户输入一样处理模型输出。4.3 流式输出别等整个回复生成完才渲染大模型生成完整回答可能耗时很长如果用户看着白屏等十秒体验会非常糟。很多 Agent 产品都采用流式输出模型生成的 token 像打字机一样一边生成一边显示。前端在处理流式这件事上反倒有优势——我们写过 EventSource写过 WebSocket也处理过fetch的 ReadableStream。用fetch发起流式请求时需要读取 response body 的流按行解析事件把增量内容追加到聊天窗口。要注意的点有两个一是用户点击停止生成时要主动中止请求不能只是 UI 上停住而底层连接还在耗流量二是流式响应里可能出现断断续续的异常要做超时和心跳处理。前端已有的即时反馈经验在这里能直接变现。4.4 记忆与持久化会话重启后失忆很正常Agent 如果只能活在单次对话里很多实用场景就做不了比如它没法记住用户上次说过的穿衣偏好。这就要引入记忆能力。可记忆要分级别短期记忆就是当前会话上下文长期记忆需要把数据落到数据库里。前端做原型最喜欢的方案是 localStorage但在浏览器环境外Node.js 服务端跑 Agent 时可以用 JSON 文件或者轻量级数据库先对付着。真正要避免的坑是别为了长期记忆这个概念一上来就引入向量数据库、嵌入模型、相似度检索全套流程。很多场景只需要存一个用户偏好表就够了用传统数据库就解决根本不需要把句子转成向量。先搞清楚业务上到底需要记住什么再决定用多重的技术方案。4.5 失败兜底与重试策略我见过不少 Agent demo模型一调用失败整个程序就抛异常。上线后用户看到的不是我好累而是服务开小差了。做 Agent 应用一定要把模型调用当成最不可靠的第三方依赖来对待。建议做三层兜底第一层是请求重试遇到网络抖动或限流时用指数退避重试两次第二层是超时总闸单个模型请求超过 30 秒就放弃不能无限等第三层是话术兜底所有失败情况要有面向用户的友好提示。给用户看到明确的错误状态和下一步操作比盲目重试更有效。这些容错设计恰好是前端做请求封装时最熟悉的那套东西。5. 给前端的 Agent 入门路线哪些必须学哪些可以暂时不碰5.1 必须补的概念少到周末能学完如果你只想尽快上手需要补的概念其实不多完全可以用一个周末过一遍。概念为什么必须前端可以对照什么Prompt 基本写法决定模型输出质量写接口文档/mock 规则消息角色体系理解 system/user/assistant/tool 的结构理解 HTTP 请求头/请求体函数调用协议让 Agent 能调外部工具理解 JSON 参数传递结构化输出让结果可被程序消费理解类型校验token 基本估算控制成本和上下文长度理解数据包大小Prompt 不用学成调优大师先会用 system 消息设定角色会用必须用中文回答不要编造数据这类约束词就够了。函数调用协议看一遍官方文档再跑一遍上面的示例代码基本就懂了。token 这个概念也花不了十分钟记住它比字符更碎、按块计费即可。5.2 现在不用碰的东西以后再说很多前端容易被大模型技术栈里的海量名词吓到。我明确劝一句以下内容现在都不用碰等真正遇到业务瓶颈再学不迟。模型微调不需要碰。你只要产品不要求模型学会某种特殊口吻、不涉及高度专业术语现成的大模型 API 足够用。微调意味着收集数据集、跑训练任务、评估效果这是一条完全不同的投入路径不是应用层开发的必修课。RAG 的底层原理可以之后再说。如果只是给 Agent 挂一个文档问答先用现成的上传解析和检索方案就好你只需要理解把内容切成片、存储、检索这个流程。向量数据里的索引算法、距离计算不是第一个 Agent 项目该考虑的事。强化学习、Agent 自我进化这类东西更像是研究者的课题离生产级应用还远。如果一个入门教程开始教你用强化学习优化 Agent 行为早点关掉它不适合你现在看。5.3 一套适合前端体质的 21 天实操安排理论说完了说点能直接照做的安排。我给身边的同学推荐过一个三周计划反馈都不错。第一周做聊天助手。纯 Node.js 写一个命令行聊天程序只用大模型 API不用任何框架。要求你学会维护 messages 数组在 system prompt 里加角色设定实现多轮对话不跑偏。这一周结束你应该能感受到模型调用只是一个普通异步请求。第二周做工具调用。把上面天气 Agent 的例子改成一个自己的版本可以换成搜索或者计算器。要求你学会解析tool_calls、执行外部接口、把结果塞回上下文。这一周结束你对 Agent 循环应该有了肌肉记忆。第三周做有界面的 Agent。用你熟悉的 React 或 Vue把第二周的 Agent 包一层聊天界面加上流式输出、停止按钮、中间状态展示。可以做成一个穿衣助手也可以做一个学习规划助手。这一周结束你就拥有一个能给别人演示、能讲清楚原理的作品。带过几个想转方向的前端同学之后我发现真正的阻碍从来不是不会写模型训练代码而是不敢开始。自己亲手把第一个 Agent 跑通看着它在终端里一步步调用工具、给出答案那种原来这就是 Agent的感觉比看十篇论文都管用。如果你也是前端先忘掉训练这个词从一段普通的 fetch 开始吧。