Skip to Content
Hermes Agent 源码解读第 1 章 从 Chatbot 到 Agent:一条尚未走完的路

第 1 章 从 Chatbot 到 Agent:一条尚未走完的路

1.1 LLM 应用的四级阶梯

过去三年,LLM 应用的演化可以粗略地分成四个阶段。每个阶段都以”上一阶段解决不了的问题”为起点,又在解决旧问题的同时引入新的工程挑战。

第一级:纯 Prompt。 最早的 ChatGPT 包装应用都属于这一级。开发者把用户输入塞进一个精心设计的 Prompt 模板,调一次 API,把返回直接展示给用户。这种方式能解决 60% 的办公场景 —— 写邮件、翻译、改简历 —— 但它有两个根本缺陷:无状态(每次调用都是独立的,模型不知道上一次说了什么)和知识陈旧(模型的知识止于训练截止日期,不知道你公司内部的文档,也不知道今天的新闻)。

第二级:RAG。 为了解决知识陈旧问题,RAG(Retrieval-Augmented Generation)成为事实标准。开发者先把外部知识(企业文档、最新资讯、用户个人资料)切成片段、计算向量、存入向量数据库;用户提问时先做一次检索,把最相关的 top-k 片段拼进 Prompt,再调模型。RAG 让 LLM “知道了”它原本不知道的东西,但它本质上还是无状态的单次调用 —— 对话历史只能塞进 Prompt 的”上下文”字段,超过窗口就被截断。RAG 还引入了一个新问题:检索质量决定一切。向量相似度高 ≠ 语义相关,很多 RAG 系统的失败案例都是”检到了但没检对”。

第三级:Tool Use。 OpenAI 在 2023 年 6 月推出 Function Calling,之后 Anthropic 的 tool_use、Google 的 Function Calling、开源模型的 ReAct 格式相继跟进。这一级的核心突破是:让模型告诉你它想调用哪个函数、用什么参数,然后开发者在外部执行这个函数,把结果再喂回模型。从此 LLM 不只是”文字生成器”,它可以查数据库、调 API、运行代码、读取文件。Tool Use 让 LLM 具备了”行动能力”,但也引入了新的问题:工具选择错误(模型选了不合适的工具)、参数幻觉(模型编造了不存在的参数)、调用顺序混乱(复杂任务需要多步工具调用,模型容易在中间某一步出错)。

第四级:Agent。 当一个任务需要模型自主规划多个步骤、根据中间结果调整计划、在长时间内反复执行,Tool Use 就不够了 —— 你需要一个Agent。Agent 和 Tool Use 的区别不在于”有没有工具”,而在于:

  • Agent 有规划能力:它会把用户的目标分解成子任务,再决定每个子任务调用哪些工具
  • Agent 有执行循环:它会在”思考 → 调工具 → 看结果 → 继续思考”的循环里自主运行,直到任务完成或达到终止条件
  • Agent 有状态:它需要记住自己已经做过什么、哪些尝试失败了、用户之前提过什么要求

这四级是递进的,不是替代的。今天一个成熟的 LLM 应用里,四级技术都在用 —— Prompt 模板写在 system message 里,RAG 用来注入领域知识,Tool Use 是 Agent 的执行器,Agent 是最外层的调度器。

本书讲的是第四级。但你如果对前三级不熟,建议先补课,因为 Agent 系统里 80% 的工程问题其实是前三级问题的叠加放大。

1.2 AutoGPT 退潮留下的三条教训

2023 年 3 月,一个叫 AutoGPT 的项目在 GitHub 爆红。它的核心思路惊人地简单:给 GPT-4 一个目标,然后在一个 while 循环里让它自己规划、自己调工具、自己反思,直到它认为目标达成。项目作者把它包装成”AGI 已经来了”的演示,一周内 star 数冲到十万。

四个月后,AutoGPT 的活跃度断崖式下跌。人们发现它在真实任务上几乎跑不通。退潮之后,社区总结出三条教训,这三条教训恰好是后续所有严肃 Agent 项目(包括 Hermes)的设计起点。

