主动式Context Curator实践：Agent上下文管理新思路

一位开发者花三个月构建主动式上下文管理器 PRAANA，放弃了主流的 reactive compactor 路线。分层记忆、BM25+语义召回，但埋在细节里的 hash embedder 让整套系统悄悄坏了几周。

一个反直觉的选择：不等窗口塞满，每一轮都挑食

这两天 Reddit 的 r/MachineLearning 上有篇长帖引起不少讨论。作者把自己花三个月踩坑做的 context 管理器 PRAANA 摊开来讲，核心观点很直接：主流 coding agent 都在等上下文塞满再压缩，这条路是错的。

他的思路是把顺序颠倒过来——不做 reactive compactor，做 proactive curator。每一轮对话产生的新内容，进入上下文之前先过一遍筛子，不合格的根本不让它污染窗口。听起来像是常识，但真正这么干的团队并不多，Manus、Anthropic、Cognition 这几家一线团队讲 context engineering，重心大多还是在"塞满之后怎么办"。

这个反差挺有意思。到 2026 年这个时间点，Claude 4.5 和 GPT-5 的上下文窗口都已经是百万级别了，按理说应该没人再关心 context 管理才对。但事实恰恰相反，Chroma 那份《Context Rot》报告的结论在这一年被反复验证：窗口越长，模型注意力越涣散，推理能力衰减得越厉害。128K 能塞下不代表 128K 都有用，很多时候塞得越多反而越蠢。

Reactive Compactor 与 Proactive Curator 两种上下文管理范式对比示意图

Reactive vs Proactive：两条路的根本差异

先把两种范式讲清楚。

Reactive Compactor（主流方案）：

上下文窗口正常填充，工具输出、思考链、观察结果一股脑往里塞
触发阈值（比如 Claude Code 的 95%）后启动压缩
通常用 LLM 做摘要，或者直接截断早期消息
典型代表：Claude Code 的 auto-compact、LangChain 的 ConversationSummaryMemory

Proactive Curator（PRAANA 走的路）：

每个 context unit 进入工作记忆前都要打分
分层管理：active tier（当前活跃）、soft tier（可召回）、hard tier（归档）
按需从 soft/hard 层召回相关内容到 active
目标是让噪音根本不进来

两者的哲学差异在于对"信息价值"的判断时机。Reactive 假设所有 token 生而平等，等到不得不砍的时候再判断；Proactive 则认为信息价值在产生的那一刻就应该被评估。作者举了个很到位的例子：一个 agent 在第 3 轮做出的关键决策，其价值远高于第 15 轮某个已经解决的工具输出，但 reactive 方案往往对它们一视同仁，最终导致 context rot。

这个判断我觉得是对的。Manus 团队在他们那篇著名的博客里其实也隐约表达过类似观点——他们用文件系统作为终极上下文，本质上就是承认了"不是所有内容都值得留在窗口里"。区别在于 Manus 是被动 offload，PRAANA 是主动 curate。

PRAANA 的 Compiler：三层记忆 + 混合召回

技术实现上，PRAANA 的核心是一个叫 compiler 的组件，做几件事：

信息密度评分：每个 context unit（可以是一次工具调用、一段推理、一个用户输入）被拆解后打分。评分维度包括新颖性、决策相关性、后续引用概率等
三层分级存储：
- Active tier：当前推理直接可见
- Soft tier：短期缓存，通过检索可召回
- Hard tier：长期归档，需要显式请求
混合召回：BM25 词法匹配 + 语义相似度双通道，用 Transformers.js 在进程内跑 embedding，不依赖外部 embedding 服务

进程内跑 embedding 这个选择挺聪明。绝大多数 agent 框架为了做 RAG 或者 memory retrieval，都得挂一个 embedding API 或者本地跑个模型服务，延迟和部署复杂度都不低。Transformers.js 直接嵌进 Node 进程，冷启动之后每次召回都是内存级操作，这对于 coding agent 这种高频交互场景是关键的。

三个月的坑：一个 placeholder embedder 毁了整个召回

这才是全文最值得看的部分。作者坦承：语义召回系统悄悄坏了好几周他都没发现。

事情是这样的。项目早期为了快速跑通链路，他随手写了一个 hash-based embedder 做占位符——就是把文本 hash 一下映射成向量。这种东西你我都写过，本意是"先让流水线跑起来，回头再换真 embedder"。

然后就忘了。

