Hermes Agent — 设计哲学与 PM 启发录

一句话总结：这是一篇横切的 PM 视角复盘——把 6 篇深度文档中散落的"启发"与"反思"汇成 7 条产品哲学、5 处架构权衡和 4 套可复用的设计模板，以便其他 Agent 产品在选型/自研时能快速借鉴。

本文不重复架构细节，只回答三个问题：

Hermes 的产品哲学是什么？（7 条核心设计哲学）
它在哪些地方做了关键权衡？（5 个工程取舍）
哪些设计可以直接套用到我自己的产品？（4 套设计模板）

第一部分：七大产品哲学

哲学 1 — Skill 是 Agent 的"程序性记忆"，必须与"陈述性记忆"分离

主张：知道什么（Memory，who/what）和怎么做（Skill，how）是两类完全不同的认知对象，应该分开存储、分开学习、分开检索。

Hermes 的体现：

Memory 用 <memory-context> 标签注入系统提示，存储用户事实和会话状态
Skill 是独立的目录结构（SKILL.md + references/ + templates/ + scripts/），存储"如何完成这类任务"
Review Prompt 中显式写："Frustration is a FIRST-CLASS skill signal, not just a memory signal" —— 用户挫败感主要更新 Skill 而非 Memory
当用户抱怨"做事方式"时，Skill 必须携带这个教训（不仅仅是 Memory）

PM 启发：

任何 Agent 产品如果只有一个"记忆文件"，本质上是把两类记忆混在一起。区分二者后，知识管理的颗粒度和检索精度都会显著提升。

架构地图位置：见全景导读 §2 架构地图中的"自进化系统"与"工具系统"两个模块。

哲学 2 — 多平台 ≠ 多产品：界面只是接入层，能力才是产品

主张：Agent 的价值不在 UI 而在底层能力。一个能力内核 + N 个平台 adapter，胜过 N 个独立产品。

Hermes 的体现：

一个 Gateway 进程统一管理 11+ 个 IM 平台（Telegram / Discord / Slack / WhatsApp / 钉钉 / 飞书 / 企微 / QQ / Home Assistant / Email / SMS / Webhook）
SessionSource 数据类抽象消息来源（平台 / chat_id / thread_id），Agent 完全不感知用户从哪来
send_message 工具可以跨平台主动发消息（Cron 调度任务也走同一接口）

PM 启发：

早期 PM 容易在每个新平台做一个"专版"App，结果维护成本指数上升。Hermes 的 Gateway 抽象告诉我们：当能力稳定后，平台应该被视为"运输层"，能力才是"业务层"。

架构地图位置：见全景导读 §3 主线二（多平台一体）。

哲学 3 — 开源 Agent 是模型训练的数据飞轮

主张：开源 Agent 不只是"产品"，更是"数据引擎"。用户使用 → 轨迹捕获 → 压缩为训练数据 → RL 训练更好的 tool-calling 模型 → 产品更强 → 吸引更多用户。

Hermes 的体现：

environments/ 目录集成 Atropos RL 框架，HermesAgentBaseEnv 抽象类只需实现 format_prompt() + compute_reward() 即可启动训练
batch_runner.py 并行生成轨迹数据，Teacher 模型默认 claude-opus-4.6
trajectory_compressor.py 把对话压到 15250 Token 用于训练
Nous Research 用这个飞轮把大模型（Claude Opus）的 Agent 能力蒸馏到小模型（Qwen 3-4B），实现降本/提速/合规

PM 启发：

开源 Agent 项目要想清楚自己是"工具产品"还是"数据基础设施"。如果是后者，从第一天起就要设计可被训练的数据格式（Hermes 选 ShareGPT 格式）和可压缩的轨迹结构。

架构地图位置：见全景导读 §3 主线三（自进化闭环）。源码深度可读 Hermes 仓库 environments/ 目录。

哲学 4 — 安全是产品，不是功能

主张：上下文注入检测、子 Agent 权限隔离、PII 自动脱敏、危险命令审批 —— 这些不是"加分项"，而是 Agent 能在生产环境跑起来的前提。

Hermes 的体现（四层防护）：

