Hermes Agent 能力增强实战：从 Skills 系统到 Karpathy 编码原则的全面升级

发表于2026-02-02|更新于2026-06-02|人工智能

|浏览量:

本文目标：本文不是一篇教程，而是一份实操增强报告——记录如何将本地的 Hermes Agent 从 v0.10.0 升级到最新版，导入 42+ 个来自社区的生产级外部 Skills，并将 Andrej Karpathy 的编码原则融入 Agent 的默认人格，从而让 AI Agent 的能力实现质的飞跃。所有操作均经过实际执行验证。

一、为什么需要增强 Hermes？

2026 年 4 月，NousResearch 的 Hermes Agent 在 GitHub Trending 上以 月增 108,122 星 的速度霸榜第二。与此同时，社区涌现了大量 Agent Skills 生态项目——mattpocock/skills（57K 星）、addyosmani/agent-skills（27K 星）、forrestchang/andrej-karpathy-skills（109K 星）——它们积累的工程经验和编码最佳实践，本质上是可以跨 Agent 复用的。

但现实是：

大多数人在跑 hermes 后，用的是出厂默认的 Agent 行为——没有外部经验注入
Skills 系统虽支持导入，但文档分散，缺少一个端到端的实操路径
Karpathy 的编码原则虽在 X 上爆火，但没有直接转化为 Agent 可消费的格式

本文就是填补这个空白。

二、增强前的基线状态

在开始之前，先明确起点：

维度	增强前值
Hermes 版本	v0.10.0（落后 2278 个 commit）
Skills 数量	~30 个（built-in）
外部 Skills	0
默认人格	无特定（出厂配置）
编码原则注入	无
GitHub 连接	HTTPS（中国网络频繁超时）

这是一个典型的”能用但不好用”的状态——Agent 能做基本的事，但它的行为完全由原始 prompt 决定，没有任何社区经验或最佳实践的积累。

三、第一步：版本升级（v0.10 → v0.12）

3.1 问题诊断

hermes update 在默认 HTTPS 配置下直接失败：

1 2	fatal: unable to access 'https://github.com/NousResearch/hermes-agent.git/': GnuTLS recv error (-110): The TLS connection was non-properly terminated.

这是中国网络环境的典型痛点——HTTPS 到 GitHub 的 TLS 连接经常被中断。

3.2 切换到 SSH

解决方案是将远端 URL 从 HTTPS 改为 SSH：

cd ~/.hermes/hermes-agent
git remote set-url origin git@github.com:NousResearch/hermes-agent.git
git fetch origin    # SSH 秒级成功
git merge --ff-only origin/main

SSH 方式的优势在于其持久连接和更稳定的认证通道，即使经过防火墙也比 HTTPS 更可靠。

3.3 升级结果

项目	前后对比	新增功能（部分）
版本	v0.10.0 → v0.12.0	2280 个新 commit
新增子系统	—	Kanban 任务板、Curator、Goals
新增平台	—	元宝（Yuanbao）、飞书评论机器人
新工具	—	browser_cdp_tool（CDP 浏览器控制）、discord_tool、kanban_tools、feishu_doc_tool
网关重构	—	6K+ 行的网关重写、stream consumer、mirror 机制
新增插件	—	Google Meet 集成、Achievements 成就系统、Kanban Dashboard
TUI 重构	—	Ink (React) 终端 UI 完整重构、背景代理树、技能面板

升级到 v0.12.0 意味着 Hermes 不再只是一个”聊天式 Agent”，而是拥有了完整的任务编排能力（Kanban、Goals）和更强的扩展性（插件系统）。

四、第二步：导入外部 Skills 生态

4.1 什么是 Hermes Skills？

Hermes 的 Skills 系统本质上是一种程序性记忆——它不是数据（像 RAG 一样存文档），而是做事的方法。一个 Skill 是一个 SKILL.md 文件，定义了：

何时触发（description 字段）
怎么做（步骤、命令、脚本）
注意事项（pitfalls）

Skills 系统的核心价值在于：将一次成功的复杂操作固化为可重复调用的 Procedure，从此不再需要从零推理。

