淘天智能体面试题：Hermes Agent 是如何实现不断自我纠正与进化的？

翻开 Hermes 源码，第一个让人停下来的东西不是复杂的算法，而是一个简单的 while 循环。但正是这个循环，解决了一个 Agent 系统最核心的痛点——模型会犯错，而且它自己意识不到。

在真实的工程环境里，Agent 一定会碰到不完整的信息、过期的知识、路径错误、工具失败。这些问题躲不掉。

讨论一个 Agent 能不能"自我进化"，目标从来不是让它永远不犯错，而是：

• 错了能尽快发现
• 发现后能继续补查
• 补查后能验证
• 最后把这次经验留下来，下一次别再退回到起跑线上

今天我们从源码级别拆解 Hermes 的这套机制，看看业界是怎么把纠错做成一套可执行、可验证、可沉淀、可回归的完整体系的。

---

01 运行时纠偏：一个简单的 while 循环，解决了什么问题？

翻开 Hermes 源码，核心逻辑可以浓缩成一段伪代码：

while 没超时 and 没超预算:
    response = 调模型(messages, tools)
    if response.有工具调用:
        逐个执行工具
        把工具结果塞回上下文
        继续下一轮
    else:
        return response.文本

这个循环到底在解决什么？

模型会犯错，这是不争的事实。但更危险的是——没有外部反馈的话，模型会顺着错误一路编下去，越说越离谱。

这个循环每轮做一次判断：

• 需不需要调工具？ 比如读文件、搜网页、跑命令
• 如果需要，系统替它执行，把真实结果写回对话历史，然后进入下一轮
• 如果不需要，说明模型认为可以回答了，直接返回文本

关键在"把结果塞回上下文"这一步

这一步的设计非常精妙——真实结果不会被模型绕开。

举个例子：

模型觉得某个路径下有配置文件，调 read_file 读出来发现不存在。

那"文件不存在"就成了下一轮模型的已知信息。它不能假装文件存在继续往下讲，只能基于"不存在"这个新事实重新想办法：

• 换路径试试
• 或者创建文件
• 或者告诉用户情况

这个机制实现了"纠正"：不是靠模型反思"我好像错了"，而是靠新证据强制修正方向。

System Prompt 里的两条纪律

循环之外，Hermes 在 system prompt 里还卡了两条纪律，确保模型不会"光说不做"：

You MUST use your tools to take action — do not describe what you would do or plan to do without actually doing it

Never end your turn with a promise of future action — execute it now

第一条防止模型说"我去查一下"然后空等，必须马上调工具。

第二条防止承诺"下一步我再搞"，必须在当前轮执行完。

另外，超时和预算上限作为兜底——超过限制就强制退出，避免循环跑死或烧太多 token。

说了就要调工具

模型犯错后最常见的情况是：道歉然后分析，话说得挺像回事，但有没有真的再去读文件、跑命令、拿新结果——这一步经常是空的。

Hermes 在 system prompt 里把这条规定死：

• 嘴上说要做什么，必须调对应的工具——read_file、terminal
• 一步不能省，做完还要回头验证

工具一调，真实结果就在面前，对错都绕不过去。很多系统的问题是表达能力太强了，本该靠执行解决的东西，留在文字层面绕一圈完事。

比如：让 Agent 把文章写到 Obsidian，写完不算完，它得自己回去读一遍，确认：

• 文件在不在
• 路径对不对
• 内容有没有落空

多这一步确实有点啰嗦，但**"做了"和"看起来做了"的区别就在这**。

---

02 跨会话记忆：同一个错误，别反复来

长期用 Agent，最累的是什么？

是同一类错过几天又来一遍。

• 说过的偏好（用中文、自然表达）
• 环境设置（工作目录、代理地址）
• 下次打开它又像初见，从头猜

你明明一直在训练同一个东西，它就是不记。

Persistent Memory 的核心逻辑

Hermes 这层叫 persistent memory，核心逻辑就一句话：

只存稳定事实，不存临时状态

记什么？

• 用户偏好的表达习惯
• 环境配置路径
• 稳定的项目约束
• 已验证过的经验（比如 vault 挂载位置）

这些下次大概率还要用。

不记什么？

• 临时任务状态
• 一次性执行结果
• 本周做了什么的流水账

这些很快就过期，塞进去反而把有用的埋了。

Memory 和 Skill 是两回事

这是一个非常容易混淆的点：

维度	Memory	Skill
存什么	“知道什么”——事实类信息	“这类事怎么做”——操作流程类知识
示例	用户的 Obsidian vault 在 /mnt/c/Users/xxx/ 下	怎么排查 WSL 下 Hermes 更新失败
特点	稳定事实，长期有效	方法步骤，可复用

举个完整的例子：

进入 Memory 的内容：

“用户的 Obsidian vault 在 /mnt/c/Users/xxx/ 下”

这是稳定事实，下次还要用。

进入 Skill 的内容：

“怎么排查 WSL 下 Hermes 更新失败”

这是方法，不是事实。Skill 结构化记录了：

• 什么时候触发
• 步骤怎么走
• 哪些地方容易踩坑
• 最后怎么验证

一件事做成一次不算能力，能接到下一次才算。

否则今天做成明天从头来，后天再踩同样的坑，永远都是临场发挥。

---

03 Memory 四层架构：信息不乱，才能用得好

Agent 用久了信息会乱，问题在于没分层。

当前任务、历史记录、长期事实、方法经验——这四类东西不该混在一起。Hermes 分了四层，每层各司其职：

