HarnessRouter：Agent 时代的统一执行控制平面

目录

一、企业的 Agent 问题，正在从“选哪个模型”转向“怎么稳定执行”

（一）模型 API 解决一轮生成，Harness 负责把任务做完

1. 从 Completion 到 Task，工作单位已经变了

2. Harness 不是模型的别名，而是一套行为系统

（二）多 Harness 并存为什么几乎不可避免

1. 任务异质性决定单一执行系统很难长期垄断

2. 企业真正害怕的不是多供应商，而是重复建设执行胶水

二、HarnessRouter 的核心价值：把 Agent 执行层变成可替换的基础设施

（一）一个统一入口，背后是多个完整执行系统

（二）UHP 是产品化的关键，不只是一个“兼容层”

三、UHP 究竟统一了什么

（一）统一任务生命周期，而不是只统一一个提交端点

1. 终态语义让客户端知道“下一步该做什么”

2. 并发约束是 Session 正确性的组成部分

（二）统一 Session 连续性，但不承诺跨 Harness 无损迁移

（三）统一流式事实，而不是统一前端渲染

（四）统一文件输入与产物输出，把 Agent 从聊天框里释放出来

（五）统一错误分类和重试依据，减少“猜错再试”的成本

四、统一协议最难的部分：不是字段映射，而是语义映射

（一）“最小公分母”会让统一接口失去价值

（二）工具禁用可能是硬隔离，也可能只是软约束

（三）模型替换必须可观察，否则测量全部失真

（四）Session 不是可随意搬运的字符串

五、HarnessRouter 与 MCP、模型网关、Sandbox、Tines 3B 解决的是不同问题

（一）四类基础设施位于不同切面

（二）最合理的关系不是替代，而是叠加

六、企业真正需要的是“Agent 执行控制平面”

（一）把统一接口放在控制面，而不是误当作全部运行时

1. 控制面管理意图、策略和状态

2. 数据面执行任务，并接受最小权限约束

（二）凭据应通过代理和短期授权到达工具，而不是进入 Agent 环境

（三）审批应该约束动作，而不是只审核提示词

（四）可观测性要覆盖“任务—Session—工具—文件—成本”全链路

七、统一接口带来的商业价值，主要来自可替换性与平台复用

（一）降低接入边际成本，而不是消灭所有适配成本

（二）把供应商切换从“重写产品”降为“重新验证能力”

（三）让评测对象从“模型回答”升级为“执行系统结果”

八、HarnessRouter 与 UHP 的局限：统一不等于同质，也不等于安全

（一）协议仍处于草案阶段，治理与独立实现数量很关键

（二）统一接口可能掩盖能力保证等级差异

（三）统一事件并不自动等于完整审计

（四）自托管不等于生产安全

（五）错误统一之后，业务补偿仍由上层决定

九、企业落地 HarnessRouter 的评估框架

（一）先证明统一接口能覆盖真实任务，不要只跑 Hello World

1. 选择五类具有代表性的任务

2. 把一致性套件纳入 CI，但增加企业自己的契约测试

（二）建立可量化的 Harness 评分卡

（三）分阶段建设，而不是一次性替换现有 Agent 平台

1. 第一阶段：统一可观测的只读任务

2. 第二阶段：加入文件与受控写入

3. 第三阶段：策略路由与多 Harness 评测

4. 第四阶段：高风险流程与人工审批

十、进一步思考：UHP 可能成为 Agent 时代的“执行层协议”，但前提是保持克制

（一）最有价值的标准，往往明确知道自己不负责什么

（二）Agent 平台竞争的焦点会从模型选择，转向执行质量

（三）真正的“统一插座”，插入的不是 Agent，而是组织的治理能力

可参考的文章与资料

干货分享，感谢您的阅读！

当企业同时采用 Codex、Claude Code、Hermes、Pi 或自研 Agent 时，目前最先暴露显然不是模型效果问题，是工程接口问题：如何创建任务、如何流式观察、如何续接 Session、如何上传文件、如何取消、如何识别失败、如何取回产物。

HarnessRouter 与 Unified Harness Protocol（UHP）试图把这些差异收敛为一个可版本化、可测试的协议。它值得关注，但它不是“万能 Agent 层”，更不是安全沙箱。真正成熟的企业架构，必须把执行路由、运行隔离、工具连接、凭据代理、策略审批和可观测性组合成一个完整控制面。

一、企业的 Agent 问题，正在从“选哪个模型”转向“怎么稳定执行”

（一）模型 API 解决一轮生成，Harness 负责把任务做完

1. 从 Completion 到 Task，工作单位已经变了

