从零理解如何构建 AI Agent

Appearance

11｜如果你也想做一个自己的 Agent：应该先抄 Hermes 的哪几层 ​

先回答一个最现实的问题 ​

到这里，这本电子书其实已经把 Hermes Agent 的主干拆得差不多了。

你已经看过：

  • 它的全局地图
  • 它的核心循环
  • 它的工具系统
  • 它的记忆与会话连续性
  • 它的 CLI 与 Gateway
  • 它的 Skills
  • 它的子 Agent
  • 它的 cron 与后台自动化
  • 它的安全约束

问题来了。

如果你现在也想做一个自己的 Agent，难道要把 Hermes 整套都照着搬一遍吗？

当然不是。

Hermes 已经是一个相对完整的 runtime 了。对大多数初学者和独立开发者来说，真正重要的不是“完整复刻”，而是：

看清楚它哪些层是基础骨架，哪些层是第二阶段增强，哪些层是更成熟后的补强。

所以这一章就专门回答这个最实际的问题：

如果你也想做一个自己的 Agent，应该先抄 Hermes 的哪几层，顺序又该怎么排？

1. 先给结论：不要从最炫的层开始抄，要从最能决定系统形状的层开始抄 ​

很多人看完前面几章，最想先抄的往往是这些：

  • Skills
  • 子 Agent
  • 多平台 Gateway
  • Cron 自动化

因为这些看起来最像“高级 Agent”。

但如果你真的一开始就从这些层下手，很容易出现两个问题：

  • 核心骨架没站稳，外围能力越加越乱
  • 演示效果很炫，但系统很快进入不可维护状态

所以我先给一个非常明确的结论：

如果你是第一次认真做 Agent，优先抄的不是最花的能力，而是最能决定系统形状的几层。

在我看来，Hermes 最值得你分阶段抄的顺序是：

  1. 核心循环层
  2. 工具编排层
  3. 会话与状态层
  4. 安全边界层
  5. 接入层
  6. 技能与委托层
  7. 自动化层

这个顺序不是按“炫酷程度”，而是按“系统站得住的必要性”排的。

下面分别解释。

2. 第一优先级：先抄 run_agent.py 背后的核心循环思想 ​

如果你只能先学 Hermes 的一层，那就是核心循环。

原因很简单：

Agent 之所以是 Agent，不在于它有多少工具，而在于它是不是一个稳定的“模型—工具—模型”闭环。

前面第二章我们已经拆过，Hermes 在 run_agent.py 里真正建立起来的，是一条比较完整的执行链：

  • 装配 system prompt
  • 组织 messages
  • 调模型
  • 解析 tool calls
  • 执行工具
  • 把结果回填
  • 继续循环直到收束

如果这层骨架不清楚，你后面加再多能力都只是堆附件。

所以第一层最值得抄的，不是代码细节，而是这几个结构原则：

  • 核心循环要有明确闭环
  • system prompt 装配要成层
  • 工具结果必须回到消息流
  • 一次用户请求要允许多轮内部推进
  • 错误、压缩、中断都要被循环层接住

如果你的项目还停留在“一次请求调一次模型”的形态，那优先把它演进成真正循环。

3. 第二优先级：再抄 model_tools.py + toolsets.py 这层工具编排 ​

一旦有了循环，下一步最值得学的就是 Hermes 的工具系统。

注意，我说的不是“去抄所有工具”，而是抄它的编排方式。

Hermes 在这层最关键的设计不是工具数量，而是：

  • 工具模块各自实现
  • import 即注册
  • 统一 registry 收口
  • model_tools.py 做发现、筛选、schema 组装和分发
  • toolsets.py 提供能力裁剪

为什么这一层要早抄？

因为它会直接决定你的系统以后会不会很快变乱。

如果没有统一工具编排层，你的项目通常会变成：

  • 核心循环直接 import 某些工具
  • CLI 和 API 各自维护一套工具列表
  • 哪些工具对模型可见没有统一规则
  • 某些平台想裁剪能力时没有收口点

这会让后续扩展越来越痛苦。

