Hermes Agent Masterclass

🖼️ 인포그래픽

Hermes Agent Masterclass 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hermes Agent는 세션이 끝나도 사용자 맥락과 작업 절차를 축적하도록 설계된 오픈소스 AI 에이전트로, 정체성 설정, 3단계 메모리, 자가 진화형 스킬, Curator, GEPA 최적화를 결합해 장기적으로 개인 워크플로에 맞춰지는 구조를 지향한다.

📌 핵심 요약

Hermes Agent의 핵심 병목 인식은 “대부분의 AI 에이전트가 세션 종료 후 모든 맥락을 잊는다”는 점이다.
이를 해결하기 위해 Hermes는 SOUL.md 기반 정체성, 다층 메모리, 절차형 스킬, 백그라운드 스킬 정리, 오프라인 최적화 파이프라인을 하나의 프레임워크로 묶는다.
메모리는 즉시 프롬프트에 들어가는 작은 핵심 메모리, SQLite 기반 세션 검색, 외부 메모리 provider의 3단계로 나뉜다.
스킬은 에이전트가 반복 가능한 작업 절차를 Markdown 파일로 저장하는 방식이며, 복잡한 작업·오류 해결·사용자 교정 이후 자동 생성될 수 있다.
Curator는 오래되거나 중복된 에이전트 작성 스킬을 정리하고, GEPA는 실행 trace를 바탕으로 스킬을 오프라인에서 평가·개선하는 역할을 맡는다.
profiles 기능을 통해 디자이너, 프로그래머, 리서처처럼 메모리·스킬·설정·SOUL.md가 분리된 여러 에이전트를 병렬로 운영할 수 있다.

🧩 주요 포인트

Hermes의 출발점은 “AI 에이전트가 매번 처음부터 다시 시작하는 문제”를 장기 기억과 절차 학습으로 줄이는 것이다.
SOUL.md는 메모리와 스킬보다 앞서 로드되는 정체성 계층으로, 에이전트의 말투·성격·제한조건을 고정한다.
메모리 시스템은 작은 핵심 메모리, 검색 가능한 대화 이력, 외부 provider를 조합해 즉시성·용량·지속성을 분리한다.
자가 진화형 스킬은 성공한 작업 절차를 재사용 가능한 playbook으로 저장해 다음 작업에서 같은 시행착오를 반복하지 않게 한다.
Curator는 스킬 라이브러리가 비대해지는 문제를 줄이고, GEPA는 에이전트의 자기평가 한계를 보완하기 위해 실행 trace 기반으로 스킬을 개선한다.
profile, Telegram bot, cron 기능을 조합하면 서로 격리된 전문 에이전트들을 24시간 운영하는 구조로 확장할 수 있다.

🧠 상세 정리

1. 왜 Hermes의 핵심 병목은 “잊어버리는 에이전트”인가

원문이 제시하는 문제의식은 명확하다. 많은 AI 에이전트는 한 세션 안에서는 유용하게 작동하지만, 세션이 끝나면 사용자의 코딩 취향, 프로젝트 규칙, 이전에 수정했던 방식, 전날 찾아낸 해결책을 다음 세션에서 다시 알지 못한다. 사용자는 같은 설명을 반복하고, 에이전트는 같은 시행착오를 다시 겪는다. Hermes Agent는 이 병목을 단순한 “대화 기록 저장” 문제가 아니라, 에이전트가 장기적으로 사용자의 workflow에 맞춰지는 구조 문제로 본다. 그래서 메모리, 스킬, 최적화가 분리된 부가기능이 아니라 하나의 learning loop로 연결된다. 원문은 이를 “오래 쓸수록 더 나아지는 에이전트”라는 한 줄 pitch로 요약한다.

2. 기본 아키텍처: 하나의 AIAgent와 여러 진입점

