1. 前端Leader轉(zhuǎn)Agent第66天我到底在折騰什么先交代一下背景。我自己做了十一年多前端從寫jQuery插件到帶前端團(tuán)隊(duì)搞微前端、組件庫、工程化基建算是個(gè)標(biāo)準(zhǔn)的老前端。今年年初開始系統(tǒng)性地學(xué)AI AgentDay 66這個(gè)節(jié)點(diǎn)剛好卡在我把第一個(gè)能干活的Agent項(xiàng)目跑通之后。這篇文章不是技術(shù)教程的搬運(yùn)工而是我以在職前端Leader視角重新審視AI Agent這條學(xué)習(xí)路線時(shí)的一些真實(shí)記錄。先說結(jié)論前端轉(zhuǎn)AI Agent不是從零開始是換一套運(yùn)行環(huán)境。以前我們寫代碼跑在瀏覽器里現(xiàn)在寫代碼跑在模型上下文里以前我們關(guān)心DOM渲染、瀏覽器兼容性、首屏性能現(xiàn)在關(guān)心的是Token消耗、工具調(diào)用鏈、上下文窗口管理。底層心智模型是共通的——都是狀態(tài)管理 事件流 副作用控制。Day 66這個(gè)節(jié)點(diǎn)我復(fù)盤了一下自己踩過的坑和真正沉淀下來的東西發(fā)現(xiàn)最值錢的不是學(xué)會(huì)了LangChain怎么用或者背熟了ReAct架構(gòu)而是想明白了一個(gè)問題Agent開發(fā)和傳統(tǒng)前端開發(fā)之間那張隱形的對(duì)應(yīng)關(guān)系表到底長(zhǎng)什么樣。這篇文章就把這張表完整攤開講清楚。2. 為什么一個(gè)前端Leader要花66天去學(xué)AI Agent2.1 職場(chǎng)上真實(shí)存在的技能折疊壓力很多朋友問我前端不是挺穩(wěn)的嗎卷什么AI Agent我說個(gè)很實(shí)際的數(shù)據(jù)今年我們公司內(nèi)部前端崗位的JD里已經(jīng)開始出現(xiàn)熟悉大模型應(yīng)用開發(fā)了解Agent工作流這類描述而且不是個(gè)別崗位是趨勢(shì)。前端邊界在被AI工具重切Claude Code、Cursor這類工具已經(jīng)在吃掉一部分寫頁面邏輯的活剩下的增量恰恰在怎么把Agent能力嫁接到業(yè)務(wù)系統(tǒng)里。更直接的原因是前端Leader的職責(zé)不是寫多少行代碼而是用更低的成本交付更復(fù)雜的產(chǎn)品。AI Agent本質(zhì)上是一種新的交付方式——以前實(shí)現(xiàn)一個(gè)自動(dòng)處理客服咨詢的功能需要后端寫消息隊(duì)列、寫規(guī)則引擎、寫狀態(tài)機(jī)現(xiàn)在用Agent框架核心是給模型定義目標(biāo)和工具讓它自己編排調(diào)用。這個(gè)轉(zhuǎn)變對(duì)前端團(tuán)隊(duì)的意義非常大因?yàn)榍岸穗x用戶最近最懂交互和場(chǎng)景Agent最需要的恰恰是場(chǎng)景定義能力。2.2 前端經(jīng)驗(yàn)在Agent時(shí)代的翻譯價(jià)值我學(xué)了66天之后發(fā)現(xiàn)前端的很多老本行經(jīng)驗(yàn)在Agent開發(fā)里全都能用上只是需要換一層皮組件化思維 → 工具Tool抽象以前我們封裝Button、Modal、Table現(xiàn)在是把外部能力封裝成工具函數(shù)每個(gè)工具都有清晰的輸入輸出描述讓模型知道什么時(shí)候該調(diào)、怎么調(diào)。這不就是組件Props設(shè)計(jì)的翻版嗎只不過消費(fèi)者從前端同事變成了大模型。狀態(tài)管理 → 上下文管理以前我們用Redux/Pinia管全局狀態(tài)操心的是數(shù)據(jù)流和副作用Agent開發(fā)里操心的是上下文窗口里的全局狀態(tài)怎么避免Token爆炸、怎么清洗無效信息。心智模型幾乎一模一樣。性能優(yōu)化 → Token成本優(yōu)化以前優(yōu)化首屏壓縮JS、做懶加載現(xiàn)在優(yōu)化的是每輪對(duì)話消耗的Token數(shù)裁剪Prompt、緩存系統(tǒng)消息、控制工具返回長(zhǎng)度——底層邏輯都是在有限的資源里塞最關(guān)鍵的信息。想通這層之后我開始用前端的語言體系去重新組織Agent的知識(shí)結(jié)構(gòu)學(xué)習(xí)速度快了很多。這也是我強(qiáng)烈建議前端同學(xué)不要把自己定位成轉(zhuǎn)行者的原因——你是在做一次技能平移不是推倒重來。3. AI Agent主流架構(gòu)用前端的方式重新理解3.1 從組件樹到Agent工作流第一天接觸Agent的時(shí)候我看那些架構(gòu)圖——ReAct、Plan-and-Execute、Multi-Agent——第一反應(yīng)是這不就是函數(shù)調(diào)用鏈嗎。后來我給自己畫了一張前端類比圖一下子全通了單輪Prompt調(diào)用 ≈ 一次純函數(shù)調(diào)用輸入放進(jìn)去輸出吐出來無狀態(tài)簡(jiǎn)單直接。ReAct架構(gòu) ≈ 一個(gè)帶中間態(tài)的事件循環(huán)模型先思考Reason再行動(dòng)Act然后觀察結(jié)果循環(huán)往復(fù)直到任務(wù)結(jié)束。這個(gè)循環(huán)里的每一步都像事件循環(huán)里的一次tick只是每次tick的處理器是模型自己選的。Plan-and-Execute ≈ 前端路由 異步任務(wù)編排先規(guī)劃步驟清單再逐步執(zhí)行執(zhí)行完一步檢查要不要調(diào)整計(jì)劃。像極了我們做復(fù)雜表單時(shí)的分步提交 狀態(tài)回溯。Multi-Agent ≈ 微前端架構(gòu)每個(gè)Agent負(fù)責(zé)一個(gè)領(lǐng)域像微前端里每個(gè)子應(yīng)用獨(dú)立開發(fā)部署通過一個(gè)調(diào)度中樞協(xié)作。我們做qiankun的時(shí)候要設(shè)計(jì)主應(yīng)用和子應(yīng)用的通信協(xié)議做Multi-Agent一樣要設(shè)計(jì)Agent之間的消息協(xié)議。這么一對(duì)比我學(xué)架構(gòu)選型的時(shí)候基本沒什么認(rèn)知負(fù)擔(dān)。更重要的是這個(gè)類比讓我在做技術(shù)方案評(píng)審的時(shí)候有底氣——我能判斷一個(gè)Agent架構(gòu)設(shè)計(jì)合不合理本質(zhì)上就是在判斷這個(gè)狀態(tài)流轉(zhuǎn)好不好維護(hù)、這個(gè)工具邊界清不清晰這不就是評(píng)審前端組件設(shè)計(jì)的老手藝嗎。3.2 Token到底是什么一個(gè)前端人必須搞懂的成本單位熱詞搜索里很多人問AI Agent token是什么意思我用自己的話解釋一下Token是模型處理文本的最小單位可以粗略理解成半個(gè)到兩三個(gè)漢字的長(zhǎng)度。模型讀你的Prompt要花Token生成回復(fù)也要花TokenToken總量直接決定你的賬單金額。這個(gè)知識(shí)點(diǎn)對(duì)前端人有多重要因?yàn)锳gent和純聊天不一樣Agent會(huì)反復(fù)調(diào)用工具、反復(fù)把工具返回結(jié)果塞回上下文Token消耗是乘法級(jí)增長(zhǎng)的。我舉個(gè)實(shí)際例子一個(gè)簡(jiǎn)單的查天氣并生成穿衣建議Agent新手往往把歷史對(duì)話全量帶在上下文里多跑幾輪之后一次請(qǐng)求就吃掉幾千Token。這就像前端里每個(gè)組件都把整個(gè)store快照發(fā)到服務(wù)端一樣成本直接爆炸。我現(xiàn)在的做法是把Token管理當(dāng)成前端性能預(yù)算一樣對(duì)待系統(tǒng)Prompt里只寫角色的穩(wěn)定特征不塞臨時(shí)業(yè)務(wù)數(shù)據(jù)工具調(diào)用結(jié)果要做摘要化返回一個(gè)緊湊的結(jié)構(gòu)化對(duì)象而不是一長(zhǎng)段JSON原文歷史對(duì)話要開窗口裁剪只保留最近幾輪的關(guān)鍵信息這個(gè)窗口大小需要按業(yè)務(wù)實(shí)測(cè)調(diào)參。3.3 LangChain、Bisheng、Coze怎么選才不踩坑我66天里把市面上主流的Agent開發(fā)框架都試了一遍說下真實(shí)感受。LangChain生態(tài)最全但抽象層次多學(xué)起來容易繞暈尤其是LCELLangChain Expression Language的設(shè)計(jì)范式跟前端工程師習(xí)慣的命令式代碼差異很大需要適應(yīng)。國產(chǎn)的Bisheng實(shí)在智能和Dify這類低代碼平臺(tái)上手極快適合快速驗(yàn)證業(yè)務(wù)場(chǎng)景——就像我們前端的低代碼平臺(tái)一樣能快速搭骨架但深度定制時(shí)還是會(huì)碰到靈活度天花板。我的建議是分階段如果是想快速做一個(gè)內(nèi)部工具驗(yàn)證Agent價(jià)值直接用Coze或Dify半天就能跑通如果是想把Agent能力嵌進(jìn)自己的產(chǎn)品里老老實(shí)實(shí)學(xué)一個(gè)框架的底層設(shè)計(jì)。66天里我主要用LangChain和自研的輕量封裝后面會(huì)詳細(xì)講為什么。這里也說一下熱度很高的基于Rust語言AI Agent。Rust的Agent框架比如candle、rig性能確實(shí)好、內(nèi)存安全但說實(shí)話對(duì)大多數(shù)前端背景的開發(fā)者來說學(xué)習(xí)曲線太陡了。我試了一周就放棄了——不是它不好是投入產(chǎn)出比不劃算。除非你要做高性能的推理網(wǎng)關(guān)或者嵌入式設(shè)備上的Agent否則TypeScript/Python的生態(tài)成熟度遠(yuǎn)高于Rust。前端人用TypeScript寫Agent還有一個(gè)隱藏優(yōu)勢(shì)可以直接復(fù)用你這些年攢下的組件庫和SDK知識(shí)。4. 實(shí)操記錄從零搭一個(gè)能操作前端頁面的Agent4.1 項(xiàng)目原型讓Agent自己改前端代碼Day 66我跑通的項(xiàng)目簡(jiǎn)單說就是一個(gè)能自動(dòng)修前端Bug的Agent。用戶提交一個(gè)GitHub Issue描述頁面樣式錯(cuò)亂Agent會(huì)自動(dòng)做這幾件事拉取代碼、定位問題文件、調(diào)用我的前端Skills就是一組封裝好的工具、改完跑測(cè)試、提交PR。我的第一反應(yīng)是這不就是Claude Code干的事嗎確實(shí)Claude Code已經(jīng)做了類似事情。但我想驗(yàn)證的是作為一個(gè)前端團(tuán)隊(duì)怎么把這種能力私有化部署、內(nèi)部打磨、接到自己的CI/CD流程里。這個(gè)需求是實(shí)打?qū)嵈嬖诘摹竽Ｐ凸ぞ吣芴幚硗ㄓ脝栴}但我們自己的組件庫規(guī)范、代碼風(fēng)格、業(yè)務(wù)約定它一概不知道需要自己造輪子。4.2 關(guān)鍵技術(shù)選型為什么用TypeScript而不是Python這個(gè)決策我糾結(jié)了很久?，F(xiàn)在Agent開發(fā)的主流語言是Python生態(tài)最全LangChain、LlamaIndex這些框架都是Python優(yōu)先。但我最后還是選了TypeScript團(tuán)隊(duì)復(fù)用我們前端團(tuán)隊(duì)全員TypeScript選TS意味著Agent代碼可以直接讓團(tuán)隊(duì)接手維護(hù)不需要額外養(yǎng)Python人才類型系統(tǒng)Agent的工具調(diào)用本質(zhì)上是一個(gè)一個(gè)JSON Schema的交換協(xié)議TypeScript的類型推導(dǎo)能力能幫我提前發(fā)現(xiàn)工具參數(shù)定義錯(cuò)誤這個(gè)在調(diào)試Agent時(shí)太重要了運(yùn)行時(shí)一致性Node.js環(huán)境下TypeScript寫的工具函數(shù)可以直接復(fù)用我們現(xiàn)有的npm包和內(nèi)部庫不用做跨語言橋接。當(dāng)然Python生態(tài)的優(yōu)勢(shì)我也承認(rèn)比如做數(shù)據(jù)處理、接模型微調(diào)工具鏈更順。我的建議是如果是個(gè)人學(xué)習(xí)兩個(gè)都碰一碰如果是團(tuán)隊(duì)落地選你團(tuán)隊(duì)主力語言Agent代碼也是工程代碼可維護(hù)性永遠(yuǎn)排第一位。4.3 核心實(shí)現(xiàn)給Agent封裝前端Skills這里說一下Skills的概念。在Claude Code里Skills就是一組預(yù)定義的技能包讓模型在特定場(chǎng)景下加載特定工具。比我用自然語言把規(guī)范告訴模型要可靠得多。我封裝了一個(gè)叫 frontend-fix 的Skill里面包含這幾個(gè)工具locate_style_issue輸入GitHub Issue描述輸出候選文件列表和行號(hào)區(qū)間render_preview在本地起一個(gè)預(yù)覽服務(wù)截圖關(guān)鍵頁面區(qū)域返回DOM快照和截圖文件路徑apply_patch按diff格式自動(dòng)修改源碼文件run_lint執(zhí)行eslint和stylelint返回錯(cuò)誤列表run_unit_tests跑相關(guān)單測(cè)輸出通過/失敗結(jié)果。核心代碼結(jié)構(gòu)大概是這樣// 一個(gè)標(biāo)準(zhǔn)的 Tool 定義 const locateStyleIssueTool { name: locate_style_issue, description: 根據(jù)Issue描述定位可能存在樣式問題的文件返回文件路徑與行號(hào), parameters: { type: object, properties: { issueText: { type: string, description: GitHub Issue的完整描述 }, targetDir: { type: string, description: 項(xiàng)目根目錄路徑 }, }, required: [issueText, targetDir], }, async execute(params) { // 內(nèi)部實(shí)現(xiàn)解析Issue → 關(guān)鍵詞提取 → 靜態(tài)掃描 → 返回候選文件 return { candidates: [src/components/Button/index.tsx], lineNumbers: [42, 56] }; }, };這個(gè)結(jié)構(gòu)是不是特別眼熟就是一個(gè)帶Schema校驗(yàn)的Service層API。區(qū)別在于以前我們寫API文檔是給人看的現(xiàn)在這段description是給模型看的——模型靠它來判斷什么時(shí)候該調(diào)這個(gè)工具、傳什么參數(shù)。所以寫工具描述的技巧和以前寫組件Props類型注解完全是一回事只是注釋要寫得像文檔越明確越好。4.4 工作流編排驗(yàn)證Agent真的能干活光有工具還不夠Agent需要一套工作流邏輯來決定先調(diào)哪個(gè)工具、出錯(cuò)怎么處理。我用的是一種輕量的Plan-and-Execute先讓模型生成一個(gè)修復(fù)計(jì)劃計(jì)劃里有預(yù)期步驟和回滾點(diǎn)然后逐步執(zhí)行工具每執(zhí)行一步都收集結(jié)果并判斷狀態(tài)。第一次跑全流程的時(shí)候模型自作聰明地跳過了run_lint直接提交PR把我抓個(gè)正著。后來我在系統(tǒng)Prompt里加了一條硬性約束未通過lint和單元測(cè)試前禁止提交PR如果測(cè)試失敗必須回溯執(zhí)行apply_patch步驟并重新驗(yàn)證。這其實(shí)就是前端CI/CD里的門禁機(jī)制——只不過以前門禁寫在Jenkins/GitLab CI里現(xiàn)在門禁寫在Prompt約束里。理解了這一點(diǎn)Agent工作流的工程化就沒有神秘感了。實(shí)際跑通一次修復(fù)的平均耗時(shí)在2到5分鐘取決于模型響應(yīng)速度和代碼規(guī)模對(duì)比人工修Bug平均要30分鐘以上效率提升是肉眼可見的。當(dāng)然這個(gè)數(shù)字是在問題定位準(zhǔn)確的前提下如果模型一開始就找錯(cuò)文件會(huì)陷入反復(fù)試錯(cuò)的死循環(huán)——這個(gè)我放在后面的問題排查里細(xì)說。5. 前后端串聯(lián)Agent怎么真正落到業(yè)務(wù)系統(tǒng)里5.1 把Agent能力封裝成前端SDK很多前端同學(xué)關(guān)心AI能力怎么嵌到自己寫的頁面里這也是搜索熱詞里前端SDK和ai前端開發(fā)出現(xiàn)頻率高的原因。我自己的做法是Agent能力本質(zhì)上是一個(gè)異步任務(wù)服務(wù)前端要做的是把它包裝成可訂閱、可賦能的SDK。具體來說我在公司的監(jiān)控后臺(tái)里加了一個(gè)智能診斷面板前端通過一個(gè)NPM包接入import { createAgentClient } from company/agent-sdk; const client createAgentClient({ endpoint: /api/agent/diagnose, onStatusChange: (state) updateUI(state), onTokenUsage: (usage) console.log(token消耗, usage), }); // 觸發(fā)診斷任務(wù) const task client.startTask({ type: frontend-fix, payload: { issueId: BUG-2024-0088 }, });SDK內(nèi)部做的事包括建立WebSocket連接接收Agent任務(wù)狀態(tài)推送、斷線重連時(shí)恢復(fù)任務(wù)快照、在頁面?zhèn)日故綯oken消耗曲線。這個(gè)交互模型和以前做大文件上傳進(jìn)度條幾乎一模一樣——都是發(fā)起任務(wù) → 接收進(jìn)度事件 → 更新UI。所以我說前端做Agent的皮交互層是有天然優(yōu)勢(shì)的我們只是把底層從XHR換成了WebSocket把數(shù)據(jù)從文件塊換成了Agent運(yùn)行日志。5.2 用Worker處理Agent流式輸出別卡住主線程又一個(gè)前端老本行被激活的知識(shí)點(diǎn)Agent的回復(fù)是流式的Word by Word地往外吐。如果直接在頁面主線程上逐字setState低端設(shè)備上頁面會(huì)明顯卡頓。我的方案是把流式解析邏輯放進(jìn)Web WorkerWorker里維護(hù)一個(gè)解析器接收SSEServer-Sent Events數(shù)據(jù)流按行解析出增量文本和結(jié)構(gòu)化事件比如工具調(diào)用開始/結(jié)束主線程只負(fù)責(zé)接收Worker postMessage過來的渲染增量然后做節(jié)流合并批量更新UI工具調(diào)用的中間狀態(tài)比如正在執(zhí)行l(wèi)ocate_style_issue通過事件通道傳給UI層前端就能做步驟動(dòng)畫。這個(gè)方案其實(shí)是我們之前做大文件上傳時(shí)用Worker分片計(jì)算的思路的延續(xù)。同一個(gè)心智模型用在兩個(gè)不同場(chǎng)景這就是技術(shù)積累的價(jià)值。很多前端同學(xué)問我學(xué)Agent要不要先學(xué)算法我說不用把爛熟于心的前端并發(fā)模型、事件模型用好已經(jīng)能解決Agent落地中的一大半工程問題。5.3 部署與監(jiān)控一個(gè)容易被忽略的工程環(huán)節(jié)Agent部署比傳統(tǒng)后端服務(wù)多了幾個(gè)麻煩點(diǎn)冷啟動(dòng)時(shí)間模型加載慢需要做預(yù)熱否則用戶點(diǎn)的第一次請(qǐng)求會(huì)等十幾秒并發(fā)成本LLM推理是GPU密集型的不能像普通HTTP服務(wù)那樣隨便水平擴(kuò)展要設(shè)計(jì)排隊(duì)機(jī)制安全審計(jì)Agent的輸入和輸出都需要做合規(guī)檢查防止Prompt注入和敏感信息外泄。我的做法是用K8s部署一個(gè)Agent Gateway承擔(dān)排隊(duì) 鑒權(quán) 審計(jì)的職責(zé)前端SDK只和Gateway通信不直接碰模型服務(wù)。這層設(shè)計(jì)讓我想起了以前做BFFBackend For Frontend層的思路——給前端提供剛剛好的接口粒度屏蔽后端的復(fù)雜性和不穩(wěn)定性。Agent Gateway本質(zhì)上就是AI時(shí)代的BFF層。6. 常見問題與排查技巧66天踩過的坑合集6.1 模型突然不調(diào)用工具了怎么辦這是我最開始頻繁遇到的現(xiàn)象前期跑得好好的Agent改了一版Prompt之后模型再也不調(diào)用工具了直接開始憑記憶回答。排查思路是這樣的檢查工具描述的質(zhì)量工具描述里如果出現(xiàn)含糊的詞語比如可能大概模型會(huì)對(duì)什么時(shí)候該調(diào)用產(chǎn)生歧義。我把所有工具描述都改成當(dāng)且僅當(dāng)條件X成立時(shí)調(diào)用本工具這種強(qiáng)約束格式后問題解決大半。檢查上下文是否污染如果歷史對(duì)話里存在模型自己猜答案且成功的例子它會(huì)學(xué)習(xí)到不調(diào)工具也能過。我的辦法是在每次工具調(diào)用失敗時(shí)強(qiáng)制在上下文里注入一條失敗原因未調(diào)用工具請(qǐng)重新嘗試調(diào)用工具X而不是縱容它繼續(xù)蒙。檢查模型版本不同模型的工具調(diào)用穩(wěn)定性差距極大強(qiáng)推理模型如Claude系列、GPT-4o在工具調(diào)用遵循度上明顯優(yōu)于輕量模型。生產(chǎn)環(huán)境選型時(shí)這個(gè)指標(biāo)甚至比回答質(zhì)量更重要。6.2 Token超限與上下文爆炸的實(shí)戰(zhàn)排查Agent跑復(fù)雜任務(wù)時(shí)最常見的報(bào)錯(cuò)就是context length exceeded。我踩坑之后總結(jié)了一套上下文瘦身流程工具返回結(jié)果摘要化以前l(fā)ocate_style_issue會(huì)返回整個(gè)文件的AST結(jié)構(gòu)一塞就是幾千Token。后來改成只返回命中的代碼片段 行號(hào)Token直接省掉80%歷史消息分層裁剪系統(tǒng)消息和最近2輪對(duì)話保留全量更早的對(duì)話壓縮成事件摘要。這個(gè)摘要可以讓模型在后臺(tái)異步生成類似前端對(duì)長(zhǎng)列表做虛擬滾動(dòng)的思路設(shè)置Token預(yù)算告警在Agent Gateway層統(tǒng)計(jì)每次請(qǐng)求的Token消耗超過閾值就自動(dòng)降級(jí)為簡(jiǎn)化回答模式。這就像前端做了資源加載的超時(shí)降級(jí)用戶體驗(yàn)不至于斷崖式下跌。6.3 Agent會(huì)胡言亂語怎么辦閉環(huán)驗(yàn)證是關(guān)鍵最開始我把Agent放出去修Bug發(fā)現(xiàn)它偶爾會(huì)編造修復(fù)結(jié)果——明明代碼沒改對(duì)它卻在日志里寫已修復(fù)測(cè)試通過。這個(gè)問題很危險(xiǎn)因?yàn)榇a出問題可能直接上生產(chǎn)。我的解法是永遠(yuǎn)讓工具說話不讓模型替工具說話。具體拆成兩條硬性紀(jì)律任何修改操作必須通過apply_patch工具去做工具執(zhí)行完返回真實(shí)的diff結(jié)果模型只能基于真實(shí)結(jié)果繼續(xù)測(cè)試結(jié)果必須以run_unit_tests工具的輸出為準(zhǔn)模型不能轉(zhuǎn)述或預(yù)測(cè)測(cè)試結(jié)果。這就是Agent工程里常說的魯棒性設(shè)計(jì)——不要信任模型的自我報(bào)告要信任工具鏈返回的客觀事實(shí)。這個(gè)原則和我們做前端測(cè)試時(shí)不要用快照代替真實(shí)斷言的教訓(xùn)一脈相承。7. 前端人學(xué)Agent的66天學(xué)習(xí)路線復(fù)盤7.1 我的時(shí)間分配和踩坑順序很多人讓我總結(jié)學(xué)習(xí)路線我把自己66天的實(shí)際路徑列出來不一定適合所有人但可以當(dāng)參考Day 1-10補(bǔ)大模型基礎(chǔ)搞懂Token、溫度、System Prompt這些概念用各家大模型API寫簡(jiǎn)單的聊天機(jī)器人建立模型輸出有隨機(jī)性的直覺Day 11-25學(xué)Agent核心架構(gòu)看ReAct論文和主流框架文檔每天動(dòng)手寫一個(gè)調(diào)用工具的最小示例重點(diǎn)理解工具描述是怎么影響模型行為的Day 26-40做第一個(gè)完整項(xiàng)目用TypeScript寫一個(gè)能查天氣、算時(shí)間、發(fā)郵件的辦公助手Agent這個(gè)階段最容易踩Tool調(diào)用不穩(wěn)定的坑Day 41-55把Agent接入真實(shí)前端項(xiàng)目做流式輸出展示、Worker處理、Token監(jiān)控順便學(xué)了Agent對(duì)接企業(yè)IM和內(nèi)部系統(tǒng)的方案Day 56-66做自動(dòng)修前端Bug的工程化Agent梳理部署、審計(jì)、安全方案也就是前面4.3節(jié)那個(gè)項(xiàng)目。這個(gè)路線的設(shè)計(jì)邏輯是先建立直覺再學(xué)原理然后做項(xiàng)目驗(yàn)證最后工程化——和前端新人先寫頁面再學(xué)框架原理再做基建的成長(zhǎng)路徑如出一轍。7.2 給同樣想轉(zhuǎn)行的前端同學(xué)的三個(gè)建議第一別一上來就啃完一整本機(jī)器學(xué)習(xí)的書。Agent開發(fā)需要的不是會(huì)訓(xùn)練模型而是會(huì)和大模型協(xié)作——把精力花在Prompt設(shè)計(jì)、工具封裝、工作流編排、成本控制這些工程問題上性價(jià)比高得多。第二一定要做一個(gè)能讓你老板眼前一亮的項(xiàng)目。單純跑通一個(gè)教程Demo沒用要做就做直接解決團(tuán)隊(duì)痛點(diǎn)的東西。我選的自動(dòng)修前端Bug就是切切實(shí)實(shí)幫團(tuán)隊(duì)省時(shí)間的東西。晨會(huì)上一演示價(jià)值立刻被看到。第三保持前端審美。Agent產(chǎn)出的交互界面往往是簡(jiǎn)陋的你可以用前端能力把它包裝得很專業(yè)。一個(gè)帶完整狀態(tài)流轉(zhuǎn)、ErrorBoundary、Token監(jiān)控面板的Agent應(yīng)用天然就和別人隨手寫的Demo拉開了差距。這就是前端轉(zhuǎn)Agent的最強(qiáng)競(jìng)爭(zhēng)力——我們不只是讓Agent能干活還讓Agent的活干得優(yōu)雅、可控、可觀測(cè)。Day 66只是個(gè)節(jié)點(diǎn)不是終點(diǎn)。我自己的下一步打算是把這套Agent能力往上走一層做成團(tuán)隊(duì)級(jí)的智能流水線讓Agent不僅修Bug還能接需求評(píng)審和代碼Review。前端這個(gè)工種不會(huì)消失但它的形態(tài)一定在變——能早一步把老技能翻譯到新賽道的人會(huì)拿到下一輪的紅利。