过去两年，围绕大模型的基础设施大多建立在“请求—响应”思维上：应用发送消息，模型返回文本或工具调用；如果要执行工具、管理文件、保存上下文、处理重试，上层应用自己完成。这个抽象对聊天、摘要和结构化抽取非常合适，因为核心工作单位是一轮生成。

但编码 Agent 和通用工作 Agent 的工作单位不是一轮生成，而是一项持续数十秒乃至数十分钟的任务。Agent 会读取仓库、建立计划、调用 Shell、修改文件、运行测试、发现错误、回退方案、再次执行，并在过程中产生大量事件和产物。UHP 对这一差异的表述非常准确：模型 API 的交换单位是 turn，而 Agent Harness 的交换单位是 job。换句话说，模型 API 给你“下一段输出”，Harness 给你“正在运行的执行过程”。

这也是为什么只做一个模型网关，并不能自然升级为 Agent 网关。模型网关擅长统一鉴权、模型名称、速率限制、Token 计费和请求重试；Agent 执行层还要处理工作目录、会话连续性、并发约束、取消语义、工具权限、文件生命周期、长连接断线和部分结果。两者都叫“统一 API”，但统一的是不同层次的问题。

2. Harness 不是模型的别名，而是一套行为系统

这里的 Harness 可以理解为包在模型外面的完整执行系统。它通常包含自主循环、系统指令、工具目录、文件操作、命令执行、会话状态、权限机制、技能或规则，以及把过程转换为用户可理解结果的输出逻辑。即使两个 Harness 使用同一个模型，它们在提示结构、工具选择、上下文压缩、错误恢复和文件操作上的行为仍可能显著不同。

因此，企业所谓“同时接入 Codex 和 Claude Code”，并不等于在请求里把model字段从 A 改成 B。它更像同时接入两个具有不同进程模型、不同状态机制和不同执行习惯的外部操作系统。真正的接口债务来自这些行为差异，而不仅是 JSON 字段命名不同。

（二）多 Harness 并存为什么几乎不可避免

1. 任务异质性决定单一执行系统很难长期垄断

代码修改、资料研究、文档生产、浏览器操作、数据分析和企业流程执行，对 Agent 的要求并不相同。有些 Harness 更擅长长程规划，有些在仓库编辑和测试闭环上更成熟，有些对本地工具和开源模型更友好，还有些来自企业内部，直接绑定私有知识、审批链和运行环境。组织会自然形成多 Harness 组合：研发团队偏好编码型 Agent，运营团队使用工作流型 Agent，安全团队保留受控自研执行器。

此外，模型和 Harness 的最佳组合也会不断变化。成本、延迟、数据驻留、许可证、区域可用性和供应商策略都会影响选择。如果上层产品把状态模型、文件系统和错误处理深度绑定某个 Harness，后续迁移不再是更换供应商，而是重写产品后端。

2. 企业真正害怕的不是多供应商，而是重复建设执行胶水

每增加一个 Harness，团队通常要重新实现至少七类胶水：任务提交、事件流、Session 续接、文件输入、产物下载、取消与超时、错误翻译。再叠加鉴权、审计和指标，适配器很容易从“几百行封装”成长为一个隐形平台。

更麻烦的是，这些胶水并非一次性成本。上游 CLI 更新参数，下游事件格式改变，Session 目录策略调整，文件引用方式变化，都会让适配器产生长期维护负担。接口不统一带来的最大损失，不是第一次接入慢，而是每个产品团队都在重复修补同一组生命周期问题，并且很难共享测试结论。

二、HarnessRouter 的核心价值：把 Agent 执行层变成可替换的基础设施

（一）一个统一入口，背后是多个完整执行系统

HarnessRouter 的基本结构并不复杂：上层应用作为 Client，只面向统一 HTTP 接口；HarnessRouter 作为 Server，负责选择并驱动具体 Harness；Codex、Claude Code、Hermes 等运行时位于其后。UHP 明确要求，Harness 如何通过容器、子进程、队列或远程 Worker 执行，不应泄露到线上协议中。

这个边界很重要。它让产品团队关注“我要提交什么任务、如何观察进度、如何取回结果”，而平台团队关注“如何安装运行时、如何调度容量、如何放置凭据、如何管理工作区”。双方通过稳定对象模型协作，而不是共同依赖某个 CLI 的输出文本。

截至本文核验时，HarnessRouter Community Edition 以 Apache-2.0 发布并支持自托管。项目文档强调可在本机 Docker 容器中运行，状态和文件保存在自有卷中，并使用自己的模型供应商密钥。需要注意的是，项目 README 的安装日志已列出 Claude Code、Codex、Hermes、Pi 和 DeepSeek Harness 等后端，而 UHP 规范中的典型示例仍主要使用 Codex、Claude Code 与 Hermes。这个差异不宜简单理解为文档错误，它更能说明后端列表变化快于协议：客户端必须依赖能力发现，而不是把支持清单写死。

