EP08: Cron และ Webhook: ให้ Hermes กลับมาทำงานเองตามเวลา

EP08: Cron และ Webhook ระบบ Scheduled Automation ของ Hermes

Series: Hermes Agent 101: จาก Chatbot สู่ AI Coworker ที่ทำงานจริง

EP07 เราคุยเรื่อง Gateway ที่ทำให้ Hermes ออกจาก terminal ไปอยู่บน Telegram, Discord, Slack EP08 นี้เราจะดูว่า Hermes ทำงานเองได้ยังไงโดยที่ไม่ต้องมีคนสั่ง

ปัญหาที่ Cron แก้

งานหลายอย่างในชีวิตประจำวันคุณทำซ้ำทุกวัน: เช็ค dashboard สรุปข่าว ตรวจ server health report ยอด ถ้าคุณต้อง prompt AI ทุกครั้ง มันก็ยังเหนื่อยเท่าเดิม

Cron คือระบบที่บอก Hermes ว่า “ทำสิ่งนี้ตามเวลาที่กำหนด” โดยไม่ต้องมีคนสั่ง

สร้าง Cron Job

วิธีง่ายที่สุดคือพูดตรงๆ ใน chat:

ทุกเช้า 9 โมง ไปดู Hacker News หาข่าว AI แล้วส่งมาที่ Telegram

Hermes จะแปลงเป็น job พร้อม schedule ถูกต้องให้เอง

หรือจะใช้ /cron command โดยตรง:

/cron add "0 9 * * *" "Summarize AI news and send to Telegram" --skill blogwatcher
/cron add "every 2h" "Check server status"
/cron add "30m" "Remind me to review the build"

หรือผ่าน CLI:

hermes cron create "every 2h" "Check server status"
hermes cron create "0 9 * * *" "Morning AI brief" --skill blogwatcher

รูปแบบ Schedule ที่รองรับ

รูปแบบ	ตัวอย่าง	ใช้สำหรับ
Relative delay	30m, 2h, 1d	One-shot, รันครั้งเดียว
Interval	every 30m, every 2h	Recurring, รันต่อเนื่อง
Cron expression	0 9 , 0 9 * 1-5	ควบคุมละเอียด
ISO timestamp	2026-03-15T09:00:00	กำหนดวันเวลาตาย

หมายเหตุ: Natural language เช่น “daily at 9am” ไม่รองรับ ต้องใช้ 0 9 * แทน

Job Lifecycle

hermes cron list              # ดู job ทั้งหมด
hermes cron pause     # หยุดชั่วคราว
hermes cron resume    # เปิดใหม่
hermes cron run       # รันทันที (สำหรับ test)
hermes cron remove    # ลบ
hermes cron status            # สถานะ scheduler

Delivery Targets

Cron job ส่งผลไปที่ไหนก็ได้:

origin          → กลับไปที่ chat ที่สร้าง job
telegram        → Telegram home channel
discord         → Discord home channel
slack           → Slack home channel
all             → ทุก platform ที่ configure ไว้
telegram,discord → หลาย platform พร้อมกัน

[SILENT] Pattern

สำหรับ monitoring job ที่ต้องการแจ้งเฉพาะตอนมีปัญหา:

/cron add "every 5m" "Check if nginx is running. If everything is healthy, respond with only [SILENT]. Otherwise report the issue."

ถ้า response ขึ้นต้นด้วย [SILENT] Hermes จะไม่ส่ง notification แต่ยังบันทึก output ไว้ใน ~/.hermes/cron/output/ เสมอ

No-Agent Mode (Watchdog)

สำหรับงานที่ไม่ต้องการ LLM เลย เช่น เช็ค RAM, disk, หรือ process health:

hermes cron create "every 5m" \
  --no-agent \
  --script memory-watchdog.sh \
  --deliver telegram \
  --name "memory-watchdog"

พฤติกรรม:

