Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Plugin ช่องทางควรเปิดเผยอะแดปเตอร์ message หนึ่งรายการจาก
openclaw/plugin-sdk/channel-message อะแดปเตอร์อธิบายวงจรชีวิตข้อความแบบเนทีฟ
ที่แพลตฟอร์มรองรับ:
receive -> route and record -> agent turn -> durable final send
send -> render batch -> platform I/O -> receipt -> lifecycle side effects
live preview -> final edit or fallback -> receipt
แกนหลักเป็นเจ้าของการจัดคิว ความคงทน นโยบายการลองใหม่ทั่วไป ฮุก ใบรับ และเครื่องมือ
message ที่ใช้ร่วมกัน Plugin เป็นเจ้าของการเรียกส่ง/แก้ไข/ลบแบบเนทีฟ
การปรับเป้าหมายให้เป็นมาตรฐาน การจัดเธรดของแพลตฟอร์ม คำพูดอ้างอิงที่เลือกไว้
แฟล็กการแจ้งเตือน สถานะบัญชี และผลข้างเคียงเฉพาะแพลตฟอร์ม
ใช้หน้านี้ร่วมกับ การสร้าง Plugin ช่องทาง
ซับพาธ channel-message ตั้งใจให้เบาพอสำหรับไฟล์บูตสแตรป Plugin ที่อยู่บนเส้นทางร้อน
เช่น channel.ts: ซับพาธนี้เปิดเผยสัญญาอะแดปเตอร์ หลักฐานความสามารถ
ใบรับ และฟาซาดความเข้ากันได้โดยไม่โหลดการนำส่งขาออก
ตัวช่วยการนำส่งขณะรันไทม์มีให้จาก
openclaw/plugin-sdk/channel-message-runtime สำหรับเส้นทางโค้ดมอนิเตอร์/ส่งที่
กำลังทำ I/O ข้อความแบบอะซิงโครนัสอยู่แล้ว
โค้ดส่งของช่องทางและ Plugin ใหม่ควรใช้ตัวช่วยวงจรชีวิตข้อความจาก
openclaw/plugin-sdk/channel-message-runtime: sendDurableMessageBatch,
withDurableMessageSendContext หรือ deliverInboundReplyWithMessageSendContext
ตัวช่วยเก่ากว่า
deliverOutboundPayloads(...) ใน openclaw/plugin-sdk/outbound-runtime
เลิกแนะนำให้ใช้แล้ว และเป็นวัสดุรองรับความเข้ากันได้/รันไทม์สำหรับภายในขาออก การกู้คืน
และอะแดปเตอร์เดิม ห้ามใช้สำหรับเส้นทางส่งของช่องทางหรือ Plugin ใหม่
sendDurableMessageBatch(...) ส่งคืนผลลัพธ์วงจรชีวิตที่ชัดเจน:
sent - มีการนำส่งข้อความแพลตฟอร์มที่มองเห็นได้อย่างน้อยหนึ่งข้อความ
suppressed - ไม่ควรถือว่าข้อความแพลตฟอร์มหายไป เหตุผลที่เสถียรรวมถึง cancelled_by_message_sending_hook,
empty_after_message_sending_hook, no_visible_payload,
adapter_returned_no_identity และ no_visible_result เดิม
partial_failed - มีการนำส่งข้อความแพลตฟอร์มอย่างน้อยหนึ่งข้อความก่อนที่เพย์โหลดหรือผลข้างเคียงภายหลังจะล้มเหลว
ผลลัพธ์รวมถึงพรีฟิกซ์ใบรับที่นำส่งแล้วพร้อมความล้มเหลว
failed - ไม่มีการสร้างใบรับของแพลตฟอร์ม
ใช้ payloadOutcomes เมื่อแบตช์ผสมเพย์โหลดที่ส่งแล้ว ถูกระงับ และล้มเหลว
อย่าอนุมานการยกเลิกโดยฮุกด้วยการตรวจว่าอาร์เรย์การนำส่งโดยตรงแบบเก่าว่างหรือไม่
ดิสแพตเชอร์ความเข้ากันได้ที่ยังต้องใช้ดิสแพตเชอร์ตอบกลับแบบบัฟเฟอร์ควร
สร้างตัวเลือกพรีฟิกซ์การตอบกลับด้วย createChannelMessageReplyPipeline(...) จาก
openclaw/plugin-sdk/channel-message แล้วเรียก
channel.turn.runPrepared(...) ของรันไทม์ ซึ่งช่วยให้การบันทึกเซสชันและลำดับการดิสแพตช์
อยู่บนวงจรชีวิตเทิร์นที่ใช้ร่วมกันโดยไม่เพิ่มตัวครอบเทิร์นสาธารณะอีกตัว
อะแดปเตอร์ขั้นต่ำ
Plugin ช่องทางใหม่ส่วนใหญ่สามารถเริ่มจากอะแดปเตอร์ขนาดเล็กได้:
import {
defineChannelMessageAdapter,
createMessageReceiptFromOutboundResults,
} from "openclaw/plugin-sdk/channel-message";
export const demoMessageAdapter = defineChannelMessageAdapter({
id: "demo",
durableFinal: {
capabilities: {
text: true,
replyTo: true,
thread: true,
messageSendingHooks: true,
},
},
send: {
text: async ({ cfg, to, text, accountId, replyToId, threadId, signal }) => {
const sent = await sendDemoMessage({
cfg,
to,
text,
accountId: accountId ?? undefined,
replyToId: replyToId ?? undefined,
threadId: threadId == null ? undefined : String(threadId),
signal,
});
return {
receipt: createMessageReceiptFromOutboundResults({
results: [{ channel: "demo", messageId: sent.id, conversationId: to }],
kind: "text",
threadId: threadId == null ? undefined : String(threadId),
replyToId: replyToId ?? undefined,
}),
};
},
},
});
จากนั้นแนบเข้ากับ Plugin ช่องทาง:
export const demoPlugin = createChatChannelPlugin({
base: {
id: "demo",
message: demoMessageAdapter,
// other channel plugin fields
},
});
ประกาศเฉพาะความสามารถที่อะแดปเตอร์รักษาไว้จริงเท่านั้น ความสามารถที่ประกาศทุกอย่าง
ควรมีการทดสอบสัญญา
บริดจ์ขาออก
หากช่องทางมีอะแดปเตอร์ outbound ที่เข้ากันได้อยู่แล้ว ให้เลือกสร้าง
อะแดปเตอร์ข้อความจากอะแดปเตอร์นั้นแทนการทำโค้ดส่งซ้ำ:
import { createChannelMessageAdapterFromOutbound } from "openclaw/plugin-sdk/channel-message";
const demoMessageAdapter = createChannelMessageAdapterFromOutbound({
id: "demo",
outbound: demoOutboundAdapter,
});
บริดจ์จะแปลงผลลัพธ์การส่งขาออกแบบเก่าเป็นค่า MessageReceipt โค้ดใหม่
ควรส่งต่อใบรับตั้งแต่ต้นจนจบ และสร้างรหัสเดิมเฉพาะที่ขอบความเข้ากันได้
ด้วย listMessageReceiptPlatformIds(...) หรือ
resolveMessageReceiptPrimaryId(...)
หากไม่ได้ระบุนโยบายการรับ createChannelMessageAdapterFromOutbound(...)
จะใช้นโยบายการยืนยันการรับแบบ manual ซึ่งทำให้การยืนยันแพลตฟอร์มที่ Plugin เป็นเจ้าของ
ชัดเจน โดยไม่เปลี่ยนช่องทางที่ยืนยัน Webhook ซ็อกเก็ต หรือออฟเซ็ตการโพล
นอกบริบทการรับทั่วไป
การส่งของเครื่องมือข้อความ
เส้นทาง message(action="send") ที่ใช้ร่วมกันควรใช้วงจรชีวิตการนำส่งแกนหลักเดียวกัน
กับการตอบกลับสุดท้าย หากช่องทางต้องการการปรับรูปแบบเฉพาะผู้ให้บริการสำหรับ
การส่งของเครื่องมือ ให้ติดตั้ง actions.prepareSendPayload(...) แทนการส่งจาก
actions.handleAction(...)
prepareSendPayload(...) รับ ReplyPayload แกนหลักที่ปรับมาตรฐานแล้วพร้อมบริบทการดำเนินการเต็มรูปแบบ
ส่งคืนเพย์โหลดพร้อมข้อมูลเฉพาะช่องทางใน
payload.channelData.<channel> และปล่อยให้แกนหลักเรียก sendMessage(...),
รันไทม์วงจรชีวิตข้อความ คิวแบบเขียนล่วงหน้า ฮุกการส่งข้อความ
การลองใหม่ การกู้คืน และการล้าง ack รันไทม์วงจรชีวิตอาจเรียก
deliverOutboundPayloads(...) ภายในเป็นวัสดุรองรับความเข้ากันได้ แต่ Plugin ช่องทาง
ไม่ควรเรียกโดยตรงสำหรับพฤติกรรมการส่งใหม่
ส่งคืน null เฉพาะเมื่อการส่งไม่สามารถแทนเป็นเพย์โหลดแบบคงทนได้
เช่น เพราะมีคอมโพเนนต์แฟกทอรีที่ทำให้เป็นอนุกรมไม่ได้ แกนหลักจะคง
ทางเลือกสำรองการดำเนินการของ Plugin เดิมไว้เพื่อความเข้ากันได้ แต่ฟีเจอร์การส่งของช่องทางใหม่
ควรแสดงเป็นข้อมูลเพย์โหลดแบบคงทนได้
export const demoActions: ChannelMessageActionAdapter = {
describeMessageTool: () => ({ actions: ["send"], capabilities: ["presentation"] }),
prepareSendPayload: ({ ctx, payload }) => {
if (ctx.action !== "send") {
return null;
}
return {
...payload,
channelData: {
...payload.channelData,
demo: {
...(payload.channelData?.demo as object | undefined),
nativeCard: ctx.params.card,
},
},
};
},
};
จากนั้นอะแดปเตอร์ขาออกจะอ่าน payload.channelData.demo ภายใน sendPayload
สิ่งนี้ทำให้การเรนเดอร์เฉพาะแพลตฟอร์มอยู่ใน Plugin ขณะที่แกนหลักยังคงเป็นเจ้าของ
การคงไว้ การลองใหม่ การกู้คืน ฮุก และ ack
เพย์โหลด message(action="send") ที่เตรียมไว้และการนำส่งการตอบกลับสุดท้ายทั่วไป
ใช้การนำส่งของแกนหลักพร้อมการจัดคิวแบบพยายามเต็มที่โดยค่าเริ่มต้น การจัดคิวแบบคงทนที่จำเป็น
ใช้ได้เฉพาะหลังจากแกนหลักตรวจสอบแล้วว่าช่องทางสามารถกระทบยอดการส่งที่ผลลัพธ์
ไม่ทราบหลังจากเกิดแครชได้ หากอะแดปเตอร์ไม่สามารถติดตั้ง reconcileUnknownSend
ให้คงเส้นทางการส่งที่เตรียมไว้เป็นแบบพยายามเต็มที่ แกนหลักยังจะลองใช้คิวแบบเขียนล่วงหน้า
แต่การคงอยู่ของคิวหรือการกู้คืนแครชที่ไม่แน่นอนไม่ได้เป็นส่วนหนึ่งของ
สัญญาการนำส่งที่จำเป็น
ความสามารถของการส่งสุดท้ายแบบคงทน
การนำส่งสุดท้ายแบบคงทนเป็นการเลือกใช้ต่อผลข้างเคียงแต่ละรายการ แกนหลักจะใช้เฉพาะ
การนำส่งคงทนทั่วไปเมื่ออะแดปเตอร์ประกาศทุกความสามารถที่จำเป็นต่อ
เพย์โหลดและตัวเลือกการนำส่ง
| ความสามารถ | ประกาศเมื่อ |
|---|
text | อะแดปเตอร์สามารถส่งข้อความและส่งคืนใบรับได้ |
media | การส่งสื่อส่งคืนใบรับสำหรับข้อความแพลตฟอร์มที่มองเห็นได้ทุกข้อความ |
payload | อะแดปเตอร์รักษาความหมายของเพย์โหลดตอบกลับแบบริช ไม่ใช่แค่ข้อความกับ URL สื่อหนึ่งรายการ |
replyTo | เป้าหมายการตอบกลับแบบเนทีฟไปถึงแพลตฟอร์ม |
thread | เป้าหมายเธรด หัวข้อ หรือเธรดช่องทางแบบเนทีฟไปถึงแพลตฟอร์ม |
silent | การระงับการแจ้งเตือนไปถึงแพลตฟอร์ม |
nativeQuote | เมตาดาต้าคำพูดอ้างอิงที่เลือกไว้ไปถึงแพลตฟอร์ม |
messageSendingHooks | ฮุกการส่งข้อความของแกนหลักสามารถยกเลิกหรือเขียนเนื้อหาใหม่ก่อน I/O ของแพลตฟอร์ม |
batch | แบตช์หลายส่วนที่เรนเดอร์แล้วสามารถเล่นซ้ำเป็นแผนคงทนหนึ่งรายการ |
reconcileUnknownSend | อะแดปเตอร์สามารถแก้ไขการกู้คืน unknown_after_send โดยไม่เล่นซ้ำแบบไม่รู้ผล |
afterSendSuccess | ผลข้างเคียงหลังส่งสำเร็จภายในช่องทางทำงานหนึ่งครั้ง |
afterCommit | ผลข้างเคียงหลังคอมมิตภายในช่องทางทำงานหนึ่งครั้ง |
การนำส่งสุดท้ายแบบพยายามเต็มที่ไม่ต้องใช้ reconcileUnknownSend; ใช้
วงจรชีวิตที่ใช้ร่วมกันเมื่ออะแดปเตอร์รักษาความหมายที่มองเห็นได้ของเพย์โหลด และ
ถอยกลับไปใช้ I/O แพลตฟอร์มโดยตรงหากการคงอยู่ของคิวไม่พร้อมใช้งาน
การนำส่งสุดท้ายแบบคงทนที่จำเป็นต้องระบุความต้องการ reconcileUnknownSend อย่างชัดเจน
หากอะแดปเตอร์ไม่สามารถระบุได้ว่าการส่งที่เริ่มแล้ว/ไม่ทราบผลไปถึงแพลตฟอร์มหรือไม่
อย่าประกาศความสามารถนั้น แกนหลักจะปฏิเสธการนำส่งคงทนที่จำเป็น
ก่อนจัดคิว
เมื่อผู้เรียกต้องการการนำส่งแบบคงทน ให้สร้างข้อกำหนดแทนการสร้าง
แมปด้วยมือ:
import { deriveDurableFinalDeliveryRequirements } from "openclaw/plugin-sdk/channel-message";
const requiredCapabilities = deriveDurableFinalDeliveryRequirements({
payload,
replyToId,
threadId,
silent,
payloadTransport: true,
extraCapabilities: {
nativeQuote: hasSelectedQuote(payload),
},
});
messageSendingHooks จำเป็นโดยค่าเริ่มต้น ตั้ง messageSendingHooks: false
เฉพาะสำหรับเส้นทางที่ตั้งใจให้ไม่สามารถเรียกใช้ฮุกการส่งข้อความส่วนกลางได้
สัญญาการส่งแบบคงทน
การส่งสุดท้ายแบบคงทนมีความหมายเข้มงวดกว่าการนำส่งเดิมที่ช่องทางเป็นเจ้าของ:
- สร้าง intent แบบคงทนก่อน I/O ของแพลตฟอร์ม
- หากการนำส่งแบบคงทนส่งคืนผลลัพธ์ที่จัดการแล้ว อย่าถอยกลับไปใช้การส่งเดิม
- ถือว่าการยกเลิกโดยฮุกและผลลัพธ์แบบไม่ส่งเป็นสถานะปลายทาง
- ถือว่า
unsupported เป็นผลลัพธ์ก่อน intent เท่านั้น
- สำหรับความคงทนที่จำเป็น ให้ล้มเหลวก่อน I/O ของแพลตฟอร์มหากคิวไม่สามารถบันทึก
ได้ว่าการส่งของแพลตฟอร์มเริ่มแล้ว
- สำหรับการนำส่งสุดท้ายที่จำเป็นและการส่งของเครื่องมือข้อความที่เตรียมไว้ซึ่งจำเป็น
ให้ตรวจล่วงหน้า
reconcileUnknownSend; การกู้คืนต้องสามารถ ack ข้อความ
ที่ส่งไปแล้ว หรือเล่นซ้ำเฉพาะหลังจากอะแดปเตอร์พิสูจน์ว่าการส่งเดิม
ไม่ได้เกิดขึ้น
- สำหรับ
best_effort ความล้มเหลวในการเขียนคิวอาจถอยกลับไปใช้ I/O แพลตฟอร์มโดยตรง
- ส่งต่อสัญญาณยกเลิกไปยังการโหลดสื่อและการส่งของแพลตฟอร์ม
- เรียกใช้ฮุกหลังคอมมิตหลังจาก ack คิว; ทางเลือกสำรองแบบพยายามเต็มที่โดยตรงเรียกใช้ฮุกเหล่านั้น
หลัง I/O แพลตฟอร์มสำเร็จ เพราะไม่มีคอมมิตคิวแบบคงทน
- ส่งคืนใบรับสำหรับรหัสข้อความแพลตฟอร์มที่มองเห็นได้ทุกตัว
- ใช้
reconcileUnknownSend เมื่อแพลตฟอร์มสามารถตรวจสอบได้ว่าการส่งที่ไม่แน่นอน
ไปถึงผู้ใช้แล้วหรือไม่
สัญญานี้หลีกเลี่ยงการส่งซ้ำหลังเกิดแครช และหลีกเลี่ยงการข้าม
ฮุกยกเลิกการส่งข้อความ
ใบรับ
MessageReceipt คือระเบียนภายในใหม่ของสิ่งที่แพลตฟอร์มยอมรับ:
type MessageReceipt = {
primaryPlatformMessageId?: string;
platformMessageIds: string[];
parts: MessageReceiptPart[];
threadId?: string;
replyToId?: string;
editToken?: string;
deleteToken?: string;
sentAt: number;
raw?: readonly MessageReceiptSourceResult[];
};
ใช้ createMessageReceiptFromOutboundResults(...) เมื่อปรับผลลัพธ์การส่งที่มีอยู่ ใช้ createPreviewMessageReceipt(...) เมื่อข้อความพรีวิวสดกลายเป็นใบตอบรับสุดท้าย หลีกเลี่ยงการเพิ่มฟิลด์ messageIds ใหม่แบบเฉพาะเจ้าของ ChannelDeliveryResult.messageIds แบบเดิมยังคงถูกสร้างที่ขอบความเข้ากันได้
พรีวิวสด
ช่องทางที่สตรีมพรีวิวแบบร่างหรือการอัปเดตความคืบหน้าควรประกาศความสามารถแบบสด:
const demoMessageAdapter = defineChannelMessageAdapter({
id: "demo",
live: {
capabilities: {
draftPreview: true,
previewFinalization: true,
progressUpdates: true,
quietFinalization: true,
},
finalizer: {
capabilities: {
finalEdit: true,
normalFallback: true,
discardPending: true,
previewReceipt: true,
retainOnAmbiguousFailure: true,
},
},
},
});
ใช้ defineFinalizableLivePreviewAdapter(...) และ
deliverWithFinalizableLivePreviewAdapter(...) สำหรับการทำขั้นสุดท้ายในรันไทม์ ตัวทำขั้นสุดท้ายจะตัดสินใจว่าการตอบกลับสุดท้ายจะแก้ไขพรีวิวในตำแหน่งเดิม ส่งทางเลือกสำรองปกติ ละทิ้งสถานะพรีวิวที่ค้างอยู่ เก็บการแก้ไขที่ล้มเหลวแบบกำกวมไว้โดยไม่ทำซ้ำข้อความ และคืนใบตอบรับสุดท้ายหรือไม่
นโยบาย ack การรับ
ตัวรับขาเข้าที่ควบคุมจังหวะการตอบรับของแพลตฟอร์มควรประกาศนโยบายการรับ:
const demoMessageAdapter = defineChannelMessageAdapter({
id: "demo",
receive: {
defaultAckPolicy: "after_agent_dispatch",
supportedAckPolicies: ["after_receive_record", "after_agent_dispatch"],
},
});
อะแดปเตอร์ที่ไม่ประกาศนโยบายการรับจะใช้ค่าเริ่มต้นเป็น:
{
receive: {
defaultAckPolicy: "manual",
supportedAckPolicies: ["manual"],
},
}
ใช้ค่าเริ่มต้นเมื่อแพลตฟอร์มไม่มีการตอบรับให้เลื่อนออกไป ตอบรับก่อนการประมวลผลแบบอะซิงโครนัสอยู่แล้ว หรือต้องใช้ความหมายการตอบกลับเฉพาะโปรโตคอล ประกาศนโยบายแบบเป็นช่วงหนึ่งในรายการเฉพาะเมื่อตัวรับใช้บริบทการรับจริงเพื่อเลื่อนการตอบรับของแพลตฟอร์มออกไป
นโยบาย:
| นโยบาย | ใช้เมื่อ |
|---|
after_receive_record | แพลตฟอร์มสามารถได้รับการตอบรับหลังจากเหตุการณ์ขาเข้าถูกแยกวิเคราะห์และบันทึกแล้ว |
after_agent_dispatch | แพลตฟอร์มควรรอจนกว่าการจัดส่งไปยังเอเจนต์จะได้รับการยอมรับ |
after_durable_send | แพลตฟอร์มควรรอจนกว่าการส่งมอบสุดท้ายจะมีการตัดสินใจที่คงทน |
manual | Plugin เป็นเจ้าของการตอบรับ เพราะความหมายของแพลตฟอร์มไม่ตรงกับช่วงทั่วไป |
ใช้ createMessageReceiveContext(...) ในตัวรับที่เลื่อนสถานะ ack และใช้
shouldAckMessageAfterStage(...) เมื่อตัวรับต้องทดสอบว่าช่วงหนึ่งตอบสนองนโยบายที่กำหนดค่าไว้แล้วหรือไม่
การทดสอบสัญญา
การประกาศความสามารถเป็นส่วนหนึ่งของสัญญา Plugin ให้รองรับด้วยการทดสอบ:
import {
verifyChannelMessageAdapterCapabilityProofs,
verifyChannelMessageLiveCapabilityAdapterProofs,
verifyChannelMessageLiveFinalizerProofs,
verifyChannelMessageReceiveAckPolicyAdapterProofs,
} from "openclaw/plugin-sdk/channel-message";
it("backs declared message capabilities", async () => {
await expect(
verifyChannelMessageAdapterCapabilityProofs({
adapterName: "demo",
adapter: demoMessageAdapter,
proofs: {
text: async () => {
const result = await demoMessageAdapter.send!.text!(textCtx);
expect(result.receipt.platformMessageIds).toContain("msg-1");
},
replyTo: async () => {
await demoMessageAdapter.send!.text!({ ...textCtx, replyToId: "parent-1" });
expect(sendDemoMessage).toHaveBeenCalledWith(
expect.objectContaining({
replyToId: "parent-1",
}),
);
},
messageSendingHooks: () => {
expect(demoMessageAdapter.durableFinal!.capabilities!.messageSendingHooks).toBe(true);
},
},
}),
).resolves.toContainEqual({ capability: "text", status: "verified" });
});
เพิ่มชุดการพิสูจน์แบบสดและการรับเมื่ออะแดปเตอร์ประกาศฟีเจอร์เหล่านั้น การพิสูจน์ที่ขาดหายควรทำให้การทดสอบล้มเหลว แทนที่จะขยายพื้นผิวที่คงทนอย่างเงียบ ๆ
API ความเข้ากันได้ที่เลิกใช้แล้ว
API เหล่านี้ยังคงนำเข้าได้เพื่อความเข้ากันได้กับบุคคลที่สาม อย่าใช้สำหรับโค้ดช่องทางใหม่
| API ที่เลิกใช้แล้ว | สิ่งที่ใช้แทน |
|---|
openclaw/plugin-sdk/channel-reply-pipeline | openclaw/plugin-sdk/channel-message |
createChannelTurnReplyPipeline(...) | createChannelMessageReplyPipeline(...) สำหรับตัวจัดส่งความเข้ากันได้ หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
buildChannelMessageReplyDispatchBase(...) | createChannelMessageReplyPipeline(...) รวมกับ channel.turn.runPrepared(...) หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
dispatchChannelMessageReplyWithBase(...) | createChannelMessageReplyPipeline(...) รวมกับ channel.turn.runPrepared(...) หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
recordChannelMessageReplyDispatch(...) | createChannelMessageReplyPipeline(...) รวมกับ channel.turn.runPrepared(...) หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
deliverOutboundPayloads(...) | sendDurableMessageBatch(...) หรือ deliverInboundReplyWithMessageSendContext(...) จาก channel-message-runtime |
deliverDurableInboundReplyPayload(...) | deliverInboundReplyWithMessageSendContext(...) จาก openclaw/plugin-sdk/channel-message-runtime |
dispatchInboundReplyWithBase(...) | createChannelMessageReplyPipeline(...) รวมกับ channel.turn.runPrepared(...) หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
recordInboundSessionAndDispatchReply(...) | createChannelMessageReplyPipeline(...) รวมกับ channel.turn.runPrepared(...) หรืออะแดปเตอร์ message สำหรับโค้ดช่องทางใหม่ |
resolveChannelSourceReplyDeliveryMode(...) | resolveChannelMessageSourceReplyDeliveryMode(...) |
deliverFinalizableDraftPreview(...) | defineFinalizableLivePreviewAdapter(...) รวมกับ deliverWithFinalizableLivePreviewAdapter(...) |
DraftPreviewFinalizerDraft | LivePreviewFinalizerDraft |
DraftPreviewFinalizerResult | LivePreviewFinalizerResult |
ตัวจัดส่งความเข้ากันได้ยังคงใช้ createReplyPrefixContext(...),
createReplyPrefixOptions(...) และ createTypingCallbacks(...) ผ่าน facade ของข้อความได้ โค้ดวงจรชีวิตใหม่ควรหลีกเลี่ยง subpath channel-reply-pipeline เก่า
รายการตรวจสอบการย้าย
- เพิ่ม
message: defineChannelMessageAdapter(...) หรือ
message: createChannelMessageAdapterFromOutbound(...) ไปยัง Plugin ช่องทาง
- คืน
MessageReceipt จากการส่งข้อความ สื่อ และ payload
- ประกาศเฉพาะความสามารถที่รองรับด้วยพฤติกรรมเนทีฟและการทดสอบ
- แทนที่แผนที่ข้อกำหนดแบบคงทนที่เขียนเองด้วย
deriveDurableFinalDeliveryRequirements(...)
- ย้ายการทำพรีวิวขั้นสุดท้ายผ่านตัวช่วยพรีวิวสดเมื่อช่องทางแก้ไขข้อความแบบร่างในตำแหน่งเดิม
- ประกาศนโยบาย ack การรับเฉพาะเมื่อตัวรับสามารถเลื่อนการตอบรับของแพลตฟอร์มได้จริง
- เก็บตัวช่วยจัดส่งการตอบกลับแบบเดิมไว้เฉพาะที่ขอบความเข้ากันได้