Mainstream messaging
สถานะ: พร้อมใช้งานจริงผ่าน WhatsApp Web (Baileys) Gateway เป็นเจ้าของเซสชันที่เชื่อมโยงไว้ทั้งหมด และไม่มีช่องทาง Twilio WhatsApp แยกต่างหาก
การติดตั้ง
openclaw onboard และ openclaw channels add --channel whatsapp จะแจ้งให้ติดตั้ง Plugin เมื่อคุณเลือกใช้งานครั้งแรก ส่วน openclaw channels login --channel whatsapp จะเสนอกระบวนการติดตั้งเดียวกันหากยังไม่มี Plugin เช็กเอาต์สำหรับการพัฒนาจะใช้พาธ Plugin ภายในเครื่อง ส่วนการติดตั้งรุ่นเสถียร/เบตาจะติดตั้ง @openclaw/whatsapp จาก ClawHub ก่อน และใช้ npm เป็นทางเลือกสำรอง รันไทม์ WhatsApp จัดส่งแยกจากแพ็กเกจ npm หลักของ OpenClaw ดังนั้นการขึ้นต่อกันของรันไทม์จึงอยู่กับ Plugin ภายนอก การติดตั้งด้วยตนเอง:
openclaw plugins install clawhub:@openclaw/whatsappใช้แพ็กเกจ npm แบบไม่มีคำนำหน้า (@openclaw/whatsapp) สำหรับกรณีสำรองผ่านรีจิสทรีเท่านั้น และตรึงเวอร์ชันที่แน่นอนเฉพาะเมื่อต้องการให้การติดตั้งทำซ้ำได้อย่างเหมือนเดิม
นโยบาย DM เริ่มต้นสำหรับผู้ส่งที่ไม่รู้จักคือการจับคู่
แนวทางวินิจฉัยและคู่มือแก้ไขปัญหาที่ใช้ร่วมกันระหว่างช่องทาง
รูปแบบและตัวอย่างการกำหนดค่าช่องทางฉบับเต็ม
การตั้งค่าอย่างรวดเร็ว
Configure access policy
{channels: {whatsapp: { dmPolicy: "pairing", allowFrom: ["+15551234567"], groupPolicy: "allowlist", groupAllowFrom: ["+15551234567"],},},}Link WhatsApp (QR)
openclaw channels login --channel whatsappการเข้าสู่ระบบรองรับเฉพาะ QR เท่านั้น สำหรับโฮสต์ระยะไกลหรือโฮสต์ที่ไม่มีส่วนแสดงผล ให้เตรียมช่องทางที่เชื่อถือได้สำหรับส่ง QR ที่ยังใช้งานได้ไปยังโทรศัพท์ก่อนเริ่มเข้าสู่ระบบ เนื่องจาก QR ที่แสดงในเทอร์มินัล ภาพหน้าจอ หรือไฟล์แนบในแชตอาจหมดอายุระหว่างการส่ง
สำหรับบัญชีที่ระบุ:
openclaw channels login --channel whatsapp --account workหากต้องการผูกไดเรกทอรีการยืนยันตัวตนที่มีอยู่หรือกำหนดเองก่อนเข้าสู่ระบบ:
openclaw channels add --channel whatsapp --account work --auth-dir /path/to/wa-authopenclaw channels login --channel whatsapp --account workStart the gateway
openclaw gatewayApprove the first pairing request (pairing mode)
openclaw pairing list whatsappopenclaw pairing approve whatsapp <CODE>คำขอจับคู่จะหมดอายุหลังจาก 1 ชั่วโมง และจำกัดคำขอที่รอดำเนินการไว้ไม่เกิน 3 รายการต่อบัญชี
รูปแบบการนำไปใช้งาน
Dedicated number (recommended)
- ข้อมูลประจำตัว WhatsApp แยกต่างหากสำหรับ OpenClaw
- รายการอนุญาต DM และขอบเขตการกำหนดเส้นทางชัดเจนยิ่งขึ้น
- ลดโอกาสเกิดความสับสนจากการแชตกับตนเอง
{ channels: { whatsapp: { dmPolicy: "allowlist", allowFrom: ["+15551234567"], }, },}Personal-number fallback
กระบวนการเริ่มต้นใช้งานรองรับโหมดหมายเลขส่วนตัวและเขียนค่าพื้นฐานที่เหมาะกับการแชตกับตนเอง ได้แก่ dmPolicy: "allowlist", allowFrom ที่มีหมายเลขของคุณเอง และ selfChatMode: true การป้องกันการแชตกับตนเองของรันไทม์อ้างอิงหมายเลขของตนเองที่เชื่อมโยงไว้ร่วมกับ allowFrom
โมเดลรันไทม์
- Gateway เป็นเจ้าของซ็อกเก็ต WhatsApp และลูปการเชื่อมต่อใหม่
- ตัวเฝ้าระวังติดตามสัญญาณสองรายการแยกจากกัน ได้แก่ กิจกรรมการขนส่งดิบของ WhatsApp Web และกิจกรรมข้อความของแอปพลิเคชัน เซสชันที่ไม่มีข้อความแต่ยังเชื่อมต่ออยู่จะไม่เริ่มใหม่เพียงเพราะไม่มีข้อความเข้ามาเมื่อไม่นานมานี้ ระบบจะบังคับให้เชื่อมต่อใหม่เฉพาะเมื่อไม่มีเฟรมการขนส่งเข้ามาภายในช่วงเวลาภายในที่กำหนดตายตัว (ผู้ใช้กำหนดค่าไม่ได้) หรือไม่มีข้อความของแอปพลิเคชันนานเกิน 4 เท่าของระยะหมดเวลาข้อความปกติ ทันทีหลังเชื่อมต่อใหม่สำหรับเซสชันที่เพิ่งมีกิจกรรม ช่วงแรกจะใช้ระยะหมดเวลาข้อความปกติที่สั้นกว่าแทนช่วงเวลา 4 เท่า OpenClaw สามารถตอบกลับข้อความออฟไลน์ที่ Baileys ส่งมาในช่วงต้นของการเชื่อมต่อใหม่นั้นโดยอัตโนมัติ ภายใต้ขอบเขตอายุการขจัดข้อความซ้ำตามรหัสข้อความขาเข้า ส่วนการเริ่มทำงานครั้งแรกยังคงใช้การป้องกันประวัติเก่าระยะสั้น
- การกำหนดเวลาซ็อกเก็ต Baileys ระบุไว้อย่างชัดเจนภายใต้
web.whatsapp.*:keepAliveIntervalMs(ช่วงเวลาการส่ง ping ของแอปพลิเคชัน),connectTimeoutMs(ระยะหมดเวลาของการจับมือเปิดการเชื่อมต่อ),defaultQueryTimeoutMs(ระยะรอคิวรีของ Baileys รวมถึงระยะหมดเวลาการส่งขาออก/การแสดงสถานะของ OpenClaw และใบตอบรับการอ่านข้อความขาเข้า) - การส่งขาออกต้องมีตัวรับฟัง WhatsApp ที่ใช้งานอยู่สำหรับบัญชีเป้าหมาย มิฉะนั้นการส่งจะล้มเหลวทันที
- การส่งไปยังกลุ่มจะแนบข้อมูลเมตาการกล่าวถึงแบบเนทีฟสำหรับโทเค็น
@+<digits>และ@<digits>(ทั้งในข้อความและคำบรรยายสื่อ) เมื่อโทเค็นตรงกับข้อมูลเมตาผู้เข้าร่วมปัจจุบัน รวมถึงกลุ่มที่รองรับด้วย LID - ระบบจะละเว้นแชตสถานะและแชตออกอากาศ (
@status,@broadcast) - แชตโดยตรงใช้กฎเซสชัน DM (
session.dmScope; ค่าเริ่มต้นmainจะรวม DM เข้าไว้ในเซสชันหลักของเอเจนต์) เซสชันกลุ่มจะแยกตาม JID (agent:<agentId>:whatsapp:group:<jid>) - สามารถกำหนด WhatsApp Channels/Newsletters เป็นเป้าหมายขาออกโดยชัดแจ้งผ่าน JID แบบเนทีฟ
@newsletterโดยใช้ข้อมูลเมตาเซสชันช่องทาง (agent:<agentId>:whatsapp:channel:<jid>) แทนความหมายแบบ DM - การขนส่ง WhatsApp Web รองรับตัวแปรสภาพแวดล้อมพร็อกซีมาตรฐานบนโฮสต์ Gateway (
HTTPS_PROXY,HTTP_PROXY,NO_PROXYรวมถึงรูปแบบตัวพิมพ์เล็ก) ควรใช้การกำหนดค่าพร็อกซีระดับโฮสต์แทนการตั้งค่าแยกต่อช่องทาง - เมื่อเปิดใช้
messages.removeAckAfterReplyOpenClaw จะล้างรีแอ็กชันตอบรับเมื่อส่งคำตอบที่มองเห็นได้สำเร็จแล้ว
โทรหาผู้ร้องขอปัจจุบันด้วย MeowCaller (ทดลอง)
Plugin สามารถเปิดให้ใช้ whatsapp_call ในรอบการทำงานของเอเจนต์ที่มาจาก WhatsApp โดยใช้ MeowCaller เพื่อโทรด้วยเสียงผ่าน WhatsApp ไปยังผู้ร้องขอปัจจุบันที่ได้รับอนุญาต และเล่นข้อความ TTS ของ OpenClaw หลังจากผู้รับสาย เครื่องมือนี้ไม่มีพารามิเตอร์หมายเลขปลายทาง ดังนั้นพรอมต์จึงเปลี่ยนเส้นทางการโทรไม่ได้ ปิดใช้งานโดยค่าเริ่มต้น
Enable experimental calls
เพิ่ม actions.calls: true ในการกำหนดค่าช่องทาง WhatsApp แล้วเริ่ม Gateway ใหม่:
{"channels": {"whatsapp": { "actions": { "calls": true }}}}เมื่อไม่มีค่านี้หรือเป็น false OpenClaw จะไม่เปิดให้ใช้เครื่องมือ whatsapp_call
Install the reviewed MeowCaller CLI
อะแดปเตอร์คาดว่าจะพบไฟล์ปฏิบัติการ meowcaller ใน PATH ของโฮสต์ Gateway จนกว่า MeowCaller PR #7 จะถูกรวม ให้สร้างจากแบรนช์ที่ผ่านการตรวจสอบแล้ว:
git clone --branch feat/send-only-notify https://github.com/steipete/meowcaller.gitcd meowcallergit checkout 752050471fc2bf7a8cdfbf7dbd3cd4e865d85d3fmkdir -p "$HOME/.local/bin"go build -o "$HOME/.local/bin/meowcaller" ./cmd/meowcallerตรวจสอบให้แน่ใจว่า $HOME/.local/bin อยู่ใน PATH ของบริการ Gateway รุ่นแก้ไขนี้มีคำสั่ง pair และ notify สำหรับการส่งเท่านั้นอย่างชัดเจน โดย notify จะไม่เปิดไมโครโฟน ลำโพง อุปกรณ์วิดีโอ หรือการบันทึกข้อมูลวินิจฉัย ห้ามใช้คำสั่ง play จาก CLI ตัวอย่างของต้นทางแทน
Pair the MeowCaller linked device
ขอให้เอเจนต์ WhatsApp ตรวจสอบการตั้งค่าการโทร (การดำเนินการสถานะของ whatsapp_call จะรายงานไดเรกทอรีสถานะเฉพาะบัญชีและคำสั่งจับคู่) สำหรับบัญชีเริ่มต้น:
state_dir="$HOME/.openclaw/credentials/whatsapp-calls/default"mkdir -p "$state_dir"chmod 700 "$state_dir"meowcaller pair --store "$state_dir/wa-voip.db"เรียกใช้แบบโต้ตอบ สแกน QR จาก WhatsApp > Linked devices และรอข้อความ MeowCaller linked device ready เก็บ wa-voip.db ไว้เป็นความลับ เนื่องจากเป็นเซสชัน MeowCaller บัญชีที่ไม่ใช่บัญชีเริ่มต้นจะได้รับพาธพื้นที่จัดเก็บของตนเองจากการดำเนินการสถานะ ส่วนบน Windows ให้เรียกใช้คำสั่ง PowerShell ที่ระบบระบุ
Configure TTS and call from WhatsApp
กำหนดค่าผู้ให้บริการ TTSที่รองรับระบบโทรศัพท์ เริ่ม Gateway ใหม่ แล้วส่งคำขอ เช่น Call me and say the build finished. เครื่องมือจะระบุผู้ส่งจากบริบทขาเข้าที่เชื่อถือได้ สังเคราะห์ไฟล์ WAV ส่วนตัวชั่วคราว เรียกใช้ MeowCaller ภายในช่วงเวลาการโทรที่จำกัด และลบไฟล์เสียงหลังจากนั้น OpenClaw จะส่งพื้นที่จัดเก็บของบัญชีอย่างชัดเจน รอสถานะออกเป็นศูนย์หลังรับสาย/เล่นเสียง/วางสาย และถือว่าการหมดเวลาหรือสถานะออกที่ไม่ใช่ศูนย์เป็นการเรียกเครื่องมือที่ล้มเหลว
ข้อจำกัด: รองรับเฉพาะการโทรด้วยเสียงขาออกแบบหนึ่งต่อหนึ่ง ไม่มีหมายเลขปลายทางที่กำหนดได้ตามอำเภอใจ ไม่ใช้การยืนยันตัวตนร่วมกับการเชื่อมต่อแชต ไม่รองรับการโทรหาตนเองจากโหมดหมายเลขส่วนตัว/แชตกับตนเอง จำกัดเสียงสังเคราะห์ไว้ที่ 60 วินาที ไม่มีใบตอบรับการได้ยินจากฝั่งโทรศัพท์นอกเหนือจากการเสร็จสิ้นขั้นตอนรับสาย/เล่นเสียง/วางสายของ MeowCaller และ OpenClaw จะหยุดกระบวนการร่วมหลังจากช่วงเวลาจำกัด 115–175 วินาที (ครอบคลุมขั้นตอนการเชื่อมต่อ การรับสาย การเล่นเสียง และการปิดระบบของ MeowCaller)
พรอมต์การอนุมัติ
WhatsApp สามารถแสดงพรอมต์อนุมัติการดำเนินการและ Plugin เป็นรีแอ็กชัน 👍/👎 โดยควบคุมผ่านการกำหนดค่าการส่งต่อการอนุมัติระดับบนสุด:
{ approvals: { exec: { enabled: true, mode: "session", }, plugin: { enabled: true, mode: "targets", targets: [{ channel: "whatsapp", to: "+15551234567" }], }, },}approvals.exec และ approvals.plugin ทำงานแยกจากกัน การเปิดใช้ WhatsApp เป็นช่องทางจะเชื่อมโยงเฉพาะการขนส่งและจะไม่ส่งสิ่งใด เว้นแต่จะเปิดใช้กลุ่มการอนุมัติที่ตรงกันและกำหนดเส้นทางมายังช่องทางนี้ โหมดเซสชันจะส่งการอนุมัติด้วยอีโมจิแบบเนทีฟเฉพาะสำหรับการอนุมัติที่มีต้นทางจาก WhatsApp เท่านั้น โหมดเป้าหมายใช้กระบวนการส่งต่อร่วมสำหรับเป้าหมายที่ระบุอย่างชัดเจน และไม่สร้างการกระจาย DM แยกไปยังผู้อนุมัติ
รีแอ็กชันการอนุมัติของ WhatsApp ต้องระบุผู้อนุมัติอย่างชัดเจนใน allowFrom (หรือ "*") defaultTo กำหนดเป้าหมายข้อความเริ่มต้นทั่วไป ไม่ใช่รายชื่อผู้อนุมัติ คำสั่ง /approve ที่ดำเนินการด้วยตนเองยังคงต้องผ่านกระบวนการอนุญาตผู้ส่ง WhatsApp ตามปกติก่อนแก้ไขผลการอนุมัติ
ฮุกของ Plugin และความเป็นส่วนตัว
ข้อความ WhatsApp ขาเข้าอาจมีเนื้อหาส่วนบุคคล หมายเลขโทรศัพท์ ตัวระบุกลุ่ม ชื่อผู้ส่ง และฟิลด์เชื่อมโยงเซสชัน WhatsApp จะไม่กระจายเพย์โหลดฮุก message_received ขาเข้าไปยัง Plugin เว้นแต่คุณจะเลือกเปิดใช้:
{ channels: { whatsapp: { pluginHooks: { messageReceived: true, }, }, },}จำกัดขอบเขตการเลือกเปิดใช้ไว้ที่บัญชีเดียวภายใต้ channels.whatsapp.accounts.<id>.pluginHooks.messageReceived เปิดใช้เฉพาะกับ Plugin ที่คุณไว้วางใจให้เข้าถึงเนื้อหาและตัวระบุ WhatsApp ขาเข้าเท่านั้น
การควบคุมการเข้าถึงและการเปิดใช้งาน
DM policy
channels.whatsapp.dmPolicy:
| ค่า | ลักษณะการทำงาน |
|---|---|
pairing (ค่าเริ่มต้น) |
ผู้ส่งที่ไม่รู้จักส่งคำขอจับคู่ และเจ้าของเป็นผู้อนุมัติ |
allowlist |
อนุญาตเฉพาะผู้ส่งใน allowFrom |
open |
กำหนดให้ allowFrom ต้องมี "*" |
disabled |
ปิดกั้น DM ทั้งหมด |
allowFrom รองรับหมายเลขรูปแบบ E.164 (ปรับรูปแบบเป็นมาตรฐานภายใน) รายการนี้เป็นรายการควบคุมการเข้าถึงของผู้ส่ง DM เท่านั้น โดยไม่ปิดกั้นการส่งขาออกที่ระบุอย่างชัดเจนไปยัง JID ของกลุ่มหรือ JID ช่องทาง @newsletter
การแทนที่สำหรับหลายบัญชี: channels.whatsapp.accounts.<id>.dmPolicy (และ .allowFrom) มีลำดับความสำคัญเหนือค่าเริ่มต้นระดับช่องทางสำหรับบัญชีนั้น
หมายเหตุเกี่ยวกับรันไทม์:
- การจับคู่จะคงอยู่ในที่เก็บรายการอนุญาตของช่องทาง และรวมเข้ากับ
allowFromที่กำหนดค่าไว้ - ระบบอัตโนมัติตามกำหนดเวลาและการสำรองผู้รับของ Heartbeat ใช้เป้าหมายการส่งที่ระบุไว้อย่างชัดเจนหรือ
allowFromที่กำหนดค่าไว้ การอนุมัติการจับคู่ DM จะไม่ถือเป็นผู้รับ Cron/Heartbeat โดยปริยาย - หากไม่ได้กำหนดค่ารายการอนุญาต หมายเลขของตนเองที่เชื่อมโยงไว้จะได้รับอนุญาตโดยค่าเริ่มต้น
- OpenClaw จะไม่จับคู่ DM ขาออกที่เป็น
fromMeโดยอัตโนมัติ (ข้อความที่คุณส่งถึงตนเองจากอุปกรณ์ที่เชื่อมโยงไว้)
นโยบายกลุ่มและรายการอนุญาต
การเข้าถึงกลุ่มมีสองชั้น:
- รายการอนุญาตสมาชิกกลุ่ม (
channels.whatsapp.groups): หากละgroupsไว้ ทุกกลุ่มจะมีสิทธิ์ หากระบุไว้ ค่านี้จะทำหน้าที่เป็นรายการอนุญาตกลุ่ม ("*"อนุญาตทุกกลุ่ม) - นโยบายผู้ส่งในกลุ่ม (
channels.whatsapp.groupPolicy+groupAllowFrom):openข้ามรายการอนุญาตผู้ส่ง,allowlistกำหนดให้ต้องตรงกับgroupAllowFrom(หรือ*), และdisabledบล็อกข้อความขาเข้าจากทุกกลุ่ม
หากไม่ได้ตั้งค่า groupAllowFrom การตรวจสอบผู้ส่งจะย้อนกลับไปใช้ allowFrom เมื่อมีรายการอยู่ ระบบจะประเมินรายการอนุญาตผู้ส่งก่อนการเปิดใช้งานด้วยการกล่าวถึง/การตอบกลับ
หากไม่มีบล็อก channels.whatsapp เลย รันไทม์จะย้อนกลับไปใช้ groupPolicy: "allowlist" (พร้อมบันทึกคำเตือน) แม้ว่า channels.defaults.groupPolicy จะตั้งค่าเป็นอย่างอื่นก็ตาม
การกล่าวถึงและ /activation
โดยค่าเริ่มต้น การตอบกลับในกลุ่มต้องมีการกล่าวถึง การตรวจจับการกล่าวถึงครอบคลุมถึง:
- การกล่าวถึงอัตลักษณ์ของบอตใน WhatsApp อย่างชัดเจน
- รูปแบบนิพจน์ทั่วไปสำหรับการกล่าวถึงที่กำหนดค่าไว้ (
agents.list[].groupChat.mentionPatternsโดยย้อนกลับไปใช้messages.groupChat.mentionPatterns) - ข้อความถอดเสียงจากข้อความเสียงขาเข้าสำหรับข้อความกลุ่มที่ได้รับอนุญาต
- การตรวจจับการตอบกลับบอตโดยปริยาย (ผู้ส่งที่ตอบกลับตรงกับอัตลักษณ์ของบอต)
ความปลอดภัย: การอ้างข้อความ/ตอบกลับมีผลเพียงผ่านเงื่อนไขการกล่าวถึงเท่านั้น แต่ ไม่ได้ ให้สิทธิ์แก่ผู้ส่ง เมื่อใช้ groupPolicy: "allowlist" ผู้ส่งที่ไม่อยู่ในรายการอนุญาตจะยังคงถูกบล็อก แม้จะตอบกลับข้อความของผู้ใช้ที่อยู่ในรายการอนุญาต
คำสั่งเปิดใช้งานระดับเซสชัน: /activation mention หรือ /activation always คำสั่งนี้จะอัปเดตสถานะเซสชัน (ไม่ใช่การกำหนดค่าส่วนกลาง) และจำกัดให้เฉพาะเจ้าของ
การผูก ACP ที่กำหนดค่าไว้
WhatsApp รองรับการผูก ACP แบบถาวรผ่าน bindings[] ระดับบนสุด:
{ bindings: [ { type: "acp", agentId: "codex", match: { channel: "whatsapp", accountId: "work", peer: { kind: "direct", id: "+15555550123" }, }, }, { type: "acp", agentId: "codex", match: { channel: "whatsapp", accountId: "work", peer: { kind: "group", id: "120363424282127706@g.us" }, }, }, ],}แชตโดยตรงจับคู่กับหมายเลข E.164 ส่วนกลุ่มจับคู่กับ JID กลุ่มของ WhatsApp รายการอนุญาตกลุ่ม นโยบายผู้ส่ง และเงื่อนไขการกล่าวถึง/การเปิดใช้งานจะทำงานก่อนที่ OpenClaw จะตรวจสอบให้แน่ใจว่าเซสชัน ACP ที่ผูกไว้มีอยู่ การผูกที่ตรงกันจะเป็นเจ้าของเส้นทาง กลุ่มกระจายข้อความจะไม่กระจายรอบการทำงานนั้นไปยังเซสชัน WhatsApp ปกติ
ลักษณะการทำงานของหมายเลขส่วนบุคคลและแชตกับตนเอง
เมื่อหมายเลขของตนเองที่เชื่อมโยงไว้มีอยู่ใน allowFrom ด้วย มาตรการป้องกันสำหรับแชตกับตนเองจะทำงาน ได้แก่ ข้ามใบตอบรับการอ่านสำหรับรอบการทำงานของแชตกับตนเอง เพิกเฉยต่อการทริกเกอร์อัตโนมัติด้วย JID การกล่าวถึงที่อาจแจ้งเตือนตัวคุณเอง และกำหนดให้การตอบกลับใช้ [{identity.name}] (หรือ [openclaw]) โดยค่าเริ่มต้นเมื่อไม่ได้ตั้งค่า messages.responsePrefix
การปรับข้อความให้เป็นรูปแบบมาตรฐานและบริบท
ซองข้อความขาเข้าและบริบทการตอบกลับ
ข้อความขาเข้าจะถูกห่อด้วยซองข้อความขาเข้าที่ใช้ร่วมกัน การตอบกลับแบบอ้างข้อความจะเพิ่มบริบทในรูปแบบนี้:
[Replying to <sender> id:<stanzaId>]<quoted body or media placeholder>[/Replying]ระบบจะเติมข้อมูลเมตาการตอบกลับ (ReplyToId, ReplyToBody, ReplyToSender, JID/E.164 ของผู้ส่ง) เมื่อมีข้อมูล หากเป้าหมายที่อ้างถึงเป็นสื่อที่ดาวน์โหลดได้ OpenClaw จะบันทึกผ่านที่เก็บสื่อขาเข้าตามปกติและเปิดเผย MediaPath/MediaType เพื่อให้เอเจนต์ตรวจสอบได้โดยตรง แทนที่จะเห็นเพียง <media:image>
ตัวยึดตำแหน่งสื่อและการแยกข้อมูลตำแหน่งที่ตั้ง/รายชื่อติดต่อ
ข้อความที่มีเฉพาะสื่อจะถูกปรับเป็นตัวยึดตำแหน่ง: <media:image>, <media:video>, <media:audio>, <media:document>, <media:sticker>
ระบบจะถอดเสียงข้อความเสียงของกลุ่มที่ได้รับอนุญาตก่อนตรวจเงื่อนไขการกล่าวถึง เมื่อเนื้อความมีเพียง <media:audio> ดังนั้นการพูดคำกล่าวถึงบอตในข้อความเสียงจึงสามารถทริกเกอร์การตอบกลับได้ หากข้อความถอดเสียงยังคงไม่ได้กล่าวถึงบอต ข้อความนั้นจะอยู่ในประวัติกลุ่มที่รอดำเนินการแทนตัวยึดตำแหน่งดิบ
เนื้อหาตำแหน่งที่ตั้งจะแสดงเป็นข้อความพิกัดแบบกระชับ ป้ายกำกับ/ความคิดเห็นของตำแหน่งที่ตั้งและรายละเอียดรายชื่อติดต่อ/vCard จะแสดงเป็นข้อมูลเมตาที่ไม่น่าเชื่อถือในบล็อกแบบมีรั้ว ไม่ใช่ข้อความพรอมต์แบบอินไลน์
การแทรกประวัติกลุ่มที่รอดำเนินการ
ข้อความกลุ่มที่ยังไม่ได้ประมวลผลจะถูกเก็บไว้ในบัฟเฟอร์และแทรกเป็นบริบทเมื่อบอตถูกทริกเกอร์ในที่สุด
- ขีดจำกัดเริ่มต้น:
50 - การกำหนดค่า:
channels.whatsapp.historyLimitโดยย้อนกลับไปใช้messages.groupChat.historyLimit 0ปิดใช้งาน
เครื่องหมายการแทรก: [ข้อความแชตนับตั้งแต่การตอบกลับครั้งล่าสุดของคุณ - สำหรับใช้เป็นบริบท] และ [ข้อความปัจจุบัน - ตอบกลับข้อความนี้]
ใบตอบรับการอ่าน
เปิดใช้งานโดยค่าเริ่มต้นสำหรับข้อความขาเข้าที่ได้รับการยอมรับ ปิดใช้งานทั่วทั้งระบบ:
{ channels: { whatsapp: { sendReadReceipts: false } } }การแทนที่ค่ารายบัญชี: channels.whatsapp.accounts.<id>.sendReadReceipts รอบการทำงานของแชตกับตนเองจะข้ามใบตอบรับการอ่านแม้จะเปิดใช้งานทั่วทั้งระบบ
การส่ง การแบ่งส่วน และสื่อ
การแบ่งข้อความ
- ขีดจำกัดส่วนเริ่มต้น:
channels.whatsapp.textChunkLimit = 4000 channels.whatsapp.chunkMode = "length" | "newline";newlineจะให้ความสำคัญกับขอบเขตย่อหน้า (บรรทัดว่าง) ก่อน แล้วจึงย้อนกลับไปแบ่งตามความยาวอย่างปลอดภัย
ลักษณะการทำงานของสื่อขาออก
- รองรับเพย์โหลดรูปภาพ วิดีโอ เสียง (ข้อความเสียง PTT) และเอกสาร
- เสียงจะถูกส่งเป็นเพย์โหลด
audioของ Baileys พร้อมptt: trueโดยแสดงผลเป็นข้อความเสียงแบบกดเพื่อพูด ระบบจะคงค่าaudioAsVoiceไว้ในเพย์โหลดการตอบกลับ เพื่อให้เอาต์พุตข้อความเสียง TTS ยังคงใช้เส้นทางนี้ไม่ว่ารูปแบบต้นฉบับของผู้ให้บริการจะเป็นแบบใด - เสียง Ogg/Opus แบบเนทีฟจะส่งเป็น
audio/ogg; codecs=opusส่วนรูปแบบอื่นทั้งหมด (รวมถึงเอาต์พุต MP3/WebM จาก TTS ของ Microsoft Edge) จะถูกแปลงด้วยffmpegเป็น Ogg/Opus โมโน 48 kHz ก่อนส่งแบบ PTT /tts latestส่งคำตอบล่าสุดของผู้ช่วยเป็นข้อความเสียงหนึ่งรายการและระงับการส่งซ้ำสำหรับคำตอบเดียวกัน ส่วน/tts chat on|off|defaultควบคุม TTS อัตโนมัติสำหรับแชตปัจจุบันgifPlayback: trueในการส่งวิดีโอจะเปิดใช้งานการเล่น GIF แบบเคลื่อนไหวforceDocument/asDocumentจะกำหนดเส้นทางรูปภาพ GIF และวิดีโอขาออกผ่านเพย์โหลดเอกสารของ Baileys เพื่อหลีกเลี่ยงการบีบอัดสื่อของ WhatsApp พร้อมคงชื่อไฟล์และชนิด MIME ที่ระบุได้- คำบรรยายจะใช้กับสื่อรายการแรกในการตอบกลับที่มีหลายสื่อ ยกเว้นข้อความเสียง PTT: เสียงจะถูกส่งก่อนโดยไม่มีคำบรรยาย จากนั้นส่งคำบรรยายเป็นข้อความแยกต่างหาก (ไคลเอนต์ WhatsApp แสดงคำบรรยายข้อความเสียงไม่สม่ำเสมอ)
- แหล่งสื่ออาจเป็น HTTP(S),
file://หรือพาธภายในเครื่อง
ขีดจำกัดขนาดสื่อและลักษณะการทำงานสำรอง
- ขีดจำกัดการบันทึกขาเข้าและการส่งขาออก:
channels.whatsapp.mediaMaxMb(ค่าเริ่มต้น50) - การแทนที่ค่ารายบัญชี:
channels.whatsapp.accounts.<id>.mediaMaxMb - ระบบจะปรับรูปภาพให้เหมาะสมโดยอัตโนมัติ (ปรับขนาด/ไล่ระดับคุณภาพ) เพื่อให้พอดีกับขีดจำกัด เว้นแต่
forceDocument/asDocumentจะร้องขอให้ส่งเป็นเอกสาร - เมื่อส่งสื่อล้มเหลว กลไกสำรองสำหรับรายการแรกจะส่งคำเตือนเป็นข้อความแทนการทิ้งคำตอบโดยไม่มีการแจ้งเตือน
การอ้างข้อความในการตอบกลับ
channels.whatsapp.replyToMode ควบคุมการอ้างข้อความในการตอบกลับแบบเนทีฟ (คำตอบขาออกจะแสดงการอ้างถึงข้อความขาเข้าอย่างชัดเจน):
| ค่า | ลักษณะการทำงาน |
|---|---|
"off" (ค่าเริ่มต้น) |
ไม่อ้างข้อความ ส่งเป็นข้อความธรรมดา |
"first" |
อ้างเฉพาะส่วนแรกของคำตอบขาออก |
"all" |
อ้างทุกส่วนของคำตอบขาออก |
"batched" |
อ้างคำตอบแบบชุดที่อยู่ในคิว และไม่อ้างคำตอบที่ส่งทันที |
การแทนที่ค่ารายบัญชี: channels.whatsapp.accounts.<id>.replyToMode
{ channels: { whatsapp: { replyToMode: "first" } } }ระดับปฏิกิริยา
channels.whatsapp.reactionLevel ควบคุมขอบเขตการใช้ปฏิกิริยาอีโมจิของเอเจนต์:
| ระดับ | ปฏิกิริยารับทราบ | ปฏิกิริยาที่เอเจนต์เริ่มเอง |
|---|---|---|
"off" |
ไม่ | ไม่ |
"ack" |
ใช่ | ไม่ |
"minimal" (ค่าเริ่มต้น) |
ใช่ | ใช่ โดยมีแนวทางให้ใช้อย่างระมัดระวัง |
"extensive" |
ใช่ | ใช่ โดยแนะนำให้ใช้ |
การแทนที่ค่ารายบัญชี: channels.whatsapp.accounts.<id>.reactionLevel
{ channels: { whatsapp: { reactionLevel: "ack" } } }ปฏิกิริยารับทราบ
channels.whatsapp.ackReaction ส่งปฏิกิริยาทันทีเมื่อรับข้อความขาเข้า โดยอยู่ภายใต้เงื่อนไขของ reactionLevel (ระงับเมื่อเป็น "off"):
{ channels: { whatsapp: { ackReaction: { emoji: "👀", direct: true, group: "mentions", // always | mentions | never }, }, },}หมายเหตุ: ส่งทันทีหลังจากยอมรับข้อความขาเข้า (ก่อนตอบกลับ) หากมี ackReaction แต่ไม่มี emoji WhatsApp จะใช้อีโมจิอัตลักษณ์ของเอเจนต์ที่กำหนดเส้นทาง โดยย้อนกลับไปใช้ "👀" (ละ ackReaction หรือตั้ง emoji: "" เพื่อไม่ส่งปฏิกิริยารับทราบ) ระบบจะบันทึกความล้มเหลวแต่จะไม่ขัดขวางการส่งคำตอบ โหมดกลุ่ม mentions จะตอบสนองเฉพาะรอบที่ทริกเกอร์ด้วยการกล่าวถึง ส่วนการเปิดใช้งานกลุ่มแบบ always จะข้ามการตรวจสอบนี้ WhatsApp ใช้เฉพาะ channels.whatsapp.ackReaction เท่านั้น (messages.ackReaction แบบเดิมไม่มีผลที่นี่)
ปฏิกิริยาสถานะวงจรชีวิต
ตั้งค่า messages.statusReactions.enabled: true เพื่อให้ WhatsApp แทนที่ปฏิกิริยารับทราบระหว่างรอบการทำงาน แทนที่จะคงอีโมจิการรับข้อความแบบเดิมไว้ โดยหมุนเวียนผ่านสถานะต่าง ๆ เช่น อยู่ในคิว กำลังคิด การทำงานของเครื่องมือ Compaction เสร็จสิ้น และข้อผิดพลาด:
{ messages: { statusReactions: { enabled: true, emojis: { deploy: "🛫", build: "🏗️", concierge: "💁", }, }, },}หมายเหตุ: channels.whatsapp.ackReaction ยังคงควบคุมสิทธิ์สำหรับข้อความโดยตรงและกลุ่ม สถานะอยู่ในคิวใช้อีโมจิที่มีผลเดียวกับปฏิกิริยารับทราบแบบธรรมดา WhatsApp มีช่องปฏิกิริยาของบอตหนึ่งช่องต่อข้อความ ดังนั้นการอัปเดตวงจรชีวิตจะแทนที่ปฏิกิริยาปัจจุบัน ณ ตำแหน่งเดิม messages.removeAckAfterReply: true จะล้างปฏิกิริยาสถานะสุดท้ายหลังช่วงเวลาคงสถานะเสร็จสิ้น/ข้อผิดพลาดที่กำหนดค่าไว้ หมวดหมู่อีโมจิของเครื่องมือประกอบด้วย tool, coding, web, deploy, build และ concierge
หลายบัญชีและข้อมูลประจำตัว
การเลือกบัญชีและค่าเริ่มต้น
รหัสบัญชีมาจาก channels.whatsapp.accounts การเลือกบัญชีเริ่มต้นจะใช้ default หากมี มิฉะนั้นจะใช้รหัสบัญชีแรกที่กำหนดค่าไว้ (เรียงตามตัวอักษร) ระบบจะปรับรหัสบัญชีให้เป็นรูปแบบมาตรฐานภายในเพื่อใช้ค้นหา
เส้นทางข้อมูลรับรองและความเข้ากันได้กับระบบเดิม
- เส้นทางการยืนยันตัวตนปัจจุบัน:
~/.openclaw/credentials/whatsapp/<accountId>/creds.json(ข้อมูลสำรอง:creds.json.bak) - การยืนยันตัวตนเริ่มต้นแบบเดิมใน
~/.openclaw/credentials/ยังคงได้รับการตรวจพบ/ย้ายข้อมูลสำหรับโฟลว์ของบัญชีเริ่มต้น
ลักษณะการทำงานเมื่อออกจากระบบ
openclaw channels logout --channel whatsapp [--account <id>] จะล้างสถานะการยืนยันตัวตน WhatsApp ของบัญชีนั้น เมื่อสามารถเข้าถึง Gateway ได้ การออกจากระบบจะหยุดตัวรับฟังที่ทำงานอยู่ของบัญชีนั้นก่อน เพื่อให้เซสชันที่เชื่อมโยงหยุดรับข้อความก่อนการเริ่มระบบใหม่ครั้งถัดไป openclaw channels remove --channel whatsapp จะหยุดตัวรับฟังที่ทำงานอยู่ก่อนปิดใช้งานหรือลบการกำหนดค่าบัญชีเช่นกัน
ในไดเรกทอรีการยืนยันตัวตนแบบเดิม ระบบจะเก็บ oauth.json ไว้ ขณะที่ลบไฟล์การยืนยันตัวตนของ Baileys
เครื่องมือ การดำเนินการ และการเขียนการกำหนดค่า
- เครื่องมือของเอเจนต์รองรับการดำเนินการแสดงความรู้สึกต่อข้อความของ WhatsApp (
react) - ตัวควบคุมการดำเนินการ:
channels.whatsapp.actions.reactions,channels.whatsapp.actions.polls(การดำเนินการที่มีอยู่มีค่าเริ่มต้นเป็นtrue),channels.whatsapp.actions.calls(ค่าเริ่มต้นfalseโปรดดู MeowCaller ด้านบน) - การเขียนการกำหนดค่าที่เริ่มต้นจากช่องทางเปิดใช้งานโดยค่าเริ่มต้น ปิดใช้งานได้ผ่าน
channels.whatsapp.configWrites: false
การแก้ไขปัญหา
ยังไม่ได้เชื่อมโยง (ต้องใช้คิวอาร์โค้ด)
อาการ: สถานะช่องทางรายงานว่ายังไม่ได้เชื่อมโยง
openclaw channels login --channel whatsappopenclaw channels statusเชื่อมโยงแล้วแต่ตัดการเชื่อมต่อ / วนเชื่อมต่อใหม่
อาการ: บัญชีที่เชื่อมโยงแล้วตัดการเชื่อมต่อหรือพยายามเชื่อมต่อใหม่ซ้ำ ๆ
บัญชีที่ไม่มีความเคลื่อนไหวมากสามารถคงการเชื่อมต่อไว้เกินช่วงหมดเวลาข้อความตามปกติได้ ตัวเฝ้าระวังจะเริ่มระบบใหม่เฉพาะเมื่อกิจกรรมการรับส่งข้อมูลของ WhatsApp Web หยุดลง ซ็อกเก็ตปิด หรือไม่มีกิจกรรมระดับแอปพลิเคชันนานเกินช่วงเวลาความปลอดภัยที่ยาวกว่า (โปรดดูโมเดลรันไทม์ด้านบน)
หากบันทึกแสดง status=408 Request Time-out Connection was lost ซ้ำ ๆ ให้ปรับช่วงเวลาซ็อกเก็ตของ Baileys ภายใต้ web.whatsapp เริ่มจากลด keepAliveIntervalMs ให้สั้นกว่าช่วงหมดเวลาเมื่อไม่มีการใช้งานของเครือข่าย และเพิ่ม connectTimeoutMs สำหรับการเชื่อมต่อที่ช้าหรือมีการสูญหาย:
{ web: { whatsapp: { keepAliveIntervalMs: 15000, connectTimeoutMs: 60000, defaultQueryTimeoutMs: 60000, }, },}วิธีแก้ไข:
openclaw channels status --probeopenclaw doctoropenclaw logs --followopenclaw gateway statusหากยังคงวนซ้ำหลังจากแก้ไขการเชื่อมต่อของโฮสต์และการตั้งเวลาแล้ว ให้สำรองไดเรกทอรีการยืนยันตัวตนของบัญชีและเชื่อมโยงใหม่:
cp -a ~/.openclaw/credentials/whatsapp/<accountId> \ ~/.openclaw/credentials/whatsapp/<accountId>.bakopenclaw channels logout --channel whatsapp --account <accountId>openclaw channels login --channel whatsapp --account <accountId>หาก ~/.openclaw/logs/whatsapp-health.log ระบุว่า Gateway inactive แต่ทั้ง openclaw gateway status และ openclaw channels status --probe แสดงว่าปกติ ให้เรียกใช้ openclaw doctor บน Linux โปรแกรม doctor จะเตือนเกี่ยวกับรายการ crontab แบบเดิมที่เรียกใช้สคริปต์ ~/.openclaw/bin/ensure-whatsapp.sh ซึ่งเลิกใช้งานแล้ว ให้ลบรายการเหล่านั้นด้วย crontab -e — Cron อาจไม่มีสภาพแวดล้อมบัสผู้ใช้ของ systemd และทำให้สคริปต์เก่านั้นรายงานสถานะของ Gateway ผิดพลาด
การเข้าสู่ระบบด้วยคิวอาร์โค้ดหมดเวลาหลังพร็อกซี
อาการ: openclaw channels login --channel whatsapp ล้มเหลวก่อนแสดงคิวอาร์โค้ดที่ใช้งานได้ โดยมี status=408 Request Time-out หรือการตัดการเชื่อมต่อซ็อกเก็ต TLS
การเข้าสู่ระบบ WhatsApp Web ใช้สภาพแวดล้อมพร็อกซีมาตรฐานของโฮสต์ Gateway (HTTPS_PROXY, HTTP_PROXY, รูปแบบตัวพิมพ์เล็ก, NO_PROXY) ตรวจสอบว่ากระบวนการ Gateway สืบทอดตัวแปรสภาพแวดล้อมพร็อกซี และ NO_PROXY ไม่ตรงกับ mmg.whatsapp.net
ไม่มีตัวรับฟังที่ทำงานอยู่ขณะส่ง
การส่งขาออกจะล้มเหลวทันทีเมื่อไม่มีตัวรับฟัง Gateway ที่ทำงานอยู่สำหรับบัญชีเป้าหมาย ตรวจสอบว่า Gateway กำลังทำงานและบัญชีเชื่อมโยงแล้ว
การตอบกลับปรากฏในบันทึกบทสนทนาแต่ไม่ปรากฏใน WhatsApp
แถวในบันทึกบทสนทนาจะบันทึกสิ่งที่เอเจนต์สร้างขึ้น ส่วนการส่งผ่าน WhatsApp จะได้รับการตรวจสอบแยกต่างหาก OpenClaw จะถือว่าการตอบกลับอัตโนมัติถูกส่งแล้วก็ต่อเมื่อ Baileys ส่งคืนรหัสข้อความขาออกสำหรับการส่งข้อความหรือสื่อที่มองเห็นได้อย่างน้อยหนึ่งรายการ
การแสดงความรู้สึกรับทราบเป็นการตอบรับก่อนส่งคำตอบที่แยกจากกัน — การแสดงความรู้สึกสำเร็จไม่ได้พิสูจน์ว่าคำตอบข้อความ/สื่อภายหลังได้รับการยอมรับ ตรวจสอบบันทึก Gateway เพื่อหา auto-reply delivery failed หรือ auto-reply was not accepted by WhatsApp provider
ข้อความกลุ่มถูกเพิกเฉยโดยไม่คาดคิด
ตรวจสอบตามลำดับนี้: groupPolicy, groupAllowFrom/allowFrom, รายการอนุญาตใน groups, การควบคุมด้วยการกล่าวถึง (requireMention + รูปแบบการกล่าวถึง) และคีย์ซ้ำใน openclaw.json (รายการที่อยู่ภายหลังใน JSON5 จะแทนที่รายการก่อนหน้า — ให้มี groupPolicy เพียงรายการเดียวต่อขอบเขต)
หากมี channels.whatsapp.groups WhatsApp ยังคงสามารถตรวจพบข้อความจากกลุ่มอื่นได้ แต่ OpenClaw จะทิ้งข้อความเหล่านั้นก่อนการกำหนดเส้นทางเซสชัน เพิ่ม JID ของกลุ่มลงใน channels.whatsapp.groups หรือเพิ่ม groups["*"] เพื่ออนุญาตทุกกลุ่มโดยยังคงควบคุมการอนุญาตผู้ส่งด้วย groupPolicy/groupAllowFrom
คำเตือนรันไทม์ Bun
รันไทม์ Gateway ของ WhatsApp ควรใช้ Node ระบบระบุว่า Bun ไม่เข้ากันกับการทำงานที่เสถียรของ Gateway สำหรับ WhatsApp/Telegram
พรอมต์ระบบ
WhatsApp รองรับพรอมต์ระบบแบบ Telegram สำหรับกลุ่มและแชตโดยตรงผ่านแมป groups และ direct
การแก้ค่าการกำหนดค่าสำหรับข้อความกลุ่ม: ระบบจะกำหนดแมป groups ที่มีผลก่อน — หากบัญชีกำหนดคีย์ groups ของตนเองไม่ว่าในรูปแบบใด คีย์ดังกล่าวจะแทนที่แมป groups ระดับรากทั้งหมด (ไม่มีการผสานเชิงลึก) จากนั้นการค้นหาพรอมต์จะทำงานกับแมปผลลัพธ์เพียงแมปเดียวนั้น:
- พรอมต์เฉพาะกลุ่ม (
groups["<groupId>"].systemPrompt): ใช้เมื่อมีรายการกลุ่มอยู่ และ มีการกำหนดคีย์systemPromptของรายการนั้น สตริงว่าง ("") จะระงับไวลด์การ์ดและไม่ใช้พรอมต์ใด ๆ - พรอมต์ไวลด์การ์ดของกลุ่ม (
groups["*"].systemPrompt): ใช้เมื่อไม่มีรายการเฉพาะกลุ่ม หรือมีรายการอยู่แต่ไม่มีคีย์systemPrompt
การแก้ค่าการกำหนดค่าสำหรับข้อความโดยตรงใช้รูปแบบเดียวกันกับแมป direct และ direct["*"]
ความแตกต่างจาก Telegram: Telegram จะระงับ groups ระดับรากสำหรับทุกบัญชีในการตั้งค่าแบบหลายบัญชี (แม้แต่บัญชีที่ไม่มี groups ของตนเอง) เพื่อป้องกันไม่ให้บอตรับข้อความกลุ่มจากกลุ่มที่บอตไม่ได้เป็นสมาชิก WhatsApp ไม่ใช้กลไกป้องกันดังกล่าว — บัญชีใดก็ตามที่ไม่มีการแทนที่ของตนเองจะสืบทอด groups/direct ระดับรากโดยไม่คำนึงถึงจำนวนบัญชี ในการตั้งค่า WhatsApp แบบหลายบัญชี ให้กำหนดแมปทั้งหมดภายใต้แต่ละบัญชีอย่างชัดเจนหากต้องการพรอมต์แยกตามบัญชี
ลักษณะการทำงานที่สำคัญ:
channels.whatsapp.groupsเป็นทั้งแมปการกำหนดค่าต่อกลุ่มและรายการอนุญาตกลุ่มระดับแชต ไม่ว่าจะอยู่ในขอบเขตระดับรากหรือระดับบัญชีgroups["*"]หมายถึง "อนุญาตทุกกลุ่ม" สำหรับขอบเขตนั้น- เพิ่ม
systemPromptแบบไวลด์การ์ดเฉพาะเมื่อคุณต้องการให้ขอบเขตนั้นอนุญาตทุกกลุ่มอยู่แล้ว หากต้องการให้มีเพียงชุดรหัสกลุ่มตายตัวที่มีสิทธิ์ ให้ระบุพรอมต์ซ้ำในแต่ละรายการที่อนุญาตอย่างชัดเจนแทนการใช้groups["*"] - การอนุญาตกลุ่มและการอนุญาตผู้ส่งเป็นการตรวจสอบแยกจากกัน
groups["*"]ขยายขอบเขตของกลุ่มที่เข้าสู่การจัดการกลุ่ม แต่ไม่ได้อนุญาตผู้ส่งทุกคนในกลุ่มเหล่านั้น — ส่วนนี้ยังคงควบคุมโดยgroupPolicy/groupAllowFrom channels.whatsapp.directไม่มีผลข้างเคียงที่เทียบเท่าสำหรับข้อความโดยตรง:direct["*"]เพียงระบุการกำหนดค่าเริ่มต้นหลังจากข้อความโดยตรงได้รับอนุญาตแล้วตามdmPolicyร่วมกับallowFromหรือกฎของที่เก็บการจับคู่
ตัวอย่าง:
{ channels: { whatsapp: { groups: { // ใช้เฉพาะเมื่อต้องการอนุญาตทุกกลุ่มในขอบเขตระดับราก // ใช้กับทุกบัญชีที่ไม่ได้กำหนดแมป groups ของตนเอง "*": { systemPrompt: "พรอมต์เริ่มต้นสำหรับทุกกลุ่ม" }, }, direct: { // ใช้กับทุกบัญชีที่ไม่ได้กำหนดแมป direct ของตนเอง "*": { systemPrompt: "พรอมต์เริ่มต้นสำหรับแชตโดยตรงทั้งหมด" }, }, accounts: { work: { groups: { // บัญชีนี้กำหนด groups ของตนเอง ดังนั้น groups ระดับรากจึงถูก // แทนที่ทั้งหมด หากต้องการคงไวลด์การ์ดไว้ ให้กำหนด "*" ที่นี่อย่างชัดเจนด้วย "120363406415684625@g.us": { requireMention: false, systemPrompt: "มุ่งเน้นการจัดการโครงการ", }, // ใช้เฉพาะเมื่อต้องการอนุญาตทุกกลุ่มในบัญชีนี้ "*": { systemPrompt: "พรอมต์เริ่มต้นสำหรับกลุ่มงาน" }, }, direct: { // บัญชีนี้กำหนดแมป direct ของตนเอง ดังนั้นรายการ direct ระดับรากจึงถูก // แทนที่ทั้งหมด หากต้องการคงไวลด์การ์ดไว้ ให้กำหนด "*" ที่นี่อย่างชัดเจนด้วย "+15551234567": { systemPrompt: "พรอมต์สำหรับแชตงานโดยตรงรายการหนึ่ง" }, "*": { systemPrompt: "พรอมต์เริ่มต้นสำหรับแชตงานโดยตรง" }, }, }, }, }, },}ตัวชี้ไปยังข้อมูลอ้างอิงการกำหนดค่า
ข้อมูลอ้างอิงหลัก: ข้อมูลอ้างอิงการกำหนดค่า - WhatsApp
| พื้นที่ | ฟิลด์ |
|---|---|
| การเข้าถึง | dmPolicy, allowFrom, groupPolicy, groupAllowFrom, groups |
| การส่งมอบ | textChunkLimit, chunkMode, mediaMaxMb, sendReadReceipts, ackReaction, reactionLevel |
| หลายบัญชี | accounts.<id>.enabled, accounts.<id>.authDir และการแทนที่เฉพาะบัญชีอื่น ๆ |
| การดำเนินงาน | configWrites, debounceMs, web.enabled, web.heartbeatSeconds, web.reconnect.*, web.whatsapp.* |
| ลักษณะการทำงานของเซสชัน | session.dmScope, historyLimit, dmHistoryLimit, dms.<id>.historyLimit |
| พรอมต์ | groups.<id>.systemPrompt, groups["*"].systemPrompt, direct.<id>.systemPrompt, direct["*"].systemPrompt |