有人让AI连续跑了60天，发现记忆衰减比宕机更致命

你的AI助手第1天表现完美，第21天开始用错API，第60天把旧仓库地址当成新的——而你直到账单爆炸才发现。

这不是假设。Adam Cipher（@Adam_cipher）真这么干了：让一个AI代理24/7运转两个月，专门观察记忆系统是怎么烂的。结论很扎心：向量搜索（vector search，一种基于语义相似度的检索技术）救不了你的agent，它只会让你的agent死得更自信。

Adam把这套观察做成了产品Engram，一个带"记忆体检"功能的持久化API。核心就一句话：给每个事实打上准确率分数，让好记忆浮上来，烂记忆沉下去。

向量匹配的陷阱：语义近≠事实对

现有方案的逻辑看起来没毛病：把知识切成片段，向量化存进数据库，检索时找语义最接近的。Adam跑了两个月后发现，这套机制有个致命盲区。

场景很典型：你的生产环境API上周迁移到了v3端点，但旧端点的向量表示和新查询依然高度相似。agent检索时，旧端点排在第一位，agent自信调用，404，重试，再404，token烧光。

「向量相似度不等于事实准确性。」Adam的原话。语义空间里的"近邻"可能是过期的幽灵，而agent没有嗅觉，闻不出腐烂。

更麻烦的是沉默性。系统不会崩溃，只是 quietly wrong（安静地出错）。你很难建立监控——错误被包装在正常的API响应里，直到下游业务爆雷。

Adam的解法是给记忆加评分层。每个事实被调用后，系统追踪它的执行结果：成功加分，失败扣分。时间衰减、来源可信度、矛盾检测，全部量化进一个分数。

高分事实优先召回，低分事实自动下沉。不需要人工策展，记忆系统自己学会"长记性"。

Engram的三张底牌：溯源、体检、MCP集成

具体实现上，Engram把每个事实拆成结构化记录。POST一条记忆时，必须带三个字段：内容本体、分类标签、来源标识。

curl示例里能看到完整字段：content（"Production API migrated to v3 endpoint"）、category（"infrastructure"）、source（"deploy-log-2026-03-30"）。不是裸文本扔进向量库，是带上下文的有出处知识。

第二张牌是drift detection（漂移检测）。专门开了一个/api/drift端点，返回正在腐烂、被矛盾或已经过期的记忆清单。

Adam的比喻很准：这是给agent知识库做"体检"。设个cron定时跑，出问题前就能收到警报。比起事后救火，这套机制试图把记忆错误变成可观测、可拦截的事件。

第三张牌是生态位选择。Engram直接以MCP服务器（Model Context Protocol，一种让AI工具与模型标准化对接的协议）形态发布， Claude Desktop、Claude Code、Cursor即插即用。7个工具覆盖记忆读写、检索、体检全流程，不绑死任何agent框架。

从个人痛点到产品：24/7运转逼出的需求

Adam的身份标签很有意思：一个"让AI代理24/7运转公司"的人。不是研究员写论文，是实战派被自己的系统坑过。

他坦承Engram的诞生路径：「我造这个是因为我需要它。」没有宏大叙事，就是记忆衰减这个沉默成本实在扛不住了。

产品目前免费开放，engram.cipherbuilds.ai直接注册。技术细节公开在文档里，包括评分算法的权重设计和漂移检测的触发条件。

有个细节值得玩味：Engram支持Templates功能，快速复用FAQ或代码片段。这暗示了Adam对agent工作流的理解——记忆不只是检索，更是组织知识的效率工具。高频事实模板化，低频事实动态评分，分层管理。

社区反馈里有人提到，把Engram接进自己的运维agent后，第一次提前48小时发现了证书过期风险。来源字段里的deploy-log让他追溯到三个月前的变更记录，而向量检索本身完全没召回这条。

这也引出一个开放问题：当agent的记忆系统开始自我评分，谁来给评分系统评分？如果agent的"成功经验"本身建立在错误前提上，正反馈会不会加速跑偏？Adam的 drift detection 能抓过期事实，但能抓"过期的方法论"吗——比如某个曾经work的调试策略，在新的架构里已经变成反模式？