“Agent 开发不是模型训练”这句话我是在 A 同学第九次问我“前端学 Agent 是不是得先去补一下训练模型”的时候认真和他聊开的。他当时的焦虑很典型看到各种 Agent 教程上来就讲注意力机制、微调、损失函数觉得自己没戏了。但真相是Agent 开发本质上是工程问题是编排问题是产品问题唯独不是模型训练问题。这个认知一旦转过来前端入局的路径会瞬间变得通顺得多。这篇内容就是把这层窗户纸捅破并给出一份可以直接照着做的入门路线。1. Agent 开发不是模型训练先把这条红线刻进脑子里1.1 A 同学的困惑和大部分前端踩进去的同一个坑A 同学是个做了三年前端开发的工程师最近被安排到一个内部效率工具项目里项目需求是做一个能自动整理会议纪要、跟进待办项、定时抓取竞品动态的智能助手。他第一反应是去搜大模型训练教程买了不少课看到“RLHF”“LoRA”“分布式训练”这些词就直接懵了来问我是不是得先学完这些才能动手。我给他的回复很简单不用。你被分配到的项目不是要你发明新的模型而是要你基于现有的模型能力把一个个真实的业务动作串起来。会议纪要整理你要解决的是怎么把录音转文字、怎么把长文本切进上下文窗口、怎么设计提示词让模型输出结构化结论竞品动态抓取你要解决的是怎么定时触发、怎么调用搜索接口、怎么把结果去重聚合。这些工作量和“训练一个模型”完全不在一个量级。这里面的认知偏差很普遍大家把“Agent”理解成“一个更强的新模型”觉得 Agent 的能力等于模型的能力。但现实中Agent 更像是一套业务流程的自动化执行体模型在里头只扮演“决策大脑”这个角色。大脑要思考但手脚怎么动、动作顺序怎么排、异常怎么处理都是代码层面的事而这些恰恰是前端工程师最擅长的领域。1.2 一个“会写代码”的模型不等于一个能工作的助手我习惯用一个类比来解释模型就好比一台超级发动机马力极大但你把它裸放在地上它什么都干不了。你需要的是一辆车要有底盘、轮胎、方向盘、仪表盘得有人把发动机的输出转化成前进的动能。Agent 开发本质上就是造车你要做的是动力匹配、车辆控制系统、驾驶舱交互界面而不是去研究发动机内部的燃烧室该怎么设计。放到实际开发场景里你调用一个大模型的 API它能帮你写段代码、能回答你问题但它不会自己主动去查数据库、不会自己记住上周聊了啥、不会在你懒得重复上下文的时候自动帮你补全。这些逻辑全都要靠 Agent 的外围代码来实现。一个只能“回答问题”的模型和一个能“完成工作任务”的 Agent 之间隔着提示词设计、工具调用协议、上下文管理、状态流转、异常处理这整整五层工程架构。所以每次做项目之前我都会先拉一张清单这个 Agent 需要调用哪些外部工具每步的输入输出结构是什么出错之后怎么回退中间状态存哪里。这件事做完剩下的就是按照协议把模型接口接进来。前端做习惯了组件化开发对这种“输入—处理—输出”的管道式思维完全不陌生差的只是把这套思维迁移到 LLM 场景里。2. 拆开 Agent 看本质模型只是其中一块编排才是主战场2.1 从产品角度看一个 Agent 由哪几层构成要把 Agent 开发这件事讲透得先把它的内部结构拆开来看。一个能稳定干活的 Agent从底层到顶层至少包含五层第一层是模型接口层负责对接不同的大模型服务把提示词组装成符合协议格式的请求拿到结果再解析回来。前端理解这一层毫无压力本质上就是一个特殊格式的 API 对接。第二层是工具调用层也就是常说的 Function Calling。Agent 不能只会聊天它得能去查天气、发邮件、写数据库、操作浏览器。这一层做的事情是注册“这个 Agent 有哪些工具可以用”以及把模型的抽象决策翻译成真实可执行的函数调用。第三层是编排层或者叫主控循环。这一层是整个 Agent 的心脏它负责决定“下一步该干什么”。模型说“我需要查一下某公司的工商信息”编排层就触发查询工具的调用查到结果后再把结果返回给模型让模型基于新的信息继续决策直到整个任务完成。第四层是状态管理层。Agent 干的是多步任务中间会产生很多中间状态已经查到哪些资料、哪些步骤完成了、哪些信息还需要二次确认。这些状态要么放内存要么落数据库不然一轮对话聊完下轮继续时就得从头再来。第五层是交互展示层。这层其实很接近前端的本职工作怎么把 Agent 的思考过程可视化、怎么把最终结果以合适的形态推给用户、怎么处理流式输出的打字机效果。把 Agent 拆成这五层之后你会发现真正和“模型训练”直接相关的只有第一层里的模型本体而那一部分是已经被别人训好的商品你只是拿来用。剩下四层全是工程架构全是前端同学每天在做的事情。2.2 前端基因和 Agent 开发的重合度比我预想的高得多我第一次带前端团队做 Agent 项目的时候有个很直观的感受大家上手比我想象中快得多。原因就是想通了一层——Agent 的编排逻辑和前端的状态管理、事件驱动模型几乎同构。前端开发天天接触的是什么事件循环、异步请求、状态机、数据流、组件生命周期。Agent 开发天天在做什么触发一次用户请求异步调用模型接口模型返回一个中间决策根据决策触发工具调用工具结果回来后再更新上下文状态继续下一轮循环。这整个流程套到前端里就是一套再熟悉不过的事件驱动体系。用户输入是一个事件模型响应是一个事件工具返回是一个事件每一步都是状态转移。甚至 ReAct 模式的本质就是“思考—行动—观察”的循环你画出来就是三个状态之间的状态机跳转。前端开发对状态机再熟悉不过Redux、Vuex、Zustand 里的 reducer本质上就是在描述“某个事件发生后状态怎么迁移”。这一点想通了Agent 开发瞬间从“遥不可及的 AI 领域”变成“一个挺复杂的业务系统”。还有个被忽视的重合点前端对性能敏感。真实调用大模型的时候一次请求动辄两三秒流式输出还要逐字渲染。前端同学天生对这个时间尺度有敬畏心不会写出“直接同步等待大模型结果”这种灾难性代码。这种体验敏感度在后端工程师里反而不一定人人都有但在前端里几乎是肌肉记忆。3. 前端转 Agent 开发的能力迁移清单与补课路线3.1 不用重新学的能力以及它们在 Agent 里的新名字如果你已经是一个合格的前端工程师我列一下你不用重新学、直接就能迁移的能力API 对接能力 → 模型服务的接入与鉴权。你会封装 axios 请求就会封装大模型 API。只是请求体结构换成 messages、tools、tool_choice响应解析换成流式读取而已。异步与事件驱动 → 多轮工具编排的核心。你在前端处理用户点击后发请求、拿到响应再更新的逻辑搬到 Agent 里就是模型决策后调工具、拿到工具结果再送回去的循环。状态管理 → 对话历史与上下文维护。你在前端维护 Store到 Agent 里变成维护 messages 数组本质上是一样的统一入口修改状态、保证状态可回溯、支持撤销与重放。组件化设计 → 工具函数的模块化组织。你把 UI 拆成组件到 Agent 里就是把能力拆成一个个职责单一的工具函数。任何能讲清楚输入输出的函数都可以直接注册成 Agent 的可用工具。异常处理 → 超时重试与降级方案。接口超时了怎么办工具挂了怎么办前端的错误边界思维在 Agent 开发里几乎原封不动。3.2 值得补的三门课提示词、工具协议、上下文预算能力可以迁移但有三个知识盲区是必须从零补的没有任何前端经验能帮你跳过。第一门课是提示词工程。不要觉得提示词就是“对着模型说人话”一个生产级的系统提示词其实是在写一份岗位说明书。它需要定义角色、目标、工作流程、输出格式、禁忌项、兜底策略。你要学会用“给定 X执行 Y以 Z 格式输出”的结构而不是“帮我做一下这个”的口语化指令。更重要的是你要学会“少让模型猜多给模型约束”把每个输出字段的格式、枚举值、示例都写清楚。第二门课是工具调用协议。主流的大模型服务都支持 Function Calling你需要在一次请求里带上工具列表让模型识别当前问题应该调用哪个工具。这里的核心是 JSON Schema 的写法。你会写 TypeScript 类型定义就一定会写工具参数描述。但要注意工具描述的好坏直接决定模型选不选中它。描述写得太泛模型会在多个工具之间犹豫写得太死又会有输入校验失败的情况。实际操作是拿一两个典型场景反复测试找到描述的那个平衡点。第三门课是上下文预算。模型不是无限记忆的每次调用都要把整个对话历史发过去Token 量直接跟费用和响应速度挂钩。你需要学会估算 Token、做消息裁剪、总结历史要点替代原文。前端做的虚拟列表是按窗口渲染数据Agent 里的上下文管理本质上是相同的游戏只是数据结构从 DOM 节点变成了消息对象。3.3 一条适合前端的上手路径按周排我给 A 同学排过一个四周的上手计划这里分享出来基本照着走即可第一周动手对接一个大模型 API用 Node 或浏览器里的 fetch 写完一个“输入问题—返回回答”的最小调用再把输出改成流式接收。这周的目的是消除对模型的陌生感知道请求长什么样、响应长什么样。第二周实现一个带 Function Calling 的多步循环。推荐做一个查天气然后回答的 Agent模型先识别用户想查天气调用一个 mock 天气接口拿到结果后再格式化回答。这周你能把 Agent 的核心循环刻进脑子里。第三周做带记忆的会话应用。把 messages 数组持久化到本地文件或数据库实现多轮对话的上下文回放。然后试着做上下文裁剪超出预算时把早期对话压缩成摘要。第四周做一个小产品。我给 A 同学的建议是做一个“日报生成助手”用户丢一段今天的零散工作记录Agent 调用工具抓取补充信息最后生成结构化日报。完整体验从编排到展示的闭环。这条路径没有任何一个环节需要你理解反向传播是怎么回事。4. 从零跑通一个“自动调研 日报生成”的入门 Agent4.1 场景设计与流程拆解光说不练是没用的我直接给出一个我在入门阶段自己写过的例子自动调研助手。场景是用户输入一个公司名字Agent 自动完成三个步骤搜索该公司的最新动态、抓取搜索结果里最有价值的一篇新闻正文、把信息汇总成一张结构化的调研简表。这个例子选得很好它包含一个完整 Agent 的所有要素多轮工具调用、外部数据获取、中间状态的维护、最后的结构化输出。核心流程可以拆成四步第一步把用户问题连同系统提示词发给模型工具列表里注册两个工具search_news和fetch_page_content。第二步模型返回一个 tool_calls 指令说明它想调用哪个工具、参数是什么。第三步代码执行对应工具把结果作为一条 role 为 tool 的消息追加进对话历史。第四步把带工具结果的完整消息再次发给模型模型根据拿到的信息生成最终答案。这个循环的终止条件就是“模型这次没有请求调用任何工具”。4.2 用 JavaScript 实现工具调用主循环因为是给前端看的我用 JavaScript 来写这个主循环。这里用 Node 环境跑用的接口风格是兼容主流大模型服务商的/v1/chat/completions格式具体地址和模型名换成你自己的环境变量即可。// agent.js const API_URL process.env.LLM_API_URL; // 例如 https://api.your-provider.example.com/v1/chat/completions const API_KEY process.env.LLM_API_KEY; const MODEL process.env.LLM_MODEL; // 模型名例如 gpt-4o-mini 或同级别国产模型 const SYSTEM_PROMPT 你是调研助手。你的工作流程 1. 如果用户给出一个需要查资料的任务先调用 search_news 查公开资料。 2. 如果搜索结果中包含值得细读的文章调用 fetch_page_content 获取正文。 3. 基于获取到的信息整理输出调研简表格式如下 | 公司 | 最新动态 | 信息来源 | 风险提示 | 如果搜索不到任何信息如实告知用户不要编造。 ; const TOOLS [ { type: function, function: { name: search_news, description: 搜索指定公司或话题的近期公开新闻返回标题和链接列表, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 }, limit: { type: number, description: 最多返回几条默认 5 } }, required: [query] } } }, { type: function, function: { name: fetch_page_content, description: 根据 URL 抓取网页正文返回纯文本内容, parameters: { type: object, properties: { url: { type: string, description: 网页地址 } }, required: [url] } } } ]; async function callModel(messages) { const resp await fetch(API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${API_KEY} }, body: JSON.stringify({ model: MODEL, messages, tools: TOOLS }) }); if (!resp.ok) { throw new Error(模型接口错误: ${resp.status} ${await resp.text()}); } const data await resp.json(); return data.choices[0].message; } async function searchNews(query, limit 5) { // 这里故意放一个本地 mock真实场景可以替换成搜索服务 API const db { 某科技公司: [{ title: 某科技公司发布新款产品, url: https://example.com/news/1 }], 某云厂商: [{ title: 某云厂商财报超预期, url: https://example.com/news/2 }] }; return db[query]?.slice(0, limit) ?? []; } async function fetchPageContent(url) { // 真实场景做抓取和正文抽取这里直接返回模拟文本 return 这里是网页正文的纯文本内容实际项目中会用正则去标签、截取正文区域。; } async function runAgent(userInput) { const messages [ { role: system, content: SYSTEM_PROMPT }, { role: user, content: userInput } ]; // 最多循环 8 轮防止死循环 for (let i 0; i 8; i) { const message await callModel(messages); messages.push(message); if (!message.tool_calls || message.tool_calls.length 0) { return message.content; // 模型不再调用工具输出最终结果 } for (const call of message.tool_calls) { const { name, arguments: argsJson } call.function; const args JSON.parse(argsJson); let result; if (name search_news) { result await searchNews(args.query, args.limit); } else if (name fetch_page_content) { result await fetchPageContent(args.url); } else { result { error: 未知工具: ${name} }; } messages.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(result) }); } } return 任务步骤过多已提前终止。; } // 跑一个真实任务 runAgent(帮我调研一下某科技公司的最新动态) .then((answer) console.log(answer)) .catch((err) console.error(执行失败:, err));这段代码你看完应该有一种感觉这其实就是一次普通的前端接口调用加一个 while 循环。整个 Agent 的核心循环不超过三十行。真正的工作量在工具实现上怎么让搜索接口稳定返回有效结果怎么从网页里抽干净正文这些才是后续要花大量时间打磨的点。4.3 前端如何接住流式输出上面是完整的非流式版本入门阶段建议先跑通这个。但真实产品里用户等一个完整回答等两三秒是极致煎熬所以生产级 Agent 基本都要做流式输出。前端对接流式输出的方案非常成熟就是用 fetch 加 ReadableStream。async function streamChat(messages, onToken) { const resp await fetch(API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${API_KEY} }, body: JSON.stringify({ model: MODEL, messages, stream: true }) }); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { const trimmed line.trim(); if (!trimmed.startsWith(data:)) continue; const payload trimmed.slice(5).trim(); if (payload [DONE]) return; const json JSON.parse(payload); const token json.choices?.[0]?.delta?.content || ; if (token) onToken(token); } } } // 使用示例把每次拿到的 token 追加到页面上 streamChat(messages, (token) { document.getElementById(output).textContent token; });前端做这块相当于本职工作难点只在 SSE 格式的解析每一行以data:开头一个事件的 JSON 可能跨行所以要用一个 buffer 拼完再切割。上面代码已经处理好了直接抄作业就行。4.4 运行结果与费用观察跑通之后你把这个 Agent 连续丢几个任务进去会观察到几个现象。第一个现象是模型真的会“思考”。它一般会先调用搜索搜索有了结果之后再判断“这条结果够不够详细”不够的话它会自己去调fetch_page_content然后才回答。你从控制台打印的 messages 里能看到这个决策过程非常有意思。第二个现象是 Token 消耗比你想象中快。一次完整的三步骤调研消息列表里至少有系统提示词、两轮大的工具结果可能一次就要 5000 到 8000 Token。如果搜索返回了十篇文章你全塞给模型可能直接就冲到 1 万 Token 以上。这时候你就理解上下文预算为什么重要了不是省钱的问题是因为模型上下文窗口是有限度的超了就直接报错。第三个现象是慢。每一步都有网络延迟多步叠加就是几秒到十几秒。这也解释了为什么 Agent 产品里“正在执行中”的反馈这么关键。前端做这个体验核心不是让流程更快而是让用户始终知道“现在进行到哪一步了”。把当前正在执行的工具名展示出来比转一个 loading 圈高级得多。5. 我亲手踩过的坑Agent 开发常见问题与排查清单5.1 模型并没有记忆上下文全靠你手动搬运新人最容易踩的第一个坑是以为模型“记得”之前说过的话。大模型的 API 设计天然无状态服务商不会帮你保存任何对话记录。你每次发请求都要带上完整的 messages 数组里面包括系统提示词、所有历史对话、所有工具结果。这意味着两件事。第一多轮对话的产品要自己做持久化用户关掉页面再回来你要从数据库把历史捞出来重新拼好再发给模型。第二messages 数组会越来越长你迟早要面对 Token 超限的问题。最简单的策略是做滑动窗口保留最近二十轮对话。再激进一点的做法是定期把历史对话丢给模型生成一段摘要然后把摘要作为新的系统提示词旧对话直接清掉。这就像是给 Agent 做记忆压缩是目前工程上处理长期记忆的主路。5.2 工具调用的返回值不是给模型看的是给流程看的第二个大坑是很多人把工具返回值当成“最终答案”直接展示给用户。实际上工具返回的是原始数据可能是 JSON、可能是页面正文、可能是报错信息。它的唯一作用是作为下一轮的上下文输入让模型基于这些材料做总结、做提炼、做判断。举一个实际的例子search_news返回了十条新闻标题和链接模型基于这些内容生成回答的时候不应该把这十条原封不动贴出来而是应该压缩成“关于该公司近期有三条值得关注的信息分别涉及新产品发布、管理层变动和财报表现”。这个压缩动作是模型的能力价值所在你不能跳过它直接让用户看原始数据。反过来也有人在工具返回之后不把它拼回消息历史直接丢给用户。这样模型根本不知道工具返回了什么后续对话一问三不知。记住工具结果是给下一轮模型调用的“燃料”不是展示给用户的“成品”。展示一定要经过模型的再加工。5.3 系统提示词不是摆设它是 Agent 的“底层代码”第三个坑是把系统提示词当成一句“你是一个有用的助手”就草草了事。系统提示词的工程含量不亚于前端里一份设计良好的全局配置文件它定义了 Agent 的整套行为边界。实际写的时候我习惯把系统提示词拆成固定区块角色定义、任务目标、工作流程、输出格式规范、禁止事项、兜底策略。输出格式规范里要用 Markdown 列出每个字段的结构甚至直接放一个期望输出示例效果远好于你用自然语言描述“请输出简洁一点”。禁止事项要写具体比如“当搜索无结果时不得编造信息必须明确告知用户”。有个排查思路值得分享如果 Agent 经常不按你的预期来先把系统提示词逐条删掉试每删一条跑一次测试你就能找到到底是哪一句话在“误导”模型。这很像前端的二分定位法非常实用。5.4 常见报错与速查表我把实际开发中最常碰到的几个问题整理成一个速查表方便你出问题时直接对照。报错context_length_exceeded消息太多或单个工具结果太长。先做上下文裁剪再把工具返回结果做截断只保留关键字段。模型不调用工具直接瞎回答工具描述不清晰或者系统提示词没写清楚工作流程。把系统提示词中的流程改成“第一步必须调用搜索工具没有搜索结果时禁止回答”。模型反复调用同一个工具进入死循环给主循环加最大轮数限制同时检查工具返回是否满足模型的“终止条件”也就是模型判断“已经拿到足够信息”。工具结果 JSON 解析失败模型偶尔会返回不合法 JSON。代码里要做好 try-catch解析失败时把这个错误信息作为工具结果回传模型看到后通常会自己修正参数重新调用。流式输出时页面卡顿频繁操作 DOM 更新导致性能问题。不要每次拿到 token 就写一次 DOM可以攒一小段再渲染或者用 requestAnimationFrame 做节流。多次运行费用飙升给每个请求记录 Token 用量设置单次任务上限。会话历史要定期压缩不要始终全量保留。这些问题我几乎全踩过一遍每一次排查到最后都发现是工程问题而不是模型能力问题“Agent 开发不是模型训练”这句话在排错的时候体现得尤其明显。6. 后续往哪走从单个 Agent 到多 Agent 协作6.1 多 Agent 不是“模拟开会”而是职责拆分与协议对接跑通单个 Agent 之后自然的进阶方向是让多个 Agent 协作。很多人听说多 Agent 就想到“让几个 AI 互相聊天开会”这其实是影视剧看多了。工程上的多 Agent 协作本质上是把一个复杂任务拆成多个子任务每个子任务由一个专职 Agent 负责然后通过协议把产出接力传递。常见模式有规划器加执行器模式规划器 Agent 负责拆解任务、分配步骤执行器 Agent 负责具体干活最后再由汇总 Agent 把各执行结果合并成最终交付物。这在设计思路上跟微服务架构的职责拆分没有本质区别——不同之处只是每个服务的“逻辑大脑”换成了模型。6.2 前端在 Agent 团队里的天然位置做多 Agent 系统的时候最痛苦的事情不是 Agent 本身而是你根本不知道这些 Agent 每一步在干什么。状态分布在不同模块里工具调用交错进行对调试和运营都是巨大挑战。这时候前端工程化思维的优势就出来了Agent 的运行轨迹本质上是一条可以可视化的流水线你可以把每个节点做成一个组件展示当前执行到哪个 Agent、调用了什么工具、消耗了多少 Token、下一步是什么。这个可视化调试台是前端在 Agent 项目里最不可替代的贡献比任何提示词技巧都更有价值。另外一个很有前景的方向是把 Agent 能力封装成配置化的低代码界面。因为 Agent 的行为主要由系统提示词、工具列表、流程编排三部分组成这三块看起来非常像一份配置对象。前端完全可以写一个可视化编排工具拖拽工具节点、连接执行顺序、编辑提示词模板让非技术背景的运营人员也能配置出简单靠谱的 Agent。这比给每个 Agent 写死代码更符合产品化的趋势也是前端视角天然的切入机会。6.3 关于学习路径我最后给一条笨但有效的建议如果让我给所有想入门前端 Agent 开发的同学说一句掏心窝的话那就是别把时间耗在理解模型内部原理上把时间花在你已经熟练的工程能力往 Agent 场景迁移这件事上。我见过太多人在“要不要先学机器学习”这个问题上卡了整整一个季度最后连一个完整 Agent 都没跑出来。反观 A 同学在我们的前两周活动里他的进度超过了很多同时期入场但陷在模型原理里的人。前期的基础是事件循环、状态管理、异步编程后期补的是提示词、工具协议、上下文管理至于反向传播、注意力机制这些用到的时候再按需查来不及到的都是一些概念层面的谈资。最后分享一个我写提示词的小习惯把系统提示词当源码管理写进 Git每次改完都留下 commit 记录。因为提示词改动对 Agent 行为的影响玄学程度不亚于早年前端经验里“改一行样式莫名引发布局错乱”你能在报错的时候翻车的话Agent 也能。有版本记录、能回滚这是所有前端工程师早就刻在骨子里的好习惯把它带到 Agent 开发里你很快会发现这可能是你能赢过很多人的地方。
“Agent 开发不是模型训练”这句话我是在 A 同学第九次问我“前端学 Agent 是不是得先去补一下训练模型”的时候认真和他聊开的。他当时的焦虑很典型看到各种 Agent 教程上来就讲注意力机制、微调、损失函数觉得自己没戏了。但真相是Agent 开发本质上是工程问题是编排问题是产品问题唯独不是模型训练问题。这个认知一旦转过来前端入局的路径会瞬间变得通顺得多。这篇内容就是把这层窗户纸捅破并给出一份可以直接照着做的入门路线。1. Agent 开发不是模型训练先把这条红线刻进脑子里1.1 A 同学的困惑和大部分前端踩进去的同一个坑A 同学是个做了三年前端开发的工程师最近被安排到一个内部效率工具项目里项目需求是做一个能自动整理会议纪要、跟进待办项、定时抓取竞品动态的智能助手。他第一反应是去搜大模型训练教程买了不少课看到“RLHF”“LoRA”“分布式训练”这些词就直接懵了来问我是不是得先学完这些才能动手。我给他的回复很简单不用。你被分配到的项目不是要你发明新的模型而是要你基于现有的模型能力把一个个真实的业务动作串起来。会议纪要整理你要解决的是怎么把录音转文字、怎么把长文本切进上下文窗口、怎么设计提示词让模型输出结构化结论竞品动态抓取你要解决的是怎么定时触发、怎么调用搜索接口、怎么把结果去重聚合。这些工作量和“训练一个模型”完全不在一个量级。这里面的认知偏差很普遍大家把“Agent”理解成“一个更强的新模型”觉得 Agent 的能力等于模型的能力。但现实中Agent 更像是一套业务流程的自动化执行体模型在里头只扮演“决策大脑”这个角色。大脑要思考但手脚怎么动、动作顺序怎么排、异常怎么处理都是代码层面的事而这些恰恰是前端工程师最擅长的领域。1.2 一个“会写代码”的模型不等于一个能工作的助手我习惯用一个类比来解释模型就好比一台超级发动机马力极大但你把它裸放在地上它什么都干不了。你需要的是一辆车要有底盘、轮胎、方向盘、仪表盘得有人把发动机的输出转化成前进的动能。Agent 开发本质上就是造车你要做的是动力匹配、车辆控制系统、驾驶舱交互界面而不是去研究发动机内部的燃烧室该怎么设计。放到实际开发场景里你调用一个大模型的 API它能帮你写段代码、能回答你问题但它不会自己主动去查数据库、不会自己记住上周聊了啥、不会在你懒得重复上下文的时候自动帮你补全。这些逻辑全都要靠 Agent 的外围代码来实现。一个只能“回答问题”的模型和一个能“完成工作任务”的 Agent 之间隔着提示词设计、工具调用协议、上下文管理、状态流转、异常处理这整整五层工程架构。所以每次做项目之前我都会先拉一张清单这个 Agent 需要调用哪些外部工具每步的输入输出结构是什么出错之后怎么回退中间状态存哪里。这件事做完剩下的就是按照协议把模型接口接进来。前端做习惯了组件化开发对这种“输入—处理—输出”的管道式思维完全不陌生差的只是把这套思维迁移到 LLM 场景里。2. 拆开 Agent 看本质模型只是其中一块编排才是主战场2.1 从产品角度看一个 Agent 由哪几层构成要把 Agent 开发这件事讲透得先把它的内部结构拆开来看。一个能稳定干活的 Agent从底层到顶层至少包含五层第一层是模型接口层负责对接不同的大模型服务把提示词组装成符合协议格式的请求拿到结果再解析回来。前端理解这一层毫无压力本质上就是一个特殊格式的 API 对接。第二层是工具调用层也就是常说的 Function Calling。Agent 不能只会聊天它得能去查天气、发邮件、写数据库、操作浏览器。这一层做的事情是注册“这个 Agent 有哪些工具可以用”以及把模型的抽象决策翻译成真实可执行的函数调用。第三层是编排层或者叫主控循环。这一层是整个 Agent 的心脏它负责决定“下一步该干什么”。模型说“我需要查一下某公司的工商信息”编排层就触发查询工具的调用查到结果后再把结果返回给模型让模型基于新的信息继续决策直到整个任务完成。第四层是状态管理层。Agent 干的是多步任务中间会产生很多中间状态已经查到哪些资料、哪些步骤完成了、哪些信息还需要二次确认。这些状态要么放内存要么落数据库不然一轮对话聊完下轮继续时就得从头再来。第五层是交互展示层。这层其实很接近前端的本职工作怎么把 Agent 的思考过程可视化、怎么把最终结果以合适的形态推给用户、怎么处理流式输出的打字机效果。把 Agent 拆成这五层之后你会发现真正和“模型训练”直接相关的只有第一层里的模型本体而那一部分是已经被别人训好的商品你只是拿来用。剩下四层全是工程架构全是前端同学每天在做的事情。2.2 前端基因和 Agent 开发的重合度比我预想的高得多我第一次带前端团队做 Agent 项目的时候有个很直观的感受大家上手比我想象中快得多。原因就是想通了一层——Agent 的编排逻辑和前端的状态管理、事件驱动模型几乎同构。前端开发天天接触的是什么事件循环、异步请求、状态机、数据流、组件生命周期。Agent 开发天天在做什么触发一次用户请求异步调用模型接口模型返回一个中间决策根据决策触发工具调用工具结果回来后再更新上下文状态继续下一轮循环。这整个流程套到前端里就是一套再熟悉不过的事件驱动体系。用户输入是一个事件模型响应是一个事件工具返回是一个事件每一步都是状态转移。甚至 ReAct 模式的本质就是“思考—行动—观察”的循环你画出来就是三个状态之间的状态机跳转。前端开发对状态机再熟悉不过Redux、Vuex、Zustand 里的 reducer本质上就是在描述“某个事件发生后状态怎么迁移”。这一点想通了Agent 开发瞬间从“遥不可及的 AI 领域”变成“一个挺复杂的业务系统”。还有个被忽视的重合点前端对性能敏感。真实调用大模型的时候一次请求动辄两三秒流式输出还要逐字渲染。前端同学天生对这个时间尺度有敬畏心不会写出“直接同步等待大模型结果”这种灾难性代码。这种体验敏感度在后端工程师里反而不一定人人都有但在前端里几乎是肌肉记忆。3. 前端转 Agent 开发的能力迁移清单与补课路线3.1 不用重新学的能力以及它们在 Agent 里的新名字如果你已经是一个合格的前端工程师我列一下你不用重新学、直接就能迁移的能力API 对接能力 → 模型服务的接入与鉴权。你会封装 axios 请求就会封装大模型 API。只是请求体结构换成 messages、tools、tool_choice响应解析换成流式读取而已。异步与事件驱动 → 多轮工具编排的核心。你在前端处理用户点击后发请求、拿到响应再更新的逻辑搬到 Agent 里就是模型决策后调工具、拿到工具结果再送回去的循环。状态管理 → 对话历史与上下文维护。你在前端维护 Store到 Agent 里变成维护 messages 数组本质上是一样的统一入口修改状态、保证状态可回溯、支持撤销与重放。组件化设计 → 工具函数的模块化组织。你把 UI 拆成组件到 Agent 里就是把能力拆成一个个职责单一的工具函数。任何能讲清楚输入输出的函数都可以直接注册成 Agent 的可用工具。异常处理 → 超时重试与降级方案。接口超时了怎么办工具挂了怎么办前端的错误边界思维在 Agent 开发里几乎原封不动。3.2 值得补的三门课提示词、工具协议、上下文预算能力可以迁移但有三个知识盲区是必须从零补的没有任何前端经验能帮你跳过。第一门课是提示词工程。不要觉得提示词就是“对着模型说人话”一个生产级的系统提示词其实是在写一份岗位说明书。它需要定义角色、目标、工作流程、输出格式、禁忌项、兜底策略。你要学会用“给定 X执行 Y以 Z 格式输出”的结构而不是“帮我做一下这个”的口语化指令。更重要的是你要学会“少让模型猜多给模型约束”把每个输出字段的格式、枚举值、示例都写清楚。第二门课是工具调用协议。主流的大模型服务都支持 Function Calling你需要在一次请求里带上工具列表让模型识别当前问题应该调用哪个工具。这里的核心是 JSON Schema 的写法。你会写 TypeScript 类型定义就一定会写工具参数描述。但要注意工具描述的好坏直接决定模型选不选中它。描述写得太泛模型会在多个工具之间犹豫写得太死又会有输入校验失败的情况。实际操作是拿一两个典型场景反复测试找到描述的那个平衡点。第三门课是上下文预算。模型不是无限记忆的每次调用都要把整个对话历史发过去Token 量直接跟费用和响应速度挂钩。你需要学会估算 Token、做消息裁剪、总结历史要点替代原文。前端做的虚拟列表是按窗口渲染数据Agent 里的上下文管理本质上是相同的游戏只是数据结构从 DOM 节点变成了消息对象。3.3 一条适合前端的上手路径按周排我给 A 同学排过一个四周的上手计划这里分享出来基本照着走即可第一周动手对接一个大模型 API用 Node 或浏览器里的 fetch 写完一个“输入问题—返回回答”的最小调用再把输出改成流式接收。这周的目的是消除对模型的陌生感知道请求长什么样、响应长什么样。第二周实现一个带 Function Calling 的多步循环。推荐做一个查天气然后回答的 Agent模型先识别用户想查天气调用一个 mock 天气接口拿到结果后再格式化回答。这周你能把 Agent 的核心循环刻进脑子里。第三周做带记忆的会话应用。把 messages 数组持久化到本地文件或数据库实现多轮对话的上下文回放。然后试着做上下文裁剪超出预算时把早期对话压缩成摘要。第四周做一个小产品。我给 A 同学的建议是做一个“日报生成助手”用户丢一段今天的零散工作记录Agent 调用工具抓取补充信息最后生成结构化日报。完整体验从编排到展示的闭环。这条路径没有任何一个环节需要你理解反向传播是怎么回事。4. 从零跑通一个“自动调研 日报生成”的入门 Agent4.1 场景设计与流程拆解光说不练是没用的我直接给出一个我在入门阶段自己写过的例子自动调研助手。场景是用户输入一个公司名字Agent 自动完成三个步骤搜索该公司的最新动态、抓取搜索结果里最有价值的一篇新闻正文、把信息汇总成一张结构化的调研简表。这个例子选得很好它包含一个完整 Agent 的所有要素多轮工具调用、外部数据获取、中间状态的维护、最后的结构化输出。核心流程可以拆成四步第一步把用户问题连同系统提示词发给模型工具列表里注册两个工具search_news和fetch_page_content。第二步模型返回一个 tool_calls 指令说明它想调用哪个工具、参数是什么。第三步代码执行对应工具把结果作为一条 role 为 tool 的消息追加进对话历史。第四步把带工具结果的完整消息再次发给模型模型根据拿到的信息生成最终答案。这个循环的终止条件就是“模型这次没有请求调用任何工具”。4.2 用 JavaScript 实现工具调用主循环因为是给前端看的我用 JavaScript 来写这个主循环。这里用 Node 环境跑用的接口风格是兼容主流大模型服务商的/v1/chat/completions格式具体地址和模型名换成你自己的环境变量即可。// agent.js const API_URL process.env.LLM_API_URL; // 例如 https://api.your-provider.example.com/v1/chat/completions const API_KEY process.env.LLM_API_KEY; const MODEL process.env.LLM_MODEL; // 模型名例如 gpt-4o-mini 或同级别国产模型 const SYSTEM_PROMPT 你是调研助手。你的工作流程 1. 如果用户给出一个需要查资料的任务先调用 search_news 查公开资料。 2. 如果搜索结果中包含值得细读的文章调用 fetch_page_content 获取正文。 3. 基于获取到的信息整理输出调研简表格式如下 | 公司 | 最新动态 | 信息来源 | 风险提示 | 如果搜索不到任何信息如实告知用户不要编造。 ; const TOOLS [ { type: function, function: { name: search_news, description: 搜索指定公司或话题的近期公开新闻返回标题和链接列表, parameters: { type: object, properties: { query: { type: string, description: 搜索关键词 }, limit: { type: number, description: 最多返回几条默认 5 } }, required: [query] } } }, { type: function, function: { name: fetch_page_content, description: 根据 URL 抓取网页正文返回纯文本内容, parameters: { type: object, properties: { url: { type: string, description: 网页地址 } }, required: [url] } } } ]; async function callModel(messages) { const resp await fetch(API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${API_KEY} }, body: JSON.stringify({ model: MODEL, messages, tools: TOOLS }) }); if (!resp.ok) { throw new Error(模型接口错误: ${resp.status} ${await resp.text()}); } const data await resp.json(); return data.choices[0].message; } async function searchNews(query, limit 5) { // 这里故意放一个本地 mock真实场景可以替换成搜索服务 API const db { 某科技公司: [{ title: 某科技公司发布新款产品, url: https://example.com/news/1 }], 某云厂商: [{ title: 某云厂商财报超预期, url: https://example.com/news/2 }] }; return db[query]?.slice(0, limit) ?? []; } async function fetchPageContent(url) { // 真实场景做抓取和正文抽取这里直接返回模拟文本 return 这里是网页正文的纯文本内容实际项目中会用正则去标签、截取正文区域。; } async function runAgent(userInput) { const messages [ { role: system, content: SYSTEM_PROMPT }, { role: user, content: userInput } ]; // 最多循环 8 轮防止死循环 for (let i 0; i 8; i) { const message await callModel(messages); messages.push(message); if (!message.tool_calls || message.tool_calls.length 0) { return message.content; // 模型不再调用工具输出最终结果 } for (const call of message.tool_calls) { const { name, arguments: argsJson } call.function; const args JSON.parse(argsJson); let result; if (name search_news) { result await searchNews(args.query, args.limit); } else if (name fetch_page_content) { result await fetchPageContent(args.url); } else { result { error: 未知工具: ${name} }; } messages.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(result) }); } } return 任务步骤过多已提前终止。; } // 跑一个真实任务 runAgent(帮我调研一下某科技公司的最新动态) .then((answer) console.log(answer)) .catch((err) console.error(执行失败:, err));这段代码你看完应该有一种感觉这其实就是一次普通的前端接口调用加一个 while 循环。整个 Agent 的核心循环不超过三十行。真正的工作量在工具实现上怎么让搜索接口稳定返回有效结果怎么从网页里抽干净正文这些才是后续要花大量时间打磨的点。4.3 前端如何接住流式输出上面是完整的非流式版本入门阶段建议先跑通这个。但真实产品里用户等一个完整回答等两三秒是极致煎熬所以生产级 Agent 基本都要做流式输出。前端对接流式输出的方案非常成熟就是用 fetch 加 ReadableStream。async function streamChat(messages, onToken) { const resp await fetch(API_URL, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${API_KEY} }, body: JSON.stringify({ model: MODEL, messages, stream: true }) }); const reader resp.body.getReader(); const decoder new TextDecoder(utf-8); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); const lines buffer.split(\n); buffer lines.pop(); for (const line of lines) { const trimmed line.trim(); if (!trimmed.startsWith(data:)) continue; const payload trimmed.slice(5).trim(); if (payload [DONE]) return; const json JSON.parse(payload); const token json.choices?.[0]?.delta?.content || ; if (token) onToken(token); } } } // 使用示例把每次拿到的 token 追加到页面上 streamChat(messages, (token) { document.getElementById(output).textContent token; });前端做这块相当于本职工作难点只在 SSE 格式的解析每一行以data:开头一个事件的 JSON 可能跨行所以要用一个 buffer 拼完再切割。上面代码已经处理好了直接抄作业就行。4.4 运行结果与费用观察跑通之后你把这个 Agent 连续丢几个任务进去会观察到几个现象。第一个现象是模型真的会“思考”。它一般会先调用搜索搜索有了结果之后再判断“这条结果够不够详细”不够的话它会自己去调fetch_page_content然后才回答。你从控制台打印的 messages 里能看到这个决策过程非常有意思。第二个现象是 Token 消耗比你想象中快。一次完整的三步骤调研消息列表里至少有系统提示词、两轮大的工具结果可能一次就要 5000 到 8000 Token。如果搜索返回了十篇文章你全塞给模型可能直接就冲到 1 万 Token 以上。这时候你就理解上下文预算为什么重要了不是省钱的问题是因为模型上下文窗口是有限度的超了就直接报错。第三个现象是慢。每一步都有网络延迟多步叠加就是几秒到十几秒。这也解释了为什么 Agent 产品里“正在执行中”的反馈这么关键。前端做这个体验核心不是让流程更快而是让用户始终知道“现在进行到哪一步了”。把当前正在执行的工具名展示出来比转一个 loading 圈高级得多。5. 我亲手踩过的坑Agent 开发常见问题与排查清单5.1 模型并没有记忆上下文全靠你手动搬运新人最容易踩的第一个坑是以为模型“记得”之前说过的话。大模型的 API 设计天然无状态服务商不会帮你保存任何对话记录。你每次发请求都要带上完整的 messages 数组里面包括系统提示词、所有历史对话、所有工具结果。这意味着两件事。第一多轮对话的产品要自己做持久化用户关掉页面再回来你要从数据库把历史捞出来重新拼好再发给模型。第二messages 数组会越来越长你迟早要面对 Token 超限的问题。最简单的策略是做滑动窗口保留最近二十轮对话。再激进一点的做法是定期把历史对话丢给模型生成一段摘要然后把摘要作为新的系统提示词旧对话直接清掉。这就像是给 Agent 做记忆压缩是目前工程上处理长期记忆的主路。5.2 工具调用的返回值不是给模型看的是给流程看的第二个大坑是很多人把工具返回值当成“最终答案”直接展示给用户。实际上工具返回的是原始数据可能是 JSON、可能是页面正文、可能是报错信息。它的唯一作用是作为下一轮的上下文输入让模型基于这些材料做总结、做提炼、做判断。举一个实际的例子search_news返回了十条新闻标题和链接模型基于这些内容生成回答的时候不应该把这十条原封不动贴出来而是应该压缩成“关于该公司近期有三条值得关注的信息分别涉及新产品发布、管理层变动和财报表现”。这个压缩动作是模型的能力价值所在你不能跳过它直接让用户看原始数据。反过来也有人在工具返回之后不把它拼回消息历史直接丢给用户。这样模型根本不知道工具返回了什么后续对话一问三不知。记住工具结果是给下一轮模型调用的“燃料”不是展示给用户的“成品”。展示一定要经过模型的再加工。5.3 系统提示词不是摆设它是 Agent 的“底层代码”第三个坑是把系统提示词当成一句“你是一个有用的助手”就草草了事。系统提示词的工程含量不亚于前端里一份设计良好的全局配置文件它定义了 Agent 的整套行为边界。实际写的时候我习惯把系统提示词拆成固定区块角色定义、任务目标、工作流程、输出格式规范、禁止事项、兜底策略。输出格式规范里要用 Markdown 列出每个字段的结构甚至直接放一个期望输出示例效果远好于你用自然语言描述“请输出简洁一点”。禁止事项要写具体比如“当搜索无结果时不得编造信息必须明确告知用户”。有个排查思路值得分享如果 Agent 经常不按你的预期来先把系统提示词逐条删掉试每删一条跑一次测试你就能找到到底是哪一句话在“误导”模型。这很像前端的二分定位法非常实用。5.4 常见报错与速查表我把实际开发中最常碰到的几个问题整理成一个速查表方便你出问题时直接对照。报错context_length_exceeded消息太多或单个工具结果太长。先做上下文裁剪再把工具返回结果做截断只保留关键字段。模型不调用工具直接瞎回答工具描述不清晰或者系统提示词没写清楚工作流程。把系统提示词中的流程改成“第一步必须调用搜索工具没有搜索结果时禁止回答”。模型反复调用同一个工具进入死循环给主循环加最大轮数限制同时检查工具返回是否满足模型的“终止条件”也就是模型判断“已经拿到足够信息”。工具结果 JSON 解析失败模型偶尔会返回不合法 JSON。代码里要做好 try-catch解析失败时把这个错误信息作为工具结果回传模型看到后通常会自己修正参数重新调用。流式输出时页面卡顿频繁操作 DOM 更新导致性能问题。不要每次拿到 token 就写一次 DOM可以攒一小段再渲染或者用 requestAnimationFrame 做节流。多次运行费用飙升给每个请求记录 Token 用量设置单次任务上限。会话历史要定期压缩不要始终全量保留。这些问题我几乎全踩过一遍每一次排查到最后都发现是工程问题而不是模型能力问题“Agent 开发不是模型训练”这句话在排错的时候体现得尤其明显。6. 后续往哪走从单个 Agent 到多 Agent 协作6.1 多 Agent 不是“模拟开会”而是职责拆分与协议对接跑通单个 Agent 之后自然的进阶方向是让多个 Agent 协作。很多人听说多 Agent 就想到“让几个 AI 互相聊天开会”这其实是影视剧看多了。工程上的多 Agent 协作本质上是把一个复杂任务拆成多个子任务每个子任务由一个专职 Agent 负责然后通过协议把产出接力传递。常见模式有规划器加执行器模式规划器 Agent 负责拆解任务、分配步骤执行器 Agent 负责具体干活最后再由汇总 Agent 把各执行结果合并成最终交付物。这在设计思路上跟微服务架构的职责拆分没有本质区别——不同之处只是每个服务的“逻辑大脑”换成了模型。6.2 前端在 Agent 团队里的天然位置做多 Agent 系统的时候最痛苦的事情不是 Agent 本身而是你根本不知道这些 Agent 每一步在干什么。状态分布在不同模块里工具调用交错进行对调试和运营都是巨大挑战。这时候前端工程化思维的优势就出来了Agent 的运行轨迹本质上是一条可以可视化的流水线你可以把每个节点做成一个组件展示当前执行到哪个 Agent、调用了什么工具、消耗了多少 Token、下一步是什么。这个可视化调试台是前端在 Agent 项目里最不可替代的贡献比任何提示词技巧都更有价值。另外一个很有前景的方向是把 Agent 能力封装成配置化的低代码界面。因为 Agent 的行为主要由系统提示词、工具列表、流程编排三部分组成这三块看起来非常像一份配置对象。前端完全可以写一个可视化编排工具拖拽工具节点、连接执行顺序、编辑提示词模板让非技术背景的运营人员也能配置出简单靠谱的 Agent。这比给每个 Agent 写死代码更符合产品化的趋势也是前端视角天然的切入机会。6.3 关于学习路径我最后给一条笨但有效的建议如果让我给所有想入门前端 Agent 开发的同学说一句掏心窝的话那就是别把时间耗在理解模型内部原理上把时间花在你已经熟练的工程能力往 Agent 场景迁移这件事上。我见过太多人在“要不要先学机器学习”这个问题上卡了整整一个季度最后连一个完整 Agent 都没跑出来。反观 A 同学在我们的前两周活动里他的进度超过了很多同时期入场但陷在模型原理里的人。前期的基础是事件循环、状态管理、异步编程后期补的是提示词、工具协议、上下文管理至于反向传播、注意力机制这些用到的时候再按需查来不及到的都是一些概念层面的谈资。最后分享一个我写提示词的小习惯把系统提示词当源码管理写进 Git每次改完都留下 commit 记录。因为提示词改动对 Agent 行为的影响玄学程度不亚于早年前端经验里“改一行样式莫名引发布局错乱”你能在报错的时候翻车的话Agent 也能。有版本记录、能回滚这是所有前端工程师早就刻在骨子里的好习惯把它带到 Agent 开发里你很快会发现这可能是你能赢过很多人的地方。
