Omnigent：一个把 Claude Code、Codex、Cursor 装进同一会话的元编排层
Omnigent 是一个开源 AI 代理框架和元工具：编排 Claude Code、Codex、Cursor、Pi 和自定义代理，无需重写即可交换工具，强制执行策略和沙箱，并通过任何设备进行实时协作。
秒懂
- 它是什么？
- Omnigent 是一个开源 Python 项目，用统一层调度多个 AI 编码代理，支持从手机或浏览器接管会话，并在云沙箱中运行。本文基于仓库文档分析它的架构、安装方式、限制与适用场景。
- 适合谁用？
- 适合需要同时管理多个编码代理、希望在不同设备间切换会话、或者想用统一策略约束代理行为的团队采用。不适合只需要单代理简单调用的用户，也不适合必须在 Windows 上使用原生终端包装器的场景。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是多代理协作的碎片化问题
现在一个工程师可能会同时用 Claude Code 写代码、用 Codex 做重构、用 Cursor 做交互式编辑。每个工具都有自己的会话、历史和权限模型，切换成本很高。Omnigent 把这一层抽出来，做成一个元编排层。它不替代这些代理，而是让它们在一个共享会话里工作，消息、子代理、终端和文件保持同步。这个项目面向的是已经用多个代理、并且觉得切换麻烦的开发者，以及需要在团队里共享代理会话的协作场景。
核心机制：会话同步与代理无关的抽象
从 README 看，Omnigent 的核心是一个服务器进程，它管理会话状态，并作为各种代理的统一入口。你可以在终端启动一个会话，然后在浏览器或手机继续，因为消息和文件状态都同步到服务器。代理本身可以是 Claude Code、Codex 等现成 CLI，也可以是用 YAML 定义的自定义代理。Omnigent 不关心底层代理是什么，它只负责把用户输入路由过去，再把结果同步回来。这种设计的关键在于，所有代理都通过同一个会话协议交互，所以你可以让一个代理审查另一个代理的输出，或者把任务拆给多个代理并行处理。
安装与启动：一条命令，但依赖不少
官方推荐的安装方式是一行脚本：curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh。这个脚本会处理 uv、git、Node.js 等前置要求。也可以手动用 uv tool install omnigent 或 pip install "omnigent"，需要 Python 3.12+。可选的集成通过 extras 传入，比如 uv tool install "omnigent[databricks,modal]" 会加入 Databricks 模型提供方和 Modal 沙箱。启动后，omnigent server 是主服务，web UI 通过 pnpm 构建。原生终端包装器（如 omnigent claude）依赖 tmux，Linux 上还强制要求 bubblewrap，否则终端无法启动。Windows 原生模式是降级的，不支持这些终端包装器，也没有文件系统和网络隔离。
策略与沙箱：治理不是附加功能，而是内置层
Omnigent 把策略控制做成了第一等公民。你可以创建策略，在代理执行危险操作前暂停等待人工批准，或者设置花费上限、限制代理能访问的工具。策略作用范围可以是整个服务器、单个代理或单次聊天。沙箱方面，它支持在 Modal、Daytona、E2B、Kubernetes 等云沙箱中运行代理，也可以由服务器按会话动态分配。这种设计意味着，你可以在不重写代理代码的情况下，给所有代理统一加上审批流程。不过要注意，策略和沙箱是两层，策略控制的是行为，沙箱控制的是运行环境，两者需要分别配置。
跨设备与协作：会话跟着人走，但同步有代价
README 强调会话可以从终端迁移到浏览器或手机，这在远程调试或演示时很实用。协作功能允许分享会话链接，让队友实时观看代理工作，甚至共同驾驶或分叉对话。但这里有个隐含的代价：所有会话状态都经过服务器，这意味着你需要维护一个常驻服务，并且要处理网络延迟和潜在的同步冲突。文档没有说明多用户同时编辑时的冲突解决策略，这是一个需要实测的点。如果你只是单机使用，这个架构可能显得过于重量级。
Windows 支持是残缺的，别指望完整体验
Omnigent 在 Windows 上原生运行但处于降级模式。安装脚本是 POSIX-only，所以要用 uv tool install 手动装。能用的有 omnigent server、web UI 和 SDK 型 harness（比如用 claude-sdk 跑 agent.yaml）。但原生终端包装器（omnigent claude 等）不可用，而且没有 bubblewrap 或 seatbelt 的文件系统和网络隔离，只有 Windows Job Object 做进程树限制。这意味着在 Windows 上，你得不到文档宣传的完整沙箱保护。如果你需要严格隔离，唯一现实的选择是 Linux 或 WSL。
替代方案与取舍：自己写胶水，还是用现成的
如果你不用 Omnigent，常见的做法是自己写脚本，用 tmux 或 screen 同时跑几个代理，然后手动复制粘贴结果。这种方式的优点是零依赖，但缺点也很明显：没有统一的会话状态，无法跨设备同步，也没有策略层。另一个方向是直接用某个代理的内置功能，比如 Claude Code 的 subagent 机制，但那就被锁定在单一厂商。Omnigent 的取舍在于，它用一个 Python 服务换来了代理无关的抽象，但代价是额外的部署和运维负担。对于只想用两个代理且不介意手动切换的人来说，这个抽象可能不值得。
维护与许可证：Apache-2.0 下的快速迭代
项目采用 Apache-2.0 许可证，这对商业使用比较友好，没有 copyleft 义务，但要注意你集成的各代理 CLI 有自己的许可证。从发布节奏看，v0.9.0 到 v0.11.0 在两周内连发三个版本，说明项目处于快速迭代期，API 可能不稳定。升级命令是 omni upgrade，它会检测你的安装方式。由于依赖较多（uv、Node.js、tmux、bubblewrap），升级时可能要同步更新这些外部工具。建议在升级前查看 changelog，因为 0.x 版本可能引入破坏性变更。
编辑结论
适合需要同时管理多个编码代理、希望在不同设备间切换会话、或者想用统一策略约束代理行为的团队采用。不适合只需要单代理简单调用的用户，也不适合必须在 Windows 上使用原生终端包装器的场景。采用前先确认三点：你的 Python 版本是否 3.12+，Linux 上是否安装了 bubblewrap（否则原生终端包装器无法启动），以及你需要的沙箱或模型提供商是否在 extras 列表中。若你依赖严格的文件系统隔离，Windows 原生模式不提供，必须改用 WSL 或 Linux。
社区笔记