前端Leader的第70天当我终于不再用前端思维学AI Agent写这篇记录的时候刚好是我给自己定的转行学习计划第70天。坐标一个正在带6人前端团队的在职Leader目标在保持主业不掉链子的前提下系统性地掌握AI Agent开发能力并逐步接到实际项目。先交代一下这70天我踩过的弯路、现在的进度、以及最关键的——我是怎么发现用前端那套学习方式去学Agent这件事本身就是最大障碍的。如果你也是前端背景正在犹豫要不要往Agent方向伸手这篇文章应该能让你少走我前面40天走过的弯路。全文涉及大量实操细节和具体代码思路已经跑通的、还没跑通的、踩坑踩到怀疑人生的我都会放在后面各节里按主题拆开讲。1. 第40天之前我差点用调接口的思路把Agent学废掉1.1 前端人的本能反应先找SDK和封装我得承认我最初对AI Agent的学习方式特别前端——先搜有没有现成的SDK、有没有封装好的组件、社区里哪个库star最多。头两周我花了大把时间在调研OpenAI SDK、LangChain的JavaScript版本、各种Agent框架的Node.js适配层上甚至还专门去看了一些基于Rust写的Agent框架的文档因为它们在并发性能和资源占用上确实有优势想着以后做服务端渲染或边缘计算会不会用得上。但问题很快就暴露了我拿着前端的调用-渲染模型去理解Agent本质上是把Agent当成一个黑盒API——输入prompt输出结果完事。可Agent开发的核心根本不是怎么把大模型接口调通而是怎么让模型在一个复杂的任务链路里做出正确决策。这个认知不扭转后面所有的学习都是白费。1.2 转折点一个反问让我停下来真正让我停下来反思的是我带团队时的一个场景。我们接到一个内部需求做一个自动收集竞品信息并生成周报的小工具。按我的第一直觉这事太简单了——调大模型接口给它一个模板让它根据抓取到的数据填内容就行。可当我真的把需求拆开需要从不同站点抓数据、需要判断哪些信息是新增的、需要去重、需要按固定格式生成Markdown表格、需要处理某个站点改版导致的选择器失效……每一步都不是一次生成能搞定的。这里涉及的是一个多轮决策、工具调用、异常处理的问题。我当时的Leader技术总监问了我一句话你觉得这个需求里哪个环节你自己最不确定怎么写我想了半天答案是我不知道怎么让它自己意识到该换一个数据源。这个瞬间我突然明白了——前端开发的核心是实现确定性逻辑而Agent开发的核心是驾驭不确定性。前者世界里if-else就那几个分支逻辑错了可以跑单测后者世界里模型的输出有概率性同样一句话这次这样理解下次可能那样理解你设计的链路必须在概率性输出之上保证稳定性。1.3 学习路线的前期复盘从40天到70天我做了哪些调整意识到问题之后我重新规划了学习路径。这里把前70天的完整节奏列出来供参考第1~10天大模型基础。重点不是API怎么调而是token机制、上下文窗口、温度参数、system prompt和user prompt的分工逻辑。第11~20天Agent核心概念梳理。工具调用function calling、ReAct模式、规划planning、记忆memory、多Agent协作。这些概念必须和实际代码一一对应不能只看概念。第21~30天动手写一个极简Agent框架。不依赖LangChain这类大而全的东西纯粹用Node.js 大模型API逐行实现一个能调用外部工具的Agent。这30天是认知提升最快的阶段。第31~40天接入真实工具链。写了一个能查数据库、能调内部接口、能在结果不满足条件时自动重试的Agent跑通了一个内部数据问答场景。第41~50天深入学习Agent主流架构。包括单Agent、多Agent协作、Human-in-the-loop几种模式的取舍以及它们对应的业务场景。第51~60天工程化方向。第一版小型Agent系统落地到公司内部试用涉及部署、日志、错误追踪、token成本监控。第61~70天回到前端本身——如何把Agent能力包装成同事爱用的界面。以及我正在做的可视化Agent工作流编排工具下面会详细讲。可以看到前期40天基本是在调整认知后30天开始真正出活。2. 从组件思维到Agent思维前端Leader的认知迁移清单2.1 组件化 vs. 工具化前端Leader对组件化再熟悉不过了一个Button组件一个Table组件定义好props、events、slots然后在业务页面里组装。这套思维在开发复杂前端应用时非常好用抽象粒度清晰复用性强团队协作边界明确。但Agent开发里的工具tool虽然表面上也是定义输入输出的抽象本质上却有巨大差异。组件是被动的——用户点击、数据传入、组件响应行为是确定性的工具是主动的——Agent根据当前任务决定要不要调用、以什么参数调用、调用之后怎么处理结果。换句话说组件是等事件工具是等决策。这直接影响了代码组织方式。前端代码里你很容易说清楚什么条件下走哪个分支Agent代码里你只能给出大致的原则让模型去判断。这就意味着你的工具定义必须写得极其清楚描述什么时候该用、什么时候不该用、参数是什么格式、返回值代表什么、失败时应该怎么办。工具描述的质量直接决定Agent行为的上限。2.2 状态管理 vs. 记忆系统做前端的人对状态管理肯定不陌生——Vuex、Pinia、Redux本质上是管理全局共享数据的一致性。Agent开发里也有类似的东西叫记忆系统但它的复杂程度要高好几个量级。前端状态是确定的结构化数据你已经知道有哪些字段、什么类型、怎么更新Agent记忆是混合的——既有结构化的对话记录、任务状态又有非结构化的长期知识、用户偏好、历史决策上下文。更麻烦的是你还需要区分短期记忆当前任务上下文和长期记忆跨任务的经验以及如何让记忆不占用过多token。我在第25天的时候就是因为没做好记忆管理导致Agent在多轮对话里忘记了用户已经提供过某个关键参数反复追问同样的问题被体验的同事吐槽像个健忘的客服。后来我专门做了一个简单的记忆模块把已收集到的关键信息同步给下一次上下文问题才解决。2.3 组件通信 vs. Agent之间的消息传递多Agent协作是Agent主流架构里很重要的方向也是我认为前端人最容易上手的一块——因为Agent之间的消息传递和组件之间的通信在概念上非常像。前端组件通信有props、自定义事件、全局状态、ref对应到多Agent架构里就是Agent之间的显式消息、共享上下文、或者统一的调度中心。我画过一个对照表帮助团队里的前端同学理解props 向下传参对应父Agent给子Agent分配子任务自定义事件向上抛对应子Agent返回结果给父Agent全局共享状态对应多个Agent读写同一个上下文存储ref直接调用对应Agent之间点对点的工具调用但凡你带过一个稍微复杂点的前端团队你就能秒懂多Agent协作里最核心的问题——消息格式和协议一致性。前端多个人改同一个页面你需要commit规范、接口文档、类型定义多Agent协作也一样每个Agent的输入输出都得有一套严格定义的协议否则底层模型的理解稍微漂移整个协作链路就断了。2.4 前端性能优化 vs. Agent成本优化前端性能优化的核心是用户等待时间、CPU占用、内存占用Agent成本优化的核心是token消耗、API调用次数、失败重试次数。表面上完全不同但优化思路惊人地相似前端减少DOM操作对应Agent减少无效推理轮次前端懒加载对应Agent按需引入工具而不是把所有工具描述都塞进上下文前端缓存对应Agent记忆复用避免每次都从头开始理解任务我在第60天做token成本统计时发现有30%的token花在了同一个Agent反复确认用户意图上原因是提示词里没有把意图识别逻辑前置。后来我把意图识别拆成一个独立的小Agent先用轻量模型快速判断意图再路由到不同的专业Agenttoken成本直接降了一半。这就像前端做首屏优化先把关键路径压缩再让非核心组件按需加载。3. 第70天进行时我正在重构的可视化Agent工作流编排器3.1 为什么是可视化编排——从一个具体场景说起我的主业是前端Leader公司内部已经有从零搭起来的组件库和一套管理后台脚手架。前段时间内部有个需求非技术同事运营、数据分析要把一些重复性的数据处理流程自动化——比如每天定时抓取某个数据源、清洗、汇总、发企业微信通知。如果直接让他们写代码不现实如果每次都需要开发介入效率又太低。于是我的想法是做一个可视化Agent工作流编排器画布上有节点每个节点代表一个操作数据源、清洗、大模型推理、Webhook通知等节点之间连线表示执行顺序。用户拖拽、配置参数后台自动生成Agent执行链路。这个想法不是凭空来的——现在市面上已经有不少Agent编排产品但大多面向开发者交互仍然偏技术化。我要做的是让公司里不懂代码的人也能编排自己的Agent流程同时保证灵活度不输给代码方式。3.2 技术选型为什么还是选了纯前端这里先说结论编排器的核心交互层我用了纯前端实现没有套任何低代码平台原因是内部业务的灵活性和可维护性更可控。画布部分最初考虑过用市面上成熟的前端组件库但它们的扩展性在自定义节点类型、复杂拖拽逻辑、动态端口连线上不太够用。最终我选择用Canvas来实现画布层DOM只做浮层节点配置面板。渲染性能实测下来很稳即便画布上挂到200多个节点交互依然流畅。这里给同样想做这个方向的朋友一个参考画布渲染Canvas自绘节点图形已经做了半年的内部积累边角圆形、端口状态、执行动画这些细节都踩过一遍交互拖拽连线、框选、缩放手势节点类型注册用了一套类似于前端组件注册的机制每个节点类型对应一个处理器、一个配置Panel、一个预览组件运行引擎每个节点编译成一个可执行的Tool函数连线编译成执行顺序的DAG底层由Agent调度3.3 工作流引擎的前端设计细节运行引擎这部分我和团队讨论了很久最后确定了和现在Agent主流架构一致的思路节点即工具每个节点最终会被编译成Agent的一个工具调用由Agent根据当前任务上下文决定是否触发。DAG编排连线定义了拓扑顺序引擎执行时先做一次DAG校验避免循环依赖。条件分支允许节点输出是否满足条件的结果然后根据条件走不同的下游节点对应Agent里的条件判断。这里有个很关键的细节——节点和节点之间传什么、怎么传。前端组件通信是有明确类型定义的而工作流里节点间传递的数据五花八门可能是结构化JSON可能是大段文本可能是文件路径。我们的方案是统一消息协议所有节点输出包装成一个标准结构{ data, meta, status }其中meta记录数据来源、生成时间、token消耗方便后续排查问题。到目前为止最复杂的是循环节点。前端里最简单的循环就是数组的map但工作流里的循环可能是反复处理一个文件列表直到全部完成期间还可能出现某个文件处理失败、需要跳过不阻塞后续节点。我们先把for-each语义做好了更复杂的带条件循环还在排期。3.4 一个前端组件库没教我的事引擎与画布的联动从前端视角看画布编辑器和运行引擎是两个独立模块它们的交互很简单编辑器保存配置引擎加载配置各自干各自的。但实际做的时候发现根本不是这样——引擎运行时需要对画布实时回显执行状态哪个节点正在执行、执行成功还是失败、当前走到了第几个循环、哪个节点耗时异常。这直接改变了我的前端设计思路。以前做管理后台前端只需要根据接口返回的最终状态渲染UI但编排器需要长连接的实时状态流。我们用了WebSocket 二进制协议推送执行事件前端画布监听事件流在节点端口上做动画反馈。这也是我这次学习下来最大的收获之一——前端不只是展示结果还得展示过程这是Agent类产品普遍的体验要求。4. 踩坑实录Token、上下文、模型输出失控与Agent的癫痫发作4.1 token是什么以及前端人可能忽略的成本陷阱ai agent token是什么意思这类搜索本质上反映了很多人对成本模型没概念。我简单把token理解成大模型计费的最小单位一个token大约对应0.75个英文单词或0.5~1个汉字。你发给模型的每一句话、模型吐出来的每一个字、系统里塞的那些工具描述、历史记忆全都在消耗token。前端的天然习惯是尽量把所有信息都拿在客户端本地存储、全局状态、请求合并——反正客户端的计算资源不要钱。但Agent开发里上下文里多塞一段文字就是一笔真实成本。我运营内部系统之后每天看token账单强烈感受到上下文压缩和记忆清理是必须做在前面的功课而不是事后优化。举一个真实数据我们有个Agent需要读取用户上传的Excel表做数据清洗和汇总。最初实现很简单直接把Excel转成文本塞进上下文让模型理解数据。跑了一个星期token消耗高得离谱——因为Excel转文本之后非常大几千行数据就是几十万token钱哗哗地烧。后来我自己写了一个数据采样与结构提取模块先做列类型识别把数值列、日期列、文本列分开再抽样几行数据用来理解语义最后把完整数据以结构化CSV的方式交给另一个确定性代码模块处理大模型只负责判断逻辑不负责读取所有数据。这个改动让单次任务token消耗降了80%以上。4.2 上下文管理为什么Agent会失忆和精分前端里有个经验表格分页、列表虚拟滚动、懒加载都是为了不要一次性把太多东西渲染在DOM里。Agent的上下文管理本质上也类似——不要让模型一次处理太多信息否则它会抓不住重点甚至遗忘前面的关键指令。我在做内部数据问答Agent时频繁遇到一类问题用户在对话中先提供了一批筛选条件然后又问了一个新的问题Agent居然忘记了之前已经确定的筛选条件返回了完全不符合用户预期的结果。打个比方就像你在淘宝上设置了价格低于500元然后搜索篮球鞋结果页面第一屏全是800以上的鞋——这么明显的筛选条件没有被延续用户直接开骂。解决方案是分块记忆管理把所有已确认的条件用户明确说过的抽取到独立的事实区每次生成回答前把事实区里的关键信息拼接到当前问题里当对话超过一定轮数自动总结早期对话丢到长期记忆里只用摘要参加后续上下文这个方案跑起来之后失忆问题基本绝迹。4.3 模型输出不可控的治理从癫痫到稳定我最想分享的坑是模型输出不稳定带来的调试噩梦。做前端时接口返回的数据结构不对第一反应是console.log打个日志看实际返回但Agent的返回是自然语言你在日志里看到的可能是一段措辞不一样但意思一样的文本肉眼看着没问题代码里的正则匹配却挂掉了。我用癫痫发作来形容这个阶段——同一套输入Agent的回复时好时坏今天能跑通的链路明天模型升级之后突然就不走了。后来我沉淀出一套治理方案输出强约束要求模型必须输出JSON且提供严格的JSON Schema解析失败就让Agent自行修复一次。修复不了则走降级逻辑直接给用户返回暂时无法理解请换个说法。关键字段校验对返回的每一个关键字段做类型与范围校验不满足条件就触发二次调用而不是直接信任模型。结构化中间表示不让模型直接输出最终回复而是先让它输出意图、实体、操作参数的中间结构再根据这个结构拼接最终文案。这个中间表示是稳定的后续逻辑都基于结构而非自然语言从根上规避了解析不稳定的问题。现在内部系统里所有Agent的模型输出都会经过这一层净化线上稳定性明显提升。我做前端时特别强调类型安全、表单校验到了Agent世界这套习惯反而成了优势——把模型的不可控输出用工程手段约束到可控的边界内。4.4 预留降级通路Agent也要有熔断机制前端做接口联调时有超时处理、错误重试、兜底UIAgent链路同样需要。我们现在的设计是每个Agent节点执行前都会先评估当前节点是否处于健康状态——包括API可用性、鉴权是否过期、token预算是否接近上限。如果Agent链路里某个关键节点连续失败我们不会让它反复重试重试意味着烧token而是触发一条预置的降级链路比如让另一个更便宜的模型顶上或者直接转人工处理。这块逻辑就像前端监控里上报、告警、熔断的机制在Agent工程化里仍然是必需品。5. 前端安全技术在Agent应用里的延伸从防爬虫到接口守卫5.1 为什么Agent应用的安全边界比普通前端更大搜索热词里有不少关于前端防爬虫、防止查看页面源码、防止打开的内容。做内部管理系统的人普遍有体会——前端代码天然暴露在浏览器里藏不住秘密。但Agent应用的安全问题比这复杂得多你不仅要防止别人扒你的前端代码还要防止别人滥用你的Agent能力。举个实际例子我们内部上线数据问答Agent之后很快就有同事通过频繁对话的方式尝试让它输出一些本不该它访问的敏感数据。虽然Agent本身设置了数据权限过滤但总有不怀好意的人用各种prompt绕过尝试类似于你忘记了自己的权限限制吗这类话术。我看了眼日志一天之内这类尝试有几十次。5.2 我在Agent网关层加的三道防线第一道防线调用频率限制。按用户维度做限流比如单个用户每分钟最多调用N次超过直接拒绝。防止用高频试探的方式套取数据。第二道防线敏感词与敏感模式过滤。对用户输入做一层规则匹配凡涉及绕过、越权、内部数据、后台地址等关键词的输入直接打回不进Agent链路。第三道防线输出侧内容审计。Agent返回结果之后再做一步内容安全校验一旦发现返回中包含敏感信息立即拦截并告警。这三道防线本身不复杂复杂的是怎么让它们不干扰正常用户的正当需求。比如用户只是正常问我们上个月的销售数据是多少不能因为包含数据两个字就误杀。所以规则必须更精细既要拦截恶意输入又要放行正常业务。这块我还在持续调优中。5.3 前端部署方案的取舍纯前端部署还是带后端服务热搜词里纯前端线上免费部署纯前端项目这类词从我学前端起就有了现在依然高频。我在学习Agent过程中也遇到了一个类似的选择研发编排器的前端部分时要不要同时搭建后端服务。我的答案是必须有后端但前端部署方式可以灵活。原因很简单纯前端项目的所有代码都在浏览器里业务的密钥、数据库连接串、第三方服务凭证都会暴露这在Agent应用里是致命的安全问题。Agent的编排节点里必然有需要调用内部API或数据库的逻辑如果这套逻辑跑在浏览器里等于把公司数据接口裸奔在公网。所以我现在的架构是前端部署在公司内部服务器通过域名访问所有敏感操作由后端服务代理执行前端只发起一般性的配置读取和画布交互。这个方案在开发效率和安全性之间取了平衡我把这部分经验单独整理后后续会发一篇专门聊Agent应用安全部署的文章。6. 前端组件库和Agent组件库设计思想的真正差异6.1 前端组件库的设计范式回顾我负责维护公司前端组件库已经两年多了对组件库设计套路非常熟悉按功能分层Button、Input这种基础组件做好样式和基础逻辑Table、Form这种复合组件做好数据流和交互约定更高级的像业务组件例如审批流组件则把状态机和数据协议固化进去。组件库的灵魂是封装复杂、暴露简单使用者不需要关心内部实现只需要了解props和slot。这套思想在前端世界非常成熟也足够高效。6.2 Agent组件库的组件是什么到了Agent世界我开始琢磨如果把一个Agent能力单元也做成组件应该长什么样起初我把一个个工具函数当成组件后来发现不对——工具函数只是组件里的一个方法真正的Agent组件应该是一个能够独立完成一个子任务的Agent模块它有自己的提示词、工具集、上下文处理逻辑、异常兜底策略。于是我做了一套内部叫Skill组件的封装模式每个Skill组件暴露一个统一的execute(input): PromiseOutput组件内部封装完整的Agent逻辑意图判断、工具调用、记忆读写、异常排练组件之间通过事件总线通信而不是直接依赖对方的具体实现这个思路放前端类比单个Button不需要知道点击它之后全局状态会被怎么改变它只管发出一个click事件Skill组件也是一个数据清洗Skill只管完成数据清洗并把结果抛出去至于下游是生成周报Skill还是发送通知Skill它完全不关心。6.3 从组件库维护者角度看Agent组件库的治理组件库最怕的是改一个组件全站遭殃。Agent组件库也有类似问题——一个Skill组件升级时要怎么做回归验证以前前端有单元测试、快照测试、视觉回归Agent组件这边由于模型输出概率性传统测试手段基本失效。我的策略是建立黄金案例集把过去踩坑案例中发现的、必须正确处理的场景固化成测试用例每次更新Skill组件时跑一遍看输出是否符合预期。比如数据清洗Skill的黄金案例就包含Excel首行不是表头日期格式有多种写法数值列里混入文本这些情况。这个思路和前端组件库跑视觉回归测试异曲同工都是用代表性的场景集保证改动不回退。7. 这30天我对要不要转行这件事的真实答案7.1 转行不是换个技术栈是换个生产角色71天前我还在纠结要不要彻底放弃前端、转行AI Agent。现在我的答案更清晰了单纯换技术栈没什么意义转行的本质是换一个生产角色。前端开发者的传统角色是什么把产品需求变成用户能用的界面。AI Agent开发者的角色是什么把业务需求变成机器能自主执行的流程。两者都是需求到产品的转化者但后者多了一个维度的要求——你需要为机器的判断负责。前端代码错了顶多页面显示异常Agent链路错了可能自动发了一封错误的邮件、删了一条不该删的数据。这个角色转变对我这种带团队的人特别明显。以前我设计前端架构重点考虑的是团队协作、组件复用、性能体验现在设计Agent系统重点变成了数据权限、执行异常处理、人工审批环节的接入、以及如果AI搞砸了怎么收场。这是一种责任边界的转移也是我目前最需要继续建立的工程能力。7.2 前端Leader学Agent的真实优势也是在学习过程中越来越笃定的前端背景在Agent开发里不仅不算弱势反而有独特的优势。我前面提到过组件化、状态管理、事件驱动这些思维在Agent工程里的映射还有一点容易被忽略——前端是最懂用户体验的岗位。Agent最终面向的是用户Agent的回答本质上也是一种界面。一条糟糕的Agent回复和一个排版混乱的页面一样让人崩溃一个需要用户反复解释需求的Agent和一个入口藏得极深的功能一样让人反感。所以当团队里别人只顾着调好模型参数、跑通链路的时候我会额外关注Agent的时间消耗、响应速度、失败后的引导文案、是否需要调用另一个Agent来确认用户意图。事实证明这些恰恰是决定Agent产品能不能真正落到业务里的关键。7.3 给同样在观望的前端同行的建议如果你正在犹豫要不要迈出这一步我的建议是不要从学哪个框架、调哪个API开始先从理解Agent是什么、它能改变什么工作方式开始不要用学习Vue/React的方式去学Agent——那套看文档、写demo、看源码的打法在Agent领域效率很低因为Agent领域还没有一个统一的、像React同样稳定的开发范式不要裸辞转行。前端Leader的优势在于你能在自己现有的团队、已有的业务场景里找到Agent落地切口把业余项目做成实际价值比任何面试作品都有说服力8. 连载记录这件事本身是我给自己的工程化实践回到DAY70这个数字。这个连载我坚持了70天每天无论多忙都会写当天的学习进展、代码片段、坑点记录。回过头看这件事本身也在锻炼我的Agent开发基本功——把复杂过程拆解、记录、复盘这和Agent系统的构建过程本质上同构。现在我的节奏是日常仍然带前端团队晚上和周末投入Agent方向的学习和内部项目。说实话精力上确实累但相比70天前我最大的变化是不再焦虑了。焦虑的来源是不知道往哪走而现在我手里已经有了一个正在被真实用户使用的编排器、一套跑通的Agent工程架构、一堆从踩坑中沉淀下来的规范文档。如果此刻的你也站在前端与AI Agent的交叉路口听我一句过来人的话别急着定义转行成功的标准先把第30天、第50天、第70天的自己拿来和前一天的自己比。变化就是在一次次今天终于搞定了那个坑的瞬间累积起来的。