命令审批：危险命令需用户确认，子 Agent 默认 auto-deny
路径安全：path_security.py 防止文件越权访问
Skill 安全扫描：skills_guard.py 对 Hub 安装的 Skill 做注入检测
上下文注入检测：prompt_builder.py 扫描 AGENTS.md / SOUL.md 中 10+ 种注入模式（prompt override、隐藏 div、凭据外泄 curl 等）
子 Agent 黑名单：DELEGATE_BLOCKED_TOOLS = {delegate_task, clarify, memory, send_message, execute_code}，禁止递归委派、禁止写共享记忆、禁止跨平台发消息
PII 自动脱敏：sender_id / chat_id 走 SHA256 哈希

PM 启发：

安全功能在路线图里永远排在"用户增长"之后，但一次注入事件就能让产品下架。判断一个 Agent 产品是否真的成熟——看它在没有人盯着的时候，安全模型还成不成立。

子 Agent 沙箱黑名单详细清单见本文 §模板 3。

哲学 5 — 模型无关 = 长期用户信任

主张：单一模型绑定是短期最优、长期负债。一旦用户信任了你的产品但绑死了某家模型，你就和那家模型共命运（涨价 / 降级 / 政策变更全要承担）。

Hermes 的体现：

通过 OpenAI SDK 统一入口，针对各厂商写 adapter（anthropic / gemini_native / bedrock / codex_responses / moonshot 等）
200+ 模型支持，包括 Ollama / NVIDIA NIM / 智谱 GLM / 小米 MiMo / Kimi / MiniMax 等中国厂商
Tool-call 解析器按模型分发（hermes / qwen / deepseek_v3 / llama / glm45 ...）
主模型故障时自动降级到备选模型

对应的工程代价：

适配层维护成本随支持模型数线性增长
不同模型的 prompt 表现差异巨大，需要模型异构注入（Claude 不需要工具提醒，GPT 要强制"用工具执行不要只描述"，Gemini 要强调绝对路径）

PM 启发：

适配层的粒度决定了"能接多少模型"的上限。如果你的 Agent 产品定位是"长期陪伴用户"，从第一版就要把 Provider 抽象做出来，不要等到迁移时才重构。

模型异构 Prompt 注入策略详见本文 §模板 2。

哲学 6 — 巨石的代价：早期效率 vs 长期门槛

主张：单文件巨石架构（run_agent.py 12K 行 + cli.py 11K 行）在早期快速迭代有优势——一处修改不需要跨文件协调；但到了 118K stars 阶段，社区贡献者需要消化全部 12K 行才能改一处，门槛极高。

Hermes 的体现（反面教材）：

核心循环全部塞在 run_agent.py 中，新贡献者上手成本远高于 Claude Code 的模块化设计
v0.11 已经做了部分模块抽离（curator / context engine），但主循环依然是巨石
早期 Skill 系统也是扁平列表，几百个 Skill 后搜索质量急剧下降，被迫升级为 umbrella 模式

PM 启发：

巨石不是错，预期不到的快速增长才是问题。如果你的 Agent 项目目标是开源 + 社区驱动，应该比预期更早做模块拆分；如果是闭源团队产品，巨石可以容忍更久。
推论：架构的复杂度应该匹配预期的协作规模，而非当前规模。

落地评估详细维度见全景导读 §5 落地评估。

哲学 7 — "自进化"的边界与误区（最重要的反营销化哲学）

主张：Agent 的"自进化"是一个被严重营销化的词。Hermes 明确划清边界，避免用户对能力产生错误预期。

Hermes 划的三条边界：

❌ 误解	✅ 实际
Hermes 会自动从用户对话中学习并训练模型	不会。RL 训练需要人工启动，且默认是 Teacher 模型（Claude Opus）的知识蒸馏，不是用户数据训练
Skill 自创建 = 模型能力提升	不是。Skill 只是外部知识库扩充，不改变模型权重
自进化 = 越用越聪明	部分对。Skill 路径让 Agent 越用越懂"这个用户的偏好"，但模型本身的逻辑能力不变

两条路径的本质区分：

路径	机制	效果	类比
外部路径：动态 Skill 生成	任务后复盘 → 抽象为 Markdown Skill	即时生效 / 可解释 / 可人工干预	"记笔记"
内部路径：RL 训练闭环	Teacher 蒸馏 → GRPO 算法 → 模型权重更新	深层能力提升 / 需算力 / 异步	"练内功"

为什么不直接用用户数据训练？

隐私问题：用户对话包含敏感信息
质量参差：低质数据会把模型训废
正确做法：人工导入 + Teacher 模型参考合成 + 质量把关

PM 启发：