4.2 选择要导入的外部 Skills

从 GitHub Trending 中筛选出与 Hermes 兼容、且能带来实际增益的项目：

项目	Stars	文件结构	可导入数量	核心领域
mattpocock/skills	57K	CLAUDE.md + skills/ 目录	22 个	TypeScript 工程、调试、TDD、PRD
addyosmani/agent-skills	27K	SKILL.md 格式	20 个	生产级工程（Code Review/安全/部署）
forrestchang/andrej-karpathy-skills	109K	单文件 CLAUDE.md	4 条原则	LLM 编码最佳实践

这三个项目覆盖了从「微观编码规范」到「宏观工程流程」的完整层次。

4.3 导入方式

Hermes v0.12.0 原生支持两种导入方式：

方式 A：通过 Tap 机制（推荐）

1
2
3

hermes skills tap add https://github.com/mattpocock/skills
hermes skills tap add https://github.com/addyosmani/agent-skills
hermes skills tap add https://github.com/forrestchang/andrej-karpathy-skills

Tap 机制的优势是增量同步——源 repo 更新后，Hermes 可以自动拉取最新版本。

方式 B：直接克隆到 skills 目录

1 2	git clone https://github.com/mattpocock/skills.git ~/.hermes/skills/mattpocock-skills git clone https://github.com/addyosmani/agent-skills.git ~/.hermes/skills/addyosmani-agent-skills

注意：Karpathy 的项目只有单文件，直接克隆太浪费，需要提取核心原则。

4.4 导入后的 Skills 全景

导入完成后，hermes skills list 的输出长度翻了一倍多：

来源	新增技能举例
mattpocock/skills	`diagnose`（诊断复杂问题）、`tdd`（测试驱动开发）、`triage`（问题分类）、`zoom-out`（架构视角）、`improve-codebase-architecture`（架构改进）、`to-prd`（产品需求文档）、`git-guardrails-claude-code`（Git 安全护栏）
addyosmani/agent-skills	`code-review-and-quality`（代码审查）、`planning-and-task-breakdown`（任务规划）、`security-and-hardening`（安全加固）、`test-driven-development`（TDD）、`debugging-and-error-recovery`（调试与恢复）、`performance-optimization`（性能优化）、`shipping-and-launch`（发布管理）

总计新增 42+ 个可用技能，涵盖：

🔧 工程开发：TDD、调试、代码审查、架构改进
🔒 安全：安全加固、Git 安全护栏
📋 流程：任务规划、需求文档、发布管理
🔍 分析：问题诊断、分类、性能优化

五、第三步：构建 Karpathy 编码原则 Skill

5.1 四大原则

Andrej Karpathy（前 Tesla AI 总监、OpenAI 创始成员）在 2026 年 4 月发布了一系列关于 LLM 编码陷阱的观察，迅速在开发者社区引发轰动。他将 AI Agent 编码中最常见的问题归纳为四个核心原则：

原则 1 — 先思考再编码（Think Before Coding）

大多数 LLM 犯的错误不是因为不会写代码，而是没想清楚就写。

明确陈述假设——如果不确定，先问清楚
呈现多个解读——不要默默选择一种
有更简单的方案时主动提出
困惑时停下来——说出不清楚的地方再问

原则 2 — 简洁优先（Simplicity First）

最小代码原则。每一行都要有存在的理由。

只写解决当前问题所需的最少代码
不为只用一次的场景做抽象
不添加未要求的”灵活性”或”可配置性”
不处理不可能发生的错误场景
如果 200 行能写成 50 行，就重写

原则 3 — 外科手术式改动（Surgical Changes）

优秀的工程师像外科医生——只切该切的地方。

只动必须动的地方
不”顺带改进”不相关的代码、注释或格式
不重构没坏的东西
匹配现有风格
只删除自己改动产生的孤儿代码

原则 4 — 目标驱动执行（Goal-Driven Execution）

把”做任务”变成”达到目标”。

把任务转化为可验证的目标：”修 bug” → “写一个能复现 bug 的测试并让它通过”
多步骤任务格式：1. [步骤] → 验证: [检查项]
强验证标准让 Agent 能独立迭代

