一次对比终结@bot与@NousResearch之争…… https://t.co/WVWs9aiMKR

Grok Bot 与 Hermes：表面相似，底层战略截然不同

一个试图让AI队友如托管产品般顺手，另一个则将智能体本身打造为开放的可组合运行时。

研究笔记 —— 2026年8月20日： 为本次对比，我刻意避免使用X平台帖子、网红讨论或“X是Y的免费版“之类的观点作为证据。我查阅了Cursor/SpaceXAI针对Grok Bot以及Nous Research针对Hermes Agent的当前第一方文档。同时包含一个独立标注的Hermes Bot模式实测环节。两款产品迭代迅速，文中描述的功能与价格均基于我查阅时公开记录的状态。

过去一周，Grok Bot与Hermes Bot模式持续被拿来比较。

这种对比情有可原。

打开任意一款产品，发展方向都日益相似：具有名称与角色、配备记忆与工具、支持可复用行为、可后台执行的持久化智能体，以及刻意弱化“与模型对话“感、强化“向队友派活“体验的界面设计。

但深入界面之下，我认为多数对比都从错误的层次开始。

真正的差异不在于能创建多少个Bot， 而在于执行发生在何处、状态存储于何处、用户能控制模型栈的多大比例、可复用能力的构成是什么，以及智能体如何与外部系统通信。

Grok Bot与Hermes在产品层日益相似， 但在架构层面正押注截然不同的方向。

1. Grok Bot：始于托管化计算环境

当前Grok Bot文档描述的持久化智能体可承担多步骤工作、使用已连接插件、在云端计算机内运行、记住上下文、执行例行任务，并在用户离线时持续工作。对于未配备插件的服务，智能体可使用Grok Bot计算机上的浏览器。

这揭示了其核心产品哲学：执行环境主要由产品本身提供。

用户创建智能体、连接服务、完成认证、描述目标，随后让托管环境处理底层机制。

Cursor企业页面将Grok Bot描述为SpaceXAI的产品，强调Bot以用户身份登录工具、完成工作并交付成果的体验。该云端计算体验在桌面端与iOS端通过同一账户通用。

产品战略清晰可见：

为AI队友提供持久化的托管环境，尽可能消除运维摩擦。

这对重视任务完成而非智能体基础设施运维的用户尤为具有吸引力。

2. Hermes：始于可配置运行时

Hermes从几乎相反的方向切入问题。

Hermes Agent是开源MIT许可软件，可在Windows、macOS、Linux/WSL及Docker环境中原生运行。其模型层可配置，不受单一供应商绑定。

其核心抽象概念并非“拥有计算机的Bot“， 而是运营商可配置组件的智能体运行时。

模型选择、工具、记忆、技能、配置文件、网关和执行后端均作为系统组件暴露。

我对此差异最简明的表述是：

Grok Bot为智能体提供托管计算机。 Hermes为你提供可置于自控环境的智能体运行时。

此表述刻意避免评判优劣，仅说明各项目选择在何处进行抽象分层。

3. Hermes中Bot可构成真实的状态边界

创建多个智能体时，这一特性变得尤为重要。

Hermes配置文件是独立的主目录。据官方文档，每个配置文件可拥有独立的配置、API密钥、SOUL.md、记忆、会话、技能、定时任务、状态数据库及网关状态。

这意味着两个Bot不必是同一智能体的两个别名。

概念上可构建：

研究智能体 专注研究的模型 网络访问权限 研究专用技能 独立记忆与状态

而另一配置文件则成为：

实施智能体 面向编码的模型 终端与文件工具 差异化技能 独立记忆与状态

这比更换头像或系统提示词具有更本质的意义。

必须明确指出重要注意事项：

状态隔离不自动等于执行隔离。

Hermes配置文件文档指出，配置文件状态与终端工作目录是独立概念。为不同智能体分配不同主目录，并不会自动为其执行的每个命令创建操作系统级沙盒。

此细微差别至关重要。将所有Hermes Bot称为“完全隔离“并不准确。

4. Hermes的模型自由度超越功能勾选框

