ใช้ Hermes ให้เกิดงานจริง: จากรายงาน ไปสู่ Loop และ Skill

The Next New Thing เพิ่งลงวิดีโอชื่อ 7 Hermes uses you must try (that actually work)

ในคลิปมี Andrew Warner และ Eric Siu คุยกันเรื่อง use case ของ Hermes Agent หลายแบบ ตั้งแต่คุมคอมพิวเตอร์ ทำ competitor research ทำ memory wiki ใช้ Linear / Slack / Zapier MCP ตั้ง cron ไปจนถึง remote gateway และการ save workflow เป็น skill

ถ้าอ่านแบบคนสนใจเครื่องมือ อาจสรุปง่าย ๆ ว่า “Hermes ทำได้เยอะ”

แต่ถ้าอ่านแบบ operator ผมว่านี่คือบทเรียนที่สำคัญกว่า:

AI Agent ที่มีค่าจริง ไม่ใช่ตัวที่ทำ report ได้เยอะที่สุด แต่คือตัวที่ทำให้งานจริงเดินต่อเป็น loop ได้

1) เกิดอะไรขึ้นในคลิปนี้

คลิปนี้ไม่ได้เป็น tutorial แบบกดตามทีละปุ่ม แต่เป็นการไล่ดู use case ที่คนเริ่มใช้ Hermes จริง แล้วให้ Eric Siu ช่วยแยกว่าอะไร practical และอะไรยังเป็นแค่ภาพสวย

ตัวอย่างที่ถูกพูดถึงมีหลายชั้น:

• computer use: ให้ Hermes คุมแอปบนเครื่อง และส่งงานต่อให้เครื่องมืออื่น
• competitor research: ให้ Hermes วิเคราะห์คู่แข่ง แล้ว export เป็น markdown เพื่อให้ coding agent ต่อได้
• memory wiki: ให้ Hermes สร้าง site หรือ log ที่รวม daily work และหัวข้อที่คุยกัน
• Obsidian / GBrain / GStack: ใช้ memory และ skill stack ให้ agent มีบริบทมากขึ้น
• Linear: ใช้ project tracker เป็นระบบงาน ไม่ใช่คุยกับ AI ลอย ๆ
• Slack / Discord: ใช้ chat surface เป็นที่รับส่งงานกับ agent
• Zapier MCP: เปิดทางให้ Hermes แตะ email / follow-up workflow แบบมี tool layer
• cron: ทำ daily briefing, server check, YouTube comment monitoring, follow-up reminder
• gateway / Tailscale: ให้ Hermes ทำงานข้ามเครื่องหรือ remote environment
• skills: save workflow ที่ทำซ้ำได้ เพื่อไม่ต้อง prompt ยาวใหม่ทุกครั้ง

Hermes official docs ก็วางภาพคล้ายกันครับ: Hermes ไม่ได้เป็นแค่ chatbot แต่เป็น autonomous agent ที่มี tools, memory, skills, messaging gateway, scheduled automations, delegation และ MCP support

จุดนี้สำคัญ เพราะมันทำให้คำถามเปลี่ยนจาก “Hermes มี feature อะไรบ้าง” เป็น “เราจะประกอบ feature เหล่านี้ให้กลายเป็น workflow ที่มี owner, approval, proof และ feedback loop ได้อย่างไร”

พูดง่าย ๆ คือ Hermes เป็น work runtime มากกว่าเป็นแค่กล่องแชท

2) จุดที่คลิปนี้พูดตรงมาก: ระวัง AI theater

ช่วงหนึ่งในคลิปประมาณนาทีที่ 03:36 Eric ใช้คำว่า AI theater

ความหมายคือ workflow ที่ดูเหมือนทำเยอะมาก มี board มี card มี report มี automation แต่สุดท้ายไม่ได้ทำให้งานจริงดีขึ้น

ผมชอบคำนี้มาก เพราะมันตรงกับสิ่งที่หลายธุรกิจจะเจอในปีนี้

ตอนเริ่มใช้ AI Agent เรามักตื่นเต้นกับสิ่งที่มันทำให้เห็นได้ทันที เช่น:

• สรุปรายงาน
• ทำ briefing ทุกเช้า
• ดึงข้อมูลจากหลายแหล่ง
• เปิด dashboard
• สร้าง task card
• เขียน draft
• ตอบ comment

ทั้งหมดนี้มีประโยชน์ได้ครับ