教训一:没有记忆的 while 循环只是更贵的一次调用。 AutoGPT 的经典失败模式是:第 1 步尝试方案 A,失败;第 2 步尝试方案 B,失败;第 3 步又回到方案 A,因为它忘了第 1 步试过。单次任务内的”工作记忆”没有持久化,跨任务的”经验记忆”更是完全不存在。结果就是 AutoGPT 在每个新任务上都是一个”初学者”,它不会从昨天的失败里学到任何东西。这直接推动了 Letta(MemGPT)、Hermes 等项目把分层记忆作为第一等设计。

教训二:没有质量闸门的自主执行是危险的。 AutoGPT 会自信地写出一段跑不通的 Python 代码,然后基于这段代码生成下一步的计划,再基于下一步的计划写更多的代码。错误会级联放大。社区里最著名的一个 case 是有人让 AutoGPT 帮他”优化公司数据库”,它真的连上了生产 DB 开始 ALTER TABLE。这个事故告诉业界:Agent 的每一步行动都需要可撤销 / 可审计 / 可拦截,不能把”让模型自主执行”理解为”让模型想干啥干啥”。

教训三:没有成本约束的自学习是奢侈品。 早期 AutoGPT 用户的账单经常是”一个简单任务花了 20 美元”。原因是 GPT-4 每次调用都很贵,而 AutoGPT 会在循环里反复调用 —— 思考一次、调工具一次、反思一次、规划下一步再一次。一个任务下来几十次调用是常态。如果你没有模型分级(简单任务用便宜模型,复杂任务才用贵的)和熔断机制(总成本超过阈值就停),自学习 Agent 在生产环境就是一颗不定时的定时炸弹。

Hermes 的设计回应了这三条教训:它把记忆做成三层持久化结构,它把技能写入做成带质量闸门的审查流程,它把模型路由做成可配置的 cheap/strong 两档策略。这些具体机制会在第 3、4、7 章展开。

1.3 从”会聊天”到”会成长”:缺失的三个维度

Chatbot 和 Agent 的差别在哪里?很多人的回答是”Agent 能调工具”。这个回答不错但不够 —— 很多 Chatbot 也能调工具(比如 ChatGPT 的插件)。真正的分界线在三个工程维度上:

维度一:持久化(Persistence)。 Chatbot 的记忆只活在单次对话里;Agent 的记忆要活过进程重启、服务器迁移、版本升级。持久化的难点不在”存”(SQLite 就能存),而在写入时机(什么时候该写)、检索策略(怎么从存的东西里找到当下需要的)、淘汰机制(什么时候该忘)。第 3 章会用一整章讲这三个问题。

维度二:自演化(Self-Evolution)。 Chatbot 永远是出厂时的样子;Agent 要能在使用过程中变得更懂你。自演化的工程本质是:让 Agent 能够修改自己的行为规则,而这些修改能够被审查、评估、回滚。Hermes 的实现方式是让 Agent 自己写 Markdown 格式的”技能文件”(skill),写完之后这些技能文件就成为下一次对话的一部分 context。第 4、5、6 章会详细解剖这个机制。

维度三:多入口(Multi-Entry)。 Chatbot 通常绑定在一个界面上(网页、APP、IDE 插件);Agent 应该可以从任何入口访问。你在 CLI 里让它做的任务,明天从飞书上问它进度,它应该知道你在问什么。多入口的挑战是状态统一 —— 所有入口必须看到同一个”大脑”,而不是每个入口维护自己的状态。Hermes 通过 gateway/ 模块抽象了这一层,第 8 章会讲它的内部结构。

这三个维度互相耦合。没有持久化,自演化就是一次性的烟花;没有多入口,持久化的价值会被单一界面的局限拖住;没有自演化,多入口只是把同一个笨 Chatbot 部署到更多地方。Hermes 的设计哲学是同时解决这三个维度,这也是它区别于 LangChain、Claude Code、AutoGPT 的核心。

1.4 Nous Research 与 Hermes 的定位

Nous Research 是一家以开源 LLM 微调起家的机构。他们最为人熟知的工作是 Hermes 系列模型 —— Hermes 2 Pro、Hermes 3 等 —— 这些模型在 tool use 和 function calling 上做了专门优化,是开源社区里少数能和 Claude、GPT-4 在工具调用场景下掰腕子的模型。

2024 年下半年,Nous 把精力从”训模型”扩展到”做 Agent”,推出了 Hermes Agent 项目(注意:和模型重名,但两者不是同一个东西;Hermes Agent 可以用任何模型作为后端,包括 OpenAI、Anthropic 和 Nous 自家的开源模型)。Hermes Agent 的 slogan 是 “the agent that grows with you”。这句话可以被展开成四个设计原则:

原则一:Model-Agnostic(模型无关)。 Hermes 在设计之初就拒绝绑定任何一个 LLM 提供商。它的 agent/anthropic_adapter.py / model_metadata.py / smart_model_routing.py 三个文件组成了一个抽象层,上层代码通过统一接口调用模型,底层可以在 200 多个模型之间切换 —— OpenRouter、OpenAI、Anthropic、本地 vLLM、Nous Portal 都是合法选项。切换模型只需要一个命令 hermes model,不用改任何代码。这个设计决定的代价是 Hermes 无法利用任何单一模型的”独家特性”(比如 Claude 的 computer use、OpenAI 的 structured outputs),但好处是你不会被任何一家 LLM 厂商锁死

原则二:Skill as Markdown(技能即文档)。 主流 Agent 框架把”工具”定义为函数 —— LangChain 的 @tool 装饰器、OpenAI Function Calling 的 JSON Schema。Hermes 走了一条不同的路:它把技能定义为一份 Markdown 文档,里面可以有自然语言说明、示例对话、代码片段、甚至失败案例。这种设计的好处是技能对人和对 AI 都是可读的,也更容易让 Agent 自己生成新技能 —— 让模型写一份 Markdown 比让它写一个符合复杂 schema 的 JSON 容易得多。代价是技能的执行需要多一层”解读”,这会增加 token 消耗。第 4 章会细讲这个权衡。

原则三:File-Based Memory(文件化记忆)。 大多数 Agent 框架把记忆存在向量数据库里。Hermes 反其道而行,它把大部分记忆存成本地文件:SQLite 数据库放会话历史,memory/ 目录下放持久化笔记,skills/ 目录下放程序化知识(也就是技能)。这种设计有三个好处:(1)可以用 git 管理,你可以像管代码一样给自己 Agent 的”记忆”打 tag、做 review、做回滚;(2)可以人工检查和编辑,出问题的时候你能直接打开文件看里面写了什么,而不是盯着一堆 embedding 的浮点数发呆;(3)跨机器迁移简单,拷贝一个目录就行。代价是对超大规模记忆(百万级文档)的检索性能不如专业向量库,但对”个人 Agent”的场景完全够用。

原则四:Gateway-First(网关优先)。 从架构图上看,Hermes 不是”一个 Agent 加几个接口”,而是”一个 Agent 加一个统一网关”。网关支持 Telegram、Discord、Slack、WhatsApp、Signal、CLI 六种入口(社区正在添加更多,包括飞书),所有入口共享同一个记忆、同一套技能、同一份用户模型。这意味着你在手机上让 Hermes 帮你查一个东西,回家打开电脑继续和它讨论结果,它不会问”我们刚才聊到哪了?”。

把这四个原则翻译成一句话:Hermes 把”会成长”的重心放在了工程可维护性上,而不是放在算法新颖性上。这是一个重要的判断。很多”研究型 Agent”(Voyager、Generative Agents)在论文里很惊艳,但把它们放到生产环境就会暴露出一堆工程问题。Hermes 的选择是反过来的 —— 它在算法上是保守的(没有发明新的记忆压缩算法,没有发明新的规划算法),但在工程上是认真的(记忆有审计、技能有版本、模型可切换、入口可扩展)。这种”工程优先”的取向正是本书值得花 400 多页去解剖它的原因。

1.5 范式对比速览

Agent 领域的玩家很多。在进入细节之前,先给你一张对比表作为心理地图。这张表会在第 13 章被扩展成一整章的深度对比,但现在你只需要知道每个项目的”气质”。

