2026 年 8 月,Show HN 上出现一个名为 HarnessRouter 的项目,定位是"为多 Agent Harness 提供统一接口"。它的核心命题很直接:Codex、Claude Code、Hermes 这些 managed agent harness 各自的请求/响应格式互不兼容,产品方每接一个就要重写一遍驱动逻辑;于是作者提议一个叫 UHP(Unified Harness Protocol)的开放协议,让应用层只用对接一次,就能路由到所有 harness。几乎同时,UHP 官方规范站(unifiedharnessprotocol.org)发布了 2026-08-11 版本,把 Architecture、Lifecycle、Harnesses、Tasks、Streaming、Sessions、Files、Errors、Security、Schema 这十个章节都写了机器可读的 OpenAPI 3.1 + JSON Schema 定义。两个一手信源在同一周内联动,让"多 Agent harness 统一接口"这件事从社区提案升级成了可被独立实现的开放标准,标题里的"Tool Use 治理盲区"也由此从一个工程细节变成了一个标准级别的待补空白。把这两个信源放在一起读,可以落几条判断:第一,Agent 工程化的瓶颈正在从模型层下沉到 harness 层;第二,统一接口不是 LiteLLM 那条"统一模型 API"的简单复刻,因为单元从"一次对话"换成了"一个任务";第三,协议一旦开源、机器可读、自带 conformance suite,Tool Use 的治理盲区反而会暴露得更彻底——之前每个 harness 自己定义权限,现在所有 harness 共用同一份契约,治理标准也得随之收敛。

一、HarnessRouter 是什么、解决的具体痛点是什么

Show HN 原帖里,作者 songrenchu 把动机说得很诚实:在做自己的产品时,他试过 LangGraph、各家厂商的 Agent SDK、pydantic、LLM tool use/function call 这些路线,做下来的感受是"工程量非常大,出来的成果和 Codex、Claude Code 比又失望"。这个经历改变了他的思路——既然前沿实验室和知名开源社区已经在 harness 上投了大量工程精力,为什么不直接复用它们,而不是自己再造一个?这个逻辑和"调用 LLM chat completion 而不是自己训模型"是完全同构的。HarnessRouter 就是这套思路的落地物:它提供 docker 镜像,docker run 一行起一个本地实例,默认账号 harnessrouter/harnessrouter,然后在 Integrations 页面填模型供应商凭证,在 Harnesses 标签页里配置要路由到哪些 harness(目前内置 Codex、Claude Code、Hermes 三款),可以自定义每个 harness 的指令、MCP 工具和 skills,最后在 Tasks 页里让它们干活。整个产品形态非常工程化:不是又一个 IDE 插件,而是一个在你自己的基础设施上跑的"harness 总线"。但它真正想做的事不是这个本地 demo,而是它身后那套协议——UHP。作者在 Show HN 里点明:每个 harness 都有自己的请求/响应格式,彼此不兼容;UHP 的目标是"标准化应用和 agent harness 的对话方式",覆盖 harness 的选择与配置、任务执行、事件流、会话启动/取消/恢复、产物管理与交付、错误处理。它和 LiteLLM 思路相近,但对象不是模型,是 harness。

二、UHP 是什么:不是模型 API,是任务契约

UHP 官方站(unifiedharnessprotocol.org,规范版本 2026-08-11)对自己的定义是"为把完整 agent harness 作为共享基础设施运行而设计的开放标准"。它给出了一段关键的边界说明:Codex、Claude Code、Hermes 这些 harness 各自已经知道怎么干活——分歧在"产品怎么驱动它们",怎么启动一个任务、追踪进度、继续对话、取消、拿回产物、理解失败原因。UHP 的解法是把这套驱动逻辑一次性定下来。它在"应用 ↔ UHP ↔ 各种 harness"之间架一个翻译层,覆盖 skill、tool、model、context、permission、environment、session、file、artifact 这些 harness 周边的连接方式。官方用一个简图把它说清楚:你的产品 → UHP → Codex / Claude Code / Hermes / DeepSeek Harness / Gemini CLI / Pi / .../ 下一个上线的 harness。UHP 强调的关键区别是:它不是模型 API,也不替代模型 API。模型 API 给的是"一轮":消息进、token 出、工具调用你自己跑。UHP 给的是"一个任务":工作进,跑出来的是一个会自己用工具、自己保留 session、会交回结果和文件的 running agent。换句话说,UHP 交换的不是 completion,是 job。