（二）UHP 是产品化的关键，不只是一个“兼容层”

如果 HarnessRouter 只有一组手写 REST 接口，它仍然只是一个产品。UHP 的价值在于把接口变成了日期版本的开放规范，并提供 OpenAPI、JSON Schema 和一致性测试。当前规范版本为2026-08-11，状态是 Draft standard：已经足够用于构建，但通过显式版本协商保留演进空间。

它规定 Client、Server、Harness 三个角色，定义 Harness、Response、Session、Container、File 和 Event 等对象，并把 Server 能力分为 Core、Extended、Full 三类。更关键的是，规范强调“一致性不是自我声明”：服务器只有通过相应测试套件，才有意义地声称自己符合某个版本和等级。当前公开套件包含 52 项检查，其中还会运行真实 Agent 任务，验证流是否真正渐进、取消是否真的终止、产物是否可下载、技能文件夹是否完整往返。

这比“接口长得像”更接近基础设施标准。Agent 系统最容易出现的问题，往往不在 Schema：服务器可以返回正确字段，却在代理层把 SSE 缓冲到任务结束；取消接口可以返回 200，却没有停止后台进程；技能配置可以在 GET 时看起来正常，却在一次无关重命名后丢失引用文件。只有行为测试才能发现这些缺陷。

三、UHP 究竟统一了什么

（一）统一任务生命周期，而不是只统一一个提交端点

1. 终态语义让客户端知道“下一步该做什么”

UHP 将任务状态区分为in_progress、completed、failed、incomplete和cancelled。这组状态看似普通，实际解决了长任务中最关键的决策问题：失败、预算耗尽和用户取消不是一回事。

incomplete表示任务因为步骤或时间预算被截断，通常值得继续；failed表示执行遇到错误，盲目续跑未必有效；cancelled表示用户主动停止，不应被记成系统故障。规范还要求终态保留此前已经产生的输出，因为部分结果是诊断和恢复的唯一证据。对企业平台而言，这使重试策略、用户提示、SLO 统计和成本归因可以基于机器可读状态，而不是解析一段错误文字。

2. 并发约束是 Session 正确性的组成部分

规范要求不同 Session 可并发运行，但同一 Session 不能同时执行两个任务。原因很直接：一个 Session 同时承载对话上下文和工作目录，两个 Agent 同时写入会产生未定义状态。第二个任务应得到409 session_busy，客户端等待当前任务终止后再重试。

这条规则提示我们，Session 不是纯聊天记录，而是一个带文件状态的事务域。任何统一协议如果只同步消息而忽略工作目录，就无法保证“继续刚才的任务”真的继续了同一个世界。

（二）统一 Session 连续性，但不承诺跨 Harness 无损迁移

UHP 使用previous_response_id续接 Session。新任务必须继承相同的工作目录、对话上下文、已配置 Harness 和 Session ID；模型可以在后续任务中切换，但 Harness 不允许静默切换。如果客户端同时指定了不一致的harness_id，服务器应返回harness_mismatch。

这是一个务实且容易被忽视的设计：统一接口并不意味着可以在同一 Session 中把 Claude Code 无缝替换成 Codex。不同 Harness 对内部状态、工具痕迹、上下文压缩和检查点的表示不同，强行切换可能让客户端误以为“原工作仍被完整继承”。UHP 宁可显式拒绝，也不制造虚假的可移植性。

真正的跨 Harness 迁移应被设计为新的任务：把必要文件、结构化摘要、决策记录和验收状态打包成迁移上下文，在另一个 Harness 中创建新 Session。换句话说，协议统一的是调用和管理，状态可迁移仍需要上层应用定义交接格式。

（三）统一流式事实，而不是统一前端渲染

Agent 任务耗时较长，没有流式事件时，用户只会看到一个无法解释的转圈。UHP 采用 Server-Sent Events，并要求每个事件带有从 0 开始、严格连续的sequence_number。流必须以创建事件开始，以且仅以一个终态事件结束；服务端不得把全部事件缓冲到最后一次性发送。

这里的设计原则是“进度是事实，不是界面”。事件描述文本增量、工具调用、输出项、错误和终态，至于前端把它渲染为终端、时间线、步骤卡片还是审计日志，由客户端决定。这既避免协议绑定某种 UI，也为可观测性提供了稳定词汇。

