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