为什么我构建了一个主动上下文策展器而不是压缩器——以及三个月里我搞错了什么

有两种方式来处理即将填满的上下文窗口。被动方式：等待它填满，然后压缩所有内容。主动方式：在每一轮中精挑细选要添加的内容，这样噪音从一开始就不会堆积起来。大多数编码代理走的是被动路线。我花了几个月构建主动方式，现在我想诚实地谈谈哪些真正有效，哪些没有。 什么才是真正重要的——你的代理在第3轮做出的决定，比第15轮工具的输出（已经解决）更值得消耗token。如果一视同仁，就会导致上下文腐烂。PRAANA的编译器将工作记忆分为活跃层、温和层和硬层。它根据信息密度对上下文单元进行评分，然后使用BM25加语义相似度（Transformers.js，进程内运行）来决定哪些内容被拉回活跃窗口。 我哪里搞错了——语义召回悄悄坏掉了好几周。我早期临时拼凑了一个基于哈希的嵌入器作为占位符。问题在于它向召回排名中注入了噪音。记忆以错误的顺序返回，不相关的条目浮现在相关条目之上。最糟糕的是：它看起来还挺合理。没有错误，只是结果不对。花了我三周才注意到。我通过切换到Transformers.js并以纯关键词全文搜索作为后备方案修复了这个问题。新规则：如果没有真正的语义嵌入器可用，那就只使用关键词召回。永远不要使用伪造的向量。 测量缺口——在项目的大部分时间里，我实际上无法证明上下文引擎优于普通的文本记录代理。“感觉更好”不能算作证据。几周前，一个遥测记分卡落地了——提供了会话级别的信号，如上下文压力、记忆召回百分比、技能加载与衰减、每部分的token核算。A/B评估框架是下一步要做的。教训：在构建你试图衡量的东西之前，先构建测量工具。 代理营销中的诚实问题——PRAANA的记忆存储和召回带有时间衰减。强化路径（在会话成功时提升置信度）已经接线，但实际触发它的信号还没有发布。所以我称之为“存储和召回”，直到这个循环闭合并且我可以展示它工作。如果一个用户看到记忆以高置信度浮现出一个过时的信念，就会对整个系统失去信任。在基准测试之前公布你的局限性，不仅仅是道德问题——这是一个产品决策。 更大的计划——四个系统：自适应上下文、认知记忆、后台整合、智能路由。所有系统都与领域无关。系统中没有任何部分专门了解代码。编码代理仅仅是试验场，因为结果容易衡量：代码是否工作，花了多少轮次，是否避免了重复上一会话中的同一个错误。第二阶段是提取运行时，以便其他开发者可以在此基础上构建领域代理。在第一阶段验证架构之前，我不会碰那个提取。这种自律是整个项目中最难的部分。 GitHub: amitkumardubey/praana — MIT, TypeScript, Bun.