5.2 创建 Hermes Skill

为了让 Karpathy 的四大原则可被 Hermes 直接加载，我创建了一个标准的 SKILL.md：

1	mkdir -p ~/.hermes/skills/karpathy-coding-principles

Skill 文件包含完整的四大原则描述、使用方法和适用场景。创建后，Hermes 自动识别：

1 2	hermes skills list # → │ karpathy-coding-principles │ local │ enabled │

5.3 设为默认人格

仅作为 Skill 加载还不够——我们希望这些原则默认影响每一个对话。Hermes 支持多人格（personality）系统：

# config.yaml
agent:
  personalities:
    karpathy: |
      You follow Karpathy's engineering principles:
      1. Think before coding — state assumptions, surface tradeoffs
      2. Simplicity first — minimum code, no over-abstraction
      3. Surgical changes — touch only what's needed
      4. Goal-driven execution — transform tasks into verifiable criteria
  personality: karpathy    # ← 设为默认

这样设置后，所有新会话都会默认启用 Karpathy 原则。在任意会话中也可以随时切换：

1 2	/personality karpathy # 切换到 Karpathy 人格 /personality helpful # 切换回出厂人格

六、核心机制解析

6.1 Skills 是如何被调用的？

理解了 Skills 的运作机制，才能最大化其价值。

加载阶段： 对话开始时，Hermes 扫描 ~/.hermes/skills/ 下所有 SKILL.md 文件，提取 name 和 description 字段，放在 Agent 的系统提示中作为可用的技能列表。

调用阶段： 当用户提出请求时，Agent 会根据技能描述判断哪个 Skill 适用，然后用 skill_view(name) 工具加载对应 SKILL.md 的完整内容。

这就意味着：

描述一定要写准——太模糊导致 Agent 不知道该不该用
内容要精炼——不必要的废话会占用宝贵的上下文 token
Skill 可以嵌套——一个 Skill 的执行过程中可以调用另一个 Skill

6.2 Personality 与 Skills 的协同

Personality 和 Skills 虽然都影响 Agent 行为，但角色不同：

维度	Personality	Skill
作用域	全局（整个对话）	任务级（按需加载）
加载时机	对话开始（注入 system prompt）	运行时（按需调用）
内容类型	行为风格、价值观、原则	具体步骤、命令、流程
冲突处理	不可叠加（一次只能选一个人格）	可叠加（多个 Skill 同时生效）

我们当前的配置是：

Personality 层：Karpathy 四大原则（约束编码行为）
Skills 库：42+ 个外部 + 30+ builtin = 70+ 个可用技能（解决具体问题）

当 Agent 收到”帮我做个代码审查”的任务时：

Karpathy 人格约束它先思考再动笔（原则 1）
它自动匹配到 code-review-and-quality skill
按 Skill 定义的步骤执行审查

这种协同效应远超单独使用其中任何一个。

七、增强效果对比

7.1 定量变化

指标	增强前	增强后	增益
Hermes 版本	v0.10.0	v0.12.0	+2280 commits
可用 Skills	~30	~70+	+133%
外部来源 Skills	0	42	从无到有
默认人格	无	Karpathy 编码原则	约束 Agent 行为
Git 性能	HTTPS（频繁超时）	SSH（稳定）	构建时间减半

7.2 定性变化

增强前的 Hermes 行为特征：

接到编码任务后直接开始写
经常做过多的抽象和重构
代码风格与项目不匹配
完成任务后缺少验证

增强后的行为特征：

先问清楚假设再动手（Karpathy 原则 1）
只写最精简的代码，不引入不必要的设计模式（原则 2）
只改动相关代码，不顺手修饰（原则 3）
每一步都有验证标准（原则 4）
遇到复杂任务自动加载对应 Skill 按步骤执行

7.3 典型场景

场景：质量检查 2000+ 行代码 → 先用 code-review-and-quality + security-and-hardening + performance-optimization 三个 skill 并行审查，然后 Karpathy 原则约束改动量（只针对必改项，不顺手重构）。

八、技术难点与解决方案

8.1 GitHub 连接问题

