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

2026년 9월 업데이트: Mnemosyne와 Memori 추가, Honcho 및 Hindsight 구성 항목 확장, 그리고 기존 인프라스트럭처 표와 함께 캡처 정책 비교 표 추가.

탭을 닫으면 현대의 AI 어시스턴트는 컨텍스트 윈도우를 넘어 지속되는 저장소가 없으면 모든 것을 잊어버립니다. 에이전트 메모리 프로바이더는 세션을 아우르는 사실과 요약을 보관하는 서비스 또는 라이브러리입니다. 이러한 메모리가 스케일링하는 동안 프레임워크는 얇게 유지되도록 플러그인 형태로 결합되는 경우가 많습니다.

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

Hermes 특유의 유한한 코어 메모리(MEMORY.md와 USER.md), 동결 동작, 트리거에 대해서는 Hermes Agent 메모리 시스템 을 참고하십시오. Hermes의 네이티브 메모리 프로바이더가 OpenClaw 대비 확산 우위로 이어지는 방식에 대한 맥락 — GitHub 스타 수, OpenRouter 토큰 랭킹, 생태계 규모 비교 포함 — 이 궁금하시다면 OpenClaw vs Hermes Agent: Stars, Downloads & Usage 2026을 참고하십시오.

리trieval(검색) 품질만큼 중요한 또 다른 축이 있습니다: 메모리 거버넌스. 프로바이더들은 자동으로 캡처하는 대상, 어시스턴트가 생성한 출력이 영구 메모리가 될 수 있는지, 회상(reflection)이 사실로 저장되는지, 모순이 어떻게 해결되는지, 사람이 작성 전 검토할 수 있는지 등 다양한 측면에서 극적인 차이를 보입니다. 장시간 실행되는 에이전트의 경우, 이러한 차이는 검색 정확도 벤치마크의 몇 점 차이보다 더 중요할 수 있습니다. 자동 캡처가 생성된 결론을 미래의 전제로 바꿀 수 있는 이유는 AI 에이전트에서의 자기 강화형 메모리 루프를 참고하고, 보수적인 구성에 대한 실습 예시는 Mnemosyne for Hermes Agent: Local Memory Quickstart를 참고하십시오.

Hermes Agent는 영구적이고 세션을 아우르는 지식을 위해 10개의 외부 메모리 프로바이더 플러그인을 나열합니다. 이는 Mnemosyne와 Memori가 추가된 원래 8개 프로바이더를 포함합니다. 동시에 활성화할 수 있는 외부 프로바이더는 하나뿐입니다. 내장된 MEMORY.md와 USER.md는 여전히 함께 로드되며, 이는 대체가 아닌 추가적인 방식입니다.

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

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 호환 엔드포인트를 모두 수용하므로, 추론을 온-프리미시스(on-premises)에 유지할 수 있습니다. 임베딩 슬롯은 기본적으로 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(Vision-Language Model), 벡터 검색을 위해 임베딩 모델이 필요하며, 둘 다 필수적입니다. 지원되는 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 도구는 메모리 간 종합을 수행합니다 — 여러 메모리를 결합하여 새로운 통찰을 만듭니다. 검색은 4가지 검색 전략(semantic, keyword/BM25, graph traversal, temporal)을 병렬로 실행한 후, 상호 역순 랭킹 융합(reciprocal rank fusion)을 사용하여 결과를 병합하고 재순서화합니다.

외부 의존성: Hindsight는 retain 호출 시 사실 및 엔티티 추출과, reflect 호출 시 종합을 위해 LLM이 필요합니다 (기본: OpenAI; 지원 프로바이더에는 Anthropic, Gemini, Groq, Ollama, LM Studio, OpenAI 호환 엔드포인트 포함). 임베딩과 리랭킹은 기본적으로 인-프로세스(in-process) 로컬 모델(SentenceTransformers; fat Docker/hindsight-all 이미지는 BGE + MiniLM 번들)을 사용하며, 이를 다른 로컬 모델이나 외부 OpenAI 호환 / TEI 엔드포인트로 교체할 수 있습니다 — 예를 들어 CPU에서 Qwen3-Embedding-0.6B와 BGE-reranker-v2-m3. 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 와이어링 — 에 대해서는 Hindsight for Hermes Agent: Self-Hosted Memory with Local LLMs를 참고하십시오.

보수적인 메모리 위생을 위해, auto_recall=true를 유지하면서 auto_retain=false로 설정하는 것이 가치가 있습니다 — semantic recall은 계속 사용할 수 있지만, 완료된 턴이 자동으로 장기 메모리에 들어가지 않습니다. reflect 출력을 메모리에서 종합된 유도된 지식으로, 그것이 구축된 메모리와 같은 증거적 무게를 가진 독립적인 관찰로 취급하지 마십시오.

Holographic

