harness与hermes-agent的区别

01. 名称、定位与关系

名称为什么容易混淆

两个项目名都以her/har开头，目录名也都较短：

• harness
• hermes-agent

但从源码、README、构建方式和依赖看，它们没有直接同源关系。

harness的 Git remote 是：

https://github.com/harness/harness.git

hermes-agent的 Git remote 是：

https://github.com/NousResearch/hermes-agent.git

所以它们属于不同组织、不同技术栈、不同产品类别。

Harness 的项目定位

Harness Open Source 是一个开源 DevOps 平台。它覆盖软件交付链路：

• 代码托管
• Pull Request
• Webhook
• Pipeline
• Gitspaces
• Artifact Registry
• 用户、权限、审计
• CLI、REST API、Swagger

它更像 GitHub/GitLab/Gitea + CI + Artifact Registry + Gitspace 能力的综合平台。

Hermes Agent 的项目定位

Hermes Agent 是 Nous Research 的自改进 AI Agent。它的核心目标不是管理代码仓库，而是让一个 LLM 驱动的 agent 能长期运行、调用工具、记忆上下文、创建和使用技能，并通过 CLI、消息平台或编辑器协议与用户交互。

它覆盖的是 AI Agent 运行时链路：

• 多模型 provider
• 工具调用循环
• 技能系统
• 长期记忆
• 任务委派
• 浏览器/终端/文件/搜索等工具
• Telegram、Discord、Slack、WhatsApp 等消息入口
• Cron 自动化
• ACP 编辑器集成

它更像一个可部署、可扩展、可学习的个人/团队 AI 操作系统。

两者的直接关系

从当前源码分析，没有发现以下关系：

• 没有共享 module/package
• 没有互相引用的依赖
• 没有共同构建系统
• 没有同一组织所有权
• 没有共同的 API contract

因此二者的“联系”主要不是源码层面的，而是使用场景层面的。

两者可能的间接联系

它们可以在 DevOps 自动化场景中互补：

• Harness 管理代码仓库、CI、Artifact、Gitspace
• Hermes Agent 可以作为自动化助手，通过 API、CLI、浏览器或终端去操作这类平台

例如：

• Hermes Agent 读取 Harness 的构建日志并总结失败原因
• Hermes Agent 调用 Harness API 创建或查询 Pipeline
• Hermes Agent 监控 Harness 仓库 PR 状态
• Hermes Agent 根据用户消息触发 DevOps 工作流
• Hermes Agent 在 Harness 托管的代码仓库里执行修复任务

这属于“智能体操作平台”的关系，不是“同一个产品里的两个模块”。

一句话区别

Harness 是被人和团队使用的 DevOps 平台；Hermes Agent 是替人调用工具和执行任务的 AI Agent。