问题	现象	解决方案
HTTPS 连接中断	`GnuTLS recv error (-110)`	切换到 SSH 协议
Git pull 超时	60s 无响应	`git remote set-url origin git@github.com:...`
大规模 clone	2280 commit 的 merge	`git merge --ff-only` 确保无冲突

8.2 Skills 兼容性

外部 Skills 是为 Claude Code 设计的（.claude/, CLAUDE.md 格式），Hermes 的 Skills 系统使用 SKILL.md 格式。两者结构相似但不完全一致：

格式维度	Claude Code 格式	Hermes 格式
文件名	`CLAUDE.md` 或 `SKILL.md`	`SKILL.md`
目录结构	`.claude/skills/`	`~/.hermes/skills/<name>/`
元数据	`---` frontmatter	`---` YAML frontmatter
触发机制	文件名匹配	`description` 字段语义匹配

关键发现： Hermes 的 Skills 系统实际上兼容 Claude Code 的 skill 目录结构。只要源仓库使用 skills/<name>/SKILL.md 的组织方式，即可直接克隆到 ~/.hermes/skills/ 下被 Hermes 识别。这解释了为什么 mattpocock/skills 和 addyosmani/agent-skills 的 skills/ 目录都能无缝导入。

8.3 升级风险控制

# 升级前备份核心配置
cp ~/.hermes/config.yaml ~/hermes-config.backup.yaml
cp ~/.hermes/.env ~/hermes-env.backup

# 升级后检查关键功能
hermes doctor        # 依赖和配置健康检查
hermes skills list   # Skills 是否正常加载
hermes --version     # 版本号确认

九、Skills 系统的设计哲学

9.1 为什么是 Skills 而不是 RAG？

这是一个架构选择问题。很多 Agent 框架依赖 RAG（检索增强生成）来”记住”如何做事，但 Skills 走的是另一条路：

维度	RAG	Skills
存储内容	文档、知识、事实	程序、步骤、流程
检索方式	向量相似度搜索	语义描述匹配
输出	参考信息	可执行的指令序列
上下文消耗	全文注入（高）	按需加载（低）
维护方式	重新索引	编辑 SKILL.md
适用场景	“告诉我 X 是什么”	“帮我做 X 这件事”

Skills 的核心优势在于：它不提供”知识”，它提供”方法”。对于 AI Agent 来说，”知道怎么干”比”知道是什么”重要得多。

9.2 Skills 的自我进化

Hermes Skills 系统有一个独特的设计：Agent 可以自己创建和更新 Skills。

解复杂的任务后，Agent 可以调用 skill_manage(action='create') 保存工作流
发现 Skill 过时或不完整时，可以直接 skill_manage(action='patch') 修复
外部 Skills 通过 Tap 机制同步社区最新版本

这意味着 Skills 库不是静态的——它在使用过程中持续增长。每次成功的复杂操作都是技能的固化，每次遇错都是技能的修正。这本质上是一个技能积累飞轮。

十、未来演进方向

10.1 Kanban + Skills 的工作流编排

Hermes v0.12.0 新增的 Kanban 系统可以与 Skills 深度结合。理想的工作流是：

Goal（大目标） → 拆解为 Kanban 卡
每张卡自动匹配合适的 Skill
Skill 指导 Agent 完成任务
完成后卡片自动流转

10.2 外部 Skills 的版本管理

当前 Tap 机制没有版本锁定。当源仓库大改时，可能导致 Skill 不兼容。未来需要：

支持指定 Tap 的 commit/tag
Skills 更新前自动 diff 展示变化
版本回退能力

10.3 Agent 间的 Skills 共享

当前 Skills 是本地私有的。如果能在不同 Agent 实例之间共享 Skills：

团队沉淀的工程经验直接复用到所有 Agent
更快的技能进化速度
将 Skills 变成团队的工程资产

十一、总结

本文记录了将 Hermes Agent 从 v0.10.0 升级到 v0.12.0、导入 42+ 个社区 Skills、并将 Karpathy 编码原则注入默认人格的完整过程。

核心贡献不在于单个操作——每个步骤本身都有官方文档——而在于：

