1. 從“金魚記憶”到“海馬體”AI辦公Agent的下一場硬仗做AI Agent開發(fā)的朋友大概都有過這種體驗?zāi)慊藘芍軙r間用LangChain或者Hermes Agent搭了一個能自動處理工單的智能體演示的時候行云流水老板看了直點頭。結(jié)果一上生產(chǎn)環(huán)境第三天就翻車了——同一個客戶上周剛投訴過物流問題這周Agent又像第一次見面一樣重新問了一遍“請問您遇到了什么問題”。用戶當(dāng)場就炸了“你們這個AI是金魚嗎七秒鐘記憶”這不是段子這是過去一年我在三個企業(yè)級Agent項目里反復(fù)踩到的坑。Agent的“聰明”程度在推理能力已經(jīng)大幅拉齊的今天越來越不取決于它用的是什么模型而取決于它能不能記住、能不能在正確的時候想起正確的事。換句話說Agent的競爭已經(jīng)從“腦子好不好使”轉(zhuǎn)向了“記性好不好使”。標(biāo)題里說的“海馬體”就是干這個的。人腦的海馬體負(fù)責(zé)把短期記憶轉(zhuǎn)化為長期記憶負(fù)責(zé)在需要的時候把相關(guān)記憶提取出來。AI Agent要真正成為“數(shù)字員工”而不是一個每次都要重新培訓(xùn)的臨時工就必須有一套自己的記憶基礎(chǔ)設(shè)施。這篇文章我就把過去一年多在企業(yè)上下文管理、Agent記憶體系搭建上的實操經(jīng)驗從頭到尾拆一遍。不管你是剛接觸Agent開發(fā)的新手還是已經(jīng)在做多Agent協(xié)作的老手應(yīng)該都能從里面找到可以直接抄作業(yè)的東西。2. 為什么你的Agent總是“失憶”核心問題拆解2.1 Agent記憶的三個層次短期、長期、永久很多人一上來就問“怎么給Agent加記憶”但連記憶分幾層都沒搞清楚。我見過最離譜的案例是把所有對話歷史一股腦塞進(jìn)向量數(shù)據(jù)庫結(jié)果檢索的時候把三個月前用戶隨口說的一句“今天天氣不錯”給召回了Agent回復(fù)“是的今天天氣不錯請問您要辦理什么業(yè)務(wù)”——用戶直接關(guān)窗口。Agent的記憶體系我習(xí)慣按三個層次來設(shè)計這個分法跟認(rèn)知心理學(xué)里的分類基本對應(yīng)短期記憶Short-term Memory當(dāng)前會話窗口內(nèi)的上下文。這部分就是LLM的context window通常用滑動窗口或者摘要壓縮來管理。它的特點是生命周期短、容量有限、訪問速度極快。你不需要為它建數(shù)據(jù)庫但需要設(shè)計好“什么時候丟棄、什么時候壓縮”的策略。長期記憶Long-term Memory跨會話的、與特定用戶或?qū)嶓w相關(guān)的記憶。比如“張三上個月買了A產(chǎn)品”“李四對價格敏感”。這部分通常存在關(guān)系型數(shù)據(jù)庫或者帶元數(shù)據(jù)的向量庫里需要設(shè)計召回策略和時效性衰減。永久記憶Permanent MemoryAgent的“世界觀”和“技能庫”包括系統(tǒng)提示詞、工具定義、領(lǐng)域知識、業(yè)務(wù)規(guī)則。這部分相對靜態(tài)但需要版本管理和熱更新能力。注意很多團(tuán)隊把長期記憶和永久記憶混在一起導(dǎo)致每次業(yè)務(wù)規(guī)則更新都要重新embedding整個知識庫成本高得離譜。分層設(shè)計的第一原則就是變更頻率不同的東西絕對不要放在同一個存儲層。2.2 企業(yè)上下文的特殊性不是“記住”就行做To C的Agent和做To B的Agent記憶系統(tǒng)的設(shè)計邏輯完全不同。To C場景下用戶容忍度高記錯了頂多覺得“這AI不太聰明”。To B場景下Agent記錯一個合同條款、漏掉一個審批節(jié)點那是要出事故的。企業(yè)上下文有幾個硬性要求直接決定了你的記憶架構(gòu)權(quán)限隔離銷售部門的Agent絕對不能召回財務(wù)部門的敏感數(shù)據(jù)。這不是“最好有”是“必須有”。時效性三個月前的庫存數(shù)據(jù)和今天的數(shù)據(jù)權(quán)重完全不一樣。記憶召回必須帶時間衰減因子。可審計Agent為什么做出這個決策它當(dāng)時“想起”了哪條記憶這條記憶從哪來的出了問題要能追溯。一致性同一個事實在短期記憶、長期記憶、永久記憶里不能互相矛盾。這需要寫入時的沖突檢測機(jī)制。我見過一個團(tuán)隊Agent在回答客戶問題時引用了已經(jīng)作廢的退貨政策原因是那條舊政策還躺在向量庫里沒被清理?？蛻裟弥貓D來投訴團(tuán)隊花了三天才定位到問題。記憶系統(tǒng)不是“存進(jìn)去就完事”寫入、更新、刪除、沖突解決每一個環(huán)節(jié)都要設(shè)計。2.3 當(dāng)前主流方案的局限為什么RAG不夠用很多人覺得“RAG就是Agent的記憶”這個認(rèn)知在2023年可能還湊合放到現(xiàn)在做企業(yè)級Agent遠(yuǎn)遠(yuǎn)不夠。RAG的本質(zhì)是“檢索增強(qiáng)生成”它解決的是“知識獲取”問題不是“記憶管理”問題。區(qū)別在哪RAG是無狀態(tài)的——每次查詢都是獨立的它不關(guān)心你上次查了什么、結(jié)果對不對、用戶有沒有糾正。而記憶是有狀態(tài)的——它需要記錄“這個信息是什么時候?qū)懭氲摹薄皝碓词钦l”“可信度多少”“有沒有被更新過”。舉個具體例子用戶上周告訴Agent“我的收貨地址是A”這周說“改成B”。純RAG方案下兩條信息都在向量庫里檢索時可能同時召回Agent就懵了。而帶記憶管理的方案會在寫入B的時候把A標(biāo)記為“已失效”召回時只返回B。所以我的判斷是RAG是記憶系統(tǒng)的一個組件但不是記憶系統(tǒng)本身。真正的Agent記憶需要寫入管道、存儲分層、召回策略、沖突解決、生命周期管理這一整套東西。3. 給Agent裝“海馬體”記憶系統(tǒng)的架構(gòu)設(shè)計3.1 整體架構(gòu)四層記憶基礎(chǔ)設(shè)施我目前在生產(chǎn)環(huán)境用的架構(gòu)參考了傳統(tǒng)軟件的分層思想把記憶系統(tǒng)拆成四層。這個分層方式跟熱搜詞里提到的“表示層、應(yīng)用層、領(lǐng)域?qū)印⒒A(chǔ)設(shè)施層”是一個思路只是聚焦在記憶這個垂直領(lǐng)域。層級職責(zé)典型技術(shù)選型變更頻率接入層記憶讀寫API、權(quán)限校驗、格式轉(zhuǎn)換FastAPI/gRPC低邏輯層記憶抽取、沖突檢測、衰減計算、召回排序Python服務(wù)中存儲層向量存儲、關(guān)系存儲、圖存儲、緩存pgvector/Neo4j/Redis低治理層審計日志、版本管理、數(shù)據(jù)清理獨立服務(wù)低這個架構(gòu)的核心思想是把記憶的“寫”和“讀”徹底分開。寫入的時候做重處理抽取、去重、沖突檢測、打標(biāo)簽讀取的時候做輕處理只做召回和排序。這樣做的原因是寫入是低頻操作可以慢一點、重一點讀取是高頻操作必須快。我試過把沖突檢測放在讀取時做結(jié)果每次召回都要跑一遍全量比對延遲直接從200ms飆到2s。后來改成寫入時做沖突檢測讀取時只做簡單的時效性過濾延遲穩(wěn)定在150ms以內(nèi)。3.2 記憶寫入管道從對話流到結(jié)構(gòu)化記憶寫入管道是整個記憶系統(tǒng)最復(fù)雜的部分。原始對話流是一堆非結(jié)構(gòu)化文本直接存進(jìn)去就是垃圾進(jìn)垃圾出。我的做法是跑一個四步管道第一步記憶抽取。用一個小模型我常用Qwen2.5-7B或者GPT-4o-mini從對話中抽取“值得記住的事實”。不是每句話都值得記“你好”“謝謝”這種客套話直接丟棄。抽取的prompt大概長這樣EXTRACT_PROMPT 從以下對話中抽取值得長期記憶的事實。每條事實包含 - content: 事實內(nèi)容一句話 - entity: 涉及的主體用戶/產(chǎn)品/訂單等 - category: 分類偏好/事實/事件/規(guī)則 - confidence: 置信度0-1 - valid_until: 預(yù)計失效時間可選 只抽取明確陳述的事實不要推理。沒有值得記憶的內(nèi)容返回空列表。 對話 {dialogue} 第二步?jīng)_突檢測。新記憶寫入前先檢索同一entity下的已有記憶判斷是否沖突。沖突分三種直接矛盾地址A vs 地址B、時間更新舊政策 vs 新政策、粒度不同“喜歡紅色” vs “喜歡深紅色”。直接矛盾和時間更新把舊記憶標(biāo)記為superseded粒度不同的保留兩條但設(shè)置不同的優(yōu)先級。第三步向量化與元數(shù)據(jù)綁定。把記憶內(nèi)容embedding后存入向量庫同時把entity、category、confidence、timestamp、source等元數(shù)據(jù)存進(jìn)關(guān)系庫。這里的關(guān)鍵是元數(shù)據(jù)要足夠豐富否則召回時沒法做精細(xì)過濾。第四步寫入審計日志。每條記憶的寫入都要記錄誰寫的、什么時候?qū)懙?、從哪條對話抽出來的、和哪些舊記憶發(fā)生了沖突。出了問題要能一鍵回滾。實操心得抽取這一步的prompt一定要加“不要推理”這個約束。我早期沒加結(jié)果模型把“用戶問了三次價格”推理成“用戶對價格敏感”然后給用戶推了一堆優(yōu)惠券用戶覺得被冒犯了。記憶是事實不是判斷。3.3 記憶召回策略在正確的時候想起正確的事召回策略決定了Agent的“臨場反應(yīng)”。我的召回流程是“粗篩-精排-組裝”三步粗篩根據(jù)當(dāng)前對話的entity和意圖從向量庫和關(guān)系庫里拉出候選記憶。粗篩用混合檢索——向量相似度 元數(shù)據(jù)過濾 時間范圍過濾。比如當(dāng)前對話涉及“訂單12345”那就只召回entity為“訂單12345”或“用戶張三”的記憶。精排對候選記憶打分分?jǐn)?shù)由四部分組成score w1 * 語義相似度 w2 * 時效性衰減 w3 * 置信度 w4 * 來源權(quán)威性時效性衰減我用的是指數(shù)衰減decay exp(-λ * days_since_creation)λ根據(jù)記憶類型調(diào)整。用戶偏好類的λ小一點衰減慢庫存數(shù)據(jù)類的λ大一點衰減快。組裝把精排后的Top-K記憶格式化成prompt片段注入到Agent的context里。這里有個技巧不同類別的記憶用不同的格式。事實類用陳述句偏好類用“用戶傾向于...”規(guī)則類用“根據(jù)XX規(guī)定...”。格式統(tǒng)一反而會讓模型混淆。3.4 多Agent場景下的記憶共享與隔離多Agent協(xié)作的時候記憶系統(tǒng)會變得特別復(fù)雜。銷售Agent和客服Agent要不要共享記憶共享的話怎么保證權(quán)限不共享的話怎么保證一致性我的方案是“共享存儲 視圖隔離”。底層是統(tǒng)一的記憶存儲但每個Agent有自己的“記憶視圖”視圖定義了它能讀哪些entity、哪些category、哪些來源的記憶。視圖配置存在治理層可以動態(tài)調(diào)整。舉個例子客服Agent的視圖是entity in [當(dāng)前用戶, 當(dāng)前訂單] AND category in [偏好, 歷史工單]銷售Agent的視圖是entity in [當(dāng)前用戶, 當(dāng)前商機(jī)] AND category in [偏好, 購買歷史]。兩個Agent共享底層存儲但看到的記憶不一樣?？鏏gent的記憶傳遞通過“記憶引用”實現(xiàn)。Agent A在完成任務(wù)后把關(guān)鍵記憶的ID傳給Agent BAgent B根據(jù)自己的視圖決定要不要讀取。這樣既保證了協(xié)作又保證了隔離。4. 實操落地從零搭建Agent記憶模塊4.1 技術(shù)選型別一上來就上重型武器我見過太多團(tuán)隊Agent還沒跑通先上了Neo4j Milvus Kafka Flink的全家桶結(jié)果維護(hù)成本比開發(fā)成本還高。技術(shù)選型的原則是從簡到繁按需升級。我的推薦路徑階段一驗證期PostgreSQL pgvector。一張表存記憶內(nèi)容和元數(shù)據(jù)pgvector做向量檢索。夠用運維簡單團(tuán)隊都會。階段二成長期PostgreSQL pgvector Redis。Redis做熱點記憶緩存把高頻召回的Top-100記憶緩存在內(nèi)存里召回延遲從200ms降到20ms。階段三成熟期引入圖數(shù)據(jù)庫Neo4j或NebulaGraph處理記憶之間的關(guān)聯(lián)關(guān)系。比如“用戶A買了產(chǎn)品B產(chǎn)品B屬于品類C品類C有促銷活動D”這種多跳關(guān)系用圖查比向量查高效得多。避坑提醒不要用純向量庫做記憶存儲。向量庫的元數(shù)據(jù)過濾能力普遍偏弱而記憶召回恰恰極度依賴元數(shù)據(jù)過濾。pgvector的WHERE子句比大多數(shù)向量庫的filter都靈活。4.2 核心代碼記憶寫入與召回的完整實現(xiàn)下面是我在生產(chǎn)環(huán)境用的簡化版實現(xiàn)基于FastAPI PostgreSQL pgvector。表結(jié)構(gòu)設(shè)計CREATE TABLE agent_memory ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), content TEXT NOT NULL, embedding vector(1536), entity_type VARCHAR(50), entity_id VARCHAR(100), category VARCHAR(50), confidence FLOAT DEFAULT 1.0, source VARCHAR(200), status VARCHAR(20) DEFAULT active, -- active/superseded/deleted superseded_by UUID, valid_from TIMESTAMP DEFAULT NOW(), valid_until TIMESTAMP, created_at TIMESTAMP DEFAULT NOW(), metadata JSONB ); CREATE INDEX idx_memory_entity ON agent_memory(entity_type, entity_id); CREATE INDEX idx_memory_category ON agent_memory(category); CREATE INDEX idx_memory_status ON agent_memory(status); CREATE INDEX idx_memory_embedding ON agent_memory USING ivfflat (embedding vector_cosine_ops) WITH (lists 100);寫入接口async def write_memory(dialogue: str, entity: dict, source: str): # 1. 抽取 facts await extract_facts(dialogue) if not facts: return [] written [] for fact in facts: # 2. 沖突檢測 conflicts await detect_conflicts(fact, entity) for old in conflicts: if old[conflict_type] supersede: await mark_superseded(old[id]) # 3. 向量化 embedding await embed(fact[content]) # 4. 寫入 memory_id await db.insert(agent_memory, { content: fact[content], embedding: embedding, entity_type: entity[type], entity_id: entity[id], category: fact[category], confidence: fact[confidence], source: source, metadata: fact.get(metadata, {}) }) written.append(memory_id) # 5. 審計 await audit_log(memory_write, { source: source, entity: entity, memory_ids: written }) return written召回接口async def recall_memory(query: str, entity: dict, top_k: int 10): query_embedding await embed(query) # 粗篩向量相似度 元數(shù)據(jù)過濾 candidates await db.fetch_all( SELECT id, content, category, confidence, created_at, metadata, 1 - (embedding $1) AS similarity FROM agent_memory WHERE status active AND entity_type $2 AND entity_id $3 AND (valid_until IS NULL OR valid_until NOW()) ORDER BY embedding $1 LIMIT 50 , query_embedding, entity[type], entity[id]) # 精排綜合打分 scored [] for c in candidates: days (now() - c[created_at]).days decay math.exp(-0.01 * days) score (0.5 * c[similarity] 0.2 * decay 0.2 * c[confidence] 0.1 * source_weight(c[metadata].get(source))) scored.append({**c, score: score}) scored.sort(keylambda x: x[score], reverseTrue) return scored[:top_k]4.3 參數(shù)調(diào)優(yōu)衰減系數(shù)、召回數(shù)量、置信度閾值參數(shù)調(diào)優(yōu)是記憶系統(tǒng)從“能用”到“好用”的關(guān)鍵。我踩過的坑包括衰減太快導(dǎo)致Agent忘了用戶偏好衰減太慢導(dǎo)致Agent引用過期信息召回太多導(dǎo)致context爆炸召回太少導(dǎo)致信息不足。我的經(jīng)驗值基于企業(yè)客服場景其他場景需要調(diào)整參數(shù)推薦值調(diào)整邏輯衰減系數(shù)λ偏好類0.005用戶偏好變化慢半衰期約140天衰減系數(shù)λ事實類0.02事實類信息變化快半衰期約35天衰減系數(shù)λ規(guī)則類0.001業(yè)務(wù)規(guī)則相對穩(wěn)定半衰期約700天召回數(shù)量Top-K8-12太少信息不足太多干擾模型置信度閾值0.6低于0.6的記憶不召回避免噪聲相似度閾值0.7低于0.7的候選直接丟棄調(diào)參的方法論是先設(shè)一個保守值然后根據(jù)bad case反向調(diào)整。我一般會收集一周的bad case分類統(tǒng)計是“該記的沒記住”還是“不該記的記住了”前者調(diào)低閾值后者調(diào)高閾值。4.4 與Agent框架的集成以Hermes Agent為例Hermes Agent是我最近用得比較多的框架它的插件機(jī)制很適合掛載記憶模塊。集成方式是在Agent初始化時注入一個MemoryProviderfrom hermes_agent import Agent, MemoryProvider class CustomMemoryProvider(MemoryProvider): async def on_turn_start(self, context): # 每輪對話開始前召回相關(guān)記憶 memories await recall_memory( querycontext.current_message, entitycontext.entity, top_k10 ) context.inject_memories(memories) async def on_turn_end(self, context): # 每輪對話結(jié)束后寫入新記憶 await write_memory( dialoguecontext.turn_dialogue, entitycontext.entity, sourcefsession:{context.session_id} ) agent Agent( modelgpt-4o, memory_providerCustomMemoryProvider(), tools[...] )這個集成的關(guān)鍵是不要阻塞主流程。寫入操作我全部改成異步任務(wù)丟到消息隊列里慢慢處理。召回操作設(shè)了200ms超時超時就返回空列表讓Agent先跑起來不要因為記憶系統(tǒng)拖慢整體響應(yīng)。5. 踩坑實錄記憶系統(tǒng)常見問題與排查5.1 記憶污染Agent記住了錯誤信息這是最危險的問題。用戶隨口說了一句“我聽說你們要漲價”Agent記成了“用戶確認(rèn)漲價信息”然后在后續(xù)對話里主動跟其他用戶說“我們即將漲價”。這種事故一旦發(fā)生公關(guān)成本極高。根因抽取模型沒有區(qū)分“用戶陳述的事實”和“用戶引用的傳聞”。我的修復(fù)方案是在抽取prompt里加了來源標(biāo)注把記憶分成“用戶確認(rèn)”“用戶推測”“第三方信息”三類只有“用戶確認(rèn)”類的記憶才允許在對外回復(fù)中引用。排查方法定期跑記憶審計隨機(jī)抽樣100條記憶人工檢查準(zhǔn)確性。我一般每周跑一次錯誤率超過2%就要調(diào)整抽取prompt。5.2 召回失效該想起的沒想起來用戶明明上周提供了訂單號這周Agent又問了一遍。排查下來發(fā)現(xiàn)上周的記憶entity_id存的是“用戶張三”這周對話的entity_id是“訂單12345”粗篩的時候按entity_id過濾直接把記憶過濾掉了。修復(fù)方案entity設(shè)計要支持多對多。一條記憶可以關(guān)聯(lián)多個entity召回時按entity集合做交集或并集。我在存儲層加了一張memory_entity_relation表一條記憶可以關(guān)聯(lián)用戶、訂單、產(chǎn)品多個實體。5.3 性能瓶頸記憶檢索拖慢響應(yīng)記憶系統(tǒng)上線后Agent的P99延遲從800ms漲到3s。排查發(fā)現(xiàn)兩個問題一是向量檢索沒有建索引全表掃描二是每次召回都實時計算embedding沒有緩存。優(yōu)化措施pgvector建ivfflat索引檢索從800ms降到50ms高頻query的embedding緩存到Redis命中率約40%召回結(jié)果緩存5分鐘同一會話內(nèi)的連續(xù)對話直接讀緩存優(yōu)化后P99延遲回到1.2s雖然比無記憶版本慢但在可接受范圍內(nèi)。5.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案Agent反復(fù)問同樣的問題召回失效或?qū)懭胧〔閷徲嬋罩敬_認(rèn)記憶是否寫入檢查entity映射修復(fù)召回過濾條件Agent引用過期信息舊記憶未標(biāo)記失效查記憶的status和valid_until加強(qiáng)沖突檢測寫入時標(biāo)記superseded響應(yīng)延遲突然升高向量檢索無索引或緩存失效查慢查詢?nèi)罩窘ㄋ饕泳彺嬖O(shè)超時不同Agent回答矛盾記憶視圖配置錯誤對比各Agent的視圖配置統(tǒng)一底層存儲修正視圖權(quán)限記憶庫無限膨脹缺少清理機(jī)制統(tǒng)計記憶總量和增長率設(shè)TTL定期歸檔低價值記憶獨家避坑技巧記憶系統(tǒng)的監(jiān)控比功能更重要。我必看的三個指標(biāo)是寫入成功率、召回命中率、記憶準(zhǔn)確率。寫入成功率低于99%說明管道有問題召回命中率低于60%說明召回策略有問題準(zhǔn)確率低于95%說明抽取有問題。這三個指標(biāo)我配了告警異常時第一時間處理。6. 記憶系統(tǒng)的未來從“海馬體”到“前額葉”把記憶系統(tǒng)跑通之后我發(fā)現(xiàn)一個有意思的現(xiàn)象Agent有了記憶行為模式會發(fā)生質(zhì)變。它不再是一個“每次都要重新理解上下文”的工具而開始表現(xiàn)出某種“連續(xù)性”——它會記得上次沒解決的問題會主動跟進(jìn)會在用戶提到相關(guān)話題時關(guān)聯(lián)歷史信息。但這只是開始。記憶系統(tǒng)解決的是“記住”的問題下一步要解決的是“用記憶做決策”的問題。人腦的海馬體只負(fù)責(zé)記憶的形成和提取真正做決策的是前額葉皮層。Agent的“前額葉”是什么我的判斷是基于記憶的推理和規(guī)劃能力。具體來說下一步要做的幾件事記憶的主動遺忘。不是所有記憶都值得保留。人腦會主動遺忘低價值信息Agent也需要。我正在實驗的方案是給每條記憶算一個“價值分”價值分 被召回次數(shù) × 召回后任務(wù)成功率。價值分低于閾值的記憶自動歸檔或刪除。記憶的抽象與泛化。從“用戶張三上周買了A產(chǎn)品”抽象出“用戶張三對A品類感興趣”從具體事件抽象出模式。這需要引入歸納推理能力目前還在探索階段?？鏏gent的記憶協(xié)同。多個Agent共享記憶池但各自有不同的“專業(yè)視角”。銷售Agent從記憶里看到的是商機(jī)客服Agent看到的是服務(wù)歷史風(fēng)控Agent看到的是異常模式。同一份記憶不同Agent讀出不同價值。記憶的可解釋性。Agent做出決策時要能說清楚“我是基于哪幾條記憶做出的這個判斷”。這在企業(yè)場景下是剛需尤其是涉及合規(guī)和審計的業(yè)務(wù)。我在實際項目里的體會是記憶系統(tǒng)的投入產(chǎn)出比遠(yuǎn)超預(yù)期。一個做了記憶管理的Agent用戶滿意度能提升30%以上任務(wù)完成率提升20%左右。而且隨著記憶積累Agent的表現(xiàn)會越來越好形成正向循環(huán)。這跟傳統(tǒng)軟件“上線即巔峰之后靠迭代”的模式完全不同。最后分享一個我在調(diào)參時發(fā)現(xiàn)的小技巧記憶的召回數(shù)量不要固定要根據(jù)對話的復(fù)雜度動態(tài)調(diào)整。簡單問答召回3-5條就夠復(fù)雜任務(wù)規(guī)劃召回15-20條。判斷復(fù)雜度的方法很簡單——看當(dāng)前對話的token長度和意圖分類長度超過200token或意圖為“規(guī)劃類”的自動提高召回數(shù)量。這個改動讓Agent在復(fù)雜任務(wù)上的表現(xiàn)提升了15%左右而簡單任務(wù)的延遲沒有明顯增加。