에이전트 메모리 프로바이더 비교: 캡처 정책 및 셀프호스팅

2026년 9월 업데이트: Mnemosyne와 Memori를 추가하고, Honcho 및 Hindsight 설정을 확장했으며, 기존 인프라 테이블과 함께 캡처 정책 비교표를 추가했습니다.

컨텍스트 윈도우를 넘어 지속되는 것이 없다면, 현대적인 어시스턴트는 탭을 닫는 순간 모든 것을 잊습니다. **에이전트 메모리 제공자(Agent memory providers)**는 세션 간에 사실과 요약을 유지하는 서비스 또는 라이브러리로, 프레임워크는 가볍게 유지하면서 메모리가 확장되도록 플러그인 형태로 통합되는 경우가 많습니다.

이 가이드는 Hermes Agent 외부 메모리 플러그인으로 제공하는 메모리 백엔드(Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory, Mnemosyne, Memori)를 비교하고, 이들이 보다 포괄적인 AI 시스템 스택에 어떻게 들어맞는지 설명합니다. 동일한 벤더들은 커뮤니티 또는 공식 통합을 통해 OpenClaw 및 기타 에이전트 도구에서도 나타납니다. **AI 시스템 메모리 허브**에서는 이 문서를 Cognee 및 관련 가이드와 함께 나열합니다.

Hermes 전용의 제한된 코어 메모리(MEMORY.md와 USER.md), 고정(freezing) 동작, 트리거에 대해서는 **Hermes Agent 메모리 시스템**을 참조하세요. 제공자 연결은 더 넓은 에이전트 지식 위계의 한 층으로, 각각 고유한 삽입(injection) 트리거를 가진 아이덴티티 파일, 상주 메모리, 스킬, 위키, 메모리 뱅크로 구성됩니다. 이는 계층적 컨텍스트: AI 에이전트를 위한 지식 위계에서 매핑됩니다. Hermes의 네이티브 메모리 제공자가 OpenClaw에 비해 성장하는 채택 우위에 어떻게 기여하는지에 대한 맥락 — GitHub 스타 수, OpenRouter 토크 랭킹, 생태계 규모 비교 포함 — 에 대해서는 OpenClaw vs Hermes Agent: 스타, 다운로드 및 사용량 2026를 참조하세요.

회상(retrieval) 품질만큼이나 중요한 또 다른 축이 있습니다: 메모리 거버넌스. 제공자들은 자동으로 무엇을 캡처하는지, 어시스턴트가 생성한 출구가 영구적 메모리가 될 수 있는지, 반성이 사실로 저장되는지, 모순이 어떻게 해결되는지, 그리고 사람이 미래 컨텍스트가 되기 전에 쓰기를 검토할 수 있는지에 따라 큰 차이를 보입니다. 장기 실행되는 에이전트의 경우, 이러한 차이가 회상 벤치마크에서 몇 점 더 올리는 것보다 더 중요할 수 있으며, 자동 캡처가 생성된 결론을 미래의 전제로 바꿀 수 있는 이유는 AI 에이전트에서의 자기 강화 메모리 루프를, 구체적인 보수적 설정 사례로는 Hermes Agent용 Mnemosyne: 로컬 메모리 퀵스타트를 참조하세요.

Hermes Agent는 지속적이고 세션을 넘나드는 지식을 위한 10개의 외부 메모리 제공자 플러그인을 나열합니다 — 원래의 8개에 Mnemosyne와 Memori가 추가되었습니다. 한 번에 활성화될 수 있는 외부 제공자는 하나만입니다. 내장된 MEMORY.md와 USER.md는 그 옆에 계속해서 로드되며, 대체가 아닌 추가(additive) 관계입니다.

외부 의존성. Holographic를 제외한 모든 외부 제공자는 최소 한 번의 외부 서비스 호출을 요구합니다 — 메모리 추출을 위한 LLM, 의미적 검색을 위한 임베딩 모델, 또는 저장을 위한 PostgreSQL과 같은 데이터베이스입니다. 이러한 의존성은 프라이버시, 비용, 그리고 메모리 스택을 완전히 셀프호스티드로 실행할 수 있는지에 대한 직접적인 영향을 미칩니다. Hindsight, ByteRover, Mnemosyne는 가장 많은 의존성을 번들링하거나 제거합니다. 반면 Honcho, Mem0, Supermemory는 가장 많은 이동 부품(moving parts)을 요구합니다. 제공자가 Ollama 또는 OpenAI 호환 엔드포인트를 지원하는 경우, LLM 및 임베딩 호출을 로컬 모델로 라우팅하여 데이터를 제3자 서버에 전혀 올리지 않을 수 있습니다.

