核心判断：Hermes Agent 用 Python 打赢 Rust，靠的不是语言性能，而是三刀精准的工程优化 + 一套"越用越聪明"的 Skills 架构。

如果你在做 Agent 开发，这篇文章会告诉你：架构决策，远比语言选型重要。

本文结构：1. 反直觉的结果 → 2. 架构分析 → 3. 三刀优化拆解 → 4. 为什么 Python 能赢 → 5. 三个启示 → 6. 框架选型参考

一、一个反直觉的结果

2026 年 5 月，开源 AI Agent 框架 Hermes 在 11 项真实 CLI 任务基准测试中，以 6:5 击败 OpenAI Codex。

（注：11 项测试样本量有限，但优化前后的对比方向是清晰的，数据差异已足够说明问题。）

这本身不算大新闻。真正炸裂的是技术栈：

表格

	Hermes Agent	OpenAI Codex
语言	Python（88.6%）	Rust
开发方	开源社区 Nous Research	万亿市值公司

Python 赢 Rust？在"性能敏感"的 Agent 框架领域？

更反直觉的是——优化前 Hermes 还是 5:6 落后。三周后，三项工程优化把启动时间从 701ms 砍到 258ms，直接翻盘。

443ms 的优化，改变了战局。

怎么做到的？

二、先看架构：Hermes 凭什么敢跟 Codex 叫板

Hermes 不是简单套壳的 Agent 框架。它的核心差异化是一套 Skills 闭环自进化系统。

Skills 闭环：让 Agent 越用越聪明

传统 Agent 框架是"单次执行"模式——你问它答，答完就忘。Hermes 设计了一个五步学习飞轮：

任务执行 → 结果评估 → 技能提取 → 技能自改进 → 定期推送 → 循环

源码里的注释写得直白：

"After completing a complex task (5+ tool calls), fixing a tricky error, or discovering a non-trivial workflow, save the approach as a skill so you can reuse it next time."

（完成一次复杂任务、修复一个棘手错误、或发现一个非平凡工作流后，把方法保存为技能，下次直接复用。）

"When using a skill and finding it outdated, incomplete, or wrong, patch it immediately — don't wait to be asked."

（使用技能时发现过时、不全或错误，立刻修——别等别人来告诉你。）

三个关键设计点：

• 触发条件明确：不是所有任务都建技能。5 次以上工具调用、修复复杂错误、发现非平凡工作流，才触发创建。
• 自改进机制：每 15 次工具调用后自动评估技能质量，发现过时立即更新。
• 渐进加载：Level 0 只加载技能名 + 描述（约 3K tokens 覆盖 40+ 技能），按需才加载完整内容，避免上下文膨胀。

三层记忆架构

表格

