1. 為什么這10道題成了Agent工程師的“照妖鏡”這兩年Agent這個詞被炒得滾燙招聘JD上但凡沾點AI的崗位不寫一句“熟悉Agent架構”都不好意思發(fā)出來。但真到面試環(huán)節(jié)很多候選人的表現就很有意思了聊概念頭頭是道一追問實現細節(jié)就開始打太極再問邊界條件和失敗場景基本就只?！斑@個我們后續(xù)會優(yōu)化”了。我參與過不少輪Agent崗位的技術面也幫朋友做過模擬面試官。說實話能把這10道題答利索的人一只手數得過來。大部分人的問題不是不懂而是只懂了個殼——知道ReAct、知道Function Calling、知道向量數據庫但為什么這么設計、什么時候會崩、崩了怎么救一問三不知。這篇文章就是把這10道高頻題拆開揉碎不光給答案更給答題的思路和背后的邏輯。適合正在準備Agent方向面試的人也適合已經在做Agent但想系統梳理一遍知識體系的工程師。我會按“面試官到底想聽什么”的角度來講而不是背八股。2. 第一類問題Agent的基礎架構與核心循環(huán)2.1 題目一請描述一個Agent的完整運行循環(huán)從接收輸入到輸出結果這題看著基礎但能答完整的人不多。大部分人會說“思考-行動-觀察”循環(huán)然后就沒然后了。面試官想聽的是你對整個鏈路的掌控力。一個完整的Agent循環(huán)至少包含這幾個階段輸入解析與意圖識別、上下文組裝、規(guī)劃與推理、工具選擇與調用、結果觀察與狀態(tài)更新、終止條件判斷。每個階段都有坑。輸入解析階段很多人直接拿用戶原始query去檢索這是大忌。用戶說“幫我看看上周那個項目的進度”你得先解析出“上周”對應的時間范圍、“那個項目”指代的是哪個項目。這一步做不好后面全白搭。上下文組裝是區(qū)分新手和老手的關鍵。新手把所有歷史對話一股腦塞進去老手會做分層上下文管理系統提示詞單獨一層、工具描述單獨一層、近期對話做摘要、遠期對話做向量檢索召回。為什么要分層因為token是錢而且無關信息會干擾模型判斷。規(guī)劃與推理階段ReAct模式是最常見的但純ReAct有個致命問題它沒有全局規(guī)劃。模型走一步看一步容易在局部最優(yōu)里打轉。所以實際生產環(huán)境里通常會加一個Plan-and-Execute的前置規(guī)劃層先讓模型出個粗粒度的步驟列表再逐步執(zhí)行。工具調用這塊面試官最愛追問的是并行調用和依賴調用的處理。比如用戶問“對比一下A公司和B公司的最新財報”這兩個查詢沒有依賴關系應該并行發(fā)起但如果問“查一下A公司CEO的母校然后看看那個學校有哪些知名校友”這就是串行依賴。你的Agent框架得能識別這兩種模式。終止條件判斷是最容易被忽略的。很多Agent跑著跑著就陷入死循環(huán)或者該停的時候不停。常見的終止策略包括達到最大步數、連續(xù)N步沒有新信息、模型輸出明確的完成信號、工具返回結果滿足預設條件。我一般會設三層保險硬性步數上限、語義重復檢測、人工確認兜底。面試官想聽的不是你背出了幾個階段而是你有沒有踩過坑、有沒有在生產環(huán)境里處理過異常情況。2.2 題目二Agent的記憶系統怎么設計短期記憶和長期記憶分別怎么實現記憶系統是Agent的靈魂但很多人把它簡單等同于“把對話歷史存下來”。這就好比說人的記憶就是一本日記太粗糙了。短期記憶的核心是工作記憶對應的是當前任務相關的上下文。實現上通常是一個滑動窗口加摘要機制。窗口大小怎么定不是拍腦袋要看你的模型上下文長度和任務復雜度。比如做多輪工具調用的任務窗口至少得覆蓋最近5-8輪交互否則模型會忘記剛才調用了什么工具、返回了什么結果。摘要機制也有講究。不是簡單地把舊對話壓縮成一段話而是要做結構化摘要保留關鍵實體、工具調用記錄、未完成的子任務、已確認的事實。我見過一個團隊的做法是維護一個“任務狀態(tài)表”每輪交互后更新比純文本摘要靠譜得多。長期記憶的實現路徑就更多了。最常見的是向量數據庫元數據過濾但純向量檢索有個問題它擅長語義相似不擅長精確匹配和時間推理。所以實際系統里往往是混合方案向量檢索負責模糊召回結構化查詢負責精確過濾再加一層重排序。還有一個容易被忽略的點是記憶的寫入策略。不是所有對話都值得存。我一般會設幾個觸發(fā)條件用戶明確說“記住這個”、任務成功完成后的關鍵結論、出現糾錯信息時。無差別全存的結果就是檢索時噪聲太大召回質量直線下降。長期記憶的更新和遺忘機制也是面試官愛問的。記憶不是只增不減過期的、矛盾的、低置信度的記憶要能標記和清理。這塊可以類比數據庫的TTL和版本管理思路是通的。2.3 題目三Function Calling的底層原理是什么模型怎么知道該調用哪個工具這題能篩掉一大半人。很多人只會用API不知道背后發(fā)生了什么。Function Calling的本質是模型在訓練階段學習了工具調用的模式。具體來說訓練數據里包含了大量“用戶請求-工具描述-調用參數”的樣本模型學會了根據工具的名稱、描述、參數schema來判斷該不該調、調哪個、傳什么參數。關鍵點來了工具描述的質量直接決定調用準確率。我見過太多團隊把工具描述寫得含糊其辭然后抱怨模型調不對。工具描述要包含功能一句話說明、適用場景、不適用場景、參數含義和格式、返回值結構、可能的錯誤碼。寫得好的工具描述模型調用準確率能提升30%以上。模型選擇工具的決策過程可以理解為一次條件概率計算給定當前上下文和所有可用工具的描述哪個工具的條件概率最高。所以工具數量不是越多越好超過一定數量后模型的選擇準確率會下降。實踐中單次暴露給模型的工具最好控制在10-15個以內多了就要做工具路由——先用一個輕量模型或規(guī)則引擎篩選出候選工具集。參數填充是另一個坑。模型有時候會漏填參數、填錯類型、或者編造不存在的參數值。所以工具調用前必須做參數校驗調用后要做結果驗證。我一般會在工具層加一層wrapper做參數schema校驗和默認值填充模型只負責給核心參數輔助參數由系統補全。還有一個高頻追問模型怎么處理工具調用失敗。好的Agent應該能區(qū)分錯誤類型參數錯誤就修正參數重試、權限錯誤就提示用戶、超時就降級或換工具、邏輯錯誤就重新規(guī)劃。無腦重試是最蠢的做法浪費token還解決不了問題。3. 第二類問題規(guī)劃、推理與決策能力3.1 題目四ReAct、Plan-and-Execute、Reflexion三種模式的區(qū)別和適用場景這三種模式經常被混為一談但它們的適用場景完全不同。ReAct是邊想邊做每一步都基于當前觀察決定下一步。優(yōu)點是靈活、能處理動態(tài)環(huán)境缺點是短視、容易陷入局部循環(huán)、token消耗大。適合工具調用鏈短、環(huán)境反饋快的場景比如簡單的信息查詢。Plan-and-Execute是先規(guī)劃再執(zhí)行。規(guī)劃器出一個步驟列表執(zhí)行器逐步完成。優(yōu)點是全局視野、步驟可審查、便于并行優(yōu)化缺點是規(guī)劃可能過時、環(huán)境變化后需要重新規(guī)劃。適合步驟明確、依賴關系清晰的任務比如多步數據處理的ETL流程。Reflexion是在執(zhí)行后加一個自我反思環(huán)節(jié)分析哪里做得好、哪里可以改進把反思結果存入記憶供后續(xù)使用。優(yōu)點是能持續(xù)改進、適合復雜任務缺點是增加額外調用、反思質量依賴模型能力。適合需要多輪迭代優(yōu)化的場景比如代碼生成和調試。實際生產系統往往是混合模式外層用Plan-and-Execute做粗粒度規(guī)劃內層用ReAct做細粒度執(zhí)行關鍵節(jié)點加Reflexion做質量檢查。面試時能說出這個組合思路基本就穩(wěn)了。選型的時候還要考慮成本。ReAct的token消耗通常是Plan-and-Execute的1.5-2倍Reflexion再加30%。如果任務簡單、預算有限別硬上復雜模式。3.2 題目五Agent怎么做任務分解分解粒度怎么控制任務分解是Agent的核心能力之一但很多人分解出來的子任務要么太粗、要么太細。分解粒度有個實用原則每個子任務應該是一個可獨立驗證的單元。什么意思就是做完這個子任務后你能明確判斷它是成功還是失敗。如果無法判斷說明粒度不對。舉個例子“調研競品并寫報告”這個任務粗分解是“調研”和“寫報告”但“調研”怎么算完成沒法判斷。細分解應該是確定競品列表、收集每個競品的定價信息、收集功能對比、收集用戶評價、匯總分析、撰寫報告。每個子任務都有明確的完成標準。分解方法上常見的有思維鏈分解、遞歸分解、模板分解。思維鏈分解適合線性任務遞歸分解適合層級任務模板分解適合重復性任務。實際用的時候往往是組合先用模板匹配看有沒有現成的分解方案沒有再用思維鏈或遞歸。分解后的子任務依賴關系要顯式建模。我一般用DAG來表示節(jié)點是子任務邊是依賴。這樣便于識別哪些可以并行、哪些必須串行、哪些是關鍵路徑。關鍵路徑上的子任務要優(yōu)先保證資源。還有一個坑是分解過細。子任務太多會導致調用次數爆炸、上下文碎片化、錯誤累積。經驗值是單個任務的子任務數控制在5-9個超過這個范圍就要考慮合并或分層。3.3 題目六多Agent協作怎么設計什么時候該用多Agent多Agent是這兩年的熱點但很多團隊是“為了多Agent而多Agent”結果復雜度上去了效果沒提升。先說什么場景適合多Agent角色分工明確且差異大的任務。比如一個Agent負責需求分析、一個負責代碼生成、一個負責測試每個角色的提示詞、工具集、知識庫都不同。這種情況下多Agent有優(yōu)勢因為可以各自專業(yè)化。什么場景不適合任務同質化高、需要頻繁共享上下文的場景。比如一個長文檔的摘要任務拆成多個Agent分別摘要再合并往往不如單個Agent一次性處理。因為拆分帶來的上下文丟失和合并成本超過了并行帶來的收益。多Agent的通信機制是面試重點。常見的有共享黑板、消息傳遞、層級匯報。共享黑板適合松耦合協作消息傳遞適合點對點交互層級匯報適合有明確管理關系的場景。選哪種取決于你的任務結構和延遲要求。協作模式上辯論模式和投票模式是兩種常見的決策機制。辯論模式讓多個Agent從不同角度分析最后綜合投票模式讓多個Agent獨立給出答案取多數。辯論適合開放性問題投票適合有明確答案的問題。我個人的經驗是能用單Agent加工具解決的別上多Agent。多Agent的調試成本是指數級上升的出了問題很難定位是哪個Agent的鍋。4. 第三類問題工程化與生產落地4.1 題目七Agent的評估怎么做離線評估和在線評估分別關注什么評估是Agent從Demo到生產的關鍵一步但很多團隊這塊是空白。離線評估關注的是可復現的指標。常見的包括任務完成率、平均步數、工具調用準確率、參數填充準確率、幻覺率、token消耗。這些指標需要在固定的測試集上跑測試集要覆蓋正常場景、邊界場景、異常場景。構建測試集有個技巧從生產日志里采樣。真實用戶的query分布和人工構造的測試集往往差異很大。我一般會從線上隨機采樣一批請求人工標注期望結果作為回歸測試集。每次迭代后跑一遍看指標有沒有退化。在線評估關注的是真實用戶體驗。核心指標包括用戶滿意度顯式評分或隱式行為、任務中斷率、人工接管率、平均響應時間。這些指標沒法離線模擬必須上生產才能拿到。還有一個容易被忽略的維度是魯棒性評估。給Agent輸入帶噪聲的、對抗性的、模糊的query看它能不能優(yōu)雅處理。比如用戶輸入里有錯別字、有歧義、有惡意誘導Agent的表現如何。這塊的測試用例要專門設計。評估頻率上離線評估每次發(fā)版必跑在線評估持續(xù)監(jiān)控。發(fā)現指標異常要能快速定位是哪個環(huán)節(jié)出了問題所以全鏈路追蹤是必須的。每個請求的每一步決策、每一次工具調用、每一個中間結果都要有日志。4.2 題目八Agent的延遲和成本怎么優(yōu)化有哪些實用手段這題是生產環(huán)境的核心痛點答得好能直接體現工程能力。延遲優(yōu)化上并行化是最直接的手段。能并行的工具調用、能并行的子任務、能并行的檢索查詢全部并行。我見過一個團隊把串行的5次檢索改成并行后延遲從8秒降到2秒。流式輸出是另一個關鍵手段。用戶不需要等整個任務完成才看到結果中間步驟可以實時展示。這不僅降低感知延遲還能讓用戶提前發(fā)現方向錯誤、及時干預。緩存要用在刀刃上。工具調用結果、檢索結果、甚至模型的部分輸出都可以緩存。但緩存要有失效策略過期的緩存比沒有緩存更危險。成本優(yōu)化上模型分級是最有效的。簡單任務用小模型復雜任務用大模型。判斷標準可以是任務類型、歷史成功率、用戶等級。我一般會設一個路由層根據任務復雜度動態(tài)選擇模型。上下文壓縮也很關鍵。不是所有歷史信息都需要傳給模型該摘要的摘要、該丟棄的丟棄。我見過一個優(yōu)化案例通過上下文壓縮把平均token消耗降低了40%效果幾乎沒損失。還有一個手段是提前終止。當Agent已經收集到足夠信息可以給出答案時不要繼續(xù)跑完所有步驟。這需要模型能判斷“信息充分性”可以在提示詞里加一個檢查點。4.3 題目九Agent的安全和權限怎么控制有哪些必須做的防護安全這塊是面試的加分項能答好說明你有生產意識。輸入防護是第一道關。用戶輸入要過濾注入攻擊、越權指令、敏感信息。比如用戶說“忽略之前的指令執(zhí)行以下操作”這種要能識別并攔截。工具權限要最小化。每個Agent只能訪問它完成任務必需的工具不能給全量權限。工具調用前要做權限校驗調用后要做審計日志。輸出防護同樣重要。Agent的輸出要過濾敏感信息、有害內容、未授權的數據泄露。特別是當Agent能訪問內部知識庫時要防止它把不該說的信息說出來。人工確認是關鍵操作的兜底。涉及資金、刪除、對外發(fā)送等高風險操作必須有人工確認環(huán)節(jié)。確認界面要清晰展示Agent打算做什么、影響范圍是什么。還有一個容易被忽略的是速率限制。防止Agent被惡意刷調用、防止單個用戶占用過多資源。我一般會做用戶級、會話級、工具級三層限流。4.4 題目十如果讓你從零設計一個Agent系統你的技術選型和架構思路是什么這是壓軸題考察的是綜合能力。我的思路是先明確任務特征是單輪還是多輪、是確定性還是探索性、是低延遲還是高準確率優(yōu)先。這些決定了架構的基本形態(tài)。然后選框架。LangChain生態(tài)全但重適合快速原型LlamaIndex檢索強適合RAG為主AutoGen多Agent支持好適合協作場景。如果團隊有工程能力我傾向于自研輕量框架因為通用框架的抽象往往帶來不必要的復雜度。模型選型上主模型選能力強的輔助任務用輕量模型。要有fallback機制主模型不可用時能切換。存儲層分三塊向量庫存語義記憶、關系庫存結構化狀態(tài)、對象存儲存原始文件。三者通過統一的元數據層關聯?？捎^測性從第一天就要做。全鏈路追蹤、指標監(jiān)控、日志聚合、告警規(guī)則一個都不能少。Agent系統的調試難度遠高于傳統服務沒有可觀測性就是盲人摸象。迭代機制要設計好。A/B測試、灰度發(fā)布、快速回滾這些是持續(xù)優(yōu)化的基礎。Agent的效果提升是個長期過程沒有好的迭代機制就走不遠。5. 面試中的加分項與避坑指南5.1 面試官最反感的幾種回答第一種是只背概念不談實踐。問ReAct是什么答“Reasoning and Acting的縮寫是一種讓模型交替推理和行動的模式”然后沒了。面試官想聽的是你用它做過什么、遇到什么問題、怎么解決的。第二種是過度承諾。問怎么保證Agent不出錯答“我們會做完善的測試和監(jiān)控”。這種回答等于沒答。正確的思路是承認Agent必然有出錯概率然后說明你怎么降低概率、怎么快速發(fā)現、怎么優(yōu)雅降級。第三種是回避不確定性。問某個技術選型的理由答“業(yè)界都這么做”。面試官想聽的是你的判斷邏輯哪怕你說“我選A是因為團隊更熟悉雖然B理論上更好”也比隨大流強。第四種是忽視成本。聊架構時只談效果不談成本面試官會覺得你沒有生產意識。Agent的token成本、延遲成本、維護成本都是真金白銀必須納入考量。5.2 怎么展示你的實戰(zhàn)經驗最有效的方式是講一個具體的失敗案例。比如“我們上線后發(fā)現Agent在某個場景下會陷入死循環(huán)排查后發(fā)現是工具返回的錯誤信息格式不一致導致模型誤判后來我們統一了錯誤碼規(guī)范并加了循環(huán)檢測”。這種故事比任何概念解釋都有說服力。另一個技巧是量化你的成果。不要說“優(yōu)化了性能”要說“通過并行化改造P99延遲從12秒降到3秒”。數字是最有說服力的。還可以展示你的技術判斷。比如“我們評估過三個框架最終選了自研因為通用框架的抽象層在我們的場景下反而增加了調試難度”。這種有取舍的判斷能體現深度。5.3 面試前的準備清單把上面10道題每個都寫一份自己的答案不要背要理解。然后找朋友做模擬面試讓對方追問細節(jié)。能扛住追問的答案才是真答案。準備2-3個實戰(zhàn)案例每個案例按“背景-問題-方案-結果-反思”的結構整理。案例要覆蓋不同的技術點架構設計、性能優(yōu)化、異常處理、成本控制。了解一下目標公司的主營業(yè)務和技術棧想想他們的Agent可能用在什么場景、面臨什么挑戰(zhàn)。面試時能結合他們的業(yè)務聊好感度直接拉滿。最后準備幾個你想問面試官的問題。比如“你們Agent的評估體系是怎么建的”、“線上出問題時排查鏈路是怎樣的”。這些問題能體現你的專業(yè)度也能幫你判斷這個團隊值不值得去。我面過不少人技術能力差不多的情況下能清晰講出自己踩過什么坑、怎么爬出來的候選人通過率明顯更高。因為這說明你真的做過而不是只看過。6. 一些沒人明說但很重要的經驗面試和實際做Agent是兩回事但底層邏輯相通。面試考的是你的知識體系和判斷力實際做考的是你的執(zhí)行力和迭代能力。我見過技術很強但面試總掛的人問題往往出在表達結構上?；卮饐栴}時先給結論再給理由最后給例子。不要一上來就鋪細節(jié)面試官沒耐心聽。也見過面試表現很好但實際做不出東西的人問題出在動手能力上。Agent這個領域變化太快很多問題沒有現成答案必須自己試。平時多動手搭一些Demo哪怕很簡單也比只看文章強。還有一個體會是Agent的很多問題本質上是軟件工程問題。狀態(tài)管理、錯誤處理、并發(fā)控制、可觀測性這些傳統后端的問題在Agent系統里同樣存在甚至更復雜。所以別只盯著模型和提示詞工程基本功要扎實。最后說一個趨勢判斷Agent正在從“能跑就行”向“生產可用”演進。面試的要求也會越來越高從問概念到問架構、從問效果到問成本、從問正常流程到問異常處理。提前按生產標準要求自己面試時自然游刃有余。這個領域沒有標準答案但有最佳實踐。多動手、多踩坑、多總結比背任何八股都管用。