Skip to main content

QQ Bot

This is a shipped runtime-backed surface: direct sends are implemented, the reply-loop runtime is implemented, and Loong owns the QQ gateway session directly through channels serve qqbot.

At A Glance

Minimal Config

Smoke Test

What success looks like:
  • QQ Bot [qqbot] appears in the gateway-supervised runtime set
  • channels serve qqbot starts a native Loong-owned runtime instead of a managed plugin selection flow
  • doctor keeps direct send / serve readiness checks visible and actionable

Current Command Surface

Required Fields For Send

Required Fields For Serve

Stable Target Templates

Account Scope Note

QQ Bot openids are scoped to the selected account. Keep account ids stable so route meaning does not drift when you rotate gateway credentials or bridge implementations.

Runtime Notes

  • QQ Bot no longer depends on managed bridge discovery for its main shipped runtime path.
  • The native runtime uses the configured QQ gateway credentials directly.

Gateway And Ownership

This surface can run directly through channels serve qqbot, or under Gateway And Supervision when the QQ Bot lane should join a larger supervised runtime set.

Operator Notes

  • Keep allowed_peer_ids explicit and narrow.
  • Loong validates allowed_peer_ids locally before forwarding a QQ send, so a mistyped openid is rejected before it reaches the upstream gateway.
  • channels serve qqbot owns the runtime loop directly; failures belong to the native runtime path instead of an external managed-plugin selection layer.
  • Treat QQ Bot as a multi-account surface from the start if you expect separate direct, group, or guild identities.
  • Continue to Weixin for the WeChat bridge-first lane.
  • Continue to OneBot when the upstream bridge already speaks OneBot v11.
  • Continue to Gateway And Supervision when QQ Bot should join a longer-lived supervised runtime.
  • Continue to Channel Setup for the shared public setup contract.