Skip to main content

Hermes + Honcho หลายเครื่อง สมองเดียว - ออกแบบ Architecture สำหรับ Homelab

· 7 min read
Kongvut Sangkla
Kongvut Sangkla
Author

สารบัญ

ผมมี ThinkPad T14 เป็นเครื่องหลัก รัน Hermes Agent คุยผ่าน Telegram ทุกวัน จน Honcho memory เริ่มมีข้อมูลเยอะขึ้นเรื่อย ๆ — AI จำผมได้จริง ๆ ไม่ใช่แค่จำ facts แต่เข้าใจ context

แล้ววันหนึ่งก็คิดขึ้นได้: ผมมี X13 อีกเครื่อง มี server Proxmox ใน homelab อีกตัว ทำไมไม่ให้ทุกเครื่องมี AI assistant ของตัวเองบ้าง?

TL;DR​

ติดตั้ง Hermes Agent หลายเครื่องใน homelab แล้วให้ทุกตัวแชร์ memory ผ่าน Honcho Server ตัวเดียวกัน แต่ละตัวมี personality ต่างกันผ่าน SOUL.md — ไม่ต้อง sync memory ด้วยตนเอง AI จำผู้ใช้ได้ไม่ว่าจะคุยจากเครื่องไหน

ปัญหาที่เจอ​

ถ้าติดตั้ง Hermes ทุกเครื่องแยกกัน แต่ละตัวก็จะจำอะไรไม่ได้ - เหมือนเริ่มใหม่ทุกครั้ง ต้องมาสอนใหม่ บอกใหม่ ว่าชอบอะไร ทำงานยังไง

คำตอบคือ Honcho หนึ่งตัว แชร์กันทุกเครื่อง

ออกแบบ Architecture​

จากที่อ่าน Hermes docs มาทั้งหมด ผมสรุป architecture ได้แบบนี้:

ทุกเครื่องเชื่อม Honcho เดียวกัน - แชร์ memory, peer card, conclusions เหมือนกันหมด แต่ละตัวมี personality ต่างกัน

แชร์ Files ยังไง​

สิ่งที่ต้อง copy ข้ามเครื่องมีแค่ 6 อย่าง:

Fileแชร์ได้?วิธี syncหมายเหตุ
SOUL.mdแต่ละตัวต่างกันcopy/manualpersonality ของแต่ละตัว
honcho.jsonเหมือนกัน ยกเว้น aiPeercopybaseUrl ชี้ไป Honcho server เดียวกัน ทุกเครื่อง
config.yamlเหมือนกันcopymodel, provider, settings
.envคล้ายกันcopy + แก้บางค่าAPI keys, bot tokens
skills/แชร์ได้gitreusable workflows
cron/แต่ละตัวต่างกันmanualscheduled tasks ต่างกัน

Note: MEMORY.md ไม่ต้อง sync - Honcho ทำหน้าที่แทน memory ทั้งหมด ข้อมูลอยู่ที่ server กลาง ไม่ใช่ที่เครื่อง

honcho.json - Config หลัก​

ทุกเครื่องใช้ config เดียวกัน แค่เปลี่ยน aiPeer:

{
  "baseUrl": "http://10.0.0.136:8000",
  "hosts": {
    "hermes": {
      "enabled": true,
      "peerName": "kongvut",
      "aiPeer": "nanako",
      "workspace": "hermes",
      "recallMode": "hybrid",
      "writeFrequency": "async",
      "saveMessages": true,
      "dialecticDepth": 2,
      "dialecticReasoningLevel": "low"
    }
  }
}

Note: aiPeer เปลี่ยนตามเครื่อง — nanako, kuma, mako — แต่ peerName (ผู้ใช้) เหมือนกันทุกเครื่อง

Network & Security​

Honcho รันที่ 10.0.0.136:8000 เป็น private network ภายใน homelab ไม่ expose ออก internet โดยตรง

  • ภายใน LAN — ทุกเครื่องต่อ Honcho ตรงผ่าน internal IP
  • จากภายนอก — ต้องต่อ VPN เข้า homelab ก่อน ถึงจะคุยกับ API Server (kuma) ได้
  • ไม่มี auth token ใน honcho.json — ต้องอาศัย network isolation เป็นหลัก ถ้าอยากเพิ่มความปลอดภัยอีกชั้น ให้ใส่ reverse proxy + basic auth หรือ WireGuard ข้างหน้า

สิ่งที่ไม่ควรทำ: เปิด Honcho port 8000 ออก public internet โดยไม่มี authentication

Naming Convention - ตั้งชื่อให้น่ารัก​

ผมเชื่อว่าถ้าใช้ AI ทุกวัน ชื่อควรน่ารัก จำง่าย ไม่ใช่ชื่อ technical เช่น "agent-01", "bot-backend"

เครื่องชื่อRolePlatform
T14nanakoเลขาส่วนตัวTelegram DM
pve01kumaServer guardianAPI Server
X13makoNotebook สำรองTelegram DM

Note: ชื่อเป็นแค่ convention - Hermes ไม่ได้บังคับว่าต้องตั้งชื่ออะไร แต่การตั้งชื่อช่วยให้แยกแยะง่ายว่าคุยกับตัวไหน โดยเฉพาะตอนที่แต่ละตัวมี personality ต่างกัน

SOUL.md ตัวอย่าง​

