15.7 借鉴哲学：从 Hermes 学到的"自进化"工程原则
☤ "自进化不是 feature，是 Agent 在长跑中胜出的唯一办法。"
一、把 Hermes 看作"系统级方法论"
如果你读完 15.4–15.6 之后只学到一个东西，那应该是："自进化"不是一个 feature，它是 Agent 在真实长跑中胜出的唯一办法。
因为：
- 短期：谁都能写出"能跑"的 Agent——前几天我们一起搭的"小付手"已经能完成邮件摘要、查日程、保存笔记；
- 长期：能跑 ≠ 能用。能用 ≠ 能用1 年。
- 真正的差异在于：30 天后、90 天后、1 年后，你的 Agent 到底是停在原地的工具，还是变成了你的私人版本。
本节把这个差异拆成 5 条可迁移的工程原则。
二、原则 1：把"长跑"当作默认假设
2.1 为什么"长跑"是大问题
短期 Agent 和长期 Agent 的工程差异是数量级的：
| 维度 | 短期 Agent | 长期 Agent（Hermes 视角） |
|---|---|---|
| 状态保存 | RAM 内即可 | 必须落盘 + 可回滚 |
| 崩溃恢复 | 无所谓 | 必须能接上 |
| 依赖管理 | freeze 即可 | 频发更新 + 灰度发布 |
| 可观测 | debug 日志 | 指标 + 日志 + 追踪 + 反馈 |
| 安全 | 本机权限即可 | 凭证轮换 + 权限审计 + 远程控制 |
| 备份 | 无所谓 | 周期 + 增量 + 跨机 |
| 演进 | 不演进 | 持续自迭代 |
2.2 借到自己的系统：把"长跑"作为第一天的设计目标
如果你要让一个 Agent 真的在生产环境用超过 30 天，从第一天就考虑这些：
- 状态必须落盘：所有 session / 记忆 / 任务进度都进数据库（Hermes 默认 SQLite）；
- 凭证走 Keyring：不要写在
config.yaml； - 启动自动恢复：当前 session 中断时，下次启动时能从断点继续；
- 能力可演进：把"添加新能力"的接口从"改源码"降到"改配置"或"加 Skill"；
- 自我可观测：能 5 分钟内知道"我的 Agent 这一刻在做什么、为什么"。
大多数"Agent 上线一个月就废"的项目都死在上面任意一条没做对。
三、原则 2：把"可持续沉淀"作为核心能力
3.1 三种"持续沉淀"方式
Hermes 在做的事，本质上是把"经验"变成"沉淀物"的三种循环：
| 输入 | 沉淀物 | 机制 |
|---|---|---|
| 对话 → Skill | 自进化技能 | 闭环（提炼 + 迭代） |
| 对话 → USER.md | 用户建模 | 增量（每次对话补充一点） |
| 对话 → MEMORY.md | 事实 + 经验 | 增量 |
每种"沉淀物"都满足两个特征：
- 机器可读（LLM 能用、文件系统能索引）；
- 人类可读（你可以直接打开看、改、合并）。
3.2 借到自己的系统：设计你自己的"沉淀物"
如果你做的 Agent 不是用 Hermes（不享受它的 self-evolving），也要至少设计以下 3 种"沉淀物"：
| 沉淀物 | 内容 | 更新方式 |
|---|---|---|
| memory.json | 长期事实、用户偏好、项目约定 | 显式（用户告知）或半显式（人工审计） |
| feedback.md | 用户对每个失败的反馈 | 人工或自动 |
| skill/ | 可复用流程 / 工具 | 人工 |
要点：哪怕每次只增加 1 行，时间会给你回报。
四、原则 3：把"反馈"做成闭环
4.1 反馈的 3 种形态
Hermes 实际上有 3 种"反馈回路"——单独任何一种都不够，组合起来才是闭环：
| 反馈形态 | 信号 | 处理 |
|---|---|---|
| 用户显式 | "这个 skill 不好" | 标记 deprecated |
| "这个 skill 应该这样改" | 写进 FEEDBACK.md | |
| 任务结果 | 成功 | 评估为"可提炼" |
| 失败 | 评估为"需要改进" | |
| 用户行为模式 | 总在晚上 22:00 复盘 | 提炼成 USER.md |
| 偏好直接给代码 | 提炼成 USER.md |
4.2 借到自己的系统：让你的 Agent 也有 3 种反馈
不管你是否做 self-evolving，至少要给 Agent 一种"反馈机制"：
class FeedbackLoop:
def on_task_done(self, trajectory):
# 形态 2：基于结果
if trajectory.success:
self.record_positive_example(trajectory)
else:
self.record_failure(trajectory)
def on_user_message(self, msg):
# 形态 3：用户行为信号
if self.looks_like_preference(msg):
self.update_user_model(msg)
# 形态 1 用户显式 feedback 是你写代码时就预留接口
def on_user_explicit_feedback(self, feedback):
self.handle(feedback)
五、原则 4：跨渠道 ≠ 重复数据
4.1 Hermes 的"一份 USER.md，多渠道共享"
OpenClaw 默认每个渠道独立 session；Hermes 默认合并为同一真人。这是个有意识的工程取舍——
- 不合并的好处：每个渠道独立、隔离、互不干扰；
- 合并的好处：跨渠道人格一致、记忆一致、长期使用体验连贯。
Hermes 选择后者。
4.2 借到自己的系统：明确你想要的"跨渠道策略"
如果你做一个跨渠道 Agent，必须先想清楚：
| 策略 | 实现 | 风险 |
|---|---|---|
| 完全隔离 | 每个渠道独立 session + 记忆 | 用户体验差（每个渠道是不同人格） |
| 完全合并 | 同一真人 = 同一 session | 安全风险（家人 / 同事能不能看到你的信息？） |
| 部分合并 | 同"个人偏好"维度合并；不同"工作上下文"维度隔离 | 实现复杂，但最稳 |
| 按身份/项目分 | 同身份 → 同个人记忆；不同项目 → 不同项目记忆 | 复杂度最高 |
Hermes 默认"完全合并"——如果你做新的 Agent，可以根据你的场景选择不同策略。
六、原则 5：可换内核（plugin / extension）= 长期可控
5.1 Hermes 的可换程度
Hermes 暴露的可换点：
| 可换 | 默认实现 | 替换 |
|---|---|---|
| LLM Provider | OpenAI / Anthropic | 任意主流模型（数量以仓库为准） |
| Tool Backend | local | Docker / SSH / Singularity / Modal / Daytona |
| Memory Store | SQLite + FTS5 | Redis / Postgres / MongoDB |
| Skill Format | agentskills.io 兼容 | 自定义 |
| Voice Transcriber | OpenAI Whisper | Paraformer / whisper.cpp |
5.2 借到自己的系统：把可换性作为长期可控的前提
如果你的 Agent 跑在生产里，它一定会被换——可能换模型、可能换存储、可能换某个工具。不让换 = 后期痛苦。
把"换"做得便宜的设计准则：
- 接口稳定：定义"插件协议"而不是"具体实现"；
- 配置覆盖：每个可换点都能被
config.yaml一行配置修改； - 失败可降级：默认实现挂了，不要让整个 Agent 挂——只降级那一块；
- 可观测：每个"插件加载"和"插件调用"都进指标；
- 可写：插件 API 文档化，让第三方能写。
七、原则 6（隐藏）：把"Agent 当成产品"来运营
7.1 Hermes 团队的运营哲学
读了 Hermes 的官方文档、Issue tracker、Discord 公告后，我发现他们有几个很产品化的做法：
- 每周 release notes —— 列改动 / 行为兼容性；
- MCP / 技能生态 —— 与其他 OpenClaw 系产品兼容，避免生态孤岛；
- 明确 deprecation 政策 —— "v2 将废弃某个 API"，给出替代 + 迁移路径；
- 教程与示例 —— 通过
hermes init --example跑一遍"我能做什么"； - 可关闭的开关 —— self-evolving 关掉就是"普通 Agent"，不强制用户接受新特性。
7.2 借到自己的系统
如果你做的不只是"个人项目"，而是"团队 / 公司"用的 Agent：
- release notes：每次升级都写得清楚，不要"silent update"；
- deprecation 政策：给用户至少一个版本的过渡；
- 示例 / 教程：让 5 分钟内能跑出一个"能 demo"的版本；
- 可关闭的特性：保守用户能逐步启用，不是一上来就要接受新范式。
八、把 6 条原则压成一句
如果上面 6 条太多难记，最后压成一句——
让你的 Agent 像一个"长跑型服务 + 持续学习系统 + 可换内核的产品"一样设计。
如果只能挑一条做，就做"状态必须落盘 + 凭证走 Keyring"——这是 30 天后不出问题的最低门槛。
九、本部分小结（Harness 谱系 + Hermes）
读完整章，你应该已经能回答：
- ✅ 什么是"自进化 Agent"：任务后提炼 Skill + Skill 离线自迭代 + 主动反思。
- ✅ 三层记忆是什么：长期语义（MEMORY/USER/Skills）+ 工作记忆 + 情景日志。
- ✅ Nudge Engine 做什么：每隔一段时间主动问自己"我学到了什么"。
- ✅ 自进化的风险与边界：草稿机制 + 安全审计 + 回滚 + 用户显式关闭。
- ✅ 可迁移原则：长跑假设、持续沉淀、反馈闭环、跨渠道策略、可换内核、Agent 当成产品。
读 Hermes 不只是"学会一个框架"，而是学会一种把 Agent 视为"长跑系统 + 学习系统"的设计思维——这才是 Hermes 给 AI 工程的最大启示。
十、接下来读什么
- 想立刻就用：跟着 14.6（OpenClaw 实战）+ 15.6（Nudge），在自己机器上跑一个 多渠道 + 跨会话学习的 Agent；
- 想研究工业级 Harness 的实现细节：第 16 章 Claude Code 深度解析——你看 Hermes 的"6 种执行后端"思想，会发现 Claude Code 在"工业 IDE 场景"中走了另一条路；
- 想理解"插件化元框架"：第 17 章 DeepSeek Harness——和 Hermes 的 Plugin 子系统同源思想，但走到极致后是非常不同的工程表达。