Omni：把公司内部工具接进一个自托管 AI 代理的 Rust 与 Python 混合栈

它解决的是企业内部的工具割裂问题

Omni 要解决的问题很具体：员工每天在 Google Drive、Gmail、Slack、Confluence、Jira、HubSpot 这些系统之间来回切换，信息分散，查找和操作都耗时。它把所有这些系统接到一个对话界面，让用户用自然语言要求代理调查问题、准备更新、分析数据或执行受支持的操作。目标用户是已经重度使用这些商业工具的企业，而不是个人开发者。它强调权限感知，索引的内容会继承每个源系统的权限设置，这意味着用户只能通过代理访问他们本来就有权访问的信息。这一点是它区别于普通 RAG 聊天机器人的关键。

架构：一个 Postgres 数据库承担三种职责

Omni 的架构选择很直接：用 Postgres 加 ParadeDB 扩展做 BM25 全文搜索，用 pgvector 做语义搜索，同时把应用数据也放在同一个数据库里。README 明确说没有 Elasticsearch，没有专门的向量数据库，只有一个数据库需要调优、备份和监控。核心服务用 Rust 编写，负责搜索、索引和连接器编排；代理运行时和模型编排用 Python；前端是 SvelteKit。每个连接器跑在独立的轻量容器里，这样不同集成可以用不同语言和依赖，不会影响系统其他部分。这种多语言混合栈的代价是部署和调试时你需要同时理解 Rust 和 Python 两个生态。

部署方式：从 Docker Compose 到 Terraform

部署路径有两条。单服务器场景用 Docker Compose，README 提供了文档链接，还提到一个 Omni CLI 用于升级和诊断。生产环境用 Terraform 部署到 AWS 或 GCP。没有给出具体的 docker-compose.yml 内容，但根据架构描述，至少需要 Postgres 加 ParadeDB、Python 代理服务、Rust 搜索服务、SvelteKit 前端，以及各个连接器容器。连接器各自独立容器意味着镜像数量会随集成数量增长，资源占用需要提前估算。对于只想跑一个最小实例的团队，Omni 的组件数量明显比单二进制工具多。

沙箱执行：隔离网络加 Landlock，但边界要自己确认

代理运行时可以在沙箱容器里执行 Python 和 bash 代码，用于检查文件、分析数据、生成输出。沙箱放在一个隔离的 Docker 网络上，没有访问内部服务或互联网的权限。它使用 Landlock 文件系统限制、资源限制和只读根文件系统。这个设计比一般工具直接调 shell 要谨慎，但文档没有说明沙箱是否支持持久化存储或网络白名单。如果你需要代理访问某些内部 API，沙箱的完全隔离可能会成为阻碍。实际部署时，你需要自己测试沙箱边界是否符合你的安全要求，README 没有给出默认的允许列表或拒绝列表。

模型接入的灵活性与代价

Omni 支持 Anthropic、OpenAI、Gemini、AWS Bedrock、Vertex AI、Azure AI Foundry，以及任何 OpenAI 兼容端点，比如 vLLM、Ollama、LM Studio、LiteLLM。这个范围覆盖了主流云服务和本地部署选项。灵活性带来的代价是配置复杂度：每个模型提供商有不同的认证方式、端点格式和限流策略。虽然 README 说模型由你选择，但没有说明是否支持多模型路由或按任务类型选择模型。对于想用单一模型快速上手的团队，这种开放性反而可能增加决策成本。

连接器的真实覆盖范围

README 列出了 Google Workspace 的 Drive、Gmail、Google Chat，Microsoft 365 的 SharePoint、OneDrive、Outlook 与 Calendar、Teams，知识库类的 Confluence、Notion、Nextcloud、Paperless-ngx、Web、Local Files，通信类的 Slack、Fireflies、IMAP，项目管理类的 Jira、GitHub、ClickUp、Linear，以及业务应用（表格被截断，但提到 HubSpot）。这个列表很广，但每个连接器的深度未知。比如 Gmail 连接器是否支持发送邮件、搜索附件、管理标签，README 没有说明。连接器用 Python 或 TypeScript 的 SDK 构建，扩展性不错，但你需要查看每个连接器的具体文档来确认它能做什么。

维护成本与许可证

Apache-2.0 许可证意味着你可以自由使用、修改和分发，没有 copyleft 义务，这对企业内部部署很友好。维护成本主要来自三方面：一是 Postgres 需要同时承担全文索引和向量索引，ParadeDB 的版本升级可能影响现有查询；二是连接器各自独立容器，每个连接器的依赖更新和安全补丁都需要单独管理；三是 Rust 和 Python 两个语言栈的构建和部署链不同，CI/CD 需要分别处理。Omni CLI 提供升级和诊断功能，能减轻一些负担，但文档没有说明 CLI 是否支持回滚或备份恢复。

一个明显的替代方案：自己拼装 RAG 流水线

如果你不想引入 Omni 这样的完整代理栈，可以直接用向量数据库加 LangChain 或 LlamaIndex 拼一个只读的问答系统。区别在于：Omni 把索引、权限继承、连接器、沙箱执行和前端都打包了，而自建方案需要你自己处理每个环节。自建的好处是你可以只连接一两个系统，用你熟悉的语言和数据库，避免引入 Rust 和 Python 两套运行时。坏处是权限继承很难做对，因为你需要从每个源系统拉取 ACL 并同步到索引，Omni 声称已经内置了这个机制。如果你的需求只是搜索文档，自建可能更快；如果需要跨系统执行操作，Omni 的沙箱和连接器框架能省不少事。

编辑结论

适合已经使用 Google Workspace、Microsoft 365、Slack、Jira 等工具，并且愿意自己维护一套多语言服务栈的企业。不适合只想快速搭一个聊天机器人的团队，因为 Omni 的部署和运维成本明显高于单容器方案。采用前先验证三件事：一是 ParadeDB 与 pgvector 在你们现有 Postgres 版本上的兼容性，二是各连接器对源系统 API 权限的实际要求，三是沙箱执行环境能否满足你们对代码隔离的合规标准。Omni 的设计核心是权限继承，如果源系统权限模型混乱，索引内容就可能出现越权暴露，这一点必须在试点阶段用真实数据测试。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes