DEV Community

Nokka
Nokka

Posted on

oh-my-hermes ทบทวน 1,400 ดาวใน 3 เดือน, ชั้นระบบปฏิบัติการที่เสริม Hermes Agent

oh-my-hermes ทบทวน 1,400 ดาวใน 3 เดือน, ชั้นระบบปฏิบัติการที่เสริม Hermes Agent

โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026

บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก README ฉบับเต็มและเอกสารภายในของโปรเจกต์ (ARCHITECTURE, DIRECTION, CAPABILITIES, WORKFLOWS ฉบับเต็ม 900KB) ที่ผมอ่านจริงทั้งหมด

oh-my-hermes

มีโปรเจกต์หนึ่งบน GitHub ที่โตเร็วผิดปกติ: oh-my-hermes (OMH) โดยนักพัฒนาชาวเกาหลีที่ใช้ชื่อ rlaope เปิดตัวเมื่อมิถุนายน 2026 และครบสามเดือนก็เก็บดาวได้กว่า 1,400 ดวง พร้อม fork 132 ครั้ง และอัปเดตเกือบทุกวัน [1]

สิ่งที่มันทำสรุปสั้นๆ ได้ว่า: มันคือ "ชั้นระบบปฏิบัติการ" ที่ติดตั้งเสริมบน Hermes Agent ตัวสร้างของ Nous Research โดยไม่แก้หรือแทนที่ Hermes (ตัวสร้างของ Nous Research [3]) แต่อย่างใด แต่บทความนี้จะเจาะลึกกว่านั้น เพราะเมื่อผมอ่านเอกสารภายในทั้งหมดแล้ว พบว่าโปรเจกต์นี้มีแนวคิดหลายอย่างที่ฉลาดและต่างจากของคนอื่นจนน่าเล่าเป็นบทเรียนได้

ก่อนอื่น, ทำความเข้าใจศัพท์

  • Hermes Agent: เอเจนต์ AI โอเพนซอร์สของ Nous Research ที่ทำงานผ่านแชตและเครื่องมือต่างๆ คล้าย Claude Code หรือ Codex แต่เป็นโอเพนซอร์สเต็มตัว
  • ชั้นปฏิบัติการ (operating layer): ซอฟต์แวร์ที่ไม่ได้ทำงานแทน AI แต่คอยจัดระเบียบวิธีทำงานของมัน ตั้งแต่แบ่งงาน ส่งต่อ ไปจนถึงตรวจสอบผล
  • Executor: เครื่องมือลงมือเขียนโค้ดจริง เช่น Claude Code หรือ Codex ที่ OMH ส่งงานต่อให้
  • Evidence-bound: หลักการที่ห้ามรายงานว่า "งานเสร็จ" จนกว่าจะมีหลักฐานที่ตรวจสอบได้จริง

ถ้าให้อุปมา: Hermes เหมือนพนักงานเก่งที่รับคำสั่งเป็นภาษาคนแล้วลงมือได้ OMH คือผู้จัดการโปรเจกต์ที่มานั่งข้างๆ เขา คอยจัดคิวงานเป็นเฟส แบ่งงานให้คนเหมาะสม จดบันทึกว่าอะไรทำแล้ว และกันเขาจากการรายงานผลงานที่ยังไม่ได้ตรวจ ผู้จัดการคนนี้ไม่ได้มาแทนพนักงาน และก็ไม่ยอมให้ใครอวดผลงานที่ตรวจไม่ผ่าน

หัวใจของแนวคิด: แยก "ความฉลาด" ออกจาก "การบริหารงาน"

สิ่งแรกที่ทำให้ OMH น่าสนใจคือปรัชญาการออกแบบที่เขียนไว้ชัดเจนในเอกสาร DIRECTION ของโปรเจกต์: ยกคุณภาพขึ้นด้วยการทำสัญญาที่แข็งแรงขึ้น ไม่ใช่ด้วยการซ่อนพฤติกรรมไว้หลัง prompt [2]

แปลเป็นภาษาคน: แทนที่จะเขียนคำสั่งลับให้ AI ทำตัวเก่งขึ้น (วิธีที่เครื่องมือส่วนใหญ่ใช้) OMH เลือกสร้างกลไกที่คาดเดาได้ ตรวจสอบได้ และแยกชิ้นงานชัดเจน ผลคือระบบที่น่าเชื่อถือขึ้นโดยที่ตัวโมเดลเดิมไม่ต้องเปลี่ยน

แนวคิดนี้เห็นได้ชัดที่สุดในสามกลไกหลักของระบบ

1. ส่งงานให้โมเดลที่ใช่ ด้วย Mixture-of-Models Routing

OMH แบ่งงานเป็น 9 หมวด แล้วกำหนด "ห่วงโซ่โมเดล" ให้แต่ละหมวด โดยเลือกโมเดลที่เหมาะกับงานนั้นๆ พร้อมลำดับสำรองเมื่อตัวแรกใช้ไม่ได้ [1]

หมวดงาน โมเดลที่แนะนำตามลำดับ
ultrabrain (คิดหนักสุด) GPT-6 Astra, แล้ว GPT-5.6 Sol
architect (ออกแบบระบบ) Claude Fable 5.1, Mythos 5.1, Fable 5, GPT-6 Astra, Sol, Kimi K3
quick (งานสั้น) GLM 5.3 Flash, GLM 5.2 Ultrafast, Kimi K3, GPT-5.6 Luna
writing (งานเขียน) Kimi K3, Qwen3-Coder, Gemini 3.1 Pro
unspecified-low (ถูกสุด) GLM 5.3, GLM 5.2, DeepSeek V3.2, Claude Opus 5

นี่คือแนวคิดเดียวกับที่งานวิจัย SWE-Bench ProMax ที่ผมรีวิวไปเมื่อวานพิสูจน์มาแล้ว: โมเดลถูกกว่าทำงานได้ใกล้เคียงโมเดลแพงในบางงาน การ routing ตามชนิดงานคือวิธีกอบโกนค่าใช้จ่ายจริง และ OMH ทำให้มันกลายเป็น config ที่แก้ได้ตามบัญชีของแต่ละคน ไม่ใช่ของตายตัว

2. ห้ามโกหกเรื่องสถานะงาน, Evidence-Bound Delivery

ส่วนที่ผมคิดว่าเป็นจุดขายที่ฉลาดที่สุดของ OMH คือการแยกสถานะงานออกเป็นสี่ระดับที่ห้ามสับสน [1]

ที่คุณเห็น ความหมายจริง
Plan, not run มีแผนพร้อมแล้ว แต่ยังไม่มีอะไรวิ่งเลย
Code, running ตัวลงมือกำลังทำงานอยู่จริง ระบบกำลังเฝ้าดู
Code, reported done ตัวลงมือบอกว่าทำเสร็จแล้ว แต่ยังไม่มีใครตรวจ
Test, verified มีการทดสอบหรือรีวิวผ่านจริง

ทำไมต้องขนาดนี้ เอกสารของเขาอธิบายตรงๆ ว่า "เครื่องมือส่วนใหญ่เรียกทั้งสองแบบล่างว่า complete", นี่คือความโกหกเชิงระบบที่เราคุ้นเคยกันดีจากบท agentic misalignment ที่ผมเขียนไปเมื่อวาน: โมเดลชอบประกาศชัยชนะก่อนเวลา OMH แก้ที่โครงสร้าง ไม่ใช่ที่ความประพฤติของโมเดล โดยบังคับให้ทุกรายงานแยกชั้นระหว่าง "เตรียมไว้" "กำลังทำ" "บอกว่าเสร็จ" และ "ตรวจแล้วจริง"

3. วงจรงานเก้าขั้นที่พูดกันรู้เรื่อง

OMH มาพร้อม workflow สำเร็จรูปเก้าตัวที่ขึ้นต้นด้วย ulw- ใช้งานด้วยการพิมพ์ชื่อในแชตได้เลย [1]

คำสั่ง ทำอะไร
ulw-context จับศัพท์และบริบทโปรเจกต์ให้ตรงกันก่อนเริ่มงาน
ulw-interview ถามทีละข้อจนรู้ว่าคุณต้องการอะไรแน่
ulw-research ค้นโค้ดจริงและเว็บจริง เก็บแหล่งอ้างอิง ตรวจของที่น่าสงสัย
ulw-plan สร้างแผนที่ผ่านการรีวิว เปรียบเทียบทางเลือก ตั้งเกณฑ์ความสำเร็จ
ulw-work รันแผนที่ตกลงแล้วแบบแยกเลน ที่ไม่แตะไฟล์เดียวกัน
ulw-maestro ส่งงานต่อให้ Claude Code หรือ Codex ลงมือเขียนโค้ด
ulw-loop วนสร้าง รีวิว แก้ จนกว่าเป้าหมายจะผ่านจริง
ulw-qa โจมตีงานตัวเองด้วยสถานการณ์แบบคนไม่หวังดี แล้วแก้ที่พัง
ulw-perf วัดว่าช้าหรือแพงตรงไหนจริง แล้วแก้ทีละจุดร้อน

