从openclaw和Hermes-agent看通用Agent的现状

截至2026.4.13，OpenClaw 和 Hermes Agent 在 GitHub 分别有 356k、71.1k 个 star，可以分别作为主流代表。

Hermes 的优势

如果只看功能，Hermes 和 OpenClaw 貌似差不多，那我们为什么还要 Hermes 呢？

NousResearch 把 Hermes 定位为能和你一起成长的 AI agent，这个巧妙地比喻其实隐含 Hermes 具有更长时间的记忆力，并且会越来越贴合用户的工作习惯，会越来越好用。

此外， Hermes工程稳定性更强，异常兜底通常更完整，长链路任务成功率更高。可观测性也更好，和 Hermes 对话时，它会告诉它用户现在在干什么，更便于调试。

如此看来，Hermes 隐隐有取代 OpenClaw 的趋势。

一次偶然体验

听到如此震撼的效果，我便本地部署尝试了一下 Hermes。最大的体验感就是可观测性，Hermes 会把正在执行的小步骤汇报给你，对读过的消息更是会给出一个“OK”符号，而 OpenClaw 却只会直接返回结果。

相应的是，Hermes 处理问题的效率却远低于 OpenClaw，我让其处理一个简单的查阅信息任务，Hermes 处理时间超过5分钟，相应的 OpenClaw 只需要30秒。这引起我对 Hermes 性能的思考。

为此我做了实验，模型为Minimax M2.7，在Gaia中的301个任务中，

指标	OpenClaw	Hermes
任务数	301	301
success	286	41
timeout	15	251
error	0	9
平均耗时	36.432s	233.402s

可以见得 Hermes 在未磨合时的稚嫩状态下，处理问题的能力远不及OpenClaw。

为什么会出现这种结果

「可观测性」不是免费的
Hermes 会把过程拆成小步骤给你看，这也意味着更多中间状态、更多日志与更多回合，在强时限任务里会被放大成更长的墙钟时间。OpenClaw 在“快”这个维度上可能更占便宜，但代价是更难复盘失败原因。

冷启动与磨合
Hermes 强调记忆与长期贴合；而一次基准跑分是短会话、强任务、弱个性化的组合。若系统需要几轮交互才能把工具链、偏好、策略调到稳态，这种情况下 Hermes 会吃亏。

我相信，在长期任务下，Hermes 的能力、稳定性、好用性还是会超过 OpenClaw。

不过体验里，有一点是共通的：两边都是在「模型 + 工具 + 网关 + 长链路」上叠出来的系统。OpenClaw 在 GAIA 上更快、更稳，不等于通用 Agent 已经可靠；Hermes 在可观测性上更友好，也不等于失败就更少。把两个具体产品放在一起看，*它们暴露的是同一类工程问题，只是程度与形态不同。

所以下面我不再单独苛责某一家，而是谈「通用 Agent」这一品类眼下普遍缺什么。

现在通用 Agent 的缺点

现在所谓的“通用”多是演示层面的通用：能接很多工具、能跑很长对话，但落地时最先撞上的往往是可靠、安全、成本三件事。

通用 Agent 真正的门槛是“可靠”

个人助手可以偶尔翻车，一旦你把 Agent 当成自动化基础设施，看起来会做和能长期稳定做好就是两码事。

什么叫不可靠：

• 同任务不同结果：提示词、工具、模型任一环节抖动，输出就飘；没有严格回归，很难说「上线了就是对的」。
• 不可复现：同样条件下，面对同样的问题，甚至很可能输出不同结果，很难认为是稳定的。
• 长链路放大误差：一步工具超时或返回空，后面要么挂死、要么瞎编；用户往往要人工兜底。
• 失败不可见：有的系统「快」但难复盘，出了问题只能猜；有的系统步骤多，墙钟时间又长——两种都不等于可靠。
• 系统未必按预设工作：有时候你预设里面要求系统调用某类工具，但模型依旧按照自己的想法我行我素。

Anthropic CEO Dario Amodei 说：“行业外的人经常会在得知一个事实后感到惊讶甚至不安：我们并不真正理解我们自己创造出来的 AI 系统是如何工作的。”

OpenClaw 仓库里曾有用户报告：工具调用异常时 Agent 长时间无响应，甚至描述为单日数小时不可用，恢复依赖删会话、重启网关一类重操作——这类 issue 讨论的就是工程可靠性，与模型不是一回事。

另一类是故障转移没按配置生效：主模型报错时未自动切到 fallback，用户只能手动改配置。维护者后来在 issue 里说明已把未知模型类错误纳入 failover 路径并关闭工单。

Hermes 一侧也有同类问题可举：例如有 issue 提到网关重启时的内存刷写曾可能覆盖用户已确认写入的内容，说明“会记忆”的产品也要过持久化与并发写入这一关。

通用 Agent 若不能做到可靠，再强的单次演示也只是 demo；可靠才是从玩具走向工具的分水岭。

安全是个大麻烦

通用 Agent 的安全麻烦，不是“会不会被黑”这么简单，而是你为了让它有用，必须给它工具权限；权限一旦给出去，风险会从模型层一路传导到文件系统、网络、凭证和外部系统。

我现在更认同一个判断：Agent 的安全问题，核心是“能力与约束不对称”。我们希望它能做复杂任务，但约束机制（沙箱、审计、最小权限、审批流）还没跟上能力增长。

典型风险可以分四类：

