---
title: "AI agent ของคุณกำลังรอคุณอยู่: เปลี่ยนจุดขออนุมัติให้เป็นสายโทรเข้า"
description: "agent อัตโนมัติจะหยุดรออย่างเงียบ ๆ เมื่อต้องการมนุษย์ และไม่มีอะไรในระบบ agent ที่โทรหาคุณเลย นี่คือวิธีเชื่อมจุดขออนุมัติของ agent และการรันที่ล้มเหลวเข้ากับสายโทรจริงด้วย Echobell"
date: 2026-08-07
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - แจ้งเตือนจาก AI agent
  - human in the loop
  - จุดขออนุมัติของ agent
  - แจ้งเตือนผ่าน webhook
  - แจ้งเตือนด้วยสายโทรเข้า
---

# AI agent ของคุณกำลังรอคุณอยู่: เปลี่ยนจุดขออนุมัติให้เป็นสายโทรเข้า

เฟรมเวิร์ก agent อัตโนมัติทุกตัวที่ออกมาในปี 2026 มีช่องโหว่เดียวกันหมด agent ทำงานไปหลายชั่วโมงโดยไม่มีคุณ แล้วไปเจอแอ็กชันที่มันทำเองไม่ได้ ก็หยุดรอ จากนั้นก็ไม่มีอะไรเกิดขึ้นอีกเลย การรันไม่ได้ล้มเหลว ไม่ได้ลองใหม่ มันแค่นั่งอยู่ในหน่วยความจำโดยถืออ็อบเจกต์สถานะที่ถูกซีเรียลไลซ์ไว้ รอมนุษย์ที่ไม่รู้เลยว่ามันกำลังรออยู่ คู่มือนี้จะแสดงวิธีอุดช่องว่างนั้น ด้วยการเปลี่ยนจังหวะที่ agent บอกว่า "ฉันต้องการมนุษย์" ให้กลายเป็นสายโทรที่ดังจริงด้วย [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-ai-agent-human-in-the-loop-alerts-th&mt=8)

