为什么我认为 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
• …

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

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

所以，如果把“后来的目录拆分时间”误当成“这条设计第一次出现的时间”，就会低估 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
• 法律意义上的最终侵权结论

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