메모리 큐레이터 패턴: 작업자 에이전트 메모리 오염 방지

멀티 에이전트 설정에서 공유 메모리 오염은 익숙한 고통입니다. r/openclaw의 한 개발자는 전용 Memory Curator 에이전트를 통해 모든 메모리 쓰기를 게이트하는 패턴을 설명하며, 작업자 에이전트가 지속적인 사실을 직접 쓰지 못하도록 합니다. 이 접근 방식은 조직의 트랜스액티브 메모리 연구(Ren & Argote)와 MemGPT, MemoryBank, LEGOMem, Generative Agents 같은 기존 에이전트 메모리 시스템에서 영감을 받았습니다.

Memory Curator 패턴 작동 방식

작업자 에이전트는 절대 메모리에 쓰지 않습니다. 대신, 제안된 범위와 증거가 포함된 구조화된 메모리 이벤트를 내보냅니다. 그런 다음 Memory Curator 에이전트는 각 이벤트를 검증, 편집, 중복 제거한 후 네 가지 범위 중 하나로 라우팅하거나 완전히 폐기합니다.

네 가지 범위

Agent Repo Memory — 단일 에이전트에 대한 지속적인 설계 결정 (개별 전문가 메모리와 유사)
Agent Team Memory — 에이전트 간 절차, 인계 표준, 안전 규칙 (트랜스액티브 팀 메모리)
Project Memory — 한 작업에 대한 현재 상태, 결정, 위험
Session Scratch — 아마도 유지되지 않아야 하는 임시 관찰 (단기 작업 메모리)

이벤트 스키마

이벤트는 유형 태그가 있는 JSON입니다: fact, decision, preference, risk, procedure, hypothesis와 증거 참조 및 제안된 범위가 포함됩니다. 큐레이터는 제안된 범위를 재정의할 수 있으며 지속적인 저장소에 유일하게 쓰는 주체입니다.

열린 질문

저자는 두 가지 우려를 제기합니다:

과잉 또는 과소 배출 — 이벤트 요구 사항으로 인해 작업자가 모든 것을 배출(범람)하거나 귀찮아서 하지 않음(유용한 관찰 손실)이 발생할 수 있습니다.
대규모 라우팅 정확도 — 긴 세션에서 세션과 프로젝트 경계가 모호해지고, 교훈이 일반화될 때 프로젝트와 팀 경계가 모호해집니다.

저장소는 github.com/jeongmk522-netizen/agent_memory_curator_agent에 있습니다. 개발자는 다른 사람들이 사전에 쓰기를 게이트하는지 아니면 나중에 정리 패스를 하는지 궁금해하며, 사후 정리가 더 쉽지만 오염이 제거 속도보다 빠르게 축적될 가능성이 있다고 지적합니다.

📖 전체 소스 읽기: r/openclaw