、fast-jev-compaction 靠決策模型：上下文管理的兩條路線誰(shuí)走得更遠(yuǎn)？)
Hermes 靠記憶系統(tǒng)、fast-jev-compaction 靠決策模型上下文管理的兩條路線誰(shuí)走得更遠(yuǎn)【免費(fèi)下載鏈接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.項(xiàng)目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction長(zhǎng)會(huì)話 Agent 最貴的不是 API 賬單而是記憶錯(cuò)位模型忘了自己改過哪個(gè)文件、丟了一段報(bào)錯(cuò)堆棧、把src/generated的禁改約束在摘要里優(yōu)化掉。2026 年圍繞上下文管理出現(xiàn)了兩條針鋒相對(duì)的技術(shù)路線——以 Nous Research Hermes Agent 為代表的記憶/檢索體系先記住再按需召回和以 TypeSafe AI 的 Jev 決策模型為底座、由 fast-jev-compaction 工程化的逐條決策壓縮不生成一個(gè)字只做選擇題按需刪除。前者試圖把上下文變成外掛硬盤后者試圖把壓縮變成法官判決。本文將以 fast-jev-compaction 倉(cāng)庫(kù)源碼為第一手證據(jù)對(duì)比兩條路線的骨架、工程成本與適用場(chǎng)景并討論它們是否會(huì)殊途同歸。一、兩條路線的骨架把上下文記住還是裁掉記憶/檢索體系上下文是資產(chǎn)值得長(zhǎng)期持有Hermes Agent 走的是記憶系統(tǒng)路線會(huì)話歷史被結(jié)構(gòu)化地存入長(zhǎng)期記憶通過向量檢索與分層歸檔按需召回配合上下文壓縮與 MCP 工具集成讓 Agent 在長(zhǎng)任務(wù)中不丟事。這套體系的核心假設(shè)是——過去的對(duì)話是有價(jià)值的資產(chǎn)值得被索引、被持久化、被重新讀取。它的代價(jià)也很明確需要維護(hù)記憶的寫入與召回策略需要向量庫(kù)或數(shù)據(jù)庫(kù)做狀態(tài)持久化本質(zhì)上是用存儲(chǔ) 檢索換上下文窗口。決策壓縮上下文是消耗品該刪就刪fast-jev-compaction 走了完全相反的路。項(xiàng)目 README 的第一句話就劃清了邊界This library never rewrites anything. It only deletes tool calls and tool results Jev says are no longer needed.README.md——它不重寫任何內(nèi)容只刪除 Jev 判定為不再需要的工具調(diào)用與工具結(jié)果用戶和助手的文本逐字逐句、原序保留。這套機(jī)制的核心假設(shè)是——大多數(shù)歷史工具調(diào)用是消耗品Read過 30 個(gè)文件、跑過 20 次測(cè)試真正需要留給模型的只有最近幾步。與其把歷史壓縮成一段漂亮話不如逐條問一個(gè)不寫字的模型這條調(diào)用還重要嗎這個(gè)結(jié)果還必須原樣留著嗎源碼里的決策流水線打開 src/compact.tscompact()的主流程清晰可見配對(duì) → 釘選 → 擬合狀態(tài) → 分批提問 → 概率決策 → 重建消息。配對(duì)collectToolCallssrc/state.ts按tool_use_id把每條tool_use與其tool_result配對(duì)沒有結(jié)果的調(diào)用根本不是候選——還沒有可刪的東西。釘選isPinned()規(guī)定index 0 || index total - preserveRecentMessages——首條消息和最近preserveRecentMessages默認(rèn) 6條消息永不觸碰。逐條提問對(duì)每個(gè)非釘選調(diào)用構(gòu)造兩個(gè)noul問題src/compact.ts 的questionsForcall_xx問知道這條調(diào)用被做出、且其輸入仍然重要嗎result_xx問完整輸出是否仍需逐字保留重跑工具不可行。概率裁決decideCall把兩個(gè)概率壓到三個(gè)動(dòng)作上——keepResult ≥ keepThreshold則整條保留否則keepCall ≥ keepThreshold則保留調(diào)用、把結(jié)果截?cái)喾駝t連調(diào)用帶結(jié)果一起刪。無損重建applyDecisions重建消息列表內(nèi)容全失的消息整體移除未觸碰的消息原對(duì)象返回任何結(jié)果都不會(huì)脫離其調(diào)用而存在。這套流水線最反直覺的地方在于給 Jev 看的是省略版歷史刪的卻是原版歷史。決策模型看到的狀態(tài)fitState產(chǎn)物里工具結(jié)果一律被替換成一行注釋ok, 4213 chars (omitted)而真正從會(huì)話中刪除的是未經(jīng)任何改寫、逐字逐句的原始消息。二、工程對(duì)比實(shí)現(xiàn)復(fù)雜度、模型依賴與成本模型依賴生成式 LLM vs 不生成文本的啞巴模型記憶系統(tǒng)路線的壓縮環(huán)節(jié)通常依賴通用 LLM 做摘要而摘要恰恰是上下文管理里最不可控的一環(huán)——它會(huì)把變量名寫丟、把邏輯平滑、把約束條件吞掉且每次壓縮都是新的幻覺風(fēng)險(xiǎn)源。社區(qū)對(duì) Jev 的討論幾乎都圍繞這一點(diǎn)展開它是System One Model不生成文本只輸出封閉空間內(nèi)的結(jié)構(gòu)化判斷noul概率、choice、score官方口徑是速度快 193 倍、成本低 444 倍、輸出 Token 免費(fèi)。在 src/types.ts 里可以直觀看到這種啞巴的代價(jià)Jev 的答案類型只有三種——NoulAnswer一個(gè)概率、ChoiceAnswer一個(gè)選擇 置信度、ScoreAnswer一個(gè)分?jǐn)?shù)僅此而已。從工程視角看這帶來一個(gè)顯著紅利響應(yīng)可校驗(yàn)。src/request.ts 的parseJevResponse對(duì)響應(yīng)做了嚴(yán)格的結(jié)構(gòu)化校驗(yàn)——非 2xx 拋錯(cuò)、非法 JSON 拋錯(cuò)、缺answers拋錯(cuò)、noul缺失或非有限數(shù)拋錯(cuò)。生成式摘要的輸出根本無法這樣硬校驗(yàn)而決策模型的輸出天然是機(jī)器可消費(fèi)的。實(shí)現(xiàn)復(fù)雜度規(guī)則層把智能降級(jí)為工程記憶系統(tǒng)需要設(shè)計(jì)記憶 schema、寫入時(shí)機(jī)、召回排序、過期策略復(fù)雜度分布在系統(tǒng)各處。fast-jev-compaction 則把復(fù)雜度收斂進(jìn)了三個(gè)可調(diào)試的規(guī)則層其一無 tokenizer 的 token 估算。src/state.ts 的estimateTokens用正則把文本切成詞/數(shù)字/符號(hào)按單詞每 6 字母 1 token、數(shù)字半 token、符號(hào) 0.9計(jì)價(jià)并明確校準(zhǔn)到比 Jev 實(shí)際報(bào)告值高出 2–18%——注釋里寫著純字符比會(huì)低估 JSON 密集狀態(tài)最多 40%。這避免了引入 tokenizer 依賴換來的是可預(yù)期的預(yù)算余量。其二分級(jí)狀態(tài)擬合。同一個(gè)文件里的fitState定義了七級(jí)瘦身階梯逐級(jí)施加、命中最先返回工具輸入截?cái)嘀?1000 → 200 → 60 字符 → 長(zhǎng)文本頭尾摘錄[… N chars omitted …]→ 舊消息折疊 → 舊調(diào)用壓成單行t12 Read file_pathsrc/a.ts → ok 480ch→ 無調(diào)用的舊消息剔除 → 連續(xù)調(diào)用行合并全部用盡仍超預(yù)算則直接拋錯(cuò)。每一級(jí)都返回stage標(biāo)簽inputs200、texts abridged、old calls compacted…壓縮究竟發(fā)生在哪一步一目了然。其三分批并發(fā)請(qǐng)求。batchCalls用maxRequestTokens默認(rèn) 30k壓在 Jev 32k 請(qǐng)求上限之下減去狀態(tài)與 20 token 請(qǐng)求開銷算出預(yù)算把問題拆成多批每批都重發(fā)同一份完整狀態(tài)Promise.all并發(fā)執(zhí)行后合并答案src/compact.ts。成本賬毫秒級(jí)、零生成、可回退決策路線的成本結(jié)構(gòu)幾乎全是判斷成本每批請(qǐng)求只輸出幾十個(gè)概率數(shù)字沒有生成文本的 token 費(fèi)用也沒有二次摘要的級(jí)聯(lián)開銷。社區(qū)實(shí)測(cè)口徑如Jev 不生成一個(gè)字卻干掉了 Agent 90% 的上下文、91.5% 壓縮率、壓縮耗時(shí) 5–20ms雖來自不同作者、數(shù)字口徑不一但方向一致決策壓縮的成本與延遲都低一個(gè)數(shù)量級(jí)。fast-jev-compaction 還做了一層工程保險(xiǎn)壓縮收益不足則回退。hooks/fast-jev.ts 中minReductionRatio默認(rèn) 0.25——若 Jev 裁掉的字符不足 25%插件 toast 提示fallback to built-in summary把session.compact事件交給 Claude Code 內(nèi)置摘要Jev 請(qǐng)求失敗、響應(yīng)畸形、缺 API key、歷史裝不進(jìn)狀態(tài)預(yù)算同樣觸發(fā)回退。決策路線因此不是孤注一擲而是能刪則刪、刪不動(dòng)就退。三、場(chǎng)景對(duì)比長(zhǎng)會(huì)話編程、RAG、多工具編排各適合誰(shuí)長(zhǎng)會(huì)話編程決策路線的主場(chǎng)fast-jev-compaction 從設(shè)計(jì)上就是為 Coding Agent 的長(zhǎng)會(huì)話定制的README 里那句a file path, exact error, constraint, or command can disappear even when it matters later直指編程場(chǎng)景的死穴。幾個(gè)源碼細(xì)節(jié)都為此服務(wù)釘選保護(hù)首條消息與最近 6 條永遠(yuǎn)不刪用戶的初始約束Never edit src/generated和正在進(jìn)行的操作鏈不會(huì)誤傷只刪工具調(diào)用不碰文本README 的 Limitations 明確寫著Only tool calls and results are candidates; text messages are never removed or shortened in the output——人類語(yǔ)言的語(yǔ)義完整性由規(guī)則保證模型判斷只作用于工具層截?cái)嗔艉劢Y(jié)果被刪時(shí)保留前 300 字符并追加[fast-jev-compaction truncated N chars…; re-run the tool if needed]src/compact.ts報(bào)錯(cuò)堆棧的頭部、CLI 參數(shù)的簽名都能留在視線里重跑兜底決策指令中明說whatever is not kept is deleted permanently, but the assistant can always re-run a tool or re-read a file——編程 Agent 的工具具有可重入性刪錯(cuò)了代價(jià)有限這正是決策路線敢刪的底氣。RAG記憶/檢索體系的主場(chǎng)決策路線在 RAG 場(chǎng)景幾乎無用武之地。RAG 的核心矛盾是語(yǔ)料在窗口之外需要的是把知識(shí)索引、持久化、按查詢召回——這是 Hermes 式記憶系統(tǒng)的能力圈。決策壓縮解決的是窗口之內(nèi)的垃圾而 RAG 解決的是窗口之外的寶藏兩者解決的問題根本不同。想用刪調(diào)用的思路管理知識(shí)庫(kù)等于用剪刀修水管。多工具編排中間地帶多工具編排里決策路線的優(yōu)勢(shì)是證據(jù)鏈完整——社區(qū)情報(bào)中反復(fù)出現(xiàn)的 K/Q/VKey/Query/Value三元組描述在源碼里的對(duì)應(yīng)物是STATE_CONTEXT與goalsrc/state.tsgoal默認(rèn)取最近三條用戶指令context明確告訴 Jev這是一段編碼助手對(duì)話正在被壓縮工具輸出已替換為簡(jiǎn)短注釋。也就是說Jev 是在知道任務(wù)目標(biāo) 看到全量歷史骨架的前提下逐條裁決的這比無目標(biāo)地批量摘要要精準(zhǔn)得多。但代價(jià)也在 README 的 Limitations 里寫著完整狀態(tài)隨每個(gè)請(qǐng)求重復(fù)發(fā)送歷史接近狀態(tài)上限時(shí)一個(gè)問題批次就是一次完整重傳——調(diào)用密度極高時(shí)請(qǐng)求數(shù)與 token 消耗會(huì)同步上升。四、融合猜想記憶 決策會(huì)不會(huì)是終局兩條路線各自承認(rèn)的邊界值得注意的細(xì)節(jié)是fast-jev-compaction 自己并不聲稱無損——README 的 Limitations 寫得很克制Calibration is at the request level; a probability is not a proof that a result is safe to delete.概率不是刪除安全的證明。這與社區(qū)里 Redis 之父對(duì) Jev 狂熱的質(zhì)疑絕大多數(shù)開發(fā)者其實(shí)不需要它遙相呼應(yīng)決策模型擅長(zhǎng)高頻、窄域、可回退的判斷但這條歷史值不值得留在語(yǔ)義深處仍是一個(gè)生成問題只是被工程手段降格成了判斷問題。每輪重新決定模型該看什么社區(qū)情報(bào)中有一條值得玩味的線索Jev 團(tuán)隊(duì)公開的 Coding Agent 設(shè)計(jì)草案提出每輪重新決定模型該看什么——這本質(zhì)上已經(jīng)不是壓縮歷史而是動(dòng)態(tài)選擇視野。把這條思路外推決策模型完全可以嵌入記憶系統(tǒng)的召回環(huán)節(jié)不是由規(guī)則或向量相似度決定召回什么而是由決策模型對(duì)當(dāng)前任務(wù) × 候選記憶逐條裁決。屆時(shí)記憶系統(tǒng)負(fù)責(zé)存得住決策模型負(fù)責(zé)看得準(zhǔn)壓縮從一次性的會(huì)話整理變成每輪推理前的實(shí)時(shí)視野管理。終局可能是分工而非取代回到標(biāo)題的問題兩條路線誰(shuí)走得更遠(yuǎn)從工程事實(shí)看它們不是同一場(chǎng)比賽。決策路線把上下文管理從昂貴的生成變成廉價(jià)的判斷在長(zhǎng)會(huì)話編程這種高頻率、可重入、證據(jù)敏感的場(chǎng)景里成本和確定性優(yōu)勢(shì)是結(jié)構(gòu)性的記憶/檢索路線則在知識(shí)持久化、跨會(huì)話復(fù)用場(chǎng)景里擁有不可替代的位置。真正的終局更可能是一種分工記憶系統(tǒng)決定什么值得長(zhǎng)期擁有決策模型決定此刻該看什么——一個(gè)管存量一個(gè)管流量。fast-jev-compaction 已經(jīng)把決策路線的工程范式釘選、分級(jí)擬合、概率裁決、可回退打磨成了可復(fù)用的開源積木src/index.ts 導(dǎo)出了compactMessages、buildJevRequest、fitState、decideCall等全套構(gòu)件下一步被接進(jìn)記憶檢索鏈路幾乎是順理成章的事。上下文管理的下半場(chǎng)贏家不會(huì)是只記住或只刪除的一方而是能把記憶的廣度和決策的鋒利組合起來的一方。【免費(fèi)下載鏈接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.項(xiàng)目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Hermes 靠記憶系統(tǒng)、fast-jev-compaction 靠決策模型：上下文管理的兩條路線誰(shuí)走得更遠(yuǎn)？
Hermes 靠記憶系統(tǒng)、fast-jev-compaction 靠決策模型上下文管理的兩條路線誰(shuí)走得更遠(yuǎn)【免費(fèi)下載鏈接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.項(xiàng)目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction長(zhǎng)會(huì)話 Agent 最貴的不是 API 賬單而是記憶錯(cuò)位模型忘了自己改過哪個(gè)文件、丟了一段報(bào)錯(cuò)堆棧、把src/generated的禁改約束在摘要里優(yōu)化掉。2026 年圍繞上下文管理出現(xiàn)了兩條針鋒相對(duì)的技術(shù)路線——以 Nous Research Hermes Agent 為代表的記憶/檢索體系先記住再按需召回和以 TypeSafe AI 的 Jev 決策模型為底座、由 fast-jev-compaction 工程化的逐條決策壓縮不生成一個(gè)字只做選擇題按需刪除。前者試圖把上下文變成外掛硬盤后者試圖把壓縮變成法官判決。本文將以 fast-jev-compaction 倉(cāng)庫(kù)源碼為第一手證據(jù)對(duì)比兩條路線的骨架、工程成本與適用場(chǎng)景并討論它們是否會(huì)殊途同歸。一、兩條路線的骨架把上下文記住還是裁掉記憶/檢索體系上下文是資產(chǎn)值得長(zhǎng)期持有Hermes Agent 走的是記憶系統(tǒng)路線會(huì)話歷史被結(jié)構(gòu)化地存入長(zhǎng)期記憶通過向量檢索與分層歸檔按需召回配合上下文壓縮與 MCP 工具集成讓 Agent 在長(zhǎng)任務(wù)中不丟事。這套體系的核心假設(shè)是——過去的對(duì)話是有價(jià)值的資產(chǎn)值得被索引、被持久化、被重新讀取。它的代價(jià)也很明確需要維護(hù)記憶的寫入與召回策略需要向量庫(kù)或數(shù)據(jù)庫(kù)做狀態(tài)持久化本質(zhì)上是用存儲(chǔ) 檢索換上下文窗口。決策壓縮上下文是消耗品該刪就刪fast-jev-compaction 走了完全相反的路。項(xiàng)目 README 的第一句話就劃清了邊界This library never rewrites anything. It only deletes tool calls and tool results Jev says are no longer needed.README.md——它不重寫任何內(nèi)容只刪除 Jev 判定為不再需要的工具調(diào)用與工具結(jié)果用戶和助手的文本逐字逐句、原序保留。這套機(jī)制的核心假設(shè)是——大多數(shù)歷史工具調(diào)用是消耗品Read過 30 個(gè)文件、跑過 20 次測(cè)試真正需要留給模型的只有最近幾步。與其把歷史壓縮成一段漂亮話不如逐條問一個(gè)不寫字的模型這條調(diào)用還重要嗎這個(gè)結(jié)果還必須原樣留著嗎源碼里的決策流水線打開 src/compact.tscompact()的主流程清晰可見配對(duì) → 釘選 → 擬合狀態(tài) → 分批提問 → 概率決策 → 重建消息。配對(duì)collectToolCallssrc/state.ts按tool_use_id把每條tool_use與其tool_result配對(duì)沒有結(jié)果的調(diào)用根本不是候選——還沒有可刪的東西。釘選isPinned()規(guī)定index 0 || index total - preserveRecentMessages——首條消息和最近preserveRecentMessages默認(rèn) 6條消息永不觸碰。逐條提問對(duì)每個(gè)非釘選調(diào)用構(gòu)造兩個(gè)noul問題src/compact.ts 的questionsForcall_xx問知道這條調(diào)用被做出、且其輸入仍然重要嗎result_xx問完整輸出是否仍需逐字保留重跑工具不可行。概率裁決decideCall把兩個(gè)概率壓到三個(gè)動(dòng)作上——keepResult ≥ keepThreshold則整條保留否則keepCall ≥ keepThreshold則保留調(diào)用、把結(jié)果截?cái)喾駝t連調(diào)用帶結(jié)果一起刪。無損重建applyDecisions重建消息列表內(nèi)容全失的消息整體移除未觸碰的消息原對(duì)象返回任何結(jié)果都不會(huì)脫離其調(diào)用而存在。這套流水線最反直覺的地方在于給 Jev 看的是省略版歷史刪的卻是原版歷史。決策模型看到的狀態(tài)fitState產(chǎn)物里工具結(jié)果一律被替換成一行注釋ok, 4213 chars (omitted)而真正從會(huì)話中刪除的是未經(jīng)任何改寫、逐字逐句的原始消息。二、工程對(duì)比實(shí)現(xiàn)復(fù)雜度、模型依賴與成本模型依賴生成式 LLM vs 不生成文本的啞巴模型記憶系統(tǒng)路線的壓縮環(huán)節(jié)通常依賴通用 LLM 做摘要而摘要恰恰是上下文管理里最不可控的一環(huán)——它會(huì)把變量名寫丟、把邏輯平滑、把約束條件吞掉且每次壓縮都是新的幻覺風(fēng)險(xiǎn)源。社區(qū)對(duì) Jev 的討論幾乎都圍繞這一點(diǎn)展開它是System One Model不生成文本只輸出封閉空間內(nèi)的結(jié)構(gòu)化判斷noul概率、choice、score官方口徑是速度快 193 倍、成本低 444 倍、輸出 Token 免費(fèi)。在 src/types.ts 里可以直觀看到這種啞巴的代價(jià)Jev 的答案類型只有三種——NoulAnswer一個(gè)概率、ChoiceAnswer一個(gè)選擇 置信度、ScoreAnswer一個(gè)分?jǐn)?shù)僅此而已。從工程視角看這帶來一個(gè)顯著紅利響應(yīng)可校驗(yàn)。src/request.ts 的parseJevResponse對(duì)響應(yīng)做了嚴(yán)格的結(jié)構(gòu)化校驗(yàn)——非 2xx 拋錯(cuò)、非法 JSON 拋錯(cuò)、缺answers拋錯(cuò)、noul缺失或非有限數(shù)拋錯(cuò)。生成式摘要的輸出根本無法這樣硬校驗(yàn)而決策模型的輸出天然是機(jī)器可消費(fèi)的。實(shí)現(xiàn)復(fù)雜度規(guī)則層把智能降級(jí)為工程記憶系統(tǒng)需要設(shè)計(jì)記憶 schema、寫入時(shí)機(jī)、召回排序、過期策略復(fù)雜度分布在系統(tǒng)各處。fast-jev-compaction 則把復(fù)雜度收斂進(jìn)了三個(gè)可調(diào)試的規(guī)則層其一無 tokenizer 的 token 估算。src/state.ts 的estimateTokens用正則把文本切成詞/數(shù)字/符號(hào)按單詞每 6 字母 1 token、數(shù)字半 token、符號(hào) 0.9計(jì)價(jià)并明確校準(zhǔn)到比 Jev 實(shí)際報(bào)告值高出 2–18%——注釋里寫著純字符比會(huì)低估 JSON 密集狀態(tài)最多 40%。這避免了引入 tokenizer 依賴換來的是可預(yù)期的預(yù)算余量。其二分級(jí)狀態(tài)擬合。同一個(gè)文件里的fitState定義了七級(jí)瘦身階梯逐級(jí)施加、命中最先返回工具輸入截?cái)嘀?1000 → 200 → 60 字符 → 長(zhǎng)文本頭尾摘錄[… N chars omitted …]→ 舊消息折疊 → 舊調(diào)用壓成單行t12 Read file_pathsrc/a.ts → ok 480ch→ 無調(diào)用的舊消息剔除 → 連續(xù)調(diào)用行合并全部用盡仍超預(yù)算則直接拋錯(cuò)。每一級(jí)都返回stage標(biāo)簽inputs200、texts abridged、old calls compacted…壓縮究竟發(fā)生在哪一步一目了然。其三分批并發(fā)請(qǐng)求。batchCalls用maxRequestTokens默認(rèn) 30k壓在 Jev 32k 請(qǐng)求上限之下減去狀態(tài)與 20 token 請(qǐng)求開銷算出預(yù)算把問題拆成多批每批都重發(fā)同一份完整狀態(tài)Promise.all并發(fā)執(zhí)行后合并答案src/compact.ts。成本賬毫秒級(jí)、零生成、可回退決策路線的成本結(jié)構(gòu)幾乎全是判斷成本每批請(qǐng)求只輸出幾十個(gè)概率數(shù)字沒有生成文本的 token 費(fèi)用也沒有二次摘要的級(jí)聯(lián)開銷。社區(qū)實(shí)測(cè)口徑如Jev 不生成一個(gè)字卻干掉了 Agent 90% 的上下文、91.5% 壓縮率、壓縮耗時(shí) 5–20ms雖來自不同作者、數(shù)字口徑不一但方向一致決策壓縮的成本與延遲都低一個(gè)數(shù)量級(jí)。fast-jev-compaction 還做了一層工程保險(xiǎn)壓縮收益不足則回退。hooks/fast-jev.ts 中minReductionRatio默認(rèn) 0.25——若 Jev 裁掉的字符不足 25%插件 toast 提示fallback to built-in summary把session.compact事件交給 Claude Code 內(nèi)置摘要Jev 請(qǐng)求失敗、響應(yīng)畸形、缺 API key、歷史裝不進(jìn)狀態(tài)預(yù)算同樣觸發(fā)回退。決策路線因此不是孤注一擲而是能刪則刪、刪不動(dòng)就退。三、場(chǎng)景對(duì)比長(zhǎng)會(huì)話編程、RAG、多工具編排各適合誰(shuí)長(zhǎng)會(huì)話編程決策路線的主場(chǎng)fast-jev-compaction 從設(shè)計(jì)上就是為 Coding Agent 的長(zhǎng)會(huì)話定制的README 里那句a file path, exact error, constraint, or command can disappear even when it matters later直指編程場(chǎng)景的死穴。幾個(gè)源碼細(xì)節(jié)都為此服務(wù)釘選保護(hù)首條消息與最近 6 條永遠(yuǎn)不刪用戶的初始約束Never edit src/generated和正在進(jìn)行的操作鏈不會(huì)誤傷只刪工具調(diào)用不碰文本README 的 Limitations 明確寫著Only tool calls and results are candidates; text messages are never removed or shortened in the output——人類語(yǔ)言的語(yǔ)義完整性由規(guī)則保證模型判斷只作用于工具層截?cái)嗔艉劢Y(jié)果被刪時(shí)保留前 300 字符并追加[fast-jev-compaction truncated N chars…; re-run the tool if needed]src/compact.ts報(bào)錯(cuò)堆棧的頭部、CLI 參數(shù)的簽名都能留在視線里重跑兜底決策指令中明說whatever is not kept is deleted permanently, but the assistant can always re-run a tool or re-read a file——編程 Agent 的工具具有可重入性刪錯(cuò)了代價(jià)有限這正是決策路線敢刪的底氣。RAG記憶/檢索體系的主場(chǎng)決策路線在 RAG 場(chǎng)景幾乎無用武之地。RAG 的核心矛盾是語(yǔ)料在窗口之外需要的是把知識(shí)索引、持久化、按查詢召回——這是 Hermes 式記憶系統(tǒng)的能力圈。決策壓縮解決的是窗口之內(nèi)的垃圾而 RAG 解決的是窗口之外的寶藏兩者解決的問題根本不同。想用刪調(diào)用的思路管理知識(shí)庫(kù)等于用剪刀修水管。多工具編排中間地帶多工具編排里決策路線的優(yōu)勢(shì)是證據(jù)鏈完整——社區(qū)情報(bào)中反復(fù)出現(xiàn)的 K/Q/VKey/Query/Value三元組描述在源碼里的對(duì)應(yīng)物是STATE_CONTEXT與goalsrc/state.tsgoal默認(rèn)取最近三條用戶指令context明確告訴 Jev這是一段編碼助手對(duì)話正在被壓縮工具輸出已替換為簡(jiǎn)短注釋。也就是說Jev 是在知道任務(wù)目標(biāo) 看到全量歷史骨架的前提下逐條裁決的這比無目標(biāo)地批量摘要要精準(zhǔn)得多。但代價(jià)也在 README 的 Limitations 里寫著完整狀態(tài)隨每個(gè)請(qǐng)求重復(fù)發(fā)送歷史接近狀態(tài)上限時(shí)一個(gè)問題批次就是一次完整重傳——調(diào)用密度極高時(shí)請(qǐng)求數(shù)與 token 消耗會(huì)同步上升。四、融合猜想記憶 決策會(huì)不會(huì)是終局兩條路線各自承認(rèn)的邊界值得注意的細(xì)節(jié)是fast-jev-compaction 自己并不聲稱無損——README 的 Limitations 寫得很克制Calibration is at the request level; a probability is not a proof that a result is safe to delete.概率不是刪除安全的證明。這與社區(qū)里 Redis 之父對(duì) Jev 狂熱的質(zhì)疑絕大多數(shù)開發(fā)者其實(shí)不需要它遙相呼應(yīng)決策模型擅長(zhǎng)高頻、窄域、可回退的判斷但這條歷史值不值得留在語(yǔ)義深處仍是一個(gè)生成問題只是被工程手段降格成了判斷問題。每輪重新決定模型該看什么社區(qū)情報(bào)中有一條值得玩味的線索Jev 團(tuán)隊(duì)公開的 Coding Agent 設(shè)計(jì)草案提出每輪重新決定模型該看什么——這本質(zhì)上已經(jīng)不是壓縮歷史而是動(dòng)態(tài)選擇視野。把這條思路外推決策模型完全可以嵌入記憶系統(tǒng)的召回環(huán)節(jié)不是由規(guī)則或向量相似度決定召回什么而是由決策模型對(duì)當(dāng)前任務(wù) × 候選記憶逐條裁決。屆時(shí)記憶系統(tǒng)負(fù)責(zé)存得住決策模型負(fù)責(zé)看得準(zhǔn)壓縮從一次性的會(huì)話整理變成每輪推理前的實(shí)時(shí)視野管理。終局可能是分工而非取代回到標(biāo)題的問題兩條路線誰(shuí)走得更遠(yuǎn)從工程事實(shí)看它們不是同一場(chǎng)比賽。決策路線把上下文管理從昂貴的生成變成廉價(jià)的判斷在長(zhǎng)會(huì)話編程這種高頻率、可重入、證據(jù)敏感的場(chǎng)景里成本和確定性優(yōu)勢(shì)是結(jié)構(gòu)性的記憶/檢索路線則在知識(shí)持久化、跨會(huì)話復(fù)用場(chǎng)景里擁有不可替代的位置。真正的終局更可能是一種分工記憶系統(tǒng)決定什么值得長(zhǎng)期擁有決策模型決定此刻該看什么——一個(gè)管存量一個(gè)管流量。fast-jev-compaction 已經(jīng)把決策路線的工程范式釘選、分級(jí)擬合、概率裁決、可回退打磨成了可復(fù)用的開源積木src/index.ts 導(dǎo)出了compactMessages、buildJevRequest、fitState、decideCall等全套構(gòu)件下一步被接進(jìn)記憶檢索鏈路幾乎是順理成章的事。上下文管理的下半場(chǎng)贏家不會(huì)是只記住或只刪除的一方而是能把記憶的廣度和決策的鋒利組合起來的一方。【免費(fèi)下載鏈接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.項(xiàng)目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考