今天是我系统学习 AI Agent 的第 61 天。白天我刚开完前端团队的季度技术规划会晚上坐在电脑前整理这一个多月的笔记时忽然觉得应该把这些东西写下来。我做了八年前端带团队两年在别人眼里是标准的“资深开发”但只有自己清楚前端这个岗位的技术边界正在被 AI 快速重绘而 Agent 就是那支最粗的画笔。写这篇文章不是因为焦虑恰恰相反正是因为想清楚了一些事情才敢在这个节点做个阶段性总结。如果你也是前端开发者或是正在犹豫要不要了解 Agent 的技术人这篇文可以帮你少走不少弯路。我会把这 61 天里学了什么、踩了什么坑、做了哪些实战项目、以及一个前端 Leader 为什么要转向 Agent 的逻辑一次性讲透。1. 第61天回望一个前端Leader为什么开始学AI Agent1.1 前端岗位的天花板比想象中来得更早先说说我自己的处境。在转学 Agent 之前我日常的工作大概可以概括为拆需求、定技术方案、排研发计划、review 代码、处理线上事故、陪产品经理聊边界。带团队之后我写代码的时间肉眼可见地在减少取而代之的是大量的“决策”和“沟通”。这个变化本身没什么问题但它暴露了一个事实前端技术栈的成长空间已经支撑不起一个 Leader 的长期增量了。你不妨回想一下从 2020 年到 2025 年前端的主流技术栈有什么本质变化吗从 jQuery 到 Vue/React 是一次跨越从 Webpack 到 Vite 是一次提速微前端、Server Components、RSC 这些概念确实不断出现但它们都还在“如何把页面做得更好”这个框架里打转。当一个领域的技术红利逐渐见顶行业的关注点就会转向“用更少的人做更多的事”——这时候 AI 来了。我不否认前端岗位的价值但如果你在一个岗位上已经很难找到“非线性增长”的机会那就必须给自己找一个新载体。2025 年到 2026 年Agent 形态的产品正在从“聊天机器人”向“自动化工作流”进化大量企业开始搭建自己的智能体。这个赛道缺的不是算法专家而是能把 Agent 做成“产品”的人——这恰恰是前端工程师的机会。1.2 我为什么不直接转后端而是选择 Agent决定转方向的那天我认真列过几个选项转后端、转算法、转产品经理、转 AI Agent。后端对我来说成本太高Java/Go 那套高并发体系不是一年半载能补齐的算法更是重灾区数学基础摆在那里硬啃不现实产品经理倒是可以转但多年的技术直觉告诉我纯做产品会丢掉自己最大的优势——亲手把想法变成现实的能力。最后我锁定了 AI Agent。原因很直接Agent 是一种“对话即应用”的新交互范式它的外延是理解用户意图、拆解任务、调用工具、返回结果。这套逻辑和前端做的事情在本质上惊人地一致前端也是在理解用户意图之后把数据和状态翻译成用户能理解的界面。前端工程师做 Agent 有一个暗藏的优势——我们对“交互”和“状态流转”有天然的直觉。语音助手为什么难用因为用户不知道它能做什么。怎么让 Agent 的能力可见、可控、可纠错这是交互设计问题而前端就是做这个的。所以我的策略不是“放弃前端”而是“给前端技能找一个不会被时代抛弃的载体”。2. 前60天学习路线从Prompt到大模型再到Agent框架2.1 第一阶段第1-15天先不急着写代码把概念磨透刚开始那几天我犯了一个典型的工程师范错误一上来就想找一个 Agent 框架赶紧跑通一个 demo。结果看 LangChain 的文档看得一头雾水什么是 Chain、什么是 Tool、什么是 Memory全在脑子里打架。后来我停下来先用一周多时间专门补基础概念。这一步我建议大家不要省。至少要把下面这些概念彻底搞明白否则后面调框架全是在抄代码。Token 与上下文窗口Token 是模型计费和长度计算的最小单位一个汉字大约消耗 1-2 个 token。上下文窗口决定了一次能塞进多少信息。做 Agent 的时候为什么要关注它因为你在设计提示词的时候要时刻知道当前任务的“预算”是多少——系统提示词写了 2000 字文档塞了 3000 字用户问题写了 300 字剩下还有多少空间留给模型输出这个账一定要会算。Temperature 与结构化输出Temperature 控制模型的随机性。做 Agent 的场景里如果你要模型输出 JSON 给程序解析temperature 一定要调低建议在 0.1 到 0.3 之间。我见过很多新手用默认温度跑结构化输出结果模型花式给你编字段名解析直接崩溃。RAG检索增强生成的基本链路把文档切成块用嵌入模型转成向量存进向量数据库用户提问时先做向量检索找出相关片段再把片段拼进提示词一起发给大模型。这个链路前端理解起来完全不困难因为它的本质就是一个“本地缓存 动态模板渲染”。这一阶段我还做了一件比较重要的事把要看的资料收敛成两个主源。一个是官方文档比如 LangChain 的官方教程和 API 参考另一个是大模型厂商的提示词工程最佳实践文档。少刷短视频平台的碎片教程那些东西看着过瘾但信息密度太低看多了反而焦虑。2.2 第二阶段第16-35天理解Agent的核心循环而不是只会调框架概念补完之后进入框架学习。这里我先踩了一个大坑花了很多时间研究框架的细节 API但忽略了 Agent 本身的运行机制。后来我才认识到所有框架的底层都是一套循环感知收到用户请求与上下文→ 规划决定下一步做什么→ 行动调用工具或直接生成回复→ 观察获取行动结果→ 反思决定是继续还是结束。我建议每一位前端同行都先亲手用代码实现一遍这个循环哪怕是最原始的版本。我当时写了一个十几行的 Python 脚本手动模拟“用户提问 → 模型决定调用函数 → 执行函数 → 把结果回传给模型 → 模型给出最终回答”的流程。就这么一小段代码比我看十篇框架教程都管用——因为它把抽象概念变成了你能掌控的状态流转。框架层面我当时对比了四个主流方案各有各的定位框架/工具特点适合人群LangChain生态最全组件化程度高但抽象层级多新手容易迷失想系统学习 Agent 概念的人LangGraph基于图结构管理 Agent 状态和流程可控性强适合复杂多步骤任务已经理解 Agent 基本循环、想做正式项目的团队CrewAI多角色协作让多个 Agent 扮演不同角色协同完成任务想快速体会“多智能体”协作的人Dify / Coze低代码平台拖拽式编排适合快速验证想法非技术背景或想快速做产品原型的人我的建议是如果你有编程基础直接用 LangChain 入门然后尽快切到 LangGraph。LangChain 最大的问题是做小 demo 很顺一旦任务复杂隐式的链式调用会让你难以调试。LangGraph 把流程画成一张图状态一目了然这对有工程化洁癖的前端来说非常友好。2.3 第三阶段第36-60天用三个小项目驱动不看视频只看输出学到这里我已经不甘心只做笔记了。从第 36 天起我给自己定了一条规矩每个知识点必须用一个能跑起来的小项目去验证。前前后后做了三个练手项目难度递增非常适合拿来检验自己的掌握程度。第一个是知识库问答 Agent。把团队的内部技术文档喂进去做一个能回答问题的机器人。这个项目让我把 RAG 全链路跑通了包括文本切片、向量化、检索、提示词拼接。做完这个之后我才真正理解了为什么切片大小和检索 TopK 对回答质量影响这么大。第二个是自动周报 Agent。让它读取我这一周的 Git 提交记录、会议纪要、待办清单自动生成一份周报草稿。这个项目让我第一次接触了工具调用Function Calling——Agent 通过调用预设函数获取数据再根据数据生成文案。这个体验非常关键因为它把 Agent 从“聊天”拉到了“做事”的层面。第三个是多角色协作 Agent——用一个编排层同时管理“需求分析 Agent”和“代码审查 Agent”让它们接力完成一个任务。这个项目踩了很多坑但也让我真正理解了多 Agent 协作的难点任务边界怎么划分、上下文怎么共享、结果怎么校验。这个经验后来直接用在了我给团队搭建的工具上这部分我在第四章详细讲。这三个项目做完最大的感受是什么是“跑通”和“能用”之间的鸿沟。demo 只需要证明路径可行生产级还需要考虑稳定性、成本、权限、错误恢复。新手往往卡在“跑通”这一步就觉得自己会了实际差得远。等到你做一个功能需要考虑几十个并发、重复请求、模型随机失败的时候工程的难度才会真正展露出来。3. 前端背景在Agent开发里的真实优势不是写页面而是写交互3.1 前端Leader的核心能力恰好是Agent最需要的东西很多前端同行考虑转 Agent 的时候容易自卑觉得自己不会 Python、不懂机器学习是不是没戏了其实完全不是这样。经过了 61 天的学习我越来越确信Agent 产品当前最稀缺的能力不是算法调优而是“如何让用户信任并高效使用一个 AI 系统”。举个例子。你让一个 Agent 帮你规划一场旅行它给出一个方案。用户面临几个问题Agent 为什么要这么规划它掌握了哪些信息哪些条件是它猜的如果我中途改变主意怎么纠正它这就是交互设计问题。前端最擅长的渐进式披露Progressive Disclosure、状态可见性、异常态处理全都是 Agent 产品需要补的课。我在学习过程中做过一个很受启发的实验给一个纯文本交互的 Agent 加了一层极简的可视化状态面板让用户能看到“当前 agent 正在调用什么工具、检索了什么资料、生成了几个候选方案”。效果惊人测试者对这个 Agent 的信任度明显上升甚至愿意让它执行更复杂的任务。这背后的道理很简单用户不怕系统笨怕的是系统在暗处自作主张。前端工程师做 Agent就应该把自己的思维方式带进去——让 Agent 的每一步行为都变得可见、可理解、可干预。3.2 前端开发者转Agent最容易踩的3个坑当然八年的前端惯性也会带来一些思维定式这些定式在 Agent 开发里可能会变成坑。坑一把 Agent 当成一个 UI 项目来做。刚开始我写 Agent 的时候总是不自觉地先想“界面长什么样”“组件怎么拆分”然后才开始设计业务流程。但在 Agent 项目里核心是推理链路和工具编排UI 只是入口。顺序应该是先想清楚 Agent 怎么决策、怎么调用工具、怎么处理异常再考虑这些过程如何呈现在界面上。我见过不少项目界面做得很漂亮但底层 Agent 的规划逻辑一塌糊涂用户一用就露馅。坑二过度抽象一上来就封装各种 Class。前端工程师做项目习惯了高内聚低耦合组件拆得细、抽象层套得多。但 Agent 学习阶段我强烈建议先写能跑的直白代码不要急着封装。Agent 的行为链路本身还不够稳定过早抽象会让你在调试时多翻好几层包装平白增加心智负担。我踩过这个坑——写了一个 500 行的 Agent 工具类结果模型输出格式一变我修了一个下午。坑三用“视觉反馈”代替“数据反馈”。前端做页面好不好看、交互顺不顺滑肉眼可见。但 Agent 的反馈是日志、是 token 消耗、是准确率、是用户留存。我刚上手的时候很不习惯做出来的东西感觉不错但不知道它实际效果如何。后来强迫自己学会建立评估集准备几十条典型问题每次改完都跑一遍比较前后答案质量。没有这套流程Agent 开发就和盲人摸象没有区别。3.3 AI Agent也在反过来改变前端开发的方式聊到这里必须提一下“前端开发 skills”这个热词。2026 年的语境里它有两层含义。一层是指 AI 辅助前端开发的技能包比如让 Agent 帮你生成代码、审查代码、写单测、搭组件另一层是指前端工程师自身需要掌握的新技能——怎么去定义 AI 的工作流、怎么把专业经验变成 Agent 可以使用的工具。我自己在团队里做过一个试验让一个代码审查 Agent 参与前端的 MR 评审。它的职责很单一——读取 diff按团队规范检查命名、组件体积、是否有遗留调试代码、是否缺少错误处理。跑了一段时间后效果是可见的但离“完全替代人工评审”还差得远。这个试验更大的意义在于它让我看到了前端岗位未来的走向一部分重复性的代码工作会被 Agent 接手而前端工程师的核心价值会转向定义规则、评估质量、处理异常。所以我对“前端会被 AI 取代吗”这个问题的回答是会被取代的是重复劳动不会被取代的是对业务的理解和对用户体验的判断。90% 的页面都可以让 AI 生成但“这个功能在这个场景下应该怎么设计才不让人困惑”这个问题依然需要人来回答。4. 第61天实战从0到1搭建一个前端代码审查Agent4.1 为什么坚持要亲手做一个“能落地到团队”的项目学完基础、做完三个练手项目之后我觉得自己缺的最后一个拼图是——真实业务场景的验证。练手项目的用户只有我自己问题数量和评价标准都是自己定的说服力不够。所以第 61 天我挑了一个团队里真实存在的痛点来搭建 Agent前端代码审查。这个选择有几个理由。一是数据容易获取Git 仓库里的 MR 历史就是现成的数据集二是判定标准相对客观代码风格和明显错误是可以枚举的三是风险低就算 Agent 判断错了也只是多了一条评论不会直接影响线上服务。对第一次做“生产级”Agent 的人来说这是一个非常安全的试水场景。选型上我用了 LangGraph 做流程编排模型用了 API 调用模式向量库暂时没上——因为代码审查主要是基于当前 MR 的上下文还不需要大规模检索。整套架构跑在团队已有的 CI 流程旁边通过一个 Webhook 接收 MR 事件异步触发审查任务。4.2 核心流程设计与参数选择这个 Agent 的工作流程设计成了四个阶段第一阶段是上下文收集。接收到 MR 事件后从代码仓库拉取变更文件列表和每个文件的 diff同时读取我们团队的代码规范文档片段。这里有一个关键操作合并 diff 前先截断——单次提交可塞进提示词的 token 有限文件过多时按变更行数排序只保留最值得审查的文件避免上下文被无关文件占满。第二阶段是逐文件审查。每个核心文件单独构造一个审查 Prompt要求模型以 JSON 格式输出发现的问题列表。每个问题包含四个字段问题类型可能值有命名规范、性能隐患、错误处理缺失、遗留调试代码、安全问题等、严重级别P0 必须修复P1 建议修复P2 可选优化、具体位置文件和行号、修改建议。用 JSON 而不是自然语言输出是为了让结果能稳定地被下游程序解析并渲染成 MR 评论。第三阶段是汇总与分级。把所有文件的审查结果汇总按严重级别分组过滤去掉重复项。汇总这个步骤看起来简单但实际上它决定了报告的可读性。如果 Agent 每个文件输出 5 条问题10 个文件就是 50 条工程师根本不会看。所以我会设定阈值只保留 P0 和 P1 级别的问题P2 只统计数量不展示细节。第四阶段是报告生成与发送。把结构化的问题列表渲染成一段带 Markdown 格式的 MR 评论相关的开发者和评审人并附上一句友好的提示“本报告由 AI 自动生成仅供参考请结合上下文判断。”这句话很重要它能显著降低团队对 AI 误报的反感度让工具先被接纳再被改进。关键的几个参数我单独说一下。模型 temperature 固定为 0.1因为审查任务需要稳定和保守不需要创造性。单次审查的 max_tokens 设为 2000避免单个文件生成超长报告拖慢响应。审查的 system Prompt 我至少迭代了五版才稳定——核心经验是明确告知模型“只审查你确有把握的问题不要猜测不要在不确定时强行给出建议”。这条约束极大地降低了误报率让报告从“看起来专业但胡说八道”变成了“偶尔疏漏但言之有据”。4.3 实测效果与真实复盘这个Agent到底好不好用第一个版本上线那一周我每天都会看它写的审查报告。真实的数据用一句话概括查得出低级问题查不出高深的逻辑错误。好的方面是遗留的 console.log、未使用的 import、明显不符合团队规范的命名、缺少 loading 状态的接口调用这些高频问题基本能稳定检出。团队里几个初级工程师反馈这个 Agent 的评论像“一个细心的老同事在旁边提醒”节省了不少 wait for review 的时间。不足的方面也很明显。首先是对跨文件逻辑的审查很弱——比如“A 组件修改之后B 组件因为共享状态而受到的影响”这类问题单 diff 粒度的审查完全无能为力。其次是误报率偏高在 20%-30% 左右主要发生在模型不理解业务上下文时把一些合理写法误判为潜在问题。还有一个比较恼火的问题模型偶尔会“幻觉”出不存在的行号这就需要展示端做一次行号合法性校验把不存在的位置过滤掉再上屏。基于这些复盘我下一步的改进方向也很明确第一在审查前引入静态分析工具ESLint 等做一次预筛选让 Agent 只关注静态工具覆盖不到的语义问题第二把团队过往的 MR 评审意见做成一个小规模的知识库用 RAG 的方式给 Agent 补充团队特有的偏好第三增加用户的“有用/无用”反馈按钮把反馈数据回流持续调整 Prompt。做这个项目最大的收获不是技术方案而是体验了一次“真实场景中 AI 能力与人性化设计如何结合”的完整闭环。5. 学习资源与技术选型避坑实录5.1 学习资源避坑别让“资料囤积症”拖慢你的进度学习 Agent 的这 61 天里我见过最多的一种人不是不学习的而是学习资源囤积狂。今天收藏一篇“Agent 入门指南”明天保存一份“Prompt 工程完整手册”后天买一个“AI Agent 实战训练营”硬盘空间消耗了不少真正掌握的没多少。我的建议是资料不要超过三份。一份大模型基础概念文档一份你选定的主力框架官方文档一份优秀的实战案例解析文章集。这三份资料反复精读读到能不看文档写出代码的程度远比看过一百个教程有用。判断有没有学懂的标准很简单能不能把核心概念讲给团队里一个完全不懂 AI 的同事听并且让对方听懂。我用了这个方法自我检验过效果奇佳——讲不出来的地方就是还没懂的地方回去补就是了。另外一个避坑点是警惕“框架追新”。AI 领域技术迭代非常快今天热门的框架可能下个月就换了主力方向。我的做法是选一个成熟稳定的框架核心不变的那一个把它学透而不是每周换一个新框架追热度。底层原理一旦通了换个框架也就是适应 API 语法的事。5.2 技术选型避坑企业级Agent不是调API那么简单练手可以随便用免费额度跑一跑但如果你像我一样最终目标是在团队和公司内部落地一个有点规模的 Agent 系统技术选型就不能只看代码能不能跑通了。这里有几个问题我在第 61 天才深刻体会到提前分享给你。第一个是权限模型。Agent 调用工具的本质是替用户执行操作。企业场景里谁能命令 Agent 执行什么操作、Agent 执行操作之前要不要审批、操作日志存多久怎么审计这些都不是技术 demo 里能预见的。MCP模型上下文协议现在成了 Agent 接入外部系统的标配协议它虽然标准化了工具接入方式但权限设计还是要结合企业自己的账号体系来做。这块如果你接触不深一定会是上线前的硬伤。第二个是评估体系。写一个 Agent 的代码一周够了建立一个评估 Agent 好坏的方法可能要好几个月。我见过太多团队挣扎在“感觉自己做的 Agent 还行但说不清哪儿行、哪儿不行”的状态里。建议从第一天起就给项目建一个评估集维护好测试用例库每轮改动后跑一次回归。这个习惯越早养成后面迭代越轻松。第三个是成本控制。大模型按 token 计费一个复杂 Agent 跑一次任务可能调用几十次模型接口。如果不加节制一个几十人的团队每天消耗的 API 费用完全可能远超预期。基本的优化手段包括缓存重复请求的结果、用小模型处理简单任务大模型处理复杂任务、给上下文瘦身。我在自己的代码审查 Agent 里做了缓存和上下文截断之后成本直接降了大概 40%。5.3 在职Leader怎么挤出时间学新东西我的时间管理心得文章写了这么长最后聊一个很现实的问题——在职前端 Leader 每天那么多会怎么挤出时间学一个新方向我的做法谈不上优雅但很实用。核心是“把学习变成日程里的固定块而不是剩余时间的消遣”。我给自己定的节奏是工作日每晚 9 点到 10 点半雷打不动学一个半小时周末每天上午花大概三小时做项目写代码。平均算下来一天大约投入两小时。61 天累计约 120 个小时谈不上很多但对于建立一套全新知识体系来说足够了。同时我学会了一个技巧让团队成为你的杠杆而不是你的阻力。我会把自己学到的一些 Agent 知识做成简单的分享在组会上讲给团队成员听一方面是倒逼自己整理和输出另一方面也能吸引团队里对 AI 有兴趣的同学一起参与。后面做代码审查 Agent 的时候组里一个前端同学主动承担了展示端的所有开发工作我只需要专注在 Agent 逻辑本身。不要试图一个人扛下所有事做 Leader 的人最该懂这个道理。还有一点我觉得比时间管理更重要那就是接受“学不完”的状态。Agent 领域的知识边界比前端还要大LLM、RAG、多模态、Agent 框架、评估体系、产品设计每一条线都能往里钻很久。我的策略是从当前项目需要什么就学什么以实战拉动学习而不是试图先精通所有理论再动手。学不完没关系保持“下一个问题驱动下一步学习”的节奏你会发现进步反而是最快的。写在最后61 天前我给自己定的目标是“搞懂 AI Agent 到底是什么、能做什么、我应该怎么参与”。现在回头看这三个问题的答案都在实践中渐渐清晰了。AI Agent 不是某个神秘的技术黑盒它是一套“用大模型驱动自动化决策与执行”的方法论——而方法论这种东西最怕的不是理解不了而是不去亲手碰一次。对于和我一样背景的前端开发者我最后想说的是不要把自己定义成“写页面的人”要定义成“把复杂系统变得可理解、可使用的人”。Agent 时代需要大量这样的人。前端这些年积累的交互直觉、工程规范、审美判断放在 Agent 产品里不但不过时反而是稀缺资产。下一步我打算继续沿着这条路往下走下一步的目标是把自己做的代码审查 Agent 升级成一个更像“完整产品”的东西围绕它做一套轻量的运营面板让团队其他成员也能自定义审查规则。路还很长但方向已经清楚了。 前端开发者61天AI Agent实战：从核心循环到代码审查Agent
今天是我系统学习 AI Agent 的第 61 天。白天我刚开完前端团队的季度技术规划会晚上坐在电脑前整理这一个多月的笔记时忽然觉得应该把这些东西写下来。我做了八年前端带团队两年在别人眼里是标准的“资深开发”但只有自己清楚前端这个岗位的技术边界正在被 AI 快速重绘而 Agent 就是那支最粗的画笔。写这篇文章不是因为焦虑恰恰相反正是因为想清楚了一些事情才敢在这个节点做个阶段性总结。如果你也是前端开发者或是正在犹豫要不要了解 Agent 的技术人这篇文可以帮你少走不少弯路。我会把这 61 天里学了什么、踩了什么坑、做了哪些实战项目、以及一个前端 Leader 为什么要转向 Agent 的逻辑一次性讲透。1. 第61天回望一个前端Leader为什么开始学AI Agent1.1 前端岗位的天花板比想象中来得更早先说说我自己的处境。在转学 Agent 之前我日常的工作大概可以概括为拆需求、定技术方案、排研发计划、review 代码、处理线上事故、陪产品经理聊边界。带团队之后我写代码的时间肉眼可见地在减少取而代之的是大量的“决策”和“沟通”。这个变化本身没什么问题但它暴露了一个事实前端技术栈的成长空间已经支撑不起一个 Leader 的长期增量了。你不妨回想一下从 2020 年到 2025 年前端的主流技术栈有什么本质变化吗从 jQuery 到 Vue/React 是一次跨越从 Webpack 到 Vite 是一次提速微前端、Server Components、RSC 这些概念确实不断出现但它们都还在“如何把页面做得更好”这个框架里打转。当一个领域的技术红利逐渐见顶行业的关注点就会转向“用更少的人做更多的事”——这时候 AI 来了。我不否认前端岗位的价值但如果你在一个岗位上已经很难找到“非线性增长”的机会那就必须给自己找一个新载体。2025 年到 2026 年Agent 形态的产品正在从“聊天机器人”向“自动化工作流”进化大量企业开始搭建自己的智能体。这个赛道缺的不是算法专家而是能把 Agent 做成“产品”的人——这恰恰是前端工程师的机会。1.2 我为什么不直接转后端而是选择 Agent决定转方向的那天我认真列过几个选项转后端、转算法、转产品经理、转 AI Agent。后端对我来说成本太高Java/Go 那套高并发体系不是一年半载能补齐的算法更是重灾区数学基础摆在那里硬啃不现实产品经理倒是可以转但多年的技术直觉告诉我纯做产品会丢掉自己最大的优势——亲手把想法变成现实的能力。最后我锁定了 AI Agent。原因很直接Agent 是一种“对话即应用”的新交互范式它的外延是理解用户意图、拆解任务、调用工具、返回结果。这套逻辑和前端做的事情在本质上惊人地一致前端也是在理解用户意图之后把数据和状态翻译成用户能理解的界面。前端工程师做 Agent 有一个暗藏的优势——我们对“交互”和“状态流转”有天然的直觉。语音助手为什么难用因为用户不知道它能做什么。怎么让 Agent 的能力可见、可控、可纠错这是交互设计问题而前端就是做这个的。所以我的策略不是“放弃前端”而是“给前端技能找一个不会被时代抛弃的载体”。2. 前60天学习路线从Prompt到大模型再到Agent框架2.1 第一阶段第1-15天先不急着写代码把概念磨透刚开始那几天我犯了一个典型的工程师范错误一上来就想找一个 Agent 框架赶紧跑通一个 demo。结果看 LangChain 的文档看得一头雾水什么是 Chain、什么是 Tool、什么是 Memory全在脑子里打架。后来我停下来先用一周多时间专门补基础概念。这一步我建议大家不要省。至少要把下面这些概念彻底搞明白否则后面调框架全是在抄代码。Token 与上下文窗口Token 是模型计费和长度计算的最小单位一个汉字大约消耗 1-2 个 token。上下文窗口决定了一次能塞进多少信息。做 Agent 的时候为什么要关注它因为你在设计提示词的时候要时刻知道当前任务的“预算”是多少——系统提示词写了 2000 字文档塞了 3000 字用户问题写了 300 字剩下还有多少空间留给模型输出这个账一定要会算。Temperature 与结构化输出Temperature 控制模型的随机性。做 Agent 的场景里如果你要模型输出 JSON 给程序解析temperature 一定要调低建议在 0.1 到 0.3 之间。我见过很多新手用默认温度跑结构化输出结果模型花式给你编字段名解析直接崩溃。RAG检索增强生成的基本链路把文档切成块用嵌入模型转成向量存进向量数据库用户提问时先做向量检索找出相关片段再把片段拼进提示词一起发给大模型。这个链路前端理解起来完全不困难因为它的本质就是一个“本地缓存 动态模板渲染”。这一阶段我还做了一件比较重要的事把要看的资料收敛成两个主源。一个是官方文档比如 LangChain 的官方教程和 API 参考另一个是大模型厂商的提示词工程最佳实践文档。少刷短视频平台的碎片教程那些东西看着过瘾但信息密度太低看多了反而焦虑。2.2 第二阶段第16-35天理解Agent的核心循环而不是只会调框架概念补完之后进入框架学习。这里我先踩了一个大坑花了很多时间研究框架的细节 API但忽略了 Agent 本身的运行机制。后来我才认识到所有框架的底层都是一套循环感知收到用户请求与上下文→ 规划决定下一步做什么→ 行动调用工具或直接生成回复→ 观察获取行动结果→ 反思决定是继续还是结束。我建议每一位前端同行都先亲手用代码实现一遍这个循环哪怕是最原始的版本。我当时写了一个十几行的 Python 脚本手动模拟“用户提问 → 模型决定调用函数 → 执行函数 → 把结果回传给模型 → 模型给出最终回答”的流程。就这么一小段代码比我看十篇框架教程都管用——因为它把抽象概念变成了你能掌控的状态流转。框架层面我当时对比了四个主流方案各有各的定位框架/工具特点适合人群LangChain生态最全组件化程度高但抽象层级多新手容易迷失想系统学习 Agent 概念的人LangGraph基于图结构管理 Agent 状态和流程可控性强适合复杂多步骤任务已经理解 Agent 基本循环、想做正式项目的团队CrewAI多角色协作让多个 Agent 扮演不同角色协同完成任务想快速体会“多智能体”协作的人Dify / Coze低代码平台拖拽式编排适合快速验证想法非技术背景或想快速做产品原型的人我的建议是如果你有编程基础直接用 LangChain 入门然后尽快切到 LangGraph。LangChain 最大的问题是做小 demo 很顺一旦任务复杂隐式的链式调用会让你难以调试。LangGraph 把流程画成一张图状态一目了然这对有工程化洁癖的前端来说非常友好。2.3 第三阶段第36-60天用三个小项目驱动不看视频只看输出学到这里我已经不甘心只做笔记了。从第 36 天起我给自己定了一条规矩每个知识点必须用一个能跑起来的小项目去验证。前前后后做了三个练手项目难度递增非常适合拿来检验自己的掌握程度。第一个是知识库问答 Agent。把团队的内部技术文档喂进去做一个能回答问题的机器人。这个项目让我把 RAG 全链路跑通了包括文本切片、向量化、检索、提示词拼接。做完这个之后我才真正理解了为什么切片大小和检索 TopK 对回答质量影响这么大。第二个是自动周报 Agent。让它读取我这一周的 Git 提交记录、会议纪要、待办清单自动生成一份周报草稿。这个项目让我第一次接触了工具调用Function Calling——Agent 通过调用预设函数获取数据再根据数据生成文案。这个体验非常关键因为它把 Agent 从“聊天”拉到了“做事”的层面。第三个是多角色协作 Agent——用一个编排层同时管理“需求分析 Agent”和“代码审查 Agent”让它们接力完成一个任务。这个项目踩了很多坑但也让我真正理解了多 Agent 协作的难点任务边界怎么划分、上下文怎么共享、结果怎么校验。这个经验后来直接用在了我给团队搭建的工具上这部分我在第四章详细讲。这三个项目做完最大的感受是什么是“跑通”和“能用”之间的鸿沟。demo 只需要证明路径可行生产级还需要考虑稳定性、成本、权限、错误恢复。新手往往卡在“跑通”这一步就觉得自己会了实际差得远。等到你做一个功能需要考虑几十个并发、重复请求、模型随机失败的时候工程的难度才会真正展露出来。3. 前端背景在Agent开发里的真实优势不是写页面而是写交互3.1 前端Leader的核心能力恰好是Agent最需要的东西很多前端同行考虑转 Agent 的时候容易自卑觉得自己不会 Python、不懂机器学习是不是没戏了其实完全不是这样。经过了 61 天的学习我越来越确信Agent 产品当前最稀缺的能力不是算法调优而是“如何让用户信任并高效使用一个 AI 系统”。举个例子。你让一个 Agent 帮你规划一场旅行它给出一个方案。用户面临几个问题Agent 为什么要这么规划它掌握了哪些信息哪些条件是它猜的如果我中途改变主意怎么纠正它这就是交互设计问题。前端最擅长的渐进式披露Progressive Disclosure、状态可见性、异常态处理全都是 Agent 产品需要补的课。我在学习过程中做过一个很受启发的实验给一个纯文本交互的 Agent 加了一层极简的可视化状态面板让用户能看到“当前 agent 正在调用什么工具、检索了什么资料、生成了几个候选方案”。效果惊人测试者对这个 Agent 的信任度明显上升甚至愿意让它执行更复杂的任务。这背后的道理很简单用户不怕系统笨怕的是系统在暗处自作主张。前端工程师做 Agent就应该把自己的思维方式带进去——让 Agent 的每一步行为都变得可见、可理解、可干预。3.2 前端开发者转Agent最容易踩的3个坑当然八年的前端惯性也会带来一些思维定式这些定式在 Agent 开发里可能会变成坑。坑一把 Agent 当成一个 UI 项目来做。刚开始我写 Agent 的时候总是不自觉地先想“界面长什么样”“组件怎么拆分”然后才开始设计业务流程。但在 Agent 项目里核心是推理链路和工具编排UI 只是入口。顺序应该是先想清楚 Agent 怎么决策、怎么调用工具、怎么处理异常再考虑这些过程如何呈现在界面上。我见过不少项目界面做得很漂亮但底层 Agent 的规划逻辑一塌糊涂用户一用就露馅。坑二过度抽象一上来就封装各种 Class。前端工程师做项目习惯了高内聚低耦合组件拆得细、抽象层套得多。但 Agent 学习阶段我强烈建议先写能跑的直白代码不要急着封装。Agent 的行为链路本身还不够稳定过早抽象会让你在调试时多翻好几层包装平白增加心智负担。我踩过这个坑——写了一个 500 行的 Agent 工具类结果模型输出格式一变我修了一个下午。坑三用“视觉反馈”代替“数据反馈”。前端做页面好不好看、交互顺不顺滑肉眼可见。但 Agent 的反馈是日志、是 token 消耗、是准确率、是用户留存。我刚上手的时候很不习惯做出来的东西感觉不错但不知道它实际效果如何。后来强迫自己学会建立评估集准备几十条典型问题每次改完都跑一遍比较前后答案质量。没有这套流程Agent 开发就和盲人摸象没有区别。3.3 AI Agent也在反过来改变前端开发的方式聊到这里必须提一下“前端开发 skills”这个热词。2026 年的语境里它有两层含义。一层是指 AI 辅助前端开发的技能包比如让 Agent 帮你生成代码、审查代码、写单测、搭组件另一层是指前端工程师自身需要掌握的新技能——怎么去定义 AI 的工作流、怎么把专业经验变成 Agent 可以使用的工具。我自己在团队里做过一个试验让一个代码审查 Agent 参与前端的 MR 评审。它的职责很单一——读取 diff按团队规范检查命名、组件体积、是否有遗留调试代码、是否缺少错误处理。跑了一段时间后效果是可见的但离“完全替代人工评审”还差得远。这个试验更大的意义在于它让我看到了前端岗位未来的走向一部分重复性的代码工作会被 Agent 接手而前端工程师的核心价值会转向定义规则、评估质量、处理异常。所以我对“前端会被 AI 取代吗”这个问题的回答是会被取代的是重复劳动不会被取代的是对业务的理解和对用户体验的判断。90% 的页面都可以让 AI 生成但“这个功能在这个场景下应该怎么设计才不让人困惑”这个问题依然需要人来回答。4. 第61天实战从0到1搭建一个前端代码审查Agent4.1 为什么坚持要亲手做一个“能落地到团队”的项目学完基础、做完三个练手项目之后我觉得自己缺的最后一个拼图是——真实业务场景的验证。练手项目的用户只有我自己问题数量和评价标准都是自己定的说服力不够。所以第 61 天我挑了一个团队里真实存在的痛点来搭建 Agent前端代码审查。这个选择有几个理由。一是数据容易获取Git 仓库里的 MR 历史就是现成的数据集二是判定标准相对客观代码风格和明显错误是可以枚举的三是风险低就算 Agent 判断错了也只是多了一条评论不会直接影响线上服务。对第一次做“生产级”Agent 的人来说这是一个非常安全的试水场景。选型上我用了 LangGraph 做流程编排模型用了 API 调用模式向量库暂时没上——因为代码审查主要是基于当前 MR 的上下文还不需要大规模检索。整套架构跑在团队已有的 CI 流程旁边通过一个 Webhook 接收 MR 事件异步触发审查任务。4.2 核心流程设计与参数选择这个 Agent 的工作流程设计成了四个阶段第一阶段是上下文收集。接收到 MR 事件后从代码仓库拉取变更文件列表和每个文件的 diff同时读取我们团队的代码规范文档片段。这里有一个关键操作合并 diff 前先截断——单次提交可塞进提示词的 token 有限文件过多时按变更行数排序只保留最值得审查的文件避免上下文被无关文件占满。第二阶段是逐文件审查。每个核心文件单独构造一个审查 Prompt要求模型以 JSON 格式输出发现的问题列表。每个问题包含四个字段问题类型可能值有命名规范、性能隐患、错误处理缺失、遗留调试代码、安全问题等、严重级别P0 必须修复P1 建议修复P2 可选优化、具体位置文件和行号、修改建议。用 JSON 而不是自然语言输出是为了让结果能稳定地被下游程序解析并渲染成 MR 评论。第三阶段是汇总与分级。把所有文件的审查结果汇总按严重级别分组过滤去掉重复项。汇总这个步骤看起来简单但实际上它决定了报告的可读性。如果 Agent 每个文件输出 5 条问题10 个文件就是 50 条工程师根本不会看。所以我会设定阈值只保留 P0 和 P1 级别的问题P2 只统计数量不展示细节。第四阶段是报告生成与发送。把结构化的问题列表渲染成一段带 Markdown 格式的 MR 评论相关的开发者和评审人并附上一句友好的提示“本报告由 AI 自动生成仅供参考请结合上下文判断。”这句话很重要它能显著降低团队对 AI 误报的反感度让工具先被接纳再被改进。关键的几个参数我单独说一下。模型 temperature 固定为 0.1因为审查任务需要稳定和保守不需要创造性。单次审查的 max_tokens 设为 2000避免单个文件生成超长报告拖慢响应。审查的 system Prompt 我至少迭代了五版才稳定——核心经验是明确告知模型“只审查你确有把握的问题不要猜测不要在不确定时强行给出建议”。这条约束极大地降低了误报率让报告从“看起来专业但胡说八道”变成了“偶尔疏漏但言之有据”。4.3 实测效果与真实复盘这个Agent到底好不好用第一个版本上线那一周我每天都会看它写的审查报告。真实的数据用一句话概括查得出低级问题查不出高深的逻辑错误。好的方面是遗留的 console.log、未使用的 import、明显不符合团队规范的命名、缺少 loading 状态的接口调用这些高频问题基本能稳定检出。团队里几个初级工程师反馈这个 Agent 的评论像“一个细心的老同事在旁边提醒”节省了不少 wait for review 的时间。不足的方面也很明显。首先是对跨文件逻辑的审查很弱——比如“A 组件修改之后B 组件因为共享状态而受到的影响”这类问题单 diff 粒度的审查完全无能为力。其次是误报率偏高在 20%-30% 左右主要发生在模型不理解业务上下文时把一些合理写法误判为潜在问题。还有一个比较恼火的问题模型偶尔会“幻觉”出不存在的行号这就需要展示端做一次行号合法性校验把不存在的位置过滤掉再上屏。基于这些复盘我下一步的改进方向也很明确第一在审查前引入静态分析工具ESLint 等做一次预筛选让 Agent 只关注静态工具覆盖不到的语义问题第二把团队过往的 MR 评审意见做成一个小规模的知识库用 RAG 的方式给 Agent 补充团队特有的偏好第三增加用户的“有用/无用”反馈按钮把反馈数据回流持续调整 Prompt。做这个项目最大的收获不是技术方案而是体验了一次“真实场景中 AI 能力与人性化设计如何结合”的完整闭环。5. 学习资源与技术选型避坑实录5.1 学习资源避坑别让“资料囤积症”拖慢你的进度学习 Agent 的这 61 天里我见过最多的一种人不是不学习的而是学习资源囤积狂。今天收藏一篇“Agent 入门指南”明天保存一份“Prompt 工程完整手册”后天买一个“AI Agent 实战训练营”硬盘空间消耗了不少真正掌握的没多少。我的建议是资料不要超过三份。一份大模型基础概念文档一份你选定的主力框架官方文档一份优秀的实战案例解析文章集。这三份资料反复精读读到能不看文档写出代码的程度远比看过一百个教程有用。判断有没有学懂的标准很简单能不能把核心概念讲给团队里一个完全不懂 AI 的同事听并且让对方听懂。我用了这个方法自我检验过效果奇佳——讲不出来的地方就是还没懂的地方回去补就是了。另外一个避坑点是警惕“框架追新”。AI 领域技术迭代非常快今天热门的框架可能下个月就换了主力方向。我的做法是选一个成熟稳定的框架核心不变的那一个把它学透而不是每周换一个新框架追热度。底层原理一旦通了换个框架也就是适应 API 语法的事。5.2 技术选型避坑企业级Agent不是调API那么简单练手可以随便用免费额度跑一跑但如果你像我一样最终目标是在团队和公司内部落地一个有点规模的 Agent 系统技术选型就不能只看代码能不能跑通了。这里有几个问题我在第 61 天才深刻体会到提前分享给你。第一个是权限模型。Agent 调用工具的本质是替用户执行操作。企业场景里谁能命令 Agent 执行什么操作、Agent 执行操作之前要不要审批、操作日志存多久怎么审计这些都不是技术 demo 里能预见的。MCP模型上下文协议现在成了 Agent 接入外部系统的标配协议它虽然标准化了工具接入方式但权限设计还是要结合企业自己的账号体系来做。这块如果你接触不深一定会是上线前的硬伤。第二个是评估体系。写一个 Agent 的代码一周够了建立一个评估 Agent 好坏的方法可能要好几个月。我见过太多团队挣扎在“感觉自己做的 Agent 还行但说不清哪儿行、哪儿不行”的状态里。建议从第一天起就给项目建一个评估集维护好测试用例库每轮改动后跑一次回归。这个习惯越早养成后面迭代越轻松。第三个是成本控制。大模型按 token 计费一个复杂 Agent 跑一次任务可能调用几十次模型接口。如果不加节制一个几十人的团队每天消耗的 API 费用完全可能远超预期。基本的优化手段包括缓存重复请求的结果、用小模型处理简单任务大模型处理复杂任务、给上下文瘦身。我在自己的代码审查 Agent 里做了缓存和上下文截断之后成本直接降了大概 40%。5.3 在职Leader怎么挤出时间学新东西我的时间管理心得文章写了这么长最后聊一个很现实的问题——在职前端 Leader 每天那么多会怎么挤出时间学一个新方向我的做法谈不上优雅但很实用。核心是“把学习变成日程里的固定块而不是剩余时间的消遣”。我给自己定的节奏是工作日每晚 9 点到 10 点半雷打不动学一个半小时周末每天上午花大概三小时做项目写代码。平均算下来一天大约投入两小时。61 天累计约 120 个小时谈不上很多但对于建立一套全新知识体系来说足够了。同时我学会了一个技巧让团队成为你的杠杆而不是你的阻力。我会把自己学到的一些 Agent 知识做成简单的分享在组会上讲给团队成员听一方面是倒逼自己整理和输出另一方面也能吸引团队里对 AI 有兴趣的同学一起参与。后面做代码审查 Agent 的时候组里一个前端同学主动承担了展示端的所有开发工作我只需要专注在 Agent 逻辑本身。不要试图一个人扛下所有事做 Leader 的人最该懂这个道理。还有一点我觉得比时间管理更重要那就是接受“学不完”的状态。Agent 领域的知识边界比前端还要大LLM、RAG、多模态、Agent 框架、评估体系、产品设计每一条线都能往里钻很久。我的策略是从当前项目需要什么就学什么以实战拉动学习而不是试图先精通所有理论再动手。学不完没关系保持“下一个问题驱动下一步学习”的节奏你会发现进步反而是最快的。写在最后61 天前我给自己定的目标是“搞懂 AI Agent 到底是什么、能做什么、我应该怎么参与”。现在回头看这三个问题的答案都在实践中渐渐清晰了。AI Agent 不是某个神秘的技术黑盒它是一套“用大模型驱动自动化决策与执行”的方法论——而方法论这种东西最怕的不是理解不了而是不去亲手碰一次。对于和我一样背景的前端开发者我最后想说的是不要把自己定义成“写页面的人”要定义成“把复杂系统变得可理解、可使用的人”。Agent 时代需要大量这样的人。前端这些年积累的交互直觉、工程规范、审美判断放在 Agent 产品里不但不过时反而是稀缺资产。下一步我打算继续沿着这条路往下走下一步的目标是把自己做的代码审查 Agent 升级成一个更像“完整产品”的东西围绕它做一套轻量的运营面板让团队其他成员也能自定义审查规则。路还很长但方向已经清楚了。