Part 1：从系统缰绳说起

§01 工具很多，但问题一直没变

这两年看 AI Agent 工具，会有一个挺明显的感觉：大家都在往同一个方向加东西。

多工具调用、多模型路由、多智能体协作、自动化工作流……每一项单独看都合理，甚至必要，但组合在一起之后，体验并没有线性变好。

很多系统在某个 demo 里看起来很完整，但一旦放进真实使用环境，就会开始暴露一些老问题，比如行为不稳定、上下文漂移、或者“看起来能做很多事，但真正可靠的只有一小部分”。

Hermes Agent 出现在这个背景里。

它没有试图继续把“能力列表”拉长，而是往回走了一步，重新看了一遍 Agent 系统到底是怎么被约束住的。

---

§02 一个容易被忽略的事实

如果把一个 Agent 的运行过程拆开看，其实不复杂：

输入 → 推理 → 工具调用 → 输出

问题往往不在这条链本身，而在链条外面那一圈东西：

• 工具怎么被允许使用
• 任务怎么被拆分
• 错误怎么被记录
• 经验有没有留下来
• 下一次是否还能复用

这些东西通常被统一叫做“工程层”，但实际情况是，它们比模型本身更影响体验。

在一些内部测试（包括 Harness Engineering 的一些公开实验）里，只调整工具约束和反馈结构，不改模型参数，任务成功率就能出现比较明显的变化。

这个结果其实挺反直觉的，尤其是刚接触 Agent 系统的时候，会下意识觉得“模型更强就行”。

但现实更接近另一种情况：模型负责思考，系统负责让思考变得稳定。

---

§03 一个不太被认真对待的问题

传统 Agent 系统里，有一件事经常是“默认交给用户处理”的：

系统怎么长期保持一致性。

比如：

• 规则写在 prompt 里
• 行为约束写在配置文件里
• 经验靠人总结
• bug 修复靠人工补规则

这些东西能工作，但有一个共同特点：它们不自己变化。

时间一长，系统就会变成一种“静态结构”，需要人不断去维护它的状态。

这在工程上当然没问题，但在使用层面，会慢慢变成负担。

Hermes 在这里做了一点不太常见的处理，它把这些原本分散的部分收拢到系统内部，让它们在运行过程中自己更新。

这个思路后面会反复出现。

---

§04 Hermes 怎么看这件事

Hermes 的结构拆开看，其实还是那一套经典组件，只是放置方式变了。

可以大致对应一下：

传统系统组件	Hermes 里的位置
行为规则	Skill
工具控制	Toolset
运行反馈	学习循环
长期信息	三层记忆
多任务执行	子 Agent

如果只看表面，它和很多 Agent 框架并没有本质差异。

差别更多在一件小事上：

这些模块不是“外置拼装”，而是“运行中生成和调整的”。

比如 Skill，不是提前写好的能力清单，而是用着用着长出来的结构。

这个变化看起来不大，但会影响后续很多行为方式。

---

§05 Skill 这件事为什么重要

Skill 在 Hermes 里是一个比较核心的概念。

它不是配置，也不是 prompt 模板，更接近“行为记录”。

一个典型场景是这样：

你让系统完成一个任务，比如整理 GitHub 通知，或者做一次固定格式的输出。

第一次它会探索执行方式。

第二次开始有一定重复模式。

到第三次左右，它可能会把这套流程写成一个 Skill 文件，存到本地目录里。

之后再遇到类似任务，它就不会从头开始试，而是直接复用这套结构。

有点像人类做事的方式变化：

从“每次重新想”，变成“直接用习惯流程”。

不过这里有一个细节容易被忽略：Skill 不只是存结果，它也会在后续使用中被调整。

如果你对输出不满意，反馈会进入系统，下一次执行的时候，Skill 本身可能已经变了。

这个过程不是很显眼，但确实在发生。

---

§06 工具和边界

Hermes 内置了不少工具，大概可以分成几类：

• 代码执行
• 文件操作
• 网页检索
• 多媒体处理
• 任务调度
• 子 Agent 协作

再往外还有 MCP，用来接外部系统，比如 GitHub、Slack、数据库之类的服务。

工具多并不稀奇，关键点在于它们是“按需打开”的。

不是所有能力默认都暴露给 Agent，而是通过 Toolset 控制。

这个设计有个比较现实的好处：减少干扰。

如果一个系统什么都能做，它反而会在执行路径上变得不稳定。

有点像给人一把工具箱，但只在需要的时候打开某几格。

---

§07 多入口这件小事

Hermes 还有一个比较实际的设计：多平台接入。

Telegram、Slack、Discord、CLI 都可以作为入口。

表面上看是“支持多端”，但更关键的是：

这些入口共享同一套状态。

也就是说：

• Telegram 里说过的话
• CLI 里继续做的任务
• Slack 里补充的信息

都会进入同一个系统上下文里。

这个设计在实际使用里会更明显一点，比如你在手机上发起一个任务，回到电脑上还能继续，而不需要重新解释背景。

这种连续性，在很多工具里其实是缺失的。

---

§08 一个比较整体的视角

如果把 Hermes 的结构压缩成一条线，大概是这样：

执行 → 记录 → 归纳 → 结构化 → 再执行

循环不是一次性的，而是持续发生的。

系统在使用过程中逐渐改变自己，而不是保持固定形态。

有点像把“配置系统”换成了“成长系统”。

当然，这种系统也有自己的不确定性，比如它变得更依赖反馈质量，或者在早期阶段行为不稳定。

但整体方向是清晰的。

---

小结

Hermes 并没有引入太多新的概念，它做的更多是重新组织已有组件。

如果用一句比较直白的话描述：

它试图让 Agent 在使用过程中形成结构，而不是依赖人提前设计结构。

这个思路后面会在 Skill 和学习循环里体现得更明显。

如果想要《Hermes Agent从入门到精通》这本书的pdf，可以来这里直接下载