Configuration

การกำหนดเส้นทางช่องทาง

ช่องทางและการกำหนดเส้นทาง

OpenClaw กำหนดเส้นทางการตอบกลับ ไปยังช่องทางที่ข้อความนั้นส่งมา โมเดลไม่ได้เลือกช่องทาง การกำหนดเส้นทางเป็นแบบตายตัวและควบคุมโดยการกำหนดค่าของโฮสต์ ภายใต้ขอบเขต DM เริ่มต้น ข้อความโดยตรงจากทุกช่องทางจะรวมเข้าสู่เซสชันหลักของเอเจนต์

คำสำคัญ

ช่องทาง: Plugin ช่องทางที่รวมมาให้ เช่น discord, googlechat, imessage, irc, line, signal, slack, telegram หรือ whatsapp รวมถึงช่องทางจาก Plugin ที่ติดตั้งไว้ webchat คือช่องทาง UI ของ WebChat ภายในและไม่ใช่ช่องทางขาออกที่กำหนดค่าได้
AccountId: อินสแตนซ์บัญชีต่อช่องทาง (เมื่อรองรับ)
บัญชีเริ่มต้นของช่องทางซึ่งเป็นตัวเลือก: channels.<channel>.defaultAccount เลือก บัญชีที่จะใช้เมื่อเส้นทางขาออกไม่ได้ระบุ accountId
- ในการตั้งค่าแบบหลายบัญชี ให้ตั้งค่าเริ่มต้นอย่างชัดเจน (defaultAccount หรือบัญชีชื่อ default) เมื่อกำหนดค่าบัญชีตั้งแต่สองบัญชีขึ้นไป หากไม่มีค่านี้ การกำหนดเส้นทางสำรองอาจเลือก ID บัญชีที่ผ่านการปรับรูปแบบเป็นมาตรฐานแล้วรายการแรก
AgentId: พื้นที่ทำงานและที่เก็บเซสชันที่แยกจากกัน ("สมอง")
SessionKey: คีย์บัคเก็ตที่ใช้จัดเก็บบริบทและควบคุมการทำงานพร้อมกัน

คำนำหน้าเป้าหมายขาออก

เป้าหมายขาออกที่ระบุอย่างชัดเจนอาจมีคำนำหน้าผู้ให้บริการ เช่น telegram:123 หรือ tg:123 Core จะถือว่าคำนำหน้านั้นเป็นเพียงคำใบ้สำหรับเลือกช่องทางก็ต่อเมื่อช่องทางที่เลือกคือ last หรือยังไม่ได้รับการแก้ไข และเฉพาะเมื่อ Plugin ที่โหลดประกาศรองรับคำนำหน้านั้น หากผู้เรียกเลือกช่องทางอย่างชัดเจนแล้ว คำนำหน้าผู้ให้บริการต้องตรงกับช่องทางนั้น การผสมข้ามช่องทาง เช่น การส่งผ่าน WhatsApp ไปยัง telegram:123 จะล้มเหลวก่อนการปรับเป้าหมายให้เป็นมาตรฐานเฉพาะของ Plugin

คำนำหน้าชนิดเป้าหมายและบริการ เช่น channel:<id>, user:<id>, room:<id>, thread:<id>, imessage:<handle> และ sms:<number> ยังคงอยู่ภายในไวยากรณ์ของช่องทางที่เลือก คำนำหน้าเหล่านี้ไม่ได้เลือกผู้ให้บริการด้วยตัวเอง

รูปแบบคีย์เซสชัน (ตัวอย่าง)

โดยค่าเริ่มต้น ข้อความโดยตรงจะรวมเข้าสู่เซสชัน หลัก ของเอเจนต์:

agent:<agentId>:<mainKey> (ค่าเริ่มต้น: agent:main:main)

session.dmScope ควบคุมการรวม DM: main (ค่าเริ่มต้น) ใช้เซสชันหลักหนึ่งเซสชันร่วมกัน ขณะที่ per-peer, per-channel-peer และ per-account-channel-peer แยก DM ไว้ในเซสชันต่างหาก การผูกเส้นทางสามารถแทนที่ขอบเขตสำหรับเพียร์ที่ตรงกันผ่าน bindings[].session.dmScope

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

กลุ่มและช่องทางยังคงแยกจากกันตามแต่ละช่องทาง:

กลุ่ม: agent:<agentId>:<channel>:group:<id>
ช่องทาง/ห้อง: agent:<agentId>:<channel>:channel:<id>

เธรด:

เธรดของ Slack/Discord จะต่อท้าย :thread:<threadId> เข้ากับคีย์ฐาน
หัวข้อฟอรัมของ Telegram จะฝัง :topic:<topicId> ไว้ในคีย์กลุ่ม

ตัวอย่าง:

agent:main:telegram:group:-1001234567890:topic:42
agent:main:discord:channel:123456:thread:987654

การปักหมุดเส้นทาง DM หลัก

เมื่อ session.dmScope เป็น main ข้อความโดยตรงอาจใช้เซสชันหลักหนึ่งเซสชันร่วมกัน เพื่อป้องกันไม่ให้ lastRoute ของเซสชันถูกเขียนทับโดย DM จากผู้ที่ไม่ใช่เจ้าของ OpenClaw จะอนุมานเจ้าของที่ปักหมุดจาก allowFrom เมื่อเงื่อนไขทั้งหมดต่อไปนี้เป็นจริง:

allowFrom มีรายการที่ไม่ใช่ไวลด์การ์ดเพียงหนึ่งรายการ
รายการดังกล่าวสามารถปรับเป็น ID ผู้ส่งที่เจาะจงสำหรับช่องทางนั้นได้
ผู้ส่ง DM ขาเข้าไม่ตรงกับเจ้าของที่ปักหมุดไว้