第一层：临时层（当前上下文）

• 存放内容：本次会话的中间结果和正在处理的文件
• 生命周期：会话结束就丢弃
• 特点：不会被长期保留

第二层：回忆层（Session History）

• 存放内容：过往任务和排错过程
• 使用场景：用户问"上次不是处理过吗"，去这里翻，不用重新猜
• 特点：保留完整的任务轨迹

第三层：持久层（Memory）

• 存放内容：用户偏好、环境路径、长期约束之类的事实型信息
• 使用场景：跨会话复用，避免重复学习
• 特点：只存稳定事实

第四层：能力层（Skill）

• 存放内容：操作流程和方法经验
• 使用场景：某次复杂任务跑出来一套稳定的打法，抽成 Skill，下次直接复用
• 特点：结构化的可执行知识

数据流动方向

这四层不是孤立的，它们之间有明确的数据流动：

临时层 → 回忆层 → 持久层(Memory) → 能力层(Skill)

• 临时层的东西做完就丢到回忆层
• 回忆层里反复出现的规律往下沉淀到 Memory
• 复杂经验再抽象成 Skill

不分层的话，四类东西全塞一起，看起来记了不少，真用的时候谁也找不到。

这就像一个图书馆如果不分类，书再多也等于没有。

---

04 兜底机制：Eval、Regression、Observability

单看一次任务，Agent 都不差。

但时间拉长以后，系统能不能持续进步，不靠换更强的模型，靠几样兜底的东西。

评估（Eval）

Eval 不光看答案对不对，对 Agent 来说，过程也是关键：

• 该查的时候查没查
• 该调工具的时候调没调
• 做完了有没有验证
• 多轮任务里有没有正确用到 Memory 和 Skill

过程质量决定了 Agent 的可靠性。

回归（Regression）

这是最容易出现的事：

今天修好 A，明天搞坏 B。

具体表现：

• 让 Agent 更主动，结果它开始乱调工具
• 让它少说废话，该有的解释跟着一起没了
• 让它别总追问，它自己开始瞎猜

没有 Regression Set 在后面拦着，看起来在变好，可能只是局部在变好。

这就像修 Bug，修了一个引出三个，没有自动化回归测试，永远不知道改了什么不该改的东西。

可观测性（Observability）

出了问题，拆开看比猜有用。

需要回答的问题：

• 它在哪一步偏的？
• 没加载 Skill？
• 工具调了但失败了？
• 读错文件了？
• Memory 写岔了？
• Session Recall 没拉到位？

有这些东西在，才拆得动：

• Trace（链路追踪）
• Tool Call Tracing（工具调用追踪）
• State Transition Logging（状态转换日志）

没有可观测性，错了你也很难知道从哪下手。

---

05 整个链路拼起来

把上面的机制串起来，Hermes 的自我进化能力可以这样理解：

运行时层

• 靠 while 循环提供回到正轨的机会
• System Prompt 保证每轮都不留空操作
• 工具调用产生真实结果，强制修正模型方向

记忆管理层

• Persistent Memory 只存稳定事实，减少重复错误
• Memory 和 Skill 分工明确，一个存"知道什么"，一个存"怎么做"

架构层

• 四层 Memory 架构，信息分层存储
• 数据从临时到持久，从事实到方法，逐层沉淀

系统保障层

• Eval 保证过程质量
• Regression 防止能力退化
• Observability 提供问题定位能力

核心理念

Hermes 的关键不在模型会不会"反思"，而是它把纠错做成了一套完整的机制：

维度	机制	作用
运行时	工具纠偏	嘴上说了就调工具，回头验证，一步不省
跨会话	Memory	只留稳定事实，不把 Memory 做成流水账
能力沉淀	Skill	一次做成的经验能接到下一次同类任务上
系统保障	Eval + Regression + Observability	把能力守住，进化不是错觉

---

06 面试时怎么答？

如果面试时被问到"Hermes Agent 是怎么不断自我纠正、自我进化的？"，可以压成几个点来答：

一句话收主线

Hermes 的关键不在模型会不会"反思"，而是它把纠错做成了一套可执行、可验证、可沉淀、可回归的机制。

四个点展开

1. 运行时靠工具纠偏

嘴上说了就调工具，read_file、terminal，回头验证，一步不省。错误会被工具结果直接逼出来。

2. 跨会话靠 Memory 减重复错误

只留稳定事实，不把 Memory 做成流水账，用久了，低级重复错误往下走。

3. 复杂经验靠 Skill 复用

一次做成的经验不是只留在那一次，能接到下一次同类任务上。

4. 系统层面靠 Eval、Regression、Observability 把能力守住

没有评测和回归，进化可能是错觉；没有可观测性，错了你也很难知道从哪下手。

一句总结

普通 Agent 像一次性执行器，Hermes 像在执行里纠偏、在复盘后留经验、长期慢慢长能力的 Agent Operating System。

---

最后说一句

Agent 的自我进化，不是一句"让模型自己反思"就能解决的工程问题。

它需要：

• 执行层面的强制约束——说了就要做，做了就要验证
• 记忆层面的精准分层——什么该记、什么不该记、记了怎么用
• 系统层面的兜底保障——能评估、能回归、能观测

这套机制的设计思路，其实可以应用到任何需要"持续改进"的系统里。

毕竟，犯错不可怕，可怕的是犯了错留不下经验，下次还从起跑线重新开始。

---

觉得有用？点个在看再走吧 👍

转发给正在做 Agent 开发的技术朋友，一起聊聊！