大模型應用開發(fā)走到今天單純調(diào)用一次 API 已經(jīng)解決不了真實業(yè)務問題。生產(chǎn)環(huán)境里最常見的 AI 工程崗位要求幾乎都圍繞三個關(guān)鍵詞展開AI、Agent、Data。AI 指大模型本身的理解與生成能力Agent 指模型如何借助工具和記憶去完成任務Data 則決定模型回答的信息質(zhì)量、知識邊界和可評估程度。這篇文章把【AIxAgentxData專題課】的學習路線和典型面試問題做一次系統(tǒng)梳理適合正在轉(zhuǎn)行 AI 應用開發(fā)、準備 Agent 相關(guān)崗位面試、或者想把手頭 ChatBot 升級成可維護智能系統(tǒng)的工程師閱讀。學習這類專題課最怕兩件事一是跟著教程調(diào)通一個 Demo 就以為掌握了二是把精力全部放在追新框架上面試時卻講不清底層機制。這篇文章不會只羅列資源而是給出一條可執(zhí)行的四階段學習路線再用一個最小 Agent 閉環(huán)示例把模型、工具、數(shù)據(jù)串起來最后按模塊拆解典型面試問題、答題結(jié)構(gòu)和工程排查清單。1. 先把 AI、Agent、Data 放在同一張技術(shù)地圖里1.1 AI 在這條路線里指的是什么在專題課語境里AI 主要指大語言模型及其周邊的應用能力文本理解、代碼生成、結(jié)構(gòu)化輸出、函數(shù)調(diào)用、多模態(tài)識別等。它解決的問題是“理解語言并生成合理內(nèi)容”。但大模型有兩個工程上繞不開的特性。第一它是概率模型同樣的 Prompt 每次輸出可能不同溫度參數(shù)調(diào)高后差異更明顯。第二它的輸出格式不穩(wěn)定讓它返回 JSON 時偶爾會在中間夾解釋文本。絕大多數(shù) AI 工程問題本質(zhì)都是圍繞這兩個特性做約束和兜底而不是期待模型“永遠正確”。學習階段至少需要掌握幾個概念token 與上下文窗口的關(guān)系system prompt 與 user prompt 的分工temperature 和 top_p 對輸出隨機性的影響few-shot 示例的作用以及函數(shù)調(diào)用function calling / tool calling的基本原理。這些是后續(xù)理解 Agent 的基礎(chǔ)。1.2 Agent 是從“回答問題”到“完成任務”的分水嶺普通聊天機器人的工作模式是“用戶提問 → 模型回答”模型不接觸外部系統(tǒng)也沒有行動能力。Agent 則把這個鏈路擴展成“用戶給目標 → 模型拆解計劃 → 調(diào)用工具 → 觀察結(jié)果 → 繼續(xù)推理 → 輸出最終答案”。這里要區(qū)分兩個層面。模型本身只是推理核心Agent 是包含模型、工具、記憶、循環(huán)控制在內(nèi)的整個系統(tǒng)。所以面試時被問“Agent 是怎么工作的”正確回答方向不是“我用了某個框架”而是講清楚感知、規(guī)劃、行動、觀察這四個環(huán)節(jié)如何循環(huán)。兩種常見控制模式需要理解。ReAct 模式讓模型交替進行推理和行動每一步先想“下一步要做什么、為什么”再調(diào)用工具把結(jié)果放回上下文繼續(xù)推理。Plan-and-Execute 模式則先讓模型生成完整計劃再逐步執(zhí)行執(zhí)行中遇到錯誤再調(diào)整計劃。前者靈活但 token 消耗大后者結(jié)構(gòu)清晰但應對變化較弱實際項目經(jīng)?；旌鲜褂谩?.3 Data 在 Agent 系統(tǒng)里承擔三重角色第一重角色是知識庫。業(yè)務文檔、FAQ、產(chǎn)品手冊經(jīng)過清洗、切片、向量化后存入向量數(shù)據(jù)庫問答時先檢索再讓模型基于檢索結(jié)果生成這就是 RAG。Data 在這里決定模型的知識邊界知識庫質(zhì)量不高模型再強也白搭。第二重角色是記憶。Agent 的短期記憶是上下文窗口長期記憶則需要把歷史對話摘要、用戶偏好、任務狀態(tài)寫入外部存儲需要時再檢索回來。第三重角色是評估數(shù)據(jù)。沒有評測集就無法回答“改了一個參數(shù)到底變好還是變壞”這個問題。專題課越到后面越強調(diào)評估因為可測量是工程化的前提。維度AIAgentData通俗解釋會思考的模型會動手的模型系統(tǒng)模型的知識、記憶和考卷關(guān)鍵技術(shù)大模型 API、Prompt、函數(shù)調(diào)用規(guī)劃、工具調(diào)用、記憶、多智能體協(xié)作采集、清洗、切片、向量化、檢索、評測常見事故輸出格式不穩(wěn)定、幻覺死循環(huán)、亂調(diào)工具、權(quán)限失控檢索不到、檢索噪聲大、評測失真2. 專題課學習路線四個階段逐層加深2.1 階段一模型 API、Prompt 與工具調(diào)用的基本功第一階段的目標不是學會某個框架而是建立起“模型輸出不可完全信任”的工程直覺。先用 Python 調(diào)通大模型 API寫一個能完成多輪對話的腳本。然后練習 Prompt 設(shè)計把 system prompt 寫清楚角色和約束用 few-shot 示例規(guī)定輸出格式再嘗試讓模型以 JSON 格式返回結(jié)果。這時會發(fā)現(xiàn)一個典型問題模型偶爾會在 JSON 前后加說明文字于是需要學會在代碼里做二次解析和兜底處理。這個階段還應該理解函數(shù)調(diào)用。函數(shù)調(diào)用不是讓模型真的執(zhí)行代碼而是讓模型從預定義的工具列表里選出“應該調(diào)用哪一個”并生成符合參數(shù) schema 的 JSON。模型返回的是調(diào)用意圖真正執(zhí)行的是業(yè)務代碼這個邊界必須分清楚。產(chǎn)出物建議是一個“輸入問題 → 輸出結(jié)構(gòu)化 JSON”的命令行腳本。自測標準是換 20 個不同類型的問題統(tǒng)計 JSON 解析成功率而不是只看一兩次運行效果。2.2 階段二Agent 機制與框架先手寫再引框架第二階段最容易踩的坑是過早引入 LangChain、LlamaIndex、AutoGen、Spring AI 這類框架。框架把工具注冊、記憶管理、模型路由都封裝好了看起來效率很高但一旦面試官追問“你的 Agent 中間某一步卡住了怎么查”只會用框架的人往往答不上來。推薦順序是先在幾百行代碼內(nèi)手寫一個最小 ReAct 循環(huán)模型生成決策、代碼執(zhí)行工具、結(jié)果回填上下文、循環(huán)直到輸出最終答案。手寫一遍之后對工具分發(fā)、終止條件、異常回傳這些細節(jié)會有體感再去看框架源碼或文檔會容易理解它們?yōu)槭裁匆O(shè)計這些抽象。框架學習要抓共性不要一個框架一個框架地背。所有 Agent 框架都會解決四件事模型怎么知道有哪些工具、工具返回值怎么塞回對話、上下文超長怎么辦、多步循環(huán)怎么終止。把每個框架在這四個問題上的實現(xiàn)方式對比一下學習效率會高很多。Java 工程師還可以單獨關(guān)注 Spring AI理解它如何把 Agent 能力嵌入 Spring 生態(tài)。2.3 階段三Data 工程與 RAG 全鏈路RAG 是當前最容易出成果、也最容易暴露數(shù)據(jù)問題的方向。全鏈路包括數(shù)據(jù)采集、格式解析、清洗去重、分塊、向量化、存儲、檢索、重排、組織上下文、生成回答。這個階段要親手做一遍完整鏈路并且記錄每一項選擇的效果。比如切片長度從 200 字調(diào)到 800 字檢索命中率怎么變化加了重疊窗口后上下文冗余是否增加對問題做改寫后再檢索效果會不會更好。沒有實驗記錄的學習等于沒學。同時要建立評測意識。構(gòu)造一份包含 50 到 100 條高質(zhì)量問答對的數(shù)據(jù)集分成檢索評測和生成評測兩部分。檢索評測看 TopK 命中率生成評測看回答是否完整覆蓋問題要點、是否引用正確來源。這套評測集以后每次改動都要跑一遍防止“改好一個 case 弄壞一片”。2.4 階段四綜合項目與生產(chǎn)化打磨前三個階段是技術(shù)能力第四階段是工程能力。一個能上線的 Agent 系統(tǒng)除了核心鏈路還需要日志追蹤、成本控制、異常處理、權(quán)限控制、安全防護和回滾機制。學習環(huán)境和生產(chǎn)環(huán)境的區(qū)別要重點區(qū)分。學習環(huán)境里 Agent 死循環(huán)最多損失幾次 API 調(diào)用生產(chǎn)環(huán)境里可能產(chǎn)生線上資損、越權(quán)操作或敏感信息泄露。所以生產(chǎn)環(huán)境至少要加三類保護最大步數(shù)限制防止死循環(huán)工具執(zhí)行前的參數(shù)與權(quán)限校驗防止亂調(diào)完整的軌跡日志方便回溯問題。綜合項目建議選一個自己熟悉的業(yè)務領(lǐng)域例如“內(nèi)部知識庫問答 Agent”或“售后服務工單 Agent”把數(shù)據(jù)接入、工具調(diào)用、人工接管、評估回歸全部串起來。做完后整理成項目文檔后面的面試就靠這個項目講深度。階段學習重點產(chǎn)出物自測問題一API、Prompt、函數(shù)調(diào)用穩(wěn)定輸出 JSON 的腳本換 20 個問題后解析成功率如何二ReAct 機制、Agent 框架手寫最小 Agent 循環(huán)亂問問題時會死循環(huán)嗎三數(shù)據(jù)清洗、切片、檢索、評測一套 RAG 鏈路和評測集檢索命中率、回答引用質(zhì)量如何四日志、安全、成本、回滾一個可演示的綜合項目線上出問題后能否快速定位3. 最小 Agent 閉環(huán)模型 工具 數(shù)據(jù)怎么協(xié)同3.1 選一個最小但完整的業(yè)務場景用“帶 FAQ 知識庫的客服 Agent”做示例。用戶提出問題時Agent 先檢索知識庫如果需要創(chuàng)建工單再調(diào)用工單工具最后把結(jié)果整理成自然語言回復。這個場景覆蓋了三要素數(shù)據(jù)來自 FAQ 文檔Agent 負責規(guī)劃和調(diào)用工具模型負責最終生成。代碼是演示思路用的最小版本真實項目要把異常處理、權(quán)限校驗和日志全部補上。3.2 數(shù)據(jù)準備先有可檢索的知識RAG 的第一步是把原始文檔轉(zhuǎn)成可檢索的片段。下面代碼展示切片的基本思路按段落切分避免把一句話拆成兩半超長段落再按句子邊界截斷。# data_pipeline.py 核心思路切片 簡單重疊 def split_document(text, max_len300, overlap30): parts [] for para in text.split(\n\n): para para.strip() if not para: continue start 0 while start len(para): end start max_len if end len(para): cut para.rfind(。, start, end) if cut ! -1: end cut 1 parts.append(para[start:end]) start end - overlap return parts真實項目中切片完成后會調(diào)用 embedding 模型轉(zhuǎn)成向量存入向量數(shù)據(jù)庫。這里為了聚焦 Agent 主流程先用一個簡單的文本重合度函數(shù)做檢索原理是一樣的給定一個查詢返回最相關(guān)的知識片段。# retrieval.py 演示用的簡單檢索真實項目替換為向量檢索 def retrieve_faq(question, chunks, top_k2): scored [] for item in chunks: score overlap_score(question, item[text]) scored.append((score, item[text])) scored.sort(keylambda x: x[0], reverseTrue) return [text for score, text in scored[:top_k]]overlap_score可以用字符交集比例實現(xiàn)也可以用 jieba 分詞后的詞重疊比例。這里的關(guān)鍵是理解“檢索結(jié)果會被拼進 Prompt 交給模型”所以返回片段不宜過長否則會稀釋模型注意力。3.3 核心循環(huán)讓模型決定下一步動作Agent 主循環(huán)的核心是“模型決策 → 系統(tǒng)執(zhí)行 → 結(jié)果回填 → 再次決策”。下面用偽代碼演示這個循環(huán)llm_call表示調(diào)用大模型它返回兩種結(jié)果之一一種是最終回答一種是工具調(diào)用意圖。# agent_loop.py 最小 ReAct 循環(huán) TOOLS { retrieve_faq: retrieve_faq, create_ticket: create_ticket, } def run_agent(user_query, max_steps5): context [{role: user, content: user_query}] for step in range(max_steps): decision llm_call( messagescontext, toolsTOOL_SCHEMAS, ) if decision[finish]: return decision[answer] tool_name decision[tool] arguments decision[arguments] try: result TOOLS[tool_name](**arguments) status ok except Exception as exc: result str(exc) status error print(fstep{step 1} tool{tool_name} status{status}) context.append({ role: tool, content: result, }) return 超過最大步數(shù)請人工接管TOOL_SCHEMAS是工具的描述列表告訴模型有哪些工具、參數(shù)是什么類型。llm_call在真實項目里對應具體 SDK 的函數(shù)調(diào)用接口。工具執(zhí)行被 try except 包裹是為了把異常變成模型可以看到的文本模型可以在下一步修正參數(shù)或換一種處理方式。這個循環(huán)有三個設(shè)計點值得記住。第一工具執(zhí)行永遠由業(yè)務代碼完成模型只是提出調(diào)用意圖。第二工具執(zhí)行結(jié)果以文本形式回填上下文相當于讓模型“看到”行動后果。第三max_steps是硬保護任何情況下都不能漏掉否則模型可能無限循環(huán)。3.4 運行驗證觀察每一步?jīng)Q策和結(jié)果運行示例后正常輸出應該類似下面的過程先檢索知識庫再決定是否創(chuàng)建工單最后給出最終回答step1 toolretrieve_faq statusok step2 toolcreate_ticket statusok 最終回答根據(jù)知識庫退款需要提供訂單號。我已經(jīng)為你先生成一張退款咨詢工單工單號 TK-2025-001客服會在 1 個工作日內(nèi)處理。驗證時不要只看最終答案要重點檢查兩點模型的每一步?jīng)Q策是否符合預期工具調(diào)用參數(shù)是否正確。如果發(fā)現(xiàn)模型跳過了檢索直接回復說明知識庫內(nèi)容沒有進入上下文如果工具參數(shù)亂填說明 schema 描述不夠明確。還需要做失敗驗證。把工具改成會拋異常觀察模型是否會讀取錯誤文本并給出合理回應。如果模型對錯誤結(jié)果視而不見說明 Prompt 里的約束不夠或者需要加上對工具返回狀態(tài)的顯式說明。3.5 最容易翻車的三個點第一個坑是把工具 schema 寫得太復雜。參數(shù)名含糊、類型定義不完整模型生成的參數(shù)就會頻繁出錯。解決方法是讓參數(shù)名貼近自然語言每個參數(shù)都寫清楚示例值并在代碼層面對參數(shù)做二次校驗。第二個坑是漏掉終止條件。有些人只在 while 循環(huán)里靠“模型返回 finish”退出一旦模型連續(xù)輸出工具調(diào)用意圖就死循環(huán)API 費用暴漲。預防措施是同時設(shè)置最大步數(shù)和單次工具執(zhí)行超時。第三個坑是讓工具返回超長內(nèi)容。檢索結(jié)果動輒幾千字直接塞回上下文后續(xù)推理會亂成本也高。應該在工具內(nèi)部先截斷或摘要只返回最必要的信息。4. 典型面試問題分模塊拆解4.1 大模型與 Prompt 方向這一模塊主要考察基本功高頻問題有三個。“如何讓模型穩(wěn)定輸出 JSON”答題時要分三層第一層是用結(jié)構(gòu)化輸出或函數(shù)調(diào)用機制從模型側(cè)約束格式第二層是代碼側(cè)做校驗解析失敗時用正則提取、截斷修復或重試第三層是兜底最終結(jié)果仍然解析失敗就返回可讀的降級文案。這樣答能體現(xiàn)工程思維而不是停留在“我在 Prompt 里寫了返回 JSON”?！皌emperature 調(diào)大有什么影響”要回答隨機性增大、輸出更多樣適合創(chuàng)意寫作檢索問答和工具調(diào)用場景適合用較低值保持結(jié)果穩(wěn)定。同時要說明這只影響生成階段的采樣策略不會改變模型知識本身更不能靠調(diào)大 temperature 來解決幻覺問題?！澳Ｐ彤a(chǎn)生幻覺怎么辦”合理的答法是把幻覺當成系統(tǒng)問題處理Prompt 約束模型只依據(jù)給定資料回答RAG 提供可追溯來源工具或數(shù)據(jù)庫對關(guān)鍵事實做校驗同時允許模型在不確定時回答“不知道”。不要把責任全部推給模型也不要用“我換了更強模型”這種沒有信息量的回答。4.2 Agent 原理與架構(gòu)方向“什么是 ReAct為什么有效”這是 Agent 方向必問題。要講清全稱是 Reasoning and Acting模型交替進行推理和行動先輸出思考過程說明為什么這么做再調(diào)用工具工具結(jié)果回來后繼續(xù)推理。它有效的關(guān)鍵是把思考過程暴露在上下文中讓模型每一步都能基于最新信息修正方向而不是一次性生成答案?！癆gent 和普通對話系統(tǒng)有什么區(qū)別”核心差異在于是否有行動能力和反饋回路。普通對話只有輸入和輸出Agent 多出工具調(diào)用和觀察結(jié)果兩個環(huán)節(jié)于是產(chǎn)生了新的工程問題工具怎么注冊、調(diào)用權(quán)限怎么控制、循環(huán)怎么終止、失敗怎么恢復?！癆gent 記憶怎么做”可以把答案拆成兩層短期記憶直接用上下文窗口控制重點是長度超長就用滑動窗口或摘要壓縮長期記憶放外部存儲需要時檢索回填。面試官如果追問還可以補充任務狀態(tài)記憶把進行到一半的流程持久化避免 Agent 重啟后斷掉?！岸鄠€工具之間怎么協(xié)調(diào)”回答方向是先讓模型做路由根據(jù)用戶意圖選擇工具復雜任務再引入規(guī)劃層先生成步驟再逐步執(zhí)行。關(guān)鍵點是給模型足夠的工具描述和前置條件說明并在工具層做參數(shù)聯(lián)動校驗不能指望模型自己理解所有業(yè)務規(guī)則。4.3 RAG 與 Data 方向“為什么用 RAG 而不是微調(diào)”這是數(shù)據(jù)方向最常見的問題。回答要點業(yè)務知識會頻繁更新RAG 只需更換知識庫數(shù)據(jù)成本低、速度快RAG 可以返回來源引用可解釋性強微調(diào)適合改變模型的風格、領(lǐng)域術(shù)語和行為規(guī)范不適合存放頻繁變化的事實性知識。兩者也能結(jié)合使用?！扒衅L度怎么選擇”不要背一個固定數(shù)字。要說明切片長度取決于文檔結(jié)構(gòu)和問題粒度長文檔用段落級切片更完整短問答用句子級更精準通常會在幾百到一千 token 量級之間實驗同時增加重疊窗口防止上下文被切斷。最終選擇要以評測集上的檢索命中率為準?！皺z索結(jié)果不準怎么辦”排查順序是先確認是不是召回問題即正確答案根本沒進 TopK再看是不是排序問題正確答案存在但排太靠后。召回問題可以從數(shù)據(jù)清洗、切片、embedding 模型、query 改寫幾個方向解決排序問題可以加 rerank 模型或元數(shù)據(jù)過濾。直接改 Prompt 是最常見的錯誤做法因為上下文里壓根沒有正確答案Prompt 寫得再好也沒用。“RAG 系統(tǒng)怎么評估”要區(qū)分配置階段和上線階段。配置階段用 golden 問答對做離線評測分別看檢索命中率和生成質(zhì)量上線階段通過日志和用戶反饋回流真實問題持續(xù)擴充評測集。評測集是 RAG 系統(tǒng)的資產(chǎn)比單次調(diào)參重要得多。4.4 系統(tǒng)設(shè)計與工程化方向“設(shè)計一個客服 Agent”是綜合題建議按五層答題數(shù)據(jù)層負責接入文檔和用戶信息問答層負責檢索和生成動作層負責工具調(diào)用如創(chuàng)建工單、查詢訂單控制層負責會話狀態(tài)、權(quán)限和人工接管運維層負責日志追蹤、監(jiān)控和評測回歸?！把舆t和成本怎么優(yōu)化”從鏈路角度回答先做意圖路由簡單問題走輕量模型復雜問題走完整 Agent 鏈路對高頻檢索結(jié)果做緩存壓縮上下文只保留必要信息和摘要工具執(zhí)行盡量并行回答用流式輸出改善體感。每項措施都要說明換來的代價比如緩存會降低時效性摘要可能丟失細節(jié)?！癆gent 系統(tǒng)如何保障安全和合規(guī)”要點包括工具執(zhí)行前做參數(shù)校驗和權(quán)限校驗防止 Agent 被誘導執(zhí)行越權(quán)操作對敏感字段做脫敏日志中不記錄明文關(guān)鍵信息限制工具可訪問范圍用最小權(quán)限原則在 Prompt 中防御注入攻擊但不能只依賴 Prompt真正的防線在工具執(zhí)行層?；卮饡r如果能主動提到“需要審計日志出事可以回溯 Agent 每一步做什么”會明顯加分。模塊高頻問題核心考點答題順序大模型與 Prompt穩(wěn)定輸出 JSON、temperature、幻覺對模型不確定性的處理機制約束 → 代碼校驗 → 兜底方案Agent 原理ReAct、記憶、工具協(xié)調(diào)對循環(huán)控制的理解環(huán)節(jié)解釋 → 代碼結(jié)構(gòu) → 失敗處理RAG 與 Data為什么 RAG、切片、評估對數(shù)據(jù)鏈路的掌握全鏈路 → 調(diào)參依據(jù) → 評測方法系統(tǒng)設(shè)計客服 Agent、成本、安全綜合工程能力分層設(shè)計 → 關(guān)鍵取舍 → 監(jiān)控回滾5. 面試答題的結(jié)構(gòu)、顆粒度與反例5.1 項目經(jīng)歷用 STAR 組織但要把“技術(shù)決策”講出來STAR 本身不難難的是把技術(shù)決策講出來。以“實現(xiàn)一個客服 Agent”為例不要只講背景和結(jié)果要重點講行動中的取舍。推薦這樣組織背景是知識分散在多個文檔人工回復效率低目標是做一個能回答問題并處理退款咨詢的 Agent行動時先搭數(shù)據(jù)清洗和檢索鏈路再手寫 ReAct 循環(huán)最后加入最大步數(shù)和參數(shù)校驗過程中發(fā)現(xiàn)切片過長導致檢索噪聲于是改成段落切片并加了標題元數(shù)據(jù)過濾結(jié)果是檢索準確率提升Agent 死循環(huán)問題被兜底。這樣回答既有結(jié)構(gòu)又有技術(shù)深度。5.2 技術(shù)顆粒度會調(diào) API 和會做系統(tǒng)是兩種面試表現(xiàn)同樣描述一個問題不同顆粒度的回答差別很大。低顆粒度的說法是“我用了向量數(shù)據(jù)庫做 RAG效果挺好的”。面試官無法判斷你到底做了什么。高顆粒度的說法是“我用文檔段落做切片每段帶來源標題存入向量數(shù)據(jù)庫檢索后先用分數(shù)閾值過濾再加一層 rerank最后把 Top2 片段拼進 Prompt我用 80 條 golden 問題評測命中率從 52% 提到 78%但對多輪指代仍然漏檢”。這種回答暴露了真實的工程經(jīng)驗也自然引出后續(xù)深入問題。注意不要編造具體指標。面試官追問數(shù)據(jù)來源時編不下去反而扣分。可以說“我們內(nèi)部做了抽樣評測具體數(shù)字需要在環(huán)境里復測”這種穩(wěn)妥表述。5.3 這三類回答最容易扣分第一類是名詞黨。把 Agent、RAG、多智能體、記憶網(wǎng)絡全羅列一遍每個都說不深。面試官只要追問“ReAct 為什么有效”就會露餡。第二類是框架依賴黨。所有問題都答“我們用的 LangChain 實現(xiàn)了”?？蚣苁枪ぞ卟皇侵R面試要講機制而不是講包名。第三類是甩鍋黨。出了任何問題都歸因于“模型不行”“框架 bug”“數(shù)據(jù)太臟”。合理做法是承認不確定性同時給出定位思路和解決方案比如先看軌跡日志判斷是檢索問題還是決策問題。5.4 遇到不會的題如何展開排查思路面試不可能每個題都會關(guān)鍵是展示解決問題的路徑?？梢杂谩跋炔鸾庠偌僭O(shè)再驗證再兜底”來組織。例如被問“如果 Agent 連續(xù)生成重復工具調(diào)用你怎么排查”。可以這樣答先看軌跡日志確認是在哪個步驟重復假設(shè)一模型上下文里工具結(jié)果沒有正確回填導致它不斷重試于是檢查消息拼裝邏輯假設(shè)二工具確實執(zhí)行了但返回值沒有狀態(tài)標識模型誤以為失敗于是改進工具返回結(jié)構(gòu)增加 success 字段如果仍然不行加最大步數(shù)和熔斷讓系統(tǒng)轉(zhuǎn)人工。這個思路即使不完全正確也能證明你是有排查方法論的工程師。6. 常見坑、排查清單與下一步建議6.1 工程實踐里反復出現(xiàn)的四個坑問題現(xiàn)象常見原因檢查方式處理建議工具調(diào)用偶爾返回不了合法參數(shù)schema 復雜、參數(shù)名含義不清晰打印模型原始輸出保留失敗樣本簡化參數(shù)名加示例值代碼層二次校驗和重試Agent 陷入循環(huán)API 費用快速增長缺少最大步數(shù)或工具結(jié)果未正確回填查日志看是否出現(xiàn)重復工具名設(shè)置最大步數(shù)確保工具結(jié)果追加進上下文RAG 檢索返回的內(nèi)容與問題無關(guān)切片過大、embedding 不適合領(lǐng)域、沒有重排單獨打印檢索 TopK 片段做檢查調(diào)切片、加元數(shù)據(jù)過濾、加 rerank、改寫 query評測集指標好但線上體驗差評測問題和線上真實問題分布不一致對比日志里的真實問題與評測集定期從線上抽問題回流評測集做分布覆蓋6.2 從現(xiàn)象倒推根因的排查清單排查 Agent 或 RAG 問題建議按以下順序走不要上來就改 Prompt輸入是否正確用戶原始問題有沒有被錯誤預處理例如亂碼、截斷、多余字符。數(shù)據(jù)是否就位知識庫有沒有更新新文檔有沒有完成切片和向量化。檢索是否命中把檢索結(jié)果打印出來確認正確答案是否進入 TopK。上下文是否完整工具返回結(jié)果是否真的追加到 messages還是只拼接了字符串。模型決策是否合理模型選擇工具是否正確參數(shù)是否符合 schema。工具執(zhí)行是否正確業(yè)務代碼本身有沒有報錯返回值結(jié)構(gòu)是否穩(wěn)定。輸出鏈路是否正常最終回答是否被后處理截斷或格式轉(zhuǎn)換破壞。監(jiān)控是否覆蓋線上有沒有軌跡日志、token 用量統(tǒng)計和異常告警。這套清單的價值在于固定排查入口避免在“模型不行”這個結(jié)論上過早停住。絕大多數(shù)線上問題最后查出來都不是模型的問題而是數(shù)據(jù)沒更新、參數(shù)沒傳對、日志沒打全。6.3 給專題課學習者的幾條可執(zhí)行建議第一務必先手寫一個一百行以內(nèi)的 ReAct 循環(huán)再學框架。手寫能建立對 Agent 四個環(huán)節(jié)的直覺框架只是把這個循環(huán)做得更工程化。第二用一份真實業(yè)務文檔完成一次完整 RAG 實驗并把每次切塊和檢索效果記錄下來。真實文檔會暴露格式混亂、重復內(nèi)容、專有名詞識別等問題這些才是工作的價值所在。第三從第一天就建立評測集。哪怕只有五十條問題也比沒有任何驗證標準強。后續(xù)所有優(yōu)化都跑同一套評測集做回歸防止改好一個壞一片。第四保留失敗樣本。無論是解析失敗的 JSON、檢索跑偏的 query還是工具參數(shù)錯誤都歸集成文件。面試時能拿出真實失敗案例和修復過程比背十個框架名更有說服力。第五關(guān)注經(jīng)典文獻和官方文檔優(yōu)于追新工具。ReAct、RAG 這幾篇基礎(chǔ)工作把核心機制講得很清楚理解它們之后任何新框架在你眼里都只是這些機制的組合與封裝。Java 方向可以結(jié)合 Spring AI 再補一套落地路徑但同樣要回到機制層面去理解?！続IxAgentxData專題課】的核心并不是三個獨立知識點的拼接而是三者在真實系統(tǒng)中的協(xié)作方式。把模型能力當作推理核心用 Agent 結(jié)構(gòu)賦予它行動能力用數(shù)據(jù)工程保證知識質(zhì)量和可評估性才是這條學習路線真正要訓練的能力。