Hermes 登顶背后：一个 Web3 团队的进阶之路

作者｜Jacob Zhao @ IOSG Hermes 的现象级增长，并非源于 OpenClaw 原理上无法复制的独家技术，而是因为在个人 Agent 品类成型的关键窗口期，最精准地闭合了一套“挑战者增长系统”：承接 OpenClaw 已经教育成熟的用户池，建立起“可委托性”（Delegation Trust）这一比“自我进化”叙事更真实的体验差异。

当专业执行 Agent 越来越强时，用户仍然需要一个长期在线、值得托付的总管家。

打开 OpenRouter 的公开应用排行榜，Hermes Agent 以 30.5 万亿的 Token 使用量位居全平台第一，同时在 Productivity、Coding Agents、Personal Agents 和 CLI Agents 四个品类中排名第一，断崖式领先 OpenClaw、Claude Code 等知名 Agent。

▲ 图 1 · Hermes Agent 在 OpenRouter 的历史数据快照（截取于 2026 年 8 月 4 日，动态页面数据会随时间变化） 尽管 OpenRouter 的统计口径无法覆盖直连官方 API（如 Claude 或 Codex 原生订阅）的全行业 Token 消耗，但作为当前全球最具规模的 AI 大模型路由与聚合平台，其榜单具有极强的“风向标”意义。

虽然在高端专业任务层面，大量用户的核心业务工作流——复杂代码生成、架构设计、高价值数据分析——仍流向 Claude Code 和 ChatGPT，但 Hermes 在后台自动化、消息入口响应、长期在线监听与轻量级任务调度等使用场景保持优势。

作为一个由 Web3 团队打造的 Agent 产品，Hermes 取得了远超预期的传播、社区与使用强度成功，我们不禁要关注： Hermes 为何能在 OpenRouter 推理调用上实现反超？它与 OpenClaw 之间的真实分野，究竟在哪里？与 Claude Code 和 Codex 的关系中，Hermes 如何保持“差异化共存”而非“正面竞争”？

从开发框架到个人 AI 系统——OpenClaw 之路 为什么早期 Agent 框架没有产生消费产品 在 OpenClaw 出现前，Agent 领域虽已具备成熟的基础设施，但存在根本局限：其采用单位是“开发项目企业工作流”，而非“个人用户”。早期框架的共同特征是面向开发者、输出代码或配置——它们构建了 Agent 的基础设施，却未交付 Agent 本身。

过高的工程门槛导致始终困于“开发者工具”阶段，缺乏将技术转化为“个人专属资产”的产品化闭环，直接面向终端用户的“个人 Agent 产品层”几乎处于空白。

▲ 图 1 · Agent 技术栈六层结构（模型层→协议层→ SDK 开发框架层→编排运行时层→执行基础设施层→部署治理层） ▲ 图 1 · Hermes Agent 在 OpenRouter 的历史数据快照（截取于 2026 年 8 月 4 日，动态页面数据会随时间变化） OpenClaw 真正改变了什么 OpenClaw 并未在底层重新发明 Agent Loop 或任务调度技术，其核心贡献在于产品层面的系统性封装。

LangChain 解决的是“如何构建 Agent”，而 OpenClaw 解决的是“如何拥有 Agent”。

它跳过了技术栈的中间层，将散落的框架能力整合为个人可直接配置与长期使用的完整产品，实现了采用单位从“开发项目”向“个人”的根本转移，具体体现在六个维度的产品创新： 身份人格化：赋予 Agent 持续的名字与身份认同，打破无状态 API 调用的工具感。入口日常化：以 Telegram/WhatsApp 等高频通讯软件为交互界面，取代复杂的命令行或 IDE。

状态常驻化：作为后台进程长期在线运行，实现从被动“待命”到主动“在场”的跃迁。权限实体化：将用户的文件系统、浏览器、终端及现实行动能力深度纳入 Agent 的操作边界。能力可扩展：通过 Skills、Memory 和社区插件，将流程沉淀为可复用能力，扩展行动边界。

