OpenClaw (Moltbot/Clawdbot) คืออะไร ฟีเจอร์ Heartbeat ทำงานอย่างไร

OpenClaw (เดิมชื่อ Moltbot/Clawdbot) ได้รับความนิยมอย่างรวดเร็วเนื่องจากมุ่งเน้นไปที่ระบบอัตโนมัติในพื้นที่ที่ใช้งานได้จริง: เฝ้าดูเครื่องของคุณ ตรวจจับความผิดปกติ และดำเนินการก่อนที่ปัญหาจะสะสม คุณสมบัติ Heartbeat เป็นหัวใจสำคัญของคำสัญญานั้น

Heartbeat คือสัญญาณสุขภาพและสถานะที่เป็นไปตามช่วงเวลา ใน OpenClaw มันทำได้มากกว่าการตรวจสอบสถานะการทำงาน มันทำงานผ่านกระบวนการตัดสินใจแบบหลายชั้น:

1. ตรวจสอบแบบกำหนดได้ที่ราคาถูกก่อน (กระบวนการ, ไฟล์, ความลึกของคิว, สถานะ API)
2. ประเมินกฎเทียบกับเกณฑ์และนโยบาย
3. การเพิ่มระดับด้วยโมเดลทางเลือกเฉพาะเมื่อยังมีความคลุมเครือ

รูปแบบ "ตรวจสอบราคาถูกก่อน, ใช้โมเดลเมื่อจำเป็นเท่านั้น" นี้คือสิ่งที่นักพัฒนาต้องการในการสนทนาของชุมชนเมื่อเร็วๆ นี้: การควบคุมต้นทุนที่ดีขึ้น, พฤติกรรมที่คาดเดาได้มากขึ้น, และการเรียกใช้ LLM ที่ไม่จำเป็นน้อยลง

หากคุณกำลังสร้างโครงสร้างพื้นฐานสำหรับเอเจนต์ นี่คือแนวคิดสำคัญ: Heartbeat เป็นส่วนประกอบพื้นฐานของ control-plane ไม่ใช่แค่เหตุการณ์การตรวจสอบเท่านั้น

สถาปัตยกรรม Heartbeat ของ OpenClaw ในมุมมองเดียว

ในขณะรันไทม์ Heartbeat ของ OpenClaw มักจะถูกนำมาใช้ในรูปแบบของลูปที่มีห้าขั้นตอน:

1. ตัวจัดกำหนดการ (Scheduler) เรียกใช้ Heartbeat (เช่น ทุก 15 วินาที / 30 วินาที / 60 วินาที)
2. ตัวเรียกใช้ Probe ดำเนินการ Probe ที่กำหนดไว้
3. กลไกนโยบาย (Policy engine) คำนวณการเปลี่ยนสถานะและความรุนแรง
4. เกตการยกระดับ (Escalation gate) ตัดสินใจว่าจำเป็นต้องใช้ LLM/ตัววางแผนเครื่องมือหรือไม่
5. ตัวกระจายการดำเนินการ (Action dispatcher) ส่งการแจ้งเตือน งานแก้ไข หรือไม่ดำเนินการใดๆ

ซองจดหมายเหตุการณ์ที่ใช้งานได้จริงมีลักษณะดังนี้:

{
  "agent_id": "desktop-a17",
  "heartbeat_id": "hb_01JX...",
  "ts": "2026-02-11T10:18:05Z",
  "probes": {
    "cpu_load": 0.72,
    "disk_free_gb": 21.4,
    "mail_queue_depth": 0,
    "service_api": {
      "status": 200,
      "latency_ms": 83
    }
  },
  "policy": {
    "state": "degraded",
    "reasons": [
      "disk_free_below_warn"
    ]
  },
  "escalation": {
    "llm_required": false,
    "confidence": 0.93
  }
}

พฤติกรรมหลักของระบบ:

• ผลลัพธ์ของ Probe ที่กำหนดไว้เป็นความจริงหลัก
• ผลลัพธ์ของนโยบายสามารถสร้างซ้ำได้และทดสอบได้
• การใช้ LLM นั้นเบาบาง ตรวจสอบได้ และถูกจำกัดด้วยเกณฑ์ที่เข้มงวด

"การตรวจสอบราคาถูกก่อน" หมายถึงอะไรในการนำไปใช้งานจริง

ใน OpenClaw การตรวจสอบราคาถูกควรเป็น:

• มีความหน่วงต่ำ (มิลลิวินาทีถึงไม่กี่ร้อยมิลลิวินาที)
• มีต้นทุนต่ำ (ไม่มีค่าใช้จ่ายโทเค็นโมเดล)
• กำหนดได้ (อินพุตเดียวกัน => ผลลัพธ์เดียวกัน)
• ไม่มีผลข้างเคียง โดยค่าเริ่มต้น

