今天是我从写了十年业务代码的前端正式转向AI Agent方向的第70天。白天我是一名前端Leader晚上九点以后回到工位才切回另一个自己学Python、跑LangGraph、做RAG、搭Agent部署。70天不算长但足够让我打破两件事一是对“前端已经到头”的焦虑二是对“AI Agent就是调大模型聊天”的错误判断。很多同行问我前端转AI Agent是不是等于转后端正好借着第70天这个节点把这段时间踩过的坑、看过的架构、总结出来的方法完整写一遍。文章会比较长适合两类人一类是还在犹豫要不要转型的前端同事另一类是想在团队里稍微懂点Agent原理的Manager。我尽量不堆术语所有技术概念都用最直白的方式讲。1. 为什么一个前端Leader会跳进AI Agent这个坑1.1 我先承认前端的天花板越来越明显干了十年前端从PC端到移动端、从jQuery到Vue再到React说实话传统前端工作里“纯界面层”的重复度已经非常高了。现在很多前端项目一大半时间花在搭页面、调组件、处理表单状态、对齐设计稿和接口文档上。这两年更明显组件库越来越完善低代码平台越来越强AI直接生成代码的能力也越来越吓人。搜索里经常能看到“ai agent 前端开发”、“codex 前端开发会使用的插件”、“前端开发skills”这类词说明大家已经默认AI能接手很大一部分编码工作。当一个岗位的核心技能可以被工具替代时Leader必须考虑团队下一步往哪走个人的路该怎么拓宽这是最现实的驱动力。另一个是业务方视角。不管做B端还是C端业务方现在聊的已经不是“做个表单页面”而是“能不能让系统自己完成一条完整的任务”。比如让AI自动整理商品资料、自动生成营销文案、自动跟进客户消息。这些需求本质上不再是页面功能而是Agent任务。业务方不管前端后端他们要的是“结果”。如果你只懂UI你没办法判断这个需求能不能做、该怎么做、风险在哪里。1.2 70天前我给自己定了一套笨但有效的节奏决定转型之后我没有立刻报课或者买一堆书而是按“输出倒逼输入”的方法给自己排了计划。计划的核心只有三条每天至少投入1.5小时每周产出一个可运行的小项目每天记录学习日志。标题里的“DAY70”就是这么来的我用一个文档天天记不追求文笔只追求把今天理解的东西写明白。时间安排上白天工作不推晚上和周末全身心扑进来。这段时间走完我的体感是第1-14天最痛苦因为你发现自己跟一个刚毕业的新人一样什么都不会第15-35天会进入“能看懂但写不出来”的瓶颈期第36-50天基本能照葫芦画瓢跑通一个简单Agent第51-70天开始敢做工程化改造了至少能把自己的想法放进Agent架构里。很多人问“70天够不够”如果把目标定成大厂算法研究员那70天只能是起点。但如果目标是能独立搭建一个符合业务场景的AI Agent应用70天按我的节奏是可行的。这也是我这篇文章最想传达的一个观点转型不是要把自己变成大模型专家而是把已有的工程能力迁移到新的技术栈上。2. 70天学习路线从零七级到真正做出Agent2.1 先补Python还是先学框架我的答案是同时进行这是新手最容易纠结的问题。网上有人推荐先从Python语法慢慢学有人说直接用LangGraph边做边学。我的建议偏向后者但要配一点前置条件。我不建议完全零基础的人直接看框架源码那样会吐。也不建议把Python学透再动手没那个必要。前端转Agent你需要的Python知识其实很聚焦基本语法、函数定义、异步async/await、类与对象、处理JSON、环境变量管理。这些东西大概两周就能上手因为我们有编程思维打底缺的只是语法习惯。等这三周过去再碰LangChain、LangGraph这类框架就舒服很多。我注意到现在也有人搜“基于rust语言ai agent”Rust做Agent是有潜力高性能、低资源、适合做运行时底层但目前主流Agent生态和示例仍然集中在Python除非你是专门研究中间件的高P否则业务型Agent还是先吃Python红利。说句经验之谈语言切换最大的坑不在语言本身而在于心智模型。前端是“事件循环驱动的UI状态机”Agent是“推理循环驱动的任务状态机”看起来都像状态机但本质不同。前者所有分支都是确定性的后者每一步都可能带随机性。这一点想通了代码反而是小事。2.2 Agent的五段核心循环理解它才能调试它从第25天开始我基本不看单个模型API的调用示例了开始逼自己理解一个Agent是怎么转起来的。这里我把核心循环拆成五个阶段这也是我看LangGraph文档时最重要的抽象任务理解把用户输入转成可执行目标拆出约束条件。规划把目标拆成子步骤判断每一步需要什么工具。执行调用工具或模型生成内容得到观察结果。记忆把结果存进短期上下文或长期向量库供后续决策。完成判断对比目标是否达成没达成就回到规划阶段继续循环达成就输出。刚开始我写Agent是这样的while True: result model_call(history tools) if result.is_final_answer: break action parse_action(result) observation call_tool(action) history.append(observation)这段代码很简单但它能帮我把概念变成可运行的东西。如果你也是前端出身可以把这想象成Redux的单向数据流dispatch一个action经过reducer得到一个新state再触发下一个action。Agent本质上就是让模型去决定下一个dispatch该是什么而工具调用就是执行副作用函数。2.3 “AI Agent token”到底要懂到哪个程度搜索热词里出现的“ai agent token是什么意思”我猜很多前端同学都困惑过。我自己的理解是token是模型理解文本的粒度中文字符通常一个汉字约对应1到1.5个token英文一个单词约1到2个token。你可以把它理解成模型面前的一盘小棋子模型一次最多只能看这么多棋子。上下文窗口就是这副棋盘的大小。普通开源模型多在8K、32K商业API大模型比如Claude、GPT系列有128K甚至更多。听起来很大但别高兴太早工具描述、历史对话、检索回来的资料块、系统提示词都会吃掉这个空间。我算过一个实际例子如果每轮对话平均800字约1200个token开32K上下文的模型只能容纳约26轮还要留出答复的空间。遇到工具返回长文本基本两三次就把窗口干穿。真正做Agent时你要把token当成预算来管理不是当成容量来使用。什么时候截断旧对话、什么时候把检索结果做摘要后再放回上下文、什么时候用向量数据库做召回而不是把所有文档全塞进来这些才是Agent工程师和“只会调用API”的人的分水岭。3. 前端经验不是没用而是换了一种用法3.1 前端在Agent应用里的3个落地位置很多前端同事觉得自己转Agent意味着放弃前端实际情况恰恰相反。Agent产品同样需要有界面而且这个界面比传统网页复杂得多。第一个位置是对话型交互界面。包括流式输出、渲染富文本、Markdown、代码高亮、消息卡片以及Agent思考过程的可视化。这个区域非常吃前端能力你需要在流式更新时保证UI状态不乱在用户发消息时快速锁定输入状态同时渲染出工具调用时间线。我们用过的组件库做传统B端没问题但放Agent场景就差一点我一般会针对思考过程单独写一个Timeline组件实时展示Step1、Step2和执行结果。第二个位置是Agent配置后台。给业务人员配置工具参数、配置角色提示、配置知识库、配置测试用例。这类后台需要大量脚手架和表单逻辑反而是前端最擅长的事情。如果团队在后端用SpringBoot搭建Agent服务前端用Vue做管理端中间协商好调度接口你会发现工作路径顺序是顺的。第三个位置是数据观测面板。Agent跑起来之后你需要观测每一轮对话的关键信息模型名、上下文窗口使用率、工具调用结果、耗时、失败率。这个面板本质上就是运维监控的前端翻版。我甚至见过一个团队后端只把事件流推给前端前端自己算token消耗、自己画趋势图协作很顺。3.2 Agent的“前后端分离”比Web前后端分离更严格有个热搜词我一眼就注意到了“open webui 需要后端服务 您正在使用不受支持的方法(仅运行前端服务)。请通过后端”。这个报错提示很典型说明很多从前端切入AI Agent的人会习惯性地认为“我只要起一个纯前端项目把前端代码部署上去就行”。但AI应用几乎不可能做纯前端。大模型API不能直接暴露在浏览器里会泄露密钥消息流需要后端做持久连接用户鉴权、会话存储、工具调用代理都需要后端能力。所以真正合理的架构是把前端只承担展示和交互把所有与模型通信、工具执行、知识检索相关的逻辑全部放在后端。有意思的是搜索词里还有“若依前后端分离前端代码在哪里”和“hzero前端开发”这类传统中后台的框架方法论放到Agent项目里依然成立。后端负责域名、权限、数据安全前端负责体验、交互、渲染这个基本分工完全没变。变的只是后端不再是简单返回CRUD数据而是要调度一个会推理的Agent runtime。我甚至在团队内部做过一次分享用一张表格给前端同事类比前端状态管理与Agent状态管理的关系传统前端AI Agent系统用户事件触发action模型推理决定下一步动作Redux/Pinia管理全局状态Memory/记忆模块管理上下文请求后端接口拿数据调用工具获取观察结果路由守卫控制页面访问完成条件判断Agent何时终止3.3 工具调用完全可以当成接口调试来对待我在第40天左右特别有体会Agent所谓“调用工具”和我们前端调后端接口没有本质区别。你定义一个工具名、描述、参数结构模型根据用户需求决定要不要调用调用时填参数后端执行完返回结果。从工程视角看这就是一次接口调用只是参数不是前端填的而是模型生成的。这就带来一个问题模型生成的参数经常瞎写可能多个字段、少个必填项、类型不对。传统前端后端联调还可以靠工具类型系统兜底Agent工具调用没人在运行前帮你检查。所以我习惯在每个工具入口做一层Schema校验不合法直接拒绝并把错误信息返回给模型让它重新生成参数。这样一次迭代成功率能从六成提到九成。把工具当成API来管理还有一个好处数据结构稳定复用性强。一张员工请假表、一个库存查询接口、一个内容发布方法都可以变成Agent工具前端只要负责把结果渲染出来。我会把工具调用记录同时发到前端相当于给每一步操作留痕方便用户反查。这个设计理念其实就是从我们熟知的接口Trace面板搬过来的。4. 70天里我踩过的坑按频次排序整理4.1 无限循环和Agent跑飞不要指望模型自觉停止第一次用LangGraph搭一个多步骤Agent时我自信满满让它自主规划结果5分钟过去了它一直在反复调用工具甚至偶尔自己给自己编造一个结果。当时我第一反应就是死循环了赶紧把日志拉出来看。排查下来问题主要有三个第一最终判断条件太模糊。我没有清楚告诉模型“当信息足够时立即终止”而是说“你认为合适时停止”这对模型来说过于开放。第二工具调用结果里“状态字段”不够明确导致模型分不清到底成功没有。第三缺少一个兜底节点循环次数超过N就直接终止回到人工复盘。我现在写Agent一定有强制性约束最大循环次数设成8到15次每一步必须返回结构化的中间结果关键分支再加一层规则判断。前端里做个路由守卫至少可以有效拦截无限跳转Agent同理。4.2 上下文爆炸Token计算和截断策略另一个高频坑是长会话崩掉。前一天还正常聊的Agent第二天用户连续发了一小时长消息突然开始胡言乱语。我最初以为是模型抽风后来查日志才发现上下文窗口已经逼近上限最前面的工具返回信息被挤掉了模型看不到早期约束。解决办法是按长度窗口滑动并给历史记录做摘要。我的策略是这样如果历史消息超过总上下文的60%先把最早的服务端数据归档只保留一句摘要。比如用户昨天问过的三个问题压缩成“用户昨天咨询了A、B、C三件事均已解决正在处理D”再把今天的内容完整保留。还要注意一个细节最关键的指令和最近一轮工具调用结果永远放在Prompt的优先级高位。模型对越靠后的内容权重越大把关键内容放在越靠后效果越好。这个我实测下来比靠前制定指令更有效。4.3 工具调用参数不听话改Schema比改Prompt快得多有一段时间我给Agent接了一个“查询销售订单”的工具输出结果一般是长文本。结果发现模型经常不填必填的shopId或者把date格式传成“昨天”。一开始我反复在提示词里加“一定要传shopId格式要正确”但效果不稳定偶尔还是会翻车。后来我换了个思路工具参数定义改成JSON Schema并对shopId字段加description和枚举示例date字段明确格式为YYYY-MM-DD。同时在后端做兜底校验参数不对就直接返回400让模型自己看错误信息重试。改完之后成功率提升非常明显。我现在跟同事强调最多的一句话就是后端定义好接口和错误码Agent才能像人一样学会怎么用工具。这个原则和前端调后端接口是完全一样的不要指望调用方自觉要指望契约和校验来保障。4.4 Open WebUI“仅运行前端服务”的报错其实是前后端架构问题很多刚接触AI前端开发的同学会用Open WebUI这类项目做本地管理界面会看到一个明确的提醒您正在使用不受支持的方法仅运行前端服务请通过后端。这里面有个很核心的工程概念AI应用必须走后端来管理模型连接与密钥不能直接把模型API地址暴露给浏览器。我自己也犯过这个错。最开始图省事在一个纯前端项目里直接调用模型API打开页面发现虽然能发消息但只要刷新页面翻到历史会话就失效而且密钥直接暴露在请求里安全完全不过关。后来我把请求改走后端转发才解决了持久化和安全问题。顺带一提前端安全技术也值得复用很多Agent管理后台同样需要防XSS、CSRF、防恶意爬取。搜索里的“前端网络安全”“防止爬虫防止查看页面源码”其实在Agent里同样要关注尤其你做了一个AI工具别人可能直接抓你的API接口把能力白嫖走。5. 如果让我重来给想转AI Agent的人一点心得5.1 最少就能跑通的路先做最小闭环如果你也想用最少的时间和成本在两周内做出一个真正能演示的Agent我建议不要一上来就研究LangGraph、Dify这类底层编排更不要先啃Rust。最优路径是先把一个大模型API摸熟然后只做一件事把一个固定业务比如“自动生成商品标题”通过一个工具函数和一个系统提示词跑出一个能调用的Agent雏形。等这个雏形成功了再逐步加工具、加记忆、加规划。很多人容易倒过来一开始就搭复杂的多Agent架构Agent之间互相调用一个崩了全都凉。我的经验是Agent越简单越容易调试越容易debug也就越容易学习。第1周学Python基础、看懂API调用完成一个单纯聊天机器人。第2周写一个单一工具调用比如查询天气、查库存学会处理工具返回结果。第3周引入多步规划和记忆让Agent记录中间结果并完成更复杂的任务。第4周之后再考虑上RAG、上向量库、上LangGraph状态机。到第9-12周把项目工程化加上用户鉴权、日志、监控、部署。这个节奏保守但稳妥适合工作党。别拿网上那些“7天冲刺AI Agent工程师”的课程节奏套自己能坚持超过两周就算赢。5.2 前端Leader要注意的“三不一无”最后想聊一下心态。你在团队里是带人的Leader转型选择和应届生完全不一样你没法完全清零重来也没有大把时间试错。这70天里我给自己定了几条纪律想分享给同样在带团队的朋友一是不要在小步快跑阶段内卷。前端Leader有一种职业病上手任何新东西都会忍不住先优化工具链、做脚手架、封装组件。学会Python时我也这样结果一周时间都在折腾环境配置和代码格式化后来才醒悟先把功能跑通比什么都重要。二是不要拿前端的“确定性”去要求一切。Agent有天然的随机性同样输入两次结果可能不一样。你如果还带着“必须复现Bug”的老开发习惯会被搞疯。设计Agent时要有兜底策略而不是追求每一步都完美。三是不要把团队牛马兄弟丢下自己单飞。前端Leader带团队转AI的价值在于“组团升级”。我会把Agent相关学习内容拆成快手短视频分享给组员每周一次十分钟同步。能带团队一起认知升级比一个人闷头看更有效率。四是不要害怕“不是科班出身”。Agent这个领域太新了科班没学过“AI Agent架构”这门课所有人都是边做边学。前端同学的交互理解、界面设计、工程化经验在Agent产品里反而是稀缺能力。最后分享我自己验证过的一个小技巧如果你正在尝试把现有业务流程变成Agent有一个特别低成本的做法先把你手头经常要用的一个后端接口包装成工具接进你选的Agent框架里。然后在System Prompt里加一句“当你需要了解该业务信息时务必先调用查询工具把结果整理后告知用户”再去测试。你会很直观地看到Agent是怎么走过去“查询-整理-回复”的闭环。我在第70天最大的体会是这个领域确实深但并不是无路可走。前端积累的架构思维、接口思维、用户体验思维都会转成你在Agent时代的独特优势。剩下的就是在每天夜深人静时把那行看似普通的循环代码继续跑下去。