• Script stdout ส่งเป็น message ตรงๆ (no LLM tokens)
• Stdout ว่าง = silent tick, ไม่ส่ง notification
• Script crash หรือ exit non-zero = error alert ส่งเสมอ

คุณสามารถบอก Hermes ว่า “Ping ฉันที่ Telegram ถ้า RAM เกิน 85% ทุก 5 นาที” แล้ว Hermes จะเขียน script และสร้าง job ให้เองในโหมด no-agent

wakeAgent Gate (Cost Control)

Script ที่รันก่อน job สามารถตัดสินใจว่าจะ wake LLM หรือเปล่า:

# ถ้าไม่มีข้อมูลใหม่ ไม่ต้องเสีย token
if latest_count == previous_count:
    print(json.dumps({"wakeAgent": False}))
else:
    print(json.dumps({"wakeAgent": True}))

Pattern นี้ทำให้ job ที่รัน frequent (ทุก 1-5 นาที) แทบไม่เสีย LLM cost ยกเว้นตอนมีข้อมูลใหม่จริงๆ

Job Chaining ด้วย context_from

สร้าง multi-stage pipeline:

# Job A: ดึงข้อมูล 7:00 น.
cronjob(action="create", name="ai-news-fetch",
        schedule="0 7 * * *",
        prompt="Fetch top 10 AI stories from Hacker News...")

# Job B: rank เรื่องน่าสนใจ 7:30 น. รับ output จาก Job A
cronjob(action="create", name="ai-news-rank",
        schedule="30 7 * * *",
        context_from="ai-news-fetch",
        prompt="Score each story 1-10 for engagement potential...")

# Job C: draft tweet 8:00 น. รับ output จาก Job B
cronjob(action="create", name="ai-news-brief",
        schedule="0 8 * * *",
        context_from="ai-news-rank",
        prompt="Write 3 tweet drafts from the top stories...")

แต่ละ job รันใน fresh session ไม่มี shared memory แต่ context_from ส่ง output ของ job ก่อนหน้าเป็น context อัตโนมัติ

Skills ใน Cron Job

hermes cron create "0 9 * * *" "Summarize new feed items" --skill blogwatcher
hermes cron create "every 6h" "Local brief" --skill blogwatcher --skill maps

Skills โหลดก่อนรัน prompt ทำให้ agent มี playbook ที่ถูกต้องโดยไม่ต้องใส่ instruction ยาวใน prompt

ข้อควรระวัง: Self-Contained Prompts

Cron job รันใน fresh session ไม่มีความจำของ conversation เดิม:

แย่: "Check on that server issue"

ดี: "SSH into 192.168.1.100 as user 'deploy', check if nginx is running with systemctl status nginx, and verify https://example.com returns HTTP 200"

—

Webhook: Event-Driven Automation

ถ้า Cron คือ time-driven, Webhook คือ event-driven คุณไม่ต้องกำหนดเวลา แต่บอกว่า “ถ้าเกิด event นี้ ให้ทำสิ่งนี้”

Quick Start

WEBHOOK_ENABLED=true
WEBHOOK_PORT=8644
WEBHOOK_SECRET=your-secret

hermes gateway setup  # ตั้งค่าผ่าน wizard
curl http://localhost:8644/health  # verify

กรณีใช้งานจริง: GitHub PR Auto-Review

# ~/.hermes/config.yaml
platforms:
  webhook:
    enabled: true
    extra:
      port: 8644
      secret: "global-secret"
      routes:
        github-pr:
          events: ["pull_request"]
          secret: "github-webhook-secret"
          prompt: |
            Review this PR:
            Repository: {repository.full_name}
            PR #{number}: {pull_request.title}
            Author: {pull_request.user.login}
            URL: {pull_request.html_url}
          skills: ["github-code-review"]
          deliver: "github_comment"
          deliver_extra:
            repo: "{repository.full_name}"
            pr_number: "{number}"

ผล: ทุกครั้งที่มี PR ใหม่ Hermes รัน code review โดยอัตโนมัติและ comment ใน GitHub

