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