今天是我在团队内部发起“前端AI Agent”学习实验的第68天。写下这篇东西不是想标榜什么而是想给同样在观望的前端同行一个真实参考一个干了多年纯前端、平时被业务需求追着跑的人怎么在两个月多一点的时间里从只会调接口到能独立搭出一个会自己调用工具解决问题的Agent。文章里没有玄学全部是这68天里踩过的坑、验证过的方法和还在坚持的路线希望能给想转方向又不知道从哪里下手的同学一点抓手。先说清楚我不是AI算法出身Vue/React写得多微前端、工程化、性能优化这些才是我的主战场。之所以花精力学AI Agent是因为我越来越清楚地意识到未来的前端应用不会停留在页面展示和交互而是会长出“能自己干活”的能力。用户不会满足于点一个按钮而是希望按钮背后有个Agent帮他走完整条流程。前端离用户最近也最应该掌握这种能力。这篇总结适合三类人看一是对AI Agent感兴趣但迟迟没动身的前端开发二是团队里想引入AI能力但不知如何落地的前端Leader三是正在准备转AI方向、想知道“前端底子到底能复用多少”的同学。我会把68天的路线规划、关键概念、实操Demo、踩坑实录全部摊开讲能捞多少看你自己动手的速度。1. 为什么一个前端Leader要跑去学AI Agent1.1 前端边界正在被AI改写焦虑不如动手做前端Leader这两年我能明显感觉到行业水温变了。以前我们焦虑的是框架又更新了、组件库又重构了、性能指标又红了现在大家焦虑的是——页面上那些表单、列表、筛选器正在被对话式交互一步步替代。用户想问的不是“帮我查一下三月份订单”而是直接输入这个需求让系统把订单列表、汇总表、异常提醒一次性给出来。这种转变对前端不是威胁反而是机会。因为AI Agent最终也要落地到界面、交互、状态管理、前端SDK集成这些地方。真正危险的不是AI会替换前端而是别的岗位拿着AI工具把前端该做的活也一起干了。我认识好几个后端和产品经理已经在用Coze、Dify搭Agent跑通业务流程前端反而成了被通知的一方。与其被跨界降维打击不如主动把自己的技能包升级。1.2 前端工程师做Agent的先天优势比想象中大很多前端同学觉得自己不懂算法、数学一般跟Agent有距离。实际上Agent工程化和算法研究是两码事。Agent落地涉及的大量环节恰恰是前端的强项交互与可视化Agent的运行状态、中间思考过程、工具调用日志都需要可视化呈现。前端能做推理过程展示、“思维链”条、Token消耗看板这是后端工程师不擅长的部分。异步与流式处理大模型全部是流式输出SSE、WebSocket、队列、重试、中断恢复这些和前端处理大文件上传、实时消息推送是同一套思路我连Web Worker都能用上。状态管理Agent多轮对话、多步工具调用的状态维护本质上就是复杂前端应用的状态管理。Redux、Zustand、Pinia那套心智模型完全迁移得过来。工程化与性能大模型返回慢前端能做骨架屏、流式逐字渲染、优先级调度组件库、SDK封装、跨平台适配这些更是看家本领。还有一个隐性优势是审美和产品感。Agent产品不是纯API拼接用户面对的是对话框节点编排器结果展示面板体验做得像不像原生应用前端的话语权非常重。1.3 我给自己定的68天目标拆解开始之前我只定了三个原则性目标避免学偏第1-20天看懂大模型基础概念明确Token、上下文窗口、Temperature、Prompt这些词到底是什么意思。第21-45天吃透Agent的四个核心模块——大模型、规划编排、工具调用、记忆管理并逐个动手做小实验。第46-68天用纯前端技术栈落地一个完整的Agent Demo部署到公网输出一篇可复盘的总结。没写太细因为我知道AI领域变化太快太细的计划大概率会被打脸。事实也证明中间至少调整了三次技术选型。但大的节奏没有乱这就是“以终为始”的价值。2. 68天学习路线实录从LLM基础到Agent落地2.1 阶段一大模型基础扫盲第1-20天这个阶段我先没碰框架老老实实看大模型本身的机制。重点做了四件事第一件事是搞懂“Token到底是什么”。这块很多人以为只是“字数统计”其实坑很多我后面单独用一节讲因为它在Agent开发里直接决定成本和质量。第二件事是理解“上下文窗口”和“Temperature”。一开始我写Prompt总想着把所有规则都塞进System Prompt结果每次对话都浪费大量Token还经常溢出。后来意识到上下文窗口就是模型一次能“记住”的全部内容超出部分不是被丢弃就是被截断所以Prompt和历史的取舍非常关键。第三件事是反复做“提示词实验”。我拿自己的学习笔记和代码片段当语料测不同写法对大模型输出的影响。比如同样的需求把“请优化下面的代码”改成“请扮演一位资深前端架构师从可维护性角度指出这段代码的3个问题并提出重构建议”输出的质量天差地别。第四件事是开始使用AI编程工具。以前我只用代码补全68天里我把Cursor、Continue这些插件全部用起来逼自己在日常业务开发中依赖AI辅助边写边理解AI回答问题的局限。理解这些工具后面也会变成Agent的一部分。2.2 阶段二Agent核心模块逐个击破第21-45天Agent不是简单调用几次大模型它有一套可拆解的架构。这个阶段我把Agent拆成四个模块每个模块用一周左右专门研究大模型Brain对比了不同模型的API出入参格式、推理速度、成本。发现绝大多数模型兼容OpenAI风格的接口用一套client基本能打通所有服务这大大降低了学习成本。规划编排Planning从最简单的ReAct模式入手——模型推理下一步该做什么、执行、观察结果、再推理。亲手写了一个十几行的循环把“思考-行动-观察”跑通才真正理解什么是Agent。工具调用Function Calling这是Agent落地最核心的一环。模型本身不联网但通过声明一堆工具查天气、搜文档、发请求模型可以根据用户需求选择合适工具并生成参数。前端的消息推送、文件上传、加密签名这些能力都可以包装成工具给Agent用。记忆管理Memory短期记忆就是当前对话上下文长期记忆需要把历史信息存到数据库或向量库。前端场景下我用IndexedDB和localStorage做过两种方案各有取舍。每个模块学完后我都用自己的话写一篇学习笔记然后录一个三分钟讲解视频存在自己电脑里。输出倒逼输入这个方法对我特别有效。2.3 阶段三从看教程到自己搭Demo第46-68天前45天我一直有个心理舒适区看别人的代码觉得都懂一关掉页面脑子一片空白。第46天我强迫自己不看任何教程白手起家搭Agent这才进入真正的涨分期。期间我试过两条路线一是用Dify、Coze这类低代码平台快速搭个Agent验证业务流程二是用代码手写Agent把细节做到可控。我的建议是两者都要用低代码平台帮你建立全局观手写代码帮你理解底层原理。我在低代码平台里调试一个“让小红书自动发消息”的Agent时理解了触发器、工作流节点、条件分支的组合方式然后才用代码实现同样的逻辑这样出错时能定位到具体环节不会被平台的黑盒困住。这个阶段的产出包括一个基于Node和浏览器环境的Agent运行沙箱、三套前端封装工具集、一个通过泛化Function Calling调起前端插件的示例、以及最终的完整业务Demo。具体细节我会在实操章节里展开。2.4 信息收集渠道和避坑路子学习过程中信息渠道选得不好会白白浪费大量时间。我个人用下来靠谱的有四类官方文档优先。大模型API文档、Agent框架官方教程、云厂商的Agent白皮书比如阿里云AI Agent白皮书虽然叫云厂商产出的但里面的架构图和对落地场景的盘点非常全都是最正统的知识源。开源项目源码。GitHub上star高的Agent项目直接读它们的核心代码比自己看二手博客强十倍。一线开发者的实践笔记。那些写“我搭了一个XX时候踩过的坑”的文章往往比教科书更实用当然也要注意时效性AI领域三个月前的经验可能就已经过时。行业大会和技术社区的热门话题。不是凑热闹而是通过“热搜词”判断现在行业到底在解决什么问题热词背后都是真需求。避坑方面我的心得是别一上来就背Prompt模板也别沉迷于各种Agent酷炫的演示Demo。演示价值不等于工程价值。要看到生产环境里那些没人愿意讲的部分——鉴权、重试、超时、熔断、成本控制、数据隔离这些才是把Agent做成产品的地方。3. 用前端视角拆透Agent架构和核心概念3.1 Agent到底是什么LLM编排工具记忆的组装体很多前端同学刚开始会混淆“聊天机器人”和“Agent”其实两者差别特别大。聊天机器人是“你说一句我回一句”数据是静态的Agent更像一个“实习生”你给它一个目标它自己拆解步骤、调用工具、检查结果、反复迭代直到把任务完成。我习惯用JavaScript开发里的比喻来解释Agent如果把大模型API比作一个超级聪明的“高阶函数”它输入一组消息输出一个回复。但单靠这个函数做不了实事因为模型本身就是个“大脑”没有手脚。Agent就是给这个大脑装上“手脚”的体系——规划器决定先做什么工具集提供能执行的动作记忆系统保存有用的信息内循环反复执行直到任务收敛。我写过一个最简的Agent循环代码去掉所有封装就四十多行async function agentLoop(task, tools, callLLM) { const messages [{ role: system, content: 你是前端助手请使用提供的工具完成用户请求。 }]; messages.push({ role: user, content: task }); let maxRounds 10; let result ; while (maxRounds-- 0) { const resp await callLLM(messages); const msg resp.choices[0].message; messages.push(msg); // 没有工具调用请求说明模型要给最终答案了 if (!msg.tool_calls || msg.tool_calls.length 0) { result msg.content; break; } // 逐个执行工具调用把结果作为新消息发回给模型 for (const call of msg.tool_calls) { const tool tools[call.function.name]; if (!tool) continue; const args JSON.parse(call.function.arguments); const toolResult await tool(args); messages.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(toolResult) }); } } return result; }这段代码就是Agent最核心的骨架。模型要求调用工具时返回带tool_calls的响应我们负责真去执行这些工具再把执行结果塞回对话让模型基于新信息继续推理。前端同学学会这个循环Agent的基础就通了。3.2 Token到底是什么意思算清楚这一笔账才敢上生产Token是模型处理文本的最小单位不是一个个汉字或英文单词而是通过分词器切出来的片段。英文里常见的是“一个单词约等于一个Token”或略多一点中文通常一个汉字占1-2个Token不同模型的分词器切法不一样具体数值以官方文档为准。在Agent开发中Token是整个成本系统的核心。因为每次API调用的价格不是按你输入的字数算而是按“实际消耗的Token数”算这个数等于单轮消息携带的全部历史Token 本次生成回复的Token。多轮对话历史一长Token量会指数级膨胀。我举个具体例子一次对话框长度约3万字历史消息占8K Token每轮用户发一条新消息约200 TokenAgent回复约500 Token。表面上一次交互只有700 Token的新成本可如果历史不清洗十个来回后历史就膨胀到10万Token接口直接报错费用也原地起飞。所以生产级Agent必须做三件事限制最大轮数、对历史做裁剪、必要时用“历史摘要”替代原始记录。我自己的经验是把超过5轮之前的消息先摘要成几句话成本能降70%对效果的影响不大。3.3 主流Agent架构单Agent、多Agent、工作流Agent根据近期项目实践和行业讨论当前主流的Agent架构可以归成三类单Agent模式一个Agent全程负责接收用户需求、拆解任务、调用工具、输出结果。实现简单适合任务边界清晰的场景比如“文档格式转换助手”。缺点是复杂任务容易在一棵树上吊死上下文也容易越积越乱。多Agent协作拆成“规划Agent”“执行Agent”“审查Agent”各管一段互相传递中间结果。效果更好但工程复杂度也高需要设计通信协议、容错机制、结果仲裁。我做过一个小实验让规划Agent拆解“布置会议室”的任务执行Agent调用日历工具和会议室查询工具审查Agent最后检查冲突比单Agent稳定得多。工作流AgentFlow-based先用可视化编排定义好分支和条件Agent严格按流程图跑。这是目前企业落地最多的方式可控性和可观测性强因为流程是确定的。我推荐前端团队首次做Agent需求时选这种模式起步而不是一上来就上“自由发挥”的Agent。选型其实很像前端技术选型没有最好的架构只有最匹配业务场景的架构。自由度高的Agent灵活但不可控确定性强的流程稳定但不够智能。我做技术方案评审时会先问业务方这个流程里可接受的最大不确定性是多少回答这个问题的过程中架构答案基本已经出来了。3.4 Function CallingAgent的“手”和“脚”Function Calling工具调用是值得重点练的地方。模型本身不联网也不会直接操作你的业务系统但我们可以给它一份工具清单每个工具包含名称、描述、参数结构JSON Schema。模型读了用户需求后根据语义生成一个结构化调用指令我们再在代码里真正执行这个指令。我封装前端业务的SysCall工具时写过这种定义{ name: frontend_shell, description: 在网页中执行前端操作比如路由跳转、打开弹窗、触发消息提示, parameters: { type: object, properties: { action: { type: string, enum: [navigate, open_modal, toast] }, payload: { type: object } }, required: [action] } }大模型看到这个工具定义在合适时机就会返回“我想调用frontend_shell工具参数是actionnavigate, payload/order/list”。我们执行后把结果回传给模型模型会基于结果继续回答用户。这个“API-API”的对接方式前端工程师理解起来非常顺畅因为本质上和我们平时封装SDK、对接后端接口的模式一模一样。4. 实操全记录纯前端技术栈落地Agent Demo4.1 技术选型为什么选纯前端方案学习阶段结束后我想做一个能验证前端能力的Agent Demo。一开始考虑过用Python后端Django来跑Agent这确实更稳妥因为很多Agent框架原生支持Python。但我的初衷是验证“前端能不能把Agent完整跑起来”所以定了纯前端路线运行环境浏览器为主Node.js为辅。前端逻辑全部用JavaScript/TypeScript。大模型接入通过后端代理或云函数转发API请求避免把密钥直接暴露在页面上。这块玩法和以前做“前端带签名请求”如出一辙。数据持久化浏览器端用IndexedDB存Agent的会话历史和工具调用记录做一个简单的“本地记忆”。部署方案用静态托管平台如Vercel、Netlify、Cloudflare Pages两层结构静态页面一层API代理一层用平台自带的Serverless函数。这样做的优点是把整个Agent产品的全链路都拴在前端可控范围内也方便我复盘每一步。缺点是需要处理浏览器CORS、跨域、密钥安全问题但这些恰好是前端老本行不算难。4.2 核心代码与业务场景我做的是“内部知识库问答纪要Agent”用户输入一句话Agent需要完成以下步骤判断意图、检索知识库我用一个静态JSON模拟、搜索翻译工具调一个公开翻译API、生成周报摘要最终把结果以流式方式渲染到页面上。核心模块分四块1消息管理与流式渲染// 使用 fetch ReadableStream 实现流式输出 async function streamChat(messages, onUpdate) { const response await fetch(/api/agent-chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages, stream: true }) }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按行解析 SSE 数据 const lines buffer.split(\n); buffer lines.pop() || ; lines.forEach(line { if (line.startsWith(data:)) { const json JSON.parse(line.slice(5).trim()); onUpdate(json); } }); } }这块实际上是前端基础能力的体现。大模型回复是流式到达的用户希望看到逐字输出的效果前端必须处理好这种“半开状态下的渲染”。用SSE协议解析数据把增量内容实时更新到界面一旦断流还要自动重连这些都是我以前做实时推送时练过的。2工具注册表const agentTools { searchKnowledge: async (keywords) { // 模拟检索内部知识库 JSON 文件 const index await fetch(/data/kb-index.json).then(r r.json()); return index .filter(doc doc.title.includes(keywords) || doc.tags.includes(keywords)) .slice(0, 5); }, translateText: async ({ text, target }) { // 调用公开翻译接口注意跨域时用代理 const res await fetch(/api/translate, { method: POST, body: JSON.stringify({ text, target }) }); return res.json(); }, generateSummary: async ({ sections }) { // 这项本来应该让模型来做但我先提供了一个本地的伪实现验证流程 return sections.map(s - ${s.name}: ${s.abstract}).join(\n); } };用代码把这些工具暴露给大模型让模型在回复里通过Function Calling驱动它们。每个工具函数的实现前端同学都很眼熟网络请求、数据处理、结果格式化和日常业务开发没什么两样。3记忆管理浏览器环境下短期记忆放在一个队列数组里长期记忆我用IndexedDB做了个简单的版本async function saveSession(sessionId, messages, summary) { const db await openDB(agent-memory, 1, { upgrade(db) { db.createObjectStore(sessions, { keyPath: id }); } }); const tx db.transaction(sessions, readwrite); tx.objectStore(sessions).put({ id: sessionId, messages, summary, updatedAt: Date.now() }); await tx.done; }跨页面刷新后Agent还能基于上次的会话摘要继续回答问题。虽然和正经向量库比不了但用来理解“记忆持久化”的原理足够了。下一步我可以再接入向量检索把相似历史会话找回来当上下文那就更接近真正的RAG了。4前端SDK封装与组件化Agent的能力我封装成了一个组件库对外暴露AgentChat /、AgentToolCallTimeline /、TokenUsageBadge /等组件。这样团队的微前端子应用可以直接引入使用主应用不需要关心Agent内部逻辑。做这个过程时我把之前已有的前端UI组件库经验全部迁移过来了包括定义事件的类型、支持暗色模式、可访问性处理。4.3 部署过程中的真实问题部署到纯静态托管平台时我踩了两个比较典型的坑第一个坑是跨域问题。浏览器直接调用大模型API会触发CORS且密钥暴露不安全。最后用Vercel的Serverless函数做了一层代理浏览器跟同域函数通信函数内部转发到模型API环境变量里存密钥。这一个动作就消除了跨域和密钥暴露两个问题。第二个坑是流式响应在代理层被缓冲了。Serverless函数默认会把后端响应完整取回来再返回导致前端半天等不到一个字。解决办法是在代理层设置Content-Type: text/event-stream并手动关闭缓冲把响应流实时转发给浏览器。部署完成的那一刻我在手机浏览器上打开页面对话框里逐字蹦出Agent的回答下面一行行显示工具调用记录——这种感觉跟当年第一次上线自己写的页面一样爽。5. 实际遇到的高频坑一条条说清楚5.1 Token消耗失控接口直接打爆实战中Token失控是我遇到的第一个大坑。有一轮Agent跑着跑着突然返回401错误一看账单才知道连续五次实验把几百万Token烧没了原因就是历史消息从未压缩。后来我加了“上下文管理器”每轮对话结束统计token占用超过阈值自动把前面的消息折叠成摘要。顺带一提调试阶段把max_tokens设小一点、多打印token数和费用能省很多钱。这个习惯值得养成。5.2 工具调用结果格式不规范Function Calling虽然强大但返回的结果有时会缺字段、错格式。我第一次用本地JSON模拟知识库时模型返回{keywords:订单}我代码里却用了args.word直接冒出undefined。解决方法是给工具函数加上入参校验和默认值并且在tools定义里把参数描述写得足够详细。最好在函数入口做一次JSON Schema校验防止脏数据污染整个链路。5.3 前端SDK兼容和流式断线浏览器端调用大模型时连接比较脆弱。移动端网络切换会导致SSE流中断用户看到回复停在半截。我做了三件事一是断线自动重连重连时带上之前收到的消息片段让模型从断点续写二是主动展示“连接中”状态避免用户以为系统死了三是请求超时设置合理值太短容易误杀太长体验又差。前端做Agent产品网络异常处理是必修课。5.4 上下文污染Agent聊着聊着就“人格分裂”多轮对话跑久了Agent会忘掉最初的设定或者把不同用户的上下文混在一起。这个在浏览器单会话里还好但一旦接入了多用户记忆隔离就成了大问题。我在项目里给每个会话生成独立的sessionId所有的记忆读写都带这个维度从源头避免串台。另外System Prompt里明确写清楚“你是XX场景的助手不要越界回答”也能缓解上下文污染。5.5 浏览器安全策略与爬虫防护这里顺带提一个很多人容易忽略的点Agent直接跑在前端意味着业务逻辑暴露在浏览器里。如果有人把JS源码拉下来逆向就能看到你的Prompt和工具接口地址。我做了一部分防护接口层增加签名校验和频控敏感信息不放前端包。前端防爬虫、防查看源码、防绕过等安全方案是另一套体系这里只提醒一点——Agent的能力边界越清晰暴露面越小不要把太多核心prompt和密钥写死在页面上。6. 给前端同学的转型建议和下一步6.1 学习路径建议先刻意立框架再往内填细节我的路线可以简化成四步跑通概念先理解大模型API、Token、Function Calling四个概念别急着写代码。看懂一个开源Agent项目找一个star高、代码量在一万行以内的项目读透它的核心循环。读不懂的地方手动断点调试一定会收获巨大。手写最小Agent不用框架自己写几十行循环跑通一个“给Agent加一个工具”的过程。这一步做完别人如果说Agent是玄学你心里会清楚它只是一个带反馈的循环。落到业务场景选一个工作中真实存在的重复性任务把它变成Agent应用。这个Demo就是你作品集里最有说服力的东西。前端同学最容易犯的错是急着学LangChain这类框架结果框架API背得溜底层原理一问三不知。框架迭代太快先把核心循环吃透框架随便换都影响不大。6.2 心态上的准备接受“被推翻”的常态学习过程中常有挫败感“昨天刚搞明白的架构今天看官方文档发现又改了”“好不容易调通的Prompt换个模型就失效了”。这些都是常态。我的心态建设方法是把学习定位成“能力积累”而不是“知识囤积”。模型会换、框架会改但我已经掌握了“怎么拆解问题、怎么调用工具、怎么控制上下文”这套方法论它才不会过时。我还养成了每周写复盘的习惯不是记流水账而是问题导向“这周我卡住的问题是什么卡了多久怎么解决的下周最先要解决哪个堵点”这样的复盘让我在第68天回看时能清晰地看到自己从“门外汉”到“能落地”的全过程。6.3 我接下来的扩展方向Day68不是终点后面的计划我已经列好了做RAG落地把团队历史文档接进Agent让内部问答真正有用起来。把Agent做成微前端能力让qiankun主应用里的子应用能独立注册自己的Agent插件互不干扰这是一套工程化考验正好好好磨一磨。探索富媒体输入讯飞实时语音转写大模型前端适配这种场景把用户语音实时转成文本喂给Agent这能大幅降低交互门槛。尝试声音输入 浏览器自动化做一个“帮我在内部系统里完成复杂表单填写”的Agent但要严格避开账号密码等敏感操作仅做合规的流程自动化。深度集成AI编程工具把Codex等前端开发插件用得更极致让AI辅助代码编写变成团队的默认工作方式再评估它能否进一步延伸到Code Review环节。内容可以不硬核但要可落地。每一条都是从当前阶段的痛点里长出来的不会为了追热点而追热点。回到最初的问题前端还能不能上车AI Agent我的答案是不上车才是真正的风险。前端工程师离用户最近天然能感知到需求又有工程化、交互体验、异步编程的手艺只要把Agent的底层原理啃透就完全能做出拿得出手的Agent应用。这68天我从一个连Token都要查半天的人变成了能在团队里做Agent技术分享的实践者中间没有捷径只有一个接一个的小Demo和小坑。希望这篇总结能帮正在观望的你少走一些弯路早一点迈出第一步。 
长河君 · 2026/10/27 3:33:41 · 阅读 1.2k 前端工程师68天实战AI Agent：从零到可落地应用全记录
今天是我在团队内部发起“前端AI Agent”学习实验的第68天。写下这篇东西不是想标榜什么而是想给同样在观望的前端同行一个真实参考一个干了多年纯前端、平时被业务需求追着跑的人怎么在两个月多一点的时间里从只会调接口到能独立搭出一个会自己调用工具解决问题的Agent。文章里没有玄学全部是这68天里踩过的坑、验证过的方法和还在坚持的路线希望能给想转方向又不知道从哪里下手的同学一点抓手。先说清楚我不是AI算法出身Vue/React写得多微前端、工程化、性能优化这些才是我的主战场。之所以花精力学AI Agent是因为我越来越清楚地意识到未来的前端应用不会停留在页面展示和交互而是会长出“能自己干活”的能力。用户不会满足于点一个按钮而是希望按钮背后有个Agent帮他走完整条流程。前端离用户最近也最应该掌握这种能力。这篇总结适合三类人看一是对AI Agent感兴趣但迟迟没动身的前端开发二是团队里想引入AI能力但不知如何落地的前端Leader三是正在准备转AI方向、想知道“前端底子到底能复用多少”的同学。我会把68天的路线规划、关键概念、实操Demo、踩坑实录全部摊开讲能捞多少看你自己动手的速度。1. 为什么一个前端Leader要跑去学AI Agent1.1 前端边界正在被AI改写焦虑不如动手做前端Leader这两年我能明显感觉到行业水温变了。以前我们焦虑的是框架又更新了、组件库又重构了、性能指标又红了现在大家焦虑的是——页面上那些表单、列表、筛选器正在被对话式交互一步步替代。用户想问的不是“帮我查一下三月份订单”而是直接输入这个需求让系统把订单列表、汇总表、异常提醒一次性给出来。这种转变对前端不是威胁反而是机会。因为AI Agent最终也要落地到界面、交互、状态管理、前端SDK集成这些地方。真正危险的不是AI会替换前端而是别的岗位拿着AI工具把前端该做的活也一起干了。我认识好几个后端和产品经理已经在用Coze、Dify搭Agent跑通业务流程前端反而成了被通知的一方。与其被跨界降维打击不如主动把自己的技能包升级。1.2 前端工程师做Agent的先天优势比想象中大很多前端同学觉得自己不懂算法、数学一般跟Agent有距离。实际上Agent工程化和算法研究是两码事。Agent落地涉及的大量环节恰恰是前端的强项交互与可视化Agent的运行状态、中间思考过程、工具调用日志都需要可视化呈现。前端能做推理过程展示、“思维链”条、Token消耗看板这是后端工程师不擅长的部分。异步与流式处理大模型全部是流式输出SSE、WebSocket、队列、重试、中断恢复这些和前端处理大文件上传、实时消息推送是同一套思路我连Web Worker都能用上。状态管理Agent多轮对话、多步工具调用的状态维护本质上就是复杂前端应用的状态管理。Redux、Zustand、Pinia那套心智模型完全迁移得过来。工程化与性能大模型返回慢前端能做骨架屏、流式逐字渲染、优先级调度组件库、SDK封装、跨平台适配这些更是看家本领。还有一个隐性优势是审美和产品感。Agent产品不是纯API拼接用户面对的是对话框节点编排器结果展示面板体验做得像不像原生应用前端的话语权非常重。1.3 我给自己定的68天目标拆解开始之前我只定了三个原则性目标避免学偏第1-20天看懂大模型基础概念明确Token、上下文窗口、Temperature、Prompt这些词到底是什么意思。第21-45天吃透Agent的四个核心模块——大模型、规划编排、工具调用、记忆管理并逐个动手做小实验。第46-68天用纯前端技术栈落地一个完整的Agent Demo部署到公网输出一篇可复盘的总结。没写太细因为我知道AI领域变化太快太细的计划大概率会被打脸。事实也证明中间至少调整了三次技术选型。但大的节奏没有乱这就是“以终为始”的价值。2. 68天学习路线实录从LLM基础到Agent落地2.1 阶段一大模型基础扫盲第1-20天这个阶段我先没碰框架老老实实看大模型本身的机制。重点做了四件事第一件事是搞懂“Token到底是什么”。这块很多人以为只是“字数统计”其实坑很多我后面单独用一节讲因为它在Agent开发里直接决定成本和质量。第二件事是理解“上下文窗口”和“Temperature”。一开始我写Prompt总想着把所有规则都塞进System Prompt结果每次对话都浪费大量Token还经常溢出。后来意识到上下文窗口就是模型一次能“记住”的全部内容超出部分不是被丢弃就是被截断所以Prompt和历史的取舍非常关键。第三件事是反复做“提示词实验”。我拿自己的学习笔记和代码片段当语料测不同写法对大模型输出的影响。比如同样的需求把“请优化下面的代码”改成“请扮演一位资深前端架构师从可维护性角度指出这段代码的3个问题并提出重构建议”输出的质量天差地别。第四件事是开始使用AI编程工具。以前我只用代码补全68天里我把Cursor、Continue这些插件全部用起来逼自己在日常业务开发中依赖AI辅助边写边理解AI回答问题的局限。理解这些工具后面也会变成Agent的一部分。2.2 阶段二Agent核心模块逐个击破第21-45天Agent不是简单调用几次大模型它有一套可拆解的架构。这个阶段我把Agent拆成四个模块每个模块用一周左右专门研究大模型Brain对比了不同模型的API出入参格式、推理速度、成本。发现绝大多数模型兼容OpenAI风格的接口用一套client基本能打通所有服务这大大降低了学习成本。规划编排Planning从最简单的ReAct模式入手——模型推理下一步该做什么、执行、观察结果、再推理。亲手写了一个十几行的循环把“思考-行动-观察”跑通才真正理解什么是Agent。工具调用Function Calling这是Agent落地最核心的一环。模型本身不联网但通过声明一堆工具查天气、搜文档、发请求模型可以根据用户需求选择合适工具并生成参数。前端的消息推送、文件上传、加密签名这些能力都可以包装成工具给Agent用。记忆管理Memory短期记忆就是当前对话上下文长期记忆需要把历史信息存到数据库或向量库。前端场景下我用IndexedDB和localStorage做过两种方案各有取舍。每个模块学完后我都用自己的话写一篇学习笔记然后录一个三分钟讲解视频存在自己电脑里。输出倒逼输入这个方法对我特别有效。2.3 阶段三从看教程到自己搭Demo第46-68天前45天我一直有个心理舒适区看别人的代码觉得都懂一关掉页面脑子一片空白。第46天我强迫自己不看任何教程白手起家搭Agent这才进入真正的涨分期。期间我试过两条路线一是用Dify、Coze这类低代码平台快速搭个Agent验证业务流程二是用代码手写Agent把细节做到可控。我的建议是两者都要用低代码平台帮你建立全局观手写代码帮你理解底层原理。我在低代码平台里调试一个“让小红书自动发消息”的Agent时理解了触发器、工作流节点、条件分支的组合方式然后才用代码实现同样的逻辑这样出错时能定位到具体环节不会被平台的黑盒困住。这个阶段的产出包括一个基于Node和浏览器环境的Agent运行沙箱、三套前端封装工具集、一个通过泛化Function Calling调起前端插件的示例、以及最终的完整业务Demo。具体细节我会在实操章节里展开。2.4 信息收集渠道和避坑路子学习过程中信息渠道选得不好会白白浪费大量时间。我个人用下来靠谱的有四类官方文档优先。大模型API文档、Agent框架官方教程、云厂商的Agent白皮书比如阿里云AI Agent白皮书虽然叫云厂商产出的但里面的架构图和对落地场景的盘点非常全都是最正统的知识源。开源项目源码。GitHub上star高的Agent项目直接读它们的核心代码比自己看二手博客强十倍。一线开发者的实践笔记。那些写“我搭了一个XX时候踩过的坑”的文章往往比教科书更实用当然也要注意时效性AI领域三个月前的经验可能就已经过时。行业大会和技术社区的热门话题。不是凑热闹而是通过“热搜词”判断现在行业到底在解决什么问题热词背后都是真需求。避坑方面我的心得是别一上来就背Prompt模板也别沉迷于各种Agent酷炫的演示Demo。演示价值不等于工程价值。要看到生产环境里那些没人愿意讲的部分——鉴权、重试、超时、熔断、成本控制、数据隔离这些才是把Agent做成产品的地方。3. 用前端视角拆透Agent架构和核心概念3.1 Agent到底是什么LLM编排工具记忆的组装体很多前端同学刚开始会混淆“聊天机器人”和“Agent”其实两者差别特别大。聊天机器人是“你说一句我回一句”数据是静态的Agent更像一个“实习生”你给它一个目标它自己拆解步骤、调用工具、检查结果、反复迭代直到把任务完成。我习惯用JavaScript开发里的比喻来解释Agent如果把大模型API比作一个超级聪明的“高阶函数”它输入一组消息输出一个回复。但单靠这个函数做不了实事因为模型本身就是个“大脑”没有手脚。Agent就是给这个大脑装上“手脚”的体系——规划器决定先做什么工具集提供能执行的动作记忆系统保存有用的信息内循环反复执行直到任务收敛。我写过一个最简的Agent循环代码去掉所有封装就四十多行async function agentLoop(task, tools, callLLM) { const messages [{ role: system, content: 你是前端助手请使用提供的工具完成用户请求。 }]; messages.push({ role: user, content: task }); let maxRounds 10; let result ; while (maxRounds-- 0) { const resp await callLLM(messages); const msg resp.choices[0].message; messages.push(msg); // 没有工具调用请求说明模型要给最终答案了 if (!msg.tool_calls || msg.tool_calls.length 0) { result msg.content; break; } // 逐个执行工具调用把结果作为新消息发回给模型 for (const call of msg.tool_calls) { const tool tools[call.function.name]; if (!tool) continue; const args JSON.parse(call.function.arguments); const toolResult await tool(args); messages.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(toolResult) }); } } return result; }这段代码就是Agent最核心的骨架。模型要求调用工具时返回带tool_calls的响应我们负责真去执行这些工具再把执行结果塞回对话让模型基于新信息继续推理。前端同学学会这个循环Agent的基础就通了。3.2 Token到底是什么意思算清楚这一笔账才敢上生产Token是模型处理文本的最小单位不是一个个汉字或英文单词而是通过分词器切出来的片段。英文里常见的是“一个单词约等于一个Token”或略多一点中文通常一个汉字占1-2个Token不同模型的分词器切法不一样具体数值以官方文档为准。在Agent开发中Token是整个成本系统的核心。因为每次API调用的价格不是按你输入的字数算而是按“实际消耗的Token数”算这个数等于单轮消息携带的全部历史Token 本次生成回复的Token。多轮对话历史一长Token量会指数级膨胀。我举个具体例子一次对话框长度约3万字历史消息占8K Token每轮用户发一条新消息约200 TokenAgent回复约500 Token。表面上一次交互只有700 Token的新成本可如果历史不清洗十个来回后历史就膨胀到10万Token接口直接报错费用也原地起飞。所以生产级Agent必须做三件事限制最大轮数、对历史做裁剪、必要时用“历史摘要”替代原始记录。我自己的经验是把超过5轮之前的消息先摘要成几句话成本能降70%对效果的影响不大。3.3 主流Agent架构单Agent、多Agent、工作流Agent根据近期项目实践和行业讨论当前主流的Agent架构可以归成三类单Agent模式一个Agent全程负责接收用户需求、拆解任务、调用工具、输出结果。实现简单适合任务边界清晰的场景比如“文档格式转换助手”。缺点是复杂任务容易在一棵树上吊死上下文也容易越积越乱。多Agent协作拆成“规划Agent”“执行Agent”“审查Agent”各管一段互相传递中间结果。效果更好但工程复杂度也高需要设计通信协议、容错机制、结果仲裁。我做过一个小实验让规划Agent拆解“布置会议室”的任务执行Agent调用日历工具和会议室查询工具审查Agent最后检查冲突比单Agent稳定得多。工作流AgentFlow-based先用可视化编排定义好分支和条件Agent严格按流程图跑。这是目前企业落地最多的方式可控性和可观测性强因为流程是确定的。我推荐前端团队首次做Agent需求时选这种模式起步而不是一上来就上“自由发挥”的Agent。选型其实很像前端技术选型没有最好的架构只有最匹配业务场景的架构。自由度高的Agent灵活但不可控确定性强的流程稳定但不够智能。我做技术方案评审时会先问业务方这个流程里可接受的最大不确定性是多少回答这个问题的过程中架构答案基本已经出来了。3.4 Function CallingAgent的“手”和“脚”Function Calling工具调用是值得重点练的地方。模型本身不联网也不会直接操作你的业务系统但我们可以给它一份工具清单每个工具包含名称、描述、参数结构JSON Schema。模型读了用户需求后根据语义生成一个结构化调用指令我们再在代码里真正执行这个指令。我封装前端业务的SysCall工具时写过这种定义{ name: frontend_shell, description: 在网页中执行前端操作比如路由跳转、打开弹窗、触发消息提示, parameters: { type: object, properties: { action: { type: string, enum: [navigate, open_modal, toast] }, payload: { type: object } }, required: [action] } }大模型看到这个工具定义在合适时机就会返回“我想调用frontend_shell工具参数是actionnavigate, payload/order/list”。我们执行后把结果回传给模型模型会基于结果继续回答用户。这个“API-API”的对接方式前端工程师理解起来非常顺畅因为本质上和我们平时封装SDK、对接后端接口的模式一模一样。4. 实操全记录纯前端技术栈落地Agent Demo4.1 技术选型为什么选纯前端方案学习阶段结束后我想做一个能验证前端能力的Agent Demo。一开始考虑过用Python后端Django来跑Agent这确实更稳妥因为很多Agent框架原生支持Python。但我的初衷是验证“前端能不能把Agent完整跑起来”所以定了纯前端路线运行环境浏览器为主Node.js为辅。前端逻辑全部用JavaScript/TypeScript。大模型接入通过后端代理或云函数转发API请求避免把密钥直接暴露在页面上。这块玩法和以前做“前端带签名请求”如出一辙。数据持久化浏览器端用IndexedDB存Agent的会话历史和工具调用记录做一个简单的“本地记忆”。部署方案用静态托管平台如Vercel、Netlify、Cloudflare Pages两层结构静态页面一层API代理一层用平台自带的Serverless函数。这样做的优点是把整个Agent产品的全链路都拴在前端可控范围内也方便我复盘每一步。缺点是需要处理浏览器CORS、跨域、密钥安全问题但这些恰好是前端老本行不算难。4.2 核心代码与业务场景我做的是“内部知识库问答纪要Agent”用户输入一句话Agent需要完成以下步骤判断意图、检索知识库我用一个静态JSON模拟、搜索翻译工具调一个公开翻译API、生成周报摘要最终把结果以流式方式渲染到页面上。核心模块分四块1消息管理与流式渲染// 使用 fetch ReadableStream 实现流式输出 async function streamChat(messages, onUpdate) { const response await fetch(/api/agent-chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ messages, stream: true }) }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按行解析 SSE 数据 const lines buffer.split(\n); buffer lines.pop() || ; lines.forEach(line { if (line.startsWith(data:)) { const json JSON.parse(line.slice(5).trim()); onUpdate(json); } }); } }这块实际上是前端基础能力的体现。大模型回复是流式到达的用户希望看到逐字输出的效果前端必须处理好这种“半开状态下的渲染”。用SSE协议解析数据把增量内容实时更新到界面一旦断流还要自动重连这些都是我以前做实时推送时练过的。2工具注册表const agentTools { searchKnowledge: async (keywords) { // 模拟检索内部知识库 JSON 文件 const index await fetch(/data/kb-index.json).then(r r.json()); return index .filter(doc doc.title.includes(keywords) || doc.tags.includes(keywords)) .slice(0, 5); }, translateText: async ({ text, target }) { // 调用公开翻译接口注意跨域时用代理 const res await fetch(/api/translate, { method: POST, body: JSON.stringify({ text, target }) }); return res.json(); }, generateSummary: async ({ sections }) { // 这项本来应该让模型来做但我先提供了一个本地的伪实现验证流程 return sections.map(s - ${s.name}: ${s.abstract}).join(\n); } };用代码把这些工具暴露给大模型让模型在回复里通过Function Calling驱动它们。每个工具函数的实现前端同学都很眼熟网络请求、数据处理、结果格式化和日常业务开发没什么两样。3记忆管理浏览器环境下短期记忆放在一个队列数组里长期记忆我用IndexedDB做了个简单的版本async function saveSession(sessionId, messages, summary) { const db await openDB(agent-memory, 1, { upgrade(db) { db.createObjectStore(sessions, { keyPath: id }); } }); const tx db.transaction(sessions, readwrite); tx.objectStore(sessions).put({ id: sessionId, messages, summary, updatedAt: Date.now() }); await tx.done; }跨页面刷新后Agent还能基于上次的会话摘要继续回答问题。虽然和正经向量库比不了但用来理解“记忆持久化”的原理足够了。下一步我可以再接入向量检索把相似历史会话找回来当上下文那就更接近真正的RAG了。4前端SDK封装与组件化Agent的能力我封装成了一个组件库对外暴露AgentChat /、AgentToolCallTimeline /、TokenUsageBadge /等组件。这样团队的微前端子应用可以直接引入使用主应用不需要关心Agent内部逻辑。做这个过程时我把之前已有的前端UI组件库经验全部迁移过来了包括定义事件的类型、支持暗色模式、可访问性处理。4.3 部署过程中的真实问题部署到纯静态托管平台时我踩了两个比较典型的坑第一个坑是跨域问题。浏览器直接调用大模型API会触发CORS且密钥暴露不安全。最后用Vercel的Serverless函数做了一层代理浏览器跟同域函数通信函数内部转发到模型API环境变量里存密钥。这一个动作就消除了跨域和密钥暴露两个问题。第二个坑是流式响应在代理层被缓冲了。Serverless函数默认会把后端响应完整取回来再返回导致前端半天等不到一个字。解决办法是在代理层设置Content-Type: text/event-stream并手动关闭缓冲把响应流实时转发给浏览器。部署完成的那一刻我在手机浏览器上打开页面对话框里逐字蹦出Agent的回答下面一行行显示工具调用记录——这种感觉跟当年第一次上线自己写的页面一样爽。5. 实际遇到的高频坑一条条说清楚5.1 Token消耗失控接口直接打爆实战中Token失控是我遇到的第一个大坑。有一轮Agent跑着跑着突然返回401错误一看账单才知道连续五次实验把几百万Token烧没了原因就是历史消息从未压缩。后来我加了“上下文管理器”每轮对话结束统计token占用超过阈值自动把前面的消息折叠成摘要。顺带一提调试阶段把max_tokens设小一点、多打印token数和费用能省很多钱。这个习惯值得养成。5.2 工具调用结果格式不规范Function Calling虽然强大但返回的结果有时会缺字段、错格式。我第一次用本地JSON模拟知识库时模型返回{keywords:订单}我代码里却用了args.word直接冒出undefined。解决方法是给工具函数加上入参校验和默认值并且在tools定义里把参数描述写得足够详细。最好在函数入口做一次JSON Schema校验防止脏数据污染整个链路。5.3 前端SDK兼容和流式断线浏览器端调用大模型时连接比较脆弱。移动端网络切换会导致SSE流中断用户看到回复停在半截。我做了三件事一是断线自动重连重连时带上之前收到的消息片段让模型从断点续写二是主动展示“连接中”状态避免用户以为系统死了三是请求超时设置合理值太短容易误杀太长体验又差。前端做Agent产品网络异常处理是必修课。5.4 上下文污染Agent聊着聊着就“人格分裂”多轮对话跑久了Agent会忘掉最初的设定或者把不同用户的上下文混在一起。这个在浏览器单会话里还好但一旦接入了多用户记忆隔离就成了大问题。我在项目里给每个会话生成独立的sessionId所有的记忆读写都带这个维度从源头避免串台。另外System Prompt里明确写清楚“你是XX场景的助手不要越界回答”也能缓解上下文污染。5.5 浏览器安全策略与爬虫防护这里顺带提一个很多人容易忽略的点Agent直接跑在前端意味着业务逻辑暴露在浏览器里。如果有人把JS源码拉下来逆向就能看到你的Prompt和工具接口地址。我做了一部分防护接口层增加签名校验和频控敏感信息不放前端包。前端防爬虫、防查看源码、防绕过等安全方案是另一套体系这里只提醒一点——Agent的能力边界越清晰暴露面越小不要把太多核心prompt和密钥写死在页面上。6. 给前端同学的转型建议和下一步6.1 学习路径建议先刻意立框架再往内填细节我的路线可以简化成四步跑通概念先理解大模型API、Token、Function Calling四个概念别急着写代码。看懂一个开源Agent项目找一个star高、代码量在一万行以内的项目读透它的核心循环。读不懂的地方手动断点调试一定会收获巨大。手写最小Agent不用框架自己写几十行循环跑通一个“给Agent加一个工具”的过程。这一步做完别人如果说Agent是玄学你心里会清楚它只是一个带反馈的循环。落到业务场景选一个工作中真实存在的重复性任务把它变成Agent应用。这个Demo就是你作品集里最有说服力的东西。前端同学最容易犯的错是急着学LangChain这类框架结果框架API背得溜底层原理一问三不知。框架迭代太快先把核心循环吃透框架随便换都影响不大。6.2 心态上的准备接受“被推翻”的常态学习过程中常有挫败感“昨天刚搞明白的架构今天看官方文档发现又改了”“好不容易调通的Prompt换个模型就失效了”。这些都是常态。我的心态建设方法是把学习定位成“能力积累”而不是“知识囤积”。模型会换、框架会改但我已经掌握了“怎么拆解问题、怎么调用工具、怎么控制上下文”这套方法论它才不会过时。我还养成了每周写复盘的习惯不是记流水账而是问题导向“这周我卡住的问题是什么卡了多久怎么解决的下周最先要解决哪个堵点”这样的复盘让我在第68天回看时能清晰地看到自己从“门外汉”到“能落地”的全过程。6.3 我接下来的扩展方向Day68不是终点后面的计划我已经列好了做RAG落地把团队历史文档接进Agent让内部问答真正有用起来。把Agent做成微前端能力让qiankun主应用里的子应用能独立注册自己的Agent插件互不干扰这是一套工程化考验正好好好磨一磨。探索富媒体输入讯飞实时语音转写大模型前端适配这种场景把用户语音实时转成文本喂给Agent这能大幅降低交互门槛。尝试声音输入 浏览器自动化做一个“帮我在内部系统里完成复杂表单填写”的Agent但要严格避开账号密码等敏感操作仅做合规的流程自动化。深度集成AI编程工具把Codex等前端开发插件用得更极致让AI辅助代码编写变成团队的默认工作方式再评估它能否进一步延伸到Code Review环节。内容可以不硬核但要可落地。每一条都是从当前阶段的痛点里长出来的不会为了追热点而追热点。回到最初的问题前端还能不能上车AI Agent我的答案是不上车才是真正的风险。前端工程师离用户最近天然能感知到需求又有工程化、交互体验、异步编程的手艺只要把Agent的底层原理啃透就完全能做出拿得出手的Agent应用。这68天我从一个连Token都要查半天的人变成了能在团队里做Agent技术分享的实践者中间没有捷径只有一个接一个的小Demo和小坑。希望这篇总结能帮正在观望的你少走一些弯路早一点迈出第一步。