这段时间Hermes Agent 被讨论得很多。热闹的部分不重复了。让我停下来的还是之前一直在想的那个问题Agent 做完一件复杂事情以后系统到底留下了什么只留下聊天记录下次还是要翻历史。只留下几条 Memory大概能记住你是谁“项目在哪里”。但如果它能留下一个可复用、可验证、可修订的做事方法后面用起来会很不一样。我现在越来越觉得Agent 的下一轮差距不会只落在更长上下文和更强模型上还会落在它有没有一层可维护的过程资产。Hermes 在这件事上做得比大多数开源 Agent 彻底。这篇不打算做源码导读更想借着它聊一个更大的问题——团队经验怎样被写进系统。太长不看版•Memory、Session Search、Skill 得分开看。事实记忆回答环境和偏好是什么会话检索回答过去聊过什么Skill 回答的是这类事以后怎么做。•Hermes 吸引我的不只是会自动写 Skill。更关键的是它把过程资产放进了运行时主路径创建、加载、使用、修补、安全扫描一整套都系统化了。•这条线和前面写过的 Claude Skills、Codex AGENTS.md、OpenClaw 是同一类问题。都在把隐性经验外部化让人和 Agent 都能复用。•自动沉淀经验很诱人也很危险。没有评估、版本、权限和回滚自动生成的 Skill 很容易把一次误判固化成长期默认动作。•更稳的方式是先从高频流程、验证流程、排障流程开始。先让经验变小、变准、可检查再谈自我进化。Agent 长期资产分层先把记忆拆开很多 Agent 讨论会卡在一个词上Memory。用户偏好叫 Memory项目路径叫 Memory上次失败的日志也叫 Memory。再往外扩部署步骤、排障经验、PR review 清单好像都能叫 Memory。词一宽系统边界就糊了。层次保存什么更适合的形态事实记忆用户偏好、项目约定、环境事实小型 memory 文件或用户画像会话检索历史对话、任务记录、上下文线索SQLite / FTS / 向量检索过程资产流程、坑点、验证、工具组合Skill、Runbook、Checklist拿发一个 Next.js 服务举例。Memory 记的是仓库在哪、默认分支是什么、团队用 pnpm、线上在 Vercel。Session Search 找的是上次这个项目发布时踩过什么坑。Skill 留下的是以后这类发布该怎么做先检查环境变量再跑构建再 smoke test最后看日志回执。这三层都像记忆但其实不是一回事。Hermes 的内置 memory 由MEMORY.md和USER.md两个文件组成容量是刻意收紧的MEMORY.md约 2,200 字符USER.md约 1,375 字符。会话开始时作为 frozen snapshot 注入系统提示中途更新会落盘但不会改当前会话的 system prompt。之前聊过这个设计现在再看还是觉得克制。它不是不能更新记忆而是刻意不在会话中途重建 system prompt。背后不是偷懒是很现实的成本判断——高变化的信息不该放进一个需要长期命中缓存的骨架里。之前聊 prompt caching 时算过这笔账Claude Code 92% 缓存命中率靠的就是稳定前缀不乱动。Hermes 在 memory 这层做了一样的取舍。历史会话交给state.db和 FTS5 检索。需要找上次怎么处理的用session_search召回就行不用每次都把历史塞进模型。之前我把它比作档案室这个比方现在还管用档案室很重要但你不会把每个柜子都背在身上。Skill 再往前一步。它不只回答上次发生了什么还会把成功路径整理成这类事情以后怎么做。这就是我说的过程资产。Hermes 把过程资产放到了运行时Hermes GitHub README 对自己定位很直接self-improving AI agent。之前把它和 OpenClaw 摆在一起看过。简单说OpenClaw 更偏入口和调度——消息怎么进来、会话怎么路由Hermes 更偏执行和学习引擎——工具怎么用、经验怎么沉淀。这次不重复那个对比更想看的是 Hermes 在 Skills 这层到底做到了什么程度。官方 Skills 文档把 Skill 定义成按需加载的知识文档走 progressive disclosure。大意是• Level 0先看skills_list()只拿名称、描述、分类• Level 1相关时用skill_view(name)加载完整内容• Level 2需要细节时再加载某个支撑文件。这个设计和 Anthropic Skills 的方向是一致的——Skill 不适合写成一段巨大的提示词更适合做成一组可按需进入上下文的工作单元。Hermes 更进一步的地方是 Agent 可以自己创建、修补、编辑、删除 Skill。复杂任务成功完成、走过错误和死胡同、用户纠正了做法、发现非平凡工作流都可能触发 Agent 创建 Skill。这就把 Skill 从人写给 Agent 的资料推成了Agent 参与维护的过程资产。这里说准确一点。“5 次工具调用后自动写 Skill这种说法方便传播但容易压扁细节。之前翻过源码run_agent.py里的实现更像一套 best-effort review主任务先完成后台再判断有没有东西值得保存。不是硬编码满了就一定写”。不是每个复杂任务都值得写 Runbook也不是每次修 bug 都要形成流程。难点在于分辨这次经验以后还会不会复用保存下来会不会反过来误导下一次。让我觉得它在认真做这件事的几个细节说过程资产谁都会说。真让我觉得 Hermes 不是在喊口号的是几个很像线上系统的工程细节。第一Skill 创建有落盘纪律。它不是把内容拼出来就write()完事。实际是先写临时文件再用os.replace()原子替换。进程中途崩了磁盘上留下的要么是旧版本要么是新版本不会是半截文件。扫描顺序也有讲究先落盘、再扫描最终文件系统状态失败就整目录回滚。这是在躲 TOCTOU检查和使用之间的竞态做过后端系统的应该很熟悉。到这里 Skill 才更像一个可维护资产而不是模型吐出来的一段 Markdown。第二Skill 内容走 User Message 注入不碰 System Prompt。这个取舍值得多说两句。Hermes 加载 Skill 后不是把内容追加到 System Prompt 里而是作为一条带[SYSTEM: ...]前缀的 User Message 塞进对话。为什么因为一碰 System PromptPrompt Cache 就碎了。之前聊 prompt caching 时算过这笔账一个 30 轮工具调用的复杂任务不碰 System Prompt 能省下 95% 以上的重复 token 成本。User Message 的指令跟随权重确实比 System Prompt 低一些但这是一个算过账的取舍——牺牲一点指令遵循的可靠性换来数十倍的成本降幅。换句话说Hermes 做的不是把 Skill 塞进去而是把高变化的过程知识从需要稳定缓存的系统骨架里拆出去。第三patch 靠 fuzzy match承认 LLM 记不准空格。Hermes patch Skill 的做法我还挺喜欢的。它没假设模型能一字不差地引用旧内容而是复用了 fuzzy match 去做替换——空格、缩进、换行、转义这些小差异尽量容忍。这类设计不酷但很工程。因为如果 patch 只接受精确命中Agent 的自我修补大概率会死在工具调用失败上。说直白点很多系统的问题不是不会改而是改不进去。第四patch 之后不强改当前会话。Skill 被 patch 成功后Hermes 会清理索引缓存和磁盘快照但效果要到下一个会话才体现——当前会话的 System Prompt 不会被回写。这是一种最终一致性当前任务发现问题并修补下一个任务开始时系统干净地加载新版本。不炫但很像真实系统的边界感。这条线上不只有 Hermes如果只盯 Hermes容易把它看成一个单点创新。但过去几个月我们写过的几条线放在一起看它们回答的其实是同一个问题经验到底该放在哪里。Skill 有用的地方不止SKILL.md还有 references、scripts、assets、examples、hooks 这些外围结构。它让模型进入一个整理好的小工作区不是只读一段提示词。Hermes 站在第三个位置。它关心的是运行时Agent 做事过程中遇到的路径、坑点和修正能不能沉淀成下次可加载、可修补的 Skill。几条经验外部化路线所以我更愿意这样看• Claude Skills 把团队经验做成工作单元• Codex 把工程经验写进仓库和流程• Hermes 把运行时经验沉淀成过程资产。三者不是互相替代从不同层面把隐性经验外部化。所以我不太想把 Hermes 简单归类成比 OpenClaw 多了自动 Skill。这个说法能解释一部分但会漏掉它在运行时经验层上的位置。更底层的变化是Agent 系统开始有意识地区分事实、历史和做事方法并把做事方法当一等资产管。自动沉淀不是免费午餐过程资产一旦能自动生成就有一个新风险错误经验也会自动沉淀。这比模型当场答错麻烦得多。当场答错影响一次任务。坏 Skill 进入系统影响的是后面一串同类任务——它会让 Agent 更快、更稳定地走向错误路径。Hermes 在安全上做了一件对的事不把防线全交给模型自觉。它的 guard 里有 90 多类威胁模式扫的不只是危险命令这种大词还有很具体的东西通过curl拼接环境变量外传凭据、直接引用~/.hermes/.env、DAN 之类的越狱短语、零宽字符和 RTL override 这些不可见 Unicode——之前讲 memory 安全扫描时提过类似机制Skill 这边覆盖面更大。更关键的是它不是一刀切。built-in、trusted、community、agent-created 用不同安装策略内置 Skill 完全信任社区 Skill 只允许最安全级别的操作Agent 自创建的 Skill 允许中等风险但危险操作会问用户。同样是 Skill来路不同不能共用一套信任假设。NousResearch 的hermes-agent-self-evolution仓库走得更远。它用 DSPy GEPA 去优化 Skill、工具描述、系统提示和代码。流程大概是读当前 Skill / prompt / tool生成评估数据用 GEPA 结合执行轨迹生成候选变体评估后过约束门禁最后以 PR 形式进入hermes-agent。我更在意的不是自动优化四个字。是后面的约束测试必须过Skill 大小受限不能破坏缓存兼容语义不能偏离原目标所有变化走 PR review不直接提交。这至少让我放心了一点他们不是只想让 Skill 长出来也在认真管它怎么长歪。自我改进如果没有评估集、版本和审查很容易把一次看起来更好的改动写进系统然后一路放大。Skill 进入生产系统要多几道门如果今天让我把 Hermes 这套思路借到自己的 Agent 系统里不会一上来就追求全自动自我进化。我会先把门禁做出来。Skill 进入生产系统的闭环第一道门结构。每个 Skill 至少要说清楚什么时候触发、解决什么问题、需要什么工具、步骤是什么、怎么验收、哪些情况不适用。Hermes 要求 frontmatter、大小限制、目录结构其实就是在给可被系统消费的经验定最小契约。没有验证方法的 Skill不会让它进入自动加载。第二道门来源。内置 Skill、团队 Skill、社区 Skill、Agent 自生成 Skill不该共用一套信任级别。我会直接把来源做成分级策略不是写在文档里提醒大家小心。Hermes 对不同来源的安装策略就是这个方向——信任应该在框架层表达靠人记不靠谱。团队内部也一样生产发布、数据导出、权限变更的 Skill不能和写周报用一套准入策略。第三道门评估。评估不一定一开始就很重但至少要有最小样例这个 Skill 解决哪几个典型任务成功输出大概长什么样哪些错误不能再出现变更前后有没有回放过历史轨迹。Hermes 的 self-evolution 仓库给了个好提醒不是能改就行而是先有评估样例再让候选变体进 PR。第四道门版本和回滚。这个我会写得重一点。因为这恰好是 Hermes 现阶段让我最想补的一块patch 后旧版本容易消失出了误修正恢复成本很高。更稳的方式是每次变更有 diff、有 changelog、有最近 N 个版本可恢复。高风险 Skill 走 PR低风险 Skill 可以自动合并但也要能追溯。第五道门权限。一个 Skill 能调用哪些工具、能读写哪些目录、能不能访问网络、能不能碰凭据都要有边界。否则 Skill 很容易从过程资产变成权限包装。这些不太性感但真到生产里大多躲不过去。我们能从 Hermes 学什么往学术线上追这条思路不新。2023 年 NVIDIA 的 Voyager 就证明过Agent 可以把成功行为沉淀成一个持续增长的 skill library。但论文世界和工程世界差得远。Voyager 解决的是技能能不能累积Hermes 回答的是另一层问题技能累积以后怎么在真实系统里安全地存、便宜地用、出了问题还能改。所以我更倾向于把 Hermes 当一个提醒Agent 系统的重心正在往经验层移动。过去大家先拼模型再拼工具再拼上下文。现在这些当然还重要但差距会越来越多出现在另一层团队有没有把反复发生的事情整理成 Agent 能稳定复用的资产。个人场景里这叫越用越顺手。团队场景里就叫工程化。对团队来说先沉淀成 Skill 的通常可以从三类小东西开始• 高频流程发布、建 PR、生成周报、同步 issue• 验证流程改完功能怎么验、怎么跑测试、怎么看日志• 排障流程告警来了先查哪里、哪些命令不能跳过、什么时候升级给人。这些东西小但复用频率高也最容易被验证。等这些小 Skill 跑稳了再谈 self-evolution 才有意义。之前写Agent Harness 综述时说过Harness 的差距不在有没有工具而在工具、上下文、权限、记忆、流程和验证能不能组成一个稳定工作台。Hermes Skills 这次给我的启发是把其中流程这一层再往前推了一步——流程不只是人提前写好的也可以从任务轨迹里慢慢长出来。但它要长在工程系统里不能只长在模型的自我感觉里。写在最后这次看 Hermes最想留下来的不是某个具体实现也不只是自动创建 Skill这个卖点。是一个更朴素的问题Agent 做完一件事以后系统要留下些什么。留下事实记忆它下次更懂你。留下会话检索它下次能找回历史。留下过程资产它下次才可能少走弯路。这三件事都重要但不能混成一团。混在一起会变成一个越来越厚、越来越难维护的上下文垃圾桶。分开管理才有机会长成可演进的 Agent Runtime。工程团队早就靠这套办法工作了。我们写 Runbook写 Checklist写 Postmortem写 CI写发布手册。现在 Agent 也开始学这套老办法。老办法不新但能复利。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】