30 个 GitHub 企业 AI 垂直方案：可交付性筛选

研究归档：本篇保留2026年9月30日前后的本地公开资料研究。开源版本、功能、许可和星数属于当时快照；技术决策应复核所列官方来源。架构与交付计划为参考设计。

更新：2026-09-30。目标是为“以 WeKnora 为知识内核，向客户交付销冠助手、门店助手、客服助手”筛选垂直业务产品与代码基础。这是官方仓库、README、许可证和文档的静态研究；没有安装、启动、压测，也没有验证任何渠道账号、客户数据或生产 SLA。

先看结论

最适合开始客户试点的组合：国内企业微信私域看 IYque-SCRM；海外 WhatsApp 看 Whatomate；网页/邮件/工单客服看 LibreDesk 或 AgentDesk；销售 CRM 看 Comp AI CRM 与 Twenty 对照。它们是应做 POC 的候选，不是已验证可生产交付的承诺。官方入口、数据回写与模型成本必须在客户环境核验。具体组合见 11-vertical-ai-opportunities.md。

门店助手尚未发现一个同时具备门店 POS/库存实时查询、店员身份权限、知识问答、销售动作闭环且许可清晰的高星完整产品。InnoShop 更像电商交易与商品底座；门店场景仍需自有应用层接 POS/ERP。不能把通用 RAG 聊天框当成门店成品。

口径与证据

• 用 GitHub 官方仓库元数据核验 70 个候选；筛掉通用 AI 框架、仅 API 通道和与客户业务链条弱相关的仓库，保留以下 30 个。其中 C 类含限制商用的公开源码项目，只作竞品研究，不等同于可自由商用的开源软件。 星数为 2026-09-30 快照，不是质量、活跃用户、交付能力或安全性证明；垂直小赛道会出现一百到几百星的项目。原始 70 仓库元数据、README 信号、许可证信号供复核。
• “AI/渠道/部署”写法仅表示官方 README 或官方文档声称有该能力。未读到的能力记为“待接入/待核”，没有根据仓库描述推断生产可用。
• A：优先 POC = 垂直流程、AI 和自托管说明较完整，许可路径相对清楚；B：组合/二开 = 适合作业务壳、组件或模板，须补产品能力；C：先过门槛 = 商业授权、渠道规则、源码缺口等事项先解决，再考虑交付。评级是本研究的选型判断，不是质量认证。
• 本次分布为 A 类 8 项、B 类 14 项、C 类 8 项；机器可读的 30 项清单含星数快照与分类，便于继续复核。
• 许可证列只是快速索引；具体以采用的 tag、文件级许可、模块授权和客户交付形态为准。AGPL/GPL 并非“禁止商用”，但网络服务、分发、修改及衍生作品义务需逐案落实。

30 项清单（按星数降序）

对选型有实际影响的五个发现

1. 客服壳与 AI 授权常分离。 Chatwoot 免费版说明与自托管定价确认 Captain AI 不随免费社区版提供；FreeScout AI 模块则明确免费、AGPL。采购/交付成本要按功能模块核算。
2. 国内客服的难点主要是渠道。 企微官方 API 是可长期交付路径，仍需企业认证、权限和会话存档条件；闲鱼/拼多多浏览器模拟方式即使开源，也不能把“今天能跑”承诺为账号安全或长期稳定。IYque 官方仓库与上述平台自动化项目需分开评估。
3. 海外首选官方 WhatsApp Cloud API。 Whatomate和 WACRM明确面向官方接口；WAHA支持多引擎，具体使用 WEBJS 等浏览器引擎时要核对平台政策。这是渠道结构差异，不是 AI 模型优劣。
4. 商用与 SaaS 是两件不同的许可问题。 ChatWiki LICENSE要求组织商业授权并限制多租户 SaaS；TGO LICENSE对多租户和标识另设条件；CordysCRM LICENSE要求保留品牌。设计自有多租户平台前先排除不匹配的代码。
5. 销售助手需要真实 CRM 数据与受控写入。 Twenty、Comp AI CRM、Relaticle可承载客户、商机、任务；知识库只能答产品/政策，实时客户状态要查 CRM。创建跟进任务、改商机阶段等写操作需用户确认和审计，见既有架构方案。

特意未进入 30 项的常见误选