为什么我认为 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.rscrates/skilllite-agent/src/evolution/feedback.rscrates/skilllite-agent/src/evolution/prompt_learner.rscrates/skilllite-agent/src/evolution/skill_synth.rsskilllite/src/commands/evolution.rscrates/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 confirmsskill_pendinglist_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.rscrates/skilllite-evolution/src/skill_synth/generate.rscrates/skilllite-evolution/src/skill_synth/refine.rs…这套结构不是最早的起点而是后面把原先的单文件逻辑抽离、整理、模块化之后的形态。如果只看公开仓库里能直接核对的证据真正的时间线应该这样看时间公开证据说明2026-02-28 18:05:33 080032206caevolution engine 首次成套落库已含skill generation / refine / retire2026-03-01 13:18:16 080036cbf93加入_pending、skill_pending、confirm/reject2026-03-01 23:53:55 08005048a76迁入skilllite-evolution属于后续模块化所以如果把“后来的目录拆分时间”误当成“这条设计第一次出现的时间”就会低估 SkillLite 在这条线上的真实起点。六、再往前追2 月 28 日不是“突发灵感”而是一次公开集成爆发点正常推理逻辑如果一个项目在某一天一次性提交了下面这些东西evolution 模块prompt learnerskill synthfeedback / decisions / metricsevolution promptsevolution CLI大概率不是当天突然冒出来的想法而是前面已经做了一段时间。就公开仓库可验证的历史看SkillLite 在2026-02-28首次把 evolution engine 成套落库而在此之前项目已经连续铺设了skills / memory / prompt / planning / observability / governance这些关键底座。仓库历史里相关模块的构建过程2026-02-127defe91feat: Add chat feature with session management and memory capabilities更早就已经有chat session memory基础。2026-02-14f61e9cefeat: Introduce planning rules configuration for task planning说明更早就在做规则化 planning这和后面的prompt/rule learner是连续的。2026-02-167dd0236feat: Introduce LLM agent chat feature说明 agent loop 在 evolution 前已经成形到一定程度。2026-02-17到2026-02-24这段时间里仓库不断强化skills的执行与管理skill integritytrust assessmentadmission risk assessmentsecurity scanning for SKILL.md这意味着SkillLite 在 evolution engine 正式落库前已经把skill当成受治理的能力单元来处理。2026-02-20775b81cfeat: Implement memory vector search functionality with sqlite-vec integration2026-02-20cb2fe14feat: Enhance task planning and memory integration in agent loop这两步说明memory已经不只是文件存储而是朝可检索、可融合进 agent loop 的方向演进。planning memory已经开始互相接入。2026-02-260fc6c38feat: Enhance prompt building with project structure indexing and auto-indentation2026-02-266461f7afeat: 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”而是落在了更具体的几件事情上都把运行中的执行轨迹当成信号来源不是只保存聊天记录而是把运行过程本身当成后续改进的输入都把经验沉淀回skills / memory / prompt不是孤立调一个 prompt而是把改进回流到 agent 日常运行依赖的能力层都带有明显的治理和门禁意味SkillLite_pending、confirm/reject、后续 backlog/coordinator/policyHermestests、constraint gates、human review、PR merge时间线上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 认为这一切只是独立发展那最有说服力的做法其实很简单公开 self-evolution 设计的最早内部时间线说明skills / memory / prompt三线演化是如何逐步形成的给出早于公库的原型、路线图、设计文档或讨论证据说明是否接触过 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法律意义上的最终侵权结论因此这篇文章的定位始终是基于公开证据的来源质疑与时间线追问。