CountBot
面向中文用户的开源 AI Agent 框架与运行中枢，支持多模型、多渠道、多工具协同
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
面向中文用户的开源 AI Agent 框架与运行中枢，支持多模型、多渠道、多工具协同
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：你是一名产品经理，需要同时处理飞书消息、微信客户咨询，还要用 AI 帮你分析竞品数据、生成周报草稿。通常你需要在多个 App 之间来回切换，让 ChatGPT 写文案、再让 Claude 写代码、还要手动复制粘贴结果——光是协调这些工具就耗费了大量精力。
CountBot 试图解决这个问题。它是一个面向中文用户的开源 AI Agent 框架与运行中枢，核心理念是把大模型、IM 渠道、工作流和外部工具统一到一个本地运行平台中。简单说：你在一个对话框里，通过自然语言驱动所有这些能力协同工作。
CountBot 的开发团队（countbot-ai）同时活跃在 OpenClaw 生态中。OpenClaw 是一个主打本地执行和自主 Agent 的框架，已经在将 Claude Code、Codex、OpenCode 等外部编程工具接入 Agent 运行时方面验证了可行性路径。CountBot 在此基础上，重点补足了中文场景适配、轻量化部署、易用性扩展和安全管控等国内用户普遍关心的能力缺口。
项目从 2026 年 2 月 21 日正式开源，至今已迭代至 v0.9.0（2026年5月），保持着较高的发布频率。从版本日志可以看出，团队在多渠道稳定性、前端交互体验、上下文 token 优化、Agent Team 协作等方面持续投入。GitHub 页面显示该项目已获得约 723 颗 star、89 个 forks，在开源 AI Agent 框架中属于活跃项目。
从代码结构来看，CountBot 采用经典的前后端分离架构：
后端（backend/） 是整个系统的核心，运行在 Python 3.8+ 之上，基于 FastAPI + Uvicorn 构建异步 Web 服务。主要模块包括：
前端（frontend/） 基于 Vue 3 + TypeScript + Vite 构建，提供 Web UI 界面。Vue3 的响应式数据绑定和组件化架构为多面板（聊天、技能、配置、工具）界面提供了良好基础。Vite 作为构建工具确保了开发阶段的热重载体验。
前后端通过 WebSocket（backend/ws/） 维持实时通信，用于会话状态广播和 MCP 连接状态同步。数据库层使用 SQLAlchemy + aiosqlite，支持异步操作。
CountBot 最有特色的功能之一是 Agent Team（多智能体协作），支持三种编排模式：
Pipeline（流水线）：任务按固定顺序依次经过多个 Agent 处理，每个 Agent 输出作为下一个 Agent 的输入，适合数据清洗→分析→报告这类有明确先后顺序的工作流。
Graph（图结构）：任务根据 Agent 的输出结果动态路由到不同的下游 Agent，支持条件分支和并行分发，适合需要根据上下文决定下一步动作的复杂场景。
Council（委员会）：多个 Agent 同时处理同一任务，各自输出结论后通过投票或加权汇总得出最终结果，适合需要多角度评估的决策场景。
这三种模式对应了 backend/modules/agent/team_commands.py 中的实现，与传统单 Agent 相比，Team 模式在处理复杂任务时分而治之的能力更强，但也带来了更高的 token 消耗和更复杂的调试成本。
对于国内用户来说，CountBot 的渠道矩阵是一个重要卖点。项目明确支持微信 ClawBot、微博、Telegram、飞书、钉钉、企业微信、QQ、小智 AI 等入口，这意味着用户可以将 AI 能力直接嵌入已有的工作沟通环境中，而不需要改变原有的工作习惯。
从代码实现来看，backend/modules/channels/ 中每个渠道都有独立的处理文件（dingtalk.py、feishu.py、wechat.py、wecom.py、qq.py、telegram.py、weibo.py、xiaozhi.py），通过统一的 base.py 和 manager.py 进行抽象管理。这种设计使得新增渠道接入时不需要修改核心逻辑，符合开闭原则。
不过需要注意的是，部分渠道接入（如微信）需要特定的官方 API 权限，申请流程可能存在门槛。
v0.6.0 引入的外部编程工具接入是 CountBot 的另一个亮点。通过 backend/modules/tools/external_coding_agent.py，项目支持将 Claude Code、Codex、OpenCode 等外部行业工具作为工具提供方接入 Agent 运行时。这意味着 Agent 在执行任务时，可以召唤这些专业编程工具来完成任务——比如让 Claude Code 帮忙写一段代码，让 Agent 在更高的抽象层做协调。
这种工具作为工具（Tool-as-Tool）的设计思路，与传统直接调用 LLM API 的方式相比，通过引入专用工具处理专用任务，理论上能获得更好的执行质量。
从部署角度来看，CountBot 目前没有提供 Dockerfile 或 docker-compose.yml，因此不支持容器化一键部署。项目提供三个启动脚本：start_app.py（生产模式，带浏览器自动打开）、start_dev.py（开发模式，支持热重载）和 start_desktop.py（桌面客户端模式，基于 pywebview）。
标准安装流程是：
git clone https://github.com/countbot-ai/CountBot.git
cd CountBot
pip install -r requirements.txt
python start_app.py
首次启动后，系统会通过远程首次初始化安全入口（/setup/<random>）引导用户完成基础配置，包括选择 LLM 提供商、填写 API Key、配置渠道凭证等。这个入口有 TTL 控制（REMOTE_SETUP_SECRET_TTL_MINUTES），超时自动失效。
依赖中值得注意的是可选模块的处理策略：MCP 客户端（mcp>=1.0.0）、中文分词（jieba）、增强网页抓取（scrapling）均为可选依赖，不安装不影响基础运行，系统会自动回退到基础方案。这种渐进增强的依赖管理策略值得肯定，避免了强制引入大体积依赖的问题。
硬件需求方面，作为纯 Python 后端 + Vue3 前端项目，CountBot 不需要 GPU，CPU 足够运行。内存约 2GB、磁盘约 1GB 的要求对于现代服务器或个人电脑来说完全在轻松承载的范围内。
尽管功能丰富，CountBot 仍有一些需要注意的局限：
没有容器化部署：对于希望快速在服务器上部署的用户来说，需要手动安装 Python 环境和配置依赖，不如 Docker 一键启动方便。
token 消耗较高：Agent Team 模式中，多 Agent 协作和上下文维护会带来较高的 token 消耗。从 v0.8.0 的更新日志来看，团队已经意识到这个问题并进行了优化（如摘要缓存、溢出历史总结），但对于预算敏感的用户仍需关注 API 调用成本。
部分渠道依赖官方 API：微信、企业微信等渠道的接入需要官方 API 权限，不是纯开源方案能直接覆盖的，可能存在申请门槛。
社区生态仍在建设中：作为一个 2026 年初才开源的项目，CountBot 的第三方 Skills（技能扩展）生态、插件体系还不像 LangChain、AutoGen 等成熟框架那样丰富。
从更大的视角来看，CountBot 的出现映射了当前 AI 应用落地的一个趋势：从追求模型能力极限，转向追求实际可部署、可维护、可治理的系统集成能力。
对比同类开源框架：LangChain 生态最成熟但学习曲线陡峭；AutoGen 侧重多 Agent 协作但部署复杂；Dify 提供了可视化编排但偏向低代码；CountBot 则在本地可控、多渠道接入、中文友好这几个维度找到了自己的差异化定位。
对于有一定技术基础、希望在私有环境中构建 AI 助手或自动化流程的中文用户来说，CountBot 是一个值得尝试的选项。它不是最强大的，也不是最简单的，但它在功能完整和上手门槛之间找到了一个还算舒适的平衡点。项目保持活跃迭代，GitHub star 增长趋势稳健，团队还维护着配套的文档站点（654321.ai）和多个 IM 渠道接入示例，值得持续关注。