为什么我认为 Hermes 需要说明 self-evolution 的设计来源

虽然我写了不一定会被看到，毕竟个人项目没什么影响力，就当是一次小小的牢骚，记录一下

摘要 ：这不是一篇先下结论的文章，而是一份基于公开仓库时间线 、实现细节 与方向可发现性的来源追问。

为了避免把范围拉得过大，本文只讨论一类更具体的系统：交互式 agent 主循环里的 skills / memory / prompt 运行时自进化闭环 。就目前可核验的公开证据看，SkillLite 至少在 **2026-02-28** 已经公开落下完整的 evolution engine，并在 **2026-03-01** 加入了 skills 的 _pending 待确认流程；而 Hermes self-evolution 在 **2026-03-09** 建仓当天的初始提交。即便按这个最保守的公开口径比较，SkillLite 仍然早了大约 9 天。如果把比较范围限定在这一层，SkillLite 与 Hermes 的公开设计仍然存在值得追问的接近性：Hermes 的这套设计来源与演进时间线，到底是什么？

---

一、先说结论和诉求

我想表达的其实很明确：

• SkillLite 在公开时间线上，早于 Hermes self-evolution 仓库落下了 skills 自动生成这条主线。
• 如果把范围限定在交互式 agent 主循环里的运行时自进化闭环 ，那么 Hermes 公开方案在 skills / memory / prompt 三条演化线 上，和 SkillLite 有高度的重合。
• 在这一更窄的比较范围里，SkillLite 作为一个公开、英文、可检索的 GitHub 项目，并不是一个很难被发现的样本。
• 所以我认为，Hermes 有需要说明其设计来源与演进时间线。

但我没有在主张的是：

• 仅凭这篇文章，就已经可以下法律意义上的"抄袭成立"结论。
• 仅凭几天时间差，就能自动证明 Hermes 一定看过 SkillLite。
• Hermes 的全部设计都来自 SkillLite。

所以这篇文章本质上是一份公开但克制的来源质疑，不是提前替事实下结论。

---

二、我质疑的是什么

我想指出的是：在交互式 agent 的主循环里，系统从执行轨迹中提取信号，再把经验沉淀成可长期复用的 skills、memory 和 prompt rules / examples，并把这些资产纳入审核、门禁和治理流程。在这条线里，最值得比较的是 skills 的自动生成和后续治理。

---

三、为什么我把 skills 自动生成当作核心争议点

原因很简单：这在 SkillLite 里不是一句概念，而是很早就已经落成代码，而且逻辑已经相当完整。

就我目前查到的公开仓库记录，SkillLite 在 **2026-02-28 18:05:33 +0800** 的提交 32206ca 中，已经新增了完整的 evolution engine 相关模块：

