Messages and delivery

Hàng đợi lệnh

Chúng tôi tuần tự hóa các lượt chạy tự động trả lời đến (tất cả kênh) qua một hàng đợi nhỏ trong tiến trình để ngăn nhiều lượt chạy tác tử va chạm, trong khi vẫn cho phép chạy song song an toàn giữa các phiên.

Lý do

Các lượt chạy tự động trả lời có thể tốn kém (lệnh gọi LLM) và có thể va chạm khi nhiều tin nhắn đến gần nhau.
Tuần tự hóa giúp tránh cạnh tranh tài nguyên dùng chung (tệp phiên, nhật ký, stdin của CLI) và giảm khả năng gặp giới hạn tốc độ từ thượng nguồn.

Cách hoạt động

Một hàng đợi FIFO có nhận biết làn xử lý từng làn với giới hạn đồng thời có thể cấu hình (mặc định 1 cho các làn chưa cấu hình; main mặc định là 4, subagent là 8).
runEmbeddedAgent đưa vào hàng đợi theo khóa phiên (làn session:<key>) để đảm bảo chỉ có một lượt chạy đang hoạt động cho mỗi phiên.
Sau đó, mỗi lượt chạy phiên được đưa vào một làn toàn cục (mặc định là main) để giới hạn mức song song tổng thể bằng agents.defaults.maxConcurrent.
Khi bật ghi nhật ký chi tiết, các lượt chạy trong hàng đợi sẽ phát ra một thông báo ngắn nếu đã chờ hơn khoảng 2 giây trước khi bắt đầu.
Chỉ báo đang nhập vẫn kích hoạt ngay khi đưa vào hàng đợi (khi kênh hỗ trợ), nên trải nghiệm người dùng không thay đổi trong lúc chờ đến lượt.

Mặc định

Khi chưa đặt, tất cả bề mặt kênh đến dùng:

mode: "steer"
debounceMs: 500
cap: 20
drop: "summarize"

Điều hướng cùng lượt là mặc định. Một prompt đến giữa lượt chạy sẽ được chèn vào môi trường thực thi đang hoạt động khi lượt chạy có thể nhận điều hướng, vì vậy không khởi động lượt chạy phiên thứ hai. Nếu lượt chạy đang hoạt động không thể nhận điều hướng, OpenClaw sẽ chờ lượt chạy đang hoạt động kết thúc trước khi bắt đầu prompt.

Chế độ hàng đợi

/queue kiểm soát cách các tin nhắn đến bình thường hoạt động khi một phiên đã có một lượt chạy đang hoạt động:

steer: chèn tin nhắn vào môi trường thực thi đang hoạt động. OpenClaw gửi tất cả tin nhắn điều hướng đang chờ sau khi lượt trợ lý hiện tại thực thi xong các lệnh gọi công cụ, trước lệnh gọi LLM tiếp theo; Codex app-server nhận một turn/steer được gộp. Nếu lượt chạy không đang chủ động truyền luồng hoặc không có điều hướng, OpenClaw sẽ chờ cho đến khi lượt chạy đang hoạt động kết thúc trước khi bắt đầu prompt.
followup: không điều hướng. Đưa từng tin nhắn vào hàng đợi cho một lượt tác tử sau khi lượt chạy hiện tại kết thúc.
collect: không điều hướng. Gộp các tin nhắn trong hàng đợi thành một lượt theo dõi duy nhất sau cửa sổ yên lặng. Nếu tin nhắn nhắm đến các kênh/luồng khác nhau, chúng được xả riêng để giữ nguyên định tuyến.
interrupt: hủy lượt chạy đang hoạt động cho phiên đó, rồi chạy tin nhắn mới nhất.

Để biết thời điểm và hành vi phụ thuộc theo từng môi trường thực thi, xem Hàng đợi điều hướng. Đối với lệnh /steer <message> rõ ràng, xem Điều hướng.

Cấu hình toàn cục hoặc theo từng kênh qua messages.queue:

json5

{  messages: {    queue: {      mode: "steer",      debounceMs: 500,      cap: 20,      drop: "summarize",      byChannel: { discord: "collect" },    },  },}

Tùy chọn hàng đợi

Các tùy chọn áp dụng cho việc gửi trong hàng đợi. debounceMs cũng đặt cửa sổ yên lặng điều hướng Codex trong chế độ steer:

debounceMs: cửa sổ yên lặng trước khi xả các lượt theo dõi trong hàng đợi hoặc các lô thu thập; trong chế độ Codex steer, là cửa sổ yên lặng trước khi gửi turn/steer được gộp. Số trần là mili giây; các đơn vị ms, s, m, h và d được tùy chọn /queue chấp nhận.
cap: số tin nhắn tối đa trong hàng đợi cho mỗi phiên. Giá trị dưới 1 bị bỏ qua.
drop: "summarize": mặc định. Bỏ các mục cũ nhất trong hàng đợi khi cần, giữ các tóm tắt gọn và chèn chúng dưới dạng prompt theo dõi tổng hợp.
drop: "old": bỏ các mục cũ nhất trong hàng đợi khi cần, không giữ tóm tắt.
drop: "new": từ chối tin nhắn mới nhất khi hàng đợi đã đầy.