• 工具链注入：提示词注入、网页恶意内容、文档里的“伪指令”会沿着检索/工具调用链放大。
• 过度授权：为了追求自动化，把文件写入、终端执行、外网请求一股脑打开，结果边界消失。
• 跨系统污染：一个环节拿到错误或恶意数据，后续 Agent 可能当成事实继续执行，形成连锁错误。
• 审计缺位：任务看似完成，但没有可追踪的“谁在什么时候用什么工具改了什么”，事故后难复盘。

这也是为什么很多一线实践者会强调“人类操作员”仍然必需。Simon Willison 说“没有熟练的人类操作者，这种‘Agent’基本就是无效的，几乎等于不存在。”。

所以，眼下更现实的做法不是“放权给 Agent”，而是“分层放权”：

• 默认只读，写操作必须审批；
• 高风险工具单独隔离（容器/沙箱）；
• 密钥最小权限、短周期轮换；
• 关键操作全量日志，可回放、可审计；
• 明确“自动可做”和“必须人工确认”的边界。

换句话说，通用 Agent 不是不能用，而是不能按“全自动员工”去用。谁先把安全问题解决，谁才有资格谈规模化落地。

成本是无底洞

说到成本，往往想到模型成本，但成本不止包含模型成本，不同成本要用不同维度对比。

模型成本

Anthropic 给 Claude Opus 4.6 的 API 标价是 输入 $5 / 百万 token、输出 $25 / 百万 token。

1）日常聊天：假设你一次来回是「约 3000 token 输入 + 800 token 输出」（大概就是几屏字、模型回一小段）。一天聊 30 个来回，模型侧大概也就一两美元以内晃。

2）vibe coding：你把整段代码、报错栈、测试输出反复喂回去，一轮里输入往往先冲到几万 token 很常见。
换句话说：vibe coding相比聊天有量级的成本增长，尤其老让模型重写，模型成本一下就高了。

3）通用 Agent：Agent 会把「计划—工具—观察—再计划」跑成很多轮。你可以把它理解成：把上面 vibe coding 里最费钱的那部分，自动化地多跑几遍。
举个保守的纸面推演：一个任务里模型来回 12 轮，平均每轮 25k 输入 + 6k 输出。单轮约 (0.125 + 0.15 = 0.275) 美元，12 轮就 大约 3.3 美元，还没算工具失败重试、子任务拆分、同一轮里重复读大段上下文。
所以 Agent 的模型成本是轮次 ×（上下文 + 输出长度），体感上是指数级的成本增长。

所以一般来说通用 Agent 都会采用如 minimax 这种便宜的模型，这样虽然模型成本下降了，但是模型性能不好又会导致其他成本上升。

工具成本

通用 Agent 要 常驻网关、可执行环境、日志与监控等。这些是固定成本。单单一项可能几块钱，但多项加在一起也不可小觑。

治理成本

自己玩的话这一项不必考虑。

小团队接入真实数据：要开始谈权限、审计、回滚、谁批准 Agent 发邮件/改库，合规、留痕、事故复盘——这些都不在 API 账单里，但会吃掉大量工程时间。

人力成本

越自动，越要人盯着。

模型能写代码以后，人并没有消失，只是换了一种累法：从“敲键盘”变成“验收、兜底、改提示、处理模型犯蠢后的烂摊子”。
这类成本很难精确到美分，但很好理解**

机会成本

团队如果把一个不适配 Agent 的流程硬自动化，常见结局不是“失败”，而是长期半死不活，偶尔很惊艳，经常要人擦屁股，维护成本把收益吃光。

这么多成本叠加在一起，足以见得成本是无底洞了。更可怕的是很多人没认识到这点，小红书上经常刷到所谓“警惕免费上门安装OpenClaw，收到账单崩溃了”这样的文章。

结构性不成熟

如果把前面的对比压成一句话：今天通用 Agent 的问题，便是“它能不能在真实世界里稳定、可控、可持续地做事”。
前面讲的可靠性、安全性、成本，表面上是三类问题，底层其实是系统还没形成工程闭环。

所以，现阶段通用 Agent 更像“玩具”，而不是“可靠的基础设施”。
这并不代表它没价值，恰恰相反：它已经值得投入，但必须有一个更硬的判断标准。

满足什么条件，我们才可以说通用 Agent 进入了成熟期？

什么时候我们能说通用 Agent 成熟了？

我自己的标准很简单，看它能不能在普通团队里，连续稳定地跑业务。

可以用五条硬标准来判断：

1）可靠性
同类任务的成功率、超时率、回滚率要稳定在可接受区间，如果还经常出现“今天行、明天不行”，就谈不上成熟。

2）可恢复
成熟系统必须具备可观测、可告警、可回滚、可恢复，一次任务失败后，能否在不清空上下文、不人工大规模介入的情况下恢复。

3）安全性
可以让广大用户群体了解到怎么配置是安全的，放权要到什么地步，模型遇到疑似有安全问题的地方要及时呼唤人工介入，稳定运行不会泄露隐私机密，不会对操作员造成损害。

4）低成本
如果 Agent 带来的节省，长期覆盖不了新增维护成本，它就只是昂贵的玩具。

5）可承接
成熟的通用 Agent 不该只在“最懂它的那一个人”手里有效，团队里普通工程师能接手、流程文档能传递、值班体系能承压，才算真正落地。

通用“Agent”仍有很长的路要走。