HermesAgent与OpenClaw的路线之争

当智能体试图记住一切，它反而失去了判断什么值得记住的能力。

·  ·  ·

一个能驱动超过200种模型的智能体系统，留给你的画像空间只有500多个token。折算下来，大约200个汉字。它试图用这200个字理解你是谁。另一边，当你和它反复交流100次甚至200次去完成一轮模型训练时，它真正能稳定记住的上下文，只够覆盖最近五六轮对话。更早试过的方案、已经确认走不通的路径，会被它不断遗忘。这就是HermesAgent——一个以“记忆机”为核心卖点的系统，在记忆这件事上暴露出的两个最尖锐的裂缝。

HermesAgent的记忆体系被明确划分为四个层级：即时上下文、中期摘要层、长期记忆层和用户画像层。层级越往下，内容越稳定。这听起来很完整。目前业界主流路径也确实是三层或四层架构，Hermes并没有在框架上偏离太远。

问题出在每一层内部的容量控制和稳定性上。

“

最上层记忆被直接纳入上下文参与推理，持久化为MD文件，规模大约800个token。

800个token在轻量场景下够用，大概支撑四五轮到六轮对话。但一旦进入专业门槛高、信息点密集的任务，这个容量会迅速崩盘。拿代码开发配合模型训练来说，人和机器之间通常需要反复交流大约100次，某些情况超过200次。而系统能稳定保留的只有最近五六次对话。早期尝试过的方案、已排除的无效路径，会不断被遗忘。

这意味着，在长周期复杂任务中，Hermes本质上是一个“健忘的协作者”。你不得不反复告诉它哪些路已经走过且不通。

长期记忆层的情况更微妙。它底层基于SQLite持久化，没有明确的硬性容量上限——真正的限制只有本地磁盘的物理空间。理论上可以无限扩展。

但这恰恰是隐患所在。

由于缺少严格的筛选机制，长期记忆层不断沉积大量低价值内容。一个总计100步的工作里，真正产生价值的环节可能只有20步，其余80步是验证、摸索或排除问题的过程。按当前机制，这80步也会被一并存入存储。长期下来，磁盘空间被快速占满，信息质量参差不齐。

更棘手的是记忆回溯能力。当系统长期使用“小A”的workflow处理某类问题，因短期业务变动暂时改用“小B”后，等这一阶段过去，Hermes基本上已经难以把memory状态恢复到先前以“小A”为中心的轨迹。业务核心的短暂转移，就会导致记忆路径难以准确还原。

HermesAgent的四级记忆架构在框架上完整，但每一层都存在容量或稳定性的瓶颈。

用户画像层的设计逻辑值得单独拿出来看。这一层被压缩在约500个token的空间内，折算汉字大概200字上下。设计出发点是：画像层对应的数据场景通常较为稳定，变化不频繁，系统不需要积累大量琐碎行为信息，掌握少量核心偏好即可，其余由自动化机制处理。

这个逻辑在个人轻量使用场景下或许成立。但在toB交付环境里，如果像某些公司那样把Hermes统一推送给内部员工使用，200字的画像容量明显不够。面对真实业务场景，这个限制已经显得不足，扩大上限的需求相当迫切。

一个面向企业级部署的系统，却用200字来理解每个使用者。这种压缩比，几乎是在用“用户画像”这个名字掩盖实际能力的缺失。

HermesAgent与常见Agent方案在记忆机制上的核心差异在于：它不依赖向量库的相似度检索，而是通过内置的GPA自动化引擎完成知识的归纳、压缩和提炼。知识检索和真实对话流程紧密绑定——某段知识被用于生成回复后，外部反馈会进一步改变整套memory的调用方式。

这套设计让记忆复用的效率更高，但也打开了新的攻击面。

“

一旦攻击者将skill控制到手，系统整体行为就会转入难以透视的黑箱之中，整个运行流程实际上会沦为一个外界无法洞察的黑盒。

Skill机制是内部固化的运行机制，不由人为操作直接设定，也不受公开规则明确限定，外部几乎无法精确了解它如何运作。如果攻击者篡改了skill，系统的行为将完全失去可见性。同时，记忆归纳提纯的自动化链路本身也可能遭受外部力量介入和操纵。

基于反馈动态调整memory的方式也带有固有风险：一旦某一轮反馈被系统放大过头，部分内容可能被误判为更重要，削弱整体记忆管理的稳定性。

把HermesAgent和OpenClaw放在一起比较，能看到两条截然不同的技术路线。

Hermes偏向让系统自动接续并完成任务，用户基本无需经历复杂的前期设置，系统几乎不做额外调校就能直接接手推进。但代价是：对操作流程和最终结果的控制能力偏弱，难以稳定保证输出质量。内部推进过程并不稳定，没有统一的固定格式，用户无法对每一步进行细致准确的控制，只能等任务结束后依据最终产出提供反馈。