项目定位记忆模型技能机制扩展入口最适合的场景
Hermes Agent会成长的个人助手分层(SQLite + 文件 + 技能)Markdown 技能,自生成 + 人工审查网关抽象,支持 6+ 入口长期个人助手、跨设备工作流
Letta(前 MemGPT)以记忆为中心的 Agent 平台虚拟内存分页(核心 + 归档)无显式技能机制,靠记忆驱动HTTP API,需自建入口需要超长时记忆的对话应用
Claude Code编码专用 Agent项目内 MEMORY.md 文件索引Skill(较新,对标 Hermes)CLI + IDE 插件软件开发、代码仓库维护
OpenClaw(Microsoft)预定义工作流驱动的 Agent短时任务上下文,无跨任务记忆YAML 工作流,人工编写HTTP API + Copilot 插件企业级标准化流程
LangGraph有状态 Agent 框架开发者自己实现Tool 注册,开发者自己组织框架,不带入口需要自定义控制流的复杂 Agent
AutoGPT(已退潮)自主智能体(实验性)单次任务的临时记忆动态工具,无技能沉淀Web UI + CLI不建议生产使用

这张表的重点不是”谁最好”,而是每个项目在”自演化 / 预定义”和”通用 / 专用”两个轴上的位置不同。下面这张矩阵把它们定位出来:

四个象限各有典型代表:

  • 自演化 + 通用:Hermes、Letta、AutoGPT(已退潮)—— 这是”会成长的个人助手”的目标象限
  • 自演化 + 专用:Claude Code(专注编码,但 skill 和 memory 都会成长)
  • 预定义 + 通用:LangGraph(给你所有零件,流程你自己搭;“成长”要你自己写)
  • 预定义 + 专用:OpenClaw(标准化的企业流程,刻意避免不确定性)

本书选 Hermes 作为主角是因为它在”自演化 + 通用”象限里做得最完整,也因此解剖它能让你学到最多的 Agent 工程通用原理。如果你将来要做一个编码 Agent,你应该用 Claude Code;如果你要做一个企业流程 Agent,你应该用 OpenClaw 或 LangGraph。但在这之前,读完本书会让你知道它们各自是怎么权衡的,以及如果你真要自己写一个会是什么样

第 13 章会把这五个项目拉出来做深度对比,从记忆模型、技能机制、可观测性、生产就绪度等 7 个维度逐一拆开。如果你现在对某个”不是 Hermes”的项目更好奇,可以先跳到 13 章看。

1.6 本书的读法

本书 16 章不是都必须顺序读。下面是三条常见路径,你可以按自己的情况挑一条。

路径一:顺序读(约 20 小时阅读 + 一周实践)。 如果你第一次接触 Hermes,或者你希望系统地建立”Agent 系统设计”的知识框架,就从第 1 章读到第 16 章。这条路径里有两个”休息点”:读完第 7 章时你应该暂停一下,把第 2 章装的 Hermes 打开,对照前几章讲的原理在实际系统里找一遍对应的文件和目录;读完第 12 章时再暂停一下,开始动手做第 14 章的案例一。完整读完并做完所有实践,大约需要两到三周。

路径二:核心机制直通车(约 8 小时)。 如果你已经在用 Hermes 或者类似的 Agent 框架,想深挖”Agent 系统内部到底是怎么工作的”,直接跳到第二部分(第 3–7 章)。这五章是全书的内核,讲清楚了记忆、技能、学习闭环、执行引擎 —— 这些是所有 Agent 系统都绕不开的共性问题。读完这五章,你对 Agent 的判断力会比读十篇综述博客更扎实。之后你可以根据兴趣挑第四部分(生产化)或第六部分(mini-hermes 实现)继续读。

路径三:生产化专题(约 5 小时)。 如果你已经在生产环境跑过 Agent,遇到的问题是”自学习跑飞了”、“成本失控了”、“技能冲突了”、“出了安全事故”这类工程问题,直接跳到第四部分(第 10–12 章)。第 10 章告诉你怎么打 trace、怎么让自学习可回放;第 11 章给你 6 个真实的失败案例拆解和对应的防御设计;第 12 章给你一套可落地的 Agent 评估方法论。这三章在市面上的 Agent 书里基本是空白的,也是”玩具 Agent”到”生产 Agent”的分水岭。

如果你时间有限,只能读三章:强烈推荐第 3 章(记忆)、第 5 章(技能标本)、第 11 章(安全与失败档案)。这三章分别代表了本书最想传达的三个信号 —— Agent 系统的工程难点在哪、具体的好设计长什么样、生产环境真正会翻车的地方在哪里。读完这三章,你对 Hermes 和 Agent 工程会有一个准确但不完整的认识,之后再按需回头补其他章节。

准备好,进入第 2 章,我们在 10 分钟内把 Hermes 装上,看着它自己写出第一个 skill。

Last updated on