적합한 용도: 로컬 전용 저장을 갖춘 프라이버시 중심 설정.

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

외부 의존성: 없음. Holographic은 LLM, 임베딩 모델, 데이터베이스, 네트워크 연결이 필요하지 않습니다. 메모리 인코딩은 전적으로 인-프로세스에서 실행되는 HRR 대수를 통해 수행됩니다. 이는 이 비교에서 모든 프로바이더 중 독특한 점으로, 외부 호출이 전혀 없어도 작동하는 유일한 프로바이더입니다. 트레이드오프는 검색 품질이 임베딩 기반 semantic search보다 낮고, 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 (semantic 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

완전한 설치와 보수적인 구성 워크스루에 대해서는 Mnemosyne for Hermes Agent: Local Memory Quickstart를 참고하십시오.

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개 프로바이더 지원). 임베딩 모델이나 데이터베이스가 필요하지 않으며 — 컨텍스트 트리는 일반 마크다운 파일의 로컬 디렉토리입니다. 클라우드 동기화는 선택적이며 팀 협업을 위해만 사용되며, 기본적으로 완전히 오프라인으로 작동합니다. 완전한 셀프-contained 로컬 설정을 위해, Ollama를 프로바이더로 연결(brv providers connect openai-compatible --base-url http://localhost:11434/v1)하면 데이터가 기계를 떠나지 않습니다.

Hermes는 자동 큐레이션 후킹을 비활성화하기 위해 auto_extract: false를 노출하여, ByteRover를 자동 캡처가 기본값이 아니라 옵트인인 프로바이더 그룹인 Holographic과 Mnemosyne에 가깝게 만듭니다.

도구: 메모리 조작을 위한 3개의 도구.

설정:

hermes memory setup  # "byterover" 선택

Supermemory

적합한 용도: 컨텍스트 펜싱과 세션 그래프 인제스트를 갖춘 엔터프라이즈 워크플로우.

Supermemory는 컨텍스트 펜싱(컨텍스트별로 메모리 격리)과 세션 그래프 인제스트(전체 대화 히스토리 가져오기)를 제공합니다. 메모리를 자동으로 추출하고, 사용자 프로필을 구축하며, semantic search와 keyword search를 결합한 하이브리드 검색을 실행합니다. 관리되는 클라우드 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 production setup을 참고하십시오.

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

Hermes는 외부 메모리 프로바이더를 위한 패키지/플러그인 인터페이스를 문서화하며, 사용자 설치 디렉터리와 Python 엔트리 포인트를 포함하므로, 생태계는 위의 전체 섹션이 있는 프로바이더를 넘어 확장되었습니다. 각 항목마다 전체 섹션을 추가하지 않고도 알 가치가 있는 몇 가지가 있습니다:

• Scope Recall은 SQLite를 영구 진실로 취급하면서 원시 대화 캡처는 별도로 스코프를 지정하여 유지하고, 보수적인 턴 후 리뷰를 위한 임의의 turn-closure-audit 동반 도구를 제공합니다 — 원시 저널 증거를 영구적 semantic memory와 분리하며, 캡처된 모든 턴을 즉시 동등한 장기 지식으로 취급하지 않습니다.
• Cognee는 Hermes 대화 메모리 플러그인이 아니라 지식 그래프 / ECL 인제스트 파이프라인입니다. 구조화된 프로젝트 또는 기관 메모리에 탁월하지만 명시적인 사실 저장소보다 더 자동화되어 있습니다; 셀프 호스팅 Cognee 빠른 시작과 Cognee에 적합한 LLM 선택를 참고하고, 드롭-인 Hermes 프로바이더로 취급하지 마십시오.
• AgentMemory는 소스 이벤트, 감사 가능성, 삭제 의미를 강조합니다 — 위에서 Mnemosyne에 대해 논의된 고아 유도 레코드 문제 이후에 관련이 있습니다.
• XMemo는 보수적인 기본값을 제공합니다: 자동 타임라인 캡처는 꺼진 상태로 유지될 수 있으며, 삭제는 제약될 수 있습니다. 채택은 아직 초기 단계이므로 전체 섹션이 아직 정당화되지 않습니다.

관련 가이드

• AI 시스템 메모리 허브 — 이 서브클러스터의 범위 및 Cognee 가이드 링크
• AI 에이전트에서의 자기 강화형 메모리 루프 — 왜 캡처 정책과 승인 게이트가 중요한지, 심층적으로
• Mnemosyne for Hermes Agent: Local Memory Quickstart — 위에서 다루어진 Mnemosyne 프로바이더에 대한 완전한 설치 및 보수적인 구성
• Hermes Agent 메모리 시스템 — 플러그인 이전의 2파일 코어 메모리
• Hermes Agent production setup — 실제에서 프로바이더에 대한 프로필 와이어링