Hermes 에이전트 Memory 기능: 실제 AI 에이전트에 무한한 채팅 기록이 아닌 엄선된 Memory이 필요한 이유

Memory은 장기 실행 에이전트 작업을 위한 제어 계층입니다.

좋은 기억 시스템은 반복적인 설명을 줄여줍니다. 나쁜 기억 시스템은 진부한 가정, 숨겨진 위험, 혼란스러운 행동을 만들어냅니다.

사람들은 AI 에이전트를 처음 테스트할 때 일반적으로 도구 사용에 중점을 둡니다. 탐색할 수 있나요? 코드를 실행할 수 있나요? 터미널을 열 수 있나요? 파일을 쓸 수 있나요? 이러한 사항은 중요하지만 핵심 병목 현상은 아닙니다. 더 어려운 문제는 세 번째나 네 번째 세션 이후에 나타납니다. 백엔드가 Go를 사용하고, 스테이징 브랜치에 다른 배포 명령이 있고, 팀이 특정 복사 패턴을 피하고, SEO 개요가 고정된 구조를 따라야 한다고 에이전트에게 알립니다. 에이전트는 해당 세션에서 좋은 성과를 냅니다. 그런 다음 다음날 동일한 설정 질문을 다시 묻거나 이미 내린 결정을 위반하는 작업을 생성합니다.

메모리가 워크플로 기능이 되는 곳이 바로 여기입니다. 영구 메모리가 없으면 모든 작업에 컨텍스트를 수동으로 다시 수화해야 합니다. 이전 지침을 붙여넣거나 긴 프롬프트 템플릿을 유지하거나 반복 수정을 허용합니다. 그 중 어느 것도 잘 확장되지 않습니다. Hermes Agent는 계층화된 메모리 모델을 통해 이에 접근합니다. 내장 메모리는 의도적으로 제한되고 선별됩니다. 이는 사용자, 환경 및 에이전트의 학습된 운영 컨텍스트에 대한 간략한 정보를 저장합니다. 이는 전체 성적표를 벡터 데이터베이스에 덤프하고 검색이 작동하기를 바라는 것과는 다릅니다.

헤르메스 에이전트가 실제로 기억하는 것

Hermes는 영구 메모리를 두 가지 실용적인 범주로 구분합니다. 첫 번째는 에이전트 메모리입니다. 즉, 환경, 프로젝트, 규칙, 워크플로 및 학습한 내용에 대한 메모입니다. 여기에는 리포지토리가 pnpm을 사용하거나, 특정 Makefile 대상을 통해 테스트가 실행되거나, 스테이징 서버에 기본이 아닌 SSH 포트가 필요하다는 사실을 에이전트가 저장할 수 있는 곳입니다. 두 번째는 사용자 메모리입니다. 즉, 선호도, 의사소통 스타일, 기대치, 역할, 작업 흐름 습관입니다. 여기서 상담원은 귀하가 간결한 응답을 선호하고, 추측성 주장을 싫어하며, SEO 초안이 특정 방식으로 구성되기를 원한다는 점을 기억할 수 있습니다.

모든 메모리가 동일한 작업을 수행하는 것은 아니기 때문에 이러한 구별이 중요합니다. 사용자 선호도에 따라 의사소통이 형성되어야 합니다. 프로젝트 사실이 실행을 결정해야 합니다. 완료된 작업 메모는 재작업을 방지해야 합니다. 도구 해결 방법을 사용하면 향후 디버깅 시간이 단축됩니다.

User memory     = how to work with me
Project memory  = how this environment works
Task memory     = what already happened
Searchable log  = what we may need to find later
External memory = what should scale beyond local notes

이것이 "더 많은 메모리"가 자동으로 더 좋아지지 않는 이유입니다. 모든 대화 내용이 영구적인 지시가 되면 상담원은 시끄러워집니다. 목표는 전체 회상이 아닙니다. 목표는 유용한 연속성입니다.

제한된 Memory이 제한이 아닌 기능인 이유

언뜻 보면 소규모로 선별된 메모리 저장소가 제한적으로 보입니다. 실제로는 더 나은 메모리 위생을 요구합니다. 많은 팀이 저지르는 실수는 에이전트 메모리를 창고처럼 취급하는 것입니다. 회의록, 원시 로그, 긴 코드 조각, 고객 기록 및 모호한 알림을 저장합니다. 나중에 에이전트는 기술적으로 관련되어 있지만 운영상 쓸모가 없는 조각을 검색합니다. 더 나쁜 것은 오래된 정보를 최신 정보로 취급할 수도 있다는 것입니다.

