Tái cấu trúc vòng đời thông điệp

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.

• Các nguyên thủy lõi nên là nhận và gửi, không phải trả lời.
• Một trả lời chỉ là một quan hệ trên tin nhắn gửi ra ngoài.
• Một lượt là tiện ích xử lý đầu vào, không phải chủ thể sở hữu việc gửi.
• Việc gửi phải dựa trên ngữ cảnh: begin, kết xuất, xem trước hoặc truyền phát, gửi cuối cùng, ghi nhận, thất bại.
• Việc nhận cũng phải dựa trên ngữ cảnh: chuẩn hóa, khử trùng lặp, định tuyến, ghi lại, điều phối, xác nhận nền tảng, thất bại.
• SDK Plugin công khai nên thu gọn thành một bề mặt tin nhắn kênh nhỏ.

​

Vấn đề

• Các adapter đầu vào đơn giản dùng runtime.channel.turn.run.
• Các adapter phong phú dùng runtime.channel.turn.runPrepared.
• Các helper cũ dùng dispatchInboundReplyWithBase, recordInboundSessionAndDispatchReply, helper payload trả lời, chia khúc trả lời, tham chiếu trả lời và helper runtime đầu ra.
• Truyền phát xem trước nằm trong các dispatcher riêng theo kênh.
• Độ bền của gửi cuối cùng đang được bổ sung quanh các đường dẫn payload trả lời hiện có.

Telegram polling update acked
  -> assistant final text exists
  -> process restarts before sendMessage succeeds
  -> final response is lost

​

Mục tiêu

• Một vòng đời lõi cho tất cả đường dẫn nhận và gửi tin nhắn kênh.
• Gửi cuối cùng bền vững theo mặc định trong vòng đời tin nhắn mới sau khi adapter khai báo hành vi an toàn khi phát lại.
• Ngữ nghĩa dùng chung cho xem trước, chỉnh sửa, truyền phát, hoàn tất, thử lại, khôi phục và biên nhận.
• Một bề mặt SDK Plugin nhỏ mà Plugin bên thứ ba có thể học và bảo trì.
• Tương thích cho các bên gọi channel.turn hiện có trong quá trình di trú.
• Điểm mở rộng rõ ràng cho năng lực kênh mới.
• Không có nhánh riêng theo nền tảng trong lõi.
• Không có tin nhắn kênh delta token. Truyền phát kênh vẫn là xem trước tin nhắn, chỉnh sửa, nối thêm hoặc gửi khối đã hoàn tất.
• Metadata có cấu trúc do OpenClaw khởi tạo cho đầu ra vận hành/hệ thống để các lỗi Gateway hiển thị không vào lại các phòng dùng bot chung dưới dạng prompt mới.

​

Không phải mục tiêu

• Không xóa runtime.channel.turn.* trong giai đoạn đầu.
• Không ép mọi kênh vào cùng một hành vi transport gốc.
• Không dạy lõi về chủ đề Telegram, stream gốc của Slack, biên tập xóa Matrix, thẻ Feishu, giọng nói QQ hoặc hoạt động Teams.
• Không xuất bản tất cả helper di trú nội bộ dưới dạng API SDK ổn định.
• Không để việc thử lại phát lại các thao tác nền tảng không bất biến đã hoàn tất.

​

Mô hình tham chiếu

• Chat
• Thread
• Channel
• Message
• các phương thức adapter như postMessage, editMessage, deleteMessage, stream, startTyping và lấy lịch sử
• một adapter trạng thái cho khử trùng lặp, khóa, hàng đợi và lưu bền vững

• Ý định gửi đầu ra bền vững trước các lệnh gọi transport trực tiếp.
• Ngữ cảnh gửi tường minh với begin, commit và fail.
• Ngữ cảnh nhận biết chính sách xác nhận nền tảng.
• Biên nhận sống sót qua khởi động lại và có thể dẫn dắt chỉnh sửa, xóa, khôi phục và chặn trùng lặp.
• Một SDK công khai nhỏ hơn. Các Plugin đi kèm có thể dùng helper runtime nội bộ, nhưng Plugin bên thứ ba nên thấy một API tin nhắn mạch lạc duy nhất.
• Hành vi theo agent: phiên, bản ghi hội thoại, truyền phát khối, tiến độ công cụ, phê duyệt, chỉ thị media, trả lời im lặng và lịch sử nhắc đến trong nhóm.

​

Mô hình lõi

core.messages.receive(...)
core.messages.send(...)
core.messages.live(...)
core.messages.state(...)

​

Thuật ngữ về tin nhắn

​

Tin nhắn

