1. 第68天站在哪个位置这不是从零开始是从“会做页面”到“会做大脑”说实话到今天DAY68我对“前端转AI Agent”这件事的理解跟最开始完全不一样了。刚开始我以为又是新一轮“学框架——写Demo——背面试题”的循环实际走下来才发现这次挑战的不是语法和API而是思维方式。作为前端Leader我每天要处理团队排期、需求评审、跨部门沟通真正能留给新方向的时间每天大概两个小时。68天前我连Agent的Tool是什么都说不清现在至少能独立搭建一个基于大模型API的简单Agent并把它接到内部系统里当工具用。想清楚“为什么转”特别重要。我做前端八年从jQuery时代一路走到Vue 3、微前端、组件库建设技术积累不算差但越来越明显的感觉是前端工程化已经高度成熟纯前端的增量空间在被AI工具压缩。不只是我团队里的小朋友用Copilot写页面效率翻倍传统的“切图——联调——提测”流程正在变薄。与其焦虑被替代不如主动走到生产工具的上游。AI Agent恰好站在“理解需求、调用工具、执行流程”这个位置跟前端天然有交集——前端的价值正在从“实现界面”上移为“定义交互与工具链”。DAY68这个节点很适合做一次完整的复盘。这篇文章不是一个教程更像是一个真实的过程记录我踩过哪些坑哪些前端经验能直接复用哪些必须推倒重来以及一个Leader如何在有限时间里完成方向切换。如果你也是前端背景、也在犹豫要不要往Agent方向靠这篇应该能给你一份不是鸡汤、也不是广告的参考。2. 前端Leader转Agent真正能带走的不是代码而是抽象和分层的能力2.1 组件化思维和Tool/Function Calling是一个东西前端人最值钱的能力是什么我认为是组件化之后的抽象能力。你会把一个页面拆成按钮、弹窗、表单再往上抽成业务组件、布局组件、容器组件。这种“把复杂拆小、把边界划清、把接口定稳”的习惯跟AI Agent里的Tool设计完全同构。我第一次接触Agent时以为要学一套全新的工程范式后面在写Tool定义时突然反应过来一个Tool就是“一个拥有清晰入参和出参的功能单元”跟封装一个组件没有本质区别。你在前端封装一个Upload组件要考虑props、事件、slot在Agent里设计一个Tool要考虑name、description、parameters和副作用。前端的props要写default、validatorAgent的参数要写type、enum、required。连出错信息都要写得让“调用方”能看懂——前端是让人看懂Agent是让模型看懂。我把自己团队内部的组件库规范直接迁移过来规定每个Tool的description不得超过50字参数必须给examples能拆小就拆小。结果呢Gpt的function calling准确率明显提升。这是我第一个强烈的感受前端的组件素养放在Agent开发里不是废技能是稀缺技能。2.2 微前端的“分而治之”可以拿来理解Agent的多智能体协作第二个让我觉得前端经验值钱的地方是遇到多Agent协作时满脑子都是微前端的影子。前两年团队做qiankun改造把巨石应用拆成主应用和子应用主应用负责注册、加载、通信子应用各自独立开发部署。这个架构心智几乎可以一比一映射到Agent的多智能体设计上。我当时照着微前端的思路画了一遍主Agent就是那个负责规划和决策的Planner相当于主应用负责接收用户意图、拆解任务、调用其他子Agent每个子Agent相当于独立子应用只干一件专业的事。它们之间通过某种协议通信——微前端靠CustomEvent、props、全局状态Agent之间则靠结构化消息和大模型生成的指令。注册子应用要配置name和activeRuleAgent里注册子智能体要给name、description让主Agent知道“什么情况该找谁”。这样一想多Agent编排对我就不再陌生了。甚至团队里的前端新人用这套类比去理解LangGraph里的节点和边也会很顺。2.3 前端“适配层”经验变成了Agent的集成层能力前端还有一个被低估的技术适配层。做过H5适配、多端适配、小程序跨端的人都知道一套逻辑要跑到不同宿主环境就要在中间加一层Translate/Adapter。Agent开发里这叫“集成层”本质上是一回事你要把大模型的能力接到企业微信、Slack、内部系统、数据库、甚至老的jQuery页面里不让模型直接面对异构系统。举一个例子。我们内部有一个用Django写的订单查询接口返回字段是order_id、customer_name、status_code。前端同事接这个接口时要做一次映射把status_code转成“已支付/待发货/已关闭”。我把Agent接到同一套系统时处理逻辑完全一致写一个Tool把模型的请求参数翻译成系统的查询条件再把系统的返回结果翻译成模型容易理解的文本。模型不需要知道数据库字段就像H5页面不需要知道iOS和Android的差异。所以如果你现在是一个前端别觉得自己要从零开始学AI Agent。你的组件抽象能力、微前端架构思维、适配层经验都是Agent工程化的核心能力。你缺的不是“会不会”而是“怎么把已有的东西翻译过去”。3. 从0到能跑通的Agent我的搭建路线与选型记录3.1 最初的四周把大模型当API调用先不做Agent很多前端朋友一上来就问我“该学LangChain还是LangGraph”我觉得太早了。第一周我的任务就是忘掉框架把大模型当接口调。我用Python写了一个最基础的脚本读用户输入拼一个Prompt调用API打印返回。这就像前端入行时先写一个原生HTML页面而不是直接上Vue CLI。当时我给自己定的目标是先搞明白三件事Token是怎么算的、System Prompt和User Prompt的区别、为什么同一个问题多问几次结果不一样。这些都是非常基础的问题但对前端背景的人来说是全新的。不理解Token可能出现的后果是你设计了一个超大上下文的应用结果每轮对话成本翻了十几倍用户点一次按钮消耗几毛钱。我在第二周做了一个很小的东西把团队日常的“代码评审意见总结”接上大模型输入一段Diff输出结构化意见。不涉及Agent只是一个简单的大模型应用。但这一步帮我建立了“模型擅长什么、不擅长什么”的直觉。比如它Summarize很强但让它精确数出文件里有多少个判断分支就会翻车。这种直觉后面设计Agent的Tool边界时特别有用。3.2 四周后开始碰框架为什么我选LangGraph而不是LangChain等基础概念清楚了我进入了框架学习阶段。现在的Agent主流架构一般是四条线单Agent直接调用、ReAct模式、多Agent协作、工作流编排。LangChain把很多组件串起来做成“链”对新人友好但实际生产里链路一复杂状态管理就乱了。LangGraph则把整个流程建模为图节点是执行单元边是流转条件像一个可以随时回溯的工作流状态机。对前端人来说LangGraph的图结构和useReducer或者状态机XState很相似。每个节点就是一个Reducer负责把上一轮状态变成下一轮状态边上的条件判断就是状态转移条件。我花了五天理解这个概念之后回过来再看LangChain的链式调用就很清楚它的局限了。我不建议你从LangChain开始学直接看LangGraph的官方例子加上状态管理。你要记住Agent的本质不是“让模型自由发挥”而是“把模型的输出嵌入到一个可控的工程流程里”。图结构天然适合这种控制。3.3 自己动手写一个最小Agent从工具定义到主循环我强烈建议每个前端转Agent的人不要直接用框架的AgentExecutor先手写一个迷你版本的Agent主循环大概几十行代码就能彻底理解所谓“Agent”到底是怎么跑起来的。当时我参考了ReAct的简化版思路流程大概是系统先给模型一段指令和若干个Tool定义模型根据用户输入决定调用哪个Tool然后代码执行该Tool把结果作为Observation反馈给模型模型再根据Observation生成最终回答或继续下一个Tool调用。这个循环听起来简单但其中任何一个环节理解不透彻后面调试会非常痛苦。我的第一个自写循环大概长这样def run_agent(user_input): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ] # 初次请求让模型决定是否调用工具 response call_model(messages, toolsTOOL_DEFINITIONS) # 若模型返回tool_calls则执行工具把结果放回去 while response.tool_calls: messages.append(response.message) for call in response.tool_calls: result execute_tool(call.name, call.arguments) messages.append({ role: tool, tool_call_id: call.id, content: result }) response call_model(messages, toolsTOOL_DEFINITIONS) return response这个循环跑通了你就知道LangGraph在替你做哪部分工作、哪些边界条件需要自己兜底。比如要不要限制循环次数、工具调用超时怎么办、模型连续调用同一个Tool怎么防止死循环。这些经验是直接上框架学不到的。3.4 Token引发的焦虑前端人最容易忽视的成本问题我前面提到Token这里必须单独拿出来讲。因为前端开发习惯性地把成本问题甩给后端但Agent应用的Token成本直接影响产品形态。我第一个Agent工具没做任何控制用户输入一个长文档再调用一次工具一次请求就把上下文撑到几万Token。按当时的API价格一个用户一天用几次一个月的成本就够请一个人吃顿饭了。后来我养成了三个习惯第一能塞进Tool返回结果的绝不塞原文尽量用摘要或关键字段第二给Agent的System Prompt里明确“不要一次性读全部内容必要时按需分段获取”第三给Tool的输出加一个上限比如“只返回前十行结果”。这些做法不高级但在真实场景里比什么花哨技巧都省成本。前端人还有一个直觉要改掉——不要把你习惯的“所有状态都存在前端内存里”迁移到Agent里。大模型的上下文窗口就是你的“内存”但它是按Token计费的。你如果什么都往里塞等于是让后端为一个永远不清空的全局变量买单。4. 每天挤2小时的学习方法Leader身份反而成为了优势4.1 碎片时间的分配策略60分钟输入60分钟输出做Leader的人有个天然劣势时间非常碎。我要参加各种会随时处理团队问题根本不可能像刚毕业时一样连续学习四小时。我的方案是把自己的时间切成了“6060”每天保证60分钟阅读和看源码主要用于理解概念和技术选型另外60分钟是纯粹的输出——写代码、写笔记、写文章、或者给团队做内部技术分享。这60分钟输出非常重要。我的经验是只看不写等于白学。Agent相关的概念特别容易产生“我懂了”的错觉实际上让你讲一遍或者写一段代码就露馅。我坚持每天在笔记里用“自己的话”解释当天学的一个概念比如“Tool Calling就是模型回答中的一种特殊格式告诉你它想调用什么函数由你的代码真正执行”。Leader这个身份反而在这里帮了我。因为Leader每天要跟很多人解释“我们要做什么、为什么这么做”你的表达能力和逻辑组织能力是训练过的。我发现自己学Agent的速度比刚工作时学后端要快很大程度上是因为输出习惯已经成熟了——我学一个新东西天然会去想“怎么把这件事讲给别人听”。4.2 用团队项目倒逼个人学习跨界实战比空学快得多学习最怕自嗨。我前几周学得很快但到第四周开始陷入“什么都会一点、什么都不精”的状态学的概念到下周就忘了。后来我改变策略不再为自己学而是为团队某个真实痛点学。当时团队刚好遇到一个问题运营同学每天要花一个多小时整理竞品公众号的文章摘要。我主动揽下来说可以做一个小工具。这个工具本质上就是抓取文章、切分文本、调用大模型生成摘要、按模板输出文档。听起来不复杂但涉及爬虫的合规性判断、文本切片策略、调用频率控制、格式统一、失败重试每一个都是真实的工程问题。这一个小项目让我一周内搞懂了文本切片的两种方式按字符硬切和按语义切分、摘要Prompt的迭代方法、以及任务失败时的重试策略。比看十篇教程有用。关键是它直接服务了团队不是我自己“学着玩”的玩具Demo。我强烈建议正在转方向的人必须找一个哪怕很小很小的真实需求把学的东西用出去。4.3 记笔记的正确姿势不抄概念只记决策和教训我见过很多人学AI Agent笔记做得密密麻麻全是概念定义但真正实操时还是不会。我的笔记体系跟别人不太一样大概分四栏今天解决了什么问题、用了什么方案、为什么是这个方案、下次遇到什么情况绝不能怎样做。举个例子。我第五周调试一个Agent死活无法正确调用某个工具最后发现是Tool描述里写了“如果用户在提问时提到订单就调用这个工具”而模型在不确定时不会轻易触发调用。我在笔记里记下Tool的触发条件描述要越“机械”越好不要给模型发挥空间类似于前端里不要给用户加不必要的选择而是把默认路径走通。这种决策记录才是真的知识沉淀。DAY68回头看我的笔记已经有将近两百条这种决策记录。它们不是对某个框架的说明书而是我对“AI Agent怎么做才能落地”的个人经验库。这些东西未来即使换了框架、换了模型仍然有效。5. 踩坑实录Agent开发的三个大坑每个都能让你白干一周5.1 环境依赖的隐蔽性Python版本、包冲突和模型版本第一个坑出乎意料地基础但越基础越容易让人心态崩溃。前端开发时的环境问题顶多是Node版本不对、依赖装不上Python的依赖冲突可能让你一条Demo代码跑出各种莫名其妙的错误。我当时为了跑一个开源的Agent项目按README装了依赖结果Python版本是3.9项目要求3.11。原以为只是小问题装了3.11后才发现某个底层库对3.11还有隐藏bug需要锁版本才能跑。这种问题排查起来非常耗时而且答案往往分散在GitHub Issues的不同楼层里。我的建议是任何Agent项目第一步先把虚拟环境打好严格按项目要求的Python版本建环境。第二步别一上来就装最新版本的框架直接看项目使用的版本锁文件。做前端习惯了npm/lockfile锁定依赖的人在Python里也要有同样的意识。这类环境问题看起来低级但实际消耗的时间远超学一个新概念。5.2 上下文污染模型自己都被自己绕晕了第二个坑是Agent在连续对话后开始胡说八道。我一开始以为模型变笨了排查了一圈才发现“记忆”并不等于把历史记录全部塞进上下文。在一次测试中用户先问了一堆无关问题Agent把这些闲聊都存进了历史后面用户问正经问题时模型反而开始混淆甚至把Tool返回的错误信息当成正确答案输出。这是典型的上下文污染。后来我做了两个改造一是给对话历史设置窗口超过一定轮数只保留摘要二是让每个用户会话在进入Agent主流程前先做一次意图判断与当前任务无关的历史全部折叠成一行摘要。这两个改造上线后准确率稳定很多。这也让我意识到Agent背后的逻辑更像一个前端路由你要清楚每一条消息走到了哪个页面状态不用的中间状态不要一直堆在内存里。上下文窗口就是内存该释放时就释放。5.3 幻觉问题不能全部甩给模型工程手段能大幅缓解提起Agent大家最担心幻觉。我的感受是单靠Prompt去压制幻觉效果有限真正的解法得靠工程兜底加模型自检。我们做内部知识库问答时模型偶尔会给出看似专业但不太好判断的答案。后来我加了一个“引用机制”每一步召回知识时把相关来源ID带进上下文并要求模型在回答末尾标注引用ID。如果模型拿不出引用ID那基本可以判定这段内容有问题直接拦下。这在效果上是极好的收敛。前端人可以把这理解为用户操作了一个按钮但没有触发相应的事件那一定是你哪里写错了不能只靠用户自己判断。如果你准备转Agent我觉得要尽早建立“模型不可靠”的默认假设所有涉及事实、数字、状态的回答都必须通过外部工具或数据源兜底验证。模型的作用是组织和表达信息而不是生成信息。这个认知转变是前端开发习惯里最大的突破点。6. 下一步路线从Demo到可用的生产级Agent还差这几关6.1 我用“前端架构评审”的方式反推Agent的落地标准前端做多了我对“Demo能跑”和“功能上线”的区别特别敏感。转Agent也一样很多框架演示跑得很顺但真正落地要考虑的维度完全不同。我给自己列了一个落地清单全部参照前端架构评审的思路身份权限谁可以调用这个Agent数据权限怎么隔离超时与熔断模型响应慢怎么办工具调用失败重试几次可观测性每一步Agent决策有没有日志和追踪怎么排查问题成本控制单次请求的Token上限是多少超出后的降级方案是什么结果校验模型输出是否符合预期有没有自动校验规则前端做复杂系统时这些是非功能需求Agent项目里它们同样一个都不能少。我最近在写一个“内部排期助手”它能根据成员当前任务和历史速度给出排期建议。但这个工具如果直接上线一旦给出错误排期团队就要买单。所以我在Agent的Tool里加上“读取数据前先校验权限”和“所有建议必须附带依据来源”跟当年给前端组件写单元测试和边界条件的思路一模一样。6.2 从“让小红书自动发消息”这类需求里看到Agent的真实机会有阵子热搜词里一直有“让小红书自动发消息”类似的需求很多人以为Agent就是搞这类自动化。但以我的经验看这种把个人工具当突破口的项目很难成为你真正的核心竞争力。它的核心难点是解析平台规则、绕过风控跟Agent本身关系不大。真正的机会在B端长链路流程里。比如内容团队的需求是把一段产品信息自动生成五条不同平台风格的文案运营团队的需求是把一篇长文自动拆成日报、摘要、朋友圈三条内容销售团队的需求是根据客户对话记录生成跟进摘要和下一步动作。这些任务不是一句话能完成的而是需要多个工具配合查知识库、调模板、改语气、审核内容。前端背景的人去做这类Agent优势在于你懂业务界面、懂人怎么使用系统知道在哪一步输出什么格式用户才容易介入和纠偏。6.3 未来三十天我的主攻方向Graph状态机工程化、评估集和前端Agent接下来一个月我给自己定了三个具体方向第一把LangGraph的状态管理吃透写出一个带超时、重试、回滚的多节点Agent第二建立自己的评估集把团队里常见的高频问题整理成二十条用例每次改Prompt或Tool都跑一遍回归防止“修了这个问题、搞坏那个功能”这跟前端做回归测试是一个道理第三尝试把一个Agent跑成前端可用的SDK形态让团队的React项目能直接调毕竟这才是我的老本行也是前端人转Agent最自然的落地位置。我希望三十天后回来复盘时能拿出一整套可复用的Agent开发模式而不是又一个“看起来能跑”的Demo。7. 写给我的前端同事们这件事越早开始越主动DAY68的真实感受是前端转Agent不是逃离前端而是把前端推到更核心的位置。你理解界面、理解用户、理解交互链路这些能力在Agent时代只会更值钱。你缺的只是补齐大模型、工具调用、状态编排这几块拼图。最后分享一个实操技巧。如果你和我一样还在职、时间不多我建议你每天记录“三个一”一个今天搞懂的概念、一个今天踩的坑、一个明天要试的想法。不追求多但一定要持续。68天下来你会发现自己早就不是当初那个只会写页面的前端了。
