Day72。说实话今天早上在备忘录里写下这个数字时自己都愣了一下——一个白天要排需求、做评审、处理团队琐事的在职前端Leader居然连续72天在深夜和AI Agent死磕。这篇文章不是什么成功学复盘就是给自己和同样在观望的人一份真实的阶段记录为什么我会从成熟的组件化开发往Agent方向转、这72天到底是怎么拆解学习计划的、目前正在做的一个智能体项目卡在了哪里、又踩了多少坑。如果你也纠结“要不要学”或者已经开了一点头但总觉得学不进去这篇应该能给你一个非常具体的参照系。1. 转行前夜前端Leader为什么盯上AI Agent1.1 不是“被替代”是“应用层正在被重写”我做了快十年前端这几年带团队做的都是管理后台、数据报表、中台系统。业务方反复提一句话能不能让系统“更聪明一点”。过去所谓的聪明顶多就是搜索框加个联想词表格加个排序筛选。但这一两年用户习惯开始变了大家已经默认“直接用一句话指挥系统完成任务”才是正常交互而不是在一堆菜单里找按钮。这个变化直接影响前端Leader的处境前端不只是“页面皮肤”而是整个智能体产品的交互载体。更深一层的原因是AI Agent会让软件交互范式从“人找功能”变成“功能找人”。以前是人去理解系统怎么用现在是系统去理解人想干嘛。谁离用户最近前端。谁最懂体验边界还是前端。所以我判断未来两三年会有一轮新的应用层重构如果那时候我不在现场那才是真正的职业危机。说白了我不是怕被AI替代而是怕整个应用层被重写时我没有参与权。1.2 盘点自己的技术栈哪些能用哪些是真缺口决定转Agent之后我先做了一次很冷静的技能盘点。前端Leader手里有三个大优势第一TypeScript整个体系可以直接覆盖Agent的工具层、状态层和运行时不用像很多Python教程里那样搞一套新的工程结构第二组件化开发的经验能快速搭建Agent前端界面游刃有余第三多年处理复杂业务状态的心智模型和Agent的“多步骤任务管理”天然对路。但缺口也非常明显大模型的能力边界我完全没概念Prompt到底怎么设计Function Calling怎么定义RAG的召回和切片怎么做Agent的循环逻辑怎么控制这些全是知识盲区。前端架构里的“状态机”概念到了Agent这边就变成了“思考-调用工具-观察结果-再思考”的循环这是一个全新的心智模型。所以我在DAY1就给自己定过规矩我不是要去当算法工程师而是做“能把大模型变成产品体验”的Agent应用架构师。这个定位直接决定了后面所有学习的取舍。2. DAY1-72学习路线拆解我是怎么一步步走过来的2.1 DAY1-10先摸清大模型的能力边界禁止碰框架前10天我给自己下了一道死命令不写业务代码不碰任何Agent编排框架每天就干一件事——反复调用大模型API做各种微小的实验。比如总结一篇长文、从非结构化文本里抽出一张结构化表、让模型扮演某个角色输出指定口吻的内容。这阶段的核心目标是建立“模型直觉”。十天下来最重要的感悟是大模型不是数据库它不知道客观事实只知道根据上下文生成概率最大的字符。这句话听起来很基础但会影响后面的每一个设计决策。同时我也发现Prompt写法对结果的影响远超预期同样一个请求加一句“先列出你的思考步骤”和完全不给思维引导输出质量完全是两个量级。所以我从DAY2开始就训练自己按同一个模板写Prompt背景信息、角色定位、任务目标、输出格式缺一不可。2.2 DAY11-40用“工具调用”理解Agent的循环脑回路过了前10天我才开始接触Agent真正的核心机制工具调用。我的学习方式不是抱着框架教程啃而是自己手写一个极小的多工具Agent循环。核心就三步把用户诉求交给大模型模型决定调用哪个工具并给出参数我执行工具后把结果当作新上下文再交回模型。这个循环跑通之后对Agent的理解就彻底从“玄学”变成了“工程”。这一步里我用TypeScript写了一个最小实现说夸张一点它改变了我对整个行业的理解。之前觉得Agent是某种黑魔法现在才知道本质就是一个while循环加上若干工具脚本。第20天左右我开始把搜索、计算、查库存这种能力挂到Agent上做了一个“帮我安排会议”的Demo模型负责理解意图工具负责操作真实系统前端只需要展示过程。那个周末我把这个Demo演示给团队看第一次觉得前面20天没白熬。2.3 DAY41-72把Agent装进前端做成可交付的原型学习进入第三个阶段后我开始关注前端和Agent的深度结合。这个阶段明显比写Demo痛苦得多因为真实场景里Agent不会永远顺利接口超时、模型返回格式不对、工具执行失败、用户中途改变主意任何一个环节断了整个体验就崩了。所以从DAY41开始我几乎都在处理“Agent状态管理”和“前端交互反馈”的问题。具体来说我把一次Agent任务当成一个有限状态机来处理初始状态、等待工具结果、生成中、完成、失败、人工介入。界面上的每个按钮、每个加载态、每个可编辑卡片都要跟这个状态机严格对应。另一个重点是流式输出模型生成的内容不是一次性返回的是一块一块吐出来的前端要做增量渲染还要处理中途断流。我在这个阶段被折腾得很惨但也正是这些痛苦让我真正理解了Agent应用和传统前端最本质的区别前者是一个有自主性的系统前端不是“显示结果”而是在“参与协作”。3. 第72天现场一个文案智能体的完整实操3.1 需求场景与整体架构目前我手上正在打磨的项目是给公司内部市场同事用的“文案智能体”。业务输入一个活动主题、目标人群和期望语气Agent自动完成两件事先从内部知识库检索往期活动数据再结合品牌规范生成三版风格不同的文案并在界面上提供一键改写和二次编辑。这个项目是我自己在团队里发起的“Agent落地试点”目的很现实不搞一个这种真实用例学再多概念都没法转岗。整体架构拆成三层最底层是模型能力和“检索工具”中间层是Agent运行时负责编排工具调用、管理上下文最上层是前端配置面板和流式展示层。后端我选择了直接落在Node.js环境里原因很简单前端团队现有基建都在这个技术栈里组织心智负担最小。3.2 用TypeScript写一个最小Agent闭环这一节直接上核心代码。我不做任何框架封装只用最原始的循环来表达原理type Tool { name: string; description: string; parameters: Recordstring, unknown; execute: (args: any) Promisestring; }; const tools: Tool[] [ { name: searchInternalDocs, description: 根据关键词检索内部活动资料库返回命中的文本片段。, parameters: { type: object, properties: { keyword: { type: string, description: 检索关键词 } }, required: [keyword] }, execute: async ({ keyword }) { return await searchDocsApi(keyword); } } ]; async function runAgent(userRequest: string) { let messages [ { role: system, content: 你是品牌文案助手只能调用可用工具获取真实信息禁止编造。 }, { role: user, content: userRequest } ]; for (let i 0; i 5; i) { const response await callChatModel({ messages, tools: tools.map(({ name, description, parameters }) ({ type: function, function: { name, description, parameters } })) }); const shouldCallTool response.tool_calls response.tool_calls.length 0; if (!shouldCallTool) { // 模型认为已经可以输出最终答案 return response.content; } for (const call of response.tool_calls) { const tool tools.find((t) t.name call.function.name); if (!tool) continue; // 执行工具时把真实错误也返回给模型增强稳定性 try { const result await tool.execute(JSON.parse(call.function.arguments)); messages.push({ role: tool, tool_call_id: call.id, content: typeof result string ? result : JSON.stringify(result) }); } catch (err) { messages.push({ role: tool, tool_call_id: call.id, content: 工具执行出错: ${err.message} }); } } } throw new Error(超过最大循环次数需要强制中断); }这段代码是整个Agent的地基核心就一个for循环模型负责决策我把决策落到真实工具上再把执行结果回传给模型。注意我故意设置了最大循环次数5次就是为了防止模型在某个死循环里转不出来这在真实生产环境里非常重要。工具执行出错时我不会直接抛异常让任务挂掉而是把错误信息塞回消息列表让模型自己判断下一步该怎么处理这是Agent比传统脚本更“聪明”的原因。3.3 前端把一次Agent任务当成状态机来管前端部分我最想分享的是状态管理思路。一句话总结Agent前端绝对不能只用一段isLoading布尔值因为“进行中”这个状态下面有太多细分情况。我用一个状态机来表达type AgentState | { status: idle } | { status: running; step: string } // 模型思考中 | { status: waiting_tool; toolName: string } // 正在调用工具 | { status: streaming; content: string } // 正在流式输出 | { status: done; content: string } | { status: error; message: string };界面上的表现是这样的状态是waiting_tool时右侧展示一张工具卡片上面写着“正在检索内部资料库”用户可以看到Agent到底在做什么而不是傻等。状态变成streaming时文本像打字机一样渲染出来用户能感知到生成过程。更关键的是我还加了一个“可编辑结果卡”的交互在每一步工具返回后用户可以直接修改工具传递的参数再重新提交也就是“人机协同”。这个设计完全来自前端思维传统模板页面是做不到这种协同意愿的。3.4 成本、效果、延时的三个优化手段项目做到现在我踩过最痛的坑是Token成本也就是大模型调用费用。第一次跑完整流程时一次文案任务就消耗了接近1万Token换算下来一次成本就够喝一杯咖啡。后来我做了三个调整第一用检索到的真实资料替换掉大量系统性提示词把不必要塞进上下文的品牌规则放到了工具侧第二增加语义缓存相同意图的历史请求直接命中缓存结果不再重复调用模型第三把“生成草稿”和“改写”切成了两个短对话而不是一次性让模型输出完美结果。效果评估上我没有用那种建模打分的方式而是请了三个市场同事盲测对比。评价维度只有三个信息准确性、语气贴合度、可直接采用比例。跑了两轮盲测后指标从最开始的40%可用率提升到了65%左右说明这个方向的基础框架是对的剩下的是调优和产品化问题。4. 在职学习的时间管理72天我是怎么扛下来的4.1 碎片时间复用我的“日课清单”在职学习最大的问题永远是时间不够。我的做法是把一天切成了五段早晨起床后40分钟看文档和笔记这阶段脑袋最清醒适合读原理通勤路上听一些技术播客不做笔记只建立关键词印象午休时间15分钟写一个Prompt练习用手机就能完成晚上九点半到十一点是核心代码时间雷打不动周末挑一个上午专门做完整项目迭代剩余时间彻底休息。这里我不推荐所有人照搬但有几个原则是通用的第一把学习任务按“认知负荷”排到不同时间段轻任务填碎片时间重任务填整块时间第二每天至少保证45分钟不受打扰的深度专注第三把“学新知识”和“做项目”分开晚上项目写累了就去读理论文档换脑交替进行不容易倦怠。4.2 让正反馈跑在焦虑前面我能坚持72天的直接原因是前10天开始我就刻意给自己制造正反馈。每次跑通一个API调用、完成一个工具封装、把Demo发给别人收获一句“挺牛”我都会在当天的日记里记一笔。这不是自嗨而是对抗长期学习焦虑的有效策略。因为Agent领域的知识更新太快今天刚学的框架下周可能就变了如果没有阶段性的小成就撑着很容易产生“学了也白学”的挫败感。我给自己定的规矩是“十天一交付”每10天必须有一个可以打开浏览器看到效果的东西。比如第10天是个命令行问答脚本第20天是会议安排Demo第30天是带前端界面的检索问答第50天就是现在的文案智能体原型。这些交付物不需要完美但必须可演示。一次可演示比十次看完课程都管用。4.3 和自己和解允许学得慢允许忘得快学习过程中我反复经历一种状态上周刚弄懂的RAG原理这周写代码时又卡壳了。一开始会恐慌觉得自己是不是没天赋。但现在我已经接受了成年人学习新技术本来就不是线性累积而是螺旋上升忘掉细节不可怕可怕的是没有建立整体的骨架。每次重新捡起一个概念我的速度都比上一次快这才是真实进步。另外很重要的一点是我不会去和算法背景或后端背景的人比。他们的优势在模型原理、系统底层而我的优势在用户感知、交互设计和产品落地。同样是学Function Calling他们可能关心机制怎么实现我关心的是前端什么时候展示工具卡片、用户能不能修改参数。找到自己的独特视角焦虑感会少掉一大半。5. 高频问题与排查技巧实录附速查表5.1 五个绕不开的技术卡点这72天里我在实际编码中至少撞过几十次同一个几个坑这里整理成一张速查表方便你直接复制使用。问题现象根因分析我的排查与解法模型返回的JSON里夹着Markdown代码块解析直接报错模型天然喜欢把结构化内容包裹在json中先用正则提取第一个{到最后一个}再做JSON.parse同时校验必填字段缺失则带错误信息重试一次Function Calling的入参偶尔出现不存在的字段模型靠上下文联想参数容易“幻觉”在parameters里写清楚description最好附带一个示例值执行前用运行时的schema校验不通过就拒绝调用长对话中Agent逐渐忘记前面的工具结果上下文窗口有限早期信息被挤出去把历史消息做分段摘要每轮只保留关键工具结果用户原始诉求始终放在system消息里流式输出中途断掉界面卡在50%网络抖动或模型端超时前端根据状态机自动触发重试后端记录已生成片段续传时从断点继续不重复生成用户输入里的指令覆盖了系统Prompt用户构造恶意内容诱导Agent改变角色前端把用户内容严格放在“待处理输入”边界内不在system层拼接对工具执行结果做白名单校验第一个问题的代码解法我可以顺手写一下因为出现频率太高了function safeJsonParse(text: string) { // 去掉常见的Markdown代码块包装 const cleaned text.replace(/json|/g, ).trim(); const start cleaned.indexOf({); const end cleaned.lastIndexOf(}); if (start -1 || end -1) return null; return JSON.parse(cleaned.slice(start, end 1)); }5.2 关于“转行”的现实问题与我的选择很多同行问我最多的问题是到底应该“转行”还是“技能叠加”我的答案很明确别把这件事理解成抛弃前端而是给前端这个能力包增加一层“智能体开发”的新技能。目标岗位也不是算法工程师而是“AI应用开发工程师”或者“Agent产品技术负责人”。这类岗位最缺的恰恰是能把模型能力落地成体验的人。落地的现实路径是先在现有前端Leader岗位上找一个小场景比如内部文案生成、客户工单分类、知识库问答用两到三周做出一个可用Demo然后向团队和上级展示“同样的团队人数加上Agent能力能多接哪些需求”。这一步不是为了炫技而是为了让你拥有“转岗数据”如果组织内部有新的Agent项目机会你天然是最合适的人选如果没有你的简历上也多了一个完整落地项目。我在DAY72这个节点上最庆幸的就是没有冲动裸辞去培训班而是用上班的间隙一点一点完成这项转型。6. DAY73-100计划与给后来者的几条建议6.1 下一个28天要交付什么接下来这28天我的目标已经从“学”转移到“做”第一把手上的文案智能体打磨成团队内部可免费使用的工具补齐权限管理和效果反馈第二把Agent运行时抽成一个前端团队可复用的小型SDK沉淀成开源小项目第三开始输出技术笔记把72天学过的东西用“前端视角”重新整理一遍因为教是最好的学也能埋下技术影响力的种子。这三件事都不大但每件都能形成一个闭环。尤其是输出笔记这件事我发现把“上下文管理”这类概念用前端Leader听得懂的语言写出来自己理解反而更深了一层。这个过程也帮我筛出了哪些知识是真正掌握的哪些只是“眼睛看会了”。6.2 如果让我重来一次我会怎么做最后给想出发的人几条我自己交了学费才懂的建议纯个人经验不一定适合所有人第一先别急着买课。任何一套教程都不如自己调通一个API来得实在。用一晚上把官方文档里的快速开始跑通你的信心比看十节课都强。第二不要贪多半个月只啃一个核心概念。我前二十天最大的失误就是同时看了Prompt工程、Agent框架、RAG三块内容结果什么都没沉淀下来。后来改成“一次只打通一个环节”进度反而快了。第三尽量找一个同路人哪怕是线上社群里的一个打卡伙伴互相Review代码和想法比自己单打独斗坚持率高出一大截。第四把“学完”的标准定义为“能讲给别人听”每次学完一个概念试着用大白话录一段50秒的语音解释给自己听讲不清楚的地方就是你的知识漏洞。DAY72这一天我最大的体会倒不是技术上的突破而是慢慢理解了什么叫“人机协同”。过去我做的所有产品都是在给人设计界面现在做Agent更像是在设计一个数字同事的工作流程还要教会这个同事使用工具、知道什么时候该问人。这种认知变化比API调用和Prompt技巧更底层也是这72天带给我的真正资产。接下来第73天我还会继续写那段最朴素的Agent循环继续打磨那个内部文案工具然后看看它到底能被多少人真正用起来。无论结果如何这段经历本身已经值回票价。
