Hermes Agent 101 — Persistent + Self-Improving Agent จริงจัง

Youssef Hosni — คู่มือครบเรื่อง Hermes Agent จาก Nous Research: persistent agent framework ที่มี identity (SOUL.md), memory 3 level, self-evolving skills, Curator, GEPA offline optimization, profiles, Telegram integration, cron scheduling. ต่างจาก session-based assistant ที่รีเซ็ตทุกครั้ง — Hermes เก็บ context สะสมข้าม session

1. ปัญหา: Session-Based Agent

AI agent ส่วนใหญ่ยังเป็น short-lived session — reason, call tool, write code, summarize ได้ แต่เสีย operational contextที่ทำให้ session ก่อนเป็นประโยชน์

Real workflow ขึ้นกับ: project convention, repeated command, debugging pattern, source preference, review habit, long-running context. Session-based = ต้องอธิบาย repo structure, tool preference, project rule, output expectation ใหม่ทุก session

Hermes Agent (Nous Research) = open-source agent framework ที่ให้ agent มี identity + memory + reusable skills + profiles + tools + messaging interface + scheduled jobs. State ตรวจสอบได้ผ่านไฟล์: SOUL.md, memory, skills, sessions, config, cron

2. Hermes คืออะไร

Long-running agent env — user interact + agent ใช้ tool + system เก็บ context เพื่อ reuse. Design centered รอบ 4 capability:

1. Persistent memory — เก็บข้อมูล user, env, project convention, previous interaction
2. Self-evolving skills — reusable procedure สำหรับ specific task type
3. Tool use + execution — interact local env, run command, work with files, external system
4. Profiles — isolated agent config (แต่ละ profile มี identity + memory + skills + sessions + tools ของตัวเอง)

Combine declarative config (user set) + adaptive behavior (evolve through use). Hermes ≠ model wrapper — add execution layer: memory + skills + tools + sessions + jobs + isolated profiles

4. Core Mental Model: 4 Layer

Identity (SOUL.md) → role + tone + priority + constraint · Memory → what agent knows · Skills → how agent performs task · Tools → where agent acts

Same model behave ต่างกันได้ตาม 4 layer นี้ — programmer profile, researcher profile, designer profile ใช้ model provider เดียวกันแต่ต่างกันเพราะ layer ต่างกัน

6. SOUL.md — Identity Layer

File ที่ describe agent behavior — role, tone, priority, communication style, operating constraint. โหลดก่อน agent เริ่ม = behavioral frame

Memory = agent รู้อะไร · Skills = agent ทำ task ยังไง · SOUL.md = agent approach งานยังไง

# SOUL.md

You are a pragmatic staff engineer.
You read existing code before writing new code.
You prefer small, safe changes over large rewrites.
You run relevant tests before saying a task is complete.
You explain trade-offs clearly and avoid unnecessary abstraction.
When debugging, first reproduce the issue, then inspect the smallest
relevant part of the codebase, then propose and verify a fix.

4 กฏเขียน SOUL.md:

1. Define role ชัด — “helpful assistant” generic ไป · “backend engineering assistant for Python services” ใช้งานได้
2. Define priority — coding: correctness + minimal change + tests · research: source quality + freshness + citation
3. Define constraint — “ห้าม change ใหญ่โดยไม่อธิบาย, ห้าม fabricate citation, ห้ามเก็บ secret ใน memory, ห้ามบอกเสร็จก่อน verify”
4. Keep maintainable — SOUL.md = stable behavioral rule ข้ามหลาย task — project fact ไป memory, procedure ไป skill

7. Memory — 3 Level

Level 1: Compact memory — โหลดเข้า context เสมอ. Stable + important + reusable. เช่น “repo ใช้ pnpm, test ด้วย pnpm test, user ชอบคำอธิบาย technical สั้น ๆ”. เจตนาให้เล็ก — ไม่งั้น prompt noise + แพง

Level 2: Searchable session history — เก็บบทสนทนาเก่า search ได้. ไม่ต้อง inject ทุก prompt — recover context เมื่อต้องการ

Level 3: External memory — external provider สำหรับ deeper/structured store

Good memory entry: stable + specific + reusable

This repository uses pnpm for package management. Use pnpm test to run the main test suite.

Weak entries (avoid):