断线也被视为正常情况。连接中断不应终止任务，客户端可重新读取 Response，或接入事件端点继续跟踪。终态事件携带完整 Response，因此中间事件丢失会影响实时体验，却不应破坏最终正确性。这种“中间增量、终态自足”的设计，适合移动网络、反向代理和长时间后台任务。

（四）统一文件输入与产物输出，把 Agent 从聊天框里释放出来

UHP 的 Extended 等级支持小文件 Data URL 内联和大文件先上传后引用。Agent 生成的文件成为 Session 容器中的 Artifact，可通过消息注解被发现，也可按 Session 列出和批量下载。文件不会只附着在最后一轮响应上，因此多轮任务较早生成的成果仍能访问。

这使“结果”不再局限于最终文本。代码仓库、报告、演示文稿、图片和测试日志都可以作为可下载对象出现。对于产品设计来说，文本回答和产物列表应当同时存在：即使客户端不理解文件注解，它仍能展示正确的文字；支持注解的客户端则可以进一步提供下载与预览。

文件能力同时扩大了安全面。规范要求下载响应设置X-Content-Type-Options: nosniff，并明确指出 Agent 生成的文件是攻击者可影响的内容。若把 HTML 产物放在与控制台相同的 Origin 下直接执行，就可能形成存储型 XSS。文件 ID 和容器 ID 组合还必须防止路径穿越。统一文件接口带来的不是“安全完成”，而是让这些风险有机会被统一测试。

（五）统一错误分类和重试依据，减少“猜错再试”的成本

UHP 区分请求失败与任务失败。请求无效时使用非 2xx 和统一错误信封；任务被成功接受但 Harness 执行失败时，HTTP 请求本身仍可成功，Response 状态为failed并携带harness_error或provider_error。这种区分让客户端知道错误发生在路由层、认证层、容量层还是执行层。

标准错误码覆盖协议版本不支持、Harness 不存在、Session 过期、Session 忙、文件过大、模型不可用和配额耗尽等情况，并给出重试建议。例如server_error可带退避重试，rate_limited应等待Retry-After，quota_exhausted不应立即重试，invalid_request_error需要先修正请求。对大规模平台而言，统一错误分类直接决定能否避免重试风暴和重复计费。

四、统一协议最难的部分：不是字段映射，而是语义映射

（一）“最小公分母”会让统一接口失去价值

任何适配层都有两种极端。第一种是只保留所有 Harness 都具备的最小能力，接口简单但能力贫瘠；第二种是把每个供应商特性都暴露成扩展字段，能力完整但上层重新耦合供应商。UHP 采用分级一致性和能力发现，试图在两者之间取平衡：Core 保证最低可用任务闭环，Extended 增加文件和 Session 检查，Full 增加 Harness 生命周期和分享。

正确的客户端不应问“UHP 支不支持文件”，而应先读取服务器能力，再决定是否显示上传入口、产物面板或 Session 列表。能力声明是一份运行时契约，不是营销清单。规范甚至明确要求：服务器不能广告自己做不到的能力，缺失能力键按false处理。

（二）工具禁用可能是硬隔离，也可能只是软约束

UHP 的 Harness 对象可以携带 MCP Server、Skills 和disabledTools。但不同运行时对逐工具禁用的执行能力不同：若底层支持，适配器应做硬阻断；若不支持，至少应把限制作为常驻指令传给 Agent，并且不能静默丢弃。

这意味着同一个字段在不同 Harness 上可能对应不同保证等级。企业若把“禁用 WebSearch”当作合规控制，不能只检查配置中是否出现该字段，还要确认底层是否支持硬执行。更合理的产品设计，是把能力拆成“请求已表达”“适配器已传递”“运行时硬阻断”“外部网络层已阻断”四个层级，并在策略页面显示最终保证，而不是显示一个模糊开关。

（三）模型替换必须可观察，否则测量全部失真

当请求的模型对所选 Harness 不可用时，UHP 允许两种行为：明确返回model_unavailable，或者切换到授权的默认模型，但必须记录请求模型、实际模型和替换原因。这个细节非常关键。如果适配层静默降级，质量评估、成本核算、A/B 测试和审计结论都会失真。

同理，Harness 的实际版本、工具集、Skill 版本和策略快照也应进入执行元数据。仅记录“任务由 codex 完成”远远不够，因为同一个 Base 在不同模型、系统指令和工具配置下就是不同的行为系统。可复现性需要记录“配置指纹”，而不仅是产品名称。

（四）Session 不是可随意搬运的字符串

统一 Session ID 容易给人一种错觉：只要所有系统都能返回 ID，就能自由迁移。实际上，Session 的真实内容可能分散在供应商远端状态、本地工作区、提示压缩摘要、工具调用历史和未提交文件中。UHP 选择把 Session 与配置 Harness 绑定，避免掩盖这种差异。

