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