1. 從能跑通到敢上線企業(yè)私有化 Agent 的真實(shí)分水嶺大多數(shù)團(tuán)隊(duì)做 Agent 的路徑都差不多拿一個(gè)開源框架接上公司內(nèi)部的大模型寫幾個(gè)工具函數(shù)跑通一個(gè)查數(shù)據(jù)、調(diào)接口、生成報(bào)告的 Demo然后興沖沖地拿去給業(yè)務(wù)方看。Demo 確實(shí)能跑業(yè)務(wù)方也覺得新鮮但一旦問到這東西能不能上生產(chǎn)、能不能給全公司用、數(shù)據(jù)會(huì)不會(huì)泄露、并發(fā)上來會(huì)不會(huì)崩場面往往就冷下來了。這個(gè)落差不是工程能力的問題而是架構(gòu)定位的問題。Demo 階段的 Agent 是一個(gè)無狀態(tài)的一次性腳本而企業(yè)私有化場景下的 Agent 是一個(gè)有記憶、有邊界、有治理的長期運(yùn)行系統(tǒng)。這兩者之間的差距就是 Memory OS 要解決的事情。所謂 Memory OS不是某個(gè)具體產(chǎn)品而是一種架構(gòu)思路把 Agent 的記憶從散落在 prompt 拼接、向量庫查詢、會(huì)話緩存里的碎片抽象成一個(gè)獨(dú)立的、可治理的、有生命周期的系統(tǒng)層。它和操作系統(tǒng)管理內(nèi)存的邏輯很像——進(jìn)程不直接操作物理內(nèi)存而是通過虛擬內(nèi)存、頁表、換入換出機(jī)制來使用內(nèi)存Agent 也不應(yīng)該直接往 prompt 里塞歷史記錄而是通過一個(gè)統(tǒng)一的記憶管理層來讀寫。為什么企業(yè)私有化場景特別需要這一層三個(gè)現(xiàn)實(shí)約束擺在那里數(shù)據(jù)不能出內(nèi)網(wǎng)。這意味著你不能依賴任何云端記憶服務(wù)所有記憶的存儲(chǔ)、檢索、淘汰都必須在自己的基礎(chǔ)設(shè)施里完成。多租戶、多部門共用。銷售部門的 Agent 和研發(fā)部門的 Agent 可能跑在同一套集群上記憶必須隔離不能串味。審計(jì)與合規(guī)。企業(yè)要知道 Agent 記住了什么、為什么記住、什么時(shí)候會(huì)忘掉這在消費(fèi)級(jí)產(chǎn)品里幾乎沒人關(guān)心但在企業(yè)里是硬需求。我見過太多團(tuán)隊(duì)在 Demo 階段用一個(gè)大字典存會(huì)話歷史上線后隨著用戶量增長內(nèi)存暴漲、檢索變慢、上下文超長導(dǎo)致模型輸出質(zhì)量斷崖式下跌。這些問題不是靠換個(gè)更強(qiáng)的模型能解決的根子在于缺少一個(gè) Memory OS 層。這篇文章會(huì)圍繞企業(yè)私有化 Agent 的設(shè)計(jì)與實(shí)現(xiàn)展開重點(diǎn)講清楚 Memory OS 這一層的設(shè)計(jì)動(dòng)機(jī)、核心組件、控制平面的職責(zé)邊界以及在真實(shí)落地中踩過的坑。適合正在做企業(yè)級(jí) Agent 平臺(tái)、或者準(zhǔn)備把 Agent 從 Demo 推向生產(chǎn)的同學(xué)參考。全文不涉及任何具體云服務(wù)選型只講架構(gòu)和實(shí)現(xiàn)思路你可以根據(jù)自己的技術(shù)棧做映射。2. 為什么把歷史記錄塞進(jìn) prompt這條路走不通2.1 上下文窗口不是記憶它只是工作臺(tái)很多人對(duì) Agent 記憶的理解停留在把之前的對(duì)話拼到 prompt 里。這個(gè)做法在小規(guī)模場景下能用但它混淆了兩個(gè)概念上下文窗口context window和記憶memory。上下文窗口是模型一次推理能看到的 token 范圍它是有限的、臨時(shí)的、每次推理都要重新計(jì)算的。而記憶是跨會(huì)話、跨任務(wù)、長期存在的知識(shí)。把記憶等同于上下文就像把辦公桌等同于整個(gè)倉庫——桌子再大也放不下所有東西而且每次開工都要把倉庫里的貨搬到桌上效率極低。實(shí)測數(shù)據(jù)很能說明問題一個(gè) 128K 上下文窗口的模型當(dāng)輸入 token 超過 60K 之后對(duì)中間位置信息的召回率會(huì)明顯下降這就是業(yè)內(nèi)常說的lost in the middle現(xiàn)象。你把 100 輪對(duì)話全塞進(jìn)去模型反而記不住關(guān)鍵的那一句。所以正確的做法是上下文窗口只放當(dāng)前任務(wù)真正需要的那部分記憶其余的存在 Memory OS 里按需檢索。2.2 企業(yè)場景下記憶的四種類型在企業(yè)私有化 Agent 里記憶不是單一維度的。我一般把它拆成四類每類的存儲(chǔ)策略、生命周期、檢索方式都不一樣記憶類型內(nèi)容舉例生命周期存儲(chǔ)選型檢索方式會(huì)話記憶當(dāng)前對(duì)話的輪次、臨時(shí)變量分鐘到小時(shí)級(jí)內(nèi)存 Redis按 session_id 直取用戶記憶用戶偏好、歷史操作習(xí)慣天到月級(jí)關(guān)系庫 向量庫混合檢索知識(shí)記憶企業(yè)文檔、規(guī)章制度、產(chǎn)品手冊(cè)長期隨版本更新向量庫 對(duì)象存儲(chǔ)語義檢索任務(wù)記憶任務(wù)執(zhí)行軌跡、中間結(jié)果、失敗原因任務(wù)周期內(nèi)關(guān)系庫 日志系統(tǒng)按 task_id 回溯這四類記憶如果混在一起存后果就是檢索時(shí)噪聲極大、淘汰策略無法統(tǒng)一、權(quán)限控制形同虛設(shè)。Memory OS 的第一個(gè)職責(zé)就是把這四類記憶在存儲(chǔ)層就分開各自有獨(dú)立的 schema、TTL 和索引策略。2.3 一個(gè)反直覺的結(jié)論記憶越多Agent 越笨新手常有的直覺是記得越多越好但實(shí)際恰恰相反。我做過一組對(duì)比測試同一個(gè)客服 Agent在記憶庫里存 500 條歷史工單 vs 存 5000 條歷史工單前者的問題解決率反而高出 12 個(gè)百分點(diǎn)。原因是檢索出來的相關(guān)記憶里混入了大量弱相關(guān)甚至誤導(dǎo)性的內(nèi)容模型被帶偏了。這引出了 Memory OS 的核心設(shè)計(jì)原則之一記憶的價(jià)值不在于數(shù)量而在于信噪比。系統(tǒng)必須有能力判斷這條記憶現(xiàn)在該不該被召回而不是無腦地把 top-k 相似結(jié)果全丟給模型。后面講控制平面時(shí)會(huì)詳細(xì)說這個(gè)判斷邏輯怎么落地。3. Memory OS 的分層架構(gòu)把記憶當(dāng)成一等公民3.1 四層結(jié)構(gòu)接入層、控制層、存儲(chǔ)層、治理層Memory OS 不是一個(gè)單體組件而是一個(gè)分層系統(tǒng)。我在實(shí)際項(xiàng)目里把它拆成四層每層職責(zé)清晰、可獨(dú)立演進(jìn)接入層Access Layer負(fù)責(zé)和 Agent 運(yùn)行時(shí)對(duì)接提供統(tǒng)一的讀寫 API。Agent 不需要知道記憶存在哪里、用什么索引只需要調(diào)用remember()、recall()、forget()這幾個(gè)語義化接口。這一層要做協(xié)議適配比如有的 Agent 框架用 function call有的用 SDK 直調(diào)接入層要能同時(shí)支持?？刂茖覥ontrol Plane是 Memory OS 的大腦也是標(biāo)題里特別強(qiáng)調(diào)的部分。它負(fù)責(zé)記憶的寫入決策、檢索編排、淘汰策略、權(quán)限校驗(yàn)?？刂茖硬淮鏀?shù)據(jù)只做決策。這個(gè)區(qū)分很重要——把決策和存儲(chǔ)分離才能讓存儲(chǔ)層自由替換今天用 pgvector明天換 Milvus控制層不用改。存儲(chǔ)層Storage Layer是真正落地?cái)?shù)據(jù)的地方包括向量庫、關(guān)系庫、對(duì)象存儲(chǔ)、緩存。存儲(chǔ)層要支持多后端因?yàn)椴煌洃涱愋偷拇鎯?chǔ)需求差異很大。治理層Governance Layer負(fù)責(zé)審計(jì)、脫敏、配額、監(jiān)控。企業(yè)場景下這層不能省它決定了系統(tǒng)能不能通過安全審查。3.2 控制平面到底控制什么控制平面這個(gè)詞容易讓人聯(lián)想到服務(wù)網(wǎng)格里的控制平面但 Memory OS 的控制平面職責(zé)更聚焦。它主要管四件事寫入決策不是所有對(duì)話內(nèi)容都值得記住?？刂破矫嬉袛嘁粭l新信息是值得長期記憶還是用完即棄。判斷依據(jù)包括信息的新穎度和已有記憶的重復(fù)度、重要性是否包含用戶明確表達(dá)的偏好、關(guān)鍵事實(shí)、時(shí)效性是否是臨時(shí)狀態(tài)。我一般用一個(gè)輕量的分類模型或者規(guī)則引擎來做這個(gè)判斷規(guī)則引擎在早期更可控。檢索編排一次 recall 請(qǐng)求進(jìn)來控制平面要決定查哪些記憶類型、用什么檢索策略、召回多少條、怎么排序、怎么去重。這里的關(guān)鍵是多路召回 重排向量檢索負(fù)責(zé)語義相似關(guān)鍵詞檢索負(fù)責(zé)精確匹配時(shí)間衰減因子負(fù)責(zé)新鮮度最后用一個(gè)重排模型統(tǒng)一打分。淘汰策略記憶不能無限增長?？刂破矫嬉獔?zhí)行 TTL 淘汰、容量淘汰、重要性淘汰。重要性淘汰最復(fù)雜需要給每條記憶維護(hù)一個(gè)價(jià)值分長期未被召回、且重要性低的記憶優(yōu)先淘汰。權(quán)限校驗(yàn)每次讀寫都要校驗(yàn)調(diào)用方有沒有權(quán)限訪問目標(biāo)記憶。企業(yè)里不同部門的 Agent 記憶必須隔離跨部門共享需要顯式授權(quán)。3.3 為什么控制平面要獨(dú)立于 Agent 運(yùn)行時(shí)一個(gè)常見的錯(cuò)誤設(shè)計(jì)是把記憶邏輯寫在 Agent 的 prompt 編排代碼里。這樣做的后果是每個(gè) Agent 各寫一套記憶邏輯行為不一致記憶策略調(diào)整要改所有 Agent無法統(tǒng)一審計(jì)。把控制平面獨(dú)立出來Agent 運(yùn)行時(shí)只負(fù)責(zé)我要什么記憶控制平面負(fù)責(zé)給你什么、為什么給你。這個(gè)解耦帶來的好處在系統(tǒng)演進(jìn)時(shí)會(huì)非常明顯——你想換檢索算法、想加新的記憶類型、想調(diào)整淘汰策略都只動(dòng)控制平面一處。4. 記憶的寫入、檢索與淘汰三個(gè)核心鏈路的實(shí)現(xiàn)細(xì)節(jié)4.1 寫入鏈路從原始對(duì)話到結(jié)構(gòu)化記憶寫入不是簡單地把文本存進(jìn)去。一條原始對(duì)話要經(jīng)過抽取、結(jié)構(gòu)化、去重、打分四個(gè)步驟才能變成一條合格的記憶。抽取從對(duì)話里識(shí)別出值得記憶的片段。比如用戶說我們公司報(bào)銷標(biāo)準(zhǔn)是每天 300 元這是一個(gè)事實(shí)型記憶用戶說以后報(bào)告都用 PDF 格式給我這是一個(gè)偏好型記憶。抽取可以用規(guī)則正則匹配關(guān)鍵句式 小模型分類哪些句子包含可記憶信息組合實(shí)現(xiàn)。結(jié)構(gòu)化把抽取出的片段轉(zhuǎn)成統(tǒng)一 schema。我用的 schema 大致是這樣{ memory_id: uuid, tenant_id: dept_001, user_id: user_123, type: preference, content: 用戶偏好 PDF 格式的報(bào)告, embedding: [0.12, -0.34, ...], metadata: { source_session: sess_abc, created_at: 2025-01-15T10:30:00Z, confidence: 0.87, importance: 0.75 }, ttl: 7776000 }去重新記憶寫入前先做一次相似度檢索如果和已有記憶相似度超過閾值我一般設(shè) 0.92就合并而不是新增。合并策略是保留更新的內(nèi)容、累加 importance 分、更新 last_accessed 時(shí)間。打分給每條記憶算一個(gè)初始 importance 分后續(xù)會(huì)根據(jù)召回頻率動(dòng)態(tài)調(diào)整。初始分的計(jì)算因子包括信息類型權(quán)重偏好 事實(shí) 閑聊、用戶顯式程度明確說記住的加分、內(nèi)容長度過短的降權(quán)。4.2 檢索鏈路多路召回與重排的工程實(shí)現(xiàn)檢索是 Memory OS 里最影響體驗(yàn)的環(huán)節(jié)。單靠向量檢索是不夠的原因有三向量檢索對(duì)精確匹配比如訂單號(hào)、人名不敏感向量檢索無法感知時(shí)間新鮮度向量檢索的 top-k 里噪聲多。我的做法是三路召回后重排向量召回用 embedding 做語義檢索召回 top 20。關(guān)鍵詞召回用 BM25 或倒排索引做精確匹配召回 top 20。時(shí)間召回按 last_accessed 和 created_at 排序召回最近 top 10。三路結(jié)果合并去重后進(jìn)入重排階段。重排用一個(gè)輕量模型可以是 cross-encoder也可以是規(guī)則加權(quán)綜合語義相似度、時(shí)間衰減、importance 分、記憶類型匹配度四個(gè)因子打分。時(shí)間衰減用指數(shù)衰減函數(shù)decay_score exp(-λ * days_since_created)λ 的取值很關(guān)鍵我一般設(shè) 0.01意味著 70 天前的記憶權(quán)重衰減到約 0.5。這個(gè)值要根據(jù)業(yè)務(wù)調(diào)整客服場景可以衰減快一點(diǎn)知識(shí)庫場景衰減慢一點(diǎn)。重排后取 top 5 到 top 8 條記憶注入上下文。這個(gè)數(shù)量不是拍腦袋定的而是根據(jù)模型上下文預(yù)算反推的——假設(shè)給記憶留 2000 token 預(yù)算每條記憶平均 250 token那就是 8 條。4.3 淘汰鏈路讓記憶系統(tǒng)保持新陳代謝沒有淘汰機(jī)制的記憶系統(tǒng)最終會(huì)變成一個(gè)又慢又吵的垃圾場。淘汰策略我分三層執(zhí)行第一層TTL 硬淘汰。會(huì)話記憶設(shè) 24 小時(shí) TTL任務(wù)記憶設(shè) 7 天用戶記憶設(shè) 90 天知識(shí)記憶不設(shè) TTL 但隨文檔版本更新。TTL 到期的記憶直接刪除這是最簡單也最有效的控制手段。第二層容量淘汰。每個(gè)租戶設(shè)記憶容量上限超限時(shí)按 importance 分從低到高淘汰。這里要注意淘汰前先做一次歸檔——把即將刪除的記憶轉(zhuǎn)存到冷存儲(chǔ)保留審計(jì)能力。第三層價(jià)值淘汰。定期我一般每周跑一次掃描所有記憶計(jì)算價(jià)值分value importance * 0.4 recall_frequency * 0.4 recency * 0.2價(jià)值分低于閾值的記憶進(jìn)入待淘汰隊(duì)列觀察一周后如果仍未被召回才真正刪除。這個(gè)觀察期設(shè)計(jì)能避免誤刪那些低頻但關(guān)鍵的記憶比如一年只用一次的合規(guī)條款。5. 私有化部署下的隔離、審計(jì)與性能取舍5.1 多租戶隔離從存儲(chǔ)到檢索的全鏈路企業(yè)私有化場景幾乎一定是多租戶的。隔離做不好輕則數(shù)據(jù)串味重則安全事故。我的隔離策略是全鏈路的存儲(chǔ)隔離向量庫按 tenant_id 分 collection 或 partition關(guān)系庫按 tenant_id 分 schema 或加行級(jí)過濾。檢索隔離所有檢索請(qǐng)求強(qiáng)制帶上 tenant_id 過濾條件這個(gè)過濾在控制平面統(tǒng)一注入不允許 Agent 自己傳。緩存隔離Redis 的 key 前綴帶 tenant_id避免緩存穿透。配額隔離每個(gè)租戶獨(dú)立的記憶容量、QPS、token 預(yù)算。這里有個(gè)容易忽略的點(diǎn)embedding 模型如果是共享的向量空間是共享的。這意味著理論上可以通過向量相似度反推其他租戶的數(shù)據(jù)。嚴(yán)格的隔離方案是每個(gè)租戶獨(dú)立的 embedding 空間但成本太高。折中方案是在檢索時(shí)強(qiáng)制 tenant 過濾并且在向量庫層面做物理隔離不同 collection這樣即使向量空間共享也無法跨租戶檢索。5.2 審計(jì)企業(yè)場景繞不開的一環(huán)審計(jì)要回答三個(gè)問題誰在什么時(shí)候?qū)懥耸裁从洃?、誰在什么時(shí)候讀了什么記憶、記憶什么時(shí)候被刪除的。實(shí)現(xiàn)上就是一張 append-only 的審計(jì)日志表記錄所有讀寫操作。日志本身也要脫敏不能把記憶原文直接寫進(jìn)去一般存 hash 和元數(shù)據(jù)。審計(jì)日志的存儲(chǔ)成本不低我的做法是熱數(shù)據(jù)存 30 天之后轉(zhuǎn)冷存儲(chǔ)保留 1 年。查詢接口只對(duì)管理員開放普通用戶只能查自己的操作記錄。5.3 性能取舍延遲、成本、準(zhǔn)確率的三方博弈Memory OS 的性能優(yōu)化本質(zhì)是在延遲、成本、準(zhǔn)確率之間找平衡點(diǎn)。幾個(gè)實(shí)測有效的取舍檢索延遲 vs 召回率三路召回全開P99 延遲大概在 200ms 左右如果只開向量召回延遲能降到 80ms但召回率下降約 15%。我的建議是默認(rèn)全開對(duì)延遲敏感的場景比如實(shí)時(shí)對(duì)話可以降級(jí)到兩路。embedding 成本 vs 檢索質(zhì)量每次寫入都要算 embedding這是主要成本。優(yōu)化手段是批量寫入 緩存相同內(nèi)容不重復(fù)算。另外可以用小模型做初篩只對(duì)候選內(nèi)容算高質(zhì)量 embedding。記憶條數(shù) vs 上下文質(zhì)量前面說過召回 5-8 條是甜點(diǎn)區(qū)。我做過測試召回 3 條時(shí)準(zhǔn)確率不夠召回 15 條時(shí)模型開始被噪聲干擾8 條左右綜合表現(xiàn)最好。6. 落地過程中踩過的坑與排查思路6.1 記憶串味一個(gè)跨租戶污染的排查過程上線初期遇到過一個(gè)詭異問題A 部門的 Agent 偶爾會(huì)引用 B 部門的內(nèi)部術(shù)語。排查過程是這樣的第一步確認(rèn)現(xiàn)象。抓取了出問題的幾次對(duì)話發(fā)現(xiàn)引用的術(shù)語確實(shí)只存在于 B 部門的記憶庫。第二步檢查檢索日志。發(fā)現(xiàn)這些請(qǐng)求的 tenant_id 過濾條件是對(duì)的理論上不應(yīng)該召回 B 部門數(shù)據(jù)。第三步檢查向量庫。發(fā)現(xiàn)問題出在 collection 的創(chuàng)建邏輯上——當(dāng)某個(gè)租戶第一次寫入時(shí)如果并發(fā)請(qǐng)求同時(shí)觸發(fā) collection 創(chuàng)建會(huì)出現(xiàn)競態(tài)導(dǎo)致兩個(gè)租戶共用了同一個(gè) collection。第四步修復(fù)。把 collection 創(chuàng)建改成冪等的加分布式鎖并且在檢索層再加一道 tenant_id 過濾作為兜底。這個(gè)坑的教訓(xùn)是隔離要做多層任何單層隔離都可能因?yàn)檫吔缜闆r失效。存儲(chǔ)層隔離 檢索層過濾 應(yīng)用層校驗(yàn)三層都做才能穩(wěn)。6.2 記憶膨脹導(dǎo)致的內(nèi)存告警另一個(gè)坑是會(huì)話記憶沒有及時(shí)清理。早期設(shè)計(jì)里會(huì)話記憶存在 Redis 里TTL 設(shè)的是 7 天。上線后隨著用戶量增長Redis 內(nèi)存持續(xù)告警。排查發(fā)現(xiàn)很多會(huì)話其實(shí)幾小時(shí)后就沒人用了7 天 TTL 太保守。修復(fù)方案是動(dòng)態(tài) TTL會(huì)話活躍時(shí)續(xù)期超過 2 小時(shí)無活動(dòng)就降到 1 小時(shí) TTL。同時(shí)加了內(nèi)存使用率監(jiān)控超過 70% 觸發(fā)主動(dòng)清理。這個(gè)改動(dòng)讓 Redis 內(nèi)存占用下降了約 60%。6.3 檢索結(jié)果看起來相關(guān)但沒用這是最隱蔽的坑。用戶反饋 Agent 經(jīng)常引用一些相關(guān)但答非所問的記憶。排查發(fā)現(xiàn)向量檢索的相似度高但語義上并不解決當(dāng)前問題。比如用戶問報(bào)銷流程檢索召回了報(bào)銷標(biāo)準(zhǔn)的記憶兩者向量相似度高但一個(gè)是流程一個(gè)是金額不是一回事。解決方案是引入意圖匹配在檢索前先對(duì)當(dāng)前 query 做意圖分類檢索時(shí)優(yōu)先召回同意圖類型的記憶。這個(gè)改動(dòng)讓檢索準(zhǔn)確率提升了約 20%。意圖分類可以用小模型也可以用規(guī)則成本不高但效果明顯。6.4 記憶寫入的過度記憶問題有些 Agent 會(huì)把用戶的每一句話都當(dāng)成記憶存下來導(dǎo)致記憶庫迅速膨脹且噪聲極大。這個(gè)問題的根因是寫入決策太寬松。修復(fù)思路是加一道記憶價(jià)值預(yù)判只有滿足以下條件之一才寫入——用戶顯式要求記住、內(nèi)容包含事實(shí)性信息、內(nèi)容包含偏好表達(dá)、內(nèi)容在多個(gè)會(huì)話中重復(fù)出現(xiàn)。其余內(nèi)容只存會(huì)話記憶不進(jìn)入長期記憶。7. 關(guān)于 Memory OS 后續(xù)演進(jìn)的一些個(gè)人判斷做了一段時(shí)間下來我對(duì) Memory OS 的演進(jìn)有幾個(gè)比較確定的判斷分享出來供參考。第一記憶的分層會(huì)越來越細(xì)?，F(xiàn)在分四類未來可能會(huì)分出情緒記憶關(guān)系記憶等更細(xì)的維度因?yàn)椴煌S度的檢索策略差異很大。但分層不是越多越好每加一層都要有明確的檢索場景支撐否則就是過度設(shè)計(jì)。第二控制平面會(huì)從規(guī)則驅(qū)動(dòng)走向模型驅(qū)動(dòng)?，F(xiàn)在寫入決策、重排打分很多還是規(guī)則未來這些小決策會(huì)逐步交給小模型。但要注意模型驅(qū)動(dòng)的前提是可觀測、可回滾不能變成一個(gè)黑盒。第三記憶的可解釋性會(huì)成為企業(yè)剛需。企業(yè)不僅要知道 Agent 記住了什么還要知道為什么這次召回了這條記憶。這要求 Memory OS 在檢索時(shí)記錄完整的決策鏈路包括每一路的召回結(jié)果、重排前后的分?jǐn)?shù)變化。這個(gè)能力現(xiàn)在很多系統(tǒng)都沒有但遲早要補(bǔ)上。第四記憶的跨 Agent 共享是個(gè)待解的難題?，F(xiàn)在每個(gè) Agent 的記憶基本是獨(dú)立的但企業(yè)里很多知識(shí)是通用的。怎么在保證隔離的前提下實(shí)現(xiàn)可控共享是個(gè)值得投入的方向。我目前的思路是通過記憶市場的模式——記憶的擁有者可以顯式地把某條記憶發(fā)布到共享池其他 Agent 申請(qǐng)后可用用完后權(quán)限回收。最后說一個(gè)實(shí)操建議不要一上來就追求大而全的 Memory OS。先從會(huì)話記憶和用戶記憶兩類做起把寫入、檢索、淘汰三個(gè)鏈路跑通驗(yàn)證效果后再逐步擴(kuò)展。我見過太多團(tuán)隊(duì)一開始就設(shè)計(jì)了一個(gè)包含七八個(gè)組件的復(fù)雜架構(gòu)結(jié)果半年都沒上線。記憶系統(tǒng)的價(jià)值在于用起來而不是設(shè)計(jì)得多漂亮。先把最小閉環(huán)跑通讓業(yè)務(wù)方看到效果后面的演進(jìn)才有資源支撐。