Prompt Templates

prompt: "PR #{pull_request.number} by {pull_request.user.login}"

• {pull_request.title} = payload[“pull_request”][“title”]
• {repository.full_name} = payload[“repository”][“full_name”]
• {raw} = full JSON payload (truncated at 4000 chars)

Direct Delivery Mode (Zero LLM)

สำหรับ notification ที่ไม่ต้องการ AI เลย:

routes:
  stripe-payment:
    secret: "stripe-secret"
    deliver: "telegram"
    deliver_only: true
    prompt: "Payment received: {data.object.amount} THB from {data.object.customer}"

ใช้ template rendering ตรงๆ ไม่ผ่าน LLM, ส่ง sub-second

Dynamic Subscriptions

hermes webhook subscribe github-issues \
  --events "issues" \
  --prompt "New issue #{issue.number}: {issue.title}" \
  --deliver telegram \
  --deliver-chat-id "-100123456789"

hermes webhook list
hermes webhook remove github-issues
hermes webhook test github-issues

ไม่ต้อง restart gateway subscriptions มีผลทันที (hot-reload)

Security ที่ต้องรู้

• HMAC validation: GitHub ใช้ X-Hub-Signature-256, GitLab ใช้ X-Gitlab-Token
• Rate limit: 30 req/min per route (ปรับได้)
• Idempotency: 1 ชั่วโมง cache ป้องกัน duplicate delivery
• Body size: 1MB max
• Prompt injection: webhook payload มาจาก external ซึ่งอาจมี malicious content ถ้า expose ทาง internet ควรใช้ Docker/SSH backend เป็น sandbox

—

Boundary: เมื่อไหรที่ยังต้องมี Human

Cron และ Webhook เหมาะกับ:

• งาน read + report (สรุปข่าว, เช็ค status, ดึงข้อมูล)
• งาน notify (แจ้งเตือน, ส่ง alert)
• งาน draft (เขียน content ให้ review ก่อน)

ยังต้องผ่าน human approval:

• Publish บทความ / โพสต์ social media
• ส่งเงิน / ทำธุรกรรมการเงิน
• แก้ไข production environment
• ส่ง email หาลูกค้า

Hermes ออกแบบมาให้ทำงาน predictable แทนคุณ ไม่ใช่ replace judgment ของคุณ

—

Cron vs Webhook เลือกอะไร?

สถานการณ์	ใช้อะไร
Report ทุกเช้า 9 โมง	Cron
Server health check ทุก 5 นาที	Cron (no-agent mode)
GitHub PR เปิดใหม่ → auto review	Webhook
Stripe payment → notify Telegram	Webhook (deliver_only)
Multi-stage data pipeline	Cron + context_from

—

EP ถัดไป

EP09 จะพูดเรื่อง Profiles: ทำไมควรมี AI หลายบทบาท และวิธีแยก coder/content/business ออกจากกันอย่างสมบูรณ์

Series นี้ทำงานจริงบน Hermes Agent open-source framework โดย NousResearch

OPB Stack tie-in: จาก prompt ทีละครั้ง เป็น operating rhythm

คนที่เหมาะกับ OPB Stack มักมีงานซ้ำที่มีจังหวะชัด เช่น report รายสัปดาห์ content calendar follow-up ลูกค้า research คู่แข่ง หรือ QA campaign ก่อนยิงจริง

Cron และ Webhook ทำให้ Hermes เปลี่ยนจาก “AI ที่ตอบเมื่อถูกถาม” เป็น “AI coworker ที่กลับมาทำงานตามจังหวะระบบ” โดยยังต้องมี proof และ approval ก่อนงานเสี่ยง

นี่คือเหตุผลที่ OPB Stack ไม่ควรขายเป็น automation ทั่วไปแบบ n8n/Make เท่านั้น แต่ควรขายเป็น sandbox ที่มี agent, memory, skills, schedule และ human approval อยู่ด้วยกัน

ดู managed path ได้ที่ opbstack.com