今天是我從寫了十年業(yè)務(wù)代碼的前端正式轉(zhuǎn)向AI Agent方向的第70天。白天我是一名前端Leader晚上九點(diǎn)以后回到工位才切回另一個自己學(xué)Python、跑LangGraph、做RAG、搭A(yù)gent部署。70天不算長但足夠讓我打破兩件事一是對“前端已經(jīng)到頭”的焦慮二是對“AI Agent就是調(diào)大模型聊天”的錯誤判斷。很多同行問我前端轉(zhuǎn)AI Agent是不是等于轉(zhuǎn)后端正好借著第70天這個節(jié)點(diǎn)把這段時間踩過的坑、看過的架構(gòu)、總結(jié)出來的方法完整寫一遍。文章會比較長適合兩類人一類是還在猶豫要不要轉(zhuǎn)型的前端同事另一類是想在團(tuán)隊里稍微懂點(diǎn)Agent原理的Manager。我盡量不堆術(shù)語所有技術(shù)概念都用最直白的方式講。1. 為什么一個前端Leader會跳進(jìn)AI Agent這個坑1.1 我先承認(rèn)前端的天花板越來越明顯干了十年前端從PC端到移動端、從jQuery到Vue再到React說實(shí)話傳統(tǒng)前端工作里“純界面層”的重復(fù)度已經(jīng)非常高了?，F(xiàn)在很多前端項(xiàng)目一大半時間花在搭頁面、調(diào)組件、處理表單狀態(tài)、對齊設(shè)計稿和接口文檔上。這兩年更明顯組件庫越來越完善低代碼平臺越來越強(qiáng)AI直接生成代碼的能力也越來越嚇人。搜索里經(jīng)常能看到“ai agent 前端開發(fā)”、“codex 前端開發(fā)會使用的插件”、“前端開發(fā)skills”這類詞說明大家已經(jīng)默認(rèn)AI能接手很大一部分編碼工作。當(dāng)一個崗位的核心技能可以被工具替代時Leader必須考慮團(tuán)隊下一步往哪走個人的路該怎么拓寬這是最現(xiàn)實(shí)的驅(qū)動力。另一個是業(yè)務(wù)方視角。不管做B端還是C端業(yè)務(wù)方現(xiàn)在聊的已經(jīng)不是“做個表單頁面”而是“能不能讓系統(tǒng)自己完成一條完整的任務(wù)”。比如讓AI自動整理商品資料、自動生成營銷文案、自動跟進(jìn)客戶消息。這些需求本質(zhì)上不再是頁面功能而是Agent任務(wù)。業(yè)務(wù)方不管前端后端他們要的是“結(jié)果”。如果你只懂UI你沒辦法判斷這個需求能不能做、該怎么做、風(fēng)險在哪里。1.2 70天前我給自己定了一套笨但有效的節(jié)奏決定轉(zhuǎn)型之后我沒有立刻報課或者買一堆書而是按“輸出倒逼輸入”的方法給自己排了計劃。計劃的核心只有三條每天至少投入1.5小時每周產(chǎn)出一個可運(yùn)行的小項(xiàng)目每天記錄學(xué)習(xí)日志。標(biāo)題里的“DAY70”就是這么來的我用一個文檔天天記不追求文筆只追求把今天理解的東西寫明白。時間安排上白天工作不推晚上和周末全身心撲進(jìn)來。這段時間走完我的體感是第1-14天最痛苦因?yàn)槟惆l(fā)現(xiàn)自己跟一個剛畢業(yè)的新人一樣什么都不會第15-35天會進(jìn)入“能看懂但寫不出來”的瓶頸期第36-50天基本能照葫蘆畫瓢跑通一個簡單Agent第51-70天開始敢做工程化改造了至少能把自己的想法放進(jìn)Agent架構(gòu)里。很多人問“70天夠不夠”如果把目標(biāo)定成大廠算法研究員那70天只能是起點(diǎn)。但如果目標(biāo)是能獨(dú)立搭建一個符合業(yè)務(wù)場景的AI Agent應(yīng)用70天按我的節(jié)奏是可行的。這也是我這篇文章最想傳達(dá)的一個觀點(diǎn)轉(zhuǎn)型不是要把自己變成大模型專家而是把已有的工程能力遷移到新的技術(shù)棧上。2. 70天學(xué)習(xí)路線從零七級到真正做出Agent2.1 先補(bǔ)Python還是先學(xué)框架我的答案是同時進(jìn)行這是新手最容易糾結(jié)的問題。網(wǎng)上有人推薦先從Python語法慢慢學(xué)有人說直接用LangGraph邊做邊學(xué)。我的建議偏向后者但要配一點(diǎn)前置條件。我不建議完全零基礎(chǔ)的人直接看框架源碼那樣會吐。也不建議把Python學(xué)透再動手沒那個必要。前端轉(zhuǎn)Agent你需要的Python知識其實(shí)很聚焦基本語法、函數(shù)定義、異步async/await、類與對象、處理JSON、環(huán)境變量管理。這些東西大概兩周就能上手因?yàn)槲覀冇芯幊趟季S打底缺的只是語法習(xí)慣。等這三周過去再碰LangChain、LangGraph這類框架就舒服很多。我注意到現(xiàn)在也有人搜“基于rust語言ai agent”Rust做Agent是有潛力高性能、低資源、適合做運(yùn)行時底層但目前主流Agent生態(tài)和示例仍然集中在Python除非你是專門研究中間件的高P否則業(yè)務(wù)型Agent還是先吃Python紅利。說句經(jīng)驗(yàn)之談?wù)Z言切換最大的坑不在語言本身而在于心智模型。前端是“事件循環(huán)驅(qū)動的UI狀態(tài)機(jī)”Agent是“推理循環(huán)驅(qū)動的任務(wù)狀態(tài)機(jī)”看起來都像狀態(tài)機(jī)但本質(zhì)不同。前者所有分支都是確定性的后者每一步都可能帶隨機(jī)性。這一點(diǎn)想通了代碼反而是小事。2.2 Agent的五段核心循環(huán)理解它才能調(diào)試它從第25天開始我基本不看單個模型API的調(diào)用示例了開始逼自己理解一個Agent是怎么轉(zhuǎn)起來的。這里我把核心循環(huán)拆成五個階段這也是我看LangGraph文檔時最重要的抽象任務(wù)理解把用戶輸入轉(zhuǎn)成可執(zhí)行目標(biāo)拆出約束條件。規(guī)劃把目標(biāo)拆成子步驟判斷每一步需要什么工具。執(zhí)行調(diào)用工具或模型生成內(nèi)容得到觀察結(jié)果。記憶把結(jié)果存進(jìn)短期上下文或長期向量庫供后續(xù)決策。完成判斷對比目標(biāo)是否達(dá)成沒達(dá)成就回到規(guī)劃階段繼續(xù)循環(huán)達(dá)成就輸出。剛開始我寫Agent是這樣的while True: result model_call(history tools) if result.is_final_answer: break action parse_action(result) observation call_tool(action) history.append(observation)這段代碼很簡單但它能幫我把概念變成可運(yùn)行的東西。如果你也是前端出身可以把這想象成Redux的單向數(shù)據(jù)流dispatch一個action經(jīng)過reducer得到一個新state再觸發(fā)下一個action。Agent本質(zhì)上就是讓模型去決定下一個dispatch該是什么而工具調(diào)用就是執(zhí)行副作用函數(shù)。2.3 “AI Agent token”到底要懂到哪個程度搜索熱詞里出現(xiàn)的“ai agent token是什么意思”我猜很多前端同學(xué)都困惑過。我自己的理解是token是模型理解文本的粒度中文字符通常一個漢字約對應(yīng)1到1.5個token英文一個單詞約1到2個token。你可以把它理解成模型面前的一盤小棋子模型一次最多只能看這么多棋子。上下文窗口就是這副棋盤的大小。普通開源模型多在8K、32K商業(yè)API大模型比如Claude、GPT系列有128K甚至更多。聽起來很大但別高興太早工具描述、歷史對話、檢索回來的資料塊、系統(tǒng)提示詞都會吃掉這個空間。我算過一個實(shí)際例子如果每輪對話平均800字約1200個token開32K上下文的模型只能容納約26輪還要留出答復(fù)的空間。遇到工具返回長文本基本兩三次就把窗口干穿。真正做Agent時你要把token當(dāng)成預(yù)算來管理不是當(dāng)成容量來使用。什么時候截斷舊對話、什么時候把檢索結(jié)果做摘要后再放回上下文、什么時候用向量數(shù)據(jù)庫做召回而不是把所有文檔全塞進(jìn)來這些才是Agent工程師和“只會調(diào)用API”的人的分水嶺。3. 前端經(jīng)驗(yàn)不是沒用而是換了一種用法3.1 前端在Agent應(yīng)用里的3個落地位置很多前端同事覺得自己轉(zhuǎn)Agent意味著放棄前端實(shí)際情況恰恰相反。Agent產(chǎn)品同樣需要有界面而且這個界面比傳統(tǒng)網(wǎng)頁復(fù)雜得多。第一個位置是對話型交互界面。包括流式輸出、渲染富文本、Markdown、代碼高亮、消息卡片以及Agent思考過程的可視化。這個區(qū)域非常吃前端能力你需要在流式更新時保證UI狀態(tài)不亂在用戶發(fā)消息時快速鎖定輸入狀態(tài)同時渲染出工具調(diào)用時間線。我們用過的組件庫做傳統(tǒng)B端沒問題但放Agent場景就差一點(diǎn)我一般會針對思考過程單獨(dú)寫一個Timeline組件實(shí)時展示Step1、Step2和執(zhí)行結(jié)果。第二個位置是Agent配置后臺。給業(yè)務(wù)人員配置工具參數(shù)、配置角色提示、配置知識庫、配置測試用例。這類后臺需要大量腳手架和表單邏輯反而是前端最擅長的事情。如果團(tuán)隊在后端用SpringBoot搭建Agent服務(wù)前端用Vue做管理端中間協(xié)商好調(diào)度接口你會發(fā)現(xiàn)工作路徑順序是順的。第三個位置是數(shù)據(jù)觀測面板。Agent跑起來之后你需要觀測每一輪對話的關(guān)鍵信息模型名、上下文窗口使用率、工具調(diào)用結(jié)果、耗時、失敗率。這個面板本質(zhì)上就是運(yùn)維監(jiān)控的前端翻版。我甚至見過一個團(tuán)隊后端只把事件流推給前端前端自己算token消耗、自己畫趨勢圖協(xié)作很順。3.2 Agent的“前后端分離”比Web前后端分離更嚴(yán)格有個熱搜詞我一眼就注意到了“open webui 需要后端服務(wù) 您正在使用不受支持的方法(僅運(yùn)行前端服務(wù))。請通過后端”。這個報錯提示很典型說明很多從前端切入AI Agent的人會習(xí)慣性地認(rèn)為“我只要起一個純前端項(xiàng)目把前端代碼部署上去就行”。但AI應(yīng)用幾乎不可能做純前端。大模型API不能直接暴露在瀏覽器里會泄露密鑰消息流需要后端做持久連接用戶鑒權(quán)、會話存儲、工具調(diào)用代理都需要后端能力。所以真正合理的架構(gòu)是把前端只承擔(dān)展示和交互把所有與模型通信、工具執(zhí)行、知識檢索相關(guān)的邏輯全部放在后端。有意思的是搜索詞里還有“若依前后端分離前端代碼在哪里”和“hzero前端開發(fā)”這類傳統(tǒng)中后臺的框架方法論放到Agent項(xiàng)目里依然成立。后端負(fù)責(zé)域名、權(quán)限、數(shù)據(jù)安全前端負(fù)責(zé)體驗(yàn)、交互、渲染這個基本分工完全沒變。變的只是后端不再是簡單返回CRUD數(shù)據(jù)而是要調(diào)度一個會推理的Agent runtime。我甚至在團(tuán)隊內(nèi)部做過一次分享用一張表格給前端同事類比前端狀態(tài)管理與Agent狀態(tài)管理的關(guān)系傳統(tǒng)前端AI Agent系統(tǒng)用戶事件觸發(fā)action模型推理決定下一步動作Redux/Pinia管理全局狀態(tài)Memory/記憶模塊管理上下文請求后端接口拿數(shù)據(jù)調(diào)用工具獲取觀察結(jié)果路由守衛(wèi)控制頁面訪問完成條件判斷Agent何時終止3.3 工具調(diào)用完全可以當(dāng)成接口調(diào)試來對待我在第40天左右特別有體會Agent所謂“調(diào)用工具”和我們前端調(diào)后端接口沒有本質(zhì)區(qū)別。你定義一個工具名、描述、參數(shù)結(jié)構(gòu)模型根據(jù)用戶需求決定要不要調(diào)用調(diào)用時填參數(shù)后端執(zhí)行完返回結(jié)果。從工程視角看這就是一次接口調(diào)用只是參數(shù)不是前端填的而是模型生成的。這就帶來一個問題模型生成的參數(shù)經(jīng)常瞎寫可能多個字段、少個必填項(xiàng)、類型不對。傳統(tǒng)前端后端聯(lián)調(diào)還可以靠工具類型系統(tǒng)兜底Agent工具調(diào)用沒人在運(yùn)行前幫你檢查。所以我習(xí)慣在每個工具入口做一層Schema校驗(yàn)不合法直接拒絕并把錯誤信息返回給模型讓它重新生成參數(shù)。這樣一次迭代成功率能從六成提到九成。把工具當(dāng)成API來管理還有一個好處數(shù)據(jù)結(jié)構(gòu)穩(wěn)定復(fù)用性強(qiáng)。一張員工請假表、一個庫存查詢接口、一個內(nèi)容發(fā)布方法都可以變成Agent工具前端只要負(fù)責(zé)把結(jié)果渲染出來。我會把工具調(diào)用記錄同時發(fā)到前端相當(dāng)于給每一步操作留痕方便用戶反查。這個設(shè)計理念其實(shí)就是從我們熟知的接口Trace面板搬過來的。4. 70天里我踩過的坑按頻次排序整理4.1 無限循環(huán)和Agent跑飛不要指望模型自覺停止第一次用LangGraph搭一個多步驟Agent時我自信滿滿讓它自主規(guī)劃結(jié)果5分鐘過去了它一直在反復(fù)調(diào)用工具甚至偶爾自己給自己編造一個結(jié)果。當(dāng)時我第一反應(yīng)就是死循環(huán)了趕緊把日志拉出來看。排查下來問題主要有三個第一最終判斷條件太模糊。我沒有清楚告訴模型“當(dāng)信息足夠時立即終止”而是說“你認(rèn)為合適時停止”這對模型來說過于開放。第二工具調(diào)用結(jié)果里“狀態(tài)字段”不夠明確導(dǎo)致模型分不清到底成功沒有。第三缺少一個兜底節(jié)點(diǎn)循環(huán)次數(shù)超過N就直接終止回到人工復(fù)盤。我現(xiàn)在寫Agent一定有強(qiáng)制性約束最大循環(huán)次數(shù)設(shè)成8到15次每一步必須返回結(jié)構(gòu)化的中間結(jié)果關(guān)鍵分支再加一層規(guī)則判斷。前端里做個路由守衛(wèi)至少可以有效攔截?zé)o限跳轉(zhuǎn)Agent同理。4.2 上下文爆炸Token計算和截斷策略另一個高頻坑是長會話崩掉。前一天還正常聊的Agent第二天用戶連續(xù)發(fā)了一小時長消息突然開始胡言亂語。我最初以為是模型抽風(fēng)后來查日志才發(fā)現(xiàn)上下文窗口已經(jīng)逼近上限最前面的工具返回信息被擠掉了模型看不到早期約束。解決辦法是按長度窗口滑動并給歷史記錄做摘要。我的策略是這樣如果歷史消息超過總上下文的60%先把最早的服務(wù)端數(shù)據(jù)歸檔只保留一句摘要。比如用戶昨天問過的三個問題壓縮成“用戶昨天咨詢了A、B、C三件事均已解決正在處理D”再把今天的內(nèi)容完整保留。還要注意一個細(xì)節(jié)最關(guān)鍵的指令和最近一輪工具調(diào)用結(jié)果永遠(yuǎn)放在Prompt的優(yōu)先級高位。模型對越靠后的內(nèi)容權(quán)重越大把關(guān)鍵內(nèi)容放在越靠后效果越好。這個我實(shí)測下來比靠前制定指令更有效。4.3 工具調(diào)用參數(shù)不聽話改Schema比改Prompt快得多有一段時間我給Agent接了一個“查詢銷售訂單”的工具輸出結(jié)果一般是長文本。結(jié)果發(fā)現(xiàn)模型經(jīng)常不填必填的shopId或者把date格式傳成“昨天”。一開始我反復(fù)在提示詞里加“一定要傳shopId格式要正確”但效果不穩(wěn)定偶爾還是會翻車。后來我換了個思路工具參數(shù)定義改成JSON Schema并對shopId字段加description和枚舉示例date字段明確格式為YYYY-MM-DD。同時在后端做兜底校驗(yàn)參數(shù)不對就直接返回400讓模型自己看錯誤信息重試。改完之后成功率提升非常明顯。我現(xiàn)在跟同事強(qiáng)調(diào)最多的一句話就是后端定義好接口和錯誤碼Agent才能像人一樣學(xué)會怎么用工具。這個原則和前端調(diào)后端接口是完全一樣的不要指望調(diào)用方自覺要指望契約和校驗(yàn)來保障。4.4 Open WebUI“僅運(yùn)行前端服務(wù)”的報錯其實(shí)是前后端架構(gòu)問題很多剛接觸AI前端開發(fā)的同學(xué)會用Open WebUI這類項(xiàng)目做本地管理界面會看到一個明確的提醒您正在使用不受支持的方法僅運(yùn)行前端服務(wù)請通過后端。這里面有個很核心的工程概念A(yù)I應(yīng)用必須走后端來管理模型連接與密鑰不能直接把模型API地址暴露給瀏覽器。我自己也犯過這個錯。最開始圖省事在一個純前端項(xiàng)目里直接調(diào)用模型API打開頁面發(fā)現(xiàn)雖然能發(fā)消息但只要刷新頁面翻到歷史會話就失效而且密鑰直接暴露在請求里安全完全不過關(guān)。后來我把請求改走后端轉(zhuǎn)發(fā)才解決了持久化和安全問題。順帶一提前端安全技術(shù)也值得復(fù)用很多Agent管理后臺同樣需要防XSS、CSRF、防惡意爬取。搜索里的“前端網(wǎng)絡(luò)安全”“防止爬蟲防止查看頁面源碼”其實(shí)在Agent里同樣要關(guān)注尤其你做了一個AI工具別人可能直接抓你的API接口把能力白嫖走。5. 如果讓我重來給想轉(zhuǎn)AI Agent的人一點(diǎn)心得5.1 最少就能跑通的路先做最小閉環(huán)如果你也想用最少的時間和成本在兩周內(nèi)做出一個真正能演示的Agent我建議不要一上來就研究LangGraph、Dify這類底層編排更不要先啃Rust。最優(yōu)路徑是先把一個大模型API摸熟然后只做一件事把一個固定業(yè)務(wù)比如“自動生成商品標(biāo)題”通過一個工具函數(shù)和一個系統(tǒng)提示詞跑出一個能調(diào)用的Agent雛形。等這個雛形成功了再逐步加工具、加記憶、加規(guī)劃。很多人容易倒過來一開始就搭復(fù)雜的多Agent架構(gòu)Agent之間互相調(diào)用一個崩了全都涼。我的經(jīng)驗(yàn)是Agent越簡單越容易調(diào)試越容易debug也就越容易學(xué)習(xí)。第1周學(xué)Python基礎(chǔ)、看懂API調(diào)用完成一個單純聊天機(jī)器人。第2周寫一個單一工具調(diào)用比如查詢天氣、查庫存學(xué)會處理工具返回結(jié)果。第3周引入多步規(guī)劃和記憶讓Agent記錄中間結(jié)果并完成更復(fù)雜的任務(wù)。第4周之后再考慮上RAG、上向量庫、上LangGraph狀態(tài)機(jī)。到第9-12周把項(xiàng)目工程化加上用戶鑒權(quán)、日志、監(jiān)控、部署。這個節(jié)奏保守但穩(wěn)妥適合工作黨。別拿網(wǎng)上那些“7天沖刺AI Agent工程師”的課程節(jié)奏套自己能堅持超過兩周就算贏。5.2 前端Leader要注意的“三不一無”最后想聊一下心態(tài)。你在團(tuán)隊里是帶人的Leader轉(zhuǎn)型選擇和應(yīng)屆生完全不一樣你沒法完全清零重來也沒有大把時間試錯。這70天里我給自己定了幾條紀(jì)律想分享給同樣在帶團(tuán)隊的朋友一是不要在小步快跑階段內(nèi)卷。前端Leader有一種職業(yè)病上手任何新東西都會忍不住先優(yōu)化工具鏈、做腳手架、封裝組件。學(xué)會Python時我也這樣結(jié)果一周時間都在折騰環(huán)境配置和代碼格式化后來才醒悟先把功能跑通比什么都重要。二是不要拿前端的“確定性”去要求一切。Agent有天然的隨機(jī)性同樣輸入兩次結(jié)果可能不一樣。你如果還帶著“必須復(fù)現(xiàn)Bug”的老開發(fā)習(xí)慣會被搞瘋。設(shè)計Agent時要有兜底策略而不是追求每一步都完美。三是不要把團(tuán)隊牛馬兄弟丟下自己單飛。前端Leader帶團(tuán)隊轉(zhuǎn)AI的價值在于“組團(tuán)升級”。我會把Agent相關(guān)學(xué)習(xí)內(nèi)容拆成快手短視頻分享給組員每周一次十分鐘同步。能帶團(tuán)隊一起認(rèn)知升級比一個人悶頭看更有效率。四是不要害怕“不是科班出身”。Agent這個領(lǐng)域太新了科班沒學(xué)過“AI Agent架構(gòu)”這門課所有人都是邊做邊學(xué)。前端同學(xué)的交互理解、界面設(shè)計、工程化經(jīng)驗(yàn)在Agent產(chǎn)品里反而是稀缺能力。最后分享我自己驗(yàn)證過的一個小技巧如果你正在嘗試把現(xiàn)有業(yè)務(wù)流程變成Agent有一個特別低成本的做法先把你手頭經(jīng)常要用的一個后端接口包裝成工具接進(jìn)你選的Agent框架里。然后在System Prompt里加一句“當(dāng)你需要了解該業(yè)務(wù)信息時務(wù)必先調(diào)用查詢工具把結(jié)果整理后告知用戶”再去測試。你會很直觀地看到Agent是怎么走過去“查詢-整理-回復(fù)”的閉環(huán)。我在第70天最大的體會是這個領(lǐng)域確實(shí)深但并不是無路可走。前端積累的架構(gòu)思維、接口思維、用戶體驗(yàn)思維都會轉(zhuǎn)成你在Agent時代的獨(dú)特優(yōu)勢。剩下的就是在每天夜深人靜時把那行看似普通的循環(huán)代碼繼續(xù)跑下去。