AI 代理接管 CRM 后还要销售干嘛

最近 GitHub 上一个叫 trycompai/crm 的项目突然冲到 1670 stars，自我介绍只有一句话——“An open-source, agentic-first CRM”。它的思路和 Salesforce、HubSpot 完全不同：不是给销售用的表格，而是给 AI 代理用的工作流。CRM 不再是”客户数据库 + 漏斗视图”，而是一组可被 LLM 自主调用的工具（Tool Calls）。配合 Ollama、vLLM 这类本地推理框架，企业可以完全在内网部署一套”会自己跟单”的后台，这也是它本周冲上 GitHub Trending 的核心原因。对厌倦了 SaaS 续费和数据出域的开发者来说，它刚好踩中了合规 + 降本 + AI 三条主线。

问题一：怎么本地跑起来？

很多开发者看到 README 第一反应是”又是 Next.js + Postgres 一把梭？“没错。trycompai/crm 用 Docker Compose 一键起服务，包含 Postgres、Redis、API Server、前端四个容器。最常见的坑是端口冲突——3000、5432、6379 经常被本地其他项目占用，导致 docker compose up 之后某个容器无限重启。

git clone https://github.com/trycompai/crm.git
cd crm
cp .env.example .env
# 先改端口再起服务
sed -i '' 's/5432/5433/g; s/6379/6380/g; s/3000/3001/g' .env
docker compose up -d
docker compose logs -f api

根因在于官方默认配置假设你的机器是干净的。解法是先改 .env 里的 POSTGRES_PORT、REDIS_PORT、WEB_PORT，再启动。如果用 colima 或 Lima，要记得开文件共享，否则 Postgres 容器会因 volume 挂载失败反复退出。这是所有自部署 SaaS 替代品最容易踩的入门坑。

问题二：AI 代理到底怎么”行动”？

这是 HN 和 Reddit 上争论最多的问题：agent 不就是个聊天框吗，凭什么算 CRM？答案是它把”行动”拆成 Tool Calls。每个 Tool 就是一个 OpenAPI endpoint，比如 create_deal、send_followup_email、score_lead。LLM 根据上下文自行决定调用顺序，而不是人在界面上点按钮。

// app/api/agents/lead-qualifier/route.ts
export async function POST(req: Request) {
  const { leadId } = await req.json();
  const lead = await db.leads.find(leadId);

  const tools = [
    tool("scoreLead", "为线索打分，0-100", scoreLeadSchema, async (args) => {
      return await scoreModel.run(lead, args);
    }),
    tool("enrichCompany", "通过域名补全公司规模、行业、融资信息", enrichSchema, async (args) => {
      return await enrichment.lookup(lead.company);
    }),
    tool("createDeal", "创建销售机会并设置初始阶段", dealSchema, async (args) => {
      return await db.deals.create({ ...args, owner: lead.owner });
    }),
  ];

  return streamAgent({ lead, tools, model: process.env.LLM_MODEL });
}

根因是很多人把 agent 当成 chatbot，但 agentic CRM 的关键是”能落地副作用”。所以写 tool 时一定要 idempotent，并且把每次 tool call 写进审计日志，方便后续回放和调试。这跟传统 SaaS 的”用户点击事件”完全不同，开发者要把每个 tool 视为一个有边界效应的 RPC。

问题三：客户数据怎么保证不出公司？

GDPR、HIPAA、内部合规审计——这是企业用户最关心的问题。trycompai/crm 默认所有业务数据走自托管，但很多人忽略了 LLM 调用那一环。默认配置会调 OpenAI，不改环境变量就等于把客户名单送给第三方，这是合规审计的红线。

正确做法是把 LLM_PROXY_URL 指向企业内部的 Ollama 或 vLLM：

# .env.production
LLM_PROXY_URL=http://internal-llm.company.local:11434
LLM_MODEL=qwen2.5-32b-instruct
EMBEDDING_MODEL=bge-m3
TELEMETRY_DISABLED=true

根因是 README 没有大写提示这一点。社区里已经有 issue 提议把它改成默认 localhost，但目前还得手动改。所有调用 prompt 和返回内容会留在内网，审计日志写入 Postgres 单独的 llm_calls 表，方便合规回溯。这是任何自部署 AI 项目都必须显式声明的配置项。

问题四：能跟现有工具打通吗？

可以，但要通过 MCP（Model Context Protocol）。项目内置了 Slack、GitHub、Gmail、Linear 四个 connector，社区贡献了 Notion、Jira、HubSpot、Stripe 的 adapter。配置非常简单：

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": { "SLACK_TOKEN": "${SLACK_BOT_TOKEN}" }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-linear"],
      "env": { "LINEAR_API_KEY": "${LINEAR_API_KEY}" }
    }
  }
}

现象是很多人装了 connector 但 agent 不调用，根因通常有两个：一是 OAuth scope 没勾全（比如 Slack 只给了 chat:write 没给 users:read，导致 @ 人失败），二是 tool description 写得太模糊，LLM 不知道什么时候该用它。社区经验是 tool description 要写得像产品文档，明确写出”何时用”和”何时不用”，这是 prompt 工程里最容易被低估的一环。

问题五：适合什么规模的公司？

Reddit r/SaaS 上有人问：“我们团队就 5 个销售，值得自部署吗？” 答案取决于复购率和线索量。如果每月新增线索超过 200 条，或者销售需要大量重复性的邮件、提醒、数据录入，agent 的自动化收益才能覆盖学习成本。否则一个 Airtable + Zapier 就够了，没必要扛运维。3-50 人团队、有技术 co-founder、痛恨 SaaS 锁定，是这个项目最精准的目标用户画像。

Sources

• GitHub Trending 2026-08-03
• trycompai/crm 仓库 README 与 Docs
• Hacker News: Show HN: trycompai/crm 讨论帖
• r/ClaudeAI: Agentic CRM self-hosted thread
• r/SaaS: Anyone using open-source CRM? 调研贴
• Model Context Protocol 官方文档