Hermes의 실행 구조는 하나의 AIAgent class를 중심으로 한다. CLI, messaging gateway, batch runner, IDE integration은 모두 같은 core agent로 들어가는 진입점이다. 이 구조 덕분에 사용자는 터미널에서 대화하든, Telegram으로 요청하든, 다른 환경에서 실행하든 동일한 에이전트 루프를 사용할 수 있다. core loop는 ReAct 스타일의 동기식 루프다. 시스템 프롬프트를 만들고, compression 필요 여부를 확인하고, interrupt 가능한 API call을 수행한 뒤, tool call을 실행하고 다시 반복한다. 원문은 추가로 Hermes가 local terminal, Docker, SSH, Modal, Daytona, Singularity 등 6가지 실행 위치를 지원하며, provider translation layer를 통해 Claude, GPT, Gemini, local Ollama 등 여러 model을 바꿔 쓸 수 있다고 설명한다. 또한 task당 90턴 제한을 둬 실패 루프나 runaway delegation이 비용을 과도하게 소모하는 상황을 막는다.

3. SOUL.md: 메모리보다 먼저 로드되는 정체성 계층

Hermes에서 메모리는 “무엇을 아는가”, 스킬은 “어떻게 하는가”를 담당한다. 그러나 원문은 그보다 앞서 “에이전트가 누구인가”를 정의하는 계층이 필요하다고 본다. 이 역할을 맡는 파일이 SOUL.md다. SOUL.md는 ~/.hermes/SOUL.md에 위치하며, 시스템 프롬프트의 slot #1에 가장 먼저 들어간다. 여기에는 personality, tone, communication style, hard limits가 들어간다. 파일이 없으면 Hermes는 기본 identity를 사용한다. 중요한 점은 SOUL.md가 hand-authored이고 static이라는 것이다. 사용자가 한 번 작성하고 시간이 지나며 조금씩 수정할 수 있지만, 메모리나 스킬처럼 자동으로 계속 변하는 층은 아니다. 이 고정된 정체성 프레임 안에서 메모리와 스킬이 축적된다.

4. 3단계 메모리: 즉시성, 검색성, 확장성의 분리

Hermes의 메모리는 하나가 아니라 세 계층으로 나뉜다. Tier 1은 두 개의 작은 Markdown 파일이다. MEMORY.md는 환경, 프로젝트 규칙, tool quirks, lessons learned를 담고, USER.md는 사용자 이름, 커뮤니케이션 선호, skill level, 피해야 할 사항 등을 담는다. 각각 2,200자, 1,375자 제한이 있으며, 세션 시작 시 frozen snapshot으로 시스템 프롬프트에 주입된다. Tier 2는 SQLite 기반 full-text session search다. CLI와 messaging conversation이 저장되고, 에이전트는 과거 대화 내용을 검색할 수 있다. 여기서 tradeoff가 생긴다. Tier 1은 항상 context에 있지만 작고, Tier 2는 용량은 크지만 검색과 요약이 필요하다. 따라서 핵심 사실은 Tier 1에, 나머지는 필요할 때 검색 가능한 형태로 남기는 구조다. Tier 3은 외부 memory provider다. Hermes는 built-in memory를 대체하지 않고 보완하는 8개 pluggable provider를 제공하며, 한 번에 하나만 활성화할 수 있다. 외부 provider가 활성화되면 Hermes는 각 turn 전에 관련 기억을 prefetch하고, 응답 후 conversation turn을 sync하며, 세션 종료 시 memory extraction을 수행한다.

5. 자가 진화형 스킬: 사실이 아니라 절차를 저장한다