The user was debugging something today.
The current error might be caused by the database.

Vague หรือ uncertain — เก็บ assumption = agent worse ตามเวลา

Memory consolidation: รวม note เล็ก ๆ ที่เกี่ยวกันเป็น note เดียว. ห้ามเก็บ secret (API key, password, token) ใน memory

8. Self-Evolving Skills

Memory เก็บ fact · Skill เก็บ procedure/workflow. Skill = Markdown file + metadata + instruction

---
name: debug-fastapi-tests
description: Use when debugging failing FastAPI backend tests.
version: 1.0.0
author: agent
---
## When to use
Use this skill when a backend test fails in the FastAPI service.
## Procedure
1. Run the focused failing test first.
2. Read the full stack trace before editing code.
3. Identify whether the failure is caused by route logic, dependency injection,
   database state, or test setup.
4. Apply the smallest safe fix.
5. Re-run the focused test.
6. Run the broader backend test command before reporting completion.
## Pitfalls
- Do not edit generated files.
- Do not skip the database fixture setup.
- Do not assume the failing test is wrong before checking the implementation.
## Verification
The focused test passes, and the broader backend test command completes successfully.

เมื่อ Hermes ทำ workflow ที่ไม่ trivial + เจอ correct path หลัง error → turn เป็น reusable skill. รอบถัดไปโหลด skill แทนเริ่มจาก 0

Progressive skill loading — agent เห็นแค่ name + description ก่อน โหลดเนื้อหาเต็มเฉพาะที่ relevant. Skill library โตได้โดยไม่ทำ context บวม

Self-evolving loop: agent attempt → error/correction → discover correct process → store as skill → future task activate skill เร็วขึ้น

เงื่อนไข skill ที่ดี: workflow น่า repeat, step actionable, จับสิ่งที่มากกว่า memory note ธรรมดา, มี verification, ไม่ encode assumption ชั่วคราวเป็น permanent rule

9. Curator — Skill Library Maintenance

Self-evolving skill = library โตเร็ว. Curator = maintenance layer:

• Recently used → active
• Not used ระยะหนึ่ง → stale
• Unused ยาวขึ้น → archived (ไม่ลบ — restore ได้)
• Overlap → consolidate
• ใกล้ใช้ได้แต่ต้องปรับ → patch

Pinning — protect critical skill ที่ rare แต่สำคัญ (deployment rollback, security review). Snapshot + rollback — เก็บ state ก่อน maintenance pass. Reversibility = safety property

Persistence ต้อง include cleanup. Memory + skills + session history มีค่าเพราะ accumulate experience — แต่ accumulation without maintenance = clutter

10. GEPA — Offline Self-Evolution

Runtime learning (skill creation ระหว่างใช้งาน) มี limit — agent อาจ overgeneralize, ถือ temporary workaround เป็น rule, ปรับ skill จาก evidence ไม่ครบ

GEPA (Genetic-Pareto Prompt Evolution) = offline optimization. analyze execution trace + evaluate candidate change + propose improved version ของ skill/prompt/tool description

ไม่ใช่ fine-tune weight — ทำงานบน text-based part (prompt, instruction, skill, tool description)

Workflow:

1. เลือก skill/prompt/tool description ที่จะ optimize
2. Build evaluation set จาก synthetic case, real session trace, curated example
3. รัน current version + collect trace
4. Analyze failure + weak output
5. Generate candidate variant
6. Evaluate variant กับ criteria เดียวกัน
7. Keep best-performing ถ้าผ่าน constraint
8. Submit หรือ review ก่อน active

Key: traces รวม model reasoning + tool call + tool output + error + intermediate result + final answer. Optimizer เห็นว่าระบบไปยังไง ไม่ใช่แค่ success/fail

GEPA เหมาะกับปัญหา repeat + measurable. ไม่เหมาะ vague preference หรือ task ที่ไม่มี clear “better”

11. Setup

Install

pip install hermes-agent

หรือ git-based (latest):

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Reload shell:

source ~/.bashrc

Verify:

hermes --help

Setup wizard

hermes setup

หรือ config model โดยตรง:

hermes model

First chat

hermes

Test prompt:

Hello. Briefly confirm that you are working and tell me what tools are available.

Diagnostic:

hermes doctor

