89% 准确率背后:工程级上下文不是塞进 prompt 那么简单
2026 年 8 月 31 日,Decispher 创始人 Ali 在 Hacker News 发了 Show HN 帖,标题一句话点题:「给 coding agent 装一层持久化工程上下文与内存」。帖子里直接给出了一组让所有做 agent 基础设施的人都会停下来看的数字——他们的系统在 LongMemEval 基准上达到 89% 准确率(oracle split,使用 GPT-4.1-mini 作为抽取与读取器),在 LongMemEval-S 子集上是 81%(用 frontier 模型可达 89%),同时实现 38 倍的中位 token reduction。
这三个数字不是孤立指标,它们一起回答了一个被无数工程师反复问过的问题:「agent 怎么才能记住上个 session 干了什么」。在过去两年里,主流解法是把上下文硬塞进 prompt——结果是要么 context window 爆掉,要么 token 费用爆掉,要么 agent 把无关信息也当真、跑偏方向。Decispher 的路径是反过来的:不靠 LLM 的 context window 记东西,靠独立的工程上下文层 + 内存层按需检索。
Decispher 的产品结构分为三块:Context Engine(把分散在 GitHub PR、Jira ticket、Slack 讨论、ownership 边界、架构决策里的工程信息聚合成可检索的「context unit」)、Memory Plane(在 user / team / project 三个层级持久化偏好与工程规约,团队可以建「frontend」「payments-backend」这种可复用的 memory set,根据任务注入)、Worker Agent(在前两层之上跑的自主执行 agent,可以从 Jira 和 Slack 接活、检索上下文、必要时反向问人)。三个组件可以独立使用。
帖子里 Ali 给出的工程细节是这种项目真正的含金量:Context Engine 不克隆源代码,只通过 GitHub API 读写;Worker Agent 跑在隔离沙箱里,除了 allowlist 代理之外没有出网路由;沙箱每次跑完销毁;原始消息与文本静态加密,合并后 7 天或最后一次活动后 30 天自动清除,保留期可配。这是一份把「隐私 + 安全 + 自动化」三件事一次性闭环的设计,不是把开源 LLM 套个壳就上线的那种 demo 项目。
96% R5 和零 LLM 调用:另一条路长什么样
几乎同期(2026 年 9 月 7 日),另一个完全独立的项目 Awareness Market 团队发了 Awareness Local,定位是「本地优先的 coding agent 内存层」,同样在 LongMemEval 上刷分,数字更激进——R@5 96.0%(500 题 480 对),Recall@1 80.2%,Recall@3 92.8%,Recall@10 98.6%。同样关键的是:整个检索过程零 LLM 调用,纯 BM25 + 向量混合 RRF,跑在 Apple M1、8GB RAM 上 35 分钟跑完全部 500 题。
Awareness Local 和 Decispher 走的是同一条「独立内存层」路线,但解法风格完全不同。Decispher 用 GPT-4.1-mini 做抽取器(reader/extractor),架构上是「agent + LLM-assisted retrieval」;Awareness Local 强调纯检索、零 LLM、hybrid 关键词 + 向量(用 multilingual-e5-small),记忆存为 .awareness/ 下的 Markdown,本地 SQLite FTS5 索引,跑一个轻量 daemon 在用户机器上。一句话总结区别——Decispher 是「带 LLM 抽取的工程上下文平台」,Awareness Local 是「零 LLM 的本地内存 daemon」,两者都解决同一个问题,但取舍不同:Decispher 更适合企业级多团队协作(需要 LLM 抽取工程语义),Awareness Local 更适合个人开发者或对隐私极敏感的小团队(完全本地、不调云端 LLM)。
Awareness Local 的 README 里给了一张表,把主流长记忆方案的 LongMemEval 成绩摆在一起对照:MemPalace(ChromaDB raw)96.6% 但只是 R@5;Awareness Memory 96.0%;OMEGA 95.4%;Mastra(GPT-5-mini)94.9%;Mastra(GPT-4o)84.2%;Supermemory 81.6%;Zep/Graphiti 71.2%;GPT-4o 直接全上下文 60.6%。第一名不是 Awareness 自己,而是 MemPalace——但 MemPalace 的 96.6% 是 R@5 only,评估时 palace hierarchy 没用上,实际部署无法复用;第二名 Awareness Memory 是 hybrid RRF,生产可用;Mastra 系列和 Supermemory 是 LLM 介入的方案,成本和延迟都不一样。这张表提供了一个难得的横向坐标——以前想做长记忆优化的工程师几乎拿不到同一基准下的多方案对比,Awareness 这次公开跑分,某种程度上把整个领域的「我做得最好」式营销往「白盒对比」拉了一步。
38× token reduction 意味着什么
回到 Decispher 给的那个 38× 中位 token reduction 数字。这不是一个学术指标,它直接对应到企业能不能把 agent 用到生产里。一个 Claude Code 的典型工程任务,如果不靠外部内存层,需要把当前 PR + 历史 PR + Jira ticket + Slack 讨论 + 架构决策 + ownership 信息全塞进 context window,一个中等复杂度的特性实现可能要消耗 50k-100k tokens;用了 Decispher 这类系统后,只检索「这个特性直接相关的」context unit,可能 1k-3k tokens 就够。38 倍 reduction 实际意味着从「每次交互成本 1-2 美元」压到「每次 3-5 美分」,这对一个日均跑几千次 agent 调用的大型工程团队来说,一年就是百万级美元的差别。
更深一层的影响是模型选择面变宽。当 38× reduction 让单次交互 token 数压到几千,选择 GPT-4.1-mini 还是 Claude Sonnet 4.5 这种中档模型就能跑完整流程,不必为了省钱压缩上下文或牺牲质量。内存层不只是省钱工具,是把模型选择面从「前沿闭源旗舰」扩展到「中档开源」的转换器。这对企业 IT 在 2026 年下半年的多模型策略有直接影响——可以混部多个不同供应商的模型,内存层做共享的工程上下文底座。
一个被严重低估的安全面
Decispher 在帖子里专门讲了 Worker Agent 的沙箱隔离细节:隔离沙箱没有出网路由,只能通过 allowlist 代理;每次跑完销毁沙箱;原始消息静态加密,自动清除。这不是安全部门催出来的合规清单,这是 agent 类系统能不能进企业生产环境的硬门槛。
2026 年上半年的几次重大 agent 安全事件(Anthropic、OpenAI、Microsoft Copilot 都有公开披露)都指向同一个攻击面:agent 拿到超出任务需要的权限 + 持久化访问敏感上下文 = 数据外泄路径。如果一个 coding agent 的内存层是「明文持久化 + 跨任务共享 + 没有 retention 控制」,那它就是一个被设计出来的内部威胁。Decispher 的 7 天 / 30 天自动清除 + 静态加密 + 沙箱隔离三件套,本质上是把这个攻击面的可利用窗口期压到最短。Awareness Local 的「本地优先 + Markdown 存储 + 可选 cloud sync」则是另一条防御路径——攻击者想拿你的 agent 内存,先得物理/远程访问你的开发机,这比攻破一个云端 SaaS 服务难度高一个数量级。
这两条路径都指向一个事实:2026 年下半年,企业部署 coding agent 的安全审查清单里,「内存层是怎么实现的」会从可选项移到必选项。一个还在用「把整段对话历史无加密塞进向量数据库」的 agent 产品,会跟当年用明文存密码的 SaaS 一样被淘汰。
给工程师和 IT 决策者的具体建议
把 Decispher 和 Awareness Local 这两份发布叠在一起看,可以提炼出 2026 年下半年 coding agent 基础设施选型的三条具体建议。
第一,长记忆能力先看 LongMemEval 跑分,再问「支持几个 IDE」。 这是评估 coding agent 配套工具的反向选择逻辑——多数项目会让你看「我们支持 Claude Code / Cursor / Copilot / Cline / Windsurf」这种 IDE 兼容列表,但这是表层;底层问题是「这个工具能不能在 500 题的 LongMemEval 上稳定拿到 80% 以上的 R@5」,这个数字决定它在实际生产任务里的可记忆容量。如果一个工具兼容 20 个 IDE 但 LongMemEval 上只有 50%,那它在跨 session 任务里还是会「失忆」,IDE 兼容再多也是空架子。
第二,内存层架构要看 LLM 调用次数,不是看功能列表。 Decispher 用 GPT-4.1-mini 做抽取,Awareness Local 零 LLM 调用,这两条路径成本结构完全不同。如果你的工程团队对单次交互延迟敏感(<500ms)且数据隐私要求极高,纯检索的 Awareness Local 路径更合适;如果你的场景是「跨团队、跨项目、需要理解架构决策上下文」,LLM-assisted 的 Decispher 路径更合适。但要警惕「宣传里 LLM 调用 0 次,实际部署里偷偷加 LLM」的伪 zero-LLM 方案——查清楚 RRF pipeline 里到底有哪些步骤是 deterministic、哪些是 model-assisted。
第三,retention 和 sandbox 是采购红线,不是 nice-to-have。 Decispher 明文写的「合并后 7 天 / 最后活动后 30 天自动清除 + 沙箱销毁 + 静态加密」三件套,可以直接抄进你公司的 agent 工具采购 RFP。一个内存层工具如果连 retention 策略都不愿意公开,或者 sandbox 隔离没明确边界,基本可以判定它没有企业级安全设计,无论营销话术多漂亮。
一个仍未解决的开放问题
两份发布合在一起,真正暴露的是 LongMemEval 这个基准本身的局限。500 题、5 个能力维度、ICLR 2025 的学术测试集——它衡量的是「agent 能不能从 115k token 长的对话历史里准确召回信息」,但工程场景里的「记忆」远不止召回。 工程场景里还要测:跨 PR 链接的因果推理、跨代码所有权变更后的 context 迁移、跨人员轮换后的「昨天谁做的决定」还原、跨 6 个月以上的项目重启后「为什么当时不这么写」的解释。LongMemEval 测的是精确召回,工程场景测的是「对过去的解释能力」,后者目前还没有公认基准。
对做 agent 基础设施的团队来说,2026 年下半年最值得投入的方向可能正是这个——开发一个面向工程团队的「跨 session 工程记忆」基准,让 Decispher / Awareness Local / Mastra / Supermemory / Zep 都能在上面跑分。Awareness 这次公开 leaderboard 的做法已经开了个头,接下来会有更多团队跟。但要注意的是:真实工程场景的标注成本远高于 LongMemEval(后者是学术数据,前者需要工程团队手动标注或半自动合成),谁能先拿出一个开源、可复现的工程级长记忆基准,谁就在下一个 agent 时代的标准化讨论里占据主动。
