Hermes 这次更新真正厉害的，不是“强 10 倍”，而是补齐了 Agent 的四层闭环

一条介绍 Hermes 更新的视频，用一句很抓眼球的话开场：“这波更新让 Hermes 强了 10 倍，4 个炸裂功能详解。”

“10 倍”当然更像传播用语，不是严谨的基准测试结论。但视频选出的四项能力很值得认真看：

说明：本文依据该视频的公开标题、章节摘要和 Hermes 官方文档进行拆解，并非逐字转写；涉及命令与现行能力的部分，以发布时的官方文档为准。

  1. Mixture of Agents（MoA，多模型协作）
  2. 自我学习与技能沉淀
  3. 背景委派与并行执行
  4. Completion Contract + Judge（完成契约与审判式验收）

它们不是四个彼此独立的新按钮，而是恰好补齐了 Agent 从思考到交付的一整条链路：

MoA 提高判断上限，Skill 形成经验复利，Delegation 提高执行吞吐，Judge 守住完成标准。

这才是这次更新最值得关注的地方。

一、为什么传统 Agent 总让人“不敢放手”

很多人第一次用 Agent 时，最震撼的是它能调用工具、改文件、查资料、执行命令。但用久以后，真正让人抓狂的问题通常不是“它不会做”，而是下面四个：

  • 遇到复杂问题时，它可能只沿着一个方向想，决策质量不稳定；
  • 同类任务做过一次，下次仍然从头摸索；
  • 大任务只能一件件串行推进，等待时间很长；
  • 最危险的是，它可能把“写完一段话”当成“任务已经完成”。

这四个问题分别对应判断、学习、执行和验收。

如果只升级底层模型，可能会改善第一项，却无法自动解决后三项。一个真正可用的 Agent 系统，需要的不只是更聪明的模型，而是一套能持续学习、拆分任务、并行推进、验证结果的工作机制。

Hermes 这四项能力，刚好沿着这条链路展开。

二、MoA：从“一个模型拍板”到“多模型会诊”

MoA 的全称是 Mixture of Agents。

在 Hermes 中，它可以被理解成一个虚拟模型提供方：多个参考模型先并行给出分析，再由聚合模型综合这些意见，生成最终回答并执行工具调用。

这和简单地问三个模型、再手工复制粘贴不同。参考模型负责提供不同角度，聚合模型仍然处在正常的 Agent 循环里，可以继续调用工具、接收结果、迭代执行。

它适合什么任务

MoA 最适合那些“单一路径容易漏掉关键问题”的高价值任务，例如：

  • 复杂技术方案评审；
  • 合同或政策风险检查；
  • 产品战略与选型；
  • 代码安全审查；
  • 重要内容发布前的事实与表达双重评审。

简单问答不必每次都上 MoA。因为多模型意味着更多调用、更高成本，也会受到最慢参考模型的等待时间影响。

怎么开始使用

先配置一个 MoA preset：

hermes moa configure

对单个困难问题临时使用：

/moa 请从技术可行性、成本、隐私和维护风险四个角度评审这个方案

如果希望接下来整段会话都使用某个 MoA preset：

/model <preset> --provider moa

实践中可以限制参考模型输出长度，让它们只提供关键判断，把最终组织和工具执行留给聚合模型。

别把 MoA 神化

多个模型不等于自动正确。

如果多个模型共享同一种盲点，聚合结果仍可能出错；如果任务本身缺少数据，三个模型也只是在不同方向上猜测。因此，MoA 应该提升“提出备选解释和发现风险”的能力，但最终结论仍要落到真实工具、数据和测试上。

三、自我学习与技能：把成功经验变成组织资产

传统对话式 AI 最大的浪费之一，是每次都在重新推导同一个流程。

今天好不容易走通一次部署，明天换个会话，它又重新踩坑。对个人来说这是时间浪费；对机构来说，这意味着经验无法沉淀，质量依赖某一次会话是否“状态好”。

