大数跨境

同一个模型,换个壳,成本差2.1倍,又一个Agent协议UHP来了

同一个模型,换个壳,成本差2.1倍,又一个Agent协议UHP来了 AI工程化
2026-10-17
3

MCP管工具,A2A管代理间通信,AG-UI管界面。现在又多了一个:UHP,管的是harness。

在HarnessRouter的首次对照测试中,只改变harness,同一模型跑同一任务,成本最多能差2.1倍。更便宜的组合少用了约53%的credits。

同一模型,只是换了个壳。

harness从来不是什么薄薄一层包装。Codex和Claude Code可能调用同一款模型,但它们的指令结构、工具使用方式、上下文管理、权限模型、任务完成判断逻辑都不一样。这些差异直接反映在成本和时间上。

Akshay在配套文章里把问题讲得很清楚:产品一旦直接集成某个harness,后端就绑定了它的任务格式、事件流、会话模型、文件系统行为。想加一个或换一个,不是改配置,是重写集成逻辑。因为每个harness都是一个完整运行时,它规划工作、调用工具、管理文件、判断任务何时结束。

直接集成4个harness需要处理36个集成点,5个就是45个。HarnessRouter的对比动图很直观:走UHP,始终1个。

集成对比动图:没有HarnessRouter时,4个harness需要36个集成点,5个45个;有了之后始终1个

UHP做了什么

UHP(Unified Harness Protocol)定义了一个HTTP契约,覆盖任务创建、进度追踪、会话管理、文件操作、任务取消、错误处理。API形状刻意兼容OpenAI Responses API,现有客户端可以少改很多代码。

它的工作方式不复杂:产品后端把任务和harness_id发给HarnessRouter,HarnessRouter路由到配置好的harness运行,harness通过Router流式返回进度和产物,Router再把结果交还给产品。

三个核心组件:Gateway处理Responses API、harness配置和模型密钥;Runner管理隔离的workspace,统一事件流,turn级别checkpoint;内置工具覆盖MCP服务器、浏览器、数据库、GitHub、媒体等。

这意味着agent基础设施变成完全可插拔的。换Codex为Claude Code,产品代码不动。同一任务跑多个harness对比输出。新harness出现,加进去就行。

模型路由 vs harness路由,别搞混

有个容易混淆的点。模型路由发生在推理层,选的是处理推理请求的模型,agent循环不变。harness路由选的是拥有整个任务生命周期的运行时。

在UHP里,模型由model字段选,harness由metadata.harness_id选。两者可以独立切换。

UHP官网把这点讲得很直白:模型API给你一个turn(消息进、token出,工具你得自己跑),UHP给你一个task(活丢进去,agent自己用工具、自己管会话、交出结果和文件)。交换的单位是任务,不是补全。

基准测试说了什么

HarnessRouter的benchmark页展示了8种harness×模型配置跑同一任务的结果。成本从223降到0.47 credits,端到端延迟从4m36s降到1m25s。

HarnessRouter基准测试结果:同一任务,成本差异99.8%,延迟差3.2倍

当然,最低成本和最低延迟的组合并不总是一样,按任务而定。这就是为什么"换个harness试试"应该和"换个模型试试"一样简单。

上手

Docker一条命令跑起来:

docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  harnessrouter/harnessrouter

默认账号密码都是harnessrouter,进去后连接provider API key,就能在Console里选harness跑任务。

产品要集成,在Console生成API key,然后调/v1/responses接口。切换harness就是改metadata.harness_id:

curl --fail-with-body -sS "$HARNESSROUTER_BASE_URL/v1/responses" \
  -H "Authorization: Bearer ${HARNESSROUTER_API_KEY:?}" \
  -H 'content-type: application/json' \
  -d '{
    "input": "Reply with exactly: it works.",
    "metadata": {"harness_id": "codex"},
    "model": "gpt-5.4-mini",
    "stream": false
  }'

把harness_id换成hermes,就是另一个运行时。请求体不变。

流式响应走Server-Sent Events。要延续同一会话,传previous_response_id。协议规范了13个章节,覆盖架构、生命周期、harness配置、插件、环境、记忆、任务、流式、会话、文件、错误、安全、Schema。OpenAPI 3.1 + JSON Schema 2020-12,有98项可运行的合规测试。

边界

UHP标准化任务生命周期,不标准化harness行为。每个harness的权限模型、工具使用、完成标准仍然各自为政。

有个具体问题值得注意:一个harness checkpoint的任务能不能在另一个harness里恢复?答案是"开始之前可以换,中途不行"。Codex开了头想让Claude Code接盘,得新开会话,把上下文(摘要、下步指令、文件)传过去。

HarnessRouter的会话隔离用独立OS用户和workspace,不是容器。生产环境部署需要自己评估安全模型。协议本身不要求托管服务、不要求账号、不要求license key。一个合规的服务器可以完全跑在自己的机器上,用自己的provider key,数据存在自己的卷里。

一些看法

过去一段时间,模型路由是热点,但随着模型能力趋同,以及Personal Agent的兴起,越来越多的agent如何发挥其各自优势,如何无缝的把任务分发给不同的Agent服务成了新的关注点,以Tokenbank为例,其在内部也实现了类似的智能体路由协议以达到不同智能体各司其职,互相协作的目的,甚至不简单只是本地的agent,还涉及到跨用户的协作,有了UHP的加成,这样的适配复杂度将会有所简化。

对于一个想把agent集成进产品的人来说,UHP作用很明显:怎么让产品不绑定在某个特定的运行时上。这比再看一个模型API有意义。

关注公众号回复“进群”入群讨论

【声明】内容源于网络
0
0
AI工程化
专注于AI领域(大模型、MLOPS/LLMOPS 、AI应用开发、AI infra)前沿产品技术信息和实践经验分享。
内容 670
粉丝 0
AI工程化 专注于AI领域(大模型、MLOPS/LLMOPS 、AI应用开发、AI infra)前沿产品技术信息和实践经验分享。
总阅读7.1k
粉丝0
内容670