외부 메모리 제공자

Hermes 에이전트용 타사 메모리 제공자를 설치, 구성 및 확인합니다. "설치됨"과 "Hermes에서 활성화됨"을 별도의 수용 기준으로 취급합니다.

원칙

최신 공식 문서에서 시작합니다. hermes-agent 스킬을 로드하고 제공자의 설치 페이지와 완전한 Hermes 통합 페이지를 모두 가져옵니다. 문서화된 권장 경로를 따르고, 실제 호환성 제약이 필요한 경우에만 문서화된 대체 경로를 사용합니다.
종속성은 Hermes의 관리형 venv 외부에 유지합니다. Hermes 업데이트는 해당 venv를 재구축할 수 있습니다. pipx 또는 전용 영구 venv를 선호합니다.
브리지 경계에서 Python ABI를 일치시킵니다. pipx 환경은 Hermes보다 최신 Python을 사용할 수 있습니다. 네이티브 휠이 관련된 경우, site-packages를 Hermes의 sys.path에 추가하는 것은 안전하지 않습니다. 래퍼가 프로세스 내에서 임포트를 실행할 때는 Hermes의 Python으로 생성된 전용 venv를 사용합니다.
구성에는 Hermes CLI를 사용합니다. config.yaml을 직접 편집하지 말고 hermes config set으로 설정을 적용합니다.
공유 메모리 도구 세트를 비활성화하지 마십시오. 레거시 파일 메모리를 교체할 때는 제공자에 문서화된 기본 제공 파일/프로필 플래그만 비활성화합니다. 포괄적인 hermes tools disable memory는 제공자 도구도 숨길 수 있습니다.
프롬프트 캐싱을 고려합니다. 제공자/도구 변경은 새로 초기화된 세션에 적용됩니다. 기존 대화의 시스템 프롬프트나 도구 스키마를 변경하지 말고 게이트웨이를 다시 시작하고 이미 실행 중인 TUI 세션을 교체해야 한다고 명확히 명시합니다.

설치 워크플로우

1. 상태 변경 전 감사

다음을 기록합니다.

hermes --version 및 Hermes의 Python 버전/경로
제공자 패키지 버전 및 설치 환경
제공자 설치 프로그램/상태 출력
hermes plugins list --plain --no-bundled
hermes config get memory.provider
hermes memory status
게이트웨이 상태

기본 패키지 버전에서 [all] 또는 이와 동등한 extras를 추론하지 마십시오. 제공자의 문서에서 명명된 모든 기능 종속성을 임포트하거나 검사합니다.

2. 격리 토폴로지 선택

제공자가 프로세스 외부에서 통신하거나 Hermes가 안전한 패키지 진입점을 발견하는 경우 pipx를 사용합니다.
Hermes가 프로세스 내에서 제공자 코드를 임포트하고 패키지에 네이티브 확장이 포함된 경우 Hermes의 Python으로 빌드된 전용 venv를 사용합니다.
importlib.util.find_spec()을 호환성 증거로 취급하지 마십시오. 모듈을 찾지만 네이티브 코드를 로드하지 않습니다. 제공자를 실행할 인터프리터에서 실제 임포트를 수행합니다.

3. 제공자 및 브리지 설치

요청된 전체 기능 프로필과 해당 Hermes 래퍼를 설치합니다. 래퍼에 설치 프로그램/상태 명령이 함께 제공되는 경우 이를 사용하여 $HERMES_HOME/plugins/ 아래에 영구 플러그인 브리지를 생성하고 임포트를 확인합니다.

Hermes가 사용자 플러그인을 옵트인으로 나열하는 경우 명시적으로 활성화합니다.

hermes plugins enable <manifest-name>

제공자 선택과 일반 플러그인 활성화는 별도의 메커니즘일 수 있습니다. 둘 다 확인합니다.

4. 중복 없이 구성

외부 제공자를 설정하고, 제공자 문서에 지시된 경우 메모리 도구 세트를 유지하면서 레거시 파일 메모리를 비활성화합니다.

hermes config set memory.provider <provider>
hermes config set memory.memory_enabled false
hermes config set memory.user_profile_enabled false

이 키가 보편적이라고 가정하지 말고 제공자의 현재 문서화된 키를 사용합니다.

5. 다시 시작 및 확인

설치, 활성화 및 구성이 완료된 후에만 게이트웨이를 다시 시작합니다. 그런 다음 확인합니다.

게이트웨이가 활성화되어 있습니다.
플러그인 브리지/상태가 설치 및 임포트 가능하다고 표시됩니다.
후크/도구가 이에 의존하는 경우 일반 플러그인 목록에 활성화됨으로 표시됩니다.
hermes memory status가 선택한 제공자가 설치, 사용 가능 및 활성 상태라고 표시됩니다.
제공자 진단에 실제 오류/실패 기록이 없습니다. 카운터, 측정값, 건너뛴 검사 또는 설정되지 않은 선택적 재정의를 실패로 오해하지 마십시오.

6. Hermes 에이전트 경로 실행

독립형 SDK 스모크 테스트는 필요하지만 충분하지 않습니다. Hermes 자체 메모리 제공자 로더를 통해 제공자를 로드하거나 새 Hermes 에이전트를 시작한 후 다음을 확인합니다.

제공자 생성 및 초기화
제공자 시스템 프롬프트 블록이 활성화됨
제공자 도구 스키마가 노출됨
고유하게 태그된 테스트 메모리 쓰기
해당 정확한 태그 불러오기
테스트 메모리 삭제
제공자 DB/경로가 의도된 Hermes 저장소인지 확인

어설션을 사용하고 단계가 실패하면 확인 명령을 실패 처리합니다. 그럴듯한 예상이 아닌 실제 관찰된 버전/상태를 보고합니다.

일반적인 함정

별도의 pipx venv는 프로세스 내 임포트에 "함께" 사용할 수 없습니다. 코어와 래퍼가 각각 단독으로 작동하는 동안 Hermes는 둘 다 안전하게 임포트하지 못할 수 있습니다.
플러그인이 발견되었다고 활성화된 것은 아닙니다. 제공자 발견은 성공할 수 있지만 후크/도구 등록은 옵트인 상태로 남아 있을 수 있습니다.
CLI 명령이 없다고 제공자 실패를 의미하지는 않습니다. Hermes는 제공자를 로드할 수 있지만 설치 프로그램이 argparse 검색에 사용되는 형제 cli.py를 생략한 경우입니다. 제공자와 CLI 경로를 독립적으로 진단한 다음 테스트된 브리지로만 복구합니다.
게이트웨이 재시작이 현재 대화를 소급 적용하지는 않습니다. 새 게이트웨이 및 CLI 세션은 제공자를 사용하지만 이전 TUI 프로세스는 고정된 프롬프트/도구 표면을 유지합니다.
성공적인 설치 명령이 완료를 의미하지는 않습니다. 읽기-확인 구성, 활성 제공자 상태 및 실제 쓰기/불러오기/정리 주기가 필요합니다.

제공자 참조

Mnemosyne + Hermes 통합, Python ABI 처리, CLI 브리지 및 결정론적 스모크 테스트: references/mnemosyne-hermes.md

Apartment38/Agent-Skills

Agent-Skills란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서