在 Agent 产品对外宣传时，"自进化"很容易写成营销话术。负责任的做法是像 Hermes 一样在文档里显式划边界——这反而提升了用户对产品的信任度。

自进化的"内外双路径"全景见全景导读 §3 主线三。

第二部分：五处关键架构权衡

每个权衡都是一个"选 A 还是选 B"的决策点，Hermes 的选择和代价都值得参考。

权衡 1 — 比例阈值压缩 vs 绝对 Token 阈值

选项	OpenClaw（绝对阈值）	Hermes（比例阈值）
触发方式	固定 Token 数（如 18K / 20K）	占窗口比例（默认 50%）
切换模型	需调配置	自动适配任意窗口大小
例子	达到 18K Token 触发	200K 窗口 × 50% = 100K 时触发
代价	配置简单直观	不同窗口大小下用户感知不一致

Hermes 选了什么：比例阈值。理由：用户切模型频繁，比例阈值省去了重新配置的摩擦。代价：用户在小窗口（4K）和大窗口（200K）模型上对"何时压缩"的体感不一致。

权衡 2 — 后台 Fork Review vs 内联 Review

选项	内联	后台 Fork
实现复杂度	低	高（线程隔离 / stdout 重定向 / 工具白名单）
用户感知延迟	高（要等 Review 完成）	零延迟
API 调用成本	单次	多一次（最多 16 次迭代）
模型注意力	与用户任务竞争	隔离

Hermes 选了什么：后台 Fork。理由：用户体验优先，零延迟感知，多花的 API 钱由开源/自部署用户自己买单。代价：实现复杂，Review Agent 需要严格隔离（仅 memory + skills 工具 / 16 迭代上限 / auto-deny / _iters_since_skill = 0 防递归）。

权衡 3 — Umbrella Skill vs Flat Skill

选项	Flat（早期 Hermes）	Umbrella（当前）
创建难度	低	中（需要决定归到哪个 umbrella）
搜索匹配率	低（窄描述容易漏匹配）	高（宽描述更易命中）
维护成本	高（几百个 Skill 后退化为噪音）	低（Curator 周期合并）
知识丢失风险	高（Skill 数量爆炸难以管理）	低（umbrella 内部章节有结构）

Hermes 选了什么：Umbrella + Curator 整理。理由：早期 Flat 模式实测证明，几百个 Skill 后搜索质量急剧下降。代价：需要 LLM 驱动的 Curator 做合并决策，增加运行成本和实现复杂度。

权衡 4 — 归档 vs 删除

选项	删除	归档（移入 `.archive/`）
存储成本	0	持续增长
知识可恢复性	不可恢复	完全可恢复
误删后果	严重	无

Hermes 选了什么：归档。原文："Archives are recoverable; deletion is not." 理由：Agent 自主生成的知识可能在未来被证明有价值（例如某个"过时"的 workaround 在回退版本时重新有用）。代价：长期运行后 .archive/ 会积累大量历史 Skill，占用磁盘但不进检索。

权衡 5 — Skill 自动安全扫描默认开 vs 默认关

选项	默认开	默认关（Hermes 选的）
安全等级	高	中
用户摩擦	高（每次创建都要扫描）	低
真实威胁覆盖	全部	仅 Hub 安装的外部 Skill

Hermes 选了什么：Agent 自创建的 Skill 默认不扫描；Hub 安装的外部 Skill 必扫。理由：Agent 本来就能通过 terminal() 执行任意代码，扫描自创建 Skill 只增加摩擦不增加实质安全。代价：理论上 Agent 可以创建恶意 Skill，但前提是模型本身被攻陷——这种情况下扫描也无济于事。

第三部分：四套可复用的设计模板

直接抄作业。

模板 1 — "经验→知识→维护"三层闭环

适用于：任何需要"越用越懂用户"的 Agent 产品

┌─────────────────────────────────────────┐
│  Layer 1: 经验捕获                        │
│  - 触发：每 N 轮对话 / N 次工具调用         │
│  - 实现：后台 fork 一个隔离 Agent         │
│  - 输出：Skill 创建/更新                  │
├─────────────────────────────────────────┤
│  Layer 2: 知识存储                        │
│  - 结构：SKILL.md + references/         │
│           + templates/ + scripts/        │
│  - 操作：create / edit / patch           │
│           / delete / write_file          │
│  - 命名：class-level umbrella，不是 session-level │
├─────────────────────────────────────────┤
│  Layer 3: 周期维护                        │
│  - 状态机：active → stale(30天) → archived(90天) │
│  - 合并：LLM 识别集群 → umbrella 合并    │
│  - 安全：归档代替删除                     │
└─────────────────────────────────────────┘