Hermes의 제한된 메모리 설계는 에이전트를 압축 방향으로 밀어냅니다. 전체 디버깅 세션을 저장하는 대신 강의를 저장해야 합니다.

Bad memory:
On Tuesday, we debugged the deployment script for two hours...

Good memory:
Project deploys to staging with `make deploy-staging`; required env vars
are in `.env.staging.local`; do not use production credentials during test deploys.

두 번째 항목은 더 짧고, 더 안전하고, 더 유용합니다. 불필요한 서사를 보존하지 않고 다음에 무엇을 해야 할지 에이전트에게 알려줍니다. 메모리가 에이전트의 작동 컨텍스트에 주입되기 때문에 이는 실제 작업에 중요합니다. 여기에 저장된 모든 내용은 향후 결정에 영향을 미칠 수 있습니다. 기억이 부풀어 오르거나, 오래되거나, 모순되면 에이전트의 행동이 저하됩니다. 컴팩트한 메모리 레이어는 "항상 사용 가능한" 컨텍스트를 깔끔하게 유지합니다.

코어 메모리, 세션 검색, 외부 공급자

세 가지 메모리 계층: 항상 사용 가능한 사실을 위한 핵심 선별 메모리, 에피소드 회상을 위한 세션 검색, 확장을 위한 외부 공급자.

Layer 1: 코어 큐레이트 메모리

코어 메모리에는 에이전트가 항상 알아야 할 사실이 포함되어 있습니다. 여기에는 지속 가능한 기본 설정, 안정적인 프로젝트 규칙, 환경 사실 및 반복 수정이 포함됩니다.

User prefers draft articles in a natural Medium tone, with short paragraphs,
practical examples, and no exaggerated marketing claims.

Project `content-pipeline` uses Python 3.11, Poetry, Playwright, and a local
SQLite queue. Run tests with `poetry run pytest`.

이 항목은 성적 증명서가 아닙니다. 이는 압축된 운영 지식입니다.

Layer 2: 세션 검색

모든 세부 사항을 영구적으로 기억할 수 있는 것은 아닙니다. 상담원이 이전 토론만 찾으면 되는 경우도 있습니다. 이를 위해서는 세션 검색이 더 적합합니다. 특정 데이터베이스 마이그레이션이 지연된 이유를 3주 전에 상담원에게 말했다고 가정해 보세요. 이는 향후 모든 프롬프트에 영구적으로 주입될 필요가 없을 수도 있습니다. 그런데 "마이그레이션에 관해 우리는 어떤 결정을 내렸나요?"라고 묻는다면 상담원은 과거 세션을 검색하고 관련 교환을 검색할 수 있어야 합니다. 이 구별이 중요합니다. 핵심 기억은 기본적으로 행동을 형성해야 하는 사실을 위한 것입니다. 세션 검색은 에피소드 회상을 위한 것입니다.

Layer 3: 외부 메모리 공급자

Hermes는 외부 메모리 공급자도 지원합니다. 메모리가 더욱 확장 가능하고 전문화되는 곳입니다. 공급자에 따라 에이전트는 의미 검색, 사용자 모델링, 백그라운드 동기화, 메모리 추출 또는 공급자별 도구를 사용할 수 있습니다. 이는 상담원이 개인 생산성에서 팀 워크플로로 이동할 때 유용합니다. 단일 개발자는 컴팩트 로컬 메모리와 세션 검색을 사용하면 괜찮을 수 있습니다. 콘텐츠 팀, 연구 그룹 또는 운영 팀은 브리핑, 캠페인, 사용자 프로필, 프로젝트 기록 및 반복되는 워크플로 전반에 걸쳐 더 광범위한 회상이 필요할 수 있습니다. 아키텍처 질문은 다음과 같습니다. 무엇이 로컬에 있어야 하고, 무엇이 검색 가능해야 하며, 무엇이 메모리 공급자에 의해 관리되어야 합니까?

실용적인 작업 흐름: Memory을 사용한 SEO 콘텐츠 에이전트