心智所有权：最核心的转变——用户从“使用一个 AI 工具”转变为“拥有一个专属的数字伙伴”。龙虾热为什么没有形成第二心智 OpenClaw 的热度催生了大量仿制品。这些产品解决了真实的用户问题：安装过程的繁琐、环境配置的困难、微信和飞书等渠道的缺失、国内模型的兼容、云主机的快速部署、企业权限管理、自动更新和安全隔离等。

它们都有各自的用户群，也有合理的商业逻辑。但几乎没有一个形成了独立的品牌心智——原因在于它们回答的问题是“怎样更容易地使用 OpenClaw”，而不是“个人 Agent 在 OpenClaw 之后应该向哪里进化”。叙事挑战者的位置在整个个人 Agent 市场中极为稀缺。

为什么最后是 Hermes 后来居上 Nous 的模型、社区与 Crypto-native 背景 Nous Research 起源于 2022 年的 Discord 开源 AI 研究社区，并于 2023 年正式完成公司化运作，核心创始团队包括 Jeffrey Quesnelle、Karan Malhotra、Teknium 和 Shivani Mitra，其业务涵盖： Hermes 模型系列：Nous 最具代表性的开源模型品牌，长期聚焦模型后训练、指令微调与 Agent 能力，在 Hugging Face 建立了庞大的开发者采用基础。

DisTrO（Distributed Training Over-the-Internet）：通过大幅降低分布式训练的跨节点通信开销，显著降低分布式训练中的跨节点通信需求，使跨地域、异构硬件在互联网带宽条件下参与协同训练成为更可行的工程路径。

Psyche 去中心化训练网络：将 DisTrO 进一步网络化，通过 Solana 协调全球分布式计算节点，使不同网络与硬件环境的 GPU 能够共同参与大模型训练。Hermes Agent：Nous 面向终端用户推出的个人 Agent 产品，将 Hermes 模型、工具调用、Memory、Skills、消息渠道和长期运行能力整合为常驻 Agent。

2025 年 4 月，Nous Research 完成由 Paradigm 领投的 5000 万美元 Series A 轮融资，投后代币估值达 10 亿美元。

在此轮融资之前，公司已累计完成约 2000 万美元的早期融资，投资方包括 Distributed Global、North Island Ventures 及 Delphi Digital 等知名机构。

Nous 构建了“Hermes（模型能力）、DisTrO（分布式训练）、Psyche（去中心化算力网络）和 Hermes Agent（个人终端产品）”的技术闭环。

Hermes Agent 的发布并非追逐热度的临时 Fork，而是 Nous 在供给侧（数据、模型、训练、开放权重）完成长期沉淀后，首次向需求侧（真实用户、任务、工作流）发起的战略级延伸——这为其建立差异化提供了比普通仿盘更深的起点。

OpenClaw 的运维痛点变成 Hermes 的增长引擎 Hermes 与 OpenClaw 在底层封装（模型+工具+ Memory +调度）上差异不显著。其现象级爆发并非依赖技术代差，而是精准闭合了一条系统性增长因果链：通过无缝迁移工具直接承接 OpenClaw 已教育成熟且饱受运维痛点折磨的用户，构成了早期最核心的增长引擎。

产品力跃迁：建立“可委托性”（Delegation Trust） Hermes 核心产品假设是解决“运维责任转嫁”，承诺“出错后由系统内部吸收修复”： 可靠性信任：确保任务持续推进与失败恢复（持久化 Kanban、/goal 模式、工具自愈）。安全性信任：防止越权、误删或数据泄露（Approvals 审批流、沙箱、严格权限边界）。

可验证信任：证明任务真正完成（Completion Contract 与 Grounded Citations）。