后果是什么？BM25 那一路还在正常工作，语义那一路持续往召回排序里注入噪音。因为 hash embedding 的向量距离是随机的，语义相似度分数完全没有意义，但代码里它照样参与最终排序的加权。整个系统看起来一切正常——召回有结果、agent 有响应、任务能完成——只是效果诡异地不稳定。

作者是怎么发现的？他说是有一次做 A/B 测试，把语义通道完全关掉，纯 BM25 反而效果更好。这才反过来去 debug，发现根本原因。

这个故事对做 agent 系统的人特别有警示意义：

占位符是技术债的高发区，尤其是在多阶段流水线里，一个环节的静默失效很难被端到端指标捕捉
混合召回的加权策略需要能独立评估各通道，如果你的评估体系只看最终排序质量，中间某一路完全跑偏你也发现不了
回归测试要覆盖检索质量本身，不能只测 agent 的任务完成率

三层记忆架构与混合召回流程图

和主流方案比，proactive 到底强在哪

作者没有把 PRAANA 吹成银弹，这点难得。他明确指出了几个 tradeoff：

优势场景：

长链路 coding agent（比如超过 30 次工具调用）
需要跨会话保持一致性的场景
对成本敏感、想压 token 消耗的生产部署

不适合的场景：

短对话（10 轮以内），curator 的开销大于收益
探索性任务，你也不知道什么信息重要
需要严格可复现的 debugging 场景，因为 curator 的决策引入了不确定性

和 Manus 的方案对比也很有意思。Manus 有几个核心原则：KV-cache 命中率优先、工具用 mask 不用移除、文件系统作为外部记忆、保留错误痕迹。这些其实和 proactive curation 并不冲突——你完全可以在 curator 里把"KV-cache 稳定性"作为一个评分维度，比如惩罚那些会插到 prompt 前部的修改。

真正的冲突点在于 Manus 那条"保留错误"的原则。Manus 认为失败的尝试应该留在上下文里，让模型隐式更新信念。但 proactive curator 天然倾向于把"已解决的错误"打低分踢出 active tier。这里怎么权衡，作者也没给出清晰答案，我觉得实际做法应该是：错误信息保留在 soft tier，需要时召回，而不是永久驻留 active。

一个更宏观的问题：context engineering 还要做多久

看完这篇分享，其实绕不开一个更大的问题——2026 年了，模型窗口越做越大，KV-cache 越来越便宜，我们还有必要在 context 管理上投这么多工程精力吗？

我的判断是：短期内没得选，长期看会被吃掉一部分。

短期看，Chroma 的 context rot 结论没被推翻，长窗口下的注意力涣散是 transformer 架构层面的问题，不是靠堆窗口能解决的。只要 agent 的工具调用还在往几百次的量级走（Anthropic 的多 agent 研究已经出现了这种规模），context engineering 就是刚需。

长期看，模型本身会内化一部分 context 管理能力。你已经能在 GPT-5 和 Claude 4.5 上看到这个趋势——它们对长上下文中的"过时信息"有了初步的自我识别能力，会主动忽略。但这种内化目前还比较粗糙，做不到 curator 那种细粒度控制。

所以 PRAANA 这类工作的价值，短期是补模型的能力短板，长期是沉淀出 context 管理的最佳实践模式，等模型真的把这些能力吸收进去，工程侧的复杂度自然会下降。

一点实操建议

如果你正在做 agent 系统，不管走 reactive 还是 proactive，有几条建议：

先建评估体系再谈优化。检索质量、token 消耗、任务完成率、KV-cache 命中率，这几个指标要能独立测量
占位符代码写完立刻加 TODO 和监控。作者踩的坑 90% 的团队都会踩
BM25 别丢。语义召回时髦，但 BM25 在代码、命令、精确 term 匹配这些场景下依然是最稳的 baseline
分层记忆的层数别贪多。三层已经足够，五层七层的方案通常是过度设计
保留错误痕迹这件事上信 Manus。除非你有强证据证明错误信息在污染决策，否则别急着清理

顺带一提，如果你要在多个模型上对比 context 管理策略的效果——比如同一套 curator 在 Claude、GPT、Gemini、DeepSeek 上表现如何——OpenAI Hub 一个 Key 调所有主流模型这个特性倒是省事，兼容 OpenAI 格式，切换模型只改 model 参数就行，不用为每家 SDK 各自适配一遍。

Agent 时代的工程复杂度正在从"怎么让模型更聪明"转移到"怎么让模型看见对的东西"。这个转移还会持续相当一段时间。