
这次看到的是这个项目:omnigent-ai/omnigent

Stars:6,447 | Forks:849 | License:Apache-2.0 | 主要语言:Python |
|---|
Omnigent 把自己叫作“meta-harness”。
这个词听起来有点绕。简单说,Claude Code、Codex、Cursor、OpenCode、Pi 这些工具,本身都负责让模型读文件、跑命令、调用工具。Omnigent 再往上加一层,把它们接进同一套会话、权限和协作界面。
所以它不是一个新模型,也不是只服务某个模型的聊天壳。它更像一个 Agent 工作台:底下接不同的执行器,上面统一管理任务、历史记录、工具权限和人机协作。

它能跑在终端、浏览器、手机和 macOS 客户端里。一次会话从终端开始,换到浏览器后还能接着看,消息、子 Agent、终端和文件会同步。
现在用多个 AI 编程工具,真正麻烦的往往不是“能不能生成代码”,而是每套工具各有自己的会话、模型配置和权限方式。
你可能让 Claude Code 写功能,让 Codex 做审查,再让另一个 Agent 查资料。任务一多,谁做了什么、花了多少、哪些命令需要确认,很快就散在几个终端里。

Omnigent 想统一的就是这一层。你可以在同一会话里混用不同 Agent,也可以让一个 Agent 检查另一个 Agent 的结果。团队成员还能通过链接进入同一场会话,查看过程、评论或继续操作。
第一个看点是组合能力。
仓库自带两个很直观的例子。Polly 像一个技术负责人:先拆任务,再把工作交给多个编码 Agent,最后让不同厂商的 Agent 交叉审查。Debby 则会同时询问 Claude 和 GPT,把答案并排放出来,还能让它们继续辩论。

第二个看点是控制能力。
它的策略不只写在提示词里。服务端可以按整套系统、单个 Agent 或单次会话设置规则,比如限制花费、约束工具访问,或者让高风险操作停下来等人确认。

第三个看点是沙箱。Linux 上可以用 bubblewrap,macOS 上用系统自带的 Seatbelt。文件和网络访问都能收紧,凭据也可以由代理在请求发出时补上,不必直接暴露给 Agent。

我觉得它值得看的地方,不是“又多了一套 Agent 框架”,而是它把注意力放在 Agent 上线之后的管理问题。
当团队只跑一个 Agent 时,切模型、共享会话、限制成本都不难。可一旦开始混用 Claude Code、Codex 和自定义 Agent,这些事就会变成公共问题。Omnigent 选择在各个 harness 之上处理,而不是要求大家重写已有 Agent。

仓库在 2026 年 6 月创建,7 月 3 日发布了 v0.4.0,目前已经有 6.4k stars。增长很快,也说明“怎么统一管理多个 Agent”确实是很多人正在遇到的问题。
最省事的安装方式是一条命令:
curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh
也可以用 uv 或 Homebrew:
uv tool install omnigent
brew install omnigent-ai/tap/omnigent
它需要 Python 3.12 以上。要运行通过 npm 安装的编程 Agent,还要准备 Node.js 22 LTS;终端包装器需要 tmux。
装好后直接运行 omnigent,它会帮你选择模型并启动第一个会话。本地 Web 界面默认在 http://localhost:6767。想明确选择工具,也可以运行 omnigent claude、omnigent codex 或 omnigent cursor。
自定义 Agent 用 YAML 描述。提示词、执行器、本地函数、MCP 服务和子 Agent 都能写进去,再用 omnigent run path/to/agent.yaml 启动。
它比较适合已经同时使用两种以上 AI 编程工具的开发者,也适合想把 Agent 会话共享给团队、统一加审批和成本限制的人。
如果你只在本机偶尔开一个 Codex 或 Claude Code,会觉得这一层偏重。Omnigent 还包含服务端、Runner、Web 界面、凭据和沙箱配置,理解成本明显高于单独运行一个 CLI。

另外,项目现在明确标注为 alpha。Windows 原生模式也有缺口:Web 界面和 SDK harness 可用,但 tmux 终端包装器、完整的文件与网络沙箱并不提供。正式接入前,要先把自己依赖的 harness、操作系统和权限链路跑通。
今天就先聊到这里。我们下期再见!