导语
过去一年，Agent 领域的协议讨论集中在三个名字上：MCP 连接工具，A2A 连接智能体，AG-UI 连接界面。三者各管一段，却共同留下一个空白——产品如何驱动一个完整的 Agent 运行时。UHP（Unified Harness Protocol）补的正是这一层：它的交换单位不是一次模型补全，而是一个 task。
本文依据 HarnessRouter 开源仓库的协议原文（版本 2026-10-19）撰写，回答四个问题：它补的是哪一层、它真正解决什么、成本数字应当如何引用、什么情况下不该用它。
一、协议谱系：边界各不相同
| 协议 | 连接的两端 | 交换单位 | 职责边界 |
|---|---|---|---|
| MCP | 智能体 ↔ 工具与数据 | 一次工具调用 | 描述智能体能够访问或调用什么 |
| A2A | 智能体 ↔ 智能体 | 一次委派 | 描述智能体之间的协作 |
| ACP | 编辑器 ↔ 编码智能体 | 一次编码会话 | 描述编辑器与编码会话的交互 |
| AG-UI | 智能体 ↔ 前端 | 一串事件 | 描述面向用户的交互边界 |
| UHP | 产品 ↔ 完整运行时 | 一个 task | 描述任务提交、进度、产物回收与会话延续 |
一个容易混淆的细节需要先澄清：市面上存在两个同名协议。本文讨论的是 Unified Harness Protocol（HarnessRouter，Apache-2.0）；另有一家的 Universal Harness Protocol 是本地进程间通信协议，不是 HTTP 契约。引用时必须写明全称。
二、一个 task 的生命周期
| 阶段 | 客户端动作 | 服务端行为 |
|---|---|---|
| 发现能力 | 读取发现文档 | 声明协议版本与一致性等级（Core / Extended / Full） |
| 选择运行时 | 取得以 chrn_ 开头的运行时标识 | 返回基础运行时与其配置（模型、系统提示、工具限制、技能、MCP、预算） |
| 提交任务 | 发送任务请求 | 起一次执行，返回以 resp_ 开头的响应标识 |
| 跟随进度 | 接收服务端推送事件 | 按事件词表流式输出，最后一个事件携带完整结果 |
| 回收产物 | 从容器中取文件 | 文件落在会话的文件命名空间中 |
| 延续会话 | 携带上一次响应标识再次请求 | 在同一会话内保持上下文 |
| 取消或失败 | 发送取消请求 | 按失败分类返回，并支持幂等重试 |
一个值得注意的工程决策：任务接口刻意做成与 OpenAI Responses API 同形。这是兼容取舍，使既有 SDK、流解析器与界面组件无需改动即可接入。UHP 新增的是模型接口没有概念的部分——由哪个运行时执行、执行时可用哪些工具、跨任务存活的会话、以及产出的文件。
三、它真正解决什么
| 维度 | 没有统一协议 | 有统一协议 |
|---|---|---|
| 集成工作量 | 每个产品 × 每个运行时各写一套适配层，即 N×M | 只对接协议，降至 N+M |
| 更换运行时 | 修改产品代码、重新联调与回归 | 改一个运行时标识 |
| 新增运行时 | 所有下游产品各改一次 | 服务端增加一个基础运行时，客户端零改动 |
| 语义一致性 | 取消、取产物、判失败各自实现一遍 | 一次定义，多处复用 |
真正的收益在架构层面：模型可以更换而运行时不变，运行时可以更换而模型不变。缺少这层解耦，任何"哪个运行时更好"的对比都不成立，因为无法区分是模型差异还是运行时差异。
四、七类对象与一种寻址方式
协议定义了七类对象，每类对象都带有区分类型的标识前缀，使标识本身不含歧义。
| 对象 | 标识前缀 | 生命周期 |
|---|---|---|
| 运行时 | chrn_ | 直到删除 |
| 响应 | resp_ | 按服务端保留策略 |
| 会话 | hsess | 直到删除 |
| 容器 | cntr_ | 随会话 |
| 文件 | file_ | 随容器 |
| 环境 | henv_ | 直到删除，只读挂载 |
| 记忆 | hmem_ | 直到删除，跨会话存活 |
响应是原子工作单位，会话是响应的链与工作目录，容器是会话的文件命名空间，环境是只读的项目依赖快照，记忆按节点授权并向下继承。
五、成本数字：三个口径不能混用
关于这套协议，流传最广的说法是"同一任务下最贵与最便宜的配置相差 99.8%"。这个数字需要拆开看。
| 数字 | 真实含义 | 能否归因于协议 |
|---|---|---|
| 约 475 倍（99.8% 跨度） | 运行时与模型组合之间的总成本跨度 | 不能，跨度主要来自模型档位差异 |
| 25%–64% | 模型固定、仅更换运行时时的成本降幅 | 可以，这才是运行时层面的贡献 |
| 3.2 倍 | 跨配置的延迟跨度 | 只能说明配置影响显著 |
准确表述应当是：集成的收益在架构上，成本的收益在"同一模型下更换运行时"这个条件下，幅度为 25% 至 64%。把跨模型档位的 99.8% 归给协议，属于归因错误。
六、适用场景
| 读者画像 | 现实痛点 | 协议给出的解法 |
|---|---|---|
| 做智能体产品的团队 | 每接入一个运行时就要写一套适配层，取消、取产物、判失败的语义各实现一遍 | 只对接一次，更换运行时改一个标识 |
| 负责技术选型与方案评审的角色 | 想比较同一任务在不同运行时上的差异，但安装、配置、日志格式各不相同 | 同一契约下横向执行，两个变量可分开控制 |
| 把智能体能力作为后端出售的平台 | 客户要求自带模型或自带运行时，平台既不愿改架构也不愿拒绝 | 配置后的运行时是可寻址对象，客户端无需改动 |
| 评测机构与技术作者 | 想复现实测结论，却卡在环境搭建 | 仓库自带实测矩阵：23 个运行时、5 类场景，可逐行核对 |
七、边界：什么情况下不该用
| 场景 | 原因 |
|---|---|
| 只调用模型接口 | 交换单位是 task 而非补全，直接用 Responses 或 Chat 接口更直接 |
| 只需工具调用 | MCP 已经足够，多引入一层反而增加复杂度 |
| 只需智能体之间协作 | 属于 A2A 的职责范围 |
| 需要确定性工作流 | 协议不承诺确定性，运行时内部仍是概率性的智能体循环 |
| 要求生产级稳定性 | 规范状态为草案，实现普遍落后规范一个版本 |
结论
第一，UHP 填补的是运行时层的空缺，与工具层、协作层、界面层不重叠，因此不与既有协议竞争。
第二，它的价值在集成量与架构解耦，不在成本。引用成本时必须写明"固定模型、只换运行时"这个条件。
第三，现阶段适合预研、评测与架构实验。规范仍为草案，且一致性测试只验证协议一致性，不验证任务效果，因此不宜作为生产环境的稳定依赖。
参考资料
| 来源 | 用途 |
|---|---|
| HarnessRouter 仓库 protocol/README.md | 协议定位与章节结构 |
| protocol/versions/2026-10-19/architecture.md | 三个角色、一致性等级、七类对象 |
| protocol/ECOSYSTEM.md | 与 MCP、A2A、ACP、AG-UI 的边界界定 |
| docs/support-matrix.md | 运行时实测矩阵（23 个运行时、5 类场景） |
| harnessrouter.ai/benchmarks | 成本跨度的官方口径 |
文章评论