MuseBot: One Go Binary for Telegram, Slack, Lark and WeChat LLM Bots

The integration tax MuseBot is trying to remove

Every messaging platform ships its own bot SDK, its own callback verification, its own message format and its own way of uploading an image. A team that wants an LLM answering questions in Telegram, Slack and a company Lark tenant normally writes three adapters, three retry policies and three ways to strip formatting the model did not mean to emit. MuseBot's premise is that this adapter layer is commodity work and should be written once in Go.

The project targets two groups. The first is small engineering teams inside companies that already live in Lark (Feishu), DingTalk, WeCom or QQ and want an internal assistant without building a bot framework. The second is individual developers who want the same bot reachable from Telegram, Discord and Slack without maintaining three codebases. The README's feature list goes beyond text: image recognition, voice input, function calling over MCP, RAG, an admin platform, service registration, Prometheus metrics and cron-triggered LLM calls. That is a lot of surface for one repository, and the honest reading is that MuseBot is closer to a small platform than to a bot script.

How the Go architecture splits platforms, LLMs and storage

The top-level layout is the clearest documentation of the design. Platform adapters live under robot/, LLM providers under llm/, retrieval under rag/, the web console under admin/, HTTP handling under http/, configuration under conf/ and param/, and storage under db/ and data/. A single main.go wires them together. That separation is why adding a platform does not require touching provider code.

go.mod confirms the adapters are real vendor SDKs rather than hand-rolled HTTP: go-telegram-bot-api for Telegram, discordgo for Discord, slack-go for Slack, larksuite/oapi-sdk-go for Lark, alibabacloud-go/dingtalk plus open-dingtalk/dingtalk-stream-sdk-go for DingTalk, PowerWeChat for WeCom, and tencent-connect/botgo for QQ. Model access is similarly split, with go-openai, deepseek-go, go-openrouter, dashscopego for Doubao and the volcengine SDKs. RAG has three vector backends in the dependency list: Milvus, Qdrant and Weaviate, plus a fork of langchaingo. Storage is MySQL via go-sql-driver or SQLite via mattn/go-sqlite3.

That dependency set is the architecture. It also means the build pulls in cloud vendor SDKs for Alibaba and Tencent even if you only ever run the Telegram bot, because Go links what it imports. The README does not describe build tags or optional compilation, so there is no documented way to strip unused platforms out of the binary.

Building MuseBot locally and running a first Telegram bot

The Makefile is the shortest path to a working binary. It builds main.go into ./bin/MuseBot and prints the path when it finishes. Note that the Makefile's VERSION variable reads 0.0.14 while the latest release tag is v1.0.42; the two numbering schemes do not agree, so do not use the Makefile version as a release identifier.

make build
make run

The build target creates ./bin and compiles main.go; run executes that binary. The README does not state which configuration file the binary reads on startup, only that configuration lives under conf/, so check that directory before the first run rather than assuming defaults.

The Docker path is the one the README advertises with a badge. The Dockerfile is a multi-stage build: a golang:1.24 builder that installs pkg-config and libopus-dev, then a debian:stable-slim runtime that installs ca-certificates, curl, libopus0, supervisor and Node.js 20 from NodeSource. A separate stage downloads static FFmpeg and ffprobe binaries from johnvansickle.com and copies them into the runtime image. The image therefore carries a Node runtime and FFmpeg, which is the cost of the voice and video features.

docker build -t musebot .
docker run --rm musebot

For a first real use, the practical sequence is: build the image, mount or edit the conf/ directory so it holds your Telegram bot token and your chosen LLM provider key, start the container, then message the bot in a private chat. The README points to per-platform documents under static/doc/ (discord.md, slack.md, lark.md, dingding.md, com_wechat.md, qq.md, wechat.md, web_api.md) rather than inlining the token keys, so the exact environment variable or config key for each platform has to be read there.

Where MuseBot is the wrong tool

