Onyx：给团队和 AI 建一层知识上下文

把 50 多个应用的知识汇成一层可检索上下文，再喂给人和 AI 代理。

企业内部知识散在 Slack、Notion、Drive、Jira、Confluence 里，员工找不到，AI 也看不到。Onyx 的做法是先把这些源接进来索引，再做一层可检索的上下文层：人可以问，AI 代理也可以通过它取。与"让 Agent 一个个调 MCP 现查"相比，它强调低延迟、低成本、少 token。项目用 Python 写，社区版 MIT，33,329 星（以 GitHub 为准）。

核心能力

1. 50+ 数据源接入与权限继承

官方 README 写的是 50 多个应用，拉取时会一并带上元数据和权限信息。这一点决定了它能否在企业里用：张三搜不到李四的薪酬文档，不是因为没人配规则，而是索引时就继承了源系统的权限。场景上，新员工入职第一天就能用自然语言找到流程文档，不用先问一圈人。

2. Agentic RAG：先检索再回答

它把混合索引与一套专为信息检索调优的 agent harness 组合起来，官方声称在搜索与回答质量上是首要指标。实际效果差异体现在复杂问题上：问"上季度客诉里反复出现的支付问题是什么，影响哪些客户"，它需要跨多个文档拼接答案，而不是把最相似的一段原文招回来。

3. Deep Research 与自定义 Agent

它内置多步研究流程，能出一份带引用的报告；也可以给不同团队建专属 Agent，各自限定知识范围、自定义指令、加上动作能力。财务团队的 Agent 只看财务库，客服的只看产品手册，避免一个万能助手什么都答但都不准。

4. 外部动作、MCP 与沙箱

Agent 不只回答，还能执行：通过外部动作与 MCP 在第三方应用里完成任务；在安全沙箱里跑代码、处理中间文件；生成文档与图表作为可下载产物；还支持语音输入输出。对开发团队来说，沙箱这一条尤其有用——让它真跑一段脚本验证结论，而不是文字推测。

5. 部署形态与 Lite 模式

官方给了一行安装脚本：curl -fsSL https://onyx.app/install_onyx.sh | bash。同时提供 Docker、Kubernetes、Helm/Terraform 部署指南。Standard 模式包含向量与关键词索引、后台同步容器、推理服务、Redis 与 MinIO；Lite 模式内存占用不到 1GB，只能做聊天与 Agent，不能索引文档——适合先看界面。

使用上手

1. 先确定部署模式：只想看界面跑 Lite，要真建知识库跑 Standard（官方建议 4GB 以上内存起步的机器）。
2. 用一行脚本或 Docker Compose 启动，确认 Web 界面能打开。
3. 接模型：本地 Ollama / vLLM 或 OpenAI、Anthropic、Gemini 均可，先接一个跑通再扩。
4. 接数据源：先接一个（比如 Confluence 或 Drive）观察索引质量与权限映射，再批量加。
5. 建第一个 Agent：限定只访问这个数据源，写清楚回答风格与拒答边界。
6. 需要接进现有工具链时，用它自带的 MCP server 把 Onyx 指向 Claude Code、Codex 等客户端。

优点与不足

优点

• 社区版 MIT，核心 RAG、聊天、Agent、动作都可用，不是功能阉割版。
• 权限继承是原生设计，企业内部落地阻力小。
• 既能自托管也能用云版，数据主权可选。
• 自带 MCP server，能被其他 AI 客户端当上下文源。

不足

• Standard 模式组件多（索引、队列、推理、Redis、MinIO），运维成本不低。
• 50+ 连接器的配置质量参差不齐，冷门源可能要自己调。
• 企业功能（SSO、SCIM、RBAC、白标）在 EE 版，要付费。
• 中文文档与社区案例偏少，国内网络下部分源连接慢。

适合谁

• 内部知识散在多个 SaaS、想统一搜索的中大型团队。
• 对数据出境敏感、必须自托管的公司。
• 想把企业知识接给 Claude Code 等编码 Agent 的工程团队。
• 需要给不同部门建专属客服/问答 Agent 的运营团队。

下载与访问

• 仓库：https://github.com/onyx-dot-app/onyx
• 官网：https://onyx.app/
• 文档：https://docs.onyx.app/

许可证与部署

本文属于「项目」分类的 AI 资源专栏，更多评测见分类页。