1. 從“全量注入”到“智能路由”一次架構(gòu)思維的轉(zhuǎn)變最近在折騰一個(gè)基于大語(yǔ)言模型的應(yīng)用框架名字叫 OpenClaw。這個(gè)名字挺有意思直譯過(guò)來(lái)是“開放的爪子”聽起來(lái)就很有抓取和操控的意味。它的核心設(shè)計(jì)理念或者說(shuō)我最初接觸它時(shí)最吸引我的地方是所謂的“全量上下文注入”。簡(jiǎn)單來(lái)說(shuō)就是不管用戶問(wèn)什么系統(tǒng)都會(huì)把當(dāng)前會(huì)話里所有相關(guān)的歷史對(duì)話、知識(shí)庫(kù)文檔、工具調(diào)用記錄一股腦兒地塞給大模型讓它自己去“大海撈針”從中找出答案。這個(gè)模式聽起來(lái)很強(qiáng)大對(duì)吧理論上模型擁有全部信息應(yīng)該能做出最全面的判斷。但實(shí)際用起來(lái)尤其是在處理稍微復(fù)雜一點(diǎn)的業(yè)務(wù)流程或者多輪對(duì)話時(shí)問(wèn)題就暴露出來(lái)了。最直觀的感受就是“慢”和“貴”。每次請(qǐng)求都攜帶海量上下文不僅增加了網(wǎng)絡(luò)傳輸和模型處理的負(fù)擔(dān)導(dǎo)致響應(yīng)延遲更重要的是大模型是按輸入和輸出的 token 數(shù)量計(jì)費(fèi)的這種“全量”模式簡(jiǎn)直就是“燒錢”模式。更隱蔽的問(wèn)題是“噪聲干擾”。當(dāng)上下文過(guò)長(zhǎng)、信息過(guò)載時(shí)模型反而容易被無(wú)關(guān)的歷史信息帶偏或者因?yàn)樾畔⑷哂喽鵁o(wú)法聚焦于當(dāng)前任務(wù)的核心導(dǎo)致回答質(zhì)量下降甚至出現(xiàn)“幻覺”——編造一些不存在的信息。所以我決定動(dòng)手改造它。我的目標(biāo)很明確把這種簡(jiǎn)單粗暴的“全量上下文注入”升級(jí)為一種更精細(xì)、更智能的“路由 記憶 編排”架構(gòu)。這不僅僅是技術(shù)上的優(yōu)化更是一次架構(gòu)思維的轉(zhuǎn)變——從“給模型所有數(shù)據(jù)讓它自己找”轉(zhuǎn)變?yōu)椤坝上到y(tǒng)智能地管理數(shù)據(jù)流只給模型它當(dāng)下最需要的那部分”。接下來(lái)我就詳細(xì)拆解一下我是如何一步步實(shí)現(xiàn)這個(gè)轉(zhuǎn)變的以及在這個(gè)過(guò)程中踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)。2. 架構(gòu)拆解理解“路由”、“記憶”與“編排”的核心角色在動(dòng)手之前我們必須先厘清這三個(gè)核心概念在優(yōu)化后的架構(gòu)中分別扮演什么角色以及它們是如何協(xié)同工作的。這就像組建一支特種部隊(duì)每個(gè)成員都有明確的職責(zé)和協(xié)作機(jī)制。2.1 路由智能的流量分發(fā)與決策中樞“路由”是整個(gè)架構(gòu)的“大腦”和“交警”。它的核心職責(zé)是分析用戶的當(dāng)前請(qǐng)求Query并決定接下來(lái)應(yīng)該走哪條“路”。這里的“路”可以指向不同的處理模塊、工具、知識(shí)庫(kù)甚至是不同的對(duì)話策略。工作流程當(dāng)一個(gè)新的用戶請(qǐng)求進(jìn)來(lái)時(shí)路由模塊首先會(huì)對(duì)其進(jìn)行分析。這個(gè)分析可以基于簡(jiǎn)單的關(guān)鍵詞匹配、意圖識(shí)別Intent Classification或者更復(fù)雜的語(yǔ)義理解。例如用戶問(wèn)“幫我查一下上個(gè)月的銷售額報(bào)告”路由模塊需要識(shí)別出這是一個(gè)“數(shù)據(jù)查詢”意圖并且需要“上個(gè)月”這個(gè)時(shí)間范圍和“銷售額報(bào)告”這個(gè)數(shù)據(jù)實(shí)體。決策輸出基于分析結(jié)果路由模塊會(huì)生成一個(gè)明確的“指令集”。這個(gè)指令集可能包括調(diào)用哪個(gè)工具Tool比如調(diào)用“數(shù)據(jù)庫(kù)查詢工具”并附上查詢條件時(shí)間范圍、報(bào)告類型。檢索哪部分記憶Memory比如從長(zhǎng)期記憶中檢索用戶之前對(duì)“銷售額”定義的特殊偏好或者從短期記憶中提取上一輪對(duì)話中提到的“本月目標(biāo)”。采用哪種對(duì)話策略O(shè)rchestration Policy比如這是一個(gè)需要分步確認(rèn)的復(fù)雜任務(wù)還是一個(gè)可以直接返回結(jié)果的簡(jiǎn)單查詢。技術(shù)實(shí)現(xiàn)選型路由的實(shí)現(xiàn)可以有很多層次。對(duì)于簡(jiǎn)單場(chǎng)景可以用規(guī)則引擎Rule Engine或決策樹。但對(duì)于OpenClaw這種希望處理復(fù)雜、開放域?qū)υ挼膽?yīng)用我強(qiáng)烈推薦使用一個(gè)輕量級(jí)的、專門用于路由的LLM。這個(gè)路由LLM的模型可以很小比如7B甚至更小的參數(shù)它的提示詞Prompt被精心設(shè)計(jì)為只做“分類”和“指令生成”這一件事這樣成本低、速度快、準(zhǔn)確率高。它的輸入是當(dāng)前用戶Query和可用的工具/記憶列表輸出就是一個(gè)結(jié)構(gòu)化的路由指令JSON。注意路由模塊的成功與否很大程度上取決于你對(duì)業(yè)務(wù)場(chǎng)景的“意圖”拆解得是否足夠細(xì)粒度。意圖劃分太粗路由就失去了意義劃分太細(xì)又會(huì)增加復(fù)雜度和維護(hù)成本。這是一個(gè)需要權(quán)衡的藝術(shù)。2.2 記憶分層化的信息存儲(chǔ)與檢索系統(tǒng)“記憶”是架構(gòu)的“知識(shí)庫(kù)”和“記事本”。在“全量注入”模式下記憶是混沌一團(tuán)的?，F(xiàn)在我們需要對(duì)它進(jìn)行分層管理讓系統(tǒng)能快速、精準(zhǔn)地找到所需信息。我將記憶系統(tǒng)分為三層這借鑒了人類記憶和許多成熟AI系統(tǒng)的設(shè)計(jì)短期記憶Short-term Memory / Conversation Buffer功能存儲(chǔ)當(dāng)前對(duì)話輪次例如最近10輪的原始對(duì)話歷史。它的容量小存取速度快。用途主要用于維持對(duì)話的連貫性讓模型理解“剛才我們說(shuō)到哪了”。例如用戶說(shuō)“把它改成紅色”模型需要從短期記憶中知道“它”指的是上一句提到的“那件襯衫”。實(shí)現(xiàn)通常用一個(gè)固定長(zhǎng)度的隊(duì)列FIFO來(lái)實(shí)現(xiàn)新的對(duì)話內(nèi)容進(jìn)入最老的被擠出。長(zhǎng)期記憶Long-term Memory / Vector Database功能存儲(chǔ)跨越多個(gè)會(huì)話的、重要的用戶信息、事實(shí)知識(shí)、業(yè)務(wù)規(guī)則等。容量大但檢索需要計(jì)算。用途用于個(gè)性化服務(wù)和深度知識(shí)問(wèn)答。例如記住用戶的偏好“不喜歡電話溝通”、公司的產(chǎn)品手冊(cè)內(nèi)容、歷史訂單信息等。實(shí)現(xiàn)這是優(yōu)化的關(guān)鍵。我使用向量數(shù)據(jù)庫(kù)如Chroma, Pinecone, Weaviate。所有需要長(zhǎng)期記憶的文本都被轉(zhuǎn)換成向量Embedding存儲(chǔ)起來(lái)。當(dāng)路由模塊判定需要長(zhǎng)期記憶時(shí)系統(tǒng)會(huì)將當(dāng)前Query也轉(zhuǎn)換成向量然后在向量數(shù)據(jù)庫(kù)中進(jìn)行相似性搜索Similarity Search只召回最相關(guān)的幾條記憶片段而不是全部。這極大地減少了上下文長(zhǎng)度。工作記憶Working Memory / State功能這是一個(gè)動(dòng)態(tài)的、結(jié)構(gòu)化的“便簽本”存儲(chǔ)當(dāng)前復(fù)雜任務(wù)執(zhí)行過(guò)程中的中間狀態(tài)和臨時(shí)變量。用途在多步驟任務(wù)編排中至關(guān)重要。比如一個(gè)“訂機(jī)票酒店租車”的旅行規(guī)劃任務(wù)工作記憶會(huì)記錄“已選定航班班次”、“酒店待支付”、“租車車型偏好”等狀態(tài)。實(shí)現(xiàn)可以用一個(gè)簡(jiǎn)單的鍵值對(duì)Key-Value存儲(chǔ)或者更結(jié)構(gòu)化的對(duì)象Object來(lái)管理。它在單次任務(wù)會(huì)話中有效任務(wù)結(jié)束后通常被清理或歸檔到長(zhǎng)期記憶。2.3 編排動(dòng)態(tài)的任務(wù)流執(zhí)行引擎“編排”是架構(gòu)的“指揮家”和“粘合劑”。它接收來(lái)自路由模塊的指令然后協(xié)調(diào)“記憶”和“工具”等各個(gè)組件按照一定的邏輯順序執(zhí)行任務(wù)并管理整個(gè)對(duì)話狀態(tài)。核心能力編排模塊的核心是管理控制流Control Flow。這包括了順序執(zhí)行、條件分支if-else、循環(huán)loop等。例如路由指令是“生成周報(bào)”編排模塊可能會(huì)分解為1) 從長(zhǎng)期記憶檢索上周任務(wù)列表2) 調(diào)用“總結(jié)工具”生成每項(xiàng)任務(wù)總結(jié)3) 調(diào)用“文檔生成工具”整合成報(bào)告4) 詢問(wèn)用戶是否發(fā)送。與狀態(tài)管理編排器緊密依賴“工作記憶”。它讀取當(dāng)前狀態(tài)來(lái)決定下一步做什么并在每一步執(zhí)行后更新狀態(tài)。這實(shí)現(xiàn)了對(duì)話的“有狀態(tài)性”讓AI能處理復(fù)雜的、多輪交互的任務(wù)。技術(shù)實(shí)現(xiàn)對(duì)于簡(jiǎn)單邏輯可以用硬編碼的狀態(tài)機(jī)State Machine。但對(duì)于OpenClaw期望的靈活性我采用了基于LLM的規(guī)劃器Planner或智能體Agent框架如LangChain的Agent、AutoGen。這些框架本質(zhì)上是一個(gè)高級(jí)的編排器它們能理解自然語(yǔ)言指令動(dòng)態(tài)地決定下一步調(diào)用哪個(gè)工具并處理工具的返回結(jié)果。三者關(guān)系總結(jié)用戶Query觸發(fā)路由路由分析后生成指令給編排器編排器根據(jù)指令從記憶系統(tǒng)中精準(zhǔn)提取所需信息短期/長(zhǎng)期/工作記憶并調(diào)用相應(yīng)的工具執(zhí)行任務(wù)執(zhí)行結(jié)果可能更新記憶并生成最終響應(yīng)給用戶。整個(gè)流程形成了一個(gè)高效、可控的閉環(huán)。3. 實(shí)戰(zhàn)改造在OpenClaw中逐步替換“全量注入”理論清晰后我們進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。對(duì)OpenClaw的改造不是一蹴而就的我采取了漸進(jìn)式的策略核心是攔截原有的“上下文組裝”環(huán)節(jié)用新的智能管道替換它。3.1 第一步構(gòu)建獨(dú)立的路由決策層首先我需要讓系統(tǒng)學(xué)會(huì)“做選擇”。我在請(qǐng)求處理流水線的最前端插入了一個(gè)路由決策模塊。創(chuàng)建路由分類器我沒有直接用主業(yè)務(wù)LLM來(lái)做路由而是單獨(dú)部署了一個(gè)小模型例如Qwen-7B-Chat-Int4。為它編寫專門的提示詞你是一個(gè)高效的路由分類器。請(qǐng)根據(jù)用戶問(wèn)題判斷其意圖并生成結(jié)構(gòu)化指令。 可用工具[“知識(shí)庫(kù)查詢”, “計(jì)算器”, “天氣查詢”, “日程管理”, “閑聊”] 可用記憶類型[“對(duì)話歷史”, “用戶檔案”, “產(chǎn)品知識(shí)”] 用戶問(wèn)題{user_query} 請(qǐng)以JSON格式輸出包含字段 - primary_intent: 主要意圖從可用工具中選擇或“純對(duì)話” - needed_memory: 需要檢索的記憶類型列表從可用記憶類型中選擇 - parameters: 提取的關(guān)鍵參數(shù)對(duì)象如時(shí)間、地點(diǎn)、名稱等集成到OpenClaw修改OpenClaw的請(qǐng)求入口函數(shù)。在將用戶輸入和傳統(tǒng)上下文拼接發(fā)送給主LLM之前先調(diào)用這個(gè)路由分類器。結(jié)果解析與傳遞解析路由分類器返回的JSON將primary_intent、needed_memory、parameters這些信息作為“元數(shù)據(jù)”附加到請(qǐng)求中傳遞給后續(xù)環(huán)節(jié)。此時(shí)主LLM的上下文仍然是全量的但我們已經(jīng)有了路由信息。實(shí)操心得路由提示詞的設(shè)計(jì)是關(guān)鍵。你需要用大量示例Few-shot去“教”這個(gè)小模型如何準(zhǔn)確分類。示例要覆蓋邊界情況比如模糊的提問(wèn)“今天怎么樣”可能指天氣也可能指心情。一開始路由準(zhǔn)確率可能只有80%需要通過(guò)bad case不斷迭代提示詞。3.2 第二步實(shí)現(xiàn)分層記憶的動(dòng)態(tài)檢索有了路由指令下一步就是按需獲取記憶而不是全量注入。改造記憶管理系統(tǒng)短期記憶維持原有的對(duì)話歷史隊(duì)列但將其從主上下文中剝離變成一個(gè)獨(dú)立的、可按需引用的模塊。長(zhǎng)期記憶引入向量數(shù)據(jù)庫(kù)。將原有的靜態(tài)知識(shí)庫(kù)文檔、用戶資料等通過(guò)嵌入模型如text-embedding-3-small批量轉(zhuǎn)換為向量存入向量數(shù)據(jù)庫(kù)我選用了Chroma因其輕量易用。工作記憶在會(huì)話中創(chuàng)建一個(gè)全局的狀態(tài)字典State Dict用于存儲(chǔ)任務(wù)執(zhí)行過(guò)程中的變量。構(gòu)建記憶檢索器編寫一個(gè)MemoryRetriever類。它的retrieve方法接收路由指令中的needed_memory列表和當(dāng)前user_query。如果needed_memory包含“對(duì)話歷史”則從短期記憶隊(duì)列中取出最近N條。如果包含“用戶檔案”或“產(chǎn)品知識(shí)”則將user_query轉(zhuǎn)換為向量在對(duì)應(yīng)的向量集合中進(jìn)行相似度搜索返回Top K個(gè)最相關(guān)的片段例如K3。將檢索到的所有記憶片段按照一定的模板如“相關(guān)用戶信息{info}”格式化準(zhǔn)備注入。替換上下文組裝邏輯這是最關(guān)鍵的一步。找到OpenClaw中原來(lái)那個(gè)把所有歷史對(duì)話和知識(shí)拼接成一個(gè)長(zhǎng)字符串的函數(shù)。將其重寫def build_intelligent_context(user_query, conversation_history, full_knowledge_base): # 1. 路由決策 route_instruction route_classifier.predict(user_query) # 2. 按需檢索記憶 retrieved_memories memory_retriever.retrieve( queryuser_query, needed_typesroute_instruction[‘needed_memory’] ) # 3. 組裝精煉上下文 new_context f“”” 當(dāng)前用戶問(wèn)題{user_query} [系統(tǒng)指令] 根據(jù)分析本次對(duì)話的核心意圖是{route_instruction[‘primary_intent’]}。 以下是為你篩選的相關(guān)背景信息請(qǐng)基于此回答問(wèn)題 [相關(guān)對(duì)話歷史] {retrieved_memories.get(‘conversation’, ‘無(wú)’)} [相關(guān)知識(shí)與信息] {retrieved_memories.get(‘knowledge’, ‘無(wú)’)} 請(qǐng)直接針對(duì)問(wèn)題結(jié)合上述信息進(jìn)行回答。 ““” return new_context, route_instruction # 同時(shí)返回路由指令供編排器使用可以看到新的上下文非常精煉只包含路由認(rèn)為必要的信息。3.3 第三步集成編排引擎串聯(lián)工具與多步任務(wù)最后我們需要一個(gè)“指揮官”來(lái)利用路由信息協(xié)調(diào)工具調(diào)用和復(fù)雜任務(wù)流。我將一個(gè)輕量級(jí)的Agent框架如LangChain的Tool-calling Agent集成到OpenClaw中。封裝工具將OpenClaw原有的或新增的業(yè)務(wù)功能查數(shù)據(jù)庫(kù)、調(diào)用API、運(yùn)行代碼等包裝成標(biāo)準(zhǔn)的“工具”函數(shù)并為其提供清晰的名稱和描述。創(chuàng)建編排器Agent配置一個(gè)主LLM作為Agent的核心并將上一步封裝好的工具列表提供給Agent。同時(shí)將我們構(gòu)建的build_intelligent_context函數(shù)作為Agent的“預(yù)處理”環(huán)節(jié)。改造主流程最終的請(qǐng)求處理流程變?yōu)閐ef process_request(user_query): # 1. 智能構(gòu)建上下文 (包含路由和記憶檢索) context, route_instruction build_intelligent_context(user_query, ...) # 2. 將精煉上下文、用戶問(wèn)題、路由參數(shù)一同交給Agent agent_response orchestration_agent.run( inputf“背景{context}\n\n問(wèn)題{user_query}”, additional_parametersroute_instruction[‘parameters’] ) # 3. Agent自動(dòng)決定是否及如何調(diào)用工具并生成最終回答 # 4. 更新短期記憶和工作記憶 update_memory(user_query, agent_response, route_instruction) return agent_response現(xiàn)在當(dāng)用戶問(wèn)“幫我對(duì)比產(chǎn)品A和產(chǎn)品B的最新價(jià)格并總結(jié)優(yōu)劣”時(shí)路由會(huì)識(shí)別出“對(duì)比分析”意圖檢索長(zhǎng)期記憶中產(chǎn)品A和B的規(guī)格書。Agent編排器收到后可能會(huì)先調(diào)用“價(jià)格查詢工具”獲取實(shí)時(shí)價(jià)格再調(diào)用“文本分析工具”對(duì)比規(guī)格最后組織語(yǔ)言生成報(bào)告。整個(gè)過(guò)程是動(dòng)態(tài)、多步的。4. 性能對(duì)比與優(yōu)化效果實(shí)測(cè)架構(gòu)改造完成后不能光憑感覺必須用數(shù)據(jù)說(shuō)話。我設(shè)計(jì)了一系列測(cè)試用例從簡(jiǎn)單問(wèn)答到復(fù)雜多輪任務(wù)對(duì)比優(yōu)化前后的關(guān)鍵指標(biāo)。測(cè)試場(chǎng)景優(yōu)化前全量注入優(yōu)化后路由記憶編排效果提升單輪簡(jiǎn)單問(wèn)答(e.g., “你好”)上下文長(zhǎng)度約500 token響應(yīng)時(shí)間~1200msAPI成本~0.001美元上下文長(zhǎng)度~150 token響應(yīng)時(shí)間~450msAPI成本~0.0003美元響應(yīng)速度提升62.5%單次成本降低70%多輪帶歷史參照的對(duì)話(e.g., “我上次說(shuō)的那件事怎么樣了”)上下文長(zhǎng)度隨輪次線性增長(zhǎng)模型易受早期無(wú)關(guān)歷史干擾第10輪響應(yīng)時(shí)間~2500ms路由精準(zhǔn)提取最近相關(guān)歷史2-3條上下文長(zhǎng)度穩(wěn)定在~300 token響應(yīng)時(shí)間穩(wěn)定在~500ms抗干擾能力顯著增強(qiáng)性能不再隨輪次劣化需要深度知識(shí)檢索的任務(wù)(e.g., “根據(jù)Q2財(cái)報(bào)分析市場(chǎng)風(fēng)險(xiǎn)”)注入全部知識(shí)庫(kù)數(shù)萬(wàn)token響應(yīng)慢成本極高模型可能“迷失”路由觸發(fā)向量檢索僅注入Top 3相關(guān)文檔片段(~600 token)響應(yīng)快答案更聚焦成本降低一個(gè)數(shù)量級(jí)答案準(zhǔn)確性和相關(guān)性大幅提升復(fù)雜多步驟工具調(diào)用(e.g., “訂明天北京飛上海的機(jī)票選靠窗座位”)難以處理。模型可能一次性輸出不完整的指令或無(wú)法記住多步狀態(tài)。編排器Agent分步執(zhí)行1.查詢航班 2.選擇航班 3.選擇座位 4.確認(rèn)。工作記憶跟蹤狀態(tài)。從不可行變?yōu)榭尚腥蝿?wù)完成率從10%提升至85%核心優(yōu)化點(diǎn)總結(jié)Token消耗與成本平均減少60%-90%的輸入token這是最直接的經(jīng)濟(jì)效益。響應(yīng)延遲因處理數(shù)據(jù)量減少和并行檢索向量檢索可與路由計(jì)算并行端到端延遲降低50%以上?；卮鹳|(zhì)量由于上下文噪聲降低模型輸出更加專注、準(zhǔn)確幻覺率有所下降。系統(tǒng)能力邊界從單一的“問(wèn)答機(jī)”擴(kuò)展為可處理復(fù)雜、有狀態(tài)工作流的“智能助手”。5. 避坑指南改造過(guò)程中遇到的典型問(wèn)題與解決方案這次改造并非一帆風(fēng)順以下是幾個(gè)印象深刻的“坑”及其解決方法。5.1 路由決策的“搖擺”與“模糊查詢”處理問(wèn)題初期路由小模型對(duì)于邊界模糊的查詢處理不穩(wěn)定。比如“講個(gè)笑話”它有時(shí)會(huì)歸類為“閑聊”有時(shí)又會(huì)因?yàn)橹R(shí)庫(kù)里有“笑話大全”文檔而被歸類為“知識(shí)庫(kù)查詢”。根因定位提示詞中對(duì)意圖的界定不夠清晰且缺少對(duì)“默認(rèn)”或“兜底”路徑的引導(dǎo)。同時(shí)模型對(duì)用戶Query的語(yǔ)義理解存在輕微偏差。解決方案細(xì)化意圖定義與優(yōu)先級(jí)在提示詞中明確“閑聊”意圖的優(yōu)先級(jí)高于“知識(shí)庫(kù)查詢”除非用戶明確說(shuō)“從你的知識(shí)庫(kù)里找個(gè)笑話”。可以定義意圖置信度閾值低于閾值則進(jìn)入“澄清”流程。引入少樣本示例在路由提示詞中增加幾個(gè)典型的模糊查詢示例及其正確輸出讓模型學(xué)會(huì)處理。設(shè)計(jì)澄清流程當(dāng)路由置信度不高時(shí)不強(qiáng)行決策而是讓編排器生成一個(gè)澄清問(wèn)題例如“您是想讓我隨便講個(gè)笑話還是從笑話庫(kù)里為您挑選一個(gè)”。這雖然增加了一輪交互但體驗(yàn)遠(yuǎn)比給出錯(cuò)誤答案要好。最終方案我采用了“路由 輕量驗(yàn)證”的模式。路由首先給出初步意圖和參數(shù)然后由一個(gè)極簡(jiǎn)的規(guī)則層或另一個(gè)更小的分類器進(jìn)行快速校驗(yàn)。例如如果路由輸出是“知識(shí)庫(kù)查詢”且參數(shù)中包含“笑話”、“故事”等詞則強(qiáng)制覆蓋為“閑聊”。這個(gè)規(guī)則層作為安全網(wǎng)有效解決了大部分搖擺問(wèn)題。5.2 向量檢索的“相關(guān)性陷阱”與“信息缺失”問(wèn)題有時(shí)向量檢索返回的Top 3片段看似語(yǔ)義相關(guān)但并未包含回答問(wèn)題的關(guān)鍵信息?；蛘哧P(guān)鍵信息被分散在多個(gè)片段中只召回其中一個(gè)導(dǎo)致答案不全。根因定位嵌入模型Embedding Model的語(yǔ)義表示能力有局限且檢索時(shí)只考慮Query與片段的相似度沒有考慮片段之間的關(guān)聯(lián)性。解決方案優(yōu)化文本分塊Chunking策略不要簡(jiǎn)單按固定長(zhǎng)度分塊。對(duì)于結(jié)構(gòu)化文檔如產(chǎn)品手冊(cè)按章節(jié)或主題分塊對(duì)于非結(jié)構(gòu)化文本使用語(yǔ)義分割模型或至少基于標(biāo)點(diǎn)、段落進(jìn)行自然分塊保證塊內(nèi)語(yǔ)義完整性。采用混合檢索Hybrid Search不單純依賴向量相似度搜索。我結(jié)合了關(guān)鍵詞檢索如BM25。先通過(guò)關(guān)鍵詞快速篩選出候選文檔再對(duì)候選文檔進(jìn)行向量相似度精排。這樣可以確保包含關(guān)鍵術(shù)語(yǔ)的片段不被遺漏。實(shí)施重排序Re-ranking檢索出Top N例如N10個(gè)片段后使用一個(gè)更精細(xì)的、專門用于重排序的小模型Cross-Encoder計(jì)算Query與每個(gè)片段的相關(guān)性得分重新排序后取Top KK3。這雖然增加了少量計(jì)算但顯著提升了召回片段的質(zhì)量。設(shè)計(jì)備用降級(jí)策略當(dāng)編排器發(fā)現(xiàn)檢索到的信息不足以回答問(wèn)題時(shí)可以觸發(fā)一個(gè)“擴(kuò)大檢索范圍”的指令或者直接告知用戶“我找到的信息可能不完整建議您提供更詳細(xì)的關(guān)鍵詞”。5.3 編排器Agent的“循環(huán)調(diào)用”與“任務(wù)失控”問(wèn)題在復(fù)雜任務(wù)中Agent有時(shí)會(huì)陷入死循環(huán)反復(fù)調(diào)用同一個(gè)工具或者在一個(gè)簡(jiǎn)單問(wèn)題上分解出過(guò)多不必要的步驟。根因定位LLM作為Agent的“大腦”其思維過(guò)程具有不確定性。當(dāng)工具返回的結(jié)果不明確或Agent對(duì)任務(wù)分解的理解出現(xiàn)偏差時(shí)就容易失控。解決方案為工具調(diào)用設(shè)置嚴(yán)格限制在Agent框架中明確設(shè)置最大迭代次數(shù)Max Iterations比如10次。達(dá)到上限后強(qiáng)制終止并返回當(dāng)前已收集的信息和“任務(wù)未完成”的提示。增強(qiáng)工具的反饋清晰度確保每個(gè)工具在失敗或結(jié)果為空時(shí)返回結(jié)構(gòu)化的錯(cuò)誤信息或明確的狀態(tài)如{“status”: “error”, “message”: “未找到符合條件的數(shù)據(jù)”}而不是簡(jiǎn)單的None或異常。這有助于Agent理解情況并調(diào)整策略。設(shè)計(jì)更精細(xì)的Agent提示詞在提示詞中明確強(qiáng)調(diào)“效率”和“必要性”。例如加入“請(qǐng)用最少的步驟解決問(wèn)題”、“如果第一步工具調(diào)用已獲得足夠信息請(qǐng)直接給出最終答案無(wú)需繼續(xù)調(diào)用其他工具”等指令。引入人工監(jiān)督或確認(rèn)點(diǎn)對(duì)于高風(fēng)險(xiǎn)或關(guān)鍵操作如發(fā)送郵件、修改數(shù)據(jù)在編排流程中設(shè)計(jì)“人工確認(rèn)”步驟。Agent在執(zhí)行到該步驟時(shí)會(huì)暫停并生成一段需要用戶確認(rèn)的文本。我的經(jīng)驗(yàn)我發(fā)現(xiàn)在Agent的提示詞中加入一個(gè)“思維鏈Chain-of-Thought自省”的要求很有效。即要求Agent在每一步?jīng)Q定調(diào)用工具前先用一句話說(shuō)明“我為什么要調(diào)用這個(gè)工具我希望得到什么”。雖然這會(huì)增加少量token但大大提高了動(dòng)作的可解釋性和可控性我可以在日志中監(jiān)控這些“自省”語(yǔ)句及時(shí)發(fā)現(xiàn)異常苗頭。6. 進(jìn)階思考架構(gòu)的擴(kuò)展性與未來(lái)優(yōu)化方向?qū)penClaw改造為“路由記憶編排”架構(gòu)后系統(tǒng)的可擴(kuò)展性變得非常好。這里分享幾個(gè)進(jìn)一步的優(yōu)化思路。1. 路由的進(jìn)化從分類到規(guī)劃目前的靜態(tài)意圖分類只是第一步。更高級(jí)的路由應(yīng)該能進(jìn)行初步的任務(wù)規(guī)劃。例如用戶說(shuō)“我想策劃一個(gè)周末團(tuán)隊(duì)建設(shè)活動(dòng)”高級(jí)路由應(yīng)該能輸出一個(gè)初步的計(jì)劃序列[“檢索團(tuán)隊(duì)偏好記憶”, “調(diào)用活動(dòng)推薦工具”, “調(diào)用預(yù)算計(jì)算工具”, “生成提案草案”]為后續(xù)的編排器提供一個(gè)高層次的“藍(lán)圖”。2. 記憶的融合從檢索到推理現(xiàn)在的記憶檢索主要是“查找-返回”模式。未來(lái)可以引入記憶融合與推理層。例如當(dāng)檢索到“用戶喜歡登山”和“上周團(tuán)隊(duì)反饋需要加強(qiáng)溝通”兩條記憶時(shí)系統(tǒng)能自動(dòng)推理出“本次團(tuán)建可考慮戶外登山溝通工作坊的組合方案”并將這個(gè)推理結(jié)論作為新生成的“衍生記憶”提供給模型而不僅僅是原始片段。3. 編排的協(xié)同從單智能體到多智能體對(duì)于極其復(fù)雜的任務(wù)單個(gè)編排Agent可能力不從心?？梢砸攵嘀悄荏wMulti-Agent協(xié)作。例如一個(gè)“規(guī)劃Agent”負(fù)責(zé)拆解任務(wù)一個(gè)“研究Agent”負(fù)責(zé)信息檢索一個(gè)“寫作Agent”負(fù)責(zé)整合成文一個(gè)“審核Agent”負(fù)責(zé)檢查質(zhì)量。它們之間通過(guò)共享的工作記憶和消息隊(duì)列進(jìn)行協(xié)作類似一個(gè)項(xiàng)目組各司其職。4. 持續(xù)學(xué)習(xí)與自適應(yīng)當(dāng)前的系統(tǒng)參數(shù)如路由規(guī)則、檢索的Top K值大多是靜態(tài)設(shè)置的?？梢砸牒?jiǎn)單的在線學(xué)習(xí)機(jī)制。例如如果用戶頻繁對(duì)某類問(wèn)題的回答進(jìn)行“點(diǎn)贊”或“點(diǎn)踩”系統(tǒng)可以微調(diào)路由策略或該領(lǐng)域知識(shí)的檢索權(quán)重讓系統(tǒng)越來(lái)越適應(yīng)用戶的個(gè)性化需求。這次對(duì)OpenClaw的改造讓我深刻體會(huì)到構(gòu)建一個(gè)強(qiáng)大的LLM應(yīng)用核心不在于堆砌最龐大的模型而在于設(shè)計(jì)一個(gè)精巧的、能夠高效管理和運(yùn)用模型能力的軟件架構(gòu)?！奥酚捎洃浘幣拧边@個(gè)模式正是將LLM從“全能但低效的巨獸”馴化為“專業(yè)且高效的伙伴”的關(guān)鍵。它通過(guò)分層與調(diào)度實(shí)現(xiàn)了成本、速度和效果的最佳平衡。如果你也在為上下文爆炸、成本高昂或任務(wù)處理能力有限而煩惱不妨從引入一個(gè)簡(jiǎn)單的路由器開始逐步重構(gòu)你的系統(tǒng)管道相信你也能收獲顯著的性能提升和更可控的用戶體驗(yàn)。