如果你讓一個(gè)大語言模型寫一封郵件、改一段 SQL、翻譯一份合同它通常表現(xiàn)得像一位熟練的員工?？梢坏┠惆阉湃霃?fù)雜業(yè)務(wù)流程——比如“從三個(gè)數(shù)據(jù)源抓取報(bào)價(jià)按規(guī)則過濾生成摘要再調(diào)用消息接口通知銷售”——它的表現(xiàn)往往會(huì)突然掉檔。輕則第二步就忘了第一步的結(jié)論重則調(diào)用工具時(shí)給出無法解析的參數(shù)最后還理直氣壯地輸出一個(gè)經(jīng)不起驗(yàn)證的答案。這不是模型“變笨了”也不是參數(shù)數(shù)量不夠而是一個(gè)結(jié)構(gòu)性問題大語言模型擅長在既有知識(shí)范圍內(nèi)逐詞生成卻不擅長在一次推理中完成需要跨越多個(gè)環(huán)節(jié)的長鏈路任務(wù)。如果要用一句話來概括這個(gè)現(xiàn)象我會(huì)說LLMs Cant Jump。大模型腦子里有海量知識(shí)點(diǎn)但要它從一個(gè)點(diǎn)自行“跳”到下一個(gè)點(diǎn)往往跳不穩(wěn)。這篇文章不打算停留在“模型有局限”這種正確廢話層面而是會(huì)做三件事。第一從自回歸生成、上下文窗口、訓(xùn)練分布三個(gè)層面解釋 LLM 為什么跳不動(dòng)。第二梳理工程上常用的補(bǔ)救方案包括 RAG、Agent、MCP 和編排框架。第三給出可運(yùn)行的示例代碼同時(shí)把 fp16、fp32、bf16 這些精度細(xì)節(jié)和實(shí)際效果串起來講。無論你是在做 LLM 應(yīng)用開發(fā)還是在為大語言模型挑選推理框架讀完都會(huì)知道下一步該從哪里下手。1. 這篇文章真正要解決的問題過去兩年LLM 應(yīng)用開發(fā)中最普遍的誤區(qū)是把大模型當(dāng)成一個(gè)可插拔的“萬能大腦”只要把任務(wù)描述清楚它就能自己理解、規(guī)劃、執(zhí)行、驗(yàn)證、修正。這個(gè)設(shè)想在單步任務(wù)里是成立的比如“把這段文本翻譯成英文”“總結(jié)一下這個(gè)網(wǎng)頁的內(nèi)容”“把這條 SQL 優(yōu)化一下”。但在多步、跨工具、需要長程狀態(tài)跟蹤的任務(wù)中同樣的模型會(huì)暴露出明顯的短板。從工程視角看問題不在于模型“不聰明”而在于它的工作方式本質(zhì)上是“逐詞生成”不是“先規(guī)劃再執(zhí)行”。一個(gè)沒有明確狀態(tài)管理、沒有工具結(jié)果回填、沒有中間校驗(yàn)的 LLM 調(diào)用鏈路跑得越長錯(cuò)誤率就越高而且錯(cuò)誤還會(huì)復(fù)制和累積。這就像讓一位短跑運(yùn)動(dòng)員去走鋼索——他的爆發(fā)力沒問題但缺少的是平衡與控制。因此這篇文章要解決的真問題是如何判斷哪些任務(wù)適合交給 LLM哪些必須拆解如何用 RAG、Agent、MCP、編排框架把一個(gè)“跳不動(dòng)”的模型放到正確的工程軌道上。適合閱讀這篇文章的讀者主要有三類剛接觸 LLM 應(yīng)用開發(fā)、正準(zhǔn)備把模型接入業(yè)務(wù)系統(tǒng)的后端工程師已經(jīng)在使用 LangChain、Spring AI 等框架但經(jīng)常調(diào)不通的開發(fā)者以及對大模型能力邊界和推理精度問題感興趣的算法工程師。2. “跳不動(dòng)”的典型表現(xiàn)在進(jìn)入原理分析之前先看幾個(gè)真實(shí)項(xiàng)目里最常見的失敗模式。你可以把這些當(dāng)作自檢清單回想一下自己的 LLM 應(yīng)用是不是也踩過同樣的坑。2.1 長程推理斷層當(dāng)任務(wù)需要連續(xù)完成多步推理時(shí)模型經(jīng)常在前半段邏輯正確后半段開始丟失關(guān)鍵中間結(jié)論。比如讓模型分析一份銷售報(bào)表并給出建議它在前面準(zhǔn)確識(shí)別出“華東區(qū)本月增長 12%”但寫到最終結(jié)論時(shí)卻假設(shè)華東區(qū)在下滑導(dǎo)致建議方向完全相反。這種問題的根源在于自回歸模型在生成長文本時(shí)每一步的注意力會(huì)集中在前不久生成的 token 上早期被確認(rèn)過的重要結(jié)論會(huì)在后續(xù)生成中被逐漸稀釋。模型不是真的“忘了”而是在概率計(jì)算中沒有給早期信息足夠的權(quán)重于是生成了在局部看起來合理、在全局卻錯(cuò)誤的文本。2.2 工具調(diào)用不自洽讓模型調(diào)用外部工具時(shí)翻車更密集。模型決定調(diào)用“查詢天氣”工具但生成的 JSON 參數(shù)是{city: 北京, unit: celsius}而工具定義只接收city和unit兩個(gè)字符串字段模型偏偏把celsius傳成了布爾類型true。更糟的情況是模型調(diào)用完工具后不會(huì)正確解析返回結(jié)果。工具返回{temperature: 23, humidity: 60}模型卻把濕度當(dāng)成溫度然后在后續(xù)所有步驟中基于這個(gè)錯(cuò)誤數(shù)據(jù)繼續(xù)推理。這種錯(cuò)誤單看每一步都“不算離譜”但疊加起來會(huì)讓應(yīng)用完全不可用。2.3 上下文中的“遠(yuǎn)端遺忘”即使上下文沒有超出窗口限制“遠(yuǎn)端遺忘”也很常見。你給模型貼了十幾條業(yè)務(wù)規(guī)則要求它按規(guī)則處理用戶請求當(dāng)規(guī)則數(shù)量超過一定閾值后模型會(huì)傾向于照顧 prompt 開頭和結(jié)尾的規(guī)則忽略中間部分。這并非模型故意不聽話。Transformer 的注意力機(jī)制在長序列上并不均勻序列中段的信息本就容易被弱化。就算把上下文窗口從 4K 擴(kuò)大到 128K這個(gè)問題也不會(huì)自動(dòng)消失——窗口變大只是給了你更大的“黑板”并不等于模型能在整塊黑板上均勻用力。2.4 知識(shí)邊界外的“自信編造”當(dāng)問題超出訓(xùn)練數(shù)據(jù)覆蓋范圍模型不會(huì)回答“我不知道”而是基于概率編造一個(gè)看起來合理的答案。這個(gè)現(xiàn)象常被稱為“幻覺”但在工程上它更像是一種統(tǒng)計(jì)外推模型從訓(xùn)練分布中學(xué)過“如何像專家一樣說話”卻沒學(xué)過“哪些事不知道時(shí)應(yīng)該閉嘴”。3. 為什么 LLM 天生“跳不動(dòng)”三個(gè)技術(shù)原因想要在工程上補(bǔ)好“跳板”得先明白 LLM 為什么跳不起來。下面三個(gè)原因由淺到深分別對應(yīng)模型生成的機(jī)制、模型記憶的邊界和模型訓(xùn)練的源頭。3.1 自回歸生成每一步只考慮左側(cè)LLM 的訓(xùn)練目標(biāo)基本是同一個(gè)給定一段文本左邊的 token預(yù)測下一個(gè) token 是什么。推理時(shí)沿用同樣的方式每次只生成一個(gè) token然后把新 token 拼到已有的文本后面繼續(xù)預(yù)測下一個(gè)。這就帶來一個(gè)先天的“短視”問題模型在生成第 100 個(gè) token 時(shí)只看到已經(jīng)生成的前 99 個(gè) token它沒有一個(gè)獨(dú)立于文本之外的“全局規(guī)劃器”。規(guī)劃能力只能靠注意力機(jī)制隱式地體現(xiàn)在生成過程中一旦前面的文本遺漏了某個(gè)關(guān)鍵結(jié)論后面自然就沒有機(jī)會(huì)修正。舉個(gè)例子讓模型寫一篇 500 字的項(xiàng)目方案它在開頭確定了預(yù)算為 10 萬元到第 400 字時(shí)如果要引用預(yù)算它需要從前面 400 個(gè) token 中把“10 萬元”這個(gè)信息重新?lián)瞥鰜?。這個(gè)信息存在但未必被注意力機(jī)制選中。所以長文檔末尾經(jīng)常出現(xiàn)預(yù)算金額、人員名單、技術(shù)選型等關(guān)鍵信息前后矛盾的情況。3.2 上下文窗口圍欄不只是長度很多人以為上下文窗口只是一個(gè)容量問題只要窗口夠大模型就能記住所有對話。實(shí)際上窗口還代表模型注意力的物理邊界。序列越長注意力矩陣的計(jì)算量越大同時(shí)重要信息被淹沒的概率也越高。多篇研究都觀察到同一個(gè)現(xiàn)象在長文檔問答中答案位于文檔中間部分時(shí)模型的表現(xiàn)最差答案位于開頭或結(jié)尾時(shí)表現(xiàn)明顯更好。這個(gè)現(xiàn)象在工程上非常關(guān)鍵因?yàn)樗馕吨?prompt 中關(guān)鍵提示的擺放位置和 prompt 里寫了什么同等重要。這也解釋了為什么“把整本手冊塞進(jìn)上下文”并不是解決 LLM 知識(shí)盲區(qū)的好辦法。手冊內(nèi)容進(jìn)入窗口之后不一定真的被模型“看見”。與其依賴窗口硬塞不如通過檢索把最相關(guān)的內(nèi)容精確放到 prompt 的關(guān)鍵位置。3.3 訓(xùn)練分布跳躍半徑由數(shù)據(jù)決定最后一個(gè)原因也是最容易被忽視的LLM 是一個(gè)概率分布學(xué)習(xí)器它的所有能力都來自于對訓(xùn)練數(shù)據(jù)分布的擬合。凡是訓(xùn)練數(shù)據(jù)里大量出現(xiàn)過的模式模型學(xué)得快、用得好凡是偏離訓(xùn)練分布的輸入模型的表現(xiàn)就會(huì)斷崖式下降。所謂“跳”本質(zhì)上是能力外推。模型需要從一個(gè)已經(jīng)掌握的知識(shí)點(diǎn)跳躍到一個(gè)訓(xùn)練分布沒有那么密集的知識(shí)點(diǎn)?？缭骄嚯x越小成功率越高跨越距離越大模型越容易退化成“按統(tǒng)計(jì)慣性編答案”。這一點(diǎn)決定了企業(yè)微調(diào)的天花板無論怎么調(diào)參模型都不可能穩(wěn)定掌握訓(xùn)練數(shù)據(jù)中從未出現(xiàn)過的新業(yè)務(wù)規(guī)則。這也就是為什么我強(qiáng)調(diào)“工程跳板”而不是“模型跳高”。既然模型本身的外推半徑有限那就把需要跳躍的步驟拆開用檢索、工具、代碼來承擔(dān)確定性的部分讓模型只負(fù)責(zé)生成和判斷。4. 工程補(bǔ)救給 LLM 搭跳板理解了“跳不動(dòng)”的原因接下來看工程上怎么做。核心思路是不要逼模型一次性跳完全程而是在每一跳之前給它搭好跳板。4.1 RAG把知識(shí)放到夠得著的地方RAGRetrieval-Augmented Generation檢索增強(qiáng)生成是目前最成熟的補(bǔ)救方案。它的思路很直接模型不知道答案那就把答案相關(guān)的資料檢索出來拼到 prompt 里讓模型“看著資料回答”。一個(gè)典型的 RAG 流程包含四步文檔切塊、向量化、相似度檢索、注入 prompt。文檔先切成大小合適的片段用 embedding 模型轉(zhuǎn)成向量查詢時(shí)把用戶問題也轉(zhuǎn)成向量在向量庫中找最相似的幾個(gè)片段最后把片段塞進(jìn) prompt讓模型基于這些片段生成回答。RAG 的價(jià)值在于它把“模型去記憶”變成了“應(yīng)用去檢索”。模型不負(fù)責(zé)記住你的私有文檔只負(fù)責(zé)理解檢索到的內(nèi)容并生成回答。這樣不僅回答更準(zhǔn)確還能在文檔更新時(shí)即時(shí)生效不需要重新訓(xùn)練或微調(diào)模型。這里真正容易踩坑的地方是文檔切塊。切塊太大檢索到的片段會(huì)包含大量不相關(guān)文字切塊太小又可能丟失完整語義。實(shí)際項(xiàng)目中我通常從 256 到 512 個(gè) token 的切塊大小起步再根據(jù)回答效果調(diào)整重疊率。4.2 Agent把大跳拆成小步如果 RAG 解決的是“知識(shí)不夠”Agent 解決的是“步驟太長”。Agent 的核心思路是把一個(gè)大任務(wù)拆成多個(gè)小步驟每一輪都執(zhí)行“調(diào)用 LLM → 決定動(dòng)作 → 執(zhí)行動(dòng)作 → 觀察結(jié)果”的循環(huán)直到任務(wù)完成。這種架構(gòu)為什么有效因?yàn)槊看握{(diào)用 LLM 時(shí)需要處理的只是當(dāng)前這一步不需要模型把所有步驟的中間結(jié)論都扛在肩上。之前步驟的狀態(tài)由應(yīng)用代碼管理工具返回的結(jié)果也會(huì)回填到對話上下文中模型永遠(yuǎn)只需要處理最近幾步大大降低了長程推理斷層的風(fēng)險(xiǎn)。但 Agent 不是銀彈。每一步調(diào)用都會(huì)引入新的不確定性誤差會(huì)隨著輪次累積。如果一個(gè) Agent 要跑 10 輪工具調(diào)用每一輪成功率為 95%那么最終整體成功率只有約 60%。所以在工程上Agent 必須搭配校驗(yàn)步驟模型說“已完成”不代表真的完成應(yīng)用層要能驗(yàn)證。4.3 MCP統(tǒng)一工具接入?yún)f(xié)議熱門的 Agent 應(yīng)用離不開大量外部工具數(shù)據(jù)庫查詢、HTTP 請求、本地腳本、辦公軟件操作等。在沒有統(tǒng)一標(biāo)準(zhǔn)時(shí)每個(gè)工具都要為特定框架寫一套適配代碼工具多了以后維護(hù)成本很高。MCPModel Context Protocol正是為了解決這個(gè)問題而出現(xiàn)的開放協(xié)議。MCP 把工具接入抽象成一個(gè)公共層工具提供方實(shí)現(xiàn)一個(gè) MCP Server暴露可調(diào)用的工具和資源應(yīng)用側(cè)通過 MCP Client 連接服務(wù)器發(fā)現(xiàn)可用工具、調(diào)用工具、獲取結(jié)果。這樣同一個(gè) LLM 應(yīng)用可以復(fù)用大量已有的 MCP 服務(wù)而不必為每個(gè)后端單獨(dú)寫適配器。從熱搜詞也能看出MCP 已經(jīng)成為 LLM 應(yīng)用開發(fā)社區(qū)的重要話題。“實(shí)現(xiàn) MCP Client 與 LLM 連接”“LLM 應(yīng)用為什么需要編排框架”這類問題本質(zhì)上都是在探討工具和模型之間如何用統(tǒng)一協(xié)議解耦。我建議新手從單工具 MCP Server 開始先跑通“LLM 發(fā)起調(diào)用 → MCP Client 傳遞 → 工具執(zhí)行 → 結(jié)果回填”的最小閉環(huán)再逐步擴(kuò)展工具數(shù)量。4.4 編排框架讓跳的過程可控RAG、Agent、MCP 聽起來是三層能力但落在代碼里它們都需要一個(gè)編排層來管理。編排框架負(fù)責(zé)處理多輪調(diào)用的狀態(tài)保存、重試、緩存、日志和權(quán)限控制目前主流的方案包括 LangChain、LlamaIndex、Spring AI、Semantic Kernel 等。很多初學(xué)者問“LLM 應(yīng)用為什么需要編排框架”一個(gè)很直接的答案是你自己手寫也能實(shí)現(xiàn) Agent 循環(huán)但框架幫你處理了大量邊界情況。比如 LLM 返回的 JSON 偶爾不合法框架可以做解析重試某次工具調(diào)用超時(shí)框架可以配置優(yōu)雅降級(jí)多輪對話的歷史消息框架可以幫忙截?cái)嗪蛪嚎s。不過需要提醒的是編排框架解決的是工程問題不是模型能力問題?？蚣苣馨压ぞ哒{(diào)用、RAG 檢索變成標(biāo)準(zhǔn)化的組件但它不會(huì)讓模型在 10 步推理時(shí)突然“跳得更好”。真正決定上限的仍然是你如何拆解任務(wù)、如何組織 prompt、如何校驗(yàn)每一步的結(jié)果。5. 精度問題跳板是否穩(wěn)固聊完架構(gòu)層面的補(bǔ)救再看一個(gè)更底層的細(xì)節(jié)模型推理精度。熱搜詞里出現(xiàn)“LLM 大模型之精度問題fp16、fp32、bf16詳解與實(shí)踐”說明精度問題已經(jīng)成了實(shí)際部署中繞不開的話題。很多人誤以為精度只影響顯存和速度實(shí)際上它也影響模型輸出的穩(wěn)定性進(jìn)而影響整個(gè)鏈路是否能“跳穩(wěn)”。5.1 fp32、fp16、bf16 到底是什么浮點(diǎn)數(shù)的核心要素有三個(gè)符號(hào)位、指數(shù)位和尾數(shù)位。指數(shù)位決定數(shù)值范圍尾數(shù)位決定精度。fp32、fp16、bf16 的區(qū)別就是這三部分的分配不同。類型位寬指數(shù)位尾數(shù)位典型用途主要風(fēng)險(xiǎn)fp3232 位8 位23 位訓(xùn)練基線、結(jié)果驗(yàn)證顯存占用大推理吞吐低fp1616 位5 位10 位GPU 推理加速數(shù)值范圍小容易溢出或下溢bf1616 位8 位7 位訓(xùn)練與推理均衡方案尾數(shù)精度低不適合高精度小數(shù)運(yùn)算fp16 的問題在于指數(shù)位只有 5 位能表示的數(shù)值范圍比 fp32 小得多。超過上限會(huì)變成無窮大接近零時(shí)會(huì)變成零從而在學(xué)習(xí)率較大或梯度較小時(shí)引發(fā)訓(xùn)練不穩(wěn)定。bf16 把指數(shù)位恢復(fù)成 8 位數(shù)值范圍和 fp32 一樣大代價(jià)是尾數(shù)位從 10 位減到 7 位精度有所下降。5.2 精度選擇對推理效果的影響對推理來說大多數(shù)人選擇的方案是 fp16 或 bf16因?yàn)閮烧叨寄馨扬@存占用和計(jì)算速度優(yōu)化到接近一半。如果只是跑文本生成bf16 和 fp16 的精度差異通常很難感知因?yàn)槟Ｐ偷臋?quán)重本來就是從 fp32 訓(xùn)練后轉(zhuǎn)換過來的少量精度損失不會(huì)顯著改變輸出分布。但在強(qiáng)推理任務(wù)上精度影響會(huì)被放大。如果模型本身對數(shù)值細(xì)節(jié)敏感或者任務(wù)要求模型在多步生成中保持參數(shù)一致低精度會(huì)讓原本就脆弱的推理鏈變得更不穩(wěn)定。試想一下你讓模型在對話里反復(fù)使用同一個(gè)數(shù)字fp16 下該數(shù)值的表示誤差累積多次后續(xù)輸出就可能出現(xiàn)輕微偏差。雖然這種偏差不一定會(huì)導(dǎo)致“跳不動(dòng)”但它會(huì)讓模型在長鏈路任務(wù)中更容易跑偏。因此精度不是導(dǎo)致“跳不動(dòng)”的原因但過低的精度會(huì)讓原本就脆弱的推理鏈雪上加霜。當(dāng)你發(fā)現(xiàn)模型在復(fù)雜任務(wù)上的表現(xiàn)不穩(wěn)定時(shí)除了檢查 prompt 和上下文也要回頭看看當(dāng)前推理服務(wù)使用的是哪種精度。5.3 實(shí)踐建議我的建議是在能承受顯存開銷的前提下優(yōu)先使用 bf16。它既有 fp16 的省顯存優(yōu)勢又保留了和 fp32 相同的數(shù)值范圍對大多數(shù)現(xiàn)代加速卡都更友好。如果你的模型或量化工具只支持 fp16那就先做一組對比實(shí)驗(yàn)在同一個(gè)評(píng)測集上分別用 fp16 和 fp32 推理確認(rèn)誤差在可接受范圍內(nèi)再上線。至于更激進(jìn)的 int8 或 int4 量化我傾向于在原型階段先不碰。量化能讓模型跑在更小的顯存里但也更容易暴露“跳不動(dòng)”的問題尤其是做數(shù)學(xué)計(jì)算和工具參數(shù)生成時(shí)。作為工程團(tuán)隊(duì)先把 bf16 跑通再去評(píng)估量化收益是比較穩(wěn)妥的路徑。6. 完整示例讓 LLM 在工程里“跳起來”下面給出三個(gè)可運(yùn)行的示例分別對應(yīng)“自回歸短視”“RAG 最小流程”“工具調(diào)用與 MCP 連接思路”。這些示例不依賴特定付費(fèi) API只需要 Python 環(huán)境和少量開源庫。6.1 示例一自回歸的“短視”模擬這個(gè)示例用一棵簡單的樹模擬自回歸生成。每一步模型都選擇局部概率最高的分支但局部最優(yōu)拼起來并不是全局最優(yōu)# 文件demo_short_sighted.py # 模擬 LLM 自回歸生成的“局部最優(yōu)不等于全局最優(yōu)” def local_greedy(next_fn, start, steps): path [start] for _ in range(steps): current .join(path) candidates next_fn(current) if not candidates: break # 每一步都選概率最高的下一個(gè) token chosen max(candidates, keylambda x: x[1]) path.append(chosen[0]) return .join(path) def fake_llm_next(prefix): # 模擬一個(gè)只有兩步?jīng)Q策空間的生成模型 table { : [(a, 0.9), (b, 0.1)], a: [(x, 0.9), (y, 0.1)], ax: [(1, 0.99)], b: [(y, 0.8), (x, 0.2)], by: [(2, 0.99)], } return table.get(prefix, []) if __name__ __main__: result local_greedy(fake_llm_next, , 3) print(局部最優(yōu)結(jié)果:, result) # 輸出局部最優(yōu)結(jié)果: ax1 # 但如果我們?nèi)藶槎x全局最優(yōu)路徑是 b - y - 2即 by2 # 這就展示了“每一步都選概率最高但不一定能得到全局最優(yōu)結(jié)果”運(yùn)行這段代碼后會(huì)看到輸出ax1。從模型的角度看每一步都做出了當(dāng)時(shí)概率最高的選擇但最終得到的并不是全局最優(yōu)路徑by2。這個(gè)例子能幫你直觀理解為什么讓 LLM 自己一路生成下去容易丟掉全局規(guī)劃。6.2 示例二極簡 RAG 檢索流程下面這個(gè)示例展示 RAG 中最核心的檢索步驟文檔切塊、向量化、查詢向量化、相似度排序。# 文件simple_rag_demo.py # 依賴pip install sentence-transformers numpy # 版本說明本文講解通用流程具體版本以你的環(huán)境為準(zhǔn) from sentence_transformers import SentenceTransformer import numpy as np # 1. 加載一個(gè)輕量級(jí)多語言 embedding 模型 model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) # 2. 模擬經(jīng)過切塊后的文檔片段 chunks [ MCPModel Context Protocol是用于連接大模型與外部工具的開放協(xié)議。, RAG 通過檢索外部文檔來增強(qiáng)大模型的事實(shí)準(zhǔn)確性適合私有知識(shí)庫場景。, fp16 和 bf16 都是 16 位浮點(diǎn)數(shù)區(qū)別在于數(shù)值范圍與精度分配。, ] # 3. 文檔向量化并歸一化 doc_embeddings model.encode(chunks) doc_embeddings doc_embeddings / np.linalg.norm(doc_embeddings, axis1, keepdimsTrue) # 4. 查詢向量化 query 大模型怎么獲取外部知識(shí) q_embedding model.encode([query]) q_embedding q_embedding / np.linalg.norm(q_embedding) # 5. 計(jì)算余弦相似度取 top-k scores doc_embeddings q_embedding.T top_k np.argsort(scores, axis0)[-2:][::-1] for idx in top_k.flatten(): print(fscore{scores[idx][0]:.4f}, chunk{chunks[idx]})預(yù)期輸出中與“外部知識(shí)”最相關(guān)的第二個(gè)片段RAG 通過檢索外部文檔來增強(qiáng)大模型的事實(shí)準(zhǔn)確性應(yīng)該排在最前面。如果檢索結(jié)果不相關(guān)第一步要檢查的是 embedding 模型是否適合中文場景以及文檔切塊是否破壞了語義完整性。6.3 示例三工具調(diào)用與 MCP 客戶端連接思路Agent 循環(huán)中最核心的一步模型返回工具調(diào)用指令應(yīng)用層解析后執(zhí)行本地函數(shù)再把結(jié)果回填給模型。下面用一段說明性的 Python 代碼展示這個(gè)流程具體 SDK 以你使用的 MCP 官方庫為準(zhǔn)。# 文件mcp_agent_loop.py # 說明這段代碼用于表達(dá) Agent 循環(huán)的通用流程具體 SDK 調(diào)用請?zhí)鎿Q為真實(shí)實(shí)現(xiàn) import json async def call_tool(tool_name, arguments): # 這里替換為真實(shí)的 MCP Client 調(diào)用 # result await client.call_tool(tool_name, arguments) return {status: ok, data: f工具 {tool_name} 執(zhí)行結(jié)果} async def llm_chat(messages, tools): # 這里替換為真實(shí)的大模型接口調(diào)用 # 返回結(jié)果中應(yīng)包含 content 和可選的 tool_calls 字段 return { content: None, tool_calls: [ { id: call_abc123, type: function, function: { name: get_weather, arguments: {city: Shanghai}, }, } ], } async def agent_loop(user_query): messages [{role: user, content: user_query}] available_tools [ { type: function, function: { name: get_weather, description: 獲取指定城市當(dāng)前天氣, parameters: { type: object, properties: { city: {type: string, description: 城市名稱} }, required: [city], }, }, } ] for step in range(5): response await llm_chat(messages, toolsavailable_tools) if response.get(tool_calls): tool_call response[tool_calls][0] arguments json.loads(tool_call[function][arguments]) # 調(diào)用 MCP 工具并拿到結(jié)果 result await call_tool( tool_call[function][name], arguments ) # 將工具結(jié)果追加到對話上下文中 messages.append( { role: tool, tool_call_id: tool_call[id], content: json.dumps(result, ensure_asciiFalse), } ) continue # 沒有 tool_calls 說明模型已準(zhǔn)備好回答 print(response[content]) break這里的核心設(shè)計(jì)是每次工具調(diào)用后工具結(jié)果都要以tool角色的消息回填到上下文。如果漏掉這一步模型在下一輪生成時(shí)就看不到工具實(shí)際返回的內(nèi)容等于“跳”出去后又丟了落點(diǎn)結(jié)果必然不穩(wěn)。6.4 運(yùn)行與驗(yàn)證上述三個(gè)示例分別用 Python 運(yùn)行即可python demo_short_sighted.py python simple_rag_demo.py python mcp_agent_loop.py判斷成功的標(biāo)準(zhǔn)示例一輸出局部最優(yōu)結(jié)果: ax1說明模擬邏輯執(zhí)行成功。示例二輸出按相似度排序的片段第一條應(yīng)該是第二個(gè) chunks說明檢索鏈路工作正常。示例三因?yàn)閘lm_chat是模擬實(shí)現(xiàn)會(huì)直接輸出解析工具調(diào)用相關(guān)日志或打印最終的 content說明 Agent 循環(huán)的結(jié)構(gòu)沒跑偏。如果運(yùn)行失敗先檢查依賴是否安裝完整sentence-transformers會(huì)下載模型權(quán)重需要網(wǎng)絡(luò)訪問如果下載緩慢可以換用更小的 embedding 模型或在本地提前下載好模型目錄。7. 常見問題與排查思路LLM 應(yīng)用排查問題比普通后端應(yīng)用更棘手因?yàn)檩敵鍪歉怕市缘?。同樣一套代碼這次跑通了下次可能就失敗。下面整理高頻問題按“現(xiàn)象、原因、排查、解決”四列組織建議收藏備用。問題現(xiàn)象可能原因排查方式解決方案多步推理結(jié)果前后矛盾上下文過長中間結(jié)論被稀釋打印完整 prompt檢查關(guān)鍵信息是否被后續(xù)頁覆蓋拆分任務(wù)把關(guān)鍵結(jié)論前置或使用 Agent 狀態(tài)管理工具調(diào)用參數(shù)格式錯(cuò)誤模型對 JSON Schema 理解不穩(wěn)定查看模型返回的原始 tool_calls 文本在 prompt 中給出示例啟用強(qiáng)制 JSON 輸出應(yīng)用層做 schema 校驗(yàn)RAG 檢索結(jié)果與問題無關(guān)embedding 模型與文檔語言不匹配或切塊粒度不當(dāng)打印檢索出的 top-k 文本人工判斷相關(guān)性換用多語言 embedding 模型調(diào)整切塊大小和重疊率相同輸入產(chǎn)生不同輸出temperature 過高檢查生成參數(shù)配置事實(shí)類任務(wù)把 temperature 降到 0 到 0.2低精度量化后效果明顯下降int8/int4 量化損失過大或校準(zhǔn)數(shù)據(jù)不足對比 bf16/fp16 與量化模型在同一評(píng)測集上的效果優(yōu)先使用 bf16量化需在原型驗(yàn)證通過后再引入Agent 循環(huán)卡住不結(jié)束模型一直生成工具調(diào)用沒有停止條件打印每一輪 actions 和中間結(jié)果設(shè)置最大輪數(shù)增加“無工具調(diào)用即結(jié)束”的判定8. 最佳實(shí)踐與工程建議結(jié)合前面的分析下面是針對 LLM 應(yīng)用開發(fā)的七條工程建議。每一條都在實(shí)際項(xiàng)目中驗(yàn)證過能顯著降低“跳不動(dòng)”帶來的返工成本。第一用“能否拆成小步”來判斷是否適合交給 LLM。如果一個(gè)任務(wù)可以拆成幾個(gè)獨(dú)立的單步操作而且每一步都可以單獨(dú)驗(yàn)證那就適合用 Agent 編排。如果一個(gè)任務(wù)必須一次性進(jìn)行長達(dá)幾十步的聯(lián)合推理坦白說當(dāng)前模型很難穩(wěn)定完成?？紤]用規(guī)則引擎或傳統(tǒng)算法替代部分步驟而不是把所有壓力都?jí)航o模型。第二把確定性邏輯從模型里抽出來。數(shù)據(jù)庫查詢、算術(shù)計(jì)算、狀態(tài)緩存、日期處理這些環(huán)節(jié)不要靠 LLM 自動(dòng)生成代碼后執(zhí)行。用固定的校驗(yàn)邏輯、公式或代碼去實(shí)現(xiàn)只把“理解、生成、判斷”這類不可替代的能力交給模型。這樣可以大幅減少錯(cuò)誤的傳播范圍。第三給每一次模型調(diào)用設(shè)計(jì)驗(yàn)證點(diǎn)。例如調(diào)用工具后先檢查返回結(jié)果是否符合預(yù)期再?zèng)Q定是否進(jìn)入下一步。如果工具返回空值可以設(shè)置重試策略或直接讓模型重新描述需求。第四工具調(diào)用必須加 schema 校驗(yàn)和重試機(jī)制。模型生成的參數(shù)偶爾不符合 JSON Schema這是常態(tài)。不要直接透傳參數(shù)建議在應(yīng)用層用 JSON Schema 校驗(yàn)工具攔截錯(cuò)誤并自動(dòng)拼接一條“參數(shù)格式錯(cuò)誤請修正”的消息回調(diào)給模型。第五RAG 的優(yōu)化順序是“切塊質(zhì)量優(yōu)先于向量庫選型”。向量庫本身差異不大真正影響檢索效果的是文檔切塊、embedding 模型和你為查詢設(shè)計(jì)的改寫邏輯。先在小數(shù)據(jù)集上人工檢查檢索結(jié)果再談擴(kuò)展到大知識(shí)庫。第六精度選擇要服務(wù)于穩(wěn)定性。優(yōu)先 bf16其次是 fp16最后才是低比特量化。不要在測試階段就用 int4 跑復(fù)雜 Agent 鏈路否則你很難區(qū)分“模型能力不夠”和“精度損失導(dǎo)致輸出不穩(wěn)定”這兩類問題。第七記錄每一步的輸入輸出建立回歸測試集。LLM 應(yīng)用上線后最容易被吐槽的點(diǎn)是“這次和上次輸出不一樣”。最好的做法是收集一批典型業(yè)務(wù)問題形成一個(gè)小型評(píng)測集每次修改 prompt 或更換模型版本后先跑回歸再發(fā)布。這也是讓團(tuán)隊(duì)敢持續(xù)迭代的基礎(chǔ)。9. 總結(jié)與后續(xù)學(xué)習(xí)方向回到標(biāo)題LLMs Cant Jump。這句話的真正含義不是“大模型沒用”而是它有著清晰的能力邊界。它像一個(gè)知識(shí)量極大的運(yùn)動(dòng)員但在需要獨(dú)立跨越長鏈路、保持全局一致性、穩(wěn)定調(diào)用外部工具時(shí)需要工程系統(tǒng)為它搭好跳板。跳板是 RAG是 Agent是 MCP是編排框架也是你在 prompt 和精度上的每一個(gè)細(xì)節(jié)選擇。讀完這篇文章你可以先做一件小事選一個(gè)你手頭最常失敗的 LLM 任務(wù)判斷失敗發(fā)生在哪一層。是知識(shí)不夠那就補(bǔ) RAG。是步驟太長那就拆 Agent。是工具調(diào)用不穩(wěn)定那就加 schema 校驗(yàn)和重試。是輸出抖動(dòng)那就檢查采樣參數(shù)和推理精度。定位到層修復(fù)方向自然明確。下一步可以繼續(xù)深入的方向有三個(gè)一是 MCP 協(xié)議試著把本地腳本或 HTTP 接口封裝成一個(gè) MCP Server讓 LLM 通過統(tǒng)一協(xié)議調(diào)用二是上下文工程研究長文檔問答中 prompt 的信息擺放、關(guān)鍵結(jié)論前置和注意力稀釋問題三是推理時(shí)計(jì)算比如思維鏈、自洽性采樣這些方法能在不改模型結(jié)構(gòu)的情況下讓模型在復(fù)雜推理任務(wù)上“跳”得更高一點(diǎn)。技術(shù)選型會(huì)變化模型版本也在快速迭代但“模型負(fù)責(zé)生成、系統(tǒng)負(fù)責(zé)可靠”這個(gè)原則會(huì)在很長一段時(shí)間內(nèi)成立。把握住這個(gè)原則LLM 應(yīng)用開發(fā)就不會(huì)迷路。