1. 为什么你的 Agent 每次都在“重新学走路”先说一个我踩过的坑。去年我给自己搭了一个代码审查 Agent每次对话结束它都“忘光”下次遇到同类问题还是从零推理。我当时的做法是把常见流程写进 system prompt结果 prompt 越堆越长最后光上下文就吃掉一半预算模型还经常“看漏”关键规则。这就是典型的静态上下文困境你把方法论写死在提示词里它不会演进只会膨胀。Hermes Agent 的 Skills 自进化机制解决的正是这件事。它让 Agent 在每轮任务结束后自己评估“这次有没有值得沉淀的做法”如果有就把它写成一份可复用的工作手册SKILL.md下次遇到同类问题直接调用。核心检索词就是 Hermes Agent Skills 自进化机制——它不是让 AI 记住你说过什么而是让 AI 学会怎么做事。这套机制适合谁三类人最该看一是正在做 Agent 应用、被 prompt 膨胀折磨的开发者二是想让自己的编码助手“越用越顺手”的独立开发者三是想理解 Agent 能力演进架构的技术负责人。读完你能拿到三样东西一份可复制的 SKILL.md 配置、一套触发自进化的验证动作、以及排查常见报错的对照表。需要先明确一个概念区分否则后面全乱。Prompt 是输入一次性的用完即弃比如“帮我修这个 KeyError”。Skill 是能力持久的跨对话生效比如“系统性调试方法论先做根因分析再动手”。前者是任务后者是方法论。Hermes 的自进化进化的对象是后者。我实测下来这套机制最反直觉的地方在于它默认“宁可不生成也不生成垃圾”。源码里那句兜底指令是If nothing is worth saving, just say Nothing to save. and stop.——这句话是整个系统的质量闸门。理解了这一点你才不会指望它每轮都产出新 skill。2. 前置准备TaoToken 接入与 Skills 目录结构在复现自进化之前得先把模型调用链路打通。Hermes 的 skill review 依赖一个能力足够强的模型来做“抽象”这一步——弱模型会把具体任务原样抄进 skill导致无法复用。我建议用 Claude 或 GPT 系列里泛化能力较好的版本。接入方式上我用 TaoToken 做统一入口好处是 Base URL 和 Key 一套配置就能切换模型不用为每个模型单独维护环境变量。官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api注意 API 地址不带 UTM 参数。先拿到 Key。进入控制台创建 API Key路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 创建后复制保存页面只显示一次。如果你还没决定用哪个模型可以先去模型对话页 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 试一下不同模型在“抽象总结”任务上的表现差异这一步很关键因为 skill 生成质量直接取决于模型的元认知能力。然后是 Skills 目录。Hermes 的 skill 存放在项目根目录的skills/下每个 skill 是一个子目录里面放一个SKILL.md。目录名就是 skill 的 name必须用 kebab-case全局唯一。比如skills/ software-development/ systematic-debugging/ SKILL.md test-driven-development/ SKILL.md research/ deep-research/ SKILL.md注意这里有个层级software-development是类别categorysystematic-debugging才是 skill 本身。类别只是组织方式Agent 检索时看的是 skill 的 frontmatter不是目录层级。所以你可以按自己的项目习惯重新分类不影响功能。环境变量配置我建议单独放一个.env不要写死在代码里# .env TAOTOKEN_API_KEYsk-你的key TAOTOKEN_BASE_URLhttps://taotoken.net/api HERMES_MODELclaude-sonnet-4-5 HERMES_SKILLS_DIR./skills HERMES_SKILL_REVIEW_ENABLEDtrue这里HERMES_SKILL_REVIEW_ENABLED是自进化机制的开关。默认开启但如果你在调试阶段不想让它自动改 skill 库可以先关掉等验证完再打开。我建议第一次跑的时候先关手动观察 review agent 的输出确认它判断合理后再开。还有一个容易忽略的点skill 目录需要有写权限。review agent 生成新 skill 时会创建目录和文件如果目录只读它会静默失败——日志里只有一行 warning很容易漏掉。用ls -ld skills/确认一下权限。3. 可复制配置SKILL.md 结构与自进化触发参数这一节是全文最该抄的部分。先给一份完整的 SKILL.md 模板字段和 Hermes 源码里的解析逻辑对齐。--- name: production-bug-handling description: Production bug triage: reproduce before fixing, verify after deploy. version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [debugging, production, incident, root-cause] related_skills: [systematic-debugging, test-driven-development] immutable: false --- # Production Bug Handling ## Overview Production bugs differ from dev bugs: you cannot attach a debugger freely, and every minute of downtime has cost. This skill defines the standard flow. ## The Iron Law REPRODUCE IN A SAFE ENVIRONMENT BEFORE TOUCHING PRODUCTION CODE. ## Steps 1. Capture the exact error signature from logs (timestamp, stack, request id). 2. Reproduce in staging with the same input. 3. Write a failing test that captures the bug. 4. Fix, run the test, confirm green. 5. Deploy, watch the same metric for 10 minutes.逐字段说清楚因为每个字段都影响自进化行为。name是唯一标识也是 Agent 调用时的关键字。改名字等于新建 skill历史版本不会跟过来所以定名要慎重。description是整个系统里最关键的一行。Agent 在 Tier 1 阶段只读这一行来决定要不要加载这个 skill。写法推荐“触发条件 核心承诺 关键约束”三段式控制在 15 个词以内。上面例子里的Production bug triage: reproduce before fixing, verify after deploy.就是标准写法。写烂了这个 skill 永远不会被触发正文写得再好也没用。version用 SemVer。自进化时扩展场景递增 minor1.0.0 → 1.1.0修正错误递增 patch1.1.0 → 1.1.1方法论大改递增 major1.1.1 → 2.0.0。这个版本号是回滚的依据。metadata.hermes.tags是检索索引。Agent 先用 tags 缩小候选集再读 description 精筛。所以 tags 要覆盖任务类型、领域、动作三个维度别只写一个。metadata.hermes.related_skills声明技能图谱。加载一个 skill 时它的 related 的 description 也会被加载不加载正文这样 Agent 能沿图跳转。这是复杂任务里“顺手用上另一个技能”的关键。metadata.hermes.immutable是自进化的刹车。设为true的 skillreview agent 不会自动修改。系统内置的铁律类 skill 应该设 true用户自定义的流程类设 false。我踩过的坑一开始把所有 skill 都设成可变结果某次用户反馈“这次直接改吧别测了”Agent 差点把“先写测试”这条规则删掉。后来把核心规则类 skill 全部锁死。接下来是自进化的触发参数。Hermes 的 review 逻辑由_SKILL_REVIEW_PROMPT驱动核心判断标准是三条任务是否用了非平凡方法、是否经历试错或中途调整、用户是否期待不同做法。这三条你没法直接配但可以通过环境变量控制触发频率和审核严格度# 每轮对话后都触发 review默认 HERMES_SKILL_REVIEW_MODEevery_turn # 只在任务被判定为非平凡时触发省 token HERMES_SKILL_REVIEW_MODEnon_trivial_only # 审核子 agent 的最大重试次数超过则放弃生成 HERMES_SKILL_REVIEW_MAX_RETRY3 # 生成前检查是否与已有 skill 重复的相似度阈值 HERMES_SKILL_DEDUP_THRESHOLD0.85HERMES_SKILL_REVIEW_MODE我建议生产环境用non_trivial_only。every_turn会让每轮对话都跑一次 reviewtoken 消耗翻倍而且大部分轮次的结果都是 “Nothing to save.”纯浪费。non_trivial_only只在检测到试错信号时才触发性价比高得多。HERMES_SKILL_DEDUP_THRESHOLD这个参数容易被忽略。它控制新生成的 skill 和已有 skill 的相似度检查超过阈值就判定为重复走“更新已有 skill”而不是“新建”。设太低会频繁误判重复设太高会生成一堆近似 skill 污染库。0.85 是我实测比较稳的值。如果你用 Claude Code 做开发环境配置可以放在~/.claude/settings.json里统一管理{ env: { TAOTOKEN_API_KEY: sk-你的key, TAOTOKEN_BASE_URL: https://taotoken.net/api, HERMES_MODEL: claude-sonnet-4-5, HERMES_SKILL_REVIEW_MODE: non_trivial_only, HERMES_SKILL_REVIEW_MAX_RETRY: 3 } }注意 Base URL 填https://taotoken.net/api不要带路径后缀也不要带 UTM 参数——UTM 是给网页统计用的API 端点加了会 404。Key 和 Model ID 三件套必须齐全缺一个都会在请求阶段报错。4. 验证请求确认自进化真的跑起来了配置写完不算完得验证。我设计了一套三步验证法从“能调用”到“能生成”再到“能优化”逐层确认。第一步验证模型调用链路通。写一个最小脚本直接打 TaoToken 的 APIimport os import requests resp requests.post( f{os.environ[TAOTOKEN_BASE_URL]}/v1/messages, headers{ x-api-key: os.environ[TAOTOKEN_API_KEY], anthropic-version: 2023-06-01, content-type: application/json, }, json{ model: os.environ[HERMES_MODEL], max_tokens: 64, messages: [{role: user, content: reply with OK only}], }, timeout30, ) print(resp.status_code) print(resp.json())跑通的话你会看到200和一段包含OK的响应。如果返回 401说明 Key 不对或没带上如果返回 404八成是 Base URL 写错了检查是不是多加了/v1或 UTM 参数。第二步验证 skill 加载。启动 Hermes让它读一遍 skills 目录看 Tier 1 索引是否建立hermes skills list --verbose正常输出会列出每个 skill 的 name、description、version、tags。如果某个 skill 没出现检查它的 frontmatter 是不是 YAML 格式错误——最常见的是 description 里有未转义的双引号或者缩进用了 tab。第三步也是最关键的验证自进化触发。故意制造一个“非平凡任务”让 Agent 处理一个需要试错的问题中途给它一次纠正反馈。比如你帮我写个脚本解析这个日志文件提取所有 ERROR 行。 Agent写了一个用正则的版本 你不对日志里有跨行的堆栈正则匹配不到得按时间戳分块。 Agent改成按时间戳分块成功任务结束后观察skills/目录有没有新文件生成或者已有 skill 的 version 有没有变。同时看日志里有没有 review agent 的输出tail -f logs/hermes-skill-review.log正常的话你会看到类似这样的记录[skill-review] task classified as non-trivial (trial_and_error detected) [skill-review] abstracting workflow... [skill-review] generated candidate: log-parsing-by-timestamp [skill-review] quality check passed (score 0.82) [skill-review] saved to skills/data-processing/log-parsing-by-timestamp/SKILL.md如果看到Nothing to save.说明 review agent 判定这次任务不值得沉淀。这时候别急着调参数先想想这次任务是不是太具体了如果换成“解析任意带跨行堆栈的日志”是不是就有复用价值了自进化机制对“可复用性”的判断很严格这是好事。验证通过后你可以打开新生成的 SKILL.md 看看质量。重点看 description 是不是三段式、正文有没有把具体文件名抽象掉。如果发现它把app.log这种具体路径写进了正文说明模型抽象能力不够换个更强的模型再试。5. 常见报错排查401、local proxy failed 与 OAuth 问题这一节按真实报错来对照都是我或读者实际遇到过的。401 Unauthorized。最常见三种原因Key 没带、Key 过期、Key 和 Base URL 不匹配。先确认请求头里有没有x-api-keyAnthropic 格式或Authorization: BearerOpenAI 格式两者别混用。然后去控制台 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 确认 Key 状态。最后检查 Base URL 是不是https://taotoken.net/api别写成别的域名。local proxy failed / connection refused。这个报错通常出现在你本地配了代理但代理没起来或者环境变量里残留了HTTP_PROXY。先env | grep -i proxy看看有没有残留有就 unset 掉。Hermes 的 skill review 是后台任务如果它继承了错误的代理配置会静默失败日志里只有一行local proxy failed很容易被忽略。我建议在启动脚本里显式清空代理变量unset HTTP_PROXY HTTPS_PROXY ALL_PROXY export NO_PROXYlocalhost,127.0.0.1reading choices of undefined。这是 OpenAI 格式响应解析失败的典型报错说明返回体结构和你预期的不一样。常见原因是模型名写错了服务端返回了一个错误对象而不是正常的 completion 结构。检查HERMES_MODEL的值是不是控制台里列出的有效模型 ID。另一个原因是流式和非流式混用——如果你开了stream: true但代码按非流式解析就会拿到 undefined。OAuth token expired / invalid_grant。如果你用 Claude Code 的 OAuth 登录方式而不是 API Key会遇到这个。OAuth token 有有效期过期后需要重新授权。但更稳的做法是改用 API Key 方式不依赖 OAuth 刷新链路。在settings.json里把认证方式从 OAuth 切到 API Key{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key, ANTHROPIC_MODEL: claude-sonnet-4-5 } }注意这里三个变量名是 Claude Code 生态的约定ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL。如果你用的是 Cline 或别的工具变量名可能不同但三件套的逻辑一样Base URL 指向https://taotoken.net/apiKey 用控制台生成的Model ID 用有效值。skill 生成了但没被触发。这不是报错但比报错更让人抓狂。原因几乎总是 description 写得太模糊。比如description: helps with debugging这种Agent 在 Tier 1 阶段根本判断不出什么时候该用它。改成description: Debug flaky tests: isolate nondeterminism before fixing.这种带触发条件的写法命中率立刻上来。记住description 是给 Agent 看的触发器不是给人看的简介。版本号不递增。自进化改了 skill 内容但 version 没变说明 review agent 走的是“原地覆盖”而不是“版本递增”。检查metadata.hermes.immutable是不是被误设成了 true或者 skill 目录的写权限有问题导致它只能改内容不能改 frontmatter。正常情况下每次修改都应该递增版本号这是回滚的前提。6. 把自进化接进你的工作流配置和验证都跑通之后最后一步是让它真正融入日常。我的做法是把 skill review 的输出接到一个轻量的审查环节每天收工前扫一眼当天新增或修改的 skill确认没有跑偏的。这不是不信任自动化而是自进化系统的质量取决于你的反馈质量——你给它的纠正越明确它沉淀的方法论越准。如果你想让 Agent 长期跑编码任务、持续积累 skill 库Coding Plan 比按量调用更划算入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有各语言 SDK 的完整示例。Claude Code 用户可以直接看 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 的接入说明。最后留一个我自己的经验自进化机制最怕的不是生成垃圾而是你从不回看它生成了什么。skill 库是你的数字资产定期 diff 一下版本变化你会发现 Agent 其实在悄悄记录你解决问题的方式——那些你以为它忘了的试错过程都被它写成了下一次的捷径。