层级	存储位置	生命周期	职能
L1 冻结 Prompt	MEMORY.md / USER.md	永久	基础身份
L2 技能记忆	skills/*.md	永久	程序性知识
L3 会话历史	SQLite FTS5	按需索引	全量对话检索

这套架构让 Hermes 在多轮任务上天然占优——Codex 每次启动都是"白纸一张"，而 Hermes 带着历史技能库上阵。

但问题在于：启动太慢了。

三、三刀砍掉 443ms：工程优化的教科书

优化前，Hermes 的启动时间是 701ms。在单轮 CLI 任务中，框架开销被 Codex 的 Rust 启动速度碾压，导致 5:6 落后。

开发者没有选"重写为 Rust"这条看似正确的路。他们拿 profiling 数据说话，一刀一刀切冗余。

第一刀：Bitwarden 磁盘缓存（省 380ms）

问题：每次启动都调 Bitwarden Secrets Manager API 拉取凭据，一次调用 380ms。之前的缓存是进程内的——连续执行两次 hermes chat -q，第二次还得重新拉。

解法：

• 加 L2 磁盘缓存层
• 缓存文件权限锁死 0600（安全）
• 访问 token 绝不落盘
• 默认 300 秒 TTL

一刀下去，省了 380ms，占全部优化的 85.8%。

💡 这不是什么高深技术。就是找到了真正的瓶颈。

第二刀：模型目录延迟加载（省 55ms）

问题：_PROVIDER_MODELS 是包含 18+ 供应商所有模型信息的巨型字典，模块加载时就急切导入。但实际上只有 model_flow 相关函数才用到它。

解法：用 PEP 562 的模块级 __getattr__ 实现懒加载。标准 Python 语法，零黑魔法。

省了 55ms。

第三刀：配置文件去重（省 17ms）

问题：main.py 顶部读了两次 config.yaml——一次为了密钥脱敏桥接，一次为了检查一个布尔值。

解法：合并为一次原始加载。

省了 17ms。

优化总结

表格

优化项	节省	占比	复杂度
Bitwarden 磁盘缓存	380ms	85.8%	低
PEP 562 延迟加载	55ms	12.4%	低
配置文件去重	17ms	3.8%	极低

三个优化的共同特点：没有改语言、没有加 C 扩展、没有换框架。 纯靠 profiling 定位瓶颈，用标准 Python 语法解决。

最终结果：701ms → 258ms，降幅 63.2%。 战绩从 5:6 翻为 6:5。

四、为什么 Python 能赢 Rust

资深开发者 netrunner 的评论一针见血：

"Python 在多轮任务上打赢 Rust，本质上是架构决策的胜利，不是语言速度的胜利。"

Hermes 联创 Teknium 被问"为什么不迁移到 Rust"时回答：

"那样就无法编辑代码，以及实时改进和迭代。"

这两句话道出了 Agent 框架的核心矛盾：

💡 Agent 框架的竞争维度不是"启动快 0.1 秒"，而是"能不能越用越聪明"。

• Codex 用 Rust 追求极致启动速度，但每次执行都是无状态的单次调用。
• Hermes 用 Python 牺牲一点启动速度，换来 Skills 自进化闭环——执行越多，技能库越丰富，后续任务效率越高。

优化前，Hermes 在多轮任务上就已经领先。三项优化抹平了单轮任务的开销差距后，Rust 的"速度优势"就不再有意义了。

五、对 Agent 开发者的三个启示

启示 1：性能靠 Profiling，不靠猜测

Hermes 三刀优化，刀刀精准：

• 最大瓶颈是 380ms 的 API 调用，不是 Python 的"慢" 。
• 解法是加缓存，不是换语言。

💡 实践建议：遇到性能问题，先 profile 再动手。往往 80% 的开销来自 20% 的代码，而那 20% 很可能跟语言无关。

启示 2：Skills 系统是差异化核心

Hermes 的 Skills 设计有三点值得借鉴：

1. 触发条件明确：不是什么任务都创建技能，5 次以上工具调用才算。
2. 自改进闭环：15 次调用后自动评估，发现过时立即更新。
3. 渐进加载：避免上下文膨胀，3K tokens 覆盖 40+ 技能。

对于扣子 / Coze Skill 开发者：设计技能时考虑触发条件 + 执行步骤 + 常见陷阱，而不是堆功能。

启示 3：开放架构比极致性能更重要

"Python 的优势不在于快，而在于活。"

Agent 框架需要持续进化。封闭的高性能方案，迭代速度永远比不过开放的易修改方案。特别是在 ASI（人工超级智能）时代，迭代速度就是生存能力。

六、框架选型参考

表格

框架	适合	不适合
Hermes	跨平台自动化、长期运行 Agent、需自学习的场景	简单一次性问答
Claude Code	IDE 深度开发、代码为主的工作流	跨平台集成、预算敏感
OpenClaw	企业自动化、多组件编排	需要自进化能力
Codex	单次 CLI 任务、追求极致启动速度	需要记忆和技能积累

写在最后

Hermes 击败 Codex 这个故事，最大的价值不是"Python 赢了 Rust"这个噱头，而是它证明了一件事：

💡 在 Agent 领域，架构决策 > 语言选型 > 原始性能。

443ms 的优化已经是框架层能挤出的极限。而一次 LLM 调用的延迟动辄数秒。真正的竞争从来不是"用什么语言写"，而是"怎么让 Agent 越用越聪明"。

Rust 是一把好刀。但 Agent 需要的不是一把更快的刀，而是一个会自己磨刀的人。

你在做 Agent 开发时，有没有遇到"换语言解决一切"的坑？你的 profiling 经历呢？欢迎留言聊聊。

下一篇拆另一个 Agent 框架的架构设计，感兴趣的评论区告诉我你想看哪个。

参考来源：

• Hermes Agent GitHub
• Hermes Agent 官方文档
• PyShine 实践指南
• Hermes Atlas 社区优化指南
• Hermes Agent 官方框架对比