Onyx 替代品：开源企业 AI 搜索与聊天平台怎么选

🇺🇸
Read in English: Onyx Alternatives: How to Choose an Open-Source Enterprise AI Search and Chat Platform

周三下午三点，市场部的小林要找一份去年 Q4 的定价复盘。她记得那份东西写在 Notion 里，可搜索框敲进去，出来三条似是而非的页面，标题都叫「定价讨论」。她转去 Slack，印象里有人发过截图，换了三个关键词也没翻到。最后她打开 Google Drive，在几十个文件里看见一个叫「final_v3_真最终版」的 PPT，点开，是另一条产品线的东西。

十分钟就这么过去了。她其实并不确定这份文档是否存在，只知道如果存在，它应该躺在某个她能访问的地方。

三十人的公司，知识散在四五个系统里，这几乎是默认状态。人少的时候靠记忆和群里喊一嗓子还能糊过去，人一多，新来的人连该问谁都不知道。

Onyx 就是冲着这个场景做的。它的 GitHub 仓库把自己称作「团队和 AI agent 的知识与上下文层」，能接五十多个应用，把里面的文档、消息、工单抓过来，建成索引，然后用一个聊天框回答「我们 Q4 的定价是怎么定的」。

这里要先把两个词说清楚。RAG，检索增强生成，意思是模型本身没读过你公司的任何文档，系统先在你的资料里找出一批相关段落，再把它们塞进模型的上下文，让它照着这些材料回答。连接器则是把 Notion、Slack、Google Drive 这类外部系统接进来的适配器，负责拉数据、同步权限、按时更新。没有连接器，索引就是一口枯井；没有索引，模型只能凭训练时的记忆胡说。

Onyx 的做法是自建索引。它同时维护向量索引和关键词索引，前者管语义相近，后者管精确匹配，官方把这种组合叫 hybrid。README 里有一句话说得挺直接：与其让 agent 现场去翻几十个 MCP、烧掉几千个 token，不如在预先建好的索引里一次性取出最相关的几篇原文。这话是它自己说的，带着立场，但方向没错。

它不是一个轻东西

把 Onyx 跑起来不难，官方给了一行安装脚本，Docker Compose 一路装完。难的是跑起来之后。

Onyx 分两种模式。Lite 是个轻量聊天界面，官方说内存占用不到 1GB，但它不建索引，连接器拉来的东西进不了库。要用完整功能得走 Standard，而 Standard 背后站着向量库、跑同步任务的后台容器、做嵌入和推理的模型服务、Redis 缓存、对象存储。这不是一台闲置笔记本能顺手扛下的组合。官方支持 Docker、Kubernetes、Helm 和 Terraform，也能在主流云上部署，言下之意是：这东西默认你是有人管的。官方文档里还单独开了一页讲资源规划，说明这不是一句客套。

具体到日常，这意味着连接器同步失败时得有人翻容器日志，模型换版本时得有人重跑嵌入，权限从 Google Workspace 同步过来对不上时得有人排查。这些活单件都不重，但它们是持续的，而且往往落在同一个人身上。

授权上，社区版是 MIT，核心的 RAG、聊天、Agent、Actions 都在里面，这一点很实在。企业版另外加了 OIDC/SAML 单点登录、本地部署、区域部署、白标、审计导出这些。官网定价页只列了 Business 和 Enterprise 两档，前者按团队规模卖，后者写着「联系我们」，没有公开数字。对预算需要提前报批的团队来说，这种不透明本身就是一道门槛。

所以找替代品的人，理由大多很具体：我只想给团队一个干净的聊天入口，不需要索引；我卡在几万份文档的同步上，想要更轻的装法；我本来就在用 Dify 搭应用，不想再养一套；也有人反过来，觉得开源自建这件事本身就不该由自己干。「Onyx 不好」这种判断反而少见。

下面这几款按「你缺的是哪一块」来分，不按功能条数排名。放在一张表里看，差异会清楚一些。