关键设计点：

触发机制要克制（不是每轮都学），用 nudge counter 攒够才触发
优先更新本次实际加载的 Skill（"Active-update bias"）
Curator 必须有 dry-run 模式给人类审核

模板 2 — 模型异构注入策略

适用于：需要支持多模型的 Agent 产品

python

agent.tool_use_enforcement 配置：
├── "auto"（默认）→ 根据模型名自动判断
├── true → 强制注入
├── false → 不注入
└── ["gpt", "gemini"] → 只对列表中的模型注入

模型	典型问题	注入策略
Claude	天然擅长工具调用	一般不需额外提醒
GPT / Codex	"只说不做"	强制"用工具执行，不要只描述"
Gemini / Gemma	路径粗糙	强调绝对路径、先读后改、并行调用
Qwen / DeepSeek	工具调用格式差异	走专用 parser 解析

关键设计点：

不要假设所有模型都按 OpenAI 格式输出 tool_calls
Tool-call 解析器要按模型名称分发，不是统一一个 parser
Prompt 注入要对模型而非用户条件化

模板 3 — 子 Agent 沙箱隔离

适用于：支持任务委派 / 子 Agent 的 Agent 产品

python

DELEGATE_BLOCKED_TOOLS = {
    "delegate_task",   # 防递归委派
    "clarify",         # 防嵌套提问
    "memory",          # 防操纵共享记忆
    "send_message",    # 防消息劫持
    "execute_code",    # 防代码执行权限升级
}
MAX_CONCURRENT_CHILDREN = 3   # 最多 3 个并行子 Agent
MAX_DEPTH = 2                 # 最多 2 层嵌套

关键设计点：

子 Agent 必须有明确的工具黑名单（防递归 / 防越权）
父级只看到委派结果摘要，不看中间过程 = 零上下文成本
嵌套深度限制是必须的，否则会无限展开

模板 4 — 14 类结构化错误自愈

适用于：所有生产级 Agent 产品

错误类型	典型场景	恢复策略
`auth` / `auth_permanent`	API Key 无效/账号封禁	重试 / 终止
`billing`	额度用完	通知用户
`rate_limit` / `overloaded`	限流 / 服务器忙	退避重试
`context_overflow`	消息太长	触发压缩
`timeout` / `server_error`	网络 / 5xx	重试
`model_not_found` / `format_error`	配置错误	修正
`thinking_signature` / `long_context_tier`	Anthropic 特有	特殊处理

关键设计点：

不要把所有错误都 except Exception，要分类到具体策略
每类错误有独立的退避曲线（rate_limit 指数退避，timeout 线性重试）
context_overflow 应该触发压缩而非直接失败

第四部分：Agent 发展三阶段定位

把 Hermes 放到 Agent 演进史中：

阶段	代表产品	特征	Hermes 的位置
1. 被动式 Agent	早期 GPT 聊天	一问一答、不能调工具	已超越
2. 自主 Agent	OpenClaw / Claude Code	自主规划 + 工具调用，完成复杂长周期任务	完整继承
3. 自进化 Agent	Hermes	执行中学习，越用越强	代表最新阶段

Hermes 的差异化集中在三个维度：

自进化机制（vs OpenClaw / Claude Code 的静态 Skill）
模型异构适配（vs Claude Code 锁定 Claude / Codex 锁定 OpenAI）
比例阈值压缩（vs OpenClaw 的绝对阈值）
生态兼容（直接读 OpenClaw 的 AGENT.md / SOUL.md / USER.md，AI Coding 的 CLAUDE.md / .cursorrules）

竞争策略推论：Hermes 不试图重新教育用户，而是降低迁移成本——用户可以从 OpenClaw / Claude Code / Cursor 无缝切换。这是后发产品的典型策略。

第五部分：可复用 PM 检查清单

如果你正在评估 / 设计一个 Agent 产品，用这份清单对照 Hermes：

记忆系统

[ ] 是否区分 Memory（陈述性）和 Skill（程序性）？
[ ] Memory 注入是否有防注入隔离（如 <memory-context> 标签）？
[ ] 是否有跨会话检索（如 FTS5 + LLM 摘要）？

学习闭环