如果企业确实需要跨 Harness 接力，应建立独立于运行时的“交接包”，至少包含：任务目标、约束、已完成步骤、未决问题、关键命令与结果、文件清单、Git Diff、测试状态、风险提示和下一步建议。交接包是应用层的可移植状态，Harness Session 则是执行层的原生状态。分清两者，才能在可移植与能力完整之间保持诚实。

五、HarnessRouter 与 MCP、模型网关、Sandbox、Tines 3B 解决的是不同问题

（一）四类基础设施位于不同切面

MCP 的官方定义是连接 LLM 应用与外部数据源、工具的开放协议，核心能力包括 Resources、Prompts 和 Tools。它解决的是“Agent 的手如何接到企业系统”。UHP 解决的是“上层产品如何驱动一整个 Agent 执行系统”。二者可以组合：一个 UHP Harness 对象可以配置多个 MCP Server，让统一执行接口调用统一工具接口。

microsandbox 的定位则是微型虚拟机：每个 Sandbox 拥有自己的 Linux 内核、文件系统和网络栈，安全边界基于硬件虚拟化，而非单纯 Linux Namespace。它不关心任务是否叫 Response、Session 如何续接，却关心进程能看到什么、网络能到哪里、资源上限是多少。HarnessRouter 可以把某个任务路由给 Agent，但是否把该 Agent 放进 microVM，是另一层决策。

Tines 3B 强调连接器、透明代理注入凭据、隔离步骤、访问控制、监控和工作流治理。它关注的是 Agent 连接生产系统时，谁能获得什么能力、密钥是否暴露、关键动作是否需要审批、运行是否可审计。HarnessRouter 统一了调用入口，并不自动建立这些企业控制。

（二）最合理的关系不是替代，而是叠加

一个成熟系统可以同时使用四层：模型网关负责供应商路由和成本；HarnessRouter/UHP 负责 Agent 任务接口；Sandbox 负责 Shell 与文件执行边界；MCP 或连接器层负责工具接入；凭据代理、策略引擎和人工审批负责高风险动作。每层的控制对象不同，缺一层都可能把风险推给不擅长处理它的组件。

六、企业真正需要的是“Agent 执行控制平面”

（一）把统一接口放在控制面，而不是误当作全部运行时

1. 控制面管理意图、策略和状态

控制面接收上层业务任务，选择 Harness 和模型，加载配置，分配预算，创建 Session，记录策略快照，管理取消与重试，并把统一事件推送给客户端。HarnessRouter 与 UHP 最适合位于这一层，因为它们定义了统一对象和生命周期。

控制面还应承担能力目录：每个 Harness 支持哪些模型、是否支持文件、能否硬禁用工具、允许哪些 MCP Server、最大文件和步骤预算、数据驻留在哪里。路由不能只按“效果最好”选择，还要把权限、成本、区域、延迟和合规作为约束。

2. 数据面执行任务，并接受最小权限约束

数据面包括真正运行 Agent 的 Worker、容器或 microVM，以及模型供应商、代码仓库、浏览器和企业工具。每次任务应获得独立或最小共享的工作区、受限网络策略、资源上限和短期凭据。数据面不应自行决定长期策略，只执行控制面下发的可验证配置。

对高信任的本地开发任务，可以选择较轻隔离以换取速度；对来自外部文件、网页或用户代码的任务，应进入更强隔离，并移除生产凭据。UHP 安全章节也强调：读取不可信输入的 Harness 不应同时持有高权限工具或 MCP Server。

（二）凭据应通过代理和短期授权到达工具，而不是进入 Agent 环境

Agent 能运行 Shell，就可能读取环境变量；Agent 能读取文件，就可能找到配置中的密钥。把长期 Provider Key、数据库密码或 SaaS Token 注入 Agent 进程，是最直接也最危险的做法。UHP 建议不要把 Provider 凭据放在 Agent 工具可读的位置；若底层 Harness 必须拿到凭据，应使用单 Session、可独立撤销的短期凭据。

对企业工具，最好采用凭据代理：Agent 只拿到一个受限工具句柄或代理端点，请求经过策略校验后由代理附加真实凭据。这样可以把密钥可见性、API 可调用范围和审计集中在执行系统之外。Tines 3B 所描述的透明代理注入凭据就是这一思路的一种产品化表达。

（三）审批应该约束动作，而不是只审核提示词

Agent 风险来自行动，不只是输出文本。读取日志、查询只读数据库与停用生产账号的风险等级完全不同。企业控制面应为工具动作定义分级策略：低风险读取自动允许；中风险写入要求规则校验；高风险或不可逆动作要求人工确认；极高风险动作直接禁止。

