omnigent

Omnigent：给 AI 编程工具装上「中央调度台」\n\n### 背景：一个程序员和三个 AI 助手的烦恼\n\n你同时用 Claude Code 写后端、用 Codex 写测试、用 Cursor 做代码审查——三个 AI 各管一摊，结果往往是：Claude 改的代码让 Codex 的测试报红，Cursor 审查时根本不知道 Claude 刚才做了什么。你疲于在三个窗口之间切换、人工同步上下文。这就是 Omnigent 试图解决的痛点：当你的团队里多了不止一个 AI 助手时，谁来协调它们？\n\nOmnigent 起源于 Databricks 内部对 AI 编程工具的统一治理需求。2024 年底由 Databricks 团队以 Apache-2.0 开源，定位是「AI Agent 元框架」（meta-harness）和「编排层」。它的核心思路是：不替代任何一个 AI 编程工具，而是为它们建造一个统一的调度平台，让 Claude Code、Codex、Cursor、Pi 等各种编程 Agent 在同一个会话中协作，而你只需站在更高层级指挥它们。\n\n### 核心功能：像一个指挥官一样调度多个 AI\n\n多 Agent 编排与会话同步是 Omnigent 的核心能力。你可以在同一个 Omnigent 会话中同时运行多个不同厂商的 AI 编程 Agent，消息、文件、终端状态在所有 Agent 之间保持同步。例如，内置的 Polly Agent 是一个「多 Agent 协调者」：她自己不写代码，而是像技术负责人一样规划任务、把工作分配给 Claude Code、Codex 或 Pi 的并行工作分支，再将每个分支的代码 diff 路由给另一个不同厂商的 Agent 做审查，最终由你决定是否合并。整个流程不需要你手动复制粘贴上下文。\n\n跨设备实时协作解决了传统 CLI 工具的孤立性问题。Omnigent 本质是一个 FastAPI + WebSocket 的服务端架构，你在一台机器上启动的会话可以通过 Web UI 从任何设备访问，包括手机。队友可以实时加入同一个会话，观察 AI 工作过程、在聊天中插入指令，甚至「共同驾驶」（co-drive）——你的队友可以在你的机器上执行消息。也可以「分叉」会话，克隆一份到自己的环境独立继续。\n\n策略Governance体系是 Omnigent 区别于其他 Agent 工具的关键差异化功能。它内置了三层策略机制（服务器级、Agent 级、会话级），通过 CEL（Common Expression Language）表达式评估每个 AI 动作的风险。内置策略包括：执行 Shell 命令前请求确认（ask_on_os_tools）、单会话最大工具调用次数限制（max_tool_calls_per_session）、Token 预算上限（cost_budget）等。策略可堆叠且以最严格者为准，开发者可以通过 YAML 文件或直接对话让 AI 自动配置策略。\n\n多模型网关支持让 Omnigent 不绑定任何单一 AI 厂商。支持四种凭证类型：直接 API Key（Anthropic、OpenAI 等）、官方 CLI 订阅（Claude Pro、ChatGPT Plus）、OpenAI/Anthropic 兼容网关（OpenRouter、Ollama、vLLM、Azure）、以及 Databricks 工作区。每个 Agent 可以有独立的默认模型，中途可以用 /model 命令动态切换。\n\n### 技术架构：FastAPI 服务端 + 模块化 Runner\n\nOmnigent 采用外部 Runner 模式：服务端（omnigent/server/）是一个 FastAPI + SQLAlchemy + PostgreSQL 的 Web 应用，负责协调、认证和持久化；实际的 Agent 执行运行在客户端机器（Runner）上，通过 WebSocket 隧道（/v1/runner/tunnel）与服务器通信。这种架构的优势是：你的 API Key 和代码始终在本地机器上，服务器只是「中控台」，不需要把密钥交给第三方。\n\n服务端路由设计极为模块化，核心包括：认证路由（auth.py）、多用户账号管理（accounts_*）、WebSocket 隧道（_runner_ws_tunnel.py）、MCP 工具池（mcp_pool.py）、托管宿主机管理（managed_hosts.py）、OIDC 单点登录（oidc.py）等。\n\n数据存储层（omnigent/stores/）包含多个专门 store：对话存储（conversation_store）、Agent 缓存（runtime/agent_cache.py）、文件存储（file_store）、Artifact 存储（artifact_store）、权限存储（permission_store）、策略存储（policy_store）。数据库迁移使用 Alembic，支持 Postgres 16。\n\n运行时层（omnigent/runtime/）负责 Harness（Agent 适配层）的进程管理（harnesses/process_manager.py）、凭据管理（credentials/）、文件系统和 MCP 工具注入。Runner 层（omnigent/runner/）处理 WebSocket 消息路由（routing.py）、工具分发（tool_dispatch.py）、策略执行（policy.py）、MCP 管理（mcp_manager.py）等。\n\n前端（ap-web/）是一个基于 Vite + TypeScript 的单页应用，使用 TipTap 编辑器，支持 Electron 桌面客户端（macOS）。后端还内置了 OpenAPI 文档（openapi.json），客户端 SDK（sdks/python-client/）和 UI SDK（sdks/ui/）与主包协同发布。\n\n### 部署方式：Docker 一键 + 多平台托管\n\nOmnigent 提供极其完善的部署选项，满足从本地开发到生产环境的全场景需求。Docker Compose 一键部署是最推荐方式：deploy/docker/docker-compose.yaml 包含 Omnigent 服务和 PostgreSQL 16 两个容器，通过 Caddy 自动处理 HTTPS。官方还在 GHCR 发布预构建镜像（ghcr.io/omnigent-ai/omnigent-server），无需本地 build，拉取即用。\n\n一键部署平台支持 Render（自动配置 Postgres，推荐）和 Railway。相比手动 Docker 部署，Render 部署只需点击一个按钮即可完成，自动配置数据库和 HTTPS。手动部署则覆盖 Fly.io（fly deploy）、Hugging Face Spaces（demo 级）、Modal（云沙箱预热）、Kubernetes（完整 K8s manifest）、Railway、Render 等。\n\n协作部署方面，设置 OMNIGENT_AUTH_ENABLED=1 启用多用户账号，首次启动自动创建 admin 账号（密码打印在日志中），通过 Web UI 邀请成员。还支持通过 OIDC 对接 Google、GitHub、Okta、Microsoft 等企业 SSO。\n\n### 使用门槛与局限性\n\n上手门槛中等偏高，不适合纯小白用户。虽然 omnigent install 一键安装脚本降低了初始配置难度，但你需要：Python 3.12+、Node.js 22（用于 Claude/Codex/Pi harness）、tmux、bubblewrap（Linux）。原生 Claude/Codex harness 还依赖 bubblewrap 做 OS 级沙箱隔离。对于只想简单体验的用户，Render 一键部署是更平滑的入口。\n\n当前局限性包括：项目处于 alpha 阶段（0.2.0.dev0），API 和配置格式可能在后续版本中发生变化；云沙箱（Modal/Daytona/Islo）虽然支持但需要额外配置；策略系统依赖 CEL 表达式，对不熟悉表达式的用户有一定学习成本；多 Agent 并行协作时，资源消耗会随 Agent 数量线性增长。\n\n### 行业意义与趋势\n\nOmnigent 代表了 AI Agent 领域的一个新兴方向——Agent 治理与编排层。随着 Claude Code、Codex、Cursor 等编程 Agent 工具的涌现，如何让它们协同工作、避免冲突、实现统一治理成为真实痛点。Omnigent 的策略Governance 机制体现了对 AI 安全性的关注——在 AI 自主性越来越强的当下，给 Agent 装上「安全阀」是不可或缺的设计。\n\n从技术趋势看，外部 Runner 架构（即数据留在本地、服务端做协调）是兼顾安全性和协作能力的平衡之选，Omnigent 在这方面的设计值得参考。其多模型网关理念（不绑定单一 AI 厂商）也反映了行业对 AI 供应商锁定问题的集体警惕。\n\n---\n\n总结：Omnigent 是一个野心勃勃的 AI Agent 协调平台，适合已经在使用多个 AI 编程工具并希望统一管理的开发团队。它的策略治理机制、多模型支持和跨设备协作能力是核心亮点，但 alpha 阶段的不稳定性意味着生产环境使用需谨慎评估升级风险。\n