ประเภทของ Probe ทั่วไป:

• รันไทม์ในเครื่อง: กระบวนการทำงานอยู่, แรงดันหน่วยความจำ, จำนวนเธรด
• สุขภาพ I/O: พื้นที่ดิสก์ว่าง, แรงดัน inode, การเปลี่ยนแปลงสิทธิ์
• สุขภาพการรวมระบบ: รหัสสถานะ API เป้าหมาย, การหมดเวลา, ความหน่วง p95
• สุขภาพงาน: คิวค้าง, ตัวบ่งชี้การพยายามซ้ำหลายครั้ง
• เงื่อนไขเบื้องต้นของนโยบาย: ข้อมูลประจำตัวที่ถูกต้อง, ช่วงเวลาหมดอายุใบรับรอง

สัญญาของ Probe

ใช้โครงสร้าง Probe ที่เข้มงวดเพื่อให้ตรรกะปลายน้ำมีความเสถียร:

yaml ProbeResult: name: string ok: boolean observed_at: datetime value: number|string|object|null severity_hint: info|warn|critical error: string|null ttl_ms: integer

ค่า ttl_ms มีความสำคัญ หากข้อมูลสดใหม่พอ ให้ข้ามการตรวจสอบที่ซ้ำกันในช่วงเวลาที่มีปริมาณงานสูง

เมื่อ OpenClaw ควรยกระดับไปสู่การให้เหตุผลด้วยโมเดล

การยกระดับด้วยโมเดลควรเกิดขึ้นเมื่อตรรกะที่กำหนดไว้ไม่สามารถตัดสินใจได้อย่างปลอดภัยเท่านั้น

ตัวกระตุ้นการยกระดับที่ดี:

• สัญญาณ Probe ที่ขัดแย้งกัน (API 200 แต่ KPI ทางธุรกิจล้มเหลว)
• กลุ่มข้อผิดพลาดใหม่ที่ไม่มีลายเซ็นที่รู้จักตรงกัน
• การวางแผนการแก้ไขหลายขั้นตอนภายใต้ข้อจำกัด
• การสร้างสรุปที่มนุษย์อ่านได้สำหรับเหตุการณ์

ตัวกระตุ้นการยกระดับที่ไม่ดี:

• ทุกเหตุการณ์เตือน
• การละเมิดเกณฑ์คงที่ที่มี Runbook ที่รู้จัก
• การสลับสถานะความถี่สูงที่ Debounce จะช่วยลดสัญญาณรบกวนได้

การออกแบบ State Machine: หลีกเลี่ยงการสลับสถานะของการแจ้งเตือน

ปัญหา Heartbeat ส่วนใหญ่มาจากการเปลี่ยนสถานะที่ไม่เสถียร ใช้ State Machine ที่มี Hysteresis:

• healthy
• degraded
• critical
• recovering

กฎการเปลี่ยนสถานะควรรวมถึง:

• เกณฑ์การเข้าสู่สถานะ (เช่น ดิสก์ < 15% => เสื่อมสภาพ)
• เกณฑ์การออกจากสถานะ (เช่น ดิสก์ > 20% เป็นเวลา 3 ช่วง => ปกติ)
• ช่วง Debounce (N ตัวอย่างต่อเนื่อง)
• ช่วงพักการดำเนินการ (หลีกเลี่ยงการแก้ไขซ้ำๆ)

ตัวอย่าง:

yaml transitions: healthy->degraded: condition: disk_free_pct < 15 consecutive: 2 degraded->critical: condition: disk_free_pct < 8 consecutive: 1 degraded->healthy: condition: disk_free_pct > 20 consecutive: 3 critical->recovering: condition: remediation_applied == true recovering->healthy: condition: disk_free_pct > 20 consecutive: 2

สิ่งนี้ช่วยลดการสั่นสะเทือนที่มีเสียงดังได้อย่างมาก

การออกแบบ API สำหรับการรับและควบคุม Heartbeat

หากคุณเปิดเผย API ของ Heartbeat ควรทำให้ชัดเจนและเป็น Idempotent เท่าที่จะเป็นไปได้

ปลายทางที่แนะนำ:

• POST /v1/heartbeats — รับเหตุการณ์ Heartbeat
• GET /v1/agents/{id}/status — สถานะที่คำนวณล่าสุด
• POST /v1/heartbeats/{id}/ack — การรับทราบของโอเปอเรเตอร์
• POST /v1/policies/simulate — จำลองการใช้นโยบายกับเพย์โหลดตัวอย่าง

ขอบเขตความปลอดภัยสำหรับ Heartbeat ของเอเจนต์