SEO 콘텐츠 워크플로우를 지원하기 위해 Hermes Agent를 사용한다고 가정해 보겠습니다. 에이전트는 주제를 조사하고, 개요를 작성하고, 기사 초안을 작성하고, 내부 연결 기회를 확인하고, CMS용 콘텐츠를 준비합니다. 기억이 없으면 모든 기사는 반복적인 설정으로 시작됩니다. 브랜드 보이스를 사용하고, 미끼를 피하고, 자연스럽게 제품을 언급하고, 주요 항목을 과도하게 사용하지 말고, 내부 연결 규칙을 따르고, 짧은 단락을 사용하고, 통계를 작성하지 마십시오. 몇 번의 세션 후에는 이것이 짜증스러워집니다. 수십 번의 세션 후에는 워크플로에 숨겨진 부담이 됩니다.

메모리를 사용하면 에이전트는 안정적인 규칙을 유지해야 합니다. 사용자는 해외 기술 독자를 위한 SEO 기사를 작성합니다. 스타일: 분석적, 실용적, 짧은 문단, 과장된 내용 없음, 가짜 통계 없음, 키워드 채우기 없음; 제품 언급은 자연스럽고 작업 흐름 맥락에 포함되어야 합니다.

헤르메스 스타일의 메모리는 연속성과 에이전트 추론에 강력합니다. EasyClaw 모든 작업을 사용자 지정 API 통합으로 전환하지 않고 콘텐츠 워크플로를 데스크톱 도구, CMS 인터페이스, 스프레드시트, 조사 탭 및 게시 단계 간에 이동해야 하는 경우 더 적합합니다. 실제 콘텐츠 운영에서 나는 이러한 도구를 "하나가 다른 하나를 대체한다"고 생각하지 않을 것입니다. 나는 여러 층으로 생각할 것입니다. Hermes 메모리는 브랜드 규칙, 콘텐츠 표준, 이전 결정 및 작업 흐름 교훈과 같은 추론 컨텍스트를 보존할 수 있습니다. EasyClaw은 초안이 존재한 후 발생하는 복잡한 애플리케이션 간 작업(콘텐츠를 CMS로 이동, 형식 확인, 메타데이터 준비 또는 도구 간 게시 작업 조정)을 실행하는 데 도움이 될 수 있습니다.

핵심은 모든 것을 저장하지 않는 것입니다. SEO 워크플로의 경우 좋은 메모리 항목에는 다음이 포함될 수 있습니다. 브랜드 목소리 - 명확하고 전문적이며 해외 기술 청중이며 과장된 주장이 없습니다. 기사 구조 — 처음 150단어 내 후크, 2-4문단마다 H2, 권장 사항 앞의 예, 끝 부분에만 소프트 CTA; SEO 규칙 - 제목, 소개, 하나의 H2 및 결론에서 기본 키워드를 자연스럽게 언급합니다. 반복적인 일치검색 키워드 채우기를 피하세요. 이러한 메모리는 작고 내구성이 뛰어나며 행동을 안내합니다.

저장하지 말아야 할 것

가장 과소평가된 메모리 기능은 망각입니다. 결코 잊지 않는 기억 시스템은 골칫거리가 됩니다. 오래된 기본 설정, 임시 디버깅 사실, 만료된 캠페인 세부 정보 또는 오래된 프로젝트 가정이 보존될 수 있습니다. 에이전트 워크플로에서 오래된 메모리는 에이전트가 이에 의존하고 있다는 사실을 사용자가 인식하지 못할 수 있기 때문에 메모리가 없는 것보다 더 나쁜 경우가 많습니다. 원시 로그, 전체 기사 초안, 임시 파일 경로, 일회용 브라우저 상태 또는 재발견하기 쉬운 사실은 저장하지 마십시오. 민감한 자격 증명을 저장하지 마십시오. "사용자가 SEO를 좋아한다"라든가 "프로젝트가 중요하다"와 같은 막연한 기억을 저장하지 마세요. 이러한 항목은 의사 결정을 개선하지 않고 공간을 소비합니다.

더 나은 테스트는 다음과 같습니다. "이 사실이 상담원이 전체 대화 없이도 향후 세션에서 더 나은 결정을 내리는 데 도움이 될까요?" 대답이 '아니오'인 경우 세션 기록, 프로젝트 문서 또는 어디에도 속하지 않습니다.

작업을 자동화하기 전에 Memory 정책을 설계하는 방법