概念辨析：“自我进化”（叙事优势）vs “自主恢复”（体验差异） 在 Hermes 的产品叙事中，“自我进化”与"自主恢复"的产品价值存在显著差异： 自我进化（Self-improvement）：本质是基于 Memory 与 Skills 的流程适应。

鉴于竞品具备类似基建，其差异化更多在于率先整合为带生命周期管理的默认系统，占据“会成长”心智的叙事优势，而非已证明的、不可逾越的技术壁垒。自主恢复（Autonomous Recovery）：这是当前最值得验证的体验差异。得益于结构化错误返回与 Provider 自动 Fallback，Hermes 能将故障消化在系统内部。

这种“不频繁打扰用户”的系统级稳定性，是更直接、可感知的产品力差异。架构红利：对专业 Agent 的委派与监督能力 Hermes 的核心价值不在于亲自执行所有专业任务，而是作为总控层（Orchestrator）承担需求补全、任务拆解、路由监控与最终验收。

通过内置 Skill 委派 Claude Code/Codex 等外部 CLI 执行具体工作，社区已沉淀出“Hermes 总控 + 外部 CLI 作为Worker”的实践范式（如/goal 机制与 oh-my-hermes 协同工具），体现了其通过调度专业 Agent 推高任务复杂度上限的架构优势。

从 Crypto-native 到 Crypto-invisible：Hermes 的 Web3 幕后操作系统 将 Hermes 的成功简单归因于“Web3 背景”是过度简化。

Web3 为 Nous 提供的是一套其他 AI 创业团队较难同时获得的“组织操作系统”，使其能以标准 AI 产品的顺滑体验切入主流市场： 风险资本的耐心：Crypto-Native 资本支持长期、高不确定性及多路线并行投入，使 Nous 能同时布局模型、训练、Runtime与Cloud，无需过早收敛于单一收入验证。

现成的用户市场：提供了熟悉 Telegram、服务器、API 及自托管的 Crypto AI 用户群体，大幅降低冷启动教育成本，并催生了高强度使用、教程传播与 Skills 贡献。

用户主权价值观：秉持自托管、开放、可迁移及反平台锁定的取向，直接落实为 MIT License、多 Provider 支持、BYOK 及 Memory/Skills 可迁移的底层架构。社区研发与垂直化：依托全球远程协作与开源文化，用户自发成为 Contributor、Skill 作者及垂直场景的产品设计者。

Hermes 几乎没有把 Crypto 暴露在用户前台。使用其 Agent、Memory、Skills 和自动化能力，不需要连接钱包、购买 Token 或理解 Solana。与此同时，Paradigm 资本、Psyche、分布式训练和 Crypto AI 社区仍然存在于产品后台。

这形成了一种可以概括为“Crypto-native in organization, crypto-invisible in product”的产品形态——组织层面保留 Crypto 最有价值的部分（资本、全球社区、用户主权与协调能力），产品层面移除最容易阻碍主流采用的部分（钱包、Token、投机叙事与链上操作摩擦）。

OpenClaw 为什么排斥 Crypto，Hermes 为什么隐藏 Crypto OpenClaw 与 Hermes在Crypto 问题上的表面对立，并非“排斥”与“拥抱”的意识形态之争，从产品结果看，都体现出开源、用户控制和降低平台锁定的取向；区别在于 Nous 进一步把加密经济机制用于分布式训练协调，而 OpenClaw 主要通过 Local-first 架构实现用户主权： OpenClaw（Local-first Sovereignty）：抵制金融投机，捍卫“本地优先”主权。

因早期遭遇假币诈骗，其对 Crypto 采取“零容忍”。通过纯开源与本地运行，实现对用户主权的非区块链式捍卫，坚决拒绝产品层面的金融化。Hermes/Nous（Cryptoeconomic Sovereignty）：工程导向，Crypto 仅作底层协调工具。

