我記得很清楚第一次意識到上下文重要性的場景是在寫一個(gè)小型終端助手的時(shí)候。這個(gè)工具需要用戶連續(xù)完成幾步操作先選擇數(shù)據(jù)源再指定處理方式最后輸出報(bào)告。但每次命令跑完它就什么都不記得了用戶下一步如果漏掉某個(gè)參數(shù)只能重新敲一遍。那一刻我意識到?jīng)]有上下文的工具就像一個(gè)每次都重新認(rèn)識你的柜臺服務(wù)員你不得不一遍遍重復(fù)自己的需求。context-mode就是為解決這類問題設(shè)計(jì)的。簡單來說它是一種讓軟件在多次操作或多次會話之間自動保存、讀取并利用歷史上下文信息的運(yùn)行模式。它解決的問題很具體減少重復(fù)輸入、保持操作連續(xù)性、讓程序能根據(jù)之前發(fā)生了什么做出更合理的判斷。如果你是做CLI工具、自動化腳本、編輯器插件或者自己在折騰AI助手相關(guān)的東西這篇文章值得看完——我會從設(shè)計(jì)思路講到代碼實(shí)現(xiàn)再分享實(shí)測中踩過的三個(gè)坑。1. context-mode是什么先從一次尷尬的失憶說起1.1 沒有上下文的世界你每天都在重復(fù)填表先想想你平時(shí)用的命令行工具尤其是那些要傳一堆參數(shù)的工具。比如一個(gè)數(shù)據(jù)遷移腳本你可能要寫成這樣python migrate.py --source /data/old --target /data/new --format csv --encoding utf-8如果跑到一半掛了或者你想換個(gè)格式再跑一次你大概率會把這條命令翻出來改一改或者按一下上箭頭重新編輯。這在單次操作里問題不大但如果是連續(xù)幾十條命令呢比如你要依次做預(yù)處理、清洗、校驗(yàn)、導(dǎo)入、導(dǎo)出每一步都要重復(fù)指定路徑、編碼、分隔符時(shí)間一長忘參數(shù)幾乎是必然的。沒有上下文的世界本質(zhì)上是把本該由程序記住的信息全壓在了用戶身上。這就像你每天去同一個(gè)快遞點(diǎn)取件每次都報(bào)一遍姓名、電話、地址?？爝f點(diǎn)的工作人員不是不想記住你而是他的系統(tǒng)沒這個(gè)能力。context-mode要做的就是給程序加上這個(gè)記憶能力。1.2 context-mode的定位讓工具記住剛才發(fā)生了什么那么context-mode具體指什么我傾向于給它一個(gè)精確的定義一種運(yùn)行模式在這種模式下程序會將用戶當(dāng)前的操作、輸入?yún)?shù)、選中項(xiàng)、臨時(shí)狀態(tài)等信息記錄下來并在后續(xù)操作中自動讀取和套用從而形成連續(xù)的操作體驗(yàn)。它和普通的日志、緩存有本質(zhì)區(qū)別。日志是寫給開發(fā)者調(diào)試用的緩存是為了加速重復(fù)讀取而context-mode關(guān)心的是語義上的連續(xù)性。舉個(gè)例子你在一個(gè)文件管理器里選中了一個(gè)文件然后準(zhǔn)備執(zhí)行壓縮操作——壓縮工具預(yù)先把當(dāng)前選中了哪個(gè)文件這個(gè)信息記下來這就是上下文。再比如AI聊天助手它能記得你五分鐘前問過什么這個(gè)記得就是上下文模式在起作用。我見過的context-mode實(shí)現(xiàn)有很多種形態(tài)基于會話服務(wù)器端為每個(gè)連接維護(hù)獨(dú)立上下文比如SSH會話。基于項(xiàng)目目錄進(jìn)入某個(gè)項(xiàng)目目錄后自動加載該項(xiàng)目相關(guān)的偏好設(shè)置?；谌钟脩艏墑e的默認(rèn)配置任何地方都能訪問。基于時(shí)間窗口只記錄最近N分鐘或N條操作形成滾動上下文。這里面的核心難點(diǎn)不是記錄數(shù)據(jù)而是決定哪些數(shù)據(jù)值得記錄、什么時(shí)候該遺忘、上下文沖突時(shí)怎么處理。1.3 什么場景真正需要它三個(gè)最典型的應(yīng)用場景我在實(shí)際項(xiàng)目里總結(jié)出三類最需要context-mode的場景你可以對照自己的需求來判斷。第一類是多步驟CLI工具。我之前寫過一個(gè)批量圖片處理工具包含導(dǎo)入、去重、壓縮、重命名、導(dǎo)出五個(gè)步驟。如果每一步都要求用戶重新輸入輸入目錄、輸出目錄、質(zhì)量參數(shù)用起來會非常痛苦。加上context-mode之后用戶只需要在第一次運(yùn)行時(shí)提供完整參數(shù)后續(xù)跑任何單步操作都會自動帶上省事很多。第二類是IDE和編輯器插件。比如你正在編輯一個(gè)Python文件然后按下快捷鍵跳到一個(gè)工具函數(shù)定義處改完之后返回原來的位置——編輯器記住了你剛才在哪里。這種上下文記錄已經(jīng)非常普遍了我們在做插件開發(fā)時(shí)也常常需要記錄光標(biāo)位置、當(dāng)前文件路徑、最近打開的文件列表這就是一種典型的window-level context。第三類是AI助手的連續(xù)對話。當(dāng)前所有主流AI對話產(chǎn)品都在做上下文管理因?yàn)榘颜螝v史全部塞給模型既浪費(fèi)tokens又會超出模型的上下文窗口。實(shí)際工程中我們往往需要保留最近幾輪對話而對更久之前的內(nèi)容做摘要或裁剪。這個(gè)保留多少、裁剪多少的策略本質(zhì)上是context-mode的策略選擇。除此之外運(yùn)維自動化、構(gòu)建系統(tǒng)、數(shù)據(jù)管道調(diào)度等領(lǐng)域也大量依賴上下文。判斷一個(gè)系統(tǒng)適不適合引入context-mode我有個(gè)簡單的經(jīng)驗(yàn)如果你發(fā)現(xiàn)使用者在反復(fù)輸入或反復(fù)選擇相同的信息并且這些信息跟上一次操作強(qiáng)相關(guān)那這個(gè)系統(tǒng)就值得改造。2. 設(shè)計(jì)一個(gè)合理的上下文模型數(shù)據(jù)結(jié)構(gòu)和生命周期2.1 上下文粒度全局、會話、項(xiàng)目三層的取舍在動手寫代碼之前必須先想清楚上下文數(shù)據(jù)要分成幾層。如果不分層所有數(shù)據(jù)混在一起很快就會出現(xiàn)張三的項(xiàng)目配置被李四帶走了這種問題。我在context-mode項(xiàng)目里設(shè)計(jì)了三個(gè)層級非常夠用層級作用范圍典型內(nèi)容生命周期global當(dāng)前用戶所有操作用戶名、默認(rèn)編輯器、常用路徑長期保留session一次工具進(jìn)程的運(yùn)行周期當(dāng)前打開的臨時(shí)文件、臨時(shí)的token會話結(jié)束即刪除project當(dāng)前項(xiàng)目/工作目錄項(xiàng)目根路徑、依賴目錄、構(gòu)建命令項(xiàng)目存在期間這套設(shè)計(jì)解決了兩個(gè)關(guān)鍵問題。一個(gè)是隔離性不同項(xiàng)目的上下文不會互相污染即使是同一個(gè)工具在項(xiàng)目A和項(xiàng)目B下會自動加載各自的設(shè)置。另一個(gè)是時(shí)效性session里的狀態(tài)本來就該用完即焚比如某次登錄產(chǎn)生的臨時(shí)憑證如果放到了global里那就是給自己埋雷。有人可能會問為什么不做成數(shù)據(jù)庫表用外鍵關(guān)聯(lián)我的答案是對于大部分工具型項(xiàng)目三層結(jié)構(gòu)用嵌套字典就夠了。數(shù)據(jù)庫適合海量數(shù)據(jù)檢索而context數(shù)據(jù)通常單用戶、低并發(fā)、量也不大用樹狀結(jié)構(gòu)反而更直觀調(diào)試時(shí)候一眼就能看到當(dāng)前上下文里有什么。2.2 持久化選型為什么用JSON加內(nèi)存兩級緩存確定層級結(jié)構(gòu)后接下來要考慮數(shù)據(jù)存哪。我先說結(jié)論我采用了內(nèi)存字典做熱存儲 JSON文件做冷持久化的組合而不是直接上SQLite。內(nèi)存字典的好處是快讀寫都在納秒級適合高頻訪問。JSON文件的好處是方便調(diào)試——你可以直接用vim或cat打開來看如果用了SQLite還得裝個(gè)客戶端才能查。對于context-mode這種偏工具性質(zhì)的組件易調(diào)試比查詢性能重要得多。具體做法是啟動時(shí)把JSON文件加載進(jìn)內(nèi)存形成一個(gè)三層嵌套字典。每次set操作先更新內(nèi)存再決定是否寫盤。寫盤不能每次set都做否則高頻操作時(shí)IO會成為瓶頸。我的做法是做一個(gè)臟標(biāo)記在程序退出、或者每隔一段時(shí)間批量落盤。下面是我最初的存儲結(jié)構(gòu)設(shè)計(jì)示意{ global: { default_editor: vim }, session: { login_time: 1700000000 }, project: { /home/user/myapp: { build_command: make, last_output: Build OK } } }這里把project的鍵設(shè)計(jì)成了項(xiàng)目絕對路徑天然實(shí)現(xiàn)了項(xiàng)目級隔離。后來又發(fā)現(xiàn)一個(gè)細(xì)節(jié)值得注意路徑里可能含有特殊字符所以我在加載時(shí)對路徑做了規(guī)范化處理去掉末尾斜杠、解析符號鏈接避免同一個(gè)項(xiàng)目因?yàn)槁窂綄懛ú煌霈F(xiàn)兩個(gè)上下文副本。2.3 上下文有效期過期策略與自動清理機(jī)制上下文不是無限堆積的否則用戶會發(fā)現(xiàn)三個(gè)月前的一次操作記錄還影響了今天的執(zhí)行結(jié)果這反而變成了一種困擾。我設(shè)計(jì)的過期策略是給每條上下文數(shù)據(jù)附加元信息{ value: data, created_at: 1700000000, updated_at: 1700000000, ttl: 3600 }created_at和updated_at分別記錄創(chuàng)建時(shí)間和最后更新時(shí)間。ttl是存活時(shí)間秒例如3600表示1小時(shí)后過期。讀取時(shí)如果now - updated_at ttl就認(rèn)為這條數(shù)據(jù)已過期不返回給調(diào)用方。這里我要強(qiáng)調(diào)一個(gè)容易犯的錯(cuò)很多人把TTL只寫在層級上比如整個(gè)session層1小時(shí)過期這會引發(fā)連鎖問題——一個(gè)長任務(wù)可能只需要某些字段長期有效但整個(gè)層級過期會把它一并殺掉。正確的做法是字段級TTL不同字段可以單獨(dú)指定有效期。比如當(dāng)前登錄用戶可以永久上次選中的文件只需要5分鐘。清理機(jī)制我用的是惰性刪除 定期掃描雙保險(xiǎn)。惰性刪除是在get時(shí)發(fā)現(xiàn)過期就順便刪掉定期掃描是每隔10分鐘把過期數(shù)據(jù)批量清掉避免臟數(shù)據(jù)堆積占內(nèi)存。這樣既保證實(shí)時(shí)性又不至于每次操作都觸發(fā)大量刪除。3. 動手實(shí)現(xiàn)一個(gè)可用的context-mode模塊Python版3.1 核心類設(shè)計(jì)ContextManager的接口定義設(shè)計(jì)完成后實(shí)現(xiàn)階段需要用代碼把想法固定下來。這一節(jié)我用Python來寫一個(gè)可直接運(yùn)行的context-mode模塊語言無關(guān)性很好你換成Go、Node.js也是一樣的思路。先定義核心類的接口。我習(xí)慣先寫注釋再寫實(shí)現(xiàn)因?yàn)檫@樣能逼自己把接口想清楚import json import os import threading import time from pathlib import Path class ContextManager: Manage context data at global/session/project levels with TTL support. def __init__(self, storage_path): self.storage_path Path(storage_path) self._lock threading.Lock() self._context {global: {}, session: {}, project: {}} self._load() def _load(self): if self.storage_path.exists(): with open(self.storage_path, r, encodingutf-8) as f: loaded json.load(f) self._context.update(loaded) def set(self, level, key, value, ttlNone): Set a value in the given level. level: global | session | project key: string key value: any JSON-serializable value ttl: optional time-to-live in seconds with self._lock: meta { value: value, created_at: time.time(), updated_at: time.time(), ttl: ttl, } self._context.setdefault(level, {})[key] meta def get(self, level, key): Get a value. Return None if key doesnt exist or is expired. with self._lock: meta self._context.get(level, {}).get(key) if meta is None: return None if meta[ttl] is not None: if time.time() - meta[updated_at] meta[ttl]: del self._context[level][key] return None return meta[value] def save(self): Persist current context to disk. with self._lock: tmp_file self.storage_path.with_suffix(.tmp) with open(tmp_file, w, encodingutf-8) as f: json.dump(self._context, f, ensure_asciiFalse, indent2) tmp_file.replace(self.storage_path)這個(gè)類雖然只有幾十行但已經(jīng)包含了最核心的能力設(shè)置、讀取、過期判斷、落盤。其中save用了一個(gè)臨時(shí)文件加原子替換的技巧避免直接寫原文件時(shí)如果程序崩潰導(dǎo)致文件損壞。這是一個(gè)我踩過坑后的經(jīng)驗(yàn)后面第4節(jié)還會詳細(xì)說。3.2 一個(gè)簡單的CLI集成示例從保存到讀取光有類還不夠我把它集成進(jìn)一個(gè)真實(shí)的CLI場景來演示。假設(shè)我們要做一個(gè)圖片壓縮工具壓縮之前需要用戶指定輸入目錄和質(zhì)量參數(shù)。我用argparse來解析命令命令行沒有提供時(shí)就從上下文讀取import argparse from pathlib import Path ctx ContextManager(~/.myapp/context.json) def require_dir(arg_valueNone): Return provided arg value, or read from context if available. if arg_value: ctx.set(project, input_dir, arg_value) return arg_value cached ctx.get(project, input_dir) if cached: return cached raise SystemExit(請輸入輸入目錄或者先設(shè)置過context-mode) if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--input-dir, defaultNone) parser.add_argument(--quality, typeint, defaultNone) args parser.parse_args() input_dir require_dir(args.input_dir) quality args.quality if quality is None: quality ctx.get(project, quality) or 85 ctx.set(project, quality, quality) ctx.save() print(f開始壓縮輸入目錄{input_dir}質(zhì)量{quality})注意require_dir的設(shè)計(jì)如果用戶傳了新參數(shù)就會更新上下文如果沒傳就嘗試從上下文取值。這就是context-mode的核心體驗(yàn)——今天少敲幾個(gè)參數(shù)明天少敲更多越用越順手。3.3 代碼走讀關(guān)鍵的邊界條件處理這幾十行代碼里有幾個(gè)邊界條件是實(shí)際跑起來之后才會發(fā)現(xiàn)的。第一個(gè)是存儲路徑的擴(kuò)展符處理。Path(~/.myapp/context.json)在Python中不會自動展開波浪號必須調(diào)用Path.expanduser()。我在最初版本里漏了這一步導(dǎo)致一直找不到文件后來排查了很久。正確寫法是self.storage_path Path(storage_path).expanduser()第二個(gè)是過期數(shù)據(jù)在get之后才刪除。我的實(shí)現(xiàn)里如果get時(shí)發(fā)現(xiàn)TTL過期會先把數(shù)據(jù)刪掉再返回None。但如果在刪除之前另一個(gè)線程正好也在讀同一個(gè)key就會出現(xiàn)競態(tài)。我在get外層加了線程鎖這就是_lock的作用。不過對單文件來說這個(gè)鎖只在進(jìn)程內(nèi)有效如果多個(gè)進(jìn)程同時(shí)讀寫同一個(gè)JSON文件還需要加文件鎖這個(gè)坑我第4節(jié)會專門講。第三個(gè)是set的值必須可JSON序列化。如果你存了個(gè)自定義對象json.dump時(shí)會直接拋TypeError。更隱蔽的是如果存的是tuplejson會把它變成list下次讀出來類型就變了。如果想保留類型信息必須在set時(shí)做轉(zhuǎn)換檢查。我在實(shí)際項(xiàng)目中加了這樣一個(gè)斷言def _ensure_json_serializable(self, value): try: json.dumps(value) except TypeError: raise TypeError(f值 {value} 無法序列化為JSON)這些邊界條件看起來不復(fù)雜但往往就是能用和好用之間的差距。4. 實(shí)測中的坑與排查過程數(shù)據(jù)覆蓋、過期混亂和隱私泄漏4.1 坑一并發(fā)寫入導(dǎo)致上下文互相覆蓋代碼看起來沒問題的部分一上實(shí)測就暴露了第一個(gè)大坑。我的工具支持并行處理多個(gè)任務(wù)于是會同時(shí)跑多個(gè)進(jìn)程每個(gè)進(jìn)程都會調(diào)用ctx.save()結(jié)果經(jīng)常出現(xiàn)進(jìn)程A把上下文寫到一半進(jìn)程B也寫過來了最終文件里數(shù)據(jù)錯(cuò)亂甚至JSON解析直接失敗。排查過程是這樣的我先檢查了代碼里的線程鎖_lock發(fā)現(xiàn)它只能鎖住當(dāng)前進(jìn)程內(nèi)的線程進(jìn)程之間完全不管用。兩個(gè)進(jìn)程同時(shí)執(zhí)行tmp_file.replace(self.storage_path)時(shí)雖然臨時(shí)文件是各自獨(dú)立的但替換操作本身不是原子的關(guān)聯(lián)操作集合——A替換成功B替換成功后面的覆蓋了前面的無法合并。解決辦法是讓進(jìn)程間也能串行化。我引入了一個(gè)簡單的文件鎖基于操作系統(tǒng)層面的fcntlimport fcntl def save(self): with open(self.storage_path, a) as lock_file: fcntl.flock(lock_file.fileno(), fcntl.LOCK_EX) # 原子寫入內(nèi)容 with open(tmp_file, w, ...): json.dump(...) tmp_file.replace(self.storage_path) fcntl.flock(lock_file.fileno(), fcntl.LOCK_UN)但這里還有個(gè)微妙的問題鎖的競爭粒度是整個(gè)文件的寫入如果多個(gè)進(jìn)程同時(shí)修改的是不同層級的數(shù)據(jù)理論上是可以合并的。我圖省事直接全文件互斥了實(shí)測下來因?yàn)閏ontext本身寫得不頻繁性能損失可以忽略。如果你的項(xiàng)目寫得很頻繁就需要把鎖粒度細(xì)化到字段級。4.2 坑二單字段過期機(jī)制導(dǎo)致的連鎖混亂第二個(gè)坑是在我加字段級TTL之后才浮現(xiàn)的。最初版本我把TTL放到了level層級也就是session層整體2小時(shí)過期。后來改成字段級TTL后我發(fā)現(xiàn)一個(gè)新的問題決定是否過期的時(shí)間基準(zhǔn)有問題。一開始我給的邏輯是now - created_at ttl就過期但這有個(gè)反例用戶在一個(gè)長任務(wù)的剛開始設(shè)置了待處理文件列表這個(gè)列表的created_at是一個(gè)小時(shí)前但任務(wù)還沒跑完。按created_at算它已經(jīng)過期了可實(shí)際上它一直被正常使用著。后來我改成now - updated_at ttl每次get命中就刷新updated_at這樣只要這個(gè)字段還在被持續(xù)使用它就會一直存活。這個(gè)邏輯目前驗(yàn)證下來比較合理但它也有代價(jià)一個(gè)長期不用的上下文永遠(yuǎn)不會被徹底清掉因?yàn)槊看蝕et都會給它續(xù)命。所以我加了一個(gè)上限當(dāng)now - created_at超過某個(gè)最大值比如7天時(shí)強(qiáng)制認(rèn)為過期防止數(shù)據(jù)無限膨脹。實(shí)際排查過程中我用了一段腳本模擬了反復(fù)讀取同一個(gè)舊字段的情況確認(rèn)了updated_at確實(shí)被刷新也發(fā)現(xiàn)了created_at一直沒變。這類問題只有在把預(yù)期行為和實(shí)際行為對照著看才容易暴露單純看代碼很難發(fā)現(xiàn)。4.3 坑三上下文日志里存了不該存的密鑰第三個(gè)坑比較嚇人。我在調(diào)試context-mode時(shí)經(jīng)常打印整個(gè)上下文看看數(shù)據(jù)對不對有一次發(fā)現(xiàn)打印內(nèi)容里包含了用戶臨時(shí)輸入的數(shù)據(jù)庫密碼。最開始沒在意覺得反正本地開發(fā)后來才意識到一旦這個(gè)模塊被集成到線上的自動化腳本里并且開啟debug日志就等于把密鑰明文寫到了日志文件里如果日志被上傳到日志中心那就是事故。修復(fù)方案是加一個(gè)脫敏層。具體在打印和序列化時(shí)需要識別常見的敏感字段名SENSITIVE_KEYS {password, secret, token, api_key} def safe_dump(data): if isinstance(data, dict): return {k: (*** if k.lower() in SENSITIVE_KEYS else safe_dump(v)) for k, v in data.items()} if isinstance(data, list): return [safe_dump(i) for i in data] return data然后把所有對外輸出改成走safe_dump底層的存量數(shù)據(jù)保持原樣。這里關(guān)鍵在于展示層脫敏存儲層不脫敏——如果你把存儲層的值都改了那后續(xù)需要用真實(shí)密碼時(shí)就會出錯(cuò)。這個(gè)坑給我一個(gè)更深的教訓(xùn)context-mode這類工具天然就是什么數(shù)據(jù)都往里塞的類型所以必須在設(shè)計(jì)階段就明確哪些數(shù)據(jù)碰都不能碰對于高敏感數(shù)據(jù)寧可完全不放進(jìn)去。4.4 修復(fù)后的驗(yàn)證方案我是怎么確認(rèn)問題真解決的修完三個(gè)坑之后我整理了一組回歸測試用例專門用來驗(yàn)證context-mode模塊的穩(wěn)定性。這組用例現(xiàn)在被我放在項(xiàng)目的tests目錄下每次改動后都會跑一遍并發(fā)測試同時(shí)啟動8個(gè)進(jìn)程每個(gè)進(jìn)程往context里寫入不同的key重復(fù)100輪最后檢查JSON文件里是否所有key都完整存在。過期測試創(chuàng)建一條TTL為1秒的數(shù)據(jù)sleep 1.2秒后讀取確認(rèn)返回None并且該key從存儲中刪除。隱私測試用一個(gè)包含了password的假上下文跑一次打印確認(rèn)輸出中對應(yīng)字段是***。邊界測試key名稱為空字符串、value為None、value為中文和帶Unicode的字符都要能正常寫入和讀取。這些測試全部通過的時(shí)候心里才踏實(shí)下來。尤其是并發(fā)測試第一次跑就失敗后來加上進(jìn)程鎖才通過那種測試救了一命的感覺寫代碼的人都懂。5. 從context-mode到智能化在LLM會話場景中的擴(kuò)展5.1 把context-mode用在大模型交互上滑動窗口和摘要搞定了基礎(chǔ)模塊之后我把它用在了另一個(gè)更貼近當(dāng)前熱點(diǎn)的場景大語言模型LLM會話的上下文管理。很多人問為什么AI聊天工具不能無限記住所有對話核心原因就是上下文窗口有上限。context-mode在這里的價(jià)值是可以設(shè)計(jì)一種滑動窗口 摘要的組合策略。具體做法是維護(hù)一個(gè)會話歷史列表新消息不斷加入。當(dāng)列表長度超過N條或者總token數(shù)超過閾值時(shí)我們?nèi)∏懊嫒舾蓷l消息做一次摘要然后把摘要作為一個(gè)新的系統(tǒng)消息再丟掉最老的消息。這樣實(shí)際上形成了一種滾動上下文。我把這個(gè)邏輯復(fù)用了之前的ContextManager只是在session層里存了一個(gè)chat_historyMAX_HISTORY 10 def append_message(role, content): history ctx.get(session, chat_history) or [] history.append({role: role, content: content}) if len(history) MAX_HISTORY: old_part history[:-MAX_HISTORY // 2] recent_part history[-MAX_HISTORY // 2:] old_text \n.join(f{m[role]}: {m[content]} for m in old_part) summary llm_summarize(old_text) # 調(diào)用模型生成摘要 ctx.set(session, chat_summary, summary) ctx.set(session, chat_history, recent_part) else: ctx.set(session, chat_history, history)這套方案的關(guān)鍵是摘要的更新時(shí)機(jī)。如果每來一條新消息就跑一次摘要成本太高我的經(jīng)驗(yàn)是等舊部分累計(jì)超過閾值時(shí)再整體生成一次摘要。另外要注意摘要本身也應(yīng)該有TTL因?yàn)樗４娴氖菚挼呐R時(shí)狀態(tài)會話結(jié)束或被新摘要替代后就不再需要了。5.2 后續(xù)還能怎么擴(kuò)展共享上下文、權(quán)限控制、可視化調(diào)試現(xiàn)在這個(gè)context-mode模塊已經(jīng)能穩(wěn)定運(yùn)行了但還談不上完善。我自己整理了三個(gè)明確的擴(kuò)展方向如果你也在做類似項(xiàng)目可以參考。第一個(gè)方向是共享上下文。目前每個(gè)用戶各自維護(hù)一份context文件如果想在團(tuán)隊(duì)里共享項(xiàng)目級上下文就需要引入同步機(jī)制。我的初步思路是給每條context記錄加一個(gè)owner字段拉取時(shí)先檢查權(quán)限只返回自己有權(quán)限的部分。這樣可以做到項(xiàng)目組共享構(gòu)建參數(shù)個(gè)人私有配置不泄露。第二個(gè)方向是權(quán)限控制。這跟上面的共享是配套的。context里往往包含敏感信息比如數(shù)據(jù)庫連接串、臨時(shí)密鑰。改造方向是在set/get的接口中加入一個(gè)權(quán)限校驗(yàn)層按照用戶角色判斷當(dāng)前操作是否被允許。最簡單的實(shí)現(xiàn)是建一個(gè)權(quán)限表每個(gè)key對應(yīng)一個(gè)可訪問的角色列表復(fù)雜一點(diǎn)的方向是做成與現(xiàn)有SSO/身份系統(tǒng)對接。第三個(gè)方向是可視化調(diào)試。前端工程師調(diào)試時(shí)最想看的是上下文樹的實(shí)時(shí)變化。我已經(jīng)用Python做了個(gè)簡單的Web頁面把ContextManager暴露成一個(gè)HTTP接口用WebSocket推送變更事件界面上能看到global/session/project三層的數(shù)據(jù)新增、過期、刪除。這個(gè)擴(kuò)展對排查為什么某次操作行為異常特別有用因?yàn)槟隳芸吹匠绦虻降子涀×耸裁础０裞ontext-mode從一個(gè)小模塊擴(kuò)展成完整的上下文管理框架這條路其實(shí)很長。但至少起步階段的方向是清晰的先保證數(shù)據(jù)結(jié)構(gòu)合理再確保并發(fā)安全最后再往智能化和協(xié)作方向走。我在實(shí)際項(xiàng)目中體會最深的一點(diǎn)是context-mode看起來像是個(gè)不起眼的輔助功能但對用戶體驗(yàn)的提升是實(shí)實(shí)在在的。它讓工具從一個(gè)每次都要重新認(rèn)識你的陌生人變成了記得你習(xí)慣的同事。開發(fā)過程中踩過的這三個(gè)坑——并發(fā)覆蓋、過期混亂、隱私泄漏——幾乎每一個(gè)都值得單獨(dú)寫篇文章但總結(jié)下來核心原則也就三條上下文要分層、過期要按字段、敏感要脫敏。記住這三點(diǎn)你也能做出一個(gè)穩(wěn)定好用的context-mode。