OpenClaw走的是另一条路。它更接近基础系统层，作用类似于AIOS，负责跨系统范围内的统一调度。设计上属于“网关+中枢调度”，当某个执行节点发生故障时，调度中心会接管处理，将任务转移到备用节点。但它采用的中心化调度存在先天不足：可以在节点故障后进行替补，却无法把某次失败中得到的经验沉淀下来，用于改进后续相似任务的执行策略。

两者在易用性与可控性上做了截然不同的取舍，也决定了各自适用的场景边界。

在易用性上，Hermes明显占优。OpenClaw对新用户至今不太友好，配置文件过多，市面上甚至出现了专门教人如何设置参数的培训机构。Hermes则把整体过程交给自动化机制，摆脱了高度依赖人工配置的方式。

但可控性上，OpenClaw更强。它的skill机制不会自动启用，需要人工逐项安装并完成设置后才会生效。每一步都在用户的明确意图下推进。

HermesAgent的实际部署存在三种模式，各自的门槛和代价差异明显。

本地部署的最低配置要求是4核CPU、64GB内存和约20GB显存。最棘手的瓶颈在那20GB显存上——绝大多数普通办公电脑根本不具备。引入MacMini来分担显存压力是一个相对可行的思路，但要在企业范围内将全体员工设备统一替换成MacMini，基本难以落地。再加上需要至少数百GB磁盘空间，操作系统目前只支持Linux和Mac。对绝大多数企业来说，走纯本地化路线并不现实。

云端部署对本地设备要求明显更低，约2核CPU和十几GB内存即可，不需要GPU。但token消耗会大幅上升。一位工程师借助Hermes分担部分岗位职责，每月消耗的token规模可达数百万M，长期累计总量可能达到上亿甚至接近十亿token。按月计算，单是token开销就可能花到几百元。云端方案倾向于使用参数量更大、架构更复杂的模型，且由于存储空间几乎可以无限扩展，对skill和memory的蒸馏优化缺乏足够驱动力，进一步推高了token成本。

混合式架构成为当前主流选择。基本逻辑是：难度较低的任务留在本地处理，复杂任务分发到云端。硬件瓶颈不高，内存几十GB，处理器约4核，搭配具备基础性能的GPU即可。由于大量基础工作在本地完成，总体token使用量被压低到约200万M的水平，运营成本一般只需几百元。

混合部署在硬件门槛和token成本之间找到了当前最务实的平衡点。

抛开记忆机制的脆弱性，HermesAgent在模型接入层的工程设计值得肯定。

它可以在超过200个模型之间切换，全部通过API接入，已提前完成对OpenAI、Anthropic、Ollama、vLLM、OpenRouter等海内外常见接口的兼容与对接，以统一方式封装不同模型，消除接口差别。在不重启服务、不修改任何代码的前提下，交互模式能够在运行过程中实现模型的动态装载和实时切换。

路由层引入OpenRouter，以单一密钥为基础，通过智能路由机制统一编排对各个模型的调用。同一把密钥覆盖的权限下，调用可被路由到200多种不同模型。系统还会依据模型参数量采用不同的推理优化方案：低于10B的轻量模型进行量化处理并限定上下文长度，自动关闭渐进式搜索等功能以避免精度问题；中等参数模型采用4比特量化方案。

这套架构让Hermes在模型兼容性和部署灵活性上建立了明显的工程优势。但问题在于，一个能调度200多个模型的系统，却给用户画像只留了200个汉字的空间。这种资源分配的失衡，很难用“设计取向”完全解释。

HermesAgent近期陷入了一场与EvoMap的公开争执。争议核心是自进化功能的方案相似性。EvoMap认为Hermes引入的自我演化方案与Evolver高度一致，并将开源许可从MIT改为GPL-3，对代码进行了高强度混淆。Hermes团队未直接回应是否借用，只表示“此前完全不了解Evolver”，并称不能因结果相似就认定抄袭。

“

这次争议折射出大模型赛道中一种典型的深层结构性冲突：小团队借助大厂技术沉淀，迅速推出有竞争力的产品，再以自己的名义发布，塑造出仿佛自主完成研发的印象。

这种现象在国内尤其常见。常见操作路径是：大厂先公开展示已验证的研究进展，小团队迅速跟进复现，完成后以自己的名义对外发布。有人视其为行业常态，也有人认为这正在对开源生态构成实质性威胁。有观点指出，今后大厂即使以开源方式发布模型，也可能在底层代码中加入加密设计，形成介于开放与封闭之间的“半开源”模式。

大厂内部研究拿到理想结果后，推进到实际业务应用通常需要约1年，对外公布往往再滞后约1年半，以维持技术优势。而小公司推进更机动、更迅速。这种效率差异被视为有助于生态成长，但也让“借鉴”的边界越来越模糊。

接下来两到三个月的变化值得密切留意：Hermes能否在版本迭代、执行路径改进和安全机制增强上拿出实质性的新动作，将决定它究竟是具备真正自研能力的长期项目，还是高度依赖他人成果的短暂产物。