审批事件必须进入统一审计轨迹，包括提出动作的 Agent、策略判断、审批人、时间、参数摘要和执行结果。若 Harness 原生不支持工具前置拦截，就应把高风险工具放到外部代理后，由代理实施硬门控，不能依赖系统提示中的“请先询问”。

（四）可观测性要覆盖“任务—Session—工具—文件—成本”全链路

传统 LLM Observability 关注 Prompt、Completion、Token、延迟；Agent Observability 还需要步骤数、工具调用、Shell 退出码、文件变化、Session 续接、取消时延、部分结果、模型替换和配置指纹。统一协议提供了事件词汇，但企业仍需定义指标和追踪关系。

建议每个任务至少记录：调用方、Harness 配置 ID 与版本、请求及实际模型、输入摘要、工作区标识、策略版本、开始与终止时间、终态、错误码、Token 与费用、工具调用计数、产物清单、人工审批和重试链。这样才能回答“为什么这次失败”“哪个 Harness 更适合这类任务”“成本上升来自模型还是循环变长”。

七、统一接口带来的商业价值，主要来自可替换性与平台复用

（一）降低接入边际成本，而不是消灭所有适配成本

采用统一协议后，上层产品只需实现一次任务、事件、Session、文件和错误处理。新增 Harness 的主要工作被集中到 Server 侧适配器和一致性测试中，前端和业务服务不必重复改造。对拥有多个 Agent 产品的企业，这种平台复用会显著降低长期维护成本。

但成本不会归零。每个 Harness 的安装、版本升级、许可证、模型兼容、工具限制和 Session 行为仍需要维护。统一协议把 N 个产品乘 M 个 Harness 的潜在 N×M 集成问题，收敛为 N 个客户端对协议、M 个适配器对协议；它减少连接数量，却没有消除端点两侧的真实差异。

（二）把供应商切换从“重写产品”降为“重新验证能力”

当上层只依赖 UHP Core 或明确声明的 Extended 能力，切换 Harness 时无需重写任务 UI 和生命周期管理。企业可以按任务类型做路由：仓库级代码修改进入编码 Harness，研究型任务进入长上下文 Harness，低敏内部任务进入低成本开源 Harness。

这种可替换性也能改善采购谈判和灾备。供应商短暂不可用时，平台可把新任务路由到替代 Harness；某模型价格变化时，可在不修改产品接口的前提下调整授权模型。需要强调的是，正在运行或已有状态的 Session 不应静默迁移，灾备主要适用于新任务或通过交接包恢复的任务。

（三）让评测对象从“模型回答”升级为“执行系统结果”

同一模型置于不同 Harness 中，结果可能不同。因此企业评测不应只比较模型基准，还要比较任务成功率、修复闭环率、步骤数、工具失败恢复、产物正确性、取消可靠性和单位成功任务成本。统一任务与事件格式让这些指标可横向比较。

更成熟的路由策略不是“某 Harness 总体得分最高”，而是为任务分类建立画像。例如，小范围代码修复看首次测试通过率；大型重构看多步计划完成率和回滚质量；研究报告看证据覆盖率和引用有效性；企业操作看策略命中率和人工审批通过率。路由器的价值最终体现为“为这类任务选择合适执行系统”，而不仅是把请求随机分发给多个后端。

八、HarnessRouter 与 UHP 的局限：统一不等于同质，也不等于安全

（一）协议仍处于草案阶段，治理与独立实现数量很关键

当前 UHP 已有版本、规范、机器可读 Schema 和一致性测试，这是很强的工程起点；但其状态仍为 Draft standard，参考实现与标准由同一项目生态推动。长期可信度取决于是否出现更多独立 Server 和 Client、规范变更是否透明、兼容窗口是否稳定，以及测试套件能否避免偏向参考实现。

开放标准真正成熟的标志，不只是许可证开放，而是多方能够独立实现并相互验证。企业在采用时应把 UHP 版本写入兼容矩阵，固定服务端版本，在预生产环境运行一致性套件，并为升级保留回滚路径。

（二）统一接口可能掩盖能力保证等级差异

disabledTools是最典型案例：一个 Harness 可以硬阻断，另一个只能把限制写进提示。若客户端只看同一个字段，会误以为安全保证相同。类似差异还可能出现在文件路径、终端类型、浏览器能力、网络策略、系统提示优先级、推理摘要、Skills 和 MCP 传输支持上。

因此，能力发现需要从布尔值进一步发展为保证描述。例如工具限制可标记hard_enforced、instruction_only、unsupported；文件隔离可标记process_user、container、microvm；凭据方式可标记direct_env、short_lived、brokered。这类扩展不一定都进入核心协议，但企业内部控制面必须有自己的风险模型。