Hermes Agent 메모리 기능을 많이 사용하기 전에 간단한 메모리 정책을 정의하십시오. 복잡할 필요는 없습니다. 우발적인 혼란을 방지하기만 하면 됩니다. 저는 네 가지 카테고리를 사용합니다. 먼저 어조, 형식, 기술적 깊이, 언어 선호도, 반복되는 기대치 등 안정적인 사용자 기본 설정을 저장합니다. 둘째, 저장소 구조, 테스트 명령, 배포 규칙, CMS 형식 지정 규칙, 명명 규칙 및 도구 체인 세부 정보와 같은 안정적인 프로젝트 규칙을 저장합니다. 셋째, 반복된 수정 사항을 저장합니다. 사용자가 동일한 동작을 두 번 수정하면 아마도 메모리에 속할 것입니다. 넷째, 향후 오류를 방지하는 교훈을 저장하십시오. 에이전트가 로컬 환경 문제로 인해 명령이 실패했음을 발견한 경우 해결 방법을 저장하십시오. 다른 모든 것은 조심스럽게 다루어야 합니다.

# Check active memory provider
hermes memory status
# Configure external memory provider
hermes memory setup
# Disable external provider when testing local-only behavior
hermes memory off

정확한 공급자 선택은 워크플로에 따라 다릅니다. 단일 사용자 로컬 설정의 경우 내장 메모리와 세션 검색으로 충분할 수 있습니다. 팀 규모, 다중 프로필 또는 세션 간 개인화의 경우 외부 공급자가 추가된 복잡성을 감당할 가치가 있을 수 있습니다.

에이전트 워크플로를 위한 간단한 Memory 흐름도

다음은 어떤 것이 메모리에 속하는지 결정할 때 사용하는 실용적인 결정 흐름입니다.

flowchart TD
    A[New information appears] --> B{Will it matter in future sessions?}
    B -- No --> C[Do not save]
    B -- Yes --> D{Is it stable or repeated?}
    D -- No --> E[Keep in session history]
    D -- Yes --> F{Is it compact and safe?}
    F -- No --> G[Summarize, redact, or skip]
    F -- Yes --> H{Does it guide behavior?}
    H -- No --> E
    H -- Yes --> I[Save to memory]

이렇게 하면 메모리가 계속 작동합니다. 요점은 사실 자체를 기억하는 것이 아니라는 것입니다. 요점은 미래의 행동을 개선하는 것입니다.

성능 절충: Always-On 컨텍스트와 주문형 리콜

Memory은 성능 균형을 만듭니다. Always On 메모리는 즉시 사용할 수 있기 때문에 빠릅니다. 하지만 이는 또한 상황을 소비하고 모든 반응에 영향을 미칩니다. 상담원은 필요할 때만 검색하므로 주문형 리콜이 더 깔끔해졌습니다. 하지만 에이전트가 검색 시기를 알아야 합니다. 이것이 Hermes의 영구 메모리와 세션 검색 간의 분리가 유용한 이유입니다. 핵심 메모리에는 모든 세션에서 비용을 지불할 가치가 있는 작은 사실 집합이 포함되어야 합니다. 세션 검색은 이전 논의의 롱테일을 유지해야 합니다.

예를 들어 "사용자는 간결한 응답을 선호합니다"는 코어 메모리에 속합니다. "3월에 3개의 CMS 플러그인을 비교했습니다"는 아마도 세션 검색에 속할 것입니다. "프로젝트는 업로드 전에 사용자 정의 이미지 압축 스크립트를 사용합니다."는 반복되는 게시 작업에 영향을 미치는 경우 코어 메모리에 속할 수 있습니다. 분류가 좋을수록 에이전트의 신뢰성이 높아집니다.

Industry Relevance: Memory이 개인 비서 이상으로 중요한 이유

AI 에이전트가 채팅에서 운영으로 이동하고 있기 때문에 Memory이 중요해지고 있습니다. 소프트웨어 팀에서 메모리는 에이전트가 프로젝트 규칙, 로컬 환경, 반복되는 오류 및 이전 구현 결정을 이해하는 데 도움이 됩니다. 콘텐츠 팀에서 메모리는 브랜드 보이스, 편집 규칙, 키워드 전략 및 출판 작업 흐름을 보존합니다. 고객 운영에서 메모리는 개인 정보 보호 및 거버넌스가 신중하게 처리되는 한 상담원이 사례, 에스컬레이션 규칙 및 고객별 기본 설정 전반에 걸쳐 연속성을 유지하는 데 도움이 될 수 있습니다.

