オープンソースのagent memory「Stash」　HNがすぐ突っ込んだ論点

発想は刺さったが、検証はもっと速かった

Hacker NewsでStashが話題になった理由は明快だ。ClaudeやChatGPTのような閉じたassistantの中に閉じ込められていた長期memoryを切り出し、どのagentにも付けられるようにするという発想だからだ。ただしスレッドは歓迎ムード一色ではなかった。むしろ最初から検証モードだった。論点は「persistent memoryが理論上便利か」ではなく、「それでpromptが汚れないのか」に集まった。

紹介ページによれば、Stashは28個のMCPツール、6段階のパイプライン、PostgreSQL + pgvectorを土台にしたmemory layerだという。rawなepisodesをfactsへ、factsをrelationshipsやpatternsへ昇格させ、goals・failures・hypothesesまで保持する設計も示している。さらにnamespaceを切って、ユーザー情報、プロジェクト情報、agent自身の知識を分けて扱う。技術的な売りは、単なる保存ではない。モデルをまたいでも必要な記憶だけを呼び戻せる継続性だ。

HNがすぐに投げた反論

ただ、実戦の視点では疑いが強かった。初期コメントから「memoryは理論上は良いが、大きくなるほど結局また散らかる」という声が出た。ある読者は、手で管理するAGENTS.mdやPROJECT.mdのほうがまだ制御しやすいと言う。別の読者は、結局はpgvectorにremember/recallを載せたRAGに見えると指摘した。さらにチーム開発では、誰のmemoryが最新なのか、別の作業領域の情報が次のsessionへどれだけ混ざるのか、という問題もある。要するに、保存技術より選別技術が問われている。

なぜこの論争が重要か

今のagentツールで本当に難しいのは、「記憶を保存できるか」ではない。多くのシステムはすでに保存している。難しいのはrecall precisionとnamespace hygieneだ。何をmemoryへ昇格させるのか、何を捨てるのか、何を今回のtaskには出さないのか。その設計が甘いと、継続性はそのままノイズになる。HNがStashに食いついた理由もそこにある。オープンなmemory layerへの需要自体は明らかだ。だが需要がそのまま有効性の証明にはならない。Stashがこれから示すべきなのは、memoryを持つことではなく、memoryが昨日の文脈を今日の雑音に変えず、実際の再開速度を上げられるかどうかだ。

出典: Stash紹介ページ · Hacker News議論