Hermes Agent와의 활성화

아래 명령어 단계는 Hermes Agent CLI 치트시트의 테이블을 따릅니다.

hermes memory setup   # 대화형 선택기 + 설정
hermes memory status  # 활성화 상태 확인
hermes memory off     # 외부 제공자 비활성화

또는 ~/.hermes/config.yaml에서 수동으로 설정:

memory:
  provider: openviking  # 또는 honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory, mnemosyne, memori

제공자 비교

캡처 정책 및 거버넌스

저장소와 의존성은 “이걸 실행할 수 있을까?“라는 질문에 답합니다. 아래 표는 장기 실행 에이전트에 있어 만큼이나 중요하지만 다른 질문에 답합니다: 무엇이 요청 없이 기록되는가, 그리고 그것이 영구적이 되기 전에 사람이나 정책이 개입할 수 있는가? 이 축이 왜 중요한지는 AI 에이전트에서의 자기 강화 메모리 루프를 참조하세요.

이것들은 품질 점수가 아니라 아키텍처적 위험 범주입니다 — 정교한 제공자가 주의 깊게 구성되면, 단순한 제공자가 엉망으로 구성되는 것보다 실제로는 더 안전할 수 있습니다.

상세 분석

Honcho

적합한 분야: 멀티 에이전트 시스템, 세션 간 컨텍스트, 사용자-에이전트 정렬.

Honcho는 기존 메모리와 함께 실행됩니다 — USER.md는 그대로 유지되고, Honcho는 컨텍스트의 추가 층을 더합니다. Honcho는 대화를 메시지 교환하는 피어로 모델링합니다 — Hermes 프로필마다 사용자 피어 1개와 AI 피어 1개이며, 모두 워크스페이스를 공유합니다.

외부 의존성: Honcho는 세션 요약, 사용자 표현 유도, 변증법적 추론을 위한 LLM, 관찰 간 의미적 검색을 위한 임베딩 모델, 벡터 저장을 위한 pgvector 확장 기능이 있는 PostgreSQL, 캐싱을 위한 Redis가 필요합니다. 관리형 클라우드 api.honcho.dev는 이 모든 것을 대신 처리해 줍니다. 셀프호스트 배포(Docker, K3s, 또는 Fly.io)의 경우, 사용자 스스로 자격 증명을 공급해야 합니다. LLM 슬롯은 Ollama 및 vLLM을 포함한 OpenAI 호환 엔드포인트를 모두 수용하므로, 추론을 온프레미스로 유지할 수 있습니다. 임베딩 슬롯은 기본적으로 openai/text-embedding-3-small을 사용하지만, LLM_EMBEDDING_API_KEY 및 LLM_EMBEDDING_BASE_URL을 통해 구성 가능한 제공자를 지원합니다 — BGE 모델이 있는 vLLM과 같은 로컬 옵션을 포함한 OpenAI 호환 임베딩 서버라면 모두 작동합니다.

도구: honcho_profile (피어 카드 읽기/업데이트), honcho_search (의미적 검색), honcho_context (세션 컨텍스트 — 요약, 표현, 카드, 메시지), honcho_reasoning (LLM 종합), honcho_conclude (결론 생성/삭제).

주요 설정 항목:

• contextCadence (기본값 1): 베이스 레이어 새로 고침 사이의 최소 턴 수
• dialecticCadence (기본값 2): peer.chat() LLM 호출 사이의 최소 턴 수 (1-5 권장)
• dialecticDepth (기본값 1): 호출당 .chat() 패스 수 (1-3으로 클램프됨)
• recallMode (기본값 ‘hybrid’): hybrid (자동+도구), context (삽입만), tools (도구만)
• writeFrequency (기본값 ‘async’): 플러시 타이밍: async, turn, session, 또는 정수 N
• observationMode (기본값 ‘directional’): directional (모두 켬) 또는 unified (공유 풀)

