1. 項(xiàng)目概述從“一次性”到“會(huì)學(xué)習(xí)”的Agent工程范式躍遷最近在搞AI Agent項(xiàng)目落地的朋友估計(jì)都踩過同一個(gè)坑辛辛苦苦搭好一個(gè)Agent上線跑得挺好但用戶反饋一多或者業(yè)務(wù)場(chǎng)景稍微一變就得回頭改提示詞、調(diào)工具鏈、甚至重構(gòu)整個(gè)工作流。這個(gè)過程就像每次開車去一個(gè)新地方都得重新看一遍地圖而不是記住“上次那個(gè)路口容易堵車得提前繞行”。這種“健忘”的Agent開發(fā)和維護(hù)成本高得嚇人。今天要聊的MemoHarness就是沖著解決這個(gè)痛點(diǎn)來的。它不是一個(gè)全新的Agent框架而是一種工程范式核心思想是讓Agent的“韁繩”Harness具備從經(jīng)驗(yàn)中學(xué)習(xí)的能力把一次性的、靜態(tài)的編排變成動(dòng)態(tài)的、可積累的智能。簡單來說傳統(tǒng)的Agent Harness我們可以理解為Agent的控制器、調(diào)度器或執(zhí)行環(huán)境是“寫死”的。它定義了Agent能調(diào)用哪些工具、遵循什么流程、遇到異常怎么處理。而MemoHarness的目標(biāo)是讓這個(gè)Harness“活”起來能夠記錄每一次Agent執(zhí)行任務(wù)的成功與失敗分析其中的決策點(diǎn)、工具使用效果、用戶反饋并將這些經(jīng)驗(yàn)結(jié)構(gòu)化地存儲(chǔ)下來。當(dāng)下一次遇到類似任務(wù)時(shí)Harness能主動(dòng)調(diào)用這些“記憶”優(yōu)化Agent的行為比如優(yōu)先選擇上次成功的工具、避開導(dǎo)致錯(cuò)誤的參數(shù)、或者直接復(fù)用某個(gè)被驗(yàn)證有效的子流程。這相當(dāng)于給Agent裝上了“肌肉記憶”和“錯(cuò)題本”。這個(gè)概念之所以火是因?yàn)樗睋袅水?dāng)前LLM應(yīng)用工程化的核心瓶頸可維護(hù)性與適應(yīng)性。無論是做智能客服、數(shù)據(jù)分析助手還是自動(dòng)化流程我們都希望系統(tǒng)越用越聰明而不是每次變更都推倒重來。MemoHarness代表的“學(xué)習(xí)型Harness”思路正是將LLM的泛化能力與系統(tǒng)工程的可控性、可積累性結(jié)合的關(guān)鍵。接下來我會(huì)結(jié)合自己的實(shí)踐拆解如何從零開始理解和構(gòu)建這樣一個(gè)系統(tǒng)。2. MemoHarness的核心設(shè)計(jì)理念與架構(gòu)拆解2.1 為什么是“Harness”學(xué)習(xí)而不是“Agent”學(xué)習(xí)這是理解MemoHarness的第一個(gè)關(guān)鍵。很多人會(huì)問讓Agent本身通過微調(diào)或者強(qiáng)化學(xué)習(xí)RL來進(jìn)化不就好了嗎理論上可以但工程上成本極高且風(fēng)險(xiǎn)大。微調(diào)LLM模型需要大量數(shù)據(jù)、算力且容易導(dǎo)致“災(zāi)難性遺忘”——學(xué)了新技能忘了舊本事。在線RL更是復(fù)雜試錯(cuò)成本可能高到業(yè)務(wù)無法承受。Harness學(xué)習(xí)則是一種更輕量、更可控的路徑。我們可以把Agent看作一個(gè)擁有強(qiáng)大但“粗糙”認(rèn)知能力LLM的“大腦”而Harness則是為這個(gè)大腦配備的“外骨骼”和“操作手冊(cè)”。這個(gè)外骨骼Harness負(fù)責(zé)工具調(diào)度與管理決定在什么情況下調(diào)用哪個(gè)API、函數(shù)或子Agent。流程編排與控制定義任務(wù)分解、步驟順序、循環(huán)與判斷邏輯。上下文管理與記憶維護(hù)對(duì)話歷史、中間結(jié)果、用戶狀態(tài)等。異常處理與回退當(dāng)某一步出錯(cuò)時(shí)決定是重試、換方案還是報(bào)錯(cuò)。讓Harness來學(xué)習(xí)意味著我們優(yōu)化的是這套“操作手冊(cè)”和“外骨骼”的適應(yīng)性而不是直接改動(dòng)“大腦”的底層認(rèn)知模型。這樣做的好處非常明顯低成本學(xué)習(xí)對(duì)象是結(jié)構(gòu)化的配置、規(guī)則或向量索引而非數(shù)十億參數(shù)的模型。高安全學(xué)習(xí)過程可以放在沙箱中驗(yàn)證不影響線上核心Agent的穩(wěn)定性。我們可以放心地做A/B測(cè)試對(duì)比新舊Harness策略?？山忉孒arness的決策邏輯比如“因?yàn)闅v史記錄顯示工具A在場(chǎng)景X下成功率高所以本次選擇工具A”比LLM黑箱內(nèi)部的神經(jīng)元激活更容易理解和審計(jì)。易迭代可以像更新配置文件一樣快速部署經(jīng)過經(jīng)驗(yàn)優(yōu)化的新Harness策略。在我的一個(gè)數(shù)據(jù)分析Agent項(xiàng)目中最初Harness里硬編碼了一條規(guī)則“用戶請(qǐng)求圖表時(shí)優(yōu)先使用matplotlib庫”。但經(jīng)驗(yàn)記錄顯示當(dāng)用戶需求是“快速預(yù)覽”時(shí)用plotly生成交互式圖表獲得的好評(píng)更多而當(dāng)需要出版級(jí)質(zhì)量時(shí)matplotlib配合特定樣式才是最佳選擇。于是我們讓Harness學(xué)習(xí)這條經(jīng)驗(yàn)將其轉(zhuǎn)化為一條帶條件的策略“IF 需求包含‘預(yù)覽’、‘交互’ THEN 選用plotlyIF 需求包含‘印刷’、‘高清’ THEN 選用matplotlib并加載‘publication’樣式”。這個(gè)策略的更新完全不需要?jiǎng)覮LM模型本身。2.2 經(jīng)驗(yàn)學(xué)習(xí)閉環(huán)記錄、抽象、檢索與應(yīng)用MemoHarness要實(shí)現(xiàn)學(xué)習(xí)必須構(gòu)建一個(gè)完整的閉環(huán)。這個(gè)閉環(huán)通常包含四個(gè)核心階段我將其概括為“記-析-找-用”。第一階段經(jīng)驗(yàn)記錄Logging這是學(xué)習(xí)的基礎(chǔ)。Harness需要在Agent執(zhí)行的每一個(gè)關(guān)鍵節(jié)點(diǎn)埋點(diǎn)記錄下“發(fā)生了什么”。這不僅僅是記錄最終的輸入和輸出更要記錄決策上下文和執(zhí)行軌跡。具體需要記錄的數(shù)據(jù)包括任務(wù)元信息任務(wù)類型、用戶ID、會(huì)話ID、時(shí)間戳。原始輸入與解析結(jié)果用戶的原始query以及經(jīng)過LLM或預(yù)處理模塊解析后的結(jié)構(gòu)化意圖例如{“action”: “query_database”, “target”: “sales_data”, “filters”: {“time”: “2024-Q1”}}。決策點(diǎn)日志Harness在何處做了何種選擇。例如“在工具選擇節(jié)點(diǎn)候選工具有 [‘sql_executor’ ‘natural_language_to_sql’]最終選擇 ‘sql_executor’因?yàn)榕渲玫膬?yōu)先級(jí)規(guī)則中它排第一。”工具調(diào)用詳情調(diào)用了哪個(gè)工具傳入的參數(shù)是什么工具的返回結(jié)果包括成功狀態(tài)、返回?cái)?shù)據(jù)、耗時(shí)、錯(cuò)誤信息。流程狀態(tài)多步任務(wù)中每一步的輸入、輸出和狀態(tài)轉(zhuǎn)移。最終結(jié)果與反饋Agent返回給用戶的最終答案以及可能收集到的顯式反饋如用戶評(píng)分“ thumbs up/down”或隱式反饋如用戶后續(xù)是否追問、會(huì)話是否迅速結(jié)束。實(shí)操心得記錄不是越多越好要平衡信息價(jià)值與存儲(chǔ)成本。我們初期曾嘗試記錄LLM每一步的完整思維鏈Chain-of-Thought數(shù)據(jù)量暴漲且包含大量噪聲。后來優(yōu)化為只記錄關(guān)鍵決策節(jié)點(diǎn)和外部工具交互的摘要。一個(gè)有用的技巧是定義“決策事件”和“工具事件”兩種日志schema使后續(xù)分析更有針對(duì)性。第二階段經(jīng)驗(yàn)抽象與索引Abstraction Indexing原始日志是雜亂的“數(shù)據(jù)”需要被提煉成可被高效檢索和推理的“經(jīng)驗(yàn)”。這一步的核心是特征提取和向量化。特征提取從日志中抽取出對(duì)未來決策有指導(dǎo)意義的特征。例如任務(wù)特征意圖分類、關(guān)鍵實(shí)體、復(fù)雜度評(píng)分。上下文特征對(duì)話歷史摘要、用戶偏好標(biāo)簽。工具特征工具名稱、參數(shù)組合、執(zhí)行環(huán)境。結(jié)果特征成功/失敗二值標(biāo)簽、質(zhì)量評(píng)分、耗時(shí)、用戶滿意度。向量化將文本特征如任務(wù)描述、錯(cuò)誤信息通過Embedding模型如text-embedding-3-small轉(zhuǎn)換為向量。同時(shí)結(jié)構(gòu)化特征如工具ID、返回碼可以單獨(dú)存儲(chǔ)或與向量拼接。構(gòu)建索引將向量和關(guān)聯(lián)的元數(shù)據(jù)如具體的決策、結(jié)果存入向量數(shù)據(jù)庫如Chroma、Weaviate、Qdrant。索引的鍵可以是“任務(wù)意圖上下文”的向量值是對(duì)應(yīng)的“經(jīng)驗(yàn)包”采取了什么行動(dòng)結(jié)果如何。第三階段經(jīng)驗(yàn)檢索Retrieval當(dāng)新的任務(wù)到來時(shí)Harness需要從“記憶庫”中找到最相關(guān)的歷史經(jīng)驗(yàn)來指導(dǎo)本次決策。這個(gè)過程通常是近似最近鄰搜索ANN。查詢構(gòu)造將當(dāng)前任務(wù)的上下文解析后的意圖、對(duì)話歷史等進(jìn)行同樣的特征提取和向量化形成查詢向量。相似度搜索在向量數(shù)據(jù)庫中搜索與查詢向量最相似的K條歷史經(jīng)驗(yàn)記錄。相關(guān)性過濾根據(jù)相似度分?jǐn)?shù)、任務(wù)類型匹配度、時(shí)間新鮮度等對(duì)檢索結(jié)果進(jìn)行過濾和重排序選出最相關(guān)的幾條經(jīng)驗(yàn)。第四階段經(jīng)驗(yàn)應(yīng)用Application檢索到的經(jīng)驗(yàn)如何影響本次Agent的執(zhí)行主要有三種模式提示詞增強(qiáng)In-context Learning將相關(guān)經(jīng)驗(yàn)作為少樣本示例Few-shot Examples插入到給LLM的提示詞中。例如“上次遇到類似查詢時(shí)我們用了X方法用戶很滿意。這次你可以參考?！边@是最靈活、最通用的方式。策略參數(shù)調(diào)整經(jīng)驗(yàn)直接影響Harness內(nèi)部的決策邏輯。例如如果歷史記錄顯示某工具在特定條件下失敗率高Harness可以動(dòng)態(tài)降低該工具的優(yōu)先級(jí)或直接跳過。流程短路Short-circuiting如果發(fā)現(xiàn)當(dāng)前任務(wù)與某個(gè)歷史成功案例幾乎完全相同Harness可以直接返回緩存的結(jié)果或調(diào)用已驗(yàn)證的流程無需再次經(jīng)過完整的LLM推理和工具調(diào)用鏈極大提升效率與一致性。在我們的項(xiàng)目中我們混合使用了這三種方式。對(duì)于創(chuàng)意類任務(wù)如寫文案多用提示詞增強(qiáng)對(duì)于流程類任務(wù)如數(shù)據(jù)導(dǎo)出多用策略調(diào)整對(duì)于事實(shí)查詢類任務(wù)如查天氣在驗(yàn)證信息未過期后會(huì)直接短路返回緩存。3. 構(gòu)建MemoHarness的關(guān)鍵組件與實(shí)操要點(diǎn)3.1 經(jīng)驗(yàn)存儲(chǔ)層向量數(shù)據(jù)庫選型與數(shù)據(jù)模型設(shè)計(jì)存儲(chǔ)層是MemoHarness的“海馬體”設(shè)計(jì)好壞直接決定學(xué)習(xí)效率。主流選擇是向量數(shù)據(jù)庫但并非唯一。選型考量Chroma輕量、易嵌入、Python原生友好適合快速原型和中小規(guī)模項(xiàng)目。它的簡單性在初期避免了運(yùn)維復(fù)雜度。Weaviate功能強(qiáng)大原生支持多模態(tài)、GraphQL接口具備內(nèi)置的模塊化設(shè)計(jì)如向量化模塊、檢索模塊。適合中大型、對(duì)檢索功能有定制化需求的系統(tǒng)。Qdrant性能強(qiáng)勁用Rust編寫分布式支持好過濾Filter功能非常靈活。適合生產(chǎn)環(huán)境、高并發(fā)、需要復(fù)雜元數(shù)據(jù)過濾的場(chǎng)景。PgvectorPostgreSQL擴(kuò)展如果你的業(yè)務(wù)數(shù)據(jù)本就存在PostgreSQL中引入pgvector可以避免維護(hù)另一個(gè)數(shù)據(jù)庫保證數(shù)據(jù)一致性。適合希望技術(shù)棧統(tǒng)一、已有較強(qiáng)PostgreSQL運(yùn)維能力的團(tuán)隊(duì)。我們項(xiàng)目初期用Chroma快速驗(yàn)證想法當(dāng)經(jīng)驗(yàn)數(shù)據(jù)超過10萬條、且需要復(fù)雜屬性過濾如“篩選出所有使用工具A且成功了的經(jīng)驗(yàn)”時(shí)遷移到了Qdrant。它的過濾性能確實(shí)出色。數(shù)據(jù)模型設(shè)計(jì)示例 一個(gè)經(jīng)驗(yàn)條目ExperienceEntry可以設(shè)計(jì)為如下結(jié)構(gòu)以JSON示意{ id: exp_001, task_embedding: [0.12, -0.05, ...], // 任務(wù)上下文向量 meta: { task_intent: generate_report, user_id: user_123, session_id: sess_456, timestamp: 2024-05-27T10:00:00Z, complexity: medium }, decision_point: tool_selection, context_before: 用戶請(qǐng)求生成Q1銷售報(bào)告已確認(rèn)數(shù)據(jù)時(shí)間段和維度。, action_taken: { type: tool_call, tool_name: advanced_chart_generator, parameters: {chart_type: stacked_bar, interactive: true} }, outcome: { success: true, quality_score: 0.92, user_feedback: explicit_positive, duration_ms: 1250, raw_output: 圖表生成成功鏈接為... }, derived_lesson: 對(duì)于包含多維度對(duì)比的銷售報(bào)告使用交互式堆疊柱狀圖獲得更高滿意度。 // 可選項(xiàng)由后續(xù)分析模塊生成 }注意事項(xiàng)task_embedding的生成至關(guān)重要。不要簡單用用戶原始query去編碼。更好的做法是用一個(gè)輕量級(jí)LLM或經(jīng)過提示詞優(yōu)化的主Agent對(duì)當(dāng)前任務(wù)上下文做一個(gè)標(biāo)準(zhǔn)化摘要再用這個(gè)摘要生成向量。這能提高相似任務(wù)檢索的準(zhǔn)確性。例如將“幫我看看上個(gè)季度賣得怎么樣”和“請(qǐng)輸出Q2的銷售業(yè)績情況”映射到相似的語義空間。3.2 學(xué)習(xí)觸發(fā)與集成策略何時(shí)以及如何影響AgentHarness不能每時(shí)每刻都“回憶”這會(huì)造成延遲和混亂。需要設(shè)計(jì)明確的觸發(fā)機(jī)制。觸發(fā)時(shí)機(jī)任務(wù)啟動(dòng)時(shí)在Agent開始規(guī)劃或執(zhí)行第一步之前檢索相關(guān)經(jīng)驗(yàn)用于初始化提示詞或預(yù)置策略。這適用于有明確模式的任務(wù)。關(guān)鍵決策點(diǎn)在Harness需要做出選擇時(shí)觸發(fā)如選擇工具、判斷分支、設(shè)定參數(shù)。這是最精細(xì)化的學(xué)習(xí)介入點(diǎn)。異常發(fā)生時(shí)當(dāng)工具調(diào)用失敗、LLM輸出格式錯(cuò)誤或用戶表達(dá)不滿時(shí)立即檢索歷史上如何處理類似異常嘗試應(yīng)用解決方案。任務(wù)完成后無論成功失敗都觸發(fā)學(xué)習(xí)流程將本次執(zhí)行的經(jīng)驗(yàn)存儲(chǔ)起來并可能觸發(fā)對(duì)歷史經(jīng)驗(yàn)的再評(píng)估和更新如修正一條過去被認(rèn)為是成功但本次被證偽的經(jīng)驗(yàn)。集成模式影子模式Shadow Mode在新手期或?qū)Ψ€(wěn)定性要求極高的場(chǎng)景Harness正常檢索經(jīng)驗(yàn)并記錄“如果應(yīng)用該經(jīng)驗(yàn)會(huì)做出什么決策”但與實(shí)際決策并行運(yùn)行、僅作日志對(duì)比不真正影響線上Agent。用于安全地評(píng)估學(xué)習(xí)效果。建議模式Advisory Mode將檢索到的經(jīng)驗(yàn)作為“建議”提供給主LLM或決策模塊由后者決定是否采納。通常通過提示詞注入實(shí)現(xiàn)如“歷史經(jīng)驗(yàn)提示在類似情況下采取X方案的成功率較高。請(qǐng)參考?！笨刂颇Ｊ紺ontrol ModeHarness擁有更高權(quán)限可以直接覆蓋默認(rèn)決策邏輯應(yīng)用學(xué)習(xí)到的最佳策略。這需要充分的測(cè)試和回滾機(jī)制。在我們的系統(tǒng)中對(duì)于“圖表生成”這類成熟任務(wù)采用控制模式對(duì)于“內(nèi)容創(chuàng)作”這類主觀性強(qiáng)、變化多的任務(wù)采用建議模式任何新上線的經(jīng)驗(yàn)策略都會(huì)先在影子模式下跑一個(gè)流量切片比如5%觀察效果后再全量。3.3 經(jīng)驗(yàn)質(zhì)量評(píng)估與負(fù)反饋處理不是所有經(jīng)驗(yàn)都是好經(jīng)驗(yàn)。錯(cuò)誤的、過時(shí)的、偶然成功的經(jīng)驗(yàn)會(huì)污染記憶庫導(dǎo)致學(xué)習(xí)系統(tǒng)退化。必須建立經(jīng)驗(yàn)的質(zhì)量評(píng)估與淘汰機(jī)制。正反饋信號(hào)顯式反饋用戶點(diǎn)贊/點(diǎn)踩、評(píng)分、滿意度調(diào)查。隱式反饋任務(wù)完成后的會(huì)話是否自然結(jié)束而非用戶憤怒打斷、用戶是否進(jìn)行了后續(xù)深度追問表明興趣、任務(wù)是否被分享或保存?？陀^指標(biāo)任務(wù)完成度、結(jié)果準(zhǔn)確性如有標(biāo)準(zhǔn)答案、耗時(shí)降低。負(fù)反饋與經(jīng)驗(yàn)修正 當(dāng)一次任務(wù)被標(biāo)記為失敗或收到負(fù)反饋時(shí)不能簡單地刪除相關(guān)經(jīng)驗(yàn)。更精細(xì)的做法是根因分析關(guān)聯(lián)失敗任務(wù)與之前檢索到的經(jīng)驗(yàn)。是經(jīng)驗(yàn)本身錯(cuò)誤還是本次上下文有未考慮到的特殊因素經(jīng)驗(yàn)降權(quán)對(duì)導(dǎo)致失敗的經(jīng)驗(yàn)條目進(jìn)行降權(quán)處理例如降低其相似度搜索中的排名或增加一個(gè)“謹(jǐn)慎參考”的標(biāo)簽。經(jīng)驗(yàn)分裂如果發(fā)現(xiàn)某條經(jīng)驗(yàn)只在特定條件下有效可以將其分裂為兩條或多條更精確的經(jīng)驗(yàn)并附加適用條件。設(shè)置TTL生存時(shí)間為經(jīng)驗(yàn)條目設(shè)置過期時(shí)間特別是對(duì)于時(shí)效性強(qiáng)的信息如“查詢某API接口狀態(tài)”該接口可能已更新。我們實(shí)現(xiàn)了一個(gè)簡單的“經(jīng)驗(yàn)健康度”分?jǐn)?shù)綜合了成功引用次數(shù)、最近成功率、時(shí)間衰減等因素。定期運(yùn)行一個(gè)后臺(tái)任務(wù)對(duì)低健康度的經(jīng)驗(yàn)進(jìn)行審查、降權(quán)或歸檔。4. 實(shí)戰(zhàn)為一個(gè)客服Agent實(shí)現(xiàn)MemoHarness理論說再多不如動(dòng)手做一遍。假設(shè)我們有一個(gè)基于LLM的智能客服Agent它能處理產(chǎn)品咨詢、故障排查、訂單查詢等?，F(xiàn)在我們要給它裝上MemoHarness讓它能記住怎么更好地服務(wù)客戶。4.1 第一步定義決策點(diǎn)與日志埋點(diǎn)首先我們要明確Harness在哪些地方可以做決策、需要學(xué)習(xí)。分析客服Agent的流程意圖分類用戶進(jìn)來一句話Harness要決定將其分類到哪個(gè)業(yè)務(wù)板塊如“售前”、“售后”、“投訴”。流程路由分類后是直接由LLM生成回答還是調(diào)用“知識(shí)庫查詢工具”或是啟動(dòng)一個(gè)多輪的“故障診斷流程”工具選擇與參數(shù)化如果調(diào)用知識(shí)庫是用“關(guān)鍵詞搜索”工具還是“語義搜索”工具查詢的top_k參數(shù)設(shè)多少回復(fù)風(fēng)格調(diào)整針對(duì)不同類型的用戶如新用戶vs老用戶、普通用戶vsVIP回復(fù)的語氣、詳細(xì)程度是否要調(diào)整異常處理當(dāng)用戶問題超出知識(shí)范圍是坦誠告知“我不會(huì)”還是嘗試轉(zhuǎn)移到人工客服我們?cè)诖a中這些決策點(diǎn)前后加入日志記錄。例如在意圖分類后# 偽代碼示例 def classify_intent(user_query, session_history): # ... 原有的分類邏輯 ... intent llm_classify(user_query) # MemoHarness: 記錄決策點(diǎn) experience_logger.log_decision_point( decision_pointintent_classification, context{ query: user_query, history_summary: summarize_history(session_history) }, action_taken{ predicted_intent: intent, confidence: classification_confidence }, outcomeNone # 此時(shí)結(jié)果未知稍后補(bǔ)充 ) return intent4.2 第二步構(gòu)建經(jīng)驗(yàn)索引與檢索服務(wù)我們選擇Qdrant作為向量庫。經(jīng)驗(yàn)的特征向量我們使用經(jīng)過微調(diào)的bge-small-zh模型來生成因?yàn)樗鼘?duì)中文任務(wù)語義匹配效果很好。經(jīng)驗(yàn)抽取任務(wù)完成后從日志中組裝一個(gè)完整的ExperienceEntry。其中task_embedding的生成我們不是直接用用戶query而是用這樣一個(gè)模板生成摘要“用戶意圖[intent]。問題核心[從query中提取的關(guān)鍵實(shí)體和訴求]。對(duì)話歷史摘要[前三輪摘要]”。然后用這個(gè)摘要文本去生成向量。建立Qdrant集合Collectionfrom qdrant_client import QdrantClient, models client QdrantClient(hostlocalhost, port6333) client.create_collection( collection_namecustomer_service_experiences, vectors_configmodels.VectorParams(size384, distancemodels.Distance.COSINE), # bge-small-zh向量維度 )插入經(jīng)驗(yàn)將組裝好的ExperienceEntry其摘要的向量作為主向量連同其他元數(shù)據(jù)存為payload插入集合。檢索服務(wù)當(dāng)新的客服會(huì)話到達(dá)某個(gè)決策點(diǎn)時(shí)如意圖分類后用同樣的方法生成當(dāng)前上下文的摘要和向量去Qdrant中搜索。def retrieve_similar_experiences(query_vector, intent_filterNone, limit3): search_filters [] if intent_filter: search_filters models.Filter(must[models.FieldCondition(keymeta.intent, matchmodels.MatchValue(valueintent_filter))]) search_result client.search( collection_namecustomer_service_experiences, query_vectorquery_vector, query_filtersearch_filters, limitlimit ) return search_result # 返回相似的經(jīng)驗(yàn)點(diǎn)列表4.3 第三步將經(jīng)驗(yàn)應(yīng)用于決策優(yōu)化假設(shè)在“流程路由”決策點(diǎn)我們檢索到3條相似歷史經(jīng)驗(yàn)。經(jīng)驗(yàn)1用戶問“電腦開不了機(jī)”歷史路由到“故障診斷流程”最終成功解決用戶好評(píng)。經(jīng)驗(yàn)2用戶問“電腦開不了機(jī)”但歷史中直接調(diào)用“知識(shí)庫文章《電腦無法開機(jī)排查指南》”并推薦給用戶用戶反饋“太長不看”。經(jīng)驗(yàn)3用戶問“軟件安裝失敗”路由到“知識(shí)庫查詢”效果一般。我們的Harness可以設(shè)計(jì)這樣的策略# 偽代碼基于經(jīng)驗(yàn)的流程路由 def route_process(intent, user_query, retrieved_experiences): if intent troubleshooting: # 檢查歷史經(jīng)驗(yàn) successful_diagnosis [e for e in retrieved_experiences if e.outcome.success and e.action_taken start_diagnosis_flow] unsuccessful_kb [e for e in retrieved_experiences if not e.outcome.success and e.action_taken query_knowledge_base] if len(successful_diagnosis) len(unsuccessful_kb): # 歷史表明對(duì)于這類問題啟動(dòng)診斷流程更可能成功 return start_diagnosis_flow else: # 否則走默認(rèn)路徑或進(jìn)一步分析 return default_router(intent, user_query) # ... 其他意圖處理邏輯對(duì)于更復(fù)雜的決策比如回復(fù)風(fēng)格調(diào)整我們可以把檢索到的成功經(jīng)驗(yàn)中的“回復(fù)樣例”直接作為few-shot例子插入到給LLM生成回復(fù)的提示詞中讓LLM去模仿那種成功的語氣和內(nèi)容組織方式。4.4 第四步建立反饋閉環(huán)與經(jīng)驗(yàn)更新每次會(huì)話結(jié)束我們通過簡單的用戶滿意度評(píng)分1-5星或后續(xù)對(duì)話分析用戶是否說了“謝謝”或表達(dá)了不滿來收集反饋。這個(gè)反饋會(huì)關(guān)聯(lián)到本次會(huì)話中產(chǎn)生的所有經(jīng)驗(yàn)條目可能涉及多個(gè)決策點(diǎn)更新它們的outcome。我們?cè)O(shè)置了一個(gè)定時(shí)任務(wù)每天凌晨運(yùn)行執(zhí)行以下操作重新計(jì)算所有經(jīng)驗(yàn)條目的“健康度分?jǐn)?shù)”。將健康度低于閾值、或長時(shí)間未被成功引用的經(jīng)驗(yàn)標(biāo)記為“待審查”。對(duì)于連續(xù)導(dǎo)致負(fù)反饋的特定模式例如只要調(diào)用“工具A”處理“問題類型B”就失敗自動(dòng)生成一條“負(fù)向規(guī)則”注入到Harness的策略引擎中在未來決策時(shí)優(yōu)先規(guī)避。5. 避坑指南與進(jìn)階思考5.1 常見問題與排查技巧問題檢索到的經(jīng)驗(yàn)不相關(guān)導(dǎo)致決策被誤導(dǎo)。排查首先檢查task_embedding的生成質(zhì)量。用一個(gè)測(cè)試集手動(dòng)評(píng)估摘要是否能準(zhǔn)確代表任務(wù)核心。其次檢查向量搜索的相似度閾值是否合理可能相似度0.7以下的經(jīng)驗(yàn)就不該被采用。解決優(yōu)化摘要生成提示詞。引入多向量檢索例如同時(shí)用“用戶query”、“解析后的意圖”、“對(duì)話歷史最后一句”分別生成向量并做融合檢索。在元數(shù)據(jù)中加強(qiáng)過濾比如必須匹配相同的intent標(biāo)簽。問題經(jīng)驗(yàn)庫膨脹檢索速度變慢。排查監(jiān)控Qdrant的查詢延遲。檢查經(jīng)驗(yàn)條目是否沒有有效的TTL或淘汰機(jī)制導(dǎo)致大量過時(shí)、無效經(jīng)驗(yàn)堆積。解決實(shí)施經(jīng)驗(yàn)的自動(dòng)歸檔與淘汰。除了基于健康度還可以基于時(shí)間窗口只保留最近N個(gè)月的經(jīng)驗(yàn)。對(duì)于Qdrant可以考慮使用標(biāo)量量化或產(chǎn)品量化來壓縮向量在精度損失可接受的前提下提升速度。也可以按任務(wù)類型分集合存儲(chǔ)。問題學(xué)習(xí)到“壞習(xí)慣”比如總是用同一種簡單方式應(yīng)付復(fù)雜問題。排查檢查反饋信號(hào)是否片面。如果只有“任務(wù)完成”作為成功信號(hào)Agent可能會(huì)學(xué)習(xí)到“盡快結(jié)束對(duì)話”就是好的哪怕答案不準(zhǔn)確。解決設(shè)計(jì)更全面的獎(jiǎng)勵(lì)信號(hào)。結(jié)合任務(wù)完成度、答案準(zhǔn)確性可通過一個(gè)小型驗(yàn)證模型評(píng)估、用戶停留時(shí)間、是否引發(fā)后續(xù)有價(jià)值對(duì)話等多個(gè)維度。引入“探索-利用”平衡即使某個(gè)經(jīng)驗(yàn)成功率很高也以一個(gè)小概率嘗試新策略避免陷入局部最優(yōu)。問題系統(tǒng)變得不穩(wěn)定行為難以預(yù)測(cè)。排查這是“控制模式”下可能的風(fēng)險(xiǎn)。檢查是否有經(jīng)驗(yàn)在互相沖突或者某條經(jīng)驗(yàn)被過度加權(quán)。解決建立Harness決策的版本控制和回滾機(jī)制。任何新學(xué)習(xí)到的、要進(jìn)入“控制模式”的策略都必須經(jīng)過一個(gè)金絲雀發(fā)布階段即先對(duì)一小部分流量生效密切監(jiān)控核心指標(biāo)如任務(wù)成功率、用戶滿意度、平均處理時(shí)長確認(rèn)正向收益后再全量。同時(shí)保留一份“基線Harness”無學(xué)習(xí)能力的版本隨時(shí)可以切換回去。5.2 進(jìn)階方向從記憶到推理與規(guī)劃基礎(chǔ)的MemoHarness實(shí)現(xiàn)了“基于案例的推理”Case-Based Reasoning。但我們可以讓它更進(jìn)一步經(jīng)驗(yàn)抽象與泛化不要只存儲(chǔ)具體案例?？梢砸胍粋€(gè)“經(jīng)驗(yàn)分析器”定期對(duì)大量相似的成功/失敗案例進(jìn)行聚類和分析總結(jié)出抽象的規(guī)則或模式。例如從100次“成功解決打印機(jī)故障”的經(jīng)驗(yàn)中抽象出一條規(guī)則“當(dāng)問題描述包含‘連接’、‘找不到’等詞時(shí)應(yīng)優(yōu)先建議用戶檢查USB線纜和電源而非直接提供驅(qū)動(dòng)下載鏈接”。這種規(guī)則比具體案例更簡潔泛化能力更強(qiáng)。與規(guī)劃器Planner結(jié)合在復(fù)雜的多步任務(wù)中讓Harness不僅記憶單步動(dòng)作還記憶整個(gè)任務(wù)規(guī)劃圖的成功范例。當(dāng)新任務(wù)來時(shí)可以嘗試復(fù)用或適配整個(gè)規(guī)劃結(jié)構(gòu)而不僅僅是單點(diǎn)決策。多智能體協(xié)作記憶在由多個(gè)專項(xiàng)Agent組成的系統(tǒng)中建立一個(gè)共享的MemoHarness。讓Agent們不僅能從自己的經(jīng)驗(yàn)中學(xué)習(xí)還能從同伴的成功與失敗中學(xué)習(xí)實(shí)現(xiàn)跨任務(wù)的協(xié)同進(jìn)化。構(gòu)建一個(gè)真正智能的、能從經(jīng)驗(yàn)中學(xué)習(xí)的Agent系統(tǒng)MemoHarness提供了一個(gè)務(wù)實(shí)且強(qiáng)大的起點(diǎn)。它不追求替換LLM而是用工程化的方式彌補(bǔ)LLM在持久化記憶和穩(wěn)定行為迭代上的不足。這個(gè)過程本身就像在教導(dǎo)一個(gè)天賦異稟但缺乏閱歷的助手如何通過記錄每一次工作的得失最終成長為一位可靠、資深的專家。