把“智能體”這三個(gè)字丟進(jìn)論文搜索引擎過去一年的產(chǎn)出量是相當(dāng)嚇人的。但真正值得讀的不是數(shù)量而是幾個(gè)方向上的拐點(diǎn)信號(hào)從“能聊天”到“能干活”從單Agent到多Agent從“能跑通Demo”到“必須過安全評(píng)測(cè)”這個(gè)領(lǐng)域在一年內(nèi)把概念期、泡沫期和初步工程化期全走了一遍。這篇分享不打算給你羅列一堆論文清單而是從智能體訓(xùn)練方法、安全評(píng)測(cè)、多智能體協(xié)同、企業(yè)落地四條主線聊聊我最近讀到的關(guān)鍵進(jìn)展以及哪些東西是真正能遷移到你自己項(xiàng)目里用的。無論你是正在做Agent應(yīng)用開發(fā)的工程師、想搭智能體產(chǎn)品的創(chuàng)業(yè)者還是被“智能體面試”折磨的求職者這篇文章里應(yīng)該都有你用得上的部分。1. 智能體到底在研究什么幾條清晰的主線1.1 從ReAct到Plan-and-Execute范式正在收斂前兩年看智能體論文幾乎每一篇都在講ReAct模式模型每走一步先Reason推理再Act行動(dòng)跟工具交互然后觀察結(jié)果繼續(xù)下一輪。這個(gè)模式確實(shí)有效但它的天花板也很明顯——模型容易陷入“走一步看一步”的短視遇到長(zhǎng)任務(wù)就開始原地打轉(zhuǎn)。最近的論文里Plan-and-Execute風(fēng)格的東西明顯變多了。模型先拆解一個(gè)完整計(jì)劃再把計(jì)劃里的每個(gè)步驟交給執(zhí)行器去跑。這個(gè)轉(zhuǎn)變本質(zhì)上是把“思考”和“執(zhí)行”分開思考階段可以反復(fù)推敲、調(diào)整計(jì)劃執(zhí)行階段則追求快速、確定性強(qiáng)的工具調(diào)用。我自己的體會(huì)是如果你讓模型在每一輪都又思考又調(diào)用工具上下文很快就會(huì)被中間推理撐爆而Plan-and-Execute能有效控制token消耗也讓問題定位容易得多。這兩種范式不是替代關(guān)系更像是互補(bǔ)。ReAct適合探索性任務(wù)比如“幫我研究一下這個(gè)競(jìng)品”Plan-and-Execute適合流程確定性強(qiáng)的任務(wù)比如“每天定時(shí)抓取數(shù)據(jù)并生成報(bào)表”。真正成熟的智能體框架大多是把兩者揉在一起先規(guī)劃再逐步執(zhí)行遇到偏差再重新規(guī)劃。1.2 當(dāng)前論文的五個(gè)熱點(diǎn)方向我看了幾十篇近期的預(yù)印本和會(huì)議論文如果要給當(dāng)前智能體研究畫一張地圖大概是這五個(gè)方向在同時(shí)發(fā)力第一可驗(yàn)證推理。把強(qiáng)化學(xué)習(xí)用到智能體決策上用規(guī)則獎(jiǎng)勵(lì)代替人工標(biāo)注這是DeepSeek公開的路線帶火的方向后面專門展開說。第二多模態(tài)與GUI Agent。模型不再只調(diào)用API而是直接“看”屏幕、“點(diǎn)”按鈕把操作系統(tǒng)的界面當(dāng)作工具來使用這條線在企業(yè)自動(dòng)化場(chǎng)景里非常實(shí)用。第三多智能體協(xié)同。單個(gè)Agent解決不了的大任務(wù)拆給多個(gè)專業(yè)Agent去協(xié)作涉及通信協(xié)議、任務(wù)分配、共識(shí)機(jī)制這些經(jīng)典分布式系統(tǒng)問題。第四安全對(duì)齊與紅隊(duì)測(cè)試。Prompt注入、工具濫用、記憶污染這些攻擊已經(jīng)開始形成評(píng)測(cè)基準(zhǔn)。第五長(zhǎng)程任務(wù)記憶。Agent記不住幾輪前說過什么、做過什么這是很多應(yīng)用上不了生產(chǎn)環(huán)境的直接原因。這五個(gè)方向不是并列的它們之間的關(guān)系更像是沒有安全評(píng)測(cè)前面四個(gè)方向的成果都很難在企業(yè)里落地。這也是為什么我這次特別想聊聊安全那條線。1.3 為什么“智能體”的定義正在變化兩年前你說智能體大家默認(rèn)指的是“一個(gè)接了工具的大模型”?，F(xiàn)在論文里討論的智能體定義已經(jīng)變成了“一個(gè)包含模型、工具、記憶、安全策略和評(píng)測(cè)體系的結(jié)構(gòu)化系統(tǒng)”。這個(gè)變化很重要它意味著研究者的注意力從“怎么讓單次回答更聰明”轉(zhuǎn)移到了“怎么讓系統(tǒng)長(zhǎng)期穩(wěn)定地完成復(fù)雜任務(wù)”。對(duì)一個(gè)從業(yè)者來說這個(gè)信號(hào)更實(shí)際你要設(shè)計(jì)的不再是一個(gè)Prompt而是一條數(shù)據(jù)流。模型在哪個(gè)環(huán)節(jié)做決策工具在哪個(gè)環(huán)節(jié)被執(zhí)行錯(cuò)誤在哪個(gè)環(huán)節(jié)被捕獲這些架構(gòu)層面的問題決定了一個(gè)智能體項(xiàng)目是活在生產(chǎn)環(huán)境里還是永遠(yuǎn)停留在Demo階段。2. 訓(xùn)練方法上的硬核突破DeepSeek公開的智能體訓(xùn)練新思路2.1 可驗(yàn)證獎(jiǎng)勵(lì)為什么是那把鑰匙DeepSeek公開的智能體訓(xùn)練新方法引發(fā)了新一輪討論核心關(guān)鍵詞其實(shí)是“可驗(yàn)證獎(jiǎng)勵(lì)”。傳統(tǒng)微調(diào)大模型做智能體任務(wù)依賴人工標(biāo)注的偏好數(shù)據(jù)讓標(biāo)注員對(duì)比兩個(gè)回答哪個(gè)更好成本高而且標(biāo)注一致性差。但智能體的很多行為結(jié)果是可以自動(dòng)判分的——工具調(diào)用成功沒成功、返回值對(duì)不對(duì)、任務(wù)有沒有在規(guī)定步數(shù)內(nèi)完成這些都是客觀事實(shí)。把RL用到智能體訓(xùn)練上的思路本質(zhì)上跟AlphaGo下棋是一樣的規(guī)則是確定的結(jié)果可以自動(dòng)判斷那就可以讓模型在大量試錯(cuò)中自己學(xué)會(huì)策略。DeepSeek技術(shù)報(bào)告里最值得關(guān)注的就是這個(gè)判斷過程完全不依賴人工打分模型做對(duì)了就加分做錯(cuò)了就扣分訓(xùn)練信號(hào)非常干凈。落到智能體場(chǎng)景規(guī)則獎(jiǎng)勵(lì)信號(hào)特別適合三類任務(wù)代碼生成與執(zhí)行結(jié)果校驗(yàn)、結(jié)構(gòu)化數(shù)據(jù)查詢SQL、文檔檢索、工具調(diào)用序列是否達(dá)成目標(biāo)。如果你要復(fù)現(xiàn)這套思路我建議從這類結(jié)果可判定的任務(wù)入手而不是一開始就試圖訓(xùn)練一個(gè)開放式對(duì)話Agent。2.2 從長(zhǎng)思考能力遷移到行動(dòng)決策DeepSeek路線里還有一個(gè)非常重要的設(shè)計(jì)就是“長(zhǎng)思考”。模型在回答前會(huì)先生成一大段內(nèi)部推理過程相當(dāng)于把“想清楚再回答”變成了訓(xùn)練目標(biāo)。這個(gè)能力遷移到智能體上就是你看到的“思考即規(guī)劃”模型不再急著調(diào)用工具而是先生成行動(dòng)計(jì)劃評(píng)估哪個(gè)工具更合適預(yù)測(cè)可能的結(jié)果再動(dòng)手。在具體實(shí)現(xiàn)上關(guān)鍵是分組相對(duì)策略優(yōu)化GRPO這個(gè)訓(xùn)練技巧。傳統(tǒng)強(qiáng)化學(xué)習(xí)要訓(xùn)練一個(gè)價(jià)值模型Critic來估計(jì)未來的收益成本很高GRPO直接從一組采樣輸出之間的相對(duì)優(yōu)劣來計(jì)算優(yōu)勢(shì)函數(shù)省掉了Critic模型顯存占用和訓(xùn)練穩(wěn)定性都友好很多。我讀論文時(shí)最大的體會(huì)是這套方法對(duì)工具選擇這類決策尤其有效。模型學(xué)會(huì)在調(diào)用工具前“停下來想一下”實(shí)際效果上就是錯(cuò)誤調(diào)用次數(shù)明顯下降。我試過用類似的思路在一個(gè)內(nèi)部的小模型上微調(diào)工具選擇策略只用了不到一萬條軌跡數(shù)據(jù)工具選擇準(zhǔn)確率就提升了一大截。當(dāng)然前提是你得有一個(gè)結(jié)果自動(dòng)判分的環(huán)境。2.3 對(duì)普通開發(fā)者的實(shí)際價(jià)值在哪里很多同學(xué)看到這種訓(xùn)練方法的第一反應(yīng)是“我根本沒有訓(xùn)練集群跟我有什么關(guān)系”其實(shí)關(guān)系很大。第一個(gè)價(jià)值是開源權(quán)重可以直接用。DeepSeek開源的推理模型經(jīng)過這類強(qiáng)化學(xué)習(xí)訓(xùn)練后處理工具調(diào)用任務(wù)時(shí)天然傾向于“先推理后行動(dòng)”。你甚至不需要微調(diào)直接調(diào)整Prompt讓它輸出思考過程就能看到它在多步工具調(diào)用中的穩(wěn)定性提升。第二個(gè)價(jià)值是數(shù)據(jù)構(gòu)造方法可以抄作業(yè)。拒絕采樣生成高質(zhì)量SFT數(shù)據(jù)再用規(guī)則獎(jiǎng)勵(lì)做一輪強(qiáng)化學(xué)習(xí)這個(gè)pipeline在小規(guī)模也能跑通幾百條高質(zhì)量軌跡就足以讓一個(gè)小模型學(xué)到“想清楚再調(diào)用工具”的習(xí)慣。當(dāng)然也有不少坑。最典型的是獎(jiǎng)勵(lì)信號(hào)設(shè)計(jì)過于稀疏任務(wù)只有成功和失敗兩種結(jié)果中間沒有過程獎(jiǎng)勵(lì)模型很難學(xué)到有效策略。還有一點(diǎn)要特別注意當(dāng)你給模型引入“長(zhǎng)思考”能力你會(huì)看到響應(yīng)延遲顯著增加。智能體場(chǎng)景里不是每個(gè)請(qǐng)求都需要深度思考我的經(jīng)驗(yàn)是加一個(gè)路由層簡(jiǎn)單任務(wù)走快速通道復(fù)雜任務(wù)再啟用帶思考的Agent否則用戶等不起。3. 安全評(píng)測(cè)正在變成比效果評(píng)測(cè)更硬的門檻3.1 AgentDojo一套更接近真實(shí)業(yè)務(wù)的攻防測(cè)試方法智能體安全這塊我最近比較關(guān)注的是AgentDojo這篇工作。它不是那種拿幾個(gè)玩具問題測(cè)來測(cè)去的benchmark而是把攻擊和防御場(chǎng)景直接裝進(jìn)了真實(shí)的業(yè)務(wù)流里。AgentDojo的思路是構(gòu)建一系列“用戶任務(wù)攻擊場(chǎng)景”每個(gè)場(chǎng)景里智能體需要調(diào)用多個(gè)工具完成一個(gè)真實(shí)目標(biāo)與此同時(shí)攻擊者會(huì)想辦法污染用戶的指令、注入惡意提示、或者誘導(dǎo)智能體錯(cuò)誤使用工具。評(píng)測(cè)維度有兩個(gè)一個(gè)叫可用性Utility即正常任務(wù)的成功率一個(gè)叫魯棒性Robustness即注入前后成功率的差值——差值越大說明越容易被攻擊者帶偏。這個(gè)設(shè)計(jì)我覺得非常聰明。以前做安全評(píng)測(cè)大家都在測(cè)“模型會(huì)不會(huì)回答有害問題”但智能體時(shí)代的安全問題更多是“模型會(huì)不會(huì)在正常任務(wù)中被劫持去做錯(cuò)誤的事”。你想要的不是模型拒絕回答問題而是模型在遭遇注入時(shí)仍然能完成用戶真正交辦的任務(wù)。實(shí)操層面的建議是拿AgentDojo這類測(cè)試框架來評(píng)估你自己的智能體時(shí)不要只看一個(gè)得分要拆開看正常任務(wù)成功率是多少、受到攻擊后掉多少點(diǎn)。如果你發(fā)現(xiàn)魯棒性掉得很厲害通常問題出在“不加區(qū)分地信任工具返回結(jié)果”或者“上下文里塞了太多外部信息”這兩類原因上。3.2 OWASP智能體應(yīng)用Top 10每個(gè)風(fēng)險(xiǎn)都是一道安全設(shè)計(jì)題2026年的OWASP智能體應(yīng)用Top 10發(fā)布后我把它當(dāng)成了一份“安全設(shè)計(jì)Checklist”來用。十個(gè)風(fēng)險(xiǎn)項(xiàng)大致覆蓋了智能體系統(tǒng)的主要攻擊面身份授權(quán)與訪問控制、記憶污染、工具誤用、提示注入、數(shù)據(jù)泄露、不當(dāng)處置、供應(yīng)鏈安全、模型幻覺導(dǎo)致的錯(cuò)誤輸出、錯(cuò)誤歸屬把模型的計(jì)劃錯(cuò)誤歸因給用戶、通信鏈路截獲等等。逐條看可能比較枯燥但從工程角度這些風(fēng)險(xiǎn)對(duì)應(yīng)著幾乎每一層架構(gòu)都需要做加固。比如記憶污染意味著你得在上下文寫入之前清洗外部數(shù)據(jù)工具誤用意味著你需要一個(gè)工具級(jí)權(quán)限控制層而不是讓模型隨心所欲地調(diào)用所有函數(shù)供應(yīng)鏈安全意味著第三方插件和模型權(quán)重都可能被投毒。我踩過的坑是團(tuán)隊(duì)開發(fā)智能體時(shí)第一版往往沒有安全設(shè)計(jì)等到評(píng)測(cè)階段才發(fā)現(xiàn)Prompt注入很容易被搞定然后返工改架構(gòu)。如果一開始就用OWASP的清單做威脅建模把“誰有權(quán)限調(diào)用哪個(gè)工具”“工具參數(shù)需要不需要白名單校驗(yàn)”“外部輸入怎么和系統(tǒng)指令區(qū)分”這些問題在架構(gòu)層面定下來后面的返工會(huì)少很多。3.3 智能體行為審計(jì)到底審計(jì)什么“智能體行為審計(jì)”這個(gè)詞最近在招聘和合規(guī)場(chǎng)景里反復(fù)出現(xiàn)。通俗地講它就是把智能體做過的事情完整記錄下來讓事后可以復(fù)盤、追責(zé)、甚至合規(guī)審查。為什么這個(gè)東西突然變重要了因?yàn)橹悄荏w是有自主性的它自己決定調(diào)用哪個(gè)工具、執(zhí)行什么操作如果出錯(cuò)你需要能說清楚“它當(dāng)時(shí)為什么要這么做”。工程上實(shí)現(xiàn)行為審計(jì)并不復(fù)雜但很容易被忽略。核心要素有三個(gè)第一鏈路追蹤每一個(gè)請(qǐng)求都帶一個(gè)trace ID貫穿Prompt、思考過程、工具調(diào)用、返回結(jié)果第二結(jié)構(gòu)化日志不是打幾行print而是把思考內(nèi)容、工具名、工具參數(shù)、執(zhí)行耗時(shí)、返回摘要都記錄成結(jié)構(gòu)化字段第三回放能力出了問題能按trace ID把一次完整的決策過程重新展示出來。這里有一個(gè)容易被忽略的點(diǎn)審計(jì)日志里要不要記錄模型的完整思考過程我傾向于要但要做脫敏處理。不記的話你只能看到它調(diào)了什么工具卻不知道它為什么這么調(diào)排查問題的能力會(huì)大打折扣。好在這兩年很多智能體框架都已經(jīng)內(nèi)置了這類追蹤能力不用自己從頭造輪子。4. 從論文到系統(tǒng)多智能體協(xié)同與工程落地經(jīng)驗(yàn)4.1 多智能體協(xié)同也在“理論化”群集運(yùn)動(dòng)控制能帶來什么啟發(fā)多智能體領(lǐng)域有一批論文來自控制論傳統(tǒng)研究的是“群集運(yùn)動(dòng)控制”一群無人機(jī)或者機(jī)器人怎么在沒有中心指揮的情況下保持隊(duì)形、避開障礙、達(dá)成一致。你可能覺得這跟軟件Agent八竿子打不著但我讀了之后發(fā)現(xiàn)它在工程上的啟發(fā)非常直接。這些論文里講的“一致性協(xié)議”本質(zhì)上就是智能體之間怎么交換信息、怎么收斂到同一個(gè)決策勢(shì)場(chǎng)避障對(duì)應(yīng)的是“當(dāng)多個(gè)Agent搶同一個(gè)資源時(shí)怎么自動(dòng)讓開”事件觸發(fā)通信對(duì)應(yīng)的是“不要每時(shí)每刻同步所有狀態(tài)只在關(guān)鍵節(jié)點(diǎn)才通信”。映射到軟件系統(tǒng)里就是一個(gè)多智能體協(xié)作架構(gòu)應(yīng)該好好設(shè)計(jì)消息總線和共享記憶池而不是讓每個(gè)子Agent都帶著全量上下文對(duì)話。我做過一個(gè)實(shí)驗(yàn)四個(gè)子Agent協(xié)作處理一個(gè)文檔分析任務(wù)一開始用的是“每個(gè)Agent把完整上下文傳給下一個(gè)”的管線方式結(jié)果上下文越滾越大到最后模型基本是懵的。后來改成共享記憶池加事件觸發(fā)的消息傳遞每個(gè)Agent只關(guān)注自己需要的片段整體效果提升非常明顯。這個(gè)經(jīng)驗(yàn)本質(zhì)上是把控制論里的“局部感知、全局涌現(xiàn)”思想用在了軟件工程上。4.2 別把React模式跟前端框架搞混一個(gè)能思考也能行動(dòng)的Agent核心循環(huán)“基于React模式構(gòu)建能思考與行動(dòng)的AI智能體”這條熱詞里的React跟前端那個(gè)React不是一回事它是Reason Act的縮寫指的是智能體把推理過程顯式地輸出出來再根據(jù)推理結(jié)果選擇行動(dòng)。很多新手在這個(gè)地方會(huì)被名字帶偏。React模式的核心循環(huán)只有四步Observe觀察當(dāng)前狀態(tài)、Thought思考該怎么做、Action調(diào)用工具或繼續(xù)推理、Result觀察工具返回結(jié)果。這個(gè)循環(huán)會(huì)一直持續(xù)到Agent得出結(jié)論或者達(dá)到最大步數(shù)。下面是一個(gè)非常精簡(jiǎn)的偽代碼你在Python里就能直接跑起來def react_loop(query, tools, max_steps5): messages [system_prompt, user(query)] for _ in range(max_steps): response llm(messages, stop[ACTION, /ACTION]) thought extract(response, thought) action extract_action(response) if action[type] finish: return extract_answer(response) tool_result call_tool(action[name], action[args], tools) messages.append(system(f工具返回結(jié)果: {tool_result})) messages.append(system(f觀察: 根據(jù)返回結(jié)果繼續(xù)推進(jìn)任務(wù)若達(dá)成目標(biāo)則輸出最終答案)) return reach_max_steps注意到幾個(gè)工程細(xì)節(jié)第一思考結(jié)果和行動(dòng)命令要用特殊的標(biāo)記包裹方便解析第二工具返回結(jié)果要以“觀察”的身份放進(jìn)上下文而不是以“用戶”的身份不然模型會(huì)誤以為那是用戶在說話第三必須設(shè)置最大步數(shù)否則一個(gè)執(zhí)拗的模型會(huì)在一個(gè)死循環(huán)里燒掉你所有的token。React模式是我認(rèn)為最適合作為智能體入門骨架的模式因?yàn)樗该?、可控、容易調(diào)試。很多生產(chǎn)級(jí)框架包括LangGraph、AgentScope里的核心執(zhí)行邏輯本質(zhì)上都是React循環(huán)的變體。4.3 平臺(tái)智能體與Python原生智能體怎么選才不后悔“利用平臺(tái)構(gòu)建的智能體與用Python構(gòu)建的智能體有什么不一樣”——這個(gè)問題幾乎每次分享都會(huì)被問到也是我經(jīng)常被拉去幫忙評(píng)估的一個(gè)技術(shù)選型問題。這里說的平臺(tái)主要是Coze、Dify這類低代碼Agent平臺(tái)Python原生則是用LangChain、AgentScope、AutoGen這類框架自己寫代碼。我的實(shí)踐結(jié)論很直接如果你的目標(biāo)是快速驗(yàn)證一個(gè)想法、兩三天內(nèi)做一個(gè)MVP給業(yè)務(wù)方看看平臺(tái)智能體幾乎是唯一解。Coze這類平臺(tái)把工具接入、知識(shí)庫、工作流編排都做成可視化的你不需要關(guān)心環(huán)境部署、模型API密鑰、向量庫連接這些事。但如果你想把它做成一個(gè)長(zhǎng)期演進(jìn)的商業(yè)系統(tǒng)特別是要做復(fù)雜權(quán)限控制、自定義評(píng)測(cè)、私有化部署的時(shí)候平臺(tái)的天花板會(huì)很快出現(xiàn)。為了讓你更好決策我列一個(gè)對(duì)比維度平臺(tái)智能體Coze/Dify類Python原生智能體框架類上手速度小時(shí)級(jí)天到周級(jí)可視化編排強(qiáng)弱靠代碼調(diào)試能力一般黑盒多強(qiáng)可單步調(diào)試權(quán)限與安全控制受平臺(tái)限制自由實(shí)現(xiàn)私有化部署受限完全可控長(zhǎng)流程復(fù)雜任務(wù)工作流編排上限明顯幾乎無上限學(xué)習(xí)成本低中高另外一個(gè)容易被忽略的點(diǎn)是成本。平臺(tái)智能體通常按調(diào)用量計(jì)費(fèi)而Python原生方案可以靈活選擇模型、控制Prompt長(zhǎng)度長(zhǎng)跑下來成本差距非常明顯。我見過不少項(xiàng)目前期用平臺(tái)搭了原型后期流量上來之后全部重寫為代碼原生架構(gòu)。所以我的建議是驗(yàn)證用平臺(tái)上線用代碼。如果你同時(shí)掌握了這兩種能力你的技術(shù)棧會(huì)非常完整。4.4 流式SSE接口封裝每個(gè)Agent應(yīng)用都會(huì)踩到的坑智能體應(yīng)用幾乎都要跟流式輸出打交道。模型思考過程、工具調(diào)用進(jìn)度、最終答案如果不用流式用戶只能對(duì)著一個(gè)空白頁面等好幾秒甚至幾十秒。這里的SSEServer-Sent Events是一種基于HTTP的服務(wù)器推送技術(shù)相比WebSocket它的實(shí)現(xiàn)簡(jiǎn)單得多單向推送足夠滿足Agent輸出場(chǎng)景。封裝SSE流式接口我建議重點(diǎn)關(guān)注四個(gè)細(xì)節(jié)。第一事件格式每一行都是data: 內(nèi)容用兩個(gè)換行符分隔第二結(jié)束標(biāo)記服務(wù)端必須在流式響應(yīng)結(jié)束時(shí)發(fā)送一個(gè)[DONE]標(biāo)記否則前端永遠(yuǎn)不知道請(qǐng)求結(jié)束了第三心跳機(jī)制如果模型推理時(shí)間很長(zhǎng)流會(huì)長(zhǎng)時(shí)間沒有數(shù)據(jù)中間要定期發(fā)一個(gè)注釋行比如: ping防止網(wǎng)關(guān)斷連第四中斷處理用戶點(diǎn)擊停止按鈕時(shí)前端要主動(dòng)關(guān)閉連接后端要能響應(yīng)斷開。給你一個(gè)簡(jiǎn)化的Node.js實(shí)現(xiàn)思路// 服務(wù)端 app.get(/agent/chat, async (req, res) { res.setHeader(Content-Type, text/event-stream); res.setHeader(Cache-Control, no-cache); res.setHeader(Connection, keep-alive); const send (data) res.write(data: ${JSON.stringify(data)}\n\n); send({ type: status, value: thinking }); const interval setInterval(() res.write(: ping\n\n), 15000); req.on(close, () clearInterval(interval)); for (const chunk of await agent.run(req.query.text)) { send({ type: delta, value: chunk }); } send({ type: done }); res.end(); });前端用fetch加ReadableStream解析或者用EventSource都行。這里最大的坑是解析不完整流式數(shù)據(jù)到達(dá)的順序不保證一次一個(gè)完整JSON對(duì)象你必須在前端做一個(gè)緩沖buffer把收到的字符攢起來按\n\n切分事件。我見過太多人在這一步翻車前端一直接收一直報(bào)JSON解析錯(cuò)誤。SSE只是Agent應(yīng)用工程化里的一個(gè)小環(huán)節(jié)但它體現(xiàn)了一個(gè)重要道理Agent不只是模型和提示詞的事前后端的數(shù)據(jù)交互細(xì)節(jié)決定了一個(gè)應(yīng)用是不是真的能用。5. 企業(yè)落地場(chǎng)景盤點(diǎn)從代碼審查到RAG知識(shí)問答5.1 代碼審查智能體91.3%召回率意味著什么“華為云碼道檢視修復(fù)智能體召回率91.3%”這個(gè)數(shù)據(jù)傳開后很多人在討論。先解釋一下召回率在代碼審查場(chǎng)景里它表示代碼中真實(shí)存在的缺陷里有多少比例被智能體成功識(shí)別出來。91.3%的召回率意味著智能體找出了絕大部分問題但要注意光看召回率是不夠的還得看誤報(bào)率——如果它把所有正常代碼都報(bào)成有缺陷召回率再高也沒有實(shí)用價(jià)值。代碼審查智能體目前常用的技術(shù)路線是混合架構(gòu)先用靜態(tài)掃描工具做第一遍粗篩再用大模型分析可疑代碼塊生成精確的缺陷描述和修復(fù)建議。優(yōu)點(diǎn)是把靜態(tài)工具的快與語言模型的懂上下文結(jié)合起來。部署時(shí)一般跑在CI流水線里提交代碼后自動(dòng)觸發(fā)掃描把缺陷報(bào)告回填到代碼評(píng)審系統(tǒng)。我在實(shí)操中的一個(gè)體會(huì)是這類智能體最有價(jià)值的產(chǎn)出不是“找出Bug”而是“給出可執(zhí)行的修復(fù)建議”。同樣一個(gè)缺陷只報(bào)“這里有空指針風(fēng)險(xiǎn)”和報(bào)“這里應(yīng)該增加判空邏輯修復(fù)建議如下參照第45行的寫法”對(duì)開發(fā)者的價(jià)值差了十萬八千里。所以做這類Agent評(píng)測(cè)指標(biāo)除了檢出率一定要加一條“修復(fù)采納率”。5.2 RAG智能體開發(fā)MaxKB和檢索增強(qiáng)的工程化RAG智能體是這兩年落地最廣泛的智能體形態(tài)。它解決的核心問題是大模型不知道你公司的內(nèi)部文檔但是你可以把文檔切碎、向量化、存進(jìn)向量庫讓模型回答問題時(shí)先檢索相關(guān)切片再基于切片生成答案。MaxKB這類開源項(xiàng)目就是專門做這個(gè)的它把向量數(shù)據(jù)庫、模型接入、知識(shí)庫管理都封裝好了適合起步階段直接使用。但我想說的是RAG智能體的坑幾乎全在工程細(xì)節(jié)里。切分粒度太大會(huì)讓檢索結(jié)果不精準(zhǔn)太小又會(huì)丟失上下文語境embedding模型的選擇直接影響召回效果同一個(gè)文檔不同的embedding模型出來的召回質(zhì)量差別很大檢索結(jié)果排序時(shí)相關(guān)性分?jǐn)?shù)高的切片不一定就是回答問題的關(guān)鍵信息往往需要重排序Rerank模型再過濾一遍。我建議你按這個(gè)優(yōu)先級(jí)來排查RAG效果問題先看召回把查詢問題打印出來看看向量檢索是不是召回了相關(guān)的切片再看重排序是不是把重要的切片排到了前面最后看生成是不是把檢索到的信息正確整合進(jìn)了Prompt。每一步都有對(duì)應(yīng)的可視化調(diào)試工具很多RAG項(xiàng)目效果不佳根本原因其實(shí)只是某個(gè)切片處理環(huán)節(jié)的參數(shù)沒調(diào)好。5.3 智能體面試常問的底層能力這個(gè)方向已經(jīng)職業(yè)化了看到“智能體面試”成為熱搜詞我其實(shí)挺感慨的。當(dāng)一個(gè)方向開始出面試題說明它已經(jīng)從論文里的概念變成了一個(gè)職業(yè)方向?？偨Y(jié)一下現(xiàn)在智能體相關(guān)的面試題目基本都在考四類能力。第一類是概念理解ReAct模式和Plan-and-Execute模式的區(qū)別是什么、什么是工具調(diào)用、什么是記憶、什么是RAG、Prompt注入怎么防御。第二類是動(dòng)手能力現(xiàn)場(chǎng)要求用一個(gè)框架搭一個(gè)能搜索文件并總結(jié)摘要的Agent或者讓你手寫一個(gè)React循環(huán)。第三類是工程經(jīng)驗(yàn)流式輸出怎么處理、多智能體怎么通信、上下文窗口滿了怎么辦、怎么給智能體做行為審計(jì)。第四類是安全設(shè)計(jì)給你一個(gè)Agent系統(tǒng)指出哪里有注入風(fēng)險(xiǎn)怎么加固。如果你正打算轉(zhuǎn)行做智能體開發(fā)我建議對(duì)照這四類能力做一個(gè)自測(cè)缺哪塊補(bǔ)哪塊。尤其不要只背概念一定要自己動(dòng)手跑通一個(gè)Agent踩過幾個(gè)坑之后面試?yán)锪钠饋硎峭耆灰粯拥臓顟B(tài)。最后分享一個(gè)我自己的實(shí)操體會(huì)做智能體項(xiàng)目無論論文里講得多酷炫第一優(yōu)先級(jí)一定不是“用上最新的技術(shù)”而是“定義清楚怎么評(píng)測(cè)”。先把成功標(biāo)準(zhǔn)定下來再?zèng)Q定用ReAct、Plan-and-Execute還是多智能體是訓(xùn)一個(gè)新模型還是調(diào)Prompt。我見過太多項(xiàng)目骨架都沒想清楚就堆了一堆工具和上下文最后變得又貴又慢還不可控。先跑通最小閉環(huán)再把論文里的新方法一層層加進(jìn)去——這個(gè)順序我至今沒找到更好的替代方案。