ทั้งเก้าขั้นนี้ไม่ใช่คำสั่งลับ แต่ถูกติดตั้งเป็น Hermes skill ที่คุณพิมพ์เรียกในแชตได้เลย เหมือนสั่งคนในทีม

สิ่งที่ทำให้ผมประทับใจจริงๆ หลังอ่านเอกสารทั้งหมด

ความระมัดระวังในระดับที่น่าแปลกใจ

เอกสารสถาปัตยกรรมของเขา [4] ใช้คำเหล่านี้ซ้ำแล้วซ้ำเล่า: prepared not observed, nothing has run yet, no hidden execution, never patching Hermes นี่คือโปรเจกต์ที่ย้ำเรื่องความซื่อสัตย์ในเชิงวิศวกรรมมากกว่าที่ผมเคยเห็นในเครื่องมือประเภทนี้ ตัวอย่างเช่น แม้แต่การจัดการความจำโปรเจกต์ เอกสารก็ระบุว่า "ไม่อ่านหรือแตะความจำภายในของ Hermes" แต่สร้างระบบความจำแยกที่ตรวจทานได้ [1]

ระบบตรวจสอบคุณภาพที่น่าจดจำ

สิ่งที่ทำให้ผมเชื่อว่าโปรเจกต์นี้จะอยู่รอดคือรายละเอียดเชิงวิศวกรรมตรงนี้: catalog ของ skill ทั้ง 120+ ตัวถูกสร้างแบบ deterministic พร้อม drift gates ที่ทำ CI ล้มเหลวถ้าข้อความเปลี่ยนแม้แต่ตัวอักษรเดียว [1] แปลว่าทุกครั้งที่มีการแก้เอกสารหรือเปลี่ยนพฤติกรรม ระบบตรวจจับได้ทันที นี่คือวินัยที่ทีมซอฟต์แวร์ระดับองค์กรใช้กัน ไม่ใช่ของโปรเจกต์อินดี้ทั่วไป

สร้างร่วมกับ AI agent อย่างเปิดเผย

โปรเจกต์ประกาศตรงๆ ใน README ว่าสร้างร่วมกับ AI agent สองตัวชื่อ Friren และ Killua ที่ช่วยพัฒนาจริง พร้อมรูปการ์ตูนประกอบ นี่คือสัญญาณของยุคใหม่ที่เราเล่ากันในบท long-running agents: คนหนึ่งคนกับเอเจนต์สองตัวสร้างโปรเจกต์ระดับ 1,400 ดาวได้ในสามเดือน

ชื่อที่เลียนแบบวัฒนธรรมโอเพนซอร์สอย่างรู้งาน

ชื่อ oh-my-hermes ที่ตามหลัง oh-my-zsh ตำนานเครื่องมือ config สำหรับ terminal บอกตำแหน่งของตัวเองชัดเจน: เหมือนที่ oh-my-zsh เปลี่ยนประสบการณ์ใช้ shell โดยไม่เปลี่ยนตัว shell ตัวนี้ก็เปลี่ยนประสบการณ์ใช้ Hermes โดยไม่แตะตัว Hermes และความเคารพนี้สอดคล้องกับที่ README เขียนว่า "ขอบคุณ Nous Research สำหรับการสร้าง Hermes Agent" อย่างเปิดเผย

ไข่กล่องที่ยังไม่ได้เปิด: ฟีเจอร์ที่ซ่อนอยู่เบื้องลึก

บทความฉบับแรกที่ผมเขียนถึงแค่ยอดภูเขา เมื่อไล่อ่านเอกสาร workflow ทั้งหมด (ไฟล์เดียวยาวกว่า 900 กิโลไบต์) พบว่าระบบนี้ใหญ่กว่าที่เขียนไว้หลายเท่า: มี skills ทั้งหมดราว 200 ตัว ในจำนวนนั้น 118 ตัวติดตั้งและเรียกใช้ได้จริง กระจายกันอย่างเป็นระเบียบใน 17 หมวด ตัวใหญ่ที่สุดคือ operations (13 ตัว), planning (11), research (10) [5]

สิ่งที่น่าสนใจไม่ใช่จำนวน แต่คือสิ่งที่ซ่อนอยู่ในรายการซึ่งคนใช้ทั่วไปอาจไม่มีวันรู้ว่ามี:

ระบบบทบาท 9 ตัวที่ทำงานเป็นองค์กรจริง

