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 throughchannels serve qqbot.
At A Glance
Minimal Config
Smoke Test
QQ Bot [qqbot]appears in the gateway-supervised runtime setchannels serve qqbotstarts 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 throughchannels serve qqbot, or under Gateway And Supervision when the QQ Bot lane should join a larger supervised runtime set.
Operator Notes
- Keep
allowed_peer_idsexplicit and narrow. - Loong validates
allowed_peer_idslocally before forwarding a QQ send, so a mistyped openid is rejected before it reaches the upstream gateway. channels serve qqbotowns 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.
Related Docs
- 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.