发布于 Tue Mar 10 2026 08:00:00 GMT+0800 (中国标准时间)
深度评测Chatwoot
Chatwoot 深度评测：6 个月生产使用后的真话
我们在生产环境跑了 6 个月 Chatwoot 4.x，处理 4 万+ 工单，从 Inbox 到 Captain 到 API 完整复盘。
选 Chatwoot 之前我们试过的#
- Intercom：好用，月费突破 $2000 后劝退
- Crisp：UX 漂亮但 AI 能力弱，缺 API 深度
- Zendesk：太重，工单流程对中小团队过度设计
- Help Scout：邮件无敌但实时聊天与移动端弱
- Papercups：Elixir 生态运维成本高
最后选 Chatwoot，主要原因：MIT 协议、Docker 一键、社区活跃、Captain 模块够用。
6 个月数据#
| 指标 | 数值 |
|---|---|
| 累计工单 | 41,283 |
| 月活坐席 | 12 |
| 主用渠道 | Web Widget、邮件、WhatsApp、Discord |
| 平均工单时长 | 2 分 14 秒（AI 介入后） |
| 宕机时间 | 累计 47 分钟（一次升级失败 + 三次 OOM） |
Inbox 系统#
Chatwoot 把所有渠道抽象成 Inbox，每个 Inbox 都可以：
- 配置自动分配规则（轮询 / 按技能 / 按客户标签）
- 启用 Captain 或 Agent Bot（兜底 AI）
- 设置营业时间和离线消息
- 绑定团队和 SLA
坑点：Inbox 删除不可逆，会丢失历史会话的关联。生产环境务必先备份。
Captain 模块实测#
Captain 是 Chatwoot 2024 推出的内置 AI 助手。我们用它当二线兜底。
优点#
- 配置简单，5 分钟上线
- 知识库支持 URL 抓取 + Markdown 上传 + 自动 sync
- Workflow 模式能接住「按订单号查询」这种简单 intent
不足#
- Workflow 节点比 Dify 少很多（无代码节点、无并发）
- 知识库分块策略不能自定义
- 单一 LLM 配置（不能为不同 Inbox 配不同模型）
我们的取舍#
Captain 用于「公开 FAQ」类轻量场景，复杂业务全部转 Dify 做。两者通过 Agent Bot 切换。
API 与 Webhook#
Chatwoot 的 API 是它最被低估的优势。我们做了这些自动化：
| 场景 | 实现 |
|---|---|
| 工单→Notion | Webhook → n8n → Notion 数据库 |
| 高优先级工单→飞书 | Webhook → 飞书 Bot |
| 月度 CSAT 报告 | Cron → API 拉数据 → Metabase |
| 敏感词识别→升级 | Pre-submit Hook → 关键词词典 |
部署经验#
推荐配置#
| 规模 | 配置 |
|---|---|
| < 5 坐席，< 1000 工单/月 | 2C4G VPS |
| 10 坐席，5000 工单/月 | 4C8G VPS |
| 30 坐席，30000 工单/月 | 两台 8C16G + 外置 Postgres |
三次踩坑#
- OOM：Sidekiq 在多渠道高并发时容易爆。修复：把 Sidekiq 进程拆出来单独跑、加 Redis 内存限制
- 邮件循环：Reply-to 配错时邮件会无限往返。修复：邮件 Inbox 一定要设独立的发件地址
- Postgres 慢查询：会话表索引不全。修复：手动给 conversations(account_id, status) 加复合索引
适合 / 不适合#
| 适合 | 不适合 |
|---|---|
| 中小团队替换 Intercom | 大企业有严苛工单流程 |
| 多渠道客服 | 纯邮件场景（FreeScout 更轻） |
| 想保留数据自主 | 完全无运维资源 |
| 愿意做二次开发 | 追求开箱即用 SaaS |
综合评分#
| 维度 | 分（10 满） |
|---|---|
| 功能完整 | 8 |
| 部署难度 | 6 |
| 社区活跃度 | 9 |
| AI 能力 | 6 |
| 二次开发友好 | 8 |
| 综合 | 7.4 |
最优组合：Chatwoot 做入口 + Dify 做大脑 + n8n 做编排——这就是我们 6 个月后给所有客户的默认推荐。