메모리가 facts를 다룬다면, 스킬은 procedures를 다룬다. Hermes의 skill은 YAML frontmatter가 포함된 Markdown 파일이며, 에이전트의 procedural memory로 작동한다. 원문은 이를 “agent-authored playbook”으로 설명한다. 즉, 에이전트가 특정 문제를 해결하는 데 성공한 절차를 저장해 다음에 재사용할 수 있게 하는 것이다. 스킬은 token cost를 줄이기 위해 progressive disclosure 구조를 쓴다. Level 0에서는 전체 catalog의 이름과 설명만 노출된다. 필요할 때 Level 1에서 full skill content를 로드하고, 더 구체적인 reference file이 필요하면 Level 2로 들어간다. 에이전트가 복잡한 작업을 완료했거나, 오류와 dead end를 통과해 working path를 찾았거나, 사용자가 접근 방식을 교정했거나, non-trivial workflow를 발견하면 skill_manage tool을 통해 스킬을 만들 수 있다. 이 loop는 “문제 발견 → 시행착오를 통한 해결 → 성공한 절차를 SKILL.md로 저장 → 유사 문제에서 재사용”으로 요약된다. 원문 기준으로 skill_manage tool은 create, patch, edit, delete, write_file, remove_file 여섯 동작을 지원하며, patch는 token 효율 때문에 선호되는 방식으로 소개된다.

6. Curator: 스킬이 쌓일수록 생기는 오염을 관리한다

자가 생성 스킬은 장점이 있지만, 시간이 지나면 좁고 중복된 playbook이 쌓일 수 있다. 그러면 catalog가 오염되고, token 비용이 늘고, 유사한 스킬 사이에서 선택이 애매해진다. Hermes의 Curator는 이 문제를 관리하는 백그라운드 maintenance system이다. Curator는 cron daemon처럼 정해진 시간마다 도는 방식이 아니라 inactivity check로 실행된다. 마지막 실행 후 7일이 지났고 에이전트가 2시간 이상 idle 상태이면, 별도 prompt cache를 가진 background fork가 만들어져 active conversation을 건드리지 않고 검토를 수행한다. 자동 전환 단계에서는 30일 미사용 스킬을 stale로, 90일 미사용 스킬을 archive로 보낸다. 이후 LLM review 단계에서는 최대 8회 iteration 동안 agent-authored skill을 대상으로 keep, patch, consolidate, archive를 판단한다. 중요한 제한도 있다. Curator는 bundled skill이나 hub-installed skill을 건드리지 않고, 에이전트가 만든 스킬만 관리한다. 또한 자동 삭제하지 않으며, 최악의 경우에도 ~/.hermes/skills/.archive/로 보관된다. 실행 전에는 skills directory 전체의 tar.gz snapshot을 남기므로 rollback이 가능하다. 중요한 스킬은 hermes curator pin <skill>로 보호할 수 있다.

7. GEPA: 에이전트의 자기평가 한계를 trace 기반 최적화로 보완한다

원문은 in-agent learning loop의 약점도 명시한다. 에이전트는 자신이 잘했다고 판단하는 경향이 있으며, 실제로 성능이 좋지 않아도 긍정적으로 자기평가할 수 있다. 또한 자동 생성 시스템이 수동 customization을 더 나쁜 버전으로 덮어쓸 위험도 있다. GEPA는 이 문제를 runtime 내부가 아니라 companion repository인 NousResearch/hermes-agent-self-evolution에서 다루는 offline optimization pipeline이다. 원문에 따르면 GEPA는 Genetic-Pareto Prompt Evolution의 약자로, ICLR 2026 Oral paper로 발표되었고 MIT license다. 핵심은 에이전트에게 “잘했는가”를 묻지 않고, execution trace를 읽어 실패 원인을 파악한 뒤 evolutionary search로 개선 후보를 만든다는 점이다. pipeline은 현재 skill을 읽고, synthetic test case나 SQLite session history, hand-curated golden set 등으로 evaluation dataset을 만들고, optimizer가 execution trace를 분석해 candidate variant를 생성하는 방식이다. 이후 LLM-as-judge scoring과 rubric을 통해 평가하며, full test suite 100% 통과, skill 15KB 이하, caching compatibility 유지, semantic purpose drift 방지 같은 constraint gate를 적용한다. 최종 variant는 direct commit이 아니라 Hermes repo에 대한 PR로 나간다. 원문은 GPU가 필요 없고 API call만으로 실행되며, 비용은 run당 대략 2~10달러라고 설명한다.

