這兩年AI Agent相關(guān)的項目我經(jīng)手了不少有內(nèi)部效率工具也有對外交付的SaaS產(chǎn)品。幾乎每個團隊都會碰到同一個問題AI在傳統(tǒng)架構(gòu)上跑得很別扭要么是Agent能力被接口限制住要么是明明接了模型但業(yè)務(wù)毫無起色。根本原因出在架構(gòu)上——大多數(shù)系統(tǒng)是先有業(yè)務(wù)后塞AI智能體只能在一個為人類操作設(shè)計的系統(tǒng)里掙扎求存。后來agent-native這個詞在圈子里傳開我才意識到這事不是加個接口就能解決的。agent-native也就是智能體原生架構(gòu)核心思路是把AI智能體當作整個系統(tǒng)的第一公民來設(shè)計從模型選擇、工具暴露、記憶存儲到任務(wù)編排全都圍繞Agent展開。這不是換了個前端殼子而是后端邏輯、接口協(xié)議、數(shù)據(jù)流全部重塑。這篇博文會把我對agent-native的理解、架構(gòu)拆解和實操經(jīng)驗一次性講透。不管你是正在做Agent應(yīng)用開發(fā)的工程師還是想評估要不要重構(gòu)現(xiàn)有系統(tǒng)的技術(shù)負責人都值得看完。文末還整理了我在真實項目中踩過的坑和排查方法這些在官方文檔里基本看不到。1. 先搞清楚agent-native到底在解決什么問題1.1 傳統(tǒng)架構(gòu)里塞AI問題出在哪傳統(tǒng)軟件架構(gòu)骨子里是確定性系統(tǒng)。用戶點擊按鈕請求打到接口業(yè)務(wù)邏輯判斷條件返回固定結(jié)構(gòu)的數(shù)據(jù)。每一步都寫死在代碼里輸入輸出可預(yù)測出了問題能靠日志逐步還原。這種架構(gòu)追求的是可控、可測、可追溯。但AI模型是概率性系統(tǒng)。同一個問題換個問法模型的決策路徑可能就不同。當你要把一個概率性系統(tǒng)塞進確定性架構(gòu)時沖突就出現(xiàn)了業(yè)務(wù)邏輯該在哪一層做判斷模型有決策權(quán)嗎系統(tǒng)怎么容忍模糊輸入這三個問題不解決AI就永遠只能在系統(tǒng)里當翻譯——理解用戶意圖、映射成固定參數(shù)、調(diào)用寫死的接口。真正的自主規(guī)劃、工具組合、試錯糾錯能力全被架構(gòu)掐死了。我見過太多團隊的狀態(tài)后端還是那套REST接口前端套了個聊天框中間接了一個大模型來理解用戶的話然后把參數(shù)拼好去調(diào)接口。這種模式嚴格來說不叫Agent應(yīng)用只是給傳統(tǒng)系統(tǒng)加了個AI皮膚。一旦用戶提出組合型任務(wù)比如把上周華東區(qū)所有異常訂單整理成報告發(fā)給財務(wù)這套架構(gòu)就徹底卡殼——因為系統(tǒng)里沒有一個實體能夠自主完成拆解、查詢、匯總、生成、通知的完整鏈路。打個比方傳統(tǒng)方式像是你要在一個已經(jīng)建好的老房子里加裝電梯處處受限承重墻不能動、管線要避開、空間不夠改造。agent-native則是在毛坯房階段就把電梯的位置預(yù)留好了所有管道、結(jié)構(gòu)、動線都配合電梯設(shè)計。前者是改后者是原生。這就是兩者最本質(zhì)的區(qū)別。1.2 agent-native項目的五個核心特征我拆解了不少agent-native的落地項目包括我自己上手做的最終總結(jié)出五個核心特征。判斷一個系統(tǒng)是否是agent-native看這五條就夠了。**特征一模型成為運行時的決策核心而非旁路調(diào)用。**傳統(tǒng)架構(gòu)里模型在業(yè)務(wù)邏輯外邊負責翻譯任務(wù)。agent-native架構(gòu)里模型在業(yè)務(wù)邏輯中間每一步?jīng)Q策——調(diào)用哪個工具、接受還是拒絕結(jié)果、下一步做什么——都由模型根據(jù)當前上下文動態(tài)決定。代碼里沒有寫死的if-else分支只有邊界約束和校驗規(guī)則。**特征二一切能力工具化工具描述是設(shè)計資產(chǎn)。**在agent-native系統(tǒng)里任何能力——查數(shù)據(jù)庫、調(diào)外部API、發(fā)消息、算指標——都抽象成工具Tool并以統(tǒng)一的Schema暴露給模型。工具之間不直接調(diào)用全部由Agent編排。工具描述怎么寫直接決定模型會不會用這是一項需要反復打磨的設(shè)計資產(chǎn)不是順手寫的注釋。**特征三記憶分層存儲系統(tǒng)記得住也忘得掉。**推理模型本質(zhì)是無狀態(tài)的每輪對話都要重新理解上下文。agent-native架構(gòu)要求記憶顯式分層短期記憶存對話上下文長期記憶存用戶偏好和事實技能記憶存任務(wù)處理模式。每一層都有獨立的讀寫機制和生命周期而不是盲目地把所有歷史一股腦塞進提示詞。**特征四編排路徑可動態(tài)規(guī)劃而非寫死在代碼里。**傳統(tǒng)流程靠狀態(tài)機或工作流引擎驅(qū)動步驟固定。agent-native讓Agent自主規(guī)劃步驟面對同樣的任務(wù)這次可能先查庫存再算價格下次可能跳過某個環(huán)節(jié)直接出結(jié)果。開發(fā)者的職責是定義每個步驟的邊界、校驗條件和失敗處理策略而不是規(guī)定必須走哪條路。**特征五失敗可觀測、可恢復、可回歸。**Agent系統(tǒng)的故障形態(tài)比傳統(tǒng)系統(tǒng)復雜得多模型可能選錯工具、參數(shù)可能傳反、多Agent協(xié)作可能死鎖。agent-native架構(gòu)從設(shè)計初期就要求全面的trace記錄、斷點重試機制和評估集回歸否則系統(tǒng)上線后一旦出現(xiàn)詭異行為根本無從排查。這五條特征不是理論推導而是實踐倒逼出來的。如果你的項目正在往這個方向靠攏接下來的章節(jié)就是具體落地細節(jié)。2. 拆開架構(gòu)看關(guān)鍵環(huán)節(jié)模型、工具、記憶、編排2.1 模型層怎么選模型怎么配置路由agent-native系統(tǒng)里模型是整個系統(tǒng)的大腦。選錯模型后邊所有工作都白費。我的經(jīng)驗是別迷信一個模型打天下?？紤]成本和性能的平衡生產(chǎn)環(huán)境通常至少要配兩個模型一個強推理模型處理復雜任務(wù)一個快響應(yīng)模型處理簡單任務(wù)。我目前常用的配置是這樣的復雜推理任務(wù)多步驟規(guī)劃、代碼生成、長文檔分析走慢思考模型比如Claude的opus系列或GPT的高推理檔簡單任務(wù)意圖識別、文案改寫、格式轉(zhuǎn)換走快模型響應(yīng)時間一般在1秒以內(nèi)。這樣做不是因為慢模型不好而是成本和延遲在真實業(yè)務(wù)里非常敏感。一個每天處理百萬次請求的Agent系統(tǒng)全量用慢模型的成本是災(zāi)難級的。模型路由的落地方式有兩種。第一種是規(guī)則路由用關(guān)鍵詞或正則做初步分流比如用戶消息里出現(xiàn)總結(jié)分析對比就路由到強模型否則走快模型。第二種是意圖分類路由用一個小模型先對用戶消息做分類再根據(jù)分類結(jié)果決定用哪個大模型。實測下來規(guī)則路由在垂直場景里夠用且更穩(wěn)定意圖分類路由在開放場景里更靈活但多了一層調(diào)用和失敗風險。另外還有兩個細節(jié)容易被忽視。一個是溫度參數(shù)要讓Agent穩(wěn)定調(diào)用工具、按格式輸出溫度必須設(shè)低我一般設(shè)在0到0.3之間如果任務(wù)需要創(chuàng)造性比如生成文案變體可以適當調(diào)高到0.7。另一個是結(jié)構(gòu)化輸出現(xiàn)在主流模型都支持JSON Mode或結(jié)構(gòu)化輸出約束建議開啟并在代碼里對模型返回值做嚴格的Schema校驗不能信任模型一定會輸出合法的JSON。2.2 工具層Function Calling 與 MCP以及描述怎么寫工具層是agent-native架構(gòu)里最關(guān)鍵的工程細節(jié)也是新手最容易搞砸的地方。模型本身不會主動調(diào)用任何函數(shù)它只是在看到工具描述后按格式輸出一個調(diào)用指令。真正執(zhí)行調(diào)用的是你的代碼。這個機制叫Function Calling函數(shù)調(diào)用幾乎所有主流模型都支持。工具怎么暴露給模型業(yè)界目前正在形成標準——MCPModel Context Protocol模型上下文協(xié)議。你可以把MCP理解成智能體世界的USB-C接口過去每個Agent項目都要自己定義一套工具暴露和調(diào)用的協(xié)議現(xiàn)在MCP把這件事標準化了。我今年的兩個新項目都直接基于MCP協(xié)議開發(fā)好處有三點一是工具定義和調(diào)用邏輯統(tǒng)一團隊協(xié)作成本低二是社區(qū)里大量現(xiàn)成的MCP Server可以直接接入不用重復造輪子三是后期切換模型供應(yīng)商時工具層完全不用動因為MCP協(xié)議是模型無關(guān)的。但是MCP只是解決了怎么暴露工具的問題真正決定Agent會不會用工具的是工具描述的質(zhì)量。很多人在工具描述上翻車。比如查詢天氣如果description只寫到查詢天氣模型在需要查詢天氣時確實會調(diào)用但在要不要帶傘適合穿什么衣服這類需要天氣數(shù)據(jù)的場景下模型可能不知道查天氣能解決這個問題于是就開始編答案。工具描述必須遵循做什么、什么時候用、注意什么三段式。以天氣工具為例描述查詢指定城市的實時天氣數(shù)據(jù)包括溫度、濕度、風力、天氣現(xiàn)象。當用戶詢問出行建議、穿衣推薦、活動安排或需要判斷當前天氣狀況時應(yīng)優(yōu)先調(diào)用此工具。注意本工具僅支持國內(nèi)城市海外城市請使用另一個工具。工具命名也要講究。命名要動賓結(jié)構(gòu)對象比如get_weather_by_city讓人工智能一看就知道這個工具返回什么。避免過于抽象的名字比如process_data這種模型根本不知道這個工具是干什么的。參數(shù)Schema盡量少而精必填參數(shù)越少越好因為模型填參數(shù)也會有幻覺參數(shù)越多出錯概率越高。如果某個參數(shù)其實不需要就別放在Schema里。2.3 記憶層別把上下文當記憶新手做Agent最常見的問題是把所有歷史消息一股腦拼進提示詞美其名曰多輪對話記憶。一旦對話超過十輪提示詞就膨脹到幾萬token模型的注意力被稀釋早前的關(guān)鍵信息全被沖垮還伴隨著推理變慢、成本飆升。這就是沒有把上下文和記憶區(qū)分開。上下文是當前任務(wù)的工作區(qū)記憶是系統(tǒng)沉淀下來的知識。agent-native架構(gòu)里記憶必須分層。第一層是短期記憶存最近對話的工作集。落地方式一般是Redis或內(nèi)存會話存儲記錄最近N輪消息摘要。這一層的特點是最新最詳細但生命周期短對話結(jié)束即可清理。第二層是長期記憶存用戶偏好、事實知識和歷史決策。比如用戶常駐城市是上海、偏好簡潔回復、上次查詢關(guān)注過哪類指標。這一層用向量數(shù)據(jù)庫或傳統(tǒng)數(shù)據(jù)庫存儲通過相似度檢索或規(guī)則匹配在下一次任務(wù)中注入。第三層是技能記憶存怎么做任務(wù)的模式比如用戶每次都要生成日報并發(fā)送到指定群系統(tǒng)沉淀成一條技能記錄下次觸發(fā)同類任務(wù)時直接復用。技能記憶本質(zhì)上是把高頻重復的Agent行為固化成模板減少模型的重復規(guī)劃和犯錯機會。記憶的更新機制才是真正的難點。什么時候?qū)懭腴L期記憶我的做法是通過情感分析或明確的用戶反饋標記來確定重要信息比如用戶說記住我每天要喝咖啡或者在任務(wù)成功完成后把關(guān)鍵結(jié)論沉淀到長期記憶庫。同時要設(shè)置遺忘機制長期不觸發(fā)的記憶定期降級避免垃圾信息堆積影響檢索效果。有一次我在項目里漏了遺忘機制結(jié)果三個月后檢索出來的記憶全是早期低質(zhì)量數(shù)據(jù)模型的決策質(zhì)量明顯下降后來加了基于時間和頻次的降權(quán)才解決。2.4 編排層單Agent與多Agent的取舍編排層決定整個系統(tǒng)的做事邏輯。只用一個Agent處理所有任務(wù)是最簡單的架構(gòu)適合垂直場景、任務(wù)鏈路短、工具數(shù)量少于十個的系統(tǒng)。單Agent的好處是上下文連貫、模型決策空間大、實現(xiàn)成本低缺點是上下文長度受限于模型窗口復雜任務(wù)容易中途丟失消息。當任務(wù)鏈路長了以后就要考慮多Agent。多Agent有兩種常見拓撲。一種是**Manager-Worker經(jīng)理-員工模式一個Manager Agent負責拆解任務(wù)、分配子任務(wù)給多個Worker Agent、匯總結(jié)果。適合需要并行處理多個獨立子任務(wù)的場景比如同時查多個數(shù)據(jù)源并匯總對比。另一種是Peer-to-Peer對等協(xié)作**模式多個Agent通過共享黑板或消息總線自由通信適合需要高度協(xié)同的復雜任務(wù)但實現(xiàn)難度大容易出現(xiàn)死鎖。我的建議是默認先用單Agent復雜度超出承受閾值再拆多Agent。拆的觸發(fā)條件有三個一是單Agent的上下文窗口頻繁打滿二是工具數(shù)量超過十五個模型在選擇工具時明顯猶豫、調(diào)用錯誤率上升三是任務(wù)本身天然分屬于不同領(lǐng)域比如一個Agent管代碼生成一個Agent管文檔撰寫權(quán)限和模型偏好都不同。還有一個常常被忽略的點多Agent不是簡單的多幾個Agent并排跑需要為每個Agent單獨配置模型、溫度、系統(tǒng)提示詞和工具集還要定義Agent之間的通信協(xié)議。這些配置項一旦多起來調(diào)試復雜度是指數(shù)級上升的。我在做多Agent系統(tǒng)時第一件事就是給每個Agent配上獨立的trace日志標簽否則線上出了bug根本分不清是誰干的。3. 動手實操一個agent-native服務(wù)的改造流程3.1 場景與選型從查詢天氣API到Agent直接調(diào)用理論說再多不如跑一個完整例子。下面我?guī)阕咭槐檎鎸嵏脑炝鞒?。假設(shè)場景是公司內(nèi)部有個天氣服務(wù)團隊成員經(jīng)常在群里問今天上海天氣怎么樣明天北京適合穿什么。傳統(tǒng)實現(xiàn)方式是一個REST API調(diào)用方寫死URL、傳參、解析返回值。數(shù)據(jù)倒是能拿到但每個使用方都要自己寫一遍調(diào)用代碼而且這個接口只能被動響應(yīng)不會根據(jù)場景主動判斷?，F(xiàn)在改成agent-native方式所有能力封裝成Agent工具讓智能體自由調(diào)用。我選MCP作為工具暴露協(xié)議理由是生態(tài)正在向MCP收斂而且MCP對Python和TypeScript的支持都很成熟內(nèi)部服務(wù)可以直接復用。3.2 步驟一定義工具協(xié)議與描述創(chuàng)建server.py定義一個MCP Server暴露get_weather工具import json from mcp.server import Server from mcp.server.stdio import stdio_server server Server(weather-agent) server.list_tools() async def list_tools(): return [ { name: get_weather, description: ( 查詢指定城市指定日期的實時天氣數(shù)據(jù)包括溫度、濕度、風力、天氣現(xiàn)象 和出行建議。當用戶詢問出行建議、穿衣推薦、活動安排或需要判斷當天 天氣狀況時應(yīng)優(yōu)先調(diào)用此工具。僅支持國內(nèi)城市海外城市請使用另一個工具。 ), inputSchema: { type: object, properties: { city: { type: string, description: 城市名支持中文如北京、上海。 }, date: { type: string, description: 查詢?nèi)掌诟袷結(jié)YYY-MM-DD默認當天。, } }, required: [city] } } ] server.call_tool() async def call_tool(name: str, arguments: dict): if name get_weather: city arguments[city] data await fetch_weather(city, arguments.get(date)) return {content: [ {type: text, text: json.dumps(data, ensure_asciiFalse)} ]}這個文件里最核心的不是代碼邏輯而是description和inputSchema。注意看描述里寫了當用戶詢問出行建議、穿衣推薦、活動安排這種觸發(fā)場景這就是為了讓模型知道什么情況下該調(diào)用這個工具。參數(shù)Schema里只放了兩個字段其中date還不是必填這樣模型填參時的出錯面就小很多。3.3 步驟二接入Agent運行時服務(wù)端定義好了現(xiàn)在寫Agent運行時誰來消費這個工具。用官方MCP Python SDK接入流程大概是import asyncio from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params StdioServerParameters( commandpython, args[server.py] ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: await session.initialize() # 獲取工具列表 tools await session.list_tools() # 調(diào)用工具 result await session.call_tool( get_weather, {city: 上海} ) print(result) asyncio.run(main())跑通這個Demo后你再把Agent Runtime接到模型上讓模型在對話過程中自動決定是否調(diào)用工具。這時代碼里不再有寫死的調(diào)用邏輯模型收到明天北京穿什么衣服合適這個問題時會自己判斷該調(diào)get_weather并帶正確的參數(shù)。3.4 步驟三加入記憶與反饋閉環(huán)光有工具調(diào)用還不夠agent-native要求系統(tǒng)有記憶。這個例子里加的短期記憶是Redis里存最近5輪對話摘要長期記憶存用戶常駐城市和穿衣偏好技能記憶是當用戶連續(xù)三次查詢同一城市的天氣后自動生成一條技能記錄——用戶經(jīng)常關(guān)注上海天氣可主動推送天氣變化。我習慣把Agent的每次決策都記一條事件日志格式固定為JSON Line{ts: 2025-01-15T10:22:31Z, session: abc123, step: 1, type: tool_call, tool: get_weather, args: {city: 上海}, result: 晴23度} {ts: 2025-01-15T10:22:33Z, session: abc123, step: 2, type: llm_output, content: 上海今天晴23度適合穿薄外套。}這種事件日志有兩個用途一是線上出了問題能完整還原每一步?jīng)Q策鏈二是積累一段時間后可以拿這些日志來做評估集回歸驗證系統(tǒng)升級后是否還正常工作。這個習慣我從第一個Agent項目就開始堅持多次救過大命。3.5 步驟四構(gòu)建評估集做回歸Agent系統(tǒng)的測試方法和傳統(tǒng)系統(tǒng)完全不同。傳統(tǒng)系統(tǒng)你寫單元測試斷言輸入輸出Agent系統(tǒng)輸出天然有隨機性沒法硬斷言。我的做法是建一個評估集準備20到50條真實用戶提問每條標注期望動作和期望結(jié)果字段。每輪迭代后自動跑一遍評估集檢查模型是否選擇了正確工具、參數(shù)是否傳對、最終輸出是否覆蓋了關(guān)鍵信息。比如這條評估樣本輸入明天廣州適合跑步嗎 期望工具get_weather 期望參數(shù){city: 廣州, date: 明天日期} 期望輸出包含天氣現(xiàn)象、溫度、空氣質(zhì)量、是否適合戶外運動用腳本跑完后人工復核統(tǒng)計通過率。我的經(jīng)驗是通過率低于85%的系統(tǒng)不要上生產(chǎn)。一套好用的評估集能讓你在改prompt、換模型、調(diào)整工具描述時快速知道改動是變好了還是變壞了避免上線后才暴雷。4. 踩過的坑Agent項目的常見故障與排查技巧4.1 模型反復調(diào)用同一個錯誤工具這是我見過最多的問題。表現(xiàn)是模型面對一個本該用A工具的任務(wù)非要去調(diào)B工具甚至連續(xù)多輪都調(diào)錯。根因通常不是模型笨而是工具描述和真實業(yè)務(wù)場景不匹配。排查路徑是先看工具列表里目標工具的description是否把觸發(fā)場景寫清楚了再看被誤調(diào)的那個工具description是否過于寬泛導致模型誤以為它能解決所有問題。我排查過一個真實案例團隊有個工具get_user_infodescription寫了獲取用戶信息結(jié)果模型在處理查詢用戶信用分時每次都調(diào)它——因為這個工具名稱對模型太有吸引力了而真正的get_credit_score工具描述沒寫好觸發(fā)場景。修復方式是把信用分工具的描述改成當用戶詢問額度、信用、借款資質(zhì)等金融相關(guān)問題時必須調(diào)用此工具獲取信用評估數(shù)據(jù)并給get_user_info加了一條約束本工具僅用于查詢用戶基本注冊信息不包含信用數(shù)據(jù)問題立刻消失。4.2 Agent進入死循環(huán)、請求超時Agent死循環(huán)是概率性故障可能一星期出現(xiàn)一次但每次都很致命。典型場景是模型自己給自己反復派活調(diào)用工具A得到結(jié)果后不滿足又調(diào)用工具BB的結(jié)果讓它覺得還要再調(diào)A陷入循環(huán)直到超時。最直接的防護是給Agent運行時加最大輪數(shù)限制和總耗時上限。我在代碼里通常設(shè)為最多15輪工具調(diào)用、單任務(wù)總耗時90秒超了就強制終止并返回處理超時請簡化請求或重試。更優(yōu)雅的解法是給模型加預(yù)算意識在系統(tǒng)提示詞里寫上你最多只能調(diào)用X次工具請規(guī)劃好你的執(zhí)行策略。實測下來模型確實會主動合并步驟、減少無效調(diào)用。死循環(huán)日志里通常能看到連續(xù)的重復tool_call記錄寫個監(jiān)控腳本定期掃描這些特征也很有必要。4.3 上下文被沖垮Agent失憶前邊說過盲目堆歷史會導致模型失憶。但即使分了層還是會遇到上下文窗口被工具返回結(jié)果占滿的情況尤其是那些返回大JSON的工具。我的一次慘痛教訓工具返回一個超過8000token的JSON數(shù)組模型讀完直接忘了用戶最初要求只要前10條繼續(xù)處理全部數(shù)據(jù)結(jié)果性能嚴重下降。解法是工具層做輸出截斷和摘要。所有工具返回Agent的內(nèi)容都應(yīng)該經(jīng)過一層壓縮關(guān)卡返回前先只保留必要字段超長列表按分頁或摘要處理。比如該工具本來返回100條記錄在MCP服務(wù)端就做一步如果用戶沒明確要求只返回前10條總數(shù)提示。這層邏輯放在工具服務(wù)端不要讓Agent自己去取舍因為Agent沒有能力分辨哪些記錄無關(guān)。4.4 多Agent協(xié)作時的死鎖與推諉多Agent系統(tǒng)最隱蔽的問題是推諉。兩個Agent誰都不想做某件事互相把任務(wù)拋給對方日志看起來都沒錯但任務(wù)始終沒進展。我遇到過一次Manager讓Worker A處理數(shù)據(jù)清洗A返回數(shù)據(jù)格式異常請B先處理格式轉(zhuǎn)換B又返回格式?jīng)]問題A可以正常清洗就這么來回跳了8輪。這類問題要從兩個方向解決一是每個Agent的職責邊界要寫清楚系統(tǒng)提示詞里明確規(guī)定如果你收到的任務(wù)不屬于你的職責范圍直接返回無法處理嚴禁將任務(wù)轉(zhuǎn)交給其他Agent二是引入任務(wù)狀態(tài)跟蹤機制每個子任務(wù)在工作流里有一個ownerowner不能轉(zhuǎn)移只有Manager可以重新分配。有了這兩條推諉現(xiàn)象基本根除。4.5 排查工具箱最后分享一個Agent項目的排查工具箱都是實測有效的方法帶上清晰的trace標簽每個Agent、每個session、每個任務(wù)都有獨立ID日志里用統(tǒng)一格式打印模型輸入、模型輸出、工具調(diào)用參數(shù)和返回結(jié)果。沒有這個基礎(chǔ)排查下面所有問題都是抓瞎。日志key-value化不要打印查詢天氣成功結(jié)果是晴天這種自然語言日志而是打印eventtool_call|toolget_weather|args{city:上海}|oktrue。關(guān)鍵信息提取效率高一個數(shù)量級。問題回放把出問題的用戶原始輸入保存下來在測試環(huán)境重新跑一遍配合trace日志逐步還原大多問題都能復現(xiàn)。評估回歸每次修復之后把出問題的請求加入評估集防止下次調(diào)完prompt又復發(fā)。這個循環(huán)堅持下來系統(tǒng)質(zhì)量會肉眼可見地穩(wěn)定。最后說一點個人體會。agent-native不是一種可以一步到位切換的技術(shù)方案它更接近一種架構(gòu)思維方式的轉(zhuǎn)變。很多人以為引入一個Agent框架就算agent-native了真落地時才發(fā)現(xiàn)工具描述、記憶機制、排查手段這些看不見的細節(jié)才是把系統(tǒng)和AI真正粘合起來的關(guān)鍵。我自己的節(jié)奏是先在一個次要業(yè)務(wù)模塊上完整跑一遍agent-native的改造流程把上面這套工具鏈和評估集搭起來驗證穩(wěn)定性后再鋪到核心業(yè)務(wù)。別一上來就讓Agent直接操盤核心鏈路留給自己的回旋余地太少。先小步快跑把坑踩一遍再放大價值這比任何理論都實用。