在职前端Leader学习/转行 AI Agent -DAY68
不知不觉，这已经是第68天了。白天带着团队排版本、评代码、盯交付，晚上回家继续啃Agent的文档和源码，周末基本都泡在实验项目和写复盘里。作为一个在前端岗位干了十年的Leader，今天想认真把这个阶段的学习记录做个阶段性梳理，聊聊一个前端人是怎么学AI Agent、踩过什么坑、哪里觉得原来积累能复用、哪里又得彻底换脑子的。
关注这个方向的人不少，但很多教程要么讲得太浅，要么纯后端视角，前端出身的人上手时经常一头雾水。这篇就以DAY68为节点，把我从"会写页面"到"勉强能搭Agent"的过程、认知转变、可复用的架构思路、实操方法和避坑经验，一次性讲透。适合正在转方向的前端工程师、技术Leader，也适合想了解Agent项目里前端技术栈到底扮演什么角色的人。
1. 这68天我在学什么：从"页面交付"到"智能体交付"的思维转换
1.1 一个前端Leader为什么突然要学AI Agent
先说动机。我干了十年前端，从jQuery时代一路写到Vue 3、React 18，带团队也带了几年。这两年观察到一个越来越明显的趋势：纯前端页面交付的边际价值在快速下降。组件库越来越齐全，中后台页面基本是拼积木；低代码平台把CRUD界面生成压缩到了分钟级；AI生成代码的能力也让初级页面开发变得非常便宜。
团队里的前端同学开始焦虑，我自己也在想，如果只停留在"把设计稿变成页面"这个层面，很快会被工具替代。那前端工程师真正的壁垒在哪？答案其实是和AI共存、把AI能力产品化。而AI Agent恰好是当下最热、最有落地价值的方向之一。它需要调度模型、工具、知识库，也需要做人和AI之间的交互层。后者正是前端的传统自留地。
所以我们团队定了一个方向：前端继续做，但每个人都要学Agent，把"会写页面"升级成"会做有智能的产品"。我自己先学，学完带团队，这就是DAY1到DAY68之间每天在做的事。
1.2 68天的学习路线拆解：我是怎么安排时间的
我在职，每天能挤出来的时间大概两小时，周末会多一些。这68天的路线大致分成三个阶段：
- 第1-20天：补基础。搞清楚大模型API怎么调、Token怎么算、Prompt怎么写、上下文窗口是什么。不贪多，重点是能自己写代码调用模型并拿到稳定结果。
- 第21-45天：学Agent架构。研究主流框架的设计思路，把ReAct、规划、记忆、工具调用、多Agent协作这些概念弄明白，并手写了一个最小的Agent循环。
- 第46-68天：做真实项目。选了三个方向实战，分别是给团队用的代码评审Agent、给业务演示的需求文档转原型Agent、以及一个部署在边缘函数的轻量Agent服务。这三个项目的细节后面专门讲。
说句实话，前20天最容易劝退。API的返回结果不稳定、Token成本让人肉疼、Prompt表现时好时坏，很容易怀疑自己适不适合这个方向。但熬过去以后，代码评审Agent跑通的那一瞬间，会觉得前面所有的时间都值了。
2. AI Agent的主流架构到底长什么样：前端视角的解构
2.1 你不需要从零写模型：Agent的四个核心组件
很多前端同学一听Agent就觉得要先懂深度学习、训练模型，其实完全不是这样。Agent开发的本质是编排：把一个强大的基础模型当成推理引擎，围绕它搭一套能感知上下文、做规划、调用外部工具的系统。可以类比成写前端：你不必自己实现浏览器，只要会写HTML、CSS、JavaScript。Agent开发中，模型就是浏览器，你真正要做的是编排逻辑。
一个通用Agent系统通常包含四个核心组件：
- 规划器：负责拆解用户目标。用户说"帮我整理这堆数据并生成报告"，Agent要先决定分几步：读数据、分析、生成模板、填充内容。
- 记忆模块：分为短期和长期。短期是当前会话的上下文，长期是向量数据库之类的结构化存贮。
- 工具层：Agent需要外部能力时，通过调用API、函数、脚本实现。比如搜索、查数据库、调企业内部系统。
- 执行与反馈循环：Agent执行一步，观察结果，再决定下一步，直到任务完成。
对应到前端开发，这套架构其实很眼熟：规划器有点像前端路由加状态机的组合，记忆模块类比应用状态管理（Redux/Pinia），工具层就是前端封装的各种API Service层，执行循环则接近render-commit的迭代过程。理解了这层对应关系，前端转过来学Agent的心智负担会小非常多。
2.2 当下主流的Agent实现方案：从单轮到多轮，从链到图
理论明白了，还得知道业界怎么落地。目前Agent的实现方案大致有几类：
一是单轮任务型。即用户发一个请求，Agent调用一次模型、执行一次工具，返回结果。适合简单问答和固定流程，比如查天气、查快递。
二是多轮循环型。代表方法是ReAct，名如其意：Reason + Act，模型先思考，然后行动，观察行动结果，再思考，循环直至完成。写代码调试这个场景特别适合ReAct，因为每一步执行完都可以看到报错信息再修正。
三是规划-执行型（Plan-and-Execute）。先让模型生成一个完整执行计划，然后逐个执行，中途可以修订计划。适合处理复杂项目，比如"分析一份IT采购合同中的风险条款"，需要先拆出条款列表、逐条分析、最后汇总。
四是多Agent协作型。多个Agent各有专长，比如一个负责搜索、一个负责写代码、一个负责测试，它们通过消息互相协调。这个架构最强大也最难驾驭，相当于把微前端里模块解耦的思想搬到了Agent世界里。
选型没有绝对最优，核心看任务复杂度、Token预算和容错要求。我自己做项目时，简单任务用单轮或浅循环，复杂任务用Plan-and-Execute，多Agent暂时没在生产环境的项目里冒险。
2.3 主流框架的横向对比：LangChain、LlamaIndex、自研、低代码平台
前端同学习惯用框架，Agent圈也有各自的"生态位"。我用过好几种，给一个不吹不黑的横评：
| 方案 | 核心优势 | 明显短板 | 适合场景 |
|---|---|---|---|
| LangChain | 生态最全，组件丰富，社区资料多 | 抽象重，升级频繁，心智负担大 | 快速验证复杂链路，研究学习 |
| LlamaIndex | 数据侧（文档检索、知识库）特别强 | 编排能力相对弱 | 重知识库问答类应用 |
| 自研轻量Agent循环 | 完全可控，体积小，费用透明 | 需要自己实现很多东西 | 对成本、稳定性和隐私要求高的生产项目 |
| 扣子/百炼等低代码平台 | 上手极快，有现成组件和发布渠道 | 灵活性受限，无法深度定制 | 内部工具和MVP试点 |
我自己的选择是：学习期用LangChain刷概念，实际项目里回到了自研轻量方案。原因很朴素——给团队和业务做的Agent规模并不复杂，几十行代码的核心循环完全够用，还能精确预测每次调用的Token消耗，出事了好排查。框架不是越重越好，这点和前端选型一个道理，盲目上重型框架只会维护得更痛苦。
3. 前端人的AI Agent实操：三个我能直接落地的项目
3.1 给团队做的"前端代码评审Agent"
这是我们团队第一个真正跑在生产环境的Agent，起因是代码量越来越大，人工评审经常流于形式。我搭了一个基于GitLab Webhook的Agent服务，流程是这样的：开发者提交Merge Request触发Webhook，服务端把MR的Diff文本、涉及文件、提交信息取下来，组装成Prompt，调用大模型，让它按团队规范（命名、副作用、异常处理、安全点）逐条评审，最后把结论发到企业微信群。
核心代码简化后大概是这样：
from server.sdk import webhook, send_to_feishu from agent.core import run_agent @webhook("/mr/review") def handle_mr(payload): diff = fetch_mr_diff(payload["project"], payload["mr_iid"]) prompt = build_review_prompt( diff=diff[:12000], # 截断到约3000 token，防止超出上下文 rules=TEAM_FRONTEND_RULES, severity=["blocker", "warning", "suggestion"] ) result = run_agent(prompt, tools=[search_docs]) send_to_feishu(format_review_result(result))这里最需要注意的细节是Token管理。一个Diff文本可能很长，尤其是大型前端MR动辄改几十个文件，全量塞进上下文既贵又容易让模型"迷路"。我用了一个简单的截断策略：优先保留新增行和删除行，省略纯格式变更；单个文件超过400行的先生成摘要再让模型基于摘要评审。实测下来，评审质量不会明显打折，成本至少省了60%。
踩过的坑有两个。一是模型会"幻觉"，比如指出一个并不存在的CSS溢出问题。后来我在Prompt里加了"如果拿不准，就说无法判断"，情况好了很多。二是不同模型对中文和代码混合输入的表现差异很大，我用同一套Prompt测过几个模型，结论是输出稳定性和代码理解深度差异明显，最终选了一个性能/价格比较合适的模型，没盲目追最强型号。
3.2 给业务方做的"需求文档转原型Agent"
第二个项目是预研性质的，业务方提的需求很直白："能不能把PRD直接变成高保真原型图？"这听起来像是AI前端生成，但实际做下来，核心难点不在渲染，而在把零散的需求文本转化成结构化的页面描述。
我的方案是拆成三步：
- 第一步，文档解析。读取Word/Markdown格式的PRD，抽取页面清单、功能点、字段表、交互规则。
- 第二步，Agent规划。让模型生成一份组件树和页面间的跳转关系，对应到团队现有的前端组件库。
- 第三步，调用前端SDK渲染。把结构化的描述喂给基于既有组件库封装的渲染SDK，自动生成可点击的H5原型。
这个方案的巧妙之处在于，前端SDK和组件库是现成的，Agent只负责"翻译"，不负责从零写代码。Render效果比纯AI页面生成稳定得多，因为最终产物用的都是团队已经打磨过的组件，而不是模型自己想象的CSS。
难点主要在第一、二步。PRD里经常有模糊描述，比如"列表支持多种筛选"，但没说筛选条件有哪些。Agent会卡住或者瞎猜。我加了一轮澄清机制：当信息不足时，Agent不是硬出结果，而是输出一个问题清单回问业务。这个机制也让业务方感受到了Agent交互的价值，比直接交付死板结果靠谱得多。
3.3 个人实验：部署一个纯前端托管的轻量Agent
第三个项目纯属个人兴趣，想验证一个问题：Agent服务能不能不搭传统后端，直接跑在边缘函数加前端托管上。我用纯前端线上免费部署那一套，把Agent的逻辑做成Serverless Function，前端页面负责会话展示和流式输出。整体跑下来是可行的，请求延迟比传统服务器略高，但省运维精力，小流量场景完全够。
但这里有一个必须强调的坑：千万不要把大模型API的密钥直接放在前端代码里。一旦发布到线上，等于把密钥公开了，任何人都能拿你的额度去调用。我见过有人把API Key写死在HTML里，结果一天被盗刷了几百美元。正确的做法是把密钥放在服务端或边缘函数的环境变量里，前端只通过代理接口访问。
顺手说一下前端安全这个热搜词。做这个实验时我认真做了一遍前端安全加固：接口不暴露原始密钥、生产环境禁掉源码映射、关键API加Referer校验、对异常高频请求做风控。这些手段都是常规前端安全操作，不是发明创造，但在Agent项目里尤其重要，因为Agent往往会暴露更多内部逻辑和工具接口。
3.4 阶段性成果数据
第三个项目做的是给团队内部的知识库问答Agent，用来回答"某个老模块的代码逻辑是什么""线上问题排查Handbook里怎么写的"这类问题。前期先让Agent把散落在文档里的知识做向量化索引，再通过RAG方式在问答时检索。
跑下来最大的感受是：对业务方，"一个能直接告诉我答案的入口"比"一份更全的文档"有感知得多；对团队，"知识被结构化保存"这件事本身就在解放我反复回答同样问题的精力。目前这个Agent已经挂在团队常用页面上，日均问题量四五十个。
4. 踩坑实录与68天经验速查表
4.1 前端思维做AI Agent最容易犯的5个错误
这68天我犯过错，也观察了身边同样转方向的人，总结出前端出身做Agent最常见的五个错。
第一个错误，把Agent当成组件库，封装得越细越死。前端习惯了高内聚低耦合，于是我一开始也想把"调用模型"封装成像<Button>一样优雅的组件。结果发现Agent行为本身是状态性的、依赖上下文的，过度封装只会让参数失控、调试困难。正确的做法是保留核心循环可见，工具函数可以抽，但别把控制流藏起来。
第二个错误，迷信测试覆盖率。前端有成熟的单测、E2E测试方法，我一度想用同样思路保证Agent输出质量。但模型输出天然有不确定性，断言"必包含某字符串"毫无意义。正确策略是加入结构化输出校验和人工抽查，保证质量下限，而不是追求确定性。
第三个错误，忽略流式输出和实时交互。前端不出意外都做过打字机效果，但Agent场景下流式输出不只是UI体验问题，还直接影响用户的等待成本和交互决策。用户希望看到模型正在处理到哪一步。我是用Server-Sent Events把Agent思考过程逐步推给前端，体验立刻提升一个档次。
第四个错误，把用户会话当成无状态HTTP请求。普通接口每次都是独立的，但Agent强烈依赖会话状态、历史记忆，无状态设计会让对话毫无连续感，Agent也容易忘记前文。
第五个错误，Token成本预估错误。前端不需要为代码执行成本发愁，但Agent每一个字都要花钱。我一个项目上线当天就烧掉了模型免费额度的三倍，就是因为没预估并发量和输入长度。建议所有Agent项目上线前都先做Token成本估算表，把对话轮数、平均Token数、单价和并发量相乘，算出来的数字往往比想象中大一截。
4.2 常见问题与排查方法速查表
实际开发中遇到的问题，整理成一张速查表：
| 故障现象 | 可能原因 | 排查思路 |
|---|---|---|
| Agent不遵循指令，答非所问 | Prompt意图不清晰/上下文污染 | 检查Prompt是否被历史输出带偏，尝试压缩历史、强化System约束 |
| 输出格式不稳定，JSON解析失败 | 模型输出被截断或幻觉 | 加JSON Schema约束，使用结构化输出功能，返回前做合法性校验 |
| 中文输出中间断掉 | 达到上下文窗口上限 | 分块处理，做摘要压缩，或切换更长上下文的模型 |
| 工具调用一直失败 | Tool描述不准确/参数很难猜 | 排查工具Schema定义，给出更明确的函数描述和参数示例 |
| 相同问题上下文遗漏 | 会话记忆未正确存取 | 检查记忆模块注入逻辑，确认历史消息是否被正确追加和裁剪 |
| Token消耗快速飙升 | 循环任务没有终止条件 | 给Agent循环加最大步骤数、超时时间，对单轮费用做熔断 |
4.3 关于工具链的选型建议
选工具链是我这68天里最纠结的事之一，给同路人几个实在建议。
自己搭还是用框架？如果你已经在做生产级项目，建议自研轻量核心循环加少量框架组件；如果还在学习和快速验证，直接选择生态成熟的框架。千万不要在生产环境跟框架版本的升级节奏跑，那是噩梦。
用国内平台还是直接调模型API？实测下来，国内平台在中文语义理解、合规性和支付便捷性上有优势，但在工具生态、复杂编排和灵活性上不如直接调用主流模型API。我的建议是：内部工具兼低延迟场景优先国内平台，研究性项目直接调更开放的模型API。
纯前端方案该不该用？只在个人项目、演示Demo或对数据安全性要求不高的场景用，正规产品必须保留服务端控制面。纯前端方案还要额外承担接口暴露、密钥管理和爬虫风险，这些成本很容易被低估。
4.4 为什么"Rust语言AI Agent"值得关注
最近热搜里有个说法"基于Rust语言AI Agent"，前端出身的人可能觉得跟自己没关系。但实际上Rust在AI Agent生态里正在被越来越多地用于高性能运行时、工具执行沙箱和边缘部署。我对Rust完全不算熟，但作为长期技术规划，我认为未来Agent的高性能基础设施层会有一部分生态落在Rust上，就像当年Node.js把JavaScript带到了服务端一样。当前端Leader，我不急于立即转型学Rust，但会持续关注这个方向，至少不是坏事。
5. 68天后的再思考：前端与AI Agent的真正结合点在哪里
5.1 不是"转行"，而是"叠加"
学到现在我逐渐意识到，对这个方向最准确的描述不是"转行"，而是"叠加"。前端并没有被抛下，反而是Agent产品体验层绕不开的一环。模型能力再强，终归需要一个让人理解、操作和反馈的界面。而Agent的不确定性，恰恰需要前端更强的容错设计和可感知设计来兜底。用户面对一个会出错、会分步思考、需要确认的AI系统，这跟面对一个业务管理系统是完全不同的交互范式。
前端技术栈具体能在AI Agent产品里做什么？首先是Agent的交互界面，包括会话流式输出、工具调用可视化、步骤状态展示、异常回退机制；其次是Agent的可观测性面板，也就是AgentOps，给开发者和运维人员看Agent每一步在干什么、花了多少钱、为什么卡住；然后是Agent的调试器，像前端调试一样方便地查看Prompt输入、模型输出和工具返回。这些方向目前人才缺口很大，正是前端同学的增量红利区。
从团队管理的角度看，作为前端Leader，我现在更多是帮团队找到成长的第二曲线。我让团队里不同成员分别去研究Agent调试器、交互范式、前端SDK化封装等子方向，每周做一次内部分享。这样既推进了Agent能力建设，又让前端同学在新赛道上有了自己的立足点。
5.2 下一步计划：从Day69开始做什么
我自己接下来的计划大致想清楚了。
第一，把知识库问答Agent迁移到更完整的工程化形态，加上身份权限、操作审计和更稳定的记忆模块，让它在团队内部可信可用。第二，开源一个针对前端开发场景的Agent模板仓库，包含代码评审、文档问答、自动化发版三个开箱即用的场景，降低前端同学的上手门槛。第三，持续跟进Rust方向在Agent运行时方面的进展，同时关注AI安全相关的前沿问题，比如提示注入怎么防、Agent工具的权限边界怎么定。前端搞安全出身的经验在这里反而能派上用场。
对想入这个方向的前端同学，我的意见是：别等"准备好"再动手，挑一个你自己日常特别繁琐的工作流，用Agent先把它自动化掉。哪怕一开始很粗糙，只要跑通一次，你就不会再想回到纯页面开发的舒适区了。
5.3 如果从头再学一遍，我会怎么学
如果现在让我回到68天前，重新从零学一次AI Agent，我会在以下方面把时间重新分配：
- 第一阶段不再疯狂看框架文档，而是先花三天时间自己写一个最小的"Prompt→模型→工具→结果"循环。哪怕只有几十行代码，也会对Agent的本质理解更扎实。
- 第二阶段直接找一个真实痛点项目动手做，而不是先追求"学全"再动手。做中学远远比我之前"先读三个月再开写"的方式效率高。
- 第三阶段把成本意识和可观测性测试提前到项目一开始，而不是等出了问题再补。Agent项目上线前就应该先设计好日志、计费和失败兜底。
如果能从头来，我会更早放弃"把所有工具都试一遍"的执念，只把一到两个方案做深做透。与其花大量时间在框架对比表格上折腾，不如把有限的业余时间投入到真实产品里积累手感。
最后的最后：第68天的一点真实感受
回顾这68天，要说最大感悟，就是前端工程师做Agent不是从零开始，而是把自己对交互、状态、性能、工程化的理解，搬到一类新系统上。你过去为复杂页面状态管理掉的头发、为兼容性问题吵过的架、为性能优化熬过的夜，在新的领域都会以另一种形式重新派上用场。
如果你也在考虑这个方向，我的建议只有一句话：别等顿悟，先做一个丑但能跑的东西。哪怕它只是把你团队最常见的三件事自动化掉，你都会从这个过程中获得比十篇教程更坚实的认知。第68天，和Agent打交道还谈不上资深，但至少我已经从那座"会写页面"的山头出发，开始走向另一片更大的地图了。
