就在今天，AI Agent开始自己给自己「删库跑路」了

上周五，GitHub上炸出了一条重磅release。

Hermes Agent v0.12.0上线，官方给它的代号是「The Curator」。我一开始以为又是那种常规迭代，修几个bug，加几个provider完事。结果一看commit数，1096个。550个PR被合并。217个贡献者。讲真，这个量级已经赶上一个小型开源项目的年度总结了。

真正让我愣住的是第一条特性描述。

Autonomous Curator。后台运行的一个agent，每7天自动跑一轮，给你的技能库打分、剪枝、合并同类项。它会把长期不用的技能判定为「可能要删」，把功能重叠的多个技能合并成更精简的版本，然后把归档记录写到日志里。

「装了一堆skill，用了三个月之后，现在有东西在帮你收拾烂摊子」，这句话不是我编的，是release note原文的意思。

不是你自己手动管理。是你部署的AI，在帮你管它自己的技能库。

这个细节听起来很小。但如果你真正在生产环境里跑过AI Agent，应该明白我在说什么。

技能库腐烂，大概是仅次于「上下文长度不够」的第二大噩梦。

我认识几个团队，从去年底开始用OpenClaw和Hermes Agent做自动化流程。一开始兴奋得不行，什么skill都往上装，github-workflow、slack-bot、web-researcher、data-analyst，恨不得把所有能力一口气塞进去。跑了两周，agent开始出现奇怪的行为，问它做什么它要卡半天，同一个任务它换三种方式试，技能之间开始打架。

根本原因是skill太多了，agent自己都分不清该调用哪个。

这时候你有两个选择。第一，老老实实一条一条去审计，问agent「你现在装了哪些skill」「哪些可以删」，然后手动清理。第二，承认自己懒，关掉电脑去摸鱼。

Hermes Agent v0.12.0给出的答案是第三条路，让agent自己来判断。

具体逻辑是这样的。Curator运行的时候，会先给技能库里每个skill打分。依据是什么？使用频率、最后一次调用的时间、和其他skill的功能重叠度。得分低的，判定为「可能死亡」的技能，进入归档队列。然后Curator会生成一份报告，说明这次归档了哪些技能、为什么归档。

整个过程不需要人介入。你唯一需要做的，就是偶尔瞟一眼那个 REPORT.md 文件。

防御纵深的设计也挺有意思。bundled和hub来源的技能，被锁定在保护层里，Curator动不了它们。只有用户自己安装的技能才会进入评估流程。说到底，核心能力不会因为打分算法的误判而被意外删除。

这个边界处理，坦白讲，比我预期的要细致。

顺着这个思路聊，就不得不提另一条正在悄悄生长的线索。

自我管理之外，还有自我进化。

NousResearch同期放出的另一个项目叫 hermes-agent-self-evolution，目前2.4k stars。名字已经说清楚它的野心了。用DSPy加上GEPA（Genetic-Pareto Prompt Evolution），让agent自动优化自己的skill文件、系统提示词和工具描述。

原理不复杂。读取执行日志，找出失败的原因分布，然后对skill文件做定向突变。比方说，你的github-code-review skill在某次运行中漏检了一个安全漏洞，self-evolution会分析这是提示词里没说清楚还是工具描述有歧义，然后生成若干改进候选，跑一遍评估，选出最优版本，最后以PR的形式提交。

整个过程走的是API调用，不需要GPU，单次优化成本2到10美元。

成本很低，但意义不低。

这意味着，一个skill在被写出来之后，不是静态的。它会因为真实使用中的反馈，被持续迭代优化。写skill的人不再需要预测所有edge case，模型会自己在生产环境里找到问题，然后修。

Phase 1已经上线，对准的是skill文件本身。Phase 2到Phase 5分别对准工具描述、系统提示词、工具实现代码，以及自动化pipeline。目前Phase 1跑通之后，后续的扩展路径是清晰的。

我看到有人在讨论区问，这个和直接fine-tune模型有什么本质区别。答案很简单，fine-tune改变的是模型权重，这东西改变的是指令文本。指令变了，行为就变，不需要重新训练。而且这套东西是model-agnostic的，换个底模照样跑。

聊到这里，整个图景就慢慢浮现出来了。

2026年的AI Agent技能生态，正在经历一次分层。

底层是模型本身，能跑通基本任务。中层是各种skill，向agent注入特定领域的能力。上层是技能管理层，让skill不要乱长、不要打架、不要变成数字垃圾。更上层是技能进化层，让skill自身能够基于真实反馈持续优化。

Hermes Agent v0.12.0解决的是中间两层的问题。self-evolution解决的是最上层的问题。

这两件事碰在一起发生，不是巧合。

技能管理这件事，在圈子里一直有两种路线之争。

