設計自檢清單)
最近一個月我?guī)褪畮讉€準備跳槽到 AI Agent 方向的工程師做了模擬面試一個感受特別明顯簡歷上寫著“精通 Agent 開發(fā)”的人一到追問環(huán)節(jié)就撐不住了。問“你的 Agent 和大模型 API 調(diào)用有什么本質(zhì)區(qū)別”很多人愣了半天問“一個工具調(diào)用返回了兩萬 token你怎么控制成本”大部分人的第一反應是“換個大上下文模型就行”。還有個候選人簡歷里寫了三個月 Agent 開發(fā)經(jīng)驗我問了一個最基礎的問題——短期記憶和長期記憶分別存在哪里他繞了五分鐘沒講到點子上。2026 年的 AI Agent 面試已經(jīng)不是“背出 ReAct 四個字母”就能過關的年代了。面試官現(xiàn)在真正考察的是架構選型、記憶設計、工具調(diào)用規(guī)范、生產(chǎn)環(huán)境可靠性、評估體系以及系統(tǒng)設計能力。這篇文章不是面試寶典的廣告而是我結合自己做 Agent 項目、也幫團隊招人的經(jīng)驗把高頻考點拆成一張真實可用的自檢清單。就覆蓋面來說我見過的高頻題里 90% 都能在這篇文章里找到對應答案適合準備投 Agent 相關崗位的同學也適合想系統(tǒng)補一遍 Agent 知識體系的開發(fā)者邊看邊查。1. Agent 基礎認知與概念辨析——面試里的“送分題”和“送命題”1.1 本質(zhì)邊界Agent 和 Chain、Workflow、RAG 到底差在哪面試一開始通常從“定義題”切入看起來是送分題其實最能拉開差距。比如“描述一下 AI Agent 的核心組成”“Agent 和普通的大模型 API 調(diào)用有什么區(qū)別”。2026 年的語境下面試官已經(jīng)不滿足于“Agent 就是 LLM 規(guī)劃 記憶 工具”這種教科書答案而是會追問你這套系統(tǒng)里哪一部分是 Agent 在決策哪一部分是你用代碼寫死的邏輯我建議用遞進式框架來答普通 API 調(diào)用是“一次問答”程序拿到結果就結束了Chain 是“多條預設好的調(diào)用鏈”流程路徑是開發(fā)者在代碼里寫死的Workflow 比 Chain 更強調(diào)狀態(tài)流轉(zhuǎn)但依然是靜態(tài)拓撲Agent 的本質(zhì)區(qū)別在于它自己決定下一步動作。也就是說Agent 讓模型擁有了對控制流的動態(tài)決策權——工具列表擺在那里調(diào)哪個、什么時候調(diào)、結果怎么處理都由模型在運行時決定。面試官最想聽到的其實是這句話因為它決定了整個系統(tǒng)架構里誰是“大腦”。再補一個高頻追問Agent 和 RAG 的區(qū)別。RAG 本質(zhì)是外部知識注入解決“模型不知道”的問題Agent 解決“模型不會做”的問題。一個偏檢索增強一個偏行動規(guī)劃。如果對方接著問“兩者能結合嗎”答案是能而且 2026 年大部分生產(chǎn)級 Agent 都帶著 RAG 組件。典型場景是 Agent 在執(zhí)行任務前先檢索內(nèi)部知識庫里的業(yè)務規(guī)則、產(chǎn)品文檔、歷史案例再開始規(guī)劃。1.2 Token、上下文窗口與“Agent 吃什么”“AI Agent 的 token 是什么意思”是這兩年搜索量暴漲的問題面試里會直接變成“你理解 token 和上下文窗口的關系嗎”“Agent 上下文溢出怎么處理”。Token 是模型處理文本的基本單位可以粗略理解成詞語碎片。但它對 Agent 格外重要因為 Agent 的每一次決策、每一次工具調(diào)用返回值、每一輪執(zhí)行日志都要占用 token。一個實戰(zhàn)計算題假設你用 ReAct 架構模型每輪先推理再決定調(diào)工具。工具返回一個幾千 token 的 JSON即使最后只用到其中兩三個字段這些 token 也要全部進入上下文。任務需要五輪工具調(diào)用上下文輕松沖到 3 萬 token 以上成本隨之飆升。2026 年百萬級上下文窗口的模型已經(jīng)很常見但面試官考的不是“你能塞多少”而是“你會不會用”。正確的答法是分層處理。第一工具返回結果落地到外部存儲比如數(shù)據(jù)庫或 Redis上下文里只放精簡后的摘要字段第二超過閾值的舊日志做截斷或摘要壓縮而不是無腦全保留第三長任務用“子 Agent”隔離主 Agent 只關心子 Agent 返回的結果不承載全部中間過程。這套三層處理邏輯我在面試里幾乎每個候選人都問能完整講清楚三層的人不到 20%屬于典型的高區(qū)分度知識點。1.3 記憶設計短期、長期與工作記憶的存儲策略記憶題的常見問法是“你的 Agent 怎么實現(xiàn)長期記憶”。這里要分清三層概念。短期記憶就是對話窗口里的會話歷史通常存在內(nèi)存或 Redis設置過期時間長期記憶用向量數(shù)據(jù)庫存用戶偏好、業(yè)務知識、歷史決策記錄配合 embedding 做相似度召回工作記憶則存放當前任務上下文和任務執(zhí)行中的臨時狀態(tài)比如“用戶剛才決定變更需求、暫時切到另一個方案”這類狀態(tài)最容易被人忽略。面試官經(jīng)常追問“記憶里應該存什么、不存什么”。我踩過的一個坑是把所有對話原文全部塞進向量庫結果召回出來全是噪聲。正確做法是只存結構化的事實、決策依據(jù)、可復用的子任務方案至于無關的寒暄和原始調(diào)試日志不但不要存還要在進入記憶之前過濾掉。召回策略也要講清楚——時間衰減權重、相關性閾值、最近 K 條兜底這三樣組合起來比單純靠相似度檢索穩(wěn)得多。記憶失效也是高頻考點。比如多輪 Agent 會話中用戶中途改了需求模型還按照舊方案繼續(xù)執(zhí)行這就是工作記憶沒有及時更新導致的。應對方式是每次計劃變更先做“計劃作廢”或“重新規(guī)劃”把舊狀態(tài)標記為 invalid而不是讓 Agent 帶著過期狀態(tài)繼續(xù)跑。2. 主流架構與核心模式從 ReAct 到 Plan-and-Execute2.1 架構全景單智能體、多智能體、圖編排的選型邏輯這部分的面試問題通常是你用過哪些 Agent 架構。背后真正想考的是你有沒有在真實場景里做過取舍?；A中的基礎是 ReAct推理 - 行動 - 觀察循環(huán)往復適合工具調(diào)用密集、需要靈活應對環(huán)境反饋的場景缺點是 token 開銷大、過程容易跑偏。相比之下Plan-and-Execute 先規(guī)劃出一個完整任務清單再逐步執(zhí)行穩(wěn)定性更高適合目標明確、步驟相對固定的任務比如“每周生成一份競品分析報告并發(fā)送郵件”。Reflexion 模式在 2026 年面試里也開始頻繁出現(xiàn)。它的特點是在執(zhí)行失敗后讓模型自我反思、更新策略更像一個“會復盤”的 Agent。面試官如果問“你的生產(chǎn)系統(tǒng)里用哪種”正確答案不是背名詞而是說探索性強、動作路徑不固定的任務用 ReAct 變體目標清晰、要控制成本的場景用 Plan-and-Execute需要持續(xù)自我改進的長周期任務考慮加一層 Reflexion 式的反思回路。再往上就是多智能體。這里有個常見的錯誤認知認為多 Agent 一定比單 Agent 強。實際上多 Agent 的成本成倍增長協(xié)調(diào)復雜度更高而且 Agent 之間的對話不可控生產(chǎn)環(huán)境很容易變成“兩個模型在互相客套”。2026 年企業(yè)級落地的主流是多 Agent 加圖編排比如 LangGraph 那種以節(jié)點和邊定義流程的方式Planner 負責任務分解Worker 負責執(zhí)行Critic 負責驗收節(jié)點之間用顯式狀態(tài)傳遞。面試里說“多 Agent 聊天式協(xié)作很優(yōu)雅”是扣分項說“圖編排可控、可觀測、可斷點續(xù)跑”才是加分項。2.2 推理規(guī)劃與工具調(diào)用從 Function Calling 到錯誤恢復工具調(diào)用是 Agent 的“手”面試幾乎必考。Function Calling 的本質(zhì)是定義函數(shù)的 JSON Schema讓模型輸出結構化的參數(shù)再在代碼里執(zhí)行真實函數(shù)。這里的關鍵不是“會調(diào)”而是面試官追問“你的工具描述怎么寫”——工具描述直接決定模型能不能在合適的時機選到合適的工具。描述里必須寫清楚工具做什么、適用條件、不適用條件、關鍵參數(shù)含義、返回結構。寫得含糊模型就會在多個相似工具之間反復橫跳。工具調(diào)用的完整鏈路有三段工具發(fā)現(xiàn)、參數(shù)生成、結果解析。高頻追問是“工具調(diào)用失敗怎么辦”。正確答案不是單純重試而是分等級降級第一先做參數(shù)糾正把模型生成的非法參數(shù)結合實際返回信息修正后重試一次第二工具多次失敗后讓 Agent 切換到無工具模式直接用自身知識回答第三將錯誤信息結構化回傳給模型讓它學習到“這條路徑走不通”避免反復踩同一個坑。還有一個必問題怎么避免 Agent 陷入無限循環(huán)。我的答案是四件套最大迭代次數(shù)限制比如 10 輪單步驟超時比如 30 秒置信度閾值低于閾值就主動向用戶確認成功標志檢測任務完成后立刻終止循環(huán)而不是讓模型繼續(xù)“錦上添花”。這四樣任何一樣缺失生產(chǎn)環(huán)境都會出亂子。2.3 主流框架的取舍LangGraph、Dify、Coze 怎么選面試里問到“用什么框架搭建”時最忌諱只報一個名字就說“挺好用的”。2026 年的面試官希望聽到的是你做過對比甚至踩過坑。LangGraph 適合復雜圖編排和精細狀態(tài)管理節(jié)點、邊、狀態(tài)流都自己控制可移植到生產(chǎn)代碼里但學習成本偏高文檔有時候要讀半天。Dify 適合快速搭建“RAG Agent”業(yè)務應用低代碼內(nèi)置知識庫和插件市場適合做企業(yè)內(nèi)部工具但深度定制會撞到它的抽象層。Coze 適合快速做面向 C 端的機器人國內(nèi)生態(tài)上手快但可移植性一般。還有一個隱藏加分點自己手寫過輕量 Agent 框架。核心就是一個循環(huán)——觀察讀取上下文和工具結果→ 決策調(diào)用模型選擇動作→ 執(zhí)行工具 → 記錄結果 → 再觀察。代碼量大約五六十行。我組織新人培訓時堅持讓每個人先手寫一遍這個循環(huán)再上 LangGraph。因為手寫能讓你真正理解狀態(tài)從哪來、錯誤在哪一層發(fā)生面試官問“底層原理”時你才不會發(fā)虛。3. 工程化與部署簡歷上寫“會 Agent 開發(fā)”的人最容易被追問的部分3.1 RAG 與 Agent 深度結合知識庫不是萬能藥RAG 和 Agent 的組合是 2026 年生產(chǎn)級應用的事實標準。面試題往往這樣出“你的 Agent 在回答業(yè)務問題時怎么接入公司內(nèi)部知識庫”這里要講清楚的不只是“接一個向量庫就行”。分塊策略要考慮 chunk size 和重疊加多少太碎則語義斷裂太大則檢索噪聲高embedding 模型選擇要看領域文本類型法律、醫(yī)療、代碼類文檔的差異很大召回之后通常還要加一層 rerank把真正相關的段落排到前面。面試官喜歡追問“RAG 檢索不到答案怎么辦”。千萬別一上來就說“調(diào)大 top-K”——那是新手操作。正確排查順序是先看分塊大小是否合理再查 query 需不需要改寫拆解、擴展、同義替換最后檢查 rerank 有沒有把正確答案壓到后面。更進一步Agent 化 RAG 的做法是讓 Agent 動態(tài)決定檢索策略簡單問題直接檢索一次復雜問題拆分子查詢多次檢索再合并而不是每條問題都走同一個重流程。順帶提一個偏實操的問題“用 AI Agent 開發(fā) Django 這種 Web 后端”到底怎么理解。這背后其實是 Agent 的托管方式——把 Agent 跑在 Web 服務里和普通 API 服務有一個重要差異Agent 任務通常是長時間的異步流程不能用普通 HTTP 請求等一個響應。需要任務隊列、長輪詢或 SSE 推送任務狀態(tài)落庫。Django 當然可以寫 Agent 服務端但設計上要把“請求-響應”模型改成“提交任務-查詢狀態(tài)-異步通知”模型這也是后端工程師轉(zhuǎn) Agent 方向最常踩的坎。3.2 可靠性設計與 Rust 運行時Agent 上生產(chǎn)的三座大山生產(chǎn)級 Agent 之所以難不是因為模型不夠聰明而是因為三個問題外部工具不穩(wěn)定、模型偶爾“發(fā)癲”、成本不可控?？煽啃缘暮诵脑O計在面試里能直接體現(xiàn)你的工程經(jīng)驗。第一是重試加熔斷連續(xù)幾次調(diào)用失敗要讓 Agent 換路徑而不是死磕同一個工具第二是冪等設計同一個工具調(diào)用多次不能產(chǎn)生副作用比如發(fā)郵件、轉(zhuǎn)賬、扣費這類操作必須靠請求 ID 去重第三是高危操作人工審批對外發(fā)送消息、提交訂單這一類動作加入 human-in-the-loop 審核節(jié)點再放行。“基于 Rust 語言構建 AI Agent”這個熱詞2026 年在面試里出現(xiàn)的頻率明顯變高了。背后的原因不是行業(yè)內(nèi)卷而是 Agent runtime 需要高并發(fā)、低延遲地處理大量流式調(diào)用。Rust 無 GC、內(nèi)存安全、并發(fā)模型強適合做調(diào)度和網(wǎng)關層讓 Python 或 TypeScript 負責業(yè)務編排。一個典型的技術棧是Rust 寫高性能 Agent 引擎上層接 LangGraph 狀態(tài)流再上層是業(yè)務插件。面試里提到這個分層會讓面試官覺得你不只是在調(diào) API而是真的考慮過性能瓶頸。部署側Agent 服務與傳統(tǒng)服務的差異是流式響應、狀態(tài)持久化、斷線續(xù)跑。用戶的瀏覽器可能關掉但后臺任務還得繼續(xù)Agent 跑了一半網(wǎng)絡斷了重新連接后要能從斷點恢復而不是從頭再來。這些都是把任務狀態(tài)持久化到數(shù)據(jù)庫、配合消息隊列做恢復才能解決的問題。順帶一提關注一下大廠和云廠商近期發(fā)布的 Agent 白皮書里面反復強調(diào)的方向無非三個可觀測、安全、成本治理。這基本就是 2026 年企業(yè)級 Agent 面試的核心風向標。3.3 評估與可觀測性不會跑評估就別投 Agent 崗評估 Agent 比評估單個大模型復雜得多因為你不僅要看最終答案對不對還要看過程合不合理。常見指標包括任務成功率、步驟完成率、工具調(diào)用準確率、無效調(diào)用率、單任務成本。舉一個真實例子兩個 Agent 完成任務的成功率都是 90%但一個平均每次任務調(diào)用 3 次工具另一個要調(diào) 12 次成本差了三倍。如果只盯著最終正確率上線后成本會直接教做人。軌跡評估是 2026 年的加分項。意思是不僅要看結果還要看路徑——Agent 是不是在沒必要的時候調(diào)用了昂貴工具是不是繞遠路是不是在涉及敏感操作時沒有停下來確認。我在實際項目里會用 LLM-as-judge 搭配人工抽檢讓一個裁判模型對 Agent 的完整軌跡打分再抽 20% 讓業(yè)務人員復核離線評估集每周跑一次防止迭代回歸?？捎^測性也有固定套路。每條 Agent 決策都要記錄模型輸入輸出、決策理由、工具入?yún)⒊鰠?、token 消耗、耗時。用 trace 把所有記錄串聯(lián)起來出問題時能像查分布式系統(tǒng)一樣定位到具體哪一步。有一位做 Agent 平臺的朋友跟我說過一句話我印象很深“你連一次任務花了多少 token 都說不清楚就別談上線?！边@話糙但在面試里很加分。4. 高頻真題實戰(zhàn)解析從概念速記到系統(tǒng)設計4.1 概念題速查表30 秒答法如果你面試前只剩幾個小時這個表可以直接拿來速記。每一題都給了核心答題框架和一句加分補充。面試問題核心答案加分補充Agent 是什么LLM 規(guī)劃 記憶 工具動態(tài)決策下一步強調(diào)“控制流由模型決定”Agent 和 Workflow 區(qū)別Workflow 流程寫死Agent 路徑由模型選生產(chǎn)環(huán)境常把兩者混用ReAct 是什么推理-行動-觀察循環(huán)適用探索型任務注意 token 成本Plan-and-Execute 優(yōu)勢先規(guī)劃再執(zhí)行穩(wěn)定可控適合固定目標、多步驟任務什么是 Function Calling模型輸出結構化參數(shù)代碼執(zhí)行真實函數(shù)工具描述質(zhì)量直接決定召回率上下文溢出怎么辦摘要、截斷、外部存儲、子 Agent 隔離分層處理是核心RAG 和 Agent 區(qū)別RAG 解決“不知道”Agent 解決“不會做”兩者可結合Agent 動態(tài)檢索多 Agent 一定更好嗎不一定成本和協(xié)調(diào)復雜度高圖編排更可控Agent 怎么評估成功率、工具準確率、成本、軌跡離線評估 線上觀察長期記憶存哪里向量數(shù)據(jù)庫存結構化事實和決策只存值得復用的信息4.2 系統(tǒng)設計題范例讓社交平臺自動發(fā)消息的 Agent把熱點場景“讓小紅書自動發(fā)消息”變成一道系統(tǒng)設計題是很好的練習也是 2026 年面試官喜歡出的“業(yè)務 Agent”綜合題。題目是這樣的設計一個 Agent每天自動在社交平臺發(fā)布內(nèi)容并自動回復用戶評論。考察點有需求拆解、工具接入、安全風控、定時調(diào)度、失敗恢復。我的答題骨架是這樣。需求拆解成五個模塊內(nèi)容生成——用 LLM 基于產(chǎn)品資料和熱點話題生成文案接 RAG 提供事實依據(jù)內(nèi)容審核——發(fā)布前必須過一層審核模型加敏感詞過濾高危內(nèi)容轉(zhuǎn)人工確認定時發(fā)布——用 Celery 或 APScheduler 做任務隊列定義好發(fā)布節(jié)奏自動回復——意圖識別加 RAG 檢索由獨立的 ReAct Agent 處理但涉及活動承諾或價格類內(nèi)容必須兜底到人工數(shù)據(jù)反饋——每天記錄閱讀量、評論傾向回傳給內(nèi)容迭代。技術選型上調(diào)度層和 Agent 執(zhí)行層分離。調(diào)度層只負責觸發(fā)Agent 層用 LangGraph 定義狀態(tài)機生成 - 自審 - 人工抽檢 - 發(fā)布 - 監(jiān)控。發(fā)布失敗要有重試和告警任務狀態(tài)持久化到數(shù)據(jù)庫保證重啟不丟任務。冪等設計很關鍵——同一條內(nèi)容不能因為網(wǎng)絡超時而重復發(fā)布所以每次發(fā)布都帶上內(nèi)容 ID 和請求 ID。安全合規(guī)是這個題最容易丟分的地方。自動發(fā)布和自動回復一旦失控影響面比普通客服機器人大得多。所以我在設計里會加發(fā)布頻率限制避免被判定為騷擾所有操作留痕可審計用戶敏感信息不能進模型的長期記憶回復中涉及優(yōu)惠、承諾、售后內(nèi)容時強制轉(zhuǎn)人工。面試官聽到這些至少會認可你是真做過上線系統(tǒng)的人而不只是會調(diào)模型接口。4.3 反面教材這幾種回答面試官一聽就搖頭有些錯誤答案幾乎是統(tǒng)一模板我在模擬面試中反復聽到。第一種“模型會自己搞定一切我們不用寫規(guī)則?！边@句話在 2026 年任何 Agent 團隊都會被否定。生產(chǎn)環(huán)境必須有人類的控制點——高危操作要二審安全策略要硬編碼流程邊界要顯式定義。Agent 的自主權是設計出來的而不是模型自然擁有的。第二種“只要上下文窗口夠大就不用設計記憶。”大模型確實能裝下很多東西但成本會爆炸而且無關信息太多會干擾決策。面試官問記憶設計考的是成本意識和信息管理能力不是讓你說“換個大模型”。第三種“我們?nèi)坑枚?Agent效果特別好?！泵つ可隙?Agent 的人往往解釋不了消息如何在角色之間傳遞、失敗如何追溯、成本如何控制。一個能跑的單 Agent 永遠比一個失控的多 Agent 有價值。第四種“評估就是拿幾個測試用例跑一下?！边@暴露了完全沒做過 Agent 工程化。評價一個 Agent 至少要看成功率、成本、延遲、安全人工介入比例還要有灰度對比和回歸集。能把評估思路完整說出來的候選人在我這里直接上一個檔次。4.4 2026 年新增考察方向從 Demo 到生產(chǎn)的轉(zhuǎn)變2026 年的 Agent 面試題有幾個明顯的新風向。第一Agent 從 Demo 走向生產(chǎn)評估、可觀測、成本治理、安全合規(guī)成為必問題。第二多模態(tài)和“GUI Agent”開始出現(xiàn)比如自動操作網(wǎng)頁、自動完成訂單流程這類要求你把視覺理解、UI 解析、操作決策合并成一個閉環(huán)。第三專屬運行時和編排引擎的討論變多也就是前面提到的 Rust 后端、高性能調(diào)度說明行業(yè)已經(jīng)在焦慮單靠 Python 腳本不夠打了。第四企業(yè)級 Agent 中臺概念流行——提示詞管理、插件市場、統(tǒng)一網(wǎng)關、權限控制這些詞背后都是同一個問題Agent 怎么在企業(yè)里批量上線而不失控。如果你正在準備面試我的建議不是題海戰(zhàn)術而是把這套題當成自檢清單。核心概念過一遍手寫一個最小 Agent 循環(huán)再用框架做一個 RAG Agent 的完整任務最后跑一輪評估、總結三到五個踩坑經(jīng)歷。這套流程走完面試里大部分問題都不只是“會背”而是“真做過”。我在實際組織新人培訓時最深的體會是手寫 Agent 循環(huán)那一步?jīng)Q定了后面所有框架知識能長多深。很多人問我會不會給題庫其實這行里最重要的不是題目而是你對自己項目的理解和復盤。如果你能針對自己做過的 Agent 項目把架構、成本、失敗案例、評估指標一口氣講清楚任何題庫都可以不用背 2026 AI Agent面試高頻考點與系統(tǒng)設計自檢清單
最近一個月我?guī)褪畮讉€準備跳槽到 AI Agent 方向的工程師做了模擬面試一個感受特別明顯簡歷上寫著“精通 Agent 開發(fā)”的人一到追問環(huán)節(jié)就撐不住了。問“你的 Agent 和大模型 API 調(diào)用有什么本質(zhì)區(qū)別”很多人愣了半天問“一個工具調(diào)用返回了兩萬 token你怎么控制成本”大部分人的第一反應是“換個大上下文模型就行”。還有個候選人簡歷里寫了三個月 Agent 開發(fā)經(jīng)驗我問了一個最基礎的問題——短期記憶和長期記憶分別存在哪里他繞了五分鐘沒講到點子上。2026 年的 AI Agent 面試已經(jīng)不是“背出 ReAct 四個字母”就能過關的年代了。面試官現(xiàn)在真正考察的是架構選型、記憶設計、工具調(diào)用規(guī)范、生產(chǎn)環(huán)境可靠性、評估體系以及系統(tǒng)設計能力。這篇文章不是面試寶典的廣告而是我結合自己做 Agent 項目、也幫團隊招人的經(jīng)驗把高頻考點拆成一張真實可用的自檢清單。就覆蓋面來說我見過的高頻題里 90% 都能在這篇文章里找到對應答案適合準備投 Agent 相關崗位的同學也適合想系統(tǒng)補一遍 Agent 知識體系的開發(fā)者邊看邊查。1. Agent 基礎認知與概念辨析——面試里的“送分題”和“送命題”1.1 本質(zhì)邊界Agent 和 Chain、Workflow、RAG 到底差在哪面試一開始通常從“定義題”切入看起來是送分題其實最能拉開差距。比如“描述一下 AI Agent 的核心組成”“Agent 和普通的大模型 API 調(diào)用有什么區(qū)別”。2026 年的語境下面試官已經(jīng)不滿足于“Agent 就是 LLM 規(guī)劃 記憶 工具”這種教科書答案而是會追問你這套系統(tǒng)里哪一部分是 Agent 在決策哪一部分是你用代碼寫死的邏輯我建議用遞進式框架來答普通 API 調(diào)用是“一次問答”程序拿到結果就結束了Chain 是“多條預設好的調(diào)用鏈”流程路徑是開發(fā)者在代碼里寫死的Workflow 比 Chain 更強調(diào)狀態(tài)流轉(zhuǎn)但依然是靜態(tài)拓撲Agent 的本質(zhì)區(qū)別在于它自己決定下一步動作。也就是說Agent 讓模型擁有了對控制流的動態(tài)決策權——工具列表擺在那里調(diào)哪個、什么時候調(diào)、結果怎么處理都由模型在運行時決定。面試官最想聽到的其實是這句話因為它決定了整個系統(tǒng)架構里誰是“大腦”。再補一個高頻追問Agent 和 RAG 的區(qū)別。RAG 本質(zhì)是外部知識注入解決“模型不知道”的問題Agent 解決“模型不會做”的問題。一個偏檢索增強一個偏行動規(guī)劃。如果對方接著問“兩者能結合嗎”答案是能而且 2026 年大部分生產(chǎn)級 Agent 都帶著 RAG 組件。典型場景是 Agent 在執(zhí)行任務前先檢索內(nèi)部知識庫里的業(yè)務規(guī)則、產(chǎn)品文檔、歷史案例再開始規(guī)劃。1.2 Token、上下文窗口與“Agent 吃什么”“AI Agent 的 token 是什么意思”是這兩年搜索量暴漲的問題面試里會直接變成“你理解 token 和上下文窗口的關系嗎”“Agent 上下文溢出怎么處理”。Token 是模型處理文本的基本單位可以粗略理解成詞語碎片。但它對 Agent 格外重要因為 Agent 的每一次決策、每一次工具調(diào)用返回值、每一輪執(zhí)行日志都要占用 token。一個實戰(zhàn)計算題假設你用 ReAct 架構模型每輪先推理再決定調(diào)工具。工具返回一個幾千 token 的 JSON即使最后只用到其中兩三個字段這些 token 也要全部進入上下文。任務需要五輪工具調(diào)用上下文輕松沖到 3 萬 token 以上成本隨之飆升。2026 年百萬級上下文窗口的模型已經(jīng)很常見但面試官考的不是“你能塞多少”而是“你會不會用”。正確的答法是分層處理。第一工具返回結果落地到外部存儲比如數(shù)據(jù)庫或 Redis上下文里只放精簡后的摘要字段第二超過閾值的舊日志做截斷或摘要壓縮而不是無腦全保留第三長任務用“子 Agent”隔離主 Agent 只關心子 Agent 返回的結果不承載全部中間過程。這套三層處理邏輯我在面試里幾乎每個候選人都問能完整講清楚三層的人不到 20%屬于典型的高區(qū)分度知識點。1.3 記憶設計短期、長期與工作記憶的存儲策略記憶題的常見問法是“你的 Agent 怎么實現(xiàn)長期記憶”。這里要分清三層概念。短期記憶就是對話窗口里的會話歷史通常存在內(nèi)存或 Redis設置過期時間長期記憶用向量數(shù)據(jù)庫存用戶偏好、業(yè)務知識、歷史決策記錄配合 embedding 做相似度召回工作記憶則存放當前任務上下文和任務執(zhí)行中的臨時狀態(tài)比如“用戶剛才決定變更需求、暫時切到另一個方案”這類狀態(tài)最容易被人忽略。面試官經(jīng)常追問“記憶里應該存什么、不存什么”。我踩過的一個坑是把所有對話原文全部塞進向量庫結果召回出來全是噪聲。正確做法是只存結構化的事實、決策依據(jù)、可復用的子任務方案至于無關的寒暄和原始調(diào)試日志不但不要存還要在進入記憶之前過濾掉。召回策略也要講清楚——時間衰減權重、相關性閾值、最近 K 條兜底這三樣組合起來比單純靠相似度檢索穩(wěn)得多。記憶失效也是高頻考點。比如多輪 Agent 會話中用戶中途改了需求模型還按照舊方案繼續(xù)執(zhí)行這就是工作記憶沒有及時更新導致的。應對方式是每次計劃變更先做“計劃作廢”或“重新規(guī)劃”把舊狀態(tài)標記為 invalid而不是讓 Agent 帶著過期狀態(tài)繼續(xù)跑。2. 主流架構與核心模式從 ReAct 到 Plan-and-Execute2.1 架構全景單智能體、多智能體、圖編排的選型邏輯這部分的面試問題通常是你用過哪些 Agent 架構。背后真正想考的是你有沒有在真實場景里做過取舍?；A中的基礎是 ReAct推理 - 行動 - 觀察循環(huán)往復適合工具調(diào)用密集、需要靈活應對環(huán)境反饋的場景缺點是 token 開銷大、過程容易跑偏。相比之下Plan-and-Execute 先規(guī)劃出一個完整任務清單再逐步執(zhí)行穩(wěn)定性更高適合目標明確、步驟相對固定的任務比如“每周生成一份競品分析報告并發(fā)送郵件”。Reflexion 模式在 2026 年面試里也開始頻繁出現(xiàn)。它的特點是在執(zhí)行失敗后讓模型自我反思、更新策略更像一個“會復盤”的 Agent。面試官如果問“你的生產(chǎn)系統(tǒng)里用哪種”正確答案不是背名詞而是說探索性強、動作路徑不固定的任務用 ReAct 變體目標清晰、要控制成本的場景用 Plan-and-Execute需要持續(xù)自我改進的長周期任務考慮加一層 Reflexion 式的反思回路。再往上就是多智能體。這里有個常見的錯誤認知認為多 Agent 一定比單 Agent 強。實際上多 Agent 的成本成倍增長協(xié)調(diào)復雜度更高而且 Agent 之間的對話不可控生產(chǎn)環(huán)境很容易變成“兩個模型在互相客套”。2026 年企業(yè)級落地的主流是多 Agent 加圖編排比如 LangGraph 那種以節(jié)點和邊定義流程的方式Planner 負責任務分解Worker 負責執(zhí)行Critic 負責驗收節(jié)點之間用顯式狀態(tài)傳遞。面試里說“多 Agent 聊天式協(xié)作很優(yōu)雅”是扣分項說“圖編排可控、可觀測、可斷點續(xù)跑”才是加分項。2.2 推理規(guī)劃與工具調(diào)用從 Function Calling 到錯誤恢復工具調(diào)用是 Agent 的“手”面試幾乎必考。Function Calling 的本質(zhì)是定義函數(shù)的 JSON Schema讓模型輸出結構化的參數(shù)再在代碼里執(zhí)行真實函數(shù)。這里的關鍵不是“會調(diào)”而是面試官追問“你的工具描述怎么寫”——工具描述直接決定模型能不能在合適的時機選到合適的工具。描述里必須寫清楚工具做什么、適用條件、不適用條件、關鍵參數(shù)含義、返回結構。寫得含糊模型就會在多個相似工具之間反復橫跳。工具調(diào)用的完整鏈路有三段工具發(fā)現(xiàn)、參數(shù)生成、結果解析。高頻追問是“工具調(diào)用失敗怎么辦”。正確答案不是單純重試而是分等級降級第一先做參數(shù)糾正把模型生成的非法參數(shù)結合實際返回信息修正后重試一次第二工具多次失敗后讓 Agent 切換到無工具模式直接用自身知識回答第三將錯誤信息結構化回傳給模型讓它學習到“這條路徑走不通”避免反復踩同一個坑。還有一個必問題怎么避免 Agent 陷入無限循環(huán)。我的答案是四件套最大迭代次數(shù)限制比如 10 輪單步驟超時比如 30 秒置信度閾值低于閾值就主動向用戶確認成功標志檢測任務完成后立刻終止循環(huán)而不是讓模型繼續(xù)“錦上添花”。這四樣任何一樣缺失生產(chǎn)環(huán)境都會出亂子。2.3 主流框架的取舍LangGraph、Dify、Coze 怎么選面試里問到“用什么框架搭建”時最忌諱只報一個名字就說“挺好用的”。2026 年的面試官希望聽到的是你做過對比甚至踩過坑。LangGraph 適合復雜圖編排和精細狀態(tài)管理節(jié)點、邊、狀態(tài)流都自己控制可移植到生產(chǎn)代碼里但學習成本偏高文檔有時候要讀半天。Dify 適合快速搭建“RAG Agent”業(yè)務應用低代碼內(nèi)置知識庫和插件市場適合做企業(yè)內(nèi)部工具但深度定制會撞到它的抽象層。Coze 適合快速做面向 C 端的機器人國內(nèi)生態(tài)上手快但可移植性一般。還有一個隱藏加分點自己手寫過輕量 Agent 框架。核心就是一個循環(huán)——觀察讀取上下文和工具結果→ 決策調(diào)用模型選擇動作→ 執(zhí)行工具 → 記錄結果 → 再觀察。代碼量大約五六十行。我組織新人培訓時堅持讓每個人先手寫一遍這個循環(huán)再上 LangGraph。因為手寫能讓你真正理解狀態(tài)從哪來、錯誤在哪一層發(fā)生面試官問“底層原理”時你才不會發(fā)虛。3. 工程化與部署簡歷上寫“會 Agent 開發(fā)”的人最容易被追問的部分3.1 RAG 與 Agent 深度結合知識庫不是萬能藥RAG 和 Agent 的組合是 2026 年生產(chǎn)級應用的事實標準。面試題往往這樣出“你的 Agent 在回答業(yè)務問題時怎么接入公司內(nèi)部知識庫”這里要講清楚的不只是“接一個向量庫就行”。分塊策略要考慮 chunk size 和重疊加多少太碎則語義斷裂太大則檢索噪聲高embedding 模型選擇要看領域文本類型法律、醫(yī)療、代碼類文檔的差異很大召回之后通常還要加一層 rerank把真正相關的段落排到前面。面試官喜歡追問“RAG 檢索不到答案怎么辦”。千萬別一上來就說“調(diào)大 top-K”——那是新手操作。正確排查順序是先看分塊大小是否合理再查 query 需不需要改寫拆解、擴展、同義替換最后檢查 rerank 有沒有把正確答案壓到后面。更進一步Agent 化 RAG 的做法是讓 Agent 動態(tài)決定檢索策略簡單問題直接檢索一次復雜問題拆分子查詢多次檢索再合并而不是每條問題都走同一個重流程。順帶提一個偏實操的問題“用 AI Agent 開發(fā) Django 這種 Web 后端”到底怎么理解。這背后其實是 Agent 的托管方式——把 Agent 跑在 Web 服務里和普通 API 服務有一個重要差異Agent 任務通常是長時間的異步流程不能用普通 HTTP 請求等一個響應。需要任務隊列、長輪詢或 SSE 推送任務狀態(tài)落庫。Django 當然可以寫 Agent 服務端但設計上要把“請求-響應”模型改成“提交任務-查詢狀態(tài)-異步通知”模型這也是后端工程師轉(zhuǎn) Agent 方向最常踩的坎。3.2 可靠性設計與 Rust 運行時Agent 上生產(chǎn)的三座大山生產(chǎn)級 Agent 之所以難不是因為模型不夠聰明而是因為三個問題外部工具不穩(wěn)定、模型偶爾“發(fā)癲”、成本不可控?？煽啃缘暮诵脑O計在面試里能直接體現(xiàn)你的工程經(jīng)驗。第一是重試加熔斷連續(xù)幾次調(diào)用失敗要讓 Agent 換路徑而不是死磕同一個工具第二是冪等設計同一個工具調(diào)用多次不能產(chǎn)生副作用比如發(fā)郵件、轉(zhuǎn)賬、扣費這類操作必須靠請求 ID 去重第三是高危操作人工審批對外發(fā)送消息、提交訂單這一類動作加入 human-in-the-loop 審核節(jié)點再放行。“基于 Rust 語言構建 AI Agent”這個熱詞2026 年在面試里出現(xiàn)的頻率明顯變高了。背后的原因不是行業(yè)內(nèi)卷而是 Agent runtime 需要高并發(fā)、低延遲地處理大量流式調(diào)用。Rust 無 GC、內(nèi)存安全、并發(fā)模型強適合做調(diào)度和網(wǎng)關層讓 Python 或 TypeScript 負責業(yè)務編排。一個典型的技術棧是Rust 寫高性能 Agent 引擎上層接 LangGraph 狀態(tài)流再上層是業(yè)務插件。面試里提到這個分層會讓面試官覺得你不只是在調(diào) API而是真的考慮過性能瓶頸。部署側Agent 服務與傳統(tǒng)服務的差異是流式響應、狀態(tài)持久化、斷線續(xù)跑。用戶的瀏覽器可能關掉但后臺任務還得繼續(xù)Agent 跑了一半網(wǎng)絡斷了重新連接后要能從斷點恢復而不是從頭再來。這些都是把任務狀態(tài)持久化到數(shù)據(jù)庫、配合消息隊列做恢復才能解決的問題。順帶一提關注一下大廠和云廠商近期發(fā)布的 Agent 白皮書里面反復強調(diào)的方向無非三個可觀測、安全、成本治理。這基本就是 2026 年企業(yè)級 Agent 面試的核心風向標。3.3 評估與可觀測性不會跑評估就別投 Agent 崗評估 Agent 比評估單個大模型復雜得多因為你不僅要看最終答案對不對還要看過程合不合理。常見指標包括任務成功率、步驟完成率、工具調(diào)用準確率、無效調(diào)用率、單任務成本。舉一個真實例子兩個 Agent 完成任務的成功率都是 90%但一個平均每次任務調(diào)用 3 次工具另一個要調(diào) 12 次成本差了三倍。如果只盯著最終正確率上線后成本會直接教做人。軌跡評估是 2026 年的加分項。意思是不僅要看結果還要看路徑——Agent 是不是在沒必要的時候調(diào)用了昂貴工具是不是繞遠路是不是在涉及敏感操作時沒有停下來確認。我在實際項目里會用 LLM-as-judge 搭配人工抽檢讓一個裁判模型對 Agent 的完整軌跡打分再抽 20% 讓業(yè)務人員復核離線評估集每周跑一次防止迭代回歸?？捎^測性也有固定套路。每條 Agent 決策都要記錄模型輸入輸出、決策理由、工具入?yún)⒊鰠?、token 消耗、耗時。用 trace 把所有記錄串聯(lián)起來出問題時能像查分布式系統(tǒng)一樣定位到具體哪一步。有一位做 Agent 平臺的朋友跟我說過一句話我印象很深“你連一次任務花了多少 token 都說不清楚就別談上線?！边@話糙但在面試里很加分。4. 高頻真題實戰(zhàn)解析從概念速記到系統(tǒng)設計4.1 概念題速查表30 秒答法如果你面試前只剩幾個小時這個表可以直接拿來速記。每一題都給了核心答題框架和一句加分補充。面試問題核心答案加分補充Agent 是什么LLM 規(guī)劃 記憶 工具動態(tài)決策下一步強調(diào)“控制流由模型決定”Agent 和 Workflow 區(qū)別Workflow 流程寫死Agent 路徑由模型選生產(chǎn)環(huán)境常把兩者混用ReAct 是什么推理-行動-觀察循環(huán)適用探索型任務注意 token 成本Plan-and-Execute 優(yōu)勢先規(guī)劃再執(zhí)行穩(wěn)定可控適合固定目標、多步驟任務什么是 Function Calling模型輸出結構化參數(shù)代碼執(zhí)行真實函數(shù)工具描述質(zhì)量直接決定召回率上下文溢出怎么辦摘要、截斷、外部存儲、子 Agent 隔離分層處理是核心RAG 和 Agent 區(qū)別RAG 解決“不知道”Agent 解決“不會做”兩者可結合Agent 動態(tài)檢索多 Agent 一定更好嗎不一定成本和協(xié)調(diào)復雜度高圖編排更可控Agent 怎么評估成功率、工具準確率、成本、軌跡離線評估 線上觀察長期記憶存哪里向量數(shù)據(jù)庫存結構化事實和決策只存值得復用的信息4.2 系統(tǒng)設計題范例讓社交平臺自動發(fā)消息的 Agent把熱點場景“讓小紅書自動發(fā)消息”變成一道系統(tǒng)設計題是很好的練習也是 2026 年面試官喜歡出的“業(yè)務 Agent”綜合題。題目是這樣的設計一個 Agent每天自動在社交平臺發(fā)布內(nèi)容并自動回復用戶評論。考察點有需求拆解、工具接入、安全風控、定時調(diào)度、失敗恢復。我的答題骨架是這樣。需求拆解成五個模塊內(nèi)容生成——用 LLM 基于產(chǎn)品資料和熱點話題生成文案接 RAG 提供事實依據(jù)內(nèi)容審核——發(fā)布前必須過一層審核模型加敏感詞過濾高危內(nèi)容轉(zhuǎn)人工確認定時發(fā)布——用 Celery 或 APScheduler 做任務隊列定義好發(fā)布節(jié)奏自動回復——意圖識別加 RAG 檢索由獨立的 ReAct Agent 處理但涉及活動承諾或價格類內(nèi)容必須兜底到人工數(shù)據(jù)反饋——每天記錄閱讀量、評論傾向回傳給內(nèi)容迭代。技術選型上調(diào)度層和 Agent 執(zhí)行層分離。調(diào)度層只負責觸發(fā)Agent 層用 LangGraph 定義狀態(tài)機生成 - 自審 - 人工抽檢 - 發(fā)布 - 監(jiān)控。發(fā)布失敗要有重試和告警任務狀態(tài)持久化到數(shù)據(jù)庫保證重啟不丟任務。冪等設計很關鍵——同一條內(nèi)容不能因為網(wǎng)絡超時而重復發(fā)布所以每次發(fā)布都帶上內(nèi)容 ID 和請求 ID。安全合規(guī)是這個題最容易丟分的地方。自動發(fā)布和自動回復一旦失控影響面比普通客服機器人大得多。所以我在設計里會加發(fā)布頻率限制避免被判定為騷擾所有操作留痕可審計用戶敏感信息不能進模型的長期記憶回復中涉及優(yōu)惠、承諾、售后內(nèi)容時強制轉(zhuǎn)人工。面試官聽到這些至少會認可你是真做過上線系統(tǒng)的人而不只是會調(diào)模型接口。4.3 反面教材這幾種回答面試官一聽就搖頭有些錯誤答案幾乎是統(tǒng)一模板我在模擬面試中反復聽到。第一種“模型會自己搞定一切我們不用寫規(guī)則?！边@句話在 2026 年任何 Agent 團隊都會被否定。生產(chǎn)環(huán)境必須有人類的控制點——高危操作要二審安全策略要硬編碼流程邊界要顯式定義。Agent 的自主權是設計出來的而不是模型自然擁有的。第二種“只要上下文窗口夠大就不用設計記憶。”大模型確實能裝下很多東西但成本會爆炸而且無關信息太多會干擾決策。面試官問記憶設計考的是成本意識和信息管理能力不是讓你說“換個大模型”。第三種“我們?nèi)坑枚?Agent效果特別好?！泵つ可隙?Agent 的人往往解釋不了消息如何在角色之間傳遞、失敗如何追溯、成本如何控制。一個能跑的單 Agent 永遠比一個失控的多 Agent 有價值。第四種“評估就是拿幾個測試用例跑一下?！边@暴露了完全沒做過 Agent 工程化。評價一個 Agent 至少要看成功率、成本、延遲、安全人工介入比例還要有灰度對比和回歸集。能把評估思路完整說出來的候選人在我這里直接上一個檔次。4.4 2026 年新增考察方向從 Demo 到生產(chǎn)的轉(zhuǎn)變2026 年的 Agent 面試題有幾個明顯的新風向。第一Agent 從 Demo 走向生產(chǎn)評估、可觀測、成本治理、安全合規(guī)成為必問題。第二多模態(tài)和“GUI Agent”開始出現(xiàn)比如自動操作網(wǎng)頁、自動完成訂單流程這類要求你把視覺理解、UI 解析、操作決策合并成一個閉環(huán)。第三專屬運行時和編排引擎的討論變多也就是前面提到的 Rust 后端、高性能調(diào)度說明行業(yè)已經(jīng)在焦慮單靠 Python 腳本不夠打了。第四企業(yè)級 Agent 中臺概念流行——提示詞管理、插件市場、統(tǒng)一網(wǎng)關、權限控制這些詞背后都是同一個問題Agent 怎么在企業(yè)里批量上線而不失控。如果你正在準備面試我的建議不是題海戰(zhàn)術而是把這套題當成自檢清單。核心概念過一遍手寫一個最小 Agent 循環(huán)再用框架做一個 RAG Agent 的完整任務最后跑一輪評估、總結三到五個踩坑經(jīng)歷。這套流程走完面試里大部分問題都不只是“會背”而是“真做過”。我在實際組織新人培訓時最深的體會是手寫 Agent 循環(huán)那一步?jīng)Q定了后面所有框架知識能長多深。很多人問我會不會給題庫其實這行里最重要的不是題目而是你對自己項目的理解和復盤。如果你能針對自己做過的 Agent 項目把架構、成本、失敗案例、評估指標一口氣講清楚任何題庫都可以不用背