Files

T

wangliang 39986f10f2 初始化 LibreDesk 本地实例部署仓库

- 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/

2026-10-29 13:24:13 +08:00

9.6 KiB

Raw Permalink Blame History

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）

Live Chat inbox + widget（Website 渠道），把这套的 widget 代码嵌到目标站点；
Email inbox：先定用哪个邮箱 —— 163 需要 imap-id-proxy（LibreDesk 不发 IMAP ID）；建议换企业邮箱/自建 SMTP 省掉代理；
配置 notification.email.*（OTP/通知邮件走同一 SMTP）；
建 Team（Wholesale Support）+ 分配规则（邮件/WhatsApp 转人工）；
建 Help Center，导入 crm-new 的 108 篇文章（可参考 import-kb-helpcenter.js）。

验收：widget 能落会话；邮件收发一轮打通；帮助中心可搜索；新会话按规则进人工团队。

P2 AI 能力（约 2–4h）

填 AI provider（复用 crm-new 的 DashScope key，或新申请），确认默认 provider；
配 AI assistant（instructions / guardrails / handoff / languages / max_turns）；
知识库二选一：
- A：用 LibreDesk 内置 KB/snippets + embedding（新栈自包含，但要重新灌数据）；
- B：沿用 bridge 的 pgvector RAG（数据现成，但依赖 bridge 运行）；
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，依赖域名/凭据）

固定域名 + Let's Encrypt（推荐）或 Cloudflare 命名隧道；quick tunnel 不可持续（crm-new 的 root_url 就是临时域名，cloudflared 一重启就变）；
WhatsApp：Meta Cloud API 凭据（WABA/phone number/token/verify token）+ 回调地址 + 模板；
复用 public-gateway 白名单思路（只暴露 WhatsApp webhook + 帮助中心，其余 404）；
root_url 与帮助中心域名统一。

验收：Meta 回调校验通过；公网只可达白名单路径；帮助中心/客服入口 HTTPS 正常。

P5 运维与上线（约 2–4h）

smoke.sh / e2e 脚本适配新实例；健康检查（已有 /health）+ 日志/告警；
定时备份 + 恢复演练纳入 runbook；
上线文档（范围、切流、验收、回滚）——可沿用 crm-new 的 go-live/runbook 结构；
版本策略：跟随稳定版（当前 v2.9.1），AI/WhatsApp 属较新功能，建议低流量验证。

3. 需要你拍板的决策点

本实例定位：独立演示/联调环境，还是将来生产？（决定域名、证书、备份等级）
和 crm-new 的关系：并存做隔离验证，还是最终替代它？
邮件渠道：继续 163（要 imap-proxy），还是换正式邮箱？
AI key：复用 crm-new 的 DashScope key，还是新申请？知识库走 LibreDesk 内置还是 bridge RAG？
Twenty / bridge：复用现有实例（A 路线），还是新建（B 路线），或只接 CRM（C 路线）？
公网：有没有可用域名？走 Cloudflare 隧道还是自有 nginx + 证书？
多站点：是否要搬 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 资源。不建议一上来复制整套栈——两套并存的维护成本和数据一致性风险不划算。

9.6 KiB Raw Permalink Blame History Unescape Escape