🌟 DeskcommCRM：当销售把 WhatsApp 当主战场，你需要的可能不是一个普通 CRM 🤖

先说一个几乎每家在巴西、在拉美、在所有“用聊天卖东西”的市场里做生意的公司都经历过的场景。

一位客户在 WhatsApp 上问：“这个套餐还能再便宜点吗？”销售 A 回了。两天后客户又问：“上次说的发票怎么开？”这次接住消息的是销售 B，他翻遍聊天记录才发现对方已经报价过。再后来客户消失了——不是因为贵，是因为没人记得他聊到哪一步。

而与此同时，公司的 CRM 里躺着三千条“线索”，状态栏统一写着：待跟进。

问题不在于团队不努力，而在于记录系统（CRM）和实际发生交易的系统（聊天工具）是两个世界。销售不愿意切窗口填表单，于是数据就永远是滞后的、残缺的。

💡 如果销售的主战场是聊天，那 CRM 就该长在聊天里

melgarafael/DeskcommCRM 的自我定位非常直接：Open-source AI sales OS——开源 AI 销售操作系统。它不是“又一个 CRM 加上一个聊天插件”，而是把 CRM + 原生 AI Agent + WhatsApp（WAHA） 放在同一个自托管系统里。

项目的描述里点名了几个对标的商业产品：Kommo、Octadesk、Intercom。这三者的共同点是都围绕“对话式销售”构建，也都不便宜，且数据托管在别人的服务器上。DeskcommCRM 给出的答案很清晰：

  • 🧩 Native AI agents：AI 不是外挂插件，而是销售流程里的原生角色
  • 💬 WhatsApp via WAHA：通过 WAHA（WhatsApp HTTP API）接入最主流的销售沟通渠道
  • 🔌 MCP-ready：可接入 Model Context Protocol 生态，让 AI 能调用外部工具与数据
  • 🏢 Multi-tenant：天然面向多团队 / 多客户的可隔离架构
  • 🇧🇷 LGPD：从设计上就把巴西数据保护法的合规需求摆上台面

🛠️ 拆开看：这套“销售 OS”由哪几块拼图组成

从项目给出的信息出发，可以把这套系统理解成四个协作层。共享一个自托管环境，数据不出你自己的边界：


# 概念示意：自托管“对话式销售系统”的典型分层
# 仅用于帮助理解信息架构，非项目官方配置
layers:
  conversation:  WAHA          # WhatsApp 的收发通道
  orchestration: AI Agents     # 接待、初筛、跟进、交接
  record:        CRM Core      # 客户、商机、阶段、历史
  extension:     MCP           # 把工具和数据能力暴露给模型

📱 第一层：为什么是 WAHA

WAHA 是一个把 WhatsApp 封装成 HTTP API 的开源网关。把这一层做成独立服务，好处很实在：业务逻辑不需要去理解底层协议的细节，收发的消息对系统来说就是一个个事件。自托管的销售系统配上自托管的通道，整条链路的可控性就回到了自己手里。

🤖 第二层：AI Agent 不是“自动回复”，是销售流程中的一个岗位

自动回复和 AI 销售代理之间隔着一整个断层。前者只会匹配关键词，后者需要理解上下文、记住客户说过什么、判断该继续推进还是该把人叫进来。

DeskcommCRM 把 Agent 定义为原生组件，意味着它天然能看到 CRM 里的客户阶段和历史消息。一个合理的分工是这样：Agent 负责消息到达后的第一分钟——接待、问需求、初步筛掉明显不匹配的线索；人类销售负责判断、谈判和成交。当 Agent 判断自己接不住时，转人工交接。


// 伪代码示意：Agent 的决策逻辑，核心不是话术而是“何时交给人”
async function handleIncoming(ctx: TenantContext, msg: InboundMessage) {
  const lead = await upsertLead(ctx, msg.from);

  if (shouldEscalateToHuman(lead)) {
    await assignToHumanAgent(ctx, lead, { reason: 'high_intent' });
    return;
  }

  const reply = await agent.compose(ctx, { lead, history: lead.messages });
  await whatsapp.send(lead.phone, reply);
}