The dependency list is the first limitation. A Telegram-only bot built on go-telegram-bot-api is a few hundred lines and one dependency; MuseBot links Alibaba Cloud, Tencent Cloud, Volcengine, Milvus, Qdrant and Weaviate clients into the same binary. If you want a minimal bot you can audit in an afternoon, this repository is larger than the problem.

The second limitation is platform behaviour. The README's own table describes WeCom, QQ and WeChat as HTTP callback integrations, while Telegram uses the bot API, Lark and DingTalk use long connections, and Slack uses Socket Mode or the Events API. Those are not equivalent deployment shapes. An HTTP callback means the platform must be able to reach your host, which rules out a laptop behind NAT without a tunnel. A long connection means the bot dials out, which is easier to host but ties you to that SDK's reconnect behaviour. MuseBot unifies the code, not the network model.

The third is operational. The README lists an admin platform, a service registration module and Prometheus metrics, but it does not document rollback, schema migration or what happens to the SQLite or MySQL state when you move between versions. Releases exist (v1.0.40 in January 2026, v1.0.41, v1.0.42 in March 2026) and the repository was pushed on 2026-09-01, so work is ongoing, but the README is silent on upgrade mechanics. Treat the database as something you back up before every version change.

MuseBot compared with a single-platform bot framework

The natural alternative is to pick one platform's own framework and stay there: go-telegram-bot-api for Telegram, discordgo for Discord, slack-go for Slack. The difference is not quality, it is scope. Those libraries give you the platform primitives and nothing else. You write the LLM call, the conversation history, the streaming edit, the image download and the command parser yourself. In exchange you get a dependency tree you can read in full and a bot whose behaviour you can explain line by line.

MuseBot inverts that trade. You get the LLM call, streaming output, image and voice handling, function calling, RAG and cron triggers already wired, and you pay with a large transitive dependency set and configuration spread across conf/ and static/doc/. The choice is between writing adapters and reading someone else's. Neither is wrong; they fail in different ways. A hand-written adapter fails when you add the second platform. MuseBot fails when a vendor SDK changes behaviour underneath you and you have to wait for an upstream fix or fork.

There is a middle option worth naming: run MuseBot as a service and put your own thin client in front of its Web API, which the README lists as a supported platform with its own document. That keeps your custom frontend small while reusing the platform adapters you do not want to write.

Licence, maintenance and the real upgrade cost

MuseBot is MIT licensed. That is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and licence text are preserved. It does not grant trademark rights, and it offers no patent grant, which some corporate policies care about. Nothing here is legal advice; check with whoever handles licensing at your organisation.

The upgrade cost is dominated by the dependency graph, not by MuseBot's own code. The Dockerfile pins golang:1.24 for the build and debian:stable-slim for the runtime, and downloads FFmpeg from a third-party static build site at image build time. That download is a moving target: rebuilding the same Dockerfile months later can pull a different FFmpeg. If reproducibility matters, pin or vendor that artefact.

On maintenance, the facts are these: the repository is not archived, the last push was on 2026-09-01, and the most recent tagged release is v1.0.42 from 2026-03-17. The gap between the last push and the last tag means main carries work that is not in a release. If you deploy from main you are testing unreleased code; if you deploy from v1.0.42 you are on a tag that is roughly six months behind the branch.

Editorial conclusion

Adopt MuseBot if you already run several messaging platforms and want one Go process, one config file and one LLM key set behind all of them, and if you are comfortable reading static/doc/*.md because the README does not document rollback or upgrade paths. Do not adopt it if you need a single-platform bot with a small dependency tree, or if you cannot run a container with Node.js and FFmpeg inside it. Before committing, verify three things yourself: that your target platform's callback or long-connection mode is reachable from where you will host the bot, that the conf/ keys for your chosen LLM provider are documented for the version you build, and that the v1.0.42 tag on 2026-03-17 is the code you actually want, since the last push to main was on 2026-09-01 and the two are not the same commit.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yincongcyincong/MuseBot on GitHub