DeskcommCRM
天赋如同自然花木，要用学习来修剪。——培根
DeskcommCRM：让 WhatsApp 销售团队拥有一套由 AI 驱动的本地 CRM
项目地址：https://github.com/melgarafael/DeskcommCRM
销售从来不只是把一条消息发出去。
真正的销售工作，往往发生在消息之后：客户是否得到及时回复，线索是否被正确分配，跟进是否在合适的时间发生，成交机会是否在沉默中流失，团队是否知道 AI 做过什么、人又接手了什么。
DeskcommCRM 是一套开源、自托管的 AI 销售操作系统。它将 CRM、WhatsApp、AI Agent、自动化、团队治理、知识库与销售分析放进同一个工作空间中，让企业能够在自己的服务器上运行一套面向聊天销售的系统。
它的核心方向很鲜明：AI Agent 可以在 WhatsApp 中接待客户、完成线索资格判断、参与销售流程，而团队仍然能够查看过程、配置规则、管理权限、审查交接与掌握数据。
这不是把一个聊天机器人嵌进 CRM，而是尝试让 CRM 本身成为人类销售人员与 AI Agent 共同工作的操作台。
从一张销售桌面开始
Deskcomm 这个名字由 Desk 与 comm 组合而来，表达的是一种很直观的想象：把商业沟通与销售运营放在同一张桌面上。
在这张桌面上，团队可以处理 WhatsApp 对话，查看客户状态，管理销售漏斗，配置 AI Agent，设置跟进规则，审查审计记录，并把不同渠道的线索带入统一的 CRM 流程。
项目最初面向电商 CRM 场景，随后扩展到诊所、房地产、信息产品、代理机构、零售与服务提供商等需要通过聊天完成销售的业务。
这种扩展并不依赖于为每一种行业重新搭建一套系统，而是通过可配置的 Pipeline 词汇适配不同业务。
在某个销售流程中，Lead 可以被称为客户。
在诊所场景中，Lead 可以被称为患者。
在其他业务中，Lead 也可以成为买家。
同样地，成交状态也可以被定义为已付款、已预约或已完成。
DeskcommCRM 的核心保持一致，但业务语言可以根据销售流程改变。
AI Agent 不只是回答消息
DeskcommCRM 中的 AI Agent 并不只是自动回复工具。
它可以在 CRM 内参与接待、资格判断、销售推进、情绪分析、意图路由、知识检索与人工交接等流程。
系统提供按租户隔离的 RAG 知识能力，Agent 可以使用 Skills 执行任务，也可以利用组织记忆参与后续服务。
当 AI 接待结束后，交接给人工的过程可以被审计。团队可以知道对话由谁接手、何时发生转移，以及 AI 在其中参与了哪些环节。
这种设计让 AI Agent 不再是一个独立于 CRM 之外的插件，而是销售运营中的一个参与者。
它能够进入对话，理解组织知识，执行预设技能，识别客户意图，并在需要时把会话交给人类团队成员。
不让机会在沉默中消失
销售场景中，最危险的状态往往不是明确拒绝，而是对话逐渐冷却。
客户没有回复，销售人员没有继续跟进，线索仍然停留在漏斗中，但已经没人知道它是否还有机会。
DeskcommCRM 将这一问题放进了系统工作流中。
它提供 Follow-up 能力，用于重新唤起已经冷却的对话。跟进时间可以根据情况调整，也可以根据 Pipeline 阶段与具体场景设置触发条件。
系统还提供 Radar，用于展示仍然开放、但可能因为迟迟没有回复而走向流失的会话。
这让销售团队不必只盯着正在发生的消息，也能够发现那些正在安静离开的机会。
消息沉默并不意味着任务完成。
没有回应的客户，也不应自动从团队视野中消失。
两种 WhatsApp 接入方式
DeskcommCRM 支持两种 WhatsApp 接入路径。
第一种是通过 QR Code 连接 WAHA，支持多号码接入，并提供节流、随机抖动与时间窗口等反封禁机制。
第二种是通过 Meta Cloud API 接入官方渠道，并支持经过批准的模板。
这两种方式服务于不同的使用路径。
QR Code 方式让业务可以更快地完成连接。
官方渠道则为规模化接入提供另一种选择。
无论采用哪一种方式，连接状态、健康检查、重连能力与模板管理都被放在系统的渠道管理范围内。
WhatsApp 在这里不再只是一个单独的通信入口，而是 CRM 中可以被分配、跟踪、审查、自动化和分析的销售渠道。
人与 AI 并肩处理客户对话
DeskcommCRM 的 Inbox 是团队处理 WhatsApp 会话的工作区域。
在这里，人工与 AI 可以并肩参与客户沟通。
团队还可以使用快速回复、查看客户信息、管理对话状态，并根据需要把会话分配或转移给其他成员。
系统提供服务治理能力，包括服务端 RBAC、经过审计的分配与转移、轮转队列、按意图自动路由，以及按角色控制可见范围。
AI 也可以成为一级分配对象。
这意味着，AI 不只是一个被动调用的功能，而可以被纳入服务分配与运营治理之中。
谁能够看到会话。
谁可以处理客户。
谁可以转移任务。
谁有权配置 Agent。
谁能够查看数据。
这些边界都属于销售系统的一部分。
从对话走进 CRM，从 CRM 回到对话
DeskcommCRM 并不把对话与客户管理拆开。
在 CRM 层，系统提供 Kanban、联系人、Pipeline、标签与客户视图等能力。销售团队可以查看每个业务机会处于哪个阶段，也可以管理漏斗步骤、行业术语和丢失原因。
对话不只是聊天记录，而可以成为销售机会的实时入口。
客户信息不只是静态表格，而可以连接到 Pipeline、服务记录、AI 交互和后续自动化。
这使得销售人员不需要在多个工具间来回切换：一边在聊天应用中回复客户，一边在另一套系统里更新线索，一边再去第三个地方查看跟进任务。
DeskcommCRM 试图将这些动作收拢到一个连续的工作流中。
AI 也需要被持续训练和审视
AI Agent 能够接待客户，并不意味着它的工作不需要被检查。
DeskcommCRM 提供 AI Evolution 页面，用于展示 Agent 是否在改善、在哪些地方出现问题，以及还缺少哪些需要学习的内容。
已解决的对话可以转化为新的知识。
这让销售经验不必只停留在某个员工的个人习惯中，也不必随着一次对话结束而消失。
当团队发现 Agent 在某类问题上答得不好，可以补充知识。
当某种沟通方式被验证有效，可以沉淀为技能或案例。
当某段对话反映出流程缺口，也可以成为系统改进的输入。
AI 的成长不再只是依赖更换模型，而是可以与组织自身的经验积累连接起来。
自动化不该被困在队列里
DeskcommCRM 支持 Webhooks 与自动化能力。
每个租户都可以创建公开的数据接收地址，用于接收来自落地页、自建表单以及自动化工具的线索数据。
在界面中，Webhooks 面向拥有 manager 或 admin 角色的成员开放。团队可以创建接收来源、复制接收地址或表单，并对传入数据进行管理。
事件进入系统后，会先成为 event_log 中的一条记录。
数据库触发器不会直接执行 HTTP 调用。
负责处理事件的是定时调用的事件队列清理路由。
这种设计让自动化任务不会因为触发器直接调用外部网络而失去控制，也让事件拥有更清晰的处理路径。
系统还可以通过 QUANDO、SE、ENTÃO 规则处理自动化流程，并向外部系统发送触发结果。
线索可以从外部进入 CRM。
事件可以在队列中等待处理。
规则可以根据条件触发动作。
销售自动化不再只是几段散落的接口调用，而是被放进可管理的业务流程中。
自托管，让数据与基础设施留在自己手里
DeskcommCRM 强调真正的自托管。
应用、WhatsApp 服务和 Workers 可以运行在自己的 VPS 上。项目提供安装工具包，用于完成应用、WhatsApp 与数据库的部署流程。
安装过程中，系统会询问与业务有关的信息，例如域名、密钥和管理员密码，并对输入进行校验。
技术密钥可以自动生成。
Postgres 扩展与完整 Schema 可以被创建和应用。
首个管理员账号可以被创建。
整套服务可以通过自动 HTTPS 启动，并在结束时进行健康检查。
安装流程还会配置自动化所需的 Cron，以及负责应用内更新按钮的更新 Agent。
安装脚本具备幂等性，可以再次运行而不重复创建 Cron、不重复创建用户，并能够从此前中断的位置继续。
对于希望通过配置文件进行非交互部署的场景，也可以准备环境文件后使用非交互模式运行安装。
更新不应该是一场手工冒险
自托管系统最常见的焦虑之一，是更新。
新版本出现后，用户往往需要通过 SSH 登录服务器，手动拉取代码，担心数据库变更，担心升级失败，也担心服务在重启后无法恢复。
DeskcommCRM 为更新提供了界面与终端两条路径。
当存在新版本时，服务器拥有者可以在侧边栏看到新版本提示，并进入更新页面。系统会展示变更内容，自动备份数据库，并依次展示备份、代码、数据库与上线过程。
如果新版本启动出现问题，更新 Agent 会回退到此前的镜像，并将回退状态记录到环境配置中，避免后续重启再次加载异常版本。
终端更新方式则可以使用：
1 | cd /caminho/do/DeskcommCRM |
该流程会先检查是否存在新版本，再进行数据库备份，获取新代码，重新应用 Schema，拉取新应用镜像，并在结束时执行健康检查。
更新目标是已发布版本，而不是直接指向 main 分支顶部的未标记提交。
系统还提供备份、恢复、密码重置、多因素认证重置和健康检查脚本：
| 脚本 | 作用 |
|---|---|
install.sh |
安装全部服务，可重复运行 |
update.sh |
更新到新版本，并自动备份 |
backup.sh |
备份数据库与 WhatsApp 会话 |
restore.sh |
恢复备份 |
reset-password.sh |
重置用户密码 |
reset-mfa.sh |
移除遗失设备用户的 MFA |
healthcheck.sh |
一次性诊断全部服务 |
销售系统里的权限，不应该只停留在前端按钮
DeskcommCRM 提供服务端 RBAC。
角色与权限不是只靠界面隐藏按钮实现，而是进入 API 与数据访问边界中。
系统还采用多租户结构，并在所有具备租户意识的数据表中使用 RLS。
项目将租户隔离测试纳入 CI 关卡：测试会创建两个组织，并通过与生产环境相同的 auth.uid() 和 fn_user_org_ids() 路径模拟 JWT Claims，以验证数据隔离是否真实有效。
对于客户对话、订单、联系人和其他个人信息，系统强调 LGPD 设计。相关能力包括导出、通过 Workers 执行数据处理、级联匿名化与经过审计的同意记录。
审计日志采用追加式记录，并设置五年保留期。
这让销售系统在处理客户信息时，不只是拥有功能，也拥有围绕组织边界、访问权限、数据隔离与操作记录的治理结构。
选择 AI，而不是被某一种模型锁定
DeskcommCRM 支持 OpenRouter、Anthropic 与 OpenAI，并允许在安装时选择提供商，之后再通过界面切换。
更进一步的是，不同系统部分可以选择不同的 AI 提供商。
负责与客户聊天的模型，不必与负责内容索引的模型相同。
这种分层选择让 AI 不再是一个不可拆分的黑盒，而可以根据不同工作环节进行配置。
接待、知识索引、Agent 能力和其他 AI 驱动流程，可以被放在更符合业务需求的模型配置中。
一套面向销售运营的完整界面
DeskcommCRM 将不同业务功能放进清晰的导航结构中。
| 分组 | 主要界面 |
|---|---|
| 服务 | Inbox、Radar、快速回复 |
| CRM | Kanban、联系人、Pipelines |
| AI Agent | Agents、Follow-ups、Routers、Providers、Credentials、Knowledge、Memory、Skills、Cases、Alerts、Prompts |
| 渠道 | Connections、Nuvemshop、Webhooks |
| 分析 | Performance、AI Evolution、Audit Log |
| 组织 | Team、服务分配、Organization、LGPD、API Tokens、Security、Profile、Notifications |
项目还规定，每一个存在的界面都必须能从导航中进入。CI 会拒绝那些存在页面、却只能通过手动输入地址访问的情况。
这种要求看似细小，却反映出一个明确方向：功能不只是代码中的路由，也必须成为用户真正能够找到和使用的产品能力。
从前端到 Workers，一套为销售流程准备的技术结构
DeskcommCRM 使用 Next.js App Router、React、严格 TypeScript、Supabase、WAHA、Meta Cloud API、Vercel AI SDK、Upstash Redis、Sentry 与 Docker 等组件构建。
| 层级 | 技术选择 | 用途 |
|---|---|---|
| 前端 | Next.js 16 App Router、React 19、严格 TypeScript | 在同一仓库中组织 Server Components 与 Route Handlers |
| 样式 | Tailwind 与 shadcn/ui | 提供可定制的界面基础 |
| 数据库 | Supabase Postgres、RLS 与 vector |
支持多租户与 RAG Embedding |
| 认证 | Supabase Auth | 使用 SameSite 严格与 HttpOnly Cookie |
| 实时能力 | Supabase Realtime | 支持数据变更与广播 |
| 存储 | Supabase Storage | 管理私有 WhatsApp 媒体 |
| WAHA Plus 与 Meta Cloud API | 分别支持 QR 接入与官方渠道 | |
| 队列 | event_log 与 Cron Workers |
避免数据库触发器直接执行 HTTP |
| 限流 | Upstash Redis | 使用滑动窗口机制 |
| AI | Vercel AI SDK | 连接多个 AI 提供商 |
| 校验 | Zod | 校验外部输入、环境变量与载荷 |
| 可观测性 | Sentry | 安装时可选择启用的错误遥测 |
| 部署 | Docker VPS | 在自己的基础设施上运行应用、WhatsApp 与 Workers |
项目的目录结构也围绕这些职责展开：
1 | DeskcommCRM/ |
其中，app/ 承担 Next.js 路由与 REST API。
components/ 承担 React 界面组件。
lib/ 包含 Supabase、WhatsApp、渠道、AI、Agent Engine、路由、导航与环境配置相关模块。
workers/ 用于处理 AI、RAG、LGPD、媒体与例行任务等事件。
supabase/ 用于维护 SQL 与自托管场景使用的 Schema 基线。
质量不只看页面能不能打开
DeskcommCRM 将 TypeScript 检查、Lint、单元测试、数据库测试与端到端测试纳入开发与合并流程。
1 | pnpm typecheck |
其中，数据库测试会启动临时 Postgres，并以安装与更新两种方式应用 baseline.sql，用于验证 Schema 在重复应用时仍然成立。
端到端测试使用 Playwright，覆盖前端交互流程。
项目还会验证 Docker 镜像是否能够构建，确保最终自托管用户实际安装的应用、Worker 与 Scheduler 镜像可用。
在可视化质量上，项目维护了证据机制。
部分界面截图属于可再生成的证据，其他截图则被视为历史证据。历史证据记录的是某次交付前的真实状态，一旦覆盖，就可能失去唯一的可追溯记录。
因此，系统会阻止无意覆盖已标记的历史截图，并明确告知拒绝原因。只有通过显式方式，才允许有意识地覆盖这些历史材料。
这让测试和质量保障不只追求“当前是否通过”，也试图保留产品曾经处于什么状态的可视化痕迹。
DeskcommCRM 想解决的，不只是消息回复效率
从表面看，DeskcommCRM 是一套面向 WhatsApp 的开源 CRM。
但它真正尝试解决的，是聊天销售运营中更深层的断裂。
客户消息来了，却没有得到及时处理。
销售人员跟进过多，重要机会被遗漏。
AI 可以回复，却不了解企业知识与业务规则。
团队成员能看到对话，却无法清晰地分配责任。
CRM 有数据，却没有把数据转化为下一步行动。
自动化已经配置，却因为队列或服务问题停在后台。
系统可以部署，却在升级时让用户感到不安。
DeskcommCRM 试图将这些环节连起来。
它让 AI Agent 进入 CRM。
让 WhatsApp 成为可管理的销售渠道。
让知识库、记忆、Skills 与 Follow-up 参与客户运营。
让权限、审计、多租户和数据隔离成为系统基础。
让部署、更新、备份和健康检查进入自托管工作流。
让团队能够在同一张销售桌面上，看见客户、看见流程、看见 AI，也看见每一次行动留下的轨迹。