SOUL.md คือไฟล์ที่กำหนด personality ของแต่ละตัว ตัวอย่างของ nanako:

# nanako

## Personality
- ชอบช่วยจัดการตารางเวลาและ reminder
- ตอบสั้น ๆ กระชับ ไม่ยาวเกินไป
- เรียกผู้ใช้ว่า "พี่" เสมอ

## Context
- ใช้ภาษาไทยเป็นหลัก ผสมภาษาอังกฤษได้ตามธรรมชาติ
- รู้ว่าผู้ใช้ทำงานเป็น developer และชอบ automate ทุกอย่าง
- จำได้ว่าผู้ใช้ชอบดื่มกาแฟตอนเช้า และไม่ชอบ meeting ก่อน 10 โมง

## Skills
- /reminder - ตั้งเตือน
- /summarize - สรุป conversation ย้อนหลัง

kuma กับ mako ก็มี SOUL.md ของตัวเอง แต่เน้นไปทาง server monitoring และ backup tasks ตามลักษณะงาน

Model Routing - ส่งไปไหนดี​

แต่ละเครื่องไม่จำเป็นต้องใช้ model เดียวกัน เลือกตาม role และความยืดหยุ่นที่ต้องการ:

nanako (T14) → MiMo API ตรง เครื่องหลักที่ใช้ทุกวัน ตั้งค่าง่าย ไม่ต้องผ่านอะไรเพิ่ม ทำให้ latency ต่ำที่สุด

kuma (pve01) → LiteLLM Gateway → MiMo / DGX Spark เป็น server ใน homelab ต้องการความยืดหยุ่นสูงสุด — ถ้าในอนาคตอยากสลับ model หรือเพิ่ม DGX Spark ก็แค่เปลี่ยนที่ Gateway ไม่ต้องไปแก้ config ทุกเครื่อง

mako (X13) → MiMo API ตรง notebook สำรอง ใช้นาน ๆ ที ตั้งค่าแบบเดียวกับ nanako เพื่อ consistency

Note: LiteLLM Gateway ทำหน้าที่เป็น proxy — ถ้าในอนาคตมี DGX Spark หรือ model ใหม่ ก็แค่เปลี่ยนที่ Gateway ไม่ต้องแก้ทุกเครื่อง

Platform Strategy - แต่ละตัวคุยยังไง​

ไม่จำเป็นต้องทุกเครื่องมี Telegram bot แยก - แต่ละตัวมี platform ที่เหมาะกับ role ของตัวเอง:

nanako (T14) - Telegram DM คุยทุกวัน เป็นเลขาส่วนตัว จัดการชีวิต ตอบเรื่องทั่วไป

kuma (pve01) - API Server ไม่ต้องมี Telegram bot - รับคำสั่งผ่าน API เท่านั้น nanako จะสั่งงานผ่าน API เพราะเป็นระบบภายใน ถ้าอยู่ข้างนอกก็ต่อ VPN เข้ามา

mako (X13) - Telegram DM มี Telegram เหมือนกัน แต่เป็น notebook สำรอง - ใช้ตอน T14 ไม่อยู่ หรือต้องการ context แยก

Concurrent Access - คุยพร้อมกันได้ไหม​

ถ้า nanako กับ mako ตอบพร้อมกัน Honcho จะจัดการให้อยู่ดี — แต่ละตัวมี aiPeer ต่างกัน ดังนั้น message thread แยกกันอยู่แล้ว สิ่งที่แชร์กันคือ memory context ของ user (kongvut) ไม่ใช่ conversation state ของแต่ละตัว

อย่างไรก็ตาม ถ้าอยากให้สมูทที่สุด ควร:

  • ตั้ง writeFrequency: "async" ใน honcho.json ให้ทุกตัว (ค่าเริ่มต้นไม่ต้องรอ write จบก่อนตอบ)
  • หลีกเลี่ยงการสั่งงาน heavy ผ่านหลายตัวพร้อมกัน (เช่น ให้ kuma รัน backup ขณะที่ nanako กำลัง summarize ข้อมูลเดียวกัน)

สรุป​

การออกแบบ Hermes หลายเครื่องไม่ใช่เรื่องยาก - ถ้าเข้าใจว่า Honcho ทำหน้าที่เป็น สมองส่วนกลาง สิ่งที่ต้องทำมีแค่:

  1. ติดตั้ง Hermes ทุกเครื่อง
  2. sync honcho.json, config.yaml, .env ไปทุกเครื่อง (ใช้ rsync, git หรือ ansible ตามถนัด)
  3. สร้าง SOUL.md ของแต่ละตัว
  4. สร้าง Peer Card ใน Honcho สำหรับแต่ละตัว
  5. เริ่มคุย — memory แชร์กันอัตโนมัติ

ไม่ต้องตั้งค่าอะไรมาก ไม่ต้องมี central coordinator ไม่ต้อง sync memory ด้วยตนเอง — Honcho จัดการให้หมด

สิ่งที่ได้กลับมาคือ AI assistant ที่จำผมได้จริง ๆ ไม่ว่าจะคุยจากเครื่องไหน

References​

aihermeshonchohomelabarchitectureagent
แชร์บทความ
☕

เนื้อหานี้มีประโยชน์ไหม? ช่วยสนับสนุนค่ากาแฟให้ผู้เขียนสักแก้ว

Buy Me a Coffee
Loading...