관찰 모드와 자기 모델링. 기본값인 directional 모드는 사용자 및 AI 피어가 서로와 자신 자신을 관찰할 수 있게 합니다 — 더 풍부한 변증법적 추론을 가능하게 하지만, 이는 AI가 작성한 메시지가 Honcho의 AI 자기 모델에 기여함을 의미합니다. unified는 더 보수적인 옵션입니다: AI는 자신의 출력에서 나오는 대응하는 자기 관찰 루프를 구축하지 않고 사용자 메시지에서 사용자를 모델링합니다. 생성된 결론이 미래 추론에 피드백되는 것에 특히 우려가 있는 사용자는 AI 에이전트에서의 자기 강화 메모리 루프를 참고하여 unified를 더 안전한 기본값으로 고려해야 합니다.

아키텍처: 2층 컨텍스트 삽입 — 베이스 레이어(세션 요약 + 표현 + 피어 카드) + 변증법적 보조(LLM 추론). 콜드 스타트와 웜 프롬프트를 자동으로 선택합니다.

멀티 피어 매핑: 워크스페이스는 프로필 간 공유된 환경입니다. 사용자 피어(peerName)는 글로벌 인간 아이덴티티입니다. AI 피어(aiPeer)는 Hermes 프로필마다 하나씩 존재합니다(hermes 기본, 나머지는 hermes.<profile>).

설정:

hermes memory setup  # "honcho" 선택
# 또는 레거시: hermes honcho setup

설정: $HERMES_HOME/honcho.json (프로파일 로컬) 또는 ~/.honcho/config.json (전역).

프로파일 관리:

hermes profile create coder --clone  # 공유 워크스페이스를 가진 hermes.coder 생성
hermes honcho sync                   # 기존 프로필에 대한 AI 피어 백필

OpenViking

적합한 분야: 구조화된 브라우징이 있는 셀프호스트 지식 관리.

OpenViking은 계층적 로딩을 가진 파일시스템 위계를 제공합니다. 무료이고 셀프호스트이며, 메모리 저장소에 대한 완전한 제어를 제공합니다.

외부 의존성: OpenViking은 의미 처리 및 메모리 추출을 위한 VLM(비전-언어 모델)과 벡터 검색을 위한 임베딩 모델이 필요하며, 둘 다 필수적입니다. 지원하는 VLM 제공자에는 OpenAI, Anthropic, DeepSeek, Gemini, Moonshot, vLLM(로컬 배포를 위해)이 포함됩니다. 임베딩을 위한 지원 제공자에는 OpenAI, Volcengine(Doubao), Jina, Voyage, 그리고 — Ollama를 통해 — 모든 로컬 서빙된 임베딩 모델이 포함됩니다. openviking-server init 대화형 마법사는 사용 가능한 RAM을 감지하고 적합한 Ollama 모델을 권장할 수 있습니다 (예: 임베딩용 Qwen3-Embedding 8B, VLM용 Gemma 4 27B) 그리고 완전한 로컬, 제로-API-키 세팅을 위해 모든 것을 자동으로 구성합니다. 외부 데이터베이스는 필요하지 않으며, OpenViking은 메모리를 파일시스템에 저장합니다.

도구: viking_search, viking_read (계층적), viking_browse, viking_remember, viking_add_resource.

사용자 메모리와 에이전트 메모리. OpenViking의 아이덴티티 모델은 사용자의 메모리 네임스페이스와 선택적인 어시스턴트 피어를 분리할 수 있습니다. 이 분리는 메모리 위생에 중요합니다: 사용자에 대한 사실과 에이전트가 생성한 경험은 동일한 보존 정책을 공유할 필요가 없으며, 이는 어시스턴트가 작성한 상태를 사용자가 작성한 상태로부터 격리하기를 원한다면 유용한 속성입니다.

설정:

pip install openviking
openviking-server init   # 대화형 마법사 (로컬 세팅을 위한 Ollama 모델 권장)
openviking-server
hermes memory setup  # "openviking" 선택
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

적합한 분야: 자동 추출이 있는 손쉬운 메모리 관리.