Setup flow: Install → Configure provider → Start terminal chat → Simple task → Check diagnostics → เพิ่ม profile/messaging/skill/automation ทีละส่วน

12. ~/.hermes/ Folder

~/.hermes/
├── config.yaml     # non-secret config
├── .env            # secrets + env vars
├── SOUL.md         # identity
├── memories/       # persistent memory
├── skills/         # reusable procedure
├── sessions/       # conversation history
├── cron/           # scheduled jobs
├── logs/           # debug
├── cache/          # runtime cache
├── plugins/        # extensions
└── state database files

กฏ: config.yaml = non-secret · .env = secret. อย่าโพสต์ .env, screenshot, blog

Profile structure — แต่ละ profile = agent home แยก:

profiles/
├── coder/
│   ├── config.yaml
│   ├── .env
│   ├── SOUL.md
│   ├── memories/
│   ├── skills/
│   └── sessions/
│
└── researcher/
    ├── config.yaml
    ├── .env
    ├── SOUL.md
    ├── memories/
    ├── skills/
    └── sessions/

13. First Useful Agent

เริ่มจาก 1 focused profile — developer-assistant. Software work มี clear context + repeatable workflow + verifiable output + defined constraint

Create profile:

hermes profile create developer-assistant --description "Helps with coding, debugging, tests, and repository documentation."

Clone base config:

hermes profile create developer-assistant --clone --description "Helps with coding, debugging, tests, and repository documentation."

Configure SOUL.md (ตัวอย่างจริง):

# SOUL.md

You are a pragmatic software engineering assistant.
Your priorities are correctness, small safe changes, and clear verification.
When working with a codebase:
- Read existing code before proposing changes.
- Prefer focused edits over broad rewrites.
- Identify the relevant test command before editing.
- Run or recommend verification steps before marking work complete.
- Explain trade-offs briefly and avoid unnecessary abstraction.

When debugging:
- Reproduce the issue when possible.
- Read the full error message and stack trace.
- Inspect the smallest relevant part of the codebase first.
- Avoid assuming the test is wrong before checking the implementation.

Safety constraints:
- Do not store secrets in memory.
- Do not modify generated files unless explicitly requested.
- Do not claim a fix is verified unless tests or checks were actually run.

First useful memory (developer):

The user prefers small, targeted code changes over large rewrites.
The user prefers technical explanations without promotional phrasing.
When working on repositories, identify the test command before changing code.
Do not store API keys, tokens, or secrets as memory.

Repo-specific memory (หลัง inspect):

This project uses pnpm for package management.
The backend API routes are under src/routes/.
Use pnpm test:api for backend API tests.
Generated files under dist/ should not be edited manually.

First task — specific ไม่ open-ended:

Inspect this repository and identify how to run the main test suite.
Do not modify files. Summarize the project structure and the commands
you found.

หลัง task — ระบุชัดว่าอะไรควรเก็บ:

Save the confirmed test command and relevant project conventions as memory.
Do not save temporary observations or guesses.

สรุปภาพใหญ่

Persistence pattern ของ Hermes:

• SOUL.md → นิยาม behavior
• Memory → เก็บ fact ที่มีประโยชน์
• Skills → เก็บ reusable procedure
• Curator → maintain skill library
• GEPA → offline evaluate + improve selected skill

Runtime learning capture experience · Curation ทำให้ manageable · Offline optimization refine ส่วนที่ต้อง systematic evaluation

Hermes ไม่ทำ agent ถูก automatic — แต่ให้ dev มี inspectable + iterative path ดีกว่า rewrite prompt ซ้ำ ๆ หรือพึ่ง model ใหญ่กว่าอย่างเดียว

แหล่งที่มา: “Hermes Agent 101: A Practical Guide to Persistent and Self-Improving Agents” โดย Youssef Hosni ตีพิมพ์ 6 ก.ค. 2026 บน Level Up Coding · อ่านต้นฉบับ · GitHub: github.com/nousresearch/hermes-agent

หมายเหตุ: สรุปนี้ครอบคลุม section 1-13 (concept + setup + first profile). ต้นฉบับยาว 27,000 คำ ยังมี section 14-19 (multiple profiles, Telegram integration, coding workflow, research workflow, cron scheduling, best practices) ไม่ได้แปลย่อในโพสต์นี้ — เปิดต้นฉบับอ่านต่อได้