ความสนใจของชุมชนเกี่ยวกับการ Sandboxing และการดำเนินการเอเจนต์ที่ปลอดภัยกำลังเพิ่มขึ้นด้วยเหตุผลที่ดี Heartbeat มักจะกระตุ้นการดำเนินการ ดังนั้นขอบเขตความปลอดภัยจึงเป็นสิ่งที่ไม่สามารถต่อรองได้

การควบคุมขั้นต่ำ:

• เพย์โหลด Heartbeat ที่ลงนามแล้ว (HMAC หรือ mTLS identity)
• โทเค็นเฉพาะเอเจนต์ (สิทธิ์ขั้นต่ำ)
• รายการที่อนุญาตสำหรับนโยบาย/การดำเนินการ (ไม่มีการเรียกใช้เครื่องมือตามอำเภอใจ)
• การดำเนินการใน Sandboxed สำหรับการแก้ไข
• บันทึกการตรวจสอบ สำหรับทุกการเปลี่ยนสถานะและการดำเนินการ

หากมีโมเดลเข้ามาเกี่ยวข้อง:

• ถือว่าเอาต์พุตของ LLM เป็นข้อความการวางแผนที่ไม่น่าเชื่อถือ
• ตรวจสอบการเรียกใช้เครื่องมือกับ Schema และนโยบาย
• กำหนดให้มีการตรวจสอบป้องกันที่กำหนดไว้ก่อนดำเนินการ

โดยสรุป: การตรวจจับ Heartbeat สามารถยืดหยุ่นได้; การดำเนินการของ Heartbeat จะต้องถูกจำกัด

กลยุทธ์การตรวจสอบและการดีบัก

ในการดีบักระบบ Heartbeat ให้วัดเมตริกเหล่านี้ก่อน:

• อัตราการรับ Heartbeat
• อัตราส่วน Heartbeat ที่ล่าช้า/พลาดไป
• ความหน่วงของ Probe ตามประเภท
• ความหน่วงในการประเมินนโยบาย
• อัตราการยกระดับ (%)
• ค่าใช้จ่ายโทเค็นโมเดลต่อเอเจนต์ต่อวัน
• ป้ายกำกับเหตุการณ์ False Positive และ False Negative

การทดสอบ API Heartbeat สไตล์ OpenClaw ด้วย Apidog

ระบบ Heartbeat ล้มเหลวที่ขอบเขต: เพย์โหลดที่ไม่ถูกต้อง, เหตุการณ์ที่เล่นซ้ำ, และ Race Condition Apidog ช่วยให้คุณทดสอบขอบเขตเหล่านั้นได้ในพื้นที่ทำงานเดียว

ขั้นตอนการทำงานที่ใช้งานได้จริง:

1. กำหนดปลายทาง Heartbeat โดยใช้ OpenAPI ในเครื่องมือออกแบบภาพของ Apidog
2. สร้างสถานการณ์ทดสอบสำหรับเหตุการณ์ Heartbeat ปกติ, ล่าช้า, ซ้ำซ้อน และเสียหาย
3. เพิ่มการยืนยันด้วยภาพเกี่ยวกับการเปลี่ยนสถานะและผลลัพธ์ของการดำเนินการ
4. จำลองช่องทางปลายน้ำ (Slack/webhook/บริการแก้ไข) ด้วยการตอบสนองแบบไดนามิก
5. รันชุดการทดสอบใน CI/CD เป็นเกตสำหรับการถดถอย

กรณีทดสอบตัวอย่าง

• ingest_valid_heartbeat_returns_200
• duplicate_idempotency_key_no_duplicate_action
• critical_state_triggers_single_alert_with_cooldown
• invalid_signature_returns_401
• novelty_trigger_causes_model_escalation_when_enabled

เนื่องจาก Apidog รวมการออกแบบ, การทดสอบ, การจำลอง (Mocking) และเอกสารไว้ด้วยกัน สัญญาและพฤติกรรม API ของคุณจึงสอดคล้องกันเมื่อตรรกะของ Heartbeat พัฒนาขึ้น

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

กรณีพิเศษที่วิศวกรมักจะมองข้าม

เวลาคลาดเคลื่อน

• การประทับเวลาของเอเจนต์อาจคลาดเคลื่อน
• ยอมรับความคลาดเคลื่อนที่จำกัดและเก็บเวลาที่เซิร์ฟเวอร์ได้รับแยกต่างหาก

การแบ่งพาร์ติชันเครือข่าย

• Heartbeat อาจมาถึงเป็นชุดหลังจากเชื่อมต่อใหม่
• ใช้หมายเลขลำดับและช่วงการจัดเรียงใหม่

พายุ Backpressure

• หากกลไกนโยบายช้าลง คิวอาจทำให้ความล่าช้ามากขึ้น
• ใช้การควบคุมการรับเข้าและลดประสิทธิภาพลงอย่างสง่างาม

ความล้มเหลวของ Probe แบบเงียบ