• crates/skilllite-agent/src/evolution/mod.rs
• crates/skilllite-agent/src/evolution/feedback.rs
• crates/skilllite-agent/src/evolution/prompt_learner.rs
• crates/skilllite-agent/src/evolution/skill_synth.rs
• skilllite/src/commands/evolution.rs
• crates/skilllite-agent/src/seed/evolution_prompts/*.md

更关键的是，这不是一个空壳模块。当时老版本的 crates/skilllite-agent/src/evolution/skill_synth.rs 已经具备这些主逻辑：

• evolve_skills(...)
• generate_skill(...)
• refine_weakest_skill(...)
• retire_skills(...)
• 从 decisions 查询重复模式
• 用 LLM 生成 SKILL.md + script
• 经过 L3/L4 检查与 refinement loop
• 记录 skill_generated

也就是说，到 2026-02-28 为止，SkillLite 不是"有一个想法"，而是已经公开实现了：

• 自动生成 skill
• 对弱 skill 做精炼
• 对低价值 skill 做淘汰

这一点很重要。因为后面和 Hermes 比较时，时间锚点不能放在后来拆分出来的 crates/skilllite-evolution/src/skill_synth/ 目录版上；那个目录版只是后续重构和模块化的结果，不是首次出现。

---

四、_pending 待确认不是后来的包装，而是很快就加入的核心治理语义

SkillLite 的 skills 进化，并不是"自动生成之后直接无门槛放行"。

就我目前查到的公开仓库记录，到了 **2026-03-01 13:18:16 +0800** 的提交 36cbf93，老路径 crates/skilllite-agent/src/evolution/skill_synth.rs 已经进一步加入：

• A10: Newly generated skills go to _evolved/_pending/ until user confirms
• skill_pending
• list_pending_skills(...)
• confirm_pending_skill(...)
• reject_pending_skill(...)

也就是说，在 Hermes self-evolution 公库出现前，SkillLite 已经不是单纯的"自动生成新 skill"，而是已经进入了更完整的第二阶段：

• 自动生成
• 进入 _pending
• 人工确认 / 拒绝

这是我觉得最值得认真比较的地方。因为它让 SkillLite 的 skills 进化不再只是"生成一段文字"，而是明确把 skill 当成一种待审能力资产来治理。

---

五、当前 skilllite-evolution/skill_synth/ 目录版只是重构结果，不是首次出现时间

为了避免误解，这里必须说清楚：

现在仓库里看到的：

• crates/skilllite-evolution/src/skill_synth/mod.rs
• crates/skilllite-evolution/src/skill_synth/generate.rs
• crates/skilllite-evolution/src/skill_synth/refine.rs
• ...

这套结构不是最早的起点，而是后面把原先的单文件逻辑抽离、整理、模块化之后的形态。

如果只看公开仓库里能直接核对的证据，真正的时间线应该这样看：

时间	公开证据	说明
2026-02-28 18:05:33 +0800	32206ca	evolution engine 首次成套落库；已含 skill generation / refine / retire
2026-03-01 13:18:16 +0800	36cbf93	加入 _pending、skill_pending、confirm/reject
2026-03-01 23:53:55 +0800	5048a76	迁入 skilllite-evolution，属于后续模块化

所以，如果把"后来的目录拆分时间"误当成"这条设计第一次出现的时间"，就会低估 SkillLite 在这条线上的真实起点。

---

六、再往前追：2 月 28 日不是"突发灵感"，而是一次公开集成爆发点

正常推理逻辑，如果一个项目在某一天一次性提交了下面这些东西：

• evolution 模块
• prompt learner
• skill synth
• feedback / decisions / metrics
• evolution prompts
• evolution CLI

大概率不是当天突然冒出来的想法，而是前面已经做了一段时间。

就公开仓库可验证的历史看，SkillLite 在 2026-02-28 首次把 evolution engine 成套落库；而在此之前，项目已经连续铺设了 skills / memory / prompt / planning / observability / governance 这些关键底座。

仓库历史里相关模块的构建过程：

2026-02-12

• 7defe91
• feat: Add chat feature with session management and memory capabilities

更早就已经有 chat + session + memory 基础。

2026-02-14

• f61e9ce
• feat: Introduce planning rules configuration for task planning

说明更早就在做规则化 planning，这和后面的 prompt/rule learner 是连续的。

2026-02-16

• 7dd0236
• feat: Introduce LLM agent chat feature

说明 agent loop 在 evolution 前已经成形到一定程度。

2026-02-17 到 2026-02-24

这段时间里，仓库不断强化：

• skills 的执行与管理
• skill integrity
• trust assessment
• admission risk assessment
• security scanning for SKILL.md

这意味着，SkillLite 在 evolution engine 正式落库前，已经把 skill 当成受治理的能力单元来处理。

2026-02-20

• 775b81c
• feat: Implement memory vector search functionality with sqlite-vec integration

2026-02-20

• cb2fe14
• feat: Enhance task planning and memory integration in agent loop

这两步说明：

• memory 已经不只是文件存储，而是朝可检索、可融合进 agent loop 的方向演进。
• planning + memory 已经开始互相接入。

2026-02-26

• 0fc6c38
• feat: Enhance prompt building with project structure indexing and auto-indentation

2026-02-26

• 6461f7a
• feat: Enhance task planning with new rules and error handling

说明 prompt / planning / rules 这条线，也在 evolution engine 前一天到两天内持续补强。

所以，最稳的说法不是"我在 2 月 28 日突然想到 self-evolution"。

---

七、Hermes 的时间线为什么值得被放到一起看

就我目前查到的公开信息，NousResearch/hermes-agent-self-evolution 的 GitHub 仓库元数据是：

• created_at: 2026-03-09T10:42:48Z

换算东八区，大约是：

• 2026-03-09 18:42:48 +0800

如果以公开仓库里最保守、也最容易核对的时间线来比较：

• SkillLite 在 **2026-02-28** 已经公开实现 skills 自动生成主逻辑
• SkillLite 在 **2026-03-01** 已经公开实现 _pending 待确认语义
• Hermes 在 2026-03-09 建仓。

也就是说，就算完全按对 Hermes 最宽松、最保守的公开口径来算，SkillLite 仍然早了大约 9 天。这个时间差当然还不足以单独推出"抄袭已经成立"，但在一个公开项目稀少、方向又不拥挤的赛道里，它已经不是可以被轻描淡写带过的细节。

我不会夸大这一点。

如果这是一个热门的大方向，我不会因为 9 天时间差专门写这篇文章；但在一个公开实现本来就不多的 skills 自进化方向里，这样的相似性和先发时间差，我认为应该值得一个公开回应：

Hermes 的这套设计是怎样形成的？

---

八、为什么我认为这不是一种普通的大方向重合

如果只讨论"优化 prompt""做 agent memory""做人机协作"这种很宽的大方向，我不会轻易写这篇文章。

我真正关心的是更窄的一层：交互式 agent 主循环里的运行时自进化闭环。 在这条线上，SkillLite 和 Hermes 的高度重合，不只是概念上都在讲"self-evolution"，而是落在了更具体的几件事情上：

1. 都把运行中的执行轨迹当成信号来源

• 不是只保存聊天记录，而是把运行过程本身当成后续改进的输入

2. 都把经验沉淀回 skills / memory / prompt

• 不是孤立调一个 prompt，而是把改进回流到 agent 日常运行依赖的能力层

3. 都带有明显的治理和门禁意味

• SkillLite：_pending、confirm/reject、后续 backlog/coordinator/policy
• Hermes：tests、constraint gates、human review、PR merge

4. 时间线上，SkillLite 的公开实现更早

• 至少按公开仓库里最保守的可核验口径，SkillLite 在这一层的实现早于 Hermes

所以，我的质疑并不是"大家都会优化 AI，为什么你也优化了 AI"；

而是：

如果把比较范围限定在交互式 agent 主循环里的 skills / memory / prompt 运行时自进化闭环，为什么一个更晚公开的项目，会和 SkillLite 更早公开的设计如此接近？

---

九、关于"可发现性"：为什么我认为这不是一个低概率接触场景

我知道有人会说：你当时 star 也不算特别多，团队未必会看到你。

但"是否容易被发现"，并不只看 star 数。

对这件事更重要的是：

• SkillLite 是一个公开 GitHub 项目
• 项目主信息是英文
• 如果把比较范围限定在交互式 agent 主循环中的 skills / memory / prompt 运行时自进化这条线上，SkillLite 并不是一个很难被发现的项目
• 当 Hermes 开始集中对外强调 self-evolution、尤其强调 skills 演化时，SkillLite 这类公开、英文、可检索的项目，本来就更容易进入比较视野
• 除了 GitHub，我也持续通过公开文章做过传播

这并不能直接证明：

• Hermes 一定看过我

但它足以支持一个更稳的判断：

Hermes 接触到 SkillLite 公开设计的可能性，不应被视为低概率事件。

如果把范围收窄到我真正关心的这一层，那么公开、英文、可检索，再加上持续的公开传播，这些条件合在一起，已经足以提高"被发现"的现实概率。

---

十、为什么我也需要区分 SkillLite 与 EvoMap

这里我也想说明一点：我的质疑并不是对 EvoMap 质疑的简单重复。两边虽然都在讨论 self-evolution，但并不是同一层设计。

EvoMap 更偏向协议化、网络化的 evolution 框架，强调 Gene / Capsule / GEP / Hub 这一类可发布、可分发、可治理的进化资产。SkillLite 则更偏向 agent runtime 内部的自进化闭环：从执行轨迹里提取信号，把经验沉淀为 skills / memory / prompt，并通过 _pending、confirm / reject、后续治理与验收机制，把这些能力资产真正纳入日常运行。

也正因为如此，我这篇文章的重点并不是"谁先做 self-evolution"这个过大的命题，而是：在 agent skills 自动生成、沉淀与治理这条更具体的线上，Hermes 的公开方向为什么会和 SkillLite 更早公开的设计这么接近。

---

十一、为什么我不把 prompt 当作最强证据

这点也必须说明白。

如果只谈 prompt optimization，我并不认为这是最强证据。

因为 prompt 优化本身就是更通用的方向，很多框架、平台和研究都在做。

所以我的核心主张从来不是：

• "谁先想到改 system prompt"
• "谁先做 prompt optimizer"

我真正想强调的是：

SkillLite 不是把 prompt 当成孤立对象来优化，而是把 prompt / memory / skills 统一放进一个 runtime self-evolution 闭环里。

因此，在相似性比较里：

• skills 是最强证据
• memory 是辅助强证据
• prompt 更适合作为辅助相似点，而不是主证据

---

十二、我现在希望 Hermes 说明什么

我并不要求 Hermes 立刻承认任何结论。

但如果 Hermes 认为这一切只是独立发展，那最有说服力的做法其实很简单：

1. 公开 self-evolution 设计的最早内部时间线
2. 说明 skills / memory / prompt 三线演化是如何逐步形成的
3. 给出早于公库的原型、路线图、设计文档或讨论证据
4. 说明是否接触过 SkillLite 及其公开仓库、文章、讨论

如果这些问题有清晰答案，争议自然会缩小。

如果这些问题长期没有答案，公众当然也有权继续保留质疑。

---

十三、结语：这不是"先发就有理"，而是"在小众方向里，先发与相似性值得被认真对待"

我并不认为"谁先 commit，谁就自动拥有一切道德制高点"。

软件世界里，独立想到同一方向并不罕见。

但这件事之所以值得写下来，是因为它同时满足了几个条件：

• 方向前沿且小众
• 公开项目不多
• SkillLite 的公开实现更早
• 技术问题定义重合度高
• skills 自动生成与治理这条线尤其接近
• 项目公开且易被发现

我也想把这件事说得更直接一些：

SkillLite 不是一个大团队项目，而是我作为个人开发者持续数月投入、反复试错、一步步搭起来的公开探索。像 skills 自动生成、_pending 待确认，以及后续围绕 memory / prompt / governance 的演化闭环，并不是一两天里凭空冒出来的点子，而是在一个并不拥挤、也并不容易做出来的方向上，靠长期投入慢慢堆出来的结果。

所以我写这篇文章，并不只是为了争一口气，也不是想把公开讨论变成情绪对立。我真正希望得到的，其实是一个很基本的东西：回应。 如果 Hermes 的这套设计确实有独立来源，那就把时间线、原型和形成过程讲清楚；如果在形成过程中确实参考、接触，或者受到了既有公开项目的影响，也应该坦诚说明。

对个人开发者来说，最难的往往不是做出第一版，而是当成果开始被更大团队、更大声量覆盖时，还能不能得到最起码的承认与尊重。

如果连这种层面的公开说明都变得可有可无，那么"开放创新"最终保护的，就更像是传播能力更强的一方，而不是更早做出探索的一方。那样的话，个人开发者为什么还要愿意把早期创新公开放到 GitHub 上？个人创新的保护，又从何谈起？

我现在最核心的判断只有一句：

截至目前公开可核验的证据，SkillLite 至少在 Hermes self-evolution 公库之前，就已经完整的公开实现了以 skills 自动生成与治理为核心的自进化链路；在一个小众且可发现的方向里，Hermes 理应对其设计来源与演进时间线做出更透明的说明。

---

附：本文使用的主要公开证据边界

为了避免过度延伸，本文只依赖以下类型的公开或仓库内可核验证据：

• SkillLite 仓库公开 commit 历史
• GitHub API 可见的 Hermes 仓库创建时间
• SkillLite 仓库中 evolution 相关文件与符号的首次出现
• 2026-02-28 前后关键文件的实际内容回溯

本文没有把以下内容当作既定事实：

• Hermes 私有仓库中是否存在更早原型
• Hermes 团队是否明确访问过 SkillLite
• 法律意义上的最终侵权结论

因此，这篇文章的定位始终是：基于公开证据的来源质疑与时间线追问。