Mem0은 add 운영 시마다 LLM 호출을 통해 서버측에서 메모리 추출을 처리합니다 — 대화를 읽고, 개별적인 사실을 추출하고, 중복을 제거하고, 저장합니다. 관리형 클라우드 API가 모든 인프라를 처리합니다. 오픈소스 라이브리와 셀프호스트 서버는 완전한 제어를 제공합니다.

외부 의존성: Mem0은 메모리 추출을 위한 LLM(기본값: OpenAI gpt-4.1-nano; 로컬 모델을 위한 Ollama, vLLM, LM Studio 포함 20개 제공자 지원)과 검색을 위한 임베딩 모델(기본값: OpenAI text-embedding-3-small; 로컬 모델을 위한 Ollama 및 HuggingFace 포함 10개 제공자 지원)이 필요합니다. 저장은 라이브러리 모드에서 /tmp/qdrant의 Qdrant를 사용하거나, 셀프호스트 서버 모드에서 pgvector가 있는 PostgreSQL을 사용합니다 — 둘 다 로컬에서 실행 가능합니다. 완전 로컬, 제로-클라우드 Mem0 스택은 실현 가능합니다: LLM용 Ollama, 임베딩용 Ollama, 로컬 Qdrant 인스턴스, 모두 Memory.from_config를 통해 구성됩니다.

Mem0은 근본적으로 추출 시스템입니다: LLM이 대화 자료를 개별적인 메모리로 변환하고 중복 제거 및 업데이트 로직을 수행합니다. 이는 편리하지만, 추출의 출처가 중요함을 의미합니다 — 캡처 경로가 추출 실행 전에 이를 필터링하지 않으면, 생성된 어시스턴트 결론은 사용자가 진술한 사실과 구조적으로 구별 불가능해질 수 있습니다.

도구: mem0_profile, mem0_search, mem0_conclude.

설정:

pip install mem0ai
hermes memory setup  # "mem0" 선택
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

설정: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

적합한 분야: 엔티티 관계가 있는 지식 그래프 기반 회상.

Hindsight는 메모리의 지식 그래프를 구축하여 엔티티와 관계를 추출합니다. 그 고유의 reflect 도구는 크로스 메모리 종합을 수행합니다 — 여러 메모리를 결합하여 새로운 통찰을 만들어냅니다. 회상은 네 가지 검색 전략(의미적, 키워드/BM25, 그래프 순회, 시간적)을 병렬로 실행한 후, 상호 역 랭킹 퓨전을 사용하여 결과를 병합하고 재순서화합니다.

외부 의존성: Hindsight는 retain 호출 시 사실 및 엔티티 추출을 위해, 그리고 reflect 호출 시 종합을 위해 LLM이 필요합니다 (기본값: OpenAI; 지원 제공자에는 Anthropic, Gemini, Groq, Ollama, LM Studio 및 OpenAI 호환 엔드포인트가 포함됩니다). 임베딩과 리랭킹은 기본적으로 인-프로세스 로컬 모델(SentenceTransformers; fat Docker/hindsight-all 이미지는 BGE + MiniLM을 번들링)을 사용하지만, Qwen3-Embedding-0.6B와 BGE-reranker-v2-m3와 같은 CPU에서 다른 로컬 모델 또는 외부 OpenAI 호환 / TEI 엔드포인트로 교체할 수 있습니다. PostgreSQL은 관리되는 pg0 데이터 디렉토리를 통해 번들링되거나, 외부 PostgreSQL 인스턴스를 가리킬 수 있습니다. 완전 로컬 생성 경로를 위해, HINDSIGHT_API_LLM_PROVIDER를 OpenAI 호환 로컬 서버(Ollama 또는 llama.cpp)로 설정하세요; retain과 recall은 완전히 작동하고, reflect는 도구 호출이 가능한 모델이 필요합니다.

도구: hindsight_retain, hindsight_recall, hindsight_reflect (고유한 크로스 메모리 종합).

설정:

hermes plugins install hindsight
hermes memory setup hindsight   # 독립적인 Hindsight API를 위해 local_external 선택

