Developer and self-hosted

IRC

ใช้ IRC เมื่อต้องการใช้ OpenClaw ในช่องทางแบบคลาสสิก (#room) และข้อความส่วนตัว IRC มาพร้อมเป็น Plugin ที่รวมไว้ในชุด แต่กำหนดค่าในคอนฟิกหลักภายใต้ channels.irc

เริ่มต้นอย่างรวดเร็ว

  1. เปิดใช้งานคอนฟิก IRC ใน ~/.openclaw/openclaw.json
  2. ตั้งค่าอย่างน้อย:
{
  channels: {
    irc: {
      enabled: true,
      host: "irc.example.com",
      port: 6697,
      tls: true,
      nick: "openclaw-bot",
      channels: ["#openclaw"],
    },
  },
}

ควรใช้เซิร์ฟเวอร์ IRC ส่วนตัวสำหรับการประสานงานของบอต หากคุณตั้งใจใช้เครือข่าย IRC สาธารณะ ตัวเลือกที่พบบ่อยได้แก่ Libera.Chat, OFTC และ Snoonet หลีกเลี่ยงช่องทางสาธารณะที่คาดเดาได้สำหรับทราฟฟิกช่องทางเบื้องหลังของบอตหรือกลุ่มทำงาน

  1. เริ่มหรือรีสตาร์ต Gateway:
openclaw gateway run

ค่าเริ่มต้นด้านความปลอดภัย

  • IRC ใช้ซ็อกเก็ต TCP/TLS แบบดิบภายนอกการกำหนดเส้นทางผ่านพร็อกซีส่งต่อที่ผู้ปฏิบัติงาน OpenClaw จัดการ ในการปรับใช้ที่กำหนดให้ทราฟฟิกขาออกทั้งหมดผ่านพร็อกซีส่งต่อนั้น ให้ตั้ง channels.irc.enabled=false เว้นแต่การออกไปยัง IRC โดยตรงจะได้รับอนุมัติอย่างชัดเจน
  • channels.irc.dmPolicy มีค่าเริ่มต้นเป็น "pairing"
  • channels.irc.groupPolicy มีค่าเริ่มต้นเป็น "allowlist"
  • เมื่อใช้ groupPolicy="allowlist" ให้ตั้ง channels.irc.groups เพื่อกำหนดช่องทางที่อนุญาต
  • ใช้ TLS (channels.irc.tls=true) เว้นแต่คุณตั้งใจยอมรับการส่งข้อมูลแบบข้อความล้วน

การควบคุมการเข้าถึง

มี “ด่าน” แยกกันสองแบบสำหรับช่องทาง IRC:

  1. การเข้าถึงช่องทาง (groupPolicy + groups): บอตจะยอมรับข้อความจากช่องทางนั้นหรือไม่
  2. การเข้าถึงของผู้ส่ง (groupAllowFrom / groups["#channel"].allowFrom ต่อช่องทาง): ใครได้รับอนุญาตให้เรียกใช้บอตภายในช่องทางนั้น

คีย์คอนฟิก:

  • รายการอนุญาต DM (การเข้าถึงของผู้ส่ง DM): channels.irc.allowFrom
  • รายการอนุญาตผู้ส่งกลุ่ม (การเข้าถึงของผู้ส่งในช่องทาง): channels.irc.groupAllowFrom
  • การควบคุมต่อช่องทาง (ช่องทาง + ผู้ส่ง + กฎการกล่าวถึง): channels.irc.groups["#channel"]
  • channels.irc.groupPolicy="open" อนุญาตช่องทางที่ไม่ได้กำหนดค่าไว้ (ยังคงถูกควบคุมด้วยการกล่าวถึงตามค่าเริ่มต้น)

รายการใน allowlist ควรใช้ตัวตนผู้ส่งที่เสถียร (nick!user@host) การจับคู่ด้วยชื่อเล่นล้วนเปลี่ยนแปลงได้ และเปิดใช้งานเฉพาะเมื่อตั้ง channels.irc.dangerouslyAllowNameMatching: true

ข้อผิดพลาดที่พบบ่อย: allowFrom ใช้สำหรับ DM ไม่ใช่ช่องทาง

หากคุณเห็นล็อกเช่น:

  • irc: drop group sender alice!ident@host (policy=allowlist)

...หมายความว่าผู้ส่งไม่ได้รับอนุญาตสำหรับข้อความแบบ กลุ่ม/ช่องทาง แก้ไขได้โดยทำอย่างใดอย่างหนึ่ง:

  • ตั้ง channels.irc.groupAllowFrom (ใช้ร่วมกันสำหรับทุกช่องทาง) หรือ
  • ตั้งรายการอนุญาตผู้ส่งต่อช่องทาง: channels.irc.groups["#channel"].allowFrom

ตัวอย่าง (อนุญาตให้ทุกคนใน #tuirc-dev คุยกับบอต):

{
  channels: {
    irc: {
      groupPolicy: "allowlist",
      groups: {
        "#tuirc-dev": { allowFrom: ["*"] },
      },
    },
  },
}

การเรียกให้ตอบกลับ (การกล่าวถึง)

แม้ว่าช่องทางจะได้รับอนุญาตแล้ว (ผ่าน groupPolicy + groups) และผู้ส่งได้รับอนุญาตแล้ว OpenClaw จะตั้งค่าเริ่มต้นให้ ต้องมีการกล่าวถึง ในบริบทกลุ่ม

นั่นหมายความว่าคุณอาจเห็นล็อกเช่น drop channel … (missing-mention) เว้นแต่ข้อความจะมีรูปแบบการกล่าวถึงที่ตรงกับบอต

หากต้องการให้บอตตอบกลับในช่องทาง IRC โดยไม่ต้องกล่าวถึง ให้ปิดการบังคับกล่าวถึงสำหรับช่องทางนั้น:

{
  channels: {
    irc: {
      groupPolicy: "allowlist",
      groups: {
        "#tuirc-dev": {
          requireMention: false,
          allowFrom: ["*"],
        },
      },
    },
  },
}

หรือหากต้องการอนุญาตช่องทาง IRC ทั้งหมด (ไม่มี allowlist ต่อช่องทาง) และยังตอบกลับได้โดยไม่ต้องกล่าวถึง:

{
  channels: {
    irc: {
      groupPolicy: "open",
      groups: {
        "*": { requireMention: false, allowFrom: ["*"] },
      },
    },
  },
}

หมายเหตุด้านความปลอดภัย (แนะนำสำหรับช่องทางสาธารณะ)

หากคุณอนุญาต allowFrom: ["*"] ในช่องทางสาธารณะ ใครก็สามารถส่งพรอมป์ให้บอตได้ เพื่อลดความเสี่ยง ให้จำกัดเครื่องมือสำหรับช่องทางนั้น

เครื่องมือเดียวกันสำหรับทุกคนในช่องทาง

{
  channels: {
    irc: {
      groups: {
        "#tuirc-dev": {
          allowFrom: ["*"],
          tools: {
            deny: ["group:runtime", "group:fs", "gateway", "nodes", "cron", "browser"],
          },
        },
      },
    },
  },
}

เครื่องมือต่างกันตามผู้ส่ง (เจ้าของมีสิทธิ์มากกว่า)

ใช้ toolsBySender เพื่อใช้นโยบายที่เข้มงวดกว่ากับ "*" และนโยบายที่ผ่อนปรนกว่ากับชื่อเล่นของคุณ:

{
  channels: {
    irc: {
      groups: {
        "#tuirc-dev": {
          allowFrom: ["*"],
          toolsBySender: {
            "*": {
              deny: ["group:runtime", "group:fs", "gateway", "nodes", "cron", "browser"],
            },
            "id:eigen": {
              deny: ["gateway", "nodes", "cron"],
            },
          },
        },
      },
    },
  },
}

หมายเหตุ:

  • คีย์ toolsBySender ควรใช้ id: สำหรับค่าตัวตนผู้ส่ง IRC: id:eigen หรือ id:[email protected] เพื่อการจับคู่ที่เข้มงวดขึ้น
  • คีย์แบบเก่าที่ไม่มีคำนำหน้ายังคงยอมรับได้ และจับคู่เป็น id: เท่านั้น
  • นโยบายผู้ส่งที่ตรงกันรายการแรกจะถูกใช้ก่อน; "*" คือทางเลือกสำรองแบบไวลด์การ์ด

ดูเพิ่มเติมเกี่ยวกับการเข้าถึงกลุ่มเทียบกับการบังคับกล่าวถึง (และวิธีที่ทั้งสองทำงานร่วมกัน) ได้ที่: /channels/groups

NickServ

เพื่อระบุตัวตนกับ NickServ หลังเชื่อมต่อ:

{
  channels: {
    irc: {
      nickserv: {
        enabled: true,
        service: "NickServ",
        password: "your-nickserv-password",
      },
    },
  },
}

การลงทะเบียนครั้งเดียวขณะเชื่อมต่อแบบไม่บังคับ:

{
  channels: {
    irc: {
      nickserv: {
        register: true,
        registerEmail: "[email protected]",
      },
    },
  },
}

ปิด register หลังจากลงทะเบียนชื่อเล่นแล้ว เพื่อหลีกเลี่ยงการพยายาม REGISTER ซ้ำ

ตัวแปรสภาพแวดล้อม

บัญชีเริ่มต้นรองรับ:

  • IRC_HOST
  • IRC_PORT
  • IRC_TLS
  • IRC_NICK
  • IRC_USERNAME
  • IRC_REALNAME
  • IRC_PASSWORD
  • IRC_CHANNELS (คั่นด้วยจุลภาค)
  • IRC_NICKSERV_PASSWORD
  • IRC_NICKSERV_REGISTER_EMAIL

ไม่สามารถตั้ง IRC_HOST จาก .env ของเวิร์กสเปซได้; ดู ไฟล์ .env ของเวิร์กสเปซ

การแก้ไขปัญหา

  • หากบอตเชื่อมต่อได้แต่ไม่เคยตอบกลับในช่องทาง ให้ตรวจสอบ channels.irc.groups และ ดูว่าการบังคับกล่าวถึงกำลังทิ้งข้อความหรือไม่ (missing-mention) หากต้องการให้ตอบกลับโดยไม่ต้องปิง ให้ตั้ง requireMention:false สำหรับช่องทางนั้น
  • หากเข้าสู่ระบบล้มเหลว ให้ตรวจสอบว่าชื่อเล่นพร้อมใช้งานและรหัสผ่านเซิร์ฟเวอร์ถูกต้อง
  • หาก TLS ล้มเหลวบนเครือข่ายแบบกำหนดเอง ให้ตรวจสอบโฮสต์/พอร์ตและการตั้งค่าใบรับรอง

ที่เกี่ยวข้อง