常见对比表述为：

“Grok使用Grok；Hermes支持多种模型。”

此说法大体正确，但忽略了更有趣的架构要点。

Hermes将智能体与所用模型解耦。

当前配置系统设有一个主模型插槽，以及用于压缩、视觉、网页摘要、审批评分、MCP路由、技能搜索等任务的独立辅助模型插槽。这些均可独立配置。Nous Portal目前提供300+模型，同时Hermes支持直连供应商与自定义端点。

换言之：

智能体身份不必等同于模型身份。

持久化研究智能体今日使用某模型，明日可切换另一模型而不改变其身份。不同智能体也可根据任务分配不同模型。

在当前公开的Grok Bot文档中，我未发现等效的用户侧模型路由层。这不证明Grok Bot无法使用不同内部模型，仅表明Hermes将模型选择暴露为运营商可控的基础能力，而Grok Bot目前将更多层级抽象隐藏。

此差异比宣称某系统拥有“更优模型“更具实质性意义。

5. 真正的长期资产可能是技能而非对话

两个系统都指向智能体设计的重大转变。

有用的智能体不应每次从零学习工作流。

Hermes将技能视为可复用的流程知识。其技能系统支持可安装能力与显式技能文件，且项目已增加第三方技能安装的安全扫描。

Grok Bot公开文档强调持久化智能体、插件与超越单次会话的持续运行例程。

实现方式不同，但更广泛的方向相似：

成功的行为应转化为可复用的行为。

这引出比“谁的记忆实现更优“更有趣的问题：

如果智能体智能的持久单元最终不是对话历史，而是其可调用的有用流程库，那会怎样？

这使智能体技能领域的竞争变得更为关键。

6. A2A协议重新定义“多智能体“

这是我想亲自测试Hermes的部分。

Hermes实现了开源Agent2Agent协议v1.0。文档显示Hermes智能体既可调用外部A2A对等体，也可接收其任务。互操作性声明不限于其他Hermes实例。官方文档描述了与LangChain、CrewAI、Google ADK智能体及基于官方A2A SDK的实现的兼容性。

这创造了根本不同的可能性：

Hermes → 另一进程 → 另一机器 → 另一框架

交接发生在协议边界处。

需补充细微差别：Hermes自身建议A2A主要用于跨越进程、机器或框架边界。对于同一机器运行的多个智能体，文档推荐使用委托或看板式工作队列等更简单的原生机制。

我的实测

我刻意在Bot模式下测试A2A，旨在验证特定设想：

如果智能体被设计为功能不完整会怎样？

我将一个工作流拆分为三个角色：

研究协调员 可协调但无法实现

↓

实施工程师 可构建但不负责审批自身工作

↓

验证审计员 可独立测试结果

测试并未在首条消息就奇迹般成功。

A2A对等体初始需要配置。早期一条消息因结构问题被拒为空任务。修正配置后，实施工程师返回PONG_OK确认通信。

随后传递真实规格。实施工程师生成Python能力风险检查器，结果传递给验证审计员。

审计员运行十项测试，包括正常能力组合、边界案例与对抗性测试。

全部通过。

成果本身并非重点。

关键在于：

通信成为职责分离的一部分。

智能体协同有效，正因为它们中没有任何一个拥有整个工作流的所有权。

这与简单地将多个Bot放入聊天室截然不同。

7. 开放互操作与产品原生协作并非等同

此处对比需格外谨慎。

Grok Bot显然围绕多持久化AI队友与真实世界工具使用设计。但我未找到公开文档证明其具备等同于Hermes A2A支持的开放外部智能体互操作层。

这不意味着内部不存在或永远不会存在此类功能。

但宣称以下任一观点都欠妥：

“Grok Bot缺乏互操作性”，或

“Grok Bot支持相同的开放智能体协议”。

今日可验证的差异更窄：

Hermes公开提供基于标准的A2A互操作性。

Grok Bot的文档优势在于围绕持久化智能体、插件、浏览器使用及例程的托管产品环境。

这已构成足够区分，无需编造更强对比。

