NoneBot2 is a cross-platform, asynchronous chatbot framework written in Python, built for developers who want one codebase to serve bots across many chat platforms instead of rewriting integration glue for each one.

What it is

NoneBot2 is a modern, extensible Python framework for chat bots, built on Python's type annotations and asynchronous features. The project lives in the Python ecosystem and is distributed under the MIT licence; its registry topics include bot, chatbot, cqhttp, onebot, mirai-bot, lark-bot, dingtalk-robot and fastapi. The framework separates bot logic from platform plumbing through an adapter layer, so an application is written once while the adapter handles the protocol of the chat service the bot is talking to. Protocol support is extensible: adapters ship both inside the project and as separate repositories, and the framework allows custom communication protocols to be defined.

The concrete problem it solves is per-platform bot code. Without an abstraction layer, a developer targeting QQ, Telegram and Feishu would maintain three unrelated integrations with different authentication, event models and message formats. NoneBot2 replaces that duplication with one application surface and swappable adapters — the OneBot adapter alone covers QQ, Telegram, WeChat official accounts and KOOK, and the Satori adapter covers OneBot, Telegram, Feishu, WeChat official accounts and Koishi. The framework also removes the boilerplate around async event handling, which is where the "asynchronous first" design matters: the README states that even very large message volumes are handled comfortably.

Key capabilities

• Adapter matrix covering OneBot, Telegram, Feishu, GitHub, QQ, Console, Red, Satori, Discord, DoDo, Kritor, Mirai and Milky, each in its own repository with a specification link.
• GitHub adapter supports both GitHub APP and OAuth APP authentication.
• Console adapter provides console-based interaction for development and testing.
• Satori adapter bridges OneBot, Telegram, Feishu, WeChat official accounts and Koishi through one protocol.
• 100% type annotation coverage, which lets editor type inference catch most bugs before runtime, as described on the project's editor support page.
• NB-CLI scaffolding that keeps generated code free of unnecessary boilerplate so developers focus on business logic.
• Community-contributed adapters extend reach to Rocket.Chat, Tailchat, Mail, Minecraft, Ntchat, Walle-Q, VoceChat and Bilibili live rooms.

Who uses it and how

• QQ bot developers, who connect through OneBot, Mirai, Red for the QQNT protocol, Milky for the QQNT bot application interface standard, or Kritor, also known as OnebotX.
• Teams building assistant bots inside workplace chat, using the Feishu adapter, the WeChat official account adapters, or DingTalk, whose official adapter is currently marked as unavailable and seeking a maintainer.
• Community-server operators running Discord bots or DoDo bots from the same application code.
• Developers who need one bot across several ecosystems at once, typically via Satori or OneBot rather than one adapter per platform.
• The README reports more than one hundred thousand direct and indirect users, with large numbers of active users daily.

Getting started

Start from the project documentation at nonebot.dev, which includes a quickstart guide and a note on what to do when the documentation will not open. Development is scaffolded through NB-CLI, which generates the project skeleton so business logic can be written directly.

How it compares

The same space contains Mirai, a QQ protocol library reachable through the dedicated Mirai adapter, OneBot as a protocol standard with its own adapter, and Koishi, which NoneBot2 can reach through the Satori adapter. NoneBot2 differs from those by being the Python asynchronous framework around the protocols rather than a single protocol implementation or a JavaScript runtime. Adapter repositories keep that protocol work separable, so a bot keeps working when one platform is swapped.

When to use it — and when not to

Choose NoneBot2 when the bot logic is written in Python and needs to survive across multiple chat platforms, since the adapter boundary is where the project's value sits. Self-hosters should expect to run and maintain the chosen adapter themselves, and should check adapter status first: Villa is offline because the official Bot protocol was retired, Gewechat is no longer maintained or available, and DingTalk's adapter is looking for a maintainer. The documented caveat that QQ official interfaces change frequently is the clearest ongoing risk, and community-contributed adapters carry no compatibility promise.