클라우드 모드는 여전히 ~/.hermes/.env에서 API 키를 수락합니다. 셀프호스트 설치에는 임베드된 또는 기존 PostgreSQL에 대한 Docker Compose를 사용하며 — 아래에 링크된 워크스루를 참조하세요. 최신 Hindsight 클라이언트/API 쌍(플러그인 문서는 >= 0.4.22 인용)이 필요합니다.

설정: $HERMES_HOME/hindsight/config.json

• mode: cloud, local, 또는 local_external
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (기본값)

로컬 UI: hindsight-embed -p hermes ui start

Docker Compose, 로컬 임베딩 및 리랭킹, 쓰기 경로 컨트롤(auto_retain), Hermes local_external 와이어링을 포함한 완전한 셀프호스트 워크스루 — 에 대해서는 Hermes Agent용 Hindsight: 로컬 LLM을 사용하는 셀프호스트 메모리를 참조하세요. OpenCode, Cursor CLI, 기타 코딩 하니스는 저장소별 뱅크를 가진 다른 패키지를 사용합니다: OpenCode, Cursor, 기타 코딩 에이전트용 Hindsight 메모리.

보수적인 메모리 위생을 위해, auto_retain=false로 설정하고 auto_recall=true를 유지하는 것을 고려해 볼 만합니다 — 의미적 회상은 여전히 사용 가능하지만, 완료된 턴은 더 이상 자동으로 장기 메모리에 진입하지 않습니다. reflect 출력을 그것이 구축된 메모리와 동일한 증거적 무게를 가진 독립적 관찰이 아니라, 메모리를 횡단하여 종합된 파생 지식으로 취급하세요.

Holographic

적합한 분야: 로컬 전용 저장이 있는 프라이버시 중심 세팅.

Holographic은 메모리 인코딩을 위해 HRR(Holographic Reduced Representation) 대수를 사용하고, 메모리 신뢰성을 위해 신뢰도 스코어링을 적용합니다. 클라우드 의존성이 없습니다 — 모든 것이 사용자의 하드웨어에서 로컬로 실행됩니다.

외부 의존성: 없음. Holographic은 LLM, 임베딩 모델, 데이터베이스, 네트워크 연결이 필요하지 않습니다. 메모리 인코딩은 완전히 인-프로세스에서 실행되는 HRR 대수를 통해 수행됩니다. 이를 통해 이 비교의 모든 제공자 중 유일하게 외부 호출이 제로인 상태로 작동하는 제공자가 됩니다. 대가는 임베딩 기반 의미적 검색보다 회상 품질이 낮고, Hindsight의 reflect와 같은 크로스 메모리 종합이 없다는 것입니다. 프라이버시와 제로-의존성 작동을 불가피하게 여기는 사용자들에게, Holographic은 이를 무조건적으로 제공하는 유일한 옵션입니다.

auto_extract의 기본값은 false이므로, Holographic은 자율적인 전사-메모리 파이프라인이 아니라 신뢰 점수가 있는 작은 명시적 사실 데이터베이스로 주로 작동할 수 있습니다. 제로 의존성과 결합하여, 자동 캡처를 의도적으로 원하지 않는 독자를 위해 Mnemosyne와 함께 가장 단순한 두 옵션 중 하나가 됩니다.

도구: HRR 대수를 통한 메모리 운영용 2개의 도구.

설정:

hermes memory setup  # "holographic" 선택

RetainDB

적합한 분야: 델타 압축이 있는 고빈도 업데이트.

RetainDB는 메모리 업데이트를 효율적으로 저장하기 위해 델타 압축을 사용하고, 관련 컨텍스트를 표면화하기 위해 하이브리드 검색(벡터 + BM25 + 리랭킹)을 사용합니다. $20/월 비용으로 클라우드 기반이며, 모든 메모리 처리가 서버측에서 처리됩니다.

외부 의존성: RetainDB의 LLM 호출, 임베딩 파이프라인, 리랭킹은 모두 RetainDB의 자체 클라우드 인프라에서 실행됩니다 — 사용자로부터 필요한 것은 RETAINDB_KEY뿐입니다. 메모리 추출은 서버측에서 Claude Sonnet을 사용합니다. 셀프호스팅 옵션이 없으며 로컬 모드가 없습니다. 모든 대화 데이터는 처리 및 저장을 위해 RetainDB 서버로 전송됩니다. 데이터 주권이나 오프라인 작동이 사용 사례에 중요하다면, 이 제공자는 적합하지 않습니다.

