一个管流程，一个当大脑！两大AI代理架构正面硬刚，结果出人意料
我同时打开两个代码库，把窗口并排放在屏幕上。左边是OpenClaw，右边是Hermes Agent。这两个项目解决同一个问题：做一个持久运行、自托管的AI代理，跑在你的电脑上，通过你每天都在用的聊天软件和你对话。但它们到底怎么建的？这个问题在我脑子里转了很久。
OpenClaw的四层架构中网关作为中枢神经系统，Pi作为推理代理，还有事件队列和心跳系统。但光看一个项目不够。两个放在一起比，才能看出真正的设计选择。这次我带着一个具体问题进去：如果两者目标相同，为什么代码组织方式差这么多？
答案不在功能列表里，而在架构的骨架上。OpenClaw像一个交响乐团，网关是指挥，AI只是其中一个乐手。Hermes则像一个独奏钢琴家，AI自己就是全部，所有的工具、记忆、通道都直接挂在它身上。这个区别，决定了后面所有东西。
下面我会一层一层拆开给你看。从通道到网关，从代理循环到缓存策略，从工具执行到记忆系统，最后到会话存储和多代理协作。每个章节我都会先说核心结论，再逐步细化。准备好了吗？我们开始。
核心架构差异：身体与大脑的比喻
在OpenClaw里面，网关是老大。AI大脑作为独立运行时（叫Pi）挂在网关下面。网关决定什么事情发生，消息往哪里走，哪个代理处理什么任务。AI只是整个编排系统里的一个组件。打个比方，OpenClaw是一个完整的身体，Pi是大脑，但身体（网关）控制着大脑什么时候思考、思考什么。
而在Hermes里面，AI大脑就是主要的决策者。它上面没有网关这一层。代理直接拥有对话循环，其他所有东西——消息平台、工具、记忆——都挂在代理身上，而不是挂在控制平面上。这里没有身体的概念。大脑就是全部。这个差异解释了这两个代码库几乎所有的不同点。
为什么这个比喻重要？因为当你去读代码的时候，OpenClaw的入口点在网关服务，你需要先启动一个WebSocket服务器，然后它再拉起Pi子进程。Hermes的入口点就是AIAgent类，你实例化它，它自己就带着所有能力。一个是从外到内编排，一个是从内到外辐射。两种哲学，没有对错，但后果完全不同。
第一层：通道的归一化处理
OpenClaw支持25个以上的消息平台适配器。这些适配器做一件事：把各个平台来的消息归一化成标准格式。支持的平台包括WhatsApp、Telegram、Discord、Slack、iMessage、Signal，还有更多。每个适配器都是一个独立的模块，实现了相同的接口。当一条消息从WhatsApp进来，适配器会提取出发送者ID、消息内容、时间戳、会话ID，然后打包成内部统一的事件对象。
Hermes的做法类似，但实现方式更直接。它没有单独的网关层来处理通道，而是每个平台适配器直接继承BasePlatformAdapter类。这个基类要求子类实现normalize_message方法，返回一个标准的Message对象。然后适配器直接把这条消息传给AIAgent实例。没有中间商赚差价。这样做的优点是路径短，延迟低。缺点是你不能在多个代理之间灵活路由消息，因为每个会话固定绑定了一个代理实例。
在实际使用中，如果你需要把同一个Telegram账号的消息分发给多个不同的代理，OpenClaw的网关架构更合适。如果你只需要一个代理处理所有消息，Hermes的直连方式更简单。两者都没有错，只是适用场景不同。
第二层：网关与中枢神经
OpenClaw的第二层是网关。它是一个WebSocket服务器，充当整个系统的中枢神经系统。网关处理五种类型的输入：人类消息、心跳信号、定时任务、内部状态变更钩子、外部Webhook。在网关看来，所有东西都是事件。人类说了一句话是一个事件，心跳到了是一个事件，cron触发了也是一个事件。这种统一的事件模型让系统的扩展变得非常简单。
网关内部有一个事件队列。所有进来的事件先排队，然后被分发到对应的处理器。处理器可能是Pi代理，可能是某个插件，也可能是内部状态管理模块。网关还负责会话管理。每个会话有一个唯一的ID，网关维护会话到代理实例的映射。当一条消息进来，网关查一下这个会话当前绑定到哪个代理，然后把消息发过去。
Hermes没有这一层。它的AIAgent类内部实现了一个简单的循环，直接监听各个平台适配器传来的消息。没有统一的事件队列，没有WebSocket服务器，没有会话路由。每个平台适配器在收到消息后，会直接调用agent.receive_message方法。这个方法把消息塞进一个内部队列，然后主循环在下一轮迭代时处理它。这种设计省掉了几千行代码，但也意味着你不能在不修改代码的情况下动态添加新的消息路由规则。
第三层：代理运行时的循环设计
OpenClaw的第三层是代理运行时，也就是Pi居住的地方。代理循环在这里运行。流程是这样的：模型收到提示，决定怎么处理，调用一个工具，拿到结果，再决定下一步做什么。这是一个标准的ReAct模式。Pi作为一个独立的子进程运行，网关通过标准输入输出和它通信。这样设计的好处是，如果Pi崩溃了，网关可以重启它，不影响整个系统的其他部分。
Pi的循环没有内置的预算上限。理论上它可以无限调用LLM，直到提供商那边主动断开连接或者你手动停止。这种设计适合需要长时间运行的任务，比如监控一个网页的变化或者等待某个条件成立。但风险也很明显，如果不加控制，一次对话可能消耗几百次API调用，账单会让你心疼。
Hermes的循环完全不同。它是一个同步的while循环，带一个预算计数器。每个轮次最多允许90次LLM调用，就像一张预付费卡。当预算用完时，代理会获得最后一次“优雅调用”，用来总结它已经完成了什么。这种设计强制代理在有限的调用次数内解决问题，迫使它更高效地使用工具和推理。
循环里还有两个有趣的机制。第一个是中断检查：每一次迭代都会检查用户是否发了新消息。如果是，代理会优雅地停止当前任务，转而处理新消息。第二个是压缩机制：如果对话历史太长，Hermes会裁剪旧的工具结果，保护最近的消息，然后把中间部分总结成摘要。如果经过三轮压缩后还是太长，它会分裂会话，把新会话链接到父会话上。这些机制确保了循环不会因为历史过长而爆炸。
第四层：记忆系统的两种哲学
OpenClaw的第四层是记忆。它有两个文件：SOUL.md存储人格和行为规则，MEMORY.md存储关于你和你偏好的事实。人格文件定义了代理的说话风格、价值观、限制条件。记忆文件存储具体信息，比如你住在哪个时区、你喜欢用什么编程语言、你的项目命名规范。
除了这两个文件，OpenClaw还有一个梦境Dreaming系统，在夜间运行。这个系统分三个阶段：浅睡、快速眼动、深睡。在深睡阶段，系统会使用六个加权因子来评分和升级记忆，只有这个阶段才会写入MEMORY.md。这意味着每天晚上你的代理会额外消耗一批API调用来整理记忆。优点是记忆会逐渐优化，缺点是每天都有固定成本。
Hermes的记忆系统有三个文件，而不是两个。（最新版本OpenClaw 2026.4.14已经是三个了）
MEMORY.md存储你告诉它的事实，比如时区、语言、项目约定。这些内容在会话启动时被快照并冻结到系统提示里。代理可以在会话中更新这个文件，但不会中途修改提示。USER.md存储你是谁，主要是你的风格、偏好、什么会让你沮丧。这是一个内置的本地文件，也可以选择由外部提供商补充，比如Honcho、Mem0或者Hindsight。第三个是技能文件，由代理在完成复杂任务后自己写入，描述解决问题的步骤。
Hermes没有后台进程，没有额外的LLM调用。记忆系统在初次对话之后是免费维护的。你告诉它一次你的偏好，它就记住了，下次直接用。这种设计更适合不想为记忆支付额外API费用的用户。
提示构建与缓存策略
在循环开始之前，Hermes会构建一个系统提示，并在整个会话期间缓存它。系统提示包含人格设定、可用工具列表、记忆快照。因为内容在整个会话中不变，Anthropic的API可以在第一次调用后缓存大部分内容。Hermes在系统提示末尾和最后三条消息处放置了四个缓存断点。由于系统提示稳定不变，除了第一次调用外，后续每次调用都命中缓存。
OpenClaw走另一条路。它在每一轮都重新构建提示，只加载这一轮相关的技能。这样提示内容保持精简，每次调用发送的token更少，但缓存命中率低。两种策略的目标一样：控制API账单。一个靠减少每次发送的token量，一个靠复用缓存的token。
Hermes还有两个额外的缓存优化。它在发送给API之前，会把JSON工具调用参数的键按字母顺序排序。这样两次完全相同的调用即使键的顺序不同，也能命中缓存。另外，网关在同一会话中复用同一个AIAgent对象，所以缓存的提示在多次调用之间不会重新构建。这些优化加起来，对于长会话可以节省30%到50%的API费用。
工具执行与并行处理
Hermes内置了46个工具。每个工具在代码启动时自动注册，不需要配置文件。有些工具有快速可用性检查，比如你没有某个API密钥，那个工具就静默隐藏自己，而不是让整个程序崩溃。这种设计让用户不用手动配置，开箱即用。
工具在哪里执行是一个关键差异。OpenClaw提供两个选项：在你的机器上直接运行，或者在Docker容器里运行。Hermes提供了六个选项：你的机器、Docker、通过SSH的远程服务器、通过Singularity的高性能计算集群、Modal上的无服务器云函数、Daytona上的开发环境。这意味着Hermes代理可以真正地生活在这些环境里，而不是只在你本地跑。
并行处理方面，当模型要求同时做多件事，比如读三个文件并写一个文件，Hermes会先判断哪些操作可以安全地同时运行。读操作总是并行执行。写操作也可以并行，除非它们访问同一个文件。这种智能调度大幅减少了多任务场景下的总执行时间。比如读取三个文件，如果串行执行需要三秒，并行执行只需要一秒。
OpenClaw的并行能力依赖于网关的事件队列。多个事件可以并发处理，但工具执行本身没有内置的读写依赖分析。你需要自己在技能描述里写明哪些步骤可以并行。两种方式各有优劣，一个靠系统自动优化，一个靠用户手动指定。
技能系统：社区市场 vs 个人闭环
OpenClaw的技能是带YAML前置信息的Markdown文件。每个SKILL.md包含技能名称、触发条件、所需权限，后面跟着具体指令。用户写这些技能，然后分享到ClawHub上。其他人安装后就能用。技能一旦发布就永远保持不变。这种模式催生了一个庞大的社区市场，现在有几千个技能可用，覆盖从代码审查到天气预报的各种场景。
Hermes的技能系统架构不同。用户仍然可以手动写技能，但系统也设计成代理可以自己创建和改进技能。完成一个复杂任务后，代理会主动提议把这个方法保存为技能。如果你同意，它就写一个SKILL.md到~/.hermes/skills/目录。下次遇到类似任务，它会找到这个技能并遵循它。这就是人们常说的闭环学习：做、反思、创建技能、持久化、回忆、改进。
这个设计的后果很有意思。因为Hermes的技能是自生成并且随时间改进的，代理在积累经验后，完成类似任务时使用的工具调用次数会明显减少。技能文档里记录了确切有效的步骤，代理不需要重新发现它们。长期来看，这是一个可以衡量的API成本差异。比如你每周都要做一次代码库重构，前两次可能需要调用三十次工具，到了第五次，技能文档已经优化好，可能只需要十次调用。
会话存储与检索
OpenClaw把会话存在JSON或JSONL文件里，使用原子写入保证一致性。跨会话回忆使用LanceDB向量搜索。向量搜索擅长语义相似度，比如找到所有关于部署的对话，即使对话里没有出现部署这个词。但它在精确关键词搜索上比较弱，比如你要找包含特定错误代码的那一次对话，向量搜索可能给你一堆不相关的结果。
Hermes把所有内容存在SQLite里，开启WAL模式和FTS5全文搜索。模式版本已经到第六版，有完整的迁移脚本。当代理需要回忆之前的会话时，它会执行一次全文关键词搜索，扫描整个对话历史，然后总结结果。不需要单独的向量数据库。它还会返回匹配会话的链接，你可以直接跳回去查看原始对话。
Hermes还支持会话分支。/branch命令会创建当前会话的一个副本，你可以在副本里独立探索。数据模型原生支持树状结构，使用parent_session_id外键，不是只有线性历史。这意味着你可以从一个会话分支出多个实验方向，每个方向互不干扰，然后随时回到主干。这对于调试和A/B测试非常有用。
多代理协作：灵活编排与安全护栏
OpenClaw的网关有一个监督树。代理之间可以互相传递消息，深度可配置。任务流在上面增加了崩溃安全的编排。如果一个子代理失败了，父代理可以收到通知并决定下一步。这种设计适合复杂的多步骤任务，比如先爬取网页，再分析内容，然后发邮件，最后记录结果，每一步都可以用不同的代理来做。
Hermes为每个子任务创建一个全新的AIAgent实例。子代理只能使用父代理拥有的工具，不能使用被阻止的工具，比如委派、澄清、记忆、代码执行。最大深度是2。每个子代理有自己的IterationBudget，默认上限50次调用。这些默认值防止了指数的成本增长，同时保留了可配置性。如果你确实需要更深的嵌套，可以改配置，但你必须明确知道你在做什么。
两种设计的根本区别在于对失控的容忍度。OpenClaw给你灵活性，相信开发者知道自己在做什么。Hermes给你护栏，默认限制住最危险的操作。前者适合构建复杂的工作流系统，后者适合个人使用，不想某天早上一觉醒来发现代理调用了一万次API。
最终总结
读完两个代码库之后，我发现真正的架构差异不在功能列表里，而在结构性的选择上。
OpenClaw选择把网关作为承重墙，所有东西都挂在它上面。Hermes选择把AI代理作为主进程，所有东西都直接挂给它。一个像操作系统，一个像应用程序。两者都能完成工作，但代码的组织方式、扩展的方式、甚至调试的方式都完全不同。
OpenClaw适合需要精细控制消息路由和多代理协作的场景。它的网关设计让你可以在不停机的情况下替换代理、增加通道、调整路由规则。Hermes适合个人开发者，想要一个开箱即用、成本可控、会自己学习的代理。它的闭环技能系统在长期使用中会越来越聪明，而SQLite存储让你不需要额外维护向量数据库。
两个项目都是开源的，都可以在GitHub上找到。我把两个代码库并排放在屏幕上看了三天，学到了两种完全不同的设计哲学。希望这个对比能帮你在构建自己的AI代理时做出更明智的选择。