Hermes 的技能系统解决的不是“让模型记住更多资料”，而是把可复用的做事方法保存成按需加载的程序性知识。

/learn 能学什么

它可以从多种来源学习：

/learn https://example.com/docs

也可以学习本地资料：

/learn 某个 SDK 文档目录，重点掌握认证、分页和错误重试

还可以把刚刚走通的流程沉淀下来：

/learn 我们刚才完成的上线流程

对于体量很大的资料，好的做法不是把全部内容塞进一个巨大文件，而是保留一个精简索引，再把章节和专题拆到按需加载的参考文件里。这样既能保留知识，又不会让每次对话都背上高昂的上下文成本。

Skill 真正有价值的前提

一个技能要成为资产，至少要满足四个条件：

  1. 可触发：清楚说明什么情况下应该使用；
  2. 可执行：步骤具体，不是泛泛的经验总结；
  3. 可验证：写明如何确认结果真的成功；
  4. 可维护：外部命令、接口和环境变化后能及时修订。

如果只收集不维护，技能库很快会变成另一个资料坟场。

所以，技能的核心不是“存”，而是“在真实任务中复用、发现问题、立即更新”。

四、背景委派：不是多开几个 Agent，而是把任务正确拆开

复杂任务经常包含多个彼此独立的工作流。

例如做一份行业报告，可以同时进行：

  • 政策与官方资料检索；
  • 竞品对比；
  • 用户评价采样；
  • 数据核对；
  • 表达和结构审稿。

如果所有事情都让一个 Agent 串行完成，等待时间会很长，主会话的上下文也会越来越重。

Hermes 的 delegate_task 可以生成拥有独立上下文和终端会话的子 Agent。多个子任务可以并行执行，父 Agent 最后只接收各自的总结，再统一合并。

最容易踩的坑：子 Agent 不知道“刚才发生了什么”

子 Agent 使用全新的对话上下文。它不会自动知道父会话里的错误、文件、约束和决定。

所以这种委派很差：

修复刚才那个错误

更好的委派必须把目标和上下文写完整：

目标：修复某模块中的空值错误并通过对应测试。
上下文：错误位置、触发条件、项目技术栈、允许修改的文件、测试命令、不得改变的接口行为。

并行工作流的正确顺序

  1. 先判断哪些任务真正独立；
  2. 为每个子任务提供完整目标、上下文和验收标准；
  3. 并行执行；
  4. 收集结果后检查冲突、重复和证据质量；
  5. 由父 Agent 做最终整合与验证。

并行的价值来自“正确拆分”，不是来自“同时启动更多模型”。任务之间高度依赖时，盲目并行反而会增加合并成本。

五、Completion Contract + Judge：把“做完了”变成“证明做完了”

四项能力中，我认为最值得所有团队优先复制的是这一项。

很多 Agent 的失败不是不会执行，而是过早停止：

  • 写了代码，但没有运行测试；
  • 生成了文件，但没有检查能否打开；
  • 发起了请求，但没有核对 HTTP 状态和业务结果；
  • 下载了数据，但没有检查条数、字段和缺失值；
  • 写完文章，却没有做事实核对和脱敏。

问题的根源是：任务只有“做什么”，没有定义“什么叫做完”。

Hermes 的持久目标和完成契约把交付标准显式化。一个好的契约通常包含：

  • Outcome：最终必须成立的状态；
  • Verification：用什么命令、测试或产物证明；
  • Constraints：不能破坏什么；
  • Boundaries：哪些范围可以动；
  • Stop when：遇到什么情况必须停下请示。

可以让 Hermes 起草契约：

/goal draft 把认证模块迁移到新的令牌方案，并确保原有客户端不受影响

也可以直接写清楚：

/goal 完成数据清洗并生成报告
verify: 测试命令通过，报告文件可打开，记录数与源数据一致
constraints: 不覆盖原始数据
boundaries: 只处理指定目录
stop when: 发现源数据字段定义冲突