type ChannelMessage = {
  id: string;
  channel: string;
  accountId?: string;
  direction: "inbound" | "outbound";
  target: MessageTarget;
  sender?: MessageActor;
  body?: MessageBody;
  attachments?: MessageAttachment[];
  relation?: MessageRelation;
  origin?: MessageOrigin;
  timestamp?: number;
  raw?: unknown;
};

​

Đích

type MessageTarget = {
  kind: "direct" | "group" | "channel" | "thread";
  id: string;
  label?: string;
  spaceId?: string;
  parentId?: string;
  threadId?: string;
  nativeChannelId?: string;
};

​

Quan hệ

type MessageRelation =
  | {
      kind: "reply";
      inboundMessageId?: string;
      replyToId?: string;
      threadId?: string;
      quote?: MessageQuote;
    }
  | {
      kind: "followup";
      sessionKey?: string;
      previousMessageId?: string;
    }
  | {
      kind: "broadcast";
      reason?: string;
    }
  | {
      kind: "system";
      reason:
        | "approval"
        | "task"
        | "hook"
        | "cron"
        | "subagent"
        | "message_tool"
        | "cli"
        | "control_ui"
        | "automation"
        | "error";
    };

​

Nguồn gốc

type MessageOrigin =
  | {
      source: "openclaw";
      schemaVersion: 1;
      kind: "gateway_failure";
      code: "agent_failed_before_reply" | "missing_api_key" | "model_login_expired";
      echoPolicy: "drop_bot_room_echo";
    }
  | {
      source: "user" | "external_bot" | "platform" | "unknown";
    };

​

Biên nhận

type MessageReceipt = {
  primaryPlatformMessageId?: string;
  platformMessageIds: string[];
  parts: MessageReceiptPart[];
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  sentAt: number;
  raw?: unknown;
};

type MessageReceiptPart = {
  platformMessageId: string;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  index: number;
  threadId?: string;
  replyToId?: string;
  editToken?: string;
  deleteToken?: string;
  url?: string;
  raw?: unknown;
};

​

Ngữ cảnh nhận

type MessageReceiveContext = {
  id: string;
  channel: string;
  accountId?: string;
  input: ChannelMessage;
  ack: ReceiveAckController;
  route: MessageRouteController;
  session: MessageSessionController;
  log: MessageLifecycleLogger;

  dedupe(): Promise<ReceiveDedupeResult>;
  resolve(): Promise<ResolvedInboundMessage>;
  record(resolved: ResolvedInboundMessage): Promise<RecordResult>;
  dispatch(recorded: RecordResult): Promise<DispatchResult>;
  commit(result: DispatchResult): Promise<void>;
  fail(error: unknown): Promise<void>;
};

platform event
  -> begin receive context
  -> normalize
  -> classify
  -> dedupe and self-echo gate
  -> route and authorize
  -> record inbound session metadata
  -> dispatch agent run
  -> durable outbound sends happen through send context
  -> commit receive
  -> ack platform when policy allows

• Xác nhận transport: cho webhook hoặc socket của nền tảng biết rằng OpenClaw đã chấp nhận phong bì sự kiện. Một số nền tảng yêu cầu điều này trước khi điều phối.
• Xác nhận offset polling: tiến một con trỏ để cùng sự kiện không bị lấy lại. Điều này không được tiến qua công việc không thể khôi phục.
• Xác nhận bản ghi đầu vào: xác nhận OpenClaw đã lưu bền vững đủ metadata đầu vào để khử trùng lặp và định tuyến một lần gửi lại.
• Biên nhận người dùng nhìn thấy: hành vi đọc/trạng thái/đang nhập tùy chọn; không bao giờ là ranh giới độ bền.

function shouldDropOpenClawEcho(params: {
  origin?: MessageOrigin;
  isBotAuthor: boolean;
  isRoomish: boolean;
}): boolean {
  return (
    params.isBotAuthor &&
    params.isRoomish &&
    params.origin?.source === "openclaw" &&
    params.origin.kind === "gateway_failure" &&
    params.origin.echoPolicy === "drop_bot_room_echo"
  );
}

type ReceiveAckPolicy =
  | { kind: "immediate"; reason: "webhook-timeout" | "platform-contract" }
  | { kind: "after-record" }
  | { kind: "after-durable-send" }
  | { kind: "manual" };

​

Ngữ cảnh gửi

