“我用了 3 天就卸载 Hermes Agent”：他的 6 条批评，道出了所有 AI Agent 框架的通病
作者视角：AI 应用工程从业者
一、一条 132 赞的推文引发的思考
4月26日，一位叫 Versun 的独立开发者在 X 上发了一条帖子：
"再次卸载了 Hermes Agent，太傻了，和 OpenClaw 比差的不是一点两点，严重怀疑那些吹它聪明的人，有没有深入用过？我的版本号：V0.11.0"
帖子获得 132 赞、13 转发。在中文 AI 开发者圈子里，这是相当高的互动量。
更有价值的是他列出的 6 条具体问题。这不是一篇情绪化的吐槽，而是一份来自真实使用者的、有层次的 Bug 报告。我逐条读完，意识到他指出的不是 Hermes 一家的问题——这是当前所有 AI Agent 框架在工程设计上还没解决的核心难题。
二、6 条批评，其实是一份 Agent Harness 的评分标准
问题 1：工具调用不灵活，容易一条路走到黑
"一个方案行不通就会一直尝试，而不是换一个方案"
这是最难的问题，没有之一。
一个工具调用失败之后，Agent 应该怎么办？重试同一个方案？还是换思路？这背后需要 Agent 对自己的失败模式有建模能力：这次失败是参数错了、工具本身有 Bug、还是方向就走错了？
当前大多数 Agent 框架的做法是：让大模型自己判断。但大模型在"是否已经尝试了足够多次"这件事上出奇地无能——它缺少对自己行为轨迹的元认知。Hermes 显然没有在 harness 层做额外约束，所以模型就陷入死循环。
OpenClaw 处理得更好，但也不是完美的。这个问题的根本解法在于结构化的重试策略，而不是全权交给模型的直觉。
问题 2：上下文管理糟糕，超出就重开
"只要超出模型上下文，基本就是重开，没有任何之前会话的记忆"
上下文溢出的处理方式，是区分 Agent 框架工程质量的核心指标之一。
当前主流有三种策略：
- 截断：最简单，丢掉最早的内容，代价是失忆
- 摘要压缩：成本高，但相对保真
- 外部记忆：向量数据库或文件系统存储，理论最好，但工程复杂度最高
Hermes 的做法显然是截断加重开，Versun 的描述已经说明这一点。这在短任务上勉强可用，但放到 agentic loop 里，稍微复杂一点的任务就会丢失关键的中间状态，等于在没有短期记忆的情况下做长程决策。
问题 3：子代理管理糟糕，不审查子代理结果
"不会审查/核实子代理返回的结果"
这是多 Agent 架构下的信任问题，也是目前被讨论最少、但实际上最危险的设计缺陷。
当主 Agent 派出子 Agent 去完成子任务，子 Agent 返回的结果是可信的吗？主 Agent 应不应该校验？如果子 Agent 幻觉了一个"任务已完成"的响应，主 Agent 是否会照单全收？
Hermes 的回答显然是"是的，照单全收"。这在简单任务里看不出问题，但在生产级的 agentic 工作流中，不加校验的子代理结果是幻觉链式传播的温床。
主 Agent 应该对子代理实施类似代码 review 的机制——不是盲信，而是用确定性规则或二次询问验证关键结果。这个功能的缺失，说明 Hermes 在多 Agent 协同的设计上还停留在"信任所有人"的天真阶段。
问题 4：无法优雅地并发处理多条信息
并发能力是 Agent 框架从"好用的 REPL"进化为"真正的自动化系统"的分水岭。
单线程阻塞式处理对于一个开发助手够了，但对于一个 autonomous agent——同时监控多个数据源、并发执行多个子任务、聚合多路结果——就显得捉襟见肘。
目前 OpenClaw 对并发的支持做得更好，Hermes 在这一块几乎是串行的。从用户角度感受到的是"处理得不够优雅"，从工程角度看是任务调度器的设计缺失。
问题 5：对自己的配置文件比用户还陌生
"哪些能改哪些不能改，比我还陌生"
这一条看起来最轻微，却最能说明问题：Agent 对自身系统的元知识。
如果一个 Agent 连自己的配置文件边界都不清楚，我们凭什么相信它能可靠地修改文件系统、执行 Shell 命令、或者管理复杂的项目结构？
这实际上揭示了 Hermes 的训练数据或系统提示里缺少对自身架构的准确描述。一个工具不理解自己，就不可能做到可预期的行为。
问题 6：系统提示词和模型调教与 OpenClaw 有巨大差距
这是 Versun 列出的 6 条里最难量化、也最难追赶的一条。
系统提示词的质量，是当前 AI Agent 框架之间最大的、也最不透明的竞争维度。它决定了模型在工具调用边界、拒绝策略、错误恢复、多轮对话一致性等方面的行为，而这些行为的差异在基础模型层面几乎看不出来，只有在实际的 agentic 场景里才会暴露。
OpenClaw 在这一块的积累已经相当深厚——这不是几个月能追上的。Hermes 的"自进化"卖点还停留在营销层面，工程层面的提示词工程还差得远。
三、炮灰也没关系——Versun 的第七个洞察
有意思的是，Versun 在这条批评帖发出前一天，刚写了一篇截然不同的反思：
"这些工具当然是实验性的，甚至很多现在看起来很热闹的东西，过半年可能就没人用了。AI 时代的工具淘汰速度太快了，今天刚搭好的工作流，明天模型一更新，可能就直接原地报废。"
"但真正有价值的是：你在亲手折腾这些工具的过程中，会被迫理解它们到底是怎么工作的。"
他把这些工具称为"炮灰"，然后说：炮灰也没关系，在炮灰堆里摸爬滚打过的人，至少知道战场长什么样。
这是我见过对当前 AI 应用开发状态最准确的描述之一。
他举了自己开发 ShareThis.Chat 的例子：一开始 Skill 文档只有一句话，后来写到百来行——只是为了让 Agent 正确处理"分享聊天内容"这一个小功能。在这个过程里，他搞清楚了：模型能力的边界在哪，产品设计的取舍是什么，安全机制在什么时候会误伤正常功能（就是他踩的 Hermes 安全机制脱敏 token 的那个坑）。
这种认知，是看再多评测帖都学不到的。
四、我的判断：这场争论的真正意义
Hermes 和 OpenClaw 都不会是终点。
更重要的问题是：当一个更强的 AI Agent 框架出来的时候，谁能快速判断它好在哪、烂在哪、该信任它什么、不该信任它什么？
答案是那些现在在折腾各种框架、踩过各种坑的人。
对于 AI 从业者，我的建议：
-
用 Versun 的 6 条标准评估你在用的任何 Agent 框架：工具调用重试策略、上下文溢出处理、子代理校验、并发能力、自我元知识、提示词工程质量。这六个维度，能帮你快速找到框架的设计下限在哪。
-
不要被"自进化"这类营销词汇迷惑。自进化听起来很酷，但 Versun 用了 3 天就发现 Hermes 并没有真正进化。真正的 Agent 质量，藏在它出错时如何恢复、卡住时如何换思路、失忆时如何续命。
-
现在的选择不重要，积累的认知重要。这些工具大概率都是过渡期产品。但你在使用它们的过程中建立起来的直觉——哪些失败是模型能力问题，哪些是 harness 设计问题，哪些是提示词问题——会成为你在 AI Agent 领域持续有价值的核心资产。
最后引用 Versun 那句话作为结尾：
"炮灰也没关系。在炮灰堆里摸爬滚打过的人，至少知道战场长什么样。"
元芳们，你怎么看？
