CountBot: a Chinese-first AI Agent hub that the author has paused
更适配中文用户的轻量开源AI Agent | 国产大模型Coding plan支持 | 兼容OpenClaw Skills生态| 已接入微信ClawBot/微博龙虾/飞书/钉钉/QQ/小智AI/Telegram/deepseek-v4。
At a glance
- What is it?
- CountBot is a Python, MIT-licensed agent framework that wires LLM providers, Chinese IM channels, roles, teams and tools into one locally hosted runtime. Its README states the author has stopped active development, which changes who should look at it.
- Who is it for?
- CountBot suits developers who want to study or fork a Chinese-first agent runtime: the MIT licence, the start_app.py entry point and the uvicorn command for backend.app:app give you something concrete to run and read. It does not suit teams that need an actively maintained dependency, because the README states the author will not keep updating it.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- 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 gap CountBot is aimed at: Chinese IM channels and local deployment
Most agent runtimes assume an English-speaking user, a cloud account and a chat surface like Slack or Discord. CountBot's README frames the project as an answer to that: a lightweight framework and runtime hub built for Chinese users, deployable locally and intended to run for long periods. The stated goal is to connect models, IM channels, workflows and external tools so that the AI reaches the execution path rather than stopping at conversation.
The channel list is the clearest expression of that intent. The repository description names WeChat ClawBot, Weibo (龙虾), Feishu, DingTalk, QQ, 小智 AI, Telegram and deepseek-v4. The README's own summary adds Web, enterprise WeChat and Discord. For an engineer whose users live inside Feishu or DingTalk, that is the difference between an agent that can be reached and one that cannot.
The README is also explicit about lineage. It credits OpenClaw with validating local execution and autonomous agents, and says CountBot targets the gaps it sees around Chinese-language scenarios, lightweight deployment, ease of extension, and security governance. That is a positioning statement, not a benchmark, and the repository offers no comparative measurements to support it.
ReAct loop, three team modes, and a layered config model
The core capability table lists an Agent Loop built on ReAct reasoning, tool invocation, result feedback and iteration control. Around that sit three collaboration modes named in the README: pipeline, graph and council. They were introduced in v0.3.0 and the README does not describe their internal scheduling, so anyone choosing between them will need the documentation site rather than the repository front page.
Configuration is layered across four levels: global defaults, role, team, and session runtime. v0.4.0 introduced session-level config so different conversations can use different models and prompts; v0.5.0 extended the same idea to roles, teams and multi-bot setups. In practice this means a Feishu bot and a Telegram bot in the same workspace can carry different personas and different model choices without forking the deployment.
Memory and context handling are described as long-term memory, summarisation, context injection and session isolation. v0.8.0's notes add short-term summary caching, overflow history summarisation and automatic memory consolidation across a whole session. v0.9.0 then claims improved context management and a simplified greeting path that reduces LLM call cost. None of these claims come with numbers, so treat them as design intent.
The execution layer is where the project is most interesting and most exposed. Tools cover files, shell, web, screenshots, memory, workflows and media sending. Beyond that, CountBot can wrap external coding tools (Claude Code, Codex, OpenCode) either as tools a model can call or as agents bound to an IM channel. That second mode means a coding agent can be reached from a chat app, which is a genuinely different topology from the usual CLI-only setup.
Getting it running: two commands and two environment variables
The README gives a source path that needs nothing beyond Python and pip. Clone the repository, install requirements, start the app:
git clone https://github.com/countbot-ai/CountBot.git cd CountBot pip install -r requirements.txt python start_app.py
The default bind is http://127.0.0.1:8000. For users on mainland networks the README offers an Aliyun PyPI mirror flag (pip install -r requirements.txt -i https://mirrors.aliyun.com/pypi/simple/) and a Gitee clone URL as a GitHub alternative. Both are practical details that many projects omit.
Listening address and port are overridden by COUNTBOT_HOST and COUNTBOT_PORT, with those variables taking priority over defaults. The README shows PowerShell and cmd forms:
$env:COUNTBOT_HOST = '0.0.0.0' $env:COUNTBOT_PORT = '8001' python start_app.py
For development there is a second entry point that bypasses start_app.py:
uvicorn backend.app:app --reload --host 0.0.0.0 --port 8000
That uvicorn line is the single most informative detail in the README for an engineer evaluating the codebase: the application is an ASGI app exposed as backend.app:app, so the FastAPI-style layout is inspectable before you commit to anything. Two other config keys appear in the release notes rather than the quick start: REMOTE_SETUP_SECRET_TTL_MINUTES, added in v0.6.0 to control how long the remote first-run entry point at /setup/<random> stays valid. Remote exposure was tightened in the same release to cover /api/* and /ws/chat.
v0.9.0 adds MCP and a BM25 wiki, but leaves MCP off
The most recent release, v0.9.1 (2026-08-11), follows v0.9.0 (2026-05-05). The v0.9.0 notes are the substantive ones. They add an MCP client module with multi-server connections, health checks and tool discovery, plus MCP and Wiki management panels, a WebSocket module that broadcasts MCP connection state to frontend sessions, and an API key rotation mechanism with failover across multiple keys.
The Wiki module is described as BM25 full-text search with batch retrieval, relevance filtering and an LRU cache. BM25 is a lexical ranking function, not a vector embedding search, and that is a deliberate trade-off worth naming: it is cheap to run locally and needs no embedding model or vector store, but it will not match paraphrases the way semantic retrieval does. For a locally deployed assistant over a modest document set, that is often the right call. For a large corpus where users phrase questions loosely, it will underperform.
The MCP client is off by default. The release notes describe it as a feature added for users who want it, which means turning it on is a decision you make in configuration, not something you inherit. That is a defensible default for a local runtime with shell and file access: every MCP server you connect is another process with its own permissions. The README does not state what the health check does when a server fails, only that health checks exist.
The author has paused development, and the README says so
This is the fact that should drive the decision. The project status section states that CountBot will not be continuously updated by the author in the near term, and that it is currently intended for learning, research and secondary development by people interested in AI agents. Pull requests are invited for issues, documentation, fixes and new capabilities.
That is an unusually frank disclosure, and it reframes everything else. The v0.9.x line is not a stable platform with a maintenance commitment behind it. It is a snapshot. If you adopt CountBot as infrastructure for a production workflow, you are implicitly accepting that you may become the maintainer.
The release history also shows a fast-moving project that has just stopped moving. Ten releases are listed between the February 2026 open-sourcing and v0.9.1 in August 2026, including v0.6.0's remote setup hardening, v0.7.0's SkillsHub integration and IMA knowledge base tools, and v0.5.0's agent teams. A project that shipped that cadence and then paused is a different risk profile from one that was always slow. The code is recent; the commitment is not.
There is a second limitation worth stating plainly. The README lists channel support broadly, but breadth of channel claims and depth of channel documentation are different things. WeChat in particular has historically required unofficial bridges, and the README does not explain what ClawBot is or how stable that path is. Anyone whose use case depends on a specific channel should confirm the integration is documented in the configuration manual before assuming it works.
How CountBot differs from OpenClaw, which it builds on
The README positions CountBot relative to OpenClaw directly, and the comparison is the honest way to place it. OpenClaw is credited with validating local execution and autonomous agents. CountBot takes that direction and adds a Chinese-language orientation, a channel matrix weighted toward domestic IM platforms, a layered configuration model spanning session, role and team, and governance features such as path restrictions, audit logs, timeouts and remote authentication boundaries.
If your agent needs to live in Feishu, DingTalk, Weibo or enterprise WeChat, and you want to run it on your own machine, OpenClaw's ecosystem is oriented elsewhere and CountBot's is oriented here. If your needs are English-language, cloud-hosted, and centred on Slack or Discord, the extra surface CountBot carries (multi-level config, agent teams, channel adapters) is weight you would be paying for without using.
A second reference point is the external coding tools CountBot wraps. Claude Code, Codex and OpenCode already exist as standalone agents with their own interfaces. CountBot's contribution is not replacing them but binding them into a runtime where they can be called as tools or exposed as IM-facing agents. That is an integration play, and its value depends entirely on whether you want those tools reachable from chat rather than from a terminal.
Licence, upgrade cost, and what a fork actually inherits
CountBot is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are preserved. This is not legal advice; read the LICENSE file in the repository for the operative terms.
The practical consequence of MIT plus a paused maintainer is that forking is the expected path. The repository layout supports it: a Python application with a start_app.py launcher, an ASGI app at backend.app:app, a frontend with build artefacts that v0.9.0 notes were regenerated, and modularised MCP and Wiki panels. A fork inherits the channel adapters, the tool registry, the agent team modes and the memory pipeline as they stood at v0.9.1.
Upgrade cost is the mirror image. Because the author has stopped updating, there is no upstream to pull from and no migration path to plan. Your cost is whatever it takes to keep the Python dependency set in requirements.txt current, plus the work of tracking changes in the IM platforms CountBot integrates with. WeChat, Feishu, DingTalk and QQ all change their APIs; a frozen adapter will eventually stop working, and the README offers no statement about which integrations are most fragile.
The Skills ecosystem is a related question. The repository topics include agent-skills and the README claims compatibility with the OpenClaw Skills ecosystem, with v0.7.0 adding find-skills and Tencent Cloud SkillsHub integration for searching, installing, enabling, disabling and deleting skills through conversation. Whether that compatibility survives upstream changes in either ecosystem, with no active maintainer on the CountBot side, is unverified.
Editorial conclusion
CountBot suits developers who want to study or fork a Chinese-first agent runtime: the MIT licence, the start_app.py entry point and the uvicorn command for backend.app:app give you something concrete to run and read. It does not suit teams that need an actively maintained dependency, because the README states the author will not keep updating it. Verify three things before committing: that your Python version satisfies the 3.8+ badge, that the channel you care about is actually documented in the configuration manual rather than only named in the README, and that the MCP client module (off by default since v0.9.0) is something you want to turn on yourself.
Community notes