Agent 界的路由器：到底什么是 Harness 抽象层？

上两篇从实战角度测了 Omnigent 的性能，也从搭建角度讲了 Polly 怎么跑。这篇聊一个更深层的问题：Omnigent 的 Harness 抽象层到底是什么，为什么值得关注。

一个正在加速的趋势

如果你一年前问一个开发者"你用什么 Agent 写代码"，答案基本是单一的——Claude Code，或者 GitHub Copilot，或者 Cursor。很少有人说"我同时用三个"。

到了 2026 年中，情况变了。Claude Code 代码质量高但贵，Codex 便宜但上限有限，Cursor 的 IDE 集成体验好但模型能力不如 Claude，Pi 在探索型任务上灵活但不太适合深度重构——每个 Agent 各有各的擅长。

结果是，越来越多开发者开始在同一个项目里切换使用不同 Agent。但问题是——每个 Agent 有自己的 CLI、自己的权限模型、自己的上下文管理方式。你没法在 Claude Code 里跟到一半让 Codex 接手，也没法让 Cursor 审查一段 Claude 写的代码。Agent 之间的墙，比 IDE 之间的墙厚得多。

Harness = "Agent 路由器"

你可以在终端里跑 claude -p "写一个 API"，但你不能在同一个会话里跑 codex -p "审查上一段的输出"，因为两个工具互不认识。

Omnigent 的 Harness 抽象层解决的就是这个问题。它的思路非常直观：给每个 Agent 套一个标准适配器，让上层只跟适配器打交道。

这个适配器就叫 Harness。在代码层面，一个 Harness 就是一个实现了统一接口的模块，定义了：

• Agent 怎么启动（是跑一个子进程还是调 SDK 还是连 TUI）
• Agent 的输入输出怎么流转（文本流、工具调用、审批请求）
• Agent 能做什么（声明式能力矩阵——支持流式？支持子 Agent？用什么认证？）
• Agent 的策略怎么执行（预算、审批、沙箱）

24 个 Harness，按集成模式分成 5 类：

← 表格可左右滑动查看

每个 Harness 有自己的能力矩阵——这是另一个聪明设计。不是简单地"把消息转发过去"，而是声明式地告诉上层：

"我是 cursor-native，我支持流式输出吗？不支持。我支持子 Agent 吗？不支持。我支持什么审批模式？面板轮询。"

这样上层编排器（Polly 之类的）可以在运行时就知道哪些 Agent 能做什么，不用写死逻辑。

这个抽象层带来了什么

一个 Session 里混用不同 Agent。 这是最直接的能力。在 Omnigent 里，你可以从一个界面里让 Claude Code 写代码、Codex 做审查、Pi 做探索，三者之间可以互相传上下文。不用开四个终端窗口手动复制粘贴。

跨供应商交叉审查。 这是 Harness 抽象层带来的独特价值。因为每个 Agent 被包装成了统一接口，Polly 可以轻松地把 Claude Code 的输出发给 Codex 审查，反之亦然。不是同一个模型自问自答，而是真正的不同模型互相把关。

统一的策略治理。 花钱上限、Shell 命令审批、沙箱隔离——这些策略在一个地方配置，对所有 Harness 生效。你想限制 Claude Code 每次调用不超过 5 美元？一个策略文件搞定，不需要在每个工具里单独设置。

它不是什么

Harness 抽象层解决的是 Agent 之间的通信和协作问题，不是 Agent 本身的质量问题。

如果你只有一个 Agent，它帮不了你太多。Harness 不会让 Claude Code 变得更聪明，不会让 Codex 写得更好，不会解决 Agent 本身的幻觉或质量问题。它的价值只在你有两个以上 Agent 需要协作时才会体现。

这也是我们在上一期横评中数据确认的：单 Agent 的聚焦任务（Bug 修复），Omnigent 反而因为编排层开销更慢。Harness 层的价值不在单打独斗，而在团队协作。

一句话总结

Harness 抽象层不是一个让你"用得更好"的技术，而是一个让你"管得更好"的技术。当你的 Agent 工具箱里只有一个工具时，它可有可无。当你的工具箱里有三四个工具时，它就是你所有 Agent 的路由器——把不同协议、不同权限、不同能力的东西接到同一张网里，然后让它们各自做自己最擅长的事。

这个方向对不对？取决于 Agent 生态是否会继续走"各立山头"的路线。从目前 Claude、OpenAI、Cursor、Pi 各自在独立发展看，答案是肯定的——Agent 只会越来越多，管理它们的需求只会越来越强。