HarnessRouter/harnessrouter

如果你正把 agent 能力嵌进产品，又不想把后端绑死在某一家的 coding harness 上，这个项目值得花半天评估。只在自己电脑上跑单一 harness 的人，收益有限。

解决什么问题

假设产品后端想提供一个 agent 功能——生成幻灯片、分析数据文件——并直接复用现成的 agent 循环，而不是自己写一套。常见做法是选定 DeepSeek Harness、Hermes、PI、Codex 或 Claude Code，再把它的会话、流式输出、文件处理、取消和报错逐一对接到代码里。等换 harness 或对方接口变化，这些活又要重做一遍。HarnessRouter 在这些 harness CLI 前面放一个自托管服务，对外提供兼容 OpenAI Responses 的端点，用 metadata.harness_id 选择后端，会话、流式、文件和取消都收敛成一套形状。Console 里的设置向导会根据一句话描述写指令、挑 harness、模型、技能和工具，并留好一条示例请求。

有什么不同

机制是路由加一份开放规范。项目称自己实现了 Unified Harness Protocol（UHP）：跨 harness 可移植的任务接口、让每个实现声明自己不支持什么的能力发现、描述 harness 差异的配置，以及 metadata 之类的扩展字段。落到工程上，产品代码只对一套 API 说话，底下用哪个 harness 变成配置项。Console 还提供工作区级的插件、技能、MCP server 和环境挂载点，项目也附了 starter kit 演示 harness 作为可插拔后端。

设计上自带一个限制：README 明确说 setup 保存后 harness 就固定了，换 harness 得新建 setup。协议层也意味着产品要接受它的词汇和功能边界，统一的代价是 harness 特有行为必须塞进能力声明和配置层，而不能直接透传。项目的对比图号称在同一任务上不同 harness/模型组合的成本和延迟差异很大，同时也注明最便宜、最快的配置因任务而异——这是作者的示意，不是服务承诺。在 Hacker News 讨论里，联合创始人 Kuanze 把目标描述为让 harness 即插即用、省去重建基础设施，之后同一账号又提到故障切换和上下文交接的用法；这是项目方陈述的方向，不是独立验证。

谁值得试

适合已经在跑不止一个 harness、或预计会切换的后端团队，并且希望自己掌控 provider 密钥和基础设施，而不是用托管的 agent 平台。想在自己任务上横向比较 harness 与模型组合、又不想为每个后端重写集成的团队也合适。不太适合：只想在本机跑 Codex 的独立开发者，或者需要把某个 harness 的精确行为原样暴露出去的人——setup 固定 harness 加上协议层会增加距离感。如果只需要程序化调用模型、不需要 agent 会话，直接用 provider API 是更小的工具。

使用条件与边界

需要 Docker、约 4 GB 磁盘和自备的 provider API key；没有账号、不附带模型或试用密钥。harness CLI 在首次启动时安装，仍受各自上游许可证约束，所以要看清楚镜像装了哪些，以及它们的条款是否适合你的产品。默认登录名和密码都是 harnessrouter，README 要求在 Profile 里改掉，改之前让实例保持本地访问——保存会让 Console 短暂重启并登出其他浏览器。

长期维护才是主要成本。命名卷保存数据库、文件、已安装的 harness CLI 和工作区；单纯 pull 新镜像不会升级正在运行的容器，相关流程写在升级与备份指南里。provider 密钥、harness CLI 变动，以及改配置后的重启，都要预留时间。

HotRepo 点评

HotRepo 只在 2026-10-26 记录到 3,663 stars、当天 +95，且只有这一天，趋势能否持续暂时无法判断。HN 帖有 10 分、14 条评论，只能说明讨论量。采纳前先看项目的协议与一致性测试材料，确认 UHP 层实际声明了哪些 harness 能力，这决定了你能保留多少 harness 特有行为。