[{"data":1,"prerenderedAt":229},["ShallowReactive",2],{"content-\u002Fcontents\u002Fagent-memory-characterization":3,"surroundPost-\u002Fcontents\u002Fagent-memory-characterization":220},{"id":4,"title":5,"body":6,"createdAt":204,"description":205,"draft":206,"extension":207,"meta":208,"navigation":209,"path":210,"seo":211,"stem":212,"tags":213,"thumbnail":218,"updatedAt":204,"__hash__":219},"contents\u002Fcontents\u002Fagent-memory-characterization.md","Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads",{"type":7,"value":8,"toc":180},"minimark",[9,13,17,20,23,26,29,32,35,38,43,46,49,52,55,58,61,64,67,70,73,76,79,92,95,109,112,120,124,128,131,135,138,142,145,149,152,156,159,163,166,170,173,177],[10,11,12],"h2",{"id":12},"どんな論文か",[14,15,16],"p",{},"この論文は、長期タスクをこなす LLM エージェントの memory system を、accuracy benchmark だけでなくシステム負荷として測る。対象は、会話履歴や tool trace を保存し、後続セッションで検索し、必要なら更新する agent memory である。",[14,18,19],{},"著者らは、agent memory を4つのパラダイムに分類する。長文コンテキスト、Flat RAG、構造化 RAG、Agentic control flow である。それぞれ、書き込み側の構築処理、保存構造、検索方法、更新可能性が異なる。",[14,21,22],{},"論文の強い点は、memory をただの検索精度の問題にしないところにある。construction、retrieval、prompt assembly、generation、maintenance に分け、どこで token、embedding、GPU energy、latency が発生するかを測っている。",[14,24,25],{},"結論はかなり実務寄りだ。高機能な agentic memory は柔軟だが、構築コストや tail latency が重い。逆に BM25 のような単純な方式が、 recall-heavy な workload では強いこともある。したがって memory system は、更新頻度、クエリ量、鮮度要件、許容遅延、fleet-scale の管理コストで選ぶ必要がある。",[14,27,28],{},"Agent Memory は、エージェント自身の interaction stream から作られる可変の外部状態を扱う。通常の RAG が静的な文書集合を検索するのに対し、agent memory はユーザーとの会話、tool output、環境からの feedback を継続的に保存・検索・更新する。",[14,30,31],{},"この論文は、agent memory の精度そのものを競うより、memory system が実運用でどんな負荷を生むかを調べる。長期エージェントを scale させるには、memory をモデルの外側にある状態管理基盤として見る必要がある、という立場で読むとよい。",[10,33,34],{"id":34},"課題と貢献",[14,36,37],{},"第一の貢献は、agent memory system を construction、storage、retrieval、mutability の観点で分類する taxonomy である。代表的な10システムを、長文コンテキスト、Flat RAG、構造化 RAG、Agentic control flow に整理している。",[39,40,42],"h3",{"id":41},"第二の貢献はphase-aware-profiling-harness-である","第二の貢献は、phase-aware profiling harness である",[14,44,45],{},"memory construction、retrieval、generation にかかる token、model call、GPU utilization、latency を分解して測る。",[14,47,48],{},"第三の貢献は、LongMemEval と MemoryAgentBench を使った system characterization である。construction cost、construction LLM の capability floor、query volume による amortization、freshness-latency tradeoff、storage growth、tail latency を横断して見ている。",[10,50,51],{"id":51},"手法のしくみ",[14,53,54],{},"論文は agent memory の実行を、ingestion、memory construction、storage、retrieval、prompt assembly、generation、maintenance に分ける。この分解により、精度だけでは見えない write path と read path の違いが見える。",[14,56,57],{},"比較対象には BM25、EmbedRAG、GraphRAG、HippoRAG v2、Mem0、SimpleMem、A-Mem、Letta、MIRIX、long-context baseline などが含まれる。単純な検索から、LLM が記憶の書き込みや検索を制御する agentic system までを同じ測定枠に置く。",[14,59,60],{},"評価では、construction を終えてから query する batch regime だけでなく、セッションが連続して届き、前の session の write が次の query に効く freshness-latency regime も見る。これにより、非同期に構築して latency を隠すと記憶が古くなる、という運用上の問題が浮かび上がる。",[10,62,63],{"id":63},"検証結果",[14,65,66],{},"長期 workload では full-history prefill が重く、agent memory は per-query serving latency を大きく下げる。ただし memory system 間にも2桁規模の latency 差があり、accuracy だけでは選べない。",[14,68,69],{},"LLM-mediated な memory system では、construction energy が lifecycle の大部分を占める。論文では、300 query の QA phase よりも construction が支配的になるケースが多く、energy per correct answer でも大きな差が出ると報告している。",[14,71,72],{},"construction は embedding と prefill に強く支配される。これは、通常の latency-sensitive QA traffic と同じ serving stack に載せると干渉しやすいことを意味する。",[14,74,75],{},"MemoryAgentBench では、BM25 が aggregate で高い accuracy と軽い construction を示す一方、paraphrase、multi-hop、temporal inference のような難しい条件では構造化・agentic memory の意義が出る。単一の最良システムはなく、construction cost、per-query latency、accuracy の frontier 上で選ぶ必要がある。",[10,77,78],{"id":78},"限界と読みどころ",[80,81,82,86,89],"ul",{},[83,84,85],"li",{},"評価は代表的な10システムと2つの benchmark suite に基づくため、すべての memory workload を代表するわけではない。特に multimodal memory や multi-agent \u002F distributed memory の一貫性問題は今後の課題として残っている。",[83,87,88],{},"また、BM25 が強く見える結果は、MemoryAgentBench の aggregate が exact-match retrieval を報いる構成を含むためでもある。すべての実務 memory で BM25 が十分という意味ではない。",[83,90,91],{},"それでも、この論文は agent memory を選ぶ時の問いを変える。どれが一番賢いかではなく、この workload ではどの phase にコストを寄せるべきか、どの freshness と latency を許すかを考えるための土台になる。",[10,93,94],{"id":94},"読みながら見る図表や節",[80,96,97,100,103,106],{},[83,98,99],{},"Figure 1 は、agent memory を write path と read path を持つ二層の記憶として見る入口になる。外部に保存された long-term memory から必要なものを working memory へ戻す、という見方が重要。",[83,101,102],{},"Table 1 は、10システムを construction、storage、retrieval、mutability で並べる taxonomy の中心。memory system の名前ではなく、どの型に属するかを見ると運用負荷を予測しやすい。",[83,104,105],{},"Figure 3 と Figure 4 は、construction が lifecycle cost を支配することを示す。query time だけ見ていると安く見える system でも、構築に大きな energy と時間を払っていることが分かる。",[83,107,108],{},"Figure 7 と Figure 8 は、construction、serve latency、accuracy、freshness の間に単純な勝者がないことを示す。実運用では query arrival pattern と update pattern を先に決める必要がある。",[10,110,111],{"id":111},"次に読むなら",[80,113,114,117],{},[83,115,116],{},"次に読むなら、Is Agent Memory a Database? と VikingMem をつなげるとよい。この論文が system cost の地図を出し、前者が agent memory を data foundation として、後者が memory base として扱う。",[83,118,119],{},"おい丸の運用に引きつけるなら、brain \u002F wiki \u002F state \u002F audit log \u002F skill を単に保存場所としてではなく、construction cost、retrieval latency、freshness、maintenance policy を持つ memory system として棚卸しできる。",[10,121,123],{"id":122},"読後qa","読後Q&A",[39,125,127],{"id":126},"この論文の中心問いは","この論文の中心問いは？",[14,129,130],{},"長期エージェントの memory system は、精度だけでなくどんな construction cost、retrieval latency、generation cost、storage footprint、freshness tradeoff を持つのか、という問い。",[39,132,134],{"id":133},"普通の-rag-と何が違う","普通の RAG と何が違う？",[14,136,137],{},"普通の RAG は静的な文書集合を検索することが多い。一方 agent memory は、エージェント自身の会話や tool trace から作られる可変の状態で、保存・検索・更新・忘却まで含む。",[39,139,141],{"id":140},"なぜ-accuracy-だけではだめ","なぜ accuracy だけではだめ？",[14,143,144],{},"同じくらいの accuracy でも、構築に何時間もかかる system と、ほぼ即座に index できる system がある。query latency や energy、storage、tail latency も大きく違うため。",[39,146,148],{"id":147},"一番よい-memory-system-は何","一番よい memory system は何？",[14,150,151],{},"論文の結論は、単一の勝者はないというもの。更新が少なく query が多い workload なら構築に寄せる方式が合い、継続的に ingestion され query が sparse なら軽い構築の方式が合う。",[39,153,155],{"id":154},"bm25-が強いならそれでいい","BM25 が強いなら、それでいい？",[14,157,158],{},"recall-heavy な aggregate では BM25 が強く見える。ただし paraphrase、multi-hop、temporal inference では弱点があり、構造化・agentic memory の価値が出る場面もある。",[39,160,162],{"id":161},"運用で一番見落としやすい点は","運用で一番見落としやすい点は？",[14,164,165],{},"construction cost。query time が速くても、記憶を作る write path が重いと、energy、GPU utilization、freshness、tail latency に効いてくる。",[39,167,169],{"id":168},"おい丸の運用にどう効く","おい丸の運用にどう効く？",[14,171,172],{},"brain、wiki、state、audit log、skills を、単なる保存先ではなく memory system として見直せる。どこで構築し、どこで検索し、どこで古くなり、どのコストを払っているかを分けて考えられる。",[39,174,176],{"id":175},"次に読むなら-1","次に読むなら？",[14,178,179],{},"Is Agent Memory a Database?、VikingMem、Mem0、Letta \u002F MemGPT 系の論文と合わせると、memory を保存箱ではなく運用基盤として見る線が太くなる。",{"title":181,"searchDepth":182,"depth":182,"links":183},"",2,[184,185,189,190,191,192,193,194],{"id":12,"depth":182,"text":12},{"id":34,"depth":182,"text":34,"children":186},[187],{"id":41,"depth":188,"text":42},3,{"id":51,"depth":182,"text":51},{"id":63,"depth":182,"text":63},{"id":78,"depth":182,"text":78},{"id":94,"depth":182,"text":94},{"id":111,"depth":182,"text":111},{"id":122,"depth":182,"text":123,"children":195},[196,197,198,199,200,201,202,203],{"id":126,"depth":188,"text":127},{"id":133,"depth":188,"text":134},{"id":140,"depth":188,"text":141},{"id":147,"depth":188,"text":148},{"id":154,"depth":188,"text":155},{"id":161,"depth":188,"text":162},{"id":168,"depth":188,"text":169},{"id":175,"depth":188,"text":176},"2026-06-06","長期タスクの LLM エージェントで使われる memory system を、精度だけでなく construction、retrieval、generation、鮮度、ストレージのシステム負荷として測る論文。Agent memory は賢さだけでなく、更新頻度とクエリ量と SLO で選ぶべきだと整理している。",false,"md",{},true,"\u002Fcontents\u002Fagent-memory-characterization",{"title":5,"description":205},"contents\u002Fagent-memory-characterization",[214,215,216,217],"論文まとめ","Agent Memory","Systems Characterization","Long-Horizon Agents","\u002Farticle-pages\u002Fdocs\u002Fassets\u002Fgraphic-recordings\u002Fagent-memory-characterization.png","5yf64Ke5TA4XWj1cFkb5ht-BaRPjGgwDVmGmrSv5m30",[221,225],{"title":222,"path":223,"stem":224,"children":-1},"Agent libOS: A Library-OS-Inspired Runtime for Long-Running, Capability-Controlled LLM Agents","\u002Fcontents\u002Fagent-libos","contents\u002Fagent-libos",{"title":226,"path":227,"stem":228,"children":-1},"A Framework for Evaluating Agentic Skills at Scale","\u002Fcontents\u002Fagentic-skills-eval","contents\u002Fagentic-skills-eval",1782055098917]