1. 为什么你的 Agent 每次都在重新踩坑如果你正在做 LLM Agent 相关的开发大概率遇到过这个场景你花了一下午调通了一条复杂的工具调用链路Agent 终于能正确完成某个任务。第二天你开了一个新会话同样的任务它又开始从头试错把昨天踩过的坑一个不落地重新踩一遍。这不是模型变笨了而是绝大多数 Agent 框架的默认行为——每次对话都是一张白纸。上下文窗口再大也只是“短期记忆”会话一结束经验就归零。Hermes 这个项目之所以在开发者圈子里被反复讨论核心就在于它把“经验沉淀”这件事做成了系统级能力。它用两条主线来承载经验Skills负责存储“怎么做”的程序性知识Prompt负责定义“什么时候该记、什么时候该用”的行为准则。两者配合形成一个从任务执行到能力复用的闭环。这篇文章面向想理解 Agent 自我进化原理的开发者会给出可复制的 Skills 配置骨架、Prompt 模板以及一轮完整的验证动作。你不需要先读完 Hermes 全部源码跟着配置和验证步骤走就能在自己的 Agent 流程里复现“经验积累”的效果。2. 前置准备用 TaoToken 打通模型调用链路在动手配置 Skills 之前你需要先有一个稳定的模型调用入口。Hermes 这类 Agent 对模型的指令跟随能力要求较高尤其是 Skills 的创建、patch 这些操作需要模型能准确理解结构化指令。我这边实测下来用 TaoToken 的 API 接入比较省事它兼容 OpenAI 风格的接口改一下 base_url 和 key 就能跑。2.1 获取 API Key 与配置环境首先到 TaoToken 控制台创建一个 API Key。地址是 https://taotoken.net/api-keys 登录后点“创建密钥”复制生成的 key。建议把它写进环境变量不要硬编码在代码里export TAOTOKEN_API_KEYsk-你的密钥 export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Python 的 openai SDK接入方式如下from openai import OpenAI import os client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[{role: user, content: 用一句话说明什么是 Agent 的 Skills 机制}], ) print(resp.choices[0].message.content)这里base_url填https://taotoken.net/api即可不要加多余的路径后缀。模型名按你实际使用的填TaoToken 支持主流模型具体可以在模型对话页面确认。2.2 确认模型可用性在正式接入 Agent 流程前建议先做一次最小验证确认 key 和模型都正常。你可以直接用模型对话功能测试或者跑上面那段 Python。如果返回正常文本说明链路通了。注意如果你的 Agent 需要长时间运行、频繁调用建议关注 Coding Plan 这类套餐比按量计费更适合持续编码和 Agent 场景。地址是 https://taotoken.net/coding-plan 。3. Skills 配置骨架把一次任务变成可复用能力Skills 的本质是一份结构化的 Markdown 文档用 YAML frontmatter 描述元数据用正文描述执行步骤。下面给出一个可以直接套用的骨架。3.1 Skill 文件的标准结构一个 Skill 文件通常命名为SKILL.md放在以技能名命名的目录下。结构如下--- name: deploy-nextjs description: 将 Next.js 应用部署到 Vercel包含环境变量配置与常见陷阱 version: 1.0.0 platforms: [macos, linux] metadata: hermes: tags: [devops, nextjs, vercel] requires_toolsets: [terminal] fallback_for_toolsets: [] related_skills: [docker-deploy] --- # Deploy Next.js to Vercel ## 触发条件 - 用户要求部署 Next.js 应用 - 目标平台是 Vercel ## 执行步骤 1. 检查项目根目录是否存在 vercel.json 或 next.config.js 2. 核对 Node.js 版本是否匹配 .nvmrc 或 package.json 的 engines 字段 3. 配置环境变量注意 NEXT_PUBLIC_* 前缀的变量必须在 Vercel 控制台设置 4. 执行 vercel --prod 并等待部署完成 5. 验证部署 URL 返回 200 ## 常见陷阱 - NEXT_PUBLIC_* 变量只写在 .env 里不会生效必须在 Vercel 控制台配置 - Node 版本不匹配会导致构建失败先检查 .nvmrc - 依赖变更后如果部署失败加 --force 清除构建缓存 ## 验证方法 - curl 部署 URL确认返回 200 - 访问 /api/health 端点确认环境变量已加载这份骨架的关键在于触发条件告诉 Agent 什么时候该用这个 Skill执行步骤是可复制的操作序列常见陷阱是踩坑经验的沉淀验证方法让 Agent 能自己确认任务是否成功。3.2 让 Agent 自己决定何时创建 SkillSkill 不应该由用户手动写而应该由 Agent 在完成任务后自主提炼。这需要在 System Prompt 里写入明确的触发规则。下面是一段可以直接用的 Prompt 模板## Skills 管理准则 在完成以下类型的任务后必须用 skill_manage 工具将方法保存为 Skill - 涉及 5 次以上工具调用的复杂任务 - 修复了一个棘手的错误 - 发现了一条非显而易见的工作流 在使用某个 Skill 时如果发现它过时、不完整或有错误立即用 skill_manage(actionpatch) 修正不要等用户要求。 未被维护的 Skill 比没有 Skill 更危险。这段 Prompt 的作用是给 Agent 一个明确的判断标准。“5 次以上工具调用”划定了创建门槛避免 Skill 库被琐碎任务淹没“立即修正”则保证了 Skill 不会随时间腐烂。3.3 索引与按需加载Skill 创建后Agent 需要知道有哪些 Skill 可用。但把所有 Skill 的完整内容都塞进 System Prompt 会吃掉大量 token。Hermes 的做法是System Prompt 里只放索引每个 Skill 只保留名称和描述大约 20 token。当 Agent 判断某个 Skill 相关时再主动加载完整内容。索引的格式如下available_skills devops: - deploy-nextjs: 将 Next.js 应用部署到 Vercel包含环境变量配置与常见陷阱 - docker-deploy: 多阶段 Docker 构建与安全加固>在回复前扫描上面的 Skill 列表。如果某个 Skill 与当前任务匹配 或者哪怕只是部分相关你必须用 skill_view(name) 加载它并遵循其指令。 只有在确实没有任何相关 Skill 时才可以在不加载的情况下继续。这种“强制加载”的措辞很重要。漏加载一个相关 Skill 的成本远大于多加载一个不相关 Skill 的成本。4. 验证请求跑一轮完整的经验沉淀流程配置好之后你需要验证这套机制是否真的在工作。下面给出一轮可复现的验证动作。4.1 第一次执行观察 Agent 是否创建 Skill给 Agent 一个需要多步工具调用的任务比如“帮我把当前目录下的 Node 项目部署到 Vercel”。观察它的行为用户帮我把当前目录下的 Node 项目部署到 Vercel Agent[调用 terminal 检查项目结构] [调用 terminal 检查 Node 版本] [调用 terminal 执行 vercel --prod] [遇到环境变量错误调整配置] [重新部署成功] [调用 skill_manage(actioncreate, namedeploy-nextjs, content...)] [返回部署结果]关键看最后一步Agent 是否主动调用了skill_manage创建 Skill。如果它只是完成了任务就结束说明你的 Prompt 触发规则还不够明确需要加强措辞。4.2 第二次执行观察 Agent 是否复用 Skill开一个新会话给一个类似的任务比如“把另一个 Node 项目也部署到 Vercel”。这次观察用户把另一个 Node 项目也部署到 Vercel Agent[扫描 available_skills发现 deploy-nextjs] [调用 skill_view(namedeploy-nextjs) 加载完整内容] [按照 Skill 中的步骤执行跳过之前踩过的坑] [一次部署成功]如果 Agent 直接加载了 Skill 并按照步骤执行说明经验沉淀生效了。如果它又开始从头试错检查两个地方一是索引是否正确注入到了 System Prompt二是skill_view工具是否可用。4.3 验证 Skill 的自动修正第三次验证故意让环境发生一点变化比如 Vercel CLI 更新了命令格式。观察 Agent 在使用 Skill 时是否会发现不一致并自动 patchAgent[加载 deploy-nextjs Skill] [执行 vercel --prod发现命令已变更为 vercel deploy --prod] [调用 skill_manage(actionpatch, old_stringvercel --prod, new_stringvercel deploy --prod)] [继续执行成功]这一步验证的是自改进机制。如果 Agent 发现了问题但没有 patch检查 Prompt 里是否有“立即修正”的指令。5. 常见错误排查5.1 Skill 创建后索引里看不到最常见的原因是 Skill 文件的 frontmatter 格式不对。检查三点name字段是否只包含小写字母、数字和连字符description是否存在且不超过一行YAML 头部是否用---正确包裹。如果 frontmatter 解析失败Skill 会被静默跳过。另一个可能是缓存问题。Hermes 有两层缓存进程内 LRU 缓存和磁盘快照。如果 Skill 文件刚创建但索引没更新可能是缓存没失效。检查磁盘快照的 manifest 是否基于文件的 mtime 和 size 做了校验。5.2 Agent 不加载 Skill 直接干活如果 Agent 明明看到了索引里的 Skill却选择不加载通常是 Prompt 的强制力不够。把“如果相关就加载”改成“你必须加载”并加上“只有在确实没有任何相关 Skill 时才可以不加载”这样的兜底措辞。还有一种情况是 Skill 的条件激活规则把它隐藏了。比如 Skill 声明了requires_toolsets: [terminal]但当前环境没有 terminal 工具这个 Skill 就不会出现在索引里。检查你的工具配置是否满足 Skill 的依赖。5.3 patch 操作频繁失败patch 失败通常是因为old_string和 Skill 文件里的实际内容有微小差异比如空格、换行、缩进不同。Hermes 用了 fuzzy match 引擎来处理这类差异但如果你自己实现建议至少做空白规范化和缩进忽略。另外patch 成功后要记得清理缓存否则下一个会话可能还在用旧版本。清理时要同时清内存缓存和磁盘快照。5.4 环境变量缺失导致 Skill 执行失败如果 Skill 依赖某个环境变量比如VERCEL_TOKEN但用户没配置Agent 不应该静默失败。正确的做法是在加载 Skill 时检查依赖的环境变量缺失时给出明确提示。在 CLI 模式下可以交互式提示输入在 Gateway 模式下则返回引导信息让用户去 CLI 完成配置。6. 把经验沉淀接入你的 Agent 流程回到最开始的问题怎么让你的 Agent 不再每次重新踩坑。核心就三件事——用 Prompt 定义“什么时候该记”用 Skills 存储“怎么做”用索引和按需加载控制成本。如果你想快速验证这套机制可以先用 TaoToken 的模型对话功能跑一轮最小测试确认模型能正确理解 Skill 的创建和加载指令。地址是 https://taotoken.net/api-keys 拿到 key 后按第 2 节的配置接入即可。接入文档在 https://taotoken.net/doc 里面有各语言的调用示例。对于需要长期运行编码 Agent 的场景建议关注 Coding Plan它在持续调用场景下比按量计费更划算。地址是 https://taotoken.net/coding-plan 。最后给一个实操建议不要一上来就追求完整的闭环。先把 Skill 的创建和加载跑通确认 Agent 能在第二次执行时复用经验再逐步加上自动 patch 和安全扫描。经验沉淀这件事跑通最小闭环比堆功能更重要。
一文搞懂 Hermes：从 Skills 与 Prompt 出发，看 Agent 如何沉淀经验自我进化
1. 为什么你的 Agent 每次都在重新踩坑如果你正在做 LLM Agent 相关的开发大概率遇到过这个场景你花了一下午调通了一条复杂的工具调用链路Agent 终于能正确完成某个任务。第二天你开了一个新会话同样的任务它又开始从头试错把昨天踩过的坑一个不落地重新踩一遍。这不是模型变笨了而是绝大多数 Agent 框架的默认行为——每次对话都是一张白纸。上下文窗口再大也只是“短期记忆”会话一结束经验就归零。Hermes 这个项目之所以在开发者圈子里被反复讨论核心就在于它把“经验沉淀”这件事做成了系统级能力。它用两条主线来承载经验Skills负责存储“怎么做”的程序性知识Prompt负责定义“什么时候该记、什么时候该用”的行为准则。两者配合形成一个从任务执行到能力复用的闭环。这篇文章面向想理解 Agent 自我进化原理的开发者会给出可复制的 Skills 配置骨架、Prompt 模板以及一轮完整的验证动作。你不需要先读完 Hermes 全部源码跟着配置和验证步骤走就能在自己的 Agent 流程里复现“经验积累”的效果。2. 前置准备用 TaoToken 打通模型调用链路在动手配置 Skills 之前你需要先有一个稳定的模型调用入口。Hermes 这类 Agent 对模型的指令跟随能力要求较高尤其是 Skills 的创建、patch 这些操作需要模型能准确理解结构化指令。我这边实测下来用 TaoToken 的 API 接入比较省事它兼容 OpenAI 风格的接口改一下 base_url 和 key 就能跑。2.1 获取 API Key 与配置环境首先到 TaoToken 控制台创建一个 API Key。地址是 https://taotoken.net/api-keys 登录后点“创建密钥”复制生成的 key。建议把它写进环境变量不要硬编码在代码里export TAOTOKEN_API_KEYsk-你的密钥 export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Python 的 openai SDK接入方式如下from openai import OpenAI import os client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelclaude-sonnet-4-20250514, messages[{role: user, content: 用一句话说明什么是 Agent 的 Skills 机制}], ) print(resp.choices[0].message.content)这里base_url填https://taotoken.net/api即可不要加多余的路径后缀。模型名按你实际使用的填TaoToken 支持主流模型具体可以在模型对话页面确认。2.2 确认模型可用性在正式接入 Agent 流程前建议先做一次最小验证确认 key 和模型都正常。你可以直接用模型对话功能测试或者跑上面那段 Python。如果返回正常文本说明链路通了。注意如果你的 Agent 需要长时间运行、频繁调用建议关注 Coding Plan 这类套餐比按量计费更适合持续编码和 Agent 场景。地址是 https://taotoken.net/coding-plan 。3. Skills 配置骨架把一次任务变成可复用能力Skills 的本质是一份结构化的 Markdown 文档用 YAML frontmatter 描述元数据用正文描述执行步骤。下面给出一个可以直接套用的骨架。3.1 Skill 文件的标准结构一个 Skill 文件通常命名为SKILL.md放在以技能名命名的目录下。结构如下--- name: deploy-nextjs description: 将 Next.js 应用部署到 Vercel包含环境变量配置与常见陷阱 version: 1.0.0 platforms: [macos, linux] metadata: hermes: tags: [devops, nextjs, vercel] requires_toolsets: [terminal] fallback_for_toolsets: [] related_skills: [docker-deploy] --- # Deploy Next.js to Vercel ## 触发条件 - 用户要求部署 Next.js 应用 - 目标平台是 Vercel ## 执行步骤 1. 检查项目根目录是否存在 vercel.json 或 next.config.js 2. 核对 Node.js 版本是否匹配 .nvmrc 或 package.json 的 engines 字段 3. 配置环境变量注意 NEXT_PUBLIC_* 前缀的变量必须在 Vercel 控制台设置 4. 执行 vercel --prod 并等待部署完成 5. 验证部署 URL 返回 200 ## 常见陷阱 - NEXT_PUBLIC_* 变量只写在 .env 里不会生效必须在 Vercel 控制台配置 - Node 版本不匹配会导致构建失败先检查 .nvmrc - 依赖变更后如果部署失败加 --force 清除构建缓存 ## 验证方法 - curl 部署 URL确认返回 200 - 访问 /api/health 端点确认环境变量已加载这份骨架的关键在于触发条件告诉 Agent 什么时候该用这个 Skill执行步骤是可复制的操作序列常见陷阱是踩坑经验的沉淀验证方法让 Agent 能自己确认任务是否成功。3.2 让 Agent 自己决定何时创建 SkillSkill 不应该由用户手动写而应该由 Agent 在完成任务后自主提炼。这需要在 System Prompt 里写入明确的触发规则。下面是一段可以直接用的 Prompt 模板## Skills 管理准则 在完成以下类型的任务后必须用 skill_manage 工具将方法保存为 Skill - 涉及 5 次以上工具调用的复杂任务 - 修复了一个棘手的错误 - 发现了一条非显而易见的工作流 在使用某个 Skill 时如果发现它过时、不完整或有错误立即用 skill_manage(actionpatch) 修正不要等用户要求。 未被维护的 Skill 比没有 Skill 更危险。这段 Prompt 的作用是给 Agent 一个明确的判断标准。“5 次以上工具调用”划定了创建门槛避免 Skill 库被琐碎任务淹没“立即修正”则保证了 Skill 不会随时间腐烂。3.3 索引与按需加载Skill 创建后Agent 需要知道有哪些 Skill 可用。但把所有 Skill 的完整内容都塞进 System Prompt 会吃掉大量 token。Hermes 的做法是System Prompt 里只放索引每个 Skill 只保留名称和描述大约 20 token。当 Agent 判断某个 Skill 相关时再主动加载完整内容。索引的格式如下available_skills devops: - deploy-nextjs: 将 Next.js 应用部署到 Vercel包含环境变量配置与常见陷阱 - docker-deploy: 多阶段 Docker 构建与安全加固>在回复前扫描上面的 Skill 列表。如果某个 Skill 与当前任务匹配 或者哪怕只是部分相关你必须用 skill_view(name) 加载它并遵循其指令。 只有在确实没有任何相关 Skill 时才可以在不加载的情况下继续。这种“强制加载”的措辞很重要。漏加载一个相关 Skill 的成本远大于多加载一个不相关 Skill 的成本。4. 验证请求跑一轮完整的经验沉淀流程配置好之后你需要验证这套机制是否真的在工作。下面给出一轮可复现的验证动作。4.1 第一次执行观察 Agent 是否创建 Skill给 Agent 一个需要多步工具调用的任务比如“帮我把当前目录下的 Node 项目部署到 Vercel”。观察它的行为用户帮我把当前目录下的 Node 项目部署到 Vercel Agent[调用 terminal 检查项目结构] [调用 terminal 检查 Node 版本] [调用 terminal 执行 vercel --prod] [遇到环境变量错误调整配置] [重新部署成功] [调用 skill_manage(actioncreate, namedeploy-nextjs, content...)] [返回部署结果]关键看最后一步Agent 是否主动调用了skill_manage创建 Skill。如果它只是完成了任务就结束说明你的 Prompt 触发规则还不够明确需要加强措辞。4.2 第二次执行观察 Agent 是否复用 Skill开一个新会话给一个类似的任务比如“把另一个 Node 项目也部署到 Vercel”。这次观察用户把另一个 Node 项目也部署到 Vercel Agent[扫描 available_skills发现 deploy-nextjs] [调用 skill_view(namedeploy-nextjs) 加载完整内容] [按照 Skill 中的步骤执行跳过之前踩过的坑] [一次部署成功]如果 Agent 直接加载了 Skill 并按照步骤执行说明经验沉淀生效了。如果它又开始从头试错检查两个地方一是索引是否正确注入到了 System Prompt二是skill_view工具是否可用。4.3 验证 Skill 的自动修正第三次验证故意让环境发生一点变化比如 Vercel CLI 更新了命令格式。观察 Agent 在使用 Skill 时是否会发现不一致并自动 patchAgent[加载 deploy-nextjs Skill] [执行 vercel --prod发现命令已变更为 vercel deploy --prod] [调用 skill_manage(actionpatch, old_stringvercel --prod, new_stringvercel deploy --prod)] [继续执行成功]这一步验证的是自改进机制。如果 Agent 发现了问题但没有 patch检查 Prompt 里是否有“立即修正”的指令。5. 常见错误排查5.1 Skill 创建后索引里看不到最常见的原因是 Skill 文件的 frontmatter 格式不对。检查三点name字段是否只包含小写字母、数字和连字符description是否存在且不超过一行YAML 头部是否用---正确包裹。如果 frontmatter 解析失败Skill 会被静默跳过。另一个可能是缓存问题。Hermes 有两层缓存进程内 LRU 缓存和磁盘快照。如果 Skill 文件刚创建但索引没更新可能是缓存没失效。检查磁盘快照的 manifest 是否基于文件的 mtime 和 size 做了校验。5.2 Agent 不加载 Skill 直接干活如果 Agent 明明看到了索引里的 Skill却选择不加载通常是 Prompt 的强制力不够。把“如果相关就加载”改成“你必须加载”并加上“只有在确实没有任何相关 Skill 时才可以不加载”这样的兜底措辞。还有一种情况是 Skill 的条件激活规则把它隐藏了。比如 Skill 声明了requires_toolsets: [terminal]但当前环境没有 terminal 工具这个 Skill 就不会出现在索引里。检查你的工具配置是否满足 Skill 的依赖。5.3 patch 操作频繁失败patch 失败通常是因为old_string和 Skill 文件里的实际内容有微小差异比如空格、换行、缩进不同。Hermes 用了 fuzzy match 引擎来处理这类差异但如果你自己实现建议至少做空白规范化和缩进忽略。另外patch 成功后要记得清理缓存否则下一个会话可能还在用旧版本。清理时要同时清内存缓存和磁盘快照。5.4 环境变量缺失导致 Skill 执行失败如果 Skill 依赖某个环境变量比如VERCEL_TOKEN但用户没配置Agent 不应该静默失败。正确的做法是在加载 Skill 时检查依赖的环境变量缺失时给出明确提示。在 CLI 模式下可以交互式提示输入在 Gateway 模式下则返回引导信息让用户去 CLI 完成配置。6. 把经验沉淀接入你的 Agent 流程回到最开始的问题怎么让你的 Agent 不再每次重新踩坑。核心就三件事——用 Prompt 定义“什么时候该记”用 Skills 存储“怎么做”用索引和按需加载控制成本。如果你想快速验证这套机制可以先用 TaoToken 的模型对话功能跑一轮最小测试确认模型能正确理解 Skill 的创建和加载指令。地址是 https://taotoken.net/api-keys 拿到 key 后按第 2 节的配置接入即可。接入文档在 https://taotoken.net/doc 里面有各语言的调用示例。对于需要长期运行编码 Agent 的场景建议关注 Coding Plan它在持续调用场景下比按量计费更划算。地址是 https://taotoken.net/coding-plan 。最后给一个实操建议不要一上来就追求完整的闭环。先把 Skill 的创建和加载跑通确认 Agent 能在第二次执行时复用经验再逐步加上自动 patch 和安全扫描。经验沉淀这件事跑通最小闭环比堆功能更重要。
