刚完成今天的学习复盘窗外天已经黑透了。第68天从一名在职前端Leader的视角持续跟进AI Agent这个方向最大的感受是真正难的不是学会某个框架怎么用而是把过去这几年在前端领域积累的思维方式和工程经验重新映射到Agent这个新战场上。这篇笔记打算把DAY68前后这段时间的思考完整写下来。内容会比较杂有架构层面的认知更新有前端技能在Agent场景下的具体落点也有安全、面试、工程化这些容易被忽略但实际很要命的细节。希望能给同样在职、同样想往AI Agent方向探索的前端同行一些参考。1. 先聊清楚前端Leader转型AI Agent转的到底是什么很多前端朋友一听说“转AI Agent”第一反应是去背LangChain文档、刷LangGraph教程或者到处收集Agent项目源码。我前三十天差不多也是这么干的但越往后越发现这条路如果不先解决认知问题学多少工具都是浮沙上盖楼。1.1 核心不是“写Agent”而是“设计Agent的工作流”我带的团队一直做中后台前端每天接触的无非是组件、状态管理、接口联调、性能优化。这些东西的特点是输入输出相对确定边界比较清晰。但AI Agent不是这样的。Agent的核心是让模型在一个目标约束下自主完成一系列决策和行动。这里面最大的变化是——你的工作对象从“确定逻辑”变成了“不确定性”。举个例子。传统前端写一个表单校验规则是写死的输入不合规就报错。但Agent场景下同样一个“帮用户订机票”的任务用户可能说“明天下午去上海尽量便宜点”也可能说“帮我看看下周二有没有去杭州的高铁时间别太早”。模型怎么拆解意图、怎么决定先查航班还是先查高铁、怎么在信息不足时主动追问这些都不再是if/else能覆盖的。所以前端Leader转Agent第一关要过的不是某个框架API而是思维模型的切换从“穷举所有可能路径并兜底”变成“定义目标、约束边界、设计反馈闭环让模型在闭环里自己跑”。1.2 为什么前端Leader反而有优势聊到转行很多前端会自卑觉得后端搞AI更顺。但我自己的体会是前端Leader有几个隐藏优势被严重低估了对交互反馈的敏感度极高。Agent不是孤立的模型它要嵌入产品、面对用户。一个Agent回答得好不好、要不要展示思考过程、多轮对话中怎么纠偏这些都是交互设计问题。对“状态管理”的理解天然顺滑。Agent运行本质是状态机等待输入、规划任务、调用工具、获取结果、修正计划、输出答案。Redux、Zustand玩得溜的人理解Agent的State、Checkpoint、Memory会快很多。工程化意识强。前端Leader常年面对构建、部署、灰度、监控这些经验在Agent上线时同样适用——Prompt版本管理、Agent链路可观测性、异常降级跟前端发布管控逻辑相通。我一直觉得前端人到Agent领域不是“从零开始”更像是带着一套成熟工程方法论去适配一个新的运行时环境。想明白这一点学习重心自然就清晰了。1.3 我给自己定下的三条学习纪律68天走下来我觉得最有用的不是具体技术而是三条纪律第一每天至少写两个“今天实际跑通的场景”。光看不练记不住光练不记等于白练。我会把当天验证过的Agent行为、参数影响、踩坑点都记录下来这是后面写复盘笔记的第一手材料。第二每周找一个前端真实问题用Agent方式重新做一遍。比如表单自动生成、接口文档转Mock、代码评审辅助。这样做的好处是能把新知识和旧经验焊在一起不会学着学着就飘了。第三强制自己输出。无论是一个小Demo还是一个踩坑记录写出来才算真懂。这也是我坚持记录到第68天的原因。2. 从架构视角重新理解AI Agent前端Leader最有优势的观察角度学Agent学到第四五十天的时候我开始不满足于“能跑通示例”这个层面的理解转而开始研究主流架构。因为作为Leader我惯性地会问这个东西如果放到线上流量来了扛得住吗如果多个任务同时跑系统会不会乱坏了怎么降级这些问题直接对应到热搜里那几个高频词ai agent 主流架构、ai agent 怎么扛并发、基于rust语言ai agent。2.1 先看一套可落地的主流架构长什么样现在比较主流的Agent架构一般包含这么几层入口/会话层负责接收用户输入管理多轮对话上下文。跟前端的Router Store有点像。规划/编排层这是Agent的大脑决定“接下来调用哪个工具、按什么顺序执行”。在LangGraph里对应Graph State和Node在扣子这类平台里叫Workflow。工具层封装具体能力比如搜索、查数据库、调第三方API。每个工具本质就是一个带“描述入参结构”的函数。记忆层管理短期会话记忆和长期持久化记忆。这里跟前端LocalStorage/IndexedDB的定位类似只是粒度细得多。执行/沙箱层跑代码、出结果有些场景还需要隔离环境防污染。我画过一张简化结构图给自己看大家自己在纸上画也行用户消息进来 → 会话层把上下文组装好 → 规划层决定动作 → 工具层执行 → 结果回到规划层 → 决定继续还是结束 → 最终回复用户。整体就是一个大循环每一轮都是“感知-决策-行动-观察”。前端Leader看这套东西会很亲切本质上跟SPA应用里“事件-状态-副作用-渲染”的循环没有本质区别只是粒度更粗、每一步中加入了模型推理。2.2 “Agent怎么扛并发”这个问题要拆开看这个热搜词很有意思说明大家已经过了“做个Demo玩玩”的阶段开始认真考虑生产环境了。Agent并发和普通Web并发最大的区别是普通接口是短平快Agent链路可能要走好几轮模型调用单次耗时几十秒都正常。我在一个测试场景里实际压过50个并发用户同时发起Agent任务每个任务平均需要调用4次模型接口、2次外部搜索、1次代码执行。如果完全不加控制模型API的配额会瞬间被打爆工具层可能收到大量重复请求数据库连接池也会被拖垮。现在主流的解法大概有这几招请求排队 限流把Agent请求放入队列由Worker按最大并发数去消费。相当于把“我立刻要结果”变成“我按节奏处理”。流式输出不等整个Agent跑完再输出而是“边想边说”用户侧先看到思考中/执行中的状态减少等待焦虑。任务快照与恢复Agent执行中如果挂了能从最近一个检查点恢复不用整个重跑。这跟前端断点续传的思路如出一辙。缓存与复用相同或相似的问题直接复用之前的推理结果或工具返回结果省掉重复计算。前端背景在这块特别容易迁移前端做性能优化时常用的“请求合并”“CDN缓存”“骨架屏”跟Agent场景下的“任务合并”“结果缓存”“流式占位反馈”几乎是同一套思维的重命名。2.3 基于Rust语言做Agent性能焦虑下的另一种选择热搜里“基于rust语言ai agent”这个词让我留意了很久。因为Node.js/Python是Agent开发的主流语言Rust突然出现在这里说明有人开始在性能上较真了。我用个人经验解释一下为什么Rust会被盯上Agent的运行链路里有一部分是纯逻辑编排不涉及模型推理但这部分代码在并发高时同样会吃CPU和内存。例如多个Graph实例同时跑、大量工具调用调度、状态快照频繁序列化——这些场景下Python的GIL和Node的单线程事件循环都会有瓶颈。Rust的优势在于内存安全性强、并发模型干净、编译后部署轻量。我见过的典型做法是用Rust写工具执行层或编排调度层把Python/Node专注在业务逻辑和Prompt管理上。不过作为长期写前端的人我不建议一上来就学Rust重写一切。大多数团队的实际瓶颈在模型API和外部服务而不是编排层那点性能。除非你做的Agent是高频、低延迟、资源敏感型场景否则先跑通业务比追求极致性能重要得多。3. Agent与前端技术的交叉地带能立刻落地的结合点这是我最想写的一部分。因为很多前端同行的问题是我知道Agent很火但跟我有什么关系其实关系大得很。下面这几个方向都是我这段时间实际碰过的交叉点。3.1 前端SDKAgent能力嵌入业务App的必经之路Agent最终要服务用户而用户大部分时候是通过前端界面访问的。现在市面上已经有不少Agent能力的接入方式但很多都做成了“嵌入一段聊天框”的形态。实际业务里你要的不是一个通用聊天框而是能把Agent能力融进现有表单、流程、看板里的体验。这就引申出一个很重要的前端职责Agent交互前端化。举个实际场景我们有个后台需要快速筛选异常订单。传统做法是用户手动填一堆筛选条件现在我们可以把筛选条件转成自然语言比如“找出昨天支付成功但今天还没发货的订单”前端拿到用户文本后交给Agent解析成结构化查询条件再渲染成可编辑的筛选表单让用户确认后执行。这个落地过程中前端的核心工作包括封装一个统一的Agent调用SDK、管理请求中的loading/错误/取消状态、处理流式输出的逐段渲染、设计“Agent建议 vs 用户确认”的交互模式。3.2 阿里开源的前端会话控件这类方案解决的是“最后一公里”热搜里“阿里开源的ai会话前端控件”说明头部团队已经在做组件化尝试了。这类控件的价值在于把“对话气泡”“流式打字”“Markdown渲染”“代码块高亮”“引用来源展示”这些高频UI都封装好了开发者不用从头造。我自己的实操经验是这类控件拿来做Demo很快但接入实际业务时一定会遇到定制化需求。比如对话消息里要嵌入内部系统链接、要支持附件上传预览、要在特定节点插入一个业务表单。所以学习方法是——先看这类控件的内部实现理解它怎么组织消息流、怎么处理渲染性能然后基于它做二次封装而不是直接裸用。顺便说一句Agent对话和普通IM聊天有个关键区别Agent消息里经常包含结构化中间产物比如思考过程、工具调用记录、置信度评分这些信息要不要展示给用户、怎么展示需要前端做很多设计。这属于纯前端发挥空间很大的地方。3.3 前端组件库的新形态从“UI组件”到“能力组件”前端组件库过去解决的是视觉交互复用比如表格、弹窗、日期选择器。但在Agent时代会出现一种新形态把一整块Agent能力打包成可复用组件。举个例子我们内部做了一个“报表解读Agent”输入一份报表JSON它能自动生成文字分析、标注异常指标、给出建议动作。这个Agent能力被封装成一个React组件调用方只需要给数据、定样式、监听事件完全不需要关心Agent内部怎么跑。这就是我一直跟团队强调的以后前端组件库的维护者可能不只是懂UI还得懂Agent编排。前端Leader如果现在开始储备Agent知识在这个趋势下是有先发优势的。3.4 直播前端H5和Worker上传两个具体场景里的Agent影子热搜里“直播的前端h5怎么做”和“前端使用worker上传大文件”乍看跟Agent没关系但我在实践中发现它们都能和Agent产生交集。直播H5场景我实际做过一个需求直播间弹幕满天飞运营想知道用户到底在讨论什么。传统做法是人力运营去看弹幕现在我们接了一个“弹幕实时分析Agent”前端通过WebSocket把弹幕流送给Agent服务Agent定期返回热点话题摘要和情感倾向。这里前端要处理的核心问题是流式数据的缓冲、断线重连、消息时序以及Agent结果延迟情况下如何优雅展示。这些体验设计前端责无旁贷。Worker上传大文件则是另一个思路。前端用Worker处理文件切片和上传本质是在浏览器里做并行计算和任务调度。Agent场景类似的痛点是需要在前端做大量文档预处理比如从PDF里抽文本、切分大文档、做格式转换如果这些全在主线程跑页面会直接卡死。把人家的Web Worker、OffscreenCanvas、IndexedDB这批手艺平移过来解决的就是Agent前端的吞吐问题。4. 安全与工程化被低估的前端基本功在Agent时代的复利效应转型学Agent的人容易一头扎进模型、提示词、工作流把老本行给丢了。但热搜里“关于前端的一些安全技术操作”“防止爬虫”“防止查看页面源码”这些词提醒我安全这个东西在任何时代都是前端的分内事Agent时代只会更复杂。4.1 Agent前端的安全问题比想的要多一个维度传统前端安全主要防三类XSS脚本注入、CSRF跨站请求伪造、敏感信息泄露。Agent前端在此基础上多了一个维度防止用户滥用Agent能力来制造恶意内容。举例来说如果业务里有一个“AI辅助生成产品文案”的功能攻击者可能通过故意构造输入让Agent绕过规则生成包含违规词的文案或者诱导Agent输出内部Prompt。前端在这里能做的事包括对用户输入做敏感预检、限制单次输入长度、对Agent输出做二次内容安全过滤后再渲染。这跟前端做XSS过滤的思路很像但范围更广不仅要防止脚本执行还要防止内容层面越界。我们的实践是建立两层过滤入站时用约束模版清理用户输入出站时用规则分类器加上模型自评来做内容校验。4.2 防止爬虫和防止查看源码在Agent时代又有了新解读以前我们做“防止爬虫”主要是防接口被批量抓。现在Agent时代有一种新的“爬虫”——AI搜索引擎会派爬虫来抓取页面内容做语料训练。这带来的新问题是你辛辛苦苦生产的内容可能成了别人模型的训练数据。目前业界有几种应对思路包括在robots协议里声明禁止AI爬虫抓取、在关键内容区用动态渲染代替静态输出、对接口数据做签名校验。这些措施的前端侧实现仍然离不开我们熟悉的JS混淆、请求指纹、验证码等老手艺。“防止查看页面源码”这件事在Agent时代也出现了新变体防止别人通过“查看源码”来扒走你的Agent编排逻辑。虽然Agent逻辑主要在服务端但前端SDK里可能会暴露一些工具名、参数结构、内部接口路径。我们这边能做的是对SDK做代码压缩混淆、把敏感配置放到服务端下发、前端不硬编码任何密钥。4.3 前端工程化经验迁移到Agent项目的真实心得带前端团队的时候我花了很多精力梳理构建、发布、监控流程。做Agent项目之后发现这些经验几乎可以直线搬迁。首先是版本管理。热搜里“通过版本号的变更让前端强制刷新页面”本质是解决“用户缓存了旧代码导致功能异常”的痛点。Agent服务也有类似问题模型版本升级、Prompt结构调整都会导致行为漂移。我们现在的做法是给Agent服务增加版本号字段前端调用时把版本号带过去后端根据版本号切换不同的Prompt模板和模型配置。一旦发现新版本行为异常可以秒级回退到旧版本。其次是可观测性。前端有Sentry这类错误监控Agent不能只靠日志。我们为每一次Agent运行生成一个Trace ID从前端发起请求开始到Agent规划、工具调用、模型返回、最终回复全程记录。排查问题时用户描述一句“刚才回答得不对”我们直接拿Trace ID去查比对规划和实际执行链路。再者是性能兜底。Agent返回慢是常态前端一定要做“超时降级”。我们在前端SDK里设计了两层超时第一层是等待“开始输出”的超时默认8秒内没开始流式输出就提示用户稍后再试第二层是整体完成超时默认40秒超出后给出兜底结果比如“这个问题比较复杂建议换个问法”。这套逻辑跟做接口超时重试本质上没有区别只是阈值需要重新调。5. 面试视角的观察2026年AI Agent相关前端岗位真正看重什么热搜词里“前端面试题2026”“2026前端面试题”“京东前端外包面试”扎堆出现说明这个行业即便在Agent热浪之下前端求职者心里还是慌。我作为面过不少人的Leader顺便聊聊这段时间对市场风向的观察。5.1 面试题在变从“会背API”到“会拆业务”2024年之前的前端面试问得比较多的还是“数组去重有几种写法”“Vue响应式原理”“浏览器缓存策略”。但2026年的面试风向已经明显偏移了。我最近筛前端候选人时已经不太爱问纯API题更关注有没有接触过流式数据渲染如果让你渲染一个持续输出的AI对话流你怎么控性能如果后端接口不稳定时快时慢甚至偶尔超时作为前端你怎么做体验兜底给你一个“AI生成表格”的需求你从交互设计到接口设计怎么拆解可以明显感觉到面试官在考察的不再是“知识储备量”而是“在不确定性的环境里能不能把体验做好”。这恰恰是Agent时代前端最需要的素质。5.2 外包面试的视角门槛分化在加剧“京东前端外包面试”这类词出现频率高说明外包市场依然是很多人的入口。我自己对外包岗的建议是基础前端能力是敲门砖Agent是加分项。但要注意包活重心往往在业务实现不会给你太多Agent从零探索的空间。所以在外包岗积累的是“工程密度”不是“创新深度”。如果你想真正转AI Agent更建议找两类机会一是已经落地Agent功能的产品团队哪怕做的只是一个对话入口也能接触线上真实链路二是数据中台或AI平台团队面向内部业务方提供Agent能力这类岗位前端能接触到的架构面更宽。5.3 结合“ai agent学习路线”词条给在职前端一份务实路线搜索词里“ai agent学习路线”是高频词。按我这68天的经验给在职前端画一条不太劝退的路线第一阶段第1-15天先搞清楚概念。学会用一个已经封装好的Agent平台比如扣子这类无代码先搭两三个能跑通的小应用培养“拆任务-接工具-看结果”的感觉。第二阶段第16-35天选一个主流的Agent开发框架按官方教程把聊天机器人、检索问答、工具调用三个经典案例实现一遍。重点理解State、Node、Edge、Tool这组核心概念。第三阶段第36-55天把Agent跟前端结合。至少做一个“React/Vue Agent后端”的完整Demo刻意练习流式输出、会话管理、错误兜底。第四阶段第56天以后选一个真实业务场景深度啃。我个人推荐“报表解读”或“文档问答”这类场景既能把Agent能力体现出来又不需要特别复杂的领域知识适合快速做出成果。这套路线的好处是每一步都不会让你觉得离前端太远每一步产出的东西都能拿给团队或面试官看。6. DAY68的自我复盘几个值得敲黑板的教训最后回到这一天的复盘。第68天我踩过的坑、修正过的认知挑几个最值得说的记录在这里希望后来者少走点弯路。第一个教训是别迷信“一个Agent搞定所有事”。我早期特别执着于做一个万能的个人助理Agent把这个功能那个能力全塞进去结果就是链路太长、调试极难、效果稀碎。后来学乖了一个Agent只解决一类任务把工具范围收窄目标写清楚效果立刻提升了。这跟前端治理巨型组件是一个道理——组件职责越单一越好维护。第二个教训是Prompt不是写出来的是试出来的。以前当Leader写需求文档会本能有“一次写完美”的倾向。但Prompt工程完全是另一套逻辑同一个目标语气词换一下、示例加一条、输出结构微调效果可能天差地别。一定要有实验心态建立自己的Prompt测试集每次改Prompt都跑同一组用例看效果变化。第三个教训是前端岗位做Agent项目要多往前“伸一只手”。不要只等着后端把接口给你因为Agent的接口形态经常变。最好的方式是前端参与Agent的编排设计讨论理解“为什么要这样规划工具顺序”“哪些信息可以让前端做临时缓存”。一旦前端理解了Agent链路设计出来的交互会比纯等接口好一个量级。第四个教训是保存好每一个能跑通的例子。Agent开发里环境变化、模型升级都可能让之前好用的代码失效。我每跑通一个场景除了记录结论还会附上“当时的输入示例”“模型配置”“Prompt版本”。这跟前端做兼容性回归测试是一个逻辑只是对象从浏览器换成了模型。第68天我依然不觉得自己已经“会了”AI Agent。但至少我已经知道该往哪里使劲该拿什么姿势去理解它以及我过去那些看似与AI无关的前端积累在什么场景下能变成新的生产力。下一步的计划是把已经跑通的“报表解读Agent”往工程化方向再推进一步加上更细的可观测性指标把Prompt版本管理接入现有CI流程再试着把多Agent协作跑通一个真实用例。这些都是后面Day70、Day80的素材。前端朋友们别焦虑路是一步一步踩出来的第1天和68天的差别比你想象中大得多。