일반적인 패턴은 연속성입니다. 실제 작업은 단일 프롬프트가 아닙니다. 이는 며칠 또는 몇 주에 걸쳐 일련의 관련 결정입니다. 팀은 고립된 상태에서 단순히 잘 대답하는 상담원을 원하지 않습니다. 그들은 주의를 낭비하지 않을 만큼 충분히 기억하는 에이전트를 원합니다. 이것이 Hermes Agent 메모리 기능의 진정한 가치입니다. 이를 통해 상담원이 완벽한 프롬프트에 덜 의존하게 됩니다. 사용자가 매번 작업 컨텍스트를 다시 설명하도록 강요하는 대신 에이전트는 중요한 부분을 전달합니다.

위험: Memory은 보이지 않는 프롬프트가 될 수 있습니다

메모리를 유용하게 만드는 동일한 기능이 메모리를 위험하게 만들기도 합니다. Memory은 보이지 않는 프롬프트처럼 작동합니다. 사용자가 이를 검사, 편집 또는 확인할 수 없다면 에이전트가 특정 방식으로 작동하는 이유를 이해하지 못할 수도 있습니다. 이것이 바로 메모리 거버넌스가 중요한 이유입니다. 사용자는 에이전트가 저장한 내용을 정기적으로 검토해야 합니다. 팀은 어떤 카테고리가 허용되는지 결정해야 합니다. 민감한 정보는 제외하거나 수정해야 합니다. 이전 프로젝트 사실이 변경되면 업데이트해야 합니다. 프로덕션 용도의 경우 메모리를 일반 채팅 기록이 아닌 구성처럼 취급합니다. 읽기, 편집, 감사가 가능하고 의도적으로 유지관리되어야 합니다.

헤르메스 에이전트 Memory 기능 잘 활용하는 방법

Hermes 메모리를 사용하는 가장 좋은 방법은 작게 시작하는 것입니다. 모든 공급자를 연결하고 모든 세션을 저장하는 것으로 시작하지 마십시오. 내장 메모리 레이어부터 시작하세요. 상담원이 귀하의 안정적인 기본 설정과 한두 가지 프로젝트 규칙을 기억하도록 하세요. 그런 다음 향후 세션이 개선되는지 관찰하십시오. 상담원이 계속해서 같은 실수를 한다면 수정 사항을 추가하세요. 동일한 설정 세부 사항이 반복적으로 필요한 경우 저장하십시오. 메모리가 오래되면 모순되는 메모를 추가하는 대신 교체하세요. 기본 루프가 작동하면 에피소드 회상을 위한 세션 검색을 추가합니다. 상시 지시를 따르기 위해 필요할 때가 아니라 이전 결정을 찾기 위해 대리인이 필요할 때 사용하십시오. 그런 다음에만 외부 메모리 공급자를 고려하십시오. 이는 가치가 있지만 또 다른 구성 및 거버넌스 계층을 추가합니다. 기억 시스템이 강력할수록 무엇을 기억해야 하는지, 어떻게 검색해야 하는지, 누가 수정할 수 있는지 정의하는 것이 더 중요해집니다.

결론: 올바른 것을 기억하십시오

Hermes Agent 메모리 기능은 AI 워크플로우 설계의 더 넓은 변화를 가리킵니다. 승리하는 에이전트는 맹목적으로 모든 것을 유지하는 에이전트가 아닙니다. 그들은 무엇을 보존하고, 무엇을 검색하고, 무엇을 압축하고, 무엇을 잊어야 하는지 아는 사람들이 될 것입니다. 사용자의 경우 실용적인 교훈은 간단합니다. 즉, 메모리를 운영 계층으로 취급하는 것입니다. 이를 사용하여 지속적인 기본 설정, 프로젝트 규칙, 반복 수정 및 향후 실수를 방지하는 교훈을 저장합니다. 검색 가능한 기록에 원시 세부정보를 유지합니다. 워크플로에 실제로 확장이 필요한 경우에만 외부 메모리 공급자를 사용하세요. 심각한 에이전트 워크플로를 구축하는 팀의 경우 자동화가 확장되기 전에 메모리를 설계해야 합니다. 그렇지 않으면 에이전트는 강력하지만 일관성이 없어질 수 있습니다. 즉, 행동할 수는 있지만 연속성을 유지할 수는 없습니다. 최고의 AI 에이전트는 가장 많이 기억하는 에이전트가 아닙니다. 올바른 세부 수준에서 올바른 항목을 기억한 다음 해당 메모리를 사용하여 다음 작업을 더 쉽게 만드는 것입니다.