🏢 第三层：多租户 + LGPD，不是两个功能，是一条底线

多租户和 LGPD 放在一起看，其实是同一个问题的两面：数据隔离。

多租户意味着系统从第一天起就必须回答“这条数据属于谁”，而不是事后加一个 WHERE tenant_id = ? 补丁。LGPD 则要求你能说清楚数据存放在哪、为什么存、什么时候删。自托管在这件事上天然有优势，因为存储的责任边界在你的基础设施之内。


// 伪代码示意：多租户的核心约束——每一次读写都带着租户上下文
type TenantContext = { tenantId: string };

async function listOpportunities(ctx: TenantContext) {
  return db.opportunities.findMany({
    where: { tenantId: ctx.tenantId },  // 不是可选项，是强制项
  });
}

🔌 第四层：MCP-ready 意味着什么

MCP（Model Context Protocol）解决的是“模型怎么安全地调用你的系统和工具”。对于一个 CRM 来说，这一点尤其关键——因为销售数据里既有客户电话，也有合同金额，你不能把这些东西一股脑塞进某个不可控的外部服务。

MCP-ready 的意义在于：DeskcommCRM 可以把自己作为能力提供方接入 MCP 生态，让 AI 在受控范围内查询客户、更新阶段、触发跟进，而不必把整张数据库表暴露出去。


{
  "mcpServers": {
    "deskcomm": {
      "type": "http",
      "url": "https://your-crm.example.com/mcp"
    }
  }
}

🎯 谁适合自托管这套东西

“开源替代”这四个字听起来很美，但它也意味着运维责任转移。所以判断标准不是“功能多不多”，而是“你愿不愿意为数据主权付出运维成本”。

  • 适合：销售完全发生在聊天里、客户数据敏感度较高、团队里有开发或愿意维护 Docker / 服务器的人
  • 适合：需要多个团队 / 品牌 / 门店共用一套系统且数据互相隔离
  • 需谨慎：期望开箱即用、零运维、不想碰部署的纯业务团队
一句话总结选型逻辑：如果你已经在为 SaaS 的按席位计费和数据出境问题头疼，那自托管方案的性价比会突然变得非常明显。

⚡ 上手建议：别一上来就让 AI 接管一切

从项目的设计取向看，一条相对稳妥的推进路径是：

  1. 先跑通通道——把 WhatsApp（WAHA）接通，确认消息能进能出，这一步是地基
  2. 再做记录——让每一条对话都落到 CRM 的客户与商机里，先让人愿意用
  3. 然后开 Agent——从低风险场景开始，比如首次接待、常见问题、消息分类
  4. 最后接 MCP——当你有明确的工具需要 AI 调用时，再打开扩展层

尤其是第 3 步，务必给 Agent 设好“交给人”的触发条件。销售场景里，AI 最危险的不是说错话，而是在该叫人时没说。

🌟 为什么这个项目值得放进你的观察列表

DeskcommCRM 出现在 Trending 上，反映的其实是行业里正在发生的一次迁移：CRM 的中心正在从“录入表单”变成“对话现场”，而 AI 从“事后分析工具”变成“流程内的执行者”。

它把几个当下最有张力的关键词——开源、自托管、AI Agent、WhatsApp、MCP、多租户、LGPD——放进同一个产品里，并且明确瞄准了被商业 SaaS 覆盖得不够好的市场。对于任何一家“靠聊天卖东西”的公司来说，这至少是一份值得认真读一遍的参考实现。

仓库地址：github.com/melgarafael/DeskcommCRM。建议先看 README 和部署方式，再决定要不要把它跑在你自己的一台机器上试试看 🚀