• "ไม่มีข้อมูล" ไม่ใช่ "ปกติ"
• เข้ารหัสสถานะที่ไม่รู้จักอย่างชัดเจน

ลูปการแก้ไขที่ควบคุมไม่ได้

• การดำเนินการกระตุ้นเงื่อนไขที่กระตุ้นการดำเนินการเดียวกันซ้ำๆ
• เพิ่มช่วงพักการดำเนินการต่อการดำเนินการและงบประมาณการลองใหม่สูงสุด

การเบี่ยงเบนของโมเดลในผลลัพธ์ของการยกระดับ

• เก็บอุปกรณ์การประเมินสำหรับการตัดสินใจที่ใช้โมเดลช่วย
• ตรวจสอบซ้ำเมื่อมีการเปลี่ยนแปลงโมเดล/เวอร์ชัน

หมายเหตุการย้ายข้อมูล: การเปลี่ยนชื่อจาก Moltbot/Clawdbot เป็น OpenClaw

ประวัติการเปลี่ยนชื่อทำให้เกิดความสับสนในชื่อแพ็คเกจ, เอกสาร, และคำนำหน้าปลายทาง หากคุณดูแลการรวมระบบ:

• เก็บชื่อเรียกแบบย้อนหลัง (Backward aliases) ไว้ในช่วงเวลาการเลิกใช้งาน
• กำหนดเวอร์ชัน Schema ของเหตุการณ์อย่างชัดเจน (event_version)
• เผยแพร่แผนที่การย้ายข้อมูล (ชื่อหัวข้อเก่า -> ชื่อหัวข้อใหม่)
• เพิ่มการทดสอบ Contract สำหรับเพย์โหลดทั้งแบบเดิมและแบบปัจจุบัน

สิ่งนี้ช่วยลดความเสียหายของระบบนิเวศในขณะที่ชุมชนกำลังปรับมาใช้ชื่อ OpenClaw

เกณฑ์มาตรฐานการผลิตที่แนะนำ

หากคุณต้องการค่าเริ่มต้นที่เหมาะสมสำหรับการใช้งาน Heartbeat:

• ช่วงเวลา: 30 วินาที
• ระยะหมดเวลาของ Probe: 500 มิลลิวินาทีต่อรายการ, งบประมาณรวม 2 วินาที
• Debounce: 2 ความล้มเหลวต่อเนื่องสำหรับการเตือน
• ช่วงพัก: 5 นาทีต่อประเภทการดำเนินการ
• ข้อจำกัดการยกระดับ: สูงสุด 5% ของ Heartbeat เรียกใช้โมเดล
• การเก็บรักษา: 30 วันแบบ Hot, 180 วันแบบ Cold สำหรับการตรวจสอบ

จากนั้นปรับแต่งตามปริมาณงาน เอเจนต์เดสก์ท็อปของนักพัฒนาและเอเจนต์เซิร์ฟเวอร์มักต้องการนโยบายที่แตกต่างกัน

ประเด็นสำคัญสุดท้าย

คุณสมบัติ Heartbeat ของ OpenClaw มีคุณค่าเพราะมันปฏิบัติต่อสุขภาพของเอเจนต์เหมือนเป็นลูปควบคุมที่มีระเบียบวินัย ไม่ใช่ขั้นตอนการทำงานที่เน้นการสนทนา รูปแบบที่ชนะเลิศนั้นชัดเจน:

• Probe ที่กำหนดไว้ก่อน,
• State machine ของนโยบายที่ชัดเจนเป็นอันดับสอง,
• การยกระดับด้วยโมเดลเฉพาะเมื่อมีความไม่แน่นอนเท่านั้น

การออกแบบนั้นช่วยให้คุณมีต้นทุนต่ำลง, คาดการณ์ได้แม่นยำขึ้น, และระบบอัตโนมัติที่ปลอดภัยยิ่งขึ้น

เมื่อคุณนำ API ของ Heartbeat มาใช้งาน ให้ลงทุนอย่างมากในเรื่องสัญญา, Idempotency, การจำลองนโยบาย, และระบบอัตโนมัติในการทดสอบ Apidog เหมาะสมอย่างยิ่งในที่นี้ เพราะคุณสามารถออกแบบ OpenAPI spec, จำลองการพึ่งพิง, รันการทดสอบ Regression, และเผยแพร่เอกสารได้ในที่เดียว

หากคุณกำลังสร้างหรือรวมระบบ Heartbeat สไตล์ OpenClaw อยู่ในตอนนี้ ให้เริ่มต้นด้วยกฎที่กำหนดไว้อย่างเข้มงวด และเพิ่มความฉลาดของโมเดลทีละน้อย ความน่าเชื่อถือมาจากการจำกัดขอบเขตก่อน แล้วจึงตามด้วยความฉลาด