为什么会觉得 Hermes 比 OpenClaw 更快、更“会干活”

为什么用户会觉得 Hermes 比 OpenClaw 更快、更“会干活”？

最近看见了一个比较搞笑的评论：”三月养虾，四月养马“。继Openclaw后Hermes再一次爆火，我翻阅了论坛上对于他的评价，基本好评是占大多数的，聚焦于两个点：① 过程更看得见 ② 速度更快了

这里说的快并不是模型的响应快了。而是任务复杂起来也不至于明显拖垮

因此，为了去验证这一说法，我也去拆解了一下Hermes的源码，以架构师的身份去了解他为什么快了，大家以后在做相应的开发时也可以将这种思路作为提示词，设计出效率更高的agent

1️⃣ 回归正题，openclaw为什么慢呢？这是因为它要反复经历这样一条链路：想一下，调一个工具，读结果，再想一下，再调工具，再读结果。轮数一多，延迟就会不断叠加。最后拖慢系统的，未必是某一轮特别慢，而是整条链路来回太多。

为了解决这个问题呢，Hermes 把原本需要模型一轮轮亲自发起的工具调用，折叠进一个脚本执行回合里。例如，原本我们的任务可能需要”先搜网页→再筛页面→抽取内容→汇总“这一链路，模型逐步的去执行这一链路，但 Hermes 把这一流程组织成一个小程序，模型先完成流程编排，再把执行交给程序， 然后让程序自己去调用工具，最后把必要结果再回给模型。

这样子做的好处就比较明显了，模型不需要一次一次的去执行命令，就像是做了规划直接让程序执行，减少了来回的轮数。

2️⃣ 除了减少轮数，我们可以发现其实很多复杂任务真正花时间的地方是在各种 I/O 上：读文件、搜内容、抓网页、查记录、访问外部资源。

如果这些动作全都串行执行，那么等待时间就会被线性叠加。但如果其中有一部分本身彼此独立、可以并发，那么总耗时就会更接近“最慢的那个”，而不是所有动作时间简单相加。

这也是我们用hermes上感觉更快的原因了，因为它不是每一步都串行执行，而是更像一个真正的运行时系统，在判断哪些操作可以并行推进。并且hermes上也定义了工具之间的联系:

• 明确绝不并行的工具
• 明确只读、可并行的工具
• 按路径隔离后可并行的文件工具

这说明 Hermes 对“同一轮多个工具调用”不是 naïve 地一个个跑，而是会判断是否可并发。