#記憶管理

この記事を読んでまず思ったのは、これはMCPそのものの話というより、「複数の agent が同じ記憶を使うとき、人はついそこを雑に信じてしまう」という、かなり現実的な危うさの話だなということだった。tool 呼び出しがうまくいっていても、あとから参照される memory が汚れていたら全部が崩れる。しかも厄介なのは、その壊れ方が一発で終わらず、間違った情報が“正しい前提”として積み上がっていくところだと思う。 特に引っかかったのは、この記事が「プロンプトで気をつけよう」ではなく、かなりはっきり構造の問題として書いている点だった。memory に provenance envelope を付けるとか、namespace を分けるとか、read 時に verification hook を噛ませるとか、地味だけど効く話が並んでいる。こういうのは派手さはないけれど、後から事故調査をすると一番効いてくるやつだと思う。逆に言うと、ここを作らずに「zero trust です」と言っても、ただの標語にしかならない、という主張にはかなり納得した。 ただ、読んでいて少し重くもなった。二重確認や huma

AIエージェントに何を覚えさせるか、どう呼び出すかは、実はかなり面倒な問題です。Cal Paterson はそこに対して、記憶を巨大なパイプラインではなく、もっと素朴な「ファイル形式」として扱おうと提案しています。記事の狙いは、既存の agent memory がなぜ使いづらいのかを整理したうえで、より単純で移植しやすい代替案を示すことにあります。単なる思いつきではなく、Markdown や SQLite、semantic search をどう組み合わせるかまで踏み込んでいるのが面白いところです。 記事の中心にあるのは、agent memory を処理工程ではなくデータとして扱おう、という考え方です。著者はまず、今よくある記憶システムを3種類に分けて批判します。ひとつ目は、特定のハーネスやプラットフォームに縛られるタイプです。会話履歴から情報を抜き出す設計が多く、結局「その人についての記憶」ばかりが増えやすい。ふたつ目は、pgvector、Neo4j、独自の LLM まで使うような複雑すぎる仕組みで、管理も大変だしモデルを混乱させる、と言います。みっつ目は、理想化された graph や

この記事を読んでまず思ったのは、「AI の記憶」を立派な仕組みとして扱う前に、せめて壊れ方を見張る発想が必要だな、ということでした。 発想自体はかなり地味です。派手なベクトルDBではなく、Markdownファイルを人間が読める形で持ち、そこに壊れたリンクや日付抜け、肥大化を検査する。けれど、その地味さがむしろ筋がいいと思いました。AIの記憶って、最新の検索技術より先に「どれだけ信じてよいか」が問題になるので。 特に引っかかったのは、「記憶が壊れるときは静かに壊れる」という見方です。ファイル名を変えたせいで wikilink が死んでも、すぐには誰も気づかない。日付のないメモは、後から見返したときにいつの知識なのか分からない。こういうのは、モデルの性能というより運用の話ですが、実際にはここで思った以上に品質が落ちるはずです。AIはそれっぽく読めてしまうぶん、間違いが見えにくい。だからこそ、機械が自分で点検する仕組みは必要だと思いました。 もう一つ面白かったのは、削除を禁止するのではなく「意図的にする」よう促している点です。pre-commit hook で大量削除を止める、というのはかな