By krit.junsree@gmail.com 
Kristopher Dunham รีวิว Hermes Desktop ฉบับ Nous Research อย่างเป็นทางการ — feature ที่แท้จริงไม่ได้อยู่ที่ chat แต่อยู่ที่oversight (การได้ดูว่า agent กำลังทำอะไร) และ profile (แยก writing / code / client ไม่ให้ปนกัน) พร้อมข้อเตือนสำคัญเรื่อง sandbox ที่ต้องรู้ก่อนติดตั้ง
Desktop app สำหรับ autonomous agent เป็นสิ่งที่แปลก
App ส่วนใหญ่ออกแบบมาสำหรับเครื่องมือที่เรา operate — คลิก แล้ว app ตอบ แล้วคลิกอีก แต่ Hermes ไม่ได้ทำงานแบบนั้น มันเป็น agent ที่วาง plan, รัน command และทำงานบน server ต่อไม่ว่าเราจะดูอยู่หรือไม่ แล้ว window มีไว้เพื่ออะไรในเมื่อสิ่งที่อยู่หลังจอไม่ต้องการให้เราเฝ้ามอง?
คำถามนี้คือส่วนที่น่าสนใจที่สุดของ Hermes Desktop — native app ที่ Nous Research เพิ่ง push เข้าสู่ public preview บน macOS, Windows และ Linux ล่าสุดมันเริ่มโผล่ในวงโคจรของ NVIDIA ด้วย — RTX AI Garage blog ของ NVIDIA เอง feature การรัน Hermes Agent บน RTX PC และ DGX Spark workstation ซึ่งบอกได้ว่าใครคือกลุ่มที่ Nous อยากดึงความสนใจ
สรุปสั้น ๆ คือ Hermes เคยเป็น terminal daemon กับ messaging bot กองหนึ่ง ตอนนี้มันมีหน้าตาแล้ว เวอร์ชันยาวน่าสนใจกว่า และเริ่มต้นที่ design decision ข้อหนึ่ง
Agent ตัวเดียว มีหลายหน้า
Hermes Desktop ไม่ใช่ program แยกที่คุยกับ agent มันคือagent ตัวเดียวกัน สวม window อยู่
มัน install runtime มาตรฐานลงใน layout ~/.hermes เดียวกัน และ share ทุกอย่างกับ CLI และ gateway — config เดียวกัน, API key เดียวกัน, session, skill และ memory เดียวกัน Nous เรียกมันว่า “another surface over one agent, not a fork” ซึ่งเป็นคำที่ตรงกับความเป็นจริง เริ่ม task ใน desktop, close window, งานก็รันต่อไปตราบใดที่ backend ยังอยู่ กลับมาเปิด conversation เดิมจาก Telegram หรือ terminal ทีหลัง ทุกอย่างยังอยู่ครบ ไม่มีการ copy ข้อมูลระหว่าง surface — มี brain เดียว และ window เป็นแค่วิธีมองมัน ถ้าเคย setup hermes ผ่าน terminal ทุกอย่างที่ set ไว้พร้อมใช้ในนี้ทันที
สิ่งที่เรากำลัง install จึงไม่ใช่ control panel ที่ own process แต่เป็นviewport เข้าสู่บางอย่างที่กำลังรันอยู่แล้ว
งานจริงของ Window คือ Oversight
หน้าต่าง chat stream ทั้ง response และ live tool activity ทำให้เราเห็น agent วาง plan, ยิง terminal command และอ่านผลลัพธ์ตอนที่มันเกิดขึ้น แถบด้านขวา render หน้าเว็บ, ไฟล์ และ tool output ไว้ให้เห็นข้าง ๆ ระหว่างที่คุยกัน มี file browser ให้ตาม agent อ่าน/แก้ working directory มี drag-and-drop สำหรับแนบไฟล์, voice in/out และ model picker สำหรับสลับ model กลาง session
ประเด็นสำคัญที่ต้องพูดตรง ๆ คือประโยชน์ของ GUI ในบริบทนี้ไม่ใช่ความสะดวก แต่คือ oversight
เมื่อ agent รัน shell command และเขียนไฟล์เองได้ การเห็น tool call stream ต่อหน้าคือความต่างระหว่าง “เชื่อใจ” กับ “กระโดดลงเหว” Terminal ก็ให้ข้อมูลนี้ในแบบของมัน แต่ preview rail และ file browser ทำให้คนที่ไม่ได้อ่าน scrollback เป็นอาชีพเข้าใจได้
Profile คือ Feature ที่ทำให้คุ้มค่าติดตั้ง
นี่คือส่วนที่ coverage ส่วนใหญ่ข้าม และเป็นสิ่งที่มีประโยชน์ที่สุดในแอป
Profile คือ Hermes environment ที่ isolated จากกัน — มี config, skill และ session ของตัวเอง แยกจากทุก profile อื่น Desktop นำเสนอ profile เป็น pane ที่สลับได้ ฟังเผิน ๆ อาจดูแห้ง แต่พอ map เข้ากับวิธีทำงานจริง ๆ มันคือเหตุผลที่คุ้มค่าให้เวลากับแอปนี้:
- Profile หนึ่งสำหรับ writing และ research พร้อม skill และ memory ที่ agent เรียนไว้เฉพาะสำหรับงานประเภทนั้น
- Profile ที่สองสำหรับ coding ที่ชี้ไปยัง sandboxed backend และใช้ model ที่ต่างออกไป
- Profile ที่สามสำหรับ client troubleshooting ที่มี credential และ messaging channel ของตัวเอง
Profile เหล่านี้ไม่ปนกัน Agent ที่รู้จัก Medium draft ของเราจะไม่มี DNS record ของ client อยู่ใน working memory ซึ่งเป็นสิ่งที่เราต้องการพอดี
Agent tool ส่วนใหญ่ให้ context ก้อนเดียวใหญ่ ๆ ไม่แยกอะไรกับอะไร แล้วก็ปล่อยให้มันเน่าไป Profile คือคำตอบของปัญหานั้น — และการที่มันอยู่หลัง switch แทนที่จะซ่อนใน config file คือสิ่งที่ทำให้คนใช้จริง
Caveat ที่ต้องพูดออกมา: profile แยก state ไม่ได้แยก filesystem access มัน keep record ของ client ให้อยู่ห่างจาก memory ของ writing agent จริง แต่ไม่ได้หยุด agent จากการเอื้อมข้าม disk งานนั้นเป็นของ backend ซึ่งเป็นสิ่งถัดไปที่ต้องเข้าใจ
ชี้ agent ไปยัง Folder เฉพาะ
Launch แอปโดยชี้ไปยัง project directory เฉพาะ file browser และ chat จะเริ่มจากที่นั่น:
hermes desktop --cwd ~/projects/my-appสำหรับงาน coding, local document folder หรือ research directory — นี่คือความต่างระหว่าง agent ที่ปล่อยหลุดใน home directory กับ agent ที่ถูก scope ให้อยู่กับสิ่งที่กำลังทำ ตั้งค่า HERMES_DESKTOP_CWD ก็ได้ถ้าไม่อยากพิมพ์ flag ทุกครั้ง
Settings ที่ไม่มี YAML
เดิมทีการ config Hermes ต้องแก้ config file ด้วยมือ แอปเปิดเผย provider, model selection, credential, toolset, MCP server, gateway setting และ session ผ่าน UI จริง ๆ
นี่คือสิ่งที่ทำให้มันกลายจาก tool สำหรับ power user ไปเป็นสิ่งที่คนทั่วไปเก็บไว้ใช้ต่อ agent plumbing น่าสนใจเสมอ แต่ config file คือกำแพงที่คนเด้งกลับ การ browse และ toggle MCP server ใน panel โดยไม่ต้อง hand-edit JSON คือสิ่งเล็ก ๆ ที่ตัดสินว่าคน stick กับมันเลย hour แรกไปหรือไม่
ความ flexible เรื่อง provider ก็ตามมาด้วย — Nous Portal, OpenRouter, OpenAI, endpoint ของเราเอง รวมถึง Ollama หรือ LM Studio local ถ้าอยากให้ model รันบน hardware ของเราเอง
ที่ที่มันรันจริง (อ่านให้จบก่อนคลิก install)
Window รันบนเครื่องเรา แต่ที่ที่ agent execute commandเป็น backend choice แยก และสำคัญกว่าอะไรบนหน้าจอทั้งหมด
Desktop page highlight 5 backend และ Hermes config doc รวมทั้งหมด 6 (Daytona เป็นตัวเพิ่มเติม):
- Local: command รันตรงบน machine ด้วย filesystem access เท่ากับ user account ของเรา ไม่มี isolation
- Docker: container hardening และ namespace isolation ตัว default ที่ sane สำหรับงาน unattended
- SSH: execute บน remote box ที่เราควบคุม
- Modal / Daytona: serverless burst หรือ persistent cloud workspace
- Singularity: rootless HPC-style image
Local โอเคสำหรับ read-only poking แต่อันตรายมากสำหรับอะไรที่ left running Agent ที่มี raw shell access ทำอะไรกับ home directory ได้เท่ากับ rm ที่ประมาท ต่างกันแค่มันตัดสินใจทำเอง
UI ไม่ใช่ sandbox — backend คือ สลับไป Docker หรือ remote backend ก่อนปล่อยให้ self-running agent ทำงานโดยที่เราไม่อยู่ในห้อง
Default ที่ sane โดยแมป profile ข้างบนเข้ากับ backend:
- Writing และ research: local โอเค เพราะส่วนใหญ่แค่อ่านกับ draft
- Coding: Docker เพื่อให้ command ที่ generated รันใน container ไม่ใช่ใน home directory
- Client work: key ของตัวเอง, working directory ของตัวเอง, ไม่ share memory
- อะไรที่ unattended: Docker หรือ remote box ไม่ใช่ raw local
Set ครั้งเดียวต่อ profile แล้วก็ไม่ต้องคิดถึงอีก
รายละเอียดที่ทำให้สับสน: มี Hermes Desktop 2 แอป
ตอนนี้มี 2 แอปที่ใช้ชื่อ “Hermes Desktop”
แอปแรกคือNous Research อย่างเป็นทางการตามที่อธิบายด้านบน และเป็นตัวที่ demo ใน GTC ส่วนอีกแอปคือ fathah/hermes-desktop — Electron companion ที่ community build ขึ้น กำลัง move เร็ว และในบาง front ก็ล้ำหน้ากว่า มัน add persona editor สำหรับ SOUL.md ของ agent, Kanban board, Office surface, SSH-tunnel control สำหรับ remote backend, provider ประมาณสิบกว่าตัว และ messaging gateway 16 ตัว ใช้ install script และ directory ~/.hermes เดียวกันข้างล่าง
ถ้าต้องการ path ที่ปลอดภัยสุดและมี official support ให้เอา Nous app ถ้าอยากได้ feature set กว้างสุดและไม่รังเกียจ rough edge companion ก็คุ้มค่าลอง โดยมี 2 caveat: Windows installer ของมันไม่ได้ code-signed จึง SmartScreen จะเตือน และ release บ่อยพอที่บางอย่างที่พึ่งใช้ในเวอร์ชันก่อนอาจย้ายในเวอร์ชันใหม่ การรู้ว่ามี 2 แอปช่วยประหยัดเวลาไม่ให้เสียครึ่งบ่ายไปกับการงงว่าทำไม repo 2 ตัวชื่อ “Hermes Desktop” ถึงอธิบาย feature ไม่เหมือนกัน
ข้อควรรู้ที่ตรงไปตรงมา
เป็น public preview จึงต้องเผื่อ rough edge “Linux desktop” ยังต้อง install ผ่าน terminal ซึ่งเป็นเรื่องแปลกที่ต้องยอมรับสำหรับ desktop app Prebuilt installer แนบกับ release ด้วยมือ จึงไม่ได้มีให้ครบทุก build ล่าสุด path install-with-Hermes เป็น path ที่ reliable กว่า ขอบเขตของสิ่งที่ Hermes ทำได้ทำให้มี learning curve จริง — ไม่ใช่ของเล่น 5 นาทีที่เข้าใจได้ตั้งแต่ launch แรก
และมี tension ที่ลึกกว่านั้น Hermes ถูกสร้างมาเพื่อ run โดยไม่ต้องมีเราเฝ้ามอง Window ที่ polished จึงขัดกับ thesis ของ product ตัวเอง แอปมีที่ยืนตอน setup, inspection และสร้าง trust แล้วก็ควรก้าวออกจากทาง Value ยังคงอยู่บน server ไม่ใช่บน chrome ของหน้าต่าง
ใครควรลองตอนนี้
ถ้ารัน CLI agent อยู่แล้ว: install วันนี้เลย เราไม่เสียอะไรจาก terminal แต่ได้ oversight, profile, file browser และ settings ที่ไม่ต้อง hand-edit เพิ่มมา มันวางทับบน workflow ที่มีอยู่แล้ว
ถ้าไม่ได้เป็นสาย technical: มันยังไม่ใช่ download-and-forget Window เอา friction ออกไปเยอะ แต่ concept ที่อยู่ใต้ (provider, model, tool, profile, gateway, sandbox backend) ยังต้องการความใส่ใจ เราจะเรียนรู้ได้ แค่มี config file น้อยลงที่ขวางทาง
ถ้าทำงานกับข้อมูล client: สิ่งแรกที่ต้อง test ไม่ใช่ model แต่คือ profile separation กับ sandbox ทำ 2 อย่างนี้ให้ถูกก่อน agent จะแตะอะไรที่ไม่ใช่ของเรา
วิธีลองแบบไม่ overthink
Install ในขั้นเดียว — บน Linux, macOS หรือ WSL2 เพิ่ม desktop flag ลง installer มาตรฐาน:
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash -s -- --include-desktopถ้ามี CLI อยู่แล้ว แค่รัน hermes desktop มันจะ build และ launch กับ setup เดิม Prebuilt .dmg, .exe และ .AppImage โผล่บนหน้า GitHub release เมื่อมี build ใหม่ publish
- Run first-run setup — walk through การเลือก provider, model และพาไปยัง message แรกภายในไม่กี่วินาที Nous Portal มี free tier ให้เริ่ม และการ sign-in ครั้งเดียวครอบคลุมทั้ง web search, image generation, text-to-speech และ browser
- สร้าง profile ต่อ job — อย่ากอง context ทุกอย่างไว้ที่เดียว spin writing profile, coding profile, client profile แล้ว switch จาก pane
- Scope ให้ folder แล้วดูมันทำงาน — launch ด้วย
hermes desktop --cwd <path>, ให้ real task อันหนึ่ง แล้วใช้ preview rail กับ file browser ตาม tool call ทุกครั้ง Inspect ก่อน trust ตั้ง backend เป็น Docker ก่อนปล่อยให้รันอะไรแบบ unattended - แล้ว close window ได้ — wire gateway ไป Telegram, ตั้ง read-only cron หนึ่งอัน (“summarize staging log 7am, message ผมถ้าอะไรพัง”) แล้วเปิด conversation กลับที่ surface ไหนก็ได้ที่ใกล้เรา round trip จาก window ไป phone ไป terminal และกลับมาที่ memory ก้อนเดียวกัน — นั่นคือ pitch ทั้งหมด
Desktop app ไม่ได้เปลี่ยนว่า Hermes เป็นอะไร — เปลี่ยนว่าใครทนใช้มันได้ Terminal daemon ที่มี persistent memory กับ cron schedule จะยังเป็น power-user thing เสมอ แต่ window ที่ให้เราเห็นมันคิด พร้อม profile ที่แยกงานออกจากกัน คือวิธีที่ tool แบบนี้จะเข้าถึงคนที่เหลือได้
ที่มา: Hermes Lived in the Terminal. Now It Has a Desktop Window by Kristopher Dunham — เผยแพร่ 4 มิ.ย. 2026
