최근 Hermes Agent 논문들은 자율 에이전트에서의 지속적 메모리, 도구 사용 추상화, 그리고 반사 루프 주위에 생산적인 논의를 촉발했다.

과장된 기대감을 더하기보다는, 1년 이상 운영 환경에서 실행되어 온 구현체인 OpenClaw와 Hermes가 제안한 아키텍처를 비교하고자 한다.

목표는 우선순위를 주장하는 것이 아니라, 패턴이 수렴되는 지점—and OpenClaw가 이미 동일한 엔지니어링 과제 중 몇 가지를 해결한 지점을 보여주는 것이다.

메모리 아키텍처

Hermes는 벡터 검색 및 감쇠 메커니즘을 갖춘 크로스 세션 지속 메모리를 제안한다.

OpenClaw는 Honcho를 사용하여 로컬 우선, 프로그래밍 가능한 메모리 레이어로 구현합니다. 주요 기술적 선택:

• 시간적 감쇠: 오래된 기억은 검색 점수가 지수적으로 낮아진다. 이로 인해 오래된 컨텍스트가 작업 기억을 지배하는 것을 방지한다.
• MMR (최대 마진 관련성): 검색기는 현재 쿼리와의 유사도와 반환된 기억 간의 다양성을 균형 있게 유지한다. 중복된 거의 동일한 구절은 없다.
• API 호출 없음: 전체 메모리 시스템이 로컬에서 실행됩니다—유료 벡터 데이터베이스나 외부 임베딩 서비스로의 왕복이 없습니다.

추론 vs. 도구 사용

Hermes는 에이전트의 추론 코어와 도구 호출 표면 사이의 깨끗한 분리를 설명합니다.

OpenClaw는 첫 번째 릴리스부터 이 분리를 가지고 있습니다:

• 추론 루프는 컴팩트한 '작업 메모리' 뷰에서 작동합니다.
• 도구는 명시적인 스키마를 가진 모듈화되고 타입이 지정된 함수로 정의됩니다.
• 에이전트는 도구를 직접 호출하지 않으며, 오케스트레이터가 라우팅하고 검증하는 구조화된 '도구 요청'을 내보냅니다.

이를 통해 도구 인터페이스를 변경하지 않고 모델을 교체할 수 있습니다(예: 작은 로컬 모델에서 GPT-4로). 이는 95%의 단계에서 추론 비용을 낮게 유지하는 패턴입니다.

반성 루프

Hermes는 자기 수정을 위한 “반성 루프”를 도입합니다.

OpenClaw는 이를 디버거 전용 제약 조건으로 구현합니다:

• 에이전트는 주로 작은 빠른 모델(Ollama, llama.cpp)에서 실행됩니다.
• 유료 모델(OpenAI, Anthropic)은 에이전트가 신뢰도 임계값에 도달하거나 실행 오류가 발생했을 때만 호출되며—실패를 반성하고 수정된 계획을 생성하기 위해서만 호출됩니다.
• 이는 반성 루프가 비용 배수가 되는 것을 방지합니다.

다중 에이전트 오케스트레이션

Hermes는 격리된 컨텍스트에서 서브에이전트 위임을 제안합니다.

OpenClaw은 Lobster 파이프라인—DAG 기반 작업 그래프를 사용합니다:

• 각 서브에이전트는 자체 메모리와 도구 컨텍스트에서 실행됩니다.
• 부모 에이전트는 구조화된 핸드오프를 통해 위임합니다(관련된 상태의 일부만 전달).
• 파이프라인은 구성, 캐시, 재생이 가능하여 무비용 장애 복구가 가능합니다.

프로덕션 테스트에서 이는 단일 에이전트가 모든 것을 처리하는 것에 비해 다단계 작업에서 토큰 소비를 70-80% 줄입니다.

Hermes가 진정으로 새로운 부분에서

공정하게 말하면, Hermes는 이러한 에이전트의 배포 및 라이프사이클 관리를 형식화합니다(버전 관리, 롤백, 메모리 매개변수의 A/B 테스트). OpenClaw은 현재 그런 세련미가 부족합니다—개발자 우선 툴킷일 뿐, 관리되는 플랫폼은 아닙니다.

이는 전체 분야에 유용한 방향입니다.

결론

오늘 에이전트를 구축하고 있다면, Hermes의 폐쇄형 소스 구현을 기다릴 필요가 없습니다.

핵심 패턴—시간적 감소가 적용된 지속적 메모리, MMR 검색, 분리된 추론/도구 계층, 비용 제어 반사 루프, 그리고 DAG 기반 서브 에이전트 오케스트레이션—은 이미 OpenClaw에 구현되어 있으며, 전체 구성 파일과 예시가 제공됩니다.

클론을 받아서 노트북에서 실행하고, 오후 안에 아키텍처 수정을 시작할 수 있습니다.

이 모든 것을 문서화한 글은 여기 있습니다: OpenClaw를 제로 달러 예산으로 구축하기: 시간적 감소가 적용된 하이브리드 멀티 에이전트 메모리와 MMR

대화를 기술적으로 유지합시다. 이 아키텍처의 어느 부분을 더 깊이 파고들고 싶으신가요?