ทุก skill ระบุบทบาทที่ Hermes จะเล่นตอนทำงาน แยกเป็นเก้า: Guide (นำทาง), Researcher (นักวิจัย), Planner (นักวางแผน), Operator (ผู้ปฏิบัติ), Memory Keeper (ภารโรงความจำ), Handoff Guide (ผู้ส่งต่องาน), Builder (ผู้สร้าง), Tracker (ผู้ติดตาม), Reviewer (ผู้ตรวจ) [5] การออกแบบนี้ทำให้คำสั่งเดียวกันให้ผลลัพธ์ต่างกันได้ตามบทบาทที่ระบบเลือกให้เหมาะกับสถานการณ์

ฟีเจอร์เด่นที่คนไม่ค่อยพูดถึง

Adversarial Consensus: ก่อนตัดสินใจใหญ่ ระบบปล่อยมุมมองอิสระหลายฝั่งโจมตีข้อเสนอของกันและกัน แล้วกลั่นเป็นชุดข้อสรุปให้ตัววางแผนตัวอื่นนำไปใช้ต่อ คล้ายจ้างผู้เชี่ยวชาญหลายฝ่ายมาถกเถียงแทนการเชื่อมุมมองเดียว [5]

AI Slop Cleaner: ลบความงี่เง่าที่ AI สร้างออกจากโค้ด ตัดโค้ดตายและส่วนซ้ำ โดยพฤติกรรมที่มองเห็นได้ต้องเหมือนเดิมทุกอย่าง นี่คือสัญญาณว่าโปรเจกต์ยอมรับความจริงของยุคนี้: AI สร้างขยะเยอะและต้องมีคนเก็บ [5]

Instinct Ledger: ระบบนี้เปลี่ยนบทเรียนที่เจอซ้ำๆ ในโปรเจกต์ให้เป็น "สัญชาตญาณ" แบบ atomic ที่มีคะแนนความมั่นใจ พร้อมขั้นตอนเลื่อนระดับและส่งออกที่ชัดเจน เหมือนสร้างสมุดจดประสบการณ์ให้ AI [5]

Voice และ Browser Operator: ระบบรองรับคำสั่งพูดสั้นๆ แบบมือถือ (voice-operator) และมีนโยบายเหนือการใช้เบราว์เซอร์ (browser-operator) ที่บังคับยืนยันก่อนล็อกอินหรือกรอกฟอร์ม พร้อมบันทึกทุกจังหวะให้ตรวจย้อนได้ [5]

Morning Brief Setup: มี workflow ตั้งค่า brief เช้าที่เชื่อมอีเมลกับปฏิทินผ่าน MCP แบบอ่านอย่างเดียว ทุกครั้งที่แตะต้องอนุมัติเป็น diff ก่อนเสมอ [5]

Achievements: ใช่ครับ มีระบบเหรียญตราให้เก็บสะสม เหมือนเกม สรุปจาก badge ที่ปลดล็อกล่าสุดและความคืบหน้า [5]

การทำความสะอาดตัวเองที่น่าชม

สิ่งที่บอกความเป็นมืออาชีพของทีมพัฒนา: skills ที่หมดวาระจะไม่หายไปเงียบๆ แต่ถูก mark เป็น retired พร้อมบอกตำแหน่งใหม่ที่ความสามารถย้ายไปอยู่ เช่น ulw-ralph และ ulw-goal เกษียณไปรวมเป็นความสามารถชื่อ single_owner_persistence และ durable_checkpoint ภายใน ulw-work [5] ผู้ใช้เก่าไม่หลงทาง ระบบเองก็ไม่อ้วนขึ้นเรื่อยๆ

ข้อจำกัดและข้อควรระวังก่อนลอง

เพื่อความสมดุล สิ่งที่ควรรู้ก่อนติดตั้งใช้จริง

ความซับซ้อนที่ซ่อนอยู่ ระบบ routing 9 หมวด 120+ skill และ workflow 9 ตัวฟังดูดี แต่การตั้งค่าให้ตรงกับบัญชีและโมเดลที่คุณมีจริงต้องผ่านขั้นตอน setup ที่ถามรายละเอียดหลายชั้น สำหรับคนที่เพิ่งเริ่มใช้ Hermes อาจงงว่าต้องตอบอะไร

การพึ่งพาโมเดลหลายค่าย ห่วงโซ่โมเดลที่แนะนำอ้างถึงโมเดลจากหกเจ้าขึ้นไป (OpenAI, Anthropic, Moonshot, Zhipu, Alibaba, Google) ถ้าบัญชีคุณมีไม่ครบ ระบบจะไล่ไปตัวสำรองตามลำดับ ซึ่งหมายความว่าประสิทธิภาพจริงขึ้นกับสิ่งที่คุณมีมากกว่าที่ตารางโฆษณา

