1. 面試里被問Agent為什么“模型加接口”這個答案會翻車面到中高級崗位的時候面試官拋出“你怎么理解Agent”這個問題十個人里有八個會脫口而出不就是大模型加一套工具接口嘛模型負責(zé)思考接口負責(zé)執(zhí)行。這個回答在2023年可能還能糊弄過去放到現(xiàn)在基本等于告訴面試官“我只用過套殼產(chǎn)品沒真正搭過系統(tǒng)”。我自己面過別人也被面過很多次這個問題的分水嶺特別明顯。答“模型加接口”的人腦子里想的是一個請求進來、模型決定調(diào)哪個函數(shù)、函數(shù)返回結(jié)果、模型再總結(jié)一下流程就結(jié)束了。而真正做過Agent系統(tǒng)的人腦子里浮現(xiàn)的是一整套運行時狀態(tài)怎么存、上下文怎么裁剪、工具調(diào)用失敗了怎么回滾、多輪任務(wù)怎么保證不跑偏、成本怎么控制、怎么評估它到底有沒有變聰明。這兩者之間的差距不是知識點多少而是有沒有真正踩過坑。先把結(jié)論擺在這Agent的本質(zhì)不是“模型接口”而是一個帶目標、能感知、會決策、可記憶、能糾錯的閉環(huán)系統(tǒng)。模型只是這個系統(tǒng)里的推理內(nèi)核接口只是它的手腳真正決定一個Agent能不能干活的是中間那層調(diào)度與狀態(tài)管理。面試官問這個問題想聽的從來不是定義而是你有沒有親手處理過“模型不聽話”“工具返回垃圾”“任務(wù)跑到一半斷了”這些真實問題。這篇文章我打算把這件事徹底講透。不管你是準備面試的候選人還是剛上手做Agent項目的開發(fā)者我都會從架構(gòu)拆解、核心模塊、實操落地、常見坑排查幾個角度把“一個合格Agent到底長什么樣”講清楚。看完你至少能做到兩件事面試時能把這個問題答出層次感動手時知道每一層該寫什么代碼、留什么后手。2. 拆開看一個Agent到底由哪些部分構(gòu)成2.1 從“模型加接口”到閉環(huán)系統(tǒng)差的是哪幾層很多人對Agent的想象是一條直線用戶輸入→模型推理→調(diào)用工具→返回結(jié)果。這條線在demo里跑得通一旦任務(wù)超過三步就會崩。原因很簡單直線結(jié)構(gòu)沒有“回頭路”模型一旦在某一步判斷錯了后面全是錯的而且它自己不知道。真實的Agent是一個帶反饋的環(huán)。我習(xí)慣把它拆成五層來看從下往上分別是模型推理層、工具執(zhí)行層、狀態(tài)與記憶層、調(diào)度控制層、評估觀測層。這五層缺一層系統(tǒng)就會在某個場景下露餡。模型推理層負責(zé)理解意圖、拆解任務(wù)、決定下一步動作它是大腦。工具執(zhí)行層是手腳負責(zé)真正去查數(shù)據(jù)庫、發(fā)請求、讀寫文件。狀態(tài)與記憶層是海馬體短期記住這輪對話干了什么長期記住用戶偏好和歷史結(jié)論。調(diào)度控制層是前額葉負責(zé)決定“現(xiàn)在該讓誰干活”“這一步失敗了要不要重試”“預(yù)算還剩多少”。評估觀測層則是體檢報告告訴你這個Agent最近表現(xiàn)是變好了還是變差了?！澳Ｐ图咏涌凇敝桓采w了前兩層后面三層全空著。這就是為什么很多人的Agent只能做單輪問答一旦讓它完成“幫我調(diào)研三家公司然后寫份對比報告”這種多步任務(wù)它就開始胡言亂語或者無限循環(huán)。2.2 為什么調(diào)度控制層才是真正的分水嶺如果只能挑一層重點講我一定選調(diào)度控制層。這一層決定了Agent是“聰明的工具”還是“會干活的助手”。調(diào)度控制層要解決的核心問題是在有限的步數(shù)和預(yù)算內(nèi)怎么讓模型做出高質(zhì)量的決策。這里面包含幾個具體機制。第一個是任務(wù)分解把一個大目標拆成可執(zhí)行的子步驟并且維護一個待辦清單做完一步劃掉一步。第二個是循環(huán)控制設(shè)定最大步數(shù)上限防止模型陷入“我再想想”的死循環(huán)。第三個是失敗重試與降級工具調(diào)用超時了是重試、換工具還是直接告訴用戶失敗這需要策略。第四個是預(yù)算管理token消耗、調(diào)用次數(shù)、時間成本都要有上限。我見過太多項目模型能力很強工具也很全但就是不好用問題幾乎都出在調(diào)度層。比如沒有步數(shù)上限模型遇到模糊任務(wù)就一直調(diào)工具燒掉幾萬token還沒結(jié)論比如沒有失敗處理一個接口掛了整個任務(wù)就卡死比如沒有待辦清單模型做到第三步就忘了第一步的目標是什么。面試時如果能把調(diào)度層講清楚基本就能和“只會調(diào)API”的候選人拉開差距。你可以說我的Agent里有一個顯式的任務(wù)狀態(tài)機每一步都有明確的輸入輸出和終止條件模型只負責(zé)在當(dāng)前步驟內(nèi)做決策不負責(zé)全局流程控制。2.3 記憶不是把歷史對話全塞進去關(guān)于記憶層新手最容易犯的錯就是把所有歷史消息原封不動拼進上下文。這么做有兩個后果token爆炸以及模型被無關(guān)信息干擾。記憶要分層。短期記憶是當(dāng)前任務(wù)的執(zhí)行軌跡比如已經(jīng)調(diào)了哪些工具、拿到了什么中間結(jié)果這部分需要完整保留但要及時壓縮。長期記憶是跨會話的知識比如用戶是誰、偏好什么風(fēng)格、之前做過什么項目這部分要結(jié)構(gòu)化存儲用的時候按需檢索。工作記憶是當(dāng)前這一步真正需要的信息是短期記憶經(jīng)過篩選后的子集。實操上我一般這么做短期記憶用一個列表存每一步的動作和結(jié)果超過一定長度就把早期的步驟總結(jié)成一段摘要長期記憶用向量庫或者結(jié)構(gòu)化表存檢索時用當(dāng)前任務(wù)描述去匹配最相關(guān)的幾條工作記憶在每次調(diào)用模型前動態(tài)組裝只放和當(dāng)前步驟強相關(guān)的內(nèi)容。這樣既控制了token又保證了模型不被噪音帶偏。3. 核心模塊的實操要點與避坑經(jīng)驗3.1 工具設(shè)計接口不是越多越好而是越“防呆”越好工具執(zhí)行層看起來簡單寫幾個函數(shù)注冊進去就行但這里面的坑特別多。我總結(jié)下來工具設(shè)計要遵守三個原則描述清晰、參數(shù)收斂、返回結(jié)構(gòu)化。描述清晰指的是每個工具的說明要寫清楚“什么時候用、什么時候不用”。模型判斷調(diào)哪個工具全靠這段描述。我見過有人把工具描述寫成“查詢數(shù)據(jù)”模型根本不知道查什么數(shù)據(jù)、什么場景該用。正確的寫法是“根據(jù)用戶ID查詢訂單列表適用于用戶詢問自己訂單的場景不適用于查詢他人訂單”。參數(shù)收斂指的是參數(shù)類型要簡單、必填項要少。模型對復(fù)雜嵌套參數(shù)的生成能力很弱能用一個字符串搞定的就別用對象。如果某個參數(shù)有固定取值范圍一定要在描述里列出來最好用枚舉約束。返回結(jié)構(gòu)化指的是工具返回結(jié)果要統(tǒng)一格式包含狀態(tài)碼、數(shù)據(jù)、錯誤信息。模型需要根據(jù)返回結(jié)果判斷下一步如果返回的是一坨自然語言它很難穩(wěn)定解析。我一般要求所有工具返回JSON字段固定為status、data、message三個。# 工具返回的統(tǒng)一結(jié)構(gòu)示例 { status: success, # success / error / timeout data: {...}, # 實際數(shù)據(jù) message: 查詢成功共返回3條記錄 }避坑經(jīng)驗工具數(shù)量控制在10個以內(nèi)超過之后模型的調(diào)用準確率會明顯下降。如果業(yè)務(wù)確實需要很多工具就做分組先讓模型選組再在組內(nèi)選具體工具。3.2 上下文管理什么時候該壓縮什么時候該丟棄上下文管理是Agent能不能跑長任務(wù)的關(guān)鍵。我的經(jīng)驗是分三步走先標記、再壓縮、后丟棄。每一步執(zhí)行完給這條記錄打上重要性標記。比如工具返回的關(guān)鍵數(shù)據(jù)標記為高模型的中間思考標記為中寒暄和確認標記為低。當(dāng)上下文接近閾值時優(yōu)先壓縮低重要性的內(nèi)容把它們總結(jié)成一句話如果還不夠就丟棄最早的已完成步驟只保留結(jié)論。這里有個細節(jié)很多人忽略壓縮不是簡單截斷而是重新生成。把一段執(zhí)行軌跡交給模型讓它用一兩句話總結(jié)“這一步做了什么、得到了什么結(jié)論”然后替換掉原始記錄。這樣既省token又保留了語義。我實測下來一個任務(wù)如果原始軌跡需要8000token經(jīng)過兩輪壓縮后能控制在3000以內(nèi)而且模型對任務(wù)目標的記憶反而更清晰因為噪音被去掉了。3.3 循環(huán)控制怎么讓Agent知道“該停了”Agent停不下來是新手最常見的翻車現(xiàn)場。模型會一直覺得“信息還不夠”然后無限調(diào)工具。解決辦法是在調(diào)度層設(shè)三道閘。第一道是最大步數(shù)比如15步到了就強制進入總結(jié)階段。第二道是重復(fù)檢測如果連續(xù)兩步調(diào)用了同一個工具且參數(shù)相同直接判定為循環(huán)中斷并報錯。第三道是目標達成判斷每步結(jié)束后讓模型自檢“當(dāng)前信息是否足以回答用戶問題”如果是就提前結(jié)束。這三道閘要配合使用。只有最大步數(shù)模型可能在最后幾步才開始有效工作只有重復(fù)檢測模型可能換個參數(shù)繼續(xù)繞只有目標判斷模型可能過于樂觀提前收工。三個一起上才能既保證效率又保證質(zhì)量。4. 從零搭一個能干活A(yù)gent的完整流程4.1 第一步把任務(wù)類型分清楚別用一套架構(gòu)打天下動手之前先分類。Agent要處理的任務(wù)大致分三種問答型、執(zhí)行型、創(chuàng)作型。問答型是用戶問、Agent查資料回答重點在檢索準確執(zhí)行型是用戶下指令、Agent操作工具完成重點在流程穩(wěn)定創(chuàng)作型是用戶給主題、Agent產(chǎn)出內(nèi)容重點在質(zhì)量把控。這三種任務(wù)的架構(gòu)側(cè)重完全不同。問答型可以輕調(diào)度、重檢索執(zhí)行型必須重調(diào)度、強狀態(tài)創(chuàng)作型要重評估、多輪打磨。我見過有人拿執(zhí)行型的重架構(gòu)去做問答結(jié)果響應(yīng)慢得要命也見過拿問答型的輕架構(gòu)去做執(zhí)行任務(wù)跑一半就崩。分類之后再決定你的Agent需要哪些模塊。問答型可能只需要模型加檢索工具加簡單記憶執(zhí)行型必須五層齊全創(chuàng)作型要在評估層下功夫加人工反饋或者自動評分。4.2 第二步定義狀態(tài)結(jié)構(gòu)這是整個系統(tǒng)的骨架狀態(tài)結(jié)構(gòu)決定了Agent能記住什么、能恢復(fù)什么。我一般用一個字典來存包含這些字段任務(wù)ID、用戶輸入、待辦清單、已完成步驟、當(dāng)前步驟、中間結(jié)果、預(yù)算余額、錯誤記錄。state { task_id: task_001, user_input: 幫我對比三款筆記軟件的功能和價格, todo_list: [確定對比維度, 收集三款軟件信息, 整理對比表, 生成結(jié)論], completed_steps: [], current_step: 確定對比維度, intermediate_results: {}, budget: {max_steps: 15, used_steps: 0, max_tokens: 50000, used_tokens: 0}, errors: [] }這個結(jié)構(gòu)的好處是任何一步崩潰了都能從狀態(tài)里恢復(fù)不用從頭再來。而且待辦清單是顯式的模型每步都能看到自己走到哪了不容易跑偏。實操心得狀態(tài)一定要持久化不能只放內(nèi)存。我一般用Redis或者SQLite存每步結(jié)束寫一次。這樣即使服務(wù)重啟任務(wù)也能接著跑。4.3 第三步寫調(diào)度循環(huán)這是Agent的心臟調(diào)度循環(huán)是整個系統(tǒng)最核心的代碼邏輯不復(fù)雜但細節(jié)很多?；玖鞒淌亲x狀態(tài)→組裝上下文→調(diào)模型→解析動作→執(zhí)行動作→更新狀態(tài)→判斷是否結(jié)束。def run_agent(state): while state[budget][used_steps] state[budget][max_steps]: # 1. 組裝當(dāng)前上下文 context build_context(state) # 2. 調(diào)用模型獲取下一步動作 action call_model(context) # 3. 解析動作類型 if action[type] tool_call: result execute_tool(action[tool], action[params]) state[intermediate_results][action[tool]] result elif action[type] final_answer: return action[content] # 4. 更新狀態(tài) state[completed_steps].append(state[current_step]) state[budget][used_steps] 1 # 5. 檢查是否完成 if check_completion(state): break # 超出步數(shù)強制總結(jié) return force_summarize(state)這段代碼里最關(guān)鍵的是build_context和check_completion兩個函數(shù)。前者決定模型看到什么后者決定什么時候停。這兩個函數(shù)的質(zhì)量直接決定Agent的表現(xiàn)。4.4 第四步加評估不然你不知道它到底行不行沒有評估的Agent就是盲盒。我一般從三個維度評任務(wù)完成率、步驟效率、輸出質(zhì)量。任務(wù)完成率看的是給定一批測試任務(wù)Agent能正確完成多少。步驟效率看的是平均用了幾步、燒了多少token。輸出質(zhì)量需要人工或者用另一個模型來打分。實操上我會準備一個測試集包含20到50個典型任務(wù)每次改動后跑一遍記錄三個指標的變化。如果完成率掉了說明改動有問題如果完成率沒變但步驟變多了說明效率下降如果都變好但質(zhì)量掉了說明模型開始偷懶。避坑經(jīng)驗評估集一定要包含“邊界任務(wù)”比如信息不足的任務(wù)、工具會失敗的任務(wù)、需要多輪澄清的任務(wù)。這些才是真實場景里最容易翻車的地方。5. 常見問題與排查技巧實錄5.1 模型不調(diào)工具一直自己瞎編這是最高頻的問題。模型明明有工具可用卻選擇直接回答結(jié)果答案全是編的。原因通常是工具描述不夠有吸引力或者系統(tǒng)提示里沒有強調(diào)“必須用工具”。解決辦法有三個。第一在系統(tǒng)提示里明確寫“涉及事實性信息必須調(diào)用工具不允許憑記憶回答”。第二工具描述里加上“當(dāng)用戶詢問X時必須使用此工具”。第三在評估階段對“該調(diào)沒調(diào)”的情況做懲罰讓模型學(xué)會。我實測下來光靠提示詞能解決80%的情況剩下20%需要在調(diào)度層加硬約束如果模型輸出里包含事實性斷言但沒有工具調(diào)用記錄直接打回重做。5.2 工具調(diào)用參數(shù)總是錯模型生成的參數(shù)格式不對、字段缺失、類型錯誤這個問題的根源通常在工具定義。檢查三件事參數(shù)描述是否清晰、是否有示例、是否用了枚舉約束。我一般會在工具描述里加一個“參數(shù)示例”把正確調(diào)用格式寫出來。比如“示例{user_id: 12345, date_range: last_7_days}”。這樣模型照著抄錯誤率能降一大半。如果還錯就在調(diào)度層加參數(shù)校驗發(fā)現(xiàn)格式不對就返回錯誤信息讓模型重試重試兩次還錯就放棄并告知用戶。5.3 任務(wù)跑一半就忘了目標多步任務(wù)里模型做到后面忘了最初要干什么這是上下文管理沒做好。解決辦法是在每步的上下文里都顯式帶上原始目標和待辦清單。我習(xí)慣在系統(tǒng)提示里固定一段“你的總目標是{user_input}。當(dāng)前待辦{todo_list}。已完成{completed_steps}。”這樣無論任務(wù)多長模型每步都能看到全局。另外待辦清單要動態(tài)更新。做完一步就劃掉發(fā)現(xiàn)新子任務(wù)就加上。讓模型感覺自己在推進一個明確的清單而不是在迷霧里亂撞。5.4 成本失控一個任務(wù)燒掉幾塊錢成本問題在長任務(wù)里特別明顯?？刂瞥杀疽獜娜矫嫦率譁p少無效調(diào)用、壓縮上下文、選對模型。減少無效調(diào)用靠調(diào)度層的重復(fù)檢測和步數(shù)上限。壓縮上下文靠前面說的分層記憶和動態(tài)組裝。選對模型指的是簡單步驟用便宜模型復(fù)雜決策用強模型。比如工具參數(shù)生成可以用小模型任務(wù)分解和最終總結(jié)用大模型。我做過一個對比同樣一個調(diào)研任務(wù)全用強模型要花1.2元混合調(diào)度后降到0.4元效果幾乎沒差別。問題現(xiàn)象可能原因排查方向解決手段模型不調(diào)工具描述不清、提示沒強調(diào)檢查工具描述和系統(tǒng)提示加必調(diào)約束、加示例參數(shù)總是錯定義模糊、缺示例檢查參數(shù)描述加枚舉、加示例、加校驗忘記目標上下文沒帶全局信息檢查每步上下文組裝固定注入目標和待辦成本失控?zé)o效調(diào)用多、上下文太長看調(diào)用日志和token統(tǒng)計加重復(fù)檢測、壓縮上下文、混合模型無限循環(huán)沒有步數(shù)上限和重復(fù)檢測看是否連續(xù)調(diào)同一工具加最大步數(shù)、加重復(fù)檢測6. 面試怎么答才能讓面試官眼前一亮回到最初的問題。面試官問“你怎么理解Agent”你可以這么組織回答。先給結(jié)論Agent是一個以目標為導(dǎo)向的閉環(huán)系統(tǒng)模型是推理內(nèi)核但真正決定它能不能干活的是調(diào)度、狀態(tài)和評估這三層。然后展開講調(diào)度層怎么做任務(wù)分解和循環(huán)控制狀態(tài)層怎么做分層記憶和持久化評估層怎么做完成率和效率的度量。最后補一句你踩過的坑比如“我遇到過模型無限調(diào)工具的情況后來加了重復(fù)檢測和步數(shù)上限才解決”。這個回答的層次感在于你先跳出了“模型加接口”的框架展示了系統(tǒng)思維然后用具體機制證明你真的做過最后用踩坑經(jīng)歷證明你不是紙上談兵。面試官聽到這里基本就能判斷你是實戰(zhàn)派。一個加分細節(jié)主動提“我會把Agent的狀態(tài)持久化支持斷點恢復(fù)”。這句話暗示你考慮過生產(chǎn)環(huán)境的穩(wěn)定性比只會在notebook里跑demo的人高一個段位。7. 我踩過的幾個印象深刻的坑說幾個我實際項目里翻過的車都是文檔里不會寫的。第一個坑是工具返回太長。有個查詢工具返回了幾萬字的原始數(shù)據(jù)模型直接懵了后面幾步全在胡言亂語。后來我在工具層加了截斷和摘要只返回關(guān)鍵字段問題就解決了。教訓(xùn)是工具返回的數(shù)據(jù)量要控制模型不是數(shù)據(jù)庫塞太多它處理不了。第二個坑是并行工具調(diào)用。我一度讓模型同時調(diào)多個工具提高效率結(jié)果模型把幾個工具的結(jié)果搞混了張冠李戴。后來改成串行雖然慢一點但準確率上來了。教訓(xùn)是并行適合獨立任務(wù)有依賴關(guān)系的步驟必須串行。第三個坑是評估集太干凈。我一開始用精心設(shè)計的測試任務(wù)完成率95%上線后真實用戶一用完成率掉到60%。原因是真實輸入充滿錯別字、歧義和跳躍。后來我把評估集換成真實日志里的臟數(shù)據(jù)才暴露出真正的問題。教訓(xùn)是評估數(shù)據(jù)要臟要接近真實分布。這幾個坑的共同點是它們都不在“模型加接口”的討論范圍內(nèi)但每一個都能讓Agent從能用變成不能用。這也是為什么面試官想聽的不是定義而是你有沒有真正把系統(tǒng)跑起來過。8. 后續(xù)可以繼續(xù)深挖的方向Agent這個領(lǐng)域變化很快但底層的東西是穩(wěn)定的。如果你已經(jīng)把基礎(chǔ)閉環(huán)搭起來了接下來可以往幾個方向深挖。一個是多Agent協(xié)作讓多個專精不同能力的Agent配合完成復(fù)雜任務(wù)。這里面要解決通信協(xié)議、任務(wù)分配、沖突消解的問題比單Agent復(fù)雜一個量級。另一個是自適應(yīng)調(diào)度讓系統(tǒng)根據(jù)任務(wù)難度自動調(diào)整步數(shù)預(yù)算和模型選擇。簡單任務(wù)用輕量流程復(fù)雜任務(wù)自動升級到重流程。還有一個是在線學(xué)習(xí)把每次任務(wù)的執(zhí)行結(jié)果反饋回系統(tǒng)讓調(diào)度策略和提示詞持續(xù)優(yōu)化。這個方向工程量大但效果上限高。不管往哪個方向走核心都是那五層架構(gòu)。把基礎(chǔ)打牢上層怎么變都不慌。面試也好做項目也好真正拉開差距的從來不是知道多少名詞而是有沒有把系統(tǒng)跑通、把坑踩遍。