引入区块链是应对工程挑战的务实选择（如 Psyche 网络利用 Solana 协调异构算力），而非构建面向终端用户的金融叙事。Hermes 的进阶模式——从个人 Agent 到任务总管家 本节希望回答一个更根本的问题：当 Claude Code 和 Codex 已经能高质量完成大多数专业执行任务时，Hermes 作为独立产品的存在理由是什么？

模式 A：直接协作型（增益有限）：用户习惯手动在 LLM 生成 Prompt 并转交执行，人工搬运结果与审查。单次输出质量虽高，但需承担全部项目管理与多 Agent 协调工作。对此类亲力亲为的用户，Hermes 的自动化反被视为"增加不透明度的中间层"，未能有效减负。

模式 B：委托管理型（增益明显）：用户将 Hermes 作为常驻总控，仅下达最终目标。由 Hermes 负责任务拆解、委派子任务、追踪 GitHub/CI 状态并自动触发返工。社区实践（如oh-my-hermes）显示，Hermes 的核心价值正是替代繁琐的跨 Agent 协调与项目管理工作。

在这个框架下，Hermes 与 Claude Code/Codex 不是替代关系，而是分层关系：后者提供第三层的执行质量，前者提供第二层的持续性、跨会话状态和跨 Agent 协调。Hermes 的价值不是均匀分布在所有用户身上，而可能高度集中于跨 Agent、跨系统、长时间异步任务的高级用户群体。

这个判断比笼统的“个人 Agent 第二心智已经形成”更精确，也更适合指导商业化和产品优先级。

▲ 图 2 · Hermes Agent 技术架构全景（用户入口→ Gateway →控制核心→Provider 层→执行层→编排层→状态层→治理层） 基于官方文档社区研究，Hermes Agent 技术架构全景框架覆盖了从用户交互到学习治理的全链路： 自主恢复的系统级支撑：“控制核心”明确包含 Context 压缩、Provider Fallback 及中断状态保存，为故障恢复提供技术基础 及任务失败时的系统自愈能力。

“委派而非替代”的执行逻辑：“工具与专业执行层”将 Claude Code、Codex 等外部 CLI 与 Hermes 原生工具（Terminal、Browser 等）平级并列，印证了其作为调度中枢的定位。

“自我进化”的治理属性：“学习、维护与治理层”包含 Curator、Skill/Command Approval 等节点，表明其经验沉淀是具备人工介入机制的治理流程，而非全自动黑箱。商业模式——谁为“Hermes”付费？若仅将其 Token 成本与直接订阅 Claude Code/Codex 进行对比，将得出误导性结论。

因为这种算法忽略了 Hermes 的核心价值：替代用户亲力亲为的项目管理、上下文搬运与跨 Agent 协调工作。

用户价值公式 Hermes 用户价值 = 节省的人工协调时间 + 异步与无人值守价值 + 跨系统自动化收益 − Token 与工具成本 − 人工介入成本 − 失败与安全风险 因此，Hermes 的经济性并非绝对，而是高度取决于用户的“委托深度”： 高委托深度（经济性成立）：若 Hermes 能将原本需数小时人工盯盘的任务转化为真正的无人值守执行，即便 Token 成本略高，其整体时间成本与效率收益依然为正。

低委托深度（经济性崩塌）：若用户仍需频繁介入纠错与救火，Hermes 则沦为纯粹的 Token 消耗器与故障放大器。这一机制精准解释了为何不同用户群体对 Hermes 的经济性评价截然相反，也提示我们：验证其商业逻辑的关键，在于量化“无人值守完成率”与“单任务人工介入次数”，而非单纯比较模型 API 的单价。

商业化底座：Nous Portal 与 Hermes Cloud Hermes Agent 采用 MIT 协议开源，定位为生态增长引擎。真正的商业化闭环集中于Nous Portal，其核心价值主张为“一个订阅，整合多类 API 密钥”，涵盖三大模块： 模型路由：聚合 252 个模型（通过 OpenRouter 及直连 Provider 提供推理）。

