今天是第68天。加班到晚上八点前端周会刚结束我又坐回工位改了一个半小时Agent项目的上下文压缩逻辑。这不是什么轰轰烈烈的转行宣言就是一个在职前端Leader把每天的碎片时间攒起来一点一点往AI Agent这条深水区里蹚的记录。之所以写下这篇文章是因为后台收到不少同行私信问我从哪开始要不要弃前端学了能干嘛。我想用这68天的真实经历一次性把这些问题说清楚。这篇内容解决的核心问题只有一个一个带团队、写业务、天天跟组件库、微前端、性能监控打交道的前端负责人是怎么从零学习AI Agent又是怎么把它和前端经验结合起来的。适合正在观望的技术管理者、想了解Agent开发的一线前端以及准备给团队寻找AI突破口但还没方向的人。看完之后你至少能知道一条不靠背概念、不靠刷论文的学习路径也能少踩几个我踩过的坑。1. 前端Leader转型AI Agent我先想明白的几件事1.1 说句实在话这是行业风向变了我做前端大概十年带团队也有四五年手上的技术储备覆盖Vue、React、跨端、微前端、组件库建设这些常规内容。但2024下半年之后我越来越明显地感觉到一个变化AI不只是在辅助写代码而是开始成为软件本身的一部分。以前我们说的前端智能化最多是智能推荐、埋点分析现在不一样了Agent可以自主调用工具、搜索信息、操作软件、生成内容它的运行形态已经超出了页面的范畴。对前端Leader来说真正让我坐不住的不是哪天被AI替代而是我的团队未来三年、五年要交付的东西是什么。如果产品里所有的功能都会变成Agent的能力那前端参与的位置在哪里这个问题不解决团队方向就会飘。所以我决定不围观直接下场学Agent。这个决定是转型的第一推动力。1.2 前端积累不是包袱反而是转Agent的底子我之前最担心的就是前端背景全是表面功夫到了Agent领域要推倒重来。实际学下来完全不是这么回事前端经验里有大量东西可以直接平移过来。组件化思想直接对应Agent的Skill封装。前端把一个下拉框封装成组件要定义 props、slot、事件Agent里的Skill就是这么个东西——把一组指令、Prompt、工具调用封装成可以被复用、被引用、被组合的单元。状态管理的经验对应Agent的上下文管理前端处理全局store、会话持久化Agent处理短期记忆和长期记忆逻辑一样是什么该存、什么该丢、什么该从外部拿。异步编程更不用说Agent跑起来满屏都是流式输出、事件回调、并发调用这本来就是前端最熟悉的领域。哪怕是我做过的qiankun微前端拆分放到多Agent协作的场景里思想也是相通的子应用负责单一职责主应用做调度和通信。所以如果你的前端基础够扎实转Agent不是从零开始而是换一套运行环境把你的工程能力重放一遍。1.3 第68天回头看这条学习路径是可以复制的很多刚起步的朋友问我到底怎么学其实我的路径并不复杂分四个阶段。第1到15天是认知搭建阶段。目标不是写代码而是搞明白Agent是什么、它跟普通程序的区别在哪、有哪些基础设施。我会去看一些主流架构的文章也会拿ChatGPT、Cursor这类工具当观察对象分析它们背后可能的运行逻辑。第16到35天是框架和协议阶段。开始动手调用大模型API做最简单的多轮对话再尝试Function Calling理解工具调用是怎么发生的。这个阶段最痛苦因为要从面向逻辑变成面向意图让模型学会自己决定调什么工具。第36到55天是实战阶段。用前端配套的技术栈把Agent完整跑起来配了UI、流式输出、会话管理然后开始做具体场景比如语音转写和自动化助手。就是这个阶段让我真正觉得自己不是门外汉了。第56到68天是工程化打磨阶段。整理上下文策略、封装Skill、设计工具协议、加点防御性处理。现在回头看这个路径最大的好处是顺序正确先有认知再动手先跑通再优化。我见过太多人上来就调框架结果看了十天文档还没跑通一个对话越学越没底气。2. AI Agent主流架构拆解我摸清的核心概念2.1 Agent和普通接口调用的本质区别它是一个循环传统前端的开发模式是页面发起请求后端返回数据前端渲染。整个链路是确定的、可预期的。Agent不是这么玩的它的核心是一个循环——模型基于目标和当前状态推理决定下一步动作执行动作得到结果再把结果追加进上下文重新推理直到完成任务。这个模式叫ReAct即Reasoning加Acting。用代码去理解的话Agent本质上是一个while循环循环体里发生着思考-行动-观察的迭代。我第一次写出这种循环的时候有一种很强的错位感我以前写代码是控制每一行现在写Agent是设计一个让模型自己决策的框架。传统程序是函数Agent是循环这一点如果你能尽早想明白后面所有概念都顺了。2.2 四个核心模块模型、规划、工具、记忆我习惯把Agent拆成四个模块来理解。模型是决策大脑负责理解上下文、生成推理和输出。但前端工程师要记住模型是概率引擎不是规则引擎它有幻觉、有随机性所以Agent工程的核心就是在不确定性上建确定性系统。规划是这个大脑的工作方式包括让模型思考后回答的CoT也包括把大任务拆成子任务再分头执行的Plan-and-Execute后面的多Agent协作本质上也属于规划的范畴。工具是Agent的手脚。大模型再强也没法直接查数据库、调接口、操作浏览器所以Agent要能调用外部函数。这个机制在OpenAI里叫Function Calling在业界标准协议里叫MCP。我把它类比成后端注册了一堆REST接口模型就是那个知道怎么用接口但不会写接口的消费者。记忆是Agent的持久化仓储。短期记忆就是上下文窗口里的对话历史长期记忆则是通过向量数据库存的业务知识和历史事实需要时用检索召回。拿前端类比短期记忆像内存里的store长期记忆像localStorage加索引。2.3 Token和上下文前端人最容易忽略的性能指标我第一次接触Token这个概念时以为它就是字数统计后来算了一笔账才明白Token是Agent项目里的成本单位和性能瓶颈。输入给模型的每一段文本、工具返回的每一份数据都要按Token计费输出也要计费上下文越长单次请求越贵响应越慢。这就逼着你做上下文治理我现在的做法是三个策略配合。第一是截断把最旧的低价值对话直接丢掉。第二是摘要让模型把早期对话压缩成几句话替代原始内容。第三是检索不同业务知识存进向量库按需要拉取。这就像前端做长列表要分页、做大数据要虚拟滚动。上下文也是资源也要用算计的心态去管理。我现在每次排查Agent表现异常第一反应就是先把最近的上下文全打印出来看一遍十次有八次问题出在该记住的丢了、不该塞进来的全塞进来了。2.4 主流框架选择别被生态绑架这68天里我过了一遍主流框架是非对错先不论适配前端背景的优先级是明确的。用表格整理一下我的对比结论框架/方案技术栈适合谁我的使用评价Vercel AI SDKTypeScript前端团队流式输出、UI集成最顺工程味重LangChain.jsTypeScript想快速搭多工具链路抽象层厚调试时心智负担偏高Dify可视化编排快速验证业务场景拖拽能用深入控制就得写代码CrewAI / AutoGenPython研究多Agent协作生态偏学术生产化要自己填坑自研运行时任意核心能力沉淀需求最费劲但最可控至于热词里一直在传的Rust语言AI Agent我也研究过。它确实扛得住高并发、低延迟适合做语音转写、本地推理链路这类偏重性能的基础设施但对我们前端团队来说现阶段自研Rust Agent有点超前。我的判断是先靠TypeScript生态把业务跑通等真遇到了语言层瓶颈再考虑Rust下沉一步到位容易噎着。3. 用前端技术栈实操搭建Agent关键步骤与代码实现3.1 技术选型逻辑为什么我从TypeScript生态切入这个问题被问过很多次转AI Agent为什么不用Python我的理由有三个。第一团队零成本迁移。我们组全员都会TypeScript选一个TS生态的Agent方案大家不需要学新语言就能进入状态。第二工程链路统一。我的目标是把Agent能力嵌进前端应用里TypeScript可以同时写页面、写Node服务、写云函数部署链路跟现有前端CI/CD完全打通。第三生态已经够用。OpenAI、Anthropic等主流服务商的SDK都有TypeScript版本Vercel AI SDK和LangChain.js也都成熟。Python当然有其优势但它是更好的选择不是唯一的选择。前端团队入局的关键是先跑起来技术栈越贴近现状越好。3.2 最小闭环一个带工具调用的Agent循环我不建议一开始就上重型框架这里放一个我自己写的极简版Agent循环核心逻辑就二三十行看懂它你就明白Agent本质了。import OpenAI from openai; const client new OpenAI({ baseURL: process.env.LLM_BASE_URL, apiKey: process.env.LLM_API_KEY, }); async function runAgent(task: string, tools: Tool[]) { const messages: ChatMessage[] [ { role: system, content: 你是一个可靠的助手请根据需要调用工具完成任务。 }, { role: user, content: task }, ]; const maxSteps 10; for (let i 0; i maxSteps; i) { const res await client.chat.completions.create({ model: gpt-4o-mini, messages, tools: tools.map((t) t.schema), }); const msg res.choices[0].message; messages.push(msg); const calls msg.tool_calls; if (!calls || calls.length 0) { // 没有工具调用说明Agent已得到最终答案 return msg.content; } for (const call of calls) { const tool tools.find((t) t.name call.function.name); if (!tool) continue; const result await tool.execute(JSON.parse(call.function.arguments)); // 把工具执行结果回传给模型成为下一轮的依据 messages.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(result), }); } } throw new Error(Agent steps limit exceeded); }这个循环里有几个值得注意的细节。maxSteps必须设上限Agent一旦陷入自我对话会无休止地调工具这是成本黑洞。工具调用结果一定要结构化返回不要返回一大段废话文本模型解析起来成本高还容易出错。messages必须完整维护每一轮的推理和工具结果都要追加进去少了任何一段模型的决策上下文就不完整。我第一次跑通这个循环时Agent连续调了八次工具才给出答案我当时第一反应是它是不是坏了后来才意识到八次调用背后是八步推理链条只要每步都有意义就属于正常行为。3.3 前端能接力的部分流式输出、会话状态与UIAgent跑起来了接下来就是前端的本职工作——把交互体验做好。流式输出是目前Agent交互的标配后端通过SSE或流式响应持续吐Token前端用fetch的ReadableStream解析。我这里不贴完整代码核心逻辑就是用reader循环读取数据块通过parse chunk把内容增量渲染到页面上配合Markdown渲染器让用户看到逐字生成的效果。关键注意点是中断处理用户点停止按钮时要取消读取并断开链接否则后端还在继续生成白白计费。会话状态管理上我直接沿用了前端的那套思路短期会话放内存store历史会话落到IndexedDBAgent的长期记忆对接向量库。界面上我把工具调用过程展示成一个运行日志面板用户能看到Agent正在调用哪个工具、传了什么参数、返回了什么结果。这一步很受团队欢迎因为透明化的Agent会让用户更信任它。这些能力做下来我可以很自信地说一个前端Leader在Agent项目里不是边缘角色恰恰相反体验、透明度、异常反馈这些决定Agent能否被真正使用的地方全是前端的主场。3.4 安全与部署Agent不是纯前端项目这里必须泼一盆冷水。Agent项目的API Key绝对不能放前端浏览器里没有任何秘密你写在代码里的密钥等于送给所有人的。我在团队内部推行的规范是大模型的Key只存在于服务端环境变量前端通过业务后端转发请求业务后端统一做鉴权、限流和内容脱敏防止有人绕过页面直接打推理接口。前端侧也要上CSP策略限制脚本来源页面层面要对用户输入做长度限制和敏感词过滤防止提示词注入。部署方面我的建议是不要试图做一个纯前端Agent。因为模型调用和工具执行必须发生在受控环境里所以至少要有一个无状态的API服务前端部分照常走静态托管。最舒服的组合是Next.js这类全栈框架API Routes里跑Agent逻辑页面部分按前端习惯部署云函数冷启动会有几十到几百毫秒延迟但个人项目体验完全能接受。做自动化操作类Agent时更要谨慎只允许在授权测试环境里用真机或模拟器涉及第三方平台的自动化操作必须遵守对应平台的接口规范和使用规则这既是法律底线也是技术人的职业操守。4. 两个实战项目的完整复盘语音转写与自动化发布助手4.1 实战一实时语音转写大模型的前端适配这个项目源于我们内部的一场技术评估需要评估实时会议记录的可行性。技术链路的前半段是语音识别后端接讯飞实时语音转写能力前端用MediaRecorder采集麦克风音频通过WebSocket推流后端转写结果以增量文本的方式实时返回。后半段是大模型理解把转写文本喂给Agent让Agent整理纪要、提取待办、识别发言人意图。前端适配的坑主要体现在三个地方。一是音频参数实测下来16kHz单声道PCM的效果和性价比最平衡过高的采样率只会增加带宽和计费。二是断句策略转写文本是持续流入的如果每来一段就发给Agent一次Token成本直接爆炸我的方案是缓冲两秒或累积满几十字后再发一次配合标点做自然断句。三是重连机制WebSocket断开后要自动重连并恢复音频流同时把断开期间的音频缓存起来避免漏段。这个项目跑通后我用它连着录了三场周会转写加纪要的效果已经能省掉大半人工记录时间而且它让我确认了一个判断语音输入未来一定会成为Agent的主入口之一谁抢先把链路做好谁就先拥有体验优势。4.2 实战二半自动发布助手的技术原型验证这个项目源于团队里一个很常见的抱怨每天重复在多个系统之间复制粘贴内容浪费时间。我搭了一个半自动发布助手的技术原型核心不是暴力爬取数据而是把人在浏览器里的重复操作抽象成Agent化的工作流。用Playwright控制浏览器环境模拟表单填写、按钮点击和信息回填由Agent根据规则决策什么时候做哪一步。整个验证跑下来有两点让我印象深刻。一是规则和Agent的配合关系前端工程师习惯把一切写成确定性的if else但发布助手场景里不同页面结构的细微差异让纯规则很难维护改用Agent理解页面后适应性能大幅提升。二是这个过程的合规风险涉及任何平台的自动化操作都要严格限制在授权的测试账号、公开接口或模拟环境里不针对真实线上用户数据操作更不能用于绕过平台的频率限制或审核机制。作为一个技术原型它的价值是证明重复操作可以被Agent化而不是教人怎么薅平台羊毛。这个度必须拿捏清楚。4.3 复盘后的工程化思考做完这两个项目我最深的感触是Agent项目的交付物不再只有代码还包括Prompt、Skill文档、工具定义和测试集。以前前端交付组件要有props说明、使用文档、单元测试Agent交付一个能力同样要有触发它的指令模板、工具调用说明、边界行为定义、效果评估标准。我甚至把团队日常的代码评审流程抽象成了一个Skill输入一段变更代码工具调用静态检查接口获取评分结合历史提交记录判断风险等级最后输出评审意见。这种做法让我重新理解了前端Leader在AI时代的角色不只是写代码还要定义AI怎么使用我们的代码资产。团队协作方式也在改变现在做一个Agent功能至少需要三种角色协同写Prompt的人理解意图写工具的人对接系统写前端的人保证交互闭环。以前我们只在技术栈内分工现在分工维度完全变了。5. 68天踩坑实录高频问题、方向误区与个人心得5.1 高频问题排查速查表我把这68天里反复踩到的问题整理成一个表格每个问题都附上了实际有效的排查手段。现象常见原因排查方法落地解决Agent不调用工具工具描述写得不清晰、模型没识别意图打印模型原始返回看tool_calls为空的原因重写工具描述写明触发条件、入参格式、示例反复调用同一工具缺终止条件、工具结果不足以得出结论检查返回结果是否包含可判断完成的信息在结果里附加状态字段Agent据此退出循环上下文膨胀后开始答非所问历史消息无限堆积、关键信息被淹没打印消息长度和首轮系统指令是否被挤出做截断策略首轮系统指令每次请求都重新注入Token成本异常飙升工具返回数据过大、被重复塞进上下文看每次请求body大小和工具结果长度工具返回只保留摘要字段完整数据落到外部存储WebSocket数据流断断续续未做心跳检测、弱网切换未重连加网络状态监听打印断线日志实现指数退避重连缓存断线期间数据恢复后补传流式输出中途卡住前端读流异常、后端队列阻塞抓包看响应流是否在持续输出前端超时后主动断开后端加超时保护和队列上限围绕这些表格我想多说一句Agent调试最大的障碍不是技术不会而是运行过程不可见。所以我养成了给Agent运行时加日志的习惯把每一步思考、调用、观察都打印出来。这个习惯至少帮我省了一半的排查时间。5.2 前端转AI Agent的三条方向性误区我看到太多人倒在错误的方向上。第一是死磕数学和论文觉得不懂Transformer就不配搞Agent真实项目里用不到这些先会用再理解需要的时候回头补完全来得及。第二是迷信LangChain这类框架以为接上框架就等于会Agent框架只是脚手架真正的核心是对模型行为的理解和对业务的拆分能力。第三是拿Agent当接口用期望给它一个输入就稳定返回固定结构的输出可Agent的本质是概率决策必须做好容错、重试和校验机制。想清楚这三点可以少走很多弯路。另外关于Rust语言AI Agent我再补充一句个人判断如果你对Agent运行时性能有执念想在本地边缘设备跑自治Agent或者要做低延迟的语音Agent网关Rust确实值得投入。但对于绝大多数前端团队先用TypeScript把业务和体验验证完再决定要不要用Rust做性能下沉模块是投入产出比最高的路径。5.3 学习节奏与团队管理的实际体会我能坚持68天靠的不是意志力而是把学习嵌进了工作流程。固定早上早起一小时用来读文档和写代码晚上如果不加班就拿出一小时做项目周末留一个完整下午处理难啃的问题。更重要的是学以致用我把这个学习项目跟团队需求绑在一起语音转写是团队会议纪要的真实痛点发布助手是我们内部运营的重复劳动问题有了真实场景学习驱动力完全不同。团队这边我现在的做法是组建了一个AI工具兴趣小组每周做一次内部分享每个人都要带一个Agent小实验来不限制方向。两周下来组里已经有人做出了自动生成周报的Agent工具也有人把前端组件库的文档Agent化了。作为Leader我越来越觉得转型不只是一个人的事如果能把学习经验沉淀成团队能力前端团队的边界就能往上一层。最后再分享一个我个人的体会。第68天我不能说我已经转型成了AI Agent专家但至少我看清了方向前端在Agent时代不是没有位置而是位置变得更加核心谁能定义Agent的交互方式谁能让Agent的能力被用户信任和使用谁就能在下一代软件里站住脚。如果你也在考虑这条路不用等全部准备好了再开始就从今天从读一遍这篇总结从跑通一个最小Agent循环开始。你先走一步就已经比停下来的人领先了68天。
