2026 年 6 月 11 日,一个名为 omnigent-ai/omnigent 的 GitHub 仓库悄悄上线。21 天后,它已经积累了 5977 颗星、758 次 fork,GitHub issues 数量也一路冲到 401 条,成为 6 月全站涨星最快的 AI 项目之一。
这个项目在做的事情,被它自己称为”meta-harness”——一个位于 Claude Code、Codex、Cursor、Pi 等多个 AI 编码 agent 之上的统一调度层。它的目标只有一句话:“swap or combine harnesses without rewriting”(在不重写的前提下,替换或组合多个 harness)。
如果把它放到更大的版图里看,这可能是 AI 编码 agent 生态从”各自为战”走向”统一编排”的标志性事件。
一、为什么需要 Meta-Harness
在解释 omnigent 之前,先要说清楚一个困扰所有 AI 编码 agent 用户的问题:被锁定。
过去半年,Claude Code、Codex、Cursor、Pi、Devin、Cline 等十几款 agent 各自占据了一个生态位——有的擅长长程重构、有的擅长单元测试、有的擅长前端生成。但用户一旦选定一个,就基本被它的 UI、它的 prompt 设计、它的 tool calling 协议、它的 sandbox 模型绑死。想换一个试试?对不起,你的工作流、你的 skill、你的 policies 全部要重写。
omnigent 想做的,正是这个层级的”统一调度”——把不同 harness 包装成可替换的”模块”,在它们之上加一层 policy/sandbox/shared history/orchestration。换句话说,Claude Code 是 GPU、Codex 是另一个 GPU、Cursor 是第三个,omnigent 想做它们共同的主板。
举几个具体的”被锁定”场景:你用 Claude Code 写了三个月的 workflow,prompt 调得很顺,skills 也装了一堆。结果发现 Codex 在长程重构上更稳定,但你不想从头学 Codex 的 prompt 语法。第二个场景:公司付费买了 Cursor 团队版,但某个新员工习惯用 Claude Code,你想让两个 agent 协作审同一个 PR。第三个场景:你做了个 YOLO mode 的 agent 让它放手跑,但发现它会 rm -rf 整个磁盘——你想给所有 agent 统一加一个”危险命令”沙箱。
这三个场景的共同点是:你想要的不是某个 agent,而是 agent 之上的能力。omnigent 正是把这种”能力”从某个具体 agent 里抽离出来,放到 meta-harness 这层。
💡 当 GPU 不再被特定主板绑定,生态才会真正爆发——AI 编码 agent 也一样。
二、omnigent 的三层架构
omnigent 的官方文档把它的架构画成了三层:Runner / Server / Session。
Runner 层:统一封装
Runner 是 omnigent 的最底层,它做的事情是把任意 agent 包装成一个”sandboxed uniform session”。也就是说,不管你用 Claude Code 还是 Codex 还是你自己写的 agent,经过 Runner 包装之后,它们对外暴露的接口是一样的。
这层抽象的关键收益是——上层的 policy、UI、history、logging 都不用关心底层 agent 是谁。换 harness 只需要改一行配置。
Server 层:统一调度
Server 在 Runner 之上,负责三件事:
- Contextual Policies(上下文感知的策略)
- Shared History(跨 session 的历史)
- Multi-device Exposure(跨终端暴露)
具体来说,Server 把所有 session 通过 terminal、web、原生 app、移动端、REST API 暴露出去,你可以在 Mac 上发起任务,在手机上查看进度,在平板上审批 policy。这是 omnigent 最具产品力的部分——它不只是框架,是一个完整的”agent 操作系统”。
Session 层:业务运行时
Session 是用户实际工作的最小单元。每次启动 omni 命令,你就创建一个 Session;Session 之间共享 Server 上的 history 和 policy,但彼此隔离,不会互相污染。
整个三层架构的精髓是:底层 agent 可替换、中层策略可继承、上层 session 可组合。
三、Contextual Policies:这是 omnigent 真正厉害的点
如果只看架构,omnigent 跟 Kubernetes 很像。但 omnigent 真正差异化的地方,是它的 Contextual Policies(上下文感知策略)。
大多数 agent 框架的策略是静态的——允许某个工具、禁止某个 API、限制某个文件路径。但 omnigent 的策略是有状态的、动态的。每一个 policy 都维护自己的 session state,根据已经发生的事做决策。
官方文档举了四个典型例子,每一个都很值得展开:
1. 成本预算(Cost Budgets)
> Track cumulative LLM spend across every turn. Warn at $3, block expensive models at $5.
追踪整个 session 的累计 LLM 花费,达到 $3 警告,达到 $5 阻止使用贵模型。policy 自己记得你花了多少钱——这是静态规则完全做不到的。
2. 速率限制(Rate Limiting)
> Count tool calls over time and deny after a threshold. The count persists across the session, not per-request.
跨 session 累计工具调用次数,达到阈值后阻止。这直接解决了 agent “陷入死循环疯狂调 API” 的经典问题——传统 rate limit 是 per-request,但 agent 一个 session 跑几千次调用太常见。
3. 风险评分(Risk Scoring)
> Accumulate a risk score from sensitive operations (accessing credentials, modifying production data). Escalate to human approval once the score crosses a threshold.
每一次访问凭证、修改生产数据都累积风险分,达到阈值后自动要求人工审批。这相当于给 agent 装了一个”安全阀”——前面所有操作都允许,但越接近敏感区域,人介入的概率越高。
4. 模型路由(Model Routing)
> Classify tasks as trivial or complex and redirect trivial ones away from expensive models, based on conversation context.
根据对话上下文判断任务是”琐碎”还是”复杂”,琐碎任务自动路由到便宜模型。这是成本优化的杀手锏——一个 session 里 80% 的子任务其实是琐碎的(改个 typo、跑个测试),把它们路由到 GPT-4.1-mini 而不是 Claude Opus,单 session 成本能降 70%。
💡 真正的成本优化不是选更便宜的模型,而是让贵的模型只在值得贵的时刻出手。
除了这四种内置 policy,用户还可以写自定义 policy——直接在 Python 里实现 allow / ask / deny 逻辑,然后通过 server config 注册到 omnigent 实例。这意味着每个公司都可以写自己的”风控规则集”,而且这些规则对所有 harness 同时生效——不需要给 Claude Code 写一套、给 Codex 写一套。
💡 Contextual Policy 把”安全规则”从静态黑名单升级成了”基于上下文的智能门卫”。
每个 policy 的返回值只有三种:ALLOW(允许)、ASK(询问)、DENY(阻止)。policy 按声明顺序求值,第一个返回 decision 的胜出,无意见(None)传给下一个。
更精细的设计是三层 scope:
| 层级 | 设置者 | 作用范围 | 优先级 |
|---|---|---|---|
| Session | 最终用户 | 当前 session | 第一 |
| Omnigent config | 开发者 | 用该 config 的所有 session | 第二 |
| Server-wide | 管理员 | 服务器上所有 session | 最后 |
这种分层意味着:管理员可以设公司级成本上限、开发者可以限制 agent 写哪个 repo、终端用户可以加额外的审批 gate——三层同时生效,互不冲突。
四、Polly 和 Debby:开箱即用的多 Agent 编排器
omnigent 不只是个抽象框架,它内置了两个开箱即用的多 agent 编排器:Polly 和 Debby。
Polly:多 Agent 编码编排器
Polly 把一个编码任务拆成多个 sub-task,delegate 给 Claude Code、Codex、Pi 在各自的 git worktree 里并行执行,然后强制跨 vendor 评审(cross-vendor review)——Claude 写的代码由 Codex 评审、Codex 写的代码由 Pi 评审。
这其实是 LLM-as-judge 的工程化实现,但 omnigent 把”评审”这件事从单 agent 升级成了”不同 vendor 的 agent 互相评审”,大幅降低了单家模型的盲区。多 vendor 互相挑刺,代码质量比单一 agent 高一个量级。
Debby:多模型辩论伙伴
Debby 把每一个问题同时发给 Claude 和 GPT,内置一个 /debate skill 支持多轮 critique。这相当于把”AI 辩论赛”做成了产品——你问一个问题,Claude 给一个答案,GPT 给一个答案,然后两个模型互相反驳 3 轮,最后给出一个合并的最佳答案。
Polly 和 Debby 都是 YAML 配置——用户可以用 YAML 写自己的多 agent orchestrator,把 agent 编排从代码级别降到了配置级别。这意味着产品经理甚至可以”调”agent 的行为,而不需要工程师改 Python。
| 维度 | Polly | Debby |
|---|---|---|
| 定位 | 编码任务编排器 | 多模型辩论伙伴 |
| 输入 | 一个编码任务 | 一个问题 |
| 编排方式 | 拆 sub-task + 多 vendor 并行 | 同时发两个模型 + 多轮 critique |
| 协作机制 | 跨 vendor 评审 | /debate skill 多轮反驳 |
| 典型场景 | 长程重构 / 多文件改动 | 决策类问题 / 方案对比 |
| 调用方式 | omni(Polly 是默认 agent) |
omni examples/debby/ |
值得注意的是,Polly 和 Debby 都可以被用户复制修改——它们是开源 YAML 而不是闭源代码,这让”自定义编排器”从”写 Python”降级到”改 YAML”,门槛大幅降低。
💡 当 agent 编排从代码变成 YAML,产品经理也成了 agent 的”开发者”。
更进一步看,omnigent 把”多 agent 协作”这件事标准化成了一个协议层——任何 agent 只要遵循这个协议,就可以被编排进任何 orchestrator 里。这跟容器时代的 OCI 镜像标准很像:有了标准,生态才有可能爆发。
五、国内对标观察:为什么还没人做这件事
聊完 omnigent,自然要问一个国内视角的问题——国内大厂为什么还没有类似的 meta-harness?
先把国内现状摆出来:
| 项目 | 形态 | 跨 harness 编排 | Contextual Policies | 多 vendor 互审 |
|---|---|---|---|---|
| omnigent | 开源 meta-harness | ✅ | ✅ | ✅ |
| 字节 Trae | 单 harness IDE | ❌ | ❌ | ❌ |
| 阿里 通义灵码 | 单 harness IDE | ❌ | ❌ | ❌ |
| 百度 Comate | 单 harness IDE | ❌ | ❌ | ❌ |
| 华为 CodeArts | 企业级 DevOps | ❌ | 部分 | ❌ |
| 深度求索 DeepSeek-Coder(API) | 纯模型 | ❌ | ❌ | ❌ |
可以看到,国内目前还停留在”做更好的单 harness”阶段,没有人在做”跨 harness 调度”。
为什么?三个原因:
第一,生态基础不同。国外的 AI 编码 agent 已经进入”百花齐放”阶段——Claude Code、Codex、Cursor、Pi 各有强项,用户开始想”能不能组合用”。国内主流还是”通义灵码 vs Comate”的二选一心态,没有跨 harness 的实际需求。
第二,商业模式不同。omnigent 是开源 + 商业版 SaaS 的双轨模式,这在国内目前不是主流。国内大厂更倾向于”自己造闭环”,不愿意把控制权交给第三方开源框架。
第三,合规要求不同。Contextual Policies 里的 cost budget、risk scoring、credential brokering,在国内都需要对接审计系统,不是单纯的工程问题。
但窗口期不会太长。当国内 AI 编码 agent 市场开始分化(字节 Trae 出企业版、阿里通义灵码支持自训练模型、华为 CodeArts 接 DeepSeek),跨 harness 的需求就会出现——届时,谁能先做出 omnigent 的国内对标,谁就能占据”AI 编码 agent 编排层”的入口。
另一个值得关注的信号是 国内”智能体互通”行业标准。信通院等机构在过去一年一直在推动 Agent 之间的互联互通标准,目标是让不同厂商的 agent 可以互相发现、互相调用、互相审计。这个方向如果推进下去,国内的 meta-harness 框架反而可能比国外更早落地——因为政策驱动 + 合规要求的双重推动,会催生”国家级 agent 编排层”的需求。
从产品形态上看,国内对标可能会跟 omnigent 走差异化路线:omnigent 是”开源 + SaaS”模式,国内对标可能直接是”云厂商 + 信通院 + 大模型厂商”的联盟模式。这不一定输给纯开源路径——它解决的不是”开发者愿不愿意用”,而是”企业愿不愿意上”。
💡 AI 编码 agent 的下半场,不是谁的单 harness 更强,而是谁的编排层更稳。
六、行业意义:Agent 生态正在从”工具时代”走向”操作系统时代”
把 omnigent、上一篇文章里讲的 Skill 市场、还有 orca/herdr 这种 agent multiplexer 放在一起看,你会看到一条越来越清晰的演化路径:
- 2024 年之前:Agent = LLM + Prompt + Tool。是”工具时代”。
- 2025 年:出现成熟的单 harness(Claude Code、Codex、Cursor)。是”应用时代”。
- 2026 年上半年:Skill 市场爆发、meta-harness 出现、agent multiplexer 兴起。是”操作系统时代”。
操作系统时代的标志是:生态的中间层开始丰富。中间层包括 Skill 市场(内容层)、Harness 框架(调度层)、Multiplexer(交互层)、Sandbox(安全层)、Policy(治理层)。这些中间层把上层应用和底层 LLM 解耦,让生态可以并行演化。
omnigent 在这条路径上的位置,是”调度层 + 治理层 + 安全层”的三合一。它不是要取代 Claude Code,而是要让 Claude Code 成为可被编排的”模块”。这种思路如果被广泛接受,未来 AI 编码 agent 的竞争,会从”哪个单 harness 更好”转向”哪个 meta-harness 的生态更厚”。
写在最后
回到开头那个问题——omnigent 是不是 AI 编码 agent 的”Kubernetes”?
现在下结论还太早。它的 stars 增长虽然猛,但 401 个 open issue 也说明了 alpha 阶段的不稳定性。Contextual Policies 的实际效果还需要更多企业用户验证。Polly/Debby 这种内置编排器的鲁棒性也有待打磨。
但方向是对的。当一个生态出现”调度需求”的时候,就意味着它已经从”探索期”进入了”成熟期”。AI 编码 agent 生态在 2026 年 6 月这个时间点,刚好走到这个临界点。
对于国内大厂来说,omnigent 是一个值得认真研究的”压力测试”——它验证了一件事:用户愿意为”跨 harness 编排”付费。这个信号如果被忽视,可能会在 12 个月后变成”为什么是 omnigent 而不是我们”的复盘。
从更大的行业视角看,omnigent 验证了三个趋势:第一,AI 编码 agent 已经从”工具”变成”基础设施”,需要编排层;第二,跨 harness 互操作是真实需求,不是空想;第三,开源 + alpha 状态也能快速积累社区信任——5977 stars 21 天涨起来,意味着开发者愿意为”未来可能性”投票。
💡 社区愿意为一个 alpha 项目投 6000 颗星,不是因为它现在有多强,而是因为它指向的方向有多对。
如果你是开发者,你会把 omnigent 用在哪个工作流里?如果是产品经理,你觉得国内的 meta-harness 应该先做哪个垂直场景?(评论区聊聊)
💡 AI 编码 agent 的未来,不是更强的模型,而是更聪明的组合方式。
💡 当生态开始需要”调度层”,就意味着它已经长大了——AI 编码 agent 也是。
💡 真正改变行业的,从来不是更快的工具,而是更好的工具组合方式。
我要评论