도구: retaindb_profile (사용자 프로파일), retaindb_search (의미적 검색), retaindb_context (태스크 관련 컨텍스트), retaindb_remember (타입 + 중요도로 저장), retaindb_forget (메모리 삭제).

RetainDB의 Hermes 통합은 원격 메모리 데이터베이스를 넘어 성장했습니다 — 이제 변증법적 종합과 에이전트 자기 모델을 포함하며, 이는 아키텍처적으로 단순한 벡터 스토어보다 Honcho에 더 가깝게 만듭니다. 이는 연속성에 유용하지만, Honcho의 directional 모드에도 적용되는 동일한 우려인 출처 사실과 생성된 해석의 분리 중요성을 높이기도 합니다.

설정:

hermes memory setup  # "retaindb" 선택

Mnemosyne

적합한 분야: 세부적인 보존 컨트롤, 검사 가능한 SQLite 저장소, 구조화된 사실, 시간적 메모리, 구성 가능한 통합이 있는 로컬 우선 메모리.

Mnemosyne은 Hermes의 원래 번들된 메모리 제공자 중 하나가 아닙니다 — 독립적인 Hermes 제공자 플러그인으로 출하되지만 동일한 MemoryProvider 인터페이스를 통해 통합됩니다. 그 주요 이점은 컨트롤입니다: 대화 자동 저장은 역할에 의해 제한되거나 sync_roles: []로 완전히 비활성화될 수 있으며, 도구 결과 로깅은 기본적으로 꺼져 있고, 명시적인 remember/recall/forget 운영은 관계없이 사용 가능하며, 더 새로운 버전에는 컨텍스트 압축 경계 주위의 선택적 자기 에코 억제가 포함됩니다.

외부 의존성: core 설치에는 없음; embeddings 추가 항목은 로컬 벡터 검색을 추가합니다. 저장은 FTS5와 선택적 벡터 검색이 있는 로컬 SQLite입니다. 시스템은 또한 작업 기억, 에피소딕 메모리, 구조화된 사실, 시간적 삼중, 정준 사실, 통합을 유지합니다.

Mnemosyne은 또한 Hermes memory.write_approval을 위한 제공자별 스테이징 된 쓰기를 구현하지만, 외부 제공자 승인은 아직 Hermes 전체에 표준화되지 않았으므로, 이 경로는 배포되는 정확한 버전들과 함께 테스트되어야 합니다. 추가된 정교함에는 비용이 있습니다: 파생된 메모리는 검사하고 정리해야 할 더 많은 라이프사이클 상태를 만듭니다. 최근 Mnemosyne 릴리스는 충돌 검증, 삭제 동작, 자기 에코 처리를 특히 강화했습니다 — 충돌 검증 변경을 동기화한 생산 감사에 대해서는 AI 에이전트에서의 자기 강화 메모리 루프를 참조하세요.

설정:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

완전한 설치와 보수적 설정 워크스루를 위해, Hermes Agent용 Mnemosyne: 로컬 메모리 퀵스타트를 참조하세요.

Memori

적합한 분야: 대화 역사만큼 실행 역사가 중요한 에이전트.

Memori는 도구 인지 구조화 메모리에 초점을 둔 더 새로운 Hermes 통합입니다. 사용 가능한 실행 컨텍스트 — 도구 사용, 워크플로 단계, 결정, 결과, 제약 조건 —와 함께 완료된 턴을 캡처하며, 이는 운영 작업 기억에 탁월하지만, 동작, 모델 결정, 도구 결과가 모두 영구적인 구조화 메모리가 될 수 있으므로 더 큰 피드백 표면도 생성합니다.

모든 턴 전에 큰 메모리 블록을 삽입하는 것이 주된 제공자와 달리, Memori는 명시적인 회상 및 회상-요약 도구를 노출하여, 에이전트가 모든 프롬프트가 아니라 실제로 필요할 때 운영 컨텍스트를 검색하게 합니다. 이는 프롬프트 오염을 줄이지만, 배경에서 완료된 턴과 실행 추적이 여전히 자동으로 캡처될 수 있으므로 쓰기측 피드백 위험을 그 자체로 제거하지는 않습니다. 따라서 Memori는 엄격한 명시적 전용 보존을 요구하는 설치보다는 이전 작업에서 배우는 에이전트를 원하는 사용자에게 더 적합합니다.

