Pallas-Bot: an Arknights-themed QQ repeater that learns from group chat
《明日方舟》帕拉斯 Bot！群聊复读机，群友聊什么牛牛就说什么，配合LLM做最懂你的牛牛！
At a glance
- What is it?
- Pallas-Bot is a NoneBot2 plugin stack that learns short phrases from group messages, repeats them on cue, and passes the same learned style into an LLM when someone explicitly at-mentions it. It is a Chinese-language group bot with a PostgreSQL dependency and a browser console, and the interesting engineering is in the corpus federation, not the chat.
- Who is it for?
- Adopt Pallas-Bot if you already run OneBot v11 (NapCat or equivalent), can give it PostgreSQL and Python 3.12+, and want a bot whose default behaviour is short group-chat mimicry rather than assistant-style replies. Do not adopt it if you need a general-purpose chat assistant, if you cannot host a database, or if the AGPL-3.0 network-copyleft terms do not fit how you intend to distribute your modified version.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Pallas-Bot actually solves
Most chat bots in a QQ group answer questions. Pallas-Bot's README states its premise directly: the bot is a repeater, and what the group members say is what it says back. The value is atmosphere, not utility. A group that already has inside jokes gets a participant that echoes their rhythm, and the README's own framing puts repetition ahead of the model: the LLM is described as supporting the repeater rather than replacing it.
The audience is narrow and specific. You need a QQ group, an OneBot v11 protocol endpoint such as NapCat, and a willingness to run PostgreSQL alongside the bot. The quickstart lists Python 3.12+ and PostgreSQL as prerequisites, with a Docker path for people who do not want to install Python at all. Someone running a Discord server or a Slack workspace is not the target, and the documentation site is written in Chinese, so an operator who cannot read it will be working from the repository alone.
Learning repeater, corpus federation, and where the LLM sits
There are three distinct mechanisms in the feature list, and they are worth separating because they have different failure modes.
The first is the learning repeater. The bot collects group chat as corpus, then decides when to interject, when to join a repeat chain, and when to attach an emoji. The README describes both the eagerness of interjection and the repeat frequency as configurable. This is a probabilistic behaviour driven by observed messages, not a script of canned responses.
The second is corpus federation. A deployment can optionally connect to a community-shared corpus pool to widen the pool of short phrases available for interjection. The README states that multiple deployments can share a pool and recognise each other, with deduplication by group ownership and by message, so the same line is not answered twice. That deduplication design is the part that matters operationally: without it, a shared pool would produce duplicate replies across deployments.
The third is the LLM path, and it is explicitly gated. Dialogue happens when someone at-mentions the bot, routed through a Bot Provider for multi-turn conversation. The README lists long-term group memory, observation of people, knowledge retrieval, web search and tool calls as supported. The output is constrained by the account persona and by the group's own expression style. That style guidance is learned per account and per group, which the README says keeps different accounts in the same group from interfering with each other. In other words, the LLM is not the default mode of the bot. It is the mode you enter by addressing it.
Getting a deployment running from the README
The quickstart is short enough to reproduce here. Clone the repository, install dependencies with uv, copy the example config, edit it, and run.
git clone https://github.com/PallasBot/Pallas-Bot.git cd Pallas-Bot pip install uv uv sync cp config/pallas.example.toml config/pallas.toml uv run pallas
The README instructs you to edit the [bootstrap] section of config/pallas.toml on first deployment: the listener settings, the superusers list, and the [bootstrap.postgres] block. Those three are the minimum. The bot then serves a browser console at http://<host>:8088/pallas/, and you log in with the key printed in the startup log. That key is the only credential mentioned in the quickstart, so treat the startup log as sensitive.
Beyond the bootstrap section, the README points to the documentation site for the full quickstart, and separately for the corpus federation and community statistics pages. The example config is the authoritative list of keys; the README does not enumerate the rest.
PostgreSQL, OneBot v11, and the deployment shape you are signing up for
This is not a single-binary bot you drop on a VPS and forget. The dependency list is Python 3.12+, PostgreSQL, and an OneBot v11 endpoint. That is three moving parts before the bot says anything, and two of them (the database and the protocol endpoint) are outside the project's control.
The architecture described in the feature list assumes a multi-process deployment. The README mentions background task delivery so slow operations do not block the message path, and multi-worker sharding for horizontal scaling. A single-process run via uv run pallas is the documented starting point, but the design clearly anticipates more than one worker. If you scale to multiple workers, the group-ownership and message-based deduplication in the corpus federation becomes load-bearing rather than optional, because two workers could otherwise answer the same message.
The WebUI is a separate concern. The console manages configuration, plugins, command permissions and message review, and the README mentions built-in LLM and AI observation and operations panels. The frontend lives in its own repository, Pallas-Bot-WebUI. If the console is the reason you are interested, note that it is a distributed component, not a page baked into the bot.
Where Pallas-Bot is the wrong tool
If your goal is a reliable question-answering assistant in a chat group, this is the wrong project. The README is candid that the LLM path is the newer, less settled part of the system, and that repetition comes first. A bot whose primary behaviour is echoing group members will, by design, produce noise. The configuration exposes interjection eagerness and repeat frequency precisely because the defaults are a matter of taste, and getting them wrong produces a bot that talks too much.
The second limitation is language and community fit. The project is built around Chinese-language QQ group culture, with the documentation site, the community centre and the developer groups all in Chinese. The learning repeater depends on corpus from real group conversation. Point it at a group that mostly posts links and it has little to learn from.
The third is the shared corpus. Joining the community pool widens the phrase source, but the README's own description of deduplication by group ownership implies that pool membership is a coordination problem, not a free upgrade. A self-hosted operator who wants strict control over what the bot says should read the corpus federation documentation before enabling it.
How it differs from a general NoneBot2 deployment
The obvious alternative is a plain NoneBot2 setup with an LLM plugin. NoneBot2 is the framework Pallas-Bot is built on, and the README notes that Pallas-Bot natively supports NoneBot plugins and can install from a built-in store. So the comparison is not framework against framework. It is a curated stack against assembling your own.
A plain NoneBot2 deployment gives you a message router and whatever plugins you pick. You would write the interjection logic, the corpus storage, the style extraction and the console yourself. Pallas-Bot ships all of that as one opinionated system: a PostgreSQL schema, a WebUI, a plugin store, and a learned style layer that feeds the LLM prompt. The trade is that you inherit its opinions. Its repetition behaviour, its corpus federation protocol and its configuration surface are not things you tune from scratch; they are things you configure within the range the project exposes.
If you have already built group-chat memory and persona handling into your own bot, adopting Pallas-Bot means discarding that work or running two bots. If you have not, and you want the repeater behaviour specifically, the assembled version saves you the corpus and deduplication engineering, which is the part that is genuinely fiddly.
Maintenance, releases, and the AGPL-3.0 question
The release cadence visible in the material is dense. Three releases landed between 5 and 9 September 2026 (v4.4.0, v4.4.1, v4.4.2), and the last push to main is dated 10 September 2026. That suggests active development, and it also means you should expect to track versions rather than pin once and walk away. The README's own note about V3 describes a rewrite that split the kernel from extensions and separated the console from the runtime, with docs, WebUI, AI runtime, community statistics and the plugin index each moved to their own repository. That split is good for maintenance and worse for anyone who wants a single checkout.
The licence is AGPL-3.0. This is the network-copyleft variant: if you run a modified version as a network service, the licence terms attach to what you serve. For a self-hosted group bot that you never distribute, this is usually unremarkable. For anyone planning to offer a hosted Pallas-Bot derivative to other groups, the obligation is the point of the licence and should be read in full before you build on it. I am not a lawyer and this is not legal advice; read LICENSE in the repository.
The optional capabilities are separate repositories. Singing and TTS live in Pallas-Bot-AI, and the MAA remote control feature is documented as a plugin rather than part of the core. Each carries its own licence and its own dependency footprint, so enabling them is a second decision, not a checkbox.
Editorial conclusion
Adopt Pallas-Bot if you already run OneBot v11 (NapCat or equivalent), can give it PostgreSQL and Python 3.12+, and want a bot whose default behaviour is short group-chat mimicry rather than assistant-style replies. Do not adopt it if you need a general-purpose chat assistant, if you cannot host a database, or if the AGPL-3.0 network-copyleft terms do not fit how you intend to distribute your modified version. Before committing, read the corpus federation documentation and decide whether your deployment joins the shared pool, then check the [bootstrap] block in config/pallas.toml against your listener address, superuser list and PostgreSQL credentials, and confirm the WebUI port 8088 does not collide with anything already bound on the host.
Community notes