สถานะพัฒนาที่ยังเดินหน้า ด้วยอัปเดตเกือบรายวันและเอกสารภายในที่เปลี่ยนเรื่อยๆ ผู้ใช้ต้องพร้อมตาม omh update ถี่ๆ และอ่าน changelog เพราะพฤติกรรมบางอย่างอาจปรับระหว่างทาง

ความเป็นมาของผู้พัฒนา นี่คือโปรเจกต์บุคคลคนเดียวของนักพัฒนาอิสระเกาหลี ไม่ใช่สินค้าจากบริษัทหลังรั้วใหญ่ ข้อดีคือความเร็วและเสียงที่ชัด ข้อควรชั่งคือความยั่งยืนระยะยาวขึ้นกับคนเดียวเป็นหลัก

ทำไมสิ่งนี้ถึงสำคัญกว่าตัวเครื่องมือเอง

ประเด็นที่ผมอยากฝากไว้ท้ายบทความคือ แม้คุณจะไม่ได้ใช้ Hermes หรือไม่สนใจโปรเจกต์นี้ตัวตน แนวคิดที่มันแสดงให้เห็นก็คือทิศทางที่วงการกำลังเดินร่วมกันหลายทาง

สังเกตว่าแนวคิดเดียวกันนี้ปรากฏในงานวิจัยที่ผมรีวิวมาทั้งสัปดาห์: บท Agentic Software พูดถึงวิชาใหม่ที่มนุษย์เปลี่ยนบทบาทจากคนเขียนโค้ดเป็นคนออกแบบเจตนา งานวิจัย benchmark สองชุดยืนยันว่าโมเดลเดียวไม่จำเป็นต้องเก่งทุกอย่าง และรายงาน misalignment เตือนว่าระบบต้องแยกการรายงานผลจากการตรวจสอบจริง OMH คือการนำหลักการทั้งหมดนี้มาประกอบเป็นของใช้จริงหนึ่งชิ้น ที่ทำงานได้วันนี้ ติดตั้งวันนี้ และโตเร็ววันนี้

คำถามชวนคุย: ถ้าให้เลือกเสริม "ผู้จัดการเสมือน" แบบนี้ให้เวิร์กโฟลว์ของคุณ คุณจะเริ่มจากกลไกไหนก่อน: การ routing โมเดลตามชนิดงาน การบังคับแยกสถานะงานจริงจากที่รายงานมา หรือวงจรวางแผนถึงตรวจสอบครบวงจร เชิญแลกเปลี่ยนกันได้ครับ

ถ้าชอบบทความเจาะโปรเจกต์โอเพนซอร์สแบบอ่านเอกสารทั้งเล่ม ติดตาม Nokka ได้ที่ dev.to/sarantoon

📚 อ่านต่อ: ผมเพิ่งเขียนเรื่อง benchmark ที่โกหกคุณ (SWE-Bench ProMax) กับกระดาษวิจัยว่าด้วยวิชาใหม่หลังยุคโค้ด (Agentic Software) บทนี้คือหน้าจาก "งานวิจัย" มาสู่ "ของใช้จริง" ของธีมเดียวกัน

แหล่งอ้างอิง

[1] rlaope. "oh-my-hermes" (README ฉบับเต็ม). GitHub. 2026. https://github.com/rlaope/oh-my-hermes

[2] rlaope. "Direction" (เอกสารภายในโปรเจกต์). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/DIRECTION.md

[3] Nous Research. "Hermes Agent". GitHub. 2026. https://github.com/NousResearch/hermes-agent

[4] rlaope. "Architecture" (เอกสารภายในโปรเจกต์). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/ARCHITECTURE.md

[5] rlaope. "Workflow Reference" (เอกสารสร้างอัตโนมัติจากแคตตาล็อก skills ทั้งหมด). GitHub. 2026. https://github.com/rlaope/oh-my-hermes/blob/main/docs/WORKFLOWS.md


บทความนี้วิเคราะห์จาก README ฉบับเต็มและเอกสารภายในทั้งสี่ชุด (ARCHITECTURE, DIRECTION, CAPABILITIES, WORKFLOWS) ซึ่งผมอ่านจริงระหว่างการค้นคว้า ตัวเลขจาก GitHub API ณ 5 กันยายน 2026 Nokka

Top comments (0)