8. Grok Bot的优势恰是部分Hermes用户眼中的局限

Grok Bot从用户心智模型中移除了大量基础设施。

需要Gmail？连接插件。 需要Slack或Notion？连接即可。 无插件？Bot可使用其浏览器环境。

对许多用户而言，这是特性而非妥协。

派活者无需理解模型路由、运行时隔离、终端后端或A2A对等配置。

Hermes暴露更多此类决策，提供控制权的同时也暴露复杂性。

我的A2A实验完美展现了此权衡的两面：

灵活性真实存在，调试过程也同样真实。

因此我认为“开放与封闭“不足以解释这些产品。

更好的区分在于：

Grok Bot对环境持明确立场，让用户无需自行选择。 Hermes暴露环境，让用户不必被迫接受单一立场。

9. 安全：信任边界转移而非消失

智能体讨论常陷入另一重二元谬误：

本地 = 安全 云端 = 不安全

此观点过于简化。

Grok Bot智能体可操作真实账户、文件与网站。Cursor明确警告用户注意此权限，建议自行登录Grok Bot计算机，并警告勿将API密钥与凭证置于普通聊天或文件中。

Hermes让运营商更多控制智能体执行位置与状态隔离方式，但也增加了配置责任。

例如，不同配置文件不自动等同于不同操作系统级沙盒。

因此Hermes的A2A层包含明确安全控制：未配置令牌时默认仅本地主机运行、逐对等体认证、入站消息提示词注入过滤、出站凭证编辑、速率限制及审计相关身份处理。

正确结论不是某架构天生安全而另一架构不安全，而是：

它们将信任置于系统不同部分。

Grok Bot将更多安全责任集中于托管产品内。 Hermes让运营商可配置更多安全边界。

这赋予运营商更多控制权，也提供了更多错误配置的可能。

10. 价格：并非简单的“$300对免费“

价格可能是此对比中被重复最多却表述最不严谨的部分。

Grok Bot

截至2026年8月20日，Cursor当前文档表明，Cursor Ultra订阅包含Grok Bot持续个人访问权限。Pro与Pro Plus不包含Grok Bot；符合条件的高级团队席位是另一访问途径。

Cursor Ultra当前价格：

200美元/月。

SuperGrok Heavy订阅者享有限时优惠，但当前文档明确：符合条件用户可获得一个月免费Cursor Ultra。此权益不因用户持续订阅SuperGrok Heavy而重复获得。

因此宣称：

“Grok Bot每月300美元”

并非当前访问模式的准确描述。

更准确的说法是：

Grok Bot访问权限目前捆绑于200美元/月的Cursor Ultra个人订阅，并提供其他符合条件的访问途径。

Hermes

Hermes Agent本身是：

0美元软件，开源MIT许可。

但这不意味着运行Hermes成本为零。

仍需要执行环境与某种形式的模型推理。

根据设置，可能需要：

• 现有计算机，
• 虚拟专用服务器，
• 本地模型硬件，
• API使用，
• OpenRouter，
• Nous Portal，
• 或其他模型提供商。

因此Hermes具有完全不同的成本曲线：

无强制性软件许可费用，但基础设施与推理成本由用户选择且取决于工作负载。

这对某些用户可能显著更便宜，对另一些用户可能更复杂甚至更昂贵。在不指定工作负载与模型栈的情况下，无法给出“Hermes成本是多少“的诚实单一数字。

11. 我实际会使用的对比

此表格刻意保守

任何无法从当前公开第一方文档验证的内容均未纳入，而非猜测

那么谁胜出了？

我认为这是错误的问题。

它们在优化AI队友的不同定义。

Grok Bot押注产品体验：

为智能体提供持久化计算机，连接用户工作环境，保持可用性，尽可能隐藏基础设施。

Hermes押注运行时自由：

让运营商选择模型、执行环境、状态边界、工具、技能，甚至日益重要的智能体通信协议。

更简单的表述：

Grok Bot试图消除运维摩擦。 Hermes试图消除架构锁定。

对于希望委派任务……