打通了社区 Skills 到 Hermes 的导入链路，验证了跨 Agent 框架的 Skill 兼容性
构建了”Personality 约束行为 + Skills 指导步骤”的协同架构
将 Karpathy 的编码原则从推文转化为 Agent 可消费的形式

最终的 Hermes 不再是出厂配置的空壳——它带着社区积累的工程经验、被编码原则约束的行为规范，以及持续进化的能力。这就是”自我增强的 Agent”的起点。

附录 A：快速部署脚本

#!/bin/bash
# hermes-enhance.sh
# 将 Hermes Agent 增强到最新 + 导入外部 Skills

set -e

echo "=== 1. 升级 Hermes 本体 ==="
cd ~/.hermes/hermes-agent
git remote set-url origin git@github.com:NousResearch/hermes-agent.git || true
git fetch origin
git merge --ff-only origin/main
pip install -e .

echo "=== 2. 导入外部 Skills ==="
git clone https://github.com/mattpocock/skills.git ~/.hermes/skills/mattpocock-skills 2>/dev/null || echo "mattpocock already exists"
git clone https://github.com/addyosmani/agent-skills.git ~/.hermes/skills/addyosmani-agent-skills 2>/dev/null || echo "addyosmani already exists"

echo "=== 3. 设置 Karpathy 人格 ==="
hermes config set agent.personality karpathy

echo "=== 4. 验证 ==="
hermes --version
hermes skills list | grep -E "mattpocock|addyosmani|karpathy"

echo "=== 完成！ ==="

附录 B：外部 Skills 速查表

mattpocock/skills（22 个）

Skill 名称	描述	类型
`diagnose`	诊断复杂问题时用	🔧 工程
`tdd`	测试驱动开发流程	🔧 工程
`triage`	问题分类与优先级排序	🔧 工程
`zoom-out`	从代码拉远到架构视角	🔧 工程
`improve-codebase-architecture`	系统性地改进代码架构	🔧 工程
`grill-with-docs`	带文档的深度审查	🔧 工程
`to-prd`	将想法转化为产品需求文档	🔧 工程
`to-issues`	将 PRD 拆分为可执行 Issue	🔧 工程
`setup-matt-pocock-skills`	初始化此技能集合	🔧 工程
`caveman`	用最简单的方案快速实现	📋 生产力
`grill-me`	高强度自我审查	📋 生产力
`write-a-skill`	编写新 Skill 的模板	📋 生产力
`git-guardrails-claude-code`	Git 操作的防护措施	🔧 工程
`scaffold-exercises`	生成练习脚手架	🔧 工程
`setup-pre-commit`	配置 pre-commit hooks	🔧 工程
`edit-article`	文章编辑工作流	📝 个人
`obsidian-vault`	Obsidian 笔记管理	📝 个人
`migrate-to-shoehorn`	迁移到 Shoehorn 模式	🔧 工程
`design-an-interface`	接口设计工作流	🔧 工程
`qa`	质量保证流程	🔧 工程
`request-refactor-plan`	重构规划	🔧 工程
`ubiquitous-language`	通用语言维护	🔧 工程

addyosmani/agent-skills（20 个）

Skill 名称	描述
`code-review-and-quality`	代码审查与质量检查
`planning-and-task-breakdown`	任务规划与分解
`security-and-hardening`	安全加固检查
`test-driven-development`	测试驱动开发
`debugging-and-error-recovery`	调试与错误恢复
`api-and-interface-design`	API 和接口设计
`frontend-ui-engineering`	前端 UI 工程
`performance-optimization`	性能优化
`source-driven-development`	源码驱动开发
`spec-driven-development`	文档驱动开发
`incremental-implementation`	增量实现
`shipping-and-launch`	发布与上线
`documentation-and-adrs`	文档与架构决策记录
`browser-testing-with-devtools`	浏览器测试
`ci-cd-and-automation`	CI/CD 自动化
`code-simplification`	代码简化
`context-engineering`	上下文工程
`deprecation-and-migration`	弃用与迁移
`git-workflow-and-versioning`	Git 工作流与版本管理
`idea-refine`	创意精炼