（三）统一事件并不自动等于完整审计

UHP 事件流提供工具调用和文本输出等事实，但审计还需要身份、策略判断、运行环境、版本指纹和外部系统响应。不同 Harness 可能暴露不同粒度的内部步骤；有些提供推理摘要，有些完全不提供。规范也明确原始 Chain of Thought 不是必须输出的内容。

企业不应把“能够看到 Agent 的思考”作为审计前提。更可靠的审计依据是可验证行动：调用了什么工具、输入参数是否经过策略检查、修改了哪些文件、运行了哪些命令、测试是否通过、谁批准了高风险动作。审计关注因果证据，而不是要求模型暴露内部推理文本。

（四）自托管不等于生产安全

HarnessRouter Community Edition 提供快速单容器部署，适合本地体验和受控环境。项目文档中的默认配置强调本机所有权，并存在面向单机所有者的信任假设。即使项目通过进程用户隔离不同 Session，容器自身也不是与 microVM 等同的通用安全边界，更不能替代网络出口控制、密钥代理、主机加固和租户隔离设计。

若要暴露到企业网络，应至少处理：默认凭据、TLS、反向代理缓冲、身份集成、租户对象范围、工作区生命周期、产物独立域名、速率限制、文件上限、Provider Key 代理、日志脱敏、镜像与 CLI 版本固定、许可证复核和安全更新。开发环境里“一个 Docker 命令可运行”与生产环境里“可以承载不可信任务”之间，有一段完整的平台工程距离。

（五）错误统一之后，业务补偿仍由上层决定

协议可以告诉客户端任务是failed、incomplete还是cancelled，但无法替业务判断是否可安全重试。Agent 可能已发送邮件、创建工单或修改远端系统，重复执行会产生副作用。UHP 支持幂等能力声明，但具体工具动作是否幂等、补偿事务如何进行，仍取决于业务连接器。

对有副作用的任务，上层应使用业务幂等键、动作日志、执行前检查和补偿步骤。重试的最小单位不一定是整个 Agent Task，可能是尚未完成的确定性动作。把 Agent 的规划与企业工作流的执行事务分开，通常比让 Harness 自己重跑全部过程更安全。

九、企业落地 HarnessRouter 的评估框架

（一）先证明统一接口能覆盖真实任务，不要只跑 Hello World

1. 选择五类具有代表性的任务

建议 PoC 至少包括：单轮只读任务、多轮代码修改、大文件输入与多产物输出、长任务取消、故障与超时恢复。每类任务分别在两个以上 Harness 上运行，并记录成功率、事件完整性、文件一致性、终态正确性和成本。

Hello World 只能证明路由连通，不能证明统一。真正困难的测试是：SSE 在代理后是否渐进到达；取消是否停止真实进程；Session 续接是否保留未提交文件；文件名包含特殊字符时是否可取回；模型不可用时是否明确替换；MCP 服务宕机时任务是否按约定降级；同一 Session 并发请求是否被拒绝。

2. 把一致性套件纳入 CI，但增加企业自己的契约测试

UHP 公共套件覆盖 Core、Extended、Full 的标准行为，是进入生产前的最低门槛。企业还需要针对自己的安全和业务假设增加测试：双身份越权、网络出口阻断、凭据不可见、产物恶意 Content-Type、超大文件、磁盘耗尽、任务级成本上限、工具审批、日志脱敏和灾备恢复。

规范一致性回答“它是不是 UHP Server”；企业契约测试回答“它是否满足我们的运行政策”。两者不能互相替代。

（二）建立可量化的 Harness 评分卡

评分卡可分为六个维度：功能覆盖、执行质量、可靠性、安全保证、可运维性和经济性。功能覆盖看 Session、文件、取消、MCP、Skills 和工具限制；执行质量看任务成功、测试通过和产物正确；可靠性看长任务、断线恢复、超时与重试；安全看隔离、凭据和对象范围；运维看升级、日志和容量；经济性看单位成功任务成本。

不要只给每个 Harness 一个总分。更有效的是形成“任务类型 × Harness”的矩阵，并设置硬门槛。例如，涉及不可信仓库的任务必须支持 microVM 或等效隔离；涉及生产写操作的任务必须通过外部审批代理；需要大文件输出的任务必须具备 Extended 文件能力。满足硬约束之后，才用质量和成本排序。

（三）分阶段建设，而不是一次性替换现有 Agent 平台

1. 第一阶段：统一可观测的只读任务

