wangliang
39986f10f2
- docker compose 部署：app / db / redis / tls(nginx) / bridge-tools，宿主端口错开避免与本机服务冲突 - bridge-tools 内联进仓库（compose build 路径改为 ./bridge-tools），仓库自包含可部署 - 部署说明 README、crm-new 对照与 bridge-tools 方案文档、备份与隧道脚本 - .gitignore 排除 .env、config.toml、uploads/、tls 私钥/证书、backups/、logs/
134 lines
9.6 KiB
Markdown
134 lines
9.6 KiB
Markdown
# crm-new vs 本实例（yehwang-ai/libredesk）差距与补充方案
|
||
|
||
> 生成时间：2026-10-28 对比基准：crm-new `docker-compose.yml` + 运行中的 `crmnew-*` 容器 + `crmnew-postgres/libredesk` 库实际数据
|
||
> 本实例：`/home/dev/code/yehwang-ai/libredesk`（LibreDesk v2.9.1 + PG18 + Redis + nginx TLS）
|
||
|
||
## 0. 一句话结论
|
||
|
||
本实例目前只是「**能登录的 LibreDesk 空壳**」（0 渠道、0 AI 助手、0 工具、0 知识库、0 自动化），
|
||
crm-new 是一条**完整跑通的 AI 客服业务链**（三渠道 + bridge 工具 + Twenty CRM + 公网入口 + 一大套配置脚本与上线文档）。
|
||
差的不是「几个开关」，而是**整条链的组件、配置、凭据和运维资产**。
|
||
|
||
## 1. 能力矩阵（均为实测，不是看代码猜的）
|
||
|
||
| 能力 | crm-new | 本实例 | 缺口 |
|
||
| --- | --- | --- | --- |
|
||
| 容器编排 | LibreDesk + Twenty(server/worker) + bridge + imap-proxy + public-gateway + cloudflared + PG + Redis（9 个） | LibreDesk + PG + Redis + nginx TLS（4 个） | Twenty、bridge、imap-proxy、public-gateway、cloudflared |
|
||
| 渠道 inbox | **3 个**：Website(livechat) / Email 163 / WhatsApp | **0** | 全部 |
|
||
| 邮件通知 | `notification.email.*`：smtp.163.com:465 TLS，已启用 | 无 | 全部 |
|
||
| Live chat | inbox + widget + 身份锚定方案（SITE_JWT / IDENTITY_*，bridge 侧） | 无 | 全部 |
|
||
| WhatsApp | inbox + 6 个模板 + Meta Cloud API 凭据 + 回调 | 无 | 全部 |
|
||
| AI provider | 2 个已配：completion=`qwen-plus-latest`(DashScope, openai 兼容)、embedding=`text-embedding-v4` | 2 行**空壳**默认记录，api_key 为空 | 填 key/模型/默认项 |
|
||
| AI assistant | 1 个（B2B 助手；max_turns=8；handoff 开；guardrails/expectation/tone） | 0 | 全部 |
|
||
| AI tools | **11 个** HTTP 工具：search_products / search_orders / search_inventory / search_kb / search_email_history / collect_info / send_verification_code / verify_email_code / handoff_to_human / create_opportunity / get_customer_info | 0 | 全部 |
|
||
| 知识库 | 帮助中心 1 个（`yehwang-help`）+ **108 篇已发布文章**；bridge 侧 pgvector RAG（快照 594 chunks） | 0 | 全部 |
|
||
| 自动化规则 | 3 条：AI 分配、邮件→Wholesale、WhatsApp→Wholesale | 0 | 全部 |
|
||
| 团队/坐席 | 1 个 team（Wholesale Support，时区 Asia/Shanghai）+ 3 agent + 2 角色；库内 27 用户（含 contact/visitor 历史） | 1 个用户（System）+ 2 个默认角色 | 团队、坐席、角色细分 |
|
||
| Webhook | 1 条：Bridge AI → `http://bridge:4100/libredesk/webhook` | 0 | 全部 |
|
||
| 公网入口 | public-gateway（只放 WhatsApp webhook + 帮助中心）+ cloudflared quick tunnel；root_url 指向临时 trycloudflare 域名（隧道重启即变，不可当长期入口） | nginx 自签 TLS（仅内网 9443）；`root_url=http://localhost:9000` | 域名、证书、白名单反代 |
|
||
| 数据库 | PG 3 库（libredesk / twenty / bridge）+ pgvector | 单库 libredesk | 若接 Twenty/bridge 需建库 |
|
||
| 网络 | 额外接入外部网络 `spug-net`，bridge 直连 yehwang RPC（9503/9505/9506/9509） | 独立 bridge 网络 | 网络互联 |
|
||
| 配置脚本 | bootstrap.sh、render-config.js、configure-ai/email、add-email-inbox、add-whatsapp-inbox、register-tools、import-kb-helpcenter、set-public-url、set-wa-webhook、smoke.sh、e2e-*、eval-*、kb-* 等约 25 个 | 无 | 全部 |
|
||
| 文档 | architecture / api-mapping / environments / go-live / runbook / human-routing / libredesk-setup / migration-plan / plan-a / deploy-wangliang | 只有一个 README | 上线、运维、切流文档 |
|
||
| 备份 | runbook 有 pg_dump / Twenty 文件存储 / KB 快照命令 | 只有我这次升级时手工做的两次 dump，**无定时任务** | 定时备份 + 恢复演练 |
|
||
|
||
**基础配置本身就有错**（两边都有，但本实例更明显）：
|
||
|
||
- 本实例 `app.root_url = http://localhost:9000`（邮件/帮助中心链接会指向 localhost）
|
||
- 本实例 `app.timezone = Africa/Cairo`（荷兰业务差 1 小时）
|
||
- crm-new 的 `app.timezone = ""`、`root_url` 是已失效的临时隧道域名
|
||
|
||
## 2. 建议补充方案（分 6 期，按依赖排序）
|
||
|
||
### P0 正确性与安全（约 0.5h，先做）
|
||
|
||
| 事项 | 说明 |
|
||
| --- | --- |
|
||
| root_url 改为 `https://192.168.31.61:9443` | 影响邮件通知、帮助中心、widget 链接 |
|
||
| timezone 改 `Europe/Berlin`（UI）或 `Europe/Amsterdam`（API） | 两者规则等价，见时区分析 |
|
||
| 建个人管理员账号，改掉 System 密码 | 避免共用超级账号 |
|
||
| 备份脚本落地（pg_dump + uploads，保留 7/30 天）+ 恢复演练一次 | 目前没有定时备份 |
|
||
| （可选）`9001` 只监听 `127.0.0.1` | 减少明文暴露面 |
|
||
|
||
验收：设置页不再出现 localhost/Cairo；备份能被 `pg_restore -l` 读出；个人账号可登录。
|
||
|
||
### P1 渠道最小闭环（约 1–2h）
|
||
|
||
1. **Live Chat inbox + widget**（Website 渠道），把这套的 widget 代码嵌到目标站点；
|
||
2. **Email inbox**：先定用哪个邮箱 —— 163 需要 imap-id-proxy（LibreDesk 不发 IMAP ID）；建议换企业邮箱/自建 SMTP 省掉代理；
|
||
3. 配置 `notification.email.*`（OTP/通知邮件走同一 SMTP）；
|
||
4. 建 **Team**（Wholesale Support）+ 分配规则（邮件/WhatsApp 转人工）；
|
||
5. 建 **Help Center**，导入 crm-new 的 108 篇文章（可参考 `import-kb-helpcenter.js`）。
|
||
|
||
验收：widget 能落会话；邮件收发一轮打通；帮助中心可搜索；新会话按规则进人工团队。
|
||
|
||
### P2 AI 能力（约 2–4h）
|
||
|
||
1. 填 AI provider（复用 crm-new 的 DashScope key，或新申请），确认默认 provider；
|
||
2. 配 AI assistant（instructions / guardrails / handoff / languages / max_turns）；
|
||
3. 知识库二选一：
|
||
- **A**：用 LibreDesk 内置 KB/snippets + embedding（新栈自包含，但要重新灌数据）；
|
||
- **B**：沿用 bridge 的 pgvector RAG（数据现成，但依赖 bridge 运行）；
|
||
4. Live Chat 开启 AI 接管，跑 preview/retrieval 验证与转人工。
|
||
|
||
验收：AI 回答能引用知识库；越界时按 guardrails 转人工；有可复跑的检索评测。
|
||
|
||
### P3 业务工具 + CRM（约 0.5–1d，取决于复用方式）
|
||
|
||
三条路线（需拍板）：
|
||
|
||
- **A. 复用 crm-new 的 bridge**：新实例 webhook 指向同一个 `crmnew-bridge:4100`，工具注册表复制一份；改动最小，但两套环境共享 bridge/数据；
|
||
- **B. 新建 bridge 实例**：复制代码 + 独立 `.env`（RPC 地址、DashScope、SMTP、Redis 库分开），隔离好但维护两份；
|
||
- **C. 只接 Twenty CRM**：不做商品/订单工具，仅联系人/商机同步，工作量最小。
|
||
|
||
再补：注册 11 个工具（`register-tools.js` 适配新实例 API key）、OTP 邮件、输出护栏与质量指标（bridge 自带，复用即得）。
|
||
|
||
验收：搜商品/查订单/建商机一条 e2e 跑通。
|
||
|
||
### P4 公网渠道（约 0.5–1d，依赖域名/凭据）
|
||
|
||
1. 固定域名 + Let's Encrypt（推荐）或 Cloudflare 命名隧道；**quick tunnel 不可持续**（crm-new 的 root_url 就是临时域名，cloudflared 一重启就变）；
|
||
2. WhatsApp：Meta Cloud API 凭据（WABA/phone number/token/verify token）+ 回调地址 + 模板；
|
||
3. 复用 public-gateway 白名单思路（只暴露 WhatsApp webhook + 帮助中心，其余 404）；
|
||
4. root_url 与帮助中心域名统一。
|
||
|
||
验收：Meta 回调校验通过；公网只可达白名单路径；帮助中心/客服入口 HTTPS 正常。
|
||
|
||
### P5 运维与上线（约 2–4h）
|
||
|
||
- smoke.sh / e2e 脚本适配新实例；健康检查（已有 `/health`）+ 日志/告警；
|
||
- 定时备份 + 恢复演练纳入 runbook；
|
||
- 上线文档（范围、切流、验收、回滚）——可沿用 crm-new 的 go-live/runbook 结构；
|
||
- 版本策略：跟随稳定版（当前 v2.9.1），AI/WhatsApp 属较新功能，建议低流量验证。
|
||
|
||
## 3. 需要你拍板的决策点
|
||
|
||
1. **本实例定位**：独立演示/联调环境，还是将来生产？（决定域名、证书、备份等级）
|
||
2. **和 crm-new 的关系**：并存做隔离验证，还是最终替代它？
|
||
3. **邮件渠道**：继续 163（要 imap-proxy），还是换正式邮箱？
|
||
4. **AI key**：复用 crm-new 的 DashScope key，还是新申请？知识库走 LibreDesk 内置还是 bridge RAG？
|
||
5. **Twenty / bridge**：复用现有实例（A 路线），还是新建（B 路线），或只接 CRM（C 路线）？
|
||
6. **公网**：有没有可用域名？走 Cloudflare 隧道还是自有 nginx + 证书？
|
||
7. **多站点**：是否要搬 crm-new 的 `sites.json` 多站点路由（www / us + 商品搜索兜底）？
|
||
|
||
## 4. 不建议照搬的部分
|
||
|
||
- 旧栈 `crm/`（chatwoot / twenty:flywheel）不要动；
|
||
- crm-new 的 quick tunnel 与临时域名（不可持续）；
|
||
- 全量商品页 sitemap（www 32,691 / us 22,625 URL）——除非要做商品搜索兜底；
|
||
- 27 个历史用户（含 visitor/contact 测试数据）——新实例只建必要坐席即可。
|
||
|
||
## 5. 风险提示
|
||
|
||
- **163 IMAP 限制**：必须靠 imap-id-proxy 才能 SELECT，换邮箱可去掉这层；
|
||
- **凭据复制**：把 crm-new 的 key/token 复制到新实例前先确认责任边界，建议新实例用独立凭据；
|
||
- **两套并存**：本机已跑 20+ 容器（内存 14G，当前用 6G），再加 Twenty 一套会明显吃资源，需先规划；
|
||
- **RC/beta 功能**：WhatsApp、AI 相关功能较新，上线前跑一轮 e2e；
|
||
- **公网入口**：没有固定域名则 WhatsApp 回调无法长期用。
|
||
|
||
## 6. 推荐路径
|
||
|
||
先做 **P0 + P1（半天内）** 得到「人工渠道 + 帮助中心」可用闭环；
|
||
确认本实例定位后，再决定 P2 AI 是否立刻上、P3/P4 是否复用 crm-new 资源。
|
||
不建议一上来复制整套栈——两套并存的维护成本和数据一致性风险不划算。
|