ช่องว่างนี้เป็นเรื่องเชิงโครงสร้าง ไม่ใช่บั๊กของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง เอกสารเรื่อง agent ของ OpenAI อธิบายกระบวนการขออนุมัติไว้อย่างชัดเจนว่า เมื่อเครื่องมือหนึ่งต้องการการอนุมัติ "การรันจะหยุดจนกว่าคุณจะอนุมัติหรือปฏิเสธ" ผลลัพธ์จะคืนค่า `interruptions` พร้อมกับ `state` ที่กลับมารันต่อได้ และถ้าการตรวจสอบอาจใช้เวลา เอกสารก็บอกให้คุณซีเรียลไลซ์สถานะนั้น เก็บไว้ แล้วค่อยกลับมารันต่อ ([OpenAI](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals), [คู่มือ Agents SDK](https://openai.github.io/openai-agents-js/guides/human-in-the-loop/)) ไม่มีจุดใดในกระบวนการนั้นเลยที่ส่งข้อความไปถึงคน การแจ้งผู้อนุมัติเป็นหน้าที่ของคุณล้วน ๆ

ขณะเดียวกันการรันก็ยาวขึ้นเรื่อย ๆ AWS อธิบาย agent ระดับแนวหน้าของตนว่าสามารถ "ทำงานได้หลายชั่วโมงหรือหลายวันโดยไม่ต้องมีใครเข้ามาแทรก" ([About Amazon](https://www.aboutamazon.com/news/aws/amazon-ai-frontier-agents-autonomous-kiro)) ส่วน Kiro Crew ที่เปิดตัวเมื่อ 4 สิงหาคม 2026 พูดไว้ตรง ๆ ว่า "เริ่มงานย้ายระบบไว้แล้วมันจะเดินหน้าผ่านจุดตรวจและการลองใหม่ต่อไป ขณะที่คุณอยู่ในที่ประชุมหรือกำลังหลับ" พร้อมกับระบุว่า "คำขอใช้เครื่องมืออาจต้องได้รับการอนุมัติ" ([Kiro](https://kiro.dev/blog/introducing-kiro-crew/)) ทั้งสองครึ่งเป็นจริงพร้อมกัน คือ agent ทำงานขณะที่คุณหลับ และ agent ก็หยุดขณะที่คุณหลับด้วย

## เหตุการณ์ที่เกี่ยวกับ agent เกิดบ่อยแค่ไหนกันแน่

**บ่อยพอที่องค์กรส่วนใหญ่เคยเจอมาแล้ว และส่วนใหญ่ก็ไม่ปล่อยให้ agent ทำงานโดยไม่มีใครดูแล** จากการสำรวจผู้เชี่ยวชาญด้าน IT และความปลอดภัย 418 คนในเดือนมกราคม 2026 โดย Cloud Security Alliance ซึ่งได้รับการสนับสนุนจาก Token Security พบว่า **65%** ขององค์กรรายงานว่าเคยเจอเหตุการณ์ที่เกี่ยวข้องกับ AI agent อย่างน้อยหนึ่งครั้งในปีที่ผ่านมา โดย **61%** เกี่ยวกับข้อมูลรั่วไหล **43%** เป็นการหยุดชะงักของการดำเนินงาน และ **35%** เป็นความสูญเสียทางการเงิน ([ข่าวประชาสัมพันธ์ของ CSA](https://cloudsecurityalliance.org/press-releases/2026/04/21/new-cloud-security-alliance-survey-reveals-82-of-enterprises-have-unknown-ai-agents-in-their-environments), [รายงานฉบับเต็ม](https://cloudsecurityalliance.org/artifacts/autonomous-but-not-controlled-ai-agent-incidents-now-common-in-enterprises))

ตัวเลขด้านการกำกับดูแลจากการสำรวจเดียวกันคือส่วนที่สำคัญต่อเรื่องการแจ้งเตือน มีเพียง **13%** ที่รัน agent แบบอัตโนมัติเต็มรูปแบบ **53%** ให้ agent ทำงานเองได้ในงานความเสี่ยงต่ำ โดยให้มนุษย์ตรวจสอบแอ็กชันที่เสี่ยงกว่า และ **24%** คงมนุษย์ไว้ในกระบวนการสำหรับงานส่วนใหญ่ ส่วน **82%** พบ agent AI เงาในสภาพแวดล้อมของตนภายในปีที่ผ่านมา

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

## เกิดอะไรขึ้นจริง ๆ เมื่อ agent ต้องการมนุษย์

**มันรอ อย่างเงียบ ๆ และทุกเฟรมเวิร์กโยนเรื่องการแจ้งเตือนมาให้คุณ** กลไกต่างกันไป แต่ผลลัพธ์เหมือนกัน

| ระบบ | กลไก | สิ่งที่ไปถึงมนุษย์ |
| --- | --- | --- |
| OpenAI Agents SDK | `needsApproval` บนเครื่องมือจะหยุดการรันและคืนค่า `interruptions` พร้อม `state` ที่รันต่อได้ | ไม่มีอะไรเลย แอปพลิเคชันของคุณเป็นผู้ตัดสินว่าจะทำอย่างไรกับการหยุดนั้น |
| MCP server | `elicitation/create` ขอข้อมูลจากผู้ใช้ระหว่างการเรียกเครื่องมือ โดยคืนค่า `accept`, `decline` หรือ `cancel` | เท่าที่ UI ของ MCP client แสดงผลออกมา ซึ่งในการรันแบบไร้หน้าจอก็ไม่มีใครดูอยู่ |
| Claude Code | hook ชื่อ `Notification` ทำงานโดยมีค่า matcher เช่น `agent_needs_input` และ `agent_completed` | เท่าที่คุณเชื่อม hook นั้นไว้กับอะไร |
| Kiro Crew | คำขอใช้เครื่องมืออาจต้องได้รับการอนุมัติ และมีการบันทึกกิจกรรมไว้ให้ตรวจสอบ | หน้า Activity ถ้าคุณเปิดดู |

Model Context Protocol ระบุเรื่องนี้ไว้ชัดเจนถึงระดับสเปก elicitation มีอยู่ก็เพื่อให้เซิร์ฟเวอร์ถามมนุษย์ได้ระหว่างการรัน และสเปกฉบับปัจจุบัน (`2026-07-28`) เตือนว่าเซิร์ฟเวอร์ "**ไม่ควร** สันนิษฐานว่าคำขอ elicitation จะสำเร็จเสมอ" และต้องรองรับกรณีปฏิเสธ ยกเลิก และไคลเอนต์ล้มเหลว ([สเปก MCP](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation)) โปรโตคอลทำให้ "คำถาม" เป็นมาตรฐาน แต่ไม่ได้ และทำไม่ได้ ที่จะทำให้ "การเรียกความสนใจจากมนุษย์" เป็นมาตรฐานไปด้วย

นั่นแหละคือโอกาสทั้งหมด ทุกชั้นของระบบ agent มีจุดหยุดที่ออกแบบมาอย่างดี แต่ไม่มีชั้นไหนมีเบอร์โทรศัพท์เลย

## เหตุการณ์ของ agent แบบไหนที่สมควรได้รับสายโทร

**มีสองแบบ และคุณควรเข้มงวดกับที่เหลือ** สายโทรเป็นทรัพยากรที่หายาก ใช้มันเฉพาะตรงที่มนุษย์ที่กำลังหลับคือตัวติดขัดจริง ๆ

1. **การขออนุมัติที่ค้างอยู่ในการรันซึ่งเดินหน้าต่อไม่ได้ถ้าไม่มีมัน** agent อยู่เฉย ๆ นาฬิกาเดินไปเรื่อย ๆ และรอไปนานแค่ไหนก็ไม่คลี่คลาย นี่คือกรณีต้นแบบ
2. **ความล้มเหลวขั้นสุดท้ายของการรันยาว ๆ ที่ไม่มีใครเฝ้า** งานย้ายระบบหกชั่วโมงที่ตายไปตั้งแต่ชั่วโมงที่สอง คือหกชั่วโมงที่คุณเรียกคืนไม่ได้ และคุณย่อมอยากรู้ตั้งแต่ชั่วโมงที่สองมากกว่า

เรื่องอื่นทั้งหมดควรอยู่ในช่องที่เงียบกว่า "งานทำสำเร็จแล้ว" คือพุชปกติ "agent ใช้งบไปแล้ว 80%" อย่างมากก็แค่สำคัญตามเวลา ส่วน "agent เริ่มทำงาน" ไม่ควรเป็นการแจ้งเตือนเลยด้วยซ้ำ [ประเภทการแจ้งเตือน](/th/docs/notification)ทั้งสามของ Echobell ทั้งมาตรฐาน สำคัญตามเวลา และโทรเข้า มีไว้เพื่อการคัดแยกแบบนี้พอดี และการจับคู่เหตุการณ์ของ agent เข้ากับสามระดับนี้คือการตัดสินใจเชิงออกแบบที่สำคัญที่สุดในเรื่องนี้ ถ้าคุณกำลังสู้กับปริมาณการแจ้งเตือนอยู่แล้ว ให้อ่าน[การแก้ปัญหาความล้าจากการแจ้งเตือน](/th/blog/fix-alert-fatigue-developer-guide)ก่อนจะเพิ่มช่องที่ส่งเสียงเรียก

## วิธีเชื่อมจุดขออนุมัติของ agent เข้ากับสายโทร

Echobell เปลี่ยน webhook หรืออีเมลให้เป็นสายโทรเข้า สายที่ดังจริง สั่นจริง และทะลุโหมดโฟกัสกับโหมดห้ามรบกวนของ iOS ได้เหมือนสายจากคนในครอบครัว (ดู[การทะลุโหมดโฟกัสของ iOS](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)) มันอยู่ระหว่าง agent ที่หยุดรอกับมนุษย์ที่ปลดล็อกให้มันเดินต่อได้

### ขั้นที่ 1 — สร้างช่องแบบโทรเข้าสำหรับ agent ที่ติดค้าง

สร้างช่องในแอปแล้วตั้งประเภทการแจ้งเตือนเป็น **โทรเข้า** ตั้งชื่อให้ไม่กำกวม เช่น "Agent blocked — needs approval" แล้วใช้กับเรื่องอื่นเด็ดขาด คัดลอก URL ของ webhook จากหน้ารายละเอียดช่อง หน้าตาจะประมาณ `https://hook.echobell.one/t/<channel-token>` ให้ถือว่าเป็นความลับ เพราะใครก็ตามที่ถือมันไว้ก็โทรหาคุณได้ ([คู่มือ webhook](/th/docs/webhook))

ตั้งเทมเพลตหัวข้อและเนื้อหาให้เป็นสิ่งที่คุณลงมือต่อได้จากหน้าจอล็อก:

```
Title: Agent blocked: {{agent}}
Body: Waiting on {{action}} in {{project}} — since {{time}} UTC
```

`{{time}}` และ[ตัวแปรเวลาของระบบ](/th/docs/template)ตัวอื่นมีให้ใช้เสมอในรูปแบบ UTC โดยที่คุณไม่ต้องส่งมาเอง

### ขั้นที่ 2 — ยิง webhook จากสาขาการขออนุมัติของคุณ

ใน SDK ใดก็ตามที่คืนค่า interruptions จุดหยุดนั้นก็คือสาขาปกติในโค้ดของคุณ ให้ POST ไปยัง URL ของช่องก่อนจะพักการรันไว้:

```javascript
let result = await run(agent, input, { stream: false });

if (result.interruptions?.length) {
  await fetch(process.env.ECHOBELL_BLOCKED_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      agent: agent.name,
      action: result.interruptions[0].rawItem.name,
      project: process.env.PROJECT_NAME,
      externalLink: `https://ops.example.com/runs/${runId}`,
    }),
  });
  await saveState(runId, result.state); // ซีเรียลไลซ์ไว้แล้วรันต่อหลังได้รับอนุมัติ
}
```

ตัวแปรพิเศษ `externalLink` จะกลายเป็นลิงก์ที่คลิกได้ในบันทึกการแจ้งเตือน คนที่รับสายจึงเข้าถึงการรันนั้นได้ทันทีโดยไม่ต้องไปไล่หา

### ขั้นที่ 3 — ใช้ hook เมื่อ agent เป็น CLI ไม่ใช่ไลบรารี

Claude Code เปิด hook ชื่อ `Notification` ที่ matcher กรองตามประเภทการแจ้งเตือนได้ รวมถึง `agent_needs_input` และ `agent_completed` และตัวจัดการ hook เป็นคำสั่งเชลล์หรือการ POST แบบ HTTP โดยตรงก็ได้ ([เอกสารอ้างอิงเรื่อง hook](https://code.claude.com/docs/en/hooks)) ตัวจัดการแบบ `command` ให้คุณควบคุมรูปร่างของ payload ได้ ซึ่งสำคัญเพราะ Echobell แสดงผลตามคีย์ JSON ที่คุณส่งไป:

```json
{
  "hooks": {
    "Notification": [
      {
        "matcher": "agent_needs_input",
        "hooks": [
          {
            "type": "command",
            "command": "jq -c '{agent: \"claude-code\", action: .message, project: .cwd}' | curl -sS -X POST -H 'Content-Type: application/json' -d @- \"$ECHOBELL_BLOCKED_URL\""
          }
        ]
      }
    ]
  }
}
```

ข้อมูลนำเข้าของ hook มาถึงในรูปแบบ JSON ทาง stdin สำหรับตัวจัดการแบบ `command` โดยมีฟิลด์อย่าง `session_id`, `cwd`, `hook_event_name` และ `permission_mode` ส่วนตัวจัดการชนิด `http` จะ POST JSON ชุดเดียวกันนั้นไปยัง URL ตรง ๆ โดยไม่ต้องมีสคริปต์เลย ซึ่งน่าใช้อยู่ แต่มันก็คาดหวังให้ผลตอบกลับเป็นเอกสารผลลัพธ์ของ hook ซึ่งผลตอบกลับของ Echobell ไม่ใช่แบบนั้น ให้ใช้ `command` เว้นแต่คุณจะยืนยันแล้วว่า `http` ทำงานอย่างที่ต้องการในระบบของคุณ

### ขั้นที่ 4 — จับ agent ที่ส่งได้แต่อีเมล

แพลตฟอร์ม agent บริการรันตามกำหนดเวลา และเครื่องมือภายในจำนวนมากรายงานผลทางอีเมลอย่างเดียว ทุกช่องของ Echobell มีที่อยู่อีเมลของตัวเองได้ กฎการส่งต่อเพียงข้อเดียวจึงเปลี่ยนข้อความเหล่านั้นให้เป็นสายโทรได้ ([ทริกเกอร์อีเมล](/th/docs/email-trigger), [การตั้งค่าอีเมลเป็นสายโทร](/th/docs/email-to-call)) ทริกเกอร์อีเมลเปิดตัวแปร `from`, `to`, `subject`, `text` และ `html` ให้ใช้ในเทมเพลต คุณจึงสร้างเงื่อนไขจากบรรทัดหัวข้อได้โดยไม่ต้องแยกวิเคราะห์อะไรเอง

### ขั้นที่ 5 — เพิ่มเงื่อนไขเพื่อให้ดังเฉพาะกรณีที่ติดค้างจริง

**ช่องที่ดังทุกครั้งที่มีเหตุการณ์ของ agent จะเลิกเป็นสายโทรและกลายเป็นเสียงรบกวนพื้นหลัง** [เงื่อนไข](/th/docs/conditions)ของ Echobell กรองจากค่าตัวแปรด้วยไวยากรณ์นิพจน์เดียวกับเทมเพลต คุณจึงกำหนดได้ เช่น:

```
blocking == true && risk == "high"
```

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

### ขั้นที่ 6 — ทดสอบขณะเปิดโหมดห้ามรบกวน

ทริกเกอร์ช่องด้วย `curl` ขณะที่เปิดโหมดห้ามรบกวนอยู่บนเครื่องที่จะรับสายจริง:

```bash
curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{"agent":"test","action":"deploy to prod","project":"demo","blocking":true,"risk":"high"}'
```

เปิด **โทรซ้ำเมื่อสายไม่ติด** ในแอป เพื่อให้ระบบพยายามโทรอีกครั้งเมื่อสายถูกโหมดโฟกัสสกัดไว้ เส้นทางการยกระดับที่ไม่เคยทดสอบก็เป็นแค่ข้อสันนิษฐาน

## แบบนี้จะเป็นการสร้างความล้าจากการแจ้งเตือนขึ้นใหม่ด้วยกระดิ่งที่ดังกว่าเดิมหรือเปล่า

**ใช่ ถ้าคุณข้ามขั้นที่ 5** ความล้มเหลวแบบนี้เกิดขึ้นได้จริงและควรพูดถึงตรง ๆ agent สร้างเหตุการณ์มากกว่าเซิร์ฟเวอร์หลายเท่า ทั้งการเรียกเครื่องมือทุกครั้ง จุดตรวจทุกจุด และการลองใหม่ทุกรอบ ความอยากจะส่งทั้งหมดนั้นไปยังที่ที่มองเห็นได้จึงรุนแรงมาก

วินัยที่ได้ผลคือ สงวนสายโทรไว้เฉพาะเหตุการณ์ที่การหลับอยู่ของมนุษย์เป็นสิ่งเดียวที่ขวางระหว่าง agent กับความคืบหน้า ซึ่งเป็นกลุ่มที่เล็กกว่า "เรื่องสำคัญที่ agent ทำ" อยู่มาก ถ้าคุณอธิบายไม่ได้ในประโยคเดียวว่าคนที่รับสายจะทำอะไรในเก้าสิบวินาทีถัดมา เรื่องนั้นก็ไม่สมควรได้รับสายโทร

ยังมีเหตุผลด้านความปลอดภัยที่ควรตั้งเกณฑ์ไว้สูงด้วย การสำรวจของ CSA ชุดเดียวกันพบว่าองค์กรจัดให้ความเสี่ยงของแอ็กชัน (**63%**) และการอนุญาตโดยมนุษย์ (**53%**) เป็นสัญญาณหลักด้านการกำกับดูแล สัญญาณเหล่านั้นจะมีความหมายก็ต่อเมื่อการอนุญาตโดยมนุษย์เกิดขึ้นได้จริงอย่างรวดเร็ว จุดขออนุมัติที่ถูกตอบช้าไปแปดชั่วโมงเป็นประจำจะฝึกให้ทุกคนอยากขยายประตูให้กว้างขึ้น ซึ่งเป็นวิธีที่ตัวเลข **13%** ของการทำงานอัตโนมัติเต็มรูปแบบค่อย ๆ กลายเป็นค่าเริ่มต้นด้วยเหตุผลที่ผิด

## สิ่งที่ Echobell ไม่ได้ทำ

การพูดให้ชัดตรงนี้สำคัญ เพราะโครงสร้างพื้นฐานด้าน agent มักดึงดูดการกล่าวอ้างเกินจริง

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

**Echobell ไม่ได้ทำสิ่งเหล่านี้:**

- **อนุมัติอะไรทั้งสิ้น** มันไม่ใช่ UI สำหรับการอนุมัติและไม่ได้เชื่อมกับสถานะของ agent ของคุณ มันแค่โทรหาคุณ ส่วนคุณก็ยังต้องเปิดโน้ตบุ๊ก แดชบอร์ด หรือเทอร์มินัลเพื่ออนุมัติหรือปฏิเสธ ไม่มี "กด 1 เพื่ออนุมัติ"
- **รันงานต่อให้** การซีเรียลไลซ์และกู้คืนสถานะของ agent เป็นหน้าที่ของเฟรมเวิร์กของคุณ Echobell ไม่แตะต้องมันเลย
- **จัดหานโยบายการยกระดับ การรับทราบ หรือการหมุนเวร on-call** ไม่มี "ถ้าไม่มีใครรับภายในห้านาที ให้โทรหาคนถัดไป" มันโทรหาผู้ติดตามของช่องเท่านั้น ถ้าคุณต้องการตารางหมุนเวรและการติดตามการรับทราบ คุณต้องใช้แพลตฟอร์มจัดการเหตุการณ์ ดูเครื่องมือกลุ่มนั้นได้ที่[การเปรียบเทียบทางเลือกแทน Opsgenie](/th/blog/opsgenie-end-of-life-alternatives)
- **ทำให้ agent ของคุณปลอดภัย** ไม่มีอะไรในนี้ที่จัดการกับ agent เงา สิทธิ์การใช้เครื่องมือที่กว้างเกินไป หรือช่องว่างเรื่องการปลดระวางที่รายงานของ CSA อธิบายไว้ การทำให้มนุษย์สนใจได้เร็วขึ้นเป็นการบรรเทาการตอบสนองที่ช้า ไม่ใช่การแก้สถาปัตยกรรมที่ไม่ดี
- **รับประกันการนำส่ง** สายโทรขึ้นอยู่กับโครงสร้างพื้นฐานการส่งพุช เครือข่าย และโทรศัพท์ที่มีแบตเตอรี่ ให้มองว่ามันเป็นชั้นที่ย่นเวลารอ ไม่ใช่มาตรการควบคุมที่พึ่งพาได้อย่างเด็ดขาด

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

## คำถามที่พบบ่อย

### ฉันอนุมัติแอ็กชันของ agent จากสายโทรได้เลยไหม

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

### เหตุการณ์ของเฟรมเวิร์กแบบไหนที่ควรทริกเกอร์ webhook

เหตุการณ์ที่ทำให้การรันเดินหน้าต่อไม่ได้ ใน OpenAI Agents SDK ก็คืออาร์เรย์ `interruptions` ที่ไม่ว่าง ใน MCP ก็คือคำขอ `elicitation/create` ที่ไคลเอนต์ของคุณตอบไม่ได้ถ้าไม่มีมนุษย์ ส่วนใน Claude Code ก็คือ hook ชื่อ `Notification` ที่มี matcher เป็น `agent_needs_input` ส่วนเหตุการณ์แจ้งว่างานเสร็จควรอยู่ในช่องแบบมาตรฐานหรือสำคัญตามเวลา ไม่ใช่ช่องแบบโทรเข้า

### ใช้ได้กับ agent แบบไร้หน้าจอใน CI ไหม

ได้ และเป็นจุดที่สำคัญที่สุดด้วย เพราะไม่มีใครนั่งเฝ้าเทอร์มินัลอยู่ ขั้นตอนใดใน CI ที่รัน `curl` ได้ก็ทริกเกอร์ช่องได้ ให้ POST ที่สาขาความล้มเหลวของงานยาว ๆ แทนที่จะทำในทุก job ไม่อย่างนั้นไปป์ไลน์ของคุณจะกลายเป็นสิ่งที่เสียงดังที่สุดที่คุณมี

### แล้ว elicitation ของ MCP โดยเฉพาะล่ะ

elicitation ออกแบบมาสำหรับไคลเอนต์ที่มีผู้ใช้อยู่ตรงนั้นเพื่อแสดงคำถามให้เห็น ในการรันที่ไม่มีใครเฝ้าก็ไม่มีใครให้แสดงผลให้ดู และสเปกก็บอกเซิร์ฟเวอร์ไว้ชัดเจนให้รองรับกรณีปฏิเสธและยกเลิก แทนที่จะสันนิษฐานว่าจะได้คำตอบ รูปแบบที่สมเหตุสมผลคือให้ตัวห่อหุ้ม MCP client ยิง webhook ของ Echobell เมื่อได้รับคำขอ elicitation ที่ตอบเองไม่ได้ แล้วค่อยพักไว้หรือยกเลิกตามนโยบายของคุณเอง

### ใส่ผลลัพธ์ของ agent ลงในการแจ้งเตือนปลอดภัยไหม

ส่งให้น้อยที่สุดเท่าที่จะทำได้ ควรส่งตัวระบุและลิงก์แทนผลลัพธ์จริงของ agent โดยใช้ `externalLink` ชี้ไปยังบันทึกการรันในระบบที่สร้างมาเพื่อเก็บข้อมูลนั้น Echobell เก็บเนื้อหาและประวัติการแจ้งเตือนไว้บนเครื่องของคุณเท่านั้น โดยมีเพียงข้อมูลบัญชี ช่อง และการติดตามอยู่บนเซิร์ฟเวอร์ ([แนวคิดด้านความเป็นส่วนตัว](/th/docs/features)) ซึ่งดีต่อการลดข้อมูลให้น้อยที่สุด แต่ก็ไม่ใช่เหตุผลที่จะส่งมากเกินความจำเป็น

### ทั้งทีมของฉันรับการแจ้งเตือนจาก agent ชุดเดียวกันได้ไหม

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

### ใช้ได้เฉพาะบน iOS ใช่ไหม

ไม่ใช่ Echobell ทำงานทั้งบน iOS และบน Android ผ่าน Google Play (ดู[การเปิดตัวเวอร์ชัน Android](/th/blog/echobell-android-release)) พฤติกรรมของการแจ้งเตือนแบบสายโทรต่างกันไปในแต่ละแพลตฟอร์ม จึงควรทดสอบบนเครื่องที่คนอยู่เวรพกจริง

### ต่างจากการตั้งค่าแบบ WebhookMCP อย่างไร

[WebhookMCP](/th/blog/get-notified-with-webhook-mcp) ให้เครื่องมือแก่โมเดลเพื่อให้มันเลือกเรียกได้เมื่องานเสร็จ ซึ่งมีประโยชน์ แต่ก็ขึ้นอยู่กับว่า agent จะตัดสินใจแจ้งคุณหรือไม่ ส่วนวิธีในบทความนี้ยิงจากโค้ดของคุณเองหรือจาก hook ของเฟรมเวิร์ก จึงทำงานได้แม้ agent จะติดค้าง สับสน หรือแครชไปแล้ว ใช้ทั้งสองอย่างเลยก็ได้ อันหนึ่งสำหรับ "เสร็จแล้ว" อีกอันสำหรับ "ติดค้างอยู่"

---

## บทความที่เกี่ยวข้อง

- [รับการแจ้งเตือนเมื่องาน AI เสร็จด้วย WebhookMCP](/th/blog/get-notified-with-webhook-mcp)
- [วิธีทะลุโหมดโฟกัสของ iOS สำหรับการแจ้งเตือนวิกฤต](/th/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [แก้ปัญหาความล้าจากการแจ้งเตือน: คู่มือสำหรับนักพัฒนา](/th/blog/fix-alert-fatigue-developer-guide)
- [การแจ้งเตือนเมื่อ cron job ล้มเหลว](/th/blog/cron-job-failure-alerts)
- [คู่มือการเชื่อมต่อ Webhook](/th/docs/webhook)
- [คู่มือเรื่องเงื่อนไข](/th/docs/conditions)