工具	部署方式	授权协议	数据源接入	适合谁
Onyx	Docker Compose、Kubernetes、Helm/Terraform，可完全离线	社区版 MIT，企业版商业授权	官方称 50+ 应用，定价页列 40+ 连接器	要多源索引、又要权限隔离的中大型团队
Dify	Docker Compose、云端、企业自托管	Dify 开源许可，基于 Apache 2.0 附加条件	文档上传与知识库流水线为主	想搭 AI 应用和 workflow 的产品、研发团队
AnythingLLM	桌面应用、Docker、多种云模板	MIT	文档上传为主，PDF、TXT、DOCX 等	小团队或个人，想十几分钟用起来
Open WebUI	pip、Docker、Kubernetes	Open WebUI 许可，要求保留品牌标识	本地上传、Google Drive、OneDrive/SharePoint，另有配套同步工具	已经有模型服务，只缺一个好用的前端
LibreChat	Docker、自建服务器，可横向扩展	MIT	文件上传与独立 RAG 服务	想要 ChatGPT 式多模型界面的团队
Glean	厂商托管 SaaS	闭源商业授权	官网称 275+ 连接器	预算充足、合规要求重的大企业

表格里最容易被忽略的一列是「数据源接入」。这一列决定了工具用起来像不像那么回事。一个只能上传文件夹的工具，和一个连 Slack 里三年前的讨论都扫进去的工具，回答质量差得很远。另一列是授权，MIT 和「基于 Apache 2.0 附加条件」在法务眼里完全两回事，尤其当你打算把它嵌进自己的产品里。

Dify：如果你真正想做的是「应用」

假设有一家二十人的电商公司，客服主管想做一个能回答退换货政策的机器人，还想让运营每天早上自动生成一份差评汇总。他们不需要一个覆盖全公司的搜索入口，需要的是把模型、提示词、知识库和外部接口串成几条固定的流水线。

这就是 Dify 的舒适区。它的核心是一块可视化画布，你把节点拖上去，连起来，中间插入知识库检索、条件判断、HTTP 请求，最后发布成一个网页应用或者 API。RAG 在它这里是一个 Pipeline，从文档解析、切分、向量化到召回都能调。模型方面它接了几十家推理服务商和自托管方案，几乎不挑。部署用 Docker Compose，官方写的最低配置是 2 核 4GiB，一台普通的云主机就能起步。

它的授权叫 Dify 开源许可，基于 Apache 2.0 加了若干附加条件。这意味着它比纯 MIT 多一层约束，商用之前值得让法务读一遍原文。多云和企业版是另外的价钱，SSO、RBAC、SLA 那些东西都在企业版里。

用它替代 Onyx 的代价在于视角。Dify 是「我来造一个东西」，Onyx 是「我来查一个东西」。前者灵活，后者省心。如果团队的诉求是「每个人都能问公司的事」，用 Dify 搭出来的应用往往要你自己补权限、组织架构、审计这些外围，工作量不小。

AnythingLLM：把门槛压到最低

再假设一个场景。三个人的设计工作室，合同、报价单、项目复盘都放在各自的电脑里，没有 IT，也没人愿意维护服务器。他们想要的是一个装上就能用、把文件夹拖进去就能问的软件。

AnythingLLM 基本就是为这种时刻准备的。它提供 macOS、Windows、Linux 的桌面版，下载安装，选一个模型，把文档拖进工作区，就能开始对话。它也内置了本地模型引擎，基于 llama.cpp 那一套，没有 API key 也能跑，只是速度取决于机器。向量库默认用 LanceDB，也支持 PGVector、Qdrant、Milvus 这些。整个项目是 MIT 协议，用起来没有太多顾虑。

需要提醒的是，多用户和权限管理只在 Docker 版本里有，桌面版本质上是单人工具。它的数据源也以文档上传为主，PDF、TXT、DOCX 这些常见格式没问题，但如果你的知识大量散落在 Slack 的对话和 Jira 的工单里，它没法像 Onyx 那样自己去捞。它还有匿名遥测，可以在设置里关掉，官方在 README 里把收集了什么写得很细，这一点倒是坦率。

对小团队来说，这种「不完美但今天就能用」的价值，常常大过一张功能对照表。

Open WebUI：你可能只缺一个门面

有一种情况很常见：公司已经通过 Ollama 或者某个 OpenAI 兼容的网关统一了模型调用，模型不缺，缺的是一个大家愿意打开的界面。这时候上 Onyx 有点像为了喝杯水修一座水厂。

Open WebUI 的定位就是那个界面，而且做得比「界面」多一点。它能接任何 OpenAI 兼容的接口，也能直接连 Ollama，装法有 pip、Docker、Kubernetes 几种。多用户、用户组、细粒度权限都有，LDAP/AD、OAuth、SCIM 这些企业里常见的认证方式也支持。它自带本地 RAG，官方说支持九种向量库，检索走 BM25 加向量的混合模式，还能重排。文件来源上，它原生支持从 Google Drive 和 OneDrive/SharePoint 里挑文件，另外有一个配套的同步工具，能从 GitHub、Confluence、Jira、Slack、Notion 等四十多个来源往知识库里灌数据。

