今天是第七十天。说实话写这条动态的时候我自己都有点恍惚。一个干了快十年的前端从组里带七八个人的Leader位置跳进AI Agent这个跑道连续记录了七十天。这个决定在周围人看来很突然但只有我自己清楚这份转型焦虑攒了多久。前端框架年年换、业务逻辑越写越薄每天最深的感受是“在做页面”而不是“在做产品”。而AI Agent这个窗口恰好给了我一个重新做决策者的机会——不再是等产品给图、等后端给接口而是自己去设计一条“感知、思考、行动”的完整链路。这篇复盘不是教程是我七十天踩坑记录的浓缩版。我尽量按照“为什么这么选、实际怎么拆、代码怎么落、遇到什么坑”的逻辑来写希望能给同样处在转型路口的前端同行一点参照。为什么是七十天而不是三十天或者一百天因为三十天只够扫盲一百天战线又太长在职状态根本扛不住。七十天恰好让我走完一个从理论到实践的小闭环理解Transformer基本概念、跑通Agent主流架构、手写第一个可用的Agent工具链、再把前端工程沉淀进去。这里面很多东西和前端底层思维是相通的只是换了层皮。下面我把这七十天拆成几个关键模块每一块都是我真实做过的不是网上抄来的综述。1. 写在Day70前端Leader为什么非得转这一趟1.1 Leader位置的隐形天花板我在原团队带前端表面上是技术管理实际上有一大半精力花在协调UI走查、接口联调、版本发布这些事上。框架层面Vue也好React也好新的东西主要解决的是开发者体验问题很难直接影响业务价值。更要命的是AI编程工具普及之后初级前端写页面这件事被压缩得很厉害——我自己用AI辅助写组件效率至少翻一倍。这时我意识到如果我的核心能力只是“更快地写界面”那我迟早会被工具取代而不是驾驭工具。AI Agent则完全是另一个物种。它要求开发者把业务流程抽象成“大模型决策工具执行记忆管理”的组合这正好是前端Leader天天在做的事情的变大版把组件抽象成Agent模块把状态管理抽象成上下文管理把事件驱动抽象成工具调用链。这个认知让我下定了决心——不是逃离前端而是把前端积累的工程化经验迁移到一个更有复利效应的领域。1.2 盘点资产前端经验里哪些能直接平移很多前端朋友问我转行是不是从零开始我说不是至少这几项能力是直接平移的组件化思维一个React/Vue组件有props、有生命周期、有状态。一个Agent也有配置参数、有运行循环、有记忆状态。我第一天学Agent架构时直接把组件生命周期映射到Agent的初始化、推理、工具调用、结果回写理解速度飞快。异步流程掌控前端最擅长的就是处理异步——Promise、事件循环、竞态条件。Agent跑起来之后模型决策是异步的工具调用是异步的结果返回也是异步的这套调度感觉和我处理并发请求一模一样。用户体验设计Agent不只是个API它最终要给用户看。前端Leader对交互细节的敏感度在做Chat UI、工具结果展示、流式输出体验时是巨大的优势。这点我在后面接公司内部Agent平台时体会特别深。1.3 七十天的目标与三个里程碑我给自己定的路径不是上来就啃论文而是以工程落地为导向分了三个阶段Day 1-14 认知重建期搞懂大模型不是魔法它是概率系统。重点消化了Token、上下文窗口、温度参数、Function Calling这些基础概念。产出是一篇给自己团队讲的内部分享用前端比喻讲完Attention机制。Day 15-30 架构拆解期研究主流Agent架构看阿里云AI Agent白皮书、读LangChain/OpenAI官方文档把Agent拆成模型、记忆、工具、编排四层。产出是一张手绘的架构脑图现在贴在工位上。Day 31-70 工程落地期参与构建一个内部用的Agent原型从前端SDK接入到纯前端部署Demo再到工具调用链的容错处理。这篇文章的核心内容基本都来自这个阶段。七十天下来我的体感是前端工程师转Agent开发最大的障碍不是技术而是“心态上的归零”。只要愿意承认“大模型这套逻辑和我以前写代码的逻辑不一样”后面的学习曲线其实很平缓。2. 70天核心路线复盘Agent主流架构与我的选型思考2.1 理解Agent的“三件套”模型、记忆、工具Agent到底是什么我用一个外包项目负责人的例子来给团队解释大模型就是那个能说会道但容易忘事的实习生记忆系统是他随身带的笔记本工具是他能调用的公司资源查库、发邮件、调用API。没有工具的Agent只是个聊天机器人没有记忆的Agent每次对话都会失忆没有好模型的Agent连活都干不动。架构拆开之后我发现它和前端的经典分层其实能对上号模型层负责语言理解与生成类比前端的渲染引擎记忆层负责存储和检索历史状态类比前端的状态管理器工具层负责对接外部系统类比前端的API请求层编排层负责决定“下一步调用哪个工具”类比前端的路由调度这个类比让我团队的同事也能快速理解Agent不至于被新概念吓住。实际开发时我优先选有Function Calling能力的模型因为这决定了工具调用的稳定程度。2.2 选型复盘Python为主Rust留了一个“备胎”热词里有人问“基于Rust语言AI Agent”我也研究了一下。不可否认Rust的性能和类型安全在Agent领域很有想象力万一以后要处理高并发的Agent推理调度Rust是个不错的选择。但目前主流Agent框架的生态还是偏向PythonLangChain、CrewAI、LlamaIndex、Dify这些工具链的文档、社区、预训练模型接入基本都是Python优先。我的建议很简单生产力优先。个人项目或小团队搞Agent先用Python快速验证等吞吐量上来了再考虑用Rust重写核心热路径。前端同学如果对Rust的ownership概念感兴趣可以把它当“第二个语言”慢慢学但不要让它挡住第一公里的路。我自己在Day 40的时候用Rust写了几个小工具练手发现类型系统带来的安全感确实很强但迭代速度比Python慢了不只一倍。2.3 前端架构师视角看编排层ReAct与Plan-and-Execute编排层是Agent的“大脑皮层”最主流的两种模式是ReAct和Plan-and-Execute。ReAct的思路是边思考边行动——每走一步都跟环境互动一次把结果反馈给模型再决定下一步Plan-and-Execute则是先制订完整计划然后按计划执行。前者灵活但容易跑偏后者稳定但应对变化弱。这就像前端里的两套路由方案一个是运行时动态路由灵活但要在代码里小心处理边界一个是静态路由表可维护但缺乏弹性。真正的产品级Agent通常会两层结合先规划一个大方向再在每一步用ReAct动态决策。这个阶段我通过一个“公司周报自动汇总Agent”的案例验证了编排层的作用它要依次调用“读取日志API、提取关键事件、生成周报、发送到群机器人”整个链路如果缺少编排层稍长一点的指令就会让模型陷入混乱。3. 实操手记从若依前端到Open WebUIAgent与前端工程的第一次握手3.1 若依前后端分离项目里前端代码到底在哪“若依前后端分离前端代码在哪里”这个热搜词一看就知道很多前端新手卡在目录结构上。若依RuoYi是很典型的前后端分离脚手架Vue版本的前端工程独立在ruoyi-ui目录下和后端Java工程完全分开。如果你想在这个项目里加一个Agent对话功能要动手的是这几个位置src/api/按模块组织的API请求定义Agent相关接口建议新建src/api/agent.jssrc/views/页面组件所在地对话界面可以建src/views/agent/index.vuesrc/router/动态路由配置新增页面需要在这里登记vite.config.js开发环境的代理配置把/api代理到后端地址我在Day 47的时候把公司内部Agent原型接到了若依项目的登录小站上最核心的改造就是新建一个agent页面然后通过src/utils/request.js里二次封装的axios发起流式请求。这里最容易踩的坑是跨域前端页面在8080端口Agent后端在8088端口没有代理配置时浏览器会直接拦截请求。解法是在vite.config.js里配proxy不是在后端配CORS——我在生产环境上因为这个问题排查了一个下午。3.2 Open WebUI的经典报错为什么必须跑后端服务热词原话是“Open WebUI 需要后端服务 您正在使用不受支持的方法仅运行前端服务。请通过后端”。这个报错我第32天就见过当时很困惑——一个Web界面为什么不能拆成纯静态页面后来看了源码才明白Open WebUI虽然看起来是前端项目但它本质是全栈应用FastAPI后端负责管理会话、用户、模型路由前端页面只是后端服务的渲染层。如果你只启动了前端静态服务比如npm run dev或者用静态服务器指到build目录后端接口全部不可用它就会抛出这个提示。正确姿势是直接用Docker跑完整服务一个命令同时拉起前后端docker run -d -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OPENAI_API_BASE_URLhttp://你的模型网关地址 \ -e OPENAI_API_KEY你的密钥 \ ghcr.io/open-webui/open-webui:main这里给前端同事一个提醒见到类似“仅运行前端服务”的警告先去找项目的服务端入口。很多工具型开源项目前端只是壳真正的逻辑都在后端别陷入“前端思维”出不来。3.3 接入Agent平台前端SDK的正确打开方式公司引进了内部Agent平台提供一套前端SDK让业务系统快速接入对话能力。第一步其实很简单在HTML里引一个JS文件然后在指定容器上实例化一个聊天组件。真正让我头疼的是参数调试sessionId通常业务侧生成用于维持会话上下文。如果不传每个请求都是“失忆”的stream是否启用流式输出前端表现为打字机效果需要处理增量渲染onMessage事件流式返回的每一段内容都要在这里累加刷新我踩的坑是忘了处理“用户连发消息”的竞态。对话界面正常情况是一问一答但用户手快连续发两条SDK内部的处理如果没有队列两个请求的响应顺序就可能错乱——后发的先回来先发的后回来界面就乱套了。后来我在SDK外层包了一个MessageQueue用前端最基础的Promise链把请求串行化问题才解决。这种问题非前端背景的开发者可能要想很久对我倒是顺手就处理了。3.4 Token到底是什么一次请求花多少钱“AI Agent token是什么意思”也是热搜词。Token是模型输入输出的最小计量单位可以粗略理解为“词的碎片”。一个英文单词通常等于1到2个Token一个汉字约等于1到2个Token。API费用按Token计费输入和输出的单价往往不一样。给个直观的计算过程假设你发了一条帮我总结一下本季度前端团队的绩效数据这行字大约20个Token。Agent要把这条指令和预设的System Prompt可能几百Token、历史上下文可能几千Token一起发给模型假设总输入是5000 Token输出是500 Token。如果模型单价是输入0.03元/千Token、输出0.06元/千Token那这一次调用的成本就是0.150.03约0.18元。单看很少但做成Agent应用一次任务可能要调用几十次模型成本就变成几块钱了。所以做Agent工程Token消耗就是“运行时成本”是必须监控的指标。我在Day 58的时候给内部Agent加了一个“上下文裁剪”策略超长对话只保留最近N轮完整消息更早的内容转为摘要存入记忆——这个策略把单任务Token开销降低了40%效果非常明显。4. 前端工程能力变形记Worker、安全、部署全都换了个用法4.1 大文件上传与Worker从传Excel到注入Agent知识库“前端使用Worker上传大文件”原本是处理“上传几十MB的Excel/压缩包”的常规需求。到了Agent场景这个能力直接变成了“知识库文件导入”。我做的Agent需要支持上传200MB以内的PDF并自动切分索引直接在UI线程做校验会让页面卡死所以我复用了以前的分片上传方案// 主线程只负责分发具体读文件交给Worker const worker new Worker(/workers/file-uploader.js); worker.postMessage({ file, chunkSize: 5 * 1024 * 1024, fileHash }); worker.onmessage (e) { const { chunkIndex, hash, result } e.data; if (result uploaded) { // 触发断点续传的下一片 uploadNext(chunkIndex 1); } };Worker里面做文件的MD5分片哈希计算、读取ArrayBuffer、并发上传主线程始终保持流畅。Agent服务端拿到完整文件后再做解析、清洗、向量化写入记忆库。这里面的经验是前端不得罪用户的体验优化到了Agent时代就是不得罪“知识库导入”这个入口。凡是超过20MB的导入任务我都会条件反射地想到Worker这已经是脑子里的肌肉记忆了。4.2 前端安全技术的边界防爬、防源码查看的真正解法热词里有一串关于前端安全的“防止爬虫、防止查看页面源码”。我不得不说实话纯前端无法根治这些安全问题。只要代码到达了浏览器就一定会被用户看到只要请求能从浏览器发起就一定会被脚本模拟。JS混淆只能提高阅读门槛不能阻止真正的攻击者动态加密接口参数也只能增加爬取成本不能杜绝爬虫。真正有效的防线是后端和风控层的组合接口鉴权用短期Token绑定设备指纹和用户行为敏感数据绝不渲染到DOM用Canvas绘制替代文字节点接口频率限制、行为检测鼠标轨迹、请求间隔核心业务逻辑尽量下沉到服务端前端只做展示和交互Agent时代一个重要的变化是爬虫不再需要写代码只要喂给Agent一个目标它能自动组合工具去抓取数据。所以“反爬虫”现在更像“反Agent”的攻防战。我的建议是前端工程师花点时间了解风控设计不要指望混淆代码能带来安全感。4.3 纯前端线上免费部署个人Agent Demo上线的三个方案“纯前端线上免费部署”是个人开发者的刚需。如果只想让一个Agent前端Demo跑起来给人看有这几个免费方案GitHub Pages适合纯静态站点仓库一推Actions自动部署Cloudflare Pages全球CDN快绑定自定义域名免费Vercel对前端体验最好支持环境变量适合Next.js/Vue项目但必须提醒Agent应用一定不能把API Key写在前端代码里。前端是拿不到后端的密钥全部会暴露。正确做法是通过Serverless函数如Cloudflare Workers、Vercel Serverless Function做代理转发请求先到你的代理函数由函数把Key注入到上游API请求再返回结果给浏览器。这是我Day 62踩过的坑——Demo发布三小时后我的个人API Key就被爬虫盗刷了。记住纯前端部署只是展示壳真正的Agent后端必须藏在服务端或者Serverless背后。5. 实战案例一个“自动发消息”Agent的技术拆解与反思5.1 应用场景和合规边界热搜词里有“让小红书自动发消息”我确实拿它做过研究案例但必须先说清楚任何自动化操作都不能违反平台规则、不能用于骚扰营销。我做这个案例的初衷是技术验证——打通“内容生成推送执行”这条链路用在自家业务后台的合规通知场景而不是去搞灰产。这个需求的本质是让Agent在特定时间节点自动生成一段消息并推送给指定对象。拆开看就是三个能力定时触发、内容生成、消息发送。这三件事在前端后端都有成熟方案难点在于怎么编排以及怎么防止Agent“过度发挥”。5.2 链路拆解与关键代码我实现了最小可用版本核心是给Agent挂一个“定时任务工具”和一个“消息推送工具”# 伪代码示意Agent自动消息任务的工具注册 tool def send_message(channel: str, content: str): 发送一条消息到指定渠道 # 实际调用消息平台OpenAPI携带签名参数 return api.post(f/v1/{channel}/message, data{content: content}) tool def schedule_task(cron: str, prompt: str): 注册一个定时任务cron表达式控制触发时间 scheduler.add_job(run_agent_task, triggerCronTrigger.from_crontab(cron), args[prompt])定时触发后Agent根据prompt生成内容然后调用send_message发送。这里最关键的工程细节是确认机制在发送前增加一个“预发送检查”节点核对生成内容是否包含违规词、是否超过长度限制、是否存在重复发送。我在实验时遇到过Agent连续发送五遍同样内容的情况——因为执行工具后的反馈没有正确返回给模型模型以为第一次没发送成功。这个问题的根治方法有两个一是把工具调用标记为幂等同一个任务ID不允许重复执行二是设置最大连续调用次数超过就暂停整个任务。5.3 实测数据与反思我跑了七天定时测试发现Agent生成的文案确实比模板灵活但输出质量波动很大——有时候能区分用户昵称并做个性化开头有时候会把两个用户的昵称搞混。原因在于上下文里加载的用户信息列表太长超出了模型注意力聚焦范围。解决办法是改用“检索后拼接”的策略每次发送前只取当前时间窗口相关的几条用户信息而不是一次性全量塞给模型。这个案例给我的最大教训是Agent应用落地比“模型聪明程度”更重要的是“边界设计”——它再怎么聪明也得在安全围栏里干活。前端工程师做交互时天然习惯“防用户误操作”到了Agent里就是“防Agent幻觉操作”。6. DAY70常见问题与排查技巧实录6.1 高频问题速查表我这七十天遇到的大概率也是后来者会遇到的整理成表如下问题现象根本原因排查与解决建议Open WebUI提示“仅运行前端服务”只启动了前端静态服务缺少FastAPI后端用Docker Compose完整启动而不是单独build前端Agent调用工具后“假装成功”工具返回结果格式不对模型无法解析真实状态让工具返回结构化JSON并在提示词中强调“必须读取工具结果”Token消耗暴涨上下文无限增长每轮都全量发送历史增加上下文裁剪与摘要压缩策略用户连发消息导致回复错乱请求并发无消息排队前端SDK外层加串行消息队列前端页面跨域开发环境代理未配置Vite代理或后端的CORS白名单二选一别同时纠结API Key泄漏盗刷Key写进了前端静态页面立即轮换密钥改用Serverless代理转发6.2 前端视角的Agent调试三板斧调试Agent比调试前端页面难多了因为问题可能出在模型、提示词、工具、上下文四个环节的任意组合。我总结了三个适用性很强的技巧第一招日志回放。把每一次模型请求的System Prompt、用户输入、工具输出、模型输出全部记录成带时间的结构化日志。排查问题时先看是哪一步和预期不符再用同一组输入去复现。不做这件事Agent出问题基本只能靠猜。第二招简化工具。Agent调用链条很长出错时先砍到只剩一个工具跑通再加第二个。这个思路和前端排查“快速定位是哪个组件崩溃”一模一样要相信二分法是万能的。第三招加“护栏”。只要是Agent主动决策调用外部系统发消息、改数据、删文件就要加人工审批或条件校验。最稳妥的做法是在工具外层加一个“允许列表”和“拒绝列表”不在允许列表里的操作一律返回“无权执行”。6.3 给同行的一条提醒团队协作里最容易撕裂的点最后一条经验给同样带团队的同学。前端团队接Agent项目最容易出问题的不是技术而是“职责边界不清”。Agent工程里谁负责Prompt、谁负责编排逻辑、谁负责工具开发、谁负责前端体验如果不提前定义好最后一定会变成前端等模型调好才能测UI算法等工具做好才能调模型产品等演示能跑才来提需求。我用了一个最土的方法解决每天站会必须回答一个问题——“今天你要为哪个Agent行为负责”。让团队成员明白Prompt也是代码工具的测试用例和前端组件的测试用例同样重要。这个理念统一之后协作效率至少提升三分之一。七十天走到今天我不再纠结“前端有没有未来”这种问题。前端没有消失它变成了AI Agent触达用户的那层关键界面。只要还有人在浏览器里点击、滚动、对话就需要有人把模型输出变成让人看得懂、操作得顺的体验。而Agent的工具调用、上下文、部署防线这些新技能其实都是旧知识的重新组合。我还在路上后面准备再花三十天把记忆系统和评测体系做扎实。到时候再来分享第二轮复盘。