Omnigent 实战横评：当 Agent 多到管不过来

---

为什么需要"管理 Agent 的 Agent"？

如果你只用一个 Agent 写代码，这个问题跟你无关。但如果你桌面上同时开着 Claude Code、Cursor、Codex，甚至偶尔切到 Pi 或者 Hermes——你会发现一个尴尬的事实：每个 Agent 各管各的，它们的上下文、工具、策略互不相通。

你想让 Claude Code 写一段代码，然后让 Codex 审查一下？做不到。想让 Cursor 接手 Claude 做到一半的工作？得手动复制上下文。

T3MPST 解决了 Agent 安全执行的问题——沙箱隔离、受控环境。但 Agent 多起来以后，下一个问题自然浮现：谁来管这些 Agent 之间的协作？

Omnigent（GitHub 7.2k ⭐，Apache 2.0）给了一个答案：一个开源的 meta-harness——用大白话说，就是「所有 Agent 的统一操作台」。

Omnigent 不是什么"又一个 Agent"

这是第一个需要澄清的误解。

项目 README 的第一句话就说明白了：Omnigent is an open-source meta-harness for all your AI agents。它不是又一个帮你写代码的 Agent，而是管理 Agent 的 Agent。

它的架构有三层：

┌─────────────────────────────────────┐
│  策略层 (Policies)                    │  ← 审批/预算/沙箱/审计
├─────────────────────────────────────┤
│  编排层 (Orchestration)              │  ← 多Agent协作/子Agent/交叉审查
├─────────────────────────────────────┤
│  Harness 抽象层                       │  ← Agent 适配器
└──────┬──────┬──────┬──────┬──────┬───┘
       ↓      ↓      ↓      ↓      ↓
   Claude  Codex  Cursor  Hermes   Pi

最底层是 Harness 抽象层——这是 Omnigent 的核心设计。每个 Agent（Claude Code、Codex、Cursor、Hermes、Pi 等）都被包装成一个标准接口的「Harness」，上层不需要知道底层跑的是哪个 Agent。代码库里注册了 24 个 Harness，分了 5 种集成模式：

← 表格可左右滑动查看

每个 Harness 都有自己的能力矩阵——它不是简单地"把命令转发过去"，而是声明式地描述这个 Agent 能做什么：支持流式输出吗？支持子 Agent 吗？用什么方式获取用户审批？用什么认证方式？

这套设计带来的能力是：你可以在同一个 Session 里混合使用不同 Agent。Claude Code 写代码 → Codex 做审查，各自用自己最擅长的模型，全程在一个界面里完成。

实战横评：我们用数据说话

为了验证 Omnigent 在实际开发场景中的表现，我们设计了 3 组测试任务，分别在 Claude Code 原生和 Omnigent（claude-sdk harness） 两种模式下执行，记录耗时、代码质量和测试通过率。

测试环境：M5 MacBook Pro，Claude Code 2.1.207，Omnigent 0.5.1。每个任务让 Agent 独立完成从编码到测试的全流程，人工不介入中间步骤。

T1：FastAPI CRUD 脚手架

创建一个任务管理 API，包含 SQLAlchemy 模型、完整的 CRUD 端点（含分页和筛选）、Pydantic v2 校验、Alembic 迁移、27 个单元测试。

← 表格可左右滑动查看

Omnigent 快了将近一倍。而且过程中它自动处理了三个原生模式没遇到的真实问题：pytest-asyncio 依赖缺失（自行安装）、SQLite 内存数据库的连接隔离（自动切到 StaticPool）、以及目录中残留的旧文件冲突（自动清理并重写）。这些虽然是小问题，但体现了编排层在复杂场景下的容错能力。

T2：Bug 修复 + 区间合并重构

给定一个有 Bug 的 merge_intervals 函数，需定位所有问题并重构为泛型实现，包含完整的边界测试。

← 表格可左右滑动查看

这是一个聚焦型任务——单文件、单功能。在这种场景下，原生表现明显更好。Omnigent 的编排层启动和连接耗时成了负担。不过它依然发现了原生版本没注意到的一个问题：pyproject.toml 里的 build backend 拼写错误。

T3：缓存层设计与实现