三、UHP 的具体形态:十章规范 + 64 项 conformance

UHP 不是一个模糊的提案,它已经把规范写到机器可读的级别。当前版本是 2026-08-11,Apache-2.0 协议,定义在 HarnessRouter 公开仓库里。规范分为十个版本化章节:Architecture(角色、一致性类、对象模型)、Lifecycle(版本协商、能力发现、任务生命周期)、Harnesses(发现、选择、配置)、Tasks(发送工作和接收结果)、Streaming(跟踪进度)、Sessions(继续对话,以及取消)、Files(传文件进,拿产物出)、Errors(失败分类、重试、幂等)、Security(实施者必须做对的,集中在一处)、Schema(机器可读定义)。协议本身没有 hosted service 强制要求。它是一个 HTTP 契约——任何服务器只要按规范回答请求,就算合规服务器。harness 可以跑在容器、子进程、队列或别人家的基础设施上,协议不要求 hosted service、账号、license key 或电话回拨。一台合规服务器可以完全跑在用户自己的机器上、用用户自己的供应商 key、把所有东西存到用户自己的卷上。客户端按规范写,就能对接任何通过 conformance suite 的服务器,不管谁写的。具体怎么用,官方给了一个 quick shape:

流是 Server-Sent Events,最后一个事件携带 finished response 对象,包括 agent 产出的所有文件。要继续同一段对话,下次请求带上 previous_response_id 即可。这套语义刻意对齐 OpenAI Responses API——所有已经会讲 Responses 的产品代码,可以直接对接到 UHP 服务器,不用改 SDK、不用改流解析、不用改 UI 组件。
## 四、conformance suite 是 UHP 的真正护城河
很多开放协议停在文档页,真正落地需要每个团队自己解读。UHP 在这一点上做得很硬:它提供 64 项可运行的 conformance checks,这是"合规"的定义。官方给了一个直接可用的命令:

在开发过程中跑这套 conformance,做完后发布报告,通过某一致性类的服务器可以自描述为"UHP 2026-08-11 conformant (client)"或 "(server)"。治理方式也很规范:规范、参考实现、conformance suite 必须一起动,缺一不可;变更先以散文形式提案,没三方一起演进就不落地。这套机制是 HarnessRouter 之外最大的价值。它让"统一接口"不只是营销话术,而是一个可被独立验证、可被版本化、可被分歧留痕的具体对象。Codex、Claude Code、Hermes 各自的协议可以被卷进同一份契约,但治理是显式的、可审计的。这点对生产落地很关键。

五、Tool Use 治理盲区:为什么"统一"反而暴露问题

标题里的核心问题是 Tool Use 治理盲区。UHP 把 Security 章节单独列出来,放在十章里的固定位置,这个动作本身就是一个信号。之所以"统一"反而暴露盲区,是因为之前每个 harness 自己管权限、自己定义 scope,各家风格不同,产品方接入时只要能调通就够了——但每家的"足够"标准不一样。换到 UHP 之后,所有 harness 共用同一份契约,意味着 tool、skill、permission、environment、session、artifact 这些概念都有了规范级的定义,任何一个 harness 偏出规范都会被 conformance suite 抓到。盲区不是消失,是被显式化了。具体哪些盲区最值得注意?结合 UHP 规范和 Show HN 帖子,可以列几条:第一,tool call 的权限边界。规范要求"实施者必须做对的"集中写,但具体到"读数据库的 tool 和写数据库的 tool 在权限上如何分离",每个 harness 的实现路径不同,产品方接入 UHP 时,如果只是把 tool 注册进 harness,而不区分 read/write scope,就等于把治理盲区一次性暴露给所有 harness。第二,跨 harness 的 tool 重名。UHP 让 harness 可以共享一套 tool registry,但同一个 tool name 在 Codex、Claude Code、Hermes 里调用语义不同,产品方在 routing 时要承担这个翻译成本。如果不分版本地共用 tool 注册表,就会出现"同一个 tool 在两个 harness 里行为不一样"的诡异 bug。第三,session 跨 harness 的持续性。UHP 的 sessions 章节支持继续对话,但 session 在 harness 之间切换时,上下文如何延续、文件如何交接、产物如何归属——这些都还没有跨 harness 的统一标准。Show HN 作者提"session 启动/取消/恢复"是 UHP 覆盖的范围,但实际跨 harness 的 session 治理是工程化的深水区。第四,artifact 的责任归属。UHP 让 harness 产出的文件可以被拉回,但文件副作用由谁负责——harness、UHP server、产品方、还是 harness 跑的具体模型?协议层面只规定传输,不规定责任,这个空白迟早要靠案例库来填。第五,Skills 的版本化。HarnessRouter 允许配置每个 harness 的 skills,但 skills 的版本、依赖、冲突在协议里没有强约束。生产环境里,Skills 互相覆盖、Skill 调用了不存在的 tool,这类故障目前要靠每个 harness 自己防。

