今天是在职学习AI Agent的第67天。前端的第8个年头我第一次觉得“前端技术栈本身”不是最值钱的东西了。这话有点狠但我劝你先别急着反驳。过去三个月我们团队用Vue3维护一套物联网管理后台业务方提的需求已经从“这个表格能不能加个筛选”变成了“这两个告警能不能自动合并然后让大模型帮我写一份处理摘要”。需求变化背后是一个正在发生的范式转移前端开发依然存在但业务价值的中心正在从“人操作界面”转移到“Agent自动完成任务”。这篇文章是我Day 67的复盘。写它有几个目的一个是梳理这67天我的认知变化另一个是给和我一样身处前端、又对AI Agent又爱又怕的同路人提供一个真实样本——一个带团队的前端Leader到底是怎么学习/转行AI Agent的中间踩了哪些坑哪些前端经验能直接迁移哪些东西必须从头学。1. 为什么一个带团队的前端Leader非要折腾AI Agent1.1 前端Leader的尴尬位置我见过太多前端Leader的生存状态白天开需求评审会晚上写页面周末还得担心团队成员的绩效。往上走的路真的不多。转管理团队才六个人管理动作没那么丰富。转架构要和后端云原生那群人卷人家一个容器编排面试题就能让你怀疑人生。转全栈体力消耗和时间成本直接翻倍。AI Agent的出现相当于给了一条新路把前端积累的交互、边界、用户体验的理解迁移到一个新物种身上。这几年低代码平台和AI生成界面工具也在挤压传统前端的存在感。一个简单的后台管理页面丢给AI生成器几分钟就能出一个能看的版本。如果我们的价值还停留在“把UI稿变成页面”那被替代是迟早的事。但Agent不一样Agent需要有人设计任务流、设计人在回路、设计异常处理。这些设计工作恰恰需要懂交互、懂状态、懂边界的人来干。前端人如果补上Agent的原理和工程知识会成为这类设计的稀缺力量。1.2 让我真正下定决心的三个瞬间第一个瞬间是面试。我和另一个前端Leader聊天发现今年收到的简历里十个里有三个会写“熟悉大模型用LangChain搭过Agent”。虽然面下来八成是背概念但市场信号很明显新的技术范式已经开始渗透到前端岗位的人才市场。第二个瞬间是团队内部的小项目。我们后端同事用大模型做了个客服反馈自动分类Agent三天跑通效果不错。我配合做了个前端页面把分类结果展示出来。业务方看完说页面挺好看但这个系统我们只需要每天看一眼结论。换句话说我花在展示层上的那些心思在业务眼里几乎等于零。那天我是有点受刺激的也第一次认真思考“前端在一个Agent系统里到底应该承担什么职责”。第三个瞬间是老板在规划会上问的一个问题。他说现在新增了一个需求要根据用户的自然语言描述自动生成设备配置模板现有规则引擎完全搞不定能不能做成“Agent模式”当时会议室没人敢接。规则引擎至少可解释、可回滚Agent是概率性的你敢让它自动改配置吗但反过来想别人不敢接我如果研究明白了这就是我的机会。提示想转AI Agent的前端第一件事不是All in而是先承认“前端技能依然重要但它在新的技术范式里开始变成配角”。承认这一点后面学习才不会有那么多心理内耗。1.3 到底是“转行”还是“技能叠加”我最后的答案是技能叠加。理由很简单AI Agent要成为一个生产级产品不可能没有前端。管理界面要做任务编排画布要做审核台要做流式输出要做多Agent协作的可视化工作台更要做。这些都是前端的活而且没人比前端更懂怎么做“复杂系统里的交互”。但只有前端技能是不够的。你至少得懂Agent的运行逻辑模型怎么调用、上下文怎么管理、工具结果怎么处理、失败怎么重试、token成本怎么控制。如果不懂这些你写的界面就只是一个空壳就像当年只切图的页面仔。所以在我眼里这不是一场“抛弃前端”的转行而是一次“前端技能Agent工程”的叠加升级。前端是底图Agent是新增的等高线。2. DAY67这一周我的实战复盘从零搭一个内容自动发布Agent2.1 为什么选“内容自动发布”当练手项目第60天的时候我给自己定了一个阶段性硬目标在Day 67之前搭出一个真正能跑通闭环的Agent小系统。题材选的是“小红书自动发消息”。为什么选这个原因有三个。第一它覆盖了Agent最常见的完整循环获取内容、大模型改写、决策发布、失败重试、人工兜底。第二它涉及真实平台接口的鉴权、限流和风控能逼我去处理工程问题而不是只调API玩。第三这个工具我家属是真用得上的。她做运营每天要写几十条文案还要在多个平台发布如果这个Agent能自动生成草稿、自动排队她至少能省一半时间。真实需求带来的动力比任何学习打卡都管用。我也见过程序员朋友学Agent一上来就复现ChatBot跑通了就发朋友圈然后就没有然后了。没有真实用户、没有业务反馈的练手项目大概率会在第20天就默默烂尾。所以特别建议选题时先问自己这个东西做完谁会真的用2.2 系统架构四层结构前端在哪一层系统整体分四层数据源层RSS订阅源加一个内部后台的导出API。处理层先做文本抽取再用LLM改写成适合平台调性的文案同时做敏感词过滤。执行层调用发布接口带鉴权和频率控制。展示层一个Web审核台运营可以预览、编辑、确认或丢弃Agent生成的每条内容。前端选型是Vue3 uni-app的H5版本。为什么不用小程序因为审核台需要快速登录uni-app的登录模块加后端签发JWT一周就能拿下。我特别想说的是组件库、登录框、状态管理这些老技能在Agent应用里不是没用了只是换了个宿主。以前组件绑定的是“表单字段”现在绑定的是“Agent任务状态”。我做审核卡片列表时用的还是老一套的分页、筛选、状态标签但背后的数据已经变成Agent的待执行任务队列了。视频素材的处理是这一周比较大的工程点。自动发布不能不支持带视频的内容而一条短视频动辄几百MB直接走普通接口上传必挂。我的方案是老技术Web Worker分包加断点续传。前端把视频切片后并发上传到对象存储再把存储地址交给处理层由Agent生成标题和封面。这个技术在Agent系统里的意义完全变了——它不再是“前端性能优化”而是“数据进入智能处理流水线的安全入口”。顺带说一句我现在看直播H5相关的技术也特别有代入感。如果做实时Agent助手音视频链路完全可以接讯飞实时语音转写这类能力给直播间提供实时字幕和话术建议。这个方向最近很热前端在音视频上的积累会派上大用场。处理层的关键逻辑我用伪代码描述一下方便和前端同学对齐思路function rewriteContent(raw): summary extract_rule_based(raw) # 规则抽取摘要省token prompt build_rewrite_prompt(summary) # 拼装系统提示词 output llm_call(prompt) # 调用大模型 plan parse_json_with_retry(output) # 解析发布计划带重试 if plan is None: plan need_human_review() # 连续解析失败转人工 return plan这段逻辑看起来很简单但这周我改了三版第一版把raw全文丢给LLM第二版加了摘要第三版加了重试和人工兜底。每一步都在解决真实问题不是为炫技。2.3 踩坑token、风控和“格式化幻觉”这一周踩得最深的坑有三个。第一个坑是token预算失控。AI Agent token是什么意思直白说token就是大模型读写内容的计量单位也是上下文窗口的计数单位更直接点就是钱包里的余额。一个汉字大约1到2个token一个英文单词大约1个token。最开始我的处理层直接把抓取到的长文丢给LLM改写结果每篇长文光输入就要消耗几千token一天下来账单涨得飞快。后来改成“先用规则引擎把长文压成摘要再让LLM基于摘要扩写”成本一下子砍掉70%。核心经验是在Agent里每一次token消耗都要算性价比能靠规则榨出来的信息就不要花token让模型读。第二个坑是平台风控。自动发消息这事没有想象中美好。发布接口调用频繁后先是出现滑块验证然后IP被限流再后来被告知需要额外授权。我一度以为是平台的爬虫反制太强后来想明白了任何在公网上运行的自动化操作都必须设计“人机协同”的节奏。妥协方案是在展示层增加人工审核队列所有Agent生成的稿件先进“待发布”状态由运营在审核台上确认再由后端定时器控制节奏去发布。这个改动看似降低了自动化程度但从工程角度看它才让Agent系统有了长期存活的基础。第三个坑是“格式化幻觉”。大模型输出并不总是一段合法的JSON。我让处理层输出发布计划偶尔缺个逗号偶尔中途截断偶尔在JSON外面套一层markdown代码块。解决方案分三层正则提取出疑似JSON的部分用容错解析器解析连续失败两次就转人工。这套兜底没有技术含量但少了它整个Agent就是一台三天两头停机的机器。为了方便阅读我把这一周的坑整理成了一张表坑位现象根因分析解决方案Token超支账单飙升响应变慢长文全文进入Prompt先规则抽取摘要再LLM扩写成本降70%平台限流发布被拦截滑块验证未控制调用频率和节奏人工审核队列 随机延迟 频率控制JSON截断发布计划解析失败模型输出被截断/不合法正则提取 容错解析 失败重试 人工兜底视频上传超时大文件上传失败普通接口不适合大文件Worker切片上传 断点续传2.4 结论Demo能跑和能上线是两回事这个项目在Day 67当天跑通了。第一版的样子是早上从RSS抓到5条行业新闻LLM改写成小红书的文案风格生成标题、正文和话题标签全部进入待审核队列家属在手机H5上点确认系统再按随机节奏发送。听起来挺美但它只证明了“能跑”离“能长期用”还有十万八千里文案风格不稳定、偶尔出现事实性错误、平台规则一变就要改适配层。但恰恰是这些不完美教会了我最重要的一件事Agent系统里90%的工程问题不是模型不够聪明而是流程设计不够稳。token怎么省、审核怎么加、重试怎么幂等、频率怎么控制、失败了怎么通知人这些才是长期价值。这也验证了1.3节说的那句话不要把学AI Agent变成“会调API”而是要成为“能把Agent从实验室带到生产环境的人”。3. 前端技能迁移地图这些老本行在Agent世界里依然值钱3.1 技能对照表我差不多花了两个星期把团队日常技能和AI Agent开发需求做了个对照发现重叠度比想象中高得多。整理结果如下前端已有技能Agent世界的对应场景迁移难度前端SDK、组件库封装大模型SDK、Agent组件封装低微前端qiankun等多Agent管理底座、插件化工作台中uni-app / 跨端开发Agent移动端、审核台、小程序入口低Web Worker、文件上传大文件进入Agent数据管道低前端安全XSS、防爬、源码保护Agent安全、鉴权、输入输出过滤中WebSocket / SSE流式Agent流式对话、实时观测雷达低直播H5、音视频实时多模态Agent、语音转写接入中说三个印象最深的。前端SDK这行迁移难度最低。你以前看别人的SDK文档、封装请求层、处理错误码到了Agent世界同一套方法论看LangChain或各厂商的Agent SDK文档封装工具调用处理模型返回的错误。组件库也一样以前封装表格、表单以后封装“Agent状态条”“任务卡片”“工具调用历史时间线”。这些组件很快会像今天的UI库一样成为Agent应用的基础设施。微前端这行比想象中更能复用。前端团队搞过qiankun的话一定熟悉“主应用定底座、子应用独立部署、统一鉴权、按需加载”这套模式。多Agent系统里几乎一模一样你要有一个控制台负责统一入口和监控每个Agent是一个独立模块有自己的版本、配置、运维权限。我在做自动发布项目时甚至直接把审核台设计成了可插拔模块以后接新的Agent任务只要把新的子模块注册进去就行。安全这行是我最近特别注意的。前端一直讲“用户输入不可信”、防XSS、防爬虫、防查看源码这些经验放到Agent上不但不过时还更有价值Agent暴露在公网上可能被恶意Prompt注入、被偷密钥、被滥用工具调用。各家云厂商陆续出的Agent安全白皮书核心就几条身份认证与授权、输入过滤与输出脱敏、工具调用鉴权、审计日志。前端的“边界意识”在这里可以直接平移你只需要补充一条新认知模型输入同样不可信。3.2 前端人做Agent有天然优势别浪费举两个真实例子。一个是我团队里的小朋友工作才一年主要做H5活动页。我让他试着做一个“Agent任务流可视化编辑器”的原型类似流程图编辑器把Agent的节点拖拽连起来。他一开始很慌说没写过这种。我告诉他你就把它当成复杂表单组件节点就是一个带状态和参数的自定义组件。结果他两周就做出了第一版还加了撤销重做和自动布局。后端同事看到原型后很惊讶说前端已经能直接操作Agent流程了。其实他没意识到后端在纠结调度引擎的时候前端天生就在跟“状态加交互”打交道可视化编排正是我们的主场。另一个例子是调试习惯。后端排错靠日志前端排错靠界面上的状态反馈。Agent这种“异步、多中间态、偶尔需要人去确认”的系统恰恰需要把每一步的意图、观察、结果可视化地暴露出来。谁最会做这种可视化前端。与其说AI Agent在替代前端不如说它在把前端推到更核心的位置。3.3 哪些前端经验迁移不了要老老实实重学只讲“前端好迁移”那是鸡汤。我也必须说实话有三样东西真的要从头学。第一是“概率性思维”。前端习惯确定性一个点击事件就该有明确结果。Agent不一样同一个Prompt、同一套参数结果可能每次都不一样。设计和调试都要接受这种不确定并为此增加校验、兜底和人工介入。第二是“上下文与记忆管理”。前端处理的是页面状态Agent处理的是模型上下文窗口。你能把页面状态做成全局Store但上下文窗口塞不下无限历史必须设计摘要、裁剪、检索。这是一个全新的抽象层次。第三是“成本意识”。前端页面多加载点图片顶多是流量费Agent多传一段文本就是模型账单。这三个认知比任何框架学习都重要也是我第67天最大的思维变化。4. AI Agent主流架构拆解从“调API玩具”到“生产级系统”4.1 先理解token它是Agent的货币我前面已经提过token这里展开讲透。token就是大模型处理文本的最基本单位你可以把它理解成“字符块”英文单词按空格切中文按字或词组切。模型按token计费同时上下文窗口也有token上限。生产级Agent里一次调用通常不止用户的一句话。它至少包括系统提示词、用户消息、历史会话摘要、工具调用结果、模型中间推理。我算过一笔账一个自动化发布任务如果设计不合理一次任务可能消耗4万token设计合理可能只要5000 token差距8倍。前端同学最容易犯的错是像处理页面资源那样不心疼“内容传输大小”。我建议刚开始做Agent的人去开一个token用量监控报表盯一周你就会对提示词产生敬畏。4.2 主流架构单Agent、流程编排、多Agent协作现在打开任何一家大厂的Agent白皮书术语都很唬人。拆掉术语壳子主流架构基本是三层半内核层大模型本身负责理解和生成。能力层工具调用Function Calling、知识库与记忆RAG、向量数据库、外部API。协作层单Agent循环观察→计划→行动或多Agent协作规划Agent、执行Agent、审查Agent。支撑层可观测、安全、评估、缓存、限流、人工介入。单Agent循环我前面已经用到了。多Agent场景更复杂比如“规划Agent”负责拆解目标“执行Agent”负责调用工具“审查Agent”负责检查结果。不是所有场景都需要多Agent我见过很多团队为了架构好看硬上多Agent结果token成本翻倍、错误更难追踪。常见原则是任务链路短、依赖少单Agent就够任务复杂、需要不同角色质检才考虑多Agent。我当时在几个主流入口之间做了一轮对比也给前端同行一个参考入口本质前端上手的友好度适合场景LangChain编程框架写代码中等要会Python/TS深度定制、生产级Dify等可视化平台拖拽式编排高几乎不用写代码快速原型、内部工具商业Agent平台托管式Agent服务高配置为主快速验证、依赖厂商完全自建全部自己维护低学习曲线陡对隐私和成本敏感前端的建议是先在可视化平台跑通业务闭环再用编程框架按生产标准重写最后才决定要不要自建。别一上来就挑战最难路线。4.3 为什么总听到“基于Rust语言做AI Agent”最近搜索榜上“基于rust语言ai agent”的热度很高这背后确实有技术逻辑Rust的性能和内存安全很适合高并发的Agent运行时。很多Agent基础设施项目后来都用Rust重写了核心组件主打低延迟和高吞吐。但我对前端同行的建议是语言别成为焦虑源。Agent工作的核心难点是理解任务拆解、工具调用、上下文管理、反馈闭环。你用Python、TypeScript还是Rust影响的是实现层面的性能不影响你设计Agent流程的智慧。别人用Rust写核心运行时我用TypeScript写业务编排两者可以在同一个系统里共存。语言是工程选型不是身份标签。4.4 部署的两种路线先托管验证再自建沉淀部署环节我初期用托管平台比较多因为它把模型调用、工具配置、日志监控打包好了十分钟能跑一个Hello Agent。等练手项目成熟再考虑自建。自建的好处是数据私有化、成本可控坏处是自己维护模型运维、向量库和弹性扩展对前端团队短期不是最优解。纯前端线上免费部署过静态站点的同学应该很熟悉“免费额度”这件事。Agent托管平台也类似很多有免费额度但只适合调试不适合生产。等做生产级部署时至少要考虑模型调用、向量库、服务转发这些费用。对了再强调一次安全底线API Key绝对不能进前端包Agent的密钥、数据库连接、内部接口地址一律走后端网关。这个底线我从Day 1喊到Day 67等真的有人把Key泄露出去你会感谢这句唠叨。5. 白天带团队晚上学Agent一个Leader的转型管理课5.1 时间从哪来我的三段式时间管理在职学习最现实的问题就是时间。我目前固定三段早晨6:30到7:30读文档、看架构文章。这个时段大脑干净适合吸收抽象概念。午休前30分钟刷社区里Agent实战帖记录灵感看到好工具就丢进收藏夹。周末上午完整3小时专门做动手项目比如第2章那个自动发布Agent。为了避免“切换成本”我把学习资料全部收敛在一个笔记库里按概念、架构、工具、踩坑、面试五个维度拆好打开就进入状态不浪费意志力。另外我刻意在工作日白天保持“完全不碰Agent学习”的纪律——Leader一旦在白天琢磨新技能很容易被业务节奏拖垮预期。5.2 把个人学习变成团队资产一个人偷偷学越学越容易被当成不务正业。我的解法是把它打开变成团队实验项目。具体操作不复杂每周五周会最后10分钟分享一个本周学到的Agent案例然后问团队一句我们哪个业务痛点适合拿来作为这个思路的实践这么做了四周之后团队认领了两个试点一个是用Agent做代码评审自动从PR描述里提取变更影响点另一个是把客服FAQ问答做成机器人。前者前后端协作后者纯前端就能做。这些试点不一定都成功但让每个人开始接触“Agent怎么和业务结合”。团队一起学比一个人学的好处有两点一是人多力量大能相互补位二是最终交付成果可以向上汇报让老板看到这不是个人镀金而是团队能力建设。5.3 向上管理用业务难题换学习空间Leader转型很容易被质疑“心思不在业务上”。我的策略是“用业务难题换学习空间”。比如老板说要做告警自动摘要我接话现有规则引擎只能做严重程度分级摘要工作量大且容易漏能不能拨一小块后端接口配合我做Agent试点这种话术的关键在于始终把Agent定位成“解决业务存量问题的工具”而不是“我的个人兴趣”。老板看到的目标是降本增效我看到的额外收益是技能迁移。建议所有想转型的Leader都养成一个小习惯每个试点项目都留一个“业务价值”段落放在周报里。不用夸大就写清楚这个Agent替代了多少人工工时、准确率多少、还有哪些风险。这份记录将来既是你向上要预算的依据也是你写简历的素材。6. 下一个七天计划从Day 67到Day 74我要做什么6.1 把练手项目工程化而不是停在Demo自动发布Agent能跑但代码还是“单体脚本前端审核台”的糙样。接下来七天我要做三件事一是把处理层从脚本拆成独立服务加入QPS限制、幂等控制和错误重试。二是给审核台增加基于SSE的“Agent实时日志”让运营能看着每一步动作进行核查。这既是体验优化也是可观测性建设。三是补部署文档和回滚方案尤其是密钥管理和环境变量配置。等这三件事做完这个项目才算是一个能在简历和面试里真正拿得出手的完整作品。6.2 把学习笔记整理成面试弹药前端面试题大家都会刷但AI Agent岗位的面试题其实有自己的一套。我整理了十几个高频题比如Agent和传统规则/流程编排的区别是什么RAG是什么什么时候不需要RAG工具调用的结果要不要让模型“看到”为什么多Agent协作相比单Agent的代价是什么如果Agent遇到Prompt注入你会怎么防御每一道题我都强迫自己用“前端能听懂的类比”写一遍再讲给团队里的应届生听。能讲明白才算真会。比如“工具调用的结果要不要给模型看”可以类比成前端调接口后把返回结果渲染到页面上用户看到了但页面也要决定哪些字段显示、哪些隐藏。模型看工具结果也一样不是所有原始结果都应该塞回上下文只摘出要用的信息否则token和上下文都被浪费。6.3 给同路人最后五条建议第一先别辞职。在职学习的压力反而是筛选器能帮你看清自己是不是三分钟热度。真想清楚转行至少坚持120天再考虑下一步。第二前端技能不是包袱是最独特的入口。没有谁规定AI Agent只能长成接口文档的样子它也需要有人把复杂流程设计得对人类友好这是前端的老本行。第三花钱要花在刀刃上。我记账67天最值钱的投资不是课程而是token费。小项目跑十遍胜过听十节理论课。第四远离“焦虑式刷帖”。每次打开搜索热词都在滚动刷多了反而不会动手。正确的姿势是把一个热词变成一个小实验比如看到“基于rust语言ai agent”就去查Rust在Agent运行时里到底解决了什么问题而不是焦虑自己不会Rust。第五给自己一个落地场景。内容发布、代码评审、简历匹配都可以但一定要让真实用户用起来。反馈会逼着你把一个玩具项目磨成真正的作品。写到这里正好是Day 67深夜。说实话这种感觉很像我10年前第一次学Vue白天写jQuery晚上折腾脚手架兴奋和焦虑对半分。不一样的是以前焦虑“能不能学会框架”现在焦虑的是“能不能在范式转移中继续提供价值”。但不管怎样前端的13年让我学会一件事任何值得做的事开始的样子都是乱七八糟的。AI Agent这条路我大概率还要走几百个Day但有前端这块地基垫着我不觉得自己是从零转行更像是在原来的底图上叠一条新的等高线。下一步我打算把自动发布Agent的工程化过程整理成一篇带代码的实战拆解包含前端审核台、Worker上传和token压缩三块。如果你也在用前端技术做Agent相关项目欢迎在评论区聊聊你的选型和踩坑。