Hermes Agent 与 Goose 对比：桌面 CLI 还是服务器运行时？

两个名字响亮的代理，瞄准的却是不同的机器

如果你在搜索框里键入"hermes agent vs goose"，你正在比较 2026 年最受关注的两个开源 AI 代理，但它们瞄准的是完全不同的机器。Goose 是 Block 用 Rust 写成、以 Apache 2.0 许可发布的桌面与 CLI 代理，GitHub 星标已超过 44,000，如今归 Linux 基金会下的 Agentic AI Foundation 治理。Hermes Agent 是 Nous Research 用 Python 写成、以 MIT 许可发布的服务器运行时，发布不到四个月即突破 175,000 星（2026 年 2 月首发）。一个是由可移植 YAML 配方驱动的精致桌面助手；另一个是常驻在线、以消息为先、带持久记忆的守护进程。

这一区分几乎决定了下游的一切：你如何安装、它住在哪台机器上、它如何记住你、你如何扩展它，以及哪些读者会在 Google 上点"返回"。本文梳理两者到底是什么、它们之间诚实的选择边界，以及同时运行两者的混合搭配。

Goose 究竟是什么

Goose 是 Block（前身为 Square）出品的一个 on-machine AI 代理。你可以把它装成原生桌面应用，也可以装成 CLI，用 Rust 写成以获得可移植性与速度；代理在你打开的一个会话里运行。让它对接一个模型提供商 - Anthropic、OpenAI、Google、Ollama、OpenRouter、Azure、Bedrock，或者任意兼容 OpenAI 的 endpoint - 然后启动一个任务。它开箱即用地支持超过 15 家提供商。

Goose 最鲜明的主张是配方：一个 YAML 文件，包含名称、prompt、扩展列表、结构化输入以及可选的子配方。配方是让同一个二进制承担 PR 评审、工单分诊、测试套件修复以及数十种其它任务的方式。一个配方可能这样写："跑一遍测试套件，收集所有失败，一条条修复，再跑一遍确认，最后创建一个 commit。"任何同事都可以把这个文件签入代码库并执行它。Block 表示，这一抽象正是让 Goose 在公司约 12,000 名员工中覆盖到 60% 的原因，覆盖工程、销售、设计、产品与客户成功五大条线。

第二根支柱是可扩展性。Goose 是 MCP 的早期采纳者之一，如今已经拥有超过 70 个已文档化的扩展。这意味着每一项新能力 - 数据库读取器、Jira 面板、监控查询 - 都是一次性的 MCP 服务器，之后就能插入到任意一份配方里。Goose 也可以并行派出独立的子代理，让主对话保持整洁。

它没有开箱提供的是关于"你"的持久跨会话身份。Goose 的记忆是会话级的，具体范围由当前配方决定要记住什么。如果你希望一个代理还记得你两周前告诉它的事，而不必重新写一份配方去取回那段上下文，那这就不是这款产品的形态。

Hermes Agent 究竟是什么

Hermes Agent 是一个用 Python 写的服务器运行时，不是桌面应用。一条命令安装，一条命令启动，你的宿主机上就会出现一个长生命周期的进程 - 可以是一台 5 美元的 VPS、一块 Raspberry Pi、一台 NAS，或者家里的服务器。你可以从最方便的地方跟它对话：Telegram、WhatsApp、Discord、Slack、Signal、Matrix、Mattermost、邮件、SMS 或本地 CLI - 约二十条通道，由一个统一网关承接。

它刻意只有一个代理。它的力量来自开箱即用的三层状态：

核心记忆文件（MEMORY.md、USER.md），会在会话开始时注入 system prompt。
会话检索由 SQLite FTS5 支撑，让代理不用你再粘贴一遍就能回忆上周二说过的话。
技能（skill），一份份符合 agentskills.io 开放标准的 markdown 文件，代理会主动加载它们；对希望以后能重现的任务，代理还会自己动手写出新的技能文件。

围绕这套核心，Hermes 还带着一整套工具腰带：网页检索、页面提取、浏览器自动化（导航、点击、输入、截图）、视觉、图像生成、文本转语音，以及数十种其它工具。Hermes 可以对接任何兼容 OpenAI 接口的模型，所以 Nous Portal、OpenRouter 的 200+ 模型、NVIDIA NIM、Hugging Face，或者你自己的 endpoint 都能工作。运行时以 MIT 发布，边际成本主要就是模型提供商的账单。

决策边界

一个有用的框架：Goose 是你用键盘驱动的代理；Hermes 是你从手机上发消息去交谈的代理。

问题	Goose	Hermes Agent
代理住在哪里	你的笔记本（桌面应用或 CLI）	一台服务器（VPS、Pi、NAS、家用主机）
会话形态	你开一个任务，跑完，退出	长生命周期守护进程，始终在线
主要界面	终端或原生桌面 UI	Telegram、WhatsApp、Discord、Signal 等 17 个以上通道
跨会话记忆	由配方驱动，未内建	核心记忆文件、FTS5 会话检索、技能
扩展机制	MCP 服务器，通过 YAML 配方引用	MCP 服务器加代理自己写出的 markdown 技能
多租户 / 团队	配方可共享；每个用户一份二进制	每次安装对应一个单用户守护进程
编程语言	Rust	Python
许可证	Apache 2.0	MIT
最擅长	代码工作、类 CI 任务、可共享工作流	个人助理、跨天草稿、长期记忆
GitHub 星标（2026）	44,000+	175,000+