8. 여러 agent로 확장: profile, Telegram, cron

Hermes의 profile 기능은 하나의 기본 agent를 여러 전문 agent로 확장하는 기반이다. 각 profile은 config, memory, skills, sessions, SOUL.md가 완전히 분리된 Hermes instance다. 원문은 designer, programmer, researcher 세 가지 profile을 예로 들며, 각각 별도의 Telegram bot을 연결하고, 각자 다른 SOUL.md를 부여하는 방식을 소개한다. programmer profile은 Claude Code CLI에 실행을 위임하도록 설정할 수 있다. 이 경우 Hermes가 orchestration을 맡고, Claude Code가 파일 수정, command 실행, git 작업을 처리한다. designer profile은 reference image를 학습해 특정 visual style을 재현하는 skill을 만들 수 있다. researcher profile은 cron 기능과 연결해 매일 Telegram digest를 보내도록 구성할 수 있다. Hermes cron은 plain English schedule을 받아 job을 만들 수 있는 scheduler다. gateway daemon이 60초마다 due job을 확인하고, isolated agent session에서 실행한 뒤 messaging platform으로 결과를 보낸다. job은 ~/.hermes/cron/jobs.json에 저장되고 output은 ~/.hermes/cron/output/에 남는다. one-shot delay, recurring interval, standard cron expression, skill attachment, chained jobs 같은 패턴도 지원된다고 원문은 설명한다.

🧾 핵심 주장 / 시사점

Hermes Agent의 차별점은 단순한 persistent chat이 아니라 identity, memory, skill, curator, GEPA를 연결한 장기 learning loop에 있다.
병목은 model 성능만이 아니라 “사용자 맥락과 작업 절차가 세션 간 축적되지 않는 구조”에 있으며, Hermes는 이를 파일·DB·스킬 시스템으로 분해해 다룬다.
자가 생성 스킬은 생산성을 높일 수 있지만, 중복·오염·잘못된 자기평가 문제가 생기므로 Curator와 GEPA 같은 검증·정리 장치가 필요하다.
profile 단위 격리는 여러 전문 agent를 운영할 때 memory와 personality가 섞이지 않도록 하는 핵심 구조다.
Telegram bot과 cron을 결합하면 Hermes는 대화형 assistant를 넘어, 일정에 따라 실행되는 개인 workflow automation agent로 확장된다.

✅ 액션 아이템

~/.hermes/SOUL.md에 에이전트의 personality, tone, communication style, hard limits를 정의해 identity layer를 먼저 고정한다.
MEMORY.md, USER.md, state.db의 역할을 구분해 핵심 정보는 Tier 1에, 과거 대화 탐색은 SQLite session search에 맡기는 운영 원칙을 세운다.
반복 작업이나 오류 해결 절차가 생기면 skill_manage를 통해 SKILL.md로 저장하고, 필요한 경우 patch 중심으로 갱신한다.
designer, programmer, researcher처럼 목적이 다른 agent는 Hermes profiles로 분리하고 각각 별도 SOUL.md, skills, Telegram bot을 구성한다.

❓ 열린 질문

에이전트가 자동 생성한 skill이 실제로 더 나은 절차인지 판단하기 위해 어떤 evaluation dataset과 rubric을 우선 설계해야 하는가?
Curator가 skill을 archive하거나 consolidate할 때, 사용자가 중요하게 여기는 수동 customization을 어떻게 더 안정적으로 보호할 수 있는가?
여러 profile을 24시간 운영할 경우, Telegram bot, cron job, memory provider 간의 충돌이나 중복 작업을 어떤 기준으로 관리해야 하는가?