所以第二层建议非常明确：

你不一定要有 Hermes 这么多工具，但一定要有 Hermes 这种“工具能力统一收口”的思想。

4. 第三优先级：尽早抄会话与状态层，不要等产品做大了再补 ​

很多人做 Agent 的早期习惯是：

“先把效果做出来，状态以后再说。”

这是一个特别常见、也特别危险的延迟决策。

因为一旦你的 Agent 开始有人连续使用，“状态以后再说”很快就会变成：

  • 历史迁不动
  • 会话恢复逻辑全是临时兼容
  • 平台接入后 session 语义对不上
  • 记忆和历史混在一起

Hermes 给你的最大启发之一，就是会话和状态不要拖太晚。

至少你应该尽早想清楚：

  • 会话 ID 怎么定义
  • 历史怎么持久化
  • 跨会话搜索要不要有
  • 长期记忆和历史记录怎么区分
  • resume / branch 这种行为未来怎么支持

Hermes 在这层的典型参考就是：

  • hermes_state.py
  • tools/session_search_tool.py
  • tools/memory_tool.py
  • gateway/session.py

你不一定一开始就全部照抄，但建议尽早把“会话是一等状态对象”这个判断建立起来。

5. 第四优先级：安全边界层应该比你想象中更早进入架构 ​

这是我最想强调的一点。

很多人会把安全边界放在项目后期，觉得等功能稳定了再补。

但如果你的 Agent 一开始就准备碰这些面：

  • 终端
  • 文件
  • 浏览器
  • 发消息

那安全边界就不应该拖。

Hermes 最值得抄的不是某个具体 regex，而是它的结构思路：

  • 高风险命令先审批
  • 路径要有共享校验 helper
  • 参数位也要防注入
  • 后台进程要可观测、可清理、可恢复

也就是说，你最少应该尽早有：

  • danger guard
  • path guard
  • 副作用隔离意识

如果这一层完全没有，你前面每加一个新能力，其实都在给系统增加新的不受控风险面。

6. 第五优先级：接入层要做，但可以分阶段做 ​

很多初学者一开始就会纠结：

我要不要像 Hermes 一样一口气做 CLI、Telegram、Discord、Slack？

我的建议是：不用。

但你应该尽早抄 Hermes 的“接入层解耦”思想。

什么意思？

就是即使你现在只有一个 CLI，也最好别把 CLI 写成系统本体。

你应该预留这种结构：

  • 核心运行时独立
  • CLI 只是一个入口
  • 将来如果要接 Web、Bot、IDE，不必重写主循环

所以在这一层，值得抄的是：

  • cli.py 不是本体
  • gateway/run.py 是接入总线而不是业务核心
  • session context 负责把平台语境注入运行时

你完全可以分阶段做：

  1. 先做 CLI
  2. 再做一个最需要的平台接入
  3. 等会话语义稳定后再扩更多入口

这比一开始贪多更稳。

7. 第六优先级：Skills 和子 Agent 是“第二阶段放大器”，不是第一阶段地基 ​

前面两章我们讲了 Skills 和 delegation，它们确实很强，也很像高级 Agent。

但我还是建议把它们放在第二阶段。

为什么？

因为它们的价值，建立在前面几层已经比较稳的前提下：

  • 没有稳定核心循环，子 Agent 只是把混乱复制出去
  • 没有统一工具系统，子 Agent 的能力边界会更难控
  • 没有状态层，技能和子任务结果都难沉淀

所以我的建议是：

Skills 适合在什么时候引入？ ​

当你已经发现：

  • 核心 prompt 越来越长
  • 某类任务流程被频繁重复
  • 某些专项经验需要独立演化

这时候再做 skill，收益最大。

子 Agent 适合在什么时候引入？ ​

当你已经发现：

  • 复杂任务明显可以拆子问题
  • 主代理上下文负担开始过重
  • 某些任务调查与实现可以明确分工

这时候再做 delegation，收益也更明确。

所以这两层很重要，但它们更像放大器，不是最初地基。