对于必须通过的检查，还可以加入质量门：

/goal gate add <验证命令>

每轮工作后，轻量 judge 会判断目标是完成、继续还是等待。只有验证条件得到具体证据支持，任务才应该结束。

Judge 也不是绝对正确

Judge 可能误判：

  • 假阳性：它说完成了，实际还有遗漏；
  • 假阴性：工作已经完成，它仍要求继续。

解决办法不是取消验收，而是把完成标准写得更可判定。模糊目标只能得到模糊判断，具体测试、文件、退出码和数据指标才是可靠的验收面。

六、四项能力为什么必须一起看

单看每项功能，都不算完全陌生。但把它们放在一起，会形成一个很清晰的闭环：

层级能力解决的问题
决策层MoA一个模型容易遗漏角度
经验层Skill / Learn同类任务反复从零开始
执行层Delegation复杂工作只能串行推进
质量层Completion Contract + JudgeAgent 容易提前宣布完成

真正成熟的工作流应该是：

  1. 用 MoA 评审复杂决策；
  2. 把验证过的流程沉淀为 Skill；
  3. 把独立工作流委派给子 Agent 并行推进；
  4. 用 Completion Contract 和质量门验收最终结果；
  5. 把这次新发现的坑更新回 Skill。

这时，Agent 才不再只是一个“会调用工具的聊天机器人”，而更像一个能学习、协作和自证交付的工作系统。

七、对个人和机构最实际的落地方式

不要一上来就重做全部流程。选一条高频、可测量的任务做试点，例如热点解读、周报、竞品研究或内容发布。

第一步：建立基线

记录现有流程的：

  • 总耗时；
  • 人工介入次数；
  • 返工次数；
  • 发布前发现的错误；
  • 最终交付是否有可验证证据。

第二步：接入四层框架

  • 选题和风险用 MoA 评审；
  • 成功步骤沉淀为 Skill；
  • 搜集、核对、审稿拆成并行子任务；
  • 用完成契约约束标题、长度、来源、脱敏和文件格式。

第三步：比较，而不是喊口号

两到四周后再比较：

  • 周期缩短了多少；
  • 返工是否下降；
  • 错误是否减少；
  • 模型成本是否值得；
  • 哪些步骤适合自动化，哪些仍需人工判断。

这样才能回答“到底强了多少”，而不是停留在“10 倍”这种无法复核的表达上。

八、这条视频的内容结构也值得借鉴

视频本身采用了一个很适合技术更新的传播结构：

  1. 先给出巨大收益；
  2. 用明确数字承诺信息清单；
  3. 每项功能对应一个具体痛点；
  4. 最后把功能收束成“可以放手”的产品价值；
  5. 用评论区提问收集下一批选题。

可以直接套用成下面这个骨架：

这次 [工具] 更新，不是多了几个按钮，而是解决了 [最抓狂的问题]。
我把最重要的变化压成 [N] 个：
第一，[功能1] 解决 [判断问题]；
第二，[功能2] 形成 [经验复利]；
第三，[功能3] 提高 [执行吞吐]；
第四，[功能4] 守住 [交付标准]。
真正重要的不是参数，而是它让你从“必须一直盯着”变成“可以按证据验收”。

如果想让技术受众更信服，只需再补一层：每个功能都配一个真实任务，展示输入、过程、成本、时间和最终验证结果。

结语

Hermes 这次更新真正值得关注的，不是某一个模型突然变得无所不能，而是它开始把 Agent 的关键短板系统化补齐。

它让多个模型参与判断，让成功经验被保存，让独立任务并行推进，也让“完成”必须接受证据检验。

未来 Agent 的竞争，不只是谁回答得更像专家，而是谁能形成更可靠的闭环：

想得更全面，做得更并行，学得能复用，交付可验证。

这四件事同时成立，才是真正意义上的“可以放手”。

参考资料