설정:

pip install hermes-memori
hermes memory setup  # "memori" 선택

ByteRover

적합한 분야: 사람이 읽을 수 있고 감사 가능한 저장이 있는 로컬 우선 메모리.

ByteRover은 임베딩 벡터나 데이터베이스가 아니라 구조화된 마크다운 컨텍스트 트리 — 도메인, 토픽, 서브토픽 파일의 위계 — 로 메모리를 저장합니다. LLM이 출처 내용을 읽고, 추론하고, 추출된 지식을 위계의 올바른 위치에 배치합니다. 검색은 계층적 LLM 구동 검색으로의 폴백을 가진 MiniSearch 전체 텍스트 검색이며, 벡터 데이터베이스가 필요하지 않습니다.

외부 의존성: ByteRover는 메모리 큐레이션과 검색을 위한 LLM이 필요합니다 (Anthropic, OpenAI, Google, Ollama 및 openai-compatible 제공자 슬롯을 통한 모든 OpenAI 호환 엔드포인트 포함 18개 제공자 지원). 임베딩 모델이나 데이터베이스는 필요하지 않으며 — 컨텍스트 트리는 일반 마크다운 파일의 로컬 디렉토리입니다. 클라우드 동기화는 선택적이며 팀 협업에만 사용되며, 기본적으로 모든 것이 완전 오프라인으로 작동합니다. 완전한 자체 완결 로컬 세팅을 위해, Ollama를 제공자로 연결하세요 (brv providers connect openai-compatible --base-url http://localhost:11434/v1) 그러면 데이터가 사용자 머신을 떠나지 않습니다.

Hermes는 자동 큐레이션 후크를 비활성화하기 위해 auto_extract: false를 노출합니다. 이는 ByteRover를 자동 캡처가 기본값이 아닌 선택(opt-in)인 제공자 그룹에서 Holographic 및 Mnemosyne와 근접시킵니다.

도구: 메모리 운영용 3개의 도구.

설정:

hermes memory setup  # "byterover" 선택

Supermemory

적합한 분야: 컨텍스트 펜싱과 세션 그래프 인제스트가 있는 엔터프라이즈 워크플로.

Supermemory는 컨텍스트 펜싱(컨텍스트별 메모리 격리)과 세션 그래프 인제스트(대화 역사 전체 가져오기)를 제공합니다. 메모리를 자동으로 추출하고, 사용자 프로파일을 구축하고, 의미적 및 키워드 검색을 결합하는 하이브리드 검색을 실행합니다. 관리형 클라우드 API가 주요 배포 목표입니다.

외부 의존성: Supermemory의 클라우드 서비스는 모든 LLM 추론과 임베딩을 서버측에서 처리합니다 — 사용자로부터 필요한 것은 Supermemory API 키뿐입니다. 셀프호스팅은 엔터프라이즈 플랜 추가 항목으로만 사용할 수 있으며 Cloudflare Workers에 배포됩니다; 벡터 저장을 위한 pgvector 확장 기능이 있는 PostgreSQL과 OpenAI API 키(필수, Anthropic 및 Gemini는 선택적 추가)를 제공해야 합니다. Docker 기반 또는 로컬 셀프호스팅 경로가 없습니다 — 아키텍처는 Cloudflare Workers 엣지 컴퓨팅에 긴밀하게 결합되어 있습니다. 엔터프라이즈 계약 없이 완전한 데이터 주권을 필요로 하는 사용자들에게, 이 제공자는 올바른 선택이 아닙니다.

현재 Hermes 통합은 Supermemory의 대화 엔드포인트를 통해 전체 세션을 단일 단위로 작성합니다. 대화를 버퍼링하고 세션 종료, 리셋, 또는 압축 시 인제스트합니다. 이는 격리된 사실 쓰기보다 더 풍부한 엔티티 및 프로파일 컨텍스트를 생성하지만, 생성된 어시스턴트 텍스트가 사용자 진술만이 아니라 메모리 추출 파이프라인에 제시되는 자료의 일부임을 의미합니다.

도구: 메모리 운영용 4개의 도구.

설정:

hermes memory setup  # "supermemory" 선택

선택 방법

하나의 글로벌 승자를 고르기보다는, 제공자를 작업에 맞춰 보세요:

• 가장 단순한 로컬 명시적 메모리: Holographic — 제로 의존성, auto_extract 기본값 끔
• 더 풍부한 라이프사이클 컨트롤이 있는 로컬 메모리: Mnemosyne — SQLite, 세부적인 보존, 자기 에코 억제
• 그래프 중심 종합: Hindsight — 지식 그래프 + reflect
• 피어 또는 사용자 모델링: Honcho — 변증법적 추론, 보수적 자기 모델링을 위한 unified 모드
• 파일시스템 스타일 지식: OpenViking — 계층적 viking:// 위계
• 손쉬운 자동 추출: Mem0 — 제로-구성 LLM 기반 사실 추출
• 운영/도구 인지 메모리: Memori — 턴 및 실행 추적 캡처
• 사람이 읽을 수 있고, 감사 가능하며, 임베딩 파이프라인 없음: ByteRover — 일반 마크다운 컨텍스트 트리
• 엔터프라이즈 컨텍스트 펜싱: Supermemory — 세션 그래프 인제스트, Cloudflare 호스팅
• 고빈도 업데이트, 셀프호스팅 불필요: RetainDB — 델타 압축, 변증법적 자기 모델

프로파일별 제공자 설정과 실제 워크플로 패턴을 위해, Hermes Agent 프로덕션 세팅을 참조하세요.

더 넓은 서드파티 Hermes 메모리 생태계

Hermes는 외부 메모리 제공자를 위한 패키지/플러그인 인터페이스를 문서화하며, 사용자 설치 디렉토리와 Python 엔트리 포인트를 포함하므로, 생태계는 이제 위에서 전체 섹션이 있는 제공자들 너머로 확장됩니다. 전체 섹션을 추가하지 않고 알아두어야 할 몇 가지가 있습니다:

• Scope Recall은 원본 대화 캡처를 별도로 범위로 유지하면서 SQLite를 영구적 진실로 취급하며, 보수적인 턴 후 검토를 위한 선택적 turn-closure-audit 동반자를 가진다 — 즉시 동등한 장기 지식으로 취급하는 것이 아니라 원본 저널 증거를 영구적 의미적 메모리로부터 분리합니다.
• Cognee는 Hermes 대화형 메모리 플러그인이 아니라 지식 그래프 / ECL 인제스트 파이프라인입니다. 구조화된 프로젝트 또는 기관적 메모리에서 뛰어나지만 명시적 사실 스토어보다 더 자동적입니다; 셀프호스팅 Cognee 퀵스타트와 Cognee를 위한 올바른 LLM 선택를 참조하고, 드롭인 Hermes 제공자로 취급하지 마세요.
• AgentMemory는 출처 이벤트, 감사 가능성, 삭제 의미를 강조합니다 — 위에서 논의된 Mnemosyne의 고아된 파생 레코드 문제 이후 관련성이 있습니다.
• XMemo는 보수적 기본값을 제공합니다: 자동 타임라인 캡처는 꺼진 채로 남을 수 있고, 삭제는 제한될 수 있습니다. 채택은 아직 전체 섹션을 정당화하기에 충분히 초기 단계입니다.

관련 가이드

• AI 시스템 메모리 허브 — 이 서브클러스터의 범위 및 Cognee 가이드 링크
• AI 에이전트에서의 자기 강화 메모리 루프 — 캡처 정책과 승인 게이트가 왜 중요한지, 심층적으로
• Hermes Agent용 Mnemosyne: 로컬 메모리 퀵스타트 — 위에서 다룬 Mnemosyne 제공자를 위한 완전한 설치와 보수적 설정
• Hermes Agent 메모리 시스템 — 플러그인 이전의 코어 2파일 메모리
• Hermes Agent 프로덕션 세팅 — 실제에서의 제공자 프로파일 와이어링