从零实现一个通用的 Python 缓存库，支持内存和磁盘两种存储、TTL 过期、装饰器语法、线程安全、访问统计和日志。

← 表格可左右滑动查看

又是一个设计型任务——多文件、跨模块的架构设计。Omnigent 的效率优势再次显现。

什么场景用什么工具

三组测试给出了一个清晰的结论：

任务类型              优势方             差距
──────────────────────────────────────────────
脚手架/新项目 (T1)    Omnigent         快 55%
Bug修复/聚焦 (T2)     Claude Code 原生  快 144%
架构设计 (T3)         Omnigent         快 69%

• 当任务涉及多文件、跨模块、需要从零搭架子时（T1、T3），Omnigent 的编排能力显著提升了开发效率——它不需要每次从头决策项目结构，而是从一开始就有一个清晰的编排框架。
• 当任务专注于单文件、已知问题、需要深入理解已有代码时（T2），原生工具更快——编排层此时变成了开销，而不是助力。
• 两种方式的输出质量没有本质差异——所有测试全部通过。Omnigent 不会让你的代码更好，但能让你在大型项目上花更少的时间。

编排的下一步：Polly 和多 Agent 协作

Omnigent 的真正潜力不在于单 Agent 编排，而在于多 Agent 的跨厂商协作。项目自带的 Polly 示例展示了这个能力：

Polly 是一个「纯编排 Agent」——她自己不写一行代码。她的工作是：分解任务 → 通过 sys_session_send 并行分派给多个子 Agent → 每个子 Agent 在独立的 git worktree 里执行 → 异步收件箱唤醒 → 跨供应商交叉审查（Claude Code 写的代码由 Codex 审查）。

这种模式的价值在于：

• 供应商多样性——不同模型擅长不同事情，让 Claude 写代码、Codex 做审查、Pi 做探索
• 并行工作流——多个子 Agent 可以同时干活
• 交叉验证——让不同供应商互审，降低错误率
• 策略治理——预算上限、Shell 审批、工具调用限制——这些在平台层面统一执行

这不是 Hermes Agent 的 delegate_task 能做的事情。delegate_task 是同一框架内的单供应商任务委派，而 Omnigent 是多供应商、平台级别的编排。

与 T3MP3ST 的对比：Agent 基础设施的两个拼图

我们上一期拆解了 T3MP3ST——一个用 AI 做安全测试的项目。它的核心价值是沙箱隔离：让 Agent 在受控环境里执行不受信任的代码。

Omnigent 和 T3MP3ST 解决的是 Agent 基础设施的不同层面：

← 表格可左右滑动查看

T3MP3ST 回答的是「Agent 跑起来怎么管住它」，Omnigent 回答的是「Agent 多起来怎么管好它」。两者拼在一起，才是完整的 Agent 基础设施拼图。

结论

Omnigent 解决了一个真实存在且越来越严重的问题：Agent 碎片化。它不是银弹——在聚焦型任务上原生工具更快——但如果你同时使用多个 Agent，或者在一个复杂项目上需要反复切换工具，Omnigent 带来的效率提升是实打实的。

值得留意的点是它的发展方向：从 Harness 抽象层到 Polly 多 Agent 编排，Omnigent 正在把自己定位成「Agent 界的 Kubernetes」——不是又一个 Agent，而是管理 Agent 的 Agent。这个方向是否正确，取决于 Agent 生态是否会继续碎片化。从目前的趋势看，答案是肯定的。

适合谁：

• 同时使用多个 Agent 的开发者
• 需要团队协作共享 Session 的小团队
• 对 Agent 消耗（预算、调用次数）有管理需求的用户

不太适合：

• 只用 Claude Code 一个工具的开发者
• 以 Bug 修复和单文件修改为主的日常工作流

安装很简单：curl -fsSL https://raw.githubusercontent.com/omnigent-ai/omnigent/main/scripts/install_oss.sh | sh，或者 brew install omnigent-ai/tap/omnigent。装完跑 omni 就能体验。

本文基于 Omnigent 0.5.1 版本实测。实测数据来自 M5 MacBook Pro，Claude Code 2.1.207。所有测试代码和原始数据可查。