选错工具的信号通常很吵。如果你想要"一个住在 Telegram 里、认识我、我早八点起床时它已经把邮件草稿写好、笔记本却还关着"的代理，Goose 就是错的形态 - 没有长生命周期服务器、没有消息桥、没有持久身份。如果你想跑的是团队共享、在 CI 里"复审这个 PR、打补丁、再跑测试、提交"的工作流，Hermes 就是错的形态 - 一个消息为先的个人守护进程不是构建代理需要的东西。

什么时候选 Goose

以下情况选 Goose 更合适：

代理的任务是你在终端里驱动的代码工作。在你已经坐着的这台机器上读、改、跑、测文件。
你想要可移植、可评审的工作流。放进代码库里的 YAML 配方就是"作品" - 同事克隆代码库，跑 goose run，得到一样的行为。
你在团队或公司里，希望几十种任务共用一份二进制和一个扩展面。Block 那 60% 的覆盖率就是这类情形的样貌。
你想在桌面上拥有最大程度的模型自由，且不打算维护服务器。Anthropic、OpenAI、Google、Ollama、OpenRouter、Bedrock、Azure 都能跑，靠 Ollama 甚至可以真正离线。
你想要并行的子代理，让主对话在后台任务运转时依然可读。

这一类属于on-machine 代理赛道。Goose 在这里和 Aider、Cursor、Claude Code 以及 OpenClaw 有重叠。它的差异点是配方格式 - 一种朴素而漂亮的抽象，也能泛化到代码以外的场景。

什么时候选 Hermes

以下情况选 Hermes 更合适：

代理是为你自己服务的，不是为一个代码库或团队。日常写作助手、长线的日志伙伴、住在 Telegram 里的个人 CRM。
你希望记忆与消息通道都是开箱即用的。不用再写一份"记住我用 pnpm"的配方，也不用手搓消息适配器。
代理需要在你睡着或笔记本合上的时候仍然醒着。服务器运行时按定义就是 24/7 在线。
你希望它能在你已经在的地方找到你。Telegram 上的语音、Slack DM、一条短信 - 而不是你要专门打开的终端窗口。
你希望它自己变得更好。Hermes 会一边工作一边写和修改自己的技能文件，所以下个月的它比今天要强一点。

这一类属于个人代理赛道。我们在 Hermes Agent vs ChatGPT、Claude 与 Gemini 里比较过它与几大只做聊天的助手，在 Hermes Agent vs n8n 里对比过它与工作流工具，在 Hermes Agent vs Agno 里对比过它与 Python 框架。

如果你希望一分钟内就在 Telegram 上跑起一个托管的 Hermes Agent，还不用自己维护 VPS，那就从 Hermify 开始。

诚实的混合搭配

两个项目并不互斥，更有意思的做法是同时用。

**Goose 住在你的开发循环里。**笔记本上，一整个目录的配方管着 PR 评审、重构扫荡、迁移过程、测试套件修复 - 这些自然属于"开一次会话，跑完，关掉"的任务。配方像其它代码一样纳入版本控制。
**Hermes 承担弥漫式的关系。**在一台你整天从 Telegram 与之对话的服务器上，Hermes 起草邮件、总结阅读、跟进项目，还记得两个星期五前你曾答应某个客户的事情。

它们之间的桥是 MCP。Hermes 说的是兼容 OpenAI 的 API，也可以把自己作为 MCP 服务器暴露出来，Goose 的配方就能把 Hermes 的记忆当作一个工具去调用（"这个项目上，客户当时报的预算是多少？"）。反过来，Hermes 的一个技能也可以直接执行 goose run recipe.yaml，把天然属于代码的任务交给 Goose。实际使用中：Hermes 持有关系状态（你是谁、你在意什么、你的联系人是谁），Goose 持有结构化工作（那些你如果必须做的话愿意用 YAML 描述的活）。

成本、托管与锁定

两个项目都是开源、都可自托管，都不会把你锁定在某家供应商上。

Goose 跑在你本地机器上，运行时的开销就是你的笔记本加上模型提供商的账单。如果你用 Ollama，离线是免费的。配方是可移植的 YAML - 没有任何运行时住在别人的云上。

Hermes 跑在服务器上，所以你付服务器（个人用途 5 美元的 VPS 已经够用）和模型提供商的钱。如果你不想自己维护那台服务器，托管方案会替你打理 VPS、更新与消息桥接，并把记忆文件保留在你自己的账户里。我们在另一篇文章里聊过自托管与托管的取舍。

如何选择

一个简短的决策规则：

如果你的问题是"我想要一个我从笔记本上驱动、写代码、跑测试、做重构、CI 风格、工作流以 YAML 可评审"的代理 - 选 Goose。
如果你的问题是"我想要一个始终在线、认识我、住在 Telegram 或 Slack 里、能跨越数周记得我"的代理 - 选 Hermes。
如果你既想要笔记本上的代码代理又想要手机上那种氛围式的个人代理 - 就两个都跑，用 MCP 让它们在任务跨越边界时互相通话。

强迫任一方去扮演另一方的角色，是常见的失败模式。Goose 不是原生的消息类个人守护进程；硬把它改造成那样，就意味着把 Hermes 本可以直接给你的部分重新做一遍。Hermes 不是代码优先的 CI 执行器；硬把它改造成那样，就意味着自己重写一份 Goose 已经有的配方格式。一旦你接受它们瞄准不同的机器，选择就变简单，两代理并行的搭配也开始变得显而易见。