先接入低风险任务，如代码解释、仓库摘要、资料整理。完成统一任务 API、SSE、终态、成本记录和基本 Session。此阶段的目标是验证平台抽象和运维链路，不追求自动写入生产系统。

2. 第二阶段：加入文件与受控写入

引入上传、产物下载、工作区隔离、Git Diff、测试执行和短期凭据。所有外部写操作通过受控连接器，建立幂等键和审计记录。开始运行 Extended 一致性套件与安全测试。

3. 第三阶段：策略路由与多 Harness 评测

根据任务类型、敏感级别、模型可用性、成本和历史成功率选择 Harness。建立配置版本、灰度升级和回退机制。路由策略应可解释，能说明为什么选择某个 Harness，以及是否发生模型替换。

4. 第四阶段：高风险流程与人工审批

只有在凭据代理、动作级策略、审批、补偿事务和完整审计成熟后，才逐步开放生产写操作。高风险动作保持确定性执行，Agent 负责分析和提出建议，人类或规则引擎决定是否放行。

十、进一步思考：UHP 可能成为 Agent 时代的“执行层协议”，但前提是保持克制

（一）最有价值的标准，往往明确知道自己不负责什么

UHP 不定义 Harness 内部循环，不要求某种容器，不规定模型供应商，也没有声称消除 Prompt Injection。这种克制反而是优势：协议把注意力放在客户端确实需要的可观察行为上，并把安全隔离、运行实现和供应商细节留给专门层次。

未来它最值得扩展的方向，不是不断吸收所有 Agent 特性，而是完善可移植的能力描述、配置指纹、事件语义和行为测试。过度追求“每个供应商特性都能从统一接口访问”，会让协议成为最大供应商 API 的并集，最终失去稳定性。

（二）Agent 平台竞争的焦点会从模型选择，转向执行质量

随着模型能力接近，企业差异化将更多来自执行系统：能否在真实仓库里稳定完成任务，能否在失败时保留证据，能否安全连接工具，能否控制成本，能否让人类在关键节点接管。HarnessRouter 把多个执行系统放到同一入口后，反而会让这些差异更容易被测量。

统一接口不是把差异抹平，而是让差异从“集成事故”变成“可管理选项”。一个成熟路由器应当承认某个 Harness 缺少硬工具阻断、另一个不支持文件预览、第三个适合低成本批处理，然后在策略约束内做选择。

（三）真正的“统一插座”，插入的不是 Agent，而是组织的治理能力

从产品视角看，HarnessRouter 是给不同 Agent Harness 的统一插座；从企业架构视角看，它更像执行控制面的南向接口。北向连接业务产品，南向连接不同 Harness，横向连接 Sandbox、MCP、凭据代理、策略引擎和可观测系统。

只有这些组件组合起来，企业才能同时获得三种能力：可替换——不让产品永久绑定单一 Harness；可控制——不让 Agent 因统一入口获得无限权限；可证明——能够重建每个任务为何被路由、做了什么、产生了什么结果。

因此，对 HarnessRouter 最准确的评价不是“它统一了所有 Agent”，而是：它把 Agent 执行层中一组长期被重复实现的生命周期问题，提升为公开、版本化、可测试的协议问题。这一步很重要，但它只是控制平面的起点。

可参考的文章与资料

1. HarnessRouter Community Edition GitHub 仓库——项目定位、自托管方式、后端安装、UHP 实现与运行说明。

2. Unified Harness Protocol：What is UHP?——协议定位、当前版本、覆盖范围与开放实现说明。

3. UHP Architecture——角色、对象模型、Core/Extended/Full 一致性等级与传输约束。

4. UHP Lifecycle——版本协商、能力发现、任务与 Session 状态机、并发规则。

5. UHP Tasks——任务请求、Harness 选择、模型替换、预算与 Response 对象。

6. UHP Streaming——SSE 事件词汇、顺序保证、终态与断线恢复。

7. UHP Sessions——Session 续接、取消、分享和删除语义。

8. UHP Files——文件上传、Artifact 引用、下载、预览、安全响应头与生命周期。

9. UHP Errors——错误信封、标准错误码和重试建议。

10. UHP Security Considerations——凭据、对象范围、恶意产物、Prompt Injection、资源与数据处理要求。

11. UHP Conformance Suite——52 项行为检查及 Core、Extended、Full 的验证范围。

12. Model Context Protocol Specification——MCP 的工具、资源、提示和安全原则，用于理解其与 UHP 的边界。

13. microsandbox：Sandboxes Overview——基于 microVM 的执行隔离、文件系统、网络和资源配置。

14. Tines 3B——连接器、透明凭据代理、隔离执行、访问控制与企业工作流治理。

15. Product Hunt：HarnessRouter——产品发布页与早期用户反馈。