这里要说清楚一点：那四十多个来源由配套组件提供，主程序里没有，部署时是另一套东西。很多人看到介绍以为开箱即得，装完发现不是，落差就在这儿。

授权方面，它用的是 Open WebUI 许可，带一条「保留品牌标识」的要求。你自己内部用没关系，但如果你想把它改成自己的产品对外发布，这条就得认真读。它的功能铺得很开，频道、笔记、日历、定时任务都有，好处是一个入口全包，坏处是对于一个只想问答的团队，界面会显得热闹过头。

LibreChat：多模型切换的那批人

还有一种团队，模型用得杂。有人坚持 Claude 写文案，有人要用 DeepSeek 省成本，研发那边还接着 Azure。他们不想要五个网站五个账号，想要一个地方切来切去，历史记录还都在。

LibreChat 干的就是这件事。它的界面明显照着 ChatGPT 的样子做，多个服务商接在一个下拉框里，对话中途也能换模型。Agent、MCP、代码解释器、artifacts、全库消息搜索这些都有，多用户认证支持 OAuth2、LDAP 和邮件登录，管理员可以在浏览器里改角色和权限，不用重新部署。整个项目是 MIT，这一点比很多「开源但带附加条款」的项目干脆。

它的知识库能力靠一个独立的 RAG 服务，需要单独部署。想要「问公司文档」，你得自己把检索那一层搭起来。界面和接口它给，五十个现成连接器它不给。对研发来说这不算事，对行政来说就是事。

Glean：另一条路上的答案

前面几款都是自己动手，Glean 是反面。它不开放部署，你买到的是一个托管服务，厂商负责接数据、建索引、管权限。官网首页列的数字很直接：275 个以上的连接器，40 多种模型，权限感知，SOC 2 Type II、ISO 27001、HIPAA、GDPR 这些合规认证一并列出。

它的目标客户也很明确，就是那些员工过千、系统成灾、法务和合规部门能一票否决的公司。对这类组织，自建一套 Onyx 的人力成本和合规成本，可能比订阅费还高。反过来，一个三十人的团队去谈 Glean，大概率连报价都拿不到，因为它走的是企业销售，没有自助注册。

把它放进这篇里不是为了凑数。替代品这个词，有时候替代的是「谁来承担运维」这个问题。Onyx 把答案交给你，Glean 把答案收回去，中间那几款各自站在不同的位置上。

怎么选，取决于你此刻最疼的地方

如果团队里已经有人在维护 Kubernetes，文档又确实散在 Notion、Confluence、Slack、Drive 这些地方，并且权限必须跟着源系统走，那 Onyx 仍然是最贴近需求的那个。它把这个组合做完整了，代价是你得养得起。先用 Lite 模式试界面，再决定要不要上 Standard，是一条比较稳的路。

如果真正的诉求是做一个面向客户或内部流程的 AI 应用，需要反复调提示词、接外部接口、看调用日志，那 Dify 更合适。它的强项在「造」这一侧，别指望它开箱就变成公司搜索。

如果只有几个人，没有运维，今天就想用，AnythingLLM 的桌面版几乎没有对手。它的天花板也明显，人一多、数据源一杂，就该考虑搬家。

如果模型层已经统一好了，缺的只是一个大家愿意用的入口，Open WebUI 的性价比很高。记得把配套的同步工具算进部署计划里，不然知识库会一直是空的。

如果团队里模型换得比衣服还勤，需要一个统一的多模型聊天台，LibreChat 的体验最接近大家已经习惯的东西。知识库那块要自己补，这是它让出来的空间。

如果公司规模已经大到合规部门会来问「数据出不出境」「权限怎么审计」，而且预算走得通，Glean 这类托管方案反而省事。它算不上开源替代品，更像「不自己干」这个选项本身。

回到小林那个下午。她最后是在一个离职同事的共享链接里找到那份复盘的，链接早就失效，是别人转存过一份。这种运气不该是公司知识管理的主要机制。选哪个工具，其实是在选你愿意为「下一次不用靠运气」付多少代价。有人付服务器，有人付订阅费，有人付一个下午的部署时间。三种都合理，只要别指望一分不付。真正要避开的，是买了一套系统却没人管同步，三个月后索引里躺着一堆过期文档，大家又回到群里喊人。