工具网关（Tool Gateway）：内置 Firecrawl（网页搜索）、FAL（图像生成）、Browser Use（云端浏览器）、Modal（沙箱执行）及 OpenAI Audio（TTS）等高频工具。托管服务：开箱即用的 Hermes Cloud 实例（按日收取运行费，不含推理与工具调用费）。

Nous 的实际收入高度依赖用户的使用路径，目前呈现明显的结构性分化： 开源与商业化，Hermes 会不会成为“Agent 世界的 Linux” Hermes 的 MIT 开源策略在驱动爆发式增长的同时，也构成了商业化的结构性约束。自托管免费模式要求其付费版必须具备不可替代的额外价值，但目前尚未形成清晰的差异化变现路径。

更深层的风险在于“价值截留”：若Hermes 持续作为可选 Runtime 被云厂商广泛集成，可能重演 Linux 或 K8s 的经典困境，核心商业价值被提供算力与托管的云厂商截留。MIT 协议在换取生态繁荣的同时，也意味着放弃了对分发渠道的绝对控制。

只要用户能自由选择“自托管+自有 API”或“第三方云部署”，庞大的使用量便无法强制转化为直接收入，使 Nous 面临“生态位提升”与“实际商业回报不匹配”的严峻考验。

Agent 生态位——个人总管家、专业工具与大厂 Claw 的三方格局 OpenClaw、Hermes 与 Claude Code、Codex 及大厂托管类产品在目标用户与核心命题上存在显著差异，属于不同的细分赛道。

为厘清当前市场格局，AI Agent 全景核心竞争矩阵如下： Hermes 并未追求泛大众市场，而是精准切入四类高密度 Power User，构成了其现象级传播的基石： 自托管与基建玩家：熟悉 VPS/Docker/SSH，将 Hermes 视为现有基础设施的自然控制层。多模型套利者：拒绝单一厂商锁定，习惯根据任务动态调度前沿或本地模型。

多 Agent 协调者：亟需将跨平台、跨工具的复杂串联工作流实现自动化编排。开源与 Crypto AI 社区：高度认同用户主权与去中心化理念，与 Nous 的组织文化深度共振。这类群体基数虽小，却具备极高的 Token 消耗量、代码贡献度与技术布道能力，是推动早期口碑传播的核心引擎。

Claude Code/Codex：既是供应方，也是威胁 #短期共生：推高执行上限 在实际工作流中，Hermes 作为总控层，通过委派机制调用 Codex（代码实现）与 Claude Code（架构与审查）。底层专业 Agent 越强，Hermes 能交付的任务复杂度上限就越高，形成“Hermes 负责路由与验收，专业 Agent 负责执行”的共生关系。

#长期可能吞噬 Hermes 的独立价值 模型厂商正加速向总控层渗透，威胁比预期更近。Anthropic 的 Claude Managed Agents 已支持多 Agent 并行编排；OpenAI 更将 Codex App 明确定位为“command center for agents”，支持多 Agent 并行、自动化与长周期后台运行。

这意味着 Codex 在软件工程边界内的多 Agent 总控能力已相对成熟，甚至在局部超越 Hermes，不再是单纯的"底层执行者"。Hermes 暂时拥有跨渠道、跨模型和跨项目的个人控制平面优势；但 Codex 已经在软件工程边界内具备强大的任务所有权和多 Agent 管理能力，这个边界内的竞争优势可能比 Hermes 更强。

核心竞争问题是：Hermes 能否先于模型厂商，把用户的项目状态、审批规则、Skills、Memory 和跨 Agent 工作流沉淀在自己这一层，形成用户不愿迁移的资产？还是最终会被模型原生产品作为标准功能吸收？