ในกรณีที่ไม่ตรงกัน OpenClaw ยังคงบันทึกข้อมูลเมตาของเซสชันขาเข้า แต่จะข้ามการอัปเดต lastRoute ของเซสชันหลัก

การบันทึกขาเข้าที่มีการป้องกัน

Plugin ช่องทางสามารถทำเครื่องหมายระเบียนเซสชันขาเข้าเป็น createIfMissing: false เมื่อเส้นทางที่มีการป้องกันต้องไม่สร้างเซสชัน OpenClaw ใหม่ ในโหมดนี้ OpenClaw อาจอัปเดตข้อมูลเมตาและ lastRoute สำหรับเซสชันที่มีอยู่ แต่จะไม่สร้างรายการเซสชันเฉพาะเส้นทางเพียงเพราะตรวจพบข้อความ

กฎการกำหนดเส้นทาง (วิธีเลือกเอเจนต์)

การกำหนดเส้นทางจะเลือก เอเจนต์หนึ่งรายการ สำหรับข้อความขาเข้าแต่ละข้อความ:

ตรงกับเพียร์ทุกประการ (bindings ที่มี peer.kind + peer.id)
ตรงกับเพียร์หลัก (การสืบทอดเธรด)
ตรงกับไวลด์การ์ดของเพียร์ (peer.id: "*" สำหรับชนิดเพียร์)
ตรงกับกิลด์และบทบาท (Discord) ผ่าน guildId + roles
ตรงกับกิลด์ (Discord) ผ่าน guildId
ตรงกับทีม (Slack) ผ่าน teamId
ตรงกับบัญชี (accountId บนช่องทาง)
ตรงกับช่องทาง (บัญชีใดก็ได้บนช่องทางนั้น, accountId: "*")
เอเจนต์เริ่มต้น (agents.list[].default มิฉะนั้นใช้รายการแรก และสำรองเป็น main)

เมื่อการผูกมีฟิลด์จับคู่หลายฟิลด์ (peer, guildId, teamId, roles) ฟิลด์ที่ระบุทั้งหมดต้องตรงกัน การผูกนั้นจึงจะมีผล

เอเจนต์ที่ตรงกันจะกำหนดพื้นที่ทำงานและที่เก็บเซสชันที่จะใช้

กลุ่มกระจายสัญญาณ (เรียกใช้หลายเอเจนต์)

กลุ่มกระจายสัญญาณช่วยให้เรียกใช้ หลายเอเจนต์ สำหรับเพียร์เดียวกันได้ เมื่อปกติ OpenClaw จะตอบกลับ (ตัวอย่างเช่น ในกลุ่ม WhatsApp หลังผ่านการตรวจสอบการกล่าวถึง/การเปิดใช้งาน)

การกำหนดค่า:

json5

{  broadcast: {    strategy: "parallel",    "120363403215116621@g.us": ["alfred", "baerbel"],    "+15555550123": ["support", "logger"],  },}

ดู: กลุ่มกระจายสัญญาณ

ภาพรวมการกำหนดค่า

agents.list: คำจำกัดความของเอเจนต์ที่มีชื่อ (พื้นที่ทำงาน โมเดล ฯลฯ)
bindings: แมปช่องทาง/บัญชี/เพียร์ขาเข้าไปยังเอเจนต์

ตัวอย่าง:

json5

{  agents: {    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],  },  bindings: [    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },  ],}

การจัดเก็บเซสชัน

แถวเซสชันรันไทม์อยู่ในฐานข้อมูล SQLite ของแต่ละเอเจนต์ภายใต้ไดเรกทอรีสถานะ (ค่าเริ่มต้น ~/.openclaw):

~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite

การติดตั้งรุ่นเก่าอาจมีไฟล์ JSONL บันทึกบทสนทนาแบบเดิมและที่เก็บแถว sessions.json ภายใต้ ~/.openclaw/agents/<agentId>/sessions/ การเริ่มต้น Gateway และ openclaw doctor --fix จะนำเข้าแถว/ประวัติแบบเดิมที่มีการใช้งานล่าสุดเข้าสู่ SQLite โดยอัตโนมัติ ใช้ openclaw doctor --session-sqlite inspect --session-sqlite-all-agents และลำดับการตรวจสอบของ Doctor เมื่อต้องการหลักฐานการย้ายข้อมูลอย่างชัดเจน ยังคงสามารถเลือกพาธที่เก็บแบบเดิมผ่านการสร้างเทมเพลต session.store และ {agentId} สำหรับเวิร์กโฟลว์การย้ายข้อมูลและการบำรุงรักษาแบบออฟไลน์ได้

การค้นหาเซสชันของ Gateway และ ACP ยังสแกนที่เก็บเอเจนต์บนดิสก์ภายใต้รูทเริ่มต้น agents/ และภายใต้รูท session.store ที่สร้างจากเทมเพลต ที่เก็บที่ค้นพบต้องอยู่ภายในรูทเอเจนต์ที่แก้ไขแล้วนั้น และใช้ไฟล์ sessions.json แบบเดิมที่เป็นไฟล์ปกติ ระบบจะละเว้นลิงก์สัญลักษณ์และพาธที่อยู่นอกรูท

ลักษณะการทำงานของ WebChat

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

บริบทการตอบกลับ

การตอบกลับขาเข้าประกอบด้วย:

ReplyToId, ReplyToBody และ ReplyToSender เมื่อมีข้อมูล
บริบทที่ยกมาจะถูกต่อท้าย Body เป็นบล็อก [Replying to ...]

ลักษณะนี้สอดคล้องกันในทุกช่องทาง

เนื้อหาที่เกี่ยวข้อง

Was this useful?