[ ] 是否有"经验捕获 → 知识存储 → 周期维护"三层完整闭环？
[ ] 触发机制是否克制（不是每轮都学）？
[ ] 是否优先更新本轮实际加载的 Skill（active-update bias）？
[ ] 是否归档代替删除？

模型抽象

[ ] 是否有 Provider 适配层？
[ ] 是否针对不同模型做 Prompt 异构注入？
[ ] 是否有自动降级机制？
[ ] Tool-call 解析器是否按模型分发？

多平台

[ ] 是否有统一的 Session 抽象？
[ ] 是否有 PII 自动脱敏？
[ ] 是否支持 Cron 调度跨平台投递？

安全模型

[ ] 是否有上下文注入检测？
[ ] 子 Agent 是否有工具黑名单？
[ ] 是否限制委派深度和并发数？
[ ] 危险命令是否走审批？

错误处理

[ ] 错误是否分类到具体策略（不是统一 except）？
[ ] 每类错误是否有独立退避曲线？
[ ] context_overflow 是否触发压缩而非失败？

自进化边界

[ ] 是否在文档中显式说明"哪些是真自进化、哪些不是"？
[ ] 用户数据训练的边界是否清晰？

与全库其他文档的关联

Agent 设计哲学与决策框架 — 本文的"七大哲学"是该文档的具体案例补充
Agent 工程实践与工具生态 — "四套设计模板"可作为该文档的案例库条目
Agent 范式演进与工程方法论 — "Agent 发展三阶段"对应该文档的演进图
Agent 评估与反思机制 — Hermes 后台 Review Fork 是反思机制的典型实现
Harness 失效模式与演化方向 — 14 类错误自愈表是该文档的工程案例

Hermes Agent — 设计哲学与 PM 启发录 ​

第一部分：七大产品哲学 ​

哲学 1 — Skill 是 Agent 的"程序性记忆"，必须与"陈述性记忆"分离 ​

哲学 2 — 多平台 ≠ 多产品：界面只是接入层，能力才是产品 ​

哲学 3 — 开源 Agent 是模型训练的数据飞轮 ​

哲学 4 — 安全是产品，不是功能 ​

哲学 5 — 模型无关 = 长期用户信任 ​

哲学 6 — 巨石的代价：早期效率 vs 长期门槛 ​

哲学 7 — "自进化"的边界与误区（最重要的反营销化哲学） ​

第二部分：五处关键架构权衡 ​

权衡 1 — 比例阈值压缩 vs 绝对 Token 阈值 ​

权衡 2 — 后台 Fork Review vs 内联 Review ​

权衡 3 — Umbrella Skill vs Flat Skill ​

权衡 4 — 归档 vs 删除 ​

权衡 5 — Skill 自动安全扫描 默认开 vs 默认关 ​

第三部分：四套可复用的设计模板 ​

模板 1 — "经验→知识→维护"三层闭环 ​

模板 2 — 模型异构注入策略 ​

模板 3 — 子 Agent 沙箱隔离 ​

模板 4 — 14 类结构化错误自愈 ​

第四部分：Agent 发展三阶段定位 ​

第五部分：可复用 PM 检查清单 ​

与全库其他文档的关联 ​

Hermes Agent — 设计哲学与 PM 启发录

第一部分：七大产品哲学

哲学 1 — Skill 是 Agent 的"程序性记忆"，必须与"陈述性记忆"分离

哲学 2 — 多平台 ≠ 多产品：界面只是接入层，能力才是产品

哲学 3 — 开源 Agent 是模型训练的数据飞轮

哲学 4 — 安全是产品，不是功能

哲学 5 — 模型无关 = 长期用户信任

哲学 6 — 巨石的代价：早期效率 vs 长期门槛

哲学 7 — "自进化"的边界与误区（最重要的反营销化哲学）

第二部分：五处关键架构权衡

权衡 1 — 比例阈值压缩 vs 绝对 Token 阈值

权衡 2 — 后台 Fork Review vs 内联 Review

权衡 3 — Umbrella Skill vs Flat Skill

权衡 4 — 归档 vs 删除

权衡 5 — Skill 自动安全扫描默认开 vs 默认关

第三部分：四套可复用的设计模板

模板 1 — "经验→知识→维护"三层闭环

模板 2 — 模型异构注入策略

模板 3 — 子 Agent 沙箱隔离

模板 4 — 14 类结构化错误自愈

第四部分：Agent 发展三阶段定位

第五部分：可复用 PM 检查清单

与全库其他文档的关联