互联网大厂 Agent 路线选择 探讨大厂应对个人 Agent 浪潮的策略，需先厘清其产品边界：面向个人的常驻 Agent 托管（如腾讯 QClaw、字节 ArkClaw）与面向办公/企业的通用工作 Agent（如 WorkBuddy、Trae）定位截然不同： 大厂 Claw 路线：通过一键部署、预设模板与本土生态接入降低门槛。

但深层鸿沟在于平台激励不可信：无论支持多少外部模型，用户天然认为其最终目的是导流至自有云与模型体系。

Hermes Runtime 集成：字节 ArkClaw 与腾讯云均正式将 Hermes Agent 作为可选插件或专属模板接入其云端控制台，确立了明确的多 Runtime 策略：大厂保留自身的云托管、计费、安全与企业级管控底座，同时将 Hermes 视为可插拔的高级组件，实现开源生态与商业云平台的互补共生。

通用办公 Agent 转型：当下大厂正将核心资源从 Claw 转向需求明确、易于验收且能直接变现的通用办公 Agent 平台（如 WorkBuddy）。此类任务能与微信、钉钉、飞书等自有生态深度绑定并转化为营收。

Hermes 对 Crypto AI 的启示 Web3 并没有直接让 Hermes 变成一个更聪明的 Agent，而是让 Nous 拥有了一套不同于传统 AI 创业公司的资本结构、组织方式、种子用户与价值观来源。Hermes 至少提出了一种更成熟的 Crypto AI 路径：让 Crypto 成为组织与基础设施，而不是用户必须面对的产品界面。

Hermes 已经完成从 Crypto AI 研究品牌到全球开源 Agent 产品的迁移，建立了大规模可归因推理活动与清晰的第二心智——但这个心智目前仍集中在 OpenRouter 生态和全球开发者圈层，并未转化为 GitHub Stars 或整体社区规模上对 OpenClaw 的全面反超。

它没有 OpenClaw 无法复制的独家技术，而是通过精准承接高强度用户、建立“可委托”与“自进化”完成了一次值得研究的挑战者产品迭代。启示一：Crypto 可作为“组织操作系统”，而非产品功能：Web3 的真实价值可体现为资本结构、早期高强度用户池与价值观底座，无需强制暴露为钱包或 Token 交互。

实现“组织层 Crypto-native，产品层 Crypto-invisible”，是兼顾创新动力与用户体验的有效战略。启示二：去中心化基建必须锚定需求侧入口才能形成闭环：纯供给侧的分布式训练网络（如 DisTrO、Psyche）若无真实用户入口与执行数据支撑，难以自证商业价值。

Hermes Agent 正是 Nous 从底层算力基建向真实需求侧跨越的关键验证。启示三：护城河可建立在“委托信任”而非单纯的“模型能力”之上：个人 Agent 的差异化未必源于更强的单次执行能力，而在于“用户是否敢于将长期责任交付于它”。这种软性的信任资产，是 Crypto AI 项目中常被忽视却极具壁垒的维度。

启示四：与云大厂的关系并非零和博弈，而是生态互补：大厂将 Hermes 作为可选 Runtime 接入，证明开源 Runtime 与大厂控制平面可共存。对创业者而言，“被集成”是一条可行的商业化路径，但需警惕核心价值被云厂商托管层截留的风险。

启示五：终局竞争将从“单次执行能力”转向“任务所有权与信任积累”：未来最具价值的未必是执行层的最强模型，而是能接收最终目标、维护长期 Context、智能调度专业执行者，并让用户安心交付责任的“上层总控系统”。

OpenClaw 让“个人拥有 Agent”成为一个清晰的产品品类；Hermes 则通过持久状态、任务恢复、证据验收、多模型供给和专业 Agent 委派，把“长期委托 Agent”推进为一套更系统的产品方向。

真正的考验是：当 Claude Code、Codex 在软件工程边界内的总控能力持续增强、大厂云平台把多 Runtime 集成做得更顺滑时，用户是否仍然愿意把最终目标和长期信任交给这个来自 Web3 背景的开放 Runtime——并为此持续付费。