前言
为什么写这本书
2023 年 3 月,AutoGPT 横空出世。它给 GPT-4 套了一个 while 循环,让模型自己规划、自己执行、自己反思。那几周社交网络上全是”AGI 已至”的欢呼。
到 2023 年 7 月,AutoGPT 仓库的周活跃提交从巅峰期的日均几十条跌到接近零,Discord 里问答频率同样断崖。人们发现它在真实任务上会陷入无限循环,会把简单任务拆成几十个 GPT-4 调用烧掉几十美元,会在第三步忘记第一步做过什么,会信心满满地写出一段跑不通的代码然后基于这段代码继续往下推。它的死法不是”不够聪明”,而是工程上不成立:没有持久化的记忆,没有跨会话的学习,没有质量闸门,没有成本约束,没有可观测性。
从那之后,“Agent”这个词在工业界变得暧昧。一边是成熟的封装框架(LangChain、LangGraph),它们把 Agent 降维成”带工具的状态机”,稳定但缺乏成长性;另一边是”自主智能体”的学术演示(Voyager、Generative Agents),惊艳但离生产十万八千里。大多数开发者卡在中间:既不想只做”加了工具的 Chatbot”,又没有把握把”自主 Agent”跑到生产。
Hermes Agent 试图同时回答这两头的问题。能站在这个位置的项目不多 —— Letta(前 MemGPT)只抓”记忆”,Claude Code 只抓”编码”,OpenClaw 选的是预定义工作流;只有 Hermes 在”自演化 + 通用 + 可审计”三条线上同时做工程化投入。它来自 Nous Research —— 一家以开源 LLM 微调著称的机构。Hermes 的核心主张很简单:Agent 应该像一个真正的助手那样随着时间变得更懂你。这意味着:
- 它要有持久化的记忆,不是每次启动都重新认识你
- 它要能自己写技能,把做过一次的事沉淀下来,而不是每次都从头推理
- 它要跨入口统一,无论你从 CLI、Telegram、飞书还是 Web 进来,看到的是同一个”大脑”
- 它要可观测、可评估、可审计,否则自学习就是技术债务
这四点听起来像口号,但 Hermes 把它们逐条翻译成了工程实现:SQLite + FTS5 的分层记忆、Markdown 格式的技能文件、统一的 Gateway 抽象、基于 OpenTelemetry 的 trace 打点。这些不是 Nous 独有的发明,很多组件在业界都有先例,但 Hermes 是少数把它们整合成一个自洽系统并且开源出来的项目。
正因为 Hermes 做到了”整合”,它才值得被解剖。
这本书不是什么
这不是一本 Hermes 的 API 手册。Hermes 的 CLI 命令、配置项、环境变量会随版本变化,正文不会列这些细节 —— 它们在 附录 B 和在线文档里维护。
这不是一本 Prompt 工程书。本书假设你已经能独立写出一个 RAG 应用,已经知道 few-shot、chain-of-thought、tool calling 是什么。如果这些对你还陌生,请先读完一本 LLM 应用入门书,再回到这里。
这不是一本”Hermes 是万能的”的宣传册。第 13 章会诚实地讲清楚 Hermes 的局限 —— 哪些场景它比 LangGraph 差、哪些任务 Claude Code 更合适、哪些需求 Letta 的纯记忆方案反而更干净。技术书的价值在于帮读者建立判断力,不是卖广告。
这本书是什么
它是一本”以 Hermes 为标本”的 Agent 系统设计书。书里反复出现的句式是:
Hermes 在这里做了 X 选择,理由是 Y。如果你换一个 Agent 框架甚至从零写一个,你会面对同样的问题,可选项包括 X、X’、X”;每个选项的代价分别是 ……
这种写法借自 Martin Kleppmann 的 Designing Data-Intensive Applications(DDIA)—— 那本书讲数据库时从不被任何具体产品绑架,而是把 MySQL、PostgreSQL、Kafka、Cassandra 当作不同设计权衡的活标本。本书对 Agent 做的是同样的事:Hermes 是主角,但不是唯一的参照系;每当有重要的设计决策出现,你都会看到 Letta、Claude Code、OpenClaw、LangGraph 作为对比标本被拉出来比较。
这本书为谁写
主要读者:有 LLM 应用开发基础、至少独立完成过一个 RAG 或 Tool Use 项目、正在考虑把”加了工具的 Chatbot”升级为”有状态的 Agent”的中高级开发者。
次要读者:AI 产品架构师(关心能不能落地、成本多少、风险在哪)、独立开发者(想做一个长期服务自己的助手)、技术书编辑和技术文章作者(想系统理解 Agent 领域的知识地图)。
不适合的读者:刚接触 LLM、还在背 Prompt 模板的初学者;只关心”能不能用一行代码做出一个 Agent”的应用开发者;寻找 SOTA 论文综述的研究者(本书偏工程,不偏研究)。
怎么读这本书
三条路径,按你的目的选:
路径一:顺序读(推荐给第一次接触 Hermes 的读者)。从第 1 章开始,走完第一部分(思想)和第二部分(核心机制),然后跳到第 15–16 章做一遍 mini-hermes,最后回头读第三、四、五部分。这条路线大约需要 15–20 小时的专注阅读,加上一周的实践时间。
路径二:只读第二部分(推荐给已经在用 Hermes 或类似框架的读者)。第 3、4、5、6、7 章是全书的”内核”,讲清楚了记忆、技能、学习闭环、执行引擎这些 Agent 系统的共性问题。读完这五章,你对 Agent 系统的判断力会比读十篇综述博客更扎实。
路径三:只读第四部分(推荐给已经在生产跑 Agent、遇到真实问题的读者)。第 10 章可观测性、第 11 章安全与失败档案、第 12 章评估 —— 这三章在市面上的 Agent 书里几乎是空白,也是”玩具 Agent”到”生产 Agent”的分水岭。这三章加起来只有 60 多页,但解决的是大多数团队在 Agent 项目中后期才意识到的问题。
配套资源
GitHub 仓库:https://github.com/book-hermes-agent/book-hermes-agent(以下正文里所有 mini-hermes/、cases/、integrations/ 开头的路径都指向这个仓库的对应目录)。book/ 目录是正文(就是你现在看到的),mini-hermes/ 是第 15、16 章的 TypeScript 实现,cases/ 是第 14 章的三个案例,integrations/ 是飞书机器人等接入示例,scripts/ 是维护者脚本。
纸质版读者:仓库 URL 同样印在扉页和附录 F的开头。扫封底二维码可直接跳转。
飞书 Wiki 同步版:仓库中的 book/ 目录会同步到飞书 Wiki。国内读者可以直接在 Wiki 上阅读、评论、协作。
勘误页:Hermes 上游在高速迭代,本书不可避免会出现信息过时或判断错误的情况。所有已知的勘误和补丁都在 附录 G 以及仓库的 errata.md 维护。如果你发现新的错误,欢迎提 Issue。
致谢
感谢 Nous Research 团队把 Hermes 开源出来,并且保持了极高的代码质量和文档密度 —— 没有一个愿意被”解剖”的开源项目,这本书不会存在。
感谢在早期草稿阶段提供反馈的读者。他们指出了大量”AI 味太重”的段落、过度泛化的断言和脱离工程现实的空话 —— 这本书能读起来像人写的,他们功不可没。
开始吧。