type MessageSendContext = {
  id: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  intent: DurableSendIntent;
  attempt: number;
  signal: AbortSignal;
  previousReceipt?: MessageReceipt;
  preview?: LiveMessageState;
  log: MessageLifecycleLogger;

  render(): Promise<RenderedMessageBatch>;
  previewUpdate(rendered: RenderedMessageBatch): Promise<LiveMessageState>;
  send(rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit(receipt: MessageReceipt, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  delete(receipt: MessageReceipt): Promise<void>;
  commit(receipt: MessageReceipt): Promise<void>;
  fail(error: unknown): Promise<void>;
};

await core.messages.withSendContext(message, async (ctx) => {
  const rendered = await ctx.render();

  if (ctx.preview?.canFinalizeInPlace) {
    return await ctx.edit(ctx.preview.receipt, rendered);
  }

  return await ctx.send(rendered);
});

begin durable intent
  -> render
  -> optional preview/edit/stream work
  -> mark sending
  -> final platform send or final edit
  -> mark committing with raw receipt
  -> commit receipt
  -> ack durable intent
  -> fail durable intent on classified failure

type MessageDurabilityPolicy = "required" | "best_effort" | "disabled";

type RenderedMessageBatch = {
  units: RenderedMessageUnit[];
  atomicity: "all_or_retry_remaining" | "best_effort_parts";
  idempotencyKey: string;
};

type RenderedMessageUnit = {
  index: number;
  kind: "text" | "media" | "voice" | "card" | "preview" | "unknown";
  payload: unknown;
  required: boolean;
};

​

Ngữ cảnh trực tiếp

type MessageLiveAdapter = {
  begin?(ctx: MessageSendContext): Promise<LiveMessageState>;
  update?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    update: LiveMessageUpdate,
  ): Promise<LiveMessageState>;
  finalize?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    final: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  cancel?(
    ctx: MessageSendContext,
    state: LiveMessageState,
    reason: LiveCancelReason,
  ): Promise<void>;
};

type LiveMessageState = {
  mode: "partial" | "block" | "progress" | "native";
  receipt?: MessageReceipt;
  visibleSince?: number;
  canFinalizeInPlace: boolean;
  lastRenderedHash?: string;
  staleAfterMs?: number;
};

• Telegram gửi kèm bản xem trước chỉnh sửa, với bản cuối mới sau khi bản xem trước quá cũ.
• Discord gửi kèm bản xem trước chỉnh sửa, hủy khi có media/lỗi/trả lời rõ ràng.
• Slack dùng stream gốc hoặc bản xem trước nháp tùy theo hình dạng luồng.
• Hoàn tất bài đăng nháp Mattermost.
• Hoàn tất sự kiện nháp Matrix hoặc biên tập xóa khi không khớp.
• Stream tiến trình gốc của Teams.
• Stream QQ Bot hoặc dự phòng tích lũy.

​

Bề mặt adapter

import { defineChannelMessageAdapter } from "openclaw/plugin-sdk/channel-message";

type ChannelMessageAdapter = {
  receive?: MessageReceiveAdapter;
  send: MessageSendAdapter;
  live?: MessageLiveAdapter;
  origin?: MessageOriginAdapter;
  render?: MessageRenderAdapter;
  capabilities: MessageCapabilities;
};

type MessageSendAdapter = {
  send(ctx: MessageSendContext, rendered: RenderedMessageBatch): Promise<MessageReceipt>;
  edit?(
    ctx: MessageSendContext,
    receipt: MessageReceipt,
    rendered: RenderedMessageBatch,
  ): Promise<MessageReceipt>;
  delete?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  classifyError?(ctx: MessageSendContext, error: unknown): DeliveryFailureKind;
  reconcileUnknownSend?(ctx: MessageSendContext): Promise<MessageReceipt | null>;
  afterSendSuccess?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
  afterCommit?(ctx: MessageSendContext, receipt: MessageReceipt): Promise<void>;
};

type MessageReceiveAdapter<TRaw = unknown> = {
  normalize(raw: TRaw, ctx: MessageNormalizeContext): Promise<ChannelMessage>;
  classify?(message: ChannelMessage): Promise<MessageEventClass>;
  preflight?(message: ChannelMessage, event: MessageEventClass): Promise<MessagePreflightResult>;
  ackPolicy?(message: ChannelMessage, event: MessageEventClass): ReceiveAckPolicy;
};

type MessageOriginAdapter<TRaw = unknown, TNative = unknown> = {
  encode?(origin: MessageOrigin): TNative | undefined;
  decode?(raw: TRaw): MessageOrigin | undefined;
};

type MessageCapabilities = {
  text: { maxLength?: number; chunking?: boolean };
  attachments?: {
    upload: boolean;
    remoteUrl: boolean;
    voice?: boolean;
  };
  threads?: {
    reply: boolean;
    topic?: boolean;
    nativeThread?: boolean;
  };
  live?: {
    edit: boolean;
    delete: boolean;
    nativeStream?: boolean;
    progress?: boolean;
  };
  delivery?: {
    idempotencyKey?: boolean;
    retryAfter?: boolean;
    receiptRequired?: boolean;
  };
};

​

Thu gọn SDK công khai

• reply-runtime
• reply-dispatch-runtime
• reply-reference
• reply-chunking
• reply-payload
• inbound-reply-dispatch
• channel-reply-pipeline
• hầu hết cách dùng công khai của outbound-runtime
• các helper vòng đời stream nháp rời rạc

​

Quan hệ với lượt kênh

channel.turn.run
  -> messages.receive context
  -> session dispatch
  -> messages.send context for visible output

channel-owned dispatcher
  -> messages.receive record/finalize bridge
  -> messages.live for preview/progress
  -> messages.send for final delivery

​

Rào chắn tương thích

• channel.turn.run và dispatchAssembledChannelTurn dùng callback phân phối của kênh trừ khi kênh đó cung cấp rõ ràng một đối tượng chính sách/tùy chọn bền đã được kiểm tra.
• channel.turn.runPrepared vẫn thuộc sở hữu của kênh cho đến khi dispatcher đã chuẩn bị gọi rõ ràng ngữ cảnh gửi.
• Các helper tương thích công khai như recordInboundSessionAndDispatchReply, dispatchInboundReplyWithBase, và helper direct-DM không bao giờ chèn phân phối bền chung trước callback deliver hoặc reply do caller cung cấp.

• Hoạt động phân phối cuối cùng bền vững trả về trạng thái phân biệt. handled_visible và handled_no_send là trạng thái kết thúc; unsupported và not_applicable có thể dự phòng về cơ chế phân phối do kênh sở hữu; failed truyền tiếp lỗi gửi.
• Hoạt động phân phối cuối cùng bền vững chung được kiểm soát bởi các năng lực của adapter như phân phối im lặng, giữ nguyên đích trả lời, giữ nguyên trích dẫn gốc và hook gửi tin nhắn. Nếu thiếu tính tương đương, hãy chọn phân phối do kênh sở hữu, không chọn một lượt gửi chung làm thay đổi hành vi người dùng nhìn thấy.
• Các lượt gửi bền vững dựa trên hàng đợi hiển thị tham chiếu ý định phân phối. Các trường phiên pendingFinalDelivery* hiện có có thể mang id ý định trong giai đoạn chuyển đổi; trạng thái cuối là một kho MessageSendIntent thay vì văn bản trả lời bị đóng băng cộng với các trường ngữ cảnh tùy biến.

• Adapter gửi chung thực thi cùng hành vi kết xuất và vận chuyển như đường dẫn trực tiếp cũ.
• Các hiệu ứng phụ cục bộ sau khi gửi được giữ nguyên thông qua ngữ cảnh gửi.
• Adapter trả về biên nhận hoặc kết quả phân phối với tất cả id tin nhắn của nền tảng.
• Các đường dẫn dispatcher đã chuẩn bị hoặc gọi ngữ cảnh gửi mới, hoặc vẫn được ghi tài liệu là nằm ngoài bảo đảm bền vững.
• Phân phối dự phòng xử lý mọi payload đã chiếu, không chỉ payload đầu tiên.
• Phân phối dự phòng bền vững ghi lại toàn bộ mảng payload đã chiếu như một ý định có thể phát lại hoặc kế hoạch theo lô.

• Cơ chế phân phối trình giám sát iMessage ghi lại các tin nhắn đã gửi trong bộ nhớ đệm echo sau một lượt gửi thành công. Các lượt gửi cuối cùng bền vững vẫn phải điền bộ nhớ đệm đó, nếu không OpenClaw có thể nhập lại các trả lời cuối cùng của chính nó dưới dạng tin nhắn người dùng gửi vào.
• Tlon thêm chữ ký mô hình tùy chọn và ghi lại các luồng đã tham gia sau các trả lời nhóm. Phân phối bền vững chung không được bỏ qua các hiệu ứng đó; hãy chuyển chúng vào adapter kết xuất/gửi/hoàn tất của Tlon hoặc giữ Tlon trên đường dẫn do kênh sở hữu.
• Discord và các dispatcher đã chuẩn bị khác đã sở hữu hành vi phân phối trực tiếp và xem trước. Chúng chưa được bao phủ bởi bảo đảm bền vững cho lượt đã lắp ráp cho đến khi dispatcher đã chuẩn bị của chúng định tuyến rõ ràng các kết quả cuối qua ngữ cảnh gửi.
• Phân phối dự phòng im lặng của Telegram phải phân phối toàn bộ mảng payload đã chiếu. Lối tắt một payload có thể làm rơi các payload dự phòng bổ sung sau khi chiếu.
• LINE, BlueBubbles, Zalo, Nostr và các đường dẫn lắp ráp/hỗ trợ hiện có khác có thể có xử lý token trả lời, proxy media, bộ nhớ đệm tin nhắn đã gửi, dọn dẹp tải/trạng thái hoặc các đích chỉ callback. Chúng vẫn ở cơ chế phân phối do kênh sở hữu cho đến khi các ngữ nghĩa đó được biểu diễn bởi adapter gửi và được xác minh bằng kiểm thử.
• Các helper Direct-DM có thể có một callback trả lời là đích vận chuyển đúng duy nhất. Cơ chế gửi ra chung không được đoán từ OriginatingTo hoặc To và bỏ qua callback đó.
• Đầu ra lỗi của OpenClaw gateway phải vẫn hiển thị với con người, nhưng các echo trong phòng do bot tạo và đã gắn thẻ phải bị loại bỏ trước bước ủy quyền allowBots. Các kênh không được triển khai việc này bằng bộ lọc tiền tố văn bản hiển thị trừ khi là biện pháp dừng khẩn cấp ngắn hạn; hợp đồng bền vững là siêu dữ liệu nguồn có cấu trúc.

​

Lưu trữ nội bộ

type DurableSendIntent = {
  id: string;
  idempotencyKey: string;
  channel: string;
  accountId?: string;
  message: ChannelMessage;
  batch?: RenderedMessageBatch;
  liveState?: LiveMessageState;
  status:
    | "pending"
    | "sending"
    | "committing"
    | "unknown_after_send"
    | "sent"
    | "failed"
    | "cancelled";
  attempt: number;
  nextAttemptAt?: number;
  receipt?: MessageReceipt;
  partialReceipt?: MessageReceipt;
  failure?: DeliveryFailure;
  createdAt: number;
  updatedAt: number;
};

load pending or sending intents
  -> acquire idempotency lock
  -> skip if receipt already committed
  -> reconstruct send context
  -> render if needed
  -> reconcile unknown_after_send if needed
  -> call adapter send/edit/finalize
  -> commit receipt, mark unknown_after_send, or schedule retry

​

Lớp lỗi

type DeliveryFailureKind =
  | "transient"
  | "rate_limit"
  | "auth"
  | "permission"
  | "not_found"
  | "invalid_payload"
  | "conflict"
  | "cancelled"
  | "unknown";

• Thử lại transient và rate_limit.
• Không thử lại invalid_payload trừ khi có dự phòng kết xuất.
• Không thử lại auth hoặc permission cho đến khi cấu hình thay đổi.
• Với not_found, cho phép hoàn tất trực tiếp dự phòng từ chỉnh sửa sang gửi mới khi kênh tuyên bố việc đó là an toàn.
• Với conflict, dùng quy tắc biên nhận/idempotency để quyết định tin nhắn đã tồn tại hay chưa.
• Bất kỳ lỗi nào sau khi adapter có thể đã hoàn tất I/O nền tảng nhưng trước khi commit biên nhận đều trở thành unknown_after_send trừ khi adapter có thể chứng minh thao tác nền tảng đã không xảy ra.

​

Ánh xạ kênh

​

Kế hoạch di chuyển

​

Giai đoạn 1: Miền tin nhắn nội bộ

• Thêm các kiểu src/channels/message/* cho tin nhắn, mục tiêu, quan hệ, nguồn gốc, biên nhận, năng lực, ý định bền vững, ngữ cảnh nhận, ngữ cảnh gửi, ngữ cảnh trực tiếp và lớp lỗi.
• Thêm origin?: MessageOrigin vào kiểu tải dữ liệu cầu nối di chuyển dùng cho phân phối trả lời hiện tại, rồi chuyển trường đó sang ChannelMessage và các kiểu tin nhắn đã kết xuất khi quá trình tái cấu trúc thay thế tải dữ liệu trả lời.
• Giữ phần này nội bộ cho đến khi bộ điều hợp và kiểm thử chứng minh được hình dạng.
• Thêm kiểm thử đơn vị thuần cho chuyển đổi trạng thái và tuần tự hóa.

​

Giai đoạn 2: Lõi gửi bền vững

• Chuyển hàng đợi gửi đi hiện có từ độ bền tải dữ liệu trả lời sang các ý định gửi tin nhắn bền vững.
• Cho phép một ý định gửi bền vững mang một mảng tải dữ liệu đã chiếu hoặc kế hoạch lô, không chỉ một tải dữ liệu trả lời.
• Bảo toàn hành vi khôi phục hàng đợi hiện tại thông qua chuyển đổi tương thích.
• Cho deliverOutboundPayloads gọi messages.send.
• Đặt độ bền gửi cuối làm mặc định và đóng khi lỗi nếu ý định bền vững không thể được ghi trong vòng đời tin nhắn mới, sau khi bộ điều hợp khai báo an toàn phát lại. Các đường dẫn tương thích channel-turn và SDK hiện có vẫn mặc định gửi trực tiếp trong giai đoạn này.
• Ghi biên nhận nhất quán.
• Trả biên nhận và kết quả phân phối về cho bên gọi bộ điều phối ban đầu thay vì xem gửi bền vững là một hiệu ứng phụ kết thúc.
• Duy trì nguồn gốc tin nhắn qua các ý định gửi bền vững để khôi phục, phát lại và gửi theo đoạn vẫn bảo toàn provenance vận hành của OpenClaw.

​

Giai đoạn 3: Cầu nối lượt kênh

• Triển khai lại channel.turn.run và dispatchAssembledChannelTurn trên nền messages.receive và messages.send.
• Giữ ổn định các kiểu fact hiện tại.
• Giữ hành vi cũ theo mặc định. Một kênh assembled-turn chỉ trở nên bền vững khi bộ điều hợp của nó chọn tham gia rõ ràng với chính sách độ bền an toàn phát lại.
• Giữ durable: false làm cửa thoát tương thích cho các đường dẫn hoàn tất chỉnh sửa gốc và chưa thể phát lại an toàn, nhưng không dựa vào các dấu false để bảo vệ các kênh chưa được di chuyển.
• Chỉ mặc định hóa độ bền assembled-turn trong vòng đời tin nhắn mới, sau khi ánh xạ kênh chứng minh đường dẫn gửi chung bảo toàn ngữ nghĩa phân phối kênh cũ.

​

Giai đoạn 4: Cầu nối bộ điều phối đã chuẩn bị

• Thay deliverDurableInboundReplyPayload bằng cầu nối ngữ cảnh gửi.
• Giữ helper cũ dưới dạng wrapper.
• Chuyển Telegram, WhatsApp, Slack, Signal, iMessage và Discord trước vì chúng đã có công việc final bền vững hoặc đường dẫn gửi đơn giản hơn.
• Xem mọi dispatcher đã chuẩn bị là chưa được bao phủ cho đến khi nó chọn rõ dùng ngữ cảnh gửi. Tài liệu và mục changelog phải nói “lượt kênh đã lắp ráp” hoặc nêu tên các đường dẫn kênh đã di trú thay vì tuyên bố tất cả phản hồi final tự động.
• Giữ nguyên hành vi bảo toàn tương thích công khai của recordInboundSessionAndDispatchReply, các helper direct-DM và các helper tương tự. Chúng có thể cung cấp cơ chế chọn tham gia ngữ cảnh gửi rõ ràng sau này, nhưng không được tự động thử phân phối bền vững generic trước callback phân phối do caller sở hữu.

​

Giai đoạn 5: Vòng đời Live hợp nhất

• Xây dựng messages.live với hai bộ điều hợp chứng minh:
  • Telegram cho gửi cộng chỉnh sửa cộng gửi final mới khi bị stale.
  • Matrix cho hoàn tất draft cộng fallback redaction.
• Sau đó di trú Discord, Slack, Mattermost, Teams, QQ Bot và Feishu.
• Chỉ xóa mã hoàn tất preview trùng lặp sau khi mỗi kênh có kiểm thử ngang bằng.

​

Giai đoạn 6: SDK công khai

• Thêm openclaw/plugin-sdk/channel-message.
• Ghi tài liệu rằng đây là API Plugin kênh được ưu tiên.
• Cập nhật package exports, inventory entrypoint, baseline API sinh ra và tài liệu SDK Plugin.
• Bao gồm MessageOrigin, các hook encode/decode origin và predicate dùng chung shouldDropOpenClawEcho trong bề mặt SDK channel-message.
• Giữ các wrapper tương thích cho subpath cũ.
• Đánh dấu các helper SDK mang tên reply là đã ngừng khuyến nghị trong tài liệu sau khi các Plugin đi kèm được di trú.

​

Giai đoạn 7: Tất cả sender

• thông báo cron và heartbeat
• hoàn tất tác vụ
• kết quả hook
• prompt phê duyệt và kết quả phê duyệt
• gửi từ message tool
• thông báo hoàn tất subagent
• gửi rõ ràng từ CLI hoặc Control UI
• đường dẫn tự động hóa/broadcast

​

Giai đoạn 8: Ngừng khuyến nghị Turn

• Giữ channel.turn dưới dạng wrapper trong ít nhất một cửa sổ tương thích.
• Xuất bản ghi chú di trú.
• Chạy kiểm thử tương thích SDK Plugin với các import cũ.
• Chỉ xóa hoặc ẩn helper nội bộ cũ sau khi không còn Plugin đi kèm nào cần chúng và các hợp đồng bên thứ ba đã có thay thế ổn định.

​

Kế hoạch kiểm thử

• Tuần tự hóa và khôi phục intent gửi bền vững.
• Tái sử dụng khóa idempotency và chặn trùng lặp.
• Commit receipt và bỏ qua replay.
• Khôi phục unknown_after_send có đối soát trước khi replay khi bộ điều hợp hỗ trợ đối soát.
• Chính sách phân loại lỗi.
• Trình tự chính sách ack khi nhận.
• Ánh xạ quan hệ cho các lượt gửi reply, followup, system và broadcast.
• Factory origin cho lỗi Gateway và predicate shouldDropOpenClawEcho.
• Bảo toàn origin qua chuẩn hóa payload, chunking, tuần tự hóa hàng đợi bền vững và khôi phục.

• Bộ điều hợp đơn giản channel.turn.run vẫn ghi nhận và gửi.
• Phân phối assembled-turn cũ không trở thành bền vững trừ khi kênh chọn tham gia rõ ràng.
• Cầu nối channel.turn.runPrepared vẫn ghi nhận và hoàn tất.
• Helper tương thích công khai mặc định gọi callback phân phối do caller sở hữu và không generic-send trước các callback đó.
• Phân phối fallback bền vững replay toàn bộ mảng payload đã chiếu sau khi khởi động lại và không thể để các payload sau đó chưa được ghi nhận sau một crash sớm.
• Phân phối assembled-turn bền vững trả về id tin nhắn nền tảng cho dispatcher đã buffer.
• Hook phân phối tùy chỉnh vẫn trả về id tin nhắn nền tảng khi phân phối bền vững bị tắt hoặc không khả dụng.
• Reply final sống sót qua khởi động lại giữa lúc assistant hoàn tất và gửi lên nền tảng.
• Draft preview hoàn tất tại chỗ khi được phép.
• Draft preview bị hủy hoặc redacted khi media/lỗi/không khớp mục tiêu reply yêu cầu phân phối bình thường.
• Block streaming và preview streaming không cùng phân phối cùng một văn bản.
• Media được stream sớm không bị nhân đôi trong phân phối final.

• Reply topic Telegram với polling ack bị trì hoãn cho đến watermark completed an toàn của ngữ cảnh nhận.
• Khôi phục polling Telegram cho các update đã chấp nhận nhưng chưa phân phối được bao phủ bởi mô hình offset safe-completed đã lưu.
• Preview stale của Telegram gửi final mới và dọn preview.
• Fallback silent của Telegram gửi mọi payload fallback đã chiếu.
• Độ bền fallback silent của Telegram ghi nhận toàn bộ mảng fallback đã chiếu một cách nguyên tử, không phải một intent bền vững một payload cho mỗi vòng lặp.
• Discord hủy preview khi có media/lỗi/reply rõ ràng.
• Final của dispatcher đã chuẩn bị trong Discord đi qua ngữ cảnh gửi trước khi tài liệu hoặc changelog tuyên bố độ bền final-reply của Discord.
• Gửi final bền vững của iMessage điền cache echo tin nhắn đã gửi của monitor.
• Đường dẫn phân phối cũ của LINE, BlueBubbles, Zalo và Nostr không bị bỏ qua bởi gửi bền vững generic cho đến khi có kiểm thử ngang bằng cho bộ điều hợp của chúng.
• Phân phối callback Direct-DM/Nostr vẫn có thẩm quyền trừ khi được di trú rõ ràng sang mục tiêu tin nhắn hoàn chỉnh và bộ điều hợp gửi an toàn khi replay.
• Tin nhắn lỗi Gateway OpenClaw được gắn thẻ của Slack vẫn hiển thị outbound, echo bot-room được gắn thẻ bị loại trước allowBots, và tin nhắn bot không gắn thẻ có cùng văn bản hiển thị vẫn đi theo ủy quyền bot bình thường.
• Fallback stream native của Slack sang draft preview trong DM cấp cao nhất.
• Hoàn tất preview và fallback redaction của Matrix.
• Echo phòng lỗi Gateway OpenClaw được gắn thẻ trong Matrix từ tài khoản bot đã cấu hình bị loại trước khi xử lý allowBots.
• Audit cascade lỗi Gateway trong phòng dùng chung của Discord và Google Chat bao phủ các chế độ allowBots trước khi tuyên bố có bảo vệ generic ở đó.
• Hoàn tất draft và fallback gửi mới của Mattermost.
• Hoàn tất tiến trình native của Teams.
• Chặn final trùng lặp của Feishu.
• Fallback timeout accumulator của QQ Bot.
• Gửi final bền vững của Tlon bảo toàn rendering model-signature và theo dõi thread đã tham gia.
• Gửi final bền vững đơn giản của WhatsApp, Signal, iMessage, Google Chat, LINE, IRC, Nostr, Nextcloud Talk, Synology Chat, Tlon, Twitch, Zalo và Zalo Personal.

• Các file Vitest mục tiêu trong quá trình phát triển.
• pnpm check:changed trong Testbox cho toàn bộ bề mặt đã thay đổi.
• pnpm check rộng hơn trong Testbox trước khi land toàn bộ refactor hoặc sau thay đổi SDK/export công khai.
• Smoke live hoặc qa-channel cho ít nhất một kênh có khả năng chỉnh sửa và một kênh chỉ gửi đơn giản trước khi xóa wrapper tương thích.

​

Câu hỏi mở

• Liệu Telegram cuối cùng có nên thay nguồn runner grammY bằng một nguồn polling hoàn toàn bền vững có thể kiểm soát việc phân phối lại ở cấp nền tảng, không chỉ watermark khởi động lại đã lưu của OpenClaw.
• Liệu trạng thái live preview bền vững nên được lưu trong cùng bản ghi hàng đợi với intent gửi final hay trong kho live-state sibling.
• Wrapper tương thích nên tiếp tục được ghi tài liệu bao lâu sau khi plugin-sdk/channel-message được phát hành.
• Liệu Plugin bên thứ ba nên triển khai trực tiếp bộ điều hợp nhận hay chỉ cung cấp các hook normalize/send/live thông qua defineChannelMessageAdapter.
• Trường receipt nào an toàn để đưa ra SDK công khai so với trạng thái runtime nội bộ.
• Liệu side effect như cache self-echo và marker thread đã tham gia nên được mô hình hóa thành hook ngữ cảnh gửi, bước finalize do bộ điều hợp sở hữu hay subscriber receipt.
• Kênh nào có metadata origin native, kênh nào cần registry outbound đã lưu, và kênh nào không thể cung cấp cơ chế chặn echo liên bot đáng tin cậy.

​

Tiêu chí chấp nhận

• Mọi kênh tin nhắn đi kèm gửi output hiển thị final qua messages.send.
• Mọi kênh tin nhắn inbound đi vào qua messages.receive hoặc một wrapper tương thích được ghi tài liệu.
• Mọi kênh preview/edit/stream dùng messages.live cho trạng thái draft và hoàn tất.
• channel.turn chỉ là wrapper.
• Helper SDK mang tên reply là export tương thích, không phải đường dẫn được khuyến nghị.
• Khôi phục bền vững có thể replay các lượt gửi final đang chờ sau khi khởi động lại mà không làm mất phản hồi final hoặc nhân đôi các lượt gửi đã commit; các lượt gửi có kết quả nền tảng không xác định được đối soát trước khi replay hoặc được ghi tài liệu là at-least-once cho bộ điều hợp đó.
• Gửi final bền vững fail closed khi intent bền vững không thể được ghi, trừ khi caller chọn rõ ràng một chế độ không bền vững đã ghi tài liệu.
• Helper tương thích channel-turn và SDK cũ mặc định dùng phân phối trực tiếp do kênh sở hữu; gửi bền vững generic chỉ là opt-in rõ ràng.
• Receipt bảo toàn tất cả id tin nhắn nền tảng cho phân phối nhiều phần và một id chính để tiện threading/edit.
• Wrapper bền vững bảo toàn side effect cục bộ của kênh trước khi thay thế callback phân phối trực tiếp.
• Dispatcher đã chuẩn bị không được tính là bền vững cho đến khi đường dẫn phân phối final của chúng dùng rõ ràng ngữ cảnh gửi.
• Phân phối fallback xử lý mọi payload đã chiếu.
• Phân phối fallback bền vững ghi nhận mọi payload đã chiếu trong một intent hoặc batch plan có thể replay.
• Output lỗi Gateway có nguồn gốc từ OpenClaw hiển thị với con người nhưng echo phòng do bot tạo được gắn thẻ bị loại trước ủy quyền bot trên các kênh tuyên bố hỗ trợ hợp đồng origin.
• Tài liệu giải thích send, receive, live, state, receipts, relations, chính sách lỗi, di trú và phạm vi kiểm thử.

​

Liên quan

• Tin nhắn
• Streaming và chunking
• Draft tiến trình
• Chính sách retry
• Kernel lượt kênh