8. 第七优先级：Cron 与自动化是第三阶段能力，适合系统已经进入持续使用后再补 ​

自动化当然很有价值。

但如果你还没有：

  • 稳定的核心循环
  • 可恢复的会话系统
  • 基本可控的副作用边界

那太早做 cron，通常只会得到一个更难调试的系统。

Hermes 的 cron 层之所以有价值，是因为它前面已经有：

  • Gateway 接入
  • session context
  • send_message 投递
  • 进程注册
  • 安全扫描

这些基础设施。

所以如果你现在刚起步，我的建议是：

把 cron 放在第三阶段。

等你的 Agent 已经被频繁使用，而且用户开始明确需要：

  • 定时检查
  • 持续监控
  • 后台长期任务

再把 Hermes 这一层搬进来，收益会更高。

9. 如果让我给出三个“最值得抄的 Hermes 原则”，我会选这三个 ​

如果你不想记太多层次，只想记最核心的三句话，我会给你这三个。

9.1 先把 Agent 当运行时，不要只当 prompt 应用 ​

这是 Hermes 最核心的启发。

从 run_agent.py 到 model_tools.py 到 hermes_state.py，它一直在证明：

真正的 Agent 是一套运行系统，而不是一段更长的 prompt。

9.2 先把“当前必要”组织好，不要把所有能力全量注入 ​

这条原则贯穿 Hermes 很多层：

  • memory 是 curated 的
  • skills 是按需展开的
  • toolsets 是裁剪式的
  • session context 是结构化注入的

如果你也能守住这条线，你的系统会更稳、更可扩展。

9.3 先把边界做出来，再追求更强自主性 ​

这是 Hermes 在安全、delegation、cron 等层反复体现的态度。

能做很多事当然重要，但能不能把这些事限定在可承受边界里更重要。

这会决定你的项目最后是酷炫 Demo，还是可用系统。

10. 一个适合初学者的“抄 Hermes 路线图” ​

如果把建议压缩成一个更实操的路线图，我会这样排：

第一阶段：做出最小但像样的 Agent Runtime ​

优先做：

  • 核心循环
  • 工具注册与分发
  • 基础会话存储
  • 基础危险操作护栏

目标不是做花，而是做稳。

第二阶段：做出真正可持续使用的 Agent ​

再补：

  • session 搜索 / resume
  • memory 的清晰边界
  • 接入层解耦
  • 一个主要平台入口

这时候系统开始从 Demo 进入日常使用。

第三阶段：做出会增长、会持续工作的 Agent ​

最后再补：

  • Skills
  • 子 Agent delegation
  • cron
  • 后台进程治理
  • 更细的安全与审计

这时候系统才开始接近 Hermes 现在这种形态。

11. 全书总结：Hermes 最值得你学的，不是“功能很多”，而是“每多一层都在回答一个真实问题” ​

回头看这 12 章，你会发现 Hermes 真正厉害的地方，不是它功能堆得多，而是它每多做一层，基本都在回答一个真实问题：

  • 为什么 Agent 不只是 prompt
  • 为什么核心是循环
  • 为什么工具系统要统一编排
  • 为什么记忆和历史要分层
  • 为什么会话必须是一等对象
  • 为什么接入层不能只剩终端
  • 为什么经验要沉淀成 Skills
  • 为什么复杂任务要能委托出去
  • 为什么时间维度需要 cron 和后台执行
  • 为什么安全边界必须进运行时

这也是我最想你从 Hermes 学走的东西：

不是某个具体功能，而是一种判断问题的方式。

你会越来越习惯问：

  • 这个能力属于哪一层？
  • 它解决的是哪个真实问题？
  • 它应该放进核心循环，还是放进扩展层？
  • 它会不会污染上下文或破坏边界？

只要这种工程视角建立起来，你就已经不只是“会调大模型”，而是开始真正进入 Agent 系统设计了。

这比学会某一个框架 API 更重要。

如果要把全书最后再压缩成一句话，那就是：

Hermes 最值得你抄的，不是某个单点功能，而是它始终在把“模型能力”翻译成“运行时结构”。