메모리 제공자
anchor alias
메모리 제공자
Hermes 에이전트는 내장된 MEMORY.md와 USER.md를 넘어 에이전트에 지속적이고 세션 간 공유되는 지식을 제공하는 8개의 외부 메모리 제공자 플러그인과 함께 제공됩니다. 한 번에 하나의 외부 제공자만 활성화될 수 있으며 — 내장 메모리는 항상 함께 활성화됩니다.
빠른 시작
hermes memory setup # interactive picker + configuration
hermes memory status # check what's active
hermes memory off # disable external provider
hermes plugins → 플러그인 제공자 → 메모리 제공자를 통해 활성 메모리 제공자를 선택할 수도 있습니다.
또는 ~/.hermes/config.yaml에서 수동으로 설정할 수 있습니다:
memory:
provider: openviking # or honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory
작동 방식
메모리 제공자가 활성화되면, Hermes는 자동으로:
- 시스템 프롬프트에 제공자 컨텍스트를 주입함 (제공자가 아는 것)
- 각 턴 전에 관련 기억을 사전 불러오기 (배경, 비차단)
- 각 응답 후 대화를 제공자에게 동기화
- 세션 종료 시 메모리를 추출합니다 (지원하는 제공자를 위한 기능)
- 내장 메모리 쓰기를 외부 제공자에게 반영
- 제공자별 도구를 추가하여 에이전트가 기억을 검색, 저장 및 관리할 수 있도록 합니다
내장 메모리(MEMORY.md / USER.md)는 이전과 똑같이 계속 작동합니다. 외부 제공자는 추가적인 역할을 합니다.
사용 가능한 제공자
호인초
방언적 추론, 세션 범위의 컨텍스트 주입, 의미 기반 검색, 지속적 결론을 활용한 AI-네이티브 교차 세션 사용자 모델링. 기본 컨텍스트에는 이제 사용자 표현과 동료 카드와 함께 세션 요약이 포함되어, 에이전트가 이미 논의된 내용을 인식할 수 있게 되었습니다.
| 에 가장 적합 | 세션 간 컨텍스트가 있는 다중 에이전트 시스템, 사용자-에이전트 정렬 |
| 필요 | pip install honcho-ai + API 키 또는 자체 호스팅 인스턴스 |
| 데이터 저장 | 혼초 클라우드 또는 자체 호스팅 |
| 비용 | Honcho 요금제(클라우드) / 무료(자가 호스팅) |
도구 (5): honcho_profile (피어 카드 읽기/업데이트), honcho_search (의미 기반 검색), honcho_context (세션 context — 요약, 표현, 카드, 메시지), honcho_reasoning (LLM-합성), honcho_conclude (결론 생성/삭제)
아키텍처: 2단계 컨텍스트 주입 — 기본 계층(세션 요약 + 표현 + 피어 카드, contextCadence에서 새로고침)과 변증법적 보조 계층(LLM 추론, dialecticCadence에서 새로고침). 변증법 계층은 기본 컨텍스트가 존재하는지 여부에 따라 콜드 스타트 프롬프트(일반 사용자 정보)와 웜 프롬프트(세션 범위 컨텍스트)를 자동으로 선택한다.
세 개의 직교 구성 노브가 비용과 깊이를 독립적으로 제어합니다:
contextCadence— 기본 레이어가 새로 고쳐지는 빈도 (API 호출 빈도)dialecticCadence— 변증법 LLM이 작동하는 빈도(LLM 호출 빈도)dialecticDepth— 변증법 호출당.chat()회 통과 횟수 (1–3, 추론의 깊이)
설정 마법사:
hermes memory setup # select "honcho" — runs the Honcho-specific post-setup
레거시 hermes honcho setup 명령은 여전히 작동합니다(현재는 hermes memory setup로 리디렉션됨), 하지만 Honcho가 활성 메모리 제공자로 선택된 후에만 등록됩니다.
설정: $HERMES_HOME/honcho.json (프로필-로컬) 또는 ~/.honcho/config.json (글로벌). 해결 순서: $HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json. 설정 참조와 Honcho 통합 가이드를 참조하세요.
Full config reference
| 열쇠 | 기본값 | 설명 |
|---|---|---|
apiKey | -- | app.honcho.dev에서 API 키 |
baseUrl | -- | 자체 호스팅된 Honcho의 기본 URL |
peerName | -- | 사용자 피어 신원 |
aiPeer | 호스트 키 | AI 동료 신원(프로필당 하나) |
workspace | 호스트 키 | 공유 작업 공간 ID |
contextTokens | null (대문자 없음) | 턴마다 자동 주입된 컨텍스트의 토큰 예산. 단어 경계에서 잘림 |
contextCadence | 1 | context() API 호출 간 최소 턴 수 (기본 레이어 새로고침) |
dialecticCadence | 2 | peer.chat() LLM 호출 간 최소 턴 수. 권장 1–5. hybrid/context 모드에만 적용됩니다 |
dialecticDepth | 1 | 방언 호출당 .chat() 회의 반복 횟수. 1–3으로 제한됨. 0회 반복: 차가운/따뜻한 프롬프트, 1회 반복: 자체 감사, 2회 반복: 조정 |
dialecticDepthLevels | null | 패스별 추론 수준의 선택적 배열, 예: ["minimal", "low", "medium"]. 비례 기본값을 재정의합니다 |
dialecticReasoningLevel | 'low' | 기본 추론 수준: minimal, low, medium, high, max |
dialecticDynamic | true | 모델은 true 시 도구 매개변수를 통해 호출별로 추론 수준을 재정의할 수 있습니다 |
dialecticMaxChars | 600 | 시스템 프롬프트에 주입된 변증법 결과의 최대 문자 수 |
recallMode | 'hybrid' | hybrid (자동 주입 + 도구), context (주입만), tools (도구만) |
writeFrequency | 'async' | 메시지를 플러시할 시기: async (백그라운드 스레드), turn (동기), session (종료 시 배치), 또는 정수 N |
saveMessages | true | 메시지를 Honcho API에 영구 저장할지 여부 |
observationMode | 'directional' | directional (모두 켬) 또는 unified (공유 풀). observation 객체로 재정의 |
messageMaxChars | 25000 | 메시지당 최대 문자 수(초과 시 분할) |
dialecticMaxInputChars | 10000 | peer.chat()에 대한 변증법적 쿼리 입력의 최대 문자 수 |
sessionStrategy | 'per-directory' | per-directory, per-repo, per-session, global |
Minimal honcho.json (cloud)
{
"apiKey": "your-key-from-app.honcho.dev",
"hosts": {
"hermes": {
"enabled": true,
"aiPeer": "hermes",
"peerName": "your-name",
"workspace": "hermes"
}
}
}
Minimal honcho.json (self-hosted)
{
"baseUrl": "http://localhost:8000",
"hosts": {
"hermes": {
"enabled": true,
"aiPeer": "hermes",
"peerName": "your-name",
"workspace": "hermes"
}
}
}
hermes honcho이전에 hermes honcho setup를 사용했다면, 구성과 모든 서버 측 데이터는 그대로 있습니다. 설정 마법사를 통해 다시 활성화하거나 수동으로 memory.provider: honcho를 설정하여 새로운 시스템에서 재활성화하면 됩니다.
다중 피어 설정:
Honcho는 대화를 피어들이 메시지를 교환하는 것으로 모델링합니다 — 하나의 사용자 피어와 하나의 AI 피어가 각각 Hermes 프로필에 있으며, 모두 작업 공간을 공유합니다. 작업 공간은 공유된 환경입니다: 사용자 피어는 프로필 전체에서 글로벌하며, 각 AI 피어는 고유한 정체성을 가집니다. 각 AI 피어는 자신의 관찰을 바탕으로 독립적인 표현/카드를 구축하므로, coder 프로필은 코딩 중심을 유지하고, writer 프로필은 동일한 사용자에 대해 편집 방향을 유지합니다.
매핑:
| 개념 | 그것이 무엇인지 |
|---|---|
| 작업 공간 | 공유 환경. 하나의 작업 공간에 있는 모든 Hermes 프로필은 동일한 사용자 ID를 봅니다. |
사용자 피어 (peerName) | 인간. 작업 공간의 프로필 간에 공유됨. |
AI 동료 (aiPeer) | Hermes 프로필당 하나. 호스트 키 hermes → 기본; 다른 것들은 hermes.<profile>. |
| 관찰 | 페어별 토글로 Honcho가 누구의 메시지를 기반으로 어떤 모델을 사용할지 제어합니다. directional (기본값, 네 가지 모두 켜짐) 또는 unified (단일 관찰자 풀). |
새 프로필, 신선한 혼초 동료
hermes profile create coder --clone
--clone는 honcho.json에서 aiPeer: "coder", 공유 workspace, 상속된 peerName, recallMode, writeFrequency, observation 등과 함께 hermes.coder 호스트 블록을 생성합니다. AI 피어는 첫 번째 메시지 전에 존재하도록 Honcho에서 적극적으로 생성됩니다.
기존 프로필, Honcho 동료 백필
hermes honcho sync
모든 Hermes 프로필을 스캔하고, 호스트 블록이 없는 프로필에 대해 호스트 블록을 생성하며, 기본 hermes 블록의 설정을 상속하고, 새로운 AI 피어를 적극적으로 생성합니다. 멱등성 — 이미 호스트 블록이 있는 프로필은 건너뜁니다.
프로필별 관찰
각 호스트 블록은 관찰 구성을 독립적으로 재정의할 수 있습니다. 예시: AI 동료가 사용자를 관찰하지만 자기 모델링은 하지 않는 코드 중심 프로필:
"hermes.coder": {
"aiPeer": "coder",
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": false, "observeOthers": true }
}
}
관찰 토글(피어별 한 세트):
| 전환 | 효과 |
|---|---|
observeMe | Honcho는 자신의 메시지에서 이 피어의 표현을 생성합니다 |
observeOthers | 이 피어는 다른 피어의 메시지를 관찰한다 (피드가 피어 간 추론을 교차함) |
observationMode를 통한 프리셋:
"directional"(기본) — 네 개의 플래그 모두 켬. 완전한 상호 관찰; 피어 간 변증법 활성화."unified"— 사용자observeMe: true, AIobserveOthers: true, 나머지는 거짓. 단일 관찰자 풀; AI는 사용자를 모델링하지만 자신은 아니며, 사용자는 오직 자신만 모델링함.
서버 측 토글은 Honcho 대시보드를 통해 설정된 것이 로컬 기본값보다 우선하며 — 세션 시작 시 다시 동기화됩니다.
전체 관찰 참조는 Honcho 페이지를 참조하세요.
Full honcho.json example (multi-profile)
{
"apiKey": "your-key",
"workspace": "hermes",
"peerName": "eri",
"hosts": {
"hermes": {
"enabled": true,
"aiPeer": "hermes",
"workspace": "hermes",
"peerName": "eri",
"recallMode": "hybrid",
"writeFrequency": "async",
"sessionStrategy": "per-directory",
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": true }
},
"dialecticReasoningLevel": "low",
"dialecticDynamic": true,
"dialecticCadence": 2,
"dialecticDepth": 1,
"dialecticMaxChars": 600,
"contextCadence": 1,
"messageMaxChars": 25000,
"saveMessages": true
},
"hermes.coder": {
"enabled": true,
"aiPeer": "coder",
"workspace": "hermes",
"peerName": "eri",
"recallMode": "tools",
"observation": {
"user": { "observeMe": true, "observeOthers": false },
"ai": { "observeMe": true, "observeOthers": true }
}
},
"hermes.writer": {
"enabled": true,
"aiPeer": "writer",
"workspace": "hermes",
"peerName": "eri"
}
},
"sessions": {
"/home/user/myproject": "myproject-main"
}
}
설정 참조 및 Honcho 통합 가이드를 참조하세요.
오픈바이킹
볼크엔진(ByteDance)의 컨텍스트 데이터베이스로, 파일시스템 방식의 지식 계층 구조, 단계별 검색, 6가지 카테고리로 자동 메모리 추출 기능을 제공합니다.
| 에 가장 적합 | 구조화된 탐색이 가능한 자체 호스팅 지식 관리 |
| 필요 | pip install openviking + 서버 실행 중 |
| 데이터 저장 | 자체 호스팅(로컬 또는 클라우드) |
| 비용 | 무료(오픈소스, AGPL-3.0) |
도구: viking_search (의미 기반 검색), viking_read (계층형: 요약/개요/전체), viking_browse (파일 시스템 탐색), viking_remember (사실 저장), viking_add_resource (URL/문서 수집)
설정:
# Start the OpenViking server first
pip install openviking
openviking-server
# Then configure Hermes
hermes memory setup # select "openviking"
# Or manually:
hermes config set memory.provider openviking
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env
주요 특징:
- 계층적 컨텍스트 로딩: L0 (~100 토큰) → L1 (~2천) → L2 (전체)
- 세션 커밋 시 자동 메모리 추출(프로필, 환경설정, 엔터티, 이벤트, 사례, 패턴)
viking://계층적 지식 탐색을 위한 URI 스킴
메모0
서버 측 LLM 사실 추출과 시맨틱 검색, 재순위 매김, 자동 중복 제거.
| 에 가장 적합 | 자동 메모리 관리 — Mem0이 추출을 자동으로 처리합니다 |
| 필요 | pip install mem0ai + API 키 |
| 데이터 저장 | 멤0 클라우드 |
| 비용 | Mem0 가격 |
도구: mem0_profile (모든 저장된 기억), mem0_search (의미 검색 + 재순위화), mem0_conclude (말 그대로의 사실 저장)
설정:
hermes memory setup # select "mem0"
# Or manually:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env
설정: $HERMES_HOME/mem0.json
| 키 | 기본값 | 설명 |
|---|---|---|
user_id | hermes-user | 사용자 식별자 |
agent_id | hermes | 에이전트 식별자 |
뒤늦은 통찰
지식 그래프, 엔티티 해상도 및 다중 전략 검색을 갖춘 장기 메모리. hindsight_reflect 도구는 다른 제공자에는 없는 교차 메모리 통합을 제공합니다. 세션 수준의 문서 추적과 함께 전체 대화 턴(도구 호출 포함)을 자동으로 유지합니다.
| 에 가장 적합 | 엔티티 관계를 활용한 지식 그래프 기반 회수 |
| 필요 | 클라우드: ui.hindsight.vectorize.io의 API 키. 로컬: LLM API 키 (OpenAI, Groq, OpenRouter 등) |
| 데이터 저장 | Hindsight 클라우드 또는 로컬 임베디드 PostgreSQL |
| 비용 | 사후 가격 책정(클라우드) 또는 무료(로컬) |
도구: hindsight_retain (엔티티 추출과 함께 저장), hindsight_recall (다중 전략 검색), hindsight_reflect (교차 메모리 합성)
설정:
hermes memory setup # select "hindsight"
# Or manually:
hermes config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env
설치 마법사는 종속 항목을 자동으로 설치하며 선택한 모드에 필요한 항목만 설치합니다 (hindsight-client는 클라우드용, hindsight-all는 로컬용). hindsight-client >= 0.4.22가 필요합니다(구버전일 경우 세션 시작 시 자동으로 업그레이드됩니다).
로컬 모드 UI: hindsight-embed -p hermes ui start
설정: $HERMES_HOME/hindsight/config.json
| 키 | 기본값 | 설명 |
|---|---|---|
mode | cloud | cloud 또는 local |
bank_id | hermes | 메모리 뱅크 식별자 |
recall_budget | mid | 세심함 기억하기: low / mid / high |
memory_mode | hybrid | hybrid (context + 도구), 컨텍스트 (자동 주입만), tools (도구만) |
auto_retain | true | 대화 순서를 자동으로 저장 |
auto_recall | true | 각 턴 전에 자동으로 기억을 불러오기 |
retain_async | true | 서버에서 비동기적으로 프로세스를 유지 |
retain_context | conversation between Hermes Agent and the User | 유지된 기억에 대한 맥락 레이블 |
retain_tags | — | 보존된 메모리에 적용된 기본 태그; 호출별 도구 태그와 병합됨 |
retain_source | — | 보존된 기억에 첨부된 선택적 metadata.source |
retain_user_prefix | User | 자동 보관된 기록을 사용자에게 제출하기 전에 사용된 라벨 |
retain_assistant_prefix | Assistant | 보조가 자동 보관된 전사에서 말을 시작하기 전에 사용되는 라벨 |
recall_tags | — | 리콜에서 필터링할 태그 |
전체 구성 참조는 플러그인 README를 참조하세요.
홀로그램의
컴포지션 대수 쿼리를 위해 FTS5 전체 텍스트 검색, 신뢰도 점수, HRR(홀로그래픽 축소 표현)을 갖춘 로컬 SQLite 사실 저장소.
| 에 가장 적합 | 고급 검색 기능을 갖춘 로컬 전용 메모리, 외부 종속 없음 |
| 필요 | 아무 것도 아님( SQLite는 항상 사용 가능). HRR 대수에는 NumPy가 선택 사항임. |
| 데이터 저장 | 로컬 SQLite |
| 비용 | 무료 |
도구: fact_store (9가지 동작: 추가, 검색, 탐색, 관련, 추론, 반박, 업데이트, 제거, 목록), fact_feedback (신뢰 점수를 훈련하는 유용/유용하지 않음 평가)
설정:
hermes memory setup # select "holographic"
# Or manually:
hermes config set memory.provider holographic
구성: config.yaml 아래 plugins.hermes-memory-store
| 키 | 기본값 | 설명 |
|---|---|---|
db_path | $HERMES_HOME/memory_store.db | SQLite 데이터베이스 경로 |
auto_extract | false | 세션 종료 시 자동으로 사실 추출 |
default_trust | 0.5 | 기본 신뢰 점수 (0.0–1.0) |
독특한 능력:
probe— 개체 특정 대수적 회상 (사람/사물에 대한 모든 사실)reason— 여러 엔티티에 걸친 구성적 AND 쿼리contradict— 상충되는 사실의 자동 감지- 비대칭 피드백을 통한 신뢰 점수 계산 (+0.05 유용함 / -0.10 유용하지 않음)
리테인DB
하이브리드 검색(Vector + BM25 + 재순위화)을 지원하는 클라우드 메모리 API, 7가지 메모리 유형 및 델타 압축.
| 에 가장 적합 | 이미 RetainDB의 인프라를 사용하고 있는 팀들 |
| 필요 | RetainDB 계정 + API 키 |
| 데이터 저장 | 리테인DB 클라우드 |
| 비용 | 월 $20 |
도구: retaindb_profile (사용자 프로필), retaindb_search (의미 검색), retaindb_컨텍스트 (작업 관련 context), retaindb_remember (유형 + 중요도 저장), retaindb_forget (기억 삭제)
설정:
hermes memory setup # select "retaindb"
# Or manually:
hermes config set memory.provider retaindb
echo "RETAINDB_API_KEY=your-key" >> ~/.hermes/.env
바이트로버
brv CLI를 통한 지속적인 메모리 — 계층화된 지식 트리와 단계적 검색(퍼지 텍스트 → LLM 기반 검색). 로컬 우선이며 선택적 클라우드 동기화 지원.
| 에 가장 적합 | CLI가 있는 휴대 가능하고 로컬 우선 메모리를 원하는 개발자 |
| 필요 | ByteRover CLI (npm install -g byterover-cli 또는 설치 스크립트) |
| 데이터 저장 | 로컬(기본) 또는 ByteRover 클라우드(선택적 동기화) |
| 비용 | 무료(로컬) 또는 ByteRover 가격(클라우드) |
도구: brv_query (지식 트리 검색), brv_curate (사실/결정/패턴 저장), brv_status (CLI 버전 + 트리 통계)
설정:
# Install the CLI first
curl -fsSL https://byterover.dev/install.sh | sh
# Then configure Hermes
hermes memory setup # select "byterover"
# Or manually:
hermes config set memory.provider byterover
주요 특징:
- 자동 사전 압축 추출(문맥 압축이 정보를 버리기 전에 인사이트를 저장함)
- 지식 트리가
$HERMES_HOME/byterover/(프로필 범위) 에 저장됨 - SOC2 Type II 인증 클라우드 동기화(선택 사항)
슈퍼메모리
프로필 회상, 의미 검색, 명시적 기억 도구, 세션 종료 대화 수집을 지원하는 Supermemory 그래프 API를 이용한 의미 장기 기억.
| 에 가장 적합 | 사용자 프로파일링 및 세션 수준 그래프 구축을 통한 의미적 회상 |
| 필요 | pip install supermemory + API 키 |
| 데이터 저장 | 슈퍼메모리 클라우드 |
| 비용 | 슈퍼메모리 가격 |
도구: supermemory_store (명시적 기억 저장), supermemory_search (의미 유사도 검색), supermemory_forget (ID 또는 최적 일치 쿼리로 잊기), supermemory_profile (지속 프로필 + 최근 문맥)
설정:
hermes memory setup # select "supermemory"
# Or manually:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env
설정: $HERMES_HOME/supermemory.json
| 키 | 기본값 | 설명 |
|---|---|---|
container_tag | hermes | 검색 및 쓰기에 사용되는 컨테이너 태그입니다. 프로필 범위 태그에 대해 {identity} 템플릿을 지원합니다. |
auto_recall | true | 턴 전에 관련된 메모리 컨텍스트를 주입하세요 |
auto_capture | true | 응답 후 각 사용자-어시스턴트 대화를 저장했습니다 |
max_recall_results | 10 | 맥스는 항목을 문맥에 맞게 형식화하기 위해 떠올렸다 |
profile_frequency | 50 | 첫 번째 턴과 매 N 턴마다 프로필 사실을 포함하세요 |
capture_mode | all | 기본적으로 작거나 사소한 회전은 건너뜁니다 |
search_mode | hybrid | 검색 모드: hybrid, memories, 또는 documents |
api_timeout | 5.0 | SDK 및 인제스트 요청 시간 초과 |
환경 변수: SUPERMEMORY_API_KEY (필수), SUPERMEMORY_CONTAINER_TAG (구성을 덮어씀).
주요 특징:
- 자동 컨텍스트 펜싱 — 캡처된 턴에서 회상된 기억을 제거하여 재귀적 메모리 오염을 방지
- 세션 종료 대화 수집을 통한 더 풍부한 그래프 수준 지식 구축
- 프로필 정보는 첫 번째 턴과 설정 가능한 간격마다 주입됩니다
- 사소한 메시지 필터링(“ok”, “thanks” 등은 건너뜀)
- 프로필 범위 컨테이너 — Hermes 프로필별로 메모리를 분리하기 위해
{identity}를container_tag에서 사용합니다 (예:hermes-{identity}→hermes-coder) - 다중 컨테이너 모드 — 에이전트가 명명된 컨테이너 간에 읽기/쓰기를 할 수 있도록
enable_custom_container_tags을(를)custom_containers목록과 함께 활성화합니다. 자동 작업(동기화, 사전 가져오기)은 기본 컨테이너에서 계속 수행됩니다.
Multi-container example
{
"container_tag": "hermes",
"enable_custom_container_tags": true,
"custom_containers": ["project-alpha", "shared-knowledge"],
"custom_container_instructions": "Use project-alpha for coding context."
}
지원: Discord · support@supermemory.com
제공자 비교
| 제공자 | 저장 | 비용 | 도구 | 의존성 | 독특한 특징 |
|---|---|---|---|---|---|
| 혼초 | 구름 | 유료 | 5 | honcho-ai | 변증법적 사용자 모델링 + 세션 범위 컨텍스트 |
| 오픈바이킹 | 셀프 호스팅 | 무료 | 5 | openviking + 서버 | 파일 시스템 계층 구조 + 계층적 로딩 |
| 메모0 | 구름 | 유료 | 3 | mem0ai | 서버 측 LLM 추출 |
| 뒤늦은 통찰(또는 회고) | 클라우드/로컬 | 무료/유료 | 3 | hindsight-client | 지식 그래프 + 반사 합성 |
| 홀로그램 | 지역의 | 무료 | 2 | 없음 | HRR 대수 + 신뢰 점수 |
| RetainDB | 구름 | $20/mo | 5 | requests | 델타 압축 |
| 바이트로버 | 로컬/클라우드 | 무료/유료 | 3 | brv CLI | 압축 전 추출 |
| 슈퍼메모리 | 구름 | 유료 | 4 | supermemory | 컨텍스트 펜싱 + 세션 그래프 수집 + 멀티 컨테이너 |
프로필 격리
각 제공자의 데이터는 프로필별로 격리됩니다:
- 로컬 스토리지 제공자(Holographic, ByteRover)는 프로필마다 다른
$HERMES_HOME/경로를 사용합니다 - 설정 파일 제공자 (Honcho, Mem0, Hindsight, Supermemory)는
$HERMES_HOME/에 설정을 저장하므로 각 프로필은 자체 자격 증명을 가집니다 - 클라우드 제공자 (RetainDB)가 프로필 범위 프로젝트 이름을 자동으로 도출함
- 환경 변수 제공자(OpenViking)는 각 프로필의
.env파일을 통해 구성됩니다
메모리 제공자 만들기
자신만의 메모리 제공자 플러그인을 만드는 방법은 개발자 가이드: 메모리 제공자 플러그인을 참조하세요.