六、对企业 Agent 落地的延伸意义

把视角拉远一点看,HarnessRouter + UHP 的出现不是孤立事件。Codex、Claude Code、Hermes、Pi 等 managed harness 在 2026 年快速分化,各家都在投工程精力做"更好的 harness",但产品方每接一家都要重写一遍驱动逻辑,这件事注定不可持续。UHP 把这个重复劳动标准化,等于在 harness 层做了 LiteLLM 在模型层做过的事,只是单元换成了"任务"而不是"对话"。对企业 Agent 落地有三条延伸意义。第一,接入策略可以重写。以前接入一个 harness 要写一个 adapter,接两个 harness 要写两个 adapter,接 N 个就要写 N 个。现在可以一次接入 UHP,任何通过 conformance 的 harness 都自动可用——前提是你的应用愿意按 Responses API 写。这对企业内部的 Agent 中台是一个直接的成本下降。第二,治理标准可以集中。UHP 之前,tool、permission、skill 的治理分散在每个 harness 里,产品方要么挑一家深度绑死,要么自己写一层治理 wrapper。现在治理 wrapper 可以直接做在 UHP server 上,所有 harness 共享同一份策略。Security 章节不再是一个 harness 的事,是整个企业的事。第三,可移植性回到桌面。HarnessRouter 给出了"在你的机器上跑你的 UHP server、用你的供应商 key、存你的卷"的明确承诺,加上 Apache-2.0 协议、独立可实现的 OpenAPI/JSON Schema、conformance suite,让"换 harness"变成一个低风险动作。这对企业避免供应商绑定是一个硬支撑。但硬币的另一面同样要看清楚:统一接口意味着所有 harness 共享同一个故障面,任何一个 harness 的 tool bug 都会沿着 UHP 传染到所有产品方。规范可以约束行为,不能约束实现质量。这条规则在 LiteLLM 时代就成立,在 UHP 时代同样成立。

七、几个具体判断

综合两个一手信源,可以落几条具体判断。第一,Agent harness 的工程化进入"协议化"阶段。Show HN 上的 HarnessRouter 提案 + UHP 官方规范的发布,标志这件事从工程实践跨进了开放标准。下一步是看 Codex、Claude Code、Hermes 这些 harness 自身是否会反向遵循 UHP——这一步决定了 UHP 是社区标准还是事实标准。第二,统一接口不是 LiteLLM 的简单复刻,因为单元从"一次对话"换成了"一个任务"。这意味着对产物的责任、对 session 的持续性、对失败的处理都进入了协议视野,治理的工作量比模型层统一大一个量级。第三,Tool Use 的治理盲区在 UHP 之后会暴露得更彻底,而不是更少。之前分散在各 harness 内部的权限模型、tool 命名、session 跨 harness 的处理、artifact 归属、Skill 版本化,这些都从工程细节升级成了协议级的待补空白。这是标题点出的核心问题——盲区不会因为协议统一而消失,反而会因为统一而显式化。第四,企业落地时,接入策略可以重写,治理标准可以集中,可移植性回到桌面。这三条是 UHP 的直接价值,但前提是企业愿意按 Responses API 写应用、不深度绑死某个 harness 的私有语义。第五,conformance suite 是 UHP 真正的护城河——64 项可运行的检查,加 Apache-2.0,加版本化治理,让"统一接口"不是营销话术。这一点很值得企业 Agent 中台借鉴:做内部 Agent 平台时,把 conformance 当成"内部一致性的定义",而不是"事后补的测试"。HarnessRouter + UHP 在 2026 年 8 月留下的最重要一条经验:Agent 工程化的下一步不是再做一个更强的 harness,而是让 harness 之间的接口标准化——同时,把治理的标准一起标准化,否则盲区只会被暴露,不会被补上。这是把 Tool Use 治理盲区当成协议级问题对待的真正意义。