Qarinah：编程Agent上下文压缩方案

Qarinah 编译了一个紧凑的、带引用的项目记忆包，而不是要求每个新的编码 Agent 会话都重放整个可用历史。

已发布的估算

在六个已提交的软工任务fixture中，全历史基线包含 442,113 个可移植的估算输入上下文 token。Qarinah 路径使用了 5,682 个。每个目标仍然直接出现在前五个结果中。

减少 436,431 个估算输入上下文 token；

减少 98.71% 的重复上下文；

以及 77.81:1 的基线-包比率。

这个比率不是说每个提供商的账单都会减少 98.71%，也不是说 Agent 会话持续时间会增加 77.81 倍。它衡量的是已发布的六fixture估算中相比的输入上下文量。

同样的 token 费率会产生什么成本

该表将四个固定的、未缓存的输入 token 费率应用于相同的两个 token 估算值。这是算术计算，不是提供商发票。

estimated tokens / 1,000,000 x flat input rate

它有意排除了提供商原生分词、缓存、输出 token、推理 token、工具调用、检索、托管和固定费用。实际成本取决于提供商、模型、缓存行为、上下文构成，以及相同历史被重新发送的频率。

为什么这个包仍然有用

压缩只有在下一个任务仍然能找到证据时才有意义。基准测试同时检查了体量和检索覆盖率：每个目标都必须直接出现在前五个结果中。Qarinah 保留了所选上下文的源事件 ID 和内容哈希，因此后续 Agent 收到的是可检查的有限交接，而不是一个不透明的故事。

Qarinah 还在 40、50 和 100 个文件的项目中通过了 380 个确定性文件级精确和容错查询测试。这些测试验证了检索行为；它们没有确立通用任务质量或与每个记忆系统的排名。

方法论、fixture 记录、成本和排除项是公开的：

机器可读指标

Qarinah 是 Apache-2.0 且优先本地运行。它与 Codex、Claude Code、Cursor、CLI 工具和兼容的 MCP 客户端配合使用。项目捕获是可选的，默认仅元数据，不捕获隐藏的推理。

如果每个选中的项目都能指回其来源，你会更信任 Agent 记忆吗？