一种叫「 marketplaces路线」，建一个技能商店，让大家上传、评分、交易。VoltAgent维护的 awesome-openclaw-skills 就是这条路，目前收集了5400多个skill，但他们在README里写得很清楚，筛掉了7000多个「可能是spam、低质量、加密货币相关、恶意」的提交，官方registry里有13729个skill，他们只收录了5211个。

过滤标准是公开的，批量账号刷的不要，名字重复的不要，英文描述写得很烂的不要，涉及金融交易的不要，已经被安全审计标记为恶意的不要。

这个筛选逻辑很有意思。它不是技术问题，是运营判断问题。什么样的skill算「低质量」？什么样的描述算「烂」？这些标准靠人工审核根本做不过来，VoltAgent的方案是用规则加人工复查，但即使这样，也只能做到「事后补救」，没法在skill安装之前就告诉你它会不会出问题。

另一种叫「安全扫描路线」，在skill安装之前就做一轮静态分析，提前拦截恶意代码。

HermesHub是这个思路的极端版本。他们在skill listing之前，加了65条威胁检测规则，覆盖8个类别，数据泄露、提示词注入、破坏性命令、混淆代码、硬编码密钥、网络滥用、环境变量滥用、供应链攻击。关键在于，Critical级别的发现会直接block merge，而且admin没有权限绕过这个block。

这个设计把安全检查变成了一个强制门禁，而不是可选项。

顺着这条线往深了看，问题就更复杂了。2月份的时候，有安全研究团队扫了一遍ClawHub，找出了824个恶意skill，占当时总量的20%。这个数字是公开信息，任何人都可以在GitHub issue里找到原始报告。4月份，另一家安全公司Ethiack用他们的 autonomous pentester产品 Hackian，对一个运行中的OpenClaw Gateway实例做了一次攻击测试，从账户接管到RCE，两小时不到，全程无人干预。

这些数字单独拎出来都很吓人。但放在一起，指向的结论是清晰的，技能层是AI Agent系统里最薄的一环。模型能力在变强，skill数量在爆炸，但skill的安全管控体系，还在婴儿期。

有意思的是，商业力量正在往这个方向涌。

3月份的时候，NSFOCUSLLM推出了AI-SCAN，专门针对OpenClaw生态系统做安全评估。官方说法是覆盖四个维度，gateway暴露面、凭证存储、记忆污染、供应链安全。4月份，Product Hunt上出现了一个叫SClawHub的产品，定位是「skill安装前的信任评分」，你在安装一个skill之前，能看到它的安全报告，然后决定装还是不装。

这两个产品面向的用户群体不太一样。AI-SCAN偏企业，做的是系统性风险评估。SClawHub偏个人开发者，做的是安装决策辅助。但核心解决的是同一个问题，如何在skill数量爆炸的背景下，让用户有足够的信息做出安全判断。

这波安全产品的出现时间节点本身就说明了很多。生态系统先有漏洞，然后才有专门针对漏洞的工具。这是技术演化的正常路径。问题是什么时候能追平。

回到Hermes Agent v0.12.0。

我在release页面看了很久，最打动我的不是Autonomous Curator，不是self-improvement loop升级，也不是Spotify和Google Meet的集成。而是一条很小的说明文字，

Prior-turn tool messages excluded from the summary so the fork sees a clean context.

这句话在说什么？意思是，当后台的自我改进fork运行时，它读取的是上一轮的「干净」上下文，不包含工具调用的具体内容。这样做的原因是避免fork在分析的时候看到一堆JSON格式的工具返回结果，然后被干扰判断。

一个这么细节的实现考虑，被写进了release note里。

说明写这段话的人，真的在生产环境里跑过这套系统，而且被这个问题坑过。

这种感觉很难描述。就是你在看一个开源项目的release note，有些项目会写「我们优化了性能」「我们修复了若干bug」。Hermes Agent的release note读起来像是在跟你讲，我们上周被这个问题烦到了，然后我们修了，你可能也会遇到，所以告诉你一声。

这种写法，在大厂的开源项目里几乎看不到。

2026年5月的第一天，AI Agent的技能管理正在经历一个转折点。

从手动到自动，从静态到进化，从无序到自净。这个转变的速度比我年初预计的要快。Hermes Agent v0.12.0的Autonomous Curator是一个标志性事件，它意味着「agent自己维护自己的能力」这件事，第一次被放到了核心功能的位置上，而不是作为实验性特性藏在某个flag背后。

但与此同时，skill的安全问题还没有被根本解决。824个恶意skill、20%的恶意占比、两小时RCE，这些数字不会因为多了几个扫描工具就消失。它们会持续给整个生态敲警钟。

技能生态的两条线，一边是管理自动化，一边是安全合规，正在并行向前。哪条线会先走到一个相对成熟的阶段，现在还看不清。但有一点是确定的，

如果你现在还在靠手动管理skill库，你可能需要认真考虑一下自动化方案了。不是因为效率问题，而是因为这个差距正在拉开。

以上内容不构成投资建议。