Mặc định: debounceMs: 500, cap: 20, drop: summarize.

Điều hướng và truyền luồng

Khi truyền luồng của kênh là partial hoặc block, điều hướng có thể trông giống nhiều phản hồi ngắn hiển thị trong lúc lượt chạy đang hoạt động đi tới các ranh giới môi trường thực thi:

partial: bản xem trước có thể hoàn tất sớm, rồi một bản xem trước mới bắt đầu sau khi điều hướng được chấp nhận.
block: các khối có kích thước như bản nháp có thể tạo ra cùng dạng xuất hiện tuần tự.
Không có truyền luồng, điều hướng sẽ chuyển dự phòng sang một lượt theo dõi sau lượt chạy đang hoạt động khi môi trường thực thi không thể nhận điều hướng cùng lượt.

steer không hủy các công cụ đang chạy. Dùng /queue interrupt khi tin nhắn mới nhất cần hủy lượt chạy hiện tại.

Thứ tự ưu tiên

Để chọn chế độ, OpenClaw phân giải:

Ghi đè /queue trực tiếp hoặc đã lưu theo từng phiên.
messages.queue.byChannel.<channel>.
messages.queue.mode.
Mặc định steer.

Đối với tùy chọn, các tùy chọn /queue trực tiếp hoặc đã lưu thắng cấu hình. Sau đó áp dụng debounce theo kênh (messages.queue.debounceMsByChannel), mặc định debounce của Plugin, tùy chọn messages.queue toàn cục và mặc định tích hợp. cap và drop là tùy chọn toàn cục/phiên, không phải khóa cấu hình theo kênh.

Ghi đè theo từng phiên

Gửi /queue <steer|followup|collect|interrupt> như một lệnh độc lập để lưu chế độ hàng đợi cho phiên hiện tại.
Có thể kết hợp tùy chọn: /queue collect debounce:0.5s cap:25 drop:summarize
/queue default hoặc /queue reset xóa ghi đè phiên.

Phạm vi và bảo đảm

Áp dụng cho các lượt chạy tác tử tự động trả lời trên tất cả kênh đến dùng pipeline trả lời Gateway (web WhatsApp, Telegram, Slack, Discord, Signal, iMessage, webchat, v.v.).
Làn mặc định (main) áp dụng toàn tiến trình cho tin nhắn đến + Heartbeat chính; đặt agents.defaults.maxConcurrent để cho phép nhiều phiên chạy song song.
Có thể tồn tại các làn bổ sung (ví dụ cron, cron-nested, nested, subagent) để các tác vụ nền có thể chạy song song mà không chặn trả lời đến. Các lượt tác tử Cron cô lập giữ một vị trí cron trong khi phần thực thi tác tử bên trong dùng cron-nested; cả hai dùng cron.maxConcurrentRuns. Các luồng nested không phải Cron dùng chung giữ hành vi làn riêng. Các lượt chạy tách rời này được theo dõi như tác vụ nền.
Các làn theo từng phiên bảo đảm rằng tại một thời điểm chỉ có một lượt chạy tác tử chạm vào một phiên nhất định.
Không có phụ thuộc bên ngoài hoặc luồng worker nền; thuần TypeScript + promise.

Khắc phục sự cố

Nếu lệnh có vẻ bị kẹt, bật nhật ký chi tiết và tìm các dòng "queued for ...ms" để xác nhận hàng đợi đang xả.
Nếu cần độ sâu hàng đợi, bật nhật ký chi tiết và theo dõi các dòng thời điểm hàng đợi.
Các lượt chạy Codex app-server nhận một lượt rồi ngừng phát tiến trình sẽ bị adapter Codex ngắt để làn phiên đang hoạt động có thể giải phóng thay vì chờ hết thời gian chờ lượt chạy bên ngoài.
Khi bật chẩn đoán, các phiên còn ở trạng thái processing quá diagnostics.stuckSessionWarnMs mà không quan sát thấy phản hồi, công cụ, trạng thái, khối hoặc tiến trình ACP sẽ được phân loại theo hoạt động hiện tại. Công việc đang hoạt động ghi nhật ký là session.long_running; các lệnh gọi mô hình im lặng có chủ sở hữu cũng vẫn là session.long_running cho đến diagnostics.stuckSessionAbortMs để các nhà cung cấp chậm hoặc không truyền luồng không bị báo là bị dừng quá sớm. Công việc đang hoạt động không có tiến trình gần đây ghi nhật ký là session.stalled; các lệnh gọi mô hình có chủ sở hữu chuyển sang session.stalled tại hoặc sau ngưỡng hủy, và hoạt động mô hình/công cụ cũ không có chủ sở hữu không bị ẩn dưới dạng chạy lâu. session.stuck được dành cho việc ghi sổ phiên cũ có thể phục hồi, bao gồm các phiên đang chờ nhàn rỗi có hoạt động mô hình/công cụ cũ không có chủ sở hữu, và chỉ đường dẫn đó mới có thể giải phóng làn phiên bị ảnh hưởng để công việc trong hàng đợi được xả. Các chẩn đoán session.stuck lặp lại sẽ lùi nhịp trong khi phiên vẫn không thay đổi.

Liên quan

Was this useful?