1. 面試官問Agent時(shí)他真正想聽的是什么面到Agent這個(gè)話題很多候選人張嘴就是“大模型加工具調(diào)用”然后開始背Function Calling的流程。我做過幾輪技術(shù)面試的旁觀者也跟不少面試官聊過說實(shí)話這個(gè)答案一出口基本就定性了——這人只停留在調(diào)用API的層面沒真正做過Agent系統(tǒng)。面試官問Agent從來不是想聽你復(fù)述某個(gè)框架的文檔。他想知道的是你有沒有想過一個(gè)Agent系統(tǒng)里決策、記憶、執(zhí)行、反饋這四個(gè)環(huán)節(jié)是怎么咬合的模型只是其中一環(huán)接口只是執(zhí)行層的一個(gè)通道。真正區(qū)分一個(gè)人有沒有Agent實(shí)戰(zhàn)經(jīng)驗(yàn)的是他能不能說清楚“模型在什么情況下會(huì)做出錯(cuò)誤決策以及系統(tǒng)怎么兜住這個(gè)錯(cuò)誤”。這個(gè)標(biāo)題之所以扎心是因?yàn)樗林辛艘粋€(gè)普遍現(xiàn)象大量教程把Agent簡化成了“LLM Tools”的公式導(dǎo)致很多人以為會(huì)調(diào)幾個(gè)API就等于會(huì)做Agent。但實(shí)際項(xiàng)目里模型加接口連最小可用系統(tǒng)都算不上。你還需要考慮狀態(tài)管理、錯(cuò)誤恢復(fù)、上下文壓縮、工具編排、權(quán)限控制、可觀測性——這些東西沒有一個(gè)是模型或接口本身能解決的。這篇文章適合兩類人一是正在準(zhǔn)備Agent相關(guān)面試、想搞清楚面試官到底在考察什么的開發(fā)者二是已經(jīng)動(dòng)手做過Demo但總覺得系統(tǒng)“不太穩(wěn)”、想弄明白差在哪里的工程師。我會(huì)從面試考察邏輯出發(fā)拆解Agent系統(tǒng)的真實(shí)架構(gòu)補(bǔ)充大量實(shí)操中才會(huì)遇到的細(xì)節(jié)幫你把“模型加接口”這個(gè)答案升級(jí)成一套完整的工程認(rèn)知。2. 為什么“模型加接口”這個(gè)答案會(huì)被扣分2.1 這個(gè)答案暴露了哪三個(gè)認(rèn)知盲區(qū)第一個(gè)盲區(qū)是把Agent等同于一次模型調(diào)用。很多人描述Agent時(shí)腦子里想的是用戶輸入→模型判斷→調(diào)用工具→返回結(jié)果。這是一條直線但真實(shí)Agent是一個(gè)循環(huán)。它需要根據(jù)執(zhí)行結(jié)果決定下一步可能重試、可能換工具、可能放棄并請(qǐng)求人工介入。沒有循環(huán)就只是一次帶工具調(diào)用的推理。第二個(gè)盲區(qū)是忽略了狀態(tài)的存在。模型本身是無狀態(tài)的每次調(diào)用都是獨(dú)立的。但Agent需要記住之前做了什么、失敗了什么、當(dāng)前進(jìn)度在哪。這些狀態(tài)存在哪里、怎么組織、怎么在上下文窗口里壓縮是工程上的核心問題。面試官問“你的Agent怎么處理多輪任務(wù)”其實(shí)就是在問狀態(tài)管理。第三個(gè)盲區(qū)是沒有錯(cuò)誤處理的概念。接口會(huì)超時(shí)、會(huì)返回格式錯(cuò)誤、會(huì)權(quán)限不足。模型也會(huì)幻覺會(huì)調(diào)用不存在的工具會(huì)陷入死循環(huán)。一個(gè)只有“模型加接口”的系統(tǒng)遇到這些情況直接崩潰。而真實(shí)Agent必須有重試策略、降級(jí)方案、熔斷機(jī)制和人工兜底通道。面試官聽到“模型加接口”時(shí)心里的判斷是這個(gè)人沒有經(jīng)歷過Agent系統(tǒng)在生產(chǎn)環(huán)境里跑起來的痛苦不知道哪里會(huì)出問題。2.2 面試官真正在考察的能力維度從我跟一些面試官交流的經(jīng)驗(yàn)看問Agent問題時(shí)他們通常在四個(gè)維度上打分。系統(tǒng)設(shè)計(jì)能力你能不能畫出一個(gè)完整的Agent架構(gòu)圖說清楚每個(gè)模塊的職責(zé)和交互方式。這包括任務(wù)規(guī)劃、工具注冊(cè)與發(fā)現(xiàn)、上下文管理、執(zhí)行引擎、結(jié)果校驗(yàn)等。邊界意識(shí)你知不知道模型的能力邊界在哪里什么任務(wù)適合交給Agent什么任務(wù)不適合什么時(shí)候該讓模型自主決策什么時(shí)候該用規(guī)則硬編碼這種判斷力比會(huì)調(diào)API重要得多。故障處理經(jīng)驗(yàn)?zāi)阌袥]有遇到過工具調(diào)用失敗、模型輸出格式錯(cuò)誤、任務(wù)陷入循環(huán)這些情況你是怎么發(fā)現(xiàn)和解決的這些細(xì)節(jié)騙不了人做過就是做過。權(quán)衡取舍Agent系統(tǒng)里到處都是取舍。用大模型還是小模型上下文全量保留還是壓縮工具粒度粗還是細(xì)每一步選擇都有代價(jià)面試官想聽的是你為什么這么選。2.3 一個(gè)真實(shí)面試場景的拆解假設(shè)面試官問“如果讓你設(shè)計(jì)一個(gè)能自動(dòng)處理客服工單的Agent你會(huì)怎么做”答“模型加接口”的人會(huì)說用大模型理解工單內(nèi)容然后調(diào)用工單系統(tǒng)的API進(jìn)行分類和回復(fù)。這個(gè)答案的問題在于工單可能包含多個(gè)問題需要拆解分類可能涉及權(quán)限判斷回復(fù)可能需要查知識(shí)庫如果模型不確定需要轉(zhuǎn)人工工單系統(tǒng)API可能失敗需要重試處理過程中需要記錄日志供審計(jì)。這些都沒有覆蓋。而一個(gè)有經(jīng)驗(yàn)的回答會(huì)先問清楚工單來源是什么分類體系有多少類回復(fù)是自動(dòng)發(fā)送還是人工審核知識(shí)庫的更新頻率如何然后給出一個(gè)包含意圖識(shí)別、任務(wù)拆解、工具編排、置信度判斷、人工兜底、全鏈路日志的方案。兩者的差距就是“會(huì)用模型”和“會(huì)做Agent”的差距。3. 一個(gè)Agent系統(tǒng)真正需要哪些模塊3.1 任務(wù)規(guī)劃與拆解層模型加接口的第一個(gè)缺口就是沒有規(guī)劃層。用戶給一個(gè)復(fù)雜任務(wù)比如“幫我分析上個(gè)月的銷售數(shù)據(jù)并生成報(bào)告”模型直接調(diào)一個(gè)數(shù)據(jù)分析接口是搞不定的。它需要先拆解第一步獲取數(shù)據(jù)第二步清洗第三步計(jì)算指標(biāo)第四步生成圖表第五步撰寫文字。每一步的輸出是下一步的輸入中間任何一步失敗都要有應(yīng)對(duì)。規(guī)劃層的實(shí)現(xiàn)方式有好幾種。最簡單的是靜態(tài)工作流把步驟寫死在代碼里模型只負(fù)責(zé)每一步的具體執(zhí)行。這種方式穩(wěn)定但不夠靈活。進(jìn)階一點(diǎn)的是動(dòng)態(tài)規(guī)劃讓模型根據(jù)任務(wù)目標(biāo)自己生成步驟列表然后逐步執(zhí)行。這種方式靈活但容易跑偏需要加約束。我在實(shí)際項(xiàng)目里更傾向于混合模式用規(guī)則定義必須執(zhí)行的骨架步驟在骨架內(nèi)部允許模型自主決定具體操作。比如數(shù)據(jù)分析任務(wù)獲取數(shù)據(jù)和生成報(bào)告是固定步驟但中間用什么方法清洗、算哪些指標(biāo)可以讓模型根據(jù)數(shù)據(jù)特征自己判斷。這樣既保證了流程可控又保留了一定的靈活性。規(guī)劃層還有一個(gè)容易被忽略的點(diǎn)步驟的粒度。拆得太粗模型一步搞不定拆得太細(xì)調(diào)用次數(shù)爆炸成本和延遲都上去了。我的經(jīng)驗(yàn)是每個(gè)步驟應(yīng)該是一個(gè)模型能在一次調(diào)用中完成、且輸出可以被明確驗(yàn)證的單元。如果一步的輸出無法判斷對(duì)錯(cuò)說明拆得不夠細(xì)。3.2 記憶與上下文管理這是“模型加接口”答案里幾乎不會(huì)提到的部分但它是Agent能不能處理長任務(wù)的關(guān)鍵。模型的上下文窗口有限一個(gè)跑了二十步的任務(wù)歷史信息早就超了。你需要決定哪些信息保留哪些壓縮哪些丟棄。我一般把記憶分成三層。短期記憶是當(dāng)前任務(wù)的執(zhí)行軌跡包括每一步的輸入輸出和狀態(tài)通常保留最近幾輪更早的做摘要壓縮。長期記憶是跨任務(wù)的知識(shí)比如用戶偏好、常見問題的解決方案存在外部存儲(chǔ)里需要時(shí)檢索注入。工作記憶是當(dāng)前步驟直接需要的上下文比如當(dāng)前處理的文件內(nèi)容、上一步的輸出結(jié)果。上下文壓縮是個(gè)技術(shù)活。簡單截?cái)鄷?huì)丟失關(guān)鍵信息全量保留會(huì)撐爆窗口。我試過幾種方案用模型對(duì)歷史做摘要、用向量檢索只取相關(guān)片段、用結(jié)構(gòu)化格式只保留關(guān)鍵字段。實(shí)測下來結(jié)構(gòu)化摘要加關(guān)鍵字段保留效果最穩(wěn)。比如每一步只保留“步驟編號(hào)、操作類型、輸入摘要、輸出摘要、狀態(tài)”比讓模型自由發(fā)揮寫摘要要可靠得多。一個(gè)實(shí)用的技巧給上下文里的每條信息打上時(shí)間戳和優(yōu)先級(jí)標(biāo)簽。當(dāng)需要壓縮時(shí)優(yōu)先保留高優(yōu)先級(jí)和最近的信息低優(yōu)先級(jí)的舊信息直接丟棄。這個(gè)策略在長任務(wù)里能顯著降低上下文占用。3.3 工具注冊(cè)、發(fā)現(xiàn)與編排工具不是越多越好。我見過一個(gè)Agent注冊(cè)了上百個(gè)工具結(jié)果模型選擇困難經(jīng)常調(diào)錯(cuò)。工具編排的核心是讓模型在正確的時(shí)間看到正確的工具。我的做法是分組注冊(cè)。按業(yè)務(wù)領(lǐng)域把工具分成若干組每次只把當(dāng)前任務(wù)相關(guān)的組暴露給模型。比如處理訂單問題時(shí)只暴露訂單查詢、退款、物流相關(guān)的工具不暴露用戶管理、數(shù)據(jù)分析的工具。這樣模型的決策空間小了準(zhǔn)確率明顯提升。工具描述也很關(guān)鍵。很多人寫工具描述就一句話“查詢訂單”模型根本不知道什么時(shí)候該用。好的描述應(yīng)該包含這個(gè)工具做什么、什么情況下用、輸入?yún)?shù)的含義和格式、返回值的結(jié)構(gòu)、可能的錯(cuò)誤。描述越清晰模型調(diào)用越準(zhǔn)確。編排層面除了讓模型自主選擇還可以加前置校驗(yàn)和后置校驗(yàn)。前置校驗(yàn)檢查模型選的工具和參數(shù)是否合法不合法直接攔截并提示模型重新選擇。后置校驗(yàn)檢查工具返回的結(jié)果是否符合預(yù)期不符合就觸發(fā)重試或降級(jí)。這兩層校驗(yàn)?zāi)軗醯舸蟛糠值图?jí)錯(cuò)誤。3.4 執(zhí)行引擎與反饋循環(huán)執(zhí)行引擎負(fù)責(zé)實(shí)際調(diào)用工具、處理返回、決定下一步。這里最核心的是反饋循環(huán)的設(shè)計(jì)。模型調(diào)用工具后結(jié)果怎么反饋給它是原樣返回還是加工后再給我的經(jīng)驗(yàn)是反饋給模型的結(jié)果要結(jié)構(gòu)化、精簡、帶狀態(tài)標(biāo)記。比如工具返回了一大段JSON不要直接塞給模型而是提取關(guān)鍵字段加上“成功/失敗”標(biāo)記和錯(cuò)誤碼。模型看到精簡后的結(jié)果更容易做出正確判斷。反饋循環(huán)里還要處理重試和退避。工具調(diào)用失敗時(shí)不能立刻重試要有退避策略。我一般用指數(shù)退避第一次等1秒第二次2秒第三次4秒最多重試三次。如果還失敗就觸發(fā)降級(jí)方案比如換備用工具、返回緩存結(jié)果、或者轉(zhuǎn)人工。還有一個(gè)容易忽略的點(diǎn)循環(huán)檢測。模型有時(shí)候會(huì)陷入“調(diào)用工具A→失敗→重試A→失敗”的死循環(huán)。執(zhí)行引擎需要檢測這種模式比如同一個(gè)工具連續(xù)失敗三次就強(qiáng)制中斷換策略或報(bào)錯(cuò)。沒有這個(gè)機(jī)制Agent可能燒掉大量token還解決不了問題。4. 面試中如何把Agent話題答出深度4.1 用“分層架構(gòu)”替代“模型加接口”當(dāng)面試官問Agent怎么設(shè)計(jì)時(shí)不要從模型開始講從分層架構(gòu)開始講。我會(huì)這樣組織回答第一層是接入層負(fù)責(zé)接收請(qǐng)求、鑒權(quán)、限流、路由。第二層是規(guī)劃層負(fù)責(zé)任務(wù)拆解和步驟生成。第三層是執(zhí)行層負(fù)責(zé)工具調(diào)用和結(jié)果處理。第四層是記憶層負(fù)責(zé)狀態(tài)存儲(chǔ)和上下文管理。第五層是觀測層負(fù)責(zé)日志、指標(biāo)、追蹤。然后說明模型在哪一層模型主要用在規(guī)劃層和執(zhí)行層的決策點(diǎn)但它不是系統(tǒng)的全部。接口在哪一層接口是執(zhí)行層調(diào)用的通道但執(zhí)行層還包括校驗(yàn)、重試、降級(jí)等邏輯。這樣回答的好處是面試官能看到你有全局視角知道每個(gè)模塊的職責(zé)和邊界。而且這個(gè)架構(gòu)不是背出來的是你真正理解系統(tǒng)后的自然表達(dá)。4.2 主動(dòng)暴露你踩過的坑面試?yán)镒罴臃值牟皇悄阏f自己做了什么而是你說自己做錯(cuò)了什么、怎么發(fā)現(xiàn)的、怎么修的。這比任何架構(gòu)圖都有說服力。比如你可以說“我早期做的Agent沒有循環(huán)檢測結(jié)果有一次模型陷入死循環(huán)十分鐘燒掉了幾十萬token。后來我加了連續(xù)失敗計(jì)數(shù)和強(qiáng)制中斷同一個(gè)工具失敗三次就切換策略。這個(gè)教訓(xùn)讓我意識(shí)到Agent系統(tǒng)里模型不是最不可控的執(zhí)行引擎的約束才是關(guān)鍵。”或者“我一開始把工具返回的原始JSON直接給模型發(fā)現(xiàn)模型經(jīng)常解析錯(cuò)字段。后來我加了一層結(jié)果格式化只提取關(guān)鍵字段并加上狀態(tài)標(biāo)記準(zhǔn)確率提升了很多。這個(gè)細(xì)節(jié)看起來小但對(duì)系統(tǒng)穩(wěn)定性影響很大。”這種回答傳遞的信息是你真正跑過系統(tǒng)遇到過問題并且有解決問題的能力。這是“模型加接口”答案完全給不出的。4.3 展示你對(duì)成本和延遲的敏感度Agent系統(tǒng)在生產(chǎn)環(huán)境里成本和延遲是繞不開的。面試官如果問你“怎么優(yōu)化”不要只說“用更小的模型”或“加緩存”要具體。我會(huì)從三個(gè)層面回答。規(guī)劃層能靜態(tài)拆解的步驟不要?jiǎng)討B(tài)生成減少模型調(diào)用次數(shù)。執(zhí)行層簡單判斷用規(guī)則復(fù)雜判斷才用模型工具結(jié)果能緩存的緩存避免重復(fù)調(diào)用。記憶層上下文壓縮要激進(jìn)不必要的歷史信息及時(shí)丟棄減少token消耗。延遲方面并行化是最大的優(yōu)化點(diǎn)。多個(gè)獨(dú)立的工具調(diào)用可以并行執(zhí)行不用串行等待。比如同時(shí)查訂單和查物流兩個(gè)接口并行調(diào)總延遲取決于最慢的那個(gè)而不是兩者之和。這個(gè)優(yōu)化在實(shí)操中效果非常明顯。面試官如果追問“怎么衡量Agent系統(tǒng)的好壞”你可以從任務(wù)完成率、平均步驟數(shù)、工具調(diào)用準(zhǔn)確率、人工介入率、單任務(wù)成本這幾個(gè)指標(biāo)來回答。這些指標(biāo)比“準(zhǔn)確率”一個(gè)詞要專業(yè)得多。5. 從Demo到生產(chǎn)Agent系統(tǒng)落地的幾個(gè)關(guān)鍵決策5.1 模型選型不是越大越好做Demo時(shí)用最強(qiáng)的模型沒問題但上生產(chǎn)就要考慮成本和延遲。我的經(jīng)驗(yàn)是分級(jí)使用規(guī)劃層用強(qiáng)模型因?yàn)槿蝿?wù)拆解需要較強(qiáng)的推理能力執(zhí)行層的簡單判斷用小模型甚至規(guī)則結(jié)果校驗(yàn)用規(guī)則或小模型。具體怎么分我會(huì)先跑一批真實(shí)任務(wù)統(tǒng)計(jì)每個(gè)環(huán)節(jié)的模型調(diào)用次數(shù)和token消耗。然后看哪些環(huán)節(jié)的模型輸出可以被規(guī)則替代哪些環(huán)節(jié)換小模型后準(zhǔn)確率下降不明顯。通常執(zhí)行層有大量調(diào)用是“格式化輸出”或“簡單分類”這些用小模型完全夠用。還有一個(gè)決策是用通用模型還是微調(diào)模型。如果任務(wù)領(lǐng)域很垂直比如只處理特定類型的工單微調(diào)一個(gè)小模型可能比通用大模型效果更好、成本更低。但微調(diào)需要標(biāo)注數(shù)據(jù)前期投入大。我的建議是先用通用模型跑通流程積累數(shù)據(jù)后再考慮微調(diào)。5.2 工具粒度粗一點(diǎn)還是細(xì)一點(diǎn)工具粒度是個(gè)權(quán)衡。粒度粗模型調(diào)用次數(shù)少但每個(gè)工具的邏輯復(fù)雜出錯(cuò)后難定位。粒度細(xì)模型調(diào)用次數(shù)多但每個(gè)工具職責(zé)單一容易測試和維護(hù)。我傾向于中等粒度一個(gè)工具對(duì)應(yīng)一個(gè)完整的業(yè)務(wù)操作而不是一個(gè)技術(shù)步驟。比如“查詢訂單狀態(tài)”是一個(gè)工具而不是“連接數(shù)據(jù)庫”“執(zhí)行查詢”“格式化結(jié)果”三個(gè)工具。這樣模型調(diào)用次數(shù)可控每個(gè)工具也有明確的業(yè)務(wù)含義。但有些情況需要細(xì)粒度。比如一個(gè)操作需要用戶確認(rèn)才能執(zhí)行那“準(zhǔn)備操作”和“執(zhí)行操作”就要拆成兩個(gè)工具中間插入確認(rèn)環(huán)節(jié)。再比如一個(gè)操作可能失敗需要重試拆成細(xì)粒度后重試范圍更小不會(huì)重復(fù)執(zhí)行已經(jīng)成功的部分。5.3 人工兜底什么時(shí)候必須讓人介入Agent不是全自動(dòng)的至少在生產(chǎn)環(huán)境里不是。必須設(shè)計(jì)人工介入的觸發(fā)條件。我的經(jīng)驗(yàn)是三類情況必須轉(zhuǎn)人工置信度低于閾值、涉及敏感操作、連續(xù)失敗超過限制。置信度怎么來可以讓模型在輸出時(shí)附帶置信度評(píng)分也可以用規(guī)則判斷比如模型輸出格式不符合預(yù)期、工具返回了異常狀態(tài)碼。敏感操作包括退款、刪除數(shù)據(jù)、修改權(quán)限等這些操作即使模型很確定也應(yīng)該讓人確認(rèn)。人工介入的體驗(yàn)也很重要。不能只給人工一個(gè)“任務(wù)失敗”的通知要把完整的執(zhí)行軌跡、當(dāng)前狀態(tài)、失敗原因、建議操作都展示出來。人工處理完后結(jié)果要能回寫到Agent系統(tǒng)里讓Agent繼續(xù)后續(xù)步驟。這個(gè)閉環(huán)設(shè)計(jì)不好人工兜底就會(huì)變成人工重做。5.4 可觀測性出了問題怎么查Agent系統(tǒng)最怕的是出了問題不知道哪里出的。模型輸出不可解釋工具調(diào)用鏈路長沒有可觀測性根本沒法排查。我一般會(huì)記錄四類數(shù)據(jù)。調(diào)用日志每次模型調(diào)用和工具調(diào)用的輸入輸出、耗時(shí)、狀態(tài)。決策軌跡模型每一步的決策理由可以讓模型輸出思考過程。狀態(tài)快照每個(gè)步驟執(zhí)行后的系統(tǒng)狀態(tài)方便回放。指標(biāo)聚合任務(wù)完成率、平均步驟數(shù)、工具調(diào)用成功率、人工介入率等。這些數(shù)據(jù)不只是用來排查問題還能用來優(yōu)化系統(tǒng)。比如分析哪些工具調(diào)用經(jīng)常失敗哪些步驟模型經(jīng)常決策錯(cuò)誤然后針對(duì)性改進(jìn)。沒有這些數(shù)據(jù)優(yōu)化就是拍腦袋。6. 幾個(gè)容易被追問的Agent細(xì)節(jié)問題6.1 模型輸出格式不穩(wěn)定怎么辦這是高頻問題。模型有時(shí)候返回JSON有時(shí)候返回帶解釋的文字有時(shí)候字段名都對(duì)不上。我的處理方式是三層防護(hù)。第一層是提示詞約束在系統(tǒng)提示里明確輸出格式給出示例強(qiáng)調(diào)“只輸出JSON不要有其他內(nèi)容”。第二層是輸出解析器用代碼解析模型輸出如果解析失敗嘗試提取JSON片段再失敗就觸發(fā)重試。第三層是重試提示重試時(shí)把解析錯(cuò)誤的信息反饋給模型讓它修正格式。實(shí)測下來這三層能解決95%以上的格式問題。剩下的5%通常是模型能力不足或任務(wù)本身模糊這種就需要換模型或重新設(shè)計(jì)任務(wù)。6.2 工具調(diào)用參數(shù)錯(cuò)誤怎么處理模型經(jīng)常傳錯(cuò)參數(shù)比如該傳數(shù)字傳了字符串該傳枚舉傳了自由文本。處理方式和格式問題類似前置校驗(yàn)加反饋重試。前置校驗(yàn)用JSON Schema定義每個(gè)工具的參數(shù)格式模型輸出后先校驗(yàn)不通過就不執(zhí)行直接把校驗(yàn)錯(cuò)誤反饋給模型讓它重新生成。反饋時(shí)要具體比如“參數(shù)order_id應(yīng)該是字符串你傳了數(shù)字”而不是籠統(tǒng)說“參數(shù)錯(cuò)誤”。如果重試多次仍然錯(cuò)誤就要考慮是不是工具描述不夠清晰或者模型能力不夠。這時(shí)候可以簡化工具參數(shù)把復(fù)雜參數(shù)拆成多個(gè)簡單參數(shù)或者換更強(qiáng)的模型。6.3 多輪對(duì)話里Agent怎么保持一致性多輪對(duì)話里用戶可能中途改變需求或者補(bǔ)充信息。Agent需要能識(shí)別這些變化并調(diào)整執(zhí)行計(jì)劃。我的做法是每輪對(duì)話都重新評(píng)估任務(wù)狀態(tài)。具體來說每輪用戶輸入后先把當(dāng)前執(zhí)行狀態(tài)和用戶新輸入一起給模型讓模型判斷是繼續(xù)當(dāng)前任務(wù)還是修改計(jì)劃還是開始新任務(wù)。這個(gè)判斷本身也是一次模型調(diào)用但能避免Agent“一根筋”地執(zhí)行舊計(jì)劃。狀態(tài)同步也很重要。如果用戶修改了某個(gè)參數(shù)Agent需要更新狀態(tài)里的對(duì)應(yīng)字段并且檢查后續(xù)步驟是否受影響。比如用戶改了收貨地址那物流相關(guān)的步驟都要用新地址重新執(zhí)行。這種依賴關(guān)系的管理是Agent系統(tǒng)里比較復(fù)雜的部分需要仔細(xì)設(shè)計(jì)狀態(tài)結(jié)構(gòu)。6.4 Agent的測試怎么做Agent的測試比傳統(tǒng)軟件難因?yàn)檩敵霾淮_定。我的策略是分層測試。單元測試測每個(gè)工具的功能這個(gè)和普通函數(shù)測試一樣。集成測試測固定輸入下的執(zhí)行軌跡不要求最終輸出完全一致但要求關(guān)鍵步驟和工具調(diào)用符合預(yù)期。評(píng)估測試用一批真實(shí)任務(wù)跑端到端統(tǒng)計(jì)任務(wù)完成率和人工介入率這個(gè)需要人工標(biāo)注或人工評(píng)估。評(píng)估測試?yán)镂視?huì)特別關(guān)注失敗案例。分析失敗是因?yàn)槟Ｐ蜎Q策錯(cuò)誤、工具問題、還是任務(wù)本身超出能力范圍。這些分析結(jié)果直接指導(dǎo)優(yōu)化方向。沒有評(píng)估測試Agent的迭代就是盲目的。7. 我在實(shí)際項(xiàng)目里總結(jié)的幾條經(jīng)驗(yàn)做Agent系統(tǒng)這幾年踩過的坑比寫過的代碼還多。有幾條經(jīng)驗(yàn)我覺得比任何架構(gòu)圖都值錢。第一條先跑通再優(yōu)化但別在Demo階段就埋雷。很多人做Demo時(shí)圖快狀態(tài)管理用內(nèi)存、錯(cuò)誤處理直接拋異常、日志隨便打。結(jié)果要上生產(chǎn)時(shí)發(fā)現(xiàn)到處都要改。我的建議是Demo階段可以簡化但狀態(tài)存儲(chǔ)、錯(cuò)誤處理、日志記錄這三個(gè)基礎(chǔ)能力一開始就要有哪怕實(shí)現(xiàn)很簡單。后面替換實(shí)現(xiàn)比從零加要容易得多。第二條模型的輸出永遠(yuǎn)要當(dāng)作不可信輸入。不管模型多強(qiáng)它的輸出都要經(jīng)過校驗(yàn)才能使用。參數(shù)校驗(yàn)、格式校驗(yàn)、業(yè)務(wù)規(guī)則校驗(yàn)一層都不能少。我見過太多因?yàn)樾湃文Ｐ洼敵龆鴮?dǎo)致的事故比如模型生成了不存在的訂單號(hào)直接去查結(jié)果報(bào)錯(cuò)模型把金額算錯(cuò)了直接提交造成損失。校驗(yàn)的成本遠(yuǎn)低于出錯(cuò)的成本。第三條上下文管理是Agent系統(tǒng)里最容易被低估的部分。很多人把精力花在模型選型和工具開發(fā)上上下文管理隨便做做。結(jié)果任務(wù)一長就出問題要么上下文超限要么關(guān)鍵信息丟失要么模型被無關(guān)信息干擾。我的經(jīng)驗(yàn)是上下文管理要像數(shù)據(jù)庫設(shè)計(jì)一樣認(rèn)真對(duì)待定義清楚什么信息存哪里、怎么檢索、怎么壓縮、怎么過期。第四條可觀測性不是可選項(xiàng)。Agent系統(tǒng)出問題時(shí)沒有日志和追蹤根本沒法排查。我一般會(huì)在項(xiàng)目第一天就搭好日志和指標(biāo)采集哪怕只是簡單的文件日志。后面再接入更專業(yè)的觀測工具。這個(gè)投入在排查問題時(shí)回報(bào)巨大。第五條人工兜底不是失敗是設(shè)計(jì)的一部分。不要追求100%自動(dòng)化那既不現(xiàn)實(shí)也不安全。把人工介入設(shè)計(jì)成系統(tǒng)的一個(gè)正常環(huán)節(jié)而不是異常處理。這樣系統(tǒng)更穩(wěn)用戶也更放心。最后說一個(gè)面試技巧如果面試官問Agent你可以先反問一句“您是想了解Agent的架構(gòu)設(shè)計(jì)還是具體某個(gè)環(huán)節(jié)的實(shí)現(xiàn)”這樣既能展示你對(duì)Agent有全局認(rèn)知又能把問題聚焦到你最擅長的部分。面試官通常會(huì)順著你的問題走你就掌握了主動(dòng)權(quán)。這個(gè)技巧我用過幾次效果都不錯(cuò)。