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