แต่ถ้าไม่มี owner action ต่อ ไม่มี verification ไม่มีการตัดสินใจ ไม่มี feedback กลับเข้า workflow มันก็กลายเป็นแค่เครื่องผลิตเอกสาร

AI theater ไม่ได้แปลว่า AI ทำงานไม่ได้

มันแปลว่าเราออกแบบ workflow ยังไม่ถึงจุดที่งานเดินจริง

3) กรอบที่ผมใช้ดู Hermes use case: REPORT → LOOP → SKILL

หลังดูคลิปนี้ ผมสรุปเป็นกรอบสั้น ๆ แบบนี้ครับ

REPORT

นี่คือชั้นแรกสุด

Hermes ไปดึงข้อมูล วิเคราะห์ สรุป หรือจัดรูปแบบให้เรา เช่น competitor report, daily briefing, YouTube research, server summary

ชั้นนี้เริ่มมีค่า เพราะช่วยลดเวลาหาข้อมูล

แต่ข้อเสียคือ report ตายง่ายมาก

ถ้าไม่มีคนอ่าน ไม่มี task ต่อ ไม่มี action ต่อ มันก็เป็นไฟล์สวย ๆ อีกไฟล์หนึ่ง

LOOP

ชั้นที่สองคือเอา report ไปต่อกับงานจริง

ตัวอย่าง:

• competitor report กลายเป็น feature hypothesis ใน GitHub issue
• YouTube comment monitoring กลายเป็น draft reply ที่รอ approval
• daily AI news กลายเป็นหัวข้อ podcast / Deep Dive / newsletter
• server check กลายเป็น incident ticket เมื่อมีสัญญาณผิดปกติ
• media kit update กลายเป็น Slack review พร้อมไฟล์แนบและ changelog

ตรงนี้ Hermes เริ่มเป็น coworker แล้วครับ

เพราะมันไม่ได้แค่ “บอก” แต่ช่วยพางานไปถึง decision point

SKILL

ชั้นที่สามคือเอา loop ที่ทำซ้ำบ่อยมา save เป็น skill

ในคลิปมีตัวอย่างว่า save workflow เป็น skill ชื่อประมาณ competitor-watch เพื่อให้ครั้งหน้าแค่ให้ search term แล้ว agent รู้ว่าต้องหา YouTube videos, save info, call out gaps

นี่คือจุดที่ agent เริ่มดีขึ้นในเชิงระบบ

ไม่ใช่เพราะ model ฉลาดขึ้นอย่างเดียว แต่เพราะเราแปลงวิธีทำงานที่เวิร์กแล้วให้เป็น procedural memory

สำหรับผม นี่คือหัวใจของ Hermes:

งานที่ดีควรถูกทำให้ซ้ำได้ และงานที่ซ้ำได้ควรถูกยกระดับเป็น skill

4) Memory ไม่ใช่แค่จำ แต่ต้องเชื่อมกับระบบงาน

คลิปพูดถึง memory wiki, Obsidian, QMD, GBrain, GStack และ Linear

ผมมองประเด็นนี้แบบนี้ครับ

ถ้า agent มีแต่ memory แต่ไม่ผูกกับระบบงาน มันจะจำได้เยอะ แต่ไม่รู้ว่างานไหนต้องทำต่อ

ถ้ามีแต่ task tracker แต่ไม่มี memory มันจะเห็น ticket แต่ไม่เข้าใจบริบทเก่า

ถ้ามีแต่ chat แต่ไม่มี skill มันจะเก่งเฉพาะรอบนั้น แล้วพรุ่งนี้ต้องเริ่มใหม่

ระบบที่ดีจึงควรมี 4 ชั้น:

1. Memory: จำ preference, decision, context สำคัญ
2. Knowledge base: เก็บ source, wiki, docs, SOP
3. Project tracker: แปลงเรื่องคุยเป็น ticket / task / owner / status
4. Skill: เก็บวิธีทำงานซ้ำ ๆ พร้อม gotcha และ verification

นี่คือเหตุผลที่ use case อย่าง Obsidian + Linear + Hermes น่าสนใจกว่า daily briefing เฉย ๆ

เพราะมันเริ่มสร้าง closed loop ระหว่างความจำ งาน และการทำซ้ำ

5) Cron ที่ดีต้องมี trigger และ output ที่มีคนใช้

ในคลิปมีตัวอย่าง cron หลายแบบ เช่น daily AI news briefing, YouTube comment monitoring, morning business summaries, server checks, research reports และ follow-up reminders

ผมใช้ cron เยอะเหมือนกันครับ และบทเรียนคือ:

cron ที่ดีไม่ใช่ cron ที่ส่งข้อความบ่อย แต่คือ cron ที่ส่งสัญญาณแล้วมีคนทำอะไรต่อได้ทันที

ตัวอย่างที่ดี:

• ถ้า server check พบ error ให้เปิด issue พร้อม log สั้น ๆ
• ถ้า YouTube comment มีคำถามซื้อคอร์ส ให้ draft reply รอ approval
• ถ้า daily news มีข่าวที่ fit กับ Data-Espresso ให้เสนอ Deep Dive candidate พร้อมคะแนน
• ถ้า lead follow-up ถึงเวลา ให้เตรียม message draft พร้อม context ลูกค้า

ตัวอย่างที่ไม่ดี:

• ส่งข่าวทุกเช้า 30 หัวข้อ แต่ไม่มี prioritization
• สร้าง report ทุกวัน แต่ไม่มี owner action
• โยนทุกอย่างเข้าห้องแชทจนคน mute

ตรงนี้เองที่แยก agent ops ออกจาก AI spam

6) ช่องทางคุยกับ Agent สำคัญกว่าที่คิด

อีกประเด็นในคลิปคือ Slack, Discord, Telegram, desktop app, gateway และ remote machine

เรื่องนี้ดูเหมือน integration แต่จริง ๆ คือ operating model

เพราะ AI coworker ที่ใช้จริงต้องอยู่ตรงที่งานเกิด:

• ถ้างานทีมอยู่ Slack, agent ต้องอยู่ Slack หรือมี bridge ที่ดี
• ถ้างานส่วนตัวอยู่ Telegram, agent ต้องตอบใน Telegram ได้
• ถ้างาน dev อยู่ Linear / GitHub, agent ต้องอ่าน issue และส่ง proof กลับได้
• ถ้างานรันบน server หรือ sandbox, agent ต้องมี gateway ไปยัง runtime นั้น

แต่ต้องระวังครับ

การให้ agent อยู่ทุกที่ไม่ได้แปลว่าให้ agent ทำทุกอย่างได้ทุกที่

ยิ่ง agent เข้าถึงหลายช่องทาง ยิ่งต้องมี scope, approval, audit log และ rule ว่าเรื่องไหนต้องถามคนก่อน

Operator Kit: Hermes Use Case Filter

ก่อนจะทำ use case ใหม่กับ Hermes หรือ AI coworker ให้เช็ก 7 ข้อนี้ครับ

1) Output นี้มีคนใช้จริงไหม

ถามตรง ๆ:

• ถ้า Hermes ทำ report นี้เสร็จ ใครอ่าน
• อ่านแล้วต้องตัดสินใจอะไร
• มี deadline หรือ trigger ต่อไหม
• ถ้าไม่มี report นี้ งานเสียหายไหม

ถ้าตอบไม่ได้ use case อาจยังเป็นแค่ demo

2) Output นี้ต่อเป็น action ได้ไหม

เปลี่ยนจาก “สรุปให้หน่อย” เป็น:

• สรุปแล้วเปิด issue
• สรุปแล้ว draft reply
• สรุปแล้วเสนอ 3 next actions
• สรุปแล้ว flag risk พร้อม evidence
• สรุปแล้วทำ PR / file / task / checklist

ถ้า output ไม่พางานไปจุดต่อไป มันยังอยู่ชั้น REPORT

3) มี human approval ตรงไหน

เขียนให้ชัดว่า action ไหนทำเองได้ และ action ไหนต้องรอคน

ตัวอย่าง action ที่ควรรอ approval:

• ส่ง email / DM / customer reply
• publish post / ad / webpage
• deploy production
• เปลี่ยนราคา / payment / quota
• แตะ customer data หรือ secret
• delete / archive / bulk update

Hermes ที่ดีไม่ใช่ทำทุกอย่างเองครับ

แต่ต้องรู้ว่าเมื่อไรต้องหยุดถาม

4) มี proof หลังทำไหม

ทุก loop ควรจบด้วย proof เช่น:

• URL
• screenshot
• test result
• issue comment
• file path
• commit SHA
• dry-run output
• media ID
• customer-safe summary

ถ้าไม่มี proof เราจะไม่รู้ว่างานจบจริงหรือแค่ agent บอกว่าจบ

5) มี feedback กลับเข้า memory หรือ skill ไหม

หลังทำงานยากหรือทำซ้ำ ให้ถาม:

• รอบนี้ prompt อะไรเวิร์ก
• ขั้นตอนไหนผิดบ่อย
• tool ไหนต้องใช้ก่อนหลัง
• guardrail อะไรขาด
• ควร save เป็น skill ไหม

นี่คือจุดที่ Hermes ควรค่อย ๆ ดีขึ้น

6) ถ้าทำทุกวัน จะกลายเป็น spam ไหม

cron / briefing / monitoring ต้องมี threshold

ไม่ใช่ส่งทุกอย่าง

ให้ส่งเฉพาะเมื่อ:

• มี change สำคัญ
• มี risk เกินเกณฑ์
• มี opportunity ที่ต้องตัดสินใจ
• มี blocker ที่ agent แก้เองไม่ได้
• มี proof ใหม่ที่ควรรู้

7) ใช้เครื่องมือถูกชั้นไหม

บางอย่างควรเป็น prompt เดียว บางอย่างควรเป็น task ใน Linear บางอย่างควรเป็น cron บางอย่างควรเป็น MCP tool บางอย่างควรเป็น skill บางอย่างควรเป็น full workflow ใน sandbox

อย่าเอาทุกอย่างไปยัดเป็น chatbot

ถ้างานมี state, owner, deadline, proof และ approval มันควรอยู่ใน workflow ไม่ใช่อยู่ในแชทลอย ๆ

ตัวอย่างธุรกิจไทย: ทำให้ Agent ไม่กลายเป็น spam

ถ้าแปลงกรอบนี้มาใช้กับธุรกิจไทย ตัวอย่างจะหน้าตาประมาณนี้ครับ

• LINE ลูกค้าถามราคา: Hermes สรุป context, draft reply, รอ admin approve แล้วบันทึก CRM note
• Daily AI news: Hermes ไม่ส่งข่าว 30 หัวข้อ แต่คัด 3 หัวข้อที่ fit กับ Data-Espresso แล้วเปิด Deep Dive candidate
• Server check: Hermes ไม่ส่ง log ทุกเช้า แต่เปิด incident ticket เฉพาะเมื่อ error เกิน threshold พร้อม proof

ประเด็นคือ agent ไม่ควรทำตัวเป็นลำโพงที่ส่งทุกอย่างเข้าห้องแชท

agent ที่ดีควรเป็นตัวกรองที่ส่งเฉพาะสัญญาณที่ต้องตัดสินใจ

ตัวอย่างการแปลง use case ให้เป็นงานจริง

สมมติ use case คือ competitor research

เวอร์ชัน REPORT:

วิเคราะห์คู่แข่ง 5 รายแล้วสรุปให้หน่อย

เวอร์ชัน LOOP:

วิเคราะห์คู่แข่ง 5 ราย หาฟีเจอร์ที่เราไม่มี จัดเป็น 3 กลุ่ม: copy now, monitor, ignore แล้วเปิด GitHub issue หรือ Linear task พร้อม evidence link สำหรับ top 3 opportunities

เวอร์ชัน SKILL:

สร้าง skill ชื่อ competitor-watch ที่รับชื่อคู่แข่งหรือ category แล้วทำ research, บันทึก source note, สรุป opportunities, เปิด task, และจบด้วย proof report ทุกครั้ง

เห็นไหมครับว่าเครื่องมือเดียวกัน แต่ business value ต่างกันมาก

สรุป

คลิปนี้ทำให้เห็นว่า Hermes Agent เริ่มมี use case ที่จับต้องได้จริงมากขึ้น

แต่บทเรียนที่ผมอยากให้จำไม่ใช่ “ต้องลอง 7 use cases นี้ทั้งหมด”

บทเรียนคือ:

อย่าเริ่มจากถามว่า Hermes ทำอะไรได้บ้าง

ให้เริ่มจากถามว่า:

1. งานไหนมี trigger ชัด
2. output ไหนมีคนใช้จริง
3. action ไหนต้องเกิดหลัง report
4. approval อยู่ตรงไหน
5. proof คืออะไร
6. ถ้าทำซ้ำได้ ควร save เป็น skill ไหม

สำหรับผม Hermes ที่ดีไม่ใช่ AI ที่พูดเก่งกว่าเดิม

แต่คือ AI coworker ที่ช่วยให้งานเดินต่อ พรุ่งนี้จำ pattern ได้ และรอบหน้าทำซ้ำได้ดีขึ้น

สุดท้าย AI Agent ไม่ได้ชนะที่ demo ครับ

มันชนะที่ loop