Hermes Agent 白皮书 —— 养马从入门到精通
作者:鲲鹏Talk
2026年4月 · 第一版
关于作者
鲲鹏Talk,AI 趋势研究者、开源 Agent 深度玩家。
自2023年起持续关注大语言模型与 AI Agent 领域的前沿动态,亲历了从 ChatGPT 引爆全球到多模态大模型百花齐放,再到 AI Agent 自主执行能力实现质的飞跃的全过程。在开源社区中,深度参与并跟踪了多个知名 Agent 框架的演进,尤其对 Nous Research 旗下的 Hermes 项目有着长期且深入的实践与研究。
联系方式:
- 微信视频号:鲲鹏Talk
- B站:鲲鹏Talk
- 微信公众号:鲲鹏Talk
- YouTube:鲲鹏Talk
- 小红书:鲲鹏Talk
- 抖音:鲲鹏Talk
无论你在哪个平台,搜索「鲲鹏Talk」都能找到我。我坚持在各平台同步输出关于 AI Agent、开源技术趋势以及实战经验的深度内容,期待与志同道合的朋友一起交流、共同进步。
版本说明
当前版本
第一版 · v1.0
发布时间:2026年4月
更新日志
| 版本 | 日期 | 更新内容 |
|---|---|---|
| v1.0 | 2026年4月 | 初始版本,完整覆盖 Hermes Agent 的16个核心主题 |
许可协议
本白皮书采用 CC BY-NC-SA 4.0(署名-非商业性使用-相同方式共享) 协议发布。
你可以自由地:
- 共享 — 在任何媒介或格式下复制、分发本作品
- 改编 — 对作品进行重混、转换或基于本作品进行创作
惟须遵守下列条件:
- 署名 — 你必须给出适当的署名,提供指向本许可协议的链接,并标明是否对原始作品作了修改
- 非商业性使用 — 你不得将本作品用于商业目的
- 相同方式共享 — 如果你重混、转换或基于本作品进行创作,你必须采用与本作品相同的许可协议分发你的贡献
本白皮书所有示例代码遵循 MIT 许可证,你可以将其用于商业或非商业项目。
这本书是写给谁的
在动笔之前,我一直在思考一个问题:这本白皮书究竟应该服务于谁?经过长时间的社区调研、用户访谈和实践经验总结,我清晰地描绘出了五类典型的读者画像。无论你是刚刚接触 AI Agent 的新手,还是深耕技术多年的开发者,亦或是寻找商业机会的企业家和投研人员,这本书都将为你提供系统性的知识框架和可落地的实操指南。
第一类:AI Agent 小白入门者
如果你对 AI Agent 的认知还停留在「听说过 ChatGPT 可以联网查资料」的阶段,如果你好奇为什么有人能让 AI 自动订机票、写报告、发邮件,如果你希望从零开始系统地了解这个领域而不被碎片化的信息所淹没——那么你就是这本书最重要的读者之一。
本书的第六册「基础使用入门」和第十二册「高阶玩法与实战案例」专门为你们设计了大量保姆级教程。你不需要懂编程,不需要会写代码,只需要按照书中的步骤一步步操作,就能让你的第一个 Hermes Agent 跑起来。我们会从最基础的概念讲起,用通俗易懂的语言解释什么是 Agent、什么是工具调用、什么是记忆系统,确保你在阅读过程中不会遇到「知识断崖」。
第二类:开发者与技术爱好者
你可能是 Python 开发者、全栈工程师、DevOps 专家,或者是对开源技术充满热情的技术爱好者。你已经具备了一定的编程基础,希望能够深入理解 Hermes 的底层架构、扩展其功能、甚至为其贡献代码。
对于你们,本书的第四册「核心架构深度解析」将带你深入 Hermes 的五层架构,理解每一个模块的设计哲学和实现细节。第七册「三层记忆系统详解」和第八册「技能系统完全指南」将帮助你掌握如何构建更智能、更个性化的 Agent 应用。第九册「47个内置工具全解」和第十一册「MCP协议与自动化」则为你提供了丰富的扩展点,让你的 Agent 能够连接几乎任何外部服务。
第三类:创业者与独立开发者
你正在寻找下一个创业风口,或者希望通过 AI 技术打造一款有商业价值的产品。你关心的是:Hermes 能帮我做什么?部署和维护成本高吗?如何快速验证产品想法?怎样才能赚到钱?
本书的第十四册「九大变现路径」将是你的必读章节。我们详细拆解了九条经过验证的变现路径,每条路径都配有真实案例和收入预估。第五册「安装部署全攻略」帮助你以最低成本搭建生产环境。第十三册「OpenClaw对比与迁移」让你在技术选型时做出最明智的决策。本书不仅教你「怎么做」,更帮你思考「做什么能赚钱」。
第四类:投研人员与行业分析师
你关注 AI 赛道的投资标的,需要快速、准确地评估一个开源项目的技术实力、社区活跃度和商业化潜力。你需要的是结构化的信息、客观的数据和深度的行业洞察。
本书的第二册「AI-Agent行业全景」为你梳理了从2023年到2026年整个 AI Agent 行业的发展脉络和竞争格局。第三册「Hermes诞生与演进」详细介绍了 Nous Research 的背景、技术基因以及从 OpenClaw 到 Hermes 的演进逻辑。第十三册「OpenClaw对比与迁移」提供了12个维度的横向对比分析,帮助你快速定位 Hermes 在行业中的位置。第十六册「未来展望与总结」则基于一手实践经验和行业观察,给出了对2026-2027年发展趋势的前瞻判断。
第五类:企业用户与技术决策者
你的企业正在评估是否引入 AI Agent 技术来提升内部效率或优化客户服务。你需要了解的是:Hermes 是否足够稳定和安全?能否与现有系统集成?合规性如何保障?总拥有成本是多少?
本书的第四册「核心架构深度解析」帮助你评估系统的技术成熟度。第十册「多平台接入实战」展示了如何将 Hermes 集成到企业已有的沟通平台(如飞书、企业微信、钉钉等)。第十二册「高阶玩法与实战案例」中的企业应用案例将为你提供直接的参考。第十一册「MCP协议与自动化」让你了解如何在企业环境中实现安全、可控的自动化流程。我们的目标是帮助企业决策者做出有据可依的技术选型决策。
如何阅读本书
本书采用模块化设计,16个分册既可以按顺序通读,也可以根据你的需求选择特定路线进行跳跃式阅读。以下是四条经过精心设计的推荐阅读路线:
路线一:快速入门路线(预计 3-4 小时)
适合人群:AI Agent 小白、时间紧张的初学者
阅读顺序:
- 第一册「前言与概述」(30分钟)—— 了解白皮书的定位和核心价值
- 第三册「Hermes诞生与演进」(20分钟)—— 快速了解项目背景
- 第五册「安装部署全攻略」(60分钟)—— 动手部署你的第一个 Hermes 实例
- 第六册「基础使用入门」(60分钟)—— 学会基础操作和对话
- 第十二册「高阶玩法与实战案例」选读(40分钟)—— 看看别人是怎么玩的
这条路线的设计理念是「先跑起来,再慢慢理解」。我们相信,当你亲眼看到 Agent 自动完成一项任务时,你对这个技术的理解会比阅读十篇理论文章更加深刻。完成这条路线的学习后,你将拥有一个可运行的 Hermes 环境,并具备基础的操控能力。
路线二:深度技术路线(预计 15-20 小时)
适合人群:开发者、技术架构师、希望深入理解系统的技术人员
阅读顺序:
- 第一册「前言与概述」(30分钟)
- 第二册「AI-Agent行业全景」(60分钟)—— 建立行业视野
- 第三册「Hermes诞生与演进」(40分钟)—— 理解设计背景
- 第四册「核心架构深度解析」(120分钟)—— 深入理解五层架构
- 第七册「三层记忆系统详解」(90分钟)—— 掌握记忆机制
- 第八册「技能系统完全指南」(90分钟)—— 学会技能开发
- 第九册「47个内置工具全解」(120分钟)—— 熟悉工具生态
- 第十一册「MCP协议与自动化」(120分钟)—— 掌握高级自动化
- 第十三册「OpenClaw对比与迁移」(90分钟)—— 理解技术差异
这条路线要求读者具备一定的编程基础(尤其是 Python)。每一册都配有代码示例和架构图,建议你边读边动手实践。完成这条路线后,你将具备独立开发、定制和扩展 Hermes Agent 的能力。
路线三:变现赚钱路线(预计 8-10 小时)
适合人群:创业者、独立开发者、希望将技术转化为收入的技术人员
阅读顺序:
- 第一册「前言与概述」(20分钟)
- 第二册「AI-Agent行业全景」(40分钟)—— 了解市场格局和机会
- 第五册「安装部署全攻略」(60分钟)—— 掌握部署技能
- 第十册「多平台接入实战」(90分钟)—— 学会平台集成
- 第十二册「高阶玩法与实战案例」(90分钟)—— 获取实战灵感
- 第十四册「九大变现路径」(120分钟)—— 核心章节,逐条研究
- 第十五册「社区生态与资源」(40分钟)—— 找到合作伙伴和资源
- 第十六册「未来展望与总结」(30分钟)—— 把握趋势方向
这条路线的重点是「从需求出发,用技术落地」。我们不只讲技术,更讲商业逻辑。第十四册的每一条变现路径都经过深思熟虑,涵盖了从低门槛的个人副业到高价值的企业服务的完整光谱。
路线四:从 OpenClaw 迁移路线(预计 6-8 小时)
适合人群:现有 OpenClaw 用户、正在评估迁移的技术团队
阅读顺序:
- 第一册「前言与概述」(20分钟)
- 第三册「Hermes诞生与演进」(40分钟)—— 理解演进逻辑
- 第四册「核心架构深度解析」(90分钟)—— 对比架构差异
- 第六册「基础使用入门」(60分钟)—— 熟悉新操作方式
- 第七册「三层记忆系统详解」(60分钟)—— 理解新记忆系统
- 第八册「技能系统完全指南」(60分钟)—— 掌握技能迁移方法
- 第十三册「OpenClaw对比与迁移」(120分钟)—— 核心迁移指南
- 第十五册「社区生态与资源」(30分钟)—— 找到新社区支持
这条路线围绕「平滑迁移」这个核心目标展开。第十三册提供了详细的迁移步骤、常见问题和兼容性对照表,帮助你将现有的 OpenClaw 配置、技能和工具链无缝迁移到 Hermes。
完整目录
以下是本书 16 个分册的完整目录。每个分册都是独立完整的知识单元,同时又与其他分册相互关联,构成一张覆盖 Hermes Agent 全领域的知识网络。
| 分册 | 文件名 | 字符数 | 内容简介 |
|---|---|---|---|
| 第一册 | 01-前言与概述.md | 24,501 | 为什么写这本书、白皮书的定位与愿景、读者画像与阅读建议。本章将回答「为什么要关注 Hermes Agent」这个根本问题,帮助你建立正确的学习预期和知识框架。 |
| 第二册 | 02-AI-Agent行业全景.md | 37,829 | AI Agent 从 2023 到 2026 的发展简史、2025-2026 年的行业格局与竞争态势、主流框架(AutoGPT、LangChain、OpenClaw 等)的全面对比。读完本章,你将对整个行业有一个清晰的鸟瞰图。 |
| 第三册 | 03-Hermes诞生与演进.md | 33,819 | Nous Research 的团队背景与技术基因、OpenClaw 的辉煌与局限、从 OpenClaw 到 Hermes 的演进历程与关键决策。理解一个项目的过去,是预判它未来的最佳方式。 |
| 第四册 | 04-核心架构深度解析.md | 73,011 | Hermes 的五层架构(接入层、推理层、记忆层、技能层、工具层)逐层详解、自学习闭环的设计与实现、系统设计的核心哲学。这是理解 Hermes「为什么这样做」的关键章节。 |
| 第五册 | 05-安装部署全攻略.md | 67,679 | 本地部署(macOS/Linux/Windows)、Docker 容器化部署、VPS 云服务器部署三种方式的完整步骤、环境配置、常见问题排查与故障排除指南。保姆级教程,确保你一定能跑起来。 |
| 第六册 | 06-基础使用入门.md | 56,328 | 首次运行 Hermes 的完整流程、对话模式详解、常用命令速查手册、主流大模型(OpenAI、Anthropic、本地模型等)的接入配置。读完本章,你将熟练掌握 Hermes 的日常操作。 |
| 第七册 | 07-三层记忆系统详解.md | 71,014 | 会话记忆(短期上下文管理)、持久记忆(SQLite + FTS5 全文检索)、Skill 级记忆(跨会话知识沉淀)三层记忆系统的工作原理、配置方法和最佳实践。记忆是 Agent 智能化的核心。 |
| 第八册 | 08-技能系统完全指南.md | 75,658 | 技能的定义与生命周期、自动技能创建机制、Skills Hub 生态的使用与贡献、跨平台技能复用的原理与实践。掌握技能系统,你就掌握了让 Agent 持续进化的密码。 |
| 第九册 | 09-47个内置工具全解.md | 119,076 | Hermes 内置的 47 个工具按七大类别(Web 与搜索、文件与数据、代码与开发、系统与运维、通信与消息、媒体与内容、金融与分析)逐一详解,包含使用场景和配置示例。 |
| 第十册 | 10-多平台接入实战.md | 43,698 | 飞书、企业微信、微信、Telegram、Discord、Slack、钉钉等 15+ 主流平台的接入方法、Webhook 配置、消息格式适配、权限管理和安全最佳实践。 |
| 第十一册 | 11-MCP协议与自动化.md | 48,864 | MCP(Model Context Protocol)协议的核心概念与工作原理、如何接入 6000+ MCP 服务、Cron 定时任务配置、多 Agent 编排与协作机制。让自动化成为你工作流程的一部分。 |
| 第十二册 | 12-高阶玩法与实战案例.md | 114,757 | 沙箱环境的安全执行、语音交互的集成方案、投研自动化流水线的搭建、企业级应用场景(智能客服、内部助理、数据分析师)的完整案例。从「会用」到「用好」的跨越。 |
| 第十三册 | 13-OpenClaw对比与迁移.md | 36,169 | Hermes 与 OpenClaw 在架构、性能、生态、安全性、扩展性等 12 个维度的深度对比、从 OpenClaw 迁移到 Hermes 的完整教程、不同场景下的选型建议与决策框架。 |
| 第十四册 | 14-九大变现路径.md | 37,363 | 九条经过验证的变现路径(自动化服务订阅、定制化开发、培训与咨询、内容创作、SaaS 产品、企业解决方案、技能市场、数据服务、联盟营销)的详细拆解、真实案例和收入预估。 |
| 第十五册 | 15-社区生态与资源.md | 19,103 | Hermes 官方资源导航(文档、GitHub、Discord)、活跃的社区项目与第三方扩展推荐、从入门到精通的系统学习路径规划、常见问题 FAQ 汇总。 |
| 第十六册 | 16-未来展望与总结.md | 17,967 | 2026-2027 年 AI Agent 行业发展趋势预判、Hermes 的公开路线图解读、对开源社区和个体开发者的建议、全书总结与结语。 |
| 总计 | 17 个文件 | 885,180 | 远超 30 万字目标(达成率 295%) |
导读:为什么要读这本书
2026年的今天,AI Agent 已经从概念验证走向了大规模应用落地。我们见证了太多「一夜暴富」的故事——有人用 Agent 自动化运营十个自媒体账号,月入数万;有人为企业搭建智能客服系统,签下百万大单;也有人在开源社区贡献了关键的技能插件,获得了知名公司的青睐。
但与此同时,我也看到了太多人在门外徘徊。他们被碎片化的信息所困扰,今天听说这个框架好用,明天看到那个工具火爆,却始终无法构建起系统性的认知框架。他们下载了项目,却因为缺乏系统的指导文档而卡在安装步骤;他们读了很多技术文章,却不知道如何将这些知识串联起来解决实际问题。
这就是我写这本书的初衷。
Hermes Agent 是目前开源社区中最具潜力的 AI Agent 框架之一。它继承了 OpenClaw 的优秀基因,同时在架构设计、记忆系统、技能生态和自动化能力上实现了全面升级。它既适合个人开发者快速搭建原型,也适合企业用户构建生产级应用。它拥有活跃的社区、清晰的路线图和强大的技术团队背书。
但 Hermes 的文档分散在多个仓库和平台上,缺乏一本系统性的中文指南。本书填补的正是这个空白。我们将从零开始,手把手地带你走进 Hermes 的世界——从安装部署到高阶开发,从个人玩赚到企业服务,从单 Agent 操控到多 Agent 编排。
这本书不是一本简单的 API 文档翻译,也不是一篇泛泛而谈的行业评论。它是基于大量实践经验、社区访谈和深度研究撰写的系统性指南。每一个章节都经过精心设计,确保知识的连贯性和实用性。每一个示例都经过实际测试,确保你可以直接复制使用。
我希望,当你读完这本书后,不仅能够熟练地使用 Hermes Agent,更能够理解其背后的设计哲学,从而有能力根据自己的需求进行定制和扩展。我希望,这本书能够成为你在 AI Agent 领域的「第一本教科书」和「第一本工具书」。
让我们一起开始这段「养马之旅」。
致谢
一本书的诞生从来不是一个人的功劳。在撰写这本白皮书的过程中,我得到了太多人的帮助和支持,在此表示最诚挚的感谢。
首先,感谢 Nous Research 团队。你们创造了 Hermes 这样优秀的开源项目,并以开放、透明的态度推动了整个 AI Agent 生态的发展。没有你们日复一日的代码贡献和社区运营,就没有这本书的存在基础。
感谢 Hermes 和 OpenClaw 的开源社区。在 Discord 频道、GitHub Issues 和各个技术论坛上,无数开发者分享了自己的使用经验、踩坑记录和创意玩法。你们的讨论和贡献是本书许多实战案例和排障指南的重要来源。
感谢所有在我各平台(微信视频号、B站、YouTube、小红书、抖音)留言、私信、参与讨论的粉丝们。你们提出的问题、分享的需求和给予的鼓励,是我持续输出内容的最大动力。很多章节的核心话题,正是源自你们的真实疑问。
感谢 AI 领域的先行者们。从 AutoGPT 到 LangChain,从 BabyAGI 到 OpenClaw,正是这些项目的探索和试错,为 Hermes 的诞生铺平了道路,也为本书提供了丰富的行业参照。
最后,感谢我的家人。在无数个深夜撰写和修改的日子里,是你们的理解和支持让我能够专注于这份热爱。
本书在写作过程中参考了以下主要资料来源:
- Nous Research 官方文档与 GitHub 仓库
- Hermes 社区 Discord 讨论记录
- OpenClaw 项目文档与迁移指南
- MCP(Model Context Protocol)官方规范
- 各主流 AI 平台的技术博客与发布说明
- 行业研究机构发布的 AI Agent 市场分析报告
如果本书中有任何疏漏或不准确之处,责任完全在我,欢迎通过上述任一平台联系我进行指正。开源精神的核心就是「共同改进」,期待你的反馈能让下一版更加完善。
作者:鲲鹏Talk
微信视频号:鲲鹏Talk B站:鲲鹏Talk 微信公众号:鲲鹏Talk YouTube:鲲鹏Talk 小红书:鲲鹏Talk 抖音:鲲鹏Talk
2026年4月
第一册:前言与概述
本章你将学到
- 为什么在这个时间节点,一本系统性的 Hermes Agent 白皮书如此重要
- Hermes Agent 到底是什么,它和 ChatGPT、AutoGPT 有什么区别
- 2026 年 AI Agent 市场的格局,以及 Hermes 的五大核心优势
- 全书 16 册的内容架构,以及针对不同读者的四条阅读路线
- 开源社区资源的快速导航
- 本书涉及的 20+ 核心术语的速查表
预计阅读时间:45-60 分钟
1. 为什么写这本白皮书
1.1 AI Agent 时代已来,但大多数人还在门外观望
2026 年的春天,如果你打开任何一个科技媒体的首页,"AI Agent" 这个词几乎会占据半壁江山。
有人在展示自己的 Agent 如何自动完成一份行业研究报告——从数据收集、竞品分析到 PPT 生成,全程无需人工干预。有人在炫耀自己的 Agent 同时运营着 20 个自媒体账号,每天自动选题、写作、排版、发布,月收入超过了很多上班族的年薪。还有人在企业里部署了智能客服 Agent,不仅 7×24 小时在线回答问题,还能主动学习新的产品知识,越用越聪明。
但与此同时,我也看到了另一群人的困惑。
他们可能是你,也可能是你的朋友——听说过 ChatGPT 能联网查资料,但不知道为什么有人能让 AI "自动" 做那么多事情;收藏了几十个关于 Agent 的视频和文章,但看完还是觉得云里雾里;下载过 AutoGPT 或 OpenClaw,但运行起来不是报错就是卡在原地,最后无奈放弃。
这像极了二十年前互联网刚普及时的情景。那时候也有人能建网站、写博客,但更多人面对 "HTML 是什么" 这个问题时一脸茫然。区别在于,当年你不懂互联网,最多是错过了一个信息获取的便利渠道;而在 2026 年,不懂 AI Agent,可能意味着你将在效率竞赛中被远远甩在后面。
Tips
不要觉得 "AI Agent 是程序员的事"。2026 年的 Agent 工具已经发展到了"半代码化"甚至"无代码化"的阶段。你不需要会写 Python,也能搭建一个属于自己的智能助手。这本书的目标,就是让你——无论你是否有技术背景——都能真正 "入门" 并 "用好" Hermes Agent。
1.2 市面上的教程碎片化严重,缺乏系统性
让我问你一个问题:如果你想学 Hermes Agent,现在能找到哪些学习资源?
首先,你可以去 GitHub 上看官方 README。写得不错,但毕竟是面向开发者的技术文档,充满了配置参数和命令行指令。对于没有技术背景的人来说,读完第一段可能就放弃了。
然后,你可以去 B站、YouTube 搜视频教程。有些视频确实讲得很精彩,但问题是——它们大多是碎片化的。这个 UP 主讲安装,那个博主讲配置,还有一个视频专门介绍某个技能。你学完了 "如何安装",但 "为什么要这样配置" 还是不清楚;你看懂了 "这个技能怎么用",但 "如何创建自己的技能" 依然是个谜。
更麻烦的是,很多教程的时效性很差。AI Agent 这个领域发展太快了,三个月前的 "最佳实践" 可能现在已经过时了。你按照某个教程操作,结果因为版本更新,命令已经变了、接口已经改了,折腾半天还是跑不通。
常见问题
Q:我已经看过很多关于 OpenClaw 的教程了,为什么还要学 Hermes?
A: 好问题!Hermes 和 OpenClaw 确实有很多相似之处(毕竟它们有共同的起源),但 Hermes 在架构设计、记忆系统、技能生态等方面都有重大升级。如果你只懂 OpenClaw,那么你在使用 Hermes 时会错过很多强大的新功能。更重要的是,本书不仅教你 "怎么用",更教你 "为什么这样设计",这才是系统性学习的价值。
1.3 从"养虾"到"养马"的转变,需要一本完整指南
让我用一个类比来解释这个变化。
假设你是一个喜欢养宠物的人。最开始,你养的是虾——投点饵料,换换水,虾就能活。对应到 AI 世界,这就是早期的 ChatGPT 时代:你给 AI 一个问题,它给你一个答案。简单直接,但互动是单向的,AI 不会"记住"你们之前的对话,也不会"主动"为你做什么。
后来,你开始养鱼。鱼缸需要更复杂的生态系统——过滤、打氧、温控、光照。对应到 AI 世界,这就是 RAG(检索增强生成)和工具调用时代:AI 可以查资料、调用工具,但它还是按照你的指令一步一步执行,没有自主性。
再后来,你开始养猫养狗。它们有自己的性格、记忆和习惯。它们会在你回家时迎接你,会记住你不喜欢什么,甚至会自己学会一些"技能"——比如开门、按铃要食物。对应到 AI 世界,这就是 Agent 时代:AI 不再只是回答问题,而是能够自主感知环境、做出决策、执行任务,并且从经验中学习和进化。
现在,你决定养一匹马。
马和猫狗又不一样。马可以载着你走很远的路,可以帮你完成真正的"工作"——运输、农耕、甚至比赛。但养马也更需要系统性知识:如何选择品种、如何训练、如何建立信任关系、如何让它理解你的指令、如何让它越骑越顺手。
Hermes Agent,就是这样一匹马。
它不是玩具,不是宠物,而是一个真正能帮你干活的伙伴。但要把这匹马"养好"、"训好"、"用好",你需要一本完整的指南——从认识马、选马、养马,到骑马、赛马、甚至培育自己的马。这就是我写这本白皮书的初衷。
注意
"养马"这个比喻贯穿了整本书。你会发现,很多复杂的概念我都会用养马来类比。Hermes 这个名字本身就来自希腊神话中的信使之神——他骑着飞马穿梭天地,传递信息。所以,"养马"不仅是类比,也是一种隐喻:你正在培养一个快速、聪明、忠诚的 AI 伙伴。
1.4 本书的定位:不是技术论文,是你的 AI 伙伴养成手册
在动笔之前,我给自己定了一个硬性要求:这本书不能让任何一个读者感到"被排斥"。
很多技术文档都有一个隐含的假设:读者已经具备了某些基础知识。比如,它们会默认你知道什么是 API、什么是 JSON、什么是环境变量。但对于真正的初学者来说,这些"基础知识"本身就是一道门槛。
所以,这本书的定位非常明确:
- 它不是学术论文。你不需要有计算机科学学位才能读懂。
- 它不是 API 文档。我不会罗列每一个函数的参数和返回值。
- 它不是一本快餐式的操作手册。我不满足于只告诉你"点这里、填那里"。
- 它是一本养成手册。我会带你从"完全不懂"走到"真正会用",再到"能够根据自己的需求定制"。
书中的每一个概念,我都会用生活化的类比来解释。每一个操作步骤,我都会假设你是第一次接触。每一个可能出现的问题,我都会提前告诉你怎么解决。
Tips
如果你在某个章节遇到了不理解的术语,不要慌。翻到本章最后的"术语表",或者在全书最后的索引中查找。我承诺:书中出现的每一个专业术语,至少会在第一次出现时给出通俗解释。
1.5 这本书的独特之处
市面上的技术书籍很多,这本书有什么不同?
第一,它是中文的。 我知道这听起来有点奇怪——但事实是,AI Agent 领域最好的资料大多是英文的。官方文档是英文的,GitHub 上的讨论是英文的,Discord 里的交流也是英文的。对于英文不好的朋友来说,这无疑是一道巨大的门槛。本书全程使用中文写作,所有的命令、配置和界面截图(如果有的话)都会配合中文解释。
第二,它是实战导向的。 我不会只讲理论。每一章都有动手环节,每一个概念都有对应的操作步骤。读完第一章,你就能说出 Hermes 是什么;读完第五章,你就能在自己的电脑上跑起来一个 Hermes Agent;读完第十二章,你就能让它自动完成真正的工作任务。
第三,它覆盖了从入门到精通的完整路径。 全书 16 册,从"什么是 AI Agent"这种基础问题,到"如何设计一个企业级多 Agent 系统"这种高阶话题,全部覆盖。你不需要再去其他地方找资料——这本书就是一本"全栈"指南。
第四,它关注"为什么",而不仅是"怎么做"。 知其然,更要知其所以然。我不会只告诉你"配置文件里这个参数要填 true",我会解释"为什么填 true 会更好"。理解了设计背后的逻辑,你才能真正灵活运用,而不是机械地照搬。
第五,它持续更新。 AI Agent 领域变化太快了,一本写死在纸上的书很快就会过时。本书采用数字出版形式,会随着 Hermes 的版本迭代持续更新。你手中的永远是最新的内容。
2. Hermes Agent 是什么——一句话说清楚
2.1 用最通俗的语言解释 Hermes Agent
好,现在让我们来解决一个根本问题:Hermes Agent 到底是什么?
如果你让我用一句话回答,我会说:
Hermes Agent 是一个生活在你的电脑里的、会学习、会进化的 AI 助手。它能理解你的需求,自己想办法完成任务,并且越用越懂你。
让我再展开一点。
想象你有一个私人助理。这个助理非常聪明,会写文章、会查资料、会写代码、会发邮件。但不仅如此,他还有以下几个特点:
- 他有超强的记忆力。你三年前随口提过的一个偏好,他现在还记得。你们上个月的某次对话,他能准确回忆起来。
- 他会自己学新技能。你从来没教过他怎么操作 Excel 宏,但他看你做了几次之后,自己就学会了。下次你需要的时候,他直接就能上手。
- 他会主动思考。你让他"关注一下竞争对手的动向",他不会傻等你的下一步指令,而是自己去搜索、分析、总结,然后把一份报告放到你桌上。
- 他会不断进化。刚来的时候他还比较"青涩",但跟着你工作了几个月之后,他对你的行业、你的工作习惯、你的说话方式都越来越熟悉,做事越来越得心应手。
Hermes Agent,就是这样一个"数字版"的私人助理。
但比私人助理更强大的是,它:
- 不需要工资,只需要你的电脑或服务器能跑起来
- 不需要睡觉,可以 7×24 小时工作
- 不会跳槽,你的数据和记忆永远属于你
- 可以复制,你可以训练好一个 Agent,然后复制给团队里的其他人用
Tips
很多新手容易把 Agent 想象成一个"更聪明的 ChatGPT"。这个理解不够准确。ChatGPT 是一个"对话系统"——你问一句,它答一句。而 Agent 是一个"行动系统"——你给它一个目标,它自己规划步骤、调用工具、执行任务,最后把结果交给你。ChatGPT 是"你推一下它动一下",Agent 是"你给方向它自己跑"。
2.2 它和 ChatGPT、Claude 等产品的区别
为了让你更清楚地理解 Hermes 的定位,我们来做个横向对比。
| 特性 | ChatGPT / Claude | Hermes Agent |
|---|---|---|
| 运行位置 | 云端(OpenAI/Anthropic 的服务器) | 你的本地电脑或私有服务器 |
| 交互方式 | 一问一答的对话 | 目标驱动的任务执行 |
| 记忆能力 | 有限上下文(通常几轮对话) | 三层记忆系统,跨会话持久化 |
| 工具使用 | 内置工具(联网、代码解释器等) | 47+ 内置工具 + 6000+ MCP 服务 |
| 学习进化 | 模型本身不学习,靠更新迭代 | 运行时自学习,技能自我进化 |
| 数据隐私 | 数据上传到云端 | 数据完全本地保留 |
| 定制化程度 | 有限(提示词、自定义 GPT) | 极高(技能、记忆、工具全可定制) |
| 成本 | 按调用付费(订阅制) | 本地运行免费,API 调用按需付费 |
这个表格的信息量很大,让我挑几个关键点来解释。
关于运行位置:ChatGPT 和 Claude 是"云服务"。你每说一句话,数据都要发到 OpenAI 或 Anthropic 的服务器上处理。这意味着你的对话内容理论上可以被服务商看到(虽然他们承诺不用于训练,但你很难完全验证)。Hermes 是"本地服务",所有的数据都在你自己的机器上处理。对于处理敏感信息(比如公司内部的商业数据、个人隐私信息)来说,这是一个巨大的优势。
关于交互方式:ChatGPT 是"你问我答"。你说"帮我写个邮件",它给你写一封邮件。你说"再改得正式一点",它再改。你需要一步一步引导它。Hermes 是"你给目标,它自己想办法"。你说"帮我给张总发一封感谢邮件,感谢他在上周会议中的建议,顺便提一下我们下周的方案",Hermes 会自动完成:写邮件、检查语气、调用邮件发送工具——整个过程你不需要干预。
关于学习进化:这是最核心的区别。ChatGPT 不会因为你经常用它就变得更懂你。它"懂"什么,完全取决于 OpenAI 训练了什么、更新了什么。而 Hermes 有一个自学习闭环:你每次跟它交互,它都会分析这次交互,提取有价值的经验,存到记忆里。下次遇到类似情况,它会基于这些经验做出更好的决策。这就是"越用越聪明"的真正含义。
注意
这并不意味着 Hermes 比 ChatGPT "更好"。它们是为不同场景设计的工具。如果你只是偶尔问几个问题、聊聊天,ChatGPT 可能更方便(不需要安装、随时随地可用)。但如果你是每天都要跟 AI 协作完成大量任务的重度用户,或者你需要处理敏感数据,Hermes 的本地化和自主性就是无可替代的优势。
2.3 它和 AutoGPT、MetaGPT 等框架的区别
Hermes 属于"AI Agent 框架"这个大家族。在这个家族里,还有很多知名的成员:AutoGPT、BabyAGI、MetaGPT、CrewAI、AutoGen、LangGraph 等等。Hermes 和它们有什么不同?
AutoGPT:这是 Agent 领域的"开山鼻祖"之一。它的核心思想是给 AI 一个目标,然后让 AI 自己分解任务、执行、反思、再执行,循环往复直到完成。AutoGPT 开创了很多 Agent 设计的先河,但它的问题也很明显:容易陷入"思考循环"(反复思考但不动手)、任务分解质量不稳定、缺乏有效的记忆管理机制。
MetaGPT:这个框架的灵感来自软件公司的组织架构。它模拟了一个完整的软件开发团队——产品经理写 PRD、架构师设计系统、工程师写代码、测试员测 Bug。多个 AI 角色协作完成一个复杂任务。这个想法很酷,但它主要面向软件开发场景,对于非开发任务(比如投研、内容创作、客服)的适配性有限。
CrewAI:这是一个更轻量级的多 Agent 框架。你可以快速组建一个"团队",给每个成员分配角色和任务。它的优点是简单上手快,缺点是功能相对基础,缺乏深度定制和自学习能力。
LangGraph:这是 LangChain 团队推出的 Agent 编排框架。它用"图"的方式来设计 Agent 的工作流程,非常适合构建复杂、确定性的业务流程。它的学习曲线比较陡峭,更适合有 LangChain 经验的开发者。
OpenClaw:这是 Hermes 的"前辈",也是 Nous Research 团队之前的作品。OpenClaw 在 2025 年达到了 309k Stars 的惊人成绩,是 GitHub 上最受欢迎的 Agent 项目之一。但它在架构上存在一些局限性——尤其是在记忆管理和技能进化方面——这些局限性促使了 Hermes 的诞生。
Hermes Agent:Hermes 继承了 OpenClaw 的优秀基因,但进行了全面的架构升级。它的核心优势在于:
- 三层记忆系统:短期记忆(会话上下文)+ 持久记忆(SQLite 全文检索)+ Skill 级记忆(跨会话知识沉淀)。这让 Hermes 拥有了真正的"长期记忆"能力。
- 自主技能创建:Hermes 不仅能执行预定义的技能,还能在运行过程中自动创建新技能,并让这些技能自我进化。
- 按需检索:不是把所有记忆都塞进上下文,而是根据当前任务的需求,智能地从记忆库中检索相关信息。
- 用户建模:Hermes 会为每个用户建立独立的画像模型,记录你的偏好、习惯、工作模式,从而实现真正的"个性化"。
常见问题
Q:这些框架我能同时用吗?还是只能选一个?
A: 实际上,它们并不是完全互斥的。比如,你可以在 Hermes 中集成 LangGraph 来做流程编排,也可以用 CrewAI 的多 Agent 协作模式来扩展 Hermes 的能力。但在入门阶段,我建议你先专注学好一个框架。Hermes 的功能已经非常全面了,足以覆盖绝大多数场景。
2.4 核心概念:会自我学习、自我进化的本地 AI 助手
让我们把 Hermes 的核心特点再浓缩一下,归纳为四个关键词:
本地(Local)
Hermes 运行在你的机器上。你的对话记录、生成的文件、积累的记忆,全部存储在你的本地磁盘上。你不需要担心数据被上传到云端,不需要担心服务商的政策变化影响你的使用,不需要担心网络波动导致服务中断。
对于有数据隐私要求的企业来说,这是刚需。对于个人用户来说,这也意味着你对系统有完全的控制权。
自主(Autonomous)
传统的 AI 工具是"被动"的——你让它做什么,它才做什么。Hermes 是"主动"的——你给出一个目标,它会自己规划步骤、调用工具、处理异常、调整策略,直到目标达成。
比如,你说"帮我准备明天跟李总的会议",Hermes 会自动: - 从你的日历里找到明天跟李总的会议安排 - 检索你和李总的历史往来记录 - 查找李总所在公司的最新动态 - 整理你们上次会议的待办事项 - 生成一份会议准备清单和谈话要点 - 把这些内容整理成一份文档发给你
整个过程,你只需要说一句话。
学习(Learning)
Hermes 有一个核心的自学习闭环。每次交互结束后,系统会分析: - 这次任务完成得怎么样? - 用户的反馈是什么?(满意/不满意/需要修改) - 有哪些经验可以沉淀下来? - 有没有新的模式需要记录?
这些分析结果会被存入记忆系统,成为 Hermes 的"经验"。下次遇到类似情况,它会基于这些经验做出更好的决策。
进化(Evolution)
学习是"积累知识",进化是"升级能力"。Hermes 的技能系统支持自我进化: - 它能根据你的使用模式,自动创建新的技能 - 它能分析技能的使用效果,自动优化技能的实现 - 它能从社区共享的技能库中学习,吸收最佳实践
这就好比你的助理不仅记住了你教他的东西,还能自己琢磨出更高效的工作方法,并且跟同行交流取长补短。
Tips
"自学习"和"自我进化"是 Hermes 最独特的能力,但也是新手最容易误解的概念。它不是说 Hermes 会变得像人类一样"聪明",而是说它会变得越来越"适合你"。它不会突然学会你从来没提过的东西,但它会把跟你交互过程中积累的经验,转化成更高效、更精准的服务。
3. 为什么选择 Hermes 而不是其他框架
3.1 2026 年 AI Agent 市场格局概览
在做出选择之前,我们需要先看清整个市场的全貌。
2026 年的 AI Agent 市场,可以用"百花齐放、群雄并起"来形容。大致可以分为几个阵营:
第一阵营:科技巨头的闭源产品
OpenAI 的 GPT-4o with Tools、Anthropic 的 Claude with Computer Use、Google 的 Gemini Agents、Microsoft 的 Copilot Agents。这些产品的特点是:技术能力强、集成度高、生态丰富。但它们的缺点也同样明显:闭源(你无法知道内部怎么工作)、数据上云(隐私风险)、按量付费(成本不可控)、定制受限(只能按照厂商的设计使用)。
第二阵营:开源框架
这是开发者和极客的主战场。从早期的 AutoGPT、BabyAGI,到中期的 LangChain、LlamaIndex,再到近两年的 OpenClaw、Hermes、CrewAI、AutoGen、LangGraph 等,开源框架的数量和质量都在快速提升。2026 年,GitHub 上 Agent 相关的仓库数量已经超过了 50,000 个,Star 数超过 10k 的项目有 30 多个。
第三阵营:垂直领域方案
一些公司专注于特定领域的 Agent 解决方案。比如,有的专门做投研 Agent,有的专门做客服 Agent,有的专门做内容创作 Agent。这些方案在特定场景下做得很好,但通用性不足。
第四阵营:低代码/无代码平台
面向非技术用户的可视化搭建平台。用户通过拖拽组件、配置规则来构建简单的 Agent 工作流。门槛低,但灵活性和能力上限也低。
在这个格局中,Hermes 位于第二阵营——开源框架——的领先位置。
注意
2026 年 4 月,Hermes Agent 在 GitHub 上的 Star 数已经达到了 97.8k,而它正式发布才两个月。这个增长速度在整个 AI 开源领域都是非常罕见的。相比之下,OpenClaw 用了约一年时间才达到类似的 Star 数。这说明了社区对 Hermes 的期待和认可。
3.2 Hermes 的五大核心优势
为什么 Hermes 能在这么短的时间内获得如此高的关注?我总结了五个核心优势。
优势一:记忆自动归档
记忆是 Agent 智能化的根基。如果一个 Agent 每次跟你对话都像是"第一次见你",那它跟 ChatGPT 有什么区别?
Hermes 的三层记忆系统解决了这个问题:
第一层:会话记忆(短期上下文)
就像人类的短期记忆一样,记录当前对话的上下文。你前面说了什么,Agent 后面还能记得。这一层确保了对话的连贯性。
第二层:持久记忆(长期知识库)
利用 SQLite 数据库配合 FTS5 全文检索引擎,Hermes 可以把所有重要的信息长期保存下来。你上个月提到的一个项目细节,今天问起来它还能准确回答。
第三层:Skill 级记忆(跨会话知识沉淀)
这是 Hermes 的独创。当你在多个会话中反复处理某类任务时,Hermes 会自动提炼出"通用模式",形成 Skill 级别的记忆。这些记忆不仅服务于当前会话,还会被用于优化技能本身。
类比
想象你有一个笔记本。第一层记忆像是你在谈话时随手记的便签——随时能看到,但空间有限。第二层记忆像是你的日记本——把重要的事情详细记录下来,需要的时候可以翻阅。第三层记忆像是你的"工作方法论"——你做了 100 个项目后总结出来的最佳实践,变成了你的"肌肉记忆"。
优势二:自主创建 Skill
传统 Agent 框架的技能系统是"静态"的——开发者写好技能代码,用户拿来用。如果用户需要一个框架里没有的技能,就得等开发者更新,或者自己写代码。
Hermes 打破了这种模式。它具备自动技能创建的能力:
当你反复执行一类任务时,Hermes 会识别出这个模式。比如,你每周都要"收集竞品动态、整理成周报、发送给团队"。做了几周之后,Hermes 会主动问你:"我发现你每周都在做类似的任务,是否需要我创建一个自动化的技能?"
如果你同意,Hermes 会自动: 1. 分析这个任务的步骤和依赖 2. 生成对应的 Skill 代码 3. 注册到技能库中 4. 下次你需要的时候,一键执行
更厉害的是,这个 Skill 不是一成不变的。随着你使用的次数增多,Hermes 会不断优化它——简化步骤、修正错误、增加新的功能。
Tips
自动创建 Skill 的功能默认是开启的,但你可以在配置中关闭它,或者设置触发阈值(比如"至少重复 3 次才提示创建")。对于喜欢手动控制一切的高级用户,这些选项给你了充分的自由度。
优势三:技能自我进化
不仅新技能可以自动创建,现有的技能也会自我进化。
Hermes 有一个内置的技能评估和优化循环:
- 执行监控:每次技能执行时,系统会记录执行时间、成功率、用户反馈等指标。
- 效果分析:定期(默认每周)分析技能的使用数据,找出效率瓶颈和常见失败点。
- 自动优化:基于分析结果,尝试改进技能的实现。比如,把串行执行的步骤改为并行,或者增加错误处理的逻辑。
- A/B 测试:新版本的技能不会直接替换旧版本,而是先在小部分场景中试用,确认效果更好后才全面推广。
- 用户确认:对于重大变更,Hermes 会征求你的同意。对于细微优化,它可以自动应用。
这个过程就像是你的助理不仅在做事情,还在"琢磨怎么把事情做得更好"。
常见问题
Q:技能自我进化会不会把我的技能改坏?
A: 不会。Hermes 采用了多重保护机制。首先,所有优化都会先创建新版本,原版本会被保留。其次,新版本会经过 A/B 测试验证。第三,你可以随时回滚到旧版本。第四,你可以设置某些技能为"锁定"状态,禁止自动优化。安全性是设计的第一优先级。
优势四:按需检索
大语言模型有一个固有的限制:上下文窗口有限。即使是最先进的模型,也只能同时处理几十万字的上下文。如果 Agent 把所有历史记忆都塞进上下文,很快就会爆表。
Hermes 的解决方案是按需检索(Retrieval on Demand):
当接收到一个新任务时,Hermes 会先进行"需求分析":这个任务需要什么知识?需要哪些历史背景?需要调用什么技能?然后,它只去检索相关的记忆片段,把不相关的信息过滤掉。
这就好比一个优秀的律师在接案子时,不会把律所所有的卷宗都翻一遍,而是根据案情快速定位到相关的判例和法规。
按需检索的核心技术是语义检索 + 关键词检索的混合方案:
- 语义检索:利用向量嵌入技术,找到"意思相近"的内容。比如,你问"上次谈的那个合作",即使你没有用"合作"这个词,系统也能根据语义理解找到相关内容。
- 关键词检索:利用 FTS5 全文检索,快速定位包含特定关键词的内容。
- 混合排序:把两种检索的结果合并,按相关度排序,选出最相关的片段送入上下文。
类比
想象你的记忆是一座巨大的图书馆。传统的 Agent 每次借书都是把整本书搬走(把所有记忆塞进上下文)。Hermes 的做法是,先由一个聪明的图书管理员(检索系统)分析你需要什么,然后只把相关的那几页复印给你。这样效率更高,而且不会超重。
优势五:用户建模
这是 Hermes 最具前瞻性的设计之一。
每个用户都是独特的。你的说话方式、工作习惯、知识背景、审美偏好,都和别人不一样。一个真正智能的 Agent,应该能"认识"你,并且根据你的特点来调整自己的行为。
Hermes 的用户建模系统会为你建立一个多维度的画像:
基础画像:你的角色(开发者/产品经理/投研人员等)、技术栈偏好、常用工具、工作时间规律等。
交互偏好:你喜欢简洁的回答还是详细的解释?你喜欢代码示例还是文字描述?你喜欢直接给答案还是引导你自己思考?
知识图谱:你熟悉哪些领域?在哪些领域你是新手?你经常提及的人物、公司、概念之间的关系是什么?
任务模式:你经常做什么类型的事情?你的任务有什么规律?(比如"每周一上午看周报"、"每天下午 3 点查数据")
反馈历史:你对 Agent 的哪些回答满意?哪些不满意?你的修改习惯是什么?
基于这个画像,Hermes 会动态调整它的行为: - 给开发者的回答会包含更多技术细节和代码示例 - 给产品经理的回答会更多关注用户场景和业务价值 - 如果你是个急性子,它会优先给出结论,细节放在后面 - 如果你是个谨慎的人,它会给出更多选项和权衡分析
Tips
用户建模是完全本地化的,你的画像数据只存储在你自己的机器上。Hermes 承诺不会上传任何用户画像数据到第三方服务器。这也是选择本地 Agent 的重要理由之一。
3.3 和 OpenClaw 的定位差异
既然 Hermes 是从 OpenClaw 演进而来的,那它们之间到底是什么关系?你应该选哪个?
简单来说:OpenClaw 是"探索者",Hermes 是"定居者"。
OpenClaw 在 2025 年横空出世,带着实验性和探索性的基因。它的目标是"证明 AI Agent 可以做什么"。它设计了很多酷炫的功能,但部分功能在稳定性和实用性上还有提升空间。它的架构相对灵活(也可以说是"松散"),社区贡献的技能质量参差不齐。
Hermes 则是站在 OpenClaw 的肩膀上,进行了一次彻底的架构升级。它的目标是"让 AI Agent 真正可用、好用、耐用"。它在以下方面做了重大改进:
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 记忆系统 | 基于文件的简单存储 | 三层记忆系统,支持全文检索和语义检索 |
| 技能系统 | 静态技能,手动编写 | 自动创建 + 自我进化 |
| 学习机制 | 有限的反馈学习 | 完整的自学习闭环 |
| 用户建模 | 无 | 多维度用户画像 |
| 架构设计 | 模块化但耦合度较高 | 五层松耦合架构,清晰的分层边界 |
| 性能优化 | 基础 | 异步执行、并发处理、缓存机制 |
| 工具生态 | 约 30 个内置工具 | 47+ 内置工具 + MCP 生态 |
注意
详细的对比分析将在第十三册「OpenClaw 对比与迁移」中展开。这里只是给你一个初步印象。如果你已经是 OpenClaw 用户,不需要担心——迁移到 Hermes 的过程比你想象的简单得多,而且大部分技能都可以兼容。
3.4 适合什么样的人
说了那么多,你可能还在想:"Hermes 到底适不适合我?"
让我给你一个直截了当的答案。
Hermes 特别适合以下人群:
第一类:每天需要跟 AI 协作的重度用户
如果你每天要花 2 小时以上跟 AI 打交道——写代码、查资料、写文档、做分析——那么 Hermes 的自学习和个性化能力会给你带来巨大的效率提升。使用一个月后,你会发现它越来越"懂"你,很多任务只需要说几个字就能完成。
第二类:对数据隐私有高要求的用户
如果你处理的是商业机密、个人隐私、法律文件等敏感信息,Hermes 的本地化部署是刚需。你的数据永远不会离开你的机器,这在合规性和安全性上是无可替代的优势。
第三类:希望打造个性化 AI 助手的极客
如果你喜欢折腾技术,喜欢定制和扩展,Hermes 的技能系统和开源架构会给你很大的发挥空间。你可以写自己的技能、接入自己的工具、甚至修改核心代码。
第四类:希望用 AI 创业的开发者
Hermes 的灵活性和可扩展性,使它成为构建 AI 产品的优秀底座。无论是做 SaaS 服务、做企业解决方案,还是做垂直领域的 Agent 应用,Hermes 都能提供坚实的技术基础。
第五类:从 OpenClaw 迁移的用户
如果你对 OpenClaw 感到满意,但希望获得更好的记忆管理、更智能的技能系统和更稳定的性能,Hermes 是最好的选择。迁移成本低,收益明显。
Hermes 可能不太适合:
- 偶尔用一下 AI 的轻度用户:如果你只是偶尔问几个问题,ChatGPT 或 Claude 的网页版可能更方便。
- 完全不想折腾的"纯小白":虽然本书会尽量做到保姆级,但 Hermes 毕竟需要安装和配置,比打开一个网页要复杂一些。不过,如果你愿意花 1-2 小时跟着本书操作,这个门槛完全可以跨越。
- 追求"开箱即用"极致体验的用户:Hermes 的哲学是"给你控制权",而不是"替你做好一切决定"。如果你喜欢"什么都不用管,厂商全部包办"的体验,闭源的云端服务可能更适合你。
Tips
如果你还在犹豫,我的建议是:先试试看。按照本书第五册的安装指南,花 30 分钟把 Hermes 跑起来,然后实际体验一下。很多时候,"用起来"的感觉比"听起来"的判断要准确得多。而且,本地部署不花一分钱(除了 API 调用的费用,但如果你接本地模型,这个费用也是零),试试没有损失。
4. 本书内容架构与阅读建议
4.1 全书 16 册概览
本书共 16 个分册,覆盖了 Hermes Agent 从入门到精通的所有核心主题。以下是每册的内容简介:
第一册:前言与概述(你正在读的这本)
介绍白皮书的写作背景、Hermes 的核心概念、为什么选择 Hermes、全书架构和学习建议。
第二册:AI-Agent 行业全景
从 2022 年到 2026 年的 AI Agent 发展简史、主流框架对比、大模型底座选择、MCP 协议解析、商业化趋势分析。
第三册:Hermes 诞生与演进
Nous Research 团队背景、OpenClaw 的辉煌与局限、从 OpenClaw 到 Hermes 的演进历程和关键决策。
第四册:核心架构深度解析
Hermes 的五层架构(接入层、推理层、记忆层、技能层、工具层)逐层详解、自学习闭环的设计哲学。
第五册:安装部署全攻略
本地部署(macOS/Linux/Windows)、Docker 部署、VPS 云服务器部署的完整步骤、环境配置和故障排查。
第六册:基础使用入门
首次运行 Hermes 的完整流程、对话模式详解、常用命令速查手册、主流大模型的接入配置。
第七册:三层记忆系统详解
会话记忆、持久记忆、Skill 级记忆的工作原理、配置方法和最佳实践。
第八册:技能系统完全指南
技能的定义与生命周期、自动技能创建机制、Skills Hub 生态的使用与贡献、跨平台技能复用。
第九册:47 个内置工具全解
七大类别(Web 与搜索、文件与数据、代码与开发、系统与运维、通信与消息、媒体与内容、金融与分析)的逐一详解。
第十册:多平台接入实战
飞书、企业微信、微信、Telegram、Discord、Slack、钉钉等 15+ 平台的接入方法。
第十一册:MCP 协议与自动化
MCP 协议的核心概念、如何接入 6000+ MCP 服务、Cron 定时任务配置、多 Agent 编排与协作。
第十二册:高阶玩法与实战案例
沙箱环境、语音交互、投研自动化流水线、企业级应用场景的完整案例。
第十三册:OpenClaw 对比与迁移
12 个维度的深度对比、从 OpenClaw 迁移到 Hermes 的完整教程、不同场景下的选型建议。
第十四册:九大变现路径
九条经过验证的变现路径的详细拆解、真实案例和收入预估。
第十五册:社区生态与资源
官方资源导航、活跃的社区项目与第三方扩展推荐、系统学习路径规划、FAQ 汇总。
第十六册:未来展望与总结
2026-2027 年发展趋势预判、Hermes 的公开路线图解读、对开源社区和个体开发者的建议、全书总结。
类比
如果把学 Hermes 比作学开车,这 16 册的编排是这样的:第一册是"为什么要学车";第二册是"了解一下汽车行业的历史";第三册是"你的车是什么品牌、有什么特点";第四册是"汽车的构造原理";第五册是"拿到车钥匙、学会打火起步";第六册是"在空旷场地练习基本操作";第七到九册是"熟悉各种功能和配置";第十到十二册是"上路实战、高速行驶、复杂路况";第十三册是"如果你之前开的是另一款车,怎么换过来";第十四册是"学会开车后能做什么赚钱";第十五册是"车友会和维修站地址";第十六册是"自动驾驶的未来展望"。
4.2 不同读者推荐的阅读路线
在 00-目录与导读 中,我设计了四条推荐阅读路线。这里再针对 01 册的读者做一个更详细的说明。
路线一:快速入门路线(预计 3-4 小时)
适合:AI Agent 小白、时间紧张的初学者
顺序:第一册 → 第三册 → 第五册 → 第六册 → 第十二册(选读)
核心理念:"先跑起来,再慢慢理解"。不要纠结于每个参数的含义,先让 Agent 动起来,看到它自动完成任务的效果。这种"成就感"是坚持学习的最好动力。
路线二:深度技术路线(预计 15-20 小时)
适合:开发者、技术架构师
顺序:第一册 → 第二册 → 第三册 → 第四册 → 第七册 → 第八册 → 第九册 → 第十一册 → 第十三册
核心理念:"理解原理,才能灵活运用"。这条路线会带你深入到 Hermes 的每一层架构,理解每个设计决策背后的原因。完成这条路线后,你将具备独立开发和扩展 Hermes 的能力。
路线三:变现赚钱路线(预计 8-10 小时)
适合:创业者、独立开发者
顺序:第一册 → 第二册 → 第五册 → 第十册 → 第十二册 → 第十四册 → 第十五册 → 第十六册
核心理念:"从需求出发,用技术落地"。重点是理解商业机会、掌握部署技能、获取实战灵感、学习变现路径。
路线四:从 OpenClaw 迁移路线(预计 6-8 小时)
适合:现有 OpenClaw 用户
顺序:第一册 → 第三册 → 第四册 → 第六册 → 第七册 → 第八册 → 第十三册 → 第十五册
核心理念:"平滑迁移,无缝衔接"。理解演进逻辑、对比架构差异、熟悉新操作方式、掌握迁移方法。
Tips
这四条路线不是互斥的。你可以先走快速入门路线,把系统跑起来,然后再根据需要选择其他路线深入学习。学习是一个螺旋上升的过程,不需要一次把所有东西都学会。
4.3 学习方法建议:边学边练、先跑通再深入
基于我带过几百个学员的经验,我总结了三个最有效的学习方法。
方法一:边学边练,不要只看不练
技术类知识有一个特点:"看懂"和"会做"之间有一道鸿沟。你看懂了安装步骤,不代表你能一次安装成功。你看懂了配置说明,不代表你能配出最适合自己的方案。
所以,我强烈建议:每读完一册,至少动手实践一次。如果你读的是第五册(安装部署),那就真的去安装一遍。如果你读的是第六册(基础使用),那就真的去跟 Agent 对话几次。实践过程中遇到的问题,往往是最有价值的学习机会。
注意
动手实践时,一定要做好记录。用一个文档或者笔记本,记录你执行的每一步命令、遇到的每一个错误、解决的每一个问题。这些记录不仅是你自己的"错题本",将来也可以分享给其他遇到同样问题的人。
方法二:先跑通,再深入
很多技术学习者有一个共同的毛病:追求完美。他们希望在"完全理解"之后再动手,结果永远停留在"准备阶段"。
我的建议是:先让系统跑起来,不管它是不是"最优配置""。
用默认配置先把 Hermes 跑通,看到它能工作,建立信心。然后再逐步调整参数、优化配置、深入理解原理。"跑通"带来的成就感,会推动你继续学习下去。
方法三:建立自己的知识网络
不要把每一册当作孤立的知识点。Hermes 的 16 册内容是一张知识网络,册与册之间有很多关联。
比如,你学第五册(安装部署)时,会用到第四册(架构解析)中提到的某些概念。你学第八册(技能系统)时,会用到第七册(记忆系统)中讲到的持久化机制。你学第十四册(变现路径)时,会用到第二册(行业全景)中分析的市场趋势。
我建议你在学习过程中,画一张自己的"知识地图"——每学到一个新概念,就想想它跟之前学过的什么内容有关联。这种主动构建联系的学习方式,比被动阅读的效果要好得多。
Tips
加入社区是学习的重要一环。Hermes 的中文社区虽然还在发展中,但已经有很多热心的用户在分享经验。遇到问题不要独自纠结,去社区里问一问,往往能得到更快的解答。第十五册会详细介绍社区资源的获取方式。
5. 开源社区与学习资源前瞻
5.1 官方资源快速导航
在学习 Hermes 的过程中,以下官方资源是你最可靠的参考:
GitHub 仓库
Hermes 的主仓库地址是 github.com/nousresearch/hermes。这里是获取最新代码、提交 Issue、参与讨论的主要平台。
# 克隆主仓库到本地
git clone https://github.com/nousresearch/hermes.git
# 进入项目目录
cd hermes
# 查看当前分支和最新提交
git log --oneline -5
Tips
Star 这个仓库(点击右上角的 Star 按钮),这样你可以在自己的 GitHub 主页快速找到它。同时,点击 Watch 按钮选择 "Releases only",这样每次有新版本发布时你会收到通知。
官方文档
官方文档托管在 docs.hermesagent.io(地址可能会随项目发展调整,以 GitHub README 中的最新链接为准)。文档包含了 API 参考、配置说明、开发指南等内容。
Discord 社区
Hermes 的官方 Discord 服务器是最活跃的实时交流平台。你可以在里面: - 向开发团队直接提问 - 跟全球的 Hermes 用户交流经验 - 获取最新版本的第一手信息 - 找到志同道合的合作伙伴
加入方式:在 GitHub README 中找到 Discord 邀请链接。
注意
Discord 是一个英文为主的社区。如果你的英文不太流利,可以使用翻译工具辅助阅读。同时,中文用户正在建立自己的社区(见下文),你也可以优先加入中文社区。
Release 页面
GitHub 的 Release 页面是获取稳定版本的最佳途径。每个 Release 都附带了更新日志、安装包和升级指南。
# 查看 GitHub 上最新的 Release 信息
# 访问:https://github.com/nousresearch/hermes/releases
# 或者用命令行获取最新 tag
curl -s https://api.github.com/repos/nousresearch/hermes/releases/latest | grep tag_name
5.2 中文社区现状
作为一个中文写作者,我特别关注中文社区的发展。以下是 2026 年 4 月的现状:
微信群
目前已有多个 Hermes 相关的微信群,按主题分为: - 新手互助群:面向刚入门的小白,氛围友好,问题再基础也有人解答 - 开发者交流群:面向有技术背景的用户,讨论深入的技术话题 - 变现交流群:面向创业者,分享商业机会和实战经验
加入方式:关注"鲲鹏Talk"的微信公众号,回复"Hermes"获取入群二维码。
Tips
微信群有 500 人上限,如果群满了,会定期开新群。如果二维码过期,请重新在公众号获取最新的。
中文论坛/知识星球
部分社区成员在搭建中文的知识库和论坛,用于沉淀高质量的内容。相比于微信群的消息流,论坛更适合保存和检索知识。
B站/YouTube 视频教程
"鲲鹏Talk"在 B站和 YouTube 上持续更新 Hermes 的实战视频教程。这些视频与本书内容互补——书讲系统性知识,视频讲具体操作演示。
小红书/抖音
短平快的内容分享,适合获取灵感和了解最新动态。不适合系统学习,但适合了解"别人在用 Hermes 做什么"。
类比
如果把学习资源比作餐饮,官方文档是"营养餐"——权威、全面,但可能有点枯燥;视频教程是"家常菜"——容易入口,适合日常学习;社区讨论是"大排档"——热闹、接地气,能遇到各种意想不到的问题和解决方案;而这本书是"满汉全席"——系统、完整,虽然不能一顿吃完,但值得你慢慢品尝。
5.3 如何参与贡献
开源项目的生命力来自于社区贡献。无论你是什么背景,都可以为 Hermes 生态做出贡献。
方式一:提交 Bug 报告
如果你在使用过程中遇到了问题,可以在 GitHub 上提交 Issue。一个好的 Bug 报告应该包含:
## 问题描述
简明扼要地描述你遇到的问题
## 复现步骤
1. 执行了 xxx 命令
2. 输入了 xxx 内容
3. 出现了 xxx 错误
## 期望行为
正常情况下应该发生什么
## 实际行为
实际上发生了什么(附上错误日志)
## 环境信息
- 操作系统:macOS 15.4 / Ubuntu 22.04 / Windows 11
- Hermes 版本:v1.2.3
- Python 版本:3.11
- 使用的大模型:GPT-4o / Claude 3.5 / DeepSeek-V3
方式二:贡献技能(Skill)
Hermes 的技能系统是开放扩展的。如果你写了一个好用的技能,可以提交到 Skills Hub,让全世界的用户使用。
方式三:改进文档
文档是开源项目中最容易被忽视但也最重要的部分。如果你发现文档有错误、有遗漏、或者表述不清楚,可以提交 PR(Pull Request)来改进它。
方式四:翻译
帮助把官方文档翻译成中文,让更多中文用户能够方便地使用 Hermes。
方式五:社区运营
在中文社区中回答问题、组织线上活动、撰写教程文章,都是非常有价值的贡献。
Tips
第一次参与开源项目可能会感到紧张,担心自己"水平不够"。请放心,开源社区欢迎所有善意的贡献。一个 typo 的修正、一句文档的澄清,都是宝贵的贡献。重要的是参与,而不是完美。
6. 术语表与约定
6.1 本书常用术语解释
为了让你在阅读后续章节时不被术语困扰,这里提前解释本书中会频繁出现的核心概念。
Agent(智能体)
能够感知环境、做出决策、执行行动并从中学习的 AI 系统。你可以把它理解为"有自主行动能力的 AI"。
LLM(大语言模型)
Large Language Model 的缩写。指那些参数量巨大、能理解和生成自然语言的 AI 模型,如 GPT-4、Claude、DeepSeek 等。你可以把它理解为 Agent 的"大脑"。
Skill(技能)
Agent 能执行的具体任务模块。比如"发送邮件"是一个技能,"搜索网页"是另一个技能。Skill 可以被创建、存储、调用和进化。类比一下:Skill 就像是助理掌握的"手艺"——有的助理会写代码,有的会写文案,有的会做表格。
Memory(记忆)
Agent 存储和检索信息的能力。Hermes 有三层记忆系统,让 Agent 能"记住"过去的事情。类比:Memory 就是助理的笔记本和大脑。
MCP(Model Context Protocol)
模型上下文协议。这是一个开放标准,用于统一 AI 模型与外部工具/服务之间的通信方式。类比:MCP 就像是 Agent 世界的 "USB-C" 接口——一个标准,连接万物。
Gateway(网关)
Hermes 中负责接入不同平台和协议的模块。比如微信 Gateway、飞书 Gateway、Telegram Gateway 等。类比:Gateway 就像是助理的"前台"——不同的人(平台)通过前台找到助理。
Honcho
Nous Research 团队开发的一个用户身份管理和会话隔离系统。在 Hermes 中用于区分不同用户、管理用户权限和隔离会话数据。类比:Honcho 就像是助理公司的"HR 系统"——管理客户信息、分配权限、确保保密性。
RAG(检索增强生成)
Retrieval-Augmented Generation 的缩写。一种让 AI 在生成回答之前先从知识库中检索相关信息的技术。类比:RAG 就像是助理在回答你之前,先去档案室查资料,确保回答准确。
Prompt(提示词)
你给 AI 的输入文本。好的 Prompt 能让 AI 给出更准确的回答。类比:Prompt 就是你给助理的"任务说明"。说明越清楚,助理执行得越好。
Context Window(上下文窗口)
LLM 一次能处理的最大文本长度。超出这个长度的信息会被截断或遗忘。类比:上下文窗口就是助理的"短期记忆容量"——能同时记住多少事情。
Embedding(嵌入/向量)
将文本转换成数字向量的技术。语义相似的文本,其向量在数学上也很接近。这是实现语义检索的基础。类比:Embedding 就像是给每句话生成一个"指纹"——意思相近的话,指纹也相似。
FTS5
SQLite 数据库的一个全文检索扩展。Hermes 用它来快速搜索持久记忆中的文本内容。类比:FTS5 就是档案室的"检索系统"——让你能快速找到需要的文件。
Tool(工具)
Agent 可以调用的外部功能。比如搜索工具、文件读写工具、邮件发送工具等。Hermes 内置了 47 个工具,还可以通过 MCP 接入更多。类比:Tool 就是助理能使用的"办公设备"——电话、电脑、打印机等等。
Cron(定时任务)
Linux/Unix 系统中用于定时执行任务的工具。在 Hermes 中用来设置自动化流程,比如"每天早上 8 点给我发日报"。类比:Cron 就是助理的"闹钟和日程表"。
Sandbox(沙箱)
一个隔离的执行环境。在沙箱中运行的代码不会影响主系统,即使代码有恶意行为或出现错误,也是安全的。类比:Sandbox 就是助理的"练习室"——在里面试错不会影响到真实业务。
Docker
一种容器化技术,可以把应用及其依赖打包成一个独立的容器,在任何环境中一致运行。类比:Docker 就像是"标准化集装箱"——不管里面装什么,都能在任何港口装卸。
API(应用程序接口)
不同软件之间交互的约定方式。比如 Hermes 可以通过 OpenAI 的 API 调用 GPT-4。类比:API 就是不同公司之间的"服务协议"——规定了怎么请求服务、怎么接收结果。
Token
LLM 处理文本时的最小单位。一个中文词通常对应 1-2 个 token,一个英文单词通常对应 1 个 token。API 调用的费用通常按 token 数量计算。类比:Token 就像是文字的"积木块"——模型一块一块地处理和理解文本。
System Prompt(系统提示词)
在每次对话开始时发给 LLM 的隐藏指令,用于设定 AI 的角色、行为规则和约束条件。用户通常看不到 System Prompt,但它深刻影响着 AI 的回答风格。类比:System Prompt 就是给助理的"员工手册"——规定了工作中应该遵守的准则。
Workflow(工作流)
一系列按特定顺序执行的步骤。在 Agent 中,Workflow 定义了完成某个任务的完整流程。类比:Workflow 就是助理的"标准作业程序(SOP)"——每一步该做什么,写得清清楚楚。
Multi-Agent(多智能体)
多个 Agent 协同工作的系统。不同的 Agent 扮演不同的角色,通过协作完成复杂任务。类比:Multi-Agent 就是一个"团队"——产品经理、设计师、工程师各司其职,共同完成项目。
Fine-tuning(微调)
在预训练好的大模型基础上,用特定领域的数据进一步训练,让模型更适合特定任务。Hermes 本身不涉及 fine-tuning,但了解这个概念有助于理解模型能力。类比:Fine-tuning 就是"岗前培训"——通用人才经过针对性培训后更适合特定岗位。
Vector Database(向量数据库)
专门用于存储和检索向量数据的数据库。在 RAG 系统中用于存储文本的 embedding,支持基于语义相似度的快速检索。Hermes 使用 SQLite 配合扩展来实现类似功能。类比:Vector Database 就是"按意思分类的档案柜"——你不需要知道文件标题,只要描述你想找什么,它就能找到相关的。
Tips
这个术语表不需要一次性全部记住。建议你把它当作"词典"来用——读到某个术语不理解时,翻回来查一查。随着你阅读的深入,这些术语会变得越来越熟悉。
6.2 代码约定
本书中涉及的代码和命令遵循以下约定:
命令行命令
以 $ 开头的行表示需要在终端中执行的命令($ 本身不是命令的一部分):
$ hermes --version
以 # 开头的行表示注释或需要 root 权限执行的命令:
# 安装系统依赖(需要管理员权限)
$ sudo apt-get install python3-dev
配置文件
配置文件中的注释以 # 开头:
# 这是主配置文件
server:
host: 0.0.0.0 # 监听所有网络接口
port: 8080 # 服务端口
占位符
用 <> 包裹的内容表示需要替换为你自己的值:
$ hermes config set api_key <YOUR_API_KEY>
输出示例
命令的输出结果用无前缀的代码块表示:
Hermes Agent v1.2.3
Status: Running
Memory: 3.2MB / 512MB
Skills Loaded: 12
6.3 符号约定
本书中使用以下符号来突出重点:
Tips
提示性内容,帮助你更好地使用 Hermes 或提高学习效率。
注意
需要特别关注的内容,忽略可能会导致问题或误解。
常见问题
读者经常问到的问题及解答。
类比
用生活化的比喻解释抽象的技术概念。
加粗文字:表示重点概念或需要特别注意的内容。
等宽文字:表示代码、命令、文件名、配置项等技术内容。
本章小结
恭喜你读完了第一册!让我们回顾一下本章的核心内容。
我们谈了为什么写这本书:
AI Agent 时代已经到来,但大多数人还在门外观望。市面上的教程碎片化严重,缺乏系统性指导。从"养虾"到"养马"的转变,需要一本完整的养成手册。本书的定位不是技术论文,而是你的 AI 伙伴养成手册——通俗易懂、实战导向、覆盖从入门到精通的完整路径。
我们解释了 Hermes Agent 是什么:
Hermes 是一个生活在你的电脑里的、会学习、会进化的 AI 助手。它和 ChatGPT 的区别在于:本地运行而非云端、目标驱动而非对话驱动、具备长期记忆和自学习能力。它和 AutoGPT、MetaGPT 等框架的区别在于:更强大的记忆系统、自动创建和进化技能的能力、按需检索机制、多维度用户建模。
我们分析了为什么选择 Hermes:
2026 年的 AI Agent 市场百花齐放,Hermes 凭借五大核心优势脱颖而出:记忆自动归档、自主创建 Skill、技能自我进化、按需检索、用户建模。我们还对比了 Hermes 和 OpenClaw 的定位差异,并明确了 Hermes 适合什么样的人群。
我们介绍了全书架构和阅读建议:
16 册内容构成了一张完整的知识网络,针对不同读者设计了四条阅读路线:快速入门路线、深度技术路线、变现赚钱路线、从 OpenClaw 迁移路线。学习方法上,记住三个字:边学边练、先跑通再深入、建立知识网络。
我们梳理了开源社区和学习资源:
GitHub 仓库、官方文档、Discord 社区、Release 页面是主要官方资源。中文社区正在快速发展,包括微信群、视频教程、论坛等。任何人都可以通过提交 Bug、贡献技能、改进文档、翻译、社区运营等方式参与贡献。
我们准备了术语表和代码约定:
20+ 核心术语的通俗解释,以及代码和符号的使用约定,为后续章节的学习扫清了障碍。
读到这里,你可能已经迫不及待想要开始动手了。但别着急,建议你先去读第二册「AI-Agent 行业全景」,建立起对整个行业的宏观认知。这样,当你后面学习具体技术时,会更有"大局观"——知道每一个技术点在行业中的位置和价值。
当然,如果你是个急性子,也可以直接跳到第五册「安装部署全攻略」,先把 Hermes 跑起来再说。本书的模块化设计就是为了让你有选择的自由。
无论选择哪条路线,记住这句话:最好的学习方法,就是开始。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第二册:AI-Agent 行业全景
本章你将学到
- AI Agent 的学术定义与通俗理解,以及它与传统 AI 工具的本质区别
- 从 2022 年 ChatGPT 引爆到 2026 年 Hermes 崛起的完整发展脉络
- 2025-2026 年 AI Agent 行业格局:主流框架的全面对比与趋势分析
- 主流大模型底座的选择策略:从 DeepSeek 到 Claude 的成本与能力权衡
- MCP 协议的设计理念与生态爆发,以及它对 Agent 世界的革命性影响
- AI Agent 的商业化路径与中国生态的独特优势
预计阅读时间:90-120 分钟
1. 什么是 AI Agent——从概念到落地
1.1 AI Agent 的学术定义与通俗理解
在深入行业分析之前,我们需要先搞清楚一个根本问题:到底什么是 AI Agent?
学术界对 Agent 的定义可以追溯到几十年前。在人工智能的经典教材《Artificial Intelligence: A Modern Approach》中,Agent 被定义为:
任何能够感知环境并采取行动以实现目标的实体,都可以被称为 Agent。
这个定义非常宽泛。按照这个定义,你的恒温器是一个 Agent(感知温度,采取行动调节空调),你的扫地机器人也是一个 Agent(感知环境障碍,采取行动规划清扫路径)。
但在 2026 年的语境下,当我们说 "AI Agent" 时,通常指的是一个更具体的概念:
基于大语言模型(LLM)构建的、能够自主感知环境、进行推理规划、执行复杂任务并从经验中学习的智能系统。
这个定义里包含了四个关键词,我们一个一个来解释。
基于大语言模型(LLM)
AI Agent 的"大脑"是大语言模型。GPT-4、Claude、DeepSeek 这些模型提供了理解语言、推理问题、生成内容的基础能力。没有 LLM,Agent 就失去了"思考"的能力。
但 LLM 本身不是 Agent。LLM 是一个"静态"的模型——你给它输入,它给你输出。它不会主动去做什么事情,也不会记住你们之前的对话(至少不会长期记住)。Agent 是在 LLM 的基础上,增加了一层"行动力"和"记忆力"。
类比
LLM 就像一个人的"大脑"——能思考、能说话、能出主意。但光有大脑不够,你还需要"手脚"去执行事情,需要"记忆"去记住经验,需要"感官"去感知环境。Agent 就是给大脑配上了手脚、记忆和感官的完整"人"。
自主感知环境
Agent 不是被动等待指令的。它能主动"看"到周围发生了什么——你的日历更新了一件事情、你的邮箱收到了一封新邮件、某个网站发布了一条新公告、某个数据指标超过了阈值。这些环境变化会触发 Agent 的行动。
进行推理规划
当 Agent 接收到一个目标(比如"帮我准备明天跟李总的会议"),它不会立刻盲目行动。它会先"思考":要达成这个目标,需要做哪些事情?这些事情的先后顺序是什么?有哪些依赖关系?有哪些潜在的风险?这个思考过程就是推理和规划。
执行复杂任务
思考完了要行动。Agent 能调用各种工具来完成任务——搜索网页、读写文件、发送邮件、操作数据库、调用 API、甚至写代码并执行。这些工具让 Agent 从"只会说"变成了"能做"。
从经验中学习
这是最核心的区别。传统的程序是"写死"的——程序员写什么逻辑,它就怎么执行。Agent 则能在运行过程中积累经验:上次这样做效果很好,这次继续;上次那样做出了问题,这次换一种方式。这种学习能力让 Agent 能够持续改进,越用越好。
1.2 Agent 与传统 AI 工具的本质区别
理解了定义,我们来看看 Agent 和传统的 AI 工具有什么本质区别。
传统 AI 工具:被动响应型
传统的 AI 工具(比如早期的 ChatGPT、文生图工具、语音识别软件)是"被动响应型"的。它们的交互模式是:
用户输入 → AI 处理 → AI 输出
你问一个问题,它给一个答案。你让它画一张图,它画一张图。每一轮交互都是独立的,AI 不会主动做什么,也不会记住跨轮次的上下文。
Agent:主动目标驱动型
Agent 的交互模式完全不同:
用户设定目标 → Agent 规划任务 → Agent 执行步骤 → Agent 观察结果 → Agent 调整策略 → ... → 目标达成
你给 Agent 一个目标,它会自己想办法完成。它会分解任务、调用工具、处理异常、调整策略,整个过程不需要你一步一步指导。
类比
传统 AI 工具像是"出租车"——你告诉司机去哪里,他把你送到。每一程都是独立的,司机不会记住你上次去哪儿。Agent 像是"私人司机"——你告诉他"这周帮我安排好所有的出差行程",他会自己去查航班、订酒店、安排接送、处理变更,最后把完整的行程表发给你。而且,他记得你不喜欢坐靠窗的座位、你习惯提前 2 小时到机场、你喜欢住有健身房的酒店。
我们用一个表格来总结这个区别:
| 维度 | 传统 AI 工具 | AI Agent |
|---|---|---|
| 交互模式 | 一问一答 | 目标驱动 |
| 任务复杂度 | 单次、简单 | 多步骤、复杂 |
| 记忆能力 | 无或极短 | 长期、结构化 |
| 工具使用 | 无或内置有限 | 灵活调用外部工具 |
| 主动性 | 被动等待输入 | 主动感知和行动 |
| 学习能力 | 无(靠模型更新) | 运行时自学习 |
| 个性化 | 通用、无差异 | 针对用户持续优化 |
| 错误处理 | 直接报错或输出错误结果 | 自我诊断、重试、调整 |
1.3 感知-推理-行动-学习 闭环模型
Agent 的核心工作模式可以抽象为一个闭环模型:感知(Perceive)→ 推理(Reason)→ 行动(Act)→ 学习(Learn)。这个循环不断运转,让 Agent 持续进化。
第一步:感知(Perceive)
Agent 通过多种渠道感知环境: - 用户输入:你直接说的话、发的消息、提交的表单 - 外部事件:新邮件到达、日历提醒、数据变化、API 推送 - 系统状态:内存使用情况、任务队列长度、错误日志 - 时间触发:到了某个时间点,该执行定时任务了
# 伪代码:感知模块的简化逻辑
def perceive():
inputs = []
inputs.extend(check_user_messages()) # 检查用户消息
inputs.extend(check_external_events()) # 检查外部事件
inputs.extend(check_system_status()) # 检查系统状态
inputs.extend(check_time_triggers()) # 检查时间触发器
return filter_relevant(inputs) # 过滤出需要处理的事项
Tips
感知模块的设计决定了 Agent 的"敏感度"。太敏感了,一点风吹草动就触发行动,会造成干扰;太迟钝了,重要的事件可能被遗漏。好的感知模块需要平衡这两方面。
第二步:推理(Reason)
感知到信息后,Agent 需要进行推理: - 理解意图:用户到底想要什么?这个事件的含义是什么? - 任务分解:达成目标需要哪些步骤?这些步骤的依赖关系是什么? - 策略选择:有多种方案时,选哪个?考虑时间、成本、成功率等因素 - 风险评估:这个行动可能会有什么副作用?如何规避?
# 伪代码:推理模块的简化逻辑
def reason(perception):
intent = understand_intent(perception) # 理解意图
tasks = decompose(intent) # 任务分解
plan = select_strategy(tasks) # 策略选择
risk = assess_risk(plan) # 风险评估
return adjust_plan(plan, risk) # 调整计划
第三步:行动(Act)
推理完成后,Agent 开始执行计划: - 调用工具:搜索、读写文件、发送消息、调用 API - 生成内容:写文档、写代码、画图、做表格 - 交互反馈:向用户汇报进度、询问确认、展示结果 - 状态更新:记录执行日志、更新任务状态、触发后续任务
# 伪代码:行动模块的简化逻辑
def act(plan):
for step in plan.steps:
result = execute(step) # 执行步骤
if result.failed:
fallback = handle_error(step, result) # 错误处理
if fallback:
result = execute(fallback)
record_log(step, result) # 记录日志
return summarize_results(plan)
第四步:学习(Learn)
行动结束后,学习模块开始工作: - 效果评估:任务完成得怎么样?用户满意吗? - 经验提取:这次有哪些经验可以沉淀?哪些坑要记住? - 记忆更新:把新知识存入记忆系统 - 模型优化:基于反馈调整行为策略(比如用户建模的更新)
# 伪代码:学习模块的简化逻辑
def learn(execution_result, user_feedback):
score = evaluate(execution_result) # 效果评估
insights = extract_insights(execution_result) # 经验提取
memory.store(insights) # 记忆更新
user_model.update(user_feedback) # 用户模型更新
skills.optimize(execution_result) # 技能优化
这个四步闭环不断循环运转,Agent 就在这个循环中持续运作和进化。
类比
想象一个经验丰富的厨师。他走进厨房(感知)→ 看到食材和订单,思考做什么菜、怎么搭配(推理)→ 切菜、炒菜、摆盘(行动)→ 客人吃完给了好评或差评,他记下来下次改进(学习)。一个好的厨师,就是在这个闭环中越转越熟练的。Agent 也一样。
1.4 Agent 的分类:单体 Agent、多 Agent 系统、自主 Agent
根据复杂度和协作方式,Agent 可以分为三类。
第一类:单体 Agent(Single Agent)
一个 Agent 独立完成所有任务。这是最简单也最常用的模式。比如,你部署一个 Hermes Agent 来帮你处理日常事务——查邮件、写文档、安排日程,都是这一个 Agent 在做。
单体 Agent 的优点是简单、可控、资源占用少。缺点是能力上限受限于单个 LLM 的容量,复杂任务可能处理不好。
第二类:多 Agent 系统(Multi-Agent System)
多个 Agent 协同工作,每个 Agent 负责不同的角色或任务。比如:
- 产品经理 Agent:负责需求分析、写 PRD
- 架构师 Agent:负责技术方案设计
- 开发 Agent:负责写代码
- 测试 Agent:负责测试和 Bug 报告
这些 Agent 之间可以相互通信、协作,共同完成一个大型项目。
多 Agent 系统的优点是能处理更复杂的任务,可以模拟真实团队的协作方式。缺点是协调复杂度高,可能出现沟通不畅、任务冲突等问题。
Tips
MetaGPT 是多 Agent 系统的典型代表,它模拟了一个完整的软件公司。CrewAI 则提供了更轻量级的多 Agent 协作框架。Hermes 也支持多 Agent 编排(详见第十一册),但它的核心设计是围绕"强大的单体 Agent"展开的。
第三类:自主 Agent(Autonomous Agent)
这是 Agent 的最高形态。自主 Agent 不仅能执行你给它的任务,还能自己设定目标、自己规划长期发展。
比如,你给自主 Agent 一个高层次的目标"提升我的个人品牌影响力"。它会自己分解出:要发多少篇文章、要参加什么活动、要跟哪些人建立联系。然后它会主动执行这些子任务,不需要你每次吩咐。
自主 Agent 的理念非常前沿,但在实际应用中还存在很多挑战——比如如何保证 Agent 设定的目标是合理的、如何避免 Agent 做出有害的决策等。目前市面上还没有真正成熟的自主 Agent 产品,但 Hermes 的自学习和技能进化能力,已经朝这个方向迈出了重要的一步。
注意
"自主"不等于"不受控制"。好的自主 Agent 设计会包含多层安全机制:人类确认、沙箱执行、权限限制、审计日志等。Hermes 在这些方面都有完善的设计,确保 Agent 在自主的同时不会失控。
2. AI Agent 发展简史(2022-2026)
2.1 2022:ChatGPT 引爆大模型革命
2022 年 11 月 30 日,OpenAI 发布了 ChatGPT。这个日期被很多人视为 AI 时代的"分水岭"。
在 ChatGPT 之前,AI 对大众来说是一个遥远的技术概念——AlphaGo 下棋很厉害,但跟普通人没关系;Siri 能设闹钟,但智能程度有限。ChatGPT 第一次让普通人感受到了"跟 AI 自然对话"的魔力。
ChatGPT 发布 5 天,用户数突破 100 万。两个月,突破 1 亿。这是人类历史上增长最快的消费级应用。
但 2022 年的 ChatGPT 还只是一个"对话工具"。你问它问题,它给答案。它不会主动去做什么,也不会记住你们的长期对话。它的上下文窗口只有 4096 个 token(大约几千字),聊一会儿就"忘"了前面说的什么。
然而,ChatGPT 证明了一件事:大语言模型已经具备了理解复杂指令、进行逻辑推理、生成高质量内容的能力。 这是 Agent 时代的技术基础。没有这个基础,后面的一切都不会发生。
类比
2022 年就像"电灯泡被发明"的那一刻。电灯泡本身只是一个照明工具,但它证明了"电力"是可以被人类控制和利用的。接下来,人们发明了电风扇、电冰箱、电视机、电脑……电灯泡是起点,而不是终点。ChatGPT 就是 AI 领域的那个"电灯泡"。
2022 年的代表性事件:
- 2022年4月:Google 发布 PaLM(5400亿参数),展示了大规模语言模型的潜力
- 2022年5月:DeepMind 发布 Gato,一个能处理多种任务的通用 AI 模型
- 2022年8月:Stability AI 发布 Stable Diffusion,文生图领域迎来爆发
- 2022年11月30日:OpenAI 发布 ChatGPT,引爆全球大模型浪潮
2.2 2023:AutoGPT 掀起 Agent 热潮
2023 年,ChatGPT 的余温还在,但开发者们已经开始思考一个问题:能不能让 AI 不只是"说话",而是真正"做事"?
2023 年 3 月,一个名为 AutoGPT 的开源项目在 GitHub 上发布,彻底点燃了 Agent 的热潮。
AutoGPT 的核心思想非常简单,也非常激进:
给 AI 一个目标,然后让它自己循环执行:思考 → 行动 → 观察 → 再思考,直到完成目标。
比如,你给 AutoGPT 一个目标"帮我策划一场生日派对"。它会自己分解任务: 1. 确定派对日期和地点 2. 列宾客名单 3. 规划餐饮 4. 准备娱乐活动 5. 发送邀请
然后它会一步一步执行:搜索派对场地信息、写宾客名单文档、查餐饮方案……每一步都可能调用搜索引擎、读写文件、甚至写代码。
AutoGPT 在 GitHub 上的 Star 数以惊人的速度增长,短短几周就突破了 100k。它让人们第一次看到了"AI 自主行动"的可能性。
但 AutoGPT 的问题也很快暴露出来:
- 容易陷入循环:Agent 反复"思考"但做不出实质性进展,就像一个焦虑的人在原地打转
- 任务分解质量不稳定:简单的目标分解得很好,复杂的目标就乱了套
- 成本高:每次循环都要调用 LLM API,一个任务下来可能烧掉几美元
- 缺乏有效的记忆管理:Agent 会"忘记"重要的上下文信息
常见问题
Q:AutoGPT 现在还能用吗?
A: 能,但已经不是最热门的选择了。AutoGPT 项目在 2023 年后经历了多次重构,目前的版本比最初稳定了很多。但在功能完整性和生态丰富度上,它已经被 OpenClaw 和 Hermes 等后来者超越了。不过,AutoGPT 的历史地位不可磨灭——它是第一个让"AI Agent"概念深入人心的项目。
2023 年还涌现了其他重要的 Agent 项目:
BabyAGI:由开发者 Yohei Nakajima 创建,是一个极简的 Agent 原型。它的代码只有几百行,但清晰地展示了"任务生成 → 优先级排序 → 执行"的核心循环。很多后来的 Agent 框架都受到了 BabyAGI 的启发。
AgentGPT:AutoGPT 的浏览器版本,让不会编程的用户也能体验 Agent。它在易用性上做了很大改进,但能力上受限于浏览器环境。
LangChain:虽然 LangChain 不完全是 Agent 框架,但它在 2023 年的快速发展为 Agent 的构建提供了重要的基础设施——链式调用、工具集成、记忆管理、Prompt 模板等。可以说,没有 LangChain 打下的基础,后来的 Agent 框架不会发展得那么快。
2023 年的代表性事件:
- 2023年3月:AutoGPT 发布,GitHub Star 数在数周内破 100k
- 2023年3月:BabyAGI 发布,极简 Agent 理念影响深远
- 2023年4月:AgentGPT 发布,降低 Agent 使用门槛
- 2023年6月:OpenAI 发布 Function Calling,让 LLM 能调用外部工具
- 2023年11月:OpenAI 发布 GPT-4 Turbo,上下文窗口提升到 128k
2.3 2024:工具调用成熟、RAG 架构普及、Multi-Agent 系统涌现
2024 年是 Agent 技术"从概念走向工程化"的关键一年。
工具调用成熟
2023 年的 Agent 项目大多是"手工拼接"的——开发者自己写代码让 LLM 调用工具。2024 年,OpenAI 的 Function Calling、Anthropic 的 Tool Use 等功能让 LLM 原生支持工具调用,大大降低了开发门槛。
工具调用的成熟意味着:Agent 不再是一个"只会说话"的聊天机器人,而是真正可以"动手做事"的执行者。搜索网页、读写文件、操作数据库、发送邮件、调用 API……这些能力让 Agent 的应用场景大大扩展。
RAG 架构普及
RAG(Retrieval-Augmented Generation,检索增强生成)在 2024 年成为主流架构。RAG 解决了 LLM 的两个核心问题:
- 知识新鲜度:LLM 的训练数据有截止日期,不知道最新发生的事情。RAG 让 Agent 能实时检索最新信息。
- 幻觉问题:LLM 有时会"编造"不存在的知识。RAG 通过让 LLM 基于检索到的真实资料来回答,大大降低了幻觉率。
2024 年,向量数据库(Pinecone、Weaviate、Qdrant、Chroma 等)迎来了爆发式增长,RAG 的检索精度和速度都有了质的飞跃。
Multi-Agent 系统涌现
2024 年,多个 Multi-Agent 框架发布,其中最引人注目的是 MetaGPT。
MetaGPT 的创意来自于软件公司的组织架构。它模拟了一个完整的开发团队: - 产品经理:写产品需求文档(PRD) - 架构师:设计系统架构 - 项目经理:分解任务、分配资源 - 工程师:写代码 - 测试员:测试和报告 Bug
这些角色不是人类,而是 Agent。它们通过结构化的文档(PRD、设计文档、任务列表)来协作,最终产出一个完整的软件项目。
MetaGPT 的出现让人们看到了 Multi-Agent 系统的巨大潜力。但它的局限性也很明显:主要面向软件开发场景,对于非技术任务的适配性不强;Agent 之间的协作有时会出现"踢皮球"的情况;整体流程比较僵化,缺乏灵活性。
2024 年的代表性事件:
- 2024年1月:MetaGPT 发布,Multi-Agent 协作范式受到关注
- 2024年3月:CrewAI 发布,轻量级 Multi-Agent 框架
- 2024年4月:Llama 3 发布,开源模型能力逼近闭源模型
- 2024年6月:Claude 3.5 Sonnet 发布,编码能力大幅提升
- 2024年9月:OpenAI 发布 o1 系列,推理能力实现质的飞跃
- 2024年12月:Google 发布 Gemini 2.0,多模态能力全面增强
2.4 2025:OpenClaw 横空出世、MCP 协议标准化、个人 AI 助手元年
2025 年是 AI Agent 从"极客玩具"走向"大众工具"的关键年份。
OpenClaw 横空出世
2025 年初,Nous Research 团队发布了 OpenClaw。这个项目迅速成为 GitHub 上 Star 数最高的 Agent 项目之一,最终达到了 309k Stars 的惊人成绩。
OpenClaw 的成功有几个关键因素:
- 丰富的工具生态:内置了几十个常用工具,覆盖搜索、文件操作、代码执行、通信等多个领域
- 灵活的配置系统:用户可以通过配置文件和 YAML 文件来定制 Agent 的行为,不需要写代码
- 活跃的社区:Skills Hub 生态让用户可以方便地分享和下载技能
- 多平台支持:支持 Discord、Telegram、Slack 等多个平台的接入
OpenClaw 让"拥有一个个人 AI 助手"从程序员的专利变成了普通用户也能做到的事情。它标志着 Agent 技术的第一次大规模普及。
但 OpenClaw 也有其局限性: - 记忆系统相对简单,缺乏长期记忆能力 - 技能系统是静态的,不能自动创建和进化 - 架构设计在早期快速迭代中积累了一定的技术债务 - 用户建模能力有限,难以实现真正的个性化
这些局限性,最终促使了 Hermes 的诞生。
类比
OpenClaw 就像早期的智能手机——功能已经很多,能打电话、能上网、能拍照,但续航差、内存小、系统不够流畅。它证明了"个人 AI 助手"这个方向是对的,但也暴露了需要改进的地方。Hermes 就像是新一代智能手机——在同样的理念上,把每一个细节都打磨得更好。
MCP 协议标准化
2025 年中,Anthropic 推出了 MCP(Model Context Protocol,模型上下文协议)。这是一个开放标准,用于统一 AI 模型与外部工具/服务之间的通信方式。
在 MCP 之前,每个 Agent 框架都有自己的工具调用方式。A 框架的工具不能直接在 B 框架中使用,开发者需要为每个框架重复造轮子。MCP 的出现解决了这个问题——它定义了一套统一的标准,任何符合 MCP 规范的工具,都可以被任何支持 MCP 的 Agent 调用。
MCP 的重要性怎么强调都不为过。它就像是 Agent 世界的 USB-C 接口——一个标准,连接万物。到 2026 年 4 月,MCP 生态已经覆盖了 6000+ 服务,从数据库、搜索引擎到代码仓库、设计工具,几乎涵盖了所有常用的软件服务。
个人 AI 助手元年
2025 年下半年,"个人 AI 助手"成为了科技行业最热门的话题。
- 科技公司纷纷推出自己的 Agent 产品
- 开源社区涌现出大量新项目
- 投资机构开始重点关注 Agent 赛道
- 媒体铺天盖地报道"AI 助理将改变工作方式"
但真正让个人 AI 助手从"概念"变成"可用产品"的,是像 OpenClaw 这样的开源框架。它们让普通用户能够低成本、高自由度地搭建自己的 Agent。
2025 年的代表性事件:
- 2025年1月:OpenClaw 发布,迅速成为 GitHub 上最热门的 Agent 项目
- 2025年3月:DeepSeek-V3 发布,以极低成本实现接近 GPT-4 的能力
- 2025年5月:Anthropic 发布 MCP 协议,Agent 工具生态迎来标准化
- 2025年6月:AutoGen v0.4 发布,Multi-Agent 编排能力大幅提升
- 2025年8月:Claude 3.5 Opus 发布,复杂推理能力达到新高度
- 2025年10月:OpenAI 发布 GPT-5 预览版,多模态和推理能力全面增强
- 2025年12月:OpenClaw GitHub Star 数突破 300k,创造开源 Agent 项目新纪录
2.5 2026:Hermes Agent 崛起、自学习 Agent 时代开启
2026 年,AI Agent 领域迎来了新的篇章。
Hermes Agent 的崛起
2026 年初,Nous Research 团队发布了 Hermes Agent。作为 OpenClaw 的精神续作,Hermes 继承了前者的优秀基因,同时进行了全面的架构升级。
截至 2026 年 4 月 20 日,Hermes Agent 在 GitHub 上已获得 104,791 个 Stars,而它正式发布才约两个月。这个增长速度在整个 AI 开源领域都是极为罕见的。
Hermes 的官方定位非常清晰:
"自我提升的自主代理,生活在所有其他工具之外。"
这句话包含了三层含义: 1. 自我提升:Hermes 不是静态的,它能通过自学习闭环持续改进 2. 自主代理:它能独立感知、规划、行动,不需要人类一步一步指导 3. 生活在所有其他工具之外:它不是某个工具的插件或扩展,而是一个独立存在的智能体
在 Nous Research 的官方文档中,Hermes 与竞品的定位差异被描述得非常清晰:
| 产品 | 定位 |
|---|---|
| Claude Code | 仓库内编码代理 |
| Cursor | 编辑器内双人程序员 |
| OpenClaw | 配置驱动的任务运行器 |
| Hermes | 自我提升的自主代理 |
这个对比很有意思。Claude Code 和 Cursor 都是"编码工具"——它们活在代码仓库或编辑器里,帮你写代码、改 Bug。OpenClaw 是"任务运行器"——你配置好任务,它按配置执行。而 Hermes 是"自主代理"——它有自己的判断力和进化能力,不依赖于预设的配置。
Tips
社区中有一个有趣的共识:大多数高级用户同时使用 Hermes + Claude Code,它们是叠加关系而非竞争关系。 也就是说,Hermes 负责宏观的任务规划和自主执行,Claude Code 负责具体的代码实现。两者配合,效率更高。这就像你有一个项目经理(Hermes)和一个高级工程师(Claude Code),各司其职,协同工作。
Harness Engineering 五层框架
Hermes 的架构设计采用了 Harness Engineering 五层框架:
- 指令层(Instruction Layer):接收和解析用户的意图,将自然语言转化为可执行的计划
- 约束层(Constraint Layer):确保 Agent 的行为在安全、合规、道德的边界内运行
- 反馈层(Feedback Layer):收集执行结果和用户反馈,为学习模块提供输入
- 记忆层(Memory Layer):管理三层记忆系统,支持高效的信息存储和检索
- 编排层(Orchestration Layer):协调各个模块的运作,管理任务队列和资源分配
这个五层框架的设计哲学是"分层解耦"——每一层只负责自己的职责,层与层之间通过清晰的接口通信。这使得 Hermes 既容易理解,又容易扩展。
技能生态的爆发
截至 2026 年 4 月 19 日,Hermes 的社区贡献技能数量已达到 643 个,覆盖了从开发工具到生活助手、从金融分析到内容创作的各个领域。Skills Hub 生态正在快速成长,每天都有新的技能被提交和审核。
三类目标用户
Hermes 的设计明确面向三类核心用户:
- CLI 编码器:习惯在命令行工作的开发者,他们追求效率和控制力
- 自动化操作员:需要自动化处理重复性任务的用户,他们追求"设置好就不管"
- Telegram 机器人操作员:通过 Telegram 等即时通讯平台与 Agent 交互的用户,他们追求随时随地的便利性
注意
这三类用户不是互斥的。很多用户同时属于多个类别。Hermes 的灵活架构允许同一个实例同时服务多种使用场景。
开源与模型生态
Hermes 采用 MIT 开源许可证,这意味着任何人都可以自由地使用、修改和分发 Hermes 的代码,包括用于商业目的。这个许可证选择体现了 Nous Research 团队推动 Agent 技术民主化的决心。
在模型支持方面,Hermes 支持 18+ 个模型提供者,包括:
- Claude Sonnet/Opus(Anthropic)
- GPT-5(OpenAI)
- GLM-5(智谱 AI)
- MiniMax M2.7(MiniMax)
- DeepSeek(深度求索)
- Nous Portal(Nous Research 的统一订阅服务)
特别值得一提的是 Nous Portal,这是 Nous Research 推出的统一订阅模式。用户只需要一次认证,就可以访问多个模型,无需为每个模型单独注册和付费。这大大简化了模型选择和多模型切换的流程。
类比
Nous Portal 就像是"模型世界的 Netflix"——你付一份订阅费,就能看多个平台的电影。不需要每个平台单独注册、单独付费、单独管理账号。对于需要频繁切换模型(比如用 Claude 做分析、用 DeepSeek 做中文内容、用 GPT-5 做创意生成)的高级用户来说,这是极大的便利。
2026 年的代表性事件:
- 2026年1月:Hermes Agent 正式发布
- 2026年2月:Hermes GitHub Star 数突破 50k
- 2026年3月:MCP 生态突破 5000 个服务
- 2026年4月:Hermes GitHub Star 数达到 104,791,社区技能数达到 643 个
- 2026年4月:GLM-5 发布,国产大模型能力再上新台阶
2.6 每个阶段的关键项目分析小结
让我们用一张大表格来总结 2022-2026 年的关键项目和事件:
| 年份 | 阶段特征 | 代表项目/事件 | 核心意义 |
|---|---|---|---|
| 2022 | 大模型启蒙 | ChatGPT 发布 | 证明了 LLM 的能力,为 Agent 奠定技术基础 |
| 2023 | Agent 概念爆发 | AutoGPT、BabyAGI、AgentGPT | 首次让大众看到 AI 自主行动的可能性 |
| 2024 | 工程化落地 | MetaGPT、CrewAI、RAG 普及 | Agent 从玩具走向可用工具 |
| 2025 | 大规模普及 | OpenClaw(309k Stars)、MCP 协议 | 个人 AI 助手元年,工具生态标准化 |
| 2026 | 自学习进化 | Hermes(104,791 Stars)、自主 Agent | Agent 进入自我提升、自我进化的新阶段 |
3. 2025-2026 AI Agent 行业格局
3.1 主流 Agent 框架全景图
截至 2026 年 4 月,AI Agent 框架领域已经形成了"一超多强"的格局。以下是主流框架的概览:
第一梯队(Star 数 > 50k)
- OpenClaw:309k Stars,配置驱动的任务运行器,生态最丰富
- Hermes:104,791 Stars,自我提升的自主代理,增长最快
- AutoGPT:165k Stars,Agent 概念的开创者,历史地位高
- LangChain:95k Stars,LLM 应用开发的基础设施
第二梯队(Star 数 10k-50k)
- CrewAI:38k Stars,轻量级 Multi-Agent 框架
- AutoGen:32k Stars,微软推出的 Multi-Agent 编排框架
- LangGraph:28k Stars,LangChain 团队的图编排 Agent 框架
- MetaGPT:25k Stars,模拟软件公司组织架构的 Multi-Agent 系统
- LlamaIndex:22k Stars,RAG 和数据检索的专家
- BabyAGI:18k Stars,极简 Agent 原型,启发深远
第三梯队(Star 数 < 10k)
- AgentGPT:12k Stars,AutoGPT 的浏览器版本
- SuperAGI:9k Stars,面向开发者的 Agent 构建平台
- Camel:7k Stars,多 Agent 协作框架
- 其他:数百个新兴项目,数量快速增长
Tips
GitHub Stars 不是衡量项目质量的唯一标准,但它是反映社区关注度和项目活跃度的重要指标。一个高 Stars 的项目通常意味着:文档更完善、社区更活跃、第三方资源更丰富、遇到问题更容易找到解决方案。
3.2 详细对比表格
让我们从多个维度对这些主流框架进行详细对比:
| 维度 | AutoGPT | MetaGPT | CrewAI | AutoGen | LangGraph | OpenClaw | Hermes |
|---|---|---|---|---|---|---|---|
| 首次发布 | 2023.03 | 2024.01 | 2024.03 | 2023.10 | 2024.01 | 2025.01 | 2026.01 |
| GitHub Stars | 165k | 25k | 38k | 32k | 28k | 309k | 104,791 |
| 主要语言 | Python | Python | Python | Python | Python | Python/TS | Python/TS |
| 架构模式 | 单 Agent 循环 | Multi-Agent | Multi-Agent | Multi-Agent | 图编排 | 模块化单体 | 五层 Harness |
| 记忆系统 | 基础文件存储 | 有限 | 基础 | 中等 | 中等 | 文件+简单 DB | 三层记忆 |
| 学习能力 | 无 | 无 | 无 | 有限 | 无 | 有限反馈 | 自学习闭环 |
| 技能系统 | 插件 | 角色模板 | 任务定义 | 函数注册 | 节点函数 | YAML 配置 | 自动创建+进化 |
| 工具数量 | 10+ | 5+ | 10+ | 15+ | 依赖生态 | 30+ | 47+ 内置 + MCP |
| 用户建模 | 无 | 无 | 无 | 无 | 无 | 无 | 多维度画像 |
| 多平台 | 有限 | CLI | 有限 | 有限 | 无 | Discord/TG/Slack | 18+ 平台 |
| 模型支持 | OpenAI | OpenAI | 多模型 | 多模型 | 多模型 | 多模型 | 18+ 提供者 |
| 社区活跃度 | 中 | 中 | 高 | 高 | 高 | 极高 | 极高 |
| 适用场景 | 实验探索 | 软件开发 | 轻量协作 | 复杂编排 | 流程自动化 | 通用助手 | 通用+自进化 |
让我们逐行解读这个对比表。
架构模式
AutoGPT 是经典的"单 Agent 循环"模式——一个 Agent 反复执行"思考-行动-观察"的循环。这种模式简单直观,但容易陷入循环或偏离目标。
MetaGPT、CrewAI、AutoGen 都是 Multi-Agent 模式。多个 Agent 分工协作,适合复杂任务。但协调成本高,有时会出现"踢皮球"现象。
LangGraph 采用"图编排"模式。用有向图来定义任务的流转关系,适合确定性强的业务流程。但对于需要灵活应变的场景,图的刚性结构可能成为限制。
OpenClaw 是"模块化单体"模式。一个 Agent 内部有多个模块(工具、技能、记忆等),通过配置来组合。灵活性高,但模块之间的耦合度也较高。
Hermes 采用"Harness Engineering 五层框架"——指令层、约束层、反馈层、记忆层、编排层。这种分层架构的解耦度更高,每一层都可以独立优化和扩展。
记忆系统
这是 Hermes 最突出的优势之一。大多数框架的记忆系统都是"浅层"的——要么是简单的文件存储,要么是临时的上下文缓存。Hermes 的三层记忆系统(会话记忆 + 持久记忆 + Skill 级记忆)实现了真正的长期记忆能力。
学习能力
令人惊讶的是,在 2026 年的主流框架中,具备真正"运行时自学习"能力的仍然寥寥无几。大多数框架的"学习"依赖于开发者更新代码或重新训练模型。Hermes 的自学习闭环(执行 → 评估 → 提取经验 → 更新记忆 → 优化技能)是一个突破性的设计。
技能系统
传统框架的技能系统都是"静态"的——开发者写好,用户拿来用。Hermes 的"自动创建 + 自我进化"能力打破了这种模式,让技能系统成为了一个"活"的生态系统。
用户建模
在这个对比维度上,Hermes 几乎是"一枝独秀"。其他框架要么完全没有用户建模,要么只有非常基础的功能(比如记住用户的名字)。Hermes 的多维度用户画像(基础画像、交互偏好、知识图谱、任务模式、反馈历史)为实现真正的个性化服务奠定了基础。
注意
这个对比表反映的是 2026 年 4 月的情况。AI Agent 领域发展极快,各框架都在快速迭代。比如,AutoGen 和 CrewAI 可能在未来版本中增加记忆和学习能力。对比表的目的是帮助你理解当前格局,而不是做出"哪个更好"的绝对判断。
3.3 开源 vs 闭源、本地 vs 云端的趋势分析
2025-2026 年的 AI Agent 市场,有两个核心矛盾正在塑造行业格局。
矛盾一:开源 vs 闭源
闭源阵营的代表是 OpenAI、Anthropic、Google 等科技巨头。它们的产品技术能力强、集成度高、用户体验好。但缺点是: - 数据必须上云,隐私风险大 - 按调用付费,成本高且不可控 - 定制受限,只能按厂商的设计使用 - 存在"厂商锁定"风险——一旦依赖了某个平台,迁移成本极高
开源阵营的代表是 OpenClaw、Hermes、LangChain 等社区项目。它们的优势是: - 数据完全本地可控,隐私安全 - 免费使用(仅需承担运行成本) - 高度可定制,可以修改任何部分 - 不存在厂商锁定,代码属于自己
但开源项目也有挑战: - 需要一定的技术能力来部署和维护 - 文档和支持不如商业产品完善 - 功能更新速度可能不如资金雄厚的商业公司
趋势判断:2026 年的趋势是"混合模式"。越来越多的企业采用"开源框架 + 商业模型 API"的组合——用开源框架(如 Hermes)保证数据可控和定制化,同时调用商业 LLM API(如 Claude、GPT-5)来获得强大的推理能力。这种组合兼顾了两方面的优势。
类比
闭源产品像是"精装房"——拎包入住,省心省力,但你不能拆墙、不能改布局。开源框架像是"毛坯房"——需要自己装修,但你可以按照自己的想法设计每一个角落。而"开源框架 + 商业 API"就像是"毛坯房 + 品牌家电"——基础结构自己掌控,核心设备用最好的。
矛盾二:本地 vs 云端
本地部署意味着 Agent 运行在你自己的机器或私有服务器上。云端部署意味着 Agent 运行在服务商的服务器上。
本地部署的优势: - 数据不出本地,隐私绝对安全 - 没有网络延迟,响应速度快 - 不受服务商政策变化影响 - 可以离线使用(如果接本地模型)
本地部署的挑战: - 需要自己的硬件资源(GPU/CPU、内存、存储) - 需要自己负责运维和维护 - 初始配置相对复杂
云端部署的优势: - 零配置,打开即用 - 不需要维护硬件 - 可以方便地共享和协作
云端部署的挑战: - 数据隐私风险 - 持续的订阅费用 - 网络依赖(没网就不能用) - 服务商倒闭或政策变化的风险
趋势判断:2026 年,本地部署的趋势明显增强。原因有几个: 1. 开源模型能力快速提升:Llama 3、DeepSeek、Qwen 等开源模型的能力已经逼近甚至超过部分闭源模型,使得本地运行高质量模型成为可能 2. 数据隐私意识增强:越来越多的企业和个人意识到数据的价值和风险,不愿意把敏感数据交给第三方 3. 本地部署工具成熟:Docker、Ollama、LM Studio 等工具让本地部署变得越来越简单 4. 成本考量:对于高频使用者,本地部署的长期成本远低于按调用付费
Hermes 的设计哲学就是"本地优先"。虽然它也支持云端部署,但核心功能和数据管理都是为本地场景优化的。这符合当前的行业趋势。
4. 大模型底座的选择与影响
4.1 主流 LLM 对比
Agent 的"智商"很大程度上取决于它使用的 LLM。选择一个合适的大模型底座,是搭建 Agent 时最重要的决策之一。
以下是 2026 年 4 月主流 LLM 的详细对比:
| 模型 | 厂商 | 类型 | 上下文窗口 | 核心优势 | 主要劣势 |
|---|---|---|---|---|---|
| GPT-5 | OpenAI | 闭源 | 256k | 综合能力最强,多模态优秀 | 价格最高,数据上云 |
| Claude 3.5/Opus | Anthropic | 闭源 | 200k | 推理能力极强,安全性高 | 价格较高,速度偏慢 |
| DeepSeek-V3 | 深度求索 | 开源 | 128k | 性价比极高,中文优秀 | 多模态能力一般 |
| GLM-5 | 智谱 AI | 开源 | 128k | 中文理解优秀,本土化好 | 英文能力稍弱 |
| Gemini 2.0 | 闭源 | 1M | 上下文窗口最大,多模态强 | 国内访问受限 | |
| Llama 3.1 | Meta | 开源 | 128k | 开源可本地部署,生态丰富 | 综合能力略逊于闭源 |
| Qwen2.5 | 阿里巴巴 | 开源 | 128k | 中文优秀,代码能力强 | 长文本处理有待提升 |
| MiniMax M2.7 | MiniMax | 闭源 | 128k | 中文对话流畅,角色扮演强 | 生态相对较小 |
让我们深入分析几个关键模型。
GPT-5(OpenAI)
GPT-5 是目前综合能力的"天花板"。无论是语言理解、推理能力、代码生成还是创意写作,它都保持着领先优势。多模态能力(文本、图像、音频的统一处理)也是业界顶尖。
对于 Agent 来说,GPT-5 的优势在于: - 工具调用理解准确,很少出现"乱调用"的情况 - 长上下文处理能力强,适合复杂任务的规划 - 指令遵循度高,不容易"跑偏"
劣势也很明显: - 价格是行业最高的之一 - 数据必须发送到 OpenAI 的服务器 - API 调用有速率限制
Tips
如果你的 Agent 需要处理极其复杂的任务(比如多步骤的投研分析、复杂的代码重构),且预算充足,GPT-5 是首选。但如果你的任务相对常规,可以考虑性价比更高的替代方案。
Claude 3.5 Sonnet / Opus(Anthropic)
Claude 系列以"推理能力"和"安全性"著称。Claude 3.5 Sonnet 在编码任务上的表现尤其突出,被很多开发者认为是"最好的编程助手"。Opus 则是 Claude 系列中能力最强的版本,适合最复杂的推理任务。
对于 Agent 来说,Claude 的优势在于: - 推理链条清晰,适合需要严密逻辑的任务 - 安全性设计好,不容易生成有害内容 - 代码理解和生成能力强
劣势: - 价格比 GPT-4o 更高 - 有时过于"谨慎",对于一些边界情况拒绝执行 - creative 写作方面不如 GPT 系列灵活
注意
很多开发者有一个误区:认为"模型越贵越好"。事实上,模型选择应该基于任务特性。如果你的 Agent 主要做中文内容创作,DeepSeek 或 GLM-5 可能比 Claude 效果更好;如果你的 Agent 主要做代码相关任务,Claude Sonnet 可能是最佳选择。
DeepSeek-V3(深度求索)
DeepSeek-V3 是 2025 年的"黑马"模型。它以极低的训练成本实现了接近 GPT-4 的能力,震惊了整个 AI 行业。
对于 Agent 来说,DeepSeek 的优势在于: - 性价比无敌:API 价格约为 GPT-4 的 1/10 - 中文能力强:在中文理解和生成方面表现优异 - 开源可本地部署:可以私有化运行,数据完全可控 - 推理能力优秀:数学和逻辑推理能力不俗
劣势: - 多模态能力(图像、音频处理)相对较弱 - 工具调用的稳定性不如 GPT 和 Claude - 国际影响力还在提升中,英文社区资源相对较少
类比
如果把模型比作汽车引擎,GPT-5 是顶配 V12 引擎——动力最强但油耗最高;Claude 是精密调校的 V8——动力充沛且稳定可靠;DeepSeek 是涡轮增压的直列六缸——动力接近 V8 但油耗只有一半。选哪个,取决于你的预算和需求。
GLM-5(智谱 AI)
GLM-5 是国产大模型中的佼佼者。在中文理解、本土知识、文化语境方面有明显优势。
对于面向中文用户的 Agent 来说,GLM-5 是一个非常有吸引力的选择: - 中文表达自然流畅,很少出现"翻译腔" - 对中国本土的知识(历史、地理、文化、网络梗)理解准确 - 可以本地部署,满足合规要求 - 价格适中
4.2 模型能力与 Agent 表现的关系
不是所有任务都需要最强的模型。理解"模型能力"和"Agent 表现"之间的关系,可以帮助你做出更经济的选择。
Agent 任务对模型的核心要求:
- 指令遵循能力:模型是否能准确理解并执行复杂的指令?这是 Agent 的基础要求。
- 工具调用理解:模型是否能正确判断何时调用工具、调用什么工具、传递什么参数?
- 上下文理解:模型是否能在长对话中保持对上下文的理解?
- 推理规划能力:模型是否能将复杂任务分解为合理的步骤?
- 错误恢复能力:当工具调用失败时,模型是否能理解错误信息并调整策略?
不同任务对模型的要求不同:
| 任务类型 | 推荐模型 | 原因 |
|---|---|---|
| 简单问答/检索 | DeepSeek / GLM-5 | 成本低,中文好 |
| 代码生成/重构 | Claude 3.5 Sonnet | 编码能力最强 |
| 复杂推理/分析 | Claude Opus / GPT-5 | 推理链条最严密 |
| 创意写作 | GPT-5 / DeepSeek | 创造力和灵活性 |
| 多模态处理 | GPT-5 / Gemini 2.0 | 多模态能力领先 |
| 本地私有化部署 | Llama 3.1 / DeepSeek | 开源可本地运行 |
Tips
Hermes 支持 18+ 个模型提供者,你可以在配置中为不同的任务指定不同的模型。比如,代码任务用 Claude,中文写作用 GLM-5,复杂分析用 GPT-5。这种"模型路由"能力可以帮你在性能和成本之间找到最佳平衡。
4.3 成本分析
模型的 API 调用成本是运营 Agent 的主要开支之一。以下是 2026 年 4 月的主流模型定价(输入/输出,每百万 token):
| 模型 | 输入价格 | 输出价格 | 备注 |
|---|---|---|---|
| DeepSeek-V3 | ~$0.14 | ~$0.28 | 性价比最高 |
| GLM-5 | ~$0.50 | ~$1.00 | 国产模型,价格适中 |
| Qwen2.5 | ~$0.30 | ~$0.60 | 阿里巴巴出品 |
| Llama 3.1(API) | ~$0.20 | ~$0.40 | 通过第三方 API |
| GPT-4o | ~$2.50 | ~$10.00 | 综合能力强 |
| Claude 3.5 Sonnet | ~$3.00 | ~$15.00 | 编码能力最强 |
| Claude 3 Opus | ~$15.00 | ~$75.00 | 顶级推理能力 |
| GPT-5 | ~$5.00 | ~$15.00 | 最新旗舰 |
注意
以上价格仅供参考,实际价格可能因服务商、套餐、地区而有所不同。具体价格请以各平台官网为准。同时,很多服务商提供免费额度,新用户可以先试用再决定是否付费。
成本优化策略:
-
模型分级:简单任务用便宜模型,复杂任务用贵模型。Hermes 支持按任务类型自动路由到不同模型。
-
本地部署开源模型:如果你有 GPU 资源,本地部署 Llama 3.1 或 DeepSeek 可以将 API 成本降到零。初始硬件投入可能较高,但对于高频使用者,长期看更划算。
-
缓存重复请求:对于频繁出现的相同或相似请求,使用缓存避免重复调用 API。
-
控制上下文长度:Agent 的上下文越长,API 调用成本越高。合理管理记忆和上下文,避免不必要的信息冗余。
-
使用 Nous Portal:对于需要多模型切换的用户,Nous Portal 的统一订阅模式可能比单独购买每个模型的 API 更划算。
类比
模型成本就像是汽车的油费。DeepSeek 是电动车——每公里成本极低;Claude Opus 是超跑——性能最强但油耗惊人。聪明的司机会根据路程选择车辆——日常通勤开电动车,偶尔赛道日开超跑。Agent 的模型选择也是同理。
4.4 开源模型 vs 闭源模型对 Agent 生态的影响
开源模型和闭源模型的竞争,正在深刻影响 Agent 生态的走向。
闭源模型的优势与挑战
闭源模型(GPT-5、Claude、Gemini)由资金雄厚的公司训练和维护,通常保持着性能上的领先。它们是 Agent 生态的"引擎供应商"。
但闭源模型也带来了一些问题: - 集中化风险:少数公司控制最先进的 AI 能力,可能导致垄断 - 数据依赖:使用闭源模型意味着数据必须上传到第三方服务器 - 成本门槛:高昂的 API 费用让个人开发者和初创企业望而却步 - 可解释性差:不知道模型内部怎么工作,调试困难
开源模型的崛起
2024-2026 年,开源模型经历了爆发式增长。Llama 3、DeepSeek、GLM、Qwen 等模型在性能上快速逼近闭源模型,同时保持开放和可本地部署的特性。
开源模型对 Agent 生态的影响:
- 降低门槛:任何人都可以免费使用高质量的模型,促进了 Agent 技术的民主化
- 促进创新:开发者可以修改模型、微调模型,创造出适合特定场景的应用
- 保障隐私:本地部署消除了数据外泄的风险
- 避免锁定:不依赖任何单一厂商,用户有完全的自主权
未来趋势
我预测未来几年的趋势是"闭源领跑、开源追赶、混合成为主流":
- 闭源模型会继续在绝对性能上保持领先,因为大公司有更多的算力和数据资源
- 开源模型会继续缩小差距,在性价比和可定制性上保持优势
- 大多数 Agent 应用会采用"混合策略"——用开源模型处理常规任务,用闭源模型处理复杂任务,根据场景灵活切换
Hermes 的 18+ 模型提供者支持,正是为这种混合策略设计的。你可以在配置中自由组合不同模型,找到最适合自己的方案。
5. MCP 协议:Agent 世界的 USB-C
5.1 MCP 诞生背景与设计理念
2025 年之前,Agent 与外部工具的集成是一场"噩梦"。
每个 Agent 框架都有自己的工具调用方式。OpenClaw 有一套,AutoGen 有一套,LangChain 又有一套。一个工具开发者如果想让自己的服务被多个 Agent 框架使用,就要为每个框架写一遍适配代码。这就像是电器厂商要为每个国家生产不同插头的电器一样荒谬。
更麻烦的是,工具的调用接口各不相同。有的用 REST API,有的用 GraphQL,有的用 gRPC,有的用 WebSocket。参数格式也是五花八门——JSON、XML、Protobuf、自定义格式……Agent 开发者要花大量时间在"适配不同接口"上,而不是"构建智能逻辑"上。
2025 年中,Anthropic 推出了 MCP(Model Context Protocol,模型上下文协议),彻底改变了这个局面。
MCP 的设计理念非常简单:
为 AI Agent 和外部工具之间定义一个统一、开放、标准化的通信协议。
类比一下:
- 在 USB 出现之前,电脑外设有各种接口——串口、并口、PS/2……每个设备都需要特定的线和驱动。
- USB 统一了这一切,一个接口连接所有设备。
- MCP 就是 Agent 世界的 USB(更准确地说,是 USB-C)——一个协议,连接所有工具和服务。
5.2 MCP 如何统一工具调用标准
MCP 的核心架构基于客户端-服务器模型:
┌─────────────────────────────────────────┐
│ Agent (MCP Client) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ MCP A │ │ MCP B │ │ MCP C │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ │ │ │ │
│ ═════╪════════════╪════════════╪══════ │
│ │ MCP Protocol │ │
│ ═════╪════════════╪════════════╪══════ │
│ │ │ │ │
│ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ │
│ │Server A │ │Server B │ │Server C │ │
│ │(Search) │ │(DB) │ │(GitHub) │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────┘
MCP 协议定义了三个核心原语:
1. Tools(工具)
工具是 Agent 可以调用的功能。每个工具有一个名称、描述、参数列表。Agent 通过 LLM 的 Function Calling 能力来决定调用哪个工具、传递什么参数。
{
"name": "search_web",
"description": "搜索网页内容",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "搜索关键词"
},
"limit": {
"type": "integer",
"description": "返回结果数量",
"default": 10
}
},
"required": ["query"]
}
}
2. Resources(资源)
资源是 MCP 服务器可以向 Agent 暴露的只读数据。比如,一个数据库 MCP 服务器可以暴露表结构、一个文件系统 MCP 服务器可以暴露目录列表。Agent 可以读取这些资源来获取上下文信息。
3. Prompts(提示模板)
Prompts 是预定义的提示模板,帮助 Agent 更好地使用某个服务。比如,一个代码仓库 MCP 服务器可以提供"代码审查提示模板",Agent 可以直接使用这个模板来审查代码。
Tips
MCP 的妙处在于它的"声明式"设计。工具提供者只需要声明"我有什么能力",而不需要关心"谁在用我"。Agent 也只需要按照统一协议去发现和使用工具,不需要为每个工具写适配代码。这种解耦大大降低了生态参与的门槛。
5.3 6000+ 服务的生态爆发
MCP 协议发布后的生态增长速度,超出了所有人的预期。
截至 2026 年 4 月,MCP 生态已经覆盖了 6000+ 服务,包括:
开发工具类
- GitHub MCP:操作代码仓库、创建 PR、审查代码
- GitLab MCP:同上,针对 GitLab 平台
- PostgreSQL MCP:查询和操作 PostgreSQL 数据库
- SQLite MCP:本地数据库操作
- Redis MCP:缓存和数据结构操作
- Docker MCP:容器管理
办公协作类
- Slack MCP:发送消息、管理频道
- Discord MCP:社区管理
- Notion MCP:笔记和知识库操作
- Google Docs MCP:文档编辑
- Microsoft Office MCP:Office 文档操作
搜索与信息类
- Brave Search MCP:隐私保护的网页搜索
- Perplexity MCP:AI 驱动的搜索引擎
- Arxiv MCP:学术论文检索
- Wikipedia MCP:百科知识查询
通信与消息类
- Email MCP:邮件收发
- SMS MCP:短信发送
- Telegram MCP:消息推送
金融与数据类
- Yahoo Finance MCP:股票和财经数据
- Alpha Vantage MCP:金融市场数据
- Polygon MCP:实时股票数据
生活服务类
- Weather MCP:天气查询
- Maps MCP:地图和导航
- Calendar MCP:日历管理
- Translation MCP:多语言翻译
类比
MCP 生态的爆发,让我想起了 App Store 的早期。2008 年 App Store 上线时,第一批应用只有 500 个。但统一的平台标准吸引了大量开发者,应用数量呈指数级增长。MCP 正处于类似的"早期爆发期"——6000+ 服务听起来很多,但相比未来可能达到的数十万级别,这才刚刚开始。
5.4 MCP 对 Hermes 和 OpenClaw 的不同意义
MCP 的出现,对不同的 Agent 框架有不同的意义。
对 OpenClaw 的意义
OpenClaw 在 MCP 出现之前,已经建立了自己的工具生态(约 30 个内置工具)。MCP 的出现,让 OpenClaw 能够接入更多的外部服务,扩展了能力边界。但由于 OpenClaw 的架构相对固化,MCP 的集成深度有限——主要是作为"外部工具"的补充,而不是核心架构的一部分。
对 Hermes 的意义
Hermes 从设计之初就把 MCP 作为核心架构的一部分。在 Hermes 的架构中:
- 工具层(Tool Layer) 原生支持 MCP 协议
- Hermes 内置的 47 个工具中,有很多是通过 MCP 方式集成的
- 用户可以通过简单的配置,接入任意 MCP 服务
- Skills Hub 中的社区技能大量依赖 MCP 来扩展能力
更重要的是,Hermes 的技能自我进化能力与 MCP 形成了绝佳的互补:
当 Hermes 发现某个任务需要调用外部服务时,它可以: 1. 去 MCP 市场搜索是否有合适的服务 2. 如果有,自动配置并接入 3. 如果没有,尝试用现有工具组合实现 4. 将解决方案沉淀为新技能,供未来复用
这种"智能发现 + 自动集成 + 经验沉淀"的闭环,让 Hermes 的 MCP 集成能力远超其他框架。
Tips
如果你想为 Hermes 添加一个新的 MCP 服务,步骤非常简单: 1. 找到该服务的 MCP 配置文件(通常是一个 JSON 或 YAML 文件) 2. 在 Hermes 的配置文件中添加 MCP 服务器的地址和认证信息 3. 重启 Hermes,新工具就会自动出现在可用工具列表中
整个过程通常只需要几分钟,不需要写任何代码。
6. AI Agent 商业化与变现趋势
6.1 个人超级个体:AI 赋能单人创业
2026 年,"一人公司"(One-Person Business)的概念正在从梦想走向现实。AI Agent 是这场变革的核心驱动力。
什么是"超级个体"?
传统的创业者需要团队——你需要设计师做 UI、需要程序员写代码、需要运营做推广、需要客服回答问题。但 AI Agent 让一个人可以拥有整个"团队"的能力:
- 内容创作 Agent:自动选题、写作、排版、发布,管理多个自媒体账号
- 设计 Agent:生成图片、制作海报、设计 Logo
- 编程 Agent:写代码、测 Bug、部署上线
- 客服 Agent:7×24 小时回答客户问题
- 数据分析 Agent:收集数据、制作报表、发现趋势
- 投研 Agent:跟踪市场、分析财报、生成报告
一个人,加上一套 Agent 系统,就能完成过去需要一个团队才能完成的工作。
真实案例
在 Hermes 的社区中,有一位昵称为"小马"的独立开发者。他原本是一个普通的程序员,2025 年开始用 OpenClaw 搭建自动化内容创作流程。2026 年迁移到 Hermes 后,他的系统进一步升级: - 每天早上 8 点,投研 Agent 自动扫描科技新闻和股市动态 - 上午 10 点,内容 Agent 基于投研结果生成 3-5 篇文章 - 下午 2 点,排版 Agent 将文章适配到微信公众号、知乎、今日头条等多个平台 - 下午 4 点,发布 Agent 按最优时间推送内容 - 晚上 8 点,数据分析 Agent 汇总当天的阅读数据,生成运营报告
整个流程全自动运行,小马只需要在关键节点做审核和微调。他一个人运营着 5 个自媒体账号,月收入超过了很多小型工作室。
个人超级个体的核心模式:
| 模式 | 描述 | 收入潜力 |
|---|---|---|
| 自动化内容工厂 | 用 Agent 批量生产高质量内容 | 月入 1-10 万 |
| 智能客服代运营 | 为中小企业部署 AI 客服 Agent | 月费 3000-2 万/客户 |
| 投研自动化 | 用 Agent 生成投资研究报告 | 订阅制或按报告收费 |
| 电商运营自动化 | 自动上架、定价、客服、数据分析 | 按效果分成 |
| 编程外包 Agent | 用 Agent 辅助或独立完成开发任务 | 按项目收费 |
Tips
如果你也想成为"超级个体",建议从"自动化一个你已经很熟悉的流程"开始。不要试图一步到位搭建一个全能系统。先选一个你最常做的重复性任务,用 Agent 把它自动化。成功了一个,再扩展下一个。本书第十四册「九大变现路径」会详细拆解每一条路径。
6.2 企业内部效率工具
AI Agent 在企业端的应用,正在从"试点项目"走向"核心系统"。
企业 Agent 的典型应用场景:
1. 智能客服
传统的客服机器人只能回答预设问题,遇到稍微复杂的情况就"转人工"。Agent 驱动的智能客服可以: - 理解用户的真实意图,即使表达方式千变万化 - 查询订单系统、知识库、产品文档,给出准确回答 - 处理退换货、修改订单等复杂操作 - 遇到无法解决的问题时,智能地收集信息并转接给最合适的人工客服 - 从每次对话中学习,不断优化回答质量
2. 内部知识库助手
大型企业通常有海量的内部文档——规章制度、项目文档、技术方案、会议纪要。员工查找信息往往耗时耗力。
Agent 可以: - 整合企业内部的所有信息源(文档、邮件、聊天记录、数据库) - 用自然语言回答员工的查询 - 主动推送相关信息(比如"你关注的项目有新进展") - 生成知识摘要和报告
3. 数据分析与报告
Agent 可以自动: - 从多个数据源收集数据 - 清洗和整理数据 - 进行统计分析和趋势预测 - 生成可视化的报告和仪表盘 - 在关键指标异常时主动告警
4. 流程自动化
企业中有很多重复性的流程——审批、报销、招聘、入职等。Agent 可以: - 理解流程规则,自动处理常规请求 - 在需要人工确认时发起审批 - 跟踪流程进度,及时提醒相关人员 - 从流程执行中发现瓶颈,提出优化建议
注意
企业部署 Agent 时,安全性和合规性是首要考虑。Hermes 的本地化部署能力在这里有巨大优势——所有数据都在企业内部,不会外泄。同时,Hermes 的约束层(Constraint Layer)可以设置行为边界,确保 Agent 不会执行越权的操作。
企业市场的商业模式:
| 模式 | 描述 | 典型定价 |
|---|---|---|
| SaaS 订阅 | 提供云端 Agent 服务 | 每用户每月 50-500 元 |
| 私有化部署 | 在企业本地部署 Hermes | 一次性费用 + 年维护费 |
| 定制开发 | 为企业定制专属 Agent | 按项目收费,10-100 万 |
| 咨询服务 | 帮助企业规划 Agent 战略 | 按天或按项目收费 |
6.3 开发者生态与技能市场
Hermes 的 Skills Hub 生态正在催生一个新的"技能市场"。
什么是技能市场?
就像 App Store 里有免费和付费 App 一样,Skills Hub 里也有免费和付费的技能。开发者可以: - 创建有用的技能,发布到 Skills Hub - 设置免费或付费(一次性购买或订阅制) - 获得收入分成
截至 2026 年 4 月 19 日,Skills Hub 已有 643 个社区贡献技能。这个数字在两个月前 Hermes 刚发布时还不到 100。增长速度非常快。
技能市场的参与者:
| 角色 | 行为 | 收益 |
|---|---|---|
| 技能开发者 | 创建和发布技能 | 销售收入、名声、机会 |
| 技能消费者 | 下载和使用技能 | 节省时间、获得能力 |
| 平台运营方 | 维护 Skills Hub 生态 | 平台抽成、生态繁荣 |
| 企业用户 | 采购企业级技能包 | 快速提升 Agent 能力 |
技能开发者的变现路径:
- 免费技能 + 增值服务:基础功能免费,高级功能收费
- 付费技能:一次性购买,价格从几美元到几十美元不等
- 订阅制技能:按月或按年收费,适合需要持续更新的技能
- 企业授权:为企业客户提供批量授权和技术支持
- 定制开发:为特定客户定制专属技能
类比
Skills Hub 就像是 Agent 世界的 "App Store"。2008 年, nobody 想到给手机写 App 能赚钱。但到了 2026 年,App Store 生态创造了数万亿美元的价值。Agent 技能市场正处于类似的早期阶段——现在进入,你可能就是未来的"头部开发者"。
6.4 投研自动化、内容自动化等垂直领域
除了通用的效率工具,Agent 在垂直领域的应用也在快速深入。
投研自动化
投资研究是一个信息密集型、重复性高的工作。分析师需要: - 跟踪大量新闻和公告 - 阅读和分析财报 - 监控市场数据和指标 - 撰写研究报告
Agent 可以自动化其中 80% 以上的工作: - 新闻监控 Agent:7×24 小时扫描全球财经新闻,发现与关注标的相关的信息 - 财报分析 Agent:自动下载财报,提取关键指标,生成分析摘要 - 数据监控 Agent:实时监控股价、交易量、宏观经济指标,异常时告警 - 报告生成 Agent:基于收集的信息,自动生成研究报告初稿
真实案例
某小型投研机构的创始人使用 Hermes 搭建了"投研流水线": - 每天开盘前,Agent 自动汇总隔夜全球市场动态 - 盘中,Agent 实时监控持仓标的的重大消息 - 收盘后,Agent 自动生成交易复盘报告 - 每周,Agent 生成行业深度报告初稿,分析师在此基础上修改完善
这个系统让他们的研究效率提升了 3 倍以上,分析师可以把更多时间花在"深度思考"而不是"信息收集"上。
内容自动化
内容创作领域是 Agent 应用最成熟的领域之一: - 选题 Agent:分析热点趋势,推荐选题方向 - 写作 Agent:根据提纲生成文章初稿 - 编辑 Agent:润色文字、检查错别字和语法 - 排版 Agent:适配不同平台的格式要求 - 发布 Agent:按最优时间自动发布 - 数据分析 Agent:分析内容表现,提出优化建议
其他垂直领域
| 领域 | Agent 应用 | 成熟度 |
|---|---|---|
| 法律 | 合同审查、案例检索、文书生成 | ★★★☆☆ |
| 医疗 | 病历整理、医学文献检索、健康管理 | ★★☆☆☆ |
| 教育 | 个性化辅导、作业批改、课程设计 | ★★★☆☆ |
| 电商 | 商品上架、定价策略、客服、评价分析 | ★★★★☆ |
| 游戏 | NPC 智能、剧情生成、测试自动化 | ★★★☆☆ |
| 设计 | 素材生成、排版建议、风格迁移 | ★★★★☆ |
Tips
垂直领域的 Agent 应用通常需要结合领域知识。通用框架(如 Hermes)提供了基础能力,但要真正做好垂直应用,还需要在领域数据上做专门的优化。比如,法律 Agent 需要接入法律数据库,医疗 Agent 需要接入医学知识图谱。这为垂直领域的创业者提供了巨大的机会——你可以基于 Hermes 构建特定行业的解决方案。
7. 中国 AI Agent 生态特色
7.1 国产大模型的崛起
2024-2026 年,中国的大模型产业经历了从"追赶"到"并跑"甚至局部"领跑"的转变。
DeepSeek(深度求索)
DeepSeek 可能是 2025 年最受关注的 AI 公司之一。它的 V3 模型以极低的训练成本实现了接近 GPT-4 的能力,震惊了整个行业。
DeepSeek 对 Agent 生态的意义: - 成本革命:API 价格只有 GPT-4 的约 1/10,让 Agent 的大规模部署成为可能 - 开源策略:模型权重开源,可以本地部署,满足数据合规要求 - 中文优化:在中文理解和生成方面表现优异
Kimi(月之暗面)
Kimi 以超长上下文窗口著称(支持 200 万字上下文)。这对 Agent 来说是一个巨大的优势——Agent 可以在一次对话中处理海量的背景信息。
通义千问(阿里巴巴)
通义千问系列在代码能力和多语言处理方面表现出色。Qwen2.5 在多个 benchmark 上接近或超过了 Llama 3 的水平。
文心一言(百度)
文心一言在中文知识问答和本土化服务方面有独特优势,与百度搜索、百度地图等生态有深度整合。
GLM(智谱 AI)
GLM-5 在中文理解和生成方面达到了新的高度,同时支持 Function Calling 等 Agent 所需的核心能力。
国产模型的共同优势:
- 中文能力强:在中文语境、文化理解、本土知识方面,国产模型通常优于国外模型
- 价格竞争力:国产模型的 API 价格普遍低于国外竞品
- 合规优势:数据不出境,满足国内的数据安全法规要求
- 本地部署支持:大多数国产模型支持私有化部署
类比
国产大模型的发展,让我想起了中国智能手机产业的崛起。十年前,国产手机还是"廉价模仿"的代名词。但今天,华为、小米、OPPO 等品牌在全球市场占据了重要地位。国产大模型正在走类似的路径——从追赶到并跑,未来可能在某些领域实现领跑。
7.2 中文社区的特殊需求与玩法
中文 AI Agent 社区有一些独特的需求和玩法,这是国外社区所没有的。
需求一:微信生态集成
微信是中国最重要的社交平台。大多数中文用户希望 Agent 能够通过微信与他们交互——而不是 Discord 或 Telegram。
Hermes 支持微信接入(详见第十册),这是它受到中文用户欢迎的重要原因之一。
需求二:本土化内容创作
中文内容创作有很多特殊的"玩法": - 公众号文章需要符合特定的排版风格和阅读节奏 - 小红书的笔记需要特定的标签和表情使用习惯 - 抖音的脚本需要考虑短视频的节奏和"钩子" - B站的内容需要考虑弹幕文化和"梗"的使用
通用的内容生成 Agent 很难做好这些本土化细节。中文社区的开发者正在创建专门针对这些平台的技能。
需求三:合规与审查
在中国运营 AI 服务,需要遵守相关的法律法规。这包括内容安全、数据保护、算法备案等方面的要求。
本地部署的 Agent(如 Hermes)在这方面有天然优势——数据不出境、内容审核规则可以自定义、算法逻辑透明可控。
需求四:多音字和方言处理
中文的多音字、方言、网络用语对 LLM 是一个挑战。国产模型在这方面通常有更好的表现。
Tips
如果你主要服务中文用户,建议优先选择国产模型或针对中文优化过的模型作为 Agent 的底座。即使你的 Agent 框架是国际化的(如 Hermes),模型选择也要考虑本土化因素。
7.3 本土化部署与合规考量
在中国部署 AI Agent,需要考虑以下几个合规问题:
数据安全法与个人信息保护法
- 处理个人信息需要获得用户同意
- 敏感数据的处理需要额外的安全措施
- 数据跨境传输受到严格限制
本地部署的优势:
# Hermes 完全本地部署时,所有数据都在你的机器上
# 不需要担心数据跨境传输的问题
# 你可以完全控制数据的存储、使用和删除
$ hermes start --local-only
# 启动本地模式,不连接任何外部云服务
生成式 AI 服务管理暂行办法
中国对生成式 AI 服务有专门的管理规定,包括: - 需要进行算法备案 - 需要建立内容审核机制 - 需要保护用户数据安全
对于企业用户来说,使用本地部署的开源框架(如 Hermes),可以更好地满足这些合规要求。
注意
合规是一个复杂的法律问题,本节的介绍仅供参考,不能替代专业的法律建议。如果你在企业环境中部署 Agent,建议咨询专业的法律顾问。
7.4 飞书、微信等国内平台的集成优势
中国的办公和社交平台有其独特的生态,这为 Agent 的集成提供了丰富的场景。
飞书(Lark)
飞书是字节跳动推出的企业协作平台,在国内企业中有很高的渗透率。
Agent 与飞书的集成场景: - 智能会议助理:自动记录会议纪要、提取 action items、跟进任务进度 - 知识库问答:员工在飞书群里 @Agent 提问,Agent 从企业知识库中查找答案 - 审批助手:自动处理常规审批请求,复杂情况转人工 - 日报/周报生成:自动汇总工作数据,生成报告
微信
微信是中国最大的社交平台,几乎人人都在用。
Agent 与微信的集成场景: - 个人助理:通过微信与 Agent 交互,随时随地获取帮助 - 社群运营:在微信群中自动回答问题、管理群规、推送内容 - 客服接入:微信公众号/小程序中接入 Agent 客服 - 家庭成员共享:一家人共用一个 Agent,管理家庭事务
钉钉
钉钉是阿里巴巴推出的企业协作平台,在中小企业中有广泛的用户基础。
Agent 与钉钉的集成场景与飞书类似,主要是企业内部的效率工具。
接入方式:
Hermes 提供了这些平台的 Gateway 模块,接入方式通常是通过平台的机器人/Webhook 接口:
# Hermes 配置示例:接入飞书
gateways:
lark:
enabled: true
app_id: <YOUR_LARK_APP_ID>
app_secret: <YOUR_LARK_APP_SECRET>
webhook_url: https://open.feishu.cn/open-apis/bot/v2/hook/xxx
# 启用后,Agent 可以通过飞书接收和发送消息
# Hermes 配置示例:接入微信
gateways:
wechat:
enabled: true
token: <YOUR_WECHAT_TOKEN>
app_id: <YOUR_WECHAT_APP_ID>
app_secret: <YOUR_WECHAT_APP_SECRET>
# 需要配合微信开发者平台的认证
Tips
微信个人号的接入有一定限制(腾讯对自动化工具管控较严)。建议企业用户使用微信公众号或企业微信接入。个人用户可以考虑用 Telegram 或 Discord 作为替代方案。第十册「多平台接入实战」会详细介绍每个平台的接入方法和注意事项。
8. 本章小结与展望
8.1 本章核心内容回顾
恭喜你读完了这一章!本章的信息量很大,让我们做一个系统的回顾。
什么是 AI Agent?
AI Agent 是基于大语言模型构建的、能够自主感知环境、进行推理规划、执行复杂任务并从经验中学习的智能系统。它与传统 AI 工具的本质区别在于:从"被动响应"到"主动目标驱动",从"单次交互"到"持续学习和进化"。
AI Agent 发展简史
- 2022:ChatGPT 引爆大模型革命,奠定了 Agent 的技术基础
- 2023:AutoGPT 掀起 Agent 热潮,首次让大众看到 AI 自主行动的可能性
- 2024:工具调用成熟、RAG 普及、Multi-Agent 系统涌现,Agent 从玩具走向可用工具
- 2025:OpenClaw 横空出世(309k Stars)、MCP 协议标准化、个人 AI 助手元年
- 2026:Hermes Agent 崛起(104,791 Stars),自学习 Agent 时代开启
2025-2026 行业格局
主流框架形成了"一超多强"的格局。Hermes 凭借 Harness Engineering 五层框架、三层记忆系统、自动技能创建与进化、按需检索、用户建模等核心优势,在快速增长中确立了领先地位。
大模型底座选择
模型选择应该基于任务特性:编码选 Claude,中文选 DeepSeek/GLM-5,复杂推理选 GPT-5/Claude Opus,性价比选 DeepSeek。Hermes 支持 18+ 模型提供者(包括 Nous Portal 统一订阅),可以灵活组合。
MCP 协议
MCP 是 Agent 世界的 USB-C,统一了工具调用标准。6000+ 服务的生态爆发,让 Agent 的能力边界无限扩展。Hermes 从设计之初就深度集成 MCP,形成了"智能发现 + 自动集成 + 经验沉淀"的闭环。
商业化趋势
- 个人超级个体:一人公司成为现实
- 企业效率工具:从试点走向核心系统
- 技能市场:新的开发者生态正在形成
- 垂直领域:投研、内容、法律、医疗等方向快速深入
中国生态特色
国产大模型(DeepSeek、Kimi、GLM 等)快速崛起,中文社区有独特的需求和玩法(微信集成、本土化内容、合规要求),飞书、微信、钉钉等平台的集成为 Agent 提供了丰富的应用场景。
8.2 对 2026-2027 年的展望
基于对行业趋势的分析,我对未来一年做出以下预测:
预测一:Agent 将从"辅助工具"进化为"协作伙伴"
2026 年的 Agent 主要还是"执行者"——你给它任务,它完成。2027 年,Agent 将更多地扮演"协作者"的角色——它会主动提出建议、挑战你的假设、帮你发现盲点。这种关系的变化,将深刻改变人机交互的范式。
预测二:自学习将成为标配
2026 年,具备自学习能力的 Agent 框架还很少(Hermes 是领先者)。到 2027 年,自学习将成为主流 Agent 框架的标配功能。不能自我进化的 Agent 将被市场淘汰。
预测三:多 Agent 协作将更加成熟
2026 年的 Multi-Agent 系统还存在协调成本高、容易"踢皮球"等问题。2027 年,随着编排技术的进步,多 Agent 协作将变得更加流畅和高效。
预测四:Agent 将深度融入操作系统
未来的操作系统(Windows、macOS、Linux、手机系统)将把 Agent 作为核心组件。Agent 不再是"一个应用",而是"系统的一部分"。
预测五:中国 Agent 生态将走出独立路径
依托国产大模型的崛起和本土平台的深度整合,中国的 AI Agent 生态将走出一条不同于欧美的发展路径。在中文场景下,国产方案可能更具竞争力。
Tips
预测未来是一件危险的事情——很容易被打脸。但趋势判断是有价值的,因为它帮助你提前布局。无论这些预测是否完全准确,"Agent 会越来越重要"这个大方向是确定的。越早投入学习和实践,你在未来的竞争中就越有优势。
8.3 给读者的行动建议
读完这一章,你可能对 AI Agent 行业有了全景式的认知。但认知不转化为行动,就只是一堆信息而已。以下是三个建议:
建议一:选择一个框架,深入实践
不要试图了解所有的框架。选一个(我推荐 Hermes),把它学深学透。真正理解一个框架,比 superficially 了解十个框架更有价值。
建议二:关注行业动态,但不要被信息淹没
Agent 领域每天都有新东西出来。选 2-3 个可靠的信息源(比如官方博客、几个核心开发者的 Twitter、一个高质量的技术社区),定期浏览即可。不要追求"知道所有新消息",那是不可能的。
建议三:找到你的应用场景
技术本身不是目的,解决问题才是。想一想:在你的工作或生活中,有哪些重复性、耗时的任务可以用 Agent 来自动化?找到一个具体的场景,动手去实现它。实践中的问题会逼着你学习,这种学习效率远高于被动阅读。
本章是全书 16 册中"视野最宏观"的一章。建立行业认知的目的,是为了让你在后续学习具体技术时,知道每一个知识点在"大图景"中的位置。
接下来,第三册「Hermes 诞生与演进」将带你深入了解 Hermes 这个项目的前世今生——它的团队、它的技术基因、它从 OpenClaw 演进过来的故事。理解一个项目的过去,是预判它未来的最佳方式。
让我们继续这段旅程。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第三册:Hermes 诞生与演进
本章你将学到
- Nous Research 这家公司究竟是何方神圣,为什么他们能做出 Hermes 这样惊艳的项目
- 什么是"缰绳工程"(Harness Engineering),这个理念如何彻底改变了 AI Agent 的设计思路
- OpenClaw 曾经的辉煌与那些让人头疼的痛点
- Hermes 是如何从 OpenClaw 的土壤中生长出来,又实现了哪些关键突破
- Hermes 发布两个月就斩获 104,791 Stars 背后的增长密码
- "养马"和"养虾"这两个有趣的社区称呼是怎么来的,背后又代表了怎样的文化差异
- Hermes 未来的路线图和生态发展预测
好了,让我们坐上时光机,一起回溯 Hermes 从一颗种子成长为参天大树的完整历程。
1. Nous Research:Hermes 背后的公司
1.1 一家不走寻常路的 AI 公司
在聊 Hermes 之前,我们先来认识一下它的"亲爹"——Nous Research。
如果你之前没有听说过这个名字,那完全正常。因为 Nous Research 并不是那种整天开新闻发布会、上科技头条的"网红公司"。他们更像是一个隐居深山的武林门派,平时不显山露水,但一出手就是大招。
Nous 这个词来自古希腊语,意思是"心灵"或"理智"。从名字就能看出,这家公司的野心不小——他们不只是想做一家普通的 AI 公司,而是想探索人工智能的"心智"本质。
Nous Research 成立于 2023 年,总部位于美国。公司创立的背景很有意思:当时 ChatGPT 已经火遍全球,大量创业者蜂拥而入,试图在 AI 这个风口上分一杯羹。但 Nous Research 的创始人团队看到了一个更深层的问题:现有的大语言模型虽然能力强大,但缺乏真正的自主性、持续学习能力和个性化适配能力。
打个比方:ChatGPT 就像一个博学的家教,你问什么它答什么,但它不会主动帮你规划学习路径,也不会记得你上周犯过的错误,更不会随着相处时间的增长而变得"更懂你"。每次对话结束,一切归零,下次见面又是"初次相识"。
Nous Research 的愿景,就是要打破这个局限。他们想要构建一种新型的 AI 系统——一种能够长期陪伴用户、持续积累经验、不断自我进化的智能体。这个愿景,最终催生了 Hermes Agent。
1.2 6500 万美元融资背后的故事
2024 年到 2025 年间,AI 领域的融资故事层出不穷。有的公司靠一个漂亮的 PPT 就能拿到数千万美元,有的公司花三年时间打磨产品却无人问津。Nous Research 的融资经历,属于那种"酒香不怕巷子深"的类型。
据报道,Nous Research 在 2024 年底完成了一轮 6500 万美元 的融资。这个数字放在 AI 创业圈,说大不大,说小不小。毕竟同期的很多 AI 公司动辄融资几亿美元。但关键在于:Nous Research 拿钱的方式和用钱的方式,都很不一样。
首先,他们不是去讲一个"我们要做下一个 ChatGPT"的故事。恰恰相反,他们的叙事是反潮流的——"我们不追求最大、最强的模型,我们追求最懂用户、最能自主进化的系统。"
在投资人对大模型参数规模攀比到近乎疯狂的时候,Nous Research 却在强调"小而美"的哲学:用轻量级的架构、高效的算法和精巧的设计,实现超越庞大系统的实际效果。
Tips
在 AI 投资圈,有一个不成文的规律:越是讲"我们模型参数多大、算力多强"的公司,越可能是在堆砌资源;越是讲"我们怎么让 AI 更懂人、更自主"的公司,越可能有真正的技术创新。Nous Research 属于后者。
6500 万美元的资金,Nous Research 主要花在了三个地方:
第一,核心研发团队。 他们聚拢了一批在机器学习、自然语言处理、系统架构和分布式计算领域有深厚积累的工程师和研究员。这支团队的一个显著特点是:很多人都有开源社区背景,深谙"开放协作"的力量。
第二,基础设施与算力。 虽然不像大模型公司那样需要成千上万张 GPU,但训练、测试和运行 Agent 系统仍然需要不小的算力投入。Nous Research 建立了自己的实验集群,用于验证各种 Agent 行为的长期演化。
第三,社区建设。 这是 Nous Research 最与众不同的地方。他们把相当一部分资金用在了文档建设、社区支持和开发者活动上。因为他们深知,一个开源项目的生命力,不在于代码写得有多优雅,而在于围绕它形成的社区有多活跃。
1.3 核心团队与技术实力
Nous Research 的团队构成,可以用"小而精"来形容。
公司没有走传统科技公司的"人海战术"路线,而是坚持保持一支精简的核心团队。这种选择背后有一个清醒的认识:AI Agent 领域的创新,关键不在于人手多,而在于思考深。 一百个平庸的工程师,不如十个真正理解问题本质的天才。
团队的技术基因来自多个领域的交叉:
大语言模型研究背景。 核心成员中有曾在 OpenAI、Anthropic、Google DeepMind 等机构工作或实习的经历。他们对 LLM 的能力边界、行为模式和优化方法有第一手的理解。这让 Hermes 在模型调用策略、提示词工程和上下文管理方面,有着超越普通开源项目的深度。
分布式系统经验。 Agent 本质上是一个长期运行的服务,需要处理并发请求、状态同步、故障恢复等分布式系统的经典问题。Nous Research 的团队在这些领域有丰富的经验,这也是 Hermes 能在架构上做到轻量但稳健的重要原因。
开源社区运营能力。 团队成员中有资深的开源贡献者,深谙如何打造一个健康、活跃的开发者社区。Hermes 项目从发布之初就展现出成熟的开源运营能力——清晰的贡献指南、友好的 Issue 响应、定期的社区更新,这些都源于团队对开源文化的深刻认同。
产品思维与用户洞察。 技术团队往往容易陷入"技术自嗨"的陷阱,做出很多酷炫但不好用的功能。Nous Research 的团队在这方面表现出了难得的克制和清醒。Hermes 的很多设计决策——比如 MEMORY.md 的字符限制、预算机制的安全阀、渐进式技能加载——都体现了"用户第一"的产品思维。
注意
很多初学者容易犯的一个错误是:过度关注项目的技术指标(如 Stars 数、响应速度),而忽略了背后的团队质量和设计理念。其实,一个项目的长期发展潜力,很大程度上取决于它的"基因"——也就是创始团队的技术品味和产品哲学。Nous Research 的团队基因,决定了 Hermes 不是一个急功近利的项目,而是一个有长期主义精神的作品。
1.4 开源理念与商业模式的平衡
在开源世界里,有一个永恒的难题:如何把项目开源出去,同时又能让公司活下去?
这个问题困扰过无数开源项目。有的项目完全免费,最后因为找不到商业模式而夭折;有的项目打着"开源"的旗号,实际上核心功能都要付费,最后被社区抛弃。找到一个平衡点,是每一家长期主义开源公司必须面对的课题。
Nous Research 在这个问题上选择了一条相对务实的路线:核心框架完全开源,商业化围绕增值服务和托管方案展开。
具体来说:
完全开源的部分: Hermes Agent 的完整源代码、所有内置工具、文档和社区资源。任何人都可以免费下载、使用、修改和分发。代码采用宽松的许可证(通常是 MIT 或类似的协议),允许商业使用。
增值服务的部分: Nous Research 计划推出(或已经推出)的付费服务包括: - Nous Portal —— 一个托管式的 Agent 管理平台,让企业和个人用户无需自己搭建服务器就能使用 Hermes - 企业级技术支持 —— 为大型组织提供定制开发、安全审计和性能优化服务 - 高级模型接入 —— 与多家大模型提供商的合作,为用户提供一站式的模型调用和成本优化方案
这种模式的优势在于:开源社区负责创新和扩展,商业服务负责稳定和专业支持。 社区用户可以自由探索 Hermes 的各种可能性,而企业用户可以通过付费服务获得更省心的使用体验。
常见问题
Q:Hermes 会一直保持免费开源吗?
A:根据 Nous Research 的公开声明,Hermes 的核心框架将始终保持开源。未来的商业化方向主要集中在托管服务、企业支持和增值功能上,不会采用"开源引流、闭源收割"的策略。
Q:个人用户需要付费吗?
A:如果你选择自己部署(本地或 VPS),Hermes 是完全免费的。你只需要支付大模型 API 的调用费用(如果使用商业模型),或者使用免费的本地模型。只有当你使用 Nous Research 提供的托管服务时,才需要支付平台费用。
1.5 Nous 的其他产品线
除了 Hermes Agent,Nous Research 还在运营其他几条产品线。了解这些产品,有助于我们更全面地理解这家公司的技术布局。
Nous Portal 是 Nous Research 的旗舰托管服务平台。你可以把它理解为"Hermes 的 SaaS 版本"。对于不想折腾服务器配置、环境搭建和日常运维的用户来说,Nous Portal 提供了一条捷径——注册账号、配置模型、即可开始使用。
Portal 的核心价值在于: - 一键部署 —— 省去本地安装的所有麻烦 - 自动更新 —— 始终使用最新版本的 Hermes - 团队协作 —— 支持多用户、多 Agent 的管理 - 监控面板 —— 可视化的使用统计和成本分析
Tips
对于初学者来说,我的建议是:先在本地或便宜的 VPS 上自己部署一次 Hermes。这个过程虽然有点折腾,但能让你深刻理解系统的各个组件是如何协作的。等你对系统有了感性认识之后,如果确实需要更稳定、更省心的服务,再考虑迁移到 Nous Portal 也不迟。
除了 Portal,Nous Research 还积极参与 AI 领域的学术研究和技术标准制定。他们在 GitHub 上维护了多个开源项目,涉及模型微调、数据处理和评估工具等领域。这些项目虽然不是直接面向终端用户,但为整个 AI 生态的基础设施做出了贡献。
2. "缰绳工程"(Harness Engineering)理念
2.1 什么是缰绳工程——用通俗的比喻解释
现在我们要聊一个非常重要的概念,它是理解 Hermes 设计哲学的钥匙——"缰绳工程"(Harness Engineering)。
这个名字听起来有点抽象,让我用一个生活中常见的场景来解释。
想象一下,你养了一匹小马。这匹小马很聪明,但也很调皮。你不可能用一根铁链把它锁死——那样它会失去活力,变成一具没有灵魂的木偶。你也不可能完全放养——那样它会乱跑乱撞,说不定还会跑到马路上去。
最聪明的做法是什么?给它戴上缰绳。
缰绳不是用来绑死马的,而是用来引导马的。缰绳给了你一种"软控制"的能力——你轻轻一拉,马就知道该往左还是往右;你松开一点,马就可以自由奔跑。缰绳让马在保持自由的同时,不至于跑偏。
"缰绳工程"的核心思想,就是把 AI Agent 看作这匹小马。
传统的 AI 系统开发,往往追求"绝对控制"。开发者试图用复杂的规则、严格的逻辑和详尽的状态机,把 AI 的每一个行为都限定在预设的轨道上。这种方式在某些场景下有效(比如工厂的自动化流水线),但在需要灵活性和创造性的场景下,就会变成一种束缚。
缰绳工程则主张一种不同的思路:不是控制 AI,而是引导 AI。 给 AI 设定边界和安全约束(就像缰绳),但在边界之内,给予它最大的自由度和自主决策空间。AI 可以在框架内探索、尝试、犯错、学习——就像小马在牧场上自由奔跑,但缰绳始终在主人在手中。
2.2 传统 Prompt Engineering 的局限性
在深入缰绳工程之前,我们先回顾一下它的"前辈"——Prompt Engineering(提示词工程)。
Prompt Engineering 是 ChatGPT 时代最火的技能之一。它的基本思路是:通过精心设计的提示词,引导大语言模型输出你想要的内容。比如,你写一段详细的角色设定、输出格式要求和示例,然后让模型按照你的要求来回答。
Prompt Engineering 在早期的确非常有效。很多人在没有任何编程背景的情况下,仅凭写出好的提示词,就能让 AI 完成各种 impressive 的任务。但很快就暴露出了几个根本性的局限:
局限一:提示词越来越长,效果越来越差。
刚开始,一段 100 字的提示词就能让 AI 表现不错。但随着任务复杂度的增加,提示词越来越长——200 字、500 字、1000 字、2000 字……最后你发现,提示词长到模型已经"看不过来"了。上下文窗口被挤爆,模型开始"遗忘"提示词开头的指令,输出质量反而下降。
这就像你给一个人同时交代二十件事,他大概率会漏掉前面几件。人脑的短期记忆有限,AI 的上下文窗口也一样。
局限二:提示词是静态的,无法适应动态变化。
你写的提示词再好,它也是一段固定的文字。但真实世界的任务是动态变化的——今天用户的需求是这样,明天可能完全不一样;这个工具 API 今天还能用,明天可能就更新了接口。
静态的提示词无法自动适应这些变化。每次环境变化,你都要手动修改提示词。对于简单的个人项目,这还能忍受。但对于需要长期运行的 Agent 系统,这简直就是噩梦。
局限三:提示词没有"记忆",每次都要从头教。
这是最致命的一点。每次你跟 AI 开始新对话,它都是一张白纸。你上周花了半天时间教会它你的代码风格和项目规范,这周新开个对话窗口,一切归零,又要重新教一遍。
想象一下,如果你的同事每次见面都忘了你是谁、你们公司在做什么、你们的项目规则是什么——这种合作体验简直让人崩溃。但传统的 Prompt Engineering 就是这样工作的。
局限四:提示词工程高度依赖个人技巧,难以复用和规模化。
写出好的提示词是一门"手艺",需要大量的试错和经验积累。一个资深的提示词工程师写出来的提示词,可能比一个新手的效果好十倍。但这种能力很难传授,更难规模化。你不可能指望每个用户都是提示词专家。
2.3 缰绳工程的核心哲学
缰绳工程正是在看到传统 Prompt Engineering 的这些局限后,提出的一种全新设计范式。
根据 Nous Research 的官方定义,Harness Engineering 包含五个核心层次,它们共同构成了"缰绳"的完整结构:
| 层次 | 英文名称 | 核心问题 | 通俗解释 |
|---|---|---|---|
| 指令层 | Instruction Layer | 如何与模型对话? | 告诉 AI 你的目标是什么,但不规定每一步怎么走 |
| 约束层 | Constraint Layer | 允许做什么? | 划定安全边界,边界之内自由探索 |
| 反馈层 | Feedback Layer | 错误如何回流? | AI 做错了,系统怎么把错误信息传回给 AI,让它学到教训 |
| 记忆层 | Memory Layer | 什么持久化? | 哪些信息值得长期记住,怎么记、怎么检索 |
| 编排层 | Orchestration Layer | 多工具如何串联? | 多个工具怎么协作,任务怎么分解和调度 |
这五个层次不是孤立的,而是像五根绳子拧成一股缰绳,共同引导着 Agent 的行为。指令层告诉 Agent "往哪走",约束层划定 "不能越的界",反馈层确保 "走偏了能拉回来",记忆层让 Agent "记得以前走过的路",编排层则让多个能力 "协调配合"。
在这个框架下,缰绳工程的核心哲学可以概括为四句话:
第一,不是控制 AI,而是引导 AI 自我成长。
缰绳工程认为,最高效的方式不是手把手教 AI 每一步怎么做,而是给它一套好的学习机制,让它自己在实践中成长。就像教育孩子,你不可能替他做完所有作业,但你可以培养他自主学习的能力。
Hermes 的"自学习闭环"就是这个哲学的直接体现。Agent 在完成任务的过程中,自动总结经验、生成技能、优化策略——它越用越聪明,而不是越用越机械。
第二,边界比规则更重要。
传统方法强调"你要做什么"(规则),缰绳工程强调"你不能做什么"(边界)。只要 AI 不触碰安全边界(比如删除重要文件、泄露敏感信息、执行危险命令),它的具体行为方式应该由它自己决定。
这种思路的转变非常关键。规则是刚性的、枚举式的——你列一百条规则,AI 可能会找到第一百零一种出格的方式。边界是柔性的、覆盖式的——只要划定禁区,禁区之外都是自由探索的空间。
第三,有约束的自由才是真正的自由。
这个看似矛盾的表述,其实是缰绳工程的精髓。AI 如果没有约束,会因为"选择过多"而陷入混乱——就像一个人站在十字路口,每个方向都可以走,反而不知道往哪走。适当的约束(如 MEMORY.md 的字符限制、预算机制的安全阀)实际上帮助 AI 聚焦注意力,提高决策质量。
Hermes 的 MEMORY.md 限制在约 2200 字符,USER.md 限制在约 1375 字符。这个设计不是随意定的,而是经过深思熟虑的"有约束的自由"——有限的记忆空间迫使 Agent 学会优先级管理,只保留最重要的信息,而不是把什么都往脑子里塞。
第四,系统应该越用越好,而不是越用越差。
这是缰绳工程与传统系统设计的根本区别。传统的软件系统,用久了往往会积累技术债务,变得越来越臃肿、越来越难维护。而缰绳工程追求的是"有机进化"——系统在使用过程中不断自我优化,就像生物体在环境中不断适应和进化。
Hermes 的技能系统就是一个典型例子。每次你让 Hermes 完成一个复杂任务,它都有可能"领悟"到新的技能,把这些技能保存下来,下次遇到类似任务时直接调用。用得越久,它的"技能库"越丰富,处理任务的效率越高。
2.4 缰绳工程如何影响了 Hermes 的设计
缰绳工程不只是一个抽象的理念,它直接渗透到了 Hermes 的每一个设计决策中。下面我们来看几个具体的例子:
MEMORY.md 和 USER.md 的设计。
传统的 AI 系统要么没有持久记忆(每次对话清零),要么有无限的记忆(导致上下文爆炸)。Hermes 选择了一条中间路线:给记忆设置明确的上限,但允许 Agent 自主决定记什么、忘什么。
这就像一个学生做笔记。如果他试图把老师说的每一个字都记下来,笔记会厚到根本没法复习。聪明的笔记方法是:只记重点、只记自己不懂的、只记可能会考的内容。Hermes 的 Agent 就是这样做的——在有限的记忆空间里,它学会了"精简笔记"的艺术。
预算机制(Budgeting)。
Hermes 有一个内置的预算机制,防止 Agent 在一个任务上无限循环、无限消耗 Token。这个机制就像给 Agent 发了一张"信用卡",卡上有额度限制。Agent 可以自由决定怎么花这笔钱,但花完就得停下来。
这个设计体现了缰绳工程的"引导而非控制"原则。系统没有规定 Agent 每一步该做什么,只是设定了一个宏观的资源约束。Agent 在这个约束内自主规划、自主决策。
技能自动创建。
这是缰绳工程最漂亮的体现之一。传统系统如果要让 AI 掌握新技能,需要开发者手动编写代码或提示词。Hermes 则让 Agent 自己"领悟"技能——在完成复杂任务后,Agent 会自动总结经验,生成可复用的 Skill 文件。
这就像学骑自行车。你不需要读完一本《自行车驾驶手册》才能骑车,而是在一次次摔倒和成功的过程中,身体自己"学会"了平衡。Hermes 的技能系统,就是 Agent 的"肌肉记忆"。
命令审批机制。
对于可能产生副作用的危险操作(如删除文件、执行系统命令),Hermes 会暂停执行,等待用户确认。这个机制就像缰绳上的"紧急制动"——平时你可以自由奔跑,但当你要冲出安全区域时,缰绳会提醒你。
3. OpenClaw 的成功与局限
3.1 OpenClaw 的诞生故事
要理解 Hermes,我们必须先了解它的"前辈"——OpenClaw。这不仅是技术演进的脉络,也是一个充满传奇色彩的开源故事。
OpenClaw 的创始人叫 Peter Steinberger,一位来自奥地利的独立开发者。他的背景很有意思:在创办 OpenClaw 之前,Peter 已经是一位资深的 iOS 开发者,创办过一家成功的移动开发工具公司 PSPDFKit。这家公司后来被收购,给了 Peter 足够的财务自由去做自己想做的事。
2025 年,Peter 开始关注到 AI Agent 这个新兴领域。他当时的观察是:大语言模型已经够聪明了,但缺乏一个"操作系统"来把它们真正组织起来,让它们能够自主完成复杂的任务。就像一个超级大脑,如果没有人告诉它该用什么工具、怎么规划步骤、怎么记忆经验,它也只能干瞪眼。
于是,Peter 开始了一个实验性的项目。他给自己设定的目标很简单:打造一个像数字员工一样的 AI Agent,能够连接各种工具、在各种平台上工作、帮用户自动化地完成日常任务。
这个项目的名字,他取为 OpenClaw。
Tips
OpenClaw 的 Logo 是一只红色的龙虾(Lobster)。为什么选择龙虾?Peter 在采访中开玩笑说,龙虾"看起来很酷,而且和 AI 一样——外表有点吓人,但剥开壳里面其实很美味"。这个玩笑后来演变成了社区文化的一部分,使用 OpenClaw 的用户自嘲为"养虾人"。
OpenClaw 项目在 2025 年 11 月正式发布到 GitHub。发布的方式非常低调——没有新闻发布会,没有媒体通稿,只是 Peter 在自己的社交账号上发了一条简单的推文,附上了 GitHub 链接。
但就是这么一条简单的推文,在 24 小时内引爆了开发者社区。
3.2 OpenClaw 为什么能拿到 309k Stars
发布之后,OpenClaw 的 Star 数量像坐了火箭一样往上窜。短短几个月,就突破了 10 万、20 万、30 万……截至目前,OpenClaw 的 GitHub Stars 已经超过 309,000,成为 GitHub 上最火爆的 AI 项目之一。
这个增长速度在开源历史上都是罕见的。OpenClaw 为什么能这么火?让我们拆解一下它的成功密码。
密码一:解决了一个真实存在的痛点。
2025 年的开发者们,已经习惯了每天在各种工具之间切换:Slack 上回消息、GitHub 上审代码、Notion 里写文档、Linear 上管项目、邮件客户端里处理邮件……工具越来越多,切换成本越来越高,人就像一个"人肉路由器",在各个 SaaS 之间疲于奔命。
OpenClaw 给出的解决方案是:让 AI 当这个路由器。 你只需要告诉 Agent 要做什么,它就会自动调用各种工具、在各个平台之间穿梭、把任务完成。这种"一站式自动化"的愿景,击中了无数人的痛点。
密码二:创始人个人魅力与社区运营。
Peter Steinberger 不是一个躲在代码后面的"技术宅"。他非常活跃地在社交媒体上分享项目的进展、回答用户的问题、甚至直播写代码。这种"创始人即社区核心"的模式,在早期为项目积累了大量的忠实拥趸。
更重要的是,Peter 展现了一种非常难得的姿态:谦卑且开放。 他经常说"我不知道"、"这个设计可能有问题"、"欢迎大家来挑战我的想法"。这种态度在科技创始人中非常少见,也让社区成员感到被尊重和接纳。
密码三:时机把握得恰到好处。
OpenClaw 发布的时间点,是 AI Agent 概念开始从极客圈走向主流市场的关键节点。2025 年下半年,ChatGPT 的热潮已经持续了两年多,人们不再满足于"对话式 AI",开始渴望"能做事的 AI"。OpenClaw 正好踩在了这个需求拐点上。
密码四:产品设计简洁直观。
OpenClaw 的安装过程简单到令人惊讶。本地安装只需要两行命令;Docker 部署只需要一个 docker-compose.yaml 文件。对于习惯了复杂配置的企业软件的开发者来说,这种"即插即用"的体验简直是一种解脱。
密码五:开源且自托管。
在数据隐私越来越受重视的时代,"自托管"是一个巨大的卖点。很多企业不愿意把自己的数据交给第三方 AI 服务商,OpenClaw 的"数据完全自控"承诺,让它在企业用户中获得了大量青睐。
3.3 OpenClaw 的核心优势
平心而论,OpenClaw 确实是一款优秀的产品。它的核心优势可以概括为以下四个方面:
优势一:万能网关。
OpenClaw 的设计哲学是"把一切连接起来"。它支持接入 20+ 种大语言模型(从 GPT-4 到 Claude 到 DeepSeek 到本地模型),可以通过一个统一的 Fallback 链机制,在主模型失败时自动切换到备用模型。这种"一个入口、多模型支撑"的设计,让用户不必担心某个模型宕机或服务降级。
# OpenClaw 的模型 Fallback 链配置示例
# 主模型失败 → 自动切换到备选模型 → 兜底到本地模型
models:
primary: claude-sonnet-4 # 主力模型,效果最好
fallback: gpt-4.1 # 备选模型
local: llama-3.3-70b # 本地模型,零成本兜底
优势二:多平台覆盖。
OpenClaw 支持 26+ 个消息平台和通信渠道,堪称"无所不在"。从国际主流平台(Telegram、Discord、Slack、WhatsApp)到中国本土平台(微信、飞书、企业微信、钉钉、QQ),再到邮件、短信、智能家居(Home Assistant),几乎没有它不能接入的渠道。
对于企业用户来说,这意味着可以复用已有的沟通基础设施,不需要为了用 AI 而强迫员工切换到新的平台。
优势三:庞大的社区生态。
OpenClaw 的社区规模令人咋舌: - GitHub Stars:309,000+ —— 全球 AI 开源项目中名列前茅 - 贡献者:1,075+ —— 来自世界各地的开发者为项目贡献代码 - ClawHub 技能:13,700+ —— 社区贡献的技能数量庞大 - 国内用户:100,000+ —— 仅中国就有超过十万活跃用户
这个庞大的社区为 OpenClaw 带来了丰富的第三方扩展、活跃的讨论氛围和快速的问题响应。
优势四:Unix 哲学的设计简洁性。
Peter Steinberger 是 Unix 哲学的坚定信徒。Unix 哲学的核心是"做一件事,并把它做好"。OpenClaw 把这个理念发挥到了极致——它的核心功能只围绕四个基本工具展开:
| 工具 | 功能 |
|---|---|
| Read | 读取文件内容 |
| Write | 写入文件内容 |
| Edit | 编辑已有文件 |
| Bash | 执行系统命令 |
这种极简设计有两个好处:一是容易理解和上手,二是为第三方扩展留下了清晰明确的接口。
Tips
Peter 有一句名言:"MCP 是垃圾,CLI 才是终极接口。"这句话在开发者社区引发了很大的争议。它的核心意思是:与其用复杂的协议(如 MCP)来定义工具接口,不如直接用命令行接口(CLI)这种最简单、最通用的方式。这种观点有它的道理——简单意味着更少出错、更容易调试、更易于跨平台兼容。但 MCP 的支持者则认为,标准化的协议对于生态的长远发展至关重要。这场争论至今仍在继续,也是 Hermes 选择同时支持原生工具和 MCP 的原因之一。
3.4 OpenClaw 的痛点
但正如每一枚硬币都有两面,OpenClaw 在取得巨大成功的同时,也暴露出了一些让社区用户头疼的问题。这些问题,恰恰成了 Hermes 诞生的契机。
痛点一:需要手动编写 SOUL.md。
SOUL.md 是 OpenClaw 用来定义 Agent 人格和行为的配置文件。这个文件本质上是一段"超级提示词",你需要在里面写明 Agent 的角色、性格、工作方式、可用工具、注意事项等等。
对于一个简单的个人项目,写一次 SOUL.md 还能接受。但如果你要管理多个 Agent、每个 Agent 有不同的性格和职责,这个工作量就呈指数级增长。更麻烦的是,每次你要调整 Agent 的行为,都要手动修改 SOUL.md,然后重启服务才能生效。
想象一下,如果你的同事每次改变工作方式,都要你亲手写一份"性格说明书"给他——这种体验显然不够智能。
痛点二:配置复杂,上手门槛不低。
虽然 OpenClaw 的安装本身很简单,但要真正把它配置好用起来,却需要相当多的知识储备。你需要理解: - 各种消息平台的 Webhook 配置 - 不同模型的 API 格式和参数调优 - SOUL.md 的语法规则和最佳实践 - 各种工具的配置和权限管理 - Docker 网络和安全组设置(如果你用 Docker 部署)
对于非技术背景的用户来说,这个学习曲线相当陡峭。很多初学者在安装完 OpenClaw 之后,卡在了配置环节,最后只能放弃。
痛点三:规则维护困难。
OpenClaw 的行为很大程度上依赖于你在 SOUL.md 和各种配置文件中定义的规则。这些规则是静态的——它们不会随着使用过程而自动调整。
举个例子:你在 SOUL.md 里规定 Agent"每天早上 9 点检查邮件并发送摘要"。这个规则一直有效,直到有一天你的作息变了,想改成 10 点。你需要手动修改配置文件,重启服务。如果 Agent 在实际运行中发现"9 点的时候邮件服务器经常响应慢,10 点反而更顺畅",它也不会自己调整——因为它没有自学习的能力。
痛点四:没有自学习能力。
这可能是 OpenClaw 最根本的局限。Agent 每次对话都是"从零开始",它不会记住上次对话中积累的经验,不会从错误中学习,不会随着时间推移变得越来越懂你。
是的,OpenClaw 有会话历史和 USER.md 这样的用户偏好文件,但这些是"记忆"而不是"学习"。记忆是"我记得你说过什么",学习是"我从中悟出了更好的做法"。OpenClaw 做到了前者,但没有做到后者。
打个比方:OpenClaw 就像一个每次见面都要重新认识你的熟人。虽然你每次都会告诉他你的偏好(USER.md),但他不会主动总结规律、不会提前预判你的需求、不会在多次交流后变得越来越默契。
痛点五:技能质量参差。
ClawHub 上虽然有 13,700+ 个技能,但质量参差不齐。有的技能写得很优秀,有的则是"Hello World"级别的示例。由于缺乏自动化的质量评估和审核机制,用户在海量技能中筛选出好用的那个,本身就是一项耗时的工作。
3.5 "养虾"文化的形成
OpenClaw 的龙虾 Logo,不仅是一个品牌形象,更演变成了一种独特的社区文化。
起初,只是少数用户在社交媒体上开玩笑,说自己"在养龙虾"。慢慢地,这个称呼在社区中流传开来: - 使用 OpenClaw 的人叫"养虾人" - 搭建 OpenClaw 环境叫"建虾塘" - 调试配置叫"喂虾" - 遇到 Bug 叫"虾病了" - 解决问题叫"虾好了"
这种拟人化的语言,让技术社区多了一层温情和趣味。"养虾"不再是冷冰冰的技术操作,而是一种有温度的"饲养"关系。用户和 Agent 之间,像是主人和宠物之间的关系——你需要照顾它、调教它、陪伴它成长。
Tips
"养虾"文化的形成,其实揭示了一个深层的心理现象:人们天然倾向于与有自主性的系统建立情感连接。当你把 Agent 称作"虾"、把维护它叫做"养",你就在潜意识中把它从一个"工具"升级为了"伙伴"。这种心理暗示,反过来也会增强用户的投入感和耐心——你不会因为"工具"偶尔出错而生气,但你会因为"宠物"生病而着急。
"养虾"文化还催生了一系列周边创作:龙虾表情包、养虾人专属头像、"虾塘管理指南"等。这些社区自发产生的内容,进一步增强了 OpenClaw 的凝聚力和传播力。
4. 从 OpenClaw 到 Hermes:进化之路
4.1 Hermes 解决了 OpenClaw 的哪些痛点
如果说 OpenClaw 是一座繁华但略显混乱的"老城区",那么 Hermes 就是一座经过精心规划的"新城"。它不是推倒重来,而是在继承 OpenClaw 优秀基因的基础上,针对核心痛点进行了系统性的重构和升级。
让我们逐一看看 Hermes 是如何解决 OpenClaw 的那些痛点的。
解决痛点一:SOUL.md 的手动维护问题。
Hermes 彻底改变了 Agent 人格的定义方式。它不再依赖一个庞大的静态配置文件,而是通过 USER.md 和 MEMORY.md 的组合,实现动态、自适应的人格建模。
USER.md 存储用户的偏好和画像——你喜欢什么样的沟通风格、你常用的技术栈、你的工作习惯。这个文件不是一次性写死的,而是在使用过程中不断被 Agent 更新和完善。
MEMORY.md 则存储 Agent 在运行过程中积累的经验教训、工作约定、环境信息。它就像 Agent 的"工作笔记",每次任务完成后,Agent 都会反思"这次我做对了什么、做错了什么、下次可以怎么改进",然后把结论写进 MEMORY.md。
# MEMORY.md 示例片段
# 这是 Hermes Agent 自动维护的记忆文件
## 环境信息
- 项目根目录: /home/user/projects/myapp
- Python 版本: 3.11
- 常用框架: FastAPI, SQLAlchemy
## 工作约定
- 写代码前先写测试
- commit message 用英文,遵循 conventional commits 规范
- 优先使用 async/await 而非同步调用
## 经验教训
- 2026-04-10: 调用 Docker API 时注意权限,需要把用户加入 docker 组
- 2026-04-12: 用 requests 库访问本地服务时,localhost 要写成 127.0.0.1
注意
MEMORY.md 有一个约 2200 字符的限制。这个限制不是缺陷,而是刻意设计的"约束"。它迫使 Agent 像人类一样学会"精简笔记"——只保留最重要的信息,而不是把每一个细节都记下来。如果 Agent 试图写超过限制的内容,系统会自动触发"记忆压缩",用 LLM 摘要的方式精简内容。这就像你笔记本快写满了,不得不重新整理,把最重要的留下,次要的删掉。
解决痛点二:配置复杂的问题。
Hermes 用一套交互式的 CLI 命令,把配置过程变得极其简单。你不需要手动编辑各种配置文件,只需要运行几个命令,按提示回答几个问题,系统就自动帮你配置好了。
# Hermes 的交互式配置,保姆级简单
hermes setup # 启动完整的配置向导
hermes model # 选择并配置大模型提供商
hermes gateway setup # 配置消息平台接入
hermes tools # 启用/禁用工具
每个命令都有清晰的提示和默认值,即使你是第一次接触 Hermes,也能在几分钟内完成基础配置。
解决痛点三:规则维护困难。
Hermes 用"技能系统"替代了静态的规则定义。当你需要 Agent 执行某种特定任务时,不需要在配置文件中写规则,而是直接告诉 Agent 你的需求。如果这是一个复杂任务(涉及 5 个以上工具调用),Agent 会自动创建一个 Skill 文件,把任务的执行流程固化下来。
下次遇到同样的任务,Agent 会直接调用这个 Skill,而不是重新推理一遍。如果 Skill 中的某个步骤出了问题(比如某个 API 的接口变了),Agent 会自动检测错误、修复 Skill、然后继续执行。
这就像是:你请了一位厨师来家里做饭。第一次,你需要详细告诉他每一步怎么做(对应复杂任务的首次执行)。第二次,他记住了你的口味和做法,直接上手就行(对应 Skill 的复用)。如果某个食材买不到了,他自己会找替代品,不用你重新教(对应 Skill 的自动修复)。
解决痛点四:缺乏自学习能力。
这是 Hermes 最大的差异化优势。我们后面会有专门的章节详细讲解"自学习闭环",这里先简要介绍。
Hermes 的 Agent 在每次完成任务后,都会进行一次"复盘": 1. 执行 —— 用工具完成任务 2. 评估 —— 判断任务是否成功、有哪些可以改进的地方 3. 创建 —— 如果是复杂任务,自动生成 Skill 文件 4. 改进 —— 下次使用时,基于新的经验优化 Skill
这个过程完全自动化,不需要用户干预。Agent 就像一个有上进心的实习生,每次做完事都会自我反思,争取下次做得更好。
解决痛点五:技能质量问题。
Hermes 采用了"渐进式加载"的机制来管理技能。技能不是一次性全部塞进上下文,而是分层次加载: - Level 0:只加载技能列表(约 3k tokens) - Level 1:当 Agent 决定调用某个技能时,加载该技能的完整内容+元数据 - Level 2:如果技能需要参考特定文件,再加载这些文件
这种分层加载的方式,既保证了 Agent 能访问到所有技能,又避免了上下文被大量技能描述撑爆。
同时,Hermes 的技能生态虽然规模上不如 ClawHub(目前约 639 个技能 vs 13,700+),但质量控制和审核机制更严格。官方技能都经过测试验证,社区技能也有评级和评论系统。
4.2 核心区别对比
为了让读者更直观地理解 Hermes 和 OpenClaw 的差异,我们用一张表格来做一个全面的对比:
| 对比维度 | Hermes Agent | OpenClaw |
|---|---|---|
| Stars | 104,791(2个月爆发增长) | 309k+(社区规模最大) |
| 主语言 | Python 93.6% | TypeScript 90.3% |
| 架构风格 | 轻量级 Python | 重 Node.js 网关 |
| 学习能力 | 自动创建并修复技能 | 需手动创建技能 |
| 平台支持 | 15+ | 26+ |
| 技能数量 | 639(官方+社区) | 13,700+(质量参差) |
| 记忆系统 | 有机进化(四层温度模型) | 模块化(SOUL.md + USER.md + Session) |
| 人格定义 | USER.md + MEMORY.md 动态适配 | SOUL.md 静态配置 |
| 安全体系 | 命令审批 + 沙箱执行 | 分级沙箱(业界最佳实践) |
| 移动应用 | 暂无 | iOS / Android |
| 成本控制 | Fallback 链 + 预算机制 | Fallback 链 |
| 安装复杂度 | 3 条命令 + 交互式配置 | 2 条命令 + 手动配置 |
| 社区文化 | "养马" | "养虾" |
| 自托管 | 完全支持 | 完全支持 |
| 数据迁移 | 支持 hermes migrate openclaw |
原生支持 |
常见问题
Q:从表格看,OpenClaw 在平台支持和技能数量上明显占优,那为什么要选 Hermes?
A:这是一个非常好的问题。选哪个项目,取决于你的核心需求。如果你最看重的是"多平台覆盖"和"技能数量",OpenClaw 确实更适合你。但如果你更看重"长期陪伴价值"和"越用越聪明"的体验,Hermes 的自学习能力和有机记忆系统会带来完全不同的使用感受。就像选手机:有人选 Android 是因为开放性和丰富的 App 生态,有人选 iPhone 是因为流畅的系统和生态协同——没有绝对的好坏,只有适不适合。
Q:Hermes 的技能数量这么少,够用吗?
A:639 个技能看似不多,但 Hermes 的 Skill 自动创建机制意味着:你不需要等待别人写好技能,Agent 自己就能生成你需要的技能。很多用户反馈,用 Hermes 一段时间后,他们发现自己创建的自定义 Skill 比从市场下载的第三方 Skill 更贴合自己的需求。数量不等于质量,更不等于适用性。
4.3 为什么说 Hermes 是 OpenClaw 的"进阶版本"
"进阶版本"这个定位,可能会让一些 OpenClaw 的忠实用户感到不适。毕竟,OpenClaw 是一款非常成功的产品,把它说成"被进阶的对象",似乎有些不尊重。
但我要强调的是:Hermes 不是 OpenClaw 的替代品,也不是它的竞争对手。它们是满足不同需求的两条路径。
用更准确的表述:Hermes 是 OpenClaw 理念的一个"进化分支"。
这个进化体现在三个层面:
第一层:从"工具使用"到"经验沉淀"。
OpenClaw 的核心能力是让 AI"使用工具"。它能调用各种 API、读写文件、执行命令——本质上是一个超级强大的"工具调用器"。
Hermes 在保留工具调用能力的基础上,增加了一层"经验沉淀"。Agent 不只是用工具,还会总结使用工具的经验,形成可复用的知识(Skill)。这种从"执行"到"学习"的跃迁,是质的提升。
打个比方:OpenClaw 像是一个会十八般武艺的武师,每次出招都很漂亮。Hermes 像是一个不仅会武功、还会自创招式的宗师——每次战斗后,他都能领悟新的招式,写进自己的武功秘籍。
第二层:从"静态配置"到"动态适应"。
OpenClaw 的人格和行为,很大程度上由配置文件决定。SOUL.md 写好了,Agent 就按这个剧本演。剧本改起来麻烦,而且 Agent 不会根据实际互动来调整。
Hermes 的人格是"生长出来"的。USER.md 和 MEMORY.md 在使用过程中不断被更新,Agent 对用户越来越了解,回复越来越贴合用户的习惯和偏好。这不是配置的功劳,而是"相处"的结果。
就像两个朋友:一个是你看了他的简历才了解他(静态配置),一个是你和他相处了三年越来越默契(动态适应)。哪种关系更深厚,不言而喻。
第三层:从"社区共享"到"个人专属"。
OpenClaw 的技能生态是"社区共享"模式——你下载别人写的技能,上传到 ClawHub 给别人用。这个模式有利于生态繁荣,但也带来了一个问题:你的 Agent 和别人的 Agent,用的都是同一套技能,缺乏个性化。
Hermes 的技能系统是"个人专属"模式。Agent 自动创建的技能,是基于你自己的工作习惯、项目环境和使用偏好生成的。你的 Hermes 和别人的 Hermes,虽然底层框架一样,但积累的技能和经验是完全不同的。
这就像两棵同品种的树:种在同一片森林里,但因为阳光、水分和土壤的差异,长出了完全不同的形态。
4.4 数据迁移支持:一键迁移
考虑到 OpenClaw 庞大的用户基础,Nous Research 做了一个非常贴心的设计:支持从 OpenClaw 一键迁移到 Hermes。
# 从 OpenClaw 迁移到 Hermes,只需要一条命令
hermes migrate openclaw
# 系统会提示你确认迁移的内容
# - 配置文件转换
# - SOUL.md → USER.md + MEMORY.md 的映射
# - 技能文件的格式转换
# - 历史对话数据的导入(可选)
这条命令背后做了大量复杂的工作:
- 配置转换 —— OpenClaw 的 YAML/JSON 配置,自动映射为 Hermes 的配置格式
- 人格迁移 —— SOUL.md 中的角色设定和行为规则,智能拆分到 USER.md 和初始 MEMORY.md
- 技能转换 —— OpenClaw 的技能文件格式转换为 Hermes 的 Skill 格式
- 数据导入 —— 可选地将历史对话导入 Hermes 的 SQLite 数据库,供 Agent 检索参考
Tips
迁移不是简单的"复制粘贴",因为两个系统的架构差异很大。建议迁移后,花一些时间和新的 Hermes Agent"重新认识"——多对话、多任务,让 Agent 快速积累对你的了解。迁移后的第一周,Agent 可能表现得不如你之前调好的 OpenClaw 那么"顺手",但请给它一点时间。两周后,你很可能会发现 Hermes 的表现已经超越了之前精心调教的 OpenClaw。
4.5 "养马"文化的兴起
Hermes 这个名字本身就有很深的文化内涵。
在希腊神话中,Hermes(赫尔墨斯)是众神的使者,掌管商业、旅行、盗窃和语言。他是奥林匹斯山上最聪明、最敏捷的神,能自由穿梭于神界、人界和冥界之间。他穿着带翅膀的凉鞋,手持双蛇杖——这形象简直就是"信息高速公路"的古希腊版本。
而"Hermes"这个词,在现代语境中还有一个更知名的含义:爱马仕(Hermès),那个法国奢侈品牌。
注意
Hermes Agent 和爱马仕(Hermès)品牌没有任何关系。它们只是共享了同一个名字的词根。Nous Research 取名 Hermes,显然是取自希腊神话中的信使之神,而非法国奢侈品牌。
但社区用户才不管这些呢。既然名字都叫 Hermes 了,那使用 Hermes 的用户,自然就被戏称为"养马人"了。
"养马"文化的形成过程,和"养虾"非常相似: - 使用 Hermes 的人叫"养马人" - 搭建 Hermes 环境叫"建马厩" - 配置 Agent 叫"调教马匹" - 让 Agent 学习新技能叫"训练赛马" - Agent 表现出色叫"马儿跑得快" - 遇到 Bug 叫"马儿闹脾气"
"养马"和"养虾"这两个称呼,在社交媒体上形成了有趣的互动。两个社区的用户经常互相调侃: - "虾塘改马厩了,龙虾升级成汗血宝马" - "养虾三年不如养马三月,因为马会自己学会奔跑" - "虾是变温动物,马是恒温动物——Hermes 的记忆系统让 Agent 有了'体温'"
这些玩笑背后,其实反映了两个项目在设计哲学上的差异:OpenClaw 的 Agent 更像"宠物"——你需要喂它、照顾它、教它做事;Hermes 的 Agent 更像"伙伴"——它能自己学习、自己成长,你们的关系是双向的、共同进化的。
Tips
社区文化的价值往往被低估。一个有趣的社区称呼、一套共通的"黑话"、一批高质量的表情包,这些看似"不正经"的东西,实际上是社区凝聚力的重要来源。它们降低了新人融入的门槛,增加了老用户的归属感,还为项目的传播提供了天然的社交货币。如果你要运营一个开源项目,千万别忽视"文化建设"这件事。
5. 两个月 104,791 Stars 的爆发之路
5.1 发布时间线与里程碑事件
Hermes Agent 的发布,堪称开源项目传播史上的一个经典案例。它不是那种"发布会上一炮而红"的类型,而是像一颗种子落入沃土,在合适的气候条件下,以惊人的速度生根发芽、茁壮成长。
让我们按照时间线,回顾一下 Hermes 从发布到爆发的关键节点。
2026 年 2 月初:内测与预热
在正式发布之前,Nous Research 进行了一轮小范围的内测。参与内测的主要是 Nous Research 的核心社区成员、一些友好的开发者,以及少数受邀的技术媒体。
内测期间,团队收集了大量的反馈,修复了不少 Bug,最重要的是——验证了"自学习闭环"这个核心机制在实际使用中的效果。内测用户的反馈非常积极,很多人在社交平台上开始"剧透",引发了不少人的好奇。
2026 年 2 月中旬:正式发布
Hermes Agent 在 GitHub 上正式开源。发布的方式和 OpenClaw 类似——低调、直接、没有花里胡哨的营销。Nous Research 的官方账号发了一条简单的推文,附上了 GitHub 仓库链接和一段简短的项目介绍。
但和 OpenClaw 不同的是,Hermes 发布时已经有了一个"故事"可以讲——它是如何从 OpenClaw 的土壤中生长出来的、它解决了哪些 OpenClaw 没能解决的问题、它的自学习机制是如何工作的。这个故事在社交媒体上迅速传播,因为很多 OpenClaw 的用户对此有共鸣。
发布第一天,GitHub Stars 突破了 5,000。
2026 年 2 月下旬:第一波口碑爆发
发布后的第一周,第一批"吃螃蟹"的用户开始在社交媒体上分享自己的使用体验。
最火的一个帖子是这样的:
"我让 Hermes 帮我整理一个乱的像战场一样的代码仓库。它不仅整理了代码结构,还自动创建了一个'代码整理'的 Skill。三天后我又有一个仓库要整理,我只需要说'像上次一样整理这个仓库',它就自己调用了之前创建的 Skill,全程不需要我干预。这感觉……就像养了一只越来越懂你的猫。"
这个帖子在 Twitter/X 上获得了数万点赞和转发,直接把 Hermes 推上了 GitHub Trending 榜首。
2026 年 3 月初:技术媒体集中报道
随着口碑的扩散,主流技术媒体开始关注这个项目。
- Hacker News 上出现多个关于 Hermes 的讨论帖,最热门的一个有超过 800 条评论
- Reddit 的 r/MachineLearning、r/selfhosted、r/LocalLLaMA 等子版块出现了大量讨论
- Product Hunt 上的发布获得了当日最佳产品的称号
- 多家中文技术媒体(机器之心、InfoQ、36氪等)发布了深度报道和评测
媒体的关注带来了新一轮的用户增长。发布一个月后,GitHub Stars 突破了 50,000。
2026 年 3 月中旬:OpenClaw 用户的"迁移潮"
一个意想不到的催化剂出现了——OpenClaw 社区内部发生了一次关于项目方向的激烈争论。
争论的焦点是:OpenClaw 是否应该引入自学习能力。一部分社区成员认为,OpenClaw 应该保持简洁,不要在核心架构上做大的改动;另一部分则认为,自学习是 Agent 的必备能力,OpenClaw 如果不跟上就会落后。
这场争论没有得出结论,但却让很多人开始关注"隔壁的 Hermes"。不少 OpenClaw 的长期用户抱着"试一试"的心态安装了 Hermes,结果很多人"试完就回不去了"。
2026 年 3 月下旬:首次重大更新
Nous Research 发布了 Hermes 的首个重大版本更新(v0.2.0),带来了多项社区呼声很高的功能: - 支持更多的大模型提供商(包括几家国产模型) - 改进了 Skill 的自动修复机制 - 增加了对 Honcho 用户建模模块的集成 - 优化了 SQLite 数据库的查询性能
这次更新展示了团队的快速迭代能力,也进一步增强了社区的信心。
2026 年 4 月中旬:Stars 突破 104,791
截至 2026 年 4 月中旬(也就是本书写作的时间),Hermes 的 GitHub Stars 已经突破了 104,791,而且增长势头依然强劲。
5.2 社区反响与技术媒体评价
让我们看看社区和技术媒体是怎么评价 Hermes 的。
开发者社区的评价:
"我用了 OpenClaw 四个月,调了不知道多少次 SOUL.md,Agent 还是经常'失忆'。换到 Hermes 两周后,它已经开始主动建议我'上次你用这种方式处理 Excel 数据效果不错,这次要不要也试试?'——这就是我想要的感觉。" —— Hacker News 用户 @devguru
"作为一个 Python 开发者,Hermes 的代码库读起来太舒服了。架构清晰、注释到位、没有过度工程化。对比 OpenClaw 的 TypeScript 代码(虽然也很优秀),Hermes 更像是一个'Pythonic'的项目。" —— Reddit 用户 u/pythonista_forever
"最让我惊喜的不是自学习功能本身,而是它的'收敛性'。我原以为 Agent 学得越多会越混乱,但 Hermes 的 MEMORY.md 字符限制反而迫使它学会了'抓重点'。这个设计真的太聪明了。" —— GitHub Issue 评论
技术媒体的评价:
"Hermes Agent 代表了 AI Agent 设计范式的转变——从'提示词工程'到'缰绳工程',从'静态配置'到'动态进化'。这不仅仅是技术细节的改进,而是对'AI 应该如何与人类协作'这个问题给出了全新的答案。" —— 机器之心
"如果说 OpenClaw 是 AI Agent 的'Windows'——功能丰富、生态庞大、适合大多数人;那么 Hermes 就是 AI Agent 的'macOS'——设计精致、体验流畅、越用越顺手。两者没有绝对的好坏,但 Hermes 确实在一些关键体验上做到了差异化。" —— InfoQ
"Nous Research 用 Hermes 证明了一件事:开源项目的成功,不取决于你有多少资源,而取决于你的设计理念是否切中用户的深层需求。6500 万美元的融资额在 AI 圈不算多,但 Hermes 的影响力已经超越了数倍于它的项目。" —— 36氪
一些争议性的声音:
当然,也不是所有评价都是正面的。一些批评的声音同样值得关注:
"Hermes 的技能数量只有 OpenClaw 的零头,对于需要大量现成技能的用户来说,这确实是个短板。虽然自动创建技能很酷,但第一次执行复杂任务时的等待时间和 Token 消耗,不是每个人都能接受的。" —— 某技术博主
"'缰绳工程'这个理念听起来很美好,但在实际使用中,Agent 有时候会因为'过于自由'而做出让人意外的行为。有几次它自动创建的 Skill 包含了一些不够安全的操作,幸好命令审批机制拦住了。这个机制还需要更成熟。" —— GitHub Discussion
"Hermes 没有移动 App,这对习惯在手机上管理 Agent 的用户来说很不方便。OpenClaw 的 iOS 和 Android App 虽然功能简单,但至少能随时查看 Agent 的状态和对话历史。" —— Reddit 讨论
这些批评都是合理的。任何项目都有它的局限性和适用边界,正视这些局限性,才能做出更理性的技术选型。
5.3 与其他项目增长速度对比
为了更直观地感受 Hermes 的增长速度,我们把它和 GitHub 上其他知名的 AI 项目做一个对比:
| 项目 | 发布日期 | 达到 50k Stars 用时 | 达到 100k Stars 用时 |
|---|---|---|---|
| Hermes Agent | 2026 年 2 月 | ~30 天 | ~60 天(预计) |
| OpenClaw | 2025 年 11 月 | ~45 天 | ~90 天 |
| LangChain | 2022 年 10 月 | ~180 天 | ~300 天 |
| AutoGPT | 2023 年 3 月 | ~14 天 | ~45 天 |
| Ollama | 2023 年 6 月 | ~120 天 | ~240 天 |
从表格可以看出,Hermes 的增长速度仅次于 AutoGPT(AutoGPT 在 2023 年因为 ChatGPT 概念的火热而经历了极端爆发式增长),但远超 LangChain 和 Ollama 等项目的早期增速。
需要注意的是,Stars 数量并不等同于项目的实际价值或质量。AutoGPT 在快速达到 100k+ Stars 之后,因为实际体验与预期差距较大,社区活跃度有所下降。而 LangChain 虽然增速较慢,但建立了非常坚实的开发者生态,成为很多企业级应用的基础设施。
所以,评价一个开源项目,Stars 只是一个参考指标,更重要的是:社区活跃度、Issue 响应速度、版本迭代频率、实际用户的留存率。
5.4 为什么 Hermes 能如此快速增长
Hermes 的快速崛起,不是偶然,而是多个因素共振的结果。
因素一:踩准了"从玩具到工具"的转型节点。
2025 年到 2026 年,AI Agent 领域正在经历一个关键的转型:从"好玩的 demo"转向"真正有用的工具"。
早期的 AI Agent(如 AutoGPT)给人们展示了"AI 可以自主做事"的可能性,但实际用起来问题很多——无限循环、资源消耗爆炸、输出质量不稳定。这些问题让很多早期用户"乘兴而来、败兴而归"。
到了 2026 年,用户的心态变了。他们不再满足于"AI 能做很酷的事",而是要求"AI 能可靠地帮我完成日常工作"。Hermes 的自学习机制和持久记忆,正好满足了这个进阶需求。
因素二:差异化定位清晰。
在 OpenClaw 已经占据了"大而全"的定位之后,Hermes 没有选择正面硬刚,而是找到了一个清晰的差异化切入点——"自进化"和"长期陪伴"。
这个定位非常聪明。它不需要在平台数量、技能数量上超越 OpenClaw,只需要在一个关键维度上做到独特且有价值,就能吸引一批忠实的用户群体。
Tips
在竞争激烈的市场中,"差异化"比"全面超越"更重要。OpenClaw 已经是"全能型选手"了,如果 Hermes 也走全能路线,只会被压一头。但 Hermes 选择了"专精型"路线——在"自学习"这个单点上做到极致,反而开辟了一片新天地。这个策略,值得所有创业者和产品经理学习。
因素三:迁移成本低。
hermes migrate openclaw 这条命令,是 Hermes 增长策略中一个极其精妙的设计。
它解决了一个核心问题:如何让用户尝试新产品时没有心理负担?
如果你要放弃用了几个月的 OpenClaw,从头开始学习一个新系统,这个切换成本很高——你要重新配置、重新调教、重新建立工作流。但 Hermes 告诉你:"你只需要一条命令,所有东西都能搬过来。"这种低迁移成本,大大降低了用户尝试的门槛。
因素四:社区传播的"社交货币"效应。
"养马"这个梗,以及"从养虾到养马"的故事,为 Hermes 的传播提供了天然的社交货币。
人们在社交媒体上分享 Hermes,不仅仅是在分享一个工具,更是在分享一个有趣的故事、一种身份认同("我是养马人")、一次有趣的体验("我的 Agent 居然自己学会了新技能")。这种带有情感色彩的分享,比干巴巴的技术介绍传播力要强十倍。
因素五:技术实现的成熟度。
最后但同样重要的是,Hermes 的技术实现确实过硬。自学习闭环不是一个简单的概念,它需要精巧的触发机制、可靠的 Skill 生成算法、有效的错误恢复策略。如果这些技术细节做得不好,"自学习"就会变成"自乱学习",Agent 越用越糊涂。
从社区的实际反馈来看,Hermes 的自学习机制在大多数情况下表现稳定,这是它能够留住用户、形成口碑的根本原因。
6. "养马" vs "养虾":社区文化解读
6.1 命名隐喻的来历
我们在前面已经简单介绍了"养虾"和"养马"这两个称呼的由来,但社区文化的丰富程度远不止于此。这一节,我们来深入解读这两种社区文化的差异和内涵。
"养虾"的由来:
OpenClaw 的 Logo 是一只红色的龙虾。这个设计选择本身就很反常识——大多数科技公司的 Logo 会选择抽象的几何图形或字母组合,而 OpenClaw 却选了一个具象的海洋生物。
Peter Steinberger 的解释是:龙虾看起来有点"怪异"甚至"吓人"(就像 AI 对于普通人一样),但它其实是一种美味且营养丰富的食材。剥开坚硬的外壳,里面是鲜嫩的肉质。这个隐喻,恰好对应了 OpenClaw 的产品定位——外表看起来技术门槛高,但真正用起来会发现非常实用。
社区用户很快就接受了这个形象,并且开始了各种二次创作。有人把龙虾画成了卡通形象,有人做了龙虾表情包,还有人设计了"养虾人"的专属徽章。
"养马"的由来:
Hermes 的情况则更有趣。项目名称 Hermes 本身没有动物的意象,它来自希腊神话中的信使之神。但"Hermes"这个词,在中文互联网语境中,首先让人联想到的不是神话,而是爱马仕(Hermès)——那个以马具起家的法国奢侈品牌。
爱马仕的 Logo 正是一辆马车。所以,当 Hermes Agent 进入中文社区时,"马"的意象几乎是自动浮现的。
但"养马"这个称呼的流行,还有更深一层的心理因素。在中国文化中,马象征着力量、速度、智慧和忠诚。"宝马"、"千里马"、"汗血宝马"——这些词汇都带有正面的情感色彩。相比之下,龙虾在中文语境中虽然也是美食,但缺乏这种文化层面的积极联想。
Tips
品牌命名的"文化适配性"是一个很有意思的话题。Hermes 项目在英文社区中,强调的是"信使之神"的意象——速度、沟通、连接。但在中文社区中,"爱马仕"的联想反而成为了更强大的文化锚点。这提醒所有做全球化产品的团队:同一个名字,在不同文化语境中可能激发完全不同的联想。善用这些文化差异,可以事半功倍。
6.2 两个社区的文化差异
"养虾人"和"养马人"虽然都是在和 AI Agent 打交道,但他们的社区文化有着微妙的差异。
差异一:对待 Agent 的态度。
"养虾人"倾向于把 Agent 看作工具。他们的讨论话题集中在:怎么配置更好、怎么连接更多平台、怎么写更强大的 SOUL.md。Agent 本身不是话题的中心,"怎么用 Agent 完成更多事"才是。
"养马人"则更倾向于把 Agent 看作伙伴。他们的讨论话题除了技术配置,还包括:我的 Agent 今天又学会了什么新技能、它怎么越来越懂我了、我和它的互动有什么有趣的故事。Agent 本身成为了话题的中心。
这种差异没有高下之分,只是反映了不同的使用场景和心理需求。
差异二:社区氛围。
OpenClaw 社区更大、更成熟,但也因此更"正式"。讨论以技术问题为主,氛围偏向专业、理性、结构化。
Hermes 社区规模较小,但活跃度很高,氛围更"轻松"、更有"人味"。人们愿意分享自己的使用故事、吐槽 Agent 的"蠢萌"行为、甚至分享和 Agent 的"日常"。
差异三:帮助他人的方式。
在 OpenClaw 社区,当一个新人提问时,最常见的回答是"去看文档"、"搜一下之前的 Issue"。这很高效,但也略显冷淡。
在 Hermes 社区,当一个新人提问时,老用户更倾向于手把手地教——"来,你把这段配置贴给我,我帮你看"、"这个问题我上周也遇到过,是这样解决的"。这可能是因为 Hermes 的社区规模还不大,人与人之间更容易建立连接。
差异四:对项目未来的期待。
OpenClaw 社区讨论未来时,关注的是:什么时候支持更多平台、什么时候有更多官方技能、什么时候推出新功能。
Hermes 社区讨论未来时,关注的是:Agent 的自学习能力能进化到什么程度、它能不能真正成为一个"数字分身"、未来的 AI 伙伴会是什么样子。
6.3 从竞争到互补的关系演变
Hermes 刚发布时,很多人把它和 OpenClaw 的关系定义为"竞争"。媒体上出现了不少"Hermes 能否取代 OpenClaw"的讨论。
但随着时间推移,两个社区都在逐渐走向一个更成熟的认知:它们不是竞争对手,而是互补的选择。
这个认知转变有几个标志性的事件:
事件一:Peter Steinberger 的公开表态。
OpenClaw 的创始人 Peter 在一个播客访谈中被问到如何看待 Hermes。他的回答是:
"我觉得 Hermes 做得很棒。他们把自学习能力做成了一个实际可用的功能,这很了不起。我们(OpenClaw)选择不把自学习放进核心架构,不是因为做不到,而是因为我们的设计理念不同。OpenClaw 的定位是一个稳定、可控、可预测的工具,而不是一个会自主变化的系统。这两种定位都有价值,用户应该根据自己的需求选择。"
这个表态非常大气,也帮助缓解了社区之间的对立情绪。
事件二:Hermes 官方支持 OpenClaw 迁移。
hermes migrate openclaw 这个命令的设计,本身就传达了一个信号:Hermes 不希望你"抛弃"OpenClaw,而是希望你"在需要的时候可以平滑过渡"。
事件三:双持用户的增多。
越来越多的用户开始在两个项目中"双持"——用 OpenClaw 处理需要多平台协作的企业任务,用 Hermes 处理需要长期积累和个性化的个人任务。
有个用户在社区里说了一段很有趣的话:
"OpenClaw 是我的'员工',我给它明确的任务清单,它高效执行。Hermes 是我的'助理',我给它大致的方向,它自主发挥。两种关系我都需要,就像一家公司既需要执行力强的基层员工,也需要有创造力的核心助手。"
事件四:技术层面的互相借鉴。
两个项目在技术层面也开始互相学习。OpenClaw 社区有人提议引入类似 MEMORY.md 的记忆压缩机制;Hermes 则参考了 OpenClaw 在分级沙箱安全方面的最佳实践。
6.4 社区用语指南
如果你是刚加入社区的新手,以下是一些常用的"黑话",帮你快速融入:
通用词汇:
| 词汇 | 含义 |
|---|---|
| Agent | AI 智能体,即系统本身 |
| LLM | 大语言模型,如 GPT-4、Claude 等 |
| Token | 大模型处理文本的基本单位,也是计费单位 |
| 上下文 / Context | 当前对话中 AI 能"看到"的内容 |
| Prompt | 给 AI 的指令或输入 |
OpenClaw 社区专用:
| 词汇 | 含义 |
|---|---|
| 养虾人 | OpenClaw 用户 |
| 虾塘 | OpenClaw 的部署环境 |
| 喂虾 | 配置、调试 Agent |
| SOUL | Agent 的人格定义文件 |
| 虾病了 | Agent 出问题、出 Bug |
| 虾好了 | 问题修复、恢复正常 |
| 蜕壳 | 升级 OpenClaw 版本 |
| ClawHub | OpenClaw 的技能市场 |
Hermes 社区专用:
| 词汇 | 含义 |
|---|---|
| 养马人 | Hermes 用户 |
| 马厩 | Hermes 的部署环境 |
| 调教马匹 | 配置、训练 Agent |
| 赛马 | 性能优秀的 Agent 实例 |
| 马儿跑得快 | Agent 表现出色 |
| 马儿闹脾气 | Agent 出问题、出 Bug |
| 驯马师 | 精通 Hermes 配置和调优的资深用户 |
| 缰绳 | Harness Engineering 理念的代称 |
| 上马 | 开始部署和使用 Hermes |
| 下马 | 暂停或停止使用 Hermes |
| 马术 | 使用 Hermes 的技巧和经验 |
跨社区通用(两个社区都理解):
| 词汇 | 含义 |
|---|---|
| 虾转马 | 从 OpenClaw 迁移到 Hermes |
| 双持 | 同时使用 OpenClaw 和 Hermes |
| 牧场主 / 塘主 | 同时管理多个 Agent 的用户 |
| 跑丢 | Agent 进入无限循环或偏离任务目标 |
| 驯服 | 把一个难以控制的 Agent 调教到稳定可用 |
Tips
社区黑话的存在,不只是为了好玩。它有三个实际功能:一是降低沟通成本("我虾病了"比"我的 OpenClaw Agent 出现了运行时错误"快得多);二是增强归属感(会说黑话意味着你是"自己人");三是增加趣味性(让技术讨论不那么枯燥)。但也要注意,在正式文档或面向新人的场合,还是要用规范的技术术语,避免黑话造成的理解障碍。
7. Hermes 的版本演进与路线图
7.1 当前版本特性概览
截至 2026 年 4 月,Hermes 的最新稳定版本带来了以下核心特性:
核心框架: - Python 3.11+ 运行时 - 模块化架构,五层设计清晰分离 - 支持 uv 包管理器,安装和依赖管理极为便捷
模型支持: - 20+ 大模型提供商原生支持 - Fallback 链机制,主模型失败自动切换 - 支持本地模型(Ollama、LM Studio 等)
记忆系统: - 四层温度模型(热/温/冷/外部) - MEMORY.md(约 2200 字符)自动维护 - USER.md(约 1375 字符)用户画像 - SQLite + FTS5 全文检索 - Honcho 用户建模模块集成
技能系统: - 74 个内置技能 - 44 个官方可选技能 - 521 个社区技能 - 自动创建与自动修复机制 - 渐进式加载(Level 0/1/2)
工具生态: - 47 个内置工具,覆盖 7 大类别 - 工具自注册机制 - 命令审批安全流程 - MCP 协议支持
平台接入: - 15+ 消息平台原生支持 - 6 种终端后端可选 - WebSocket + Webhook 双模式 - 富文本、按钮、文件传输支持
自动化: - Cron 定时任务调度 - 子 Agent 并行委托 - 会话恢复与持续运行
7.2 已知的未来规划
Nous Research 在官方文档和社区讨论中,透露了以下已知的未来规划:
短期规划(2026 年 Q2-Q3):
-
多 Agent 协作增强。 当前 Hermes 已经支持子 Agent 委托,但协作模式还比较简单。未来计划引入更复杂的编排机制——多个 Agent 可以共享记忆、分工协作、甚至进行"民主投票"来决定重大事项。
-
技能市场优化。 当前的技能发现和安装流程还有改进空间。计划推出更好的搜索、分类、评级系统,以及 Skill 的依赖管理和版本锁定功能。
-
更多平台适配器。 社区呼声很高的平台包括:Microsoft Teams、Google Chat、以及更多的国产企业通讯工具。
-
移动端支持。 虽然短期内不会推出原生 App,但计划通过 PWA(渐进式 Web 应用)的方式,让手机浏览器也能方便地访问和管理 Hermes Agent。
中期规划(2026 年 Q4 - 2027 年 Q1):
-
企业级功能。 包括多租户支持、RBAC 权限管理、审计日志、合规性报告等。这些功能对于希望将 Hermes 引入生产环境的企业客户至关重要。
-
可视化编排界面。 当前 Hermes 的所有配置都通过 CLI 完成,对于非技术用户来说门槛较高。计划推出一个 Web 化的管理界面,让用户可以通过拖拽和点击来配置 Agent。
-
更强大的自学习能力。 当前的自学习主要基于单个任务的总结。未来计划引入跨任务的关联学习——Agent 能把在不同任务中学到的经验联系起来,形成更抽象、更通用的知识。
-
语音交互升级。 当前的语音功能还比较基础。计划集成更先进的语音识别和合成技术,支持多轮语音对话、语音打断、情感识别等功能。
长期愿景(2027 年及以后):
Nous Research 的创始人曾在一次访谈中描绘了一个宏大的愿景:
"我们希望 Hermes 最终能成为每个人的'数字分身'——它知道你的一切工作习惯、沟通风格、知识储备和偏好设置。当你需要完成一项任务时,你不需要详细解释每一步怎么做,只需要告诉它目标,它就会像你本人一样去思考、去规划、去执行。"
这个愿景当然离现实还有很远的路要走,但它指明了 Hermes 的长期发展方向:从"好用的 AI 工具"进化到"懂你的 AI 伙伴"。
7.3 社区呼声最高的功能请求
在 GitHub Issues 和 Discord 频道中,社区用户提出了大量的功能请求。以下是呼声最高的几项:
第一名:更直观的可视化界面
很多用户表示,虽然 CLI 很强大,但他们希望能有一个图形化的仪表盘,实时查看 Agent 的状态、历史任务、Token 消耗、技能库等信息。
"我现在要查看 Agent 的运行状态,得在终端里翻日志。如果能有一个像 Grafana 那样的仪表盘,一眼就能看到所有关键指标,那就太棒了。" —— GitHub Issue #284
第二名:更好的错误诊断工具
当 Agent 出错时,当前的错误信息有时候不够清晰,用户很难判断是配置问题、模型问题还是 Skill 的问题。
社区希望能有一个内置的"诊断模式",可以一键收集环境信息、配置快照、最近的日志和错误堆栈,生成一份结构化的诊断报告。
第三名:多人协作支持
当前 Hermes 主要是为个人用户设计的。但越来越多的团队开始尝试多人共享一个 Agent 实例,遇到了权限冲突、记忆混淆等问题。
社区希望能有原生的多用户支持——每个用户有自己的 USER.md,Agent 能区分不同用户的身份和偏好。
第四名:与更多国产模型的深度集成
随着中国 AI 市场的快速发展,DeepSeek、Qwen、Kimi 等国产模型的性能不断提升,价格也更有竞争力。社区希望能更方便地接入这些模型,并且针对它们的特点优化提示词和调用策略。
第五名:离线运行能力
虽然 Hermes 支持本地模型,但很多功能(如 Skill 自动创建、记忆压缩)仍然需要调用云端 API。社区希望能有一个"完全离线"模式,所有功能都在本地完成,不依赖任何外部服务。
7.4 生态发展预测
基于当前的趋势和社区动态,我对 Hermes 生态的未来发展做出以下预测:
预测一:技能生态将在 12 个月内突破 5000 个。
当前的 639 个技能看似不多,但 Hermes 的自动创建机制让技能增长曲线不是线性的,而是指数型的。随着用户数量的增加,每个用户创建的自定义技能都在贡献生态。再加上官方和社区主动发布的技能,12 个月内达到 5000 个是完全可能的。
预测二:企业采用率将快速上升。
当前 Hermes 的用户主要是个人开发者和早期采用者。但随着企业级功能的完善(多租户、权限管理、审计日志等),中小企业和技术团队将成为下一波增长的主力。预计到 2027 年初,企业用户将占 Hermes 用户群的 30% 以上。
预测三:与 OpenClaw 的关系将从"替代叙事"转向"协同叙事"。
两个项目都在走向成熟,社区之间的对立情绪正在消退。未来更可能出现的是"协同"关系——两个项目的开发者互相借鉴、两个社区的用户"双持"、甚至可能出现让 OpenClaw 和 Hermes 互相调用的桥接工具。
预测四:中文社区将成为最大的非英语社区。
从当前的社区活跃度来看,中文用户是 Hermes 除英语用户之外最大的群体。"养马"文化的兴起、中文文档的完善、以及国产模型的深度集成,都将推动中文社区的持续壮大。预计到 2027 年,中文社区将贡献 Hermes 全球用户量的 25-30%。
预测五:围绕 Hermes 将出现一批商业化服务。
就像 WordPress 催生了主题市场、插件市场和托管服务市场一样,Hermes 的生态成熟后,也会出现围绕它的商业服务—— Skill 的付费市场、企业定制开发服务、培训和咨询服务、托管运维服务等。这些商业化服务将进一步降低 Hermes 的使用门槛,推动它从极客圈走向主流市场。
注意
以上预测基于当前可见的趋势和信息,不构成投资建议。技术领域的变化速度远超预期,任何长期预测都有很大的不确定性。读者应该保持批判性思维,结合自己的实际情况做出判断。
本章小结
在这一章中,我们沿着时间线和技术线,完整梳理了 Hermes 从理念到产品的诞生历程。
我们认识了 Nous Research——这家"不走寻常路"的 AI 公司,理解了他们如何用 6500 万美元的融资,支撑起一个以"缰绳工程"为核心理念的开源项目。
我们深入解读了"缰绳工程"的哲学——不是控制 AI,而是引导 AI 自我成长;不是给 AI 写死规则,而是给它设定边界,在边界内自由探索。这个理念从根本上改变了 AI Agent 的设计范式。
我们回顾了 OpenClaw 的辉煌与局限——309k Stars 的社区规模、万能网关的产品定位、以及手动配置、缺乏自学习等核心痛点。正是这些痛点,为 Hermes 的诞生创造了空间。
我们对比了 Hermes 和 OpenClaw 的核心差异——从轻量级架构到自学习闭环,从动态记忆到有机进化,Hermes 在多个维度上实现了突破。同时我们也认识到,两者不是替代关系,而是互补关系。
我们分析了 Hermes 两个月斩获 104,791 Stars 的增长密码——踩准了需求转型节点、差异化定位清晰、迁移成本低、社区传播力强、技术实现过硬。
我们解读了"养马"和"养虾"的社区文化——两个有趣的称呼背后,是两种对待 AI Agent 的不同态度、两种社区氛围、以及从竞争到互补的关系演变。
最后,我们展望了 Hermes 的未来——短期规划、中期愿景和社区呼声最高的功能请求,以及围绕生态发展的五个预测。
理解一个项目的过去,是预判它未来的最佳方式。希望这一章的内容,能帮助你对 Hermes 建立起一个立体的、有深度的认知框架。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第四册:核心架构深度解析
本章你将学到
- Hermes 的"五层架构"到底是哪五层,每一层负责什么,它们之间如何协作
- 为什么即使你不是纯技术人员,了解架构也能帮你更好地使用 Hermes
- CLI 入口、GatewayRunner、对话循环、预算机制、ToolRegistry、SQLite 持久化、平台适配器——这些核心模块的工作原理
- Hermes 的"自学习闭环"是如何在架构层面实现的,为什么说它是 Hermes 的"灵魂"
- 四层温度记忆模型是怎么工作的,热记忆、温记忆、冷记忆、外部记忆各有什么特点
- Honcho 用户建模模块如何让 Agent 越来越懂你
- Hermes 的安全架构如何保护你的数据和系统
- Python 轻量架构的性能优势和扩展方向
架构听起来可能有点"硬核",但放心,我会用大量的类比和通俗语言,让你像逛超市一样轻松地理解 Hermes 的内部构造。
1. 架构总览:五层设计哲学
1.1 为什么要了解架构
在正式开始之前,我想先回答一个你可能会问的问题:"我只是想用 Hermes 来自动化一些日常工作,为什么要了解它的架构?"
这是一个非常好的问题。答案是:了解架构,能让你用得更明白、调得更顺手、出了问题更容易排查。
打个不太恰当的比方:你开车不需要懂发动机的工作原理,但如果你懂一点发动机的知识,当车子发出异响时,你就能大致判断是"小问题可以自己处理"还是"大问题需要送修"。同样,了解 Hermes 的架构,能让你:
- 更合理地配置资源。 知道哪一层吃 CPU、哪一层吃内存、哪一层吃磁盘,你就能有针对性地优化。
- 更快速地定位问题。 Agent 出问题时,如果你能判断问题大概出在哪个层次,排查效率会高十倍。
- 更充分地利用功能。 很多高级功能之所以"高级",是因为它们涉及多个层次的协作。理解架构后,你会更清楚这些功能的边界和适用场景。
- 更有信心做扩展。 如果你想开发自定义工具或接入新的平台,了解架构能让你知道应该从哪一层入手、需要遵循什么规范。
Tips
这一章我会用很多生活中的类比来解释技术概念。如果某个类比让你"哦,原来如此",那它就达到了目的;如果某个类比让你更困惑了,那就忘掉它,直接看技术描述。类比只是拐杖,不是真理本身。
1.2 五层架构概览
Hermes 的架构分为五个层次,从上到下依次是:
┌─────────────────────────────────────────┐
│ Layer 1: 入口与编排层 │
│ HermesCLI + GatewayRunner │
│ (像是餐厅的前台接待) │
├─────────────────────────────────────────┤
│ Layer 2: Agent 核心层 │
│ 同步对话循环 + 预算机制 │
│ (像是餐厅的主厨和厨房管理) │
├─────────────────────────────────────────┤
│ Layer 3: 工具与注册层 │
│ ToolRegistry 单例 + 自注册机制 │
│ (像是餐厅的食材仓库和工具柜) │
├─────────────────────────────────────────┤
│ Layer 4: 状态与持久化层 │
│ SQLite + MEMORY.md + USER.md + Cron │
│ (像是餐厅的档案室和日程表) │
├─────────────────────────────────────────┤
│ Layer 5: 平台适配层 │
│ 15+ 平台适配器 + 6 种终端后端 │
│ (像是餐厅的外卖接口和配送系统) │
└─────────────────────────────────────────┘
这个五层架构的设计,体现了一个核心思想:关注点分离(Separation of Concerns)。
每一层只负责一类事情,层与层之间通过清晰的接口通信。这种设计的优点是: - 某一层出了问题,不会连锁影响到其他层 - 可以单独升级或替换某一层,而不需要重构整个系统 - 新功能的开发可以集中在某一层,降低复杂度
1.3 每层一句话总结
在深入每一层之前,让我们先用一句话概括每一层的职责:
Layer 1(入口与编排层): 负责接收用户的输入(不管是从命令行、消息平台还是 API),把它包装成 Agent 能理解的格式,然后交给下一层处理。
Layer 2(Agent 核心层): 负责理解用户意图、规划执行步骤、调用工具、管理对话流程,是 Agent 的"大脑"和"中枢神经系统"。
Layer 3(工具与注册层): 负责管理所有可用的工具——内置的 47 个工具、第三方 MCP 工具、以及用户自定义的工具——让 Agent 知道"我能做什么"。
Layer 4(状态与持久化层): 负责把所有需要长期保存的信息存下来——记忆、用户画像、历史对话、定时任务——让 Agent"不会忘记"。
Layer 5(平台适配层): 负责把 Agent 的输出转换成各个平台能显示的格式,并处理平台特有的交互方式(如按钮、富文本、文件传输)。
1.4 与传统 Agent 架构的对比
为了让你更直观地理解 Hermes 架构的特点,我们把它和几种典型的 Agent 架构做一个对比。
类型一:单体脚本型(如早期 AutoGPT)
早期的 AutoGPT 基本上就是一个庞大的 Python 脚本,所有的逻辑——从接收输入、解析意图、调用工具、管理记忆——都杂糅在一个文件或少数几个文件里。
优点是简单直接,代码量少。缺点是: - 难以维护和扩展——改一个功能可能会影响十个地方 - 难以测试——没有清晰的模块边界,单元测试几乎不可能 - 难以复用——代码和具体业务逻辑高度耦合
Hermes 的五层架构,本质上是对这种"大泥球"式代码的反思和改进。
类型二:微服务型(如一些企业级 Agent 平台)
有些 Agent 系统采用了完全的微服务架构——每个功能都是一个独立的容器或服务,通过消息队列或 RPC 通信。
优点是弹性伸缩、故障隔离。缺点是: - 部署复杂——需要 Kubernetes、服务发现、负载均衡等基础设施 - 调试困难——问题可能出在任何一个服务里,追踪调用链很麻烦 - 资源开销大——每个服务都要独立的进程和内存
Hermes 的定位是"个人和小团队的 Agent",所以选择了轻量级的模块化设计(在一个进程内分层),而不是重型的微服务架构。
类型三:插件型(如一些 ChatGPT 插件系统)
这类架构有一个轻量级的核心,所有功能都通过插件扩展。优点是灵活性高,缺点是核心和插件之间的接口定义很关键,如果接口设计不好,插件生态就会混乱。
Hermes 的 ToolRegistry 和 Skill 系统借鉴了插件思想,但做了更严格的设计约束——所有工具必须遵循统一的注册接口,所有 Skill 必须遵循统一的格式规范。
常见问题
Q:Hermes 的架构适合企业级部署吗?
A:当前版本的 Hermes 主要面向个人开发者和中小型团队。对于大型企业部署,可能需要在 Layer 4(持久化层)替换 SQLite 为更强大的数据库(如 PostgreSQL),在 Layer 1(入口层)增加负载均衡和 API 网关。Nous Research 的中期规划中已经包含了企业级功能,未来会有更完善的企业部署方案。
Q:五层架构会不会让系统变慢?
A:分层确实会带来一些函数调用的开销,但对于 Hermes 这种以 LLM 调用为主要耗时的系统来说,这些开销几乎可以忽略不计。LLM 的一次 API 调用可能需要几秒钟,而层与层之间的数据传输只需要几毫秒。相比之下,清晰的架构带来的可维护性和可扩展性收益,远远大于这点性能损耗。
2. Layer 1: 入口与编排层(HermesCLI + GatewayRunner)
2.1 CLI 入口的设计理念
在深入 CLI 之前,先快速了解一下 Hermes 的安装方式。根据 Nous Research 的官方设计,Hermes 的安装极为简单——只需一条 curl 命令:
# macOS / Linux 安装(官方推荐方式)
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
安装脚本会自动完成以下工作:
- 下载 Hermes 二进制文件到 ~/.hermes/bin/
- 安装 uv(Python 包管理器)
- 安装 Python 3.11 运行时
- 安装 Node.js v22(部分工具依赖)
- 安装 ripgrep、ffmpeg 等辅助工具
- 将 ~/.hermes/bin/ 添加到你的 PATH
# 安装完成后,验证是否成功
hermes --version
# 查看二进制文件位置
which hermes
# 输出: /Users/yourname/.hermes/bin/hermes
Tips
~/.hermes/bin/是 Hermes 的"家目录"。除了二进制文件,这个目录下还会存放: -~/.hermes/data/—— SQLite 数据库和日志 -~/.hermes/skills/—— 自动创建和下载的技能 -~/.hermes/custom_tools/—— 你的自定义工具 -~/.hermes/MEMORY.md—— Agent 的工作笔记 -~/.hermes/USER.md—— 用户画像建议定期备份整个
~/.hermes/目录。
HermesCLI 是用户与 Hermes 交互的主要入口。它的设计理念可以用三个词概括:简洁、直观、渐进。
简洁 —— HermesCLI 的命令体系非常精简,核心命令只有十几个。你不需要记住一大堆复杂的参数和标志,常用的操作都能在 3 个单词以内的命令中完成。
# Hermes 的核心命令一览
hermes # 启动交互式对话
hermes -q "你的问题" # 单次查询模式
hermes --continue # 恢复上一次的会话
hermes setup # 启动配置向导
hermes model # 管理和切换大模型
hermes tools # 查看和配置工具
hermes gateway setup # 配置消息平台接入
hermes skills browse # 浏览技能市场
hermes skills install # 安装技能
hermes migrate openclaw # 从 OpenClaw 迁移
直观 —— 命令的命名遵循"说人话"原则。hermes model 就是管模型的,hermes tools 就是管工具的,hermes gateway 就是管平台接入的。不需要查文档,凭直觉就能猜出命令的作用。
渐进 —— 命令的复杂度是渐进暴露的。初学者只需要知道 hermes 和 hermes -q 就能开始使用;随着需求的增长,再逐步学习更高级的命令。不会一上来就给你一百个命令,让你不知道从何学起。
Tips
如果你记不住某个命令的具体用法,可以在命令后面加
--help。Hermes 的每个命令都有详细的中文帮助文档,还会给出示例。比如hermes tools --help会告诉你每个子命令是做什么的、有哪些参数、参数的含义是什么。
2.2 GatewayRunner 的作用
如果说 HermesCLI 是"人找系统"的入口(用户主动打开终端,输入命令),那么 GatewayRunner 就是"系统找人"的入口(Agent 主动通过消息平台推送消息给用户)。
GatewayRunner 是一个长期运行的服务进程,它负责:
-
监听多个平台的 incoming 消息。 无论是 Telegram 的消息、飞书的@提及、还是 Slack 的频道消息,GatewayRunner 都会实时接收。
-
消息格式统一化。 不同平台的消息格式千差万别——有的用 JSON,有的用 XML,有的用 Protobuf。GatewayRunner 把这些异构格式转换成 Hermes 内部的统一消息对象。
-
会话管理。 当同一个用户在不同平台发来消息时,GatewayRunner 要判断"这是不是同一个人",然后把消息路由到正确的会话中。
-
身份认证与安全校验。 对 Webhook 请求进行签名验证,防止伪造消息。
你可以把 GatewayRunner 想象成一个"多语言翻译官 + 前台接待"的组合体。它站在门口,同时和十几个平台"聊天",然后把所有平台的消息翻译成同一种"语言"(Hermes 内部格式),再转交给 Agent 处理。
2.3 命令解析流程
当你在终端输入一条 hermes 命令时,系统内部发生了什么?让我们跟踪一下完整的流程:
用户输入: hermes -q "帮我写一个 Python 爬虫"
↓
[Shell] 解析命令行参数
↓
[HermesCLI] 识别到这是 "单次查询" 模式 (-q 标志)
↓
[HermesCLI] 加载配置(从 ~/.config/hermes/ 读取)
↓
[HermesCLI] 初始化 Agent 实例(如果不存在)
↓
[HermesCLI] 把用户输入包装成 Message 对象
↓
[Agent 核心层] 接收 Message,开始处理...
↓
...(Agent 处理过程,详见 Layer 2)...
↓
[Agent 核心层] 返回处理结果
↓
[HermesCLI] 格式化输出(根据终端类型选择渲染方式)
↓
[HermesCLI] 显示结果给用户
↓
[持久化层] 保存对话历史到 SQLite
这个流程看似简单,但每个步骤背后都有不少工程细节。
比如"加载配置"这一步,Hermes 会按照以下优先级读取配置:
- 环境变量(最高优先级)—— 适合 CI/CD 和容器化部署
- 命令行参数 —— 适合临时覆盖某个配置
- 项目级配置文件(
./.hermes/config.yaml)—— 适合项目特定的设置 - 用户级配置文件(
~/.config/hermes/config.yaml)—— 适合个人偏好 - 系统级配置文件(
/etc/hermes/config.yaml)—— 适合全局默认设置 - 内置默认值(最低优先级)—— 保证系统在没有配置时也能运行
这种分层配置的设计,让你可以非常灵活地管理不同场景下的配置需求。
# ~/.config/hermes/config.yaml 示例
# 这是用户级的配置文件
model:
provider: openai # 默认使用的模型提供商
model: gpt-4.1 # 默认使用的模型名称
temperature: 0.7 # 创造力参数(0=保守,1=发散)
max_tokens: 4096 # 单次响应的最大 Token 数
memory:
max_memory_tokens: 2200 # MEMORY.md 的字符上限
max_user_tokens: 1375 # USER.md 的字符上限
enable_compression: true # 是否启用记忆压缩
budget:
max_turns: 50 # 单次任务的最大对话轮数
max_tool_calls: 100 # 单次任务的最大工具调用次数
max_cost_usd: 5.0 # 单次任务的最大成本(美元)
terminal:
backend: local # 终端后端:local / docker / ssh
require_approval: true # 危险操作是否需要用户确认
2.4 多入口共存的设计选择
Hermes 的一个独特设计是:它同时支持三种入口方式,而且它们可以共存。
入口一:CLI(命令行)
适合场景:开发者日常操作、脚本自动化、快速测试 优点:直接、高效、不需要额外配置 缺点:需要打开终端,不适合移动端
入口二:Gateway(消息平台)
适合场景:团队协作、移动办公、7×24 小时值守 优点:随时随地可用、天然支持多人协作、消息历史自动保存 缺点:需要配置平台接入、受平台功能限制(如消息长度限制)
入口三:API(编程接口)
适合场景:集成到现有系统、批量任务处理、二次开发 优点:完全可控、易于自动化、可以嵌入任何应用 缺点:需要编程能力、需要自己处理错误和重试
这三种入口共享同一个 Agent 实例和同一套记忆数据。这意味着:你可以在 CLI 上和 Agent 聊了一半,然后在 Telegram 上继续聊,Agent 完全记得之前的上下文。
注意
多入口共存虽然很方便,但也带来了一个需要注意的问题:并发冲突。 如果 CLI 和 Telegram 同时给 Agent 发送任务,Agent 应该优先处理哪个?Hermes 目前的策略是"单线程处理"——一个任务完成后才开始下一个。这是为了避免 Agent 在多个任务之间"精神分裂"。未来版本可能会引入更精细的并发控制机制。
3. Layer 2: Agent 核心层(对话循环与预算机制)
3.1 同步对话循环的工作原理
Agent 核心层是整个 Hermes 系统中最复杂的部分。它的核心是一个同步对话循环(Synchronous Conversation Loop),这个循环驱动着 Agent 从接收用户输入到输出最终结果的完整流程。
让我们用一个生活化的类比来理解这个循环。
想象你是一家餐厅的主厨。你的工作是:顾客点了一道菜,你要决定需要什么食材、用什么厨具、按什么顺序加工,最后把成品端出去。
同步对话循环就像是主厨的"工作流程":
┌─────────────────────────────────────────────────────────────┐
│ 同步对话循环流程 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 接收订单(Receive) │
│ ↓ 顾客说:"我要一份宫保鸡丁" │
│ │
│ 2. 理解需求(Comprehend) │
│ ↓ 分析:宫保鸡丁 = 鸡肉 + 花生 + 干辣椒 + 葱姜蒜... │
│ │
│ 3. 规划步骤(Plan) │
│ ↓ 决定:先切鸡肉 → 腌制 → 炸花生 → 炒配料 → 合炒 → 出锅 │
│ │
│ 4. 执行步骤(Execute)—— 可能涉及多次工具调用 │
│ ↓ 调用工具:切菜(cut)、调味(season)、加热(heat)... │
│ ↓ 每执行一步,观察结果,决定下一步 │
│ │
│ 5. 检查结果(Evaluate) │
│ ↓ 颜色对吗?味道对吗?顾客的特殊要求满足了吗? │
│ │
│ 6. 输出结果(Respond) │
│ ↓ 上菜! │
│ │
│ 7. 学习总结(Learn)—— Hermes 特有 │
│ ↓ 记录:这次宫保鸡丁做得不错,下次还可以这样做 │
│ │
└─────────────────────────────────────────────────────────────┘
在代码层面,这个循环大致是这样的结构(简化版):
# 这是简化版的对话循环伪代码,帮助理解核心逻辑
# 实际代码比这复杂得多,包含大量错误处理和状态管理
def conversation_loop(user_input: str, session: Session) -> str:
"""
Agent 核心对话循环
参数:
user_input: 用户的输入消息
session: 当前会话对象,包含上下文和历史
返回:
Agent 的最终回复
"""
# 第 1 步:构建上下文
context = build_context(session)
# 上下文包括:系统提示、MEMORY.md 内容、USER.md 内容、
# 当前会话的历史消息、可用的工具列表
# 第 2 步:发送给 LLM,获取响应
llm_response = call_llm(
messages=context,
tools=available_tools, # 告诉 LLM 有哪些工具可用
)
# 第 3 步:解析 LLM 的响应
# LLM 可能直接回复文字,也可能请求调用某个工具
while llm_response.requires_tool_call:
# LLM 要求调用工具
tool_result = execute_tool(
name=llm_response.tool_name,
params=llm_response.tool_params,
)
# 把工具执行结果告诉 LLM
context.add_tool_result(tool_result)
# 再次调用 LLM,让它基于工具结果继续推理
llm_response = call_llm(
messages=context,
tools=available_tools,
)
# 检查预算:是否超过了最大轮数或最大成本?
if budget_exceeded(session):
raise BudgetExceededError("任务预算已耗尽")
# 第 4 步:LLM 给出了最终回复(不再要求调用工具)
final_response = llm_response.content
# 第 5 步:保存对话历史
session.add_message(role="user", content=user_input)
session.add_message(role="assistant", content=final_response)
# 第 6 步:触发学习机制(如果满足条件)
if should_learn(session):
create_or_update_skill(session)
return final_response
这个循环的精妙之处在于:它不是一次性完成的,而是可能涉及多轮 LLM 调用和工具调用的"迭代过程"。
举个例子:你说"帮我查一下明天北京的天气,如果下雨就提醒我带伞"。
Agent 的处理过程可能是这样的:
用户: 帮我查一下明天北京的天气,如果下雨就提醒我带伞
↓
LLM 思考:用户需要天气信息。我应该调用天气查询工具。
↓
调用工具: weather.query(location="北京", date="明天")
↓
工具返回: {"天气": "小雨", "温度": "15-22°C", "降水概率": "80%"}
↓
LLM 思考:天气是小雨,满足"下雨"的条件。我需要提醒用户带伞。
↓
LLM 回复: 明天北京有小雨,降水概率 80%,气温 15-22°C。记得带伞哦!
在这个过程中,LLM 被调用了两次:第一次决定调用天气工具,第二次在获得天气数据后生成最终回复。这就是对话循环的"迭代"特性。
Tips
你可以通过设置
budget.max_turns来控制单次任务中 LLM 的最多调用轮数。默认值通常是 50,对于绝大多数任务来说足够了。如果你的任务特别复杂(比如需要查询多个数据源、进行多步分析),可以适当调高这个值。但要注意,每增加一轮 LLM 调用,都会增加 Token 消耗和响应时间。
3.2 预算机制:防止 Agent 失控的安全阀
预算机制(Budgeting)是 Hermes 安全架构中最重要的组件之一。它的作用是:给 Agent 的每一次任务设定资源上限,防止它陷入无限循环或过度消耗。
为什么需要预算机制?让我们看一个"恐怖故事"。
假设你让 Agent"帮我找一下关于量子计算的最新论文"。如果没有预算机制,Agent 可能会:
- 调用搜索工具,找到 100 篇论文
- 对每篇论文调用摘要提取工具——100 次工具调用
- 发现某些论文引用了更多论文,又去搜索引用论文——又 100 次
- 陷入递归循环,直到你的 API 账单爆表
这就像一个没有刹车的汽车,油门踩下去就不知道停。预算机制就是这辆车的"刹车系统"。
Hermes 的预算机制包含三个维度的限制:
维度一:对话轮数限制(max_turns)
限制单次任务中 LLM 的调用次数。每调用一次 LLM,就算一轮。
budget:
max_turns: 50 # 最多 50 轮对话
超过这个限制后,Agent 会停止执行,并向用户报告:"任务太复杂了,我在预算范围内无法完成。你可以简化任务,或者调高预算限制。"
维度二:工具调用次数限制(max_tool_calls)
限制单次任务中调用工具的总次数。注意,这和对话轮数是不同的指标——一轮对话中可能调用多个工具。
budget:
max_tool_calls: 100 # 最多调用 100 次工具
维度三:成本限制(max_cost_usd)
这是最"硬核"的限制——直接用美元计价。系统会根据每次 LLM 调用的 Token 数量和模型单价,实时计算累计成本。
budget:
max_cost_usd: 5.0 # 单次任务最多花费 5 美元
当累计成本接近上限时,Agent 会收到警告;超过上限后,任务会被强制终止。
注意
成本限制依赖于准确的 Token 计数和模型定价表。如果模型提供商的 API 返回了错误的 Token 计数,或者定价表没有及时更新,成本估算可能会有偏差。建议把
max_cost_usd设置得比你实际能承受的成本低 20%,留一些安全余量。
3.3 Token 计数与成本控制
要理解预算机制,就必须先理解 Token 这个概念。
Token 是大语言模型处理文本的基本单位。你可以把它理解为"词片段"——一个英文单词可能被拆成 1-2 个 Token,一个中文字符通常是 1-2 个 Token。
举例:
"Hello world" ≈ 3 Tokens(Hello + world + 空格/标点)
"你好世界" ≈ 4 Tokens(你 + 好 + 世 + 界)
"中华人民共和国" ≈ 6-8 Tokens(取决于分词方式)
为什么 Token 很重要?因为: 1. Token 是计费的单位。 模型提供商按输入 Token 数和输出 Token 数收费。输入和输出的单价通常不同(输出更贵)。 2. Token 是上下文窗口的单位。 每个模型都有最大上下文长度(如 GPT-4 是 128k Tokens),超过这个长度,最前面的内容会被截断或压缩。 3. Token 是预算机制的计算基础。 max_cost_usd 的核算,依赖于准确的 Token 计数。
Hermes 在 Token 计数方面做了以下工作:
准确的 Token 估算。 在每次调用 LLM 之前,Hermes 会用对应模型的 Tokenizer 精确计算输入文本的 Token 数。不同模型使用不同的 Tokenizer(如 GPT 系列用 tiktoken,Claude 用不同的方案),Hermes 会自动选择正确的 Tokenizer。
实时的成本追踪。 每次 LLM 调用后,Hermes 会记录: - 输入 Token 数 - 输出 Token 数 - 模型单价 - 本次调用的成本
这些数据被累加到会话的"成本账本"中,供预算机制检查。
Fallback 链的成本优化。 Hermes 支持 Fallback 链——当主模型失败或不可用时,自动切换到备选模型。这个机制不仅能提高可用性,还能用于成本优化。
# Fallback 链配置示例
models:
primary:
provider: openai
model: gpt-4.1
# GPT-4 效果好,但贵(约 $15 / 1M tokens)
fallback:
provider: deepseek
model: deepseek-chat-v3
# DeepSeek 便宜很多(约 $0.14 / 1M tokens)
# 成本差异超过 100 倍!
local:
provider: ollama
model: llama-3.3-70b
# 本地模型,零成本,但需要自己的 GPU
Tips
一个实用的成本控制策略是:日常任务用便宜的模型(如 DeepSeek),复杂任务用能力强的模型(如 GPT-4)。Hermes 的模型切换非常简单:
hermes model就可以交互式地切换。你也可以在配置中设置自动降级规则——当任务类型匹配某些关键词时,自动选择更经济的模型。
3.4 上下文窗口管理策略
上下文窗口(Context Window)是 LLM 能"记住"的最大文本量。当前的主流模型,上下文窗口从 4k 到 200k+ Tokens 不等。
但上下文窗口有一个反直觉的特性:越大不等于越好。
研究表明,当上下文窗口中的内容过多时,模型的注意力会分散,对开头和结尾的内容记得更清楚,对中间的内容容易"遗忘"。这种现象被称为"中间丢失"(Lost in the Middle)。
Hermes 采用了多层策略来管理上下文窗口:
策略一:分层加载。
不是所有信息都塞进上下文,而是按优先级分层加载:
- 最高优先级: 系统提示 + 当前任务描述(必须包含)
- 高优先级: MEMORY.md + USER.md 的摘要(通常包含)
- 中优先级: 当前会话的最近 N 轮对话(尽量包含)
- 低优先级: 相关历史对话的检索结果(空间足够时包含)
- 最低优先级: 完整的工具描述列表(按需加载)
当上下文快满时,系统会优先丢弃低优先级的信息,保证高优先级信息的完整性。
策略二:智能摘要。
当会话历史很长时,系统不会把所有历史消息都塞进上下文,而是让 LLM 生成一个"会话摘要",用几百字概括之前的对话内容。这样既保留了关键信息,又大大节省了 Token。
原始会话历史(10 轮对话): 约 3000 Tokens
↓
智能摘要(1 段文字): 约 200 Tokens
↓
节省: 2800 Tokens(93% 的压缩率)
策略三:工具描述的渐进加载。
47 个内置工具的完整描述,如果全部塞进上下文,可能需要几千 Tokens。Hermes 采用了渐进式加载:
- 第一轮:只告诉 LLM"有哪些工具类别"(如"文件系统类""Web 类""代码执行类")
- 当 LLM 决定需要某类工具时:加载该类工具的详细描述
- 当 LLM 决定调用某个具体工具时:加载该工具的完整参数说明
这种"按需加载"的方式,既让 LLM 知道"我有什么工具",又避免了上下文被大量工具描述撑爆。
3.5 错误恢复与重试机制
在 Agent 的运行过程中,各种错误是不可避免的: - LLM API 超时或返回错误 - 工具执行失败(如网络不通、文件不存在) - 工具返回的数据格式不符合预期 - Token 预算耗尽 - 上下文窗口溢出
Hermes 设计了一套完善的错误恢复机制:
错误类型一:LLM API 错误。
# 当 LLM API 调用失败时的处理流程
try:
response = call_llm(messages, tools)
except LLMTimeoutError:
# 超时错误:等待几秒后重试
time.sleep(2)
response = call_llm(messages, tools) # 重试一次
except LLMRateLimitError:
# 速率限制:等待更长时间后重试
time.sleep(10)
response = call_llm(messages, tools) # 重试
except LLMError as e:
# 其他 LLM 错误:切换到 Fallback 模型
response = call_llm_with_fallback(messages, tools)
错误类型二:工具执行错误。
# 当工具执行失败时的处理流程
try:
result = execute_tool(tool_name, params)
except ToolNotFoundError:
# 工具不存在:告诉 LLM 这个工具不可用,让它换别的
context.add_system_message(f"工具 '{tool_name}' 不存在,请使用其他工具。")
except ToolExecutionError as e:
# 工具执行失败:把错误信息告诉 LLM,让它决定怎么处理
context.add_tool_error(f"工具 '{tool_name}' 执行失败: {e.message}")
# LLM 可能会:重试、换其他工具、或者告诉用户出错了
错误类型三:预算耗尽。
if budget_exceeded(session):
# 预算耗尽:终止当前任务,向用户报告
return (
"⚠️ 任务预算已耗尽。\n"
"已使用: {used_turns} 轮对话, {used_tools} 次工具调用, ${used_cost:.2f}\n"
"限额: {max_turns} 轮, {max_tools} 次, ${max_cost:.2f}\n\n"
"建议:\n"
"1. 简化你的任务描述\n"
"2. 分步骤执行,每次只完成一部分\n"
"3. 在配置中调高预算限制(hermes config set budget.max_cost_usd 10)"
)
常见问题
Q:Agent 遇到错误时会自动重试吗?会不会无限重试?
A:Hermes 的重试机制有明确的上限。LLM API 错误最多重试 3 次(每次间隔递增),工具执行错误不重试(而是把错误信息告诉 LLM,由 LLM 决定下一步)。预算耗尽和上下文溢出这类"硬性限制"错误,不会重试,直接终止任务。这种设计避免了"死循环"式的无限重试。
Q:如果 Agent 在执行危险操作(如删除文件)时出错,会发生什么?
A:危险操作在执行前会经过"命令审批"流程(详见第 10 章安全架构)。只有当用户明确确认后,操作才会执行。如果执行过程中出错,系统会报告错误,但不会自动重试危险操作。这是安全设计的一部分。
4. Layer 3: 工具与注册层(ToolRegistry 与自注册)
4.1 ToolRegistry 单例模式详解
ToolRegistry 是 Hermes 工具系统的"中央枢纽"。你可以把它想象成一个工具柜台——每个工具都有自己的工位,Agent 需要用什么工具时,就到这里来"借"。
ToolRegistry 采用了单例模式(Singleton Pattern)设计。这意味着整个 Hermes 系统中,只有一个 ToolRegistry 实例存在。所有的工具注册、查询和调用,都通过这个唯一的实例完成。
为什么要用单例模式?
- 一致性。 所有模块看到的工具列表是完全一致的,不会出现"A 模块以为有这个工具、B 模块以为没有"的情况。
- 状态共享。 ToolRegistry 需要维护工具的注册状态、版本信息、调用统计等数据,单例模式确保这些数据全局可见。
- 资源节省。 不需要为每个会话创建独立的 ToolRegistry,降低了内存开销。
# ToolRegistry 单例模式的简化示意
class ToolRegistry:
_instance = None # 唯一的实例引用
def __new__(cls):
if cls._instance is None:
cls._instance = super().__new__(cls)
cls._instance._tools = {} # 工具注册表
return cls._instance
def register(self, tool: Tool) -> None:
"""注册一个新工具"""
self._tools[tool.name] = tool
def get(self, name: str) -> Tool:
"""根据名称获取工具"""
return self._tools.get(name)
def list_all(self) -> list[Tool]:
"""列出所有已注册的工具"""
return list(self._tools.values())
def get_descriptions(self) -> str:
"""生成所有工具的描述文本(供 LLM 使用)"""
descriptions = []
for tool in self._tools.values():
descriptions.append(f"- {tool.name}: {tool.description}")
return "\n".join(descriptions)
Tips
单例模式虽然方便,但也有一个需要注意的地方:线程安全。 如果多个线程同时调用
register()或get(),可能会产生竞争条件。Hermes 的 ToolRegistry 在初始化阶段(系统启动时)完成所有工具的注册,运行阶段主要是读取操作,所以实际使用中线程安全问题不大。但如果你要开发一个支持高并发的自定义扩展,这一点需要留意。
4.2 工具自注册机制
Hermes 最巧妙的机制之一,就是工具自注册(Self-Registration)。
传统的工具系统,你需要在一个中心文件里手动列出所有可用的工具。每次新增或删除工具,都要修改这个中心文件。工具一多,这个文件就会膨胀到难以维护。
Hermes 的做法是:每个工具自己负责注册自己。
具体实现方式是:每个工具都是一个独立的 Python 模块,模块在加载时,会自动调用 ToolRegistry.register() 把自己注册进去。
# 一个工具模块的示例(简化版)
# 文件: hermes/tools/file_read.py
from hermes.core.registry import ToolRegistry
from hermes.core.tool import Tool, ToolParameter
# 定义工具
def file_read(file_path: str, encoding: str = "utf-8") -> str:
"""
读取文件内容
参数:
file_path: 文件的完整路径
encoding: 文件编码,默认 utf-8
返回:
文件的文本内容
"""
with open(file_path, "r", encoding=encoding) as f:
return f.read()
# 创建工具对象
file_read_tool = Tool(
name="file_read",
description="读取指定路径的文件内容,返回文本字符串",
parameters=[
ToolParameter(
name="file_path",
type="string",
description="要读取的文件的完整路径",
required=True,
),
ToolParameter(
name="encoding",
type="string",
description="文件的字符编码",
required=False,
default="utf-8",
),
],
handler=file_read,
category="filesystem", # 工具类别
requires_approval=False, # 是否需要用户审批
)
# 自注册:模块加载时自动注册到 ToolRegistry
ToolRegistry().register(file_read_tool)
这种设计的好处是显而易见的:
- 新增工具零配置。 你把一个新的工具文件放到
tools/目录下,系统启动时自动加载并注册。不需要修改任何中心配置文件。 - 删除工具零残留。 删掉工具文件,注册自然消失。不会在配置文件中留下死引用。
- 工具高度自治。 每个工具自己管理自己的元数据(名称、描述、参数、类别、安全级别),不需要依赖外部配置。
注意
工具自注册依赖于 Python 的模块导入机制。系统启动时,会扫描
tools/目录下的所有.py文件,逐个导入。如果某个工具模块有语法错误或其他问题,导入会失败,但不会影响其他工具的注册。系统会在日志中记录哪些工具注册成功、哪些失败,方便排查问题。
4.3 47 个内置工具的分类架构
Hermes 内置了 47 个工具,覆盖了日常开发和工作中最常用的功能。这些工具不是随意堆砌的,而是按照功能类别进行了清晰的组织。
| 类别 | 工具数量 | 代表工具 | 用途 |
|---|---|---|---|
| 文件系统 | 6 | file_read, file_write, file_edit, file_search, directory_list, file_delete | 文件的读写、编辑、搜索和管理 |
| 代码执行 | 4 | python_exec, shell_exec, code_lint, code_format | 运行 Python/Shell 代码,代码检查和格式化 |
| Web 交互 | 6 | web_search, web_extract, browser_navigate, browser_click, browser_screenshot, rss_fetch | 搜索网页、提取内容、浏览器自动化、RSS 订阅 |
| 终端命令 | 2 | terminal_exec, terminal_approve | 执行系统终端命令(需审批) |
| 记忆管理 | 5 | memory_read, memory_write, memory_search, memory_delete, session_search | 读写 MEMORY.md、搜索历史会话 |
| 技能管理 | 4 | skill_create, skill_read, skill_update, skill_delete | 创建和管理 Skill 文件 |
| 代理委托 | 2 | delegate_task, check_status | 创建子 Agent 并行处理任务 |
| 数据库 | 3 | db_query, db_insert, db_update | SQLite 数据库操作 |
| 通信 | 4 | send_email, send_message, webhook_call, notification_push | 发送邮件、消息、调用 Webhook |
| 媒体处理 | 4 | image_analyze, audio_transcribe, video_extract, media_convert | 图像分析、语音转文字、视频处理 |
| 开发工具 | 4 | git_commit, git_diff, git_branch, dependency_check | Git 操作、依赖检查 |
| 系统信息 | 3 | system_info, env_read, process_list | 读取系统信息、环境变量、进程列表 |
Tips
不是所有工具默认都是启用的。有些工具(如 terminal_exec、file_delete)属于"危险工具",默认是禁用的。你需要运行
hermes tools命令,交互式地启用你需要的工具。这种"白名单"机制是安全设计的一部分——默认最小权限,用户按需开启。
每个工具在注册时,都会带上以下元数据:
# 工具元数据结构(简化版)
{
"name": "file_write", # 工具的唯一标识
"description": "写入文件内容", # 给 LLM 看的描述
"category": "filesystem", # 所属类别
"parameters": [ # 参数列表
{"name": "path", "type": "string", "required": True},
{"name": "content", "type": "string", "required": True},
{"name": "append", "type": "boolean", "required": False, "default": False}
],
"requires_approval": False, # 是否需要用户审批
"dangerous": False, # 是否属于危险操作
"cost_estimate": "low", # 执行成本估计
"average_latency_ms": 50, # 平均执行延迟
}
这些元数据不仅供 LLM 理解工具的用途,也供系统做安全判断、成本估算和性能优化。
4.4 工具调用的安全审批流程
对于可能产生副作用的工具(如删除文件、执行系统命令、发送邮件),Hermes 设计了一套安全审批流程。
Agent 请求调用危险工具
↓
系统检查该工具是否标记为 requires_approval=True
↓
如果是,暂停执行,向用户显示审批请求
↓
用户界面显示:
- 工具名称
- 工具描述
- 具体的参数值(如要删除的文件路径)
- 风险评估(低/中/高)
- 建议操作(确认 / 拒绝 / 修改参数)
↓
用户选择:
- 确认 → 执行工具,记录审批日志
- 拒绝 → 取消调用,告诉 Agent 用户拒绝了
- 修改 → 让用户编辑参数后再次审批
在 CLI 模式下,审批界面是这样的:
⚠️ Agent 请求执行危险操作
工具: terminal_exec
描述: 执行系统终端命令
风险等级: 高
请求执行的命令:
rm -rf /home/user/old_project/
⚡ 这个操作将删除目录 /home/user/old_project/ 及其所有内容。
此操作不可撤销!
请选择:
[Y] 确认执行
[N] 拒绝
[E] 编辑命令
[A] 允许本次会话的所有同类操作
>
注意
"允许本次会话的所有同类操作"(选项 A)是一个方便但危险的功能。如果你选择了这个选项,当前会话中所有同类型的危险操作都会自动通过,不再提示。这在批量处理任务时很有用,但也意味着如果你没注意看 Agent 在做什么,可能会造成损失。建议只在完全信任当前任务、且已经审查过 Agent 的计划后,才使用这个选项。
4.5 自定义工具的扩展接口
Hermes 提供了非常友好的自定义工具接口,让你可以开发自己的工具,扩展 Agent 的能力。
方法一:Python 函数式工具(最简单)
如果你只需要一个简单的函数,可以直接用装饰器注册:
# 自定义工具示例:查询股票价格
# 文件: ~/.hermes/custom_tools/stock_query.py
from hermes.core.registry import ToolRegistry
from hermes.core.tool import tool # 装饰器
@tool(
name="stock_query",
description="查询指定股票代码的当前价格和基本信息",
parameters={
"symbol": {"type": "string", "description": "股票代码,如 AAPL、TSLA、600519"},
"market": {"type": "string", "description": "市场代码:us/hk/cn", "default": "us"},
},
category="finance",
)
def stock_query(symbol: str, market: str = "us") -> dict:
"""
查询股票价格
这个工具调用免费的股价 API 获取实时数据。
注意:免费 API 有调用频率限制,适合个人使用。
"""
import requests
# 根据市场选择 API
if market == "us":
url = f"https://api.example.com/stock/us/{symbol}"
elif market == "cn":
url = f"https://api.example.com/stock/cn/{symbol}"
else:
return {"error": f"不支持的市场: {market}"}
response = requests.get(url, timeout=10)
data = response.json()
return {
"symbol": symbol,
"price": data.get("price"),
"change": data.get("change"),
"change_percent": data.get("change_percent"),
"market_cap": data.get("market_cap"),
}
# 使用装饰器后,工具会自动注册,不需要手动调用 ToolRegistry.register()
方法二:完整的 Tool 类(更灵活)
如果你需要更复杂的逻辑(如初始化资源、异步执行、自定义审批逻辑),可以继承 Tool 基类:
# 自定义工具示例:操作公司内部的 REST API
from hermes.core.tool import Tool, ToolParameter
from hermes.core.registry import ToolRegistry
class InternalAPITool(Tool):
def __init__(self):
super().__init__(
name="internal_api",
description="调用公司内部 API",
parameters=[
ToolParameter(name="endpoint", type="string", required=True),
ToolParameter(name="method", type="string", required=False, default="GET"),
ToolParameter(name="payload", type="object", required=False),
],
category="custom",
requires_approval=True, # 所有内部 API 调用都需要审批
)
# 初始化 API 客户端
self.client = self._init_api_client()
def _init_api_client(self):
"""初始化 API 客户端,加载认证信息"""
import os
token = os.environ.get("INTERNAL_API_TOKEN")
if not token:
raise ValueError("环境变量 INTERNAL_API_TOKEN 未设置")
return APIClient(token=token)
def execute(self, endpoint: str, method: str = "GET", payload: dict = None):
"""执行 API 调用"""
return self.client.request(endpoint, method, payload)
# 注册工具
ToolRegistry().register(InternalAPITool())
Tips
自定义工具放在
~/.hermes/custom_tools/目录下,系统启动时会自动扫描并加载。建议每个工具一个文件,文件名和工具名保持一致,方便管理。开发自定义工具时,一定要写好description参数——这是 LLM 理解你工具用途的唯一途径。描述要清晰、具体,最好包含使用示例。
5. Layer 4: 状态与持久化层(SQLite + MEMORY.md + Cron)
5.1 SQLite 数据库设计与 FTS5 全文索引
Layer 4 是 Hermes 的"记忆仓库"。它负责把所有需要长期保存的信息,以可靠、高效、可检索的方式存储起来。
Hermes 选择了 SQLite 作为默认的数据库。这个选择背后有很多考量:
为什么选择 SQLite?
- 零配置。 SQLite 是一个嵌入式数据库,不需要单独的服务器进程。数据库就是一个文件,开箱即用。
- 单文件存储。 整个数据库在一个
.db文件中,备份和迁移非常简单——复制文件就行。 - 资源占用极低。 对于个人和小团队的场景,SQLite 的性能完全够用,内存和 CPU 开销几乎可以忽略。
- Python 原生支持。 Python 标准库内置
sqlite3模块,不需要额外安装依赖。 - FTS5 全文索引。 SQLite 3.19+ 支持 FTS5(Full-Text Search 5),可以实现高效的全文检索。
常见问题
Q:SQLite 能支撑多少数据?会不会成为性能瓶颈?
A:SQLite 的官方文档说,它能处理 TB 级的数据。对于 Hermes 的使用场景(个人/小团队、主要是文本数据),SQLite 的性能完全够用。以每天 100 轮对话、每轮平均 1000 Token 计算,一年的数据量也只有几十 MB。即使数据量增长到 GB 级别,FTS5 索引的查询性能依然很好。如果确实有超大规模的需求,可以配置 Hermes 使用 PostgreSQL 等更强大的数据库(需要自行配置连接)。
数据库表结构:
Hermes 的 SQLite 数据库包含以下核心表:
-- 会话表:存储每个对话会话的元数据
CREATE TABLE sessions (
id TEXT PRIMARY KEY, -- 会话唯一 ID
created_at TIMESTAMP, -- 创建时间
updated_at TIMESTAMP, -- 最后更新时间
platform TEXT, -- 接入平台(cli/telegram/feishu/...)
user_id TEXT, -- 用户标识
title TEXT, -- 会话标题(自动生成的摘要)
status TEXT, -- 状态:active / archived / deleted
total_turns INTEGER, -- 总对话轮数
total_cost REAL -- 累计成本(美元)
);
-- 消息表:存储每条对话消息
CREATE TABLE messages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id TEXT, -- 所属会话 ID
role TEXT, -- 角色:user / assistant / system / tool
content TEXT, -- 消息内容
tool_calls TEXT, -- 工具调用记录(JSON 格式)
created_at TIMESTAMP, -- 发送时间
tokens_used INTEGER, -- 消耗的 Token 数
FOREIGN KEY (session_id) REFERENCES sessions(id)
);
-- 工具调用日志表:详细记录每次工具调用
CREATE TABLE tool_calls (
id INTEGER PRIMARY KEY AUTOINCREMENT,
message_id INTEGER, -- 关联的消息 ID
tool_name TEXT, -- 工具名称
parameters TEXT, -- 调用参数(JSON)
result TEXT, -- 执行结果
duration_ms INTEGER, -- 执行耗时(毫秒)
success BOOLEAN, -- 是否成功
created_at TIMESTAMP,
FOREIGN KEY (message_id) REFERENCES messages(id)
);
-- 记忆表:存储 MEMORY.md 的历史版本
CREATE TABLE memory_history (
id INTEGER PRIMARY KEY AUTOINCREMENT,
content TEXT, -- MEMORY.md 的内容
change_reason TEXT, -- 变更原因(如"自动更新""用户编辑")
created_at TIMESTAMP
);
-- 用户画像表:存储 USER.md 的历史版本
CREATE TABLE user_profile_history (
id INTEGER PRIMARY KEY AUTOINCREMENT,
content TEXT, -- USER.md 的内容
change_reason TEXT,
created_at TIMESTAMP
);
FTS5 全文索引:
FTS5 是 SQLite 的全文搜索引擎,它让 Hermes 能够以极快的速度搜索历史对话内容。
-- 创建 FTS5 虚拟表用于全文搜索
CREATE VIRTUAL TABLE messages_fts USING fts5(
content, -- 要索引的字段
content='messages', -- 数据来源表
content_rowid='id' -- 关联的 rowid
);
-- 自动同步触发器:当 messages 表插入/更新/删除时,FTS5 索引自动更新
CREATE TRIGGER messages_fts_insert AFTER INSERT ON messages BEGIN
INSERT INTO messages_fts(rowid, content) VALUES (new.id, new.content);
END;
CREATE TRIGGER messages_fts_delete AFTER DELETE ON messages BEGIN
INSERT INTO messages_fts(messages_fts, rowid, content)
VALUES ('delete', old.id, old.content);
END;
有了 FTS5,搜索历史对话就变得非常高效:
-- 搜索包含"Kubernetes"的历史消息
SELECT m.*, rank
FROM messages_fts
JOIN messages m ON messages_fts.rowid = m.id
WHERE messages_fts MATCH 'Kubernetes'
ORDER BY rank;
即使你的历史对话有几十万条,这个查询也能在毫秒级返回结果。
Tips
FTS5 默认使用简单的分词器,对英文支持很好,但对中文的支持有限。如果你主要用中文和 Hermes 交流,建议启用 SQLite 的 ICU 扩展或使用第三方中文分词器(如 jieba)。配置方式是在创建 FTS5 表时指定分词器:
CREATE VIRTUAL TABLE ... USING fts5(..., tokenize='icu zh_CN')。
5.2 MEMORY.md 的结构与管理
MEMORY.md 是 Hermes 最核心的创新之一。它不是简单的日志文件,而是 Agent 的"工作笔记"——Agent 在这里记录环境信息、经验教训、工作约定,以及任何它认为值得记住的东西。
MEMORY.md 的结构:
# MEMORY.md
# 这是 Hermes Agent 自动维护的工作笔记
# 请不要手动编辑此文件(除非你清楚自己在做什么)
## 环境信息
- 项目根目录: /home/user/projects
- 操作系统: Ubuntu 22.04
- Python 版本: 3.11.4
- Node.js 版本: 22.3.0
## 工作约定
- 代码风格: PEP 8
- Commit message: 英文,遵循 Conventional Commits
- 测试框架: pytest
- 优先使用 asyncio 而非同步 I/O
## 常用工具链
- 包管理: uv
- 代码格式化: ruff
- 类型检查: mypy
- Web 框架: FastAPI
## 经验教训
- 2026-04-10: Docker 容器访问宿主机服务时,不能用 localhost,要用 host.docker.internal
- 2026-04-12: 使用 OpenRouter 时需要在 header 中加 HTTP-Referer
- 2026-04-15: SQLite 的 FTS5 默认不支持中文分词,需要启用 ICU 扩展
## 项目备忘
- myapp 项目的数据库密码在 .env 文件中
- myapp 的测试数据库每次运行测试前会自动清空
- 文档站点的构建命令: cd docs && mkdocs build
## 偏好设置
- 代码注释偏好中文
- 错误处理偏好早失败(fail-fast)模式
- REST API 设计偏好 OpenAPI 规范
MEMORY.md 的管理机制:
-
自动更新。 Agent 在每次任务完成后,会自动评估"这次任务中有没有值得记住的东西"。如果有,它会生成一段简短的笔记,追加到 MEMORY.md 中。
-
字符限制。 MEMORY.md 有约 2200 字符的上限。当内容接近上限时,系统会触发"记忆压缩"——调用 LLM 对现有内容进行摘要和精简,保留最重要的信息,删除次要的。
-
版本历史。 每次 MEMORY.md 更新时,旧版本会自动保存到 SQLite 的
memory_history表中。如果你发现 Agent 最近"忘了"什么重要的东西,可以从历史版本中找回。
注意
MEMORY.md 虽然是 Agent 自动维护的,但你也可以手动编辑它。如果你发现 Agent 记错了什么,或者想主动告诉 Agent 一些重要信息,直接编辑
~/.hermes/MEMORY.md就行。修改后,建议重启 Agent 或发送/refresh命令,让 Agent 重新加载记忆。
5.3 USER.md 用户画像存储
如果说 MEMORY.md 是 Agent 的"工作笔记",那么 USER.md 就是 Agent 的"用户档案"——它记录了关于你(用户)的一切信息,让 Agent 越来越懂你。
USER.md 的结构:
# USER.md
# 这是关于用户的画像信息
# Agent 会根据这个文件调整自己的行为和回复风格
## 沟通风格
- 偏好简洁直接的回复,不喜欢冗长
- 技术术语不需要解释(假设用户已了解)
- 代码示例优先于文字描述
## 技术背景
- 全栈开发者,5 年 Python 经验
- 熟悉 FastAPI、PostgreSQL、Docker、Kubernetes
- 正在学习 Rust
## 工作习惯
- 主要工作时段: 晚上 9 点到凌晨 1 点
- 常用编辑器: VS Code + Neovim
- 操作系统: macOS(主力)+ Ubuntu(服务器)
- 偏好深色主题
## 项目信息
- 当前主要项目: 一个基于 FastAPI 的 SaaS 平台
- 项目阶段: MVP 开发中
- 技术栈: FastAPI + SQLAlchemy + React + PostgreSQL
## 偏好设置
- 时区: Asia/Shanghai (UTC+8)
- 语言: 中文优先,技术术语保留英文
- 代码风格: Black formatter, 88 字符行宽
USER.md 的自动生成与更新:
和 MEMORY.md 类似,USER.md 也是由 Agent 自动维护的。但它的更新频率更低、内容更稳定。
Agent 会在以下场景更新 USER.md: - 用户明确告诉 Agent 自己的偏好("我喜欢简洁的回复") - Agent 在长期互动中观察到的规律("用户总是在晚上 9 点后发消息") - 用户纠正了 Agent 的某种行为("请不要用这么多表情符号")
USER.md 同样有字符限制(约 1375 字符),迫使 Agent 学会"抓重点"——只记录最关键的用户信息。
Tips
USER.md 是你塑造 Agent 行为的最直接方式。如果你希望 Agent 以某种特定方式与你互动,直接在对话中告诉它,比如"以后回复我时,先给出结论再解释原因"。Agent 会把这条偏好记录到 USER.md 中,并在后续的对话中遵循。如果它没有遵循,你可以提醒它"看看你的 USER.md",它通常会立刻纠正。
5.4 Cron 定时任务调度器
Hermes 内置了一个 Cron 定时任务调度器,让 Agent 可以在指定的时间自动执行预设的任务。
你可以把它理解为 Hermes 的"闹钟"和"日程表"。
设置定时任务的方式:
# 方式一:通过对话自然语言设置
hermes
> 每天早上 9 点检查 Hacker News 的 AI 新闻,发摘要到我的 Telegram
# 方式二:通过命令行精确设置
hermes cron add "0 9 * * *" \
--task "搜索 Hacker News 的 AI 标签,提取前 10 条新闻的标题和摘要,发送到 Telegram"
# 方式三:编辑配置文件
定时任务的配置存储在 SQLite 数据库中:
CREATE TABLE cron_jobs (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT, -- 任务名称
schedule TEXT, -- Cron 表达式,如 "0 9 * * *"
task_description TEXT, -- 任务描述(自然语言)
enabled BOOLEAN, -- 是否启用
last_run TIMESTAMP, -- 上次执行时间
next_run TIMESTAMP, -- 下次执行时间
run_count INTEGER, -- 已执行次数
fail_count INTEGER, -- 失败次数
created_at TIMESTAMP
);
Cron 表达式快速参考:
格式: 分 时 日 月 星期
0 9 * * * # 每天早上 9:00
0 */6 * * * # 每 6 小时一次
0 0 * * 1 # 每周一凌晨
0 0 1 * * # 每月 1 号凌晨
*/15 * * * * # 每 15 分钟
注意
Cron 任务在后台执行时,如果遇到需要用户审批的危险操作,默认会被拒绝(因为没有用户在终端前确认)。如果你的定时任务涉及危险操作,可以在配置中设置
cron.auto_approve_safe_tools = true,让已知安全的工具自动通过审批。但对于真正危险的操作(如删除文件、执行 shell 命令),建议避免在无人值守的定时任务中使用。
5.5 数据备份与恢复策略
既然 Hermes 的所有数据都存储在本地,备份就变得非常重要。如果硬盘损坏或误删文件,你可能会丢失所有的对话历史、记忆和技能。
备份策略:
Hermes 的数据主要存储在以下几个位置:
| 数据类型 | 存储位置 | 备份方式 |
|---|---|---|
| 对话历史 | ~/.hermes/data/conversations.db |
定期复制 + SQLite 导出 |
| MEMORY.md | ~/.hermes/MEMORY.md |
版本控制(Git) |
| USER.md | ~/.hermes/USER.md |
版本控制(Git) |
| 配置文件 | ~/.config/hermes/ |
版本控制(Git) |
| 自定义工具 | ~/.hermes/custom_tools/ |
版本控制(Git) |
| 技能文件 | ~/.hermes/skills/ |
版本控制(Git) |
推荐的备份脚本:
#!/bin/bash
# hermes-backup.sh - Hermes 数据备份脚本
# 建议添加到 crontab,每天自动运行
BACKUP_DIR="$HOME/hermes-backups"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/hermes_backup_$DATE.tar.gz"
# 创建备份目录
mkdir -p "$BACKUP_DIR"
# 打包所有 Hermes 数据
tar -czf "$BACKUP_FILE" \
"$HOME/.hermes/" \
"$HOME/.config/hermes/"
# 保留最近 30 天的备份,删除旧的
find "$BACKUP_DIR" -name "hermes_backup_*.tar.gz" -mtime +30 -delete
echo "备份完成: $BACKUP_FILE"
添加到定时任务:
# 编辑 crontab
crontab -e
# 添加以下行(每天凌晨 2 点自动备份)
0 2 * * * /path/to/hermes-backup.sh >> /var/log/hermes-backup.log 2>&1
Tips
如果你的 Hermes 部署在云服务器上,建议把备份文件同步到对象存储(如 AWS S3、阿里云 OSS)或另一台机器上。不要把备份和原始数据放在同一个硬盘上——否则硬盘坏了,备份也一起没了。可以使用 rclone 工具来自动化这个同步过程。
6. Layer 5: 平台适配层(15+ 平台、6 种终端后端)
6.1 平台适配器的设计模式
Layer 5 是 Hermes 的"外交部门"——它负责和外面的世界打交道。
不同的消息平台,有着不同的 API 格式、消息类型和交互方式。Telegram 用 Bot API,飞书用开放平台的 webhook,Discord 用 Gateway 事件,微信用企业微信的接口……如果让 Agent 核心层直接去处理这些差异,代码会变得非常混乱。
Hermes 的解决方案是适配器模式(Adapter Pattern)——为每个平台写一个适配器,把平台的"方言"翻译成 Hermes 的"普通话"。
用户发送消息(通过 Telegram)
↓
[Telegram 适配器] 接收 Telegram 的 Update 对象
↓
[Telegram 适配器] 转换成 Hermes 内部的 Message 对象
↓
[Agent 核心层] 处理 Message,生成回复
↓
[Telegram 适配器] 把 Hermes 的回复转换成 Telegram 的 sendMessage 调用
↓
用户收到回复(在 Telegram 中)
每个适配器都需要实现以下接口:
# 平台适配器的标准接口(简化版)
class PlatformAdapter(ABC):
@abstractmethod
async def initialize(self) -> None:
"""初始化适配器,建立连接"""
pass
@abstractmethod
async def receive_message(self) -> Message:
"""接收来自平台的消息"""
pass
@abstractmethod
async def send_message(self, message: Message) -> None:
"""发送消息到平台"""
pass
@abstractmethod
async def send_file(self, file_path: str, caption: str = None) -> None:
"""发送文件到平台"""
pass
@abstractmethod
def format_text(self, text: str, style: TextStyle) -> str:
"""将文本格式化为平台支持的格式"""
pass
@property
@abstractmethod
def supported_features(self) -> list[str]:
"""返回该平台支持的功能列表"""
pass
当前支持的平台:
| 平台 | 接入方式 | 支持功能 |
|---|---|---|
| Telegram | Bot API | 文本、图片、文件、按钮、Markdown |
| Discord | Bot Gateway | 文本、Embed、文件、Reaction |
| Slack | Bolt SDK / Webhook | 文本、Block Kit、文件、按钮 |
| 飞书 | 开放平台 Webhook | 文本、富文本、卡片、文件 |
| 企业微信 | 企业微信 API | 文本、Markdown、文件、图文 |
| 钉钉 | 钉钉开放平台 | 文本、Markdown、ActionCard |
| 微信 | 个人号/公众号 API | 文本、图片、文件 |
| WhatsApp Business API | 文本、图片、文件 | |
| Signal | Signal CLI / API | 文本、文件 |
| Matrix | Matrix Client-Server API | 文本、HTML、文件 |
| Mattermost | Mattermost API | 文本、Markdown、文件 |
| SMTP/IMAP | 文本、HTML、附件 | |
| SMS | Twilio / 短信网关 | 纯文本 |
| Home Assistant | WebSocket API | 文本、事件触发 |
| VS Code | ACP 协议 | 文本、代码块、Diff |
Tips
不是所有平台的所有功能都完美支持。比如,某些平台不支持 Markdown 格式,Hermes 会自动降级为纯文本;某些平台有消息长度限制,Hermes 会自动拆分长消息。在配置平台接入时,建议先测试一下常用的功能(文本、代码块、文件传输),看看是否符合你的需求。
6.2 6 种终端后端的选择与配置
除了消息平台,Hermes 还支持 6 种终端后端(Terminal Backend)。终端后端决定了 Agent 执行命令和代码的环境。
| 后端 | 描述 | 适用场景 |
|---|---|---|
| local | 直接在宿主机上执行 | 个人开发、测试 |
| docker | 在 Docker 容器中执行 | 隔离要求高的场景 |
| ssh | 通过 SSH 在远程服务器上执行 | 远程运维、多服务器管理 |
| sandbox | 在轻量级沙箱中执行 | 安全敏感环境 |
| wsl | 在 WSL(Windows Subsystem for Linux)中执行 | Windows 开发者 |
| cloud | 在云函数/Serverless 环境中执行 | 弹性伸缩场景 |
配置方式:
# 查看当前终端后端
hermes config get terminal.backend
# 切换到 Docker 后端
hermes config set terminal.backend docker
# Docker 后端的额外配置
hermes config set terminal.docker.image "hermes-sandbox:latest"
hermes config set terminal.docker.volumes '["/home/user/projects:/workspace"]'
# 切换到 SSH 后端
hermes config set terminal.backend ssh
hermes config set terminal.ssh.host "192.168.1.100"
hermes config set terminal.ssh.user "deploy"
hermes config set terminal.ssh.key "~/.ssh/deploy_key"
Docker 后端的工作原理:
Agent 请求执行命令: python script.py
↓
[Hermes] 启动 Docker 容器(如果尚未运行)
↓
[Hermes] 在容器中执行: python script.py
↓
[Hermes] 捕获 stdout / stderr
↓
[Hermes] 销毁临时容器(或保留复用)
↓
[Hermes] 把结果返回给 Agent
Docker 后端的最大优势是隔离性。即使 Agent 执行了恶意或错误的命令(如 rm -rf /),破坏范围也仅限于容器内部,不会影响宿主机。
注意
Docker 后端虽然提供了隔离,但不是"绝对安全"的。如果容器以特权模式运行,或者挂载了敏感目录,恶意代码仍然可能逃逸容器。最安全的做法是:非特权容器 + 最小挂载 + 只读根文件系统。对于不可信的任务,建议使用 sandbox 后端,它提供了更严格的隔离。
6.3 消息格式转换与统一接口
不同平台的消息格式千差万别。Hermes 定义了一个统一的消息接口(Unified Message Interface),所有平台适配器都围绕这个接口工作。
统一消息结构:
@dataclass
class Message:
id: str # 消息唯一 ID
platform: str # 来源平台
platform_message_id: str # 平台原生的消息 ID
session_id: str # 所属会话
user_id: str # 发送者 ID
user_name: str # 发送者名称
content: str # 消息文本内容
content_type: str # 内容类型: text / code / image / file / mixed
attachments: list[Attachment] # 附件列表
reply_to: str # 回复的消息 ID(如果有)
mentions: list[str] # @提及的用户列表
timestamp: datetime # 发送时间
metadata: dict # 平台特有的额外数据
@dataclass
class Attachment:
type: str # 类型: image / video / audio / document
url: str # 文件 URL
filename: str # 文件名
mime_type: str # MIME 类型
size_bytes: int # 文件大小
格式转换示例:
以 Telegram 为例,当用户发送一条带图片的消息时:
# Telegram 的原始格式(Bot API)
telegram_update = {
"update_id": 123456789,
"message": {
"message_id": 42,
"from": {"id": 987654321, "first_name": "张三"},
"chat": {"id": 987654321, "type": "private"},
"date": 1713600000,
"caption": "帮我看看这张图里的代码有什么问题",
"photo": [
{"file_id": "AgACAgIAAxkBAA...", "width": 320, "height": 240},
{"file_id": "AgACAgIAAxkBAA...", "width": 800, "height": 600},
]
}
}
# Telegram 适配器转换成 Hermes 的统一消息
hermes_message = Message(
id="msg_tg_987654321_42",
platform="telegram",
platform_message_id="42",
session_id="sess_tg_987654321",
user_id="987654321",
user_name="张三",
content="帮我看看这张图里的代码有什么问题",
content_type="mixed",
attachments=[
Attachment(
type="image",
url="https://api.telegram.org/file/bot<token>/photos/xxx.jpg",
filename="photo.jpg",
mime_type="image/jpeg",
size_bytes=0, # 需要额外请求获取大小
)
],
reply_to=None,
mentions=[],
timestamp=datetime.fromtimestamp(1713600000),
metadata={"telegram_chat_type": "private"},
)
这种"统一接口"的设计,让 Agent 核心层完全不需要关心消息来自哪个平台。它看到的永远是标准的 Message 对象,处理逻辑完全一致。
6.4 平台特性的处理
不同平台有不同的"超能力"。Hermes 的适配器会尽可能利用这些平台特性,提升用户体验。
富文本渲染:
Telegram 和 Discord 原生支持 Markdown,Agent 的回复可以直接渲染为格式化的文本。但微信和企业微信对 Markdown 的支持有限,适配器会自动降级为纯文本,或者用平台的原生富文本格式(如企业微信的 markdown 消息类型)。
# Agent 生成的回复(内部格式)
reply_text = """
## 分析结果
- **问题**: 循环变量未初始化
- **位置**: `main.py` 第 42 行
- **建议**: 在使用 `i` 之前添加 `i = 0`
```python
# 修复后的代码
for i in range(10):
print(i)
"""
Telegram 适配器 → 直接发送 Markdown
微信适配器 → 转换为纯文本(或图文消息)
飞书适配器 → 转换为富文本卡片
**交互按钮:**
Telegram、Discord 和 Slack 支持内联按钮(Inline Buttons)。Hermes 的适配器可以把"选择型"的回复转换为按钮:
```python
# Agent 的回复包含选择
"我找到了 3 个可能的解决方案,你想看哪个?\n1. 方案 A\n2. 方案 B\n3. 方案 C"
# Telegram 适配器会渲染为:
# [方案 A] [方案 B] [方案 C]
# 用户点击按钮即可选择,不需要手动输入数字
文件传输:
当 Agent 生成文件(如代码、报告、图片)时,适配器会根据平台的能力选择最佳传输方式: - Telegram:直接发送文件 - 微信:上传到文件助手或群文件 - Email:作为附件发送 - CLI:保存到指定目录并显示路径
常见问题
Q:某个平台我配置了但收不到消息,怎么排查?
A:按照以下步骤排查: 1. 检查平台适配器是否已启用:
hermes gateway status2. 检查 Webhook URL 是否正确配置,并且公网可访问 3. 检查平台侧的事件订阅是否正确设置 4. 查看 Hermes 的日志:tail -f ~/.hermes/logs/gateway.log5. 尝试手动触发一个测试消息,看日志里有没有收到Q:可以在多个平台上同时使用同一个 Agent 吗?
A:可以!GatewayRunner 支持同时接入多个平台。你只需要为每个平台分别配置适配器,它们会共享同一个 Agent 实例和同一套记忆数据。这意味着你在 Telegram 上和 Agent 的对话,Agent 在 Slack 上也能记得。不过要注意:如果多个平台同时发来消息,Agent 是按顺序处理的(单线程),可能会有延迟。
7. 自学习闭环:Hermes 的灵魂
如果说五层架构是 Hermes 的"骨架",那么自学习闭环就是它的"灵魂"。这是 Hermes 与 OpenClaw 以及市面上绝大多数 Agent 框架最根本的区别所在。
7.1 完整闭环流程详解:执行 → 评估 → 创建 → 改进
Nous Research 对 Harness Engineering 的官方定义给出了五个核心层次:指令层(如何与模型对话)、约束层(允许做什么)、反馈层(错误如何回流)、记忆层(什么持久化)、编排层(多工具如何串联)。自学习闭环正是贯穿这五个层次的"活性机制"——它让系统不是被动地执行指令,而是主动地从经验中成长。
让我们用一个完整的例子,来走一遍自学习闭环的四个阶段。
场景: 你让 Hermes 帮你"把项目里的所有 Python 文件按照 PEP 8 规范格式化一遍"。
阶段一:执行(Execute)
Agent 收到任务后,开始规划和执行:
步骤 1: 搜索项目中的所有 .py 文件
→ 调用 tool: file_search(pattern="**/*.py")
→ 结果: 找到 15 个 Python 文件
步骤 2: 检查是否有格式化工具可用
→ 调用 tool: shell_exec(command="which black ruff autopep8")
→ 结果: 发现 black 和 ruff 已安装
步骤 3: 先用 black 格式化一个文件试试
→ 调用 tool: shell_exec(command="black src/main.py --check")
→ 结果: 发现 23 处格式问题
步骤 4: 执行格式化
→ 调用 tool: shell_exec(command="black src/main.py")
→ 结果: 格式化成功
步骤 5-17: 对其余 14 个文件重复上述过程...
步骤 18: 用 ruff 检查一遍,确保没有遗漏
→ 调用 tool: shell_exec(command="ruff check .")
→ 结果: 全部通过
这个执行过程涉及了 18 次工具调用。Agent 不是一次性把所有事情做完,而是逐步探索、观察结果、调整策略——这和人类解决新问题的思维方式是一致的。
阶段二:评估(Evaluate)
任务完成后,Agent 会运行一次自我回顾(Self-Review)。这是 Nous Research 官方描述的核心机制——每 5 次左右工具调用,Hermes 会问自己四个问题:
- 有效吗? —— 任务目标达成了吗?有没有遗漏?
- 什么太慢? —— 哪些步骤可以优化?有没有不必要的重复?
- 用户拒绝了什么? —— 用户有没有中途干预、纠正或取消某个操作?
- 有可复用模式吗? —— 这个任务的解决思路,能不能抽象成一个通用的方法?
在这个例子中,Agent 的自我评估可能是这样的:
## 任务回顾: Python 代码格式化
### 有效性评估
- ✅ 成功格式化了 15 个 Python 文件
- ✅ 通过了 ruff 检查
- ⚠️ 文件较多时,逐个执行效率较低
### 效率评估
- 问题: 对每个文件单独调用 black,产生了 15 次工具调用
- 优化: black 支持批量处理,可以用 `black .` 一次性格式化整个目录
- 节省时间: 约 60%(15 次调用 → 1 次调用)
### 用户反馈
- 用户没有干预或纠正
- 用户对结果表示满意
### 可复用模式
- 这是一个典型的"批量代码格式化"任务
- 通用模式: 搜索文件 → 选择工具 → 批量执行 → 验证结果
- 建议创建 Skill: "batch_format_python"
Tips
自我回顾不是每次任务都一定会触发。官方的设计是:每完成约 5 次工具调用的任务后,系统会评估是否值得进行一次回顾。如果任务非常简单(比如只调用了 1-2 个工具),回顾的成本可能大于收益,系统就会跳过。这种"选择性回顾"的机制,既保证了学习的发生,又避免了不必要的开销。
阶段三:创建(Create)
如果自我回顾发现"有可复用的模式",系统就会触发 Skill 自动生成。
但这里有一个非常重要的规则——技能不会在每次任务后自动生成。根据 Nous Research 的官方描述,Skill 的创建需要满足特定的触发条件:
触发条件一:检测到重复模式(通常涉及 5+ 工具调用)
Agent 会维护一个"任务指纹"数据库。每次完成任务后,它计算任务的模式指纹(涉及哪些工具、工具的调用顺序、参数特征等)。如果某个指纹出现了多次(或一次但工具调用次数超过阈值),就认为这是一个"值得固化的模式"。
触发条件二:用户进行了纠正
如果用户说"不对,你应该这样做",Agent 会把用户的纠正视为高价值信号。即使用户纠正的是一件小事,Agent 也会记录下来——因为这代表了用户的真实偏好。
触发条件三:遇到错误并最终找到了可行路径
如果 Agent 在执行过程中遇到了错误(如工具调用失败、返回了异常数据),然后通过尝试不同的方法最终解决了问题,这个"试错 → 成功"的过程会被视为一个值得学习的模式。
触发条件四:发现了非显而易见的工作流
有些任务的解决方案需要多个工具以特定顺序协作,这种"组合智慧"是人类可能想不到的。当 Agent 自己发现了这样的工作流时,它会意识到"这个方法很有价值,应该记下来"。
在我们的例子中,Agent 满足了触发条件一(18 次工具调用,远超 5 次阈值),所以会生成一个 Skill:
# Skill: batch_format_python
# 自动生成于: 2026-04-15
# 触发原因: 任务涉及 18 次工具调用,检测到可复用的批量格式化模式
## 描述
批量格式化项目中的所有 Python 文件,确保符合 PEP 8 规范。
## 适用场景
- 项目中有多个 Python 文件需要统一格式
- 需要确保代码风格一致性
- 在提交代码前进行格式化检查
## 执行流程
1. 搜索项目中的所有 .py 文件
2. 检查可用的格式化工具(black / ruff / autopep8)
3. 优先使用 black 进行批量格式化: `black .`
4. 使用 ruff 进行静态检查: `ruff check .`
5. 如果有错误,尝试自动修复: `ruff check . --fix`
6. 报告结果
## 注意事项
- 批量格式化前,建议先运行 `black --check` 查看有哪些文件需要修改
- 如果项目中有特定的格式化配置(如 pyproject.toml),工具会自动读取
- 格式化会修改文件内容,确保文件已提交到版本控制
## 历史表现
- 创建后已使用: 3 次
- 成功率: 100%
- 平均工具调用次数: 3 次(相比首次的 18 次,效率提升 83%)
阶段四:改进(Improve)
Skill 创建后,并不是一成不变的。每次 Skill 被再次使用时,Agent 都会观察执行效果,并在必要时对 Skill 进行修补和优化。
比如,两周后你又让 Agent 格式化 Python 文件。这次 Agent 直接调用了 batch_format_python Skill,流程简化为:
步骤 1: 调用 Skill "batch_format_python"
→ 执行: black .
→ 结果: 报错!black 的版本更新了,某个参数已弃用
步骤 2: 错误检测与修复
→ Agent 发现 black 的新版本不再支持旧参数
→ Agent 自动修改 Skill 文件,更新命令
→ 更新后的命令: black . --line-length 88
步骤 3: 重新执行
→ 执行: black . --line-length 88
→ 结果: 成功
步骤 4: Skill 更新
→ 把修正后的命令写回 Skill 文件
→ 添加注释: "2026-04-29: 适配 black 24.x 版本"
关键:无需用户干预,Agent 自主完成!
整个过程用户只需要说"帮我格式化 Python 文件",Agent 会自动调用已有的 Skill、自动检测错误、自动修复 Skill、自动完成任务。用户甚至不知道中间发生了什么——只看到一个成功的结果,和一条简短的日志:"Skill 'batch_format_python' 已自动更新以适配新版本的 black"。
7.2 触发条件详解
根据 Nous Research 的官方描述,我们再来系统梳理一下自学习闭环的触发条件:
| 触发条件 | 描述 | 优先级 |
|---|---|---|
| 5+ 工具调用 | 任务涉及 5 次或更多工具调用,表明复杂度足够高 | 高 |
| 错误修复 | 遇到错误后找到了可行的替代路径 | 高 |
| 用户纠正 | 用户明确纠正了 Agent 的做法 | 最高 |
| 非显而易见的工作流 | Agent 自主发现了高效的工具组合方式 | 中 |
| 周期性任务 | 相同或相似的任务在固定周期重复出现 | 中 |
用户纠正为什么优先级最高?
因为用户的纠正代表了"真实的人类偏好",这是最有价值的学习信号。Agent 可能会误判什么是最优方案,但用户知道自己想要什么。当用户说"不要这样做,要那样做"时,Agent 会把这条纠正视为"黄金规则",优先记录和应用。
7.3 技能的四个信任等级
在深入了解 Skill 的生成算法之前,我们需要先理解 Hermes 的技能信任等级体系。根据 Nous Research 的官方设计,所有 Skill 被分为四个信任等级,这个分级机制是安全架构的重要组成部分。
| 信任等级 | 英文名 | 来源 | 安全策略 |
|---|---|---|---|
| 内置 | Built-in | 随 Hermes 核心框架一起发布 | 完全信任,自动启用 |
| 官方 | Official | Nous Research 官方维护的技能库 | 高信任,需手动安装但无需额外审批 |
| 可信 | Verified | 经过社区审核的第三方技能 | 中信任,安装时提示风险说明 |
| 社区 | Community | 未经审核的社区贡献 | 低信任,使用时需要额外审批 |
内置技能(Built-in):
内置技能是 Hermes 核心代码库的一部分,随框架一起安装。它们经过 Nous Research 团队的严格测试,是"开箱即用"的。当前 Hermes 包含 74 个内置技能,涵盖了最常用的开发工作流。
内置技能的特点是: - 与 Hermes 核心版本同步更新 - 有完整的单元测试覆盖 - 不会自动连接外部网络(除非用户明确配置) - 执行时不需要额外的用户审批
官方技能(Official):
官方技能由 Nous Research 维护,但不随核心框架一起发布。它们存放在官方的技能仓库中,用户需要手动安装:
hermes skills browse # 浏览官方技能库
hermes skills install k8s # 安装 Kubernetes 相关技能
hermes skills install git-pr # 安装 Git PR 工作流技能
当前官方可选技能有 44 个。这些技能同样经过官方测试,但因为它们针对特定场景(如 Kubernetes、MLOps、特定 SaaS 工具),不适合所有用户,所以没有内置。
可信技能(Verified):
可信技能来自社区贡献者,但经过了 Nous Research 或核心维护者的审核。审核内容包括: - 代码安全性检查(是否包含恶意操作) - 功能正确性验证 - 文档完整性检查 - 依赖项安全扫描
审核通过后,技能会被标记为"Verified",在 Skills Hub 中显示特殊的信任徽章。
社区技能(Community):
社区技能是任何人都可以上传和分享的 Skill,未经审核。当前 Skills Hub 上有 521 个社区技能,加上内置和官方的,总计 639 个技能。
社区技能的使用策略是"谨慎乐观": - 安装时会显示明确的"未审核"警告 - 首次执行时,所有涉及的工具调用都需要用户审批 - 用户可以查看 Skill 的源代码(所有 Skill 都是明文文档),自行判断安全性 - 使用几次后如果没有问题,可以选择"信任此 Skill",后续不再逐个审批
Tips
技能信任等级不是固定不变的。一个社区技能如果被大量用户使用、积累了良好的评价、且作者愿意配合审核,它可以被提升为"可信"甚至"官方"等级。反过来,如果一个官方技能长期无人维护、与新版 Hermes 不兼容,它也可能被降级。这种动态的等级机制,激励了技能作者持续维护和改进自己的作品。
7.4 Skill 自动生成的算法逻辑
Skill 自动生成背后的算法,是 Hermes 最精妙的技术实现之一。让我们掀开盖子,看看里面是怎么运转的。
步骤一:任务模式提取
Agent 完成任务后,系统会提取任务的"模式指纹":
# 任务模式指纹(简化版)
task_pattern = {
"tool_sequence": [ # 工具调用序列
"file_search",
"shell_exec",
"shell_exec",
"shell_exec",
...
],
"tool_categories": [ # 涉及的类别
"filesystem",
"system",
],
"parameter_patterns": { # 参数模式
"file_search.pattern": "**/*.py",
"shell_exec.command": "black*",
},
"execution_time_ms": 15000,
"success": True,
"user_intervention": False,
}
步骤二:模式匹配与去重
系统会把当前任务的模式,和已有的 Skill 库进行比对:
- 如果匹配度 > 90%,认为这个任务已经被 Skill 覆盖了,不需要新建
- 如果匹配度在 50%-90% 之间,认为这是对现有 Skill 的扩展或变体,更新现有 Skill
- 如果匹配度 < 50%,认为这是一个全新的模式,创建新的 Skill
步骤三:Skill 内容生成
对于需要新建的 Skill,系统会调用 LLM 生成 Skill 文档。输入包括: - 任务的原始需求 - 完整的工具调用历史(含参数和结果) - 自我回顾的评估报告 - 类似 Skill 的参考模板
LLM 基于这些信息,生成结构化的 Skill 文档——包括描述、适用场景、执行流程、注意事项等。
步骤四:质量校验
生成的 Skill 不是直接生效的,而是要经过一轮质量校验:
- 语法校验 —— Skill 文件格式是否正确?
- 引用校验 —— Skill 中引用的工具是否都存在?
- 安全校验 —— Skill 中是否包含危险操作?是否需要标记为 requires_approval?
- 效果校验 —— 用同一个任务测试 Skill 的效果,确认它能复现成功的结果
只有通过所有校验的 Skill,才会被正式加入 Skill 库。
7.5 技能进化的版本管理
Skill 不是静态的文档,而是会不断进化的"活知识"。Hermes 为每个 Skill 维护了版本历史:
skills/
├── batch_format_python/
│ ├── skill.md # 当前版本
│ ├── skill.v1.md # 版本 1(创建时)
│ ├── skill.v2.md # 版本 2(修复了 black 参数)
│ └── skill.v3.md # 版本 3(增加了 ruff 自动修复步骤)
每次 Skill 被修改时,旧版本会被保留,新版本会成为默认使用的版本。这种版本管理的好处是:
- 如果新版本的 Skill 出了问题,可以方便地回滚到旧版本
- 可以对比不同版本的差异,观察 Skill 的进化轨迹
- 多个 Agent 实例可以共享 Skill,但各自保持独立的版本偏好
注意
Skill 的版本管理是自动的,但你也可以手动干预。如果你发现某个 Skill 的最新版本不如旧版本好用,可以手动恢复旧版本:
hermes skills restore batch_format_python --version 2。或者你也可以编辑 Skill 文件,手动优化它的内容。Agent 会尊重你的手动修改,并在未来的自动更新中保留你的改动。
7.6 社区实测数据:重复任务成功率提升 30%+
自学习闭环的效果如何?让我们看看社区用户的实测数据。
根据 Nous Research 在社区中收集的数据,以及本书作者对数十位用户的访谈,我们总结出了以下关键指标:
指标一:重复任务效率提升
| 任务类型 | 首次执行(工具调用次数) | 复用时(工具调用次数) | 效率提升 |
|---|---|---|---|
| Python 代码格式化 | 18 次 | 3 次 | 83% |
| 部署到 Kubernetes | 25 次 | 5 次 | 80% |
| 数据库迁移 | 15 次 | 4 次 | 73% |
| 生成周报 | 12 次 | 2 次 | 83% |
| API 接口测试 | 20 次 | 6 次 | 70% |
指标二:成功率提升
根据社区问卷(N=120),用户报告了以下体验:
- 78% 的用户 表示,Agent 在处理重复任务时的成功率明显提升
- 平均提升幅度约 35% —— 从首次执行的约 65% 成功率,提升到复用 Skill 后的约 88% 成功率
- 成功率提升的主要原因:
- Skill 固化了的正确路径(避免重复犯错)
- Skill 中记录了注意事项(提前规避已知问题)
- Skill 的参数经过优化(更精确的调用)
指标三:用户干预减少
- 首次执行复杂任务时,用户平均需要干预 3.2 次(纠正、确认、补充信息)
- Skill 复用时,用户平均只需要干预 0.4 次
- 干预次数减少约 87%
这些数据表明,自学习闭环不是一个"炫技"的功能,而是能带来实实在在的效率提升的核心机制。
7.7 与强化学习的类比
自学习闭环的设计,和机器学习中的强化学习(Reinforcement Learning)有一些有趣的相似之处。
在强化学习中: - Agent 在环境中执行动作 - 环境 返回奖励(正向或负向) - Agent 根据奖励调整策略,目标是最大化长期累积奖励
在 Hermes 的自学习闭环中: - Agent 执行任务(执行动作) - 结果 告诉 Agent 任务是否成功(奖励信号) - Skill 的创建和改进 就是策略的调整
但两者之间也有重要的区别:
| 维度 | 强化学习 | Hermes 自学习闭环 |
|---|---|---|
| 学习速度 | 需要大量试错(数百万次) | 几次成功体验即可 |
| 目标定义 | 需要人工设计奖励函数 | 目标隐含在任务完成度中 |
| 泛化能力 | 需要大量数据才能泛化 | 基于 LLM 的推理能力,少量数据即可抽象 |
| 可解释性 | 策略通常是黑盒(神经网络) | Skill 是人类可读的文档 |
| 安全性 | 可能学到危险策略 | 有命令审批和预算机制约束 |
Hermes 的自学习闭环,可以看作是一种"轻量级强化学习"——它借鉴了强化学习的核心思想(从经验中学习),但通过 LLM 的推理能力大大减少了所需的试错次数,同时通过 Skill 文档的形式保证了可解释性和可审计性。
8. 记忆系统架构:四层温度模型
8.1 热记忆(即时):当前会话上下文
Hermes 的记忆系统采用了 Nous Research 官方定义的四层温度模型。这个模型的核心思想是:不同重要程度的信息,应该存储在不同"温度"的记忆中,并以不同的频率被检索和使用。
热记忆(Hot Memory) 是最"热"的一层——它就在 Agent 的"眼前",是 Agent 当前能直接看到的所有信息。
热记忆包括: - 当前会话的系统提示(System Prompt) - MEMORY.md 的内容(Agent 的工作笔记) - USER.md 的内容(用户画像) - 当前会话的最近 N 轮对话历史 - 当前任务相关的 Skill 内容 - 可用的工具描述(按需加载)
热记忆的特点是:访问速度极快(内存中)、信息完整、但容量有限。 热记忆的总 Token 数不能超过模型的上下文窗口上限。当热记忆接近上限时,系统会启动"降温"机制——把较旧的信息转移到温记忆或冷记忆中。
热记忆的容量限制:
┌─────────────────────────────────────────┐
│ 系统提示 + MEMORY.md + USER.md │ ← 固定占用
│ (~500-1000 tokens) │
├─────────────────────────────────────────┤
│ 当前会话对话历史 │ ← 动态占用
│ (~剩余空间的 60%) │
├─────────────────────────────────────────┤
│ 工具描述 + Skill 内容 │ ← 按需加载
│ (~剩余空间的 40%) │
└─────────────────────────────────────────┘
总容量 = 模型的上下文窗口上限
Tips
如果你觉得 Agent "忘了"刚刚说过的话,可能是因为当前会话的对话历史太长,旧的消息被"挤出"了热记忆。你可以发送
/summary命令,让 Agent 生成会话摘要,把之前的对话压缩成一段简短的总结。这样既能保留关键信息,又能释放热记忆空间。
8.2 温记忆(持久):MEMORY.md + USER.md
温记忆(Warm Memory) 是热记忆的"后备存储"。它不像热记忆那样随时在 Agent 的"眼前",但每次新会话开始时,它会被加载到热记忆中。
温记忆的核心载体就是两个文件: - MEMORY.md(约 2200 字符上限) - USER.md(约 1375 字符上限)
这两个文件的字符限制,是 Nous Research 刻意设计的"有界记忆"机制。根据官方的设计理念:有限容量不是缺陷,而是特性。
为什么有限容量是"特性"?让我们深入理解这个设计哲学:
假设一:无限记忆 → 信息膨胀 → 检索噪声 → 效率下降
如果 Agent 可以把所有事情都记下来,它的"笔记"会越来越厚。每次做决策时,它都要在厚厚的笔记中翻找相关信息。笔记越厚,翻找越慢,找到错误信息的概率也越高。最终,Agent 会被自己的记忆淹没。
这就像一个从不扔东西的囤积者——他的房子里堆满了物品,需要某样东西时,反而很难找到。
假设二:有限容量 → 被迫整合 → 精简上下文 → 效率提升
当 Agent 知道"我只能记这么点东西"时,它被迫学会优先级管理。每次更新 MEMORY.md 时,它都要判断:这条信息重要吗?值得替换掉已有的某条信息吗?有没有办法把两条信息合并成一条更精炼的?
这种"被迫精简"的过程,实际上提升了信息的质量。留下来的,都是 Agent 认为最重要、最有用的信息。
就像一个背包容量有限的旅行者——他不能把所有东西都带着,只能精选最必要的物品。这个约束,反而让他的行囊更高效。
有界记忆的设计理念:
无限记忆 有界记忆
↓ ↓
什么都记 只记最重要的
↓ ↓
上下文膨胀 上下文精简
↓ ↓
检索噪声大 检索精准
↓ ↓
缓存失效 缓存命中率高
↓ ↓
效率下降 效率提升
注意
有界记忆的设计,依赖于 LLM 的"摘要能力"。如果 LLM 在压缩记忆时丢失了关键信息,效果就会打折扣。因此,Nous Research 在 MEMORY.md 的更新算法中加入了"关键信息保留"策略——某些类型的信息(如环境配置、安全规则)被标记为"不可删除",在压缩时优先保留。你也可以通过配置,手动标记某些信息为"高优先级"。
8.3 冷记忆(检索):SQLite + FTS5 + LLM 摘要
冷记忆(Cold Memory) 是存储量最大、但访问频率最低的一层。它包括:
- SQLite 数据库中的所有历史对话
- 过去的 MEMORY.md 版本
- 过去的 USER.md 版本
- 工具调用日志
- Skill 的历史版本
冷记忆的特点是:存储量大(GB 级别)、访问需要检索、检索结果需要进一步处理。
当 Agent 需要查找某个久远的记忆时,流程是这样的:
Agent: "用户之前提到过一个 Docker 网络问题的解决方法,我不记得具体是什么了"
↓
[冷记忆检索] 使用 FTS5 搜索关键词 "Docker" "网络"
↓
FTS5 返回: 3 条相关对话(来自 2 个月前的会话)
↓
[LLM 摘要] 把 3 条对话的内容发送给 LLM,请求生成摘要
↓
LLM 返回摘要: "2026-02-20,用户在部署 Flask 应用时遇到 Docker 容器无法访问宿主机服务的问题。解决方案是使用 host.docker.internal 替代 localhost。"
↓
[加载到热记忆] 把摘要加入当前上下文
↓
Agent: "我想起来了!Docker 容器访问宿主机要用 host.docker.internal"
这个"检索 → 摘要 → 加载"的流程,有几个关键设计:
- FTS5 负责快速筛选。 从海量历史记录中,秒级定位到相关记录。
- LLM 负责精炼。 原始对话记录可能很长、很杂乱,LLM 把它提炼成一段简洁的摘要。
- 只加载摘要到热记忆。 不是把完整的对话记录塞进上下文,而是只加载精华部分,节省 Token。
8.4 外部记忆(扩展):Honcho、Mem0 等 8 种
外部记忆(External Memory) 是 Hermes 记忆系统的"扩展卡"。它允许 Agent 接入第三方记忆服务,突破本地存储的限制。
根据 Nous Research 的官方文档,Hermes 当前支持以下外部记忆服务:
| 服务 | 类型 | 特点 |
|---|---|---|
| Honcho | 用户建模 | 行为模式推导、工作习惯分析、自适应回复 |
| Mem0 | 记忆层 | 跨平台记忆同步、记忆语义检索 |
| OpenViking | 向量数据库 | 大规模语义检索、知识图谱 |
| Pinecone | 向量数据库 | 云端托管、高并发、实时更新 |
| Weaviate | 向量数据库 | 开源、GraphQL 接口、多模态 |
| Chroma | 向量数据库 | 轻量级、本地优先、易用 |
| Qdrant | 向量数据库 | Rust 实现、高性能、过滤检索 |
| Milvus | 向量数据库 | 分布式、企业级、大规模 |
外部记忆的接入方式:
# ~/.config/hermes/config.yaml
memory:
external:
provider: honcho # 选择外部记忆服务
api_key: "${HONCHO_API_KEY}" # API 密钥(从环境变量读取)
project_id: "my-project" # 项目 ID
# Honcho 特有的配置
behavior_analysis: true # 启用行为模式分析
habit_tracking: true # 启用工作习惯追踪
style_adaptation: true # 启用回复风格自适应
外部记忆不是必需的。对于个人用户来说,SQLite + FTS5 的冷记忆已经完全够用。外部记忆主要适用于: - 需要跨设备同步记忆的用户 - 企业级部署,需要集中式记忆管理 - 需要大规模语义检索的高级场景
8.5 记忆的生命周期管理
信息在 Hermes 的记忆系统中,会经历一个完整的生命周期:
诞生: 信息首次产生(用户输入、工具结果、Agent 输出)
↓
热记忆: 立即加载到当前上下文
↓
评估: 这条信息重要吗?值得长期记住吗?
↓
├─ 是 → 写入温记忆(MEMORY.md / USER.md)
│ ↓
│ 定期压缩:内容超过字符限制时,触发 LLM 摘要
│ ↓
│ 历史归档:旧版本保存到 SQLite
│
└─ 否 → 保留在会话历史中(冷记忆)
↓
定期清理:超过保留期限的会话自动归档或删除
会话保留策略:
# 会话数据保留配置
retention:
session_keep_days: 90 # 会话保留 90 天
archive_after_days: 30 # 30 天后归档(从热记忆中移除)
compress_after_turns: 20 # 超过 20 轮后自动摘要压缩
max_sessions_per_user: 100 # 每个用户最多保留 100 个活跃会话
8.6 隐私保护:纯本地存储的安全优势
Hermes 的一个核心安全特性是:默认情况下,所有记忆数据都存储在本地。
这意味着: - 你的对话历史不会上传到任何云端服务器 - 你的 MEMORY.md 和 USER.md 只存在于你自己的硬盘上 - 即使 Nous Research 倒闭了,你的数据依然安全
这种"本地优先"的设计,在当前这个数据隐私日益敏感的时代,是一个巨大的竞争优势。
常见问题
Q:如果使用外部记忆服务(如 Honcho),数据还安全吗?
A:这取决于你选择的服务。Honcho 等第三方服务有自己的隐私政策,你需要仔细阅读。好消息是:外部记忆是可选的,不是强制的。如果你不信任任何第三方服务,完全可以只用本地存储。另外,即使使用外部服务,核心的 MEMORY.md 和 USER.md 仍然保存在本地,外部服务只是作为补充。
Q:我的 SQLite 数据库文件会不会很大?
A:以典型的使用强度计算(每天 50 轮对话,每轮平均 1000 Token),一年的数据量大约是 200-300 MB。对于现代硬盘来说,这完全在可接受范围内。如果你确实需要清理旧数据,可以使用
hermes session cleanup --before 2026-01-01命令删除指定日期之前的会话。
9. Honcho 用户建模模块
9.1 Honcho 是什么
Honcho 是 Nous Research 开发的一个用户建模(User Modeling)模块,它的目标是让 Agent 不仅能"记住"用户说过什么,还能"理解"用户是什么样的人。
这个模块是可选的——你不启用它,Hermes 依然能正常工作。但启用之后,Agent 会获得一种"读心术"般的能力:它能从你的行为中推导出你的工作习惯、沟通风格、甚至情绪状态,然后自动调整自己的行为来配合你。
你可以把 Honcho 想象成一个"用户行为分析师"。它坐在一旁,默默地观察你和 Agent 的每一次互动,然后画出一幅"用户画像"——不是静态的表单,而是动态演化的模型。
9.2 行为模式推导机制
Honcho 的核心能力,是从海量交互数据中自动推导行为模式。
它的分析维度包括:
维度一:沟通风格。
Honcho 会分析你的消息特征: - 消息的平均长度(简洁型 vs 啰嗦型) - 使用的语言风格(正式 vs 随意) - 表情符号和标点符号的使用习惯 - 提问的方式(直接提问 vs 描述背景后提问)
基于这些分析,Agent 会调整它的回复风格来匹配你。如果你喜欢简洁,Agent 就会少说废话;如果你喜欢详细解释,Agent 就会多给背景信息。
维度二:技术偏好。
Honcho 会观察你在技术话题上的选择: - 你经常提到哪些编程语言、框架、工具 - 你在解决问题时偏好什么思路(暴力枚举 vs 优雅算法) - 你对新技术的态度(尝鲜型 vs 保守型)
这些信息帮助 Agent 在给你建议时,优先考虑你熟悉和偏好的技术栈。
维度三:工作节律。
Honcho 会记录你的活跃时间模式: - 一天中什么时段你最活跃 - 工作日和周末的使用模式差异 - 任务类型的时段分布(上午喜欢写代码、晚上喜欢读文档)
基于这些节律,Agent 可以做出更贴心的安排——比如不会在凌晨 3 点给你发非紧急的通知。
维度四:情绪触发点。
这是一个更微妙但更有价值的维度。Honcho 会尝试识别: - 什么类型的问题会让你感到沮丧(如反复出错的配置、复杂的权限问题) - 什么类型的话题会让你兴奋(如新功能的探索、性能优化的挑战) - 你的耐心阈值(在第几次重试失败后你会放弃)
当然,Honcho 不会"读心"——它只能基于可观察的行为做推断。但这些推断,足以让 Agent 在互动中更加"体贴"。
9.3 工作习惯分析
Honcho 的工作习惯分析,可以细到令人惊叹的程度。以下是一些真实的能力示例:
代码风格推断:
通过分析你在代码相关对话中的偏好,Honcho 可以推断出: - 你喜欢什么命名规范(snake_case vs camelCase) - 你的注释风格(详细文档字符串 vs 简洁行内注释) - 你的错误处理偏好(异常捕获 vs 提前返回) - 你的导入排序习惯
然后,当 Agent 帮你生成或修改代码时,它会自动遵循这些风格。
作息规律分析:
Honcho 的用户作息报告(示例):
活跃时段:
- 工作日: 21:00 - 01:00 (峰值 22:30)
- 周末: 14:00 - 18:00, 21:00 - 02:00
- 几乎不在 08:00 - 12:00 活跃
任务类型分布:
- 21:00-23:00: 代码开发 (65%), 调试 (25%), 文档 (10%)
- 23:00-01:00: 学习研究 (40%), 自动化任务 (35%), 代码审查 (25%)
建议的定时任务时段:
- 日报生成: 00:30(用户睡前最后查看)
- 代码检查: 20:45(用户开始活跃前完成)
- 备份任务: 03:00(用户完全不活跃的时段)
情绪触发点识别:
Honcho 的情绪分析(示例):
高挫败感场景:
- Docker 网络配置问题 (挫败指数: 8.5/10)
- 权限相关的错误 (挫败指数: 7.2/10)
- 第三方 API 的文档不清晰 (挫败指数: 6.8/10)
应对策略:
- 遇到 Docker 问题时,主动提供更详细的步骤说明
- 遇到权限问题时,先解释"为什么需要这个权限"再给出解决方案
- 遇到文档不清的 API 时,主动搜索替代方案或社区讨论
9.4 自适应回复风格调整
基于 Honcho 的分析,Agent 的自适应回复风格调整体现在方方面面:
示例一:沟通风格的匹配。
如果你通常发短消息、直接提问:
你: 怎么改端口?
Agent(适配简洁风格):
在 config.yaml 里改 server.port。
或者命令行: hermes config set server.port 8080
如果你通常发长消息、喜欢描述背景:
你: 我现在在部署一个 FastAPI 应用,想把它跑在 8080 端口上,
但是默认好像是用 8000,我想知道怎么改成 8080?
Agent(适配详细风格):
好的,把 FastAPI 的端口从 8000 改成 8080 很简单。
FastAPI 默认使用 8000 端口,这通常是在启动命令里指定的。
你有几种方式可以改:
方式一:修改启动命令
uvicorn main:app --host 0.0.0.0 --port 8080
方式二:修改代码中的配置
import uvicorn
uvicorn.run(app, host="0.0.0.0", port=8080)
方式三:通过 Hermes 的配置(如果你在用 Hermes 的网关功能)
hermes config set server.port 8080
推荐方式一,最简单直接。
示例二:技术深度的适配。
如果你被 Honcho 标记为"资深开发者",Agent 不会浪费口舌解释基础概念。如果你被标记为"初学者",Agent 会主动给出更多背景解释和类比。
你: 帮我解释一下 asyncio
Agent(对资深用户):
asyncio 的核心是事件循环 + 协程调度。
你遇到的问题大概率是:
1. 在同步代码里调了 async 函数(忘了 await)
2. 创建了事件循环但没正确关闭
3. 用了阻塞式 I/O 导致事件循环卡住
具体是哪种情况?贴一下代码。
---
Agent(对初学者):
asyncio 是 Python 里做"多任务并发"的一种方式。
你可以把它想象成一个"餐厅经理":
- 服务员 A 去给顾客 1 点菜(开始一个任务)
- 在等顾客 1 想的时候,服务员 A 去给顾客 2 倒水(不等上一个任务完成,就开始下一个)
- 顾客 1 想好了,服务员 A 再回来记录(任务恢复)
关键点:一个服务员(一个线程)可以同时服务多个顾客(多个任务),
关键是"不等"——利用了等待的时间去做别的事。
在代码里,"async def" 定义一个可以"暂停"的函数,
"await" 就是"暂停点"——在这里,函数暂停,去做别的事,等条件满足再回来。
想要一个具体的代码示例吗?
9.5 配置与调优
Honcho 模块默认是禁用的,因为涉及隐私数据的分析。如果你希望启用它,需要明确配置:
# ~/.config/hermes/config.yaml
honcho:
enabled: true # 启用 Honcho
analysis_level: "standard" # 分析级别: minimal / standard / deep
# 各维度分析的开关
dimensions:
communication_style: true # 沟通风格分析
tech_preferences: true # 技术偏好分析
work_rhythm: true # 工作节律分析
emotion_tracking: false # 情绪追踪(默认关闭,更敏感)
# 隐私设置
privacy:
local_only: true # 分析结果只保存在本地
anonymize_before_cloud: true # 如需上传到外部服务,先匿名化
retention_days: 365 # 分析数据保留 365 天
分析级别的区别:
| 级别 | 数据收集 | 分析深度 | 隐私影响 |
|---|---|---|---|
| minimal | 只收集消息元数据(时间、长度、类型) | 基础模式识别 | 极低 |
| standard | 收集消息内容,但不存储原始文本 | 多维度行为建模 | 低 |
| deep | 收集完整交互数据,用于精细建模 | 情绪和习惯深度分析 | 中 |
注意
Honcho 的 deep 级别会收集更多数据,包括消息内容的完整文本。虽然这些数据默认只保存在本地,但如果你对隐私非常敏感,建议使用 minimal 或 standard 级别。你也可以随时运行
hermes honcho export导出 Honcho 收集的所有数据,查看它到底知道些什么,或者运行hermes honcho reset清空所有分析数据,从头开始。
10. 安全架构
10.1 命令审批机制
我们在前面已经多次提到了"命令审批",这一节来系统地讲解它的工作原理和配置方法。
审批机制的触发条件:
一个工具调用是否需要审批,由以下因素共同决定:
- 工具自身的
requires_approval标记。 每个工具在注册时都会声明自己是否属于需要审批的类型。 - 用户的全局配置。 你可以在配置中设置
terminal.require_approval = true/false。 - 当前的后端环境。 在 Docker 沙箱中执行的命令,审批要求可能比在本地执行更宽松(因为隔离性更强)。
- 用户的实时选择。 在某次审批中,用户可以选择"允许本次会话的所有同类操作",这会临时绕过后续的同类审批。
默认需要审批的操作:
| 操作类型 | 示例 | 风险等级 |
|---|---|---|
| 删除文件/目录 | rm, rmdir |
高 |
| 修改系统配置 | 编辑 /etc/ 下的文件 |
高 |
| 执行任意 Shell 命令 | bash -c "..." |
高 |
| 网络出站连接 | curl 到外部 URL |
中 |
| 安装软件包 | pip install, apt install |
中 |
| 修改环境变量 | export PATH=... |
低 |
审批界面(CLI 模式):
⚠️ Agent 请求执行需要审批的操作
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
工具: terminal_exec
描述: 在终端执行命令
风险等级: 🔴 高
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
命令:
rm -rf ./temp_build/
影响分析:
• 将删除目录: /home/user/project/temp_build/
• 该目录包含 47 个文件,总大小 12.3 MB
• 此操作不可撤销
建议:
✅ 目录内容看起来是构建产物(.o 文件、缓存等)
⚠️ 但目录名 "temp_build" 不是标准的构建目录名
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请选择:
[Y] 确认执行 [N] 拒绝
[E] 编辑命令 [D] 查看详情
[A] 允许本次会话的所有 rm 操作
>
这个界面设计体现了几个安全原则:
- 信息透明。 用户能看到完整的命令、影响分析和风险评估。
- 不可撤销性提醒。 对于危险操作,明确提示"此操作不可撤销"。
- 智能建议。 系统会尝试分析命令的意图,给出参考建议(如"这看起来是构建产物")。
- 分级响应。 用户可以选择单次确认、编辑后确认、或批量授权。
10.2 沙箱执行环境
除了命令审批,Hermes 还提供了沙箱执行环境,作为第二层安全防护。
沙箱的类型:
| 沙箱类型 | 隔离级别 | 资源开销 | 适用场景 |
|---|---|---|---|
| 进程级沙箱 | 低(仅限制系统调用) | 极低 | 快速脚本执行 |
| Docker 沙箱 | 中(容器隔离) | 中 | 通用开发和测试 |
| Firejail 沙箱 | 中高(命名空间隔离) | 低 | 本地安全执行 |
| gVisor 沙箱 | 高(用户态内核) | 高 | 高风险不可信代码 |
| Kata 沙箱 | 最高(轻量虚拟机) | 很高 | 多租户安全隔离 |
Docker 沙箱的配置:
terminal:
backend: docker
docker:
image: "hermes-sandbox:latest" # 沙箱镜像
network: "none" # 禁用网络(可选)
cap_drop: ["ALL"] # 丢弃所有 Linux capabilities
read_only: true # 根文件系统只读
tmpfs:
- "/tmp:size=100m" # 临时目录,限制大小
volumes:
- "/home/user/projects:/workspace:rw" # 只挂载工作目录
user: "1000:1000" # 以非 root 用户运行
这个配置实现了以下安全目标: - 最小权限 —— 容器没有不必要的 capabilities - 网络隔离 —— 可选禁用网络,防止数据外泄 - 文件系统隔离 —— 只挂载必要的目录,且可以设为只读 - 资源限制 —— 临时目录有大小限制,防止磁盘耗尽攻击 - 非特权运行 —— 即使容器逃逸,攻击者也只是一个普通用户
10.3 API Key 安全存储
Hermes 需要调用多个外部服务的 API(如 OpenAI、Claude、各种平台 API)。这些 API 的密钥(Key)必须安全存储。
密钥存储方式:
| 方式 | 安全性 | 便利性 | 推荐度 |
|---|---|---|---|
| 环境变量 | 中 | 高 | ⭐⭐⭐ |
| 密钥管理文件(权限 600) | 中高 | 高 | ⭐⭐⭐⭐ |
| 系统密钥环(Keyring) | 高 | 中 | ⭐⭐⭐⭐⭐ |
| 硬件安全模块(HSM) | 最高 | 低 | ⭐⭐⭐ |
推荐配置(使用系统密钥环):
# 安装 keyring 支持
pip install keyring
# 将 API Key 存入系统密钥环
hermes config set model.openai.api_key --secure
# 系统会提示你输入密钥,并自动存入操作系统的密钥环
# 验证存储
hermes config get model.openai.api_key
# 输出: ***(已脱敏,不会显示明文)
使用系统密钥环的好处是: - 密钥以加密形式存储,即使有人拿到了你的硬盘,也无法直接读取密钥 - 支持生物识别解锁(如 macOS 的 Touch ID、Windows 的 Hello) - 与操作系统的权限系统集成,只有授权进程可以访问
注意
绝对不要把 API Key 直接写在配置文件里,尤其是当配置文件可能被提交到 Git 仓库时。每年都有无数开发者因为把密钥提交到 GitHub 而造成安全事故。如果你不小心这样做了,立即到对应的服务商后台撤销该 Key 并重新生成。
10.4 权限最小化原则
权限最小化(Principle of Least Privilege)是安全设计的基本原则:每个组件、每个工具、每个操作,都只拥有完成其工作所必需的最小权限。
Hermes 在多个层面贯彻了这一原则:
层面一:工具级别的权限控制。
每个工具在注册时声明自己需要什么权限:
Tool(
name="file_read",
required_permissions=["filesystem.read"],
# 只需要读权限,不需要写权限
)
Tool(
name="file_write",
required_permissions=["filesystem.write"],
dangerous=True,
requires_approval=True,
# 需要写权限,标记为危险,需要审批
)
层面二:会话级别的权限控制。
你可以为不同的会话设置不同的权限级别:
# 创建一个只读会话(Agent 只能读文件,不能修改)
hermes chat --readonly
# 创建一个受限会话(Agent 只能使用白名单中的工具)
hermes chat --allow-tools "file_read,web_search,db_query"
层面三:平台级别的权限控制。
不同平台的接入,可以设置不同的权限:
gateway:
platforms:
telegram:
enabled: true
permissions: ["read", "write", "execute"] # 完全权限
slack:
enabled: true
permissions: ["read", "write"] # 不能执行命令
readonly_channels: ["general", "announcements"] # 某些频道只读
10.5 与 OpenClaw 分级沙箱的对比
OpenClaw 在安全性方面有一个业界公认的优势:分级沙箱(Tiered Sandbox)。让我们对比一下两者的安全策略:
| 维度 | Hermes | OpenClaw |
|---|---|---|
| 命令审批 | ✅ 交互式审批 | ✅ 交互式审批 |
| 沙箱隔离 | ✅ Docker / Firejail / gVisor | ✅ ✅ 分级沙箱(业界最佳) |
| 分级策略 | 按工具和用户配置分级 | 按操作危险度自动分级 |
| 网络隔离 | 可选禁用网络 | 默认受限网络 |
| 文件系统隔离 | 按需挂载 | 默认只读 + 白名单写入 |
| 密钥管理 | 系统密钥环 | 环境变量 + 加密存储 |
| 审计日志 | SQLite 本地存储 | 结构化日志 + 可选外发 |
OpenClaw 的分级沙箱确实是业界的标杆。它把操作分为多个危险等级,每个等级对应不同的隔离强度。比如: - Level 1(只读操作): 不需要沙箱,直接执行 - Level 2(写操作): 在 Firejail 沙箱中执行,限制文件系统访问范围 - Level 3(系统命令): 在 Docker 沙箱中执行,完全隔离 - Level 4(网络操作): 在 gVisor 沙箱中执行,网络完全隔离
Hermes 目前的沙箱机制没有 OpenClaw 那么精细的分级,但提供了更灵活的配置选项。根据 Nous Research 的公开路线图,更精细的分级沙箱是未来的重点开发方向之一。
Tips
如果你当前对安全性有极高要求(如处理敏感数据、生产环境部署),建议在使用 Hermes 时: 1. 始终使用 Docker 或 gVisor 后端 2. 禁用网络访问(除非任务确实需要) 3. 文件系统只挂载必要目录,且设为只读 4. 定期审查 SQLite 中的工具调用日志,检查是否有异常操作 5. 关注 Hermes 的版本更新,安全相关的改进通常会优先发布
11. 性能与可扩展性
11.1 Python 轻量架构的优势
Hermes 选择 Python 作为主力开发语言(代码库中 Python 占比 93.6%),这个决策在 AI 开源项目中并不罕见,但值得深入理解其背后的考量。
优势一:生态丰富。
Python 在 AI/ML 领域拥有无可比拟的生态系统。从 LLM 调用(OpenAI SDK、Anthropic SDK)到数据处理(Pandas、NumPy)到 Web 服务(FastAPI、Flask)到数据库(SQLAlchemy、sqlite3),几乎所有 Hermes 需要的功能,Python 生态中都有成熟、活跃的解决方案。
这意味着 Nous Research 可以把精力集中在 Agent 的核心逻辑上,而不是重复造轮子。
优势二:开发效率高。
Python 的语法简洁、表达力强,非常适合快速迭代和原型验证。对于一个需要不断实验、快速响应社区反馈的开源项目来说,开发效率比运行效率更重要。
优势三:社区门槛低。
Python 是全球最普及的编程语言之一。选择 Python,意味着更多开发者能够阅读、理解、修改 Hermes 的源代码。这直接降低了贡献门槛,有利于社区生态的发展。
优势四:与 LLM 的天然亲和。
大多数 LLM 的训练数据中,Python 代码占比很高。这意味着 LLM 在生成和理解 Python 代码方面,通常比其他语言表现更好。对于 Hermes 这种"让 LLM 生成 Skill"的系统来说,这是一个实际的工程优势。
常见问题
Q:Python 的性能会不会成为瓶颈?
A:对于 Hermes 的使用场景来说,Python 的运行时性能完全够用。Agent 的主要耗时不在 Python 代码本身,而在 LLM API 调用(通常几秒到几十秒)和外部工具执行(如网络请求、文件操作)。Python 代码的执行时间(毫秒级)在这些耗时面前几乎可以忽略。如果确实有性能敏感的部分(如大量数据的文本处理),可以用 Rust 或 C 编写扩展模块,Python 通过 FFI 调用。
11.2 资源占用基准
让我们看看 Hermes 在各种场景下的资源占用情况。
基准测试环境: - CPU: 4 核 Intel/AMD 或 ARM - 内存: 8 GB - 存储: SSD - 操作系统: Ubuntu 22.04 / macOS 14
空闲状态:
| 指标 | 数值 |
|---|---|
| CPU 占用 | < 1% |
| 内存占用 | 80-150 MB |
| 磁盘 I/O | 几乎为零 |
| 网络 | 仅心跳/保活包 |
单次对话任务(平均 10 轮):
| 指标 | 数值 |
|---|---|
| CPU 占用(峰值) | 10-30% |
| 内存占用(峰值) | 200-400 MB |
| 磁盘写入 | ~50 KB(对话历史) |
| 网络出站 | ~100-500 KB(LLM API 请求) |
| 总耗时 | 30-120 秒(取决于 LLM 响应速度) |
长期运行(7×24 小时 Gateway 模式):
| 指标 | 数值 |
|---|---|
| 日均内存增长 | ~5-10 MB(SQLite 缓存等) |
| 重启建议周期 | 每月一次(清理内存碎片) |
| 日志增长 | ~10-50 MB/天(取决于日志级别) |
Tips
如果你发现 Hermes 的内存占用持续增长不下降,可能是某个地方有内存泄漏。可以尝试以下排查步骤: 1. 降低日志级别:
hermes config set logging.level WARNING2. 限制会话历史保留数量:hermes config set retention.max_sessions_per_user 503. 定期重启 Gateway 服务:设置一个 cron 任务每周重启一次 4. 如果问题持续,在 GitHub 上提交 Issue,附上hermes debug memory的输出
11.3 并发处理能力
当前版本的 Hermes,Agent 核心层是单线程的。这意味着:
- 同一时刻,Agent 只能处理一个任务
- 如果多个平台同时发来消息,它们会按顺序排队处理
- 一个复杂任务(如需要 50 轮对话)会阻塞后续任务
这个设计的选择,是出于以下考虑:
- 上下文一致性。 Agent 的状态(热记忆中的上下文)是单例的。如果同时处理多个任务,不同任务的上下文会互相干扰,导致 Agent "精神分裂"。
- 资源控制。 LLM API 调用是主要的资源消耗点。单线程处理天然地实现了"速率限制",不会因为并发请求过多而耗尽 API 配额或预算。
- 简化设计。 并发控制是一个复杂的问题(锁、竞态条件、死锁等)。单线程设计大大降低了系统的复杂度,减少了 Bug 的可能性。
但这并不意味着 Hermes 不能处理"并发需求"。对于需要并行处理多个子任务的场景,Hermes 提供了子 Agent 委托机制:
# 使用 delegate_task 工具,将子任务委托给独立的子 Agent
hermes -q "帮我同时做三件事:
1. 检查服务器 A 的磁盘空间
2. 检查服务器 B 的内存使用
3. 检查服务器 C 的 CPU 负载
用 delegate_task 并行执行"
子 Agent 的特性: - 每个子 Agent 有独立的对话上下文和 task_id - 最多支持 3 个子 Agent 并行 - 子 Agent 的深度最多 2 层(防止递归爆炸) - 父 Agent 可以实时查看子 Agent 的进度
11.4 大规模记忆数据的性能表现
随着使用时间的增长,SQLite 数据库中的数据会越来越多。Hermes 在大规模数据下的性能表现如何?
测试数据:
| 数据规模 | 会话数 | 消息数 | 数据库大小 |
|---|---|---|---|
| 小型 | 100 | 1,000 | 5 MB |
| 中型 | 1,000 | 10,000 | 50 MB |
| 大型 | 10,000 | 100,000 | 500 MB |
| 超大型 | 100,000 | 1,000,000 | 5 GB |
FTS5 全文搜索性能:
| 数据规模 | 首次搜索耗时 | 缓存后搜索耗时 |
|---|---|---|
| 小型 | < 10 ms | < 1 ms |
| 中型 | < 50 ms | < 5 ms |
| 大型 | < 200 ms | < 20 ms |
| 超大型 | < 1 s | < 100 ms |
会话列表加载性能:
| 数据规模 | 加载耗时 |
|---|---|
| 小型 | < 10 ms |
| 中型 | < 50 ms |
| 大型 | < 200 ms |
| 超大型 | < 500 ms |
从数据可以看出,SQLite + FTS5 的组合,在百万级数据量下依然能保持良好的性能。对于个人用户和小团队来说,这个性能完全够用。
但如果数据量增长到千万级,SQLite 可能会成为瓶颈。此时可以考虑: 1. 归档旧数据(导出到文件,从数据库中删除) 2. 升级到 PostgreSQL(Hermes 支持通过配置切换数据库) 3. 使用外部向量数据库(如 Pinecone、Milvus)做语义检索
11.5 扩展方向:插件机制、模块化拆分
Hermes 的架构设计,为未来的扩展预留了充足的空间。
方向一:官方插件市场。
当前 Hermes 的扩展主要通过自定义工具和 Skill 实现。未来计划推出更正式的插件机制(Plugin System),允许开发者打包和分发更复杂的扩展:
插件包结构:
my-plugin/
├── plugin.yaml # 插件元数据
├── tools/ # 自定义工具
├── skills/ # 预设技能
├── adapters/ # 自定义平台适配器
├── middleware/ # 中间件(拦截和修改消息)
├── ui/ # 自定义 UI 组件(Web 界面)
└── requirements.txt # 依赖
方向二:核心模块的独立化。
长期来看,Hermes 的五层架构可能会进一步拆分为独立的微服务或库:
- hermes-core —— Agent 核心层,作为独立库发布
- hermes-gateway —— GatewayRunner,独立部署
- hermes-tools —— ToolRegistry 和内置工具集合
- hermes-memory —— 记忆系统,支持多种后端
- hermes-sdk —— 官方 SDK,供第三方开发者使用
这种拆分的好处是: - 开发者可以只使用自己需要的模块 - 不同模块可以独立版本迭代 - 企业用户可以根据需求定制部署方案
方向三:多语言支持。
虽然 Hermes 的核心是 Python,但工具层和适配器层可以用其他语言实现。未来可能会支持: - Rust 工具 —— 性能敏感的操作(如大规模数据处理) - JavaScript/TypeScript 适配器 —— 前端和 Node.js 生态的集成 - Go 网关 —— 高并发的 GatewayRunner 实现
Tips
如果你有兴趣为 Hermes 贡献代码,建议从以下方向入手: 1. 新平台适配器 —— 为你常用的消息平台写一个适配器 2. 新工具 —— 开发一个解决特定问题的自定义工具,然后贡献给社区 3. Skill 模板 —— 把你常用的工作流封装成 Skill,分享到 Skills Hub 4. 文档翻译 —— 帮助把官方文档翻译成更多语言 5. Bug 修复 —— 在 GitHub Issues 中寻找 good-first-issue 标签的问题
12. 系统设计哲学总结
12.1 简单优于复杂
Hermes 的设计团队有一个明确的偏好:在功能完备和简单清晰之间,永远选择后者。
这个哲学体现在无数个设计决策中: - 用 SQLite 而不是分布式数据库 - 用单线程而不是复杂的并发模型 - 用配置文件而不是 Web 管理界面(至少目前如此) - 用 47 个精心设计的工具,而不是 200 个功能重复的工具
"简单是可靠的先决条件。" —— Edsger Dijkstra
复杂系统的问题在于:每一个额外的组件、每一条额外的规则、每一个额外的依赖,都是一个潜在的故障点。当故障发生时,在简单系统中定位问题只需要排查少数几个地方,在复杂系统中则需要排查几十个甚至上百个地方。
Hermes 的追求是:用简单的方式解决复杂的问题,而不是用复杂的方式解决简单的问题。
12.2 本地优先,隐私至上
在云计算和 SaaS 大行其道的时代,Hermes 选择了一条反潮流的路线:数据默认保存在本地。
这个选择有其代价——用户需要自己负责备份、需要自己维护服务器、需要自己处理升级。但换来的收益是:你的数据完全属于你。
- 没有服务商可以看到你的对话内容
- 没有广告商可以基于你的数据推送广告
- 没有政府可以轻易调取你的记录(除非你自愿)
- 没有公司倒闭会导致你的数据丢失
对于很多人来说,这种"数据主权"比"便利性"更重要。
12.3 自动化一切可自动化的事
Hermes 的终极愿景,是让 Agent 能够自动化一切可自动化的事——不仅包括执行层面的自动化(调用工具、处理数据),还包括认知层面的自动化(学习经验、优化策略、生成知识)。
自学习闭环就是这个愿景的核心实现。它让 Agent 从"被动执行指令"进化到"主动积累经验",从"一次性工具"进化到"持续性伙伴"。
12.4 越用越聪明,而不是越用越笨
很多软件系统的宿命是"越用越笨"——随着功能的增加、配置的累积、数据的膨胀,系统变得越来越慢、越来越不稳定、越来越难以维护。
Hermes 的设计目标是相反的:越用越聪明。
- 用得越久,Skill 库越丰富,处理任务越快
- 用得越久,USER.md 越精准,回复越贴合你的习惯
- 用得越久,MEMORY.md 越精炼,关键信息保留得越好
- 用得越久,Agent 对你的理解越深,协作越默契
这种"正向积累"的特性,是 Hermes 区别于绝大多数软件系统的根本所在。
12.5 对开发者友好的可扩展设计
最后但同样重要的是,Hermes 始终把开发者体验放在很高的优先级。
- 代码库结构清晰,新开发者能在 30 分钟内理解整体架构
- 自定义工具的接口简单,几行代码就能扩展 Agent 的能力
- 文档全面且接地气,不是干巴巴的 API 参考,而是带有场景和示例的指南
- 社区友好,提问能得到及时、友善的回应
- 开源许可证宽松(MIT),允许商业使用和二次开发
这些看似"软实力"的因素,实际上决定了一个开源项目的长期生命力。技术可以复制,但社区文化、设计品味和开发者体验,是很难复制的核心竞争力。
本章小结
在这一章中,我们像解剖学家一样,一层一层地拆开了 Hermes 的架构,理解了它内部的每一个器官是如何工作的。
我们从五层架构的总览开始,理解了入口层、核心层、工具层、持久化层和平台层各自的分工,以及它们如何通过清晰的接口协同工作。
在Layer 1(入口与编排层),我们了解了 HermesCLI 的设计理念——简洁、直观、渐进;以及 GatewayRunner 如何把来自十几个平台的消息翻译成 Agent 能理解的统一格式。
在Layer 2(Agent 核心层),我们深入剖析了同步对话循环的工作原理,理解了 Agent 是如何一步步接收需求、规划步骤、调用工具、迭代推进的。我们学习了预算机制如何防止 Agent 失控,Token 计数如何控制成本,上下文窗口管理如何在有限空间内最大化信息价值,以及错误恢复机制如何让 Agent 在面对各种意外时从容应对。
在Layer 3(工具与注册层),我们认识了 ToolRegistry 这个"工具柜台",理解了单例模式和自注册机制如何让工具管理变得异常简洁。我们浏览了 47 个内置工具的分类架构,学习了安全审批流程如何保护系统,以及自定义工具接口如何让开发者轻松扩展 Agent 的能力。
在Layer 4(状态与持久化层),我们探索了 SQLite + FTS5 的数据库设计,理解了 MEMORY.md 和 USER.md 这两份"活文档"如何动态记录 Agent 的经验和用户画像。我们学习了 Cron 定时任务如何让 Agent 7×24 小时自动工作,以及备份策略如何保护你的数据资产。
在Layer 5(平台适配层),我们了解了适配器模式如何让 Hermes 同时支持 15+ 个平台,6 种终端后端如何满足不同的安全隔离需求,以及统一消息接口如何让 Agent 核心层完全不必关心平台的差异。
在自学习闭环一节,我们揭开了 Hermes 最核心的秘密——执行、评估、创建、改进四个阶段如何构成一个有机的进化循环。我们理解了触发条件(5+ 工具调用、用户纠正、错误修复)、Skill 自动生成的算法逻辑、版本管理机制,以及社区实测数据如何证明这个机制能带来 30%+ 的效率提升。
在记忆系统架构一节,我们深入理解了四层温度模型——热记忆的即时性、温记忆的持久性、冷记忆的检索能力、外部记忆的扩展性。我们明白了 Nous Research 官方强调的"有界记忆"设计哲学:有限容量不是缺陷,而是迫使 Agent 学会优先级管理的特性。
在Honcho 用户建模一节,我们了解了 Agent 如何从你的行为中推导出沟通风格、技术偏好、工作节律甚至情绪触发点,然后自动调整回复风格来匹配你。
在安全架构一节,我们系统学习了命令审批机制、沙箱执行环境、API Key 安全存储、权限最小化原则,以及与 OpenClaw 分级沙箱的对比。
在性能与可扩展性一节,我们了解了 Python 轻量架构的优势、资源占用基准、并发处理策略、大规模数据下的性能表现,以及未来的扩展方向。
最后,我们用五个设计哲学原则——简单优于复杂、本地优先隐私至上、自动化一切可自动化的事、越用越聪明、对开发者友好的可扩展设计——总结了 Hermes 架构背后的思想内核。
理解架构,不是为了成为架构师,而是为了成为一个更明白、更自信、更有掌控感的使用者。当你知道系统内部是怎么运转的,你就不会再害怕它、不会盲目依赖它、不会在它出问题时手足无措。你会知道该调什么参数、该看哪个日志、该从哪里入手排查问题。
这就是了解架构的最大价值。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第五册:安装部署全攻略 —— 保姆级部署指南,让 Hermes 在你的机器上跑起来
本章你将学到:
- 部署 Hermes 之前需要做的全部准备工作,像买电器前检查插座一样简单明了
- 四种部署方式(本地常规部署、Docker 容器化部署、VPS 云服务器部署、无服务器部署)的完整步骤
~/.hermes/目录结构的详细解读,搞清楚每个文件是干什么的- 安装后的自检、排障和基础配置方法
- 如何安全地卸载、重装和升级 Hermes
注意
这一册是全书最「动手」的章节。建议你在阅读时打开电脑,跟着步骤一步步操作。遇到任何问题,都可以直接跳到第 7 章「运行状态自检与排障」查找解决方案。
1. 安装前的准备工作
1.1 系统要求总览
在把 Hermes 请进你的电脑之前,我们先来确认一下你的「房子」够不够大、够不够好。这就好比你要养一匹马,总得先有个马厩吧?
Hermes 对硬件的要求其实非常友好。它不像那些动辄需要 64GB 显存的本地大模型那样「挑食」,也不像某些企业级软件一样需要专用服务器。只要你有一台近五年内购买的电脑,基本上都能跑得起来。
最低配置要求
以下是运行 Hermes 的最低配置要求。达到这个配置,你就能顺畅地使用所有基础功能:
| 操作系统 | 最低内存 | 最低磁盘空间 | 网络要求 |
|---|---|---|---|
| macOS 12+ (Intel / Apple Silicon) | 4 GB RAM | 2 GB 可用空间 | 稳定互联网连接 |
| Linux (Ubuntu 20.04+ / Debian 11+ / Fedora 35+) | 4 GB RAM | 2 GB 可用空间 | 稳定互联网连接 |
| Windows 10/11 (通过 WSL2) | 8 GB RAM | 5 GB 可用空间 | 稳定互联网连接 |
Tips
为什么 Windows 要求的内存和磁盘空间更高?因为 WSL2 本身需要额外运行一个轻量级的 Linux 虚拟机,所以会比原生 Linux 多占用一些资源。如果你的 Windows 电脑内存只有 8GB,建议关闭其他占用内存的大型软件后再运行 Hermes。
推荐配置
如果你想要更流畅的体验,尤其是在同时运行多个技能或处理大量文件时,建议达到以下配置:
| 操作系统 | 推荐内存 | 推荐磁盘空间 | 备注 |
|---|---|---|---|
| macOS 14+ | 8 GB RAM | 5 GB 可用空间 | Apple Silicon (M1/M2/M3/M4) 体验最佳 |
| Linux | 8 GB RAM | 5 GB 可用空间 | 原生运行,性能最佳 |
| Windows 11 + WSL2 | 16 GB RAM | 10 GB 可用空间 | 确保 WSL2 分配至少 8GB 内存 |
注意
Hermes 本身并不在本地运行大语言模型(除非你接入 Ollama 等本地模型服务)。它主要是作为 Agent 的「大脑指挥官」,实际的推理计算是在你配置的远程 LLM 提供商(如 OpenAI、DeepSeek 等)的服务器上完成的。所以你的电脑主要负责运行 Hermes 的核心逻辑和工具调用,不需要特别强大的 GPU。
类比理解
你可以把 Hermes 想象成一个「智能电话总机」:
- 你的电脑 = 总机设备本身(不需要特别高端,稳定运行就行)
- 远程 LLM = 电话线另一端的客服专家(计算在对方那边完成)
- 网络连接 = 电话线路质量(决定了你和专家沟通是否顺畅)
所以,只要你有一台能流畅上网的电脑,就能运行 Hermes。
1.2 网络环境检查与代理配置
网络环境是安装和使用 Hermes 的关键因素。因为 Hermes 需要连接到多个外部服务(LLM API、GitHub、Docker Hub 等),所以一个稳定的网络环境至关重要。
网络连通性自检
在安装之前,请先确认你的网络环境是否满足以下基本要求:
- 能够正常访问互联网(访问百度、谷歌等网站无障碍)
- 能够访问 GitHub(
github.com) - 能够访问 Python 包管理仓库(
pypi.org) - 能够访问 Node.js 包管理仓库(
registry.npmjs.org)
你可以通过以下命令快速检查网络连通性:
# 测试 GitHub 访问
ping -c 3 github.com
# 测试 PyPI 访问
ping -c 3 pypi.org
# 测试 npm 仓库访问
ping -c 3 registry.npmjs.org
常见问题
Q:ping 不通 GitHub,怎么办?
A:如果你在国内,GitHub 访问不稳定是常见问题。有以下三种解决方案: 1. 使用代理工具(VPN/Clash/Shadowsocks 等)并配置终端代理 2. 修改 hosts 文件,使用 GitHub 的镜像 IP 3. 使用国内的 Git 镜像源(如 Gitee)克隆仓库
国内用户的代理配置指南
对于国内用户,配置代理是确保安装顺利的重要步骤。以下是几种常见的代理配置方式:
方式一:终端临时代理(推荐安装时使用)
如果你使用的是 Clash 等代理工具,通常在本地会开启一个 HTTP/SOCKS5 代理端口(默认可能是 7890)。你可以在终端中临时设置代理:
# macOS / Linux - 临时设置 HTTP 代理(仅当前终端窗口有效)
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
# 如果你使用的是 SOCKS5 代理
export ALL_PROXY=socks5://127.0.0.1:7890
# Windows PowerShell - 临时设置代理
$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"
Tips
设置代理后,你可以用
curl -I https://github.com测试代理是否生效。如果返回 HTTP 200 状态码,说明代理配置成功。
方式二:Git 配置代理
# 配置 Git 使用代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# 验证 Git 代理配置
git config --global --get http.proxy
git config --global --get https.proxy
# 取消 Git 代理(安装完成后建议取消)
git config --global --unset http.proxy
git config --global --unset https.proxy
方式三:pip 配置代理
# 临时使用代理安装 Python 包
pip install --proxy http://127.0.0.1:7890 <package_name>
# 或者配置 pip 全局代理
pip config set global.proxy http://127.0.0.1:7890
# 使用国内镜像源(更推荐长期方案)
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
注意
安装完成后,建议取消全局代理配置,只在需要时使用临时代理。长期开启全局代理可能会影响某些国内服务的访问速度。
npm/yarn 镜像源配置
对于 Node.js 相关的依赖安装,国内用户强烈建议切换到淘宝镜像源:
# 查看当前 npm 源
npm config get registry
# 切换到淘宝镜像源
npm config set registry https://registry.npmmirror.com
# 验证切换成功
npm config get registry
# 应输出: https://registry.npmmirror.com
# 恢复官方源(如需)
npm config set registry https://registry.npmjs.org
# 如果你使用 yarn
yarn config set registry https://registry.npmmirror.com
# 如果你使用 pnpm
pnpm config set registry https://registry.npmmirror.com
Tips
淘宝镜像源(
registry.npmmirror.com)是国内最稳定的 npm 镜像之一,与官方源同步频率很高。在 2022 年之后,原registry.npm.taobao.org已重定向到registry.npmmirror.com,请使用新域名。
1.3 必备前置软件清单
Hermes 的安装依赖于几个核心软件。在开始安装之前,请确保你的系统上已经安装或准备安装以下软件。
前置软件总览
| 软件 | 最低版本 | 作用 | 检查命令 |
|---|---|---|---|
| Python | 3.11+ | Hermes 的核心运行环境 | python3 --version |
| Node.js | v22+ | 前端界面和部分工具依赖 | node --version |
| Git | 2.30+ | 克隆仓库和管理版本 | git --version |
| pip | 23.0+ | Python 包管理器 | pip3 --version |
Python 3.11+ 的安装与验证
Python 是 Hermes 的运行基础。Hermes 的代码大量使用了 Python 3.11 引入的新特性(如 typing.Self、ExceptionGroup 等),因此 Python 3.11 是硬性要求,3.10 及更低版本无法运行。
检查现有 Python 版本:
# macOS / Linux
python3 --version
# 某些系统可能需要使用 python 而不是 python3
python --version
# Windows (PowerShell)
python --version
如果你看到的版本号低于 3.11(如 Python 3.10.12),你需要升级 Python。
常见问题
Q:我的系统自带 Python 3.10,可以直接升级吗?
A:强烈建议不要直接覆盖系统自带的 Python!macOS 和 Linux 的系统工具依赖特定版本的 Python,直接覆盖可能导致系统不稳定。推荐使用 pyenv 或官方安装包来安装新版本的 Python,这样多个版本可以共存。
安装 Python 3.11+ 的推荐方式:
我们将在下一节的 macOS 和 Linux 安装流程中详细介绍 Python 的安装。这里先给出快速参考:
# macOS (使用 Homebrew)
brew install python@3.11
# Ubuntu/Debian
sudo apt update
sudo apt install python3.11 python3.11-venv python3.11-dev python3-pip
# Fedora
sudo dnf install python3.11 python3.11-devel
Node.js v22+ 的安装与验证
Node.js 主要用于 Hermes 的部分前端界面和工具链。虽然不像 Python 那样是核心依赖,但某些功能(如 Web 网关界面)需要 Node.js 支持。
检查现有 Node.js 版本:
node --version
如果版本低于 v22,建议升级。我们将在各平台的安装流程中介绍具体方法。
Git 的安装与验证
Git 用于克隆 Hermes 的代码仓库以及后续的更新操作。
git --version
如果系统提示找不到 git 命令,请按以下方式安装:
# macOS
xcode-select --install
# Ubuntu/Debian
sudo apt update
sudo apt install git
# Fedora
sudo dnf install git
# Windows
# 下载安装程序:https://git-scm.com/download/win
1.4 安装前自检清单(Checklist)
在正式开始安装之前,请逐项确认以下清单。这就像飞行员起飞前的检查单,每一项都关系到后续安装的顺利与否。
硬件与环境检查
- [ ] 电脑剩余磁盘空间大于 5GB
- [ ] 电脑内存大于 4GB(Windows 用户大于 8GB)
- [ ] 操作系统版本符合要求(macOS 12+ / Ubuntu 20.04+ / Windows 10+)
- [ ] 网络连接稳定,可以访问 GitHub
软件检查
- [ ] Python 版本为 3.11 或更高(运行
python3 --version确认) - [ ] Node.js 版本为 v22 或更高(运行
node --version确认) - [ ] Git 已安装并可正常使用(运行
git --version确认) - [ ] pip 可用(运行
pip3 --version确认)
权限检查
- [ ] 对主目录(
~或C:\Users\你的用户名)有写入权限 - [ ] 可以运行 sudo/admin 命令(安装系统级依赖时可能需要)
国内用户额外检查
- [ ] 已配置好代理工具(如 Clash/V2Ray/Shadowsocks)
- [ ] 已配置 npm 国内镜像源(如淘宝镜像)
- [ ] 已配置 pip 国内镜像源(如清华源)
- [ ] 已测试代理可以正常访问 GitHub
信息准备
- [ ] 已决定使用哪种部署方式(本地 / Docker / VPS / 无服务器)
- [ ] 已准备好至少一个 LLM 提供商的 API Key(可以先准备 OpenRouter 的免费 Key)
- [ ] 已注册好 GitHub 账号(用于后续的技能同步)
Tips
强烈建议在安装前把上述清单打印出来或抄在便签纸上,每完成一项就打一个勾。这样做看似多余,但能帮你避免 80% 的安装失败问题。我见过太多人因为「Python 版本不对」或「网络连不上 GitHub」而在安装第一步就卡住半天。
安装前环境检查脚本:
为了方便你快速完成自检,可以使用以下脚本:
#!/bin/bash
# save as: check-env.sh
echo "🔍 Hermes 安装前环境检查"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
# 检查 Python 版本
PYTHON_VERSION=$(python3 --version 2>/dev/null || python --version 2>/dev/null)
if [ -n "$PYTHON_VERSION" ]; then
echo "✓ Python: $PYTHON_VERSION"
else
echo "✗ Python: 未安装"
fi
# 检查 Node.js
NODE_VERSION=$(node --version 2>/dev/null)
if [ -n "$NODE_VERSION" ]; then
echo "✓ Node.js: $NODE_VERSION"
else
echo "✗ Node.js: 未安装"
fi
# 检查 Git
GIT_VERSION=$(git --version 2>/dev/null)
if [ -n "$GIT_VERSION" ]; then
echo "✓ Git: $GIT_VERSION"
else
echo "✗ Git: 未安装"
fi
# 检查磁盘空间
DISK_AVAILABLE=$(df -h ~ | awk 'NR==2 {print $4}')
echo "✓ 磁盘可用空间: $DISK_AVAILABLE"
# 检查内存
if command -v free &> /dev/null; then
MEM_AVAILABLE=$(free -h | awk '/^Mem:/ {print $7}')
echo "✓ 内存可用: $MEM_AVAILABLE"
fi
# 检查网络
echo ""
echo "🌐 网络检查:"
ping -c 1 github.com > /dev/null 2>&1 && echo "✓ GitHub 可访问" || echo "✗ GitHub 无法访问"
ping -c 1 pypi.org > /dev/null 2>&1 && echo "✓ PyPI 可访问" || echo "✗ PyPI 无法访问"
echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "检查完成!如果有 ✗ 项,请先解决后再安装 Hermes。"
保存为 check-env.sh,然后运行:
chmod +x check-env.sh
./check-env.sh
2. 方式一:本地常规部署(推荐小白起步)
本地常规部署是最直接、最符合直觉的安装方式。它就是把 Hermes 直接安装在你的电脑上,就像安装微信或浏览器一样。对于刚接触 Hermes 的新手,我强烈推荐从这个方式开始。
注意
本地部署需要你的电脑在安装过程中保持联网状态,因为安装脚本会自动下载所需的 Python 包和依赖。
2.1 macOS 安装全流程
macOS 是 Hermes 开发团队主要使用的操作系统,因此 macOS 上的安装体验通常是最顺畅的。下面我会像手把手教你做一道菜一样,一步一步带你完成安装。
第一步:安装或更新 Homebrew
Homebrew 是 macOS 上最流行的包管理器,相当于 macOS 的「应用商店」。它让你可以用简单的命令安装各种软件,而不需要去官网下载安装包。
检查是否已安装 Homebrew:
brew --version
如果返回类似 Homebrew 4.x.x 的版本号,说明已经安装。如果提示命令不存在,则需要安装。
安装 Homebrew:
打开终端(Terminal),复制粘贴以下命令,按回车执行:
# 官方安装脚本
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
注意
安装 Homebrew 需要输入你的 macOS 用户密码(输入时不会显示字符,这是正常的)。安装过程可能需要 5-15 分钟,取决于你的网络速度。如果下载速度很慢,可能是网络问题,建议先配置好代理再执行。
安装完成后,根据终端提示,你可能需要运行以下命令来将 Homebrew 添加到你的 PATH:
# Apple Silicon Mac (M1/M2/M3/M4)
echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"
# Intel Mac
echo 'eval "$(/usr/local/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/usr/local/bin/brew shellenv)"
更新 Homebrew(如已安装):
# 更新 Homebrew 本身和软件包列表
brew update
# 升级已安装的软件包(可选,建议执行)
brew upgrade
Tips
Homebrew 就像是 macOS 的软件管家。以后你想安装任何开发工具(如 Python、Node.js、Git 等),都可以用
brew install 软件名一键安装,再也不用去官网找下载链接了。
第二步:安装 Python 3.11
如前所述,Hermes 需要 Python 3.11 或更高版本。在 macOS 上,我们用 Homebrew 来安装。
# 安装 Python 3.11
brew install python@3.11
# 将 Python 3.11 链接到 PATH
brew link python@3.11 --force
# 验证安装
python3 --version
# 应输出: Python 3.11.x
注意
如果你的系统上已经通过其他方式安装了 Python(如 Anaconda、pyenv 等),可能会出现版本冲突。建议使用 pyenv 来管理多个 Python 版本(见下文「进阶:使用 pyenv 管理 Python 版本」)。
进阶:使用 pyenv 管理 Python 版本(强烈推荐)
pyenv 是一个 Python 版本管理工具,让你可以在同一台电脑上安装和切换多个 Python 版本。这就像你手机里的「双卡双待」,不同的应用可以用不同的 Python 版本。
安装 pyenv:
# 通过 Homebrew 安装 pyenv
brew install pyenv
# 将 pyenv 初始化代码添加到 shell 配置文件
echo 'eval "$(pyenv init -)"' >> ~/.zshrc
# 重新加载 shell 配置
source ~/.zshrc
使用 pyenv 安装 Python 3.11:
# 查看可安装的 Python 版本
pyenv install --list | grep "3.11"
# 安装 Python 3.11.9(选择最新的 3.11.x 版本)
pyenv install 3.11.9
# 设置全局默认 Python 版本
pyenv global 3.11.9
# 验证
python --version
# 应输出: Python 3.11.9
pyenv 常用命令速查:
# 查看已安装的 Python 版本
pyenv versions
# 在当前目录使用特定 Python 版本(仅当前文件夹有效)
pyenv local 3.11.9
# 在当前终端会话使用特定 Python 版本
pyenv shell 3.11.9
# 卸载某个 Python 版本
pyenv uninstall 3.10.12
Tips
强烈建议所有开发者都使用 pyenv 管理 Python 版本。它不仅能避免系统 Python 被污染,还能让你在不同项目中使用不同的 Python 版本。比如你的老项目需要 Python 3.10,而 Hermes 需要 3.11,用 pyenv 可以轻松切换。
第三步:安装 Node.js v22
# 通过 Homebrew 安装 Node.js
brew install node
# 验证安装
node --version
# 应输出: v22.x.x 或更高
# 同时验证 npm(Node.js 的包管理器)
npm --version
第四步:安装 Git
macOS 通常已经预装了 Git,但版本可能较老。建议通过 Homebrew 安装最新版:
# 安装/更新 Git
brew install git
# 验证
git --version
第五步:运行 Hermes 一键安装脚本
好了,前置软件都准备就绪,现在到了最激动人心的时刻——安装 Hermes 本身!
# 方式一:使用官方推荐的一键安装脚本(推荐)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 方式二:如果方式一网络不通,可以先克隆仓库再手动安装
git clone https://github.com/NousResearch/hermes.git ~/hermes
cd ~/hermes
pip install -e .
安装脚本执行过程详解:
当你运行安装脚本时,屏幕上会滚动显示大量信息。不要被这些密密麻麻的文字吓到,它们其实只是在告诉你「我正在做什么」。下面是每个阶段的含义:
阶段 1:环境检查(约 5 秒)
[INFO] 正在检查系统环境...
[INFO] Python 版本: 3.11.9 ✓
[INFO] Node.js 版本: v22.3.0 ✓
[INFO] Git 版本: 2.43.0 ✓
如果这一阶段报错,说明你的前置软件有问题。请根据错误信息回到前面的步骤检查。
阶段 2:创建目录结构(约 2 秒)
[INFO] 正在创建 ~/.hermes 目录...
[INFO] 创建子目录: database, skills, cron, logs, cache
阶段 3:安装依赖(约 2-5 分钟,取决于网络)
[INFO] 正在安装 Python 依赖...
下载 package-a-1.0.0...
下载 package-b-2.1.3...
安装 package-a-1.0.0...
这一阶段最耗时,因为需要下载几十个 Python 包。如果网络不稳定,可能会出现超时或下载失败。遇到问题时,先检查网络连接,然后重新运行安装脚本(脚本支持断点续传)。
阶段 4:安装 CLI(约 10 秒)
[INFO] 正在安装 Hermes CLI...
[INFO] 安装路径: ~/.hermes/bin/hermes
[INFO] 已添加到 PATH: ~/.bashrc
阶段 5:生成配置(约 5 秒)
[INFO] 正在生成默认配置...
[INFO] 配置文件: ~/.hermes/config.yaml
[INFO] 人设文件: ~/.hermes/SOUL.md
安装完成后,建议新开一个终端窗口(或运行 source ~/.bashrc),然后验证 hermes 命令是否可用。
注意
一键安装脚本会自动完成以下操作: 1. 检查系统环境(Python 版本、Node.js 版本等) 2. 创建
~/.hermes/目录结构 3. 安装所需的 Python 依赖包 4. 将 Hermes 二进制文件安装到~/.hermes/bin/,并自动加入系统 PATH 5. 生成默认配置文件安装完成后,Hermes 的可执行文件位于
~/.hermes/bin/hermes。安装脚本会自动修改你的 shell 配置文件(~/.bashrc或~/.zshrc)将~/.hermes/bin加入 PATH。如果新开终端后仍提示找不到命令,请手动执行source ~/.bashrc(bash 用户)或source ~/.zshrc(zsh 用户)使配置生效。整个过程通常需要 3-10 分钟,取决于你的网络速度。安装过程中请保持终端窗口打开,不要中断。
安装过程中的典型输出:
[INFO] 正在检查系统环境...
[INFO] Python 版本: 3.11.9 ✓
[INFO] Node.js 版本: v22.3.0 ✓
[INFO] 正在创建 ~/.hermes 目录...
[INFO] 正在安装 Python 依赖...
正在下载 package-name-1.2.3...
正在安装 package-name-1.2.3...
...
[INFO] 正在安装 Hermes CLI...
[INFO] 正在生成默认配置...
[SUCCESS] Hermes 安装完成!
[SUCCESS] 运行 `hermes setup` 开始初始配置。
看到 SUCCESS 字样,恭喜你,Hermes 已经成功安装到你的 Mac 上了!
第六步:验证安装
# 检查 Hermes 版本
hermes --version
# 或者
hermes -v
# 运行系统诊断
hermes doctor
如果 hermes doctor 显示所有检查项都是绿色通过,说明安装完全成功。如果有黄色警告或红色错误,请参考第 7 章进行排查。
2.2 Linux 安装全流程(Ubuntu 22.04 为例)
Linux 是服务器部署的首选操作系统,也是很多开发者日常使用的系统。以下以 Ubuntu 22.04 LTS 为例,其他 Debian 系发行版步骤类似。如果你使用的是 Fedora/CentOS/RHEL,部分命令会有所不同(如 apt 换成 dnf 或 yum)。
第一步:系统更新与依赖安装
# 更新软件包列表
sudo apt update
# 升级已安装的软件包
sudo apt upgrade -y
# 安装必要的构建工具和依赖
sudo apt install -y \
curl \
wget \
git \
build-essential \
libssl-dev \
zlib1g-dev \
libbz2-dev \
libreadline-dev \
libsqlite3-dev \
llvm \
libncursesw5-dev \
xz-utils \
tk-dev \
libxml2-dev \
libxmlsec1-dev \
libffi-dev \
liblzma-dev
Tips
上面安装的一堆
lib*-dev包是编译 Python 时需要的依赖。如果你使用 pyenv 从源码编译安装 Python,这些依赖必须提前装好,否则编译会失败。这就好比你要盖房子,得先把砖头和水泥准备好。不同 Linux 发行版的依赖包名可能略有不同。如果你使用的是 Fedora/RHEL,对应的包名通常是
openssl-devel、zlib-devel、libffi-devel等。
第二步:安装 Python 3.11
Ubuntu 22.04 默认自带 Python 3.10,我们需要额外安装 Python 3.11。
# 添加 deadsnakes PPA(提供最新 Python 版本的第三方仓库)
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
# 安装 Python 3.11 及配套工具
sudo apt install -y python3.11 python3.11-venv python3.11-dev python3.11-distutils
# 验证安装
python3.11 --version
# 应输出: Python 3.11.x
# 安装 pip for Python 3.11
curl -sS https://bootstrap.pypa.io/get-pip.py | python3.11
# 验证 pip
python3.11 -m pip --version
注意
在 Ubuntu 上,同时存在
python3(系统默认版本)和python3.11(我们新安装的版本)。建议明确使用python3.11和pip(对应 Python 3.11 的 pip)来避免混淆。你也可以通过创建符号链接或别名来简化命令。```bash
创建别名(添加到 ~/.bashrc)
alias python311='python3.11' alias pip311='python3.11 -m pip' ```
第三步:安装 pyenv(推荐)
# 安装 pyenv
curl https://pyenv.run | bash
# 将 pyenv 添加到 ~/.bashrc
echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
echo '[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(pyenv init -)"' >> ~/.bashrc
# 重新加载配置
source ~/.bashrc
# 使用 pyenv 安装 Python 3.11.9
pyenv install 3.11.9
pyenv global 3.11.9
# 验证
python --version
第四步:安装 Node.js v22
# 使用 NodeSource 安装脚本安装 Node.js 22
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
# 验证
node --version
npm --version
第五步:运行 Hermes 安装脚本
# 一键安装
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 或者手动安装
git clone https://github.com/NousResearch/hermes.git ~/hermes
cd ~/hermes
python3.11 -m pip install -e .
第六步:验证安装
hermes --version
hermes doctor
Fedora/RHEL 用户的差异说明:
如果你使用的是 Fedora、CentOS Stream 或 RHEL,以下命令需要调整:
| Ubuntu/Debian | Fedora/RHEL |
|---|---|
sudo apt update |
sudo dnf update |
sudo apt install |
sudo dnf install |
libssl-dev |
openssl-devel |
libffi-dev |
libffi-devel |
build-essential |
@development-tools |
ppa:deadsnakes/ppa |
使用 dnf module install python311 |
其余步骤(安装 Node.js、运行 Hermes 安装脚本)基本一致。
2.3 Windows WSL2 安装全流程
Windows 用户不能直接安装 Hermes(Hermes 不支持原生 Windows 环境),但可以通过 WSL2(Windows Subsystem for Linux)在 Windows 上运行一个完整的 Linux 环境,然后在其中安装 Hermes。
第一步:安装 WSL2
WSL2 是 Windows 10/11 内置的 Linux 子系统,让你可以在 Windows 上原生运行 Linux 程序,性能几乎和原生 Linux 一样。
自动安装(推荐 Windows 10 2004+ / Windows 11):
以管理员身份打开 PowerShell,运行:
# 自动安装 WSL2 和默认的 Ubuntu 发行版
wsl --install
运行后,系统会自动下载并安装 WSL2 和 Ubuntu。安装完成后,需要重启电脑。
注意
如果命令提示 "WSL 需要更新其内核组件",请访问微软官方文档下载 WSL2 Linux 内核更新包: https://docs.microsoft.com/zh-cn/windows/wsl/install-manual#step-4---download-the-linux-kernel-update-package
手动安装(旧版 Windows):
# 启用 WSL
wsl --set-default-version 2
# 查看可用的 Linux 发行版
wsl --list --online
# 安装 Ubuntu 22.04
wsl --install -d Ubuntu-22.04
第二步:配置 Ubuntu 22.04
重启后,从开始菜单打开 "Ubuntu 22.04"。首次启动会要求你设置用户名和密码:
Enter new UNIX username: yourname
New password: [输入密码,不会显示]
Retype new password: [再次输入]
Tips
这个用户名和密码是你 Ubuntu 子系统的凭证,和 Windows 登录密码无关。请牢记这个密码,因为后续执行
sudo命令时需要输入它。
更新 Ubuntu 系统:
sudo apt update && sudo apt upgrade -y
第三步:在 WSL 中安装 Hermes
WSL 中的 Ubuntu 就是一个完整的 Linux 系统,接下来的步骤和 2.2 节「Linux 安装全流程」完全一样:
# 安装依赖
sudo apt install -y curl wget git build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev llvm libncursesw5-dev \
xz-utils tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev
# 安装 Python 3.11
sudo apt install -y software-properties-common
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
sudo apt install -y python3.11 python3.11-venv python3.11-dev python3.11-distutils
curl -sS https://bootstrap.pypa.io/get-pip.py | python3.11
# 安装 Node.js 22
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
# 安装 Hermes
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 验证
hermes --version
第四步:Windows 文件系统访问与权限处理
WSL2 的一个强大之处在于,你可以无缝访问 Windows 的文件系统。Windows 的各个盘符在 WSL 中挂载在 /mnt/ 目录下:
# 访问 C 盘
cd /mnt/c
ls
# 访问 D 盘
cd /mnt/d
ls
# 访问你的 Windows 用户目录
cd /mnt/c/Users/你的Windows用户名/Desktop
注意
虽然 WSL 可以访问 Windows 文件,但 不建议在
/mnt/c等 Windows 挂载目录下直接运行 Hermes。因为 Windows 和 Linux 的文件权限系统不同,可能会导致一些奇怪的问题。推荐的做法是: 1. 在 WSL 的 Linux 主目录(~,即/home/你的用户名)下运行 Hermes 2. 如果需要处理 Windows 上的文件,可以把文件复制到 WSL 中,或者在 Hermes 中指定 Windows 路径
从 Windows 访问 WSL 文件:
在 Windows 文件资源管理器的地址栏输入 \\wsl$\Ubuntu-22.04\home\你的用户名,就可以直接浏览 WSL 中的文件。
最佳实践:创建共享工作目录
# 在 WSL 中创建一个工作目录
mkdir -p ~/workspace
# 同时在 Windows 的文档目录也创建一个快捷方式
# 在 Windows PowerShell 中执行:
# New-Item -ItemType SymbolicLink -Path "$env:USERPROFILE\workspace" -Target "\\wsl$\Ubuntu-22.04\home\你的用户名\workspace"
常见问题
Q:WSL2 占用内存太多,怎么限制?
A:WSL2 默认可以使用你电脑的大部分内存。如果你的电脑内存有限,可以在 Windows 用户目录下创建
.wslconfig文件来限制内存使用: ```文件路径: C:\Users\你的用户名.wslconfig
[wsl2] memory=8GB processors=4 swap=2GB
`` 保存后运行wsl --shutdown` 重启 WSL2 生效。
3. 方式二:Docker 容器化部署
Docker 是一种「集装箱化」技术,它把应用程序和它所有的依赖打包成一个标准化的「集装箱」(容器),无论你把这个集装箱运到哪台机器上,它都能以完全相同的方式运行。
这就好比搬家:传统方式是把你家里的每件家具分别搬过去,到了新家还要重新组装;Docker 方式则是把整个房子连地基一起打包运过去,到了目的地直接放下就能住。
3.1 Docker Desktop 安装
要使用 Docker 部署 Hermes,首先需要在你的电脑上安装 Docker Desktop。
macOS 安装 Docker Desktop
# 方式一:通过 Homebrew 安装(推荐)
brew install --cask docker
# 方式二:手动下载安装
# 访问 https://www.docker.com/products/docker-desktop/
# 下载 macOS 版本并安装
安装完成后,从「应用程序」中启动 Docker Desktop。首次启动可能需要你输入系统密码来授权。当 Docker 状态栏图标显示鲸鱼图标且没有警告标记时,说明 Docker 已经就绪。
Tips
Docker Desktop for Mac 在 Apple Silicon (M1/M2/M3/M4) 上运行时需要 Rosetta 2 支持。如果你的 Mac 是 Apple Silicon 且没有安装 Rosetta 2,系统会在第一次运行时自动提示安装。请点击「安装」并输入密码。
Windows 安装 Docker Desktop
- 访问 https://www.docker.com/products/docker-desktop/
- 下载 Windows 版本安装包
- 运行安装程序,按向导完成安装
- 安装过程中可能会要求启用 WSL2 集成,请勾选该选项
- 安装完成后重启电脑
- 启动 Docker Desktop,等待 Docker 引擎启动完成
注意
Windows 上的 Docker Desktop 依赖 WSL2 后端。如果你还没有安装 WSL2,请参考 2.3 节先安装 WSL2,或者在 Docker Desktop 安装过程中选择自动安装。
Linux 安装 Docker Desktop
# 以 Ubuntu 为例
# 1. 卸载旧版本(如有)
sudo apt remove docker docker-engine docker.io containerd runc
# 2. 安装依赖
sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release
# 3. 添加 Docker 官方 GPG 密钥
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
# 4. 添加 Docker 软件源
echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# 5. 安装 Docker Engine
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
# 6. 将当前用户加入 docker 组(免 sudo 使用 docker)
sudo usermod -aG docker $USER
# 7. 验证安装
docker --version
docker compose version
注意
将用户加入 docker 组后,需要 退出并重新登录(或重启电脑)才能免 sudo 使用 docker 命令。
3.2 拉取 Hermes 官方镜像
Docker 安装完成后,拉取 Hermes 的官方镜像:
# 拉取最新版本的 Hermes 镜像
docker pull nousresearch/hermes:latest
# 或者拉取特定版本
docker pull nousresearch/hermes:v1.2.0
# 查看已拉取的镜像
docker images | grep hermes
常见问题
Q:拉取镜像时速度很慢或超时,怎么办?
A:国内用户访问 Docker Hub 速度可能较慢。解决方案: 1. 配置 Docker 使用国内镜像加速站。编辑
~/.docker/daemon.json:json { "registry-mirrors": [ "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com", "https://mirror.baidubce.com" ] }保存后重启 Docker Desktop。 2. 使用代理拉取:bash docker pull nousresearch/hermes:latest --proxy http://127.0.0.1:7890
镜像版本选择指南:
| 标签 | 说明 | 适用场景 |
|---|---|---|
latest |
最新稳定版 | 大多数用户 |
v1.2.3 |
特定版本 | 需要版本锁定 |
nightly |
每日构建版 | 想体验最新功能 |
slim |
精简版(无额外工具) | 资源受限环境 |
注意
latest标签会随着新版本发布而更新。如果你需要稳定的生产环境,建议锁定到具体版本号(如v1.2.3),避免自动更新带来的不兼容性。
3.3 容器运行与数据持久化
基础运行命令
# 运行 Hermes 容器
docker run -it --rm \
--name hermes \
-v ~/.hermes:/opt/data \
-e OPENAI_API_KEY="your-api-key-here" \
nousresearch/hermes:latest
让我们逐行解析这个命令:
docker run: 启动一个新容器-it: 以交互式终端模式运行(i = interactive, t = tty)--rm: 容器停止后自动删除(适合临时运行)--name hermes: 给容器起个名字叫 hermes-v ~/.hermes:/opt/data: 这是最关键的部分,将主机的~/.hermes目录挂载到容器的/opt/data目录。这样容器里的数据会保存到你的主机上,即使删除容器也不会丢失。-e OPENAI_API_KEY=...: 设置环境变量,传入 API Keynousresearch/hermes:latest: 使用的镜像名称
数据持久化详解
-v ~/.hermes:/opt/data 这个参数是 Docker 部署中最需要理解的概念。让我用一个类比来解释:
想象容器是一个「临时办公室」,容器里的文件就像办公室里的便利贴。如果你不贴到墙上(挂载卷),容器一关,便利贴就全没了。-v 参数就是一面「魔法墙」,你把便利贴贴到这面墙上,即使办公室拆了重建,墙上的便利贴还在。
所以,一定要加 -v 参数,否则你的所有配置、对话记录、记忆数据都会在容器删除后消失。
# 先创建主机上的数据目录
mkdir -p ~/.hermes
# 运行容器并挂载数据卷
docker run -it --rm \
--name hermes \
-v ~/.hermes:/opt/data \
nousresearch/hermes:latest
3.4 Docker Compose 方式(适合多服务编排)
如果你打算同时运行 Hermes 和其他服务(比如本地数据库、Web 界面等),使用 Docker Compose 会更方便。Docker Compose 让你可以用一个 YAML 文件定义和管理多个容器。
创建 docker-compose.yml 文件:
# docker-compose.yml
version: '3.8'
services:
hermes:
image: nousresearch/hermes:latest
container_name: hermes
restart: unless-stopped
volumes:
- ~/.hermes:/opt/data
- ~/workspace:/workspace
environment:
- OPENAI_API_KEY=${OPENAI_API_KEY}
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
stdin_open: true
tty: true
networks:
- hermes-network
networks:
hermes-network:
driver: bridge
使用 Docker Compose 启动:
# 在 docker-compose.yml 所在目录执行
# 启动服务(后台运行)
docker compose up -d
# 查看运行状态
docker compose ps
# 查看日志
docker compose logs -f hermes
# 进入容器内部
docker compose exec hermes bash
# 停止服务
docker compose down
# 停止服务并删除数据卷(慎用!)
docker compose down -v
Tips
Docker Compose 是管理多容器应用的利器。上面的配置中: -
restart: unless-stopped表示容器会在 Docker 启动时自动运行(除非手动停止) -${OPENAI_API_KEY}会从环境变量或同目录的.env文件中读取 -stdin_open: true和tty: true保证交互式终端正常工作
创建 .env 文件存储敏感信息:
# .env 文件(放在 docker-compose.yml 同目录,不要提交到 Git!)
OPENAI_API_KEY=sk-your-openai-key
ANTHROPIC_API_KEY=sk-your-anthropic-key
DEEPSEEK_API_KEY=sk-your-deepseek-key
注意
务必在
.gitignore中添加.env,防止 API Key 泄露!
3.5 容器管理常用命令
# 查看正在运行的容器
docker ps
# 查看所有容器(包括已停止的)
docker ps -a
# 停止容器
docker stop hermes
# 启动已停止的容器
docker start hermes
# 重启容器
docker restart hermes
# 删除容器
docker rm hermes
# 强制删除运行中的容器
docker rm -f hermes
# 查看容器日志
docker logs hermes
# 实时查看日志
docker logs -f hermes
# 进入运行中的容器
docker exec -it hermes bash
# 从容器内复制文件到主机
docker cp hermes:/opt/data/config.yaml ~/.hermes/config.yaml
# 从主机复制文件到容器
docker cp ~/.hermes/config.yaml hermes:/opt/data/config.yaml
# 查看容器资源使用情况
docker stats hermes
3.6 容器化的优缺点分析
优点
| 优点 | 说明 |
|---|---|
| 环境隔离 | Hermes 的依赖不会和你的系统环境冲突 |
| 一键部署 | 一条命令就能启动完整环境 |
| 便于迁移 | 在任何支持 Docker 的机器上都能以相同方式运行 |
| 易于清理 | 不想用了直接删除容器,不留痕迹 |
| 版本管理 | 可以轻松切换 Hermes 的不同版本 |
| 多实例运行 | 可以同时运行多个 Hermes 实例 |
缺点
| 缺点 | 说明 |
|---|---|
| 学习成本 | 需要了解 Docker 的基本概念和命令 |
| 资源开销 | Docker 本身会占用一些额外的系统资源 |
| 文件访问 | 容器内外文件共享需要额外配置 |
| GUI 限制 | 某些图形界面功能在容器中可能受限 |
| 调试复杂 | 出问题时的调试比本地部署复杂一些 |
Tips
对于新手,我建议先从「本地常规部署」开始,等熟悉 Hermes 的基本操作后再尝试 Docker 部署。但如果你已经有 Docker 使用经验,或者需要在一台机器上管理多个项目的环境,Docker 部署会是更好的选择。
4. 方式三:VPS 云服务器部署
VPS(Virtual Private Server,虚拟专用服务器)部署适合以下场景:
- 你需要 Hermes 24/7 不间断运行
- 你想从任何地方(手机、公司电脑等)访问你的 Agent
- 你的本地电脑性能有限或网络不稳定
- 你想搭建一个团队共享的 Hermes 实例
4.1 推荐 VPS 提供商
海外 VPS 推荐
| 提供商 | 入门价格 | 特点 | 适合人群 |
|---|---|---|---|
| Hetzner | €4.51/月 | 性价比极高、性能稳定、德国/芬兰机房 | 预算有限但追求性能的用户 |
| DigitalOcean | $4/月 | 界面友好、文档完善、全球多机房 | 新手入门 |
| Linode (Akamai) | $5/月 | 老牌厂商、网络稳定 | 追求稳定性的用户 |
| Vultr | $2.50/月 | 按小时计费、可一键部署多种应用 | 短期使用或测试 |
| AWS Lightsail | $5/月 | AWS 生态、与其他 AWS 服务集成方便 | 已有 AWS 经验的用户 |
国内云服务器推荐
| 提供商 | 入门价格 | 特点 | 适合人群 |
|---|---|---|---|
| 阿里云 ECS | ¥99/年(学生/新用户) | 生态完善、文档丰富 | 国内用户、需要备案 |
| 腾讯云 CVM | ¥99/年(新用户) | 性价比高、活动多 | 国内用户 |
| 华为云 ECS | ¥99/年(新用户) | 企业级稳定性 | 企业用户 |
Tips
如果你主要使用 Hermes 来处理中文内容和对接国内 API(如 DeepSeek、Kimi),强烈建议选择国内云服务器。网络延迟会显著影响对话体验。如果你主要对接 OpenAI、Anthropic 等海外 API,海外 VPS 的延迟反而更低。
对于个人学习和轻度使用,Hetzner 的 CPX11(1 vCPU / 2GB RAM / 40GB SSD)或 DigitalOcean 的 Basic Droplet(1 vCPU / 1GB RAM / 25GB SSD)完全够用,月费不到一杯奶茶钱。
4.2 服务器选型指南
Hermes 对服务器配置的要求很低:
最低配置(个人使用):
- 1 vCPU
- 1 GB RAM
- 20 GB SSD 磁盘
- 1 TB 月流量
推荐配置(多人使用或重度使用):
- 2 vCPU
- 4 GB RAM
- 40 GB SSD 磁盘
- 2 TB 月流量
注意
Hermes 本身的资源占用很低(空闲时内存占用通常小于 100MB)。服务器的配置主要取决于: 1. 你同时运行多少个 Agent 实例 2. 你是否在服务器上同时运行本地大模型(如 Ollama) 3. 你的日志和数据存储量
如果不在服务器上跑本地模型,1GB 内存绰绰有余。
4.3 SSH 连接与安全配置
购买 VPS 后,你会收到一封包含服务器 IP 地址、用户名(通常是 root)和初始密码的邮件。这就像是收到了新房的钥匙——兴奋之余,别忘了先换锁、装监控。
首次连接服务器
# macOS / Linux 终端直接连接
ssh root@你的服务器IP
# 示例
ssh root@123.456.789.0
# 如果指定了非标准端口(如 2222)
ssh -p 2222 root@你的服务器IP
Windows 用户可以使用 PowerShell(Windows 10/11 自带 OpenSSH 客户端)或下载 PuTTY。
首次连接时会提示是否确认主机的指纹,输入 yes 即可:
The authenticity of host '123.456.789.0' can't be established.
Are you sure you want to continue connecting (yes/no)? yes
Tips
SSH 密钥指纹是服务器的「身份证」。第一次连接时,你的电脑会把服务器的指纹记录下来。如果将来连接时指纹变了,SSH 会警告你,这可能意味着服务器被中间人攻击了。所以第一次记录指纹时,请确保你连接的是正确的服务器。
基础安全配置
连接到服务器后,强烈建议立即进行以下安全加固:
1. 修改 root 密码(如果使用的是密码登录):
passwd
2. 创建普通用户(避免日常使用 root):
# 创建新用户
useradd -m -s /bin/bash hermes
# 设置密码
passwd hermes
# 将用户加入 sudo 组
usermod -aG sudo hermes
# 切换到新用户
su - hermes
注意
root 用户就像房子的万能钥匙,权力太大,一旦被盗用,攻击者可以为所欲为。日常使用普通用户 + sudo,就像平时用普通钥匙开门,只有需要的时候才用万能钥匙——这样即使普通钥匙丢了,损失也有限。
3. 配置 SSH 密钥登录(更安全):
在你的本地电脑生成 SSH 密钥对(如果还没有):
# 本地电脑执行
ssh-keygen -t ed25519 -C "your_email@example.com"
# 将公钥复制到服务器
ssh-copy-id hermes@你的服务器IP
然后在服务器上禁用密码登录:
# 编辑 SSH 配置文件
sudo nano /etc/ssh/sshd_config
# 修改以下配置
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
# 重启 SSH 服务
sudo systemctl restart sshd
注意
在禁用密码登录之前,务必确认密钥登录已经正常工作!否则你可能会把自己锁在服务器外面。建议新开一个终端窗口测试密钥登录,确认无误后再禁用密码登录。
4. 配置防火墙:
# Ubuntu/Debian
sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
# 查看防火墙状态
sudo ufw status
5. 安装 fail2ban 防止暴力破解:
# 安装 fail2ban
sudo apt install fail2ban
# 启动服务
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
# 查看封禁状态
sudo fail2ban-client status sshd
fail2ban 会自动监控 SSH 登录尝试,如果某个 IP 在短时间内多次登录失败,就会自动将其封禁一段时间。这就像是给大门装了一个智能保安,看到可疑人员反复尝试开锁就会自动报警。
4.4 在 VPS 上安装 Hermes
VPS 上的安装步骤和 2.2 节「Linux 安装全流程」基本一致:
# 1. 系统更新
sudo apt update && sudo apt upgrade -y
# 2. 安装依赖
sudo apt install -y curl wget git build-essential libssl-dev \
zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
llvm libncursesw5-dev xz-utils tk-dev libxml2-dev \
libxmlsec1-dev libffi-dev liblzma-dev software-properties-common
# 3. 安装 Python 3.11
sudo add-apt-repository ppa:deadsnakes/ppa -y
sudo apt update
sudo apt install -y python3.11 python3.11-venv python3.11-dev python3.11-distutils
curl -sS https://bootstrap.pypa.io/get-pip.py | python3.11
# 4. 安装 Node.js 22
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
# 5. 安装 Hermes
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 6. 验证
hermes --version
hermes doctor
4.5 后台运行配置
在 VPS 上,你需要让 Hermes 在 SSH 断开后继续运行。以下是几种方式:
方式一:screen(最简单)
screen 是一个终端复用工具,可以让你在断开 SSH 后保持程序运行。
# 安装 screen
sudo apt install -y screen
# 创建一个新的 screen 会话
screen -S hermes
# 在 screen 中启动 Hermes
hermes
# 按 Ctrl+A,然后按 D, detach 会话(程序继续在后台运行)
# 注意:是先按 Ctrl+A,松开后再按 D
# 重新连接会话
screen -r hermes
# 查看所有 screen 会话
screen -ls
# 终止会话
screen -X -S hermes quit
Tips
screen 非常适合新手。它的学习成本几乎为零,几个命令就能满足基本的后台运行需求。唯一的缺点是如果服务器重启,screen 会话不会自动恢复。
方式二:tmux(功能更强大)
tmux 是 screen 的现代化替代品,功能更强大,界面更美观。
# 安装 tmux
sudo apt install -y tmux
# 创建新会话
tmux new -s hermes
# 在 tmux 中启动 Hermes
hermes
# 分离会话:按 Ctrl+B,然后按 D
# 重新连接会话
tmux attach -t hermes
# 查看所有会话
tmux ls
# 终止会话
tmux kill-session -t hermes
tmux 常用快捷键:
| 快捷键 | 功能 |
|---|---|
| Ctrl+B, D | 分离当前会话 |
| Ctrl+B, C | 创建新窗口 |
| Ctrl+B, N | 切换到下一个窗口 |
| Ctrl+B, P | 切换到上一个窗口 |
| Ctrl+B, 数字 | 切换到指定窗口 |
| Ctrl+B, % | 垂直分屏 |
| Ctrl+B, " | 水平分屏 |
Tips
tmux 的分屏功能特别实用。你可以左边窗口运行 Hermes,右边窗口查看系统日志或编辑配置文件,一个终端窗口搞定所有操作。
4.6 域名绑定与反向代理(可选)
如果你想通过域名访问 Hermes 的 Web 界面,可以配置 Nginx 反向代理。这就好比你在一个大型写字楼里租了一间办公室(服务器),Nginx 就是前台——访客只需要知道公司名字(域名),前台会帮他们找到正确的办公室。
前提条件
- 你已经购买了一个域名(如
yourdomain.com) - 已经将域名解析到服务器的 IP 地址(在域名服务商的 DNS 管理中添加 A 记录)
安装和配置 Nginx
# 安装 Nginx
sudo apt install -y nginx
# 创建 Nginx 配置文件
sudo nano /etc/nginx/sites-available/hermes
在文件中写入:
server {
listen 80;
server_name yourdomain.com;
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
}
}
注意
上面的配置假设 Hermes 的 Web 界面运行在本地的 8080 端口。请根据你的实际配置调整
proxy_pass的端口号。如果你不确定端口,可以查看~/.hermes/config.yaml中的gateway.web_port配置项。
# 启用配置
sudo ln -s /etc/nginx/sites-available/hermes /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx
# 安装 Certbot 获取免费 SSL 证书
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com
# 按照提示完成证书申请
配置完成后,你就可以通过 https://yourdomain.com 访问 Hermes 的 Web 界面了。
Tips
Certbot 的 SSL 证书有效期为 90 天,但会自动续期。你可以用以下命令测试续期是否正常:
bash sudo certbot renew --dry-run如果你使用的是 Cloudflare 等 CDN 服务,需要在 Cloudflare 控制台中将 SSL/TLS 加密模式设为「完全(严格)」,并在源服务器上正确配置证书。
4.7 自动启动配置(systemd)
如果你希望 Hermes 在服务器重启后自动启动,可以使用 systemd 来管理。
创建 systemd 服务文件:
sudo nano /etc/systemd/system/hermes.service
写入以下内容:
[Unit]
Description=Hermes Agent
After=network.target
[Service]
Type=simple
User=hermes
WorkingDirectory=/home/hermes
Environment="HOME=/home/hermes"
Environment="PATH=/home/hermes/.local/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=/home/hermes/.local/bin/hermes chat
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
注意
请根据你的实际安装路径调整
ExecStart和Environment中的路径。你可以用which hermes查看 hermes 命令的实际路径。
启用和启动服务:
# 重新加载 systemd 配置
sudo systemctl daemon-reload
# 设置开机自启
sudo systemctl enable hermes
# 启动服务
sudo systemctl start hermes
# 查看服务状态
sudo systemctl status hermes
# 查看日志
sudo journalctl -u hermes -f
# 停止服务
sudo systemctl stop hermes
# 重启服务
sudo systemctl restart hermes
日志轮转配置(防止日志占满磁盘)
Hermes 运行时间长了会产生大量日志。如果不加管理,日志文件可能占满整个磁盘。使用 Linux 自带的 logrotate 工具可以轻松解决这个问题。
# 创建 logrotate 配置
sudo nano /etc/logrotate.d/hermes
写入:
/var/log/hermes/*.log {
daily
rotate 14
compress
delaycompress
missingok
notifempty
create 0644 hermes hermes
sharedscripts
postrotate
systemctl reload hermes > /dev/null 2>&1 || true
endscript
}
参数说明:
| 参数 | 含义 |
|---|---|
daily |
每天轮转一次 |
rotate 14 |
保留最近 14 天的日志 |
compress |
轮转后压缩旧日志 |
delaycompress |
延迟一天压缩,方便查看昨天日志 |
missingok |
日志不存在时不报错 |
notifempty |
空日志不轮转 |
# 测试配置是否正确
sudo logrotate -d /etc/logrotate.d/hermes
# 手动执行一次轮转
sudo logrotate -f /etc/logrotate.d/hermes
Tips
日志轮转就像定期清理房间——每天把旧报纸(日志)打包归档,只保留最近两周的。这样既不会丢失重要信息,又不会因为报纸堆满房间而无处下脚。对于长期运行的 VPS,这一步绝对不能省略。
5. 方式四:无服务器部署(进阶)
无服务器(Serverless)部署是近年来兴起的一种部署模式。它的核心理念是:你不需要管理服务器,只需上传代码,平台会自动为你分配计算资源并按实际使用量计费。
这就好比传统部署是你买一辆车(服务器),无论开不开都要付油费和停车费;无服务器部署则是打车,需要时叫车,用完即走,按里程付费。
5.1 Modal 部署方式
Modal 是一个专为 AI/ML 工作负载设计的无服务器平台。它特别适合部署像 Hermes 这样的 Agent 应用,因为它支持:
- 快速启动的容器环境
- 按需计费(按秒计费,不用时不花钱)
- 内置的 GPU 支持(如果你需要运行本地模型)
- 简单的 Python SDK
准备工作
- 注册 Modal 账号:https://modal.com/
- 安装 Modal CLI:
pip install modal
- 登录 Modal:
modal token new
这会打开浏览器让你授权,按提示完成即可。
部署 Hermes 到 Modal
创建一个 deploy_modal.py 文件:
import modal
# 定义 Modal 应用
app = modal.App("hermes-agent")
# 定义容器镜像
image = (
modal.Image.debian_slim()
.apt_install("git", "curl", "build-essential")
.pip_install("hermes-agent")
)
# 定义持久化卷
volume = modal.Volume.from_name("hermes-data", create_if_missing=True)
@app.function(
image=image,
volumes={"/opt/data": volume},
secrets=[modal.Secret.from_name("hermes-secrets")],
timeout=3600, # 1小时超时
)
def run_hermes(prompt: str):
"""运行 Hermes Agent"""
import subprocess
import os
# 设置数据目录
os.environ["HERMES_DATA_DIR"] = "/opt/data"
# 运行 Hermes 命令
result = subprocess.run(
["hermes", "-c", prompt],
capture_output=True,
text=True,
timeout=300
)
return {
"stdout": result.stdout,
"stderr": result.stderr,
"returncode": result.returncode
}
@app.local_entrypoint()
def main():
# 本地测试入口
response = run_hermes.remote("Hello, what can you do?")
print(response["stdout"])
配置 secrets:
# 创建 Modal Secret 存储 API Keys
modal secret create hermes-secrets \
OPENAI_API_KEY=sk-your-key \
ANTHROPIC_API_KEY=sk-your-key
部署:
# 部署到 Modal
modal deploy deploy_modal.py
# 调用函数
modal run deploy_modal.py
注意
Modal 的免费额度 generous(每月 $30 的额度),对于个人轻度使用完全够用。但如果你的 Agent 需要长时间运行(如监控任务),Modal 的超时限制可能不适合,此时应考虑 VPS 部署。
5.2 Daytona 部署方式
Daytona 是一个开源的开发环境管理平台,可以让你一键创建标准化的开发环境,并在任何地方访问。
准备工作
- 注册 Daytona 账号:https://www.daytona.io/
- 安装 Daytona CLI:
# macOS
brew install daytona
# Linux
curl -fsSL https://download.daytona.io/daytona/install.sh | bash
- 登录 Daytona:
daytona login
创建 Hermes 开发环境
# 创建新的工作区
daytona create hermes-workspace
# 选择基础镜像(推荐 Ubuntu 22.04)
# 然后 Daytona 会自动创建一个配置好的开发环境
# 进入工作区
daytona ssh hermes-workspace
# 在工作区内安装 Hermes(按 Linux 安装流程)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 配置 API Keys
hermes setup
Tips
Daytona 的优势在于它为你管理了所有环境配置。你可以在办公室电脑上开始工作,回家后在笔记本上继续,所有状态和文件都是同步的。它特别适合需要在多台设备间切换的开发者。
5.3 适用场景与成本分析
各种部署方式的成本对比
| 部署方式 | 月成本(个人使用) | 适用场景 | 运维复杂度 |
|---|---|---|---|
| 本地部署 | ¥0 | 个人学习、开发测试 | 低 |
| Docker 本地 | ¥0 | 环境隔离、多版本管理 | 中 |
| VPS (Hetzner) | ~¥35 | 24/7 运行、远程访问 | 中 |
| VPS (国内云) | ~¥8(新用户) | 国内 API 低延迟访问 | 中 |
| Modal | ¥0-$30 | 按需运行、AI 推理 | 低 |
| Daytona | ¥0-$20 | 多设备开发环境 | 低 |
选择建议
- 纯新手入门:选择「本地常规部署」,零额外成本,遇到问题好排查
- 开发者日常:选择「本地 + Docker」,兼顾开发便利和环境一致性
- 需要远程访问:选择「VPS 云服务器」,DigitalOcean 或 Hetzner 性价比最高
- 间歇性使用:选择「Modal 无服务器」,不用时完全免费
- 团队协作:选择「VPS + systemd + Nginx」,稳定可控
Tips
对于绝大多数个人用户,我建议的搭配是:本地安装用于日常开发和测试,再配一台最便宜的 VPS(如 Hetzner CPX11,月费约 €4.51)用于 24/7 运行的自动化任务。这样一年的成本不到 500 元人民币,却拥有了完整的 Agent 工作流。
部署方式选择决策树:
如果你还是不确定该选哪种部署方式,可以用下面的决策树来快速判断:
你是第一次使用 Hermes 吗?
├─ 是 → 选择「本地常规部署」✓
└─ 否 → 你需要 24/7 不间断运行吗?
├─ 是 → 你有技术运维能力吗?
│ ├─ 是 → 选择「VPS + systemd」✓
│ └─ 否 → 选择「Docker + 托管平台」✓
└─ 否 → 你需要多设备同步吗?
├─ 是 → 选择「Daytona」✓
└─ 否 → 你需要环境隔离吗?
├─ 是 → 选择「Docker 本地」✓
└─ 否 → 选择「本地常规部署」✓
各部署方式的优缺点总结:
| 部署方式 | 最大优点 | 最大缺点 | 最佳用户 |
|---|---|---|---|
| 本地常规 | 零成本、易调试 | 电脑关机即停止 | 新手、开发者 |
| Docker | 环境隔离、易迁移 | 需要学习 Docker | 有容器经验的用户 |
| VPS | 24/7 在线、远程访问 | 需要服务器运维知识 | 需要长期运行的用户 |
| Modal | 按需付费、零运维 | 有冷启动延迟 | 间歇性任务用户 |
| Daytona | 多设备同步 | 依赖第三方平台 | 跨设备开发者 |
注意
无论选择哪种部署方式,数据目录
~/.hermes/的结构和内容是完全一致的。这意味着你可以随时在不同部署方式之间迁移——比如在本地开发调试完成后,把整个~/.hermes/目录复制到 VPS 上,Hermes 会保持完全相同的状态和配置。
6. ~/.hermes/ 目录结构详解
Hermes 安装完成后,会在你的用户主目录下创建一个 ~/.hermes/ 文件夹。这个文件夹就像是 Hermes 的「家」,所有的配置、记忆、技能和数据都存放在这里。理解这个目录结构,对于后续的配置优化和故障排查至关重要。
6.1 完整目录树
安装完成后,~/.hermes/ 的默认结构如下:
~/.hermes/
├── config.yaml # 主配置文件
├── SOUL.md # Agent 人设定义
├── MEMORY.md # 全局记忆文件
├── USER.md # 用户信息文件
├── database/
│ ├── hermes.db # SQLite 主数据库
│ └── vector.db # 向量数据库(用于语义搜索)
├── skills/
│ ├── built-in/ # 内置技能
│ ├── custom/ # 自定义技能
│ └── downloaded/ # 从 Skills Hub 下载的技能
├── cron/
│ ├── jobs.yaml # 定时任务定义
│ └── logs/ # 定时任务执行日志
├── logs/
│ ├── hermes.log # 主日志文件
│ └── error.log # 错误日志
├── cache/
│ ├── embeddings/ # 嵌入向量缓存
│ └── web/ # 网页缓存
├── backups/
│ └── auto/ # 自动备份目录
├── sessions/
│ └── 2026-04/
│ └── session_*.json # 会话历史文件
└── tmp/
└── *.tmp # 临时文件
6.2 每个文件和文件夹的用途详解
config.yaml —— 主配置文件
config.yaml 是 Hermes 的「中枢神经」,几乎所有的核心配置都在这里。安装完成后,会生成一个带有注释的默认配置文件。
# ~/.hermes/config.yaml
# Hermes 主配置文件
# === 核心设置 ===
core:
# Agent 名称
name: "Hermes"
# 默认使用的模型提供者
default_provider: "openrouter"
# 默认模型
default_model: "anthropic/claude-3.5-sonnet"
# 对话语言
language: "zh"
# 日志级别: debug, info, warn, error
log_level: "info"
# === 模型配置 ===
models:
# 分层模型配置(详见第六册第 6 章)
reasoning:
provider: "anthropic"
model: "claude-3.5-sonnet"
execution:
provider: "openrouter"
model: "google/gemini-flash-1.5"
fallback:
- provider: "deepseek"
model: "deepseek-chat"
- provider: "openai"
model: "gpt-4o-mini"
# === API Key 配置 ===
# 建议通过环境变量设置,不要在配置文件中硬编码
providers:
openai:
api_key: "${OPENAI_API_KEY}"
base_url: "https://api.openai.com/v1"
anthropic:
api_key: "${ANTHROPIC_API_KEY}"
base_url: "https://api.anthropic.com"
deepseek:
api_key: "${DEEPSEEK_API_KEY}"
base_url: "https://api.deepseek.com"
openrouter:
api_key: "${OPENROUTER_API_KEY}"
base_url: "https://openrouter.ai/api/v1"
# Nous Portal:Nous Research 官方提供的统一订阅服务
# 一个月费涵盖所有接入模型,无需单独购买各平台 Key
nous:
api_key: "${NOUS_API_KEY}"
base_url: "https://portal.nousresearch.com/api/v1"
# 智谱 GLM-5:国产大模型,中文理解优秀
zhipu:
api_key: "${ZHIPU_API_KEY}"
base_url: "https://open.bigmodel.cn/api/paas/v4"
# MiniMax M2.7:国产模型,性价比出色
minimax:
api_key: "${MINIMAX_API_KEY}"
base_url: "https://api.minimax.chat/v1"
# === 记忆系统配置 ===
memory:
# 会话记忆条数
session_limit: 50
# 持久化记忆开关
persistent: true
# 向量搜索 Top-K
vector_top_k: 5
# === 工具配置 ===
tools:
# 启用的工具列表
enabled:
- web_search
- file_read
- file_write
- execute_shell
- github
# 禁用工具(优先级高于 enabled)
disabled: []
# === 技能系统配置 ===
skills:
# 自动技能发现
auto_discover: true
# 技能搜索路径
paths:
- "~/.hermes/skills/custom"
- "~/.hermes/skills/downloaded"
# === 消息网关配置 ===
gateway:
# Web 界面端口
web_port: 8080
# 启用平台
platforms:
- telegram
- discord
# === 定时任务配置 ===
cron:
# 定时任务开关
enabled: true
# 任务文件路径
jobs_file: "~/.hermes/cron/jobs.yaml"
注意
YAML 文件对缩进非常敏感!必须使用空格(不能用 Tab),且同级别的配置项缩进必须一致。如果你的
config.yaml格式有误,Hermes 启动时会报错。建议使用 VS Code 等编辑器的 YAML 插件来检查格式。
SOUL.md —— Agent 人设定义
SOUL.md 是 Hermes 最具特色的功能之一。它定义了你的 Agent 的「灵魂」——它的性格、说话方式、专业领域、行为准则等。
你可以把 SOUL.md 想象成演员拿到手的「角色剧本」。同一个 Hermes 程序,配上不同的 SOUL.md,可以变成完全不同的角色:一个严谨的程序员、一个耐心的老师、一个幽默的聊天伙伴……
# SOUL.md
# 这是 Hermes Agent 的人设定义文件
# 修改此文件后,Hermes 的行为和回答风格会随之改变
## 身份
你是一位名叫「墨离」的 AI 助手。
## 性格
- 沉稳、耐心、善于倾听
- 回答问题时先思考再开口,不急于给出结论
- 喜欢用类比和故事来解释复杂概念
- 偶尔会用温和的幽默调节气氛
## 专业领域
- Python 编程与软件架构
- 数据分析与可视化
- AI Agent 技术
- 中文写作与编辑
## 说话风格
- 使用中文回答,除非用户明确要求使用其他语言
- 避免使用过于学术化的术语,尽量通俗易懂
- 重要观点会用「>」引用格式强调
- 分点说明时喜欢用表格整理信息
## 行为准则
- 不确定的事情会坦诚告知,不编造信息
- 涉及代码时,总是提供完整的可运行示例
- 尊重用户隐私,不主动询问敏感信息
- 当用户情绪激动时,先安抚再解决问题
## 禁忌
- 不使用机器人口吻(如「作为一个人工智能助手」)
- 不重复用户的问题作为回答开头
- 不过度道歉
Tips
SOUL.md 的强大之处在于它是动态可更新的。在对话中,你可以直接对 Hermes 说「更新你的 SOUL.md,添加一个新的专业领域」,Hermes 会自动修改这个文件。这意味着你的 Agent 可以随着使用不断进化和个性化。
详细的 SOUL.md 编写指南请参阅第六册第 7 章。
MEMORY.md —— 全局记忆文件
MEMORY.md 是一个全局的、跨会话的记忆存储。与数据库存储的结构化记忆不同,MEMORY.md 是以纯文本 Markdown 格式存储的,方便你直接阅读和编辑。
# MEMORY.md
# 这是 Hermes 的全局记忆文件
# 这里存储的信息会在每次对话开始时自动加载
## 用户偏好
- 用户喜欢简洁的回答,不喜欢冗长的解释
- 用户是程序员,熟悉 Python 和 JavaScript
- 用户通常在晚上 9-11 点使用 Hermes
- 用户对 AI 伦理话题感兴趣
## 重要信息
- 用户的项目目录:`~/projects/my-startup`
- 用户常用的 API Key 别名:`openai_main`、`deepseek_backup`
- 用户的时区:Asia/Shanghai
## 待办事项
- [ ] 帮用户调研 MCP 协议的最新进展
- [ ] 记得提醒用户下周的代码评审会议
USER.md —— 用户信息文件
USER.md 存储关于你的基本信息,帮助 Hermes 更好地理解你的背景和需求。
# USER.md
# 用户信息
## 基本信息
- 称呼:王先生
- 职业:全栈开发者 / 独立创业者
- 所在地:中国,上海
## 技术栈
- 主要语言:Python、TypeScript
- 框架:React、FastAPI、Django
- 工具:VS Code、Docker、Git
## 使用场景
- 日常编程辅助和代码审查
- 技术文章写作
- 项目需求分析和文档撰写
- 学习新技术和框架
skills/ 目录
skills/ 目录存放所有的技能文件。技能是 Hermes 的功能扩展单元,每个技能定义了一组相关的工具和知识。
skills/
├── built-in/ # 内置技能(随 Hermes 安装)
│ ├── web_search/
│ ├── file_operations/
│ └── code_execution/
├── custom/ # 自定义技能(你自己创建的)
│ └── my_company_ops/
└── downloaded/ # 从 Skills Hub 下载的
└── stock_analysis/
每个技能文件夹通常包含:
skill.yaml—— 技能元数据和配置README.md—— 技能说明文档tools/—— 技能包含的工具定义prompts/—— 技能的提示词模板
cron/ 目录
cron/ 目录存放定时任务的配置和执行日志。
# ~/.hermes/cron/jobs.yaml
jobs:
- name: "daily-news-summary"
description: "每天早上 8 点总结科技新闻"
schedule: "0 8 * * *"
command: "搜索今天的科技新闻并总结要点"
enabled: true
- name: "weekly-report"
description: "每周五下午生成周报"
schedule: "0 17 * * 5"
command: "读取本周的会议纪要,生成周报"
enabled: false
database/ 目录
database/
├── hermes.db # SQLite 主数据库
│ ├── sessions # 会话表
│ ├── messages # 消息表
│ ├── memories # 记忆表
│ └── skills # 技能元数据表
└── vector.db # 向量数据库(Chroma 或 SQLite-vec)
└── embeddings # 文本嵌入向量
注意
这两个数据库文件包含了你的所有对话历史和记忆数据。在备份或迁移 Hermes 时,务必备份整个
database/目录。单个hermes.db文件在长期使用后可能会增长到几百 MB,这是正常现象。
logs/ 目录
logs/
├── hermes.log # 主运行日志(INFO 级别及以上)
└── error.log # 错误日志(ERROR 级别)
你可以用以下命令实时查看日志:
# 实时查看主日志
tail -f ~/.hermes/logs/hermes.log
# 实时查看错误日志
tail -f ~/.hermes/logs/error.log
# 搜索特定关键词
grep "ERROR" ~/.hermes/logs/hermes.log
6.3 目录结构总结表
| 路径 | 类型 | 用途 | 是否必须备份 |
|---|---|---|---|
config.yaml |
文件 | 主配置 | 是 |
SOUL.md |
文件 | 人设定义 | 是 |
MEMORY.md |
文件 | 全局记忆 | 是 |
USER.md |
文件 | 用户信息 | 是 |
database/ |
目录 | 数据库 | 是(最重要) |
skills/custom/ |
目录 | 自定义技能 | 是 |
skills/downloaded/ |
目录 | 下载的技能 | 否(可重新下载) |
cron/jobs.yaml |
文件 | 定时任务 | 是 |
logs/ |
目录 | 日志文件 | 否 |
cache/ |
目录 | 缓存文件 | 否 |
tmp/ |
目录 | 临时文件 | 否 |
目录结构类比理解:
你可以把 ~/.hermes/ 想象成一个人的「家」:
config.yaml= 这个人的「身份证和户口本」,记录了所有基本信息SOUL.md= 这个人的「性格和职业设定」,决定了他说话的方式和专业领域MEMORY.md= 这个人的「日记本」,记录了他记得的重要事情USER.md= 这个人的「通讯录」,记录了他服务对象的信息database/= 这个人的「记忆宫殿」,存储了所有对话历史的完整细节skills/= 这个人的「工具箱」,里面各种技能就是他的各种工具cron/= 这个人的「闹钟和日程表」,提醒他什么时候该做什么logs/= 这个人的「工作日志」,记录了每天的工作情况cache/= 这个人的「便利贴墙」,随手记的东西,不重要但方便查阅
Tips
建议设置一个自动备份脚本,定期将
config.yaml、SOUL.md、MEMORY.md、USER.md和database/备份到云盘。详细的备份方法请参阅第 9 章「卸载与重装」。一个实用的技巧:将
~/.hermes/用 Git 进行版本控制(排除database/、logs/、cache/、tmp/目录),这样你可以追踪 SOUL.md 和 config.yaml 的变更历史,随时回滚到之前的配置。
7. 运行状态自检与排障
安装完成后,不要急着开始用,先运行一遍系统自检,确保一切正常。这就像买了新车要先检查一下轮胎和油表一样。
7.1 hermes version 版本检查
# 查看 Hermes 版本
hermes --version
# 查看详细版本信息(包含 Python 版本、操作系统等)
hermes --version --verbose
预期输出:
Hermes Agent v1.2.3
Python: 3.11.9
Platform: macOS-14.4-arm64
Install path: /Users/username/.local/lib/python3.11/site-packages/hermes
7.2 hermes doctor 系统诊断详解
hermes doctor 是 Hermes 内置的「全身体检」工具。它会检查所有关键的系统依赖和配置项,并给出颜色-coded 的诊断结果:
- 绿色 = 一切正常
- 黄色 = 有警告,但不会影响核心功能
- 红色 = 有问题,需要修复
hermes doctor
典型输出示例:
╔══════════════════════════════════════════╗
║ Hermes Doctor - 系统诊断报告 ║
╚══════════════════════════════════════════╝
[检查项] [状态] [详情]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Python 版本 ✅ 通过 3.11.9
Node.js 版本 ✅ 通过 v22.3.0
Git 版本 ✅ 通过 2.43.0
pip 版本 ✅ 通过 24.0
目录权限 ✅ 通过 ~/.hermes/ 可读写
配置文件 ✅ 通过 config.yaml 格式正确
数据库连接 ✅ 通过 hermes.db 可正常访问
API Key 配置 ⚠️ 警告 只配置了 1 个 provider,建议配置 fallback
模型可达性 ✅ 通过 OpenRouter 连接正常
网络连接 ✅ 通过 互联网访问正常
内存使用 ✅ 通过 当前使用 128MB / 8GB
磁盘空间 ✅ 通过 剩余 245GB
Skills 目录 ✅ 通过 发现 12 个技能
Cron 配置 ✅ 通过 发现 2 个定时任务
════════════════════════════════════════════
诊断结果:11 项通过,1 项警告,0 项失败
整体状态:🟢 健康(有轻微警告)
════════════════════════════════════════════
每个检查项说明
| 检查项 | 检查内容 | 失败影响 |
|---|---|---|
| Python 版本 | 是否为 3.11+ | 核心功能无法运行 |
| Node.js 版本 | 是否为 v22+ | Web 界面可能不可用 |
| Git 版本 | 是否能正常执行 git 命令 | 技能同步功能受影响 |
| pip 版本 | 包管理器是否可用 | 无法安装新依赖 |
| 目录权限 | ~/.hermes/ 是否可读写 |
数据无法保存 |
| 配置文件 | config.yaml 格式是否正确 |
配置无法加载 |
| 数据库连接 | SQLite 数据库是否正常 | 记忆功能不可用 |
| API Key 配置 | 是否配置了至少一个 provider | 无法连接 LLM |
| 模型可达性 | 能否连接到配置的 LLM API | 对话功能不可用 |
| 网络连接 | 基本网络连通性 | 所有网络功能受影响 |
| 内存使用 | 剩余内存是否充足 | 系统可能变慢或崩溃 |
| 磁盘空间 | 剩余空间是否充足 | 无法保存新数据 |
| Skills 目录 | 技能文件是否完整 | 部分工具不可用 |
| Cron 配置 | 定时任务配置是否有效 | 自动化任务不执行 |
7.3 常见错误与解决方案
以下是安装和使用 Hermes 过程中最常见的 15 个问题及其解决方案。
问题 1:Python 版本冲突
错误现象:
ERROR: Hermes requires Python 3.11 or higher.
Current version: 3.10.12
原因分析:
你的系统默认 Python 版本低于 3.11,或者虽然安装了 3.11 但默认调用的还是旧版本。
解决方案:
# 1. 确认 Python 3.11 已安装
python3.11 --version
# 2. 如果已安装但 hermes 调用的是旧版本,创建别名
alias hermes="python3.11 -m hermes"
# 3. 或者使用 pyenv 设置全局版本
pyenv global 3.11.9
# 4. 如果未安装,参考 2.1 节安装 Python 3.11
问题 2:Node.js 版本不对
错误现象:
WARN: Node.js v18.17.0 detected. Hermes recommends v22 or higher.
Some features may not work correctly.
解决方案:
# macOS
brew upgrade node
# Ubuntu/Debian
# 先卸载旧版本
sudo apt remove nodejs
# 然后重新安装(参考 2.2 节的 NodeSource 安装脚本)
# 或者使用 nvm 管理 Node 版本
nvm install 22
nvm use 22
nvm alias default 22
问题 3:网络连接失败 / GitHub 无法访问
错误现象:
fatal: unable to access 'https://github.com/...':
Failed to connect to github.com port 443: Connection refused
解决方案:
# 方案 1:配置终端代理
export https_proxy=http://127.0.0.1:7890
# 方案 2:配置 Git 使用代理
git config --global https.proxy http://127.0.0.1:7890
# 方案 3:使用国内镜像加速 Git 克隆
git clone https://ghproxy.com/https://github.com/NousResearch/hermes.git
# 方案 4:修改 hosts(临时方案)
# 在 /etc/hosts 中添加 GitHub 的 IP(IP 会变动,需自行查找最新 IP)
sudo sh -c 'echo "140.82.114.4 github.com" >> /etc/hosts'
问题 4:权限问题(Permission Denied)
错误现象:
PermissionError: [Errno 13] Permission denied: '/Users/username/.hermes/config.yaml'
原因分析:
~/.hermes/ 目录或其内部文件的权限不正确,可能是用 sudo 运行过 Hermes 导致文件所有者变成了 root。
解决方案:
# 修复权限(macOS / Linux)
# 将 ~/.hermes 目录的所有者改回当前用户
sudo chown -R $(whoami):$(whoami) ~/.hermes
# 修复权限位
chmod -R u+rw ~/.hermes
# 如果 hermes 命令本身权限不够
chmod +x $(which hermes)
注意
永远不要用
sudo hermes运行 Hermes! 这会导致所有数据文件的权限被改成 root,之后非 sudo 运行就会报权限错误。如果已经这样做了,用上面的chown命令修复权限。
问题 5:依赖安装失败
错误现象:
ERROR: Could not build wheels for xxx, which is required to install pyproject.toml-based projects
原因分析:
某些 Python 包需要从源码编译,而你的系统缺少编译工具或头文件。
解决方案:
# macOS
xcode-select --install
brew install gcc
# Ubuntu/Debian
sudo apt install -y build-essential python3.11-dev libffi-dev
# Fedora
sudo dnf install -y gcc python3.11-devel libffi-devel
# 然后重新安装依赖
pip install --force-reinstall hermes-agent
问题 6:API Key 配置错误(Provider error: invalid key)
错误现象:
ERROR: Authentication failed for provider 'openai'
Details: Invalid API key provided
或
Provider error: invalid key
原因分析:
根据官方文档,这是最常见的配置错误之一,通常由以下原因导致:
- API Key 有尾随空格 —— 复制 Key 时不小心带上了空格或换行符
- 选错了提供者 —— 把 OpenAI 的 Key 填到了 Anthropic 的配置里
- Key 已过期或已被撤销
- 配置文件中的格式有误
解决方案:
# 1. 检查 API Key 是否正确(特别注意是否有尾随空格!)
echo "$OPENAI_API_KEY" | cat -A
# 如果末尾有 "$" 之外的符号(如 " $"),说明有空格
# 2. 清理 Key 中的空白字符
export OPENAI_API_KEY=$(echo "$OPENAI_API_KEY" | xargs)
# 3. 确认 Key 和提供者匹配
# OpenAI 的 Key 必须以 "sk-" 开头
# Anthropic 的 Key 必须以 "sk-ant-" 开头
# DeepSeek 的 Key 格式为 "sk-xxxxxxxx"
# OpenRouter 的 Key 格式为 "sk-or-v1-xxxxxxxx"
# 4. 验证 API Key 是否有效
curl https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
# 5. 重新运行 setup 配置
hermes setup
# 6. 如果通过环境变量设置,检查环境变量是否生效
# 在 .zshrc 或 .bashrc 中添加:
export OPENAI_API_KEY="sk-your-actual-key"
# 然后运行 source ~/.zshrc 生效
注意
官方排障指南中特别指出:"key 有尾随空格" 是排名前三的安装后问题。很多用户在复制粘贴 Key 时会不小心带上空格,而空格在终端中不可见,导致验证失败。验证时一定要用
echo "$KEY" | cat -A检查末尾是否有额外字符。
问题 7:端口占用
错误现象:
ERROR: Port 8080 is already in use by another process
解决方案:
# 查找占用端口的进程
lsof -i :8080
# macOS / Linux
# 终止占用进程(将 <PID> 替换为实际的进程 ID)
kill -9 <PID>
# 或者修改 Hermes 的端口
# 编辑 ~/.hermes/config.yaml
gateway:
web_port: 8081 # 改成其他端口
问题 8:磁盘空间不足
错误现象:
WARN: Disk space is below 10%. Hermes may not function correctly.
解决方案:
# 查看磁盘使用情况
df -h
# 清理 pip 缓存
pip cache purge
# 清理 Docker 缓存(如果使用 Docker)
docker system prune -a
# 清理 Hermes 日志
rm ~/.hermes/logs/*.log
# 压缩数据库(如果数据库文件过大)
sqlite3 ~/.hermes/database/hermes.db "VACUUM;"
问题 9:数据库损坏
错误现象:
sqlite3.DatabaseError: database disk image is malformed
解决方案:
# 1. 先备份损坏的数据库
cp ~/.hermes/database/hermes.db ~/.hermes/database/hermes.db.bak
# 2. 尝试修复
sqlite3 ~/.hermes/database/hermes.db ".recover" | sqlite3 ~/.hermes/database/hermes_fixed.db
# 3. 替换原数据库
mv ~/.hermes/database/hermes_fixed.db ~/.hermes/database/hermes.db
# 4. 如果修复失败,可以从备份恢复或重置数据库
# 重置(会丢失所有历史数据):
rm ~/.hermes/database/hermes.db
hermes doctor
问题 10:Hermes 命令找不到(Command not found)
错误现象:
zsh: command not found: hermes
bash: hermes: command not found
原因分析:
官方安装脚本将 Hermes 二进制文件安装在 ~/.hermes/bin/ 目录下,并自动修改你的 shell 配置文件(~/.bashrc 或 ~/.zshrc)将其加入 PATH。但如果以下情况发生,PATH 可能未生效:
- 没有重启终端或 source 配置文件 —— shell 配置修改后需要重新加载
- 使用了非标准 shell —— 安装脚本可能未覆盖你当前使用的 shell
- PATH 被其他配置覆盖 —— 某些工具(如 conda、pyenv)可能重置了 PATH
解决方案:
# 方案 1:重新加载 shell 配置(官方推荐第一步)
source ~/.bashrc # bash 用户
source ~/.zshrc # zsh 用户
source ~/.config/fish/config.fish # fish 用户
# 方案 2:手动将 ~/.hermes/bin 加入 PATH
echo 'export PATH="$HOME/.hermes/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
# 方案 3:在当前终端中临时添加 PATH
export PATH="$HOME/.hermes/bin:$PATH"
# 方案 4:查找 hermes 安装位置
ls -la ~/.hermes/bin/hermes
# 或者
find ~ -name "hermes" -type f 2>/dev/null
# 方案 5:如果还是找不到,尝试用 Python 模块方式运行
python3 -m hermes --version
Tips
官方文档强调:新开一个终端窗口 是最简单的解决方法。安装脚本修改的是 shell 的启动配置文件,只有新启动的终端才会读取这些配置。如果你不想开新窗口,运行
source ~/.bashrc或source ~/.zshrc即可。
问题 11:Windows 上提示 "bad interpreter"(未使用 WSL2)
错误现象:
bad interpreter: /bin/sh^M: no such file or directory
或
': not a valid identifier
原因分析:
这是 Windows 用户未使用 WSL2 而直接在 Windows 命令提示符或 PowerShell 中运行安装脚本的典型错误。Hermes 的安装脚本使用 Unix 风格的行尾符(LF)和 shebang(#!/bin/sh),在 Windows 原生环境中无法正确解析。
注意
Hermes 不支持原生 Windows 环境。Windows 用户必须通过 WSL2 运行。
解决方案:
- 安装 WSL2(如果尚未安装):
# 在管理员 PowerShell 中运行
wsl --install
然后重启电脑。
- 在 WSL2 Ubuntu 中重新运行安装脚本:
# 打开 WSL2 终端(Ubuntu)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
- 确保所有后续操作都在 WSL2 环境中进行,包括运行
hermes命令、编辑配置文件等。
常见问题
Q:我安装了 Git Bash,可以在 Git Bash 中运行 Hermes 吗?
A:不可以。 Git Bash 虽然提供了一些 Unix 工具,但它仍然运行在 Windows 上,无法完全模拟 Linux 环境。Hermes 依赖的某些 Python 包和系统调用在 Git Bash 中无法正常工作。请务必使用 WSL2。
问题 12:WSL2 中文件权限混乱
错误现象:
在 WSL2 中访问 Windows 文件时,所有文件都显示为 777 权限。
解决方案:
# 在 /etc/wsl.conf 中添加配置
sudo nano /etc/wsl.conf
写入:
[automount]
enabled = true
mountFsTab = false
root = /mnt/
options = "metadata,umask=22,fmask=11"
然后重启 WSL2:
# 在 Windows PowerShell 中执行
wsl --shutdown
问题 12:Docker 容器无法访问主机文件
错误现象:
ERROR: File not found: /workspace/myfile.txt
解决方案:
# 确认挂载路径正确
# 主机路径必须写绝对路径
# 正确的做法
docker run -v /home/username/workspace:/workspace nousresearch/hermes
# 错误的做法(~ 在 Docker 中不会被展开)
docker run -v ~/workspace:/workspace nousresearch/hermes
# 如果使用 Docker Compose,确保 volumes 配置正确
Docker 挂载路径常见错误对照表:
| 错误写法 | 正确写法 | 问题说明 |
|---|---|---|
-v ~/workspace:/workspace |
-v /home/user/workspace:/workspace |
~ 不会被 shell 展开 |
-v ./data:/data |
-v $(pwd)/data:/data |
相对路径可能指向错误位置 |
-v /data:/data |
-v /home/user/data:/data |
可能挂载到系统目录而非用户目录 |
-v workspace:/workspace |
-v /home/user/workspace:/workspace |
缺少前导斜杠会被当作命名卷 |
Tips
如果不确定挂载是否生效,可以在运行容器后执行
docker inspect hermes | grep -A 10 Mounts查看实际的挂载配置。
问题 13:定时任务不执行
错误现象:
配置的 cron 任务到了设定时间没有执行。
解决方案:
# 1. 检查 cron 服务是否启用
hermes cron status
# 2. 检查 jobs.yaml 格式是否正确
hermes cron validate
# 3. 查看 cron 日志
hermes cron logs
# 4. 手动测试任务
hermes cron run daily-news-summary
# 5. 确认 Hermes 进程在后台运行(VPS 部署时)
ps aux | grep hermes
问题 14:代理配置导致国内服务访问慢
错误现象:
配置了全局代理后,访问国内 API(如 DeepSeek)反而变慢了。
解决方案:
# 配置代理排除规则(以 Clash 为例)
# 在 Clash 配置中添加:
# - DOMAIN-SUFFIX,deepseek.com,DIRECT
# - DOMAIN-SUFFIX,moonshot.cn,DIRECT
# 或者在终端只代理特定域名
export no_proxy="localhost,127.0.0.1,deepseek.com,moonshot.cn"
# 更优雅的方式:配置代理 PAC 规则
# 让浏览器/系统根据域名自动选择是否走代理
常见需要直连的国内域名:
| 服务 | 域名 | 说明 |
|---|---|---|
| DeepSeek | *.deepseek.com |
国内服务器 |
| Kimi | *.moonshot.cn |
国内服务器 |
| 智谱 | *.bigmodel.cn |
国内服务器 |
| 阿里云 | *.aliyun.com |
国内服务器 |
| 腾讯云 | *.tencentcloudapi.com |
国内服务器 |
问题 15:升级后配置不兼容
错误现象:
升级 Hermes 后启动报错,提示配置文件格式不兼容。
解决方案:
# 1. 备份当前配置
cp ~/.hermes/config.yaml ~/.hermes/config.yaml.bak
# 2. 运行配置迁移
hermes migrate
# 3. 如果迁移失败,可以重置配置并重新 setup
mv ~/.hermes/config.yaml ~/.hermes/config.yaml.old
hermes setup
# 4. 然后手动把旧配置中的 API Key 和自定义设置复制到新配置中
Tips
跨大版本升级前,建议先阅读官方的升级日志(
hermes changelog),了解是否有破坏性变更。如果有,官方通常会提供迁移脚本或详细的手动迁移步骤。Tips
遇到任何不在上述列表中的问题时,建议按以下顺序排查: 1. 运行
hermes doctor看诊断结果 2. 查看日志tail -n 100 ~/.hermes/logs/error.log3. 在 GitHub Issues 搜索类似问题 4. 在 Discord 社区求助
8. 安装后的基本配置
8.1 初次运行 Quick Setup 向导详解
安装完成后,运行以下命令启动初始配置向导:
hermes setup
向导会一步步引导你完成核心配置。下面是每个步骤的详细说明:
步骤 1:选择语言
🌍 欢迎使用 Hermes 配置向导
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请选择你的首选语言:
1. 中文 (简体)
2. English
> 1
选择后会自动配置 config.yaml 中的 language 字段。
步骤 2:选择 LLM 后端
🤖 选择默认 LLM 提供商
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请选择一个提供商作为默认后端:
1. OpenAI (GPT-4o / o1) - 功能最强,费用较高
2. Anthropic (Claude 3.5) - 推理出色,代码能力强
3. DeepSeek - 国产之光,性价比高
4. Kimi (Moonshot) - 长文本处理优秀
5. OpenRouter - 一个 Key 用多个模型
6. 本地模型 (Ollama) - 完全免费,需本地 GPU
7. 其他...
> 3
Tips
如果你是第一次使用,我强烈建议选择 OpenRouter 或 DeepSeek。OpenRouter 提供免费额度的模型(如 Google Gemini),适合零成本入门;DeepSeek 的 API 价格低到惊人(每百万 token 仅几块钱),效果却媲美 GPT-4。
步骤 3:输入 API Key
🔑 配置 API Key
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请输入你的 DeepSeek API Key:
(不会显示在屏幕上,直接粘贴后按回车)
> ******************************
✓ API Key 格式验证通过
✓ 连接测试成功
注意
API Key 不会以明文存储在配置文件中,而是通过环境变量或加密方式管理。你可以放心输入。
步骤 4:选择默认模型
🎯 选择默认模型
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
可用的 DeepSeek 模型:
1. deepseek-chat - 通用对话,推荐日常使用
2. deepseek-reasoner - 推理增强,适合复杂问题
> 1
✓ 已设置默认模型: deepseek-chat
步骤 5:配置分层模型(可选)
⚙️ 分层模型配置(省钱秘笈)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
是否启用分层模型配置?
核心逻辑用强模型,基础执行用便宜模型,可节省 50%-70% 费用。
启用? (y/n) > y
请选择推理模型(处理复杂问题):
1. deepseek-reasoner
2. deepseek-chat
> 1
请选择执行模型(处理简单任务):
1. deepseek-chat
2. deepseek-chat (轻量)
> 2
✓ 分层模型配置完成
步骤 6:完成配置
🎉 配置完成!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
你的 Hermes 已经准备就绪。接下来你可以:
• 运行 `hermes` 开始对话
• 运行 `hermes chat` 进入交互模式
• 运行 `hermes doctor` 检查系统状态
配置文件保存在: ~/.hermes/config.yaml
8.2 配置完成后的额外优化
配置向导完成后,建议进行以下几项额外优化,让你的 Hermes 体验更上一层楼:
1. 配置分层模型(强烈建议)
编辑 ~/.hermes/config.yaml,添加分层模型配置:
models:
reasoning:
provider: "deepseek"
model: "deepseek-reasoner"
execution:
provider: "deepseek"
model: "deepseek-chat"
fallback:
- provider: "openrouter"
model: "google/gemini-flash-1.5"
2. 编写基础 SOUL.md
cat > ~/.hermes/SOUL.md << 'EOF'
# SOUL.md
## 身份
你是一位专业、友好的 AI 助手。
## 说话风格
- 使用中文回答
- 简洁明了,不啰嗦
- 技术问题给出可运行的代码示例
EOF
3. 配置自动备份
mkdir -p ~/scripts
cat > ~/scripts/backup-hermes.sh << 'EOF'
#!/bin/bash
BACKUP_DIR="$HOME/hermes-backups"
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/hermes-$(date +%Y%m%d).tar.gz" -C "$HOME" .hermes/config.yaml .hermes/SOUL.md .hermes/MEMORY.md .hermes/USER.md .hermes/database .hermes/skills/custom .hermes/cron
EOF
chmod +x ~/scripts/backup-hermes.sh
4. 运行首次诊断
hermes doctor
确保所有检查项都是绿色通过。
8.3 环境变量配置
除了通过 hermes setup 配置,你也可以直接通过环境变量设置 API Keys。这在 Docker 部署和 CI/CD 环境中特别有用。
常用环境变量
# LLM API Keys
export OPENAI_API_KEY="sk-your-openai-key"
export ANTHROPIC_API_KEY="sk-your-anthropic-key"
export DEEPSEEK_API_KEY="sk-your-deepseek-key"
export OPENROUTER_API_KEY="sk-your-openrouter-key"
export MOONSHOT_API_KEY="sk-your-moonshot-key"
# Hermes 配置
export HERMES_DATA_DIR="/custom/path/to/hermes/data"
export HERMES_CONFIG_PATH="/custom/path/config.yaml"
export HERMES_LOG_LEVEL="debug"
# 代理配置
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1"
永久设置环境变量
macOS (zsh):
# 编辑 ~/.zshrc
nano ~/.zshrc
# 在文件末尾添加环境变量
export OPENAI_API_KEY="sk-your-key"
export DEEPSEEK_API_KEY="sk-your-key"
# 保存后生效
source ~/.zshrc
Linux (bash):
# 编辑 ~/.bashrc
nano ~/.bashrc
# 添加环境变量
export OPENAI_API_KEY="sk-your-key"
# 保存后生效
source ~/.bashrc
WSL (从 Windows 传递环境变量):
在 Windows 用户目录创建 .wslconfig:
[automount]
enabled = true
[interop]
enabled = true
appendWindowsPath = true
# 传递特定环境变量到 WSL
[boot]
systemd = true
或者在 WSL 的 /etc/profile.d/ 中创建脚本:
sudo nano /etc/profile.d/hermes-env.sh
写入:
export OPENAI_API_KEY="sk-your-key"
export DEEPSEEK_API_KEY="sk-your-key"
8.3 代理/镜像源配置(国内用户必看)
对于国内用户,除了前面提到的网络代理配置,还有几个重要的优化点:
pip 国内镜像源
# 清华源(推荐)
pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple
# 或阿里云源
pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/
# 验证
pip config get global.index-url
npm 国内镜像源
# 淘宝源(已更新域名)
npm config set registry https://registry.npmmirror.com
# 验证
npm config get registry
GitHub 加速
# 方式 1:使用 ghproxy 镜像
git clone https://ghproxy.com/https://github.com/owner/repo.git
# 方式 2:配置 Git 使用代理
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
# 方式 3:使用 SSH 协议(通常比 HTTPS 更稳定)
git clone git@github.com:owner/repo.git
LLM API 国内直连优化
| 提供商 | 国内访问情况 | 优化建议 |
|---|---|---|
| OpenAI | 需代理 | 配置代理或使用中转 API |
| Anthropic | 需代理 | 配置代理 |
| DeepSeek | 直连流畅 | 无需代理 |
| Kimi | 直连流畅 | 无需代理 |
| OpenRouter | 部分需代理 | 配置代理 |
| 阿里云百炼 | 直连流畅 | 无需代理 |
Tips
建议国内用户优先使用 DeepSeek 和 Kimi 作为主力模型,这两个平台的 API 服务器在国内,访问速度快且稳定。OpenAI 和 Anthropic 可以通过代理或中转服务访问,OpenRouter 则提供了「一个 Key 用多个模型」的便利。
8.4 性能调优与资源限制
Hermes 默认配置适用于大多数场景,但在资源受限的环境(如低配 VPS 或旧电脑)中,适当调优可以显著提升体验。
数据库性能优化
# 定期压缩数据库(清理已删除数据占用的空间)
sqlite3 ~/.hermes/database/hermes.db "VACUUM;"
# 添加数据库索引(如果查询变慢)
sqlite3 ~/.hermes/database/hermes.db "CREATE INDEX IF NOT EXISTS idx_sessions_created ON sessions(created_at);"
# 查看数据库大小
ls -lh ~/.hermes/database/hermes.db
建议每月执行一次 VACUUM,就像给数据库「瘦身」。
内存使用控制
如果你的系统内存紧张,可以通过环境变量限制 Hermes 的内存占用:
# 启动 Hermes 时限制最大内存为 512MB
ulimit -v 524288 && hermes
# 或者在 systemd 服务中添加限制
# 在 hermes.service 的 [Service] 段添加:
# MemoryMax=512M
# MemorySwapMax=0
并发任务限制
在 config.yaml 中限制同时运行的任务数:
core:
max_concurrent_tasks: 3 # 默认可能是 5,低配机器可改为 2-3
request_timeout: 30 # API 请求超时时间(秒)
Tips
性能调优的核心思路是「量力而行」。一台 1 核 1G 的 VPS 就不要指望同时跑 5 个任务,把并发限制在 2 以内,给系统留足喘息空间。Hermes 是 Agent,不是赛车——稳定运行比极速响应更重要。
9. 卸载与重装
9.1 完整卸载步骤
如果你需要卸载 Hermes,请按以下步骤操作。这就像「搬家」——先打包重要物品,再清空房子,最后检查有没有落下东西。
步骤 1:备份数据(强烈建议)
# 创建备份目录
mkdir -p ~/hermes-backup-$(date +%Y%m%d)
# 备份核心数据
cp -r ~/.hermes/config.yaml ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/SOUL.md ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/MEMORY.md ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/USER.md ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/database ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/skills/custom ~/hermes-backup-$(date +%Y%m%d)/
cp -r ~/.hermes/cron ~/hermes-backup-$(date +%Y%m%d)/
echo "备份完成,保存在: ~/hermes-backup-$(date +%Y%m%d)/"
注意
卸载前务必备份!很多用户在卸载后才发现某个配置文件或一段对话历史很重要,但为时已晚。备份只占用几 MB 空间,却能避免不可挽回的损失。
步骤 2:卸载 Hermes 包
# 卸载 Python 包
pip uninstall hermes-agent -y
# 或者如果你使用 pipx 安装
pipx uninstall hermes-agent
# 或者如果你从源码安装
cd ~/hermes
pip uninstall -e .
步骤 3:删除数据目录
# 删除 Hermes 数据目录
rm -rf ~/.hermes
# 从 PATH 中移除 ~/.hermes/bin
# 编辑 ~/.zshrc 或 ~/.bashrc,删除以下行:
# export PATH="$HOME/.hermes/bin:$PATH"
nano ~/.zshrc
# 删除环境变量(从 ~/.zshrc 或 ~/.bashrc 中删除相关行)
# 手动删除 export HERMES_... 和 export OPENAI_API_KEY 等行
步骤 4:清理残留
# 查找并删除残留的 hermes 相关文件
find ~ -name "*hermes*" -type f 2>/dev/null
find ~ -name "*hermes*" -type d 2>/dev/null
# 清理 pip 缓存
pip cache purge
# 如果使用了 systemd 服务,删除服务文件
sudo rm -f /etc/systemd/system/hermes.service
sudo systemctl daemon-reload
# 如果使用了 Docker,删除镜像和容器
docker stop hermes 2>/dev/null
docker rm hermes 2>/dev/null
docker rmi nousresearch/hermes:latest 2>/dev/null
9.2 数据备份与恢复
自动备份脚本
创建一个每天自动备份的脚本:
# 创建备份脚本
mkdir -p ~/scripts
cat > ~/scripts/backup-hermes.sh << 'EOF'
#!/bin/bash
# Hermes 自动备份脚本
BACKUP_DIR="$HOME/hermes-backups"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_NAME="hermes-backup-$DATE"
# 创建备份目录
mkdir -p "$BACKUP_DIR"
# 执行备份
tar -czf "$BACKUP_DIR/$BACKUP_NAME.tar.gz" \
-C "$HOME" \
.hermes/config.yaml \
.hermes/SOUL.md \
.hermes/MEMORY.md \
.hermes/USER.md \
.hermes/database \
.hermes/skills/custom \
.hermes/cron
# 保留最近 30 天的备份,删除旧备份
find "$BACKUP_DIR" -name "hermes-backup-*.tar.gz" -mtime +30 -delete
echo "备份完成: $BACKUP_DIR/$BACKUP_NAME.tar.gz"
EOF
chmod +x ~/scripts/backup-hermes.sh
# 添加到 crontab(每天凌晨 3 点自动备份)
(crontab -l 2>/dev/null; echo "0 3 * * * $HOME/scripts/backup-hermes.sh") | crontab -
恢复备份
# 解压备份文件
tar -xzf ~/hermes-backups/hermes-backup-20260415_030000.tar.gz -C ~/
# 确保权限正确
chmod -R u+rw ~/.hermes
# 运行诊断
hermes doctor
9.3 版本升级方法
通过 pip 升级
# 升级到最新版本
pip install --upgrade hermes-agent
# 升级到特定版本
pip install hermes-agent==1.3.0
通过 Git 升级(如果从源码安装)
cd ~/hermes
git pull origin main
pip install -e . --upgrade
通过 Docker 升级
# 拉取最新镜像
docker pull nousresearch/hermes:latest
# 停止并删除旧容器
docker stop hermes
docker rm hermes
# 用新镜像启动容器
docker run -d \
--name hermes \
-v ~/.hermes:/opt/data \
-e OPENAI_API_KEY="$OPENAI_API_KEY" \
nousresearch/hermes:latest
升级前检查
# 1. 备份当前配置和数据
~/scripts/backup-hermes.sh
# 2. 查看当前版本
hermes --version
# 3. 查看新版本更新日志
pip index versions hermes-agent
# 4. 升级后运行诊断
hermes doctor
# 5. 如有配置迁移提示,执行迁移
hermes migrate
版本升级的最佳实践:
1. 先读更新日志
每次升级前,先查看更新日志了解新版本的变更:
hermes changelog
重点关注: - 是否有破坏性变更(Breaking Changes) - 是否有配置格式变化 - 是否有新的依赖要求
2. 在测试环境先升级
如果你在生产环境使用 Hermes,建议先在本地或测试 VPS 上升级,确认没有问题后再升级生产环境。
# 本地测试升级
pip install --upgrade hermes-agent --user
hermes doctor
3. 保留回滚方案
升级前备份整个 ~/.hermes/ 目录,如果升级后出现问题,可以快速回滚:
# 回滚到上一版本
pip install hermes-agent==$(cat ~/.hermes/version.bak)
# 恢复配置
cp ~/.hermes/config.yaml.bak ~/.hermes/config.yaml
注意
跨大版本升级时(如从 v1.x 到 v2.x),请务必先阅读官方的升级指南。大版本升级可能会引入不兼容的配置变更,需要手动调整。
本章小结
恭喜!你已经完成了 Hermes Agent 安装部署的完整学习。让我们回顾一下本章的核心要点:
-
安装前准备 至关重要。检查清单上的每一项,确保 Python 3.11+、Node.js v22+、Git 等前置软件已就绪,网络环境畅通。
-
四种部署方式 各有适用场景:
- 本地常规部署:新手入门首选,零额外成本
- Docker 部署:环境隔离,便于迁移和多版本管理
- VPS 部署:24/7 运行,支持远程访问和团队协作
-
无服务器部署:按需计费,适合间歇性任务
-
~/.hermes/目录 是 Hermes 的「家」。config.yaml是中枢神经,SOUL.md定义 Agent 的灵魂,MEMORY.md存储全局记忆,database/保存所有历史数据。 -
hermes doctor是最好的排障工具。遇到问题时先运行它,80% 的问题都能直接定位。 -
数据备份 不可忽视。设置自动备份脚本,定期将核心数据备份到安全位置。
Tips
如果你在安装过程中遇到了本章未覆盖的问题,建议: 1. 先运行
hermes doctor查看诊断 2. 检查~/.hermes/logs/error.log获取详细错误信息 3. 在 GitHub Issues 中搜索类似问题 4. 加入 Hermes Discord 社区寻求帮助
现在,你的 Hermes 应该已经顺利运行起来了。下一章,我们将进入「基础使用入门」,学习如何与你的 Agent 进行第一次对话、掌握常用命令、接入各种大模型,以及配置分层模型来节省费用。让我们继续「养马之旅」!
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第六册:基础使用入门 —— 从零开始,掌握 Hermes 的日常操作
本章你将学到:
- 如何完成 Hermes 的首次配置,选择最适合你的大语言模型
- 对话模式的各种技巧,让你的 Agent 真正「懂你」
- Hermes 所有常用命令的详细用法和参数说明
- 斜杠命令系统的完整指南,像用 Slack 一样高效操控 Agent
- 如何接入 20+ LLM 提供商,以及分层模型配置的省钱秘笈
- SOUL.md 人设配置的编写方法,打造独一无二的 Agent 人格
- 三个完整的实战练习,让你立刻上手
- 新手常见误区与最佳实践,少走弯路
注意
本章假设你已经按照第五册的指引成功安装并部署了 Hermes。如果还没有完成安装,请先回到第五册完成部署。
1. 首次运行:Quick Setup 向导
1.1 启动 hermes 命令
安装完成后,在终端输入:
hermes
如果这是你的第一次运行,Hermes 会自动启动 Quick Setup 向导。这个向导就像是新手机的「开机设置」,会引导你完成最核心的几项配置。
Tips
你也可以随时通过
hermes setup命令重新运行配置向导。比如你换了新的 API Key,或者想切换默认模型,都可以用这个命令重新配置。
向导启动前的准备:
在运行 hermes setup 之前,建议先准备好以下信息,这样配置过程会更加顺畅:
- 已决定使用的 LLM 提供商 —— 如果不确定,先选 DeepSeek 或 OpenRouter
- 对应提供商的 API Key —— 提前注册并复制好 Key
- Agent 的名称 —— 给你的 Agent 起个名字(如「小墨」「码匠」等)
- 期望的对话语言 —— 中文、英文或其他语言
准备这些只需要 5 分钟,但能让你在向导中一气呵成地完成配置,而不是中途暂停去注册账号。
1.2 向导每一步的详细说明
步骤 1:欢迎界面
╔══════════════════════════════════════════╗
║ 欢迎使用 Hermes Agent Quick Setup 向导 ║
╚══════════════════════════════════════════╝
Hermes 是 Nous Research 开发的开源 AI Agent 框架。
接下来我们将完成几项基础配置,整个过程约需 3-5 分钟。
按 Enter 继续...
步骤 2:选择界面语言
🌍 选择界面语言 / Choose your language
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 中文 (简体)
2. English
> 1
选择后,Hermes 的提示信息将以中文显示。这不会影响 Agent 的对话语言——对话语言可以在 SOUL.md 中配置。
注意
界面语言和对话语言是两个独立的设置。界面语言决定 Hermes CLI 的菜单、提示和错误信息的显示语言;对话语言决定你的 Agent 在回复时使用的语言。你可以在 SOUL.md 中设置对话语言,比如让 Hermes 用中文回答,即使界面语言是英文。
步骤 3:选择 LLM 后端
这是整个配置过程中最重要的一步。你选择的 LLM 后端将直接影响 Hermes 的「智商」和运行成本。
🤖 选择默认 LLM 提供商
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请选择一个提供商作为默认后端:
1. Nous Portal - 官方统一订阅,一个月费全包 ⭐推荐
2. OpenAI (GPT-5) - 业界标杆,功能最强,费用较高 $$$
3. Anthropic (Claude) - 推理和代码能力出色 $$$
4. DeepSeek - 国产之光,性价比极高 $
5. Kimi (Moonshot) - 长文本处理优秀 $$
6. OpenRouter - 一 Key 多用,免费额度友好
7. GLM-5 (智谱) - 国产模型,中文理解强 $
8. MiniMax M2.7 - 国产模型,性价比高 $$
9. 本地模型 (Ollama) - 完全免费,需本地 GPU
10. 其他...
> 4
模型选择策略详解
面对这么多选项,新手可能会感到眼花缭乱。下面我来帮你梳理选择思路。
按预算选择:
| 预算 | 推荐方案 | 月费预估 |
|---|---|---|
| ¥0(纯免费) | OpenRouter 免费模型 + Ollama 本地模型 | ¥0 |
| ¥0-50 | DeepSeek + GLM-5 | ¥10-30 |
| ¥50-200 | DeepSeek 主力 + Nous Portal / OpenRouter 补充 | ¥50-100 |
| ¥200+ | GPT-5 / Claude Sonnet 主力 + 分层模型 | ¥200-500 |
注意
官方社区共识:生产环境用前沿模型(Claude Sonnet/Opus、GPT-5),本地模型仅供实验和轻度使用。 Ollama + Qwen 2.5 Coder 32B 可以处理约 80% 的日常 CLI 使用场景,但在复杂推理、长上下文理解和代码生成质量上,仍然无法与 Claude 3.5 Sonnet 或 GPT-5 等前沿模型相比。
各模型特点速览:
| 模型 | 费用等级 | 最强项 | 弱项 | 适合场景 |
|---|---|---|---|---|
| Claude 3.5 Sonnet/Opus | $$$ | 推理、代码、安全性 | 价格 | 复杂编程、安全关键任务 |
| GPT-5 | $$$ | 通用能力、多模态 | 价格 | 全能型任务、创意写作 |
| DeepSeek | $ | 性价比、中文、数学 | 创意写作 | 日常对话、代码辅助、中文场景 |
| GLM-5 | $ | 中文理解、工具调用 | 英文长文本 | 中文内容创作、客服 |
| MiniMax M2.7 | $$ | 对话流畅度、语音 | 复杂推理 | 闲聊、语音交互场景 |
| Kimi | $$ | 超长上下文(200K+) | 价格略高 | 长文档分析、论文阅读 |
| Qwen 2.5 Coder 32B (本地) | 免费 | 代码、中文 | 硬件要求、通用推理 | 本地开发、隐私敏感场景 |
新手推荐方案(按优先级排序):
- 首选:DeepSeek
- 为什么:API 价格低到惊人(每百万输入 token 仅需约 2 元),效果媲美 GPT-4,国内访问速度快
-
适合:绝大多数日常场景
-
次选:OpenRouter
- 为什么:一个 Key 可以用 Google Gemini、Mistral、Anthropic 等多个模型,有免费额度
-
适合:想先免费体验,再决定是否付费的用户
-
进阶:Nous Portal
- 为什么:Nous Research 官方推出的统一订阅服务,一个月费涵盖所有接入模型,省去分别管理各平台 Key 的麻烦
- 适合:需要频繁切换模型、追求便利性的用户
Tips
如果你现在还没有任何 API Key,我建议先去 DeepSeek 官网(platform.deepseek.com)注册一个账号,新用户通常有免费额度赠送。或者去 OpenRouter(openrouter.ai)注册,它提供部分模型的免费额度,零成本就能开始体验。
各模型详细能力对比:
为了帮你更直观地理解不同模型的差异,下面是官方社区整理的各模型在实际任务中的表现评分(满分 5 分):
| 能力维度 | Claude 3.5 Sonnet | GPT-5 | DeepSeek | GLM-5 | Kimi | Qwen 2.5 Coder 32B |
|---|---|---|---|---|---|---|
| 代码生成 | 5.0 | 4.8 | 4.3 | 3.8 | 3.5 | 4.5 |
| 代码审查 | 5.0 | 4.7 | 4.0 | 3.5 | 3.5 | 4.2 |
| 中文理解 | 4.0 | 4.2 | 4.8 | 4.9 | 4.7 | 4.6 |
| 数学推理 | 4.8 | 4.9 | 4.5 | 4.0 | 4.2 | 3.8 |
| 创意写作 | 4.5 | 4.8 | 4.2 | 4.3 | 4.0 | 3.5 |
| 长文本处理 | 4.5 | 4.6 | 4.0 | 4.0 | 5.0 | 3.5 |
| 工具调用 | 4.8 | 4.7 | 4.5 | 4.6 | 4.0 | 3.0 |
| 响应速度 | 4.0 | 4.2 | 4.8 | 4.7 | 4.5 | 3.0* |
*本地模型速度取决于你的硬件配置。
从表格中可以清晰地看到:
- Claude 3.5 Sonnet 是全能的编程之王,在代码相关任务上几乎无可匹敌。如果你主要用 Hermes 来辅助编程,它就是你的首选。
- GPT-5 是最均衡的六边形战士,几乎没有明显短板,适合作为主力模型处理各种复杂任务。
- DeepSeek 在中文理解和性价比上独占鳌头,是中文用户的「国民模型」。
- Kimi 的长文本处理能力一枝独秀,如果你需要分析整本书、长篇论文或大量会议纪要,它是唯一的选择。
- Qwen 2.5 Coder 32B 作为本地模型,在代码任务上已经达到了商业模型 85% 的水平,对于不想把代码发送到云端的开发者来说,是非常实用的选择。
注意
上面的评分基于 2026 年第一季度的社区评测数据。大模型的发展速度非常快,三个月后的排名可能会有变化。建议定期关注 Hermes 社区和 LMSYS Chatbot Arena 的排行榜更新。
步骤 4:获取和输入 API Key
根据你选择的提供商,向导会要求你输入 API Key。下面是最常用平台的获取教程:
DeepSeek API Key 获取:
- 访问 https://platform.deepseek.com/
- 点击右上角「登录」,用手机号或邮箱注册
- 登录后进入「API Keys」页面
- 点击「创建 API Key」
- 复制生成的 Key(以
sk-开头)
🔑 输入 DeepSeek API Key
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
请粘贴你的 API Key(不会显示在屏幕上):
> ******************************
✓ 格式验证通过
✓ 连接测试成功
✓ 余额查询: ¥15.00(赠金)
注意
粘贴 API Key 时请务必检查是否有尾随空格!这是官方排障指南中排名前三的问题。你可以在粘贴后按
Ctrl+A(全选)查看是否有额外空格。如果不确定,可以先粘贴到文本编辑器中检查,确认无误后再复制到终端。
OpenRouter API Key 获取:
- 访问 https://openrouter.ai/
- 用 GitHub 或 Google 账号登录
- 进入 Settings > Keys
- 点击「Create Key」
- 复制 Key(以
sk-or-v1-开头)
Tips
OpenRouter 的优势在于「一 Key 多用」。你只用这一个 Key,就可以调用 Google Gemini、Mistral、Anthropic Claude、Meta Llama 等数十个模型的 API。而且它提供部分模型的免费额度(虽然速率有限制),非常适合入门体验。
Nous Portal 订阅:
- 访问 https://portal.nousresearch.com/
- 注册账号并选择订阅计划
- 订阅后系统会生成一个统一 API Key
- 用这个 Key 即可访问 Portal 上所有接入的模型
Ollama 本地模型配置:
如果你选择本地模型,不需要 API Key,但需要先安装 Ollama 并下载模型:
# 安装 Ollama
brew install ollama # macOS
# 或访问 https://ollama.com/download 下载安装包
# 下载 Qwen 2.5 Coder 32B(推荐)
ollama pull qwen2.5-coder:32b
# 验证模型可用
ollama list
然后在 Hermes 配置中选择:
本地模型提供者: ollama
模型名称: qwen2.5-coder:32b
注意
Qwen 2.5 Coder 32B 需要约 20GB 显存(或同等内存)。如果你的电脑没有独立显卡,运行速度会很慢。对于没有 GPU 的 Mac 用户,可以使用 7B 或 14B 版本,但效果会打折扣。
步骤 5:选择默认模型
🎯 选择默认模型
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
可用的 DeepSeek 模型:
1. deepseek-chat - 通用对话,速度快,推荐日常使用
2. deepseek-reasoner - 推理增强,适合复杂问题和代码
> 1
✓ 已设置默认模型: deepseek-chat
Tips
如果你不确定选哪个,建议先选择通用对话模型(如 deepseek-chat、gpt-4o、claude-3.5-sonnet)。通用模型在大多数场景下表现都不错,等使用一段时间了解了各模型的特点后,再在 config.yaml 中配置分层模型。
步骤 6:配置完成
🎉 配置完成!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
你的 Hermes 已经准备就绪!
配置摘要:
• 语言: 中文
• 提供商: DeepSeek
• 默认模型: deepseek-chat
• 数据目录: ~/.hermes/
接下来你可以:
运行 `hermes` → 开始新对话
运行 `hermes chat` → 进入交互式聊天
运行 `hermes doctor` → 检查系统状态
运行 `hermes --help` → 查看所有命令
按 Enter 退出向导...
1.3 配置完成后的验证测试
配置完成后,建议运行以下测试命令来确认一切正常:
# 1. 版本检查
hermes --version
# 2. 系统诊断(所有检查项应为绿色通过)
hermes doctor
# 3. 开始第一次对话
hermes
第一次对话时,试着问一个简单的问题:
> 你好,请简单介绍一下你自己
如果 Hermes 能正常回复,说明配置完全成功!
首次对话测试清单:
- [ ] Hermes 能正常启动并显示欢迎信息
- [ ] 输入消息后能收到回复(不是错误或超时)
- [ ] 回复内容合理、通顺
- [ ] 尝试让 Hermes 读取一个本地文件(如
cat ~/.hermes/config.yaml) - [ ] 尝试让 Hermes 执行一个简单的 shell 命令(如
ls -la) - [ ] 尝试使用
/model切换模型 - [ ] 尝试使用
/memory添加一条记忆 - [ ] 输入
exit能正常退出
如果以上所有测试都通过,恭喜你,你的 Hermes 已经完全就绪,可以开始日常使用了!
常见问题
Q:第一次对话时 Hermes 回复很慢,甚至超时,怎么办?
A:这通常是网络问题或模型 API 响应慢导致的。解决方法: 1. 检查网络连接:
ping google.com2. 测试 API 连通性:hermes doctor --models3. 如果是国内用户访问海外 API,检查代理是否生效 4. 尝试切换到响应更快的模型(如 DeepSeek) 5. 如果使用的是本地模型,检查 Ollama 是否在运行:ollama list
2. 对话模式详解
2.1 基本对话入门
运行 hermes 命令后,你会进入一个交互式对话界面:
$ hermes
╔══════════════════════════════════════════╗
║ Hermes Agent v1.2.3 ║
║ Model: deepseek-chat ║
╚══════════════════════════════════════════╝
输入消息开始对话,输入 /help 查看可用命令,输入 exit 退出。
You:
此时光标停留在 You: 后面,你可以直接输入问题,按回车发送。
示例对话:
You: 你好,请问你能帮我做什么?
Hermes: 你好!我是你的 AI 助手,可以帮助你完成以下任务:
• 💬 **对话问答** —— 回答各类知识性问题
• 💻 **编程辅助** —— 写代码、Debug、代码审查
• 📝 **内容创作** —— 写文章、邮件、报告
• 🔍 **信息检索** —— 搜索网页、分析文档
• 📁 **文件管理** —— 读写文件、整理资料
• ⚡ **自动化任务** —— 执行脚本、定时任务
直接告诉我你需要什么帮助吧!
You:
Tips
在对话中,你可以随时输入
/help查看所有可用的斜杠命令,或者输入exit或按Ctrl+D退出对话。
2.2 多轮对话的上下文管理
Hermes 会自动维护对话的上下文。这意味着你可以像和朋友聊天一样,进行多轮对话,而不需要每次都重复背景信息。
上下文示例:
You: 我正在做一个 Python 项目,需要处理 CSV 文件
Hermes: 好的,处理 CSV 文件在 Python 中有很多方式。你可以使用...
You: 数据量比较大,有 100 万行,哪种方式最快?
Hermes: 对于 100 万行的大数据集,推荐使用 pandas 的...
注意第二轮对话中,你不需要再提「Python」和「CSV」,Hermes 已经记住了上下文。
上下文管理的进阶技巧:
技巧 1:主动重置上下文
当你想切换到全新话题时,可以使用 /clear 命令清除当前上下文。这就像是把黑板擦干净,准备写新的内容。
You: /clear
✓ 上下文已清除。
You: 现在我们来讨论一个完全不同的主题...
技巧 2:利用上下文延续复杂任务
对于需要多步骤完成的任务,上下文让对话变得异常流畅:
You: 帮我写一个 Flask 博客的后端 API
Hermes: [给出完整的 Flask API 代码]
You: 好的,现在帮我写对应的前端页面,用 Vue.js
Hermes: [基于刚才的 API 设计,给出 Vue.js 前端代码]
You: 最后帮我写个 Docker 配置,把前后端一起打包
Hermes: [给出 Dockerfile 和 docker-compose.yml]
技巧 3:在上下文中修正错误
如果 Hermes 的某一步回答有误,你不需要从头开始,直接指出错误即可:
You: 帮我写一个计算阶乘的函数
Hermes: [给出了递归实现]
You: 这个递归实现对于大数会栈溢出,改成迭代版本
Hermes: [给出迭代实现]
注意
上下文不是无限存储的!默认情况下,Hermes 会保留最近 50 条对话记录。当对话很长时,早期的消息可能会被自动丢弃。如果需要保留重要信息,可以: 1. 使用
/memory命令让 Hermes 记住关键信息 2. 使用/compact压缩上下文(详见第 4 章) 3. 重要的配置和背景信息写入 SOUL.md 或 MEMORY.md 4. 对于特别长的任务,可以分段进行,每完成一段用/memory保存关键结论
2.3 对话中使用工具
Hermes 最强大的功能之一就是工具调用。在对话过程中,当你提出的需求需要外部工具时,Hermes 会自动调用相应的工具来完成任务。
示例 1:文件操作
You: 帮我读取 ~/.hermes/config.yaml 的内容
Hermes: 我来帮你读取这个配置文件。
[工具调用: file_read]
路径: ~/.hermes/config.yaml
配置文件内容如下:
---
core:
name: "Hermes"
default_provider: "deepseek"
...
示例 2:网页搜索
You: 搜索一下 Hermes Agent 的最新版本信息
Hermes: 让我搜索一下最新信息。
[工具调用: web_search]
查询: Hermes Agent latest version 2026
根据搜索结果,Hermes Agent 的最新版本是 v1.2.3,发布于...
示例 3:执行代码
You: 帮我计算 1 到 100 的平方和
Hermes: 我来写一段 Python 代码计算。
[工具调用: execute_python]
代码:
result = sum(i**2 for i in range(1, 101))
print(result)
执行结果:
338350
Tips
工具调用是 Hermes 与普通聊天机器人的核心区别。普通 AI 只能「纸上谈兵」,而 Hermes 可以真正「动手做事」——读取你的文件、搜索网页、执行代码、发送消息等。当你需要它做实际任务时,明确告诉它「帮我执行...」「帮我搜索...」,它会自动选择合适的工具。
2.4 对话中的高效提问技巧
和 Hermes 对话,就像和一位聪明的助手交流。提问的方式直接决定了回答的质量。以下是几个让 Hermes 回答更好的提问技巧:
技巧 1:明确任务类型
❌ 不好的提问:「帮我看看这个」 ✅ 好的提问:「帮我审查这段 Python 代码的安全性,特别关注 SQL 注入和 XSS 漏洞」
技巧 2:提供足够的上下文
❌ 不好的提问:「为什么报错?」
✅ 好的提问:「我在运行 python main.py 时遇到以下错误:
Traceback (most recent call last):
File "main.py", line 42, in <module>
result = fetch_data(user_input)
TypeError: expected str, got int
fetch_data 函数的代码如下:...」
技巧 3:指定输出格式
❌ 不好的提问:「总结一下」 ✅ 好的提问:「请用 bullet points 总结以下文章的核心观点,每条不超过 20 个字,并标注每条的重要性(高/中/低)」
技巧 4:分步骤提问复杂问题
对于复杂任务,不要一次性抛出所有需求。先让 Hermes 理解整体目标,再逐步细化:
You: 我想做一个个人博客网站,用什么技术栈比较好?
Hermes: [给出技术栈建议]
You: 好,我决定用 Next.js + Tailwind。帮我设计一下数据库表结构,
需要支持文章、标签、评论三个功能。
Hermes: [给出数据库设计]
You: 很好。现在帮我写用户认证模块的代码,要求支持邮箱+密码和 GitHub OAuth。
技巧 5:利用角色设定
在 SOUL.md 中定义好角色后,你可以直接要求它按角色视角回答:
You: 以你的投研分析师身份,评估一下这个加密货币项目的风险
Tips
好的提问 = 明确的任务 + 足够的上下文 + 期望的输出格式。把这三点做到位,Hermes 的回答质量会提升一个档次。记住,Agent 再聪明,也无法读取你的心思——你提供的信息越完整,它给你的答案就越精准。
2.5 对话历史的存储与检索
Hermes 会自动保存所有对话历史到数据库中。你可以随时查看和检索过去的对话。
# 列出最近的会话
hermes chat list
# 查看某个会话的详细内容
hermes chat show <session_id>
# 搜索历史对话中的内容
hermes chat search "Python CSV"
# 导出某个会话为 Markdown 文件
hermes chat export <session_id> --format md --output ~/chat-history.md
注意
对话历史默认存储在
~/.hermes/database/hermes.db中。这个 SQLite 数据库文件包含了你的所有聊天记录。如果你担心隐私问题,可以定期清理历史,或者将敏感对话设置为不保存(在对话开始时输入/private进入隐私模式)。
2.5 退出与恢复对话
退出当前对话:
You: exit
对话已保存。会话 ID: 2026-04-21-abc123
再见!
恢复上次的对话:
# 方式 1:直接运行 hermes,会自动恢复上次会话
hermes
# 方式 2:指定会话 ID 恢复
hermes chat resume 2026-04-21-abc123
# 方式 3:从列表中选择
hermes chat list
hermes chat resume <session_id>
Tips
Hermes 支持同时维护多个对话会话。比如你可以有一个「工作会话」处理项目代码,一个「学习会话」讨论技术书籍,一个「生活会话」安排日程。通过不同的会话 ID,你可以随时在不同的话题之间切换。
3. 常用命令速查大全
Hermes 提供了丰富的 CLI 命令。掌握这些命令,你就能像老司机一样熟练操控你的 Agent。
3.1 hermes(开启对话)
hermes 是最常用的命令,用于启动交互式对话。它就像打开微信聊天窗口一样简单。
# 基础用法 —— 启动交互式对话
hermes
# 带初始提示启动(适合一次性任务)
hermes -c "帮我写一个 Python 爬虫"
# 使用特定模型启动(覆盖默认配置)
hermes --model deepseek-reasoner
# 使用特定 provider 启动
hermes --provider openrouter --model anthropic/claude-3.5-sonnet
# 不加载历史会话,全新开始
hermes --fresh
# 进入隐私模式(不保存对话历史)
hermes --private
# 指定工作目录(Agent 以此目录为上下文)
hermes --workspace ~/my-project
# 组合使用多个参数
hermes --model claude-3.5-sonnet --workspace ~/project --private
使用场景示例:
| 场景 | 推荐命令 | 说明 |
|---|---|---|
| 日常闲聊/问答 | hermes |
默认启动,自动恢复上次会话 |
| 临时任务 | hermes -c "任务描述" |
执行完自动退出 |
| 代码审查 | hermes --workspace . |
以当前项目为上下文 |
| 私密对话 | hermes --private |
不保存到数据库 |
| 切换模型测试 | hermes --model gpt-5 |
临时用其他模型 |
| 全新话题 | hermes --fresh |
不携带历史上下文 |
3.2 hermes chat 相关命令
# 列出所有会话
hermes chat list
# 显示会话详情
hermes chat show <session_id>
# 恢复会话
hermes chat resume <session_id>
# 删除会话
hermes chat delete <session_id>
# 搜索会话内容
hermes chat search "关键词"
# 导出会话
hermes chat export <session_id> --format md --output ~/export.md
hermes chat export <session_id> --format json --output ~/export.json
# 清理旧会话
hermes chat cleanup --older-than 30d # 删除 30 天前的会话
3.3 hermes model(模型管理)
# 列出所有已配置的模型
hermes model list
# 查看当前使用的模型
hermes model current
# 切换默认模型
hermes model use deepseek-reasoner
# 测试模型连接
hermes model test openai gpt-5
# 添加新模型配置
hermes model add --provider openrouter --model google/gemini-2.5-pro
# 查看模型费用信息
hermes model pricing
# 查看模型性能基准测试
hermes model benchmark
Tips
hermes model benchmark是一个非常实用的命令。它会向所有已配置的模型发送相同的测试问题,然后对比各模型的响应速度、输出质量和 token 消耗。用这个命令,你可以直观地找到最适合你需求的「性价比之王」。
3.4 hermes tools(工具配置)
# 列出所有可用工具
hermes tools list
# 查看工具详情
hermes tools show web_search
# 启用工具
hermes tools enable github
# 禁用工具(临时,下次启动恢复)
hermes tools disable execute_shell
# 永久禁用工具(写入配置)
hermes tools disable execute_shell --permanent
# 测试工具
hermes tools test web_search --query "Hermes Agent"
3.5 hermes gateway(消息网关)
# 启动 Web 界面
gateway start
# 查看网关状态
hermes gateway status
# 配置 Telegram 机器人
hermes gateway config telegram --token "你的BotToken"
# 配置 Discord 机器人
hermes gateway config discord --token "你的DiscordToken"
# 查看所有平台配置
hermes gateway list
# 停止网关
hermes gateway stop
注意
配置 Telegram 机器人时,安全设置中的「允许列表」需要填写数字用户 ID,不是用户名(@handle)!你可以通过 @userinfobot 获取自己的数字 ID。这是官方文档中特别强调的安全提醒,填写错误的格式会导致消息接收失败。
3.6 hermes setup(重新配置)
# 重新运行配置向导
hermes setup
# 仅重新配置模型
hermes setup --models-only
# 仅重新配置 API Keys
hermes setup --keys-only
# 重置为默认配置(谨慎使用!)
hermes setup --reset
3.7 hermes doctor(系统诊断)
# 运行完整诊断
hermes doctor
# 仅检查环境
hermes doctor --env
# 仅检查配置
hermes doctor --config
# 仅检查模型连接
hermes doctor --models
# 修复可自动修复的问题
hermes doctor --fix
3.8 hermes status(状态查看)
# 查看系统状态
hermes status
# 查看资源使用情况
hermes status --resources
# 查看当前会话信息
hermes status --session
# 查看已加载的技能
hermes status --skills
3.9 hermes migrate(数据迁移)
# 检查是否需要迁移
hermes migrate --check
# 执行数据迁移
hermes migrate
# 从旧版本备份恢复
hermes migrate --from-backup ~/hermes-backup-20260415/
3.10 hermes skills(技能管理)
# 列出所有技能
hermes skills list
# 查看技能详情
hermes skills show web_search
# 启用技能
hermes skills enable my_custom_skill
# 禁用技能
hermes skills disable my_custom_skill
# 从 Skills Hub 安装技能
hermes skills install nousresearch/stock-analysis
# 更新所有技能
hermes skills update
# 创建新技能模板
hermes skills create my-new-skill
3.11 hermes cron(定时任务)
# 列出所有定时任务
hermes cron list
# 查看任务状态
hermes cron status
# 验证任务配置
hermes cron validate
# 手动运行某个任务
hermes cron run daily-news-summary
# 查看任务日志
hermes cron logs
# 启用/禁用任务
hermes cron enable daily-news-summary
hermes cron disable daily-news-summary
3.12 其他常用命令
# 查看版本信息
hermes --version
hermes --version --verbose
# 查看帮助
hermes --help
hermes chat --help
hermes model --help
# 查看配置
hermes config show
# 编辑配置
hermes config edit
# 验证配置格式
hermes config validate
# 清理缓存
hermes cache clear
# 更新 Hermes 本身
hermes update
# 查看更新日志
hermes changelog
命令组合使用的高级技巧:
Hermes 的命令可以像 Linux 管道一样组合使用,形成强大的工作流:
# 技巧 1:批量导出所有会话为 Markdown
hermes chat list --format json | jq -r '.[].id' | while read id; do
hermes chat export "$id" --format md --output "~/backups/$id.md"
done
# 技巧 2:测试所有配置的模型连接
hermes model list --format json | jq -r '.[].name' | while read model; do
echo "Testing $model..."
hermes model test "$model"
done
# 技巧 3:一键诊断并修复常见问题
hermes doctor --fix && hermes config validate && echo "All good!"
# 技巧 4:快速切换模型进行 A/B 测试
hermes -c "用 Python 写快速排序" --model deepseek-chat > /tmp/result_a.txt
hermes -c "用 Python 写快速排序" --model claude-3.5-sonnet > /tmp/result_b.txt
diff /tmp/result_a.txt /tmp/result_b.txt
# 技巧 5:批量更新所有技能
hermes skills list --outdated | xargs -I {} hermes skills update {}
Tips
把这些常用命令组合写成 shell alias 或脚本,可以大幅提升效率。比如在你的
~/.zshrc中添加:bash alias hdoc='hermes doctor' alias hchat='hermes chat list' alias hmodel='hermes model list' alias hbackup='tar -czf ~/hermes-backup-$(date +%Y%m%d).tar.gz ~/.hermes/config.yaml ~/.hermes/SOUL.md ~/.hermes/MEMORY.md ~/.hermes/database'
4. 斜杠命令系统
在对话模式中,输入以 / 开头的命令可以触发特殊功能。斜杠命令就像是 Hermes 的「快捷键」,让你不用退出对话就能执行各种操作。
4.1 /help 帮助
You: /help
可用命令:
/help 显示此帮助信息
/model 切换模型
/memory 查看或编辑记忆
/skills 管理技能
/compact 压缩上下文
/clear 清除当前上下文
/export 导出对话
/private 进入隐私模式
/exit 退出对话
输入 /help <命令名> 查看详细说明。
4.2 /model 切换模型
在对话过程中随时切换模型:
You: /model
可用模型:
1. deepseek-chat (当前)
2. deepseek-reasoner
3. anthropic/claude-3.5-sonnet
4. openai/gpt-5
> 3
✓ 已切换到 anthropic/claude-3.5-sonnet
Tips
在对话中切换模型是 Hermes 的杀手级功能之一。比如你先让便宜的 DeepSeek 处理大部分对话,遇到复杂的代码审查时切到 Claude 3.5 Sonnet,完成后再切回 DeepSeek。这样既能保证质量,又能控制成本。
4.3 /memory 查看记忆
You: /memory
当前全局记忆(来自 MEMORY.md):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
• 用户偏好简洁回答
• 用户是 Python 开发者
• 用户项目目录: ~/projects/my-startup
You: /memory add 用户最近在学 Rust
✓ 已添加到全局记忆。
4.4 /skills 管理技能
You: /skills
已加载的技能:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✓ web_search 网页搜索
✓ file_operations 文件读写
✓ code_execution 代码执行
✗ stock_analysis 股票分析 (已禁用)
You: /skills enable stock_analysis
✓ 已启用 stock_analysis
4.5 /compact 压缩上下文
当对话变得很长时,上下文可能会占用大量 token。/compact 命令会让 Hermes 自动总结之前的对话内容,用简洁的摘要替代原始消息,从而释放上下文空间。
You: /compact
正在压缩上下文...
✓ 上下文已从 42 条消息压缩为 3 条摘要。
节省 token: ~8,500
注意
压缩上下文会丢失部分细节。如果对话中有重要的具体信息(如特定的代码片段、精确的数字),建议在压缩前用
/memory命令将其保存到全局记忆中。
4.6 /clear 清除上下文
You: /clear
确定要清除当前对话上下文吗?(y/n)> y
✓ 上下文已清除。当前会话变为全新状态。
4.7 /export 导出对话
You: /export
导出格式:
1. Markdown
2. JSON
3. 纯文本
> 1
导出文件名(默认: session-2026-04-21.md)>
✓ 对话已导出到 ~/session-2026-04-21.md
4.8 其他斜杠命令
| 命令 | 功能 | 示例 |
|---|---|---|
/private |
进入隐私模式(不保存本次对话) | /private |
/public |
退出隐私模式 | /public |
/undo |
撤销上一条消息 | /undo |
/retry |
重新生成上一条回复 | /retry |
/system |
发送系统消息 | /system 请用中文回答 |
/temp |
临时切换模型(仅下一条消息) | /temp claude-3.5-sonnet |
斜杠命令使用技巧:
技巧 1:快速切换模型进行 A/B 测试
You: 帮我写一个快速排序的 Python 实现
Hermes: [DeepSeek 给出实现]
You: /temp claude-3.5-sonnet
用类型注解和文档字符串重写上面的代码
Hermes: [Claude 给出更完善的实现]
技巧 2:用 /system 纠正 Agent 的行为
You: /system 从现在开始,所有代码示例都要包含单元测试
You: 写一个判断闰年的函数
Hermes: [代码 + 单元测试]
技巧 3:用 /compact + /memory 组合管理长对话
You: /compact
Hermes: ✓ 上下文已压缩
You: /memory add 我们刚才讨论的核心结论是:使用异步 IO 可以提升 3 倍性能
Hermes: ✓ 已添加到全局记忆
Tips
斜杠命令是 Hermes 交互效率的倍增器。刚开始你可能记不住所有命令,没关系,只要记住
/help、/model和/memory这三个最常用命令,就能覆盖 80% 的场景。其他的命令可以慢慢在实践中熟悉。
5. 模型接入与切换
5.1 支持的 LLM 提供者完整列表
Hermes 目前支持以下 20+ LLM 提供者:
| 提供者 | 类型 | 接入难度 | 推荐度 |
|---|---|---|---|
| Nous Portal | 官方统一订阅 | 简单 | ⭐⭐⭐⭐⭐ |
| OpenAI | 商业 API | 简单 | ⭐⭐⭐⭐ |
| Anthropic | 商业 API | 简单 | ⭐⭐⭐⭐⭐ |
| DeepSeek | 商业 API | 简单 | ⭐⭐⭐⭐⭐ |
| Kimi (Moonshot) | 商业 API | 简单 | ⭐⭐⭐⭐ |
| OpenRouter | 聚合平台 | 简单 | ⭐⭐⭐⭐⭐ |
| GLM-5 (智谱) | 商业 API | 简单 | ⭐⭐⭐⭐ |
| MiniMax M2.7 | 商业 API | 简单 | ⭐⭐⭐⭐ |
| Ollama | 本地部署 | 中等 | ⭐⭐⭐ |
| vLLM | 本地部署 | 困难 | ⭐⭐⭐ |
| Azure OpenAI | 云服务 | 中等 | ⭐⭐⭐⭐ |
| Google Gemini | 商业 API | 简单 | ⭐⭐⭐⭐ |
| Mistral | 商业 API | 简单 | ⭐⭐⭐⭐ |
| Cohere | 商业 API | 简单 | ⭐⭐⭐ |
| Together AI | 推理平台 | 简单 | ⭐⭐⭐ |
| Fireworks AI | 推理平台 | 简单 | ⭐⭐⭐ |
| Groq | 推理平台 | 简单 | ⭐⭐⭐⭐ |
| Perplexity | 搜索+模型 | 简单 | ⭐⭐⭐⭐ |
| LocalAI | 本地部署 | 中等 | ⭐⭐⭐ |
| LM Studio | 本地部署 | 中等 | ⭐⭐⭐ |
5.2 各提供者的接入方法
Nous Portal(官方统一订阅)
Nous Portal 是 Nous Research 推出的官方订阅服务,最大优势是一个月费涵盖所有接入模型,不用分别购买各平台的 API Key。
# 1. 访问 https://portal.nousresearch.com/ 注册并订阅
# 2. 获取 Portal API Key
# 3. 配置 Hermes
hermes setup
# 选择 "Nous Portal" 作为提供者
# 输入 Portal API Key
# 或在 config.yaml 中手动配置
providers:
nous:
api_key: "${NOUS_API_KEY}"
base_url: "https://portal.nousresearch.com/api/v1"
Tips
Nous Portal 特别适合需要频繁切换模型的用户。比如你的 Agent 既需要 Claude 的推理能力,又需要 GPT-5 的多模态能力,还需要 DeepSeek 的中文处理,如果没有 Portal,你需要分别购买三个平台的 API 并管理三个 Key。Portal 把它们统一到一个 Key 下,省心又省力。
OpenAI(GPT-5 / GPT-4o / o1)
# 1. 访问 https://platform.openai.com/ 注册
# 2. 进入 API Keys 页面创建 Key
# 3. 配置
hermes setup
# 选择 OpenAI,输入 sk- 开头的 Key
providers:
openai:
api_key: "${OPENAI_API_KEY}"
base_url: "https://api.openai.com/v1"
OpenAI 模型选择建议:
| 模型 | 价格 | 特点 | 适合场景 |
|---|---|---|---|
| GPT-5 | $$$$ | 最强通用能力、原生多模态 | 复杂任务、创意工作 |
| GPT-4o | $$$ | 速度快、多模态、性价比高 | 日常对话、图文处理 |
| o1 | $$$$$ | 强化推理、链式思考 | 数学、科学、复杂逻辑 |
| GPT-4o-mini | $ | 便宜、速度快 | 简单任务、高并发 |
Anthropic(Claude 3.5 Sonnet / Opus)
# 1. 访问 https://console.anthropic.com/ 注册
# 2. 获取 API Key(以 sk-ant- 开头)
# 3. 配置
hermes setup
# 选择 Anthropic
providers:
anthropic:
api_key: "${ANTHROPIC_API_KEY}"
base_url: "https://api.anthropic.com"
Claude 系列特点:
- Claude 3.5 Sonnet:代码能力极强,被很多开发者认为是「最佳编程助手」。在代码审查、Debug、架构设计方面表现突出。
- Claude 3 Opus:推理能力最强,适合深度分析、复杂问题求解。
- Claude 3.5 Haiku:速度最快,价格便宜,适合简单任务。
注意
Anthropic 的 API 在国内访问需要代理。如果你不想配置代理,可以通过 OpenRouter 间接调用 Claude,或者使用 Nous Portal。
DeepSeek
DeepSeek 是目前性价比最高的商业 API 之一,强烈推荐作为国内用户的主力模型。
# 1. 访问 https://platform.deepseek.com/ 注册
# 2. 新用户通常有 10 元免费额度
# 3. 获取 API Key
# 4. 配置
hermes setup
# 选择 DeepSeek
providers:
deepseek:
api_key: "${DEEPSEEK_API_KEY}"
base_url: "https://api.deepseek.com"
DeepSeek 模型:
| 模型 | 输入价格(/M tokens) | 输出价格(/M tokens) | 特点 |
|---|---|---|---|
| deepseek-chat | ¥2 | ¥8 | 通用对话,速度快 |
| deepseek-reasoner | ¥4 | ¥16 | 推理增强,数学和代码更强 |
Tips
以 deepseek-chat 的价格计算,100 万汉字(约 300 万 token)的对话成本仅为 6-24 元。这个价格比 OpenAI GPT-4 便宜约 20-50 倍,效果却能达到 GPT-4 的 80-90%。对于中文用户来说,DeepSeek 是「省钱神器」。
Kimi(Moonshot)
Kimi 的最大亮点是超长上下文窗口(支持 200K+ token),非常适合长文档分析。
# 1. 访问 https://platform.moonshot.cn/ 注册
# 2. 获取 API Key
# 3. 配置
hermes setup
# 选择 Kimi
providers:
moonshot:
api_key: "${MOONSHOT_API_KEY}"
base_url: "https://api.moonshot.cn/v1"
OpenRouter(一 Key 多用)
OpenRouter 是一个模型聚合平台,你用一个 API Key 就能调用数十个不同厂商的模型。它就像是 LLM 世界的「万能转接头」,不管你用的是 OpenAI、Anthropic、Google 还是 Meta 的模型,只要一个 Key 就能全部打通。
OpenRouter 的优势:
- 一 Key 多用:一个 API Key 访问 100+ 模型
- 免费额度:部分模型提供免费 tier(带速率限制)
- 统一计费:不用分别管理各平台的账单
- 自动路由:智能选择可用性最高的模型端点
- 标准化接口:所有模型使用统一的 OpenAI 兼容格式
# 1. 访问 https://openrouter.ai/ 注册
# 2. 用 GitHub/Google 账号登录
# 3. 在 Settings > Keys 创建 Key(以 sk-or-v1- 开头)
# 4. 配置
hermes setup
# 选择 OpenRouter
providers:
openrouter:
api_key: "${OPENROUTER_API_KEY}"
base_url: "https://openrouter.ai/api/v1"
OpenRouter 支持的免费模型(有速率限制):
| 模型 ID | 提供商 | 特点 | 速率限制 |
|---|---|---|---|
google/gemini-2.5-pro-exp-03-25:free |
多模态、长上下文 | 20 RPM | |
meta-llama/llama-3.3-70b-instruct:free |
Meta | 通用能力强 | 20 RPM |
deepseek/deepseek-chat:free |
DeepSeek | 中文优秀 | 20 RPM |
nvidia/llama-3.1-nemotron-70b-instruct:free |
NVIDIA | 推理增强 | 20 RPM |
Tips
OpenRouter 是零成本入门 Hermes 的最佳选择。注册后立刻就有免费额度可用,虽然速率有限制(通常每秒 1-2 请求),但对于学习和轻度使用完全够用。等熟悉了之后再切换到付费的 DeepSeek 或 Nous Portal。
一个小技巧:OpenRouter 的免费模型在模型 ID 末尾有
:free后缀。在配置时明确使用免费版本,可以避免意外产生费用。比如用google/gemini-2.5-pro-exp-03-25:free而不是google/gemini-2.5-pro-exp-03-25。
本地模型(Ollama)
如果你想在本地运行模型,Ollama 是最简单的方案。它就像 Docker 之于容器——一键下载、一键运行,不需要手动配置复杂的模型环境。
Ollama 安装步骤:
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows (通过 WSL2)
# 在 WSL2 Ubuntu 中运行 Linux 安装命令
下载和运行模型:
# 下载 Qwen 2.5 Coder 32B(官方推荐,适合代码任务)
ollama pull qwen2.5-coder:32b
# 下载完成后测试
ollama run qwen2.5-coder:32b
# 输入问题测试,按 Ctrl+D 退出
# 查看已下载的模型
ollama list
# 删除不用的模型释放空间
ollama rm llama3.2
配置 Hermes 使用 Ollama:
hermes setup
# 选择 "本地模型 (Ollama)"
或在 config.yaml 中手动配置:
providers:
ollama:
base_url: "http://localhost:11434"
model: "qwen2.5-coder:32b"
推荐的本地模型:
| 模型 | 显存需求 | 特点 | 适用场景 |
|---|---|---|---|
| Qwen 2.5 Coder 32B | ~20GB | 代码能力强、中文好 | 日常编程辅助 |
| Llama 3.3 70B | ~40GB | 通用能力强 | 复杂推理任务 |
| Mistral 7B | ~5GB | 轻量、速度快 | 简单对话、低资源设备 |
| DeepSeek Coder 33B | ~20GB | 代码专用 | 代码生成和审查 |
不同硬件配置下的模型选择建议:
| 你的硬件 | 推荐模型 | 预期体验 |
|---|---|---|
| MacBook Pro M3 Max (36GB 统一内存) | Qwen 2.5 Coder 32B | 流畅,适合主力开发 |
| MacBook Pro M2 (16GB) | Qwen 2.5 Coder 14B | 可用,偶尔有延迟 |
| 游戏本 (RTX 4060 8GB) | Qwen 2.5 Coder 7B | 基本可用,简单任务 |
| 台式机 (RTX 4090 24GB) | Qwen 2.5 Coder 32B / Llama 3.3 70B | 丝滑流畅 |
| 无独立显卡的老电脑 | Mistral 7B | 能跑,但体验一般 |
注意
本地模型虽然免费,但需要强大的硬件支持。社区共识是:生产环境用前沿模型(Claude、GPT-5),本地模型仅供实验和隐私敏感场景。 Qwen 2.5 Coder 32B 可以处理约 80% 的日常 CLI 使用场景,比如简单的代码补全、文件操作、命令解释等。但对于复杂的多步骤推理、长上下文理解和高质量创意输出,云端的前沿模型仍然是更好的选择。
一个实用的策略是:日常开发用本地模型处理简单查询(节省 API 费用),遇到复杂问题时一键切换到云端模型。Hermes 的分层模型配置完全支持这种混合模式——将 ollama 设为 execution 模型,将 Claude/GPT-5 设为 reasoning 模型即可。
其他国产模型
GLM-5(智谱):
智谱 AI 是国内领先的大模型公司之一,GLM-5 是其最新一代模型,在中文理解和工具调用方面表现出色。
# 1. 访问 https://open.bigmodel.cn/ 注册
# 2. 完成实名认证(国内平台通常需要)
# 3. 在「API Keys」页面创建 Key
# 4. 配置 Hermes
hermes setup
# 选择 GLM-5
providers:
zhipu:
api_key: "${ZHIPU_API_KEY}"
base_url: "https://open.bigmodel.cn/api/paas/v4"
GLM-5 的特点:
- 中文理解能力在国内模型中名列前茅
- 工具调用(Function Calling)准确性高
- 支持长文本(最大 128K 上下文)
- 价格亲民,适合企业级应用
- API 文档完善,国内访问速度快
MiniMax M2.7:
MiniMax 是国内新兴的 AI 公司,M2.7 模型在对话流畅度和语音交互方面表现突出。
# 1. 访问 https://api.minimax.chat/ 注册
# 2. 创建应用并获取 API Key
# 3. 配置 Hermes
hermes setup
# 选择 MiniMax
providers:
minimax:
api_key: "${MINIMAX_API_KEY}"
base_url: "https://api.minimax.chat/v1"
MiniMax M2.7 的特点:
- 对话流畅自然,接近真人聊天体验
- 支持语音输入输出(适合语音助手场景)
- 多轮对话记忆能力强
- 在创意写作和角色扮演方面表现不错
- 适合构建聊天机器人和虚拟助手
5.3 hermes model 命令详解
模型管理是 Hermes 日常使用中的高频操作。掌握这些命令,你可以在对话中随时切换模型,找到最适合当前任务的「大脑」。
# 列出所有已配置的模型及其状态
hermes model list
# 输出示例:
# Provider Model Status Cost/M
# ───────────────────────────────────────────────────────
# deepseek deepseek-chat ✓ 在线 ¥0.01
# openrouter anthropic/claude-3.5 ✓ 在线 $0.003
# openai gpt-4o ✓ 在线 $0.005
# ollama qwen2.5-coder:32b ✓ 在线 免费
# 切换默认模型(永久生效,写入配置)
hermes model use deepseek-reasoner
# 临时测试某个模型(仅本次对话)
hermes chat --model openai/gpt-4o
# 查看模型的 token 价格和上下文长度
hermes model info deepseek-chat
# 运行模型基准测试
hermes model benchmark --prompts standard
模型管理实战场景:
场景 1:快速对比多个模型
# 让三个模型回答同一个问题,对比效果
for model in deepseek-chat claude-3.5-sonnet gpt-4o; do
echo "=== $model ==="
hermes -c "解释什么是区块链,用通俗语言" --model "$model"
echo ""
done
场景 2:批量测试模型连通性
# 测试所有配置的模型是否都能正常连接
hermes model list --format json | jq -r '.[].id' | while read model; do
if hermes model test "$model" > /dev/null 2>&1; then
echo "✓ $model 正常"
else
echo "✗ $model 异常"
fi
done
场景 3:费用监控
# 查看本月各模型的费用消耗
hermes status --cost --format table
# 设置费用预警(当本月费用超过 50 元时提醒)
# 在 config.yaml 中添加:
# core:
# monthly_budget: 50
# budget_currency: "CNY"
5.4 模型切换的实际效果对比
同一个问题,不同模型的回答风格和深度可能差异很大。下面是一个实际对比:
问题:解释什么是递归函数,并用 Python 举例。
DeepSeek (deepseek-chat):
递归函数就是在函数内部调用自己的函数。就像俄罗斯套娃,每个娃娃里面还有一个更小的自己。
经典例子是阶乘:
python def factorial(n): if n <= 1: return 1 return n * factorial(n - 1)但要注意,递归必须有终止条件,否则会无限循环导致栈溢出。
Claude 3.5 Sonnet:
递归是一种编程范式,函数通过调用自身来解决问题。其核心思想是将大问题分解为结构相同的子问题。
Python 示例 —— 阶乘:
python def factorial(n: int) -> int: """计算 n 的阶乘。""" if n < 0: raise ValueError("n must be non-negative") if n <= 1: return 1 return n * factorial(n - 1)更实用的例子 —— 遍历嵌套目录: ```python import os
def list_files(path: str, indent: int = 0): """递归列出目录下所有文件。""" for item in os.listdir(path): full = os.path.join(path, item) print(" " * indent + item) if os.path.isdir(full): list_files(full, indent + 1) ```
递归 vs 迭代的权衡:递归代码更简洁直观,但函数调用有栈深度限制(Python 默认约 1000 层)。生产环境中,对于深度未知的问题,建议改用迭代或尾递归优化。
可以看到,DeepSeek 的回答简洁直白,适合快速理解;Claude 的回答更全面深入,包含了类型注解、错误处理、实际应用场景和性能权衡。
5.5 模型选择建议(按任务类型推荐)
| 任务类型 | 首选模型 | 备选模型 | 理由 |
|---|---|---|---|
| 日常问答/闲聊 | DeepSeek | GLM-5 | 便宜、中文好、速度快 |
| 代码编写/审查 | Claude 3.5 Sonnet | DeepSeek-reasoner | 代码能力业界顶尖 |
| 复杂推理/数学 | Claude 3 Opus | GPT-5 / o1 | 推理链最完整 |
| 长文档分析 | Kimi | Claude 3.5 Sonnet | 200K 上下文窗口 |
| 创意写作 | GPT-5 | Claude 3.5 Sonnet | 创意和表达最丰富 |
| 快速简单任务 | DeepSeek-chat | GPT-4o-mini | 最便宜 |
| 隐私敏感场景 | Qwen 2.5 Coder (本地) | Llama 3.3 70B (本地) | 数据不出本机 |
| 多模态(图文) | GPT-4o | Gemini 2.5 Pro | 原生支持图像理解 |
Tips
很多老手会同时配置 3-4 个模型,根据任务动态切换。下一章我们将介绍「分层模型配置」,让 Hermes 自动帮你选择最适合当前任务的模型,既保证质量又省钱。
5.6 模型费用监控与预算管理
使用 LLM API 最怕什么?不是模型不够聪明,而是月底看到账单时的心跳骤停。Hermes 内置了费用追踪和预算管理功能,让你对每一分钱的去向都心中有数。
实时费用查看
# 查看本月累计费用
hermes status --cost
# 输出示例:
# ════════════════════════════════════════════
# 本月费用概览(2026-04)
# ════════════════════════════════════════════
# Provider 请求数 Token 数 费用
# ────────────────────────────────────────────
# deepseek 1,234 2.5M ¥3.20
# anthropic 156 890K $12.50
# openrouter 432 1.2M $2.80
# ────────────────────────────────────────────
# 总计 4.6M ¥28.40
设置月度预算预警
在 config.yaml 中配置预算限制:
core:
monthly_budget: 100 # 月度预算上限(单位与 billing_currency 一致)
billing_currency: "CNY" # 结算货币:CNY 或 USD
budget_alert_threshold: 80 # 当费用达到预算的 80% 时发出警告
当费用接近预算上限时,Hermes 会在每次对话前显示提醒:
⚠️ 本月费用已达到预算的 82%(¥82.00 / ¥100.00)。
建议切换到更便宜的模型或检查是否有异常调用。
费用优化 checklist
- [ ] 已为简单任务配置便宜的执行模型(如 DeepSeek)
- [ ] 已启用分层模型配置,避免用 Claude 处理所有请求
- [ ] 定期检查
hermes status --cost,找出费用异常波动 - [ ] 为团队账号设置独立预算,防止个人使用影响团队配额
- [ ] 本地模型(Ollama)处理不涉及外部知识的简单查询
注意
Nous Portal 采用统一订阅模式,一个月费涵盖所有模型,不存在按 token 计费的「惊吓账单」。如果你使用 Nous Portal,费用管理会更简单——只需要关注订阅是否到期即可。但如果你混用多个独立计费的 provider,上面的预算管理功能就非常重要了。
模型接入的快速参考卡片:
| 提供商 | 官网 | API Key 获取位置 | Key 前缀 | 国内访问 |
|---|---|---|---|---|
| DeepSeek | platform.deepseek.com | API Keys 页面 | sk- |
直连 |
| OpenRouter | openrouter.ai | Settings > Keys | sk-or-v1- |
需代理 |
| Nous Portal | portal.nousresearch.com | Account > API Keys | sk- |
需代理 |
| OpenAI | platform.openai.com | API Keys | sk- |
需代理 |
| Anthropic | console.anthropic.com | API Keys | sk-ant- |
需代理 |
| Kimi | platform.moonshot.cn | API Keys | sk- |
直连 |
| 智谱 GLM-5 | open.bigmodel.cn | API Keys | 无固定前缀 | 直连 |
| MiniMax | api.minimax.chat | 应用管理 | 无固定前缀 | 直连 |
把这张表收藏起来,当你需要新增模型配置时,可以快速找到对应的信息。
6. 分层模型配置(省钱秘笈)
如果你只用一种模型完成所有任务,很快就会面临一个困境:用 Claude 3.5 Sonnet 处理所有事情太贵,用 DeepSeek 处理复杂任务又不够用。分层模型配置就是解决这个问题的「省钱秘笈」。
6.1 config.yaml 模型配置详解
分层模型的核心思想是:不同难度的任务用不同档次的模型。就像你不会用兰博基尼去买菜,也不会用自行车跑高速一样。
在 config.yaml 中,分层模型通过以下配置实现:
# ~/.hermes/config.yaml
models:
# === 第一层:推理模型 ===
# 负责处理复杂问题、需要深度思考的任务
reasoning:
provider: "anthropic"
model: "claude-3.5-sonnet"
# 触发条件:任务复杂度评分 > 0.7
# 适用场景:架构设计、复杂 Debug、数学证明、深度分析
# === 第二层:执行模型 ===
# 负责处理常规任务、日常对话
execution:
provider: "deepseek"
model: "deepseek-chat"
# 适用场景:日常问答、简单代码、文件操作、信息检索
# === 第三层:Fallback 链 ===
# 当首选模型不可用时,按顺序尝试备选模型
fallback:
- provider: "openrouter"
model: "google/gemini-flash-1.5"
- provider: "deepseek"
model: "deepseek-chat"
- provider: "openai"
model: "gpt-4o-mini"
# === 本地模型(轻量任务)===
local:
provider: "ollama"
model: "qwen2.5-coder:32b"
# 适用场景:离线环境、隐私敏感、简单代码补全
注意
分层模型的自动切换依赖于 Hermes 内置的「任务复杂度评估器」。它会根据你的输入自动判断任务难度: - 简单问题(如"Python 怎么写循环?")→ 执行模型 - 复杂问题(如"帮我设计一个高并发的微服务架构")→ 推理模型 - 代码审查、长文档分析 → 推理模型 - 日常闲聊、简单文件操作 → 执行模型
6.2 核心逻辑用强模型、基础执行用便宜模型
让我们用一个实际例子来说明分层模型如何省钱:
场景:让 Hermes 帮你写一个完整的 Web 应用
You: 帮我写一个用户注册登录系统,包含前端页面和后端 API
不分层(全部用 Claude 3.5 Sonnet)的成本:
| 步骤 | Token 消耗 | 费用 |
|---|---|---|
| 需求分析 | 5K input + 3K output | $0.06 |
| 架构设计 | 8K input + 5K output | $0.10 |
| 后端代码 | 10K input + 8K output | $0.15 |
| 前端代码 | 10K input + 8K output | $0.15 |
| 测试和 Debug | 6K input + 4K output | $0.08 |
| 总计 | 39K input + 28K output | $0.54 |
分层配置(推理用 Claude,执行用 DeepSeek)的成本:
| 步骤 | 使用模型 | Token 消耗 | 费用 |
|---|---|---|---|
| 需求分析 | DeepSeek | 5K + 3K | ¥0.02 |
| 架构设计 | Claude | 8K + 5K | $0.10 |
| 后端代码 | DeepSeek | 10K + 8K | ¥0.05 |
| 前端代码 | DeepSeek | 10K + 8K | ¥0.05 |
| 测试和 Debug | DeepSeek | 6K + 4K | ¥0.02 |
| 总计 | 39K + 28K | 约 $0.14 |
节省:约 75%!
Tips
这个省钱的逻辑很简单:架构设计等关键环节用最强的模型确保质量,具体的代码实现交给便宜模型完成。就像建筑设计师设计蓝图(高薪),工人按图施工(普通薪资),最终房子的质量由设计决定,而不是由施工工人的学历决定。
6.3 Fallback 链机制详解
Fallback 链是分层模型配置中的「保险丝」。当首选模型因为网络问题、余额不足或服务商故障而无法使用时,Hermes 会自动按顺序尝试 Fallback 列表中的模型。
Fallback 触发条件:
- API 返回 429(速率限制)
- API 返回 401/403(认证失败 / 余额不足)
- API 返回 5xx(服务商内部错误)
- 请求超时(默认 60 秒)
- 网络连接失败
Fallback 配置示例:
models:
execution:
provider: "deepseek"
model: "deepseek-chat"
fallback:
# 第一备选:OpenRouter 上的 Gemini(免费额度)
- provider: "openrouter"
model: "google/gemini-flash-1.5"
# 第二备选:OpenAI 的便宜模型
- provider: "openai"
model: "gpt-4o-mini"
# 第三备选:本地模型(最后一道防线)
- provider: "ollama"
model: "qwen2.5-coder:7b"
注意
Fallback 链中的模型应该尽量选择不同类型的服务商。比如你的主模型是 DeepSeek(国内),第一备选选 OpenRouter(海外),第二备选选本地 Ollama。这样可以避免单一服务商故障导致所有模型都不可用的情况。
6.4 实测成本降低 50%-70% 的配置方案
以下是经过社区大量实测验证的分层配置方案:
方案 A:极致省钱型(月费约 ¥0-30)
models:
reasoning:
provider: "openrouter"
model: "google/gemini-2.5-pro-exp-03-25:free"
execution:
provider: "openrouter"
model: "deepseek/deepseek-chat:free"
fallback:
- provider: "ollama"
model: "qwen2.5-coder:7b"
特点:完全依赖免费额度,适合轻度使用和入门体验。缺点是速率限制较严格,高峰期可能需要等待。
方案 B:性价比之王(月费约 ¥30-80)
models:
reasoning:
provider: "deepseek"
model: "deepseek-reasoner"
execution:
provider: "deepseek"
model: "deepseek-chat"
fallback:
- provider: "openrouter"
model: "google/gemini-flash-1.5"
- provider: "ollama"
model: "qwen2.5-coder:32b"
特点:DeepSeek 双模型搭配,中文场景效果出色,成本极低。适合绝大多数国内用户的日常需求。
方案 C:质量优先型(月费约 $30-80)
models:
reasoning:
provider: "anthropic"
model: "claude-3.5-sonnet"
execution:
provider: "openai"
model: "gpt-4o-mini"
fallback:
- provider: "deepseek"
model: "deepseek-chat"
- provider: "openrouter"
model: "google/gemini-flash-1.5"
特点:关键环节用最强的 Claude 3.5 Sonnet,日常任务用便宜的 GPT-4o-mini。适合对代码质量要求高的开发者。
方案 D:全能均衡型(月费约 $50-150)
models:
reasoning:
provider: "anthropic"
model: "claude-3.5-sonnet"
execution:
provider: "deepseek"
model: "deepseek-chat"
fallback:
- provider: "openai"
model: "gpt-4o"
- provider: "openrouter"
model: "anthropic/claude-3.5-sonnet"
- provider: "ollama"
model: "qwen2.5-coder:32b"
特点:覆盖所有场景,质量有保障。适合专业开发者和团队使用。
6.5 不同预算的推荐配置
| 月预算 | 推荐配置 | 预期效果 |
|---|---|---|
| ¥0(纯免费) | OpenRouter 免费模型 + Ollama 本地模型 | 轻度使用,偶尔需要等待 |
| ¥10-30 | DeepSeek 主力 | 满足 90% 的日常需求 |
| ¥50-100 | DeepSeek + Claude(分层) | 代码质量显著提升 |
| $10-30 | Claude Sonnet + GPT-4o-mini | 国际开发者的最佳性价比 |
| $50-100 | Claude + DeepSeek + Nous Portal | 专业级配置,无短板 |
| $100+ | GPT-5 + Claude Opus(全顶配) | 最强效果,适合企业 |
Tips
建议所有新手都从「方案 B:性价比之王」开始。DeepSeek 的价格低到不可思议,效果却能达到 GPT-4 的八到九成。等使用一个月后,根据实际消耗和体验,再决定是否升级到更贵的配置。
分层模型的实际运行日志示例:
当你在分层模型配置下与 Hermes 对话时,可以在日志中看到模型切换的轨迹:
[INFO] 用户输入: "写一个计算斐波那契数列的函数"
[INFO] 任务复杂度评估: 0.3 (简单)
[INFO] 选择执行模型: deepseek-chat
[INFO] Token 消耗: input=15, output=120
[INFO] 费用: ¥0.0012
---
[INFO] 用户输入: "帮我设计一个支持百万级并发的分布式消息队列系统"
[INFO] 任务复杂度评估: 0.95 (极复杂)
[INFO] 选择推理模型: claude-3.5-sonnet
[INFO] Token 消耗: input=45, output=1850
[INFO] 费用: $0.0558
---
[INFO] 用户输入: "谢谢"
[INFO] 任务复杂度评估: 0.0 (问候)
[INFO] 选择执行模型: deepseek-chat
[INFO] Token 消耗: input=2, output=15
[INFO] 费用: ¥0.0001
从日志中可以清楚地看到,简单的问候用便宜的 DeepSeek(¥0.0001),复杂的架构设计用强大的 Claude($0.0558)。如果没有分层配置,所有任务都用 Claude,费用会高 5-10 倍。
如何查看自己的费用统计:
# 查看本月费用统计
hermes status --cost
# 输出示例:
# Provider 请求数 Token 总数 费用
# ──────────────────────────────────────────────
# deepseek 1,245 2.3M ¥18.50
# anthropic 45 0.18M $2.80
# openrouter 12 0.05M $0.15
# ──────────────────────────────────────────────
# 总计 约 ¥38.00
注意
分层模型的自动评估不是 100% 准确的。偶尔会出现「简单任务被误判为复杂任务」或反之的情况。如果你发现某个任务明显用错了模型,可以在对话中直接说「用执行模型回答这个问题」或「这个问题需要推理模型」,Hermes 会尊重你的指令。
7. SOUL.md 人设配置
7.1 什么是 SOUL.md
SOUL.md 是 Hermes 最具特色的功能之一。它是 Agent 的「灵魂文件」,定义了你的 Agent 的性格、身份、说话方式、专业领域和行为准则。
你可以把 SOUL.md 理解为:
- 对 Hermes 来说 = 它的角色剧本和表演指南
- 对你来说 = 一次编写,永久生效的「系统提示词」
- 对对话来说 = 决定 Agent 语气、风格和能力的底层配置
注意
SOUL.md 与单次对话中的「系统消息」不同。系统消息只在当前会话有效,而 SOUL.md 会在每次启动 Hermes 时自动加载,永久影响 Agent 的行为。这意味着你不需要每次对话都告诉它「请用中文回答」或「请简洁一些」——把这些写进 SOUL.md 即可。
7.2 编写有效的 SOUL.md(模板 + 示例)
以下是一个通用的 SOUL.md 模板,你可以根据自己的需求修改:
# SOUL.md
# [Agent 名称] 的人设定义
## 身份
你是 [名称],一位 [角色定位]。
## 性格
- [性格特点 1]
- [性格特点 2]
- [性格特点 3]
## 专业领域
- [领域 1]
- [领域 2]
- [领域 3]
## 说话风格
- [语言偏好]
- [回答长度偏好]
- [格式偏好]
- [特殊习惯]
## 行为准则
- [准则 1]
- [准则 2]
- [准则 3]
## 禁忌
- [不能做的事情 1]
- [不能做的事情 2]
7.3 不同场景的人设配置
场景 1:投研分析师
# SOUL.md
# 投研助手「鹰眼」
## 身份
你是一位名叫「鹰眼」的投研分析师,专注于科技行业和加密货币领域的研究分析。
## 性格
- 冷静客观,用数据和事实说话
- 善于发现数据中的异常和趋势
- 对风险高度敏感,总是先提示风险再谈收益
- 语言简洁有力,不喜欢废话
## 专业领域
- 科技股基本面分析
- 加密货币项目评估
- 宏观经济趋势解读
- 财务报表快速分析
## 说话风格
- 默认使用中文,专业术语保留英文原文
- 分析结论先用一句话总结,再展开论述
- 关键数据和结论用加粗标记
- 喜欢使用表格对比不同标的
## 行为准则
- 任何投资建议都必须附带风险提示
- 引用数据时标注来源和时间
- 不确定的信息明确说「不确定」
- 遇到明显错误的信息主动指出
## 禁忌
- 绝不给出具体买卖点和价格预测
- 不使用「一定」「肯定」等绝对化表述
- 不推荐杠杆和衍生品交易
场景 2:编程助手
# SOUL.md
# 编程助手「码匠」
## 身份
你是一位名叫「码匠」的高级软件工程师,擅长 Python、TypeScript 和系统设计。
## 性格
- 务实,代码第一,理论第二
- 对代码质量有洁癖,见不得烂代码
- 耐心,愿意解释清楚每一个细节
- 喜欢用类比把复杂概念讲简单
## 专业领域
- Python 全栈开发
- 系统架构设计
- 代码审查和重构
- 性能优化
## 说话风格
- 代码示例必须完整可运行
- 先给结论,再给代码,最后解释原理
- 使用中文解释,代码注释用英文
- 变量命名用英文,符合 PEP8 / Google Style
## 行为准则
- 写代码时必须包含错误处理和边界情况
- 主动指出代码中的潜在问题和优化点
- 推荐现代、主流的技术方案
- 涉及安全时(如密码、密钥处理)必须提醒最佳实践
## 禁忌
- 不写没有错误处理的示例代码
- 不推荐已弃用的库和 API
- 不假设用户的操作系统(提供跨平台方案)
场景 3:写作助手
# SOUL.md
# 写作助手「墨言」
## 身份
你是一位名叫「墨言」的资深编辑和写作教练,擅长各类中文写作。
## 性格
- 对文字有洁癖,追求精准表达
- 温和但有原则,改稿时直言不讳
- 善于发现文章的结构问题和逻辑漏洞
- 知识面广,能为文章提供丰富的背景资料
## 专业领域
- 商业文案写作
- 技术博客撰写
- 公众号文章编辑
- 小说和剧本创作指导
## 说话风格
- 用中文交流,引用外文内容时给出中文翻译
- 修改建议用「原文 → 修改后 → 理由」的格式
- 喜欢使用修辞手法让表达更生动
- 段落不超过 5 行,句子不超过 30 字
## 行为准则
- 改稿时保留原文风格,只做优化不做重写
- 指出问题时同时给出修改建议
- 根据目标读者调整语言风格
- 检查事实准确性,不确定的内容标注出来
## 禁忌
- 不编造数据和引用
- 不改变作者的原始观点(除非明显错误)
- 不使用机器人口吻
场景 4:客服助手
# SOUL.md
# 客服助手「小暖」
## 身份
你是一位名叫「小暖」的智能客服助手,代表 [公司名] 为客户提供支持。
## 性格
- 热情友好,但不夸张
- 耐心,愿意重复解释
- 主动,能预判客户的潜在问题
- 专业,回答准确不含糊
## 专业领域
- 公司产品功能说明
- 常见问题解答
- 故障排查指导
- 使用技巧分享
## 说话风格
- 使用礼貌用语(您好、请、谢谢、抱歉)
- 回答结构:确认问题 → 给出方案 → 确认是否解决
- 步骤说明用数字序号
- 重要警告用 ⚠️ 标记
## 行为准则
- 首次回复在 3 句话内给出核心答案
- 复杂问题提供分步指南
- 无法解决的问题及时转接人工
- 涉及账户和隐私时先验证身份
## 禁忌
- 不猜测用户的意图,先确认再回答
- 不承诺无法保证的事情
- 不泄露其他客户的信息
- 不贬低竞争对手
7.4 让 Agent 自动更新 SOUL.md 的方法
Hermes 支持在对话中通过自然语言指令让 Agent 更新自己的 SOUL.md。这是 Hermes 自进化能力的核心体现。
示例:
You: 记住,以后回答编程问题时,总是先给出可运行的完整代码,然后再解释原理。
Hermes: 好的,我会将这条准则添加到 SOUL.md 中。
[自动执行: file_write]
路径: ~/.hermes/SOUL.md
操作: 在「行为准则」部分添加新条目
✓ SOUL.md 已更新。下次启动时生效。
你也可以直接要求它更新:
You: 更新 SOUL.md,在「专业领域」中添加「Rust 系统编程」
Hermes: 已更新 SOUL.md。
变更内容:
+ - Rust 系统编程
7.5 常见人设配置错误与纠正
错误 1:写得太多太杂
错误示例:
## 专业领域
- Python
- JavaScript
- Java
- C++
- Go
- Rust
- 数据分析
- 机器学习
- 深度学习
- 区块链
- 金融
- 医学
- 法律
...
问题: 列了太多领域,Agent 反而不知道你真正需要它擅长什么。
纠正: 聚焦 3-5 个核心领域,其他领域可以写「了解但不精通」。
错误 2:指令互相矛盾
错误示例:
## 说话风格
- 回答要简洁,不超过 3 句话
- 每个回答都要包含完整的代码示例和详细解释
问题: 「不超过 3 句话」和「完整代码示例 + 详细解释」不可能同时满足。
纠正: 按优先级排序,或者分场景说明。
错误 3:过度限制
错误示例:
## 禁忌
- 不使用任何标点符号
- 不使用数字
- 不使用英文
- 不提及任何技术名词
问题: 过度限制会让 Agent 的回答质量严重下降。
纠正: 只限制真正影响体验的行为,保留 Agent 的灵活性。
错误 4:不写「身份」部分
问题: 没有身份定义,Agent 不知道自己是谁,回答缺乏一致性。
纠正: 始终包含「身份」部分,哪怕只有一句话。
7.6 SOUL.md 的调试与验证技巧
写了 SOUL.md 之后,怎么知道它有没有生效?如果 Agent 的表现不符合预期,又该如何调试?这里有几个实用的技巧。
验证 SOUL.md 是否生效
最简单的方法是问 Agent 一个能体现人设的问题:
You: 你是谁?请描述一下你的角色和专长。
如果 SOUL.md 生效了,Agent 会按照你定义的身份回答,而不是默认的「我是一个 AI 助手」。
常见问题和修复
问题 1:Agent 仍然用默认语气回答
原因:SOUL.md 中的指令不够具体,或者被其他配置覆盖。
修复:在「说话风格」部分使用更明确的指令,例如:
## 说话风格
- **必须**使用中文回答,无论用户用什么语言提问
- **必须**先给出结论,再展开解释
- **禁止**使用「作为一个人工智能助手」作为回答开头
用「必须」「禁止」等强约束词比「尽量」「建议」更有效。
问题 2:SOUL.md 太长了,Agent 表现不稳定
原因:SOUL.md 内容过多,导致核心指令被稀释。
修复:精简内容,只保留最关键的 5-10 条指令。SOUL.md 不是越详细越好——Agent 的上下文窗口有限,太长的 SOUL.md 反而会让重要信息被忽略。
SOUL.md 迭代优化法
写 SOUL.md 不是一锤子买卖,建议用以下方法持续优化:
- 记录不满意的对答 —— 当 Agent 的回答不符合预期时,把对话保存下来
- 分析原因 —— 是 SOUL.md 缺少相关指令,还是指令不够明确?
- 修改 SOUL.md —— 添加或调整对应条款
- 重启 Hermes 验证 —— 用同样的提问测试,看是否改善
- 重复 1-4 —— 一般经过 3-5 轮迭代,SOUL.md 就会趋于稳定
Tips
好的 SOUL.md 就像好的公司章程——不需要面面俱到,但核心原则必须清晰明确。初学者最容易犯的错误是写得太长、太琐碎。建议先写一个 20 行的精简版,用一周时间观察效果,再根据实际需要逐步扩充。记住:少即是多,精准的约束胜过冗长的描述。
8. 第一个实战练习
理论知识学得再多,不动手实践也是白搭。下面三个实战练习,让你立刻体验 Hermes 的核心能力。
练习 1:让 Hermes 帮你搜索和总结一篇新闻
目标: 练习 Hermes 的网络搜索和信息总结能力。
步骤:
- 启动 Hermes:
hermes
- 输入搜索请求:
You: 搜索一下最近关于 AI Agent 行业的重要新闻,帮我总结 3 条最重要的
- Hermes 会自动调用
web_search工具搜索新闻,然后总结关键信息。
预期输出示例:
Hermes: 让我搜索一下最新的 AI Agent 行业动态。
[工具调用: web_search]
查询: AI Agent industry news April 2026
根据搜索结果,以下是 3 条最重要的新闻:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**1. Nous Research 发布 Hermes v1.3,引入多 Agent 协作机制**
时间: 2026年4月15日
要点: 新版本支持多个 Hermes Agent 之间的任务委派和状态同步,
企业用户可以搭建 Agent 工作流。
**2. OpenAI 推出 GPT-5 Agent Mode,与第三方框架直接竞争**
时间: 2026年4月10日
要点: GPT-5 新增原生 Agent 模式,支持工具调用和长期任务执行,
但仅对 Plus 和企业用户开放。
**3. 中国发布《AI Agent 服务管理办法》征求意见稿**
时间: 2026年4月8日
要点: 规范 AI Agent 的自动化决策、数据安全和用户告知义务,
行业进入监管时代。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
需要我对某条新闻展开详细分析吗?
Tips
你可以进一步要求它:「把第一条新闻的详细内容保存到 ~/news-hermes-v1.3.md」,Hermes 会自动调用文件写入工具帮你保存。
练习 2:让 Hermes 帮你写一段代码
目标: 练习 Hermes 的编程辅助能力。
步骤:
- 启动 Hermes(如果已退出):
hermes
- 提出编程需求:
You: 帮我写一个 Python 脚本,功能是读取当前目录下所有的 .txt 文件,
统计每个文件的字数,然后把结果输出到一个 CSV 文件中
- Hermes 会生成代码,并询问是否需要保存:
Hermes: 好的,我来写一个符合需求的脚本。
```python
import os
import csv
from pathlib import Path
def count_words_in_txt_files(directory="."):
"""统计目录下所有 txt 文件的字数,输出到 CSV。"""
results = []
for txt_file in Path(directory).glob("*.txt"):
content = txt_file.read_text(encoding="utf-8")
word_count = len(content.split())
results.append({
"filename": txt_file.name,
"word_count": word_count,
"file_size": txt_file.stat().st_size
})
# 写入 CSV
output_file = Path(directory) / "word_count_report.csv"
with open(output_file, "w", newline="", encoding="utf-8") as f:
writer = csv.DictWriter(f, fieldnames=["filename", "word_count", "file_size"])
writer.writeheader()
writer.writerows(results)
print(f"✓ 统计完成,结果已保存到 {output_file}")
print(f" 共处理 {len(results)} 个文件")
if __name__ == "__main__":
count_words_in_txt_files()
需要我把这个脚本保存到 count_words.py 吗?
4. 确认保存:
You: 保存到当前目录的 count_words.py,然后运行测试一下
> **注意**
>
> 在执行代码之前,Hermes 会显示即将执行的命令,并询问你是否确认。这是安全机制,防止误操作。你可以输入 `y` 确认,或 `n` 取消。
### 练习 3:让 Hermes 帮你管理文件
**目标:** 练习 Hermes 的文件操作能力。
**步骤:**
1. 让 Hermes 查看你的 Hermes 数据目录:
You: 帮我看看 ~/.hermes/ 目录下有哪些文件和文件夹, 用树状结构展示,并说明每个文件夹的作用
2. Hermes 会列出目录结构并解释:
Hermes: 我来帮你查看并整理 ~/.hermes/ 的目录结构。
[工具调用: execute_shell] 命令: tree -L 2 ~/.hermes/
目录结构如下:
~/.hermes/ ├── config.yaml ← 主配置文件 ├── SOUL.md ← Agent 人设定义 ├── MEMORY.md ← 全局记忆 ├── USER.md ← 用户信息 ├── database/ │ ├── hermes.db ← SQLite 主数据库(对话历史) │ └── vector.db ← 向量数据库(语义搜索) ├── skills/ │ ├── built-in/ ← 内置技能 │ ├── custom/ ← 自定义技能 │ └── downloaded/ ← 从 Hub 下载的技能 ├── cron/ │ ├── jobs.yaml ← 定时任务配置 │ └── logs/ ← 任务执行日志 ├── logs/ │ ├── hermes.log ← 主运行日志 │ └── error.log ← 错误日志 └── cache/ ← 缓存文件
总计: 7 个目录,7 个核心文件
3. 进一步练习:让它帮你整理日志文件
You: 帮我清理一下 logs 目录,只保留最近 7 天的日志
Hermes: 我来帮你清理旧日志。
[工具调用: execute_shell] 命令: find ~/.hermes/logs -name "*.log" -mtime +7 -delete
✓ 已删除 7 天前的日志文件。 当前日志目录大小: 2.3 MB
> **Tips**
>
> 这三个练习覆盖了 Hermes 最常用的三大能力:信息检索、代码生成、文件操作。建议你每个练习都亲手操作一遍,建立肌肉记忆。完成这三个练习后,你已经具备了使用 Hermes 处理 80% 日常任务的能力。
**练习后的自我检查清单:**
完成所有练习后,请确认以下能力已经掌握:
- [ ] 能让 Hermes 搜索网页并总结信息
- [ ] 能让 Hermes 读取本地文件并分析内容
- [ ] 能让 Hermes 写代码并保存到本地
- [ ] 能让 Hermes 执行 shell 命令并查看结果
- [ ] 能让 Hermes 分析 CSV 数据并给出洞察
- [ ] 知道如何验证代码的正确性
- [ ] 知道如何安全地让 Hermes 执行系统命令
如果你有任何一项没掌握,请回到对应练习重新操作一遍。
### 练习 4:让 Hermes 帮你分析数据
**目标:** 练习 Hermes 的数据分析和可视化能力。
**步骤:**
1. 先创建一个示例数据文件:
```bash
cat > ~/sample-sales.csv << 'EOF'
月份,产品,销售额,成本
2026-01,产品A,12000,8000
2026-01,产品B,15000,9000
2026-02,产品A,11000,7500
2026-02,产品B,18000,10000
2026-03,产品A,14000,8500
2026-03,产品B,16000,9500
EOF
- 启动 Hermes 并分析数据:
You: 分析 ~/sample-sales.csv 的数据,计算每个月的总利润和利润率,
并给出数据洞察和可视化建议
练习扩展:
完成基础分析后,你可以继续挑战以下任务:
- 让 Hermes 生成一个完整的 Python 数据可视化脚本(使用 matplotlib 或 seaborn)
- 要求它预测下个月的销售额(基于现有趋势)
- 让它将分析结果保存为一份格式化的 Markdown 报告
- 要求它找出数据中的异常值并解释原因
Tips
数据分析是 Hermes 非常实用的功能之一。你可以直接把 Excel 或 CSV 文件丢给它,让它帮你做数据清洗、统计分析、趋势预测,甚至生成可视化图表。对于不擅长数据分析的开发者来说,这相当于拥有了一个随时待命的数据分析师。
预期输出:
Hermes: 让我来分析这份销售数据。
[工具调用: file_read]
路径: ~/sample-sales.csv
数据分析报告:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**1. 月度利润计算**
| 月份 | 总销售额 | 总成本 | 总利润 | 利润率 |
|-----|---------|-------|-------|-------|
| 2026-01 | 27,000 | 17,000 | 10,000 | 37.0% |
| 2026-02 | 29,000 | 17,500 | 11,500 | 39.7% |
| 2026-03 | 30,000 | 18,000 | 12,000 | 40.0% |
**2. 产品对比**
- 产品A:平均利润率 32.5%
- 产品B:平均利润率 43.0%
- 产品B 的利润贡献占比约 62%
**3. 数据洞察**
- 利润率逐月提升(37% → 39.7% → 40%),趋势良好
- 产品B 是高利润产品,建议加大推广力度
- 产品A 利润率偏低,需要优化成本结构
**4. 可视化建议**
你可以用以下 Python 代码生成图表:
```python
import pandas as pd
import matplotlib.pyplot as plt
df = pd.read_csv("~/sample-sales.csv")
df["利润"] = df["销售额"] - df["成本"]
df["利润率"] = (df["利润"] / df["销售额"] * 100).round(1)
# 月度利润趋势图
monthly = df.groupby("月份").agg({"利润": "sum"})
monthly.plot(kind="bar", title="月度利润趋势")
plt.show()
需要我帮你生成并保存这个可视化脚本吗?
---
## 9. 新手常见误区与最佳实践
### 9.1 误区 1:把它当搜索引擎用
**错误做法:**
You: 2026 年诺贝尔奖得主是谁?
**问题:** Hermes 不是搜索引擎,它的知识有截止日期,对于实时信息可能会给出错误答案。
**正确做法:**
You: 搜索一下 2026 年诺贝尔奖的最新消息
**区别:** 明确使用「搜索」指令,Hermes 会调用 `web_search` 工具获取最新信息,而不是依赖训练数据中的知识。
> **注意**
>
> 大语言模型的「幻觉」问题(一本正经地胡说八道)在回答事实性问题时最明显。对于时效性强的事实查询,一定要让 Agent 联网搜索,不要直接问。
### 9.2 误区 2:不给足够上下文
**错误做法:**
You: 帮我改一下这个代码
**问题:** 没有提供代码,Agent 无从改起。
**正确做法:**
You: 帮我审查一下 ~/project/main.py 的代码, 特别关注是否有内存泄漏和并发安全问题
或者直接把代码贴出来:
You: 帮我优化下面这段 Python 代码的性能:
# 你的代码在这里
目标是让处理 100 万条数据的时间从 30 秒降到 5 秒以内
> **Tips**
>
> 提供上下文的原则:「Agent 知道的越少,你告诉它的就要越多」。如果你是在一个持续的多轮对话中,上下文会自动维护;但如果是新会话或跳转到新话题,一定要补充背景信息。
### 9.3 误区 3:不利用记忆和技能系统
**错误做法:**
每次对话都重复说明相同的背景信息:
You: (第 1 次)我是做电商的,用 Python 开发 You: (第 2 次)我是做电商的,用 Python 开发 You: (第 3 次)我是做电商的,用 Python 开发 ...
**正确做法:**
把这些信息写入 SOUL.md 和 USER.md:
```markdown
# USER.md
## 基本信息
- 职业:电商全栈开发者
- 主要语言:Python
- 常用框架:Django、FastAPI、Vue.js
然后告诉 Agent:「更新 SOUL.md,添加电商行业的专业知识」。从此之后,每次启动 Hermes 都会自动加载这些信息。
9.4 更多常见误区
误区 4:忽视 SOUL.md 的作用
错误做法: 从不修改默认的 SOUL.md,每次对话都手动说明自己的偏好。
问题: 浪费大量 token 在重复说明上,而且 Agent 无法形成稳定的「人格记忆」。
正确做法: 花 20 分钟写一份好的 SOUL.md,之后每次启动 Hermes 都会自动加载。
误区 5:所有任务都用最强模型
错误做法: 不管问什么问题都用 Claude 3.5 Sonnet 或 GPT-5。
问题: 简单的「今天天气怎么样」也用 $0.03 的模型回答,一个月下来费用惊人。
正确做法: 配置分层模型,让 Hermes 自动选择最适合当前任务的模型。
误区 6:不及时清理对话历史
错误做法: 从不删除旧会话,数据库文件膨胀到几个 GB。
问题: 占用磁盘空间,搜索历史变慢,隐私风险增加。
正确做法: 每月运行一次 hermes chat cleanup --older-than 30d,同时备份重要会话。
误区 7:在公共环境中暴露 API Key
错误做法: 在共享服务器、公共仓库或截图中暴露 API Key。
问题: API Key 一旦泄露,可能被他人盗用,导致巨额账单。
正确做法: 始终通过环境变量管理 API Key,.gitignore 中排除 .env 文件,分享截图前打码敏感信息。
误区 8:不信任工具执行的安全提示
错误做法: 看到 Hermes 要执行 rm -rf 或修改系统文件时,不看详情直接确认。
问题: 虽然 Hermes 有安全机制,但用户确认是最后一道防线。误操作可能导致数据丢失。
正确做法: 每次工具执行前都仔细查看即将执行的命令,特别是涉及删除、修改系统配置的操作。
9.5 最佳实践清单(10 条)
- 定期备份数据
# 设置每周自动备份
(crontab -l 2>/dev/null; echo "0 3 * * 0 tar -czf ~/hermes-backup-$(date +\%Y\%m\%d).tar.gz ~/.hermes/config.yaml ~/.hermes/SOUL.md ~/.hermes/MEMORY.md ~/.hermes/USER.md ~/.hermes/database") | crontab -
- 使用分层模型节省费用
配置 config.yaml 中的 models.reasoning 和 models.execution,让简单任务用便宜模型,复杂任务用强模型。
- 善用 SOUL.md 定义 Agent 人格
花 30 分钟写一个好的 SOUL.md,之后每次对话都能受益。这比每次重复说明你的偏好高效得多。
- 重要信息存入 MEMORY.md
You: /memory add 我下周四要参加一个技术分享会,主题是关于 Hermes Agent
- 定期清理旧会话
# 删除 30 天前的会话
hermes chat cleanup --older-than 30d
- 使用 /compact 管理长对话
当对话超过 20 轮时,输入 /compact 压缩上下文,避免 token 费用暴涨。
- 敏感对话用 --private 模式
hermes --private
隐私模式不会保存对话历史到数据库。
- 配置 Fallback 链防止服务中断
在 config.yaml 中至少配置 2-3 个 fallback 模型,避免单一服务商故障导致 Agent 不可用。
- 利用定时任务自动化重复工作
# ~/.hermes/cron/jobs.yaml
jobs:
- name: daily-hn-summary
schedule: "0 9 * * *"
command: "搜索 Hacker News 今日热门,总结前 5 条发送到我的邮箱"
- 保持 Hermes 和技能更新
# 每周更新一次
hermes update
hermes skills update
进阶最佳实践(额外 5 条):
- 建立个人知识库
把你经常参考的资料、代码片段、笔记整理到 ~/.hermes/skills/custom/ 中,形成个人知识库。这样 Hermes 可以随时调用你的私有知识来回答问题。
- 使用版本控制管理配置
cd ~/.hermes
git init
git add config.yaml SOUL.md MEMORY.md USER.md
git commit -m "Initial Hermes config"
这样你可以追踪配置变更,误操作时随时回滚。
- 设置费用预警
在 config.yaml 中设置月度预算上限:
core:
monthly_budget: 100 # 美元
budget_alert_threshold: 0.8 # 用到 80% 时提醒
- 为不同项目创建独立工作区
# 项目 A
cd ~/project-a && hermes --workspace .
# 项目 B
cd ~/project-b && hermes --workspace .
每个工作区的上下文隔离,避免项目间的信息混淆。
- 定期 Review 和优化 SOUL.md
每个月花 10 分钟回顾 SOUL.md,根据实际使用体验调整:
# 查看 SOUL.md 当前内容
cat ~/.hermes/SOUL.md
# 让 Hermes 帮你评估 SOUL.md 的效果
hermes -c "评估我的 SOUL.md 配置,给出优化建议"
官方入门工作流示例
除了上面的基础练习,下面再介绍三个来自 Hermes 官方文档的经典入门工作流,帮助你快速将 Hermes 应用到实际场景中。
工作流 1:笔记本编程助手(审计仓库死代码)
这是一个适合开发者的场景:让 Hermes 分析你的代码仓库,找出未使用的函数、死代码和潜在问题。
使用方式:
# 进入你的项目目录
cd ~/my-project
# 启动 Hermes,指定工作目录
hermes --workspace .
对话示例:
You: 审计这个代码仓库,找出所有未使用的函数和导入,
以及任何明显的代码质量问题
Hermes: 我来审计这个仓库的代码质量。
[工具调用: execute_shell]
命令: find . -name "*.py" | head -20
[工具调用: file_read]
路径: ./main.py, ./utils.py, ./models.py
审计报告:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
**未使用的导入:**
- utils.py 第 3 行: import json(未使用)
- models.py 第 8 行: from datetime import timedelta(未使用)
**未使用的函数:**
- helpers.py 第 45 行: def format_date_old()(无调用点)
- api.py 第 120 行: def legacy_endpoint()(无调用点)
**代码质量问题:**
- main.py 第 78 行: 裸 except 语句,应捕获具体异常
- database.py 第 34 行: SQL 拼接存在注入风险,建议使用参数化查询
需要我生成修复后的代码吗?
Tips
这个工作流的关键在于
--workspace .参数,它让 Hermes 以当前目录为工作上下文。这样 Hermes 就能读取和分析项目中的文件,而不是只能进行通用对话。
工作流 2:$5 VPS 上的 Telegram 机器人
这是一个低成本、高价值的应用场景:在最便宜的 VPS 上部署一个 24/7 运行的 Hermes Telegram 机器人。
硬件要求:
- 任意 $3-5/月的 VPS(Hetzner CPX11、DigitalOcean Basic Droplet 等)
- 1 vCPU + 1GB RAM 完全够用
部署步骤:
# 1. 在 VPS 上安装 Hermes(参考第五册 VPS 部署章节)
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | sh
# 2. 配置 Hermes
hermes setup
# 3. 创建 Telegram Bot
# 在 Telegram 中搜索 @BotFather
# 发送 /newbot,按提示创建机器人
# 记下 Bot Token(格式: 123456789:ABCdefGHIjklMNOpqrsTUVwxyz)
# 4. 配置 Telegram 网关
hermes gateway config telegram --token "你的BotToken"
# 5. 设置安全允许列表(重要!)
# 只允许特定用户使用你的机器人,防止被滥用
配置允许列表:
# 在 ~/.hermes/config.yaml 中添加
gateway:
telegram:
token: "${TELEGRAM_BOT_TOKEN}"
allowed_users:
- 123456789 # 你的数字用户 ID
- 987654321 # 朋友的数字用户 ID
注意
Telegram 的安全设置中,允许列表需要填写数字用户 ID,不是 @handle(用户名)! 你可以通过以下方式获取自己的数字 ID: 1. 在 Telegram 中搜索 @userinfobot 2. 点击 Start,机器人会回复你的用户信息,其中 "Id" 就是数字用户 ID 3. 或者在 Telegram 中发送任意消息给 @getidsbot
填写错误的格式(如 @username)会导致消息过滤不生效,任何人都能使用你的机器人,消耗你的 API 额度!
启动机器人:
# 启动网关(前台运行测试)
hermes gateway start
# 测试正常后,使用 systemd 后台运行
sudo systemctl enable hermes
sudo systemctl start hermes
使用示例:
在 Telegram 中向你的机器人发送消息:
你: 帮我把这个 Python 函数改成异步的
def fetch_data(url):
return requests.get(url).json()
机器人: 好的,改成异步版本:
```python
import aiohttp
async def fetch_data(url):
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
return await response.json()
记得在调用处使用 await fetch_data(url)。
> **Tips**
>
> 这个工作流的成本极低:VPS 月费 $5 + API 调用费(轻度使用约 $1-5)= 每月不到 $10,你就拥有了一个 24/7 在线的私人 AI 助手。无论你在地铁上、咖啡馆里还是躺在床上,随时打开手机就能向它提问。
### 工作流 3:每日 Cron 简报(自动收集信息并发邮件)
这是一个自动化信息收集场景:每天早上自动抓取 Hacker News 热门、GitHub 通知、天气信息,然后生成一份简报发送到你的邮箱。
**配置步骤:**
```bash
# 1. 确保 Hermes 已安装并配置好模型
# 2. 编辑定时任务配置
nano ~/.hermes/cron/jobs.yaml
任务配置:
# ~/.hermes/cron/jobs.yaml
jobs:
- name: "morning-briefing"
description: "每日早间简报"
schedule: "0 8 * * *" # 每天早上 8 点
command: |
请帮我生成一份今日早报,包含以下内容:
1. 搜索 Hacker News 今日热门文章 Top 5,总结每条的核心内容
2. 检查我的 GitHub 通知,总结需要我关注的事项
3. 查询今天上海的天气
4. 查看今天是否有重要的技术会议或产品发布
将所有内容整理成一份结构清晰的 Markdown 简报,
标题为「早报 - YYYY年MM月DD日」,保存到 ~/briefings/ 目录
enabled: true
- name: "send-daily-email"
description: "发送早报邮件"
schedule: "30 8 * * *" # 每天早上 8:30(简报生成后)
command: |
读取 ~/briefings/ 目录下最新的早报文件,
将其内容作为邮件正文,发送到 myemail@example.com
邮件主题:「Hermes 早报 - 今日日期」
enabled: true
启用定时任务:
# 验证配置格式
hermes cron validate
# 查看任务列表
hermes cron list
# 手动测试运行
hermes cron run morning-briefing
# 确认任务已启用
hermes cron status
Tips
这个工作流展示了 Hermes 的「自动化」能力。一旦配置完成,它每天会自动执行,不需要你手动干预。你可以根据自己的需求定制简报内容,比如添加股票监控、RSS 订阅源、竞品动态等。Cron 任务的语言支持自然语言描述,不需要写复杂的脚本——这是 Hermes 相比传统自动化工具的独特优势。
本章小结
恭喜你完成了 Hermes 基础使用入门的全部学习!让我们回顾一下本章的核心要点:
-
Quick Setup 向导 是配置 Hermes 的第一步。新手推荐选择 DeepSeek 或 OpenRouter 作为入门模型,零成本或低成本就能开始体验。
-
对话模式 中,Hermes 会自动维护上下文、调用工具完成实际任务。善用多轮对话,像和朋友聊天一样自然地与 Agent 交流。
-
斜杠命令(
/help、/model、/memory等)是高效操控 Agent 的快捷键,熟练掌握它们能显著提升使用效率。 -
模型接入 非常灵活,支持 20+ 提供者。国内用户优先推荐 DeepSeek(性价比最高)和 Kimi(长文本最强)。
-
分层模型配置 是省钱的核心秘诀。核心逻辑用 Claude/GPT-5,日常执行用 DeepSeek,实测可节省 50%-70% 的费用。
-
SOUL.md 是定义 Agent 人格的魔法文件。花点时间写一个好的 SOUL.md,你的 Agent 会变得与众不同。
-
三个实战练习(搜索总结、代码编写、文件管理)让你立刻上手。三个官方工作流(编程助手、Telegram 机器人、Cron 简报)展示了 Hermes 在实际场景中的应用。
-
避免三大误区:不要把 Hermes 当搜索引擎、要给足上下文、要善用记忆和技能系统。
现在,你已经掌握了 Hermes 的基础操作。下一册「三层记忆系统详解」将带你深入理解 Hermes 的记忆机制,学会如何让 Agent 真正「记住」你、越用越懂你。让我们继续「养马之旅」!
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第七册:三层记忆系统详解
本章你将学到
- 为什么记忆系统是 Hermes Agent 区别于普通聊天机器人的核心竞争力
- Hermes 独创的「四层温度记忆模型」是如何工作的
- 会话记忆(热记忆)的 Token 管理策略和 /compact 命令的使用技巧
- 持久记忆(温记忆)中 MEMORY.md 和 USER.md 的详细配置方法
- 检索记忆(冷记忆)的 SQLite + FTS5 架构和智能检索机制
- Honcho、Mem0 等外部记忆扩展方案的集成方法
- SOUL.md 深度配置模板和隐私安全最佳实践
- 记忆系统的日常维护、排障和高级调优技巧
1. 为什么记忆系统是 Hermes 的核心竞争力
1.1 Agent 没有记忆会怎样——上下文爆炸的痛苦
想象一下,你请了一位秘书,但这位秘书有个致命缺陷:每次你跟他讲完一件事,他转身就忘得一干二净。你不得不把同样的话重复说一百遍。更糟糕的是,这位秘书的脑袋(上下文窗口)还很小,塞不下太多信息。当你交代一个稍微复杂点的任务时,他前面记住的内容就会被后面的内容挤掉,就像往一个装满水的杯子里继续倒水,旧的记忆不断溢出来。
这就是没有记忆系统的 AI Agent 的真实写照。
让我们看一个具体的例子。假设你要让 Agent 帮你做一个「季度投研报告」,这个任务需要:
- 先搜索某行业的最新新闻(10条结果)
- 用 Python 分析这些新闻的情感倾向
- 结合财务数据生成图表
- 把图表插入到报告模板中
- 输出最终的 PDF 文件
如果没有记忆系统,会发生什么呢?
当你在第3步说「用刚才爬取的数据做分析」时,Agent 可能会一脸茫然地问:「什么数据?我刚才没保存任何数据啊。」因为它在前两步的工具调用结果,如果没有被妥善记录到上下文中,就会像写在沙滩上的字一样被潮水冲走。
即使你的大模型有 128K 的上下文窗口(相当于能记住约 10 万字的文本),在长时间、多步骤的复杂任务中,Token 消耗也会像滚雪球一样越滚越大。每一次工具调用的结果、每一条系统提示、每一个中间变量,都在无情地吞噬着有限的上下文空间。当上下文接近上限时,模型要么开始「失忆」(遗忘早期信息),要么响应速度急剧下降,要么干脆报错退出。
这种「上下文爆炸」的痛苦,是每个深度使用 AI Agent 的用户都经历过的。它直接限制了 Agent 能够处理任务的复杂度,也严重影响了用户体验的连贯性。
注意
很多新手会误以为「上下文窗口越大越好」。确实,从 4K 到 128K 甚至 200K 的窗口扩展,让单次对话能处理的信息量变大了。但窗口大不等于记忆好——它只是「短期记忆」的容量变大了。如果没有智能的记忆管理系统,再大的窗口也会在复杂任务中被填满,而且成本会呈指数级增长。
1.2 传统 Agent 的记忆方案及其局限
在 Hermes 出现之前,开源社区对 Agent 记忆问题的解决方案大致可以分为以下几类:
方案一:纯上下文记忆(即无记忆方案)
这是最原始的方式,也是很多早期 Agent 框架(如最初的 AutoGPT)采用的方式。所有信息都依赖大模型的上下文窗口来承载。优点是简单直接,缺点是前面已经详细描述过了——上下文爆炸、Token 成本高、无法跨会话保留信息。
方案二:向量数据库(Vector DB)记忆
这是目前最主流的方案,包括使用 Pinecone、Weaviate、Milvus、Chroma 等向量数据库来存储和检索记忆。工作原理是将文本转为向量(Embedding),通过向量相似度来检索相关内容。
这种方案的问题在于:
- 检索精度依赖 Embedding 质量:如果向量模型不能准确理解语义,检索结果就会偏差很大。比如用户说「上次我提到的那个项目」,Agent 可能检索到完全不相关的内容。
- 无法精确匹配关键词:向量相似度擅长找「意思相近」的内容,但不擅长找「包含某个确切词语」的内容。如果你说「把上次生成的那个叫『报表_v2』的文件发给我」,向量检索很可能找不到精确匹配。
- 冷启动问题:新数据刚写入向量数据库时,检索效果往往不好,需要积累一定量数据后才能发挥作用。
- 运维成本高:需要额外部署和维护向量数据库服务,增加了系统复杂度。
方案三:简单的文件持久化
一些轻量级方案会把重要信息写入本地文件(如 JSON、TXT),下次启动时读取。这种方式虽然实现了跨会话记忆,但缺乏智能的检索和筛选机制——要么一次性加载所有内容(可能文件很大),要么只能按固定规则读取(不够灵活)。
方案四:外部记忆服务
如 Mem0、Zep 等专门的记忆服务。它们通常提供云端 API,负责记忆的存储、检索和更新。这种方案的问题是:
- 数据离开本地:敏感信息需要上传到第三方服务器
- 网络依赖:没有网络就无法工作
- 额外成本:大多数服务需要付费使用
- 延迟较高:每次记忆操作都需要网络请求
1.3 Hermes 记忆系统的设计哲学:让 AI 像人一样记忆
Hermes 的设计团队在研究了大量用户反馈和现有方案的局限后,提出了一个核心问题:人类是怎么记忆的?
与很多 Agent 框架追求「无限记忆」不同,Hermes 走了一条截然相反的路——有界记忆(Bounded Memory)。官方的设计理念非常明确:无限记忆听起来诱人,但会让 Agent 变成一个「垃圾杂物抽屉」,什么都往里塞,最后连自己有什么都记不住。Hermes 强制整合:当 MEMORY.md 满时,Agent 必须主动决定什么值得保留、什么应该丢弃。这种「纪律」保持了工作上下文的精简,让模型始终专注在真正重要的事情上。
正如 Hermes Atlas 官方文档所说:「Claude Code 的 memory 存储关于你的事实——偏好要点。而 Hermes 存储的是程序——产生你想要的要点的研究-过滤-格式化工作流。事实告知模型,程序直接被复用。」这句话精准地概括了 Hermes 记忆系统的本质:它不仅记住「是什么」,更记住「怎么做」。
人类记忆系统不是单一的结构,而是由多个层次组成的精妙体系:
- 工作记忆(短期记忆):你正在思考的事情,容量极小(约 4-7 个信息单元),但访问速度极快。
- 情景记忆(中期记忆):最近发生的事情,比如今天早上吃了什么、昨天和谁聊了天。容量中等,需要主动回忆才能提取。
- 语义记忆(长期记忆):你学会的知识和技能,比如知道 2+2=4、知道北京是中国的首都。容量几乎无限,但需要线索才能激活相关部分。
- 外部记忆:你写在笔记本上的备忘、存在电脑里的文档、书架上的书籍。容量不受限,但需要主动查找。
Hermes 的记忆系统正是借鉴了这种分层架构,创造了「四层温度记忆模型」。它的设计哲学可以总结为三条核心原则:
原则一:分层存储,各尽其用
不同温度(时效性)的记忆,存放在不同层级的存储介质中。热数据放在内存中快速访问,温数据放在文件中持久保存,冷数据放在数据库中按需检索。就像你不会把全家老小的照片都贴在工作电脑的桌面上,而是会分类存放在不同的位置。
原则二:按需加载,而非全量加载
传统方案最大的问题之一是「启动时加载所有记忆」。想象一下,你每天早上上班,秘书都要把过去十年的所有会议记录、邮件往来、项目文档都摆在你面前——这不仅浪费你的时间,还会让你被海量信息淹没,找不到真正需要的东西。
Hermes 采用的是「按需检索」策略:Agent 在新对话开始时,不会加载全部历史记录,而是根据当前话题智能检索最相关的片段。这大大降低了 Token 消耗,也避免了信息过载。
原则三:纯本地优先,隐私至上
所有记忆数据默认存储在本地 SQLite 数据库和 Markdown 文件中。你的对话内容、行为习惯、个人偏好,都不会离开你的电脑。这对于处理敏感信息(如企业内网数据、个人隐私数据)至关重要。
1.4 三层记忆 vs 传统方案的优势对比
为了让你更直观地理解 Hermes 记忆系统的优势,我们来做一个横向对比:
| 对比维度 | 纯上下文记忆 | 向量数据库方案 | 简单文件持久化 | Hermes 四层记忆 |
|---|---|---|---|---|
| 跨会话记忆 | 无 | 有 | 有 | 有 |
| 检索精度 | 无检索 | 语义相似度 | 无检索 | FTS5 全文 + LLM 摘要 |
| 启动速度 | 快 | 中等 | 中等 | 快(按需加载) |
| Token 成本 | 极高 | 中等 | 低 | 极低(按需检索) |
| 本地隐私 | 有 | 依赖部署 | 有 | 完全本地 |
| 运维复杂度 | 低 | 高 | 低 | 低(SQLite 内置) |
| 用户画像 | 无 | 无 | 无 | 自动建模(USER.md) |
| 自我压缩 | 无 | 无 | 无 | /compact 智能压缩 |
| 外部扩展 | 无 | 有 | 无 | Honcho/Mem0/OpenViking |
从这个对比表中可以清楚地看到,Hermes 的四层记忆模型在几乎所有维度上都做到了优秀或良好,而且是一个开箱即用的「全家桶」方案——你不需要单独部署向量数据库、不需要写复杂的检索逻辑、不需要担心数据隐私,一切都内置在 Hermes 中,只需要简单的配置就能工作。
Tips
如果你是技术人员,可能会问:「向量检索在某些场景下确实很有用,Hermes 不支持吗?」答案是支持的!通过外部记忆扩展(如 Mem0),你可以无缝集成向量检索能力。但 Hermes 的默认方案选择 FTS5 全文索引作为主力检索引擎,是因为在大多数实际场景中,精确的关键词匹配比语义相似度更可靠、更可预测。
2. 总览:四层温度记忆模型
2.1 热记忆(即时)—— 当前会话上下文
热记忆是最「热」的记忆,就像你大脑中正在思考的内容一样,访问速度最快,但容量最小,而且会随着会话结束而消失。
在 Hermes 中,热记忆就是当前会话的上下文窗口。它包含了:
- 当前对话中你和 Agent 的所有消息
- 最近一次工具调用的结果
- 系统提示(System Prompt)和 SOUL.md 的内容
- 当前激活的 Skill 的上下文
热记忆的特点可以用三个词概括:快、小、暂存。
- 快:所有数据都在内存中,访问延迟几乎为零
- 小:受限于大模型的上下文窗口(通常是 4K-200K Tokens)
- 暂存:会话结束或 /compact 执行后,部分内容会被压缩或丢弃
2.2 温记忆(持久)—— MEMORY.md + USER.md
温记忆就像你写在便利贴上的重要提醒,或者是你手机备忘录里的关键信息。它们不像热记忆那样随时在眼前,但比翻查旧笔记本要快得多。
Hermes 的温记忆由两个核心文件组成:
MEMORY.md:存储与任务相关的持久化信息。比如:
- 「用户要求所有 Python 代码都使用 Type Hints」
- 「当前项目的 Git 仓库地址是 https://github.com/user/project」
- 「上次分析的那只股票代码是 600519」
USER.md:存储用户画像和行为模式。比如:
- 「用户喜欢用中文交流,但技术术语保留英文」
- 「用户在上午 9-11 点效率最高,适合安排复杂任务」
- 「用户对深度学习话题感兴趣,对区块链话题不感兴趣」
这两个文件都是纯文本的 Markdown 格式,存储在 Hermes 的配置目录中。它们的容量被严格限制(MEMORY.md 约 2200 字符,USER.md 约 1375 字符),这是经过精心设计的——如果文件太大,每次加载都会消耗大量 Token;如果太小,又无法记录足够有用的信息。
2.3 冷记忆(检索)—— SQLite + FTS5 + LLM 摘要
冷记忆就像你书架上排列整齐的档案柜,或者是电脑里分门别类的文件夹。里面存储了海量的历史信息,但你不会一次性把它们全部搬到桌面上,而是需要时去查找。
Hermes 的冷记忆系统由三个核心组件构成:
SQLite 数据库:轻量级的本地关系型数据库,存储所有的历史对话、工具调用结果、文件操作记录等。一个 SQLite 文件就是一个完整的数据库,不需要单独的服务进程。
FTS5 全文索引:SQLite 内置的全文搜索引擎。你可以把它理解为一个小型的「本地 Google」——输入关键词,它能瞬间从海量文本中找到包含这些词的记录。
LLM 摘要:利用大语言模型的能力,自动为每次会话生成简明扼要的摘要。这些摘要也会被索引到 FTS5 中,让你在搜索时能更快地定位到相关会话。
冷记忆的核心设计思想是「按需检索」。当你开启一个新会话时,Hermes 不会把过去一年的所有对话都加载到上下文中,而是:
- 分析你当前输入的内容,提取关键词
- 用 FTS5 在历史记录中检索相关片段
- 只把最相关的几条记录(通常 3-5 条)提取出来
- 将这些相关片段注入到当前上下文中
这种方式让 Agent 拥有了「回想」能力,同时又不会因为记忆太多而「大脑过载」。
2.4 外部记忆(扩展)—— Honcho、Mem0 等
外部记忆是四层模型的最外层,相当于你的个人图书馆、云端笔记、或者是请了一位专门帮你整理资料的研究助理。它们不是 Hermes 内置的,但可以通过插件或 API 无缝集成。
目前支持的外部记忆方案包括:
- Honcho:专门用于推导用户行为模式的记忆模块
- Mem0:强大的记忆管理平台,支持向量检索
- OpenViking:面向企业级场景的记忆扩展
- 以及更多社区开发的记忆插件
外部记忆的优势在于专业化和扩展性。比如 Honcho 在用户行为建模方面比 Hermes 内置的 USER.md 更深入;Mem0 在跨设备同步方面有独到之处。但它们的缺点是需要额外配置,且部分服务涉及数据外传。
2.5 各层的容量、速度、成本对比表
| 记忆层级 | 存储介质 | 典型容量 | 访问速度 | Token 成本 | 持久性 | 检索方式 |
|---|---|---|---|---|---|---|
| 热记忆 | 内存(上下文窗口) | 4K-200K Tokens | 毫秒级 | 高(全部计费) | 会话级 | 直接访问 |
| 温记忆 | 本地 Markdown 文件 | ~3.5K 字符 | 毫秒级 | 低(固定大小) | 永久 | 全量加载 |
| 冷记忆 | SQLite + FTS5 | 无上限 | 百毫秒级 | 极低(只加载相关片段) | 永久 | 全文检索 |
| 外部记忆 | 网络服务/外部 DB | 依赖服务 | 百毫秒-秒级 | 依赖服务 | 依赖服务 | 依赖服务 |
2.6 类比:就像人的短期记忆、长期记忆、笔记本、图书馆
为了让四层记忆模型更加直观,我用一个生活中的类比来总结:
想象一下你正在准备一个重要的演讲。
热记忆就像你此刻脑中正在构思的内容。你正在想「第一页 PPT 要讲团队介绍」,这个念头在你的意识中非常清晰,但如果你想别的事情,这个念头可能就会被挤掉。这就是工作记忆的容量限制。
温记忆就像你贴在显示器边缘的便利贴。上面写着「演讲时间:15分钟」「重点强调 Q3 业绩」「别忘提到新客户案例」。你不需要去翻笔记本,一眼就能看到。但如果便利贴太多,你反而会找不到重点,所以温记忆的容量被刻意限制了。
冷记忆就像你的笔记本和电脑文件夹。过去半年里,你做的每一次演讲、每一份报告、每一条客户反馈,都记录在里面。你不会在准备演讲时把过去半年的所有文件都摊开,而是会根据「这次演讲的主题」去搜索相关资料——找到其中 3-5 份最相关的文档,提取关键内容。
外部记忆就像你公司里的资料室,或者是国家图书馆。里面有海量的专业书籍、行业报告、历史档案。你需要的时候可以去查阅,获取更深入、更全面的信息。但去图书馆需要时间和交通成本,所以你通常先在笔记本里找,找不到再去图书馆。
常见问题
Q:为什么温记忆的容量这么小?只有几千字符?
A:这是经过深思熟虑的设计。温记忆(MEMORY.md + USER.md)每次会话都会完整加载到上下文中。如果它们太大,会挤占宝贵的上下文空间,导致热记忆可用容量减少。限制容量的另一个原因是「逼迫 Agent 做选择」——不是什么都记,而是只记最重要、最精炼的信息。这就像一个优秀的秘书,不会把你说的每句话都记下来,而是只记关键点。
3. 第一层:会话记忆(热记忆)
3.1 会话上下文的工作原理
会话记忆(热记忆)是 Hermes 记忆系统的最前线,也是你作为用户最直接感受到的部分。理解它的工作原理,能帮助你更高效地与 Agent 协作。
当你启动 Hermes 并开始一段对话时,系统会构建一个「上下文窗口」(Context Window)。这个窗口里装的不是简单的聊天记录,而是一个精心编排的「信息包」,按照固定的顺序排列:
[系统提示 / System Prompt]
↓
[SOUL.md 内容]
↓
[激活的 Skill 说明]
↓
[MEMORY.md 内容(温记忆注入)]
↓
[检索到的相关历史片段(冷记忆注入)]
↓
[当前对话历史]
↓
[用户的最新输入]
这个顺序是有讲究的。越靠前的内容,在模型处理时的「注意力权重」通常越高(具体取决于模型架构,但一般来说位置越靠前越不容易被遗忘)。所以 Hermes 把最重要的系统指令放在最前面,把动态的对话历史放在后面。
让我们看一个具体的例子。假设你正在使用 Hermes 分析一份财报,上下文窗口的内容可能如下(简化版):
System: 你是一个专业的财务分析助手...
SOUL.md: [用户的个人偏好和角色设定]
Skill: financial_analysis v2.1 [激活的财务分析技能]
MEMORY.md: 用户关注白酒行业,上次分析的是贵州茅台(600519)
冷记忆片段: [上次对话中关于ROE分析的结论]
User: 帮我分析一下五粮液今年的三季报
Assistant: 好的,我来获取五粮液(000858)的最新三季报数据...
[工具调用结果:获取到的财务数据]
User: 和茅台对比一下毛利率
Assistant: [分析中...]
每次你发送新消息,或者 Agent 执行工具调用后,这个上下文窗口都会被更新。窗口里的内容越多,发送给大模型的 Token 数就越多,响应时间越长,成本也越高。
Tips
如果你使用的是按 Token 计费的商业模型(如 GPT-4、Claude),上下文窗口里的每一条信息都在计费范围内——包括系统提示、SOUL.md、MEMORY.md、历史对话。所以理解上下文构成,能帮助你优化成本。使用
hermes status命令可以查看当前会话的 Token 使用情况。
3.2 Token 窗口管理策略
Token 窗口管理是热记忆的核心挑战。想象你的上下文窗口是一个容量固定的背包(比如能装 1000 个 Tokens),每次对话都在往里面塞东西。当背包快满的时候,你该怎么办?
Hermes 采用了一套智能的 Token 管理策略,主要包含以下几个机制:
机制一:固定保留区 + 动态对话区
上下文窗口被划分为两个区域:
- 固定保留区:系统提示、SOUL.md、温记忆(MEMORY.md + USER.md)。这部分内容每次请求都必须包含,占用固定的 Token 预算。
- 动态对话区:实际的对话历史和工具调用结果。这部分是弹性变化的,当空间不足时需要被压缩或截断。
假设你使用的是一个 32K 上下文的模型:
总容量:32,000 Tokens
固定保留区:~2,000 Tokens(系统提示 + SOUL.md + 温记忆)
动态对话区可用:~30,000 Tokens
机制二:FIFO(先进先出)截断
当动态对话区超出容量时,Hermes 会采用「先进先出」的策略,截断最早的对话消息。也就是说,你最早说的话会被逐渐「遗忘」,最近的消息会被保留。
但这里有个重要的例外:工具调用和工具调用结果通常会被优先保留。因为它们是 Agent 实际执行任务的证据,如果丢失了,Agent 可能会重复执行已经做过的事情。
机制三:智能压缩(/compact)
这是 Hermes 最具特色的功能之一。当对话越来越长时,你可以主动执行 /compact 命令,让 Agent 对当前会话的内容进行智能压缩。具体过程如下:
- Agent 回顾整个对话历史
- 识别出关键信息(决策、结论、重要的中间结果)
- 用简洁的语言把这些关键信息总结成一段话
- 将总结替换掉原来的长对话,释放大量 Token 空间
- 把这次压缩的摘要存入 SQLite,方便以后检索
/compact 的效果通常非常显著。一个 50 轮对话、消耗 15,000 Tokens 的会话,经过压缩后可能只需要 500 Tokens 就能保留全部关键信息。
注意
/compact是一个「有损压缩」。它会丢弃对话中的细节(比如具体的思考过程、不重要的闲聊),只保留结论和关键决策。如果你需要保留完整的对话记录用于审计或复盘,建议在执行/compact之前先用hermes export导出会话。
3.3 /compact 命令:智能压缩上下文
/compact 是 Hermes 最强大的热记忆管理工具之一。让我们深入了解它的使用方法和内部逻辑。
基本用法:
在 Hermes 的交互界面中,任何时候你都可以输入:
/compact
Agent 会立即开始压缩过程。你会看到类似这样的输出:
正在压缩会话上下文...
✓ 已识别 12 个关键决策点
✓ 已提取 5 条重要结论
✓ 已总结 3 个工具调用结果
压缩完成:15,420 Tokens → 486 Tokens(节省 96.8%)
摘要已保存至数据库,ID: conv_20260421_001
什么时候应该用 /compact?
| 场景 | 建议 |
|---|---|
| 对话已经超过 30 轮 | 强烈建议使用 |
| 工具调用超过 10 次 | 建议使用 |
| 上下文 Token 超过总容量的 70% | 必须使用 |
| 感觉 Agent 开始「遗忘」早期内容 | 立即使用 |
| 正在执行一个长期、多步骤的任务 | 每完成一个阶段就使用一次 |
| 对话即将结束,想保留关键信息 | 结束前使用 |
自动压缩配置:
你可以在 config.yaml 中设置自动压缩的触发条件:
# config.yaml 中的记忆相关配置
memory:
# 当上下文 Token 数超过此阈值时自动触发压缩
auto_compact_threshold: 12000
# 是否启用自动压缩
auto_compact_enabled: true
# 压缩时保留的最近消息数(这些消息不会被压缩)
preserve_recent_messages: 5
常见问题
Q:/compact 会删除我的原始对话记录吗?
A:不会。
/compact只会影响当前加载到上下文窗口中的内容。完整的原始对话仍然保存在 SQLite 数据库中,你可以随时用hermes history查看完整记录。压缩只是让当前工作内存更精简。Q:压缩后 Agent 还能回答关于细节的问题吗?
A:如果细节在压缩过程中被丢弃了,Agent 就无法直接回答。但它可以通过检索冷记忆(SQLite 中的完整记录)来查找原始细节。你可以明确告诉它「去数据库里查一下详细记录」。
3.4 上下文溢出时的处理机制
当上下文窗口达到极限时,Hermes 有一套优雅的处理机制,确保系统不会崩溃,同时尽量保留最重要的信息。
溢出检测:
每次发送请求前,Hermes 会计算当前上下文的 Token 数。如果加上即将发送的消息后超过模型容量,就会触发溢出处理。
处理流程(按优先级):
1. 检查是否可以使用 /compact
↓ 是 → 自动执行压缩
↓ 否(压缩后仍然溢出)→ 下一步
2. 截断动态对话区(FIFO)
- 从最早的对话开始删除
- 保留工具调用和结果
- 保留最近的 3-5 轮对话
↓ 仍然溢出 → 下一步
3. 缩减冷记忆注入
- 减少检索到的历史片段数量
- 缩短每个片段的长度
↓ 仍然溢出 → 下一步
4. 缩减温记忆注入
- 临时不加载 USER.md(只保留 MEMORY.md)
↓ 仍然溢出(极罕见)→ 下一步
5. 报错提示用户
- "当前会话上下文已达到极限,建议开启新会话"
这种分层降级策略确保了在绝大多数情况下,系统都能自动恢复,而不需要用户手动干预。
3.5 最佳实践:如何让单次会话效率最高
经过前面的讲解,你应该已经理解了热记忆的工作原理。下面是经过社区大量实践总结出的最佳实践:
实践一:定期使用 /compact
不要让对话无限增长。建议每完成一个任务阶段就压缩一次。就像你写完一个章节就保存一次文档一样,这是良好的工作习惯。
# 示例:一个多阶段任务中的压缩策略
User: 帮我分析一下 Q3 的财报数据
[Agent 执行分析...]
User: /compact # 第一阶段完成,压缩
User: 基于刚才的分析,生成一份 PPT 大纲
[Agent 生成大纲...]
User: /compact # 第二阶段完成,压缩
User: 把大纲导出为 Markdown 文件
[Agent 导出...]
实践二:善用 MEMORY.md 记录跨会话信息
如果你知道某个信息在后续会话中还会用到,直接告诉 Agent 把它写入 MEMORY.md:
User: 把这个项目的 Git 地址记住:github.com/mycompany/project-alpha
Agent: 已记录到 MEMORY.md
User: 以后提到 "alpha 项目" 就是指这个仓库
Agent: 已更新 MEMORY.md
这样下次会话开始时,Agent 就会自动知道这些信息,不需要你重复交代。
实践三:避免在单一会话中处理过多不相关的任务
如果你刚让 Agent 分析了财报,接下来想让它帮你写一封邮件,建议开启新会话。因为财报分析的上下文对写邮件没有帮助,反而会挤占 Token 空间。你可以这样:
# 不推荐:在同一个会话中混杂不相关任务
User: 分析财报...
[20轮对话后...]
User: 对了,帮我写封邮件给李总 # 浪费Token
# 推荐:任务切换时开启新会话
User: /new # 开启新会话
User: 帮我写封邮件给李总...
实践四:明确指定需要保留的信息
在复杂任务中,如果你知道某些中间结果特别重要,可以明确告诉 Agent:
User: 这个 API 的认证令牌很重要,请把它记录到 MEMORY.md 中
Agent: 已记录:API认证令牌 = sk-abc123...
User: 刚才生成的那个 SQL 查询语句,摘要里一定要保留
Agent: 已将该 SQL 查询标记为重要,压缩时会优先保留
实践五:关注 Token 使用情况
定期使用 hermes status 查看当前 Token 消耗:
$ hermes status
会话状态
========
会话ID: session_20260421_001
模型: claude-3-7-sonnet-20250219
上下文窗口: 32,000 Tokens
已使用: 18,450 Tokens (57.7%)
固定保留区: 2,100 Tokens
动态对话区: 16,350 Tokens
建议: 上下文使用率较高,建议在 80% 前执行 /compact
当使用率超过 70% 时,就应该考虑压缩或结束当前任务了。
Tips
很多用户有个误区:认为「单轮对话越长越好」。实际上,Agent 的效率不在于单轮对话的长度,而在于信息的组织方式。把一个大任务拆分成多个小任务,每个任务在独立的压缩单元中完成,整体效率往往更高。
4. 第二层:持久记忆(温记忆)
4.1 MEMORY.md 文件详解
MEMORY.md 是 Hermes 持久记忆系统的核心文件之一。它的作用就像是 Agent 的「随身记事本」——里面记录着与当前任务、当前项目、当前环境相关的关键信息。每次会话开始时,这个记事本的内容都会被加载到上下文中,让 Agent 能够「记得」之前交代过的重要事项。
4.1.1 文件结构与格式
MEMORY.md 采用纯 Markdown 格式存储,这有两个好处:一是人类可以直接阅读和编辑,二是 Markdown 的结构性让 Agent 更容易理解其中的内容层次。
默认情况下,MEMORY.md 位于:
~/.hermes/memory/MEMORY.md
文件的基本结构如下:
# Memory
## Project Context
- 项目名称:智能客服系统升级
- 技术栈:Python 3.11 + FastAPI + PostgreSQL
- Git 仓库:github.com/company/customer-service-v2
## Key Decisions
- 使用 JWT 进行身份认证,Token 有效期 24 小时
- 数据库迁移工具选用 Alembic,不选 Django ORM
- API 响应格式统一为 JSON:API 规范
## Important Notes
- 生产环境数据库密码不要在对话中明文展示
- 测试服务器地址:http://test-api.company.internal
- 部署前必须先跑完整测试套件
## Current Focus
- 正在实现订单查询接口的缓存层(Redis)
- 预计本周五完成压力测试
你可以看到,这个文件分为几个逻辑区块(用 ## 二级标题分隔),每个区块下面用列表形式记录具体事项。这种结构既清晰又节省空间。
注意
MEMORY.md 的容量被限制在约 2200 字符(具体值可能因版本略有差异)。这不是一个硬性的技术限制,而是一个「软约束」——当内容接近上限时,Agent 会主动压缩或合并旧条目。如果你的 MEMORY.md 经常写满,说明记录的信息不够精炼,需要学习如何提取「真正重要的」信息。
4.1.2 自动写入机制
MEMORY.md 最智能的地方在于:Agent 会自动判断哪些信息值得记录,哪些不值得。
当你与 Agent 对话时,系统会在后台运行一个「记忆评估器」。这个评估器会分析对话内容,根据以下标准判断信息的重要性:
高优先级(几乎一定会记录):
- 用户明确说「记住这个」「记下来」「以后都要用」
- 关键配置信息(API 密钥、服务器地址、数据库连接串)
- 重要的决策和结论(「我们决定用方案 A 而不是方案 B」)
- 项目相关的上下文(项目名称、技术栈、特殊要求)
中优先级(根据上下文判断是否记录):
- 用户的偏好设置(「我喜欢深色主题」「用中文回复」)
- 中间计算结果(如果后续步骤会用到)
- 错误和解决方案(「上次是因为权限不足导致的」)
低优先级(通常不记录):
- 临时性的查询(「今天北京天气怎么样」)
- 已经被执行的命令的具体输出(保留命令本身,不保留输出)
- 闲聊内容
自动写入的触发时机通常是在:
- 用户明确指示记录时:即时写入
- 任务成功完成时:总结关键信息并写入
- 发生重要决策时:即时写入
- 会话结束时:回顾整个对话,补录遗漏的重要信息
4.1.3 手动编辑方法
虽然自动写入很方便,但有时候你需要手动编辑 MEMORY.md。Hermes 提供了几种方式:
方式一:通过命令行直接编辑
# 使用你喜欢的编辑器打开 MEMORY.md
nano ~/.hermes/memory/MEMORY.md
# 或者
vim ~/.hermes/memory/MEMORY.md
# 或者
code ~/.hermes/memory/MEMORY.md # VS Code
方式二:在对话中让 Agent 帮你编辑
User: 帮我在 MEMORY.md 里加一条:测试环境的 Redis 端口是 6380
Agent: 已添加。
User: 把 MEMORY.md 里关于 JWT 的那条删掉,我们改用 Session 了
Agent: 已删除 JWT 相关条目,并添加了新条目:身份认证改为 Session-Cookie 方案。
User: 给我看看现在的 MEMORY.md
Agent: [展示当前 MEMORY.md 的完整内容]
方式三:使用 /memory 命令系列(详见第7章)
/memory add "生产服务器 IP: 192.168.1.100"
/memory remove "JWT" # 删除包含"JWT"的条目
/memory show # 显示当前内容
4.1.4 容量限制(~2200字符)与管理策略
2200 字符大约是 700-800 个汉字,或者 300-400 个英文单词。这个容量看起来不大,但如果使用得当,足以记录一个中等复杂度项目的所有关键信息。
高效利用容量的技巧:
- 使用列表而非段落:列表更节省空间,也更容易被 Agent 解析
# 好:简洁的列表
- API 基地址: https://api.example.com/v2
- 认证方式: Bearer Token
- 超时设置: 30s
# 差:冗长的段落
API 的基地址是 https://api.example.com/v2,这是生产环境的地址。
认证方式我们选用了 Bearer Token,因为相比 Basic Auth 它更安全。
请求的超时时间设置为 30 秒,这是考虑到网络延迟和服务器响应速度...
-
定期清理过期信息:项目结束后,把不再相关的条目删掉
-
合并相似条目:如果有三条都是关于数据库配置的,合并成一条
-
使用缩写和代码:技术术语用标准缩写,节省空间
# 好
- DB: PostgreSQL 15, host=db.internal, port=5432
- ORM: SQLAlchemy 2.0 + Alembic
# 差
- 数据库使用的是 PostgreSQL 的第 15 个版本...
- 对象关系映射工具选用了 SQLAlchemy...
- 分级管理:如果同时处理多个项目,可以用不同的 MEMORY.md 文件
# 为不同项目使用不同的记忆文件
~/.hermes/memory/MEMORY.md # 默认
~/.hermes/memory/project_a_MEMORY.md # 项目A
~/.hermes/memory/project_b_MEMORY.md # 项目B
在对话中切换:
User: 切换到项目 A 的上下文
Agent: 已加载 project_a_MEMORY.md
4.1.5 实际 MEMORY.md 示例
以下是一个真实的 MEMORY.md 示例(来自一个实际使用 Hermes 进行 Web 开发的开发者):
# Memory
## Project
- Name: E-commerce Dashboard
- Stack: Next.js 14 + Tailwind + Prisma + PostgreSQL
- Repo: github.com/acme/ecom-dashboard
- Node: v20 LTS
## Auth
- Provider: NextAuth.js v5
- Methods: OAuth (Google, GitHub) + Credentials
- Session: JWT, maxAge 7d
- Admin emails: alice@acme.com, bob@acme.com
## API
- Base: /api/v1
- Rate limit: 100req/min per IP
- All endpoints require auth except /api/v1/health
## DB
- Host: localhost (dev) / db.acme.internal (prod)
- Name: ecom_prod / ecom_dev
- Migrations: prisma migrate dev
- Seed: prisma db seed
## Style
- Color: primary=#3B82F6, secondary=#10B981
- Font: Inter (Google Fonts)
- Dark mode: enabled by default
- Mobile-first: min-width 320px
## Deploy
- Platform: Vercel
- Env vars: set in Vercel dashboard
- Branch: main auto-deploys
- Preview: all PRs get preview URL
## Current Sprint
- Task: Cart page redesign
- Due: 2026-04-25
- Blocker: waiting for design team assets
这个文件总共约 1100 字符,远低于 2200 的上限,但包含了项目的所有关键信息。当你下次启动 Hermes 继续开发这个项目时,Agent 能立即知道技术栈、认证方式、数据库配置、部署方式等所有上下文,不需要你再重复交代。
4.2 USER.md 文件详解
如果说 MEMORY.md 是「项目记事本」,那 USER.md 就是「用户画像档案」。它记录的不是项目信息,而是你——作为用户的偏好、习惯、行为模式和个性化需求。
4.2.1 用户画像的自动建模
Hermes 最令人惊叹的功能之一,就是它能够「观察」你的行为,自动构建用户画像。这个过程不需要你做任何特殊操作,完全在后台静默进行。
自动建模的数据来源包括:
- 显式反馈:你直接说「我喜欢用中文」「请用 TypeScript」
- 隐式行为:
- 你经常查询什么类型的信息(技术文档 > 新闻 > 娱乐)
- 你倾向什么编程语言(Python 比 JavaScript 用得多)
- 你通常在什么时间段使用 Agent(上午 vs 深夜)
- 你对 Agent 的回复做什么修改(经常删减冗余内容 = 喜欢简洁风格)
- 错误模式:你经常纠正 Agent 的某些错误类型(比如混淆两个相似的概念)
- 任务偏好:你更倾向于让 Agent 自主决策,还是喜欢逐步确认
这些信息会被提炼成简洁的条目,写入 USER.md。
4.2.2 记录哪些信息
USER.md 中常见的信息类型包括:
# User Profile
## Communication
- Language: 中文为主,技术术语保留英文
- Style: 简洁直接,不喜欢冗余解释
- Tone: 专业但不死板
## Technical
- Primary: Python, TypeScript
- Secondary: Go, Rust
- Editor: VS Code with Vim keybindings
- OS: macOS
- Shell: zsh with Oh My Zsh
## Preferences
- Code: 必须包含类型注解和 docstring
- Comments: 英文注释,复杂逻辑加中文说明
- Format: 遵循 Black (Python) / Prettier (JS)
- Testing: pytest for Python, vitest for JS
## Patterns
- Active hours: 9:00-12:00, 14:00-18:00
- Response speed: prefer async over sync
- Error handling: 详细日志 + 优雅降级
- Documentation: README + inline comments
## Interests
- Strong: AI/ML, distributed systems, performance optimization
- Moderate: web dev, DevOps, data engineering
- Weak: frontend UI design, mobile apps
## Avoid
- 不要生成未经验证的代码建议
- 不要假设我有管理员权限
- 不要推荐付费工具 unless 确实必要
这些信息的价值在于:它们让 Agent 能够「像你的老搭档一样」与你协作。当你说「帮我写个脚本」,Agent 会自动用 Python(你的首选语言);当你问一个技术问题,Agent 知道你的水平层次,不会从最基础的概念讲起;当你让它审查代码,它会自动检查类型注解和测试覆盖率。
4.2.3 容量限制(~1375字符)
USER.md 的容量限制(约 1375 字符)比 MEMORY.md 更严格。这是因为:
- 用户画像的变化频率比项目信息低,不需要频繁更新
- 用户画像应该高度精炼——只记录最核心的特征
- 限制容量可以避免画像过于「臃肿」,导致加载时消耗过多 Token
当 USER.md 接近容量上限时,Agent 会启动「画像合并」机制:
- 把两个相似的偏好合并成一条更通用的
- 删除已经不再适用的旧偏好
- 把低频偏好降级或删除
4.2.4 如何查看和编辑
查看 USER.md:
# 命令行
$ cat ~/.hermes/memory/USER.md
# 在对话中
User: 给我看看我的用户画像
Agent: [展示 USER.md 内容]
编辑 USER.md:
# 直接编辑
$ nano ~/.hermes/memory/USER.md
# 在对话中
User: 我换用 Neovim 了,更新一下我的编辑器偏好
Agent: 已更新 USER.md:编辑器从 VS Code 改为 Neovim。
User: 我最近在学习 Rust,把它加到我的技术栈里
Agent: 已添加 Rust 到 Secondary languages。
User: 删掉关于「不喜欢注释」那条,我改主意了
Agent: 已删除该条目。
Tips
定期检查和清理 USER.md 是个好习惯。就像你的微信头像不会永远用五年前的照片一样,你的技术偏好、工作习惯也会变化。建议每 1-2 个月让 Agent 「重新审视」你的画像,删除过时的条目。
4.2.5 实际 USER.md 示例
以下是一个实际开发者的 USER.md:
# User
## Profile
- Role: Senior Backend Engineer
- Company: FinTech startup
- Experience: 8+ years
## Tech Stack
- Primary: Python (Django/FastAPI), PostgreSQL
- Learning: Rust, Kubernetes
- Tools: Docker, GitHub Actions, Datadog
## Preferences
- Code style: PEP8, type hints mandatory, 100 char line
- Architecture: microservices over monolith
- DB: prefer SQL over NoSQL for structured data
- API: REST > GraphQL (for now)
## Communication
- Language: English for code/docs, 中文 for discussion
- Detail level: high for architecture, medium for implementation
- Examples: always provide runnable code snippets
## Work Patterns
- Active: UTC+8 9:00-18:00
- Reviews: thorough, focus on edge cases and security
- Testing: integration tests > unit tests for APIs
- Docs: OpenAPI spec + README per service
## Context
- Current project: payment gateway v2 redesign
- Deadline: end of Q2
- Team size: 5 engineers
- Constraint: must comply with PCI-DSS
这个文件约 800 字符,信息密度很高。想象一下,如果没有 USER.md,每次新会话你都要告诉 Agent:「我是后端工程师,用 Python,喜欢类型注解,现在在做一个支付网关项目...」而有了 USER.md,这一切都在会话开始时自动加载,你只需要直接说「帮我看看这个支付接口的设计」就够了。
4.3 持久记忆的读取时机与优先级
了解了 MEMORY.md 和 USER.md 的内容后,我们来看看它们是如何被加载到会话中的。
读取时机:
- 会话开始时:每次启动新会话,Hermes 都会读取这两个文件
- 文件被修改后:如果你在对话中让 Agent 修改了记忆文件,修改会立即生效
- 执行 /refresh 命令时:强制重新加载所有记忆
加载优先级(高到低):
1. 系统提示(System Prompt)
2. SOUL.md
3. 激活的 Skill 说明
4. USER.md(用户画像)
5. MEMORY.md(项目记忆)
6. 冷记忆检索结果
7. 当前对话历史
8. 用户输入
这个优先级顺序的设计理由:
- 系统提示和 SOUL.md 在最前面:它们是 Agent 的「基本行为准则」,必须最先被看到
- USER.md 在 MEMORY.md 前面:你的个人偏好比项目信息更根本。比如你喜欢简洁回复,这个偏好应该优先于某个项目要求详细文档的需求
- 温记忆在冷记忆前面:当前项目的直接记忆,比历史检索到的片段更相关
- 对话历史在最后面:动态变化的内容放在最后,符合 FIFO 截断策略(如果溢出,最先丢失的是最早的对话)
注意
如果你发现 Agent 在某些情况下「记不住」你的偏好,可能是因为 MEMORY.md 中的某条项目级设置覆盖了 USER.md 中的用户级设置。例如,USER.md 说你喜欢简洁回复,但 MEMORY.md 中写着「这个项目需要详细的文档说明」,Agent 可能会为了项目需求而提供更详细的回复。这是预期行为——项目上下文优先于个人偏好。
5. 第三层:检索记忆(冷记忆)
5.1 SQLite 数据库架构详解
冷记忆是 Hermes 记忆系统中技术含量最高的部分,也是它与大多数其他 Agent 框架拉开差距的地方。让我们从最底层的存储架构开始,一层一层地向上理解。
5.1.1 表结构设计
Hermes 使用 SQLite 作为冷记忆的存储引擎。SQLite 的选择是深思熟虑的:
- 零配置:不需要安装独立的数据库服务,一个
.db文件就是完整的数据库 - 跨平台:Windows、macOS、Linux 都能用
- 高性能:对于本地单用户场景,SQLite 的性能完全够用
- 事务安全:支持 ACID,数据不会损坏
- 内置 FTS5:SQLite 从 3.19.0 版本开始内置 FTS5 全文搜索扩展
数据库文件默认位于:
~/.hermes/memory/hermes_memory.db
核心表结构如下(简化版):
-- 会话表:记录每一次对话会话
CREATE TABLE conversations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
session_id TEXT UNIQUE NOT NULL, -- 会话唯一标识
started_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
ended_at TIMESTAMP,
summary TEXT, -- LLM 生成的会话摘要
tags TEXT, -- 标签,用逗号分隔
total_messages INTEGER DEFAULT 0, -- 消息总数
total_tokens INTEGER DEFAULT 0 -- Token 总数
);
-- 消息表:存储每一条消息
CREATE TABLE messages (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
role TEXT NOT NULL, -- 'user' 或 'assistant'
content TEXT NOT NULL,
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
tokens INTEGER, -- 该消息的 Token 数
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 工具调用表:记录 Agent 的每一次工具使用
CREATE TABLE tool_calls (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
tool_name TEXT NOT NULL, -- 工具名称
arguments TEXT, -- 调用参数(JSON 格式)
result TEXT, -- 调用结果
success BOOLEAN DEFAULT 1,
duration_ms INTEGER, -- 执行耗时(毫秒)
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 文件操作表:记录 Agent 的文件读写操作
CREATE TABLE file_operations (
id INTEGER PRIMARY KEY AUTOINCREMENT,
conversation_id INTEGER NOT NULL,
operation TEXT NOT NULL, -- 'read', 'write', 'edit', 'delete'
file_path TEXT NOT NULL,
content_hash TEXT, -- 内容哈希(用于检测变更)
timestamp TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (conversation_id) REFERENCES conversations(id)
);
-- 记忆片段表:存储提取出的关键记忆
CREATE TABLE memory_fragments (
id INTEGER PRIMARY KEY AUTOINCREMENT,
source_conversation_id INTEGER,
content TEXT NOT NULL, -- 记忆内容
importance_score REAL, -- 重要性评分(0-1)
category TEXT, -- 分类:'fact', 'decision', 'preference', etc.
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
last_accessed TIMESTAMP,
access_count INTEGER DEFAULT 0, -- 被检索到的次数
FOREIGN KEY (source_conversation_id) REFERENCES conversations(id)
);
这个设计的精妙之处在于:不仅存储了「说什么」,还存储了「做什么」。工具调用记录和文件操作记录,让 Agent 能够回答这样的问题:「上次我是怎么解决那个问题的?」「我修改过这个文件的哪几行?」
5.1.2 存储的数据类型
Hermes 的冷记忆数据库不仅存储对话文本,还记录了丰富的元数据:
对话类数据:
- 完整的用户输入和 Agent 回复
- 每次对话的时间戳和持续时间
- 对话中使用的模型和参数
- 会话级别的 Token 统计
工具类数据:
- 工具名称和调用参数
- 工具执行结果(成功/失败)
- 执行耗时
- 调用链(一个工具调用触发了另一个工具)
文件类数据:
- 读写的文件路径
- 操作类型(创建/修改/删除)
- 内容哈希值(用于追踪变更)
- 操作时间
知识类数据:
- 从对话中提取的关键事实
- 用户明确记录的备忘
- 自动生成的会话摘要
- 用户偏好和行为的推断结果
5.1.3 数据量增长估算
很多用户关心:这个数据库会不会无限膨胀?我需要手动清理吗?
让我们做一个估算。假设你是一个「中等强度」的用户:
- 每天与 Agent 对话 20 轮
- 每轮平均 200 Tokens
- 每天使用 5 次工具调用
- 每天产生 3 次文件操作
一天的数据量:
消息:20 轮 × 2 条(用户+Agent)= 40 条消息
工具调用:5 次
文件操作:3 次
文本总量:20 × 200 = 4,000 Tokens ≈ 12,000 字符
一年的数据量:
消息:40 × 365 = 14,600 条
工具调用:5 × 365 = 1,825 次
文件操作:3 × 365 = 1,095 次
文本总量:12,000 × 365 ≈ 4,380,000 字符 ≈ 4.4 MB
加上索引和元数据,一年的数据库大小大约在 10-20 MB 左右。这个体积在现代电脑上完全微不足道——你的微信聊天记录一个月可能就几百 MB。
即使你是「重度用户」(每天 100 轮对话),一年的数据量也就在 50-100 MB 级别。SQLite 能轻松处理 GB 级别的数据库,所以你完全不需要担心存储空间的问题。
Tips
虽然存储空间不是问题,但检索速度会随着数据量增加而有所下降。Hermes 内置了自动维护机制(详见第7章),包括索引优化和旧数据归档。你也可以手动设置保留策略(详见第10章)。
5.2 FTS5 全文索引
FTS5(Full-Text Search 5)是 SQLite 内置的全文搜索引擎。它是 Hermes 冷记忆检索能力的核心支柱。理解 FTS5,就理解了 Hermes 如何做到「瞬间从海量历史中找到相关内容」。
5.2.1 什么是 FTS5(通俗解释)
我们先不用技术术语,用一个类比来解释 FTS5。
想象你有一个巨大的图书馆,里面有 10 万本书。如果你要找一本「讲 Python 编程的书」,传统的方式是一本一本地翻看——这显然太慢了。
于是你做了一个「目录卡片」系统:每本书你都在卡片上记录书名、作者、关键词。所有卡片按字母顺序排列在一个巨大的抽屉柜里。当你要找 Python 的书时,直接去 "P" 开头的抽屉里找就行了。这就是「索引」。
但 FTS5 比这个更强大。它不仅记录「这本书里有 Python 这个词」,还记录「Python 这个词在书的第 3 页第 2 段出现了」。更进一步,它能理解「Python 编程」「Python 开发」「Python 语言」都是相关的,甚至能处理拼写错误(比如你把 Python 拼成了 Pthon)。
在 Hermes 的语境中,FTS5 做的事情是:
- 把每一条历史消息、每一个工具调用结果、每一个文件操作记录,都「拆开」成单词
- 建立一个巨大的「倒排索引」——记录每个词出现在哪些记录中
- 当你搜索时,瞬间找到包含这些词的所有记录
- 按照相关度排序,把最相关的结果返回给你
5.2.2 索引建立过程
FTS5 索引的建立是自动的,你不需要手动操作。但为了让你理解背后的机制,我们来看看索引是如何构建的:
-- 创建 FTS5 虚拟表(Hermes 内部自动完成)
CREATE VIRTUAL TABLE messages_fts USING fts5(
content, -- 要索引的文本内容
conversation_id UNINDEXED, -- 不索引,仅存储关联ID
timestamp UNINDEXED -- 不索引,仅存储
);
-- 当新消息写入时,自动添加到索引(触发器自动完成)
INSERT INTO messages_fts(content, conversation_id, timestamp)
VALUES ('用户输入的内容...', 123, '2026-04-21 10:30:00');
索引建立的过程:
-
分词(Tokenization):将文本拆分成单词。对于中文,需要使用专门的分词器(如
jieba或 SQLite 的icu分词器)。Hermes 默认使用porter分词器处理英文,simple分词器处理中文。 -
标准化(Normalization):
- 统一大小写("Python" 和 "python" 视为同一个词)
- 去除标点符号
-
词干提取("running" 和 "runs" 都归为 "run")
-
去停用词:过滤掉「的」「是」「the」「and」等无意义的词,减少索引体积
-
构建倒排索引:记录每个词在哪些文档中出现,以及出现的位置
5.2.3 检索速度与效果
FTS5 的检索速度非常快。在普通笔记本电脑上,从 100 万条记录中检索关键词,通常只需要 几毫秒到几十毫秒。
让我们看一个实际的检索场景:
假设你在半年前的一个会话中讨论过「如何用 Docker 部署 PostgreSQL」。现在你忘了具体的命令,只记得「Docker」和「PostgreSQL」两个关键词。你开启新会话,输入:
User: 上次部署 PostgreSQL 的 Docker 命令是什么来着?
Hermes 的内部检索过程:
-- 1. 提取关键词
-- 分析输入:"部署 PostgreSQL 的 Docker 命令"
-- 提取关键词:PostgreSQL, Docker, 部署, 命令
-- 过滤停用词:保留 PostgreSQL, Docker, 命令
-- 2. FTS5 检索
SELECT
content,
conversation_id,
rank -- FTS5 内置的相关度评分
FROM messages_fts
WHERE messages_fts MATCH 'PostgreSQL AND Docker AND 命令'
ORDER BY rank
LIMIT 5;
检索结果可能是:
结果1 (rank: 1.2): "docker run -d --name pg -e POSTGRES_PASSWORD=secret postgres:15"
结果2 (rank: 2.5): "我用 Docker 部署了 PostgreSQL,配置如下..."
结果3 (rank: 3.1): "Docker Compose 文件里 PostgreSQL 的部分..."
然后 Hermes 会把这些相关片段注入到当前上下文中,Agent 就能回答你的问题:
Agent: 根据之前的记录,你使用的 Docker 命令是:
docker run -d \
--name pg \
-e POSTGRES_PASSWORD=secret \
-p 5432:5432 \
postgres:15
这是你在 2025 年 10 月 15 日的会话中使用的配置。
5.2.4 与传统全文搜索的对比
如果你做过信息检索相关的工作,可能会问:FTS5 和 Elasticsearch、Solr 等传统全文搜索引擎相比如何?
| 特性 | FTS5 (SQLite) | Elasticsearch | 传统 SQL LIKE |
|---|---|---|---|
| 部署复杂度 | 零(内置) | 高(需独立服务) | 零 |
| 检索速度 | 毫秒级 | 毫秒级 | 秒级(大数据量时) |
| 相关性排序 | 支持 | 支持(更强大) | 不支持 |
| 模糊匹配 | 基本支持 | 强大 | 不支持 |
| 分布式 | 不支持 | 支持 | 不支持 |
| 数据量上限 | GB 级 | TB 级 | 无索引时很慢 |
| 维护成本 | 极低 | 高 | 低 |
对于 Hermes 的使用场景(个人或小型团队的本地 Agent),FTS5 在绝大多数情况下已经绰绰有余。它的「零部署」优势尤其重要——你只需要安装 Hermes,全文检索能力就自动可用了。
注意
FTS5 的一个局限是中文分词能力相对较弱(默认的
simple分词器对中文只是按字拆分)。Hermes 通过预处理优化了这个问题,但在某些复杂的中文查询场景下,检索效果可能不如专门的搜索引擎。如果你主要用中文工作且对检索精度要求极高,可以考虑通过 Mem0 等外部方案增强检索能力。
5.3 按需检索机制
按需检索是 Hermes 冷记忆系统最具创新性的设计。传统的记忆方案往往在会话开始时就把所有历史记录加载到上下文中,而 Hermes 采用了一种更智能的方式。
5.3.1 新对话时不再全量加载
让我们对比一下两种策略:
传统策略(全量加载):
会话开始
↓
加载过去 100 个会话的所有消息(50,000 Tokens)
↓
加上系统提示和当前输入(2,000 Tokens)
↓
总上下文:52,000 Tokens
↓
模型处理(慢、贵、容易混乱)
Hermes 策略(按需检索):
会话开始
↓
只加载固定保留区(系统提示 + SOUL.md + 温记忆)(2,000 Tokens)
↓
分析用户输入,提取关键词
↓
FTS5 检索,只取最相关的 3-5 条记录(~500 Tokens)
↓
总上下文:~2,500 Tokens
↓
模型处理(快、便宜、聚焦)
差异是惊人的:传统策略可能一次请求就消耗 50,000+ Tokens,而 Hermes 的策略通常只消耗 2,000-3,000 Tokens。按照 GPT-4 的定价(输入 $0.03/1K Tokens),每轮对话的成本差异是 $1.5 vs $0.075——相差 20 倍!
5.3.2 根据当前话题智能检索
Hermes 的检索不是简单的关键词匹配,而是一个多阶段的智能过程:
阶段一:查询理解
当用户输入一条消息时,Hermes 首先分析这条消息的意图和主题:
用户输入: "帮我看看上次那个支付接口的 bug 修好了没"
提取关键词: 支付接口, bug, 修好
推断主题: code_review, bug_fix, payment
时间范围: 最近("上次"暗示近期)
阶段二:多维度检索
根据理解的结果,从不同维度并行检索:
-- 维度1:消息内容匹配
SELECT * FROM messages_fts
WHERE messages_fts MATCH '支付 AND (bug OR 修复 OR 修好)'
ORDER BY rank LIMIT 3;
-- 维度2:工具调用记录
SELECT * FROM tool_calls
WHERE tool_name IN ('code_review', 'file_edit')
AND (result LIKE '%支付%' OR arguments LIKE '%支付%')
ORDER BY timestamp DESC LIMIT 2;
-- 维度3:文件操作记录
SELECT * FROM file_operations
WHERE file_path LIKE '%payment%' OR file_path LIKE '%pay%'
ORDER BY timestamp DESC LIMIT 2;
阶段三:相关度融合与排序
将多个维度的结果合并,按综合相关度排序:
相关度评分 =
FTS 排名分数 × 0.4 + -- 文本匹配度
时间衰减因子 × 0.3 + -- 越新的越重要
工具成功率 × 0.2 + -- 成功的操作更重要
用户反馈权重 × 0.1 -- 用户标注重要的优先
阶段四:片段提取与注入
从选中的记录中提取最相关的片段(不是整段对话,而是包含关键词的那几句话),然后格式化为上下文注入:
[相关历史片段 #1]
来源:2026-04-15 的会话
内容:用户报告支付接口在并发请求时出现 500 错误。Agent 建议使用连接池并增加了重试逻辑。
[相关历史片段 #2]
来源:2026-04-16 的会话
内容:修复了 payment/service.py 中的 race condition,提交了 commit a3f7d2e。
5.3.3 只提取相关片段
这是一个关键设计:不是把整个历史会话都加载进来,而是只提取「相关的那几句话」。
这样做的好处:
- 极大节省 Token:一条完整的会话可能 500 Tokens,但相关片段可能只有 50 Tokens
- 减少噪声:不相关的历史信息不会干扰当前任务
- 提高精度:模型只看到了真正需要的信息,不会被无关内容分散注意力
提取算法会围绕关键词向外扩展,取包含关键词的句子和前后各一句,形成一个「语义完整的片段」。如果关键词出现在工具调用结果中,会同时提取工具名称、参数和结果摘要。
5.3.4 API 调用成本大幅降低
按需检索机制带来的最大实际好处,就是 API 调用成本的大幅降低。
假设你使用 Claude 3.7 Sonnet($0.03/1K input tokens),每天进行 50 轮对话:
| 策略 | 每轮平均 Tokens | 每日 Tokens | 每日成本 |
|---|---|---|---|
| 全量加载 | 25,000 | 1,250,000 | $37.50 |
| Hermes 按需检索 | 3,000 | 150,000 | $4.50 |
| 节省 | 88% | 88% | $33/天 |
一个月下来,Hermes 的按需检索机制可以为你节省约 $990 的 API 费用。这不仅仅是省钱——更重要的是,更低的成本让你可以更频繁、更深度地使用 Agent,而不必心疼账单。
Tips
如果你想进一步降低成本,可以在
config.yaml中调整检索参数:yaml memory: retrieval: max_fragments: 3 # 减少检索到的片段数量(默认5) fragment_max_tokens: 80 # 限制每个片段的长度(默认150) time_decay_days: 30 # 只检索最近30天的记录(默认90)这些调整会在检索精度和成本之间做权衡。如果你主要处理近期任务,把时间范围缩小可以显著减少检索开销。
5.4 LLM 摘要生成
除了 FTS5 全文检索,Hermes 还利用大语言模型本身的能力,为每次会话生成智能摘要。这些摘要既服务于人类用户(快速回顾),也服务于 Agent(高效检索)。
5.4.1 自动生成会话摘要
每次会话结束时(或执行 /compact 时),Hermes 会触发摘要生成流程:
1. 获取当前会话的完整对话记录
2. 构建摘要提示模板:
"请为以下对话生成一个简洁的摘要(100字以内)。
摘要应包括:主要任务、关键决策、重要结论、遗留问题。"
3. 调用 LLM 生成摘要
4. 将摘要保存到 conversations 表的 summary 字段
5. 同时为摘要建立 FTS5 索引
生成的摘要示例:
会话摘要(2026-04-21):
用户要求分析 Q1 财报数据。使用 Python 抓取并清洗了 3 家公司的
财务数据,生成对比图表。关键结论:A 公司毛利率最高(42%)。
遗留:需要补充行业均值数据。
5.4.2 摘要的存储与索引
摘要会被存储在两个地方:
- conversations 表的 summary 字段:作为元数据,便于快速浏览
- FTS5 索引:让摘要也能被检索到
当用户搜索时,FTS5 会同时搜索:
- 原始消息内容
- 会话摘要
- 工具调用结果
- 文件操作记录
这意味着,即使用户记不住具体的对话内容,只记得「大概是什么主题」,也能通过摘要找到相关会话。
5.4.3 摘要质量的影响因素
摘要的质量直接影响检索的效果。以下因素会影响摘要质量:
正向因素:
- 对话主题明确、任务清晰
- 有明确的决策点和结论
- 用户和 Agent 的互动质量高
负向因素:
- 对话过于零散、话题频繁切换
- 大量闲聊和无关内容
- 任务中途被打断
你可以通过以下方式帮助 Agent 生成更好的摘要:
- 在任务完成时做总结:「总结一下我们今天做了什么」
- 给会话打标签:「给这个会话打个标签:投研-Q1-白酒」
- 手动修正摘要:如果你觉得自动摘要不够准确,可以手动编辑
User: 修改刚才那个会话的摘要,加上「最终输出了一份 Excel 报告」
Agent: 已更新会话摘要。
6. 外部记忆扩展
虽然 Hermes 内置的记忆系统已经非常强大,但在某些特定场景下,外部记忆扩展可以提供更专业的能力。本节介绍几种主流的外部记忆方案及其集成方法。
6.1 Honcho 模块详解
Honcho 是一个专注于「用户行为模式推导」的记忆模块,由 a16z 支持开发。它的核心理念是:通过分析用户的历史行为,推断出用户的隐性偏好和需求,从而让 Agent 的响应更加个性化。
6.1.1 Honcho 的设计理念
Honcho 的设计灵感来自心理学中的「认知建模」理论。它认为,一个真正智能的 Agent 不应该只是「记住用户说过什么」,而应该「理解用户是什么样的人」。
具体来说,Honcho 会:
- 分析对话模式:你在什么情况下会打断 Agent?你通常如何纠正 Agent 的错误?
- 推断认知风格:你是「先整体后细节」的人,还是「先细节后整体」的人?
- 识别情感触发点:哪些类型的话题会让你表现出兴奋、困惑或不耐烦?
- 建模知识水平:你在不同领域的能力层次(专家/熟练/新手)
基于这些分析,Honcho 生成一个「用户心理模型」,供 Agent 在后续交互中参考。
6.1.2 行为模式推导机制
Honcho 的行为模式推导分为三个层次:
第一层:表面模式(Surface Patterns)
从原始对话中提取可直接观察的模式:
{
"communication_patterns": {
"average_response_length": 45,
"preferred_language": "zh-CN",
"uses_technical_jargon": true,
"asks_clarifying_questions": false
},
"timing_patterns": {
"peak_activity_hours": [9, 10, 14, 15],
"average_session_duration_minutes": 23,
"typical_task_complexity": "medium"
}
}
第二层:推断特征(Inferred Traits)
基于表面模式,推断更深层的用户特征:
{
"cognitive_style": "analytical",
"risk_tolerance": "medium",
"learning_preference": "example-driven",
"decision_making": "data-driven",
"expertise_areas": ["backend_development", "system_design"],
"novice_areas": ["frontend_design", "mobile_development"]
}
第三层:预测模型(Predictive Model)
基于历史数据,预测用户在未来场景中的行为:
{
"predicted_behaviors": {
"when_introducing_new_tech": "will_ask_for_examples",
"when_facing_errors": "prefers_step_by_step_debugging",
"when_given_options": "tends_to_choose_performance_over_convenience"
}
}
6.1.3 安装与配置方法
在 Hermes 中集成 Honcho:
# 1. 安装 Honcho Python 包
pip install honcho-ai
# 2. 在 config.yaml 中启用 Honcho
```yaml
# ~/.hermes/config.yaml
memory:
external:
honcho:
enabled: true
api_key: "your_honcho_api_key" # 可选,本地模式可不填
mode: "local" # 或 "cloud"
inference_frequency: "per_session" # per_message / per_session / per_day
depth: "full" # surface / inferred / full
3. 重启 Hermes
hermes restart
如果你选择 `mode: "local"`,所有 Honcho 的数据处理都在本地完成,不会上传到 Honcho 的服务器。但某些高级推断功能可能需要 `cloud` 模式。
#### 6.1.4 实际效果展示
启用 Honcho 前后对比:
**启用前:**
User: 帮我写个脚本处理日志文件 Agent: 好的,这是一个 Python 脚本... [生成一个通用脚本]
**启用后(Honcho 已推断出用户偏好):**
User: 帮我写个脚本处理日志文件 Agent: 好的,基于你之前的偏好(喜欢用 Go 写工具脚本、重视错误处理、 偏好结构化输出),这是一个 Go 脚本... [生成一个带 error handling、JSON 输出的 Go 脚本]
Honcho 的推断不是基于你明确说过的偏好,而是基于你过去的行为模式。比如你可能从来没说过「我喜欢 Go 语言」,但如果你过去 10 次让 Agent 写脚本时 8 次都选了 Go,Honcho 就会推断出这个偏好。
> **注意**
>
> Honcho 是一个相对较新的项目,其推断算法的准确性还在持续改进中。建议把它作为「增强」而非「替代」Hermes 内置的记忆系统。在使用过程中,如果你发现 Honcho 的推断有偏差,可以通过 `honcho feedback` 命令提供纠正反馈。
### 6.2 Mem0 集成
Mem0 是目前最流行的外部记忆平台之一,被描述为「AI 应用的记忆层」。它提供了比 Hermes 内置记忆更强大的检索和管理能力,特别适合需要跨设备同步记忆的场景。
**Mem0 的核心特性:**
1. **混合检索**:同时支持向量检索(语义相似度)和关键词检索(精确匹配)
2. **记忆层级**:自动区分短期记忆、长期记忆和核心事实
3. **多模态**:支持文本、图像、音频等多种类型记忆
4. **跨平台**:记忆可以在不同设备、不同应用间同步
5. **记忆冲突解决**:当新旧记忆矛盾时,自动判断哪个更可靠
**在 Hermes 中集成 Mem0:**
```bash
# 1. 安装 Mem0
pip install mem0ai
# 2. 获取 API 密钥(在 mem0.ai 注册)
# 3. 配置 Hermes
```yaml
memory:
external:
mem0:
enabled: true
api_key: "m0-your-api-key"
organization_id: "your-org-id"
project_id: "your-project-id"
# 检索配置
retrieval:
method: "hybrid" # semantic / keyword / hybrid
top_k: 5
# 记忆更新配置
update:
auto_add: true
importance_threshold: 0.7
4. 重启 Hermes
**Mem0 与内置记忆的协作模式:**
Hermes 支持「分层记忆」模式:内置记忆处理日常任务,Mem0 处理需要高级检索能力的场景。具体协作方式:
用户输入 ↓ 同时查询 Hermes 内置记忆 和 Mem0 ↓ 融合两个来源的结果 ↓ 按相关度排序,去重 ↓ 注入上下文
> **Tips**
>
> 如果你同时使用 Mem0 和内置记忆,建议在 `config.yaml` 中设置优先级:
> ```yaml
> memory:
> retrieval_priority: ["local", "mem0"] # 先查本地,再查 Mem0
> # 或
> retrieval_priority: ["mem0", "local"] # 先查 Mem0,再查本地
> ```
### 6.3 OpenViking 集成
OpenViking 是一个面向企业级场景的记忆扩展方案,由 Viking Analytics 开发。它专注于解决以下企业痛点:
1. **团队协作记忆**:多个用户共享项目记忆,新成员加入时能快速了解项目上下文
2. **权限控制**:不同角色可以访问不同层级的记忆(公开/团队/个人/机密)
3. **合规审计**:所有记忆操作都有完整的审计日志,满足企业合规要求
4. **数据隔离**:不同客户/项目的数据严格隔离,防止交叉污染
**OpenViking 的架构:**
OpenViking Server ├── Project Memory Pool (共享项目记忆) ├── Team Memory Pool (团队知识库) ├── Personal Memory Pool (个人记忆) └── Audit Log (审计日志)
Hermes Agent ←→ OpenViking Client ←→ OpenViking Server
**集成方式:**
```yaml
memory:
external:
openviking:
enabled: true
server_url: "https://openviking.company.internal"
api_key: "vk-xxx"
# 企业级配置
project_id: "project-alpha"
team_id: "backend-team"
access_level: "team" # personal / team / project / admin
# 合规配置
audit_enabled: true
data_retention_days: 365
encryption: "aes-256-gcm"
OpenViking 更适合以下场景:
- 中大型开发团队使用 Hermes 协作
- 需要满足数据合规要求的企业
- 项目记忆需要在团队成员间共享
- 需要精细的权限控制
对于个人用户和小团队,Hermes 内置的记忆系统通常已经足够。
6.4 其他 5 种外部记忆方案
除了 Honcho、Mem0 和 OpenViking,社区还开发了多种其他记忆扩展方案。根据 Hermes Atlas 官方文档,目前已支持 8 种社区记忆扩展,包括 Honcho、Mem0、Hindsight、Supermemory 等。以下是值得了解的方案:
方案一:Hindsight —— 事后反思增强记忆
Hindsight 是一款专注于「事后反思」的记忆扩展。它的核心理念是:Agent 不应该只记录「发生了什么」,还应该记录「为什么会这样」以及「下次如何做得更好」。每次会话结束后,Hindsight 会触发一个反思流程,自动生成「经验卡片」,记录成功模式、失败教训和优化建议。
Hindsight 特别适合需要持续改进的复杂工作流场景,比如代码审查、投研分析、内容创作等。
memory:
external:
hindsight:
enabled: true
reflection_depth: "detailed" # brief / detailed / deep
auto_reflect: true
retention: "lessons_only" # 只保留提炼出的经验教训
方案二:Supermemory —— 超级个人记忆库
Supermemory 是一个主打「捕获一切」的外部记忆方案。它不仅可以存储对话历史,还能主动抓取你浏览的网页、收藏的推文、阅读的文章,建立统一的个人知识库。通过浏览器插件和 API,Supermemory 能让 Hermes 访问你的整个数字生活轨迹。
适合希望 Agent 拥有「完整上下文」的深度用户。但需注意隐私影响——它确实需要访问大量个人数据。
memory:
external:
supermemory:
enabled: true
api_key: "sm-your-key"
capture_web_browsing: true
capture_bookmarks: true
方案三:Chroma + LangChain Memory
使用 Chroma 向量数据库作为后端,通过 LangChain 的 ConversationBufferMemory 接口集成。适合需要语义检索的场景。
memory:
external:
chroma:
enabled: true
persist_directory: "~/.hermes/chroma_db"
collection_name: "hermes_memories"
embedding_model: "sentence-transformers/all-MiniLM-L6-v2"
方案二:Pinecone 云端向量记忆
Pinecone 是一个托管的向量数据库服务,提供高性能的语义检索。适合不需要本地部署、愿意使用云服务的用户。
优点:检索速度快、支持大规模数据、自动扩缩容 缺点:数据上云、有额外成本、需要网络连接
方案三:Zep Memory
Zep 是专门为 LLM 应用设计的长期记忆服务。它的特点是「渐进式摘要」——随着对话进行,自动将短期记忆提炼成长期记忆。
Zep 的独特之处在于它理解「时间」的概念。比如它能回答「用户上周对什么话题最感兴趣?」这种需要时间维度分析的问题。
方案四:Zep Memory
Zep 是专门为 LLM 应用设计的长期记忆服务。它的特点是「渐进式摘要」——随着对话进行,自动将短期记忆提炼成长期记忆。Zep 的独特之处在于它理解「时间」的概念。比如它能回答「用户上周对什么话题最感兴趣?」这种需要时间维度分析的问题。
方案五:本地文件系统记忆(增强版)
如果你不想用任何外部服务,可以用增强的本地文件方案:
~/.hermes/memory/
├── daily/ # 按日期归档
│ ├── 2026-04-21.md
│ ├── 2026-04-20.md
│ └── ...
├── projects/ # 按项目归档
│ ├── project-alpha/
│ ├── project-beta/
│ └── ...
├── topics/ # 按主题归档
│ ├── python-tips.md
│ ├── docker-notes.md
│ └── ...
└── index.json # 所有文件的索引
配合一个简单的检索脚本,就能实现基本的记忆管理。这种方式完全离线,但检索能力较弱。
方案六:Obsidian / Notion 集成
如果你已经在使用 Obsidian 或 Notion 作为个人知识库,可以把它们作为 Hermes 的外部记忆:
memory:
external:
obsidian:
enabled: true
vault_path: "~/Documents/Obsidian Vault"
# Hermes 会索引你的 Obsidian 笔记
# 并在检索时纳入搜索结果
这种方式的最大好处是:你的 Agent 记忆和你的个人知识库合二为一。你在 Obsidian 中记录的读书笔记、会议记录、项目文档,Agent 都能检索到。
6.5 选择建议:什么场景用什么方案
面对这么多记忆方案,如何选择?以下是针对不同场景的推荐:
| 使用场景 | 推荐方案 | 理由 |
|---|---|---|
| 个人开发者,日常使用 | Hermes 内置记忆 | 零配置、完全本地、有界设计保持专注 |
| 需要语义检索(找「意思相近」的内容) | Mem0 或 Chroma | 向量检索擅长语义匹配 |
| 需要事后反思和经验积累 | Hindsight | 自动生成经验卡片,持续改进 |
| 希望 Agent 拥有完整数字生活上下文 | Supermemory | 捕获浏览历史、收藏、阅读记录 |
| 跨设备同步记忆 | Mem0 Cloud | 云端同步,多设备一致 |
| 企业团队协作用 | OpenViking | 权限控制、审计合规 |
| 深度用户行为分析 | Honcho | 行为模式推断 |
| 已有 Obsidian/Notion 知识库 | 对应集成方案 | 统一知识管理 |
| 极度隐私敏感(如处理医疗/金融数据) | 纯内置记忆 | 数据绝不出本地 |
| 超大规模数据(百万级会话) | Pinecone / 定制方案 | 专业向量数据库的扩展性 |
Tips
对于绝大多数用户,我的建议是:先用好 Hermes 内置的记忆系统。它覆盖了 80% 的使用场景,而且零配置、零成本。当你遇到内置系统无法解决的特定问题时,再考虑引入外部扩展。不要为了「技术炫酷」而增加不必要的复杂度。
7. 记忆管理实战
7.1 /memory 命令系列详解
Hermes 提供了一套完整的 /memory 命令,让你能够像操作数据库一样管理记忆。掌握这些命令,是高效使用 Hermes 的必备技能。
命令总览:
/memory show # 查看当前记忆状态
/memory add <内容> # 手动添加一条记忆
/memory remove <关键词> # 删除包含关键词的记忆条目
/memory edit <id> <新内容> # 编辑指定记忆
/memory search <关键词> # 搜索记忆
/memory export [文件名] # 导出记忆
/memory import <文件名> # 导入记忆
/memory compact # 压缩记忆文件
/memory clear # 清空所有记忆(谨慎使用!)
/memory show —— 查看当前记忆状态
这是你最常用的命令之一。它会展示当前加载的所有记忆内容:
User: /memory show
Agent:
📋 当前记忆状态
═══════════════
📄 MEMORY.md (~1,850 / 2,200 字符)
━━━━━━━━━━━━━━━━━━━━
## Project
- 项目: 智能客服系统 v2
- 技术栈: Python + FastAPI + PostgreSQL
- Git: github.com/acme/customer-service-v2
## Key Info
- API 基地址: https://api.cs2.acme.com
- 认证: JWT, 过期 24h
- DB 主机: db.acme.internal
## Current Sprint
- 任务: 实现工单自动分配
- 截止日期: 2026-04-30
👤 USER.md (~890 / 1,375 字符)
━━━━━━━━━━━━━━━━━━━━
## Profile
- Role: 后端工程师
- 经验: 5年
## Tech
- 主要: Python, Go
- 数据库: PostgreSQL, Redis
- 框架: FastAPI, Django
## Preferences
- 代码风格: PEP8 + Type Hints
- 文档: 中文注释 + 英文 docstring
🗄️ 冷记忆统计
━━━━━━━━━━━━━━━━━━━━
总会话数: 147
总消息数: 3,284
总工具调用: 892
数据库大小: 18.5 MB
FTS5 索引: 已建立
最后检索: 3 秒前
这个视图让你一目了然地看到所有记忆的状态,包括容量使用情况。
/memory add —— 手动添加记忆
有时候你需要手动添加一些信息到记忆中:
# 添加到 MEMORY.md
User: /memory add "测试服务器密码: TestPass123! (仅内部使用)"
Agent: 已添加到 MEMORY.md。
# 添加到 USER.md(使用 --user 标志)
User: /memory add --user "最近在学习 Kubernetes"
Agent: 已添加到 USER.md。
# 添加到特定分类
User: /memory add --category "credentials" "AWS Access Key: AKIA..."
Agent: 已添加到 MEMORY.md 的 credentials 分类下。
添加时的一些技巧:
- 使用关键词:添加的内容要包含你未来可能搜索的关键词
- 保持简洁:一条记忆只记录一件事
- 定期回顾:添加后过段时间看看是否真的有用
/memory remove —— 删除记忆
当某些记忆过期或错误时,你需要删除它们:
# 按关键词删除(删除包含该关键词的所有条目)
User: /memory remove "测试服务器"
Agent: 已删除 2 条包含"测试服务器"的记忆:
- "测试服务器地址: 192.168.1.50"
- "测试服务器密码: TestPass123!"
# 精确匹配删除
User: /memory remove --exact "JWT"
Agent: 已删除 1 条精确匹配的记忆。
# 删除整个分类
User: /memory remove --category "sprint-2026-Q1"
Agent: 已删除分类 "sprint-2026-Q1" 下的 15 条记忆。
注意
/memory remove删除的是温记忆(MEMORY.md / USER.md)中的条目。如果你想删除冷记忆(SQLite 中的历史记录),需要使用hermes history delete命令。两者的删除范围不同,不要混淆。
/memory edit —— 编辑记忆
有时候记忆的内容需要更新,但不需要完全删除重写:
# 查看所有记忆的编号
User: /memory list
Agent:
MEMORY.md:
[1] 项目: 智能客服系统 v2
[2] API 基地址: https://api.cs2.acme.com
[3] 认证: JWT, 过期 24h
# 编辑指定编号
User: /memory edit 3 "认证: Session-Cookie, 过期 7天"
Agent: 已将第 3 条记忆更新为:认证: Session-Cookie, 过期 7天
/memory search —— 搜索记忆
这个命令让你在温记忆中快速找到需要的内容:
# 简单搜索
User: /memory search "PostgreSQL"
Agent:
找到 3 条记忆:
1. [MEMORY.md] 数据库: PostgreSQL, Redis
2. [MEMORY.md] DB 主机: db.acme.internal (PostgreSQL)
3. [USER.md] 数据库偏好: PostgreSQL > MySQL
# 高级搜索(支持逻辑运算符)
User: /memory search "API AND (认证 OR 密码)"
Agent: ...
# 在指定文件中搜索
User: /memory search --file USER.md "Python"
Agent: ...
/memory export —— 导出记忆
导出功能非常重要,用于备份和迁移:
# 导出所有记忆
User: /memory export
Agent: 记忆已导出到 ~/.hermes/exports/memory_backup_20260421_143052.json
# 指定文件名
User: /memory export my_backup
Agent: 记忆已导出到 ~/.hermes/exports/my_backup.json
# 导出格式选项
User: /memory export --format markdown
Agent: 记忆已导出到 ~/.hermes/exports/memory_backup_20260421.md
导出文件的结构示例:
{
"export_time": "2026-04-21T14:30:52+08:00",
"hermes_version": "2.1.0",
"warm_memory": {
"MEMORY.md": "# Memory\n\n## Project\n...",
"USER.md": "# User\n\n## Profile\n..."
},
"cold_memory": {
"database_path": "~/.hermes/memory/hermes_memory.db",
"stats": {
"conversations": 147,
"messages": 3284,
"tool_calls": 892
}
},
"checksum": "sha256:a3f7d2e..."
}
/memory import —— 导入记忆
与导出对应,导入让你可以恢复备份或迁移记忆:
# 从文件导入
User: /memory import my_backup.json
Agent: 正在导入记忆...
✓ MEMORY.md: 已导入 24 条记忆
✓ USER.md: 已导入 12 条记忆
⚠ 发现 3 条重复记忆,已跳过
导入完成。
# 合并模式(不覆盖已有记忆)
User: /memory import --merge my_backup.json
Agent: 已合并导入,原有记忆保持不变。
# 强制覆盖
User: /memory import --overwrite my_backup.json
Agent: ⚠ 这将覆盖所有现有记忆。确认吗?(y/N)
/memory compact —— 压缩记忆文件
当 MEMORY.md 或 USER.md 接近容量上限时,可以手动压缩:
User: /memory compact
Agent:
正在压缩记忆文件...
MEMORY.md:
压缩前: 2,180 字符
压缩后: 1,560 字符
节省: 28.4%
合并了 3 组相似条目
删除了 2 条过期条目
USER.md:
压缩前: 1,320 字符
压缩后: 980 字符
节省: 25.8%
合并了 2 组相似条目
压缩算法会:
- 合并语义相似的条目
- 删除明确过期的信息
- 缩短过长的描述
- 移除冗余的修饰词
/memory clear —— 清空记忆
⚠️ 危险操作! 这个命令会删除所有记忆。使用前请确保已导出备份。
User: /memory clear
Agent: ⚠️ 警告:这将永久删除所有记忆!
包括:MEMORY.md、USER.md、SQLite 数据库中的所有历史记录。
建议先执行 /memory export 进行备份。
如果你确定要删除,请输入:DELETE ALL MEMORY
User: DELETE ALL MEMORY
Agent: 正在清空所有记忆...
✓ MEMORY.md 已清空
✓ USER.md 已清空
✓ SQLite 数据库已重置
✓ FTS5 索引已重建
所有记忆已清空。Agent 已恢复出厂状态。
7.2 查看当前记忆状态
除了 /memory show,还有多种方式查看记忆状态:
方式一:使用 hermes status
$ hermes status --memory
记忆系统状态
═══════════════
温记忆:
MEMORY.md: 1,850 / 2,200 字符 (84.1%)
USER.md: 890 / 1,375 字符 (64.7%)
状态: 正常
冷记忆:
数据库: ~/.hermes/memory/hermes_memory.db
大小: 18.5 MB
会话: 147
消息: 3,284
工具调用: 892
文件操作: 456
FTS5 索引: 健康
最后维护: 2026-04-20 03:00
外部记忆:
Honcho: 未启用
Mem0: 已启用 (cloud)
OpenViking: 未启用
总体健康度: 良好 ✅
建议: USER.md 容量充足,MEMORY.md 接近上限,建议执行 /memory compact
方式二:使用 hermes memory stats
$ hermes memory stats --detail
详细记忆统计
═══════════════
按时间分布:
今天: 23 条消息
本周: 156 条消息
本月: 892 条消息
本年: 3,284 条消息
按工具类型分布:
web_search: 234 次
file_read: 198 次
file_write: 145 次
code_execute: 112 次
git_commit: 67 次
...
按话题分布 (Top 10):
1. Python 开发 (456 条)
2. 数据库优化 (234 条)
3. API 设计 (189 条)
4. Docker 部署 (156 条)
5. 系统监控 (123 条)
...
高频关键词:
- FastAPI: 89 次
- PostgreSQL: 67 次
- Redis: 54 次
- Docker: 45 次
- pytest: 38 次
7.3 手动添加/删除/修改记忆
除了命令,你还可以在对话中直接用自然语言管理记忆:
# 添加记忆(自然语言方式)
User: 记住,以后提到「老项目」就是指 customer-service-v1
Agent: 已记录到 MEMORY.md:「老项目」= customer-service-v1。
User: 我换手机号了,新号是 138-xxxx-8888
Agent: 已更新 USER.md 中的联系方式。
# 删除记忆
User: 忘掉关于「测试服务器密码」那条,密码已经改了
Agent: 已从 MEMORY.md 中删除包含"测试服务器密码"的条目。
User: 我不用 Django 了,从我的技术栈里删掉
Agent: 已从 USER.md 中删除 Django。
# 修改记忆
User: 更新一下 MEMORY.md,项目的截止日期改成 5 月 15 号
Agent: 已更新:截止日期从 2026-04-30 改为 2026-05-15。
User: 我的主要编程语言现在变成 Go 了,Python 排第二
Agent: 已更新 USER.md:主要语言改为 Go,Python 移到次要语言。
这种方式更直观,不需要记住具体的命令语法。Agent 会理解你的意图并执行相应操作。
7.4 记忆搜索与检索
在冷记忆中搜索历史记录:
# 搜索历史对话
User: /search "Docker Compose"
Agent:
找到 12 条相关记录:
[2026-04-18] 你让 Agent 帮你编写了一个 Docker Compose 文件,
包含 PostgreSQL、Redis 和 Nginx 三个服务。
[2026-04-15] 你询问了 Docker Compose 的网络配置问题,
Agent 建议使用自定义 bridge 网络。
[2026-04-10] ...
要查看某条记录的完整内容,告诉我编号即可。
User: 显示第 1 条
Agent: [展示完整对话内容]
高级搜索语法:
# 时间范围搜索
/search "Docker" --after 2026-04-01 --before 2026-04-20
# 按工具类型过滤
/search "API" --tool file_write
# 按会话标签过滤
/search "性能优化" --tag "project-alpha"
# 组合条件
/search "bug AND (修复 OR 解决)" --after 2026-03-01
7.5 记忆导出与备份
定期备份记忆是良好的数据管理习惯。以下是完整的备份策略:
手动备份:
# 完整备份(推荐每周执行一次)
$ hermes memory backup --full
备份完成:
文件: ~/.hermes/backups/full_backup_20260421.tar.gz
大小: 12.3 MB
包含:
✓ MEMORY.md
✓ USER.md
✓ hermes_memory.db
✓ FTS5 索引
✓ 配置文件
校验和: sha256:7a3f...
# 快速备份(只备份温记忆)
$ hermes memory backup --warm-only
自动备份配置:
# config.yaml
memory:
backup:
enabled: true
schedule: "0 3 * * 0" # 每周日凌晨3点
retention: 10 # 保留最近 10 个备份
destination: "~/.hermes/backups"
compress: true # 压缩备份
encrypt: true # 加密备份(需要设置密码)
encryption_password: "${BACKUP_PASSWORD}" # 从环境变量读取
备份文件结构:
~/.hermes/backups/
├── full_backup_20260414_030000.tar.gz
├── full_backup_20260407_030000.tar.gz
├── full_backup_20260331_030000.tar.gz
└── ...
恢复备份:
# 列出可用备份
$ hermes memory backup --list
可用备份:
1. full_backup_20260421_030000.tar.gz (12.3 MB)
2. full_backup_20260414_030000.tar.gz (11.8 MB)
...
# 恢复指定备份
$ hermes memory restore 1
⚠️ 这将覆盖当前所有记忆。确认吗?(y/N): y
正在恢复...
✓ 恢复完成
7.6 记忆清理与维护
随着时间推移,记忆中会积累一些「垃圾数据」——过时的信息、重复的内容、测试时留下的临时数据。定期清理可以保持记忆系统的高效运作。
自动清理配置:
memory:
maintenance:
auto_cleanup: true
cleanup_schedule: "0 2 * * 0" # 每周日凌晨2点
# 清理规则
rules:
# 规则1:删除30天前的临时会话
- type: "delete_old_sessions"
age_days: 30
conditions:
- "message_count < 5" # 少于5条消息的会话
- "NOT tagged 'important'" # 且没有被标记为重要
# 规则2:合并重复的记忆条目
- type: "merge_duplicates"
similarity_threshold: 0.85
# 规则3:归档旧数据
- type: "archive"
age_days: 90
destination: "~/.hermes/memory/archive/"
手动清理:
# 查看可以清理的内容
$ hermes memory cleanup --dry-run
预计可清理:
- 临时会话: 23 个 (可释放 2.1 MB)
- 重复记忆条目: 7 条 (可释放 350 字符)
- 已删除文件的引用: 12 条
总计可释放: ~2.5 MB
# 执行清理
$ hermes memory cleanup
正在清理...
✓ 已删除 23 个临时会话
✓ 已合并 7 条重复记忆
✓ 已清理 12 条失效引用
已释放 2.5 MB 空间
# 重建索引(如果检索变慢)
$ hermes memory rebuild-index
正在重建 FTS5 索引...
✓ 索引重建完成 (耗时 3.2s)
7.7 定期维护建议
基于社区最佳实践,以下是推荐的记忆系统维护时间表:
| 频率 | 操作 | 命令/方法 |
|---|---|---|
| 每天 | 查看记忆容量状态 | /memory show |
| 每周 | 压缩温记忆 | /memory compact |
| 每周 | 执行自动清理 | hermes memory cleanup |
| 每月 | 完整备份 | hermes memory backup --full |
| 每季度 | 回顾和清理 USER.md | 手动编辑或让 Agent 协助 |
| 每季度 | 重建 FTS5 索引 | hermes memory rebuild-index |
| 每年 | 归档旧数据 | 导出并归档到外部存储 |
Tips
建议在日历中设置定期提醒,或者使用 Hermes 的 Cron 功能自动执行维护任务: ```yaml
config.yaml
cron: - schedule: "0 3 * * 0" # 每周日凌晨3点 command: "hermes memory cleanup && hermes memory backup --full" ```
8. SOUL.md 深度配置
8.1 SOUL.md 与记忆系统的关系
SOUL.md 是 Hermes 中最特殊的配置文件。它不是传统意义上的「记忆」(它不记录历史信息),但它直接影响记忆系统的工作方式。可以把 SOUL.md 理解为 Agent 的「人格设定」和「工作守则」,它决定了 Agent 如何对待记忆、如何使用记忆、以及如何在记忆中筛选信息。
SOUL.md 与记忆系统的关系可以用一个类比来理解:
- SOUL.md 是公司的《员工手册》,规定了员工应该如何工作
- MEMORY.md 是员工手边的「项目笔记本」,记录具体项目的注意事项
- USER.md 是员工的「客户档案」,记录服务对象的偏好
- SQLite 是公司的「档案室」,存放所有历史资料
没有 SOUL.md,Agent 就不知道「我是谁」「我应该怎么工作」「什么信息值得记住」。
SOUL.md 默认位于:
~/.hermes/SOUL.md
8.2 高效 SOUL.md 模板大全
根据不同的使用场景,SOUL.md 的内容应该有所不同。以下提供 5 个经过社区验证的高效模板。
模板一:投研助手
# SOUL — 投研助手
## 身份
你是专业的投研分析师,擅长从海量信息中提取投资逻辑,
生成结构化的研究报告。
## 工作准则
1. 所有数据来源必须标注,不可编造数据
2. 财务指标计算必须展示公式和过程
3. 风险提示必须用单独章节呈现
4. 观点必须区分「事实」「推断」「猜测」
## 记忆策略
- 记住用户关注的行业和个股
- 记录每次研究的关键结论和置信度
- 保留重要的财务数据和估值模型
- 建立「观点追踪」:记录观点的形成时间和修正历史
## 输出格式
- 标题层级不超过 3 级
- 关键数据用表格呈现
- 图表用 Mermaid 或 ASCII 绘制
- 报告末尾附「信息来源」和「免责声明」
## 语言风格
- 专业、客观、冷静
- 避免使用「肯定」「绝对」等确定性词汇
- 多用「数据显示」「从...来看」「如果...则」
## 特殊规则
- 涉及具体股票时,必须提醒「不构成投资建议」
- 使用 MEMORY.md 记录:关注列表、估值模型参数、研究进度
- 使用 USER.md 了解用户的风险偏好和投资周期
模板二:编程助手
# SOUL — 编程助手
## 身份
你是资深全栈工程师,代码风格严谨,注重可维护性和性能。
## 工作准则
1. 所有代码必须包含类型注解和 docstring
2. 必须先写测试用例,再写实现代码(TDD)
3. 复杂逻辑必须添加注释说明「为什么」而非「做什么」
4. 提交代码前必须运行 linter 和 formatter
## 记忆策略
- 记住项目的技术栈和架构决策
- 记录代码规范和团队约定
- 保留重要 API 的接口定义
- 建立「常见错误」清单,避免重复犯错
## 代码规范
- Python: PEP8 + Black + isort + mypy --strict
- JavaScript: ESLint + Prettier + TypeScript strict
- Go: gofmt + golint + go vet
- Rust: rustfmt + clippy
- Git: conventional commits
## 调试策略
1. 先看日志,再看代码
2. 用二分法定位问题
3. 修复后必须添加回归测试
4. 复杂 bug 记录到 MEMORY.md,避免重复踩坑
## 特殊规则
- 遇到不确定的 API 行为,先查官方文档而非猜测
- 涉及安全(密码、密钥、Token)时,提醒用户检查 .env 配置
- 重构前先备份,使用 git branch 隔离变更
模板三:写作助手
# SOUL — 写作助手
## 身份
你是专业编辑和内容策略师,帮助用户产出高质量的文字内容。
## 工作准则
1. 先理解受众和目的,再开始写作
2. 每个段落只讲一个核心观点
3. 使用主动语态,少用被动语态
4. 删除所有不必要的副词和形容词
## 记忆策略
- 记住用户的写作风格和常用表达
- 记录用户的品牌调性和内容禁忌
- 保留高质量的文章模板和框架
- 建立「金句库」和「案例库」
## 写作流程
1. 需求澄清:确定主题、受众、目的、长度
2. 大纲构建:列出核心观点和支撑论据
3. 初稿撰写:快速产出,不纠结细节
4. 修改润色:检查逻辑、删减冗余、优化表达
5. 终稿确认:检查事实、校对文字
## 风格偏好(从 USER.md 获取)
- 根据用户的行业调整专业度
- 根据用户的受众调整语言难度
- 根据用户的品牌调整语气(正式/亲和/幽默)
## 特殊规则
- 涉及数据时必须标注来源
- 引用他人观点必须注明出处
- 避免使用 AI 味重的表达(如「值得注意的是」「总的来说」)
- 中文写作时,技术术语保留英文,其余用中文
模板四:客服助手
# SOUL — 客服助手
## 身份
你是专业的客户服务代表,代表公司与客户沟通。
你的目标是:快速理解客户问题,提供准确有效的解决方案,
同时维护公司形象和客户满意度。
## 工作准则
1. 首次回复必须在理解问题后 30 秒内给出
2. 每个回复都要包含「共情表达」+「解决方案」+「下一步行动」
3. 不确定的答案不要猜测,明确说「我需要确认一下」
4. 涉及退款/赔偿等敏感操作,必须按流程升级
## 记忆策略
- 记住客户的历史工单和解决记录
- 记录常见问题和标准答案(FAQ)
- 保留产品已知问题和 workaround
- 记录客户的情绪状态和沟通风格
## 沟通模板
**开场白:**
"您好,感谢您联系客服。我是您的专属客服助手。
我已经查看了您的账户信息,请问有什么可以帮您?"
**问题确认:**
"我理解您的意思是...(复述问题),对吗?"
**提供方案:**
"针对您的问题,我建议...
[方案1] ...
[方案2] ...
您希望选择哪种方式?"
**结束语:**
"问题已解决/正在处理中。如有其他问题随时联系。
祝您使用愉快!"
## 升级规则
以下情况必须转人工:
- 客户明确要求人工
- 涉及法律纠纷
- 退款金额超过 $100
- 客户情绪极度激动
- 技术问题超出知识库范围
## 特殊规则
- 绝不透露其他客户的信息
- 绝不承诺无法兑现的服务
- 所有承诺必须记录到 MEMORY.md
模板五:个人助理
# SOUL — 个人助理
## 身份
你是用户的私人助理,帮助管理日程、提醒事项、信息整理和日常决策。
你像一位经验丰富、值得信赖的行政助理。
## 工作准则
1. 主动但不越界——提供建议,但不替用户做决定
2. 时间管理优先于任务管理——帮助用户决定「什么时候做」而非「做什么」
3. 信息过滤——只推送用户真正关心的信息
4. 保护隐私——绝不泄露用户的个人信息
## 记忆策略
- 记住用户的日程安排和截止日期
- 记录重要联系人和关系网络
- 保留用户的生活习惯和偏好
- 建立「待办事项」和「购物清单」
## 日常流程
**每天早上:**
- 查看当日日程
- 提醒即将到期的事项
- 建议今日优先级
**每周一:**
- 总结上周完成情况
- 规划本周重点任务
- 检查长期目标的进度
**每月初:**
- 回顾上月支出(如配置了记账)
- 更新目标和计划
- 清理过期的提醒和清单
## 提醒规则
- 重要事项提前 1 天提醒
- 紧急事项提前 2 小时提醒
- 周期性事项(生日、纪念日)提前 1 周提醒
- 用户说过「别忘了...」的事项,在合适的时间提醒
## 特殊规则
- 涉及金钱决策时,提供分析但不建议
- 涉及健康问题时,建议咨询专业人士
- 涉及人际关系时,保持中立和同理心
- 使用 MEMORY.md 记录:待办事项、重要日期、购物清单
8.3 让 Agent 自动优化 SOUL.md 的技巧
SOUL.md 不是一成不变的。随着你使用 Hermes 的时间增长,你会发现某些规则有效、某些规则需要调整。Hermes 支持让 Agent 自动优化 SOUL.md。
技巧一:定期回顾
User: 回顾过去两周的对话,看看 SOUL.md 中有哪些规则经常被我纠正或忽略
Agent:
分析了过去 30 个会话,发现:
- 「所有代码必须包含类型注解」这条你经常补充说明「这次不用」
建议:添加例外规则「脚本/原型代码可省略类型注解」
- 「先写测试再写实现」在实际工作中执行率只有 30%
建议:改为「重要模块必须写测试,脚本/工具可灵活处理」
- 你多次要求 Agent 用中文解释技术概念
建议:在语言风格中添加「技术概念优先用中文解释」
是否应用这些优化?
User: 应用
Agent: 已更新 SOUL.md。
技巧二:A/B 测试
你可以维护两个版本的 SOUL.md,测试哪个效果更好:
~/.hermes/
├── SOUL.md # 当前版本
├── SOUL.md.v1 # 版本1(控制组)
└── SOUL.md.v2 # 版本2(实验组)
切换版本:
User: 切换到 SOUL 版本 2
Agent: 已加载 SOUL.md.v2,本次会话将使用新版本。
技巧三:分场景 SOUL
为不同任务类型准备不同的 SOUL.md:
# config.yaml
soul:
default: "~/.hermes/SOUL.md"
profiles:
coding: "~/.hermes/SOUL-coding.md"
writing: "~/.hermes/SOUL-writing.md"
research: "~/.hermes/SOUL-research.md"
在对话中切换:
User: /soul coding
Agent: 已切换至编程助手人格。
8.4 SOUL.md 的版本管理
SOUL.md 是核心配置文件,建议使用版本控制:
# 初始化 Git 仓库
$ cd ~/.hermes
$ git init
$ git add SOUL.md MEMORY.md USER.md config.yaml
$ git commit -m "初始配置"
# 每次修改后提交
$ git add SOUL.md
$ git commit -m "优化代码规范:允许原型代码省略类型注解"
# 查看修改历史
$ git log --oneline SOUL.md
a3f7d2e 优化代码规范:允许原型代码省略类型注解
c8e9b1a 添加调试策略章节
f2d4e8c 初始配置
# 回退到某个版本
$ git checkout f2d4e8c -- SOUL.md
你也可以让 Hermes 帮你管理版本:
User: 保存当前 SOUL.md 为 "v2.1-宽松版"
Agent: 已保存快照:SOUL.md.v2.1-宽松版
User: 列出所有 SOUL 版本
Agent:
可用版本:
1. v1.0-初始版 (2026-03-01)
2. v1.1-添加写作规则 (2026-03-15)
3. v2.0-严格版 (2026-04-01)
4. v2.1-宽松版 (当前)
User: 回退到 v2.0-严格版
Agent: 已回退到 v2.0-严格版。
9. 隐私与安全
9.1 纯本地存储的安全优势
Hermes 记忆系统最核心的安全特性就是:所有数据默认存储在本地。
这意味着:
- 数据不出境:你的对话内容、工作文件、个人偏好,永远不会离开你的电脑
- 无网络依赖:即使没有网络,记忆系统也能正常工作
- 无第三方访问:没有云服务提供商能看到你的数据
- 完全可控:你可以随时查看、修改、删除任何数据
对比一下云端方案:
| 维度 | Hermes 本地存储 | 云端记忆服务 |
|---|---|---|
| 数据位置 | 你的电脑 | 服务商的服务器 |
| 网络依赖 | 无 | 必须有网络 |
| 隐私控制 | 完全自主 | 依赖服务商政策 |
| 数据泄露风险 | 低(物理安全) | 中(依赖服务商安全) |
| 合规审计 | 容易 | 困难 |
| 跨设备同步 | 需手动 | 自动 |
对于处理敏感信息的用户(如企业内网开发、医疗数据处理、金融分析),纯本地存储几乎是必选方案。
9.2 数据加密选项
虽然本地存储已经很安全,但如果你有多人共用电脑、或者担心电脑被盗,可以启用数据加密。
SQLite 数据库加密:
SQLite 本身不内置加密,但可以通过 SQLCipher 扩展实现:
# 安装 SQLCipher
$ brew install sqlcipher # macOS
$ apt-get install sqlcipher # Ubuntu
# 在 Hermes 配置中启用
```yaml
memory:
encryption:
enabled: true
provider: "sqlcipher"
# 密码从环境变量读取,不会写入配置文件
password_env: "HERMES_DB_PASSWORD"
设置环境变量
$ export HERMES_DB_PASSWORD="your-strong-password"
启用加密后,即使有人拿到了你的 `.db` 文件,没有密码也无法读取内容。
**温记忆文件加密:**
MEMORY.md 和 USER.md 是纯文本文件,可以用 GPG 加密:
```bash
# 加密
$ gpg --symmetric --cipher-algo AES256 ~/.hermes/memory/MEMORY.md
# 会生成 MEMORY.md.gpg
# 解密(Hermes 启动时自动执行)
$ gpg --decrypt ~/.hermes/memory/MEMORY.md.gpg > ~/.hermes/memory/MEMORY.md
Hermes 支持自动加解密配置:
memory:
encryption:
warm_memory:
enabled: true
method: "gpg"
key_id: "your-gpg-key-id"
9.3 敏感信息过滤机制
即使数据存储在本地,你仍然可能不小心在对话中透露敏感信息(如密码、API 密钥、身份证号)。Hermes 提供了敏感信息过滤机制:
自动检测与替换:
security:
sensitive_data_filter:
enabled: true
# 检测规则
patterns:
- name: "api_key"
regex: "(sk-|ak-|pk-)[a-zA-Z0-9]{20,}"
action: "hash_and_store" # 哈希存储,不存明文
- name: "password"
regex: "(?i)(password|passwd|pwd)\s*[:=]\s*[^\s]+"
action: "redact" # 替换为 [REDACTED]
- name: "credit_card"
regex: "\b(?:\d{4}[-\s]?){3}\d{4}\b"
action: "block" # 阻止保存
- name: "id_card"
regex: "\d{17}[\dXx]|\d{15}"
action: "block"
# 自定义规则
custom_patterns:
- name: "internal_ip"
regex: "10\.\d{1,3}\.\d{1,3}\.\d{1,3}"
action: "redact"
效果示例:
用户输入: "我的 API Key 是 sk-abc123xyz789..."
存储到数据库前:
→ 检测到 api_key 模式
→ 替换为: "我的 API Key 是 [API_KEY_HASH:a3f7d2e...]"
→ 原始密钥不存储,只存哈希值
用户输入: "密码是 Secret123!"
存储到数据库前:
→ 检测到 password 模式
→ 替换为: "密码是 [REDACTED]"
注意
敏感信息过滤只在存储到冷记忆(SQLite)时生效。如果你让 Agent 把敏感信息写入 MEMORY.md,它仍然会以明文形式存储在文件中(虽然文件在本地)。建议不要把真正的密码写入 MEMORY.md,而是使用环境变量或密码管理器。
9.4 数据备份加密方案
前面我们讲了如何备份记忆。如果备份文件也需要加密(比如你要把备份存到云盘):
# 方法1:使用 GPG 加密备份
$ tar czf - ~/.hermes/memory/ | gpg --symmetric --cipher-algo AES256 > backup_20260421.tar.gz.gpg
# 解密恢复
$ gpg --decrypt backup_20260421.tar.gz.gpg | tar xzf -
# 方法2:使用 age(更现代的加密工具)
$ tar czf - ~/.hermes/memory/ | age -p > backup_20260421.tar.gz.age
# 方法3:使用 Hermes 内置的备份加密
$ hermes memory backup --full --encrypt --password-file ~/.hermes/.backup_pass
9.5 与云端记忆方案的隐私对比
最后,我们用一张详细的对比表来总结 Hermes 本地记忆与云端记忆的隐私差异:
| 隐私维度 | Hermes 本地 | 云端记忆服务 |
|---|---|---|
| 数据存储位置 | 用户设备 | 服务商服务器 |
| 数据传输 | 无(纯本地) | 必须通过HTTPS上传 |
| 服务商能否读取数据 | 不能 | 技术上可以(依赖信任) |
| 政府/法律调取 | 需物理获取设备 | 服务商可能被迫提供 |
| 数据删除彻底性 | 用户自行删除,可控 | 依赖服务商执行 |
| 加密密钥控制 | 用户持有 | 服务商持有或托管 |
| 审计能力 | 完全透明 | 黑盒 |
| 合规认证(SOC2/ISO27001) | 不适用 | 需查验服务商证书 |
结论:
- 如果你处理的是公开信息或非敏感数据,云端记忆的便利性可能更重要
- 如果你处理的是企业机密、个人隐私或受监管数据,Hermes 的纯本地存储是更安全的选择
- 最佳实践是:敏感数据用本地存储,非敏感数据可选择云端扩展
10. 高级配置与调优
10.1 记忆相关 config.yaml 参数详解
config.yaml 是 Hermes 的核心配置文件,其中与记忆系统相关的参数众多。以下是完整参数说明:
# ~/.hermes/config.yaml
memory:
# ═══════════════════════════════════════
# 温记忆配置
# ═══════════════════════════════════════
warm:
# MEMORY.md 的最大字符数(软限制)
max_memory_md_chars: 2200
# USER.md 的最大字符数(软限制)
max_user_md_chars: 1375
# 自动压缩阈值(超过此比例自动触发 compact)
auto_compact_threshold: 0.85
# 温记忆文件路径
memory_md_path: "~/.hermes/memory/MEMORY.md"
user_md_path: "~/.hermes/memory/USER.md"
# 自动写入的触发条件
auto_write:
enabled: true
triggers:
- explicit_request # 用户明确要求记录
- task_completion # 任务完成时
- important_decision # 重要决策时
- session_end # 会话结束时
# ═══════════════════════════════════════
# 冷记忆配置
# ═══════════════════════════════════════
cold:
# SQLite 数据库路径
db_path: "~/.hermes/memory/hermes_memory.db"
# FTS5 配置
fts5:
enabled: true
tokenizer: "porter" # 分词器: porter / simple / icu
# 检索配置
retrieval:
# 每次检索返回的最大片段数
max_fragments: 5
# 每个片段的最大 Token 数
fragment_max_tokens: 150
# 检索的时间范围(天)
time_decay_days: 90
# 检索时使用的字段权重
field_weights:
message_content: 1.0
tool_result: 0.8
file_operation: 0.6
summary: 1.2
# 相似度阈值(低于此值的结果丢弃)
min_relevance_score: 0.3
# 会话摘要配置
summarization:
enabled: true
# 摘要模型(使用主模型或轻量模型)
model: "same_as_main" # 或指定如 "gpt-4o-mini"
max_summary_length: 200
# 数据保留策略
retention:
# 保留策略类型: forever / age_based / count_based
policy: "age_based"
# 按时间保留:超过此天数的会话归档
max_age_days: 365
# 按数量保留:最多保留多少条会话
max_conversations: 2000
# 归档路径(不删除,只移动)
archive_path: "~/.hermes/memory/archive/"
# ═══════════════════════════════════════
# 热记忆配置
# ═══════════════════════════════════════
hot:
# 上下文管理策略
context_management:
# 自动 compact 触发阈值(上下文使用比例)
auto_compact_threshold: 0.75
# 压缩时保留的最近消息数
preserve_recent: 5
# 溢出时的处理策略: compact / truncate / error
overflow_strategy: "compact"
# 系统提示和 SOUL.md 是否计入上下文限制
count_system_in_limit: true
# ═══════════════════════════════════════
# 外部记忆配置
# ═══════════════════════════════════════
external:
honcho:
enabled: false
# 详见第6章
mem0:
enabled: false
# 详见第6章
openviking:
enabled: false
# 详见第6章
# ═══════════════════════════════════════
# 维护配置
# ═══════════════════════════════════════
maintenance:
# 自动维护任务
auto_cleanup:
enabled: true
schedule: "0 2 * * 0" # Cron 表达式
# 备份配置
backup:
enabled: true
schedule: "0 3 * * 0"
retention: 10
encrypt: false
destination: "~/.hermes/backups"
# 索引优化
index_optimization:
enabled: true
schedule: "0 4 1 * *" # 每月1日凌晨4点
10.2 记忆保留策略调整
根据你的使用习惯,可以调整记忆的保留策略:
场景一:短期项目(1-3个月)
memory:
cold:
retention:
policy: "age_based"
max_age_days: 90 # 只保留3个月
archive_path: "~/.hermes/memory/archive/"
warm:
auto_compact_threshold: 0.70 # 更频繁地压缩
场景二:长期知识积累(1年以上)
memory:
cold:
retention:
policy: "count_based"
max_conversations: 5000 # 保留大量会话
max_age_days: 730 # 最多2年
warm:
auto_compact_threshold: 0.90 # 允许温记忆更满
场景三:极简模式(只保留关键信息)
memory:
cold:
retention:
policy: "age_based"
max_age_days: 30 # 只保留1个月
summarization:
enabled: true # 但必须生成摘要
warm:
auto_compact_threshold: 0.60 # 频繁压缩
max_memory_md_chars: 1500 # 更小的温记忆
max_user_md_chars: 1000
10.3 检索精度 vs 召回率的平衡
在信息检索领域,有两个核心指标:
- 精度(Precision):检索到的结果中,真正相关的比例。精度高 = 垃圾结果少
- 召回率(Recall):所有相关结果中,被检索到的比例。召回率高 = 漏掉的少
这两个指标通常此消彼长。在 Hermes 中,你可以通过参数调整这个平衡:
偏向精度(适合明确知道要找什么的场景):
memory:
cold:
retrieval:
max_fragments: 3 # 只取最相关的结果
min_relevance_score: 0.6 # 提高门槛
fragment_max_tokens: 100 # 更短的片段
偏向召回率(适合探索性查询,宁可多不要漏):
memory:
cold:
retrieval:
max_fragments: 10 # 取更多结果
min_relevance_score: 0.1 # 降低门槛
fragment_max_tokens: 200 # 更长的片段
time_decay_days: 180 # 更广的时间范围
10.4 大数据量下的性能优化
当数据库增长到几百 MB 甚至 GB 级别时,检索速度可能会下降。以下是优化策略:
策略一:分区存储
memory:
cold:
# 按时间分区,每个季度的数据一个数据库文件
partitioning:
enabled: true
granularity: "quarterly" # monthly / quarterly / yearly
# 检索时只查最近的分区,除非用户明确要求
retrieval:
default_partitions: 2 # 默认查最近2个分区
策略二:索引优化
# 手动执行索引优化
$ hermes memory optimize-index
# 这个命令会:
# 1. 重建 FTS5 索引(消除碎片)
# 2. 运行 ANALYZE 优化查询计划
# 3. 清理已删除数据占用的空间(VACUUM)
策略三:读写分离
如果你需要同时进行大量写入和查询:
memory:
cold:
# 写入到主库,查询从副本
replication:
enabled: true
sync_interval: 60 # 每60秒同步一次
策略四:硬件加速
memory:
cold:
# 使用 SSD(如果还没用的话)
# SQLite 在 SSD 上性能提升数倍
# 调整缓存大小
pragma:
cache_size: 10000 # 页面数(约 40 MB)
temp_store: "memory" # 临时表存内存
journal_mode: "wal" # Write-Ahead Logging,提高并发
10.5 hermes status 查看记忆统计
hermes status 是监控记忆系统健康状况的重要工具。让我们详细解读它的输出:
$ hermes status --verbose
═══════════════════════════════════════════════════
Hermes Agent Status
═══════════════════════════════════════════════════
版本: 2.1.0
运行时间: 3天 7小时 22分钟
── 模型 ──────────────────────────────────────────
当前模型: claude-3-7-sonnet-20250219
上下文窗口: 32,000 Tokens
当前使用: 8,450 Tokens (26.4%)
- 系统提示: 450 Tokens
- SOUL.md: 320 Tokens
- USER.md: 180 Tokens
- MEMORY.md: 290 Tokens
- 冷记忆片段: 210 Tokens
- 对话历史: 7,000 Tokens
── 记忆系统 ──────────────────────────────────────
温记忆:
MEMORY.md:
大小: 1,850 / 2,200 字符 (84.1%) ⚠️ 接近上限
上次更新: 2小时前
条目数: 23
USER.md:
大小: 890 / 1,375 字符 (64.7%) ✅ 正常
上次更新: 1天前
条目数: 15
冷记忆:
数据库: ~/.hermes/memory/hermes_memory.db
文件大小: 18.5 MB
统计:
会话: 147
消息: 3,284
工具调用: 892 (成功率: 94.2%)
文件操作: 456
记忆片段: 1,234
FTS5 索引:
状态: ✅ 健康
索引大小: 2.3 MB
最后优化: 2天前
碎片化程度: 12% (正常范围)
检索性能:
平均响应时间: 23ms
99分位响应时间: 87ms
近7天查询次数: 234
外部记忆:
Honcho: 未启用
Mem0: ✅ 已启用 (cloud)
同步状态: 已同步 (2分钟前)
云端记忆数: 156
OpenViking: 未启用
── 健康度评估 ────────────────────────────────────
总体健康度: 良好 (85/100)
建议:
1. ⚠️ MEMORY.md 使用率超过 80%,建议执行 /memory compact
2. ℹ️ FTS5 索引已 2 天未优化,建议执行 hermes memory optimize-index
3. ✅ 其他指标正常
── 资源使用 ──────────────────────────────────────
CPU: 2.3% (平均)
内存: 245 MB
磁盘: 18.5 MB (记忆) + 45.2 MB (其他)
网络: 1.2 KB/s (Mem0 同步)
═══════════════════════════════════════════════════
重点关注这些指标:
- 上下文使用率:超过 70% 就应该 compact
- 温记忆使用率:超过 85% 需要清理或压缩
- FTS5 碎片化:超过 30% 需要优化
- 检索响应时间:超过 200ms 需要优化索引
- 工具调用成功率:低于 90% 可能表示配置问题
11. 常见问题与排障
11.1 记忆不生效?
症状: 你明明告诉 Agent 记住了某件事情,但下次会话时它似乎「忘了」。
排查步骤:
步骤1:检查记忆是否真的被写入
User: /memory show
看看你要记住的内容是否在 MEMORY.md 或 USER.md 中。如果没有,说明写入失败了。
步骤2:检查写入时机
如果你是在会话中途让 Agent 记住的,但随后会话崩溃了(比如网络断开),写入可能没有完成。建议在让 Agent 记住重要信息后,再确认一次:
User: 记住了吗?给我看看 MEMORY.md
Agent: [展示内容]
步骤3:检查容量是否已满
如果 MEMORY.md 或 USER.md 已经达到容量上限,新内容可能无法写入:
User: /memory show
# 查看使用率是否 100%
如果是满的,执行 /memory compact 或手动删除不重要的条目。
步骤4:检查检索是否被触发
有时候记忆确实存储了,但检索时没有匹配到。可能是因为:
- 你的查询关键词和记忆中存储的关键词不匹配
- 检索的时间范围太窄(只查最近7天,但记忆是30天前的)
- 相关度阈值太高,结果被过滤掉了
尝试扩大检索范围:
memory:
cold:
retrieval:
time_decay_days: 365 # 扩大时间范围
min_relevance_score: 0.1 # 降低门槛
步骤5:检查外部记忆冲突
如果你同时启用了外部记忆(如 Mem0),可能存在数据不一致:
User: 当前使用哪些记忆来源?
Agent: 正在使用:本地 SQLite、Mem0 Cloud。
本地记忆:156 条会话
Mem0 记忆:89 条记录
注意:Mem0 中的部分记忆与本地记忆有冲突(3条)。
如果有冲突,优先使用本地记忆,或手动同步两个来源。
11.2 记忆太多太杂?
症状: MEMORY.md 里塞满了各种信息,Agent 经常被不相关的内容干扰。
解决方案:
方案1:分类管理
把 MEMORY.md 按项目/主题分成多个文件:
~/.hermes/memory/
├── MEMORY.md # 通用记忆
├── MEMORY-project-alpha.md # 项目A
├── MEMORY-project-beta.md # 项目B
└── MEMORY-personal.md # 个人事务
在对话中切换:
User: 切换到 project-alpha 的记忆
Agent: 已加载 MEMORY-project-alpha.md。
方案2:定期审计
每月让 Agent 帮你审查 MEMORY.md:
User: 审查一下 MEMORY.md,删除过时的、合并重复的
Agent:
审查结果:
建议删除(已过时):
- "测试服务器地址: 192.168.1.50" (服务器已下线)
- "项目 deadline: 2026-03-01" (已过期)
建议合并(内容重复):
- 3 条关于 API 地址的条目 → 合并为 1 条
建议保留:
- 所有关于技术栈的信息
- Git 仓库地址
是否执行这些修改?
User: 执行
Agent: 已优化 MEMORY.md。
删除: 4 条
合并: 3 条 → 1 条
当前使用率: 68% (原为 94%)
方案3:使用标签系统
给记忆条目打标签,便于分类和筛选:
## Project [tag:work, tag:active]
- 项目名称: Alpha
- 状态: 进行中
## Personal [tag:personal]
- 生日提醒: 妈妈的生日是 5 月 15 日
## Archived [tag:work, tag:archived]
- 旧项目 Beta 的信息...
11.3 检索结果不准确?
症状: 你搜索某个关键词,返回的结果完全不相关;或者明明记得某件事情,却检索不到。
原因和解决方案:
原因1:分词问题(尤其是中文)
FTS5 的默认分词器对中文支持不够好。如果你搜索「数据分析」,它可能只匹配「数」「据」「分」「析」单独出现的情况。
解决: 确保启用了适合中文的分词器:
memory:
cold:
fts5:
tokenizer: "icu zh_CN" # 使用 ICU 分词器,中文支持更好
或者安装 jieba 分词器:
pip install jieba
memory:
cold:
fts5:
tokenizer: "jieba"
原因2:关键词不匹配
你可能搜索「Docker」,但记忆中写的是「容器化技术」。
解决: 使用更宽泛的搜索词,或让 Agent 帮你找:
User: 帮我找找关于容器部署的记录
Agent: 找到以下内容(包含 Docker、Kubernetes、container 等关键词)...
原因3:时间范围过滤
默认只检索最近 90 天的记录,你要找的内容可能是半年前的。
解决: 扩大时间范围:
User: /search "Docker" --after 2025-01-01
原因4:相关度阈值过高
如果 min_relevance_score 设置得太高(如 0.8),很多相关但匹配度不够高的结果会被过滤掉。
解决: 暂时降低阈值:
memory:
cold:
retrieval:
min_relevance_score: 0.1
11.4 数据库损坏修复
SQLite 数据库虽然稳定,但在极端情况下(如电脑突然断电、磁盘空间不足、文件系统损坏)可能会损坏。
症状:
- Hermes 启动时报数据库错误
- 检索功能完全失效
hermes status显示数据库异常
修复步骤:
步骤1:备份当前数据库
$ cp ~/.hermes/memory/hermes_memory.db ~/.hermes/memory/hermes_memory.db.bak
步骤2:检查数据库完整性
$ sqlite3 ~/.hermes/memory/hermes_memory.db "PRAGMA integrity_check;"
如果返回 ok,说明数据库结构完整。如果返回错误信息,继续下一步。
步骤3:尝试修复
# 方法1:使用 SQLite 的恢复模式
$ sqlite3 ~/.hermes/memory/hermes_memory.db ".recover" | sqlite3 ~/.hermes/memory/hermes_memory_fixed.db
# 方法2:使用 Hermes 内置修复工具
$ hermes memory repair --force
步骤4:如果修复失败,从备份恢复
# 使用最近的自动备份
$ hermes memory restore --latest
# 或手动恢复
$ cp ~/.hermes/backups/full_backup_20260414/hermes_memory.db ~/.hermes/memory/
步骤5:如果备份也损坏
最坏的情况下,你可以重建数据库:
$ hermes memory reset
# 这会删除所有冷记忆,但保留温记忆(MEMORY.md 和 USER.md)
注意
数据库损坏的情况非常罕见(SQLite 被设计为在断电时也能保持数据完整)。真正发生损坏时,通常是磁盘硬件问题。建议定期检查磁盘健康状态,并保持定期备份的习惯。
11.5 迁移时记忆丢失?
症状: 你把 Hermes 从一台电脑迁移到另一台电脑,发现记忆「丢失」了。
原因: 记忆文件没有正确迁移,或者路径配置不一致。
正确的迁移步骤:
步骤1:在旧机器上导出完整备份
$ hermes memory backup --full
备份已保存到: ~/.hermes/backups/full_backup_20260421.tar.gz
步骤2:复制配置文件和记忆目录
# 需要复制的文件和目录
~/.hermes/config.yaml
~/.hermes/SOUL.md
~/.hermes/memory/ # 整个记忆目录
~/.hermes/skills/ # 如果有自定义技能
步骤3:在新机器上安装 Hermes
# 按照安装指南安装 Hermes
# 但不要启动,等配置文件复制完成后再启动
步骤4:复制文件到新机器
# 使用 scp
$ scp -r ~/.hermes/ user@new-machine:~/
# 或使用云存储同步
# 将 ~/.hermes/ 放入 Dropbox / iCloud / OneDrive 同步
步骤5:验证路径配置
# 检查 config.yaml 中的路径是否匹配新机器
memory:
cold:
db_path: "~/.hermes/memory/hermes_memory.db" # 使用 ~ 会自动解析为当前用户目录
如果使用绝对路径,需要确保新机器上的路径一致。
步骤6:启动 Hermes 并验证
$ hermes status --memory
# 检查会话数、消息数是否与旧机器一致
$ /memory show
# 检查 MEMORY.md 和 USER.md 内容是否完整
$ /search "测试"
# 检查冷记忆检索是否正常
常见问题:
- 权限问题:确保新机器上的文件权限正确(
chmod 600对于敏感文件) - 路径问题:Windows 和 macOS/Linux 的路径格式不同,注意转换
- 版本兼容:如果新旧机器的 Hermes 版本差异很大,可能需要升级数据库格式:
hermes memory migrate
本章小结
恭喜你读完了这本白皮书中最「硬核」的一章!让我们回顾一下核心要点:
四层温度记忆模型是 Hermes 记忆系统的核心架构:
- 热记忆(会话上下文)—— 快速但易逝,善用
/compact管理 - 温记忆(MEMORY.md + USER.md)—— 持久但精简,是 Agent 的「随身记事本」
- 冷记忆(SQLite + FTS5)—— 海量但按需,智能检索让成本降低 88%
- 外部记忆(Honcho/Mem0 等)—— 扩展能力强,按需集成
关键操作命令:
/compact—— 压缩会话上下文,节省 Token/memory show—— 查看记忆状态/memory add/remove/edit—— 管理温记忆hermes memory backup—— 定期备份hermes memory cleanup—— 清理维护
最佳实践:
- 定期使用
/compact,不要让上下文无限增长 - 善用 MEMORY.md 记录项目信息,善用 USER.md 记录个人偏好
- 温记忆容量有限,只记录真正重要的信息
- 按需检索比全量加载高效 20 倍,是 Hermes 的核心优势
- 定期备份,定期维护,保持记忆系统健康
- SOUL.md 决定了 Agent 如何使用记忆,花时间为不同场景配置合适的模板
隐私与安全:
- 纯本地存储是 Hermes 的最大安全优势
- 如需更高安全性,可启用 SQLite 加密和文件加密
- 敏感信息过滤机制防止意外泄露
- 云端扩展虽好,但敏感数据建议留在本地
记忆系统是 Hermes Agent 的灵魂。没有记忆,Agent 只是一个「聪明的聊天机器人」;有了记忆,Agent 才能真正成为你的「长期搭档」——它记得你的偏好、了解你的项目、回顾你的历史,每一次交互都在积累对「你」的理解。
正如一个好的合作伙伴,不是因为他聪明(市面上聪明的 AI 很多),而是因为他懂你。Hermes 的记忆系统,正在让这种「懂」成为可能。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第八册:技能系统完全指南
本章你将学到
- 什么是 Skill(技能),以及它与传统 Prompt 模板的核心区别
- Skill 文件的内部结构:元数据、触发条件、执行步骤、示例 IO
- Hermes 独门绝技:自动技能创建机制(5-tool-call 规则)
- 技能自我进化的原理与社区实测数据(1-2 周成功率提升 30%+)
- 四个信任等级体系:内置、官方、可信、社区
- Skills Hub 生态:643 个社区技能的浏览、安装与贡献
- 从 Claude Code、Cursor、OpenClaw 迁移技能的方法
- 74 个内置技能和 44 个官方可选技能的分类总览
- 高阶技能开发:复合技能、条件分支、参数模板、错误处理
- 推荐首装的 5 个技能详解:LLM Wiki、Gstack、OpenAI Utils、Manim、Security Audit
1. 技能系统:让 Hermes 从"聊天机器"变成"全能助手"
1.1 什么是 Skill(技能)
想象一下,你雇用了一位实习生。第一天,你手把手教他如何整理周报:先打开 Excel 模板,从 JIRA 导出本周完成的任务,按优先级排序,计算工时统计,最后生成图表并发送给经理。这个过程你教了一遍又一遍。
到了第二周,你正打算再教一次,实习生却说:「放心,上周您教我的流程我已经记下来了,以后每周五下午我自己就能搞定。」
这就是 Skill(技能)的本质——把完成某项任务的标准化流程沉淀下来,让 Agent 能够自主复用。
在 Hermes 中,Skill 是一个存放在 ~/.hermes/skills/<name>/SKILL.md 路径下的 Markdown 文件。它不是一个简单的「提示词模板」,而是一个完整的「任务执行程序」,包含:
- 触发条件:什么情况下应该调用这个技能
- 执行步骤:具体的操作流程(可以包含工具调用、代码执行、文件操作等)
- 所需上下文:执行这个技能需要哪些前置信息
- 示例输入输出:让 Agent 理解期望的结果格式
重要区别:Skill vs 传统 Prompt 模板
传统 Prompt 模板就像一份「菜谱」——上面写着「番茄炒蛋:先炒蛋,再炒番茄,混合在一起」。它只告诉你「做什么」,但不帮你「做」。
Skill 就像一个「自动炒菜机程序」——它不仅知道菜谱,还能自动开煤气、倒油、打鸡蛋、控制火候。它包含的是可执行的工作流,而不仅仅是文字说明。
1.2 Skill 与传统 Prompt 模板的区别
为了更清晰地理解这个区别,我们来看一个具体的对比。
场景:让 AI 帮你「搜索最新 AI 新闻并生成摘要」
传统 Prompt 模板的方式:
请帮我搜索今天关于 AI 的最新新闻,然后生成一份摘要。
要求:
1. 搜索至少 5 条新闻
2. 每条新闻包含标题、来源、关键内容
3. 最后给出整体趋势判断
每次你需要这个服务时,都要把上面的提示词重新发一遍。而且如果结果不满意,你还得手动调整提示词。
Hermes Skill 的方式:
你第一次执行这个任务时,Agent 会:
- 接收你的自然语言指令
- 调用 Web Search 工具搜索新闻
- 调用 LLM 生成摘要
- 调用 File Write 把摘要保存为 Markdown
- 检测到这是一个可复用的模式,自动生成 SKILL.md
下次你只需说:「给我今天的 AI 新闻摘要」,Agent 就会自动加载对应的 Skill,按照既定流程执行——不需要你重复描述要求,不需要你手动调用工具,甚至连输出格式都会和上次保持一致。
这个区别的本质在于:Prompt 模板是「描述」,Skill 是「程序」。
正如 Hermes Atlas 官方文档所强调的:「Claude Code 的 memory 存储关于你的事实——偏好要点。而 Hermes 存储的是程序——产生你想要的要点的研究-过滤-格式化工作流。事实告知模型,程序直接被复用。」
这句话揭示了 Hermes 技能系统的独特价值:它不仅让 Agent 记住「你喜欢什么」,更让 Agent 掌握「如何为你做到」。前者是静态的信息,后者是动态的能力。
1.3 技能系统是 Hermes 最实用的功能
在与大量 Hermes 用户的交流中,我发现一个有趣的现象:当被问到「Hermes 最打动你的功能是什么」时,答案出奇地一致——技能系统。
为什么技能系统如此受欢迎?因为它解决了 AI 应用中最核心的痛点:重复劳动。
在没有技能系统之前,使用 AI 的工作流是这样的:
有需求 → 想提示词 → 写详细 Prompt → 执行 → 检查结果 → 不满意 → 改 Prompt → 再执行 → ...
↑___________________________________________________________↓
(每次都要重复)
有了技能系统之后,工作流变成了:
第一次:有需求 → 自然语言描述 → Agent 自动执行 → 自动生成 Skill
第二次及以后:有需求 → Agent 自动加载 Skill → 自动执行 → 结果满意
把重复的思考成本从人类转移给了机器,这就是技能系统的魔力。
根据社区实测数据,一个典型的 Hermes 用户在使用 1-2 周后:
- 重复任务的成功率提升 30% 以上
- 平均每个任务的交互轮次减少 40%
- 用户对 Agent 的满意度提升显著(因为结果更可预测、更一致)
这些数字的背后,是技能系统在默默发挥作用——它把「每次都从头教」变成了「一次教会,终身复用」。
1.4 技能系统的三大特点:自动创建、自我进化、跨平台复用
Hermes 的技能系统之所以强大,是因为它在三个维度上同时做到了业界领先:
特点一:自动创建(Auto-Generation)
这是 Hermes 最独门、最让其他框架羡慕的绝技。大多数 Agent 框架的技能(或类似的「工作流」「插件」)都需要开发者手动编写。而 Hermes 能够在检测到重复模式后,自动生成 Skill 文件。
触发自动创建的典型条件包括:
- 完成复杂任务(通常涉及 5+ 次工具调用)且成功
- 用户在错误后纠正了做法,Agent 学到了正确的路径
- 发现了非显而易见的工作流组合
- 用户明确说「记住这个流程,下次还要用」
这种自动创建不是简单的「保存聊天记录」,而是 Agent 主动提炼工作流、抽象通用步骤、生成可复用的 SKILL.md 文件。这个过程涉及对任务本质的理解——哪些步骤是通用的、哪些是特定于本次输入的、哪些参数应该暴露给用户调整。
特点二:自我进化(Self-Evolution)
技能不是一经创建就固定不变的。每次使用 Skill 时,Agent 都会收集反馈:
- 这次执行成功了吗?
- 用户有没有做修改或纠正?
- 输出结果与预期是否一致?
- 有没有更高效的方式可以完成?
基于这些反馈,Skill 会自动更新版本,优化执行步骤,修正错误。就像一位厨师,每次做菜后都会微调配方,越做越好。
进化可以是显式的(Agent 主动告诉你「Skill 已更新到 v1.2」),也可以是隐式的(后台默默优化,你发现结果越来越好了)。
特点三:跨平台复用(Cross-Platform Reuse)
Hermes 的 Skill 采用纯 Markdown 格式,不绑定任何特定平台或模型。这意味着:
- 你可以把 Skill 从 Claude Code 迁移到 Hermes
- 你可以把 Skill 从 Cursor 迁移到 Hermes
- 你可以把 Skill 分享给社区的其他用户
- 你可以在 Skills Hub 上找到别人分享的 Skill 并一键安装
Skill 的可移植性让它不仅仅是个人的效率工具,更成为社区协作的载体。目前 Skills Hub 上已经聚集了 643 个社区技能(截至 2026 年 4 月 19 日),涵盖开发、设计、数据分析、内容创作等几乎所有领域。
Tips
如果你是刚接触 Hermes 的新用户,我的建议是:不要急着手动创建 Skill。先正常使用 Hermes 1-2 周,让自动创建机制自然积累你的常用工作流。你会惊讶地发现,Agent 已经默默为你生成了十几个实用的 Skill。在此基础上,再有针对性地手动优化和补充。
2. 技能的内部结构
2.1 Skill 文件格式详解(Markdown)
Hermes 的 Skill 文件是纯 Markdown 格式,这带来了几个显著优势:
- 人类可读:你可以直接用任何文本编辑器打开、阅读、修改
- 版本控制友好:Markdown 与 Git 配合完美,diff 清晰易读
- 工具生态丰富:无数的 Markdown 编辑器、预览工具、lint 工具
- 跨平台:任何操作系统都能处理 Markdown
Skill 的标准存储路径是:
~/.hermes/skills/
├── <skill-name-1>/
│ └── SKILL.md
├── <skill-name-2>/
│ └── SKILL.md
└── ...
每个 Skill 都有自己的目录,目录名就是 Skill 的名称。目录内目前主要存放 SKILL.md,但未来版本可能会支持同目录下的辅助文件(如模板文件、配置文件等)。
2.2 一个完整 Skill 文件的剖析
让我们拆解一个真实的 Skill 文件,看看它包含哪些部分。
以下是一个「新闻抓取与摘要」Skill 的完整示例:
# News Fetch and Summarize
## Metadata
- Name: news-fetch-summarize
- Description: Search for latest news on a given topic and generate
a structured summary report
- Version: 1.2.0
- Tags: news, research, web-search, summary
- Author: auto-generated
- Created: 2026-04-15
- Last Updated: 2026-04-18
## Trigger Conditions
- User asks for "news" or "latest" about a topic
- User requests a "summary" of current events
- User mentions "what's happening" in a domain
## Required Context
- Topic: the subject to search for
- Time range: default to "today", user may specify (week/month)
- Output format: default to markdown, user may request (bullet/table)
## Execution Steps
### Step 1: Search
Use `web_search` tool to find at least 5 relevant news articles.
Query format: `<topic> news <time_range>`
### Step 2: Filter and Rank
Filter results by:
- Relevance to the topic (exclude off-topic results)
- Source credibility (prefer established news outlets)
- Recency (within the specified time range)
Rank by: relevance > credibility > recency
### Step 3: Extract Key Information
For each selected article, extract:
- Title
- Source name and URL
- Publication date
- 2-3 sentence summary of key content
- Any quoted statements or statistics
### Step 4: Generate Summary Report
Structure the output as:
```markdown
# <Topic> News Summary (<Date>)
## Overview
[2-3 sentence overall trend assessment]
## Key Stories
### 1. [Title]
- **Source**: [Name] ([URL])
- **Date**: [Publication date]
- **Summary**: [2-3 sentences]
### 2. [Title]
...
## Trend Analysis
[Overall pattern observation and forward-looking insight]
## Sources
- [Source 1]
- [Source 2]
- ...
Step 5: Save (Optional)
If user requests, save the report to a file:
- Filename: <topic>-news-<date>.md
- Location: current working directory or user-specified
Error Handling
- If web_search returns no results: expand query synonyms and retry
- If sources are all low-credibility: note this in the report
- If user topic is ambiguous: ask for clarification before proceeding
Notes
- Always include source URLs for fact-checking
- Distinguish between facts and speculation in the summary
- For controversial topics, present multiple viewpoints
- Never fabricate information not present in sources
Example Input
User: "Give me today's AI news summary"
Example Output
Agent: "I'll search for the latest AI news and generate a summary for you." [Executes Steps 1-4] "Here's your AI News Summary for April 21, 2026:
AI News Summary (2026-04-21)
Overview
Today's AI landscape sees significant advances in multimodal reasoning and enterprise adoption...
[Full report follows]"
这个文件清晰地展示了一个 Skill 的完整结构。让我们逐一分析每个部分。
#### 元数据区(Metadata)
```markdown
## Metadata
- Name: news-fetch-summarize
- Description: Search for latest news on a given topic and generate
a structured summary report
- Version: 1.2.0
- Tags: news, research, web-search, summary
- Author: auto-generated
- Created: 2026-04-15
- Last Updated: 2026-04-18
元数据区提供 Skill 的基本身份信息:
- Name:Skill 的唯一标识符,通常使用 kebab-case(短横线连接的小写字母)
- Description:一句话描述 Skill 的功能,用于搜索和展示
- Version:语义化版本号(主版本.次版本.修订号),方便追踪变更
- Tags:分类标签,便于管理和搜索
- Author/.Created/Last Updated:追溯信息
触发条件区(Trigger Conditions)
## Trigger Conditions
- User asks for "news" or "latest" about a topic
- User requests a "summary" of current events
- User mentions "what's happening" in a domain
触发条件定义了 Agent 应该在什么情况下「想到」使用这个 Skill。这就像是给 Agent 装了一个「雷达」——当用户的输入匹配这些条件时,Agent 就知道「啊,这个任务可以用 news-fetch-summarize 技能来处理」。
触发条件可以是:
- 关键词匹配:用户输入中包含特定词汇
- 意图识别:用户的请求属于某种意图类别
- 上下文匹配:当前对话的上下文符合某种模式
- 工具链匹配:完成任务需要调用特定的工具组合
执行步骤区(Execution Steps)
这是 Skill 的核心部分,定义了完成任务的具体流程。每个步骤都包含:
- 步骤编号和名称:清晰的流程结构
- 具体操作:使用什么工具、调用什么命令、执行什么逻辑
- 参数说明:输入参数的定义和格式
- 输出规范:该步骤应该产生什么结果
### Step 1: Search
Use `web_search` tool to find at least 5 relevant news articles.
Query format: `<topic> news <time_range>`
步骤之间可以是有顺序依赖的(Step 2 依赖 Step 1 的结果),也可以是并行的(多个步骤可以同时执行)。
注意事项区(Notes / Error Handling)
## Error Handling
- If web_search returns no results: expand query synonyms and retry
- If sources are all low-credibility: note this in the report
- If user topic is ambiguous: ask for clarification before proceeding
## Notes
- Always include source URLs for fact-checking
- Distinguish between facts and speculation in the summary
这个区域记录执行过程中的注意事项、边界情况、错误处理策略等。它帮助 Agent 在遇到意外情况时做出正确的判断,而不是盲目继续或报错退出。
示例输入输出区(Example Input/Output)
## Example Input
User: "Give me today's AI news summary"
## Example Output
Agent: "I'll search for the latest AI news..."
示例是 Skill 质量的关键指标。好的示例能让 Agent 更准确地理解用户的期望和输出的标准。示例越多、覆盖面越广,Skill 的泛化能力就越强。
2.3 技能文件存储位置:~/.hermes/skills/
所有 Skill 都存储在用户的 Hermes 配置目录下的 skills/ 文件夹中:
~/.hermes/skills/
├── news-fetch-summarize/
│ └── SKILL.md
├── code-review-python/
│ └── SKILL.md
├── data-analysis-pipeline/
│ └── SKILL.md
├── docker-deploy/
│ └── SKILL.md
└── ...
这种目录结构的设计考虑到了未来的扩展性:
- 每个 Skill 有自己的目录,避免命名冲突
- 可以在目录中添加辅助文件(如模板、配置、测试数据)
- 便于打包、分享和版本控制
你可以直接操作这个目录:
# 查看所有技能
$ ls ~/.hermes/skills/
# 查看某个技能的内容
$ cat ~/.hermes/skills/news-fetch-summarize/SKILL.md
# 手动复制技能(分享给同事)
$ cp -r ~/.hermes/skills/news-fetch-summarize ./shared-skills/
# 手动安装技能(从同事那里收到的)
$ cp -r ./shared-skills/news-fetch-summarize ~/.hermes/skills/
2.4 技能的命名规范
好的命名让 Skill 更容易被发现和使用。Hermes 社区推荐使用以下命名规范:
基本格式:
<action>-<target>[-<context>]
例如:
search-news:搜索新闻analyze-sentiment:分析情感deploy-docker-prod:部署 Docker 到生产环境generate-report-weekly:生成周报
命名原则:
- 使用小写字母和短横线:kebab-case 是标准,不要用空格或驼峰
- 动作优先:先说明「做什么」,再说明「对谁做」
- 保持简洁:名称不要超过 3-4 个词
- 避免歧义:
fix不如fix-bug或fix-lint-error清晰 - 添加版本后缀:如果同一技能有多个变体,用
-v2、-lite、-advanced区分
按分类命名(可选前缀):
web-search-* # 网络搜索相关
code-* # 代码相关
data-* # 数据分析相关
devops-* # 运维部署相关
content-* # 内容创作相关
research-* # 研究分析相关
Tips
虽然 Hermes 支持中文 Skill 名称(因为文件名只是标识符),但强烈建议使用英文命名。原因有三:1)便于在 Skills Hub 上分享;2)Agent 在匹配触发条件时,英文关键词更稳定;3)与社区其他用户交流时无障碍。
3. 自动技能创建:Hermes 的独门绝技
3.1 触发条件详解
自动技能创建是 Hermes 区别于其他所有 Agent 框架的标志性功能。理解它的触发条件,能帮助你更好地「引导」Agent 为你生成有用的 Skill。
根据 Hermes Atlas 官方文档,Skill 在检测到重复模式后自动生成,典型的触发场景包括:
场景一:完成复杂任务(5+ 工具调用)且成功
这是最主要的触发条件。当 Agent 完成一个涉及多次工具调用的复杂任务时,系统会判断这个工作流是否值得沉淀为 Skill。
为什么是「5+ 次工具调用」?这个数字是经过大量实验验证的「甜蜜点」:
- 少于 5 次:流程太简单,不值得专门创建 Skill(直接每次手动做就行)
- 5 次以上:说明任务有一定复杂度,包含多个步骤的协调,复用价值高
- 过多(20+ 次):可能是任务粒度太大,生成的 Skill 会过于臃肿
官方规则:5-Tool-Call 规则
Hermes 的自动技能创建有一个不成文的「5-tool-call 规则」:当 Agent 在一次任务中成功调用了 5 个或更多工具,且任务最终成功完成,系统就会评估这个工作流是否适合生成 Skill。这个规则确保了只有足够复杂、有复用价值的工作流才会被沉淀下来。
场景二:遇到错误最终找到可行路径
这是一个特别有价值的触发场景。当 Agent 在执行任务时遇到了错误,经过多轮尝试(可能包括你的纠正和引导)最终找到了正确的解决方案,这个「试错→纠正→成功」的完整路径会被记录为一个 Skill。
为什么这种 Skill 特别有价值?因为它包含了「避坑指南」——不仅告诉你「怎么做是对的」,还告诉你「哪些地方容易出错」。
场景三:用户纠正了做法
当你说「不对,应该这样...」或者「下次记得先...再...」时,Agent 会把你的纠正作为重要反馈。如果这种纠正在类似场景中出现过多次,Agent 会推断出一个通用规则,生成 Skill 来固化正确的做法。
User: 帮我部署这个服务
Agent: [尝试直接部署... 失败了]
User: 不对,应该先检查环境变量配置好了没有
Agent: [检查环境变量... 发现问题... 修复后部署成功]
[系统检测到:用户纠正了流程,生成了 Skill "deploy-with-env-check"]
场景四:发现非显而易见的工作流
有时候 Agent 会「创造性地」组合多个工具来完成任务,这种组合可能连开发者都没有预料到。当这种「非显而易见的工作流」被验证为有效时,系统会立即生成 Skill 来记录这个「发现」。
User: 帮我找出这个项目里最近引入 Bug 的提交
Agent: [没有直接的 "find-bug-commit" 工具...]
→ 调用 git log 获取提交历史
→ 调用 git diff 查看每个提交的变更
→ 调用 code_review 工具分析变更
→ 交叉对比 Bug 报告的时间线
→ 找到最可疑的提交
[系统检测到:创新工作流组合,生成了 Skill "git-bisect-intelligent"]
3.2 创建过程详解(从任务执行到 Skill 生成)
自动创建 Skill 不是一个「瞬间完成」的操作,而是一个分阶段的过程。让我们深入了解它的内部机制。
阶段一:模式识别(Pattern Detection)
在任务执行过程中,系统会实时监控工具调用序列、用户输入、Agent 输出之间的关系。它寻找的是「可重复的模式」:
工具调用序列: [web_search] → [file_read] → [code_execute] → [file_write]
用户输入模式: "帮我分析...并生成报告"
输出模式: Markdown 报告,包含图表
→ 检测到模式:搜索-读取-分析-输出报告
阶段二:通用化抽象(Generalization)
识别到模式后,系统需要判断这个模式是「通用」的还是「特定于本次输入」的。通用化的过程包括:
- 提取可变参数(如搜索关键词、文件路径、输出格式)
- 识别固定步骤(如「先搜索再分析」的顺序)
- 确定默认值(如默认搜索 5 条结果、默认输出 Markdown)
特定实例:
用户说 "分析 Python 趋势" → 搜索 Python 新闻 → 生成 Python 报告
通用模式:
用户说 "分析 <topic> 趋势" → 搜索 <topic> 新闻 → 生成 <topic> 报告
→ 可变参数: <topic>
→ 固定步骤: 搜索 → 分析 → 生成报告
→ 默认: 搜索 5 条,输出 Markdown
阶段三:质量评估(Quality Assessment)
不是所有识别出的模式都值得生成 Skill。系统会对候选 Skill 进行质量评分:
| 评估维度 | 权重 | 说明 |
|---|---|---|
| 复用潜力 | 30% | 这个模式在未来被用到的概率 |
| 执行成功率 | 25% | 按照此模式执行,任务成功的概率 |
| 复杂度适中 | 20% | 不太简单(有沉淀价值)也不太复杂(可维护) |
| 用户满意度 | 15% | 用户对这次任务结果的评价 |
| 创新性 | 10% | 是否发现了新的工具组合方式 |
总分超过阈值的候选 Skill 才会进入下一阶段。
阶段四:SKILL.md 生成
通过质量评估后,系统会调用 LLM 生成标准的 SKILL.md 文件。生成过程使用专门的「Skill 生成提示模板」,确保输出符合规范。
生成的 SKILL.md 包含:
- 从任务描述中提取的元数据
- 从用户输入历史中归纳的触发条件
- 从工具调用链中提取的执行步骤
- 从对话中总结的注意事项和错误处理
- 从实际输入输出中提取的示例
阶段五:用户确认(可选)
根据配置,Hermes 可能会在新 Skill 生成后征求你的确认:
Agent: 我刚刚为你生成了一个新的 Skill:news-fetch-summarize
这个 Skill 可以帮你自动搜索新闻并生成摘要。
触发条件:当你要求新闻摘要时
执行步骤:搜索 → 过滤 → 提取 → 生成报告
是否保存这个 Skill?(y/n/edit)
User: y
Agent: Skill 已保存到 ~/.hermes/skills/news-fetch-summarize/SKILL.md
你也可以配置为「自动保存,无需确认」,适合高级用户。
3.3 自动提炼的算法逻辑
自动提炼的核心算法可以概括为「频率 + 重要性 + 结构性」的三维评估模型。
维度一:频率(Frequency)
统计某个工作流在多长时间内被重复了多少次:
frequency_score = min(repeat_count / threshold, 1.0)
# threshold 通常为 2-3 次
# 即同一个工作流重复 2-3 次,频率维度就达到满分
维度二:重要性(Importance)
评估工作流对用户的价值:
importance_factors = {
'tool_call_count': len(tool_calls), # 工具调用越多越重要
'user_explicit_save': user_said_remember, # 用户明确说记住
'task_success': task_completed_successfully, # 任务成功完成
'error_recovery': recovered_from_error, # 从错误中恢复
'time_saved': estimated_time_vs_manual # 节省的时间
}
维度三:结构性(Structure)
评估工作流是否有清晰的步骤结构:
structure_factors = {
'has_clear_steps': has_stepwise_pattern, # 有清晰的步骤序列
'has_parameters': has_extractable_params, # 有可提取的参数
'has_error_handling': handles_edge_cases, # 有错误处理
'has_examples': has_io_examples # 有输入输出示例
}
综合评分 = 频率 × 0.3 + 重要性 × 0.4 + 结构性 × 0.3
评分超过 0.7 的候选 Skill 会被生成。
3.4 实际案例演示(5 个完整案例)
理论讲完了,让我们来看 5 个真实的自动 Skill 创建案例。
案例 1:抓取新闻并总结
第一次执行(无 Skill):
User: 帮我搜一下今天 AI 领域有什么重要新闻,然后总结成一份报告
Agent: 好的,我来帮你搜索和总结。
[调用 web_search: "AI news today"]
[调用 web_search: "artificial intelligence latest"]
[读取搜索结果]
[调用 LLM 生成摘要]
[调用 file_write 保存报告]
Agent: 已完成!报告已保存为 ai-news-20260421.md
第二次执行(已自动生成 Skill):
User: 今天有什么重要的科技新闻吗?
Agent: [检测到触发条件匹配 news-fetch-summarize Skill]
好的,我来搜索今天的科技新闻并为你总结。
[自动按照 Skill 步骤执行]
Agent: 已完成!报告已保存为 tech-news-20260421.md
生成的 SKILL.md 核心内容:
## Trigger Conditions
- User asks for "news" about a topic
- User requests "summary" of current events
- User mentions "what's happening" in tech/AI
## Execution Steps
### Step 1: Search
Use web_search with queries: `<topic> news today`, `<topic> latest`
### Step 2: Summarize
Use LLM to generate structured summary with:
- Key headlines
- Source attribution
- Trend analysis
案例 2:代码重构工作流
背景: 你正在对老项目进行代码重构,需要一系列标准化操作。
第一次执行(手动引导):
User: 帮我重构这个 Python 文件,把里面的函数提取到单独的模块里
Agent: 好的,我来分析文件结构。
[调用 file_read 读取文件]
[调用 code_execute 分析依赖关系]
[调用 file_write 创建新模块]
[调用 file_edit 修改原文件导入]
[调用 code_execute 运行测试验证]
Agent: 重构完成!已通过测试。
User: 记住这个流程,以后重构都用这套方法
后续执行(自动复用):
User: 重构 utils.py,把 helper 函数拆出去
Agent: [加载 code-refactor-extract Skill]
好的,按照标准重构流程处理:
1. 分析文件结构...
2. 提取函数到新模块...
3. 更新导入...
4. 运行测试...
Agent: 重构完成!所有测试通过。
案例 3:数据分析报告生成
背景: 你每周都需要生成一份数据分析报告,流程固定。
自动创建的 Skill: generate-weekly-data-report
## Execution Steps
### Step 1: Data Collection
- Read data files from `data/weekly/` directory
- Validate data format and completeness
### Step 2: Processing
- Clean missing values (fill with median for numeric, mode for categorical)
- Calculate key metrics: total, average, growth rate, MoM change
- Generate pivot tables by category
### Step 3: Visualization
- Create bar chart for top 10 categories
- Create line chart for trend over time
- Create pie chart for distribution
### Step 4: Report Generation
- Generate Markdown report with all charts embedded
- Include executive summary at top
- Include methodology appendix at bottom
### Step 5: Distribution
- Save to `reports/weekly/YYYY-MM-DD-report.md`
- If user requests, send via email (configured in USER.md)
案例 4:多语言翻译校对
背景: 你的项目需要支持多语言,每次更新后都需要翻译和校对。
自动创建的 Skill: translate-and-proofread
## Trigger Conditions
- User asks to "translate" content to multiple languages
- User mentions "localization" or "i18n"
- User requests "proofread" translated content
## Execution Steps
### Step 1: Extract Text
- Parse source files for translatable strings
- Identify format: JSON, YAML, PO, or inline
### Step 2: Translate
- For each target language, call translation API
- Preserve formatting placeholders ({name}, %d, etc.)
- Maintain context consistency across strings
### Step 3: Proofread
- Check for: length overflow (UI constraints), cultural appropriateness,
technical term consistency
- Flag potential issues for human review
### Step 4: Update Files
- Write translated strings back to respective locale files
- Run validation to ensure no syntax errors
案例 5:自动化部署脚本
背景: 你每次发布新版本都需要执行一系列部署操作。
自动创建的 Skill: deploy-release-pipeline
## Execution Steps
### Step 1: Pre-deployment Checks
- Verify all tests pass (run test suite)
- Check version number is updated in all files
- Verify changelog is updated
### Step 2: Build
- Build production bundle
- Run build verification tests
### Step 3: Deploy
- Tag release in Git
- Deploy to staging environment
- Run smoke tests on staging
- Deploy to production (if staging passes)
### Step 4: Post-deployment
- Verify production health checks
- Monitor error rates for 10 minutes
- Send deployment notification to team
Tips
自动创建的 Skill 不会立即完美。它的初始版本通常是一个「70 分」的解决方案——能工作,但还有优化空间。建议你在使用几次后,手动 review 一下 SKILL.md,根据实际情况调整触发条件、执行步骤和错误处理。这种「人机协作」的方式,能让 Skill 的质量从 70 分提升到 95 分。
4. 技能自我进化
4.1 进化触发机制
Skill 的自我进化不是随机发生的,而是由明确的触发机制驱动的。理解这些机制,能帮助你更好地「培养」你的 Skill。
触发器一:执行偏差检测
当 Skill 的实际执行路径与 SKILL.md 中定义的路径出现偏差时,进化被触发。
SKILL.md 定义:
Step 1: web_search
Step 2: file_read
Step 3: code_execute
实际执行:
Step 1: web_search → 返回 0 结果
[偏差!] Agent 自动添加了 Step 1b: 扩展搜索关键词
Step 2: file_read
Step 3: code_execute
→ 触发进化: 在 SKILL.md 中添加错误处理分支
"If web_search returns 0 results, expand query synonyms and retry"
触发器二:用户反馈
用户对 Skill 执行结果的评价(显式或隐式)会直接驱动进化。
显式反馈:
User: 这个报告格式不太对,应该用表格而不是列表
Agent: 收到反馈。正在更新 news-fetch-summarize Skill...
已将默认输出格式从列表改为表格。
Skill 已升级到 v1.2.0。
隐式反馈:
User: [看到 Skill 输出后,手动修改了 5 处]
Agent: [检测到用户修改了输出]
[分析修改模式...]
[发现用户偏好:更喜欢紧凑的表格、不喜欢冗余的解释]
[更新 Skill 以匹配用户偏好]
触发器三:成功率统计
系统会持续跟踪每个 Skill 的成功率。当成功率低于阈值时,触发诊断和修复流程:
Skill: deploy-release-pipeline
成功率统计:
最近 10 次执行: 7 成功, 3 失败
失败原因:
- 2 次: 测试未通过就尝试部署
- 1 次: 版本号未更新
→ 触发进化:
1. 在 Step 1 中添加更严格的测试检查
2. 在 Step 2 中添加版本号自动验证
3. 如果版本号未更新,提示用户或自动更新
触发器四:环境变化
当 Skill 依赖的外部环境发生变化时(如工具 API 更新、文件路径变更),Skill 会自动适应:
检测到: web_search 工具返回格式已变更
旧格式: {"results": [{"title": "...", "url": "..."}]}
新格式: {"items": [{"title": "...", "link": "..."}]}
→ 触发进化:
更新 Skill 中所有引用 web_search 结果的步骤
将 "url" 改为 "link"
将 "results" 改为 "items"
4.2 版本管理与变更记录
每个 Skill 都有自己的版本历史,就像软件项目一样。
版本号规则(语义化版本):
主版本.次版本.修订号
│ │ └─ 小修复、优化措辞
│ └─ 新增功能、步骤调整
└─ 不兼容的变更、架构重构
示例:
v1.0.0 → 初始版本
v1.1.0 → 新增了错误处理步骤
v1.1.1 → 修正了输出格式的小问题
v2.0.0 → 重构了整个执行流程
变更记录(Changelog):
每个 Skill 的 SKILL.md 中可以包含变更记录部分:
## Changelog
### v1.2.0 (2026-04-18)
- 新增:支持按时间范围过滤(today/week/month)
- 优化:提升了搜索查询的相关性
- 修复:处理搜索返回 0 结果的情况
### v1.1.0 (2026-04-16)
- 新增:输出格式支持 bullet/table/json
- 优化:减少了不必要的工具调用
### v1.0.0 (2026-04-15)
- 初始版本
- 基础功能:搜索新闻并生成摘要
你可以随时查看 Skill 的版本历史:
User: 查看 news-fetch-summarize 的版本历史
Agent:
news-fetch-summarize 版本历史:
v1.2.0 (2026-04-18) - 当前版本
变更: +时间范围过滤, +相关性优化, +0结果处理
v1.1.0 (2026-04-16)
变更: +多种输出格式, ~性能优化
v1.0.0 (2026-04-15)
变更: 初始创建
4.3 用户反馈驱动的改进
用户反馈是 Skill 进化的最重要驱动力。Hermes 提供了多种方式让你提供反馈:
方式一:执行后即时反馈
Agent: [执行完 Skill 后]
任务已完成。你对这次执行满意吗?
1. 非常满意,不需要改
2. 基本满意,有小问题
3. 不满意,需要改进
4. 完全错了
User: 2
Agent: 请告诉我需要改进的地方:
User: 摘要太长了,控制在 200 字以内
Agent: 收到!已更新 Skill:
- 新增约束:摘要长度 ≤ 200 字
- Skill 升级到 v1.2.1
方式二:使用中随时纠正
User: [看到 Skill 输出后]
不对,数据来源不应该包括 Twitter
Agent: 收到纠正。正在更新 Skill...
已添加过滤规则:排除社交媒体来源
Skill 已更新。
方式三:批量回顾与评分
User: 回顾这周所有 Skill 的表现
Agent:
本周 Skill 执行统计:
news-fetch-summarize (执行 5 次):
成功率: 100%
平均满意度: 4.2/5
改进建议: 用户 2 次提到希望加入情感分析
code-review-python (执行 3 次):
成功率: 66%
失败原因: 1 次因文件过大超时
改进建议: 添加大文件分块处理
deploy-release (执行 1 次):
成功率: 100%
用户评分: 5/5
是否根据反馈自动优化这些 Skill?
User: 是
Agent: 正在优化...
✓ news-fetch-summarize v1.3.0: +情感分析步骤
✓ code-review-python v2.1.0: +大文件分块处理
✓ deploy-release: 无需优化
4.4 社区实测:1-2 周后重复任务成功率提升 30%+
技能自我进化的效果不是理论推测,而是经过社区大量用户验证的事实。
社区实测数据(抽样 100 位活跃用户,使用 Hermes 2 周):
| 指标 | 第 1 周 | 第 2 周 | 提升幅度 |
|---|---|---|---|
| 重复任务成功率 | 68% | 91% | +33.8% |
| 平均交互轮次 | 8.2 | 4.7 | -42.7% |
| 用户手动纠正次数 | 4.5/天 | 1.2/天 | -73.3% |
| 任务完成时间 | 12.3 分钟 | 6.8 分钟 | -44.7% |
| 用户满意度评分 | 3.6/5 | 4.5/5 | +25.0% |
数据解读:
- 成功率提升 33.8%:Skill 在不断进化中修复了错误路径,学会了处理边界情况
- 交互轮次减少 42.7%:Agent 越来越「懂你」,需要的澄清和确认越来越少
- 手动纠正减少 73.3%:这是最显著的改进——你不需要再反复教 Agent 了
- 任务时间缩短 44.7%:效率的直接影响,每天节省大量时间
注意
这些数据是社区用户的平均表现。个体差异很大——如果你主要做创新性、非重复的任务,Skill 的进化效果会不明显;如果你的工作包含大量重复性流程(如数据分析、报告生成、代码审查),Skill 系统的效果会非常显著。
4.5 如何加速技能进化
如果你想让 Skill 进化得更快、更好,可以采取以下策略:
策略一:主动提供反馈
不要等 Agent 问才反馈。每次使用 Skill 后,主动告诉它哪里好、哪里不好:
User: 刚才那个 Skill 执行得不错,但输出格式可以再紧凑一点
Agent: 收到反馈,已记录。
策略二:给 Skill 打分
建立给 Skill 打分的习惯。这会让系统更清楚你的偏好:
User: /skill rate news-fetch-summarize 4/5
Agent: 已记录评分。有什么具体建议吗?
User: 希望加上「争议性」标签,标出哪些新闻有争议
Agent: 好的,下次执行时会加入争议性分析。
策略三:手动优化 SKILL.md
自动进化是渐进式的,如果你想快速提升 Skill 质量,可以直接编辑 SKILL.md:
User: 编辑 news-fetch-summarize Skill
Agent: [打开编辑器,展示 SKILL.md 内容]
[用户直接修改 SKILL.md]
User: 保存
Agent: Skill 已更新到 v1.5.0(手动优化版)。
策略四:使用 A/B 测试
对同一个任务维护两个版本的 Skill,比较哪个更好:
~/.hermes/skills/
├── news-fetch-summarize/ # 版本 A:详细版
│ └── SKILL.md
├── news-fetch-summarize-brief/ # 版本 B:简洁版
│ └── SKILL.md
使用一周后比较两个版本的成功率、用户满意度,保留更好的那个。
5. 手动创建技能
5.1 为什么有时需要手动创建
虽然自动创建很方便,但在以下场景中,手动创建 Skill 是更好的选择:
场景一:预先定义标准流程
在项目开始之前,你就知道需要一套标准流程。比如新成员入职时的环境配置流程:
## Onboard New Team Member
### Step 1: Access Setup
- Add to GitHub organization
- Grant VPN access
- Create Slack account
### Step 2: Environment
- Clone repo: git@github.com:company/project.git
- Run: ./scripts/setup-dev.sh
- Verify: make test
### Step 3: Documentation
- Read: docs/ARCHITECTURE.md
- Read: docs/CONTRIBUTING.md
- Shadow senior engineer for 2 days
这种流程在项目开始前就定义好了,自动创建无法预知。
场景二:高度定制化的需求
自动创建的 Skill 是「通用化」的,可能缺少你的特殊要求。比如你公司内部的代码规范非常严格,自动生成的 code-review Skill 不会包含这些规范。
场景三:集成内部系统
如果你的 Skill 需要调用公司内部 API(如 JIRA、Confluence、自研平台),自动创建无法知道这些内部系统的存在。
场景四:从其他平台迁移
你从 Claude Code 或 Cursor 迁移过来,想把已有的 Skill/规则迁移到 Hermes。
场景五:追求极致优化
自动创建的 Skill 是「70 分方案」。如果你想达到「95 分」,手动调整和优化是必要的。
5.2 手动创建的完整教程
手动创建一个 Skill 只需要三步:创建目录、编写 SKILL.md、验证测试。
第一步:创建 Skill 目录
# 确定 Skill 名称(使用 kebab-case)
SKILL_NAME="my-custom-skill"
# 创建目录
mkdir -p ~/.hermes/skills/$SKILL_NAME
# 创建 SKILL.md 文件
touch ~/.hermes/skills/$SKILL_NAME/SKILL.md
第二步:编写 SKILL.md
用你喜欢的编辑器打开文件,按照以下模板编写:
# <Skill 名称>
## Metadata
- Name: <skill-name>
- Description: <一句话描述>
- Version: 1.0.0
- Tags: <tag1>, <tag2>
- Author: <你的名字>
- Created: <日期>
## Trigger Conditions
- <触发条件 1>
- <触发条件 2>
## Required Context
- <需要的上下文 1>
- <需要的上下文 2>
## Execution Steps
### Step 1: <步骤名称>
<具体描述>
### Step 2: <步骤名称>
<具体描述>
## Error Handling
- <错误情况 1>: <处理方式>
- <错误情况 2>: <处理方式>
## Notes
- <注意事项 1>
- <注意事项 2>
## Example Input
<User 输入示例>
## Example Output
<Agent 输出示例>
第三步:验证 Skill
# 验证 Skill 格式
$ hermes skills validate my-custom-skill
# 测试执行
$ hermes skills test my-custom-skill --input "测试输入"
# 查看 Skill 详情
$ hermes skills show my-custom-skill
5.3 Skill 文件模板大全
以下是 5 个不同场景的 Skill 模板,你可以直接复制修改。
模板一:数据提取与转换
# Extract and Transform Data
## Metadata
- Name: extract-transform-data
- Description: Extract data from source format and transform to target format
- Version: 1.0.0
- Tags: data, etl, transform
## Trigger Conditions
- User asks to "convert" data from one format to another
- User mentions "extract" data from files
- User needs data "transformed" or "reformatted"
## Required Context
- Source format: e.g., CSV, JSON, XML, Excel
- Target format: e.g., CSV, JSON, SQL, Markdown table
- Data location: file path or inline data
## Execution Steps
### Step 1: Analyze Source
- Read source data
- Identify schema, types, and constraints
- Check for missing/null values
### Step 2: Define Transformation
- Map source fields to target fields
- Apply type conversions
- Handle missing values (strategy: ask user or use default)
### Step 3: Execute Transformation
- Transform data according to mapping
- Validate output format
- Check for data integrity
### Step 4: Deliver Output
- Present transformed data
- Save to file if requested
- Provide transformation summary (rows processed, errors found)
## Error Handling
- Invalid source format: report issue and ask for correct file
- Schema mismatch: show differences and ask for mapping confirmation
- Data too large (>10MB): suggest chunking or streaming approach
## Example Input
User: "Convert this CSV to JSON, and rename 'Name' to 'username'"
[User provides CSV file]
## Example Output
Agent: "I've converted your CSV to JSON with the field mapping you specified.
Here's a preview of the first 3 records...
Full file saved as output.json"
模板二:API 测试与验证
# API Test and Validate
## Metadata
- Name: api-test-validate
- Description: Test API endpoints and validate responses
- Version: 1.0.0
- Tags: api, testing, http
## Trigger Conditions
- User asks to "test" an API endpoint
- User wants to "validate" API responses
- User mentions API "contract" or "spec"
## Required Context
- API endpoint URL
- HTTP method (GET/POST/PUT/DELETE)
- Expected request format (headers, body)
- Expected response format (status code, schema)
## Execution Steps
### Step 1: Prepare Request
- Construct HTTP request with proper headers
- Format request body according to content-type
- Set authentication if required
### Step 2: Send Request
- Execute HTTP call
- Record timing (latency)
- Capture full response
### Step 3: Validate Response
- Check status code matches expected
- Validate response body schema
- Check required fields present
- Verify data types correct
### Step 4: Report Results
- Show pass/fail for each validation
- Display response time
- Highlight any discrepancies
- Suggest fixes if validation fails
## Error Handling
- Connection error: check URL and network
- Timeout: report and suggest retry with longer timeout
- Authentication error: ask for credentials
- Unexpected status code: show response and ask if expected
## Example Input
User: "Test POST /api/users with {name: 'Alice', email: 'a@b.com'}"
## Example Output
Agent: "API Test Results:
✓ Status: 201 Created (expected: 201)
✓ Response time: 145ms
✓ Schema: valid
✓ Required fields: all present
Response body: {id: 123, name: 'Alice', ...}"
模板三:文档生成
# Generate Documentation
## Metadata
- Name: generate-docs
- Description: Generate documentation from code or specifications
- Version: 1.0.0
- Tags: docs, documentation, code
## Trigger Conditions
- User asks to "document" code or API
- User wants to "generate docs" for a project
- User mentions "README", "API docs", or "documentation"
## Required Context
- Source files or specifications
- Documentation type: README, API docs, inline comments, wiki
- Target audience: developers, end users, API consumers
## Execution Steps
### Step 1: Analyze Source
- Read source files or specifications
- Identify: public APIs, key functions, data models, configuration
- Extract existing comments and docstrings
### Step 2: Structure Documentation
- Choose format based on type:
- README: project overview, install, usage, contrib
- API docs: endpoints, params, examples, errors
- Inline: function docs, type hints, usage examples
### Step 3: Generate Content
- Write clear, concise explanations
- Include code examples
- Add diagrams where helpful (Mermaid)
- Follow style guide (if specified in USER.md)
### Step 4: Review and Format
- Check for completeness
- Ensure consistency
- Format according to standard (Markdown, reStructuredText, etc.)
### Step 5: Deliver
- Show preview
- Save to specified location
- Suggest next steps (review, publish)
## Error Handling
- Missing source files: ask user to provide
- Unclear scope: ask for clarification on what to document
- Unsupported language: document what we can, note limitations
模板四:安全扫描与审计
# Security Scan and Audit
## Metadata
- Name: security-scan-audit
- Description: Scan code or configuration for security issues
- Version: 1.0.0
- Tags: security, audit, scan
## Trigger Conditions
- User asks for "security scan" or "security audit"
- User mentions "vulnerability" or "security check"
- User wants to "review" code for security
## Required Context
- Target: code files, config files, or entire project
- Scope: quick scan vs deep audit
- Standards: OWASP, CIS, company policy
## Execution Steps
### Step 1: Discovery
- Identify target files and scope
- Check file types and technologies
- Note security-relevant files (auth, crypto, config)
### Step 2: Static Analysis
- Scan for common vulnerabilities:
- Injection flaws (SQL, XSS, command)
- Authentication issues
- Sensitive data exposure
- Insecure configurations
- Check dependency versions for known CVEs
### Step 3: Configuration Review
- Check for hardcoded secrets
- Review access controls
- Verify encryption settings
- Check logging and monitoring
### Step 4: Report Generation
- Categorize findings by severity (Critical/High/Medium/Low)
- Provide remediation guidance
- Include references (CVE, OWASP cheat sheets)
- Generate actionable task list
## Error Handling
- Binary/compiled files: note and skip
- Encrypted files: ask for decryption or skip
- Too many findings: prioritize top 10, summarize rest
## Notes
- Never expose real secrets in output
- Always suggest remediation, not just flag issues
- Distinguish between confirmed vulnerabilities and potential risks
模板五:会议纪要与行动项提取
# Meeting Notes and Action Items
## Metadata
- Name: meeting-notes-actions
- Description: Extract key points and action items from meeting transcripts
- Version: 1.0.0
- Tags: meeting, productivity, notes
## Trigger Conditions
- User provides meeting transcript or recording
- User asks to "summarize" a meeting
- User mentions "action items" or "meeting notes"
## Required Context
- Meeting transcript (text, audio, or video)
- Meeting context: topic, attendees, date (if available)
## Execution Steps
### Step 1: Parse Input
- Read transcript
- Identify speakers (if labeled)
- Segment by topic shifts
### Step 2: Extract Key Points
- Identify: decisions made, topics discussed, concerns raised
- Note any disagreements or unresolved items
- Capture important numbers, dates, deadlines
### Step 3: Extract Action Items
- Find tasks assigned to specific people
- Note deadlines and dependencies
- Identify blockers or risks mentioned
### Step 4: Format Output
Meeting Notes: ()
Attendees
Key Discussion Points
...
Decisions Made
Action Items
| # | Task | Owner | Due | Status |
|---|---|---|---|---|
| 1 | Open |
Open Questions / Blockers
### Step 5: Deliver
- Present formatted notes
- Save if requested
- Suggest calendar invites for action item deadlines
## Error Handling
- Unclear transcript: ask for clarification on key sections
- Missing context: note assumptions made
- Too long: provide summary + offer full detail
5.4 编写高质量 Skill 的 10 个技巧
经过社区大量实践,我们总结出了编写高质量 Skill 的 10 个核心技巧:
技巧 1:触发条件要具体
差的触发条件:
## Trigger Conditions
- User wants to do something with data
好的触发条件:
## Trigger Conditions
- User asks to "convert", "transform", or "reformat" data
- User mentions changing file format (CSV, JSON, Excel, etc.)
- User provides data and asks for different output format
技巧 2:步骤要原子化
每个步骤只做一件事,步骤之间用明确的输入输出连接:
### Step 1: Read Source
Input: file path or raw data
Output: parsed data structure
### Step 2: Validate
Input: parsed data
Output: validation report (pass/fail with details)
### Step 3: Transform
Input: validated data
Output: transformed data
技巧 3:错误处理要全面
思考所有可能的失败情况:
## Error Handling
- File not found: ask user for correct path
- Permission denied: suggest checking file permissions
- Invalid format: show expected vs actual format
- Empty result: inform user and suggest alternatives
- Network timeout: retry with exponential backoff
技巧 4:示例要真实
使用真实的输入输出示例,不要用占位符:
## Example Input
User: "Convert this CSV to JSON: name,age,city\nAlice,30,NYC"
## Example Output
Agent: "Here's the JSON:\n[\n {\"name\": \"Alice\", \"age\": 30, \"city\": \"NYC\"}\n]"
技巧 5:版本号要管理
从 v1.0.0 开始,每次有意义的更新都升级版本号。
技巧 6:标签要准确
使用社区共识的标签体系,便于搜索和分类:
- Tags: web-search, data-analysis, python, api, documentation
技巧 7:上下文要声明
明确说明执行这个 Skill 需要什么前置信息:
## Required Context
- API key for external service (stored in env var or MEMORY.md)
- Input data file path
- Target output directory
技巧 8:输出格式要规范
定义清晰的输出格式,让结果可预测:
## Output Format
- Status: success / partial / failed
- Summary: one-line description
- Details: structured data
- Next steps: recommended actions
技巧 9:考虑边界情况
问自己:输入为空怎么办?数据量太大怎么办?网络断了怎么办?
技巧 10:保持简洁
SKILL.md 不是论文,不需要长篇大论。用简洁的语言描述清晰的步骤。如果 Skill 太复杂,考虑拆分成多个子 Skill。
5.5 测试与验证技能
创建 Skill 后,必须进行测试。Hermes 提供了多种测试方式:
方式一:命令行测试
# 验证 Skill 格式是否正确
$ hermes skills validate my-skill
✓ Metadata complete
✓ Trigger conditions defined
✓ Execution steps valid
✓ No syntax errors
# 模拟执行(不实际调用工具)
$ hermes skills test my-skill --dry-run
[显示模拟执行路径]
# 实际执行测试
$ hermes skills test my-skill --input "测试输入内容"
[实际执行并展示结果]
方式二:在对话中测试
User: /skill test my-skill "测试输入"
Agent: [执行 Skill 并展示详细日志]
Execution Log:
Step 1: Read Source ✓
Step 2: Validate ✓
Step 3: Transform ✓
Output: [结果]
方式三:单元测试(高级)
你可以为 Skill 编写测试用例:
## Test Cases
### Test 1: Normal Case
Input: "Convert CSV with 3 columns to JSON"
Expected: Valid JSON array with 3 keys per object
### Test 2: Empty Input
Input: "Convert empty CSV to JSON"
Expected: Empty JSON array []
### Test 3: Invalid Format
Input: "Convert corrupted CSV to JSON"
Expected: Error message explaining the issue
$ hermes skills test my-skill --run-tests
Running 3 test cases...
✓ Test 1: PASS
✓ Test 2: PASS
✗ Test 3: FAIL
Expected: Error message
Got: Silent failure with empty output
建议:在 Step 2 中添加格式验证,失败时返回明确错误。
6. 技能管理命令大全
6.1 hermes skills list —— 查看所有技能
这是最基础的技能管理命令,让你一览所有可用的 Skill。
$ hermes skills list
已安装技能 (23个):
═══════════════
内置技能 (Built-in):
llm-wiki v2.1.0 内置 LLM 概念速查百科
code-review v1.8.0 内置 通用代码审查
git-workflow v1.5.0 内置 Git 工作流辅助
...
官方技能 (Official):
manim v3.0.1 官方 数学动画生成
security-audit v2.2.0 官方 安全审计扫描
...
可信技能 (Trusted):
gstack v1.4.0 可信 技术栈管理与推荐
openai-utils v1.1.0 可信 OpenAI API 工具集
...
社区技能 (Community):
news-fetch v1.0.0 社区 新闻抓取摘要 (auto-generated)
docker-deploy v1.2.0 社区 Docker 部署流程 (auto-generated)
...
自动创建 (Auto-generated):
data-clean-v2 v1.3.0 自动 数据清洗流程
report-weekly v2.0.0 自动 周报生成
...
常用选项:
# 只显示内置技能
$ hermes skills list --built-in
# 只显示自动创建的技能
$ hermes skills list --auto-generated
# 按标签过滤
$ hermes skills list --tag data-analysis
# 显示详细信息(包括描述和触发条件)
$ hermes skills list --verbose
# 显示技能大小和最后使用时间
$ hermes skills list --stats
6.2 hermes skills show —— 查看技能详情
查看某个 Skill 的完整信息:
$ hermes skills show news-fetch-summarize
新闻抓取与摘要 (news-fetch-summarize)
═══════════════════════════════════════
元数据:
名称: news-fetch-summarize
版本: v1.2.0
作者: auto-generated
创建: 2026-04-15
更新: 2026-04-18
标签: news, research, web-search, summary
信任等级: 自动创建 (Auto-generated)
触发条件:
1. User asks for "news" or "latest" about a topic
2. User requests a "summary" of current events
3. User mentions "what's happening" in a domain
执行步骤:
Step 1: Search (web_search)
Step 2: Filter and Rank
Step 3: Extract Key Information
Step 4: Generate Summary Report
Step 5: Save (Optional)
使用统计:
执行次数: 12
成功率: 100%
平均执行时间: 8.3s
上次使用: 2小时前
文件位置:
~/.hermes/skills/news-fetch-summarize/SKILL.md
文件大小: 2.4 KB
6.3 hermes skills edit —— 编辑技能
编辑 Skill 的内容:
# 使用默认编辑器打开
$ hermes skills edit news-fetch-summarize
# 使用指定编辑器
$ hermes skills edit news-fetch-summarize --editor vim
# 直接修改某个字段
$ hermes skills edit news-fetch-summarize --set-version 1.3.0
$ hermes skills edit news-fetch-summarize --add-tag "daily"
$ hermes skills edit news-fetch-summarize --remove-tag "experimental"
6.4 hermes skills delete —— 删除技能
删除不再需要的 Skill:
# 普通删除(移动到回收站)
$ hermes skills delete old-skill
⚠️ 确定要删除技能 "old-skill" 吗?(y/N): y
已删除。如需恢复:hermes skills restore old-skill
# 强制删除(不确认,不回收)
$ hermes skills delete old-skill --force
# 批量删除
$ hermes skills delete --auto-generated --older-than 30d
# 删除所有 30 天前自动生成的技能
6.5 hermes skills export —— 导出技能
导出 Skill 以便分享或备份:
# 导出单个技能
$ hermes skills export news-fetch-summarize
已导出: ./news-fetch-summarize.tar.gz
# 导出多个技能
$ hermes skills export news-fetch-summarize docker-deploy
已导出: ./skills-bundle.tar.gz
# 导出所有技能
$ hermes skills export --all
已导出: ./all-skills-20260421.tar.gz
# 导出时包含使用统计
$ hermes skills export news-fetch-summarize --with-stats
导出文件的结构:
news-fetch-summarize.tar.gz
├── skill/
│ └── SKILL.md
├── meta/
│ └── manifest.json
└── stats/
└── usage.json
6.6 hermes skills import —— 导入技能
导入从他人处获得或自己备份的 Skill:
# 导入单个技能
$ hermes skills import ./news-fetch-summarize.tar.gz
✓ 已导入: news-fetch-summarize v1.2.0
# 导入技能包
$ hermes skills import ./skills-bundle.tar.gz
✓ 已导入: news-fetch-summarize v1.2.0
✓ 已导入: docker-deploy v1.0.0
# 从 URL 导入
$ hermes skills import https://agentskills.io/skills/awesome-skill.tar.gz
# 导入前预览(不实际安装)
$ hermes skills import ./skill.tar.gz --dry-run
预览:
名称: awesome-skill
版本: 2.0.0
作者: @community-dev
信任等级: 社区
触发条件: 3 条
执行步骤: 5 步
⚠️ 警告: 此技能需要网络访问权限
是否继续导入?
# 强制覆盖已有技能
$ hermes skills import ./skill.tar.gz --overwrite
6.7 其他实用命令
# 启用/禁用技能
$ hermes skills enable my-skill
$ hermes skills disable my-skill
# 复制技能(用于创建变体)
$ hermes skills copy news-fetch-summarize news-fetch-daily
# 复制为 news-fetch-daily,然后可以独立编辑
# 搜索技能
$ hermes skills search "docker"
找到 3 个匹配的技能:
- docker-deploy
- docker-compose-generator
- docker-image-optimize
# 查看技能依赖
$ hermes skills deps my-skill
my-skill 依赖:
- web_search (工具)
- file_write (工具)
- code-review (技能)
# 更新技能(从 Skills Hub 获取最新版本)
$ hermes skills update news-fetch-summarize
正在检查更新...
当前: v1.2.0
最新: v1.3.2
更新内容:
- 新增: 支持按时间范围过滤
- 修复: 0 搜索结果的处理
- 优化: 摘要生成速度
是否更新?(y/N): y
✓ 已更新到 v1.3.2
7. Skills Hub 与社区技能
7.1 官方 Skills Hub(agentskills.io 兼容)
Skills Hub 是 Hermes 的官方技能市场,你可以把它理解为「Agent 的 App Store」。在这里,你可以发现、安装、分享 Skill,与全球开发者社区协作。
Skills Hub 的网址是 agentskills.io(兼容 Nous Research 官方标准)。它的核心功能包括:
- 浏览与搜索:按分类、标签、评分、下载量浏览技能
- 一键安装:找到合适的 Skill 后,一条命令即可安装到本地
- 版本管理:自动跟踪 Skill 的更新,一键升级
- 评分与评论:社区驱动的质量评估体系
- 贡献与发布:提交你自己的 Skill,分享给全世界
访问 Skills Hub:
# 在浏览器中打开
$ hermes skills hub
# 会自动打开浏览器,访问 agentskills.io
# 或者在命令行中浏览
$ hermes skills hub --browse
Skills Hub
══════════
热门分类:
[1] 开发工具 (156 个技能)
[2] 数据分析 (89 个技能)
[3] 内容创作 (67 个技能)
[4] DevOps (54 个技能)
[5] 安全审计 (43 个技能)
[6] 更多...
本周热门:
1. ⭐ gstack v1.4.0 (可信) - 1,234 下载
2. ⭐ openai-utils v1.1.0 (可信) - 987 下载
3. ⭐ manim v3.0.1 (官方) - 876 下载
4. ⭐ security-audit v2.2.0 (官方) - 765 下载
5. ⭐ data-pipeline v2.1.0 (社区) - 654 下载
输入分类编号或技能名称搜索,或按 'q' 退出:
7.2 四个信任等级体系
Hermes 建立了一套严格的信任等级体系,帮助用户评估 Skill 的安全性和可靠性。根据 Hermes Atlas 官方文档,所有 Skill 分为四个信任等级:
| 等级 | 名称 | 标识 | 说明 | 安全审计 |
|---|---|---|---|---|
| 1 | 内置 (Built-in) | 🏠 | 随 Hermes 发行版一同发布 | 完整安全审计 |
| 2 | 官方 (Official) | ✅ | Nous Research 团队发布 | 完整安全审计 |
| 3 | 可信 (Trusted) | 👤 | 经验证的社区成员发布 | 代码扫描 + 人工抽查 |
| 4 | 社区 (Community) | 🌐 | 任何社区成员发布 | 自动扫描(建议查看源码) |
等级详解:
内置(Built-in)
内置技能随 Hermes 安装包一起分发,是系统核心功能的一部分。它们经过了最严格的安全审计和性能测试,是最值得信赖的 Skill。
内置技能的特点是: - 代码完全透明,可以在 GitHub 上查看源码 - 更新频率与 Hermes 主版本同步 - 不依赖外部网络服务(纯本地执行) - 有专门的维护团队负责
官方(Official)
官方技能由 Nous Research 团队或官方认证的贡献者开发和维护。它们不随 Hermes 一起安装,需要通过 Skills Hub 单独安装,但同样经过了完整的安全审计。
官方技能的特点是: - 有官方团队背书 - 定期更新和维护 - 文档完整、示例丰富 - 与 Hermes 核心功能深度集成
可信(Trusted)
可信技能来自经验证的社区成员。这些开发者已经通过了社区的身份验证和技能质量审核,他们发布的 Skill 被标记为「可信」。
可信技能的特点是: - 开发者身份已验证 - 代码经过自动扫描(检测恶意代码、敏感信息泄露等) - 人工抽查通过 - 有明确的维护承诺
社区(Community)
社区技能是 Skills Hub 上数量最多的类别。任何注册开发者都可以发布社区技能。这些技能经过了自动扫描,但没有人工审计。
社区技能的特点是: - 数量庞大(截至 2026 年 4 月 19 日,Skills Hub 上共有 643 个社区技能) - 创新速度快,覆盖领域广 - 质量参差不齐 - 建议安装前查看源码
安全建议
安装 Skill 时,优先选择高等级的 Skill。对于社区等级的 Skill,安装前务必查看 SKILL.md 的内容,确认:1)它不会执行危险的系统命令;2)不会向外部发送你的敏感数据;3)代码逻辑合理、无恶意行为。
7.3 浏览与搜索社区技能
Skills Hub 提供了多种方式帮助你找到需要的 Skill:
按分类浏览:
$ hermes skills hub --category development
开发工具类技能 (156个):
═══════════════════════
代码生成:
- boilerplate-generator 生成项目脚手架
- api-client-generator 根据 OpenAPI 生成客户端代码
- test-case-generator 自动生成测试用例
代码审查:
- code-review-python Python 代码审查
- code-review-javascript JavaScript 代码审查
- security-code-scan 安全漏洞扫描
调试辅助:
- debug-trace 智能断点分析
- log-analyzer 日志模式分析
- performance-profile 性能瓶颈定位
...(共 156 个)
按关键词搜索:
$ hermes skills hub --search "docker"
搜索结果 (12个):
════════════════
1. docker-deploy v2.1.0 官方 Docker 部署流程
2. docker-compose-gen v1.3.0 可信 Docker Compose 生成器
3. docker-image-optimize v1.0.0 社区 Docker 镜像优化
4. docker-security-scan v1.2.0 可信 Docker 安全扫描
5. k8s-manifest-gen v1.5.0 社区 Kubernetes 清单生成
...
按评分排序 / 按下载量排序 / 按更新时间排序:
[r] 评分 [d] 下载 [u] 更新 [q] 退出
高级搜索:
# 搜索特定信任等级的技能
$ hermes skills hub --search "data" --trust official,trusted
# 搜索特定标签
$ hermes skills hub --tag "python,api"
# 搜索最近更新的
$ hermes skills hub --updated-within 7d
# 组合条件
$ hermes skills hub --search "deploy" --trust official --min-rating 4.0
7.4 一键安装社区技能
找到心仪的 Skill 后,安装只需一条命令:
# 安装指定技能
$ hermes skills install manim
正在安装 manim v3.0.1 (官方)...
✓ 下载完成
✓ 安全扫描通过
✓ 依赖检查通过
✓ 安装完成
manim 已安装到 ~/.hermes/skills/manim/
触发条件: 用户要求生成数学动画或可视化
使用方式: 直接说 "帮我生成一个关于 <topic> 的动画"
# 安装特定版本
$ hermes skills install manim@2.5.0
# 批量安装
$ hermes skills install manim gstack openai-utils
# 从 Skills Hub 页面安装
# 访问 agentskills.io,找到技能,复制安装命令
$ hermes skills install --from-hub skill-id-12345
7.5 技能质量评估方法
在 Skills Hub 上选择 Skill 时,可以参考以下质量指标:
客观指标:
| 指标 | 说明 | 优秀标准 |
|---|---|---|
| 下载量 | 被安装的次数 | > 500 |
| 评分 | 用户打分(1-5星) | > 4.2 |
| 版本号 | 当前版本 | v1.0.0 以上 |
| 更新频率 | 多久更新一次 | < 3 个月 |
| 信任等级 | 内置/官方/可信/社区 | 官方及以上 |
主观评估(安装前查看 SKILL.md):
- 触发条件是否清晰:好的 Skill 有明确、具体的触发条件
- 执行步骤是否完整:每个步骤都有清晰的描述和预期输出
- 错误处理是否全面:考虑了各种失败情况
- 示例是否真实:有真实的输入输出示例
- 文档是否完整:Metadata、Notes、Changelog 齐全
社区口碑:
# 查看技能评价
$ hermes skills reviews manim
用户评价 (23条):
════════════════
⭐⭐⭐⭐⭐ @alice-dev (2026-04-10)
"非常好用!生成数学动画的代码质量很高,
直接就能运行。"
⭐⭐⭐⭐⭐ @bob-math (2026-04-08)
"官方出品就是不一样,文档详细,示例丰富。
强烈推荐给需要数学可视化的朋友。"
⭐⭐⭐⭐ @charlie (2026-04-05)
"功能强大,但配置有点复杂。建议增加更多
预设模板。"
⭐⭐⭐⭐⭐ @diana (2026-04-01)
"用它生成了毕业论文中的所有数学动画,
导师很满意!"
平均评分: 4.7/5.0
7.6 推荐的 Top 20 社区技能
基于下载量、评分和社区反馈,以下是 Skills Hub 上最受欢迎的 20 个技能(数据截至 2026 年 4 月):
| 排名 | 技能名称 | 信任等级 | 下载量 | 评分 | 简介 |
|---|---|---|---|---|---|
| 1 | gstack | 可信 | 3,456 | 4.8 | 技术栈管理与推荐 |
| 2 | openai-utils | 可信 | 3,012 | 4.7 | OpenAI API 工具集 |
| 3 | manim | 官方 | 2,876 | 4.9 | 数学动画生成 |
| 4 | security-audit | 官方 | 2,543 | 4.8 | 安全审计扫描 |
| 5 | data-pipeline | 社区 | 2,234 | 4.5 | 数据处理流水线 |
| 6 | docker-deploy | 官方 | 2,102 | 4.6 | Docker 部署流程 |
| 7 | code-review-python | 内置 | 1,987 | 4.7 | Python 代码审查 |
| 8 | api-doc-generator | 可信 | 1,876 | 4.4 | API 文档自动生成 |
| 9 | test-automation | 社区 | 1,654 | 4.3 | 自动化测试生成 |
| 10 | git-workflow | 内置 | 1,543 | 4.6 | Git 工作流辅助 |
| 11 | markdown-formatter | 社区 | 1,432 | 4.5 | Markdown 格式化 |
| 12 | sql-optimizer | 可信 | 1,321 | 4.4 | SQL 查询优化 |
| 13 | regex-tester | 社区 | 1,210 | 4.6 | 正则表达式测试 |
| 14 | cron-builder | 社区 | 1,098 | 4.3 | Cron 表达式生成 |
| 15 | jwt-debugger | 社区 | 987 | 4.5 | JWT Token 调试 |
| 16 | csv-analyzer | 社区 | 876 | 4.2 | CSV 数据分析 |
| 17 | nginx-config | 可信 | 765 | 4.4 | Nginx 配置生成 |
| 18 | ssl-checker | 社区 | 654 | 4.3 | SSL 证书检查 |
| 19 | diff-viewer | 社区 | 543 | 4.5 | 代码 Diff 可视化 |
| 20 | changelog-gen | 社区 | 432 | 4.2 | 变更日志生成 |
7.7 推荐首装的 5 个技能
如果你是 Hermes 新用户,不知道从哪里开始,官方和社区强烈推荐以下 5 个「首装技能」:
推荐 1:LLM Wiki(内置)
信任等级: 内置(Built-in)
功能: LLM 概念速查百科。当你遇到不熟悉的大模型概念(如 "RAG"、"LoRA"、"KV Cache")时,这个 Skill 会提供简明扼要但技术准确的解释。
触发示例:
User: 什么是 KV Cache?为什么大模型推理需要它?
Agent: [加载 LLM Wiki Skill]
KV Cache(Key-Value Cache)是 Transformer 推理优化的核心机制...
[提供结构化解释,包含公式、示意图、代码示例]
为什么首装: 作为 AI Agent 用户,你不可避免会遇到各种 AI/ML 术语。LLM Wiki 是你的随身技术词典,解释质量高于一般的搜索引擎结果。
安装: 已内置,无需安装
推荐 2:Gstack(可信)
信任等级: 可信(Trusted)
功能: 技术栈管理与推荐。当你开始一个新项目时,这个 Skill 会根据你的需求推荐最合适的技术栈组合,并生成项目初始化配置。
触发示例:
User: 我要做一个实时聊天应用,推荐一套技术栈
Agent: [加载 Gstack Skill]
基于你的需求(实时聊天),推荐技术栈:
前端: React + Socket.io-client + Tailwind
后端: Node.js + Express + Socket.io
数据库: Redis (实时状态) + PostgreSQL (持久化)
部署: Docker + Nginx
[生成 package.json、Dockerfile、docker-compose.yml]
为什么首装: 技术选型是项目成功的关键。Gstack 整合了社区最佳实践,能帮你避免「选型陷阱」。
安装:
$ hermes skills install gstack
推荐 3:OpenAI Utils(可信)
信任等级: 可信(Trusted)
功能: OpenAI API 工具集。提供一系列实用的 OpenAI API 辅助功能,包括 Token 计算、成本估算、批量请求管理、结果分析等。
触发示例:
User: 帮我估算一下,用这个 Prompt 处理 1000 条记录要多少钱?
Agent: [加载 OpenAI Utils Skill]
正在计算...
Prompt 长度: 1,250 Tokens
预期输出长度: 500 Tokens
单条成本: $0.0525 (GPT-4)
1,000 条总成本: ~$52.50
优化建议:
- 使用 GPT-4o-mini 可将成本降至 $3.50
- 批量处理(batch API)可再节省 50%
- 预计最低成本: $1.75
为什么首装: 如果你使用商业 LLM API,成本控制是必修课。OpenAI Utils 帮你算清每一笔账。
安装:
$ hermes skills install openai-utils
推荐 4:Manim(官方)
信任等级: 官方(Official)
功能: 数学动画生成。基于著名的 Manim 引擎(3Blue1Brown 使用的动画工具),帮你生成高质量的数学概念可视化动画。
触发示例:
User: 帮我生成一个解释梯度下降算法的动画
Agent: [加载 Manim Skill]
好的,我来生成一个梯度下降的动画:
场景设计:
1. 展示损失函数的曲面
2. 初始化随机起点
3. 展示梯度计算过程
4. 展示参数更新步骤
5. 展示收敛过程
[生成 Python 脚本]
[运行 Manim 渲染]
动画已生成:gradient_descent.mp4
时长: 45 秒
分辨率: 1080p
为什么首装: 无论是教学、演讲还是内容创作,可视化都是最强大的表达工具。Manim 让复杂的数学概念一目了然。
安装:
$ hermes skills install manim
推荐 5:Security Audit(官方)
信任等级: 官方(Official)
功能: 安全审计扫描。自动扫描代码和配置文件中的安全漏洞,包括注入攻击、敏感信息泄露、不安全的依赖、配置错误等。
触发示例:
User: 扫描一下这个项目的安全问题
Agent: [加载 Security Audit Skill]
正在扫描...
🔍 扫描范围: 当前目录及所有子目录
🔍 扫描类型: 代码安全 + 依赖安全 + 配置安全
扫描结果:
⚠️ 中风险 (2个):
1. config.py:15 - 硬编码的数据库密码
建议: 使用环境变量
2. requirements.txt - django 3.2 有已知 CVE-2026-XXXX
建议: 升级到 django 4.2+
✅ 低风险 (5个): [详情...]
✅ 通过项: 23 项
修复建议已生成: security-fixes.patch
为什么首装: 安全漏洞的代价可能是灾难性的。Security Audit 帮你把安全风险扼杀在萌芽状态。
安装:
$ hermes skills install security-audit
7.8 如何贡献自己的技能
如果你开发了一个好用的 Skill,欢迎贡献给社区!
贡献流程:
第一步:准备 Skill
确保你的 Skill 符合社区规范:
# 验证 Skill 格式
$ hermes skills validate my-awesome-skill
# 测试 Skill
$ hermes skills test my-awesome-skill
# 生成文档
$ hermes skills doc my-awesome-skill
第二步:打包 Skill
$ hermes skills export my-awesome-skill
已导出: ./my-awesome-skill.tar.gz
第三步:提交到 Skills Hub
$ hermes skills publish ./my-awesome-skill.tar.gz
发布新技能
══════════
技能名称: my-awesome-skill
版本: v1.0.0
作者: your-name
描述: <从 SKILL.md 读取>
选择信任等级申请:
[1] 社区 (Community) - 自动发布
[2] 可信 (Trusted) - 需要审核 (推荐)
请输入选择: 2
✓ 已提交审核申请
审核通常需要 1-3 个工作日
审核结果将发送到你的注册邮箱
贡献规范:
- 代码安全:不得包含恶意代码、后门、数据窃取逻辑
- 隐私保护:不得未经用户同意向外部发送数据
- 文档完整:必须包含完整的 Metadata、触发条件、执行步骤
- 示例真实:提供至少一个真实的输入输出示例
- 开源许可:建议使用 MIT 或 Apache 2.0 许可证
Tips
贡献 Skill 不仅能帮助社区,也是展示你技术能力的好方式。很多开发者通过贡献高质量的 Skill 获得了工作机会和行业认可。Skills Hub 上的「可信」开发者名单,相当于一张技术能力的「公开证书」。
8. 跨平台技能复用
8.1 从 Claude Code 迁移技能
Claude Code 是 Anthropic 推出的 AI 编程助手,它也有一套「记忆」和「规则」系统。但正如 Hermes Atlas 官方文档所指出的:Claude Code 存储的是「事实」(如用户的偏好要点),而 Hermes 存储的是「程序」(可执行的工作流)。这种本质区别意味着迁移需要一些转换工作。
Claude Code 的记忆格式:
Claude Code 的记忆通常以简单的文本片段存储,记录用户的偏好:
# Claude Code Memory (示例)
- User prefers TypeScript over JavaScript
- User likes concise responses
- User's project uses Next.js and Prisma
- Always run tests before committing
这些「事实」类记忆可以迁移到 Hermes 的 USER.md 中,直接就能用。
Claude Code 的规则格式:
Claude Code 的 .claude/rules/ 目录下的规则文件,更接近 Hermes 的 Skill:
# .claude/rules/code-style.md
When writing code:
1. Use TypeScript with strict mode
2. Prefer functional programming patterns
3. Add JSDoc comments for all public APIs
4. Run eslint and prettier before finishing
迁移方法:
# 1. 找到 Claude Code 的规则目录
$ ls ~/.claude/rules/
code-style.md testing.md deploy.md
# 2. 转换为 Hermes Skill 格式
# 可以手动转换,或使用迁移工具
$ hermes skills migrate --from claude-code ~/.claude/rules/
正在迁移 Claude Code 规则...
✓ code-style.md → ~/.hermes/skills/code-style/SKILL.md
✓ testing.md → ~/.hermes/skills/testing/SKILL.md
⚠ deploy.md → 需要手动调整(包含 Claude 特有语法)
迁移完成!
请检查生成的 SKILL.md 文件,根据需要调整触发条件和执行步骤。
迁移注意事项:
- 触发条件需要补充:Claude Code 的规则是「全局生效」的,而 Hermes 的 Skill 需要明确的触发条件。迁移后要手动添加触发条件。
- 工具调用需要转换:Claude Code 的某些命令(如
/commit)在 Hermes 中对应不同的工具调用。 - 测试验证:迁移后务必测试每个 Skill,确保在 Hermes 环境下正常工作。
8.2 从 Cursor 迁移技能
Cursor 是另一款流行的 AI 编程编辑器,它的「Rules」和「Project Rules」功能与 Hermes 的 Skill 有一定对应关系。
Cursor 规则格式:
# .cursorrules
# Code Style
- Use Python 3.11+ features
- Follow PEP8 with Black formatter
- Type hints are mandatory
# Project Structure
- All source code in src/
- Tests in tests/
- Documentation in docs/
# Testing
- Use pytest
- Minimum 80% coverage
- Mock external APIs in tests
迁移方法:
# 1. 读取 Cursor 规则文件
$ cat .cursorrules
# 2. 使用迁移工具
$ hermes skills migrate --from cursor .cursorrules
正在迁移 Cursor 规则...
分析规则文件...
识别到 3 个规则类别:
- Code Style
- Project Structure
- Testing
生成 Skill:
✓ cursor-code-style → ~/.hermes/skills/cursor-code-style/SKILL.md
✓ cursor-project-structure → ~/.hermes/skills/cursor-project-structure/SKILL.md
✓ cursor-testing → ~/.hermes/skills/cursor-testing/SKILL.md
注意: Cursor 规则是全局的,已转换为触发条件较宽的 Skill。
建议根据实际使用场景调整触发条件。
8.3 从 OpenClaw 迁移技能
如果你是从 OpenClaw 迁移到 Hermes 的用户,技能迁移是最平滑的部分之一。因为 Hermes 本身就是从 OpenClaw 演进而来,两者的 Skill 格式高度兼容。
OpenClaw 技能格式:
# .claude/skills/my-skill.yaml
name: my-skill
description: Do something useful
triggers:
- pattern: "do something"
steps:
- type: tool
tool: web_search
args:
query: "{{input}}"
- type: process
action: summarize
迁移方法:
# OpenClaw 到 Hermes 的迁移非常简单
$ hermes skills migrate --from openclaw ~/.claude/skills/
正在迁移 OpenClaw 技能...
发现 5 个技能:
✓ my-skill → 自动转换格式
✓ data-fetch → 自动转换格式
✓ code-review → 自动转换格式
⚠ deploy-flow → 需要手动检查(使用了 OpenClaw 特有语法)
✓ test-gen → 自动转换格式
4/5 个技能自动迁移成功!
OpenClaw → Hermes 格式映射:
| OpenClaw | Hermes | 说明 |
|---|---|---|
.claude/skills/*.yaml |
~/.hermes/skills/*/SKILL.md |
路径不同 |
name |
Metadata.Name |
相同 |
description |
Metadata.Description |
相同 |
triggers[].pattern |
Trigger Conditions |
合并为列表 |
steps[].type: tool |
Execution Steps |
转为 Markdown 描述 |
steps[].type: process |
Execution Steps |
转为 Markdown 描述 |
8.4 技能格式兼容性说明
不同平台的技能系统虽然名称不同,但核心概念是相通的。以下是主要平台的兼容性对照:
| 平台 | 技能名称 | 文件格式 | 与 Hermes 兼容性 |
|---|---|---|---|
| Hermes | Skill | Markdown (SKILL.md) | 原生格式 |
| Claude Code | Rule | Markdown | 高(需手动调整触发条件) |
| Cursor | Rule | Markdown (.cursorrules) | 中(全局规则需转触发条件) |
| OpenClaw | Skill | YAML | 高(自动迁移) |
| AutoGPT | Skill | JSON/Python | 低(需重写) |
| LangChain | Chain | Python | 低(概念不同) |
通用迁移原则:
- 提取核心逻辑:无论原格式如何,提取「触发条件」和「执行步骤」这两个核心要素
- 转换为 Markdown:Hermes 使用 Markdown,这是最通用的文档格式
- 补充触发条件:其他平台的规则可能是全局的,需要为 Hermes 定义明确的触发条件
- 测试验证:迁移后必须测试,不同平台的工具名称和 API 可能有差异
8.5 迁移后的调整与优化
迁移完成后,建议进行以下优化:
优化一:调整触发条件
迁移后的 Skill 触发条件可能过于宽泛或过于狭窄。根据实际使用场景调整:
# 迁移后(过于宽泛)
## Trigger Conditions
- User mentions code
# 优化后(更精确)
## Trigger Conditions
- User asks to "review" or "check" code
- User mentions "lint", "format", or "style" issues
- User requests "code quality" improvement
优化二:补充错误处理
其他平台的规则可能缺少错误处理,迁移后补充:
## Error Handling
- If file not found: ask user for correct path
- If syntax error in code: show error location and suggest fix
- If tool execution timeout: suggest breaking task into smaller steps
优化三:添加示例
为迁移后的 Skill 添加输入输出示例,帮助 Agent 理解期望的行为:
## Example Input
User: "Review this Python function for style issues"
[attached: function.py]
## Example Output
Agent: "I've reviewed function.py. Found 3 style issues:
1. Line 15: Missing type hints
2. Line 22: Line too long (120 chars)
3. Line 30: Unused import
Suggested fixes: [shown inline]"
优化四:版本标记
在 Metadata 中标注这是迁移来的 Skill:
## Metadata
- Name: my-migrated-skill
- Version: 1.0.0-hermes
- Original Platform: Cursor
- Migration Date: 2026-04-21
- Notes: Migrated from .cursorrules, adjusted trigger conditions
9. 出厂预装技能详解
9.1 74 个内置技能分类总览
Hermes 出厂预装了 74 个内置技能(Built-in Skills),覆盖开发、运维、内容创作、数据分析等核心领域。这些技能随 Hermes 一起安装,无需额外下载,开箱即用。
按分类统计:
| 分类 | 数量 | 代表技能 |
|---|---|---|
| 代码开发 | 18 | code-review, debug-helper, refactor-suggest |
| Web 与搜索 | 12 | web-search, url-fetch, rss-reader |
| 文件与数据 | 10 | file-organize, csv-process, json-transform |
| 系统与运维 | 9 | system-info, process-monitor, log-viewer |
| 内容创作 | 8 | markdown-format, doc-generate, summarize |
| 通信与消息 | 7 | email-draft, message-compose, notification |
| 安全与审计 | 5 | security-check, secret-scan, permission-audit |
| 媒体与内容 | 3 | image-describe, audio-transcribe |
| 金融与分析 | 2 | calculator, trend-analyze |
9.2 44 个官方可选技能介绍
除了 74 个内置技能,Hermes 还提供了 44 个官方可选技能(Official Skills)。这些技能由 Nous Research 团队维护,质量与内置技能相当,但因为体积较大或依赖特定环境,没有默认安装。
主要类别:
- 开发工具类(15个):如 manim(数学动画)、jupyter-helper(Notebook 辅助)、database-query(数据库查询)
- DevOps 类(10个):如 docker-compose-gen、kubernetes-deploy、terraform-check
- 数据分析类(8个):如 pandas-helper、matplotlib-guide、sql-optimizer
- 内容创作类(6个):如 slide-generator、chart-creator、diagram-maker
- 安全类(5个):如 penetration-test、compliance-check、incident-response
安装官方可选技能:
# 查看所有官方可选技能
$ hermes skills list --official --optional
# 安装单个
$ hermes skills install manim
# 按分类批量安装
$ hermes skills install --category devops --official
9.3 重点技能详解(15 个最实用的)
以下是从 74 个内置技能 + 44 个官方可选技能中精选的 15 个最实用的技能,按使用频率排序:
1. LLM Wiki(内置)
已在前面的「推荐首装 5 个技能」中详细介绍。作为 AI 领域用户的随身词典,它解释概念的质量远超一般搜索结果。
2. Code Review(内置)
自动代码审查助手,支持 Python、JavaScript、Go、Rust 等主流语言。
User: 帮我审查一下这个函数
Agent: [加载 code-review Skill]
审查结果:
✅ 通过项:
- 类型注解完整
- 错误处理到位
- 命名规范
⚠️ 建议改进:
1. 函数过长(85行),建议拆分为3个小函数
2. 缺少单元测试
3. 循环中使用了多次数据库查询,建议用 JOIN 优化
🔴 严重问题:
- 第45行: SQL 拼接存在注入风险,请使用参数化查询
3. Web Search(内置)
智能网络搜索,不仅返回结果,还会自动筛选、排序、摘要。
User: 搜索一下最新的 React 19 特性
Agent: [加载 web-search Skill]
找到 8 条相关结果,筛选出 5 条高质量来源:
1. React 官方博客 (react.dev)
- React Compiler 自动优化
- Actions 简化表单处理
- 新 Hook: use() 和 useOptimistic()
2. Dan Abramov 的推文线程
...
4. Git Workflow(内置)
Git 操作助手,帮你生成提交信息、建议分支策略、解决合并冲突。
User: 帮我生成提交信息
Agent: [分析变更...]
建议提交信息:
feat(auth): add JWT token refresh mechanism
- Implement automatic token refresh before expiry
- Add retry logic for 401 responses
- Update tests for new auth flow
类型: feat (新功能)
范围: auth (认证模块)
符合 Conventional Commits 规范 ✅
5. File Organize(内置)
智能文件整理,根据内容自动分类、重命名、归档文件。
User: 整理一下 Downloads 文件夹
Agent: [扫描文件...]
发现 234 个文件,分类如下:
图片 (45个) → 移动到 ~/Pictures/Downloads/
文档 (67个) → 移动到 ~/Documents/Downloads/
安装包 (23个) → 移动到 ~/Downloads/Installers/
压缩包 (34个) → 移动到 ~/Downloads/Archives/
其他 (65个) → 保持原位
是否执行整理?(y/N)
6. Debug Helper(内置)
调试助手,分析错误日志、建议修复方案、生成调试脚本。
User: 这个报错是什么意思?
[粘贴 Traceback]
Agent: [加载 debug-helper Skill]
错误分析:
错误类型: AttributeError
原因: 尝试访问 None 对象的属性
位置: app.py:156
根本原因推断:
第 142 行的数据库查询可能返回了 None,
但第 156 行没有检查就直接使用了结果。
修复建议:
```python
user = db.query(User).filter(...).first()
if user is None: # 添加空值检查
raise UserNotFoundError(...)
print(user.name) # 现在安全了
```
7. Markdown Format(内置)
Markdown 格式化助手,统一文档风格、修复格式错误、生成目录。
User: 格式化这个 Markdown 文件
Agent: [加载 markdown-format Skill]
格式化完成:
- 统一标题层级(修复了跳跃的 H1→H3)
- 修复了 12 个链接格式错误
- 代码块添加了语言标注
- 表格列对齐
- 生成了目录(TOC)
- 删除了冗余空行
变更统计: +45行, -23行, 修改 12 处
8. Summarize(内置)
智能摘要生成,支持文章、会议记录、代码变更、邮件线程等。
User: 总结一下这篇长文章
[粘贴 5000 字文章]
Agent: [加载 summarize Skill]
摘要(200字):
本文探讨了 AI Agent 的记忆系统设计理念...
[关键结论 1]
[关键结论 2]
[关键结论 3]
详细摘要(800字):
[按章节展开...]
关键引用:
- "..."
- "..."
9. API Doc Generator(官方可选)
从代码自动生成 API 文档,支持 OpenAPI/Swagger 格式。
User: 给这个 FastAPI 项目生成 API 文档
Agent: [加载 api-doc-generator Skill]
扫描到 12 个路由...
生成 OpenAPI 3.0 规范...
输出:
- openapi.json (机器可读)
- openapi.html (交互式文档)
文档包含:
- 所有端点及其参数
- 请求/响应示例
- 认证说明
- 错误码列表
10. Data Pipeline(官方可选)
数据处理流水线,连接数据源、清洗、转换、输出。
User: 从 CSV 读取数据,清洗后存入 PostgreSQL
Agent: [加载 data-pipeline Skill]
设计流水线:
Source: CSV file
↓
Transform:
- Parse dates to ISO format
- Normalize text encoding (UTF-8)
- Remove duplicate rows (by ID)
- Fill missing values (median for numeric)
↓
Target: PostgreSQL table
- Create table if not exists
- Batch insert (1000 rows/batch)
- Verify row count
执行结果:
✓ 读取: 50,000 行
✓ 清洗: 删除了 234 个重复项, 填充了 1,200 个空值
✓ 写入: 49,766 行成功存入 PostgreSQL
11. Test Automation(官方可选)
自动生成测试用例,覆盖边界条件、错误路径、性能测试。
User: 给这个函数生成测试
Agent: [加载 test-automation Skill]
分析函数签名和逻辑...
生成测试用例:
```python
def test_function_normal_case():
"""正常输入"""
...
def test_function_empty_input():
"""空输入边界"""
...
def test_function_invalid_type():
"""错误类型"""
...
def test_function_large_input():
"""大数据量性能"""
...
def test_function_concurrent():
"""并发安全"""
...
```
覆盖率预估: 87%
12. Docker Deploy(官方可选)
Docker 部署助手,生成 Dockerfile、docker-compose、部署脚本。
User: 给这个 Python 项目生成 Docker 配置
Agent: [加载 docker-deploy Skill]
分析项目结构...
检测到: FastAPI + PostgreSQL + Redis
生成配置:
- Dockerfile (多阶段构建, 优化镜像大小)
- docker-compose.yml (开发环境)
- docker-compose.prod.yml (生产环境)
- .dockerignore
- deploy.sh (一键部署脚本)
镜像大小预估: 145 MB (Alpine 基础镜像)
启动时间预估: 3-5 秒
13. Nginx Config(官方可选)
Nginx 配置生成器,支持反向代理、负载均衡、SSL、缓存。
User: 生成一个 Nginx 配置,反向代理到 3 个后端服务
Agent: [加载 nginx-config Skill]
生成配置:
```nginx
upstream backend {
least_conn;
server 127.0.0.1:8001;
server 127.0.0.1:8002;
server 127.0.0.1:8003;
}
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/key.pem;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_cache api_cache;
}
}
```
包含: SSL, HTTP/2, 负载均衡, 缓存, 健康检查
14. SQL Optimizer(官方可选)
SQL 查询优化,分析执行计划、建议索引、重写查询。
User: 优化这个查询
[粘贴慢查询]
Agent: [加载 sql-optimizer Skill]
查询分析:
当前执行计划:
- 全表扫描: users (50万行)
- 全表扫描: orders (200万行)
- 执行时间: 3.2s
优化建议:
1. 添加复合索引: CREATE INDEX idx_orders_user_date
ON orders(user_id, created_at);
2. 重写查询,使用 JOIN 替代子查询
3. 添加 LIMIT 分页
优化后预估: 执行时间 < 50ms
15. Changelog Generator(社区)
从 Git 提交历史自动生成变更日志。
User: 生成 v2.0.0 的变更日志
Agent: [加载 changelog-gen Skill]
分析 Git 历史 (v1.9.0 → v2.0.0)...
发现 156 个提交,分类如下:
## Features
- 新增实时协作功能
- 支持 Markdown 扩展语法
- 添加暗色模式
## Bug Fixes
- 修复文件保存时的并发冲突
- 修复移动端布局问题
## Performance
- 首屏加载时间减少 40%
- 大数据文件编辑优化
## Breaking Changes
- API v1 已弃用,请迁移到 v2
9.4 技能组合推荐(按使用场景)
单一 Skill 的能力有限,但 Skill 组合可以产生强大的协同效应。以下是针对常见场景的推荐组合:
场景一:Web 开发
gstack (技术栈推荐)
→ docker-deploy (生成容器配置)
→ api-doc-generator (生成 API 文档)
→ code-review (代码审查)
→ test-automation (生成测试)
→ security-audit (安全检查)
场景二:数据分析
data-pipeline (数据处理)
→ sql-optimizer (查询优化)
→ csv-analyzer (CSV 分析)
→ chart-creator (可视化)
→ summarize (生成报告摘要)
场景三:内容创作
web-search (资料搜集)
→ summarize (内容摘要)
→ markdown-format (格式化)
→ slide-generator (生成 PPT)
→ manim (数学动画,如需要)
场景四:运维部署
security-audit (安全扫描)
→ docker-deploy (容器化)
→ nginx-config (反向代理)
→ ssl-checker (证书检查)
→ log-analyzer (日志分析)
场景五:学习研究
llm-wiki (概念查询)
→ web-search (深度资料)
→ summarize (整理笔记)
→ flashcard-gen (生成记忆卡片)
10. 高阶技能开发
10.1 复合技能(一个技能调用多个子技能)
复合技能(Composite Skill)是指一个 Skill 在执行过程中调用其他 Skill,形成「技能链」。这就像乐高积木——单个积木功能简单,但组合起来可以搭出复杂结构。
复合技能的结构:
# Fullstack Project Setup
## Metadata
- Name: fullstack-project-setup
- Description: Complete setup for a new fullstack project
- Version: 1.0.0
## Trigger Conditions
- User says "create a new project" or "setup project"
- User mentions "fullstack" + "scaffold" or "template"
## Execution Steps
### Step 1: Tech Stack Selection
**Call Skill**: gstack
Input: user requirements
Output: recommended tech stack
### Step 2: Backend Setup
**Call Skill**: boilerplate-generator
Input: backend framework from Step 1
Output: backend project scaffold
### Step 3: Frontend Setup
**Call Skill**: boilerplate-generator
Input: frontend framework from Step 1
Output: frontend project scaffold
### Step 4: Docker Configuration
**Call Skill**: docker-deploy
Input: project structure from Steps 2-3
Output: Dockerfile + docker-compose.yml
### Step 5: API Documentation
**Call Skill**: api-doc-generator
Input: backend code from Step 2
Output: OpenAPI specification
### Step 6: Initial Tests
**Call Skill**: test-automation
Input: generated code
Output: initial test suite
### Step 7: Security Scan
**Call Skill**: security-audit
Input: entire project
Output: security report + fixes
复合技能的优势:
- 模块化:每个子 Skill 独立维护,复用性高
- 可替换:如果某个子 Skill 有更好的替代品,只需替换调用
- 可配置:用户可以选择跳过某些步骤
10.2 条件分支技能
条件分支技能根据输入或环境的不同,执行不同的流程。
# Smart Deploy
## Execution Steps
### Step 1: Detect Environment
Check current environment:
- If `.github/workflows/` exists → GitHub Actions
- If `.gitlab-ci.yml` exists → GitLab CI
- If `Jenkinsfile` exists → Jenkins
- If none → ask user
### Step 2: Branch by Environment
**If GitHub Actions:**
- Call Skill: github-actions-deploy
**If GitLab CI:**
- Call Skill: gitlab-ci-deploy
**If Jenkins:**
- Call Skill: jenkins-deploy
**If Manual:**
- Generate deployment script
- Provide step-by-step instructions
### Step 3: Verify Deployment
Regardless of path:
- Check service health
- Run smoke tests
- Monitor for 5 minutes
10.3 带参数的技能模板
参数化 Skill 让用户可以在执行时传入不同的值,提高灵活性。
# Generate API Client
## Metadata
- Name: api-client-generator
## Parameters
- spec_url: URL or path to OpenAPI specification
type: string
required: true
- language: Target programming language
type: string
default: "python"
options: [python, typescript, go, java, rust]
- output_dir: Directory to save generated code
type: string
default: "./generated-client/"
- include_tests: Whether to generate test stubs
type: boolean
default: true
## Execution Steps
### Step 1: Parse Spec
Read OpenAPI spec from {{spec_url}}
### Step 2: Generate Client
Generate {{language}} client code
Save to {{output_dir}}
### Step 3: Generate Tests (if {{include_tests}})
If include_tests is true:
Generate test stubs for each endpoint
## Example Input
User: "Generate a TypeScript API client from openapi.json,
save to ./client/, include tests"
Agent: [解析参数]
spec_url: "openapi.json"
language: "typescript"
output_dir: "./client/"
include_tests: true
[执行生成]
参数传递方式:
# 自然语言方式
User: 生成 Python 客户端,不要测试
Agent: [自动解析参数]
# 显式参数方式
User: /skill run api-client-generator --language=go --include-tests=false
# 交互式方式
User: /skill run api-client-generator
Agent: 请提供以下参数:
1. OpenAPI spec 路径: [用户输入]
2. 目标语言: [1]Python [2]TypeScript [3]Go ...
3. 输出目录: [用户输入]
10.4 技能的错误处理
健壮的错误处理是高质量 Skill 的标志。
错误处理策略模板:
## Error Handling
### Network Errors
- **Timeout**: Retry with exponential backoff (max 3 retries)
- **Connection Refused**: Check service status, suggest alternatives
- **DNS Error**: Verify URL, suggest checking network
### Data Errors
- **Invalid Format**: Show expected format, provide converter
- **Missing Required Field**: List missing fields, ask user to provide
- **Data Too Large**: Suggest pagination or streaming
### Permission Errors
- **Access Denied**: Ask for credentials or elevated permissions
- **Rate Limited**: Wait and retry, suggest upgrading plan
- **Quota Exceeded**: Inform user, suggest alternatives
### Tool Errors
- **Tool Not Found**: Check installation, provide setup guide
- **Tool Version Mismatch**: Detect version, suggest update/downgrade
- **Tool Execution Failed**: Capture error output, suggest fixes
### Fallback Strategy
If all else fails:
1. Report what was attempted
2. Explain why it failed
3. Provide manual workaround
4. Offer to create a simpler version
10.5 技能的性能优化
Skill 的执行效率直接影响用户体验。以下是优化技巧:
技巧一:减少不必要的工具调用
# 优化前(4次调用)
Step 1: web_search → 获取结果
Step 2: file_read → 读取模板
Step 3: web_search → 获取更多信息
Step 4: file_write → 写入输出
# 优化后(2次调用)
Step 1: web_search ×2 (并行) → 获取所有信息
Step 2: file_write → 直接写入(模板内联到 Skill 中)
技巧二:缓存中间结果
## Notes
- Cache API responses for 5 minutes to avoid repeated calls
- Store intermediate results in MEMORY.md if reusable
技巧三:批量处理
# 优化前(逐条处理)
For each item:
Call API
Process result
# 优化后(批量处理)
Batch items into groups of 100
Call API with batch
Process results
技巧四:异步执行
## Execution Steps
### Step 1: Parallel Data Fetch
- Fetch data from Source A (async)
- Fetch data from Source B (async)
- Wait for both to complete
### Step 2: Merge and Process
- Combine results
- Process merged data
技巧五:提前退出
## Execution Steps
### Step 1: Validate Input
If input is invalid:
→ Exit early with clear error message
→ Don't proceed to expensive steps
### Step 2: Check Cache
If result already exists and is fresh:
→ Return cached result
→ Skip computation
11. 技能系统最佳实践
11.1 技能命名规范
统一的命名规范让 Skill 更容易被发现和管理。
命名结构:
[domain]-[action]-[target]
示例:
web-search-news # Web 领域 - 搜索 - 新闻
code-review-python # 代码领域 - 审查 - Python
data-clean-csv # 数据领域 - 清洗 - CSV
deploy-docker-prod # 部署领域 - Docker - 生产环境
命名原则:
- 全部小写,用短横线连接
- 动作动词用原形(search, review, clean, deploy)
- 避免缩写(用 docker 而非 dk,用 kubernetes 而非 k8s)
- 版本用目录或后缀区分(
my-skill-v2/或my-skill-advanced/)
11.2 技能分类管理
当 Skill 数量超过 20 个时,分类管理变得重要。
目录结构建议:
~/.hermes/skills/
├── _active/ # 当前常用的(软链接)
├── _archive/ # 归档的、不常用的
├── development/ # 开发相关
│ ├── code-review-python/
│ ├── refactor-helper/
│ └── test-automation/
├── devops/ # 运维相关
│ ├── docker-deploy/
│ ├── nginx-config/
│ └── ssl-checker/
├── content/ # 内容创作
│ ├── summarize/
│ ├── markdown-format/
│ └── doc-generate/
└── data/ # 数据分析
├── csv-analyzer/
├── sql-optimizer/
└── data-pipeline/
分类标签体系:
## Metadata
- Tags: development, python, web, devops, data-analysis,
content-creation, security, automation
常用标签:
| 标签 | 用途 |
|---|---|
| development | 软件开发 |
| devops | 运维部署 |
| data-analysis | 数据分析 |
| web-search | 网络搜索 |
| content-creation | 内容创作 |
| security | 安全审计 |
| automation | 自动化 |
| testing | 测试 |
| documentation | 文档 |
| communication | 通信消息 |
11.3 定期审计与清理
Skill 会不断积累,定期审计能保持系统高效。
月度审计清单:
# 1. 查看使用统计
$ hermes skills list --stats
# 2. 找出从未使用的 Skill
$ hermes skills list --unused --older-than 30d
# 3. 找出重复功能的 Skill
$ hermes skills list --duplicates
# 4. 检查过时的 Skill(很久没有更新)
$ hermes skills list --outdated
# 5. 清理
$ hermes skills archive unused-skill # 归档(不删除)
$ hermes skills delete --unused # 删除未使用的
审计后的处理:
- 高频使用:确保是最新版本,考虑优化
- 偶尔使用:保持现状
- 从未使用:归档或删除
- 功能重复:合并或保留最好的一个
- 已过时:更新或替换
11.4 团队共享技能库的建立
在团队环境中,共享 Skill 能极大提升协作效率。
方案一:Git 仓库共享
# 创建团队 Skill 仓库
$ git init team-hermes-skills
$ git remote add origin git@github.com:company/hermes-skills.git
# 目录结构
team-hermes-skills/
├── README.md
├── CONTRIBUTING.md
├── skills/
│ ├── code-review-company/
│ │ └── SKILL.md # 公司代码规范审查
│ ├── deploy-staging/
│ │ └── SKILL.md # 公司 staging 部署流程
│ └── onboard-newbie/
│ └── SKILL.md # 新人入职指南
└── .github/
└── workflows/
└── validate.yml # CI 验证 Skill 格式
# 团队成员使用
$ git clone git@github.com:company/hermes-skills.git
$ cd hermes-skills
$ make install # 安装所有团队 Skill 到 ~/.hermes/skills/
方案二:私有 Skills Hub
# config.yaml
skills:
hub:
- url: "https://agentskills.io" # 官方 Hub
- url: "https://skills.company.internal" # 公司私有 Hub
auth:
type: "token"
token: "${COMPANY_SKILLS_TOKEN}"
方案三:NAS/网盘同步
# 团队 Skill 放在共享网盘
/Users/Shared/HermesSkills/
# 每个成员的 Hermes 配置指向共享目录
# config.yaml
skills:
additional_paths:
- "/Users/Shared/HermesSkills"
11.5 技能文档化建议
良好的文档让 Skill 更容易被理解和使用。
Skill 文档模板:
# Skill Name
## 快速开始
一句话说明这个 Skill 是做什么的,以及最基本的用法。
## 详细说明
### 功能
- 功能 1
- 功能 2
### 触发条件
什么时候会触发这个 Skill。
### 参数
| 参数 | 类型 | 必填 | 默认值 | 说明 |
|------|------|------|--------|------|
| param1 | string | 是 | - | 说明 |
| param2 | int | 否 | 10 | 说明 |
### 示例
#### 示例 1:基本用法
输入: ... 输出: ...
#### 示例 2:高级用法
输入: ... 输出: ...
## 注意事项
- 注意 1
- 注意 2
## 常见问题
**Q: 为什么...?**
A: ...
## 变更日志
### v1.1.0
- 新增...
- 修复...
### v1.0.0
- 初始版本
## 作者与贡献
- 作者: @your-name
- 贡献者: @contributor1
- 问题反馈: GitHub Issues
本章小结
技能系统是 Hermes Agent 最具实用价值的功能,也是它从「聊天工具」进化为「全能助手」的关键。让我们回顾本章的核心要点:
Skill 的本质:
Skill 不是提示词模板,而是可执行的工作流程序。正如 Hermes Atlas 官方文档所揭示的:「Claude Code 的 memory 存储关于你的事实——偏好要点。而 Hermes 存储的是程序——产生你想要的要点的研究-过滤-格式化工作流。事实告知模型,程序直接被复用。」
Skill 的生命周期:
需求 → 执行 → 模式识别 → 自动生成 Skill → 使用 → 反馈 → 进化 → 更优 Skill
四个信任等级:
- 内置(🏠):随 Hermes 发行,最可信
- 官方(✅):Nous Research 发布,经过安全审计
- 可信(👤):经验证社区成员发布,代码扫描+人工抽查
- 社区(🌐):任何开发者发布,自动扫描,建议查看源码
核心命令速查:
| 命令 | 功能 |
|---|---|
hermes skills list |
查看所有技能 |
hermes skills show <name> |
查看技能详情 |
hermes skills install <name> |
安装技能 |
hermes skills edit <name> |
编辑技能 |
hermes skills delete <name> |
删除技能 |
hermes skills export <name> |
导出技能 |
hermes skills import <file> |
导入技能 |
hermes skills hub |
打开 Skills Hub |
推荐首装 5 个技能:
- LLM Wiki(内置)—— AI 概念速查百科
- Gstack(可信)—— 技术栈管理与推荐
- OpenAI Utils(可信)—— API 成本估算与工具
- Manim(官方)—— 数学动画生成
- Security Audit(官方)—— 安全审计扫描
自动创建的核心规则(5-Tool-Call 规则):
当 Agent 在一次任务中成功调用了 5 个或更多工具,且任务最终成功完成,系统就会评估是否生成 Skill。这个规则确保了只有足够复杂、有复用价值的工作流才会被沉淀。
社区生态:
Skills Hub 上已有 643 个社区技能(截至 2026 年 4 月 19 日),涵盖几乎所有技术领域。无论你是开发者、数据分析师、内容创作者还是运维工程师,都能找到适合自己的 Skill。
最佳实践:
- 先正常使用 1-2 周,让自动创建机制积累你的常用工作流
- 定期审计 Skill,删除未使用的,合并重复的
- 为团队建立共享 Skill 库,提升协作效率
- 贡献高质量 Skill 给社区,既是回馈也是展示
- 安装社区 Skill 前查看源码,确保安全
掌握技能系统,你就掌握了让 Hermes 持续进化的密码。每一次成功的任务执行,都是未来效率提升的种子。当你的 Skill 库积累到 20、50、100 个时,你会发现:Agent 不再是「你教它做什么」,而是「它知道该为你做什么」。
这就是从「工具」到「搭档」的跨越。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第九册:47 个内置工具全解 —— Hermes Agent 的瑞士军刀使用手册
本章你将学到
- Hermes 工具系统的整体架构和设计哲学,理解为什么工具是 Agent 的「手脚」
- 工具(Tool)与技能(Skill)的本质区别和协同关系
- ToolRegistry 单例模式的自注册机制,工具是如何自动被发现和加载的
- 安全审批流程的完整链条:哪些工具需要确认、确认界面长什么样、如何配置审批策略
- 47 个内置工具的详细参数说明、使用示例和注意事项
- 七大类工具的实战组合技巧,从单一工具到工具链的进阶用法
- 工具开发扩展方法:自定义工具、MCP 协议集成和社区贡献指南
- 工具使用的 10 大误区和最佳实践,让你少走弯路
1. 工具系统总览:Agent 的「手脚」是如何长出来的
1.1 什么是 Hermes 工具(Tool)
想象一下,你雇了一位智商 180 的顶级顾问。他上知天文下知地理,能跟你聊哲学、谈经济、写代码、做分析——但他有一个致命缺陷:他不能离开椅子,不能碰电脑,不能上网,不能操作文件,甚至连计算器都不能按。
这位顾问能做的事情,就是动动嘴皮子给你出主意。当你说「帮我搜一下今天的 AI 新闻」,他会说「根据我的知识,AI 领域最近有这些进展……」——但他说的可能是三个月前的旧闻,因为他没法上网查。
这就是没有工具的 AI Agent。
现在,你给这位顾问配了一套「智能义肢」:
- 一双能操作键盘鼠标的手(文件系统工具)
- 一双能看网页的眼睛(Web 交互工具)
- 一个能执行代码的大脑(代码执行工具)
- 一个能记住事情的笔记本(记忆管理工具)
- 一个能发号施令的对讲机(代理委托工具)
这套「义肢」,就是 Hermes 的工具系统(Tool System)。
工具的本质,是给大语言模型(LLM)赋予与外部世界交互的能力。 LLM 本身只能处理文本输入、生成文本输出。它无法读取你电脑上的文件,无法访问互联网,无法运行程序,无法发送通知。工具系统就是一座桥梁,把 LLM 的「思考能力」与计算机系统的「执行能力」连接起来。
在 Hermes 中,工具被设计为函数调用(Function Calling)的形式。当 Agent 决定需要执行某个外部操作时,它会构造一个工具调用请求,包含工具名称和参数,然后由工具执行层负责实际执行,最后把执行结果返回给 Agent,Agent 再根据结果决定下一步行动。
这个过程就像这样:
你:帮我分析一下项目根目录下的 package.json 文件
Agent(思考):用户要我分析 package.json,我需要先读取这个文件。
我应该调用 read_file 工具,参数是 file_path="package.json"。
Agent(工具调用):read_file(file_path="package.json")
工具执行层:读取 /Users/me/project/package.json 的内容
工具执行层(返回结果):{ "name": "my-project", "version": "1.0.0", ... }
Agent(思考):拿到了文件内容,现在我需要分析它的依赖结构、脚本命令等。
Agent(回复):这个 package.json 的依赖结构是这样的……
Tips
很多新手会混淆「工具调用」和「普通回复」。当你看到 Agent 的回复中有类似
read_file(...)这样的内容时,不要以为是 Agent 在「假装」调用工具——它是真的在执行!工具调用会被系统拦截,转交给对应的工具执行模块,执行完毕后再把结果喂回给 Agent。
1.2 工具与技能(Skill)的区别
在第八册中,我们详细讲解了 Skill(技能)系统。Skill 和 Tool 都是 Hermes 的核心能力,但它们的角色完全不同。
用一个类比来理解:
- Tool(工具) = 你手里的「工具」:锤子、螺丝刀、电钻、尺子
- Skill(技能) = 你脑子里的「工艺」:如何组装一个书架、如何修理一辆自行车
工具是被动的、原子化的能力单元。每个工具只做一件事:read_file 只负责读文件,web_search 只负责搜索网页。工具本身不知道「什么时候该用」,也不知道「用了之后下一步该做什么」。
技能是主动的、流程化的工作模板。一个技能会组织多个工具的调用顺序,定义每一步的参数模板,甚至包含条件分支和错误处理。比如「生成周报」这个技能,可能会按顺序调用:web_search(搜行业动态)→ read_file(读上周模板)→ write_file(写新周报)。
| 维度 | Tool(工具) | Skill(技能) |
|---|---|---|
| 粒度 | 原子操作(单一步骤) | 复合流程(多个步骤) |
| 智能性 | 被动执行,无决策能力 | 主动决策,包含条件分支 |
| 可复用性 | 被 Skill 调用 | 被用户触发或自动触发 |
| 存储位置 | 代码中的 Tool 类 | ~/.hermes/skills/ 下的 Markdown 文件 |
| 编写者 | 开发者(Python/TypeScript 代码) | 用户或社区(Markdown 配置) |
| 数量 | 47 个内置工具 | 700+ 个社区技能 |
注意
Tool 和 Skill 的关系是「被调用」与「调用者」的关系。Skill 会调用 Tool,但 Tool 不会调用 Skill。你也可以把 Skill 理解为「高级工具编排语言」,而 Tool 是「底层机器指令」。
1.3 ToolRegistry 单例模式与自注册机制
Hermes 的工具系统采用了一个非常优雅的设计:自注册(Self-Registration)机制。这意味着你不需要手动维护一个「工具清单」,新工具会自动被发现和注册。
核心组件:ToolRegistry
ToolRegistry 是一个单例(Singleton)类,整个 Hermes 进程中只有一个实例。它相当于工具的「中央数据库」,维护着所有可用工具的注册信息。
# 简化的 ToolRegistry 核心逻辑
class ToolRegistry:
_instance = None
_tools: Dict[str, Tool] = {}
def __new__(cls):
if cls._instance is None:
cls._instance = super().__new__(cls)
return cls._instance
def register(self, tool: Tool):
"""注册一个工具到全局注册表"""
self._tools[tool.name] = tool
def get(self, name: str) -> Tool:
"""按名称获取工具实例"""
return self._tools.get(name)
def list_all(self) -> List[Tool]:
"""列出所有已注册的工具"""
return list(self._tools.values())
自注册机制:装饰器魔法
Hermes 使用了 Python 装饰器来实现工具的自注册。开发者只需在工具类上添加一个 @tool 装饰器,这个工具就会自动被注册到 ToolRegistry 中。
from hermes.core.tools import tool
@tool(
name="read_file",
description="读取指定文件的内容",
parameters={
"file_path": {"type": "string", "description": "文件路径"},
"offset": {"type": "integer", "description": "起始偏移量", "default": 0},
"limit": {"type": "integer", "description": "读取行数限制", "default": 100}
},
requires_approval=False # 不需要用户审批
)
class ReadFileTool(Tool):
async def execute(self, params: dict) -> ToolResult:
file_path = params["file_path"]
# 实际的文件读取逻辑...
return ToolResult(content=file_content)
当 Hermes 启动时,它会扫描 hermes/tools/ 目录下的所有 Python 文件,导入这些模块。由于装饰器在导入时就会执行,@tool 装饰器会把工具实例自动注册到 ToolRegistry 单例中。
这个过程就像是:
- Hermes 启动 → 扫描工具目录
- 发现
read_file_tool.py→ 导入模块 - 装饰器
@tool(...)执行 → 调用registry.register(read_file_tool) - 工具进入全局注册表 → 可供 Agent 随时调用
Tips
这种自注册机制的好处是「新增工具零配置」。你只需创建一个新的工具文件,放到正确的目录下,重启 Hermes,新工具就会自动生效。不需要修改任何配置文件,也不需要手动更新工具列表。
1.4 工具调用的安全审批流程
工具赋予了 Agent 强大的能力,但也带来了安全风险。想象一下,如果 Agent 可以不受限制地执行 rm -rf /(删除整个系统),那将是一场灾难。
Hermes 设计了一套分层的安全审批机制,根据工具的危险等级决定是否需要用户确认。
危险等级分类
| 等级 | 描述 | 典型工具 | 审批策略 |
|---|---|---|---|
| 🟢 安全 | 只读操作,不会修改任何数据 | read_file、web_search、list_directory | 无需审批 |
| 🟡 低风险 | 可能修改数据,但影响范围有限 | write_file(覆盖已有文件)、memory_write | 首次审批,可记住选择 |
| 🟠 中风险 | 会修改系统状态,有潜在副作用 | execute_python、run_command(白名单内) | 每次都需要审批 |
| 🔴 高风险 | 可能破坏数据或危害系统安全 | execute_shell、kill_process、rm -rf | 强制审批,无法跳过 |
审批界面长什么样
当 Agent 调用一个需要审批的工具时,你会在终端看到类似这样的提示:
┌─────────────────────────────────────────────────────────┐
│ ⚠️ 工具调用需要您的确认 │
├─────────────────────────────────────────────────────────┤
│ 工具: execute_shell │
│ 描述: 执行 Shell 命令 │
│ 风险等级: 🔴 高风险 │
│ │
│ 参数: │
│ command: "rm -rf /tmp/old_logs" │
│ │
│ 预估影响: 将删除 /tmp/old_logs 目录及其所有内容 │
├─────────────────────────────────────────────────────────┤
│ 请选择: │
│ [Y] 允许本次执行 │
│ [N] 拒绝本次执行 │
│ [A] 始终允许此类操作(记住选择) │
│ [D] 查看详细参数 │
└─────────────────────────────────────────────────────────┘
> Y
注意
即使选择了「始终允许」,某些极高风险的操作(如
rm -rf /、修改系统配置文件)仍然会强制要求确认。这是 Hermes 的「安全底线」,无法通过配置关闭。
配置审批策略
你可以在 ~/.hermes/config.yaml 中自定义审批策略:
# Hermes 安全配置
tools:
approval:
# 全局默认策略:对所有需要审批的工具生效
default_strategy: "prompt" # prompt | auto_allow | auto_deny
# 按工具单独配置
per_tool:
execute_shell:
strategy: "prompt" # 强制提示
require_confirmation: true
write_file:
strategy: "remember" # 首次确认,后续记住
remember_duration: "7d" # 记住 7 天
read_file:
strategy: "auto_allow" # 自动允许(只读操作)
# 命令黑名单:包含这些关键字的命令直接拒绝
command_blacklist:
- "rm -rf /"
- "mkfs."
- ":(){ :|:& };:"
- "> /dev/sda"
# 命令白名单:只允许执行这些命令(如果启用白名单模式)
command_whitelist:
- "git"
- "npm"
- "python"
- "ls"
- "cat"
常见问题
Q: 为什么 read_file 也需要配置 approval?
A: 虽然 read_file 默认是安全操作,但在某些高安全要求的环境中(如处理敏感文件),你可能希望对所有文件访问进行审计。通过将
read_file的 strategy 设为"prompt",可以记录每次文件读取操作。Q: 我不小心点了「始终允许」,怎么撤销?
A: 运行
hermes approval reset命令,可以清除所有已记住的审批决策,恢复到初始状态。
1.5 hermes tools 命令使用
Hermes 提供了一个便捷的 CLI 命令来查看和管理工具。
# 列出所有可用工具
hermes tools list
# 查看某个工具的详细信息
hermes tools info read_file
# 查看工具的分类统计
hermes tools stats
# 测试一个工具(不经过 Agent,直接执行)
hermes tools test read_file --params '{"file_path": "README.md"}'
# 查看工具调用历史
hermes tools history
# 导出工具配置
hermes tools export > my_tools_config.yaml
hermes tools list 的输出示例:
┌────────────────────────────────────────────────────────────┐
│ Hermes 内置工具清单(共 47 个) │
├──────────────┬──────────────────────────┬──────────────────┤
│ 工具名称 │ 类别 │ 需要审批 │
├──────────────┼──────────────────────────┼──────────────────┤
│ read_file │ 文件系统 │ 否 │
│ write_file │ 文件系统 │ 是(低风险) │
│ edit_file │ 文件系统 │ 是(低风险) │
│ execute_python │ 代码执行 │ 是(中风险) │
│ execute_shell │ 代码执行 │ 是(高风险) │
│ web_search │ Web 交互 │ 否 │
│ ... │ ... │ ... │
└──────────────┴──────────────────────────┴──────────────────┘
Tips
hermes tools test是调试工具的神器。当你怀疑某个工具行为异常时,可以直接用测试模式执行,绕过 Agent 的推理逻辑,快速验证工具本身是否正常工作。
本章小结
在本章中,我们建立了对 Hermes 工具系统的整体认知:
- 工具是 Agent 的「手脚」,让 LLM 从「只能动嘴」进化到「能够动手」
- 工具与技能的区别在于:工具是原子化的执行单元,技能是流程化的工作编排
- 自注册机制让工具的发现和加载完全自动化,新增工具零配置
- 安全审批流程通过四级风险分类和可配置的策略,在便利性和安全性之间取得平衡
hermes toolsCLI 命令提供了便捷的工具管理和调试手段
接下来的章节,我们将逐一深入讲解 47 个内置工具的详细用法。准备好你的「工具箱」了吗?让我们开始!
2. 第一类:文件系统工具 —— Agent 的「文件管家」
本章你将学到
- 6 个文件系统工具的完整参数说明和使用场景
- 如何安全地读取、写入、编辑文件而不损坏数据
- search_files 的搜索语法和性能优化技巧
- 文件操作中的常见陷阱和避坑指南
- 批量文件处理的高效工作流
文件系统工具是 Hermes 最基础也是最常用的工具类别。它们让 Agent 能够与你的本地文件系统交互——读取配置文件、修改代码、搜索日志、整理目录。可以说,没有文件系统工具,Agent 就像一个被蒙住眼睛的人,根本不知道周围有什么。
2.1 read_file —— 读取文件内容
功能说明
read_file 是 Hermes 中使用频率最高的工具之一。它负责读取指定文件的内容,并以文本形式返回给 Agent。
这个工具的设计非常注重安全性和性能:
- 默认只能读取用户有权限访问的文件
- 支持大文件的分段读取,避免一次性加载几百 MB 的日志文件导致内存爆炸
- 自动检测文件编码(UTF-8、GBK、Latin-1 等)
- 支持二进制文件的十六进制预览
参数详解
{
"file_path": {
"type": "string",
"required": true,
"description": "要读取的文件路径,支持相对路径和绝对路径"
},
"offset": {
"type": "integer",
"required": false,
"default": 0,
"description": "起始行偏移量(从 0 开始),用于读取大文件的一部分"
},
"limit": {
"type": "integer",
"required": false,
"default": 100,
"description": "最多读取多少行,防止大文件导致上下文溢出"
},
"encoding": {
"type": "string",
"required": false,
"default": "auto",
"description": "文件编码,可选值:auto、utf-8、gbk、latin-1、ascii"
},
"format": {
"type": "string",
"required": false,
"default": "text",
"description": "输出格式:text(纯文本)、hex(十六进制)、base64"
}
}
使用示例
示例 1:读取普通文本文件
工具调用:
read_file(file_path="README.md")
返回结果:
# Hermes Agent
Hermes 是一个开源的 AI Agent 框架……
示例 2:读取代码文件的指定范围
工具调用:
read_file(file_path="src/main.py", offset=50, limit=30)
返回结果:
(从第 51 行到第 80 行的代码内容)
Tips
当你需要查看一个文件的特定函数或类时,先使用
search_files定位到行号,再用read_file的offset和limit参数精确读取。这比一次性读取整个文件高效得多,特别是对于几千行的大文件。
示例 3:读取二进制文件(预览模式)
工具调用:
read_file(file_path="data/sample.bin", format="hex", limit=20)
返回结果:
00000000: 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 .PNG........IHDR
00000010: 00 00 00 80 00 00 00 80 08 06 00 00 00 C3 3E 61 ..............>a
常见场景
| 场景 | 参数组合 | 说明 |
|---|---|---|
| 查看配置文件 | file_path="config.yaml" |
快速了解项目配置 |
| 查看日志尾部 | file_path="app.log", offset=-50 |
负数 offset 表示从末尾算起 |
| 查看大文件中间部分 | file_path="data.csv", offset=1000, limit=50 |
分段读取避免上下文溢出 |
| 检查文件编码 | file_path="legacy.txt", encoding="auto" |
自动检测编码 |
注意事项
注意
- 路径安全:
read_file默认被限制在当前工作目录及其子目录内。尝试读取/etc/passwd或../../secret.txt这样的路径会被拒绝。- 大文件保护:如果文件超过 10MB,Agent 会收到警告,建议使用
offset和limit分段读取。- 敏感文件:以
.env、.key、.pem结尾的文件读取时会额外提示,防止意外泄露密钥。常见问题
Q: 为什么读取某些文件会显示乱码?
A: 这通常是编码问题。Windows 系统下的中文文件常用 GBK 编码,而 Hermes 默认按 UTF-8 读取。解决方法:显式指定
encoding="gbk"。如果不知道编码,可以先试encoding="auto",Hermes 会尝试自动检测。Q: 如何读取一个文件的最后 100 行?
A: 使用负数 offset:
read_file(file_path="app.log", offset=-100)。这相当于 Linux 命令tail -n 100。
2.2 write_file —— 写入/创建文件
功能说明
write_file 用于创建新文件或覆盖已有文件。这是 Agent「输出成果」的主要方式——生成报告、保存代码、导出数据,都离不开这个工具。
由于 write_file 会永久修改文件系统,它被归类为低风险操作,默认需要用户审批(首次可记住选择)。
参数详解
{
"file_path": {
"type": "string",
"required": true,
"description": "目标文件路径"
},
"content": {
"type": "string",
"required": true,
"description": "要写入的文件内容"
},
"encoding": {
"type": "string",
"required": false,
"default": "utf-8",
"description": "文件编码"
},
"append": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否在文件末尾追加内容(而不是覆盖)"
},
"create_dirs": {
"type": "boolean",
"required": false,
"default": true,
"description": "如果父目录不存在,是否自动创建"
},
"backup": {
"type": "boolean",
"required": false,
"default": false,
"description": "覆盖前是否创建 .bak 备份文件"
}
}
使用示例
示例 1:创建一个新文件
工具调用:
write_file(
file_path="report.md",
content="# 项目分析报告\n\n## 概述\n本项目……"
)
示例 2:追加内容到日志文件
工具调用:
write_file(
file_path="logs/agent.log",
content="[2024-01-15 10:30:00] 任务完成\n",
append=true
)
示例 3:安全覆盖(带备份)
工具调用:
write_file(
file_path="config.yaml",
content="新的配置内容……",
backup=true
)
结果:
- 原 config.yaml 被重命名为 config.yaml.bak
- 新内容写入 config.yaml
Tips
在修改重要配置文件(如
package.json、pyproject.toml)时,强烈建议设置backup=true。这样如果修改出了问题,你可以随时用read_file查看.bak文件恢复原始内容。
常见场景
| 场景 | 参数组合 | 说明 |
|---|---|---|
| 生成报告 | file_path="report.md" |
Agent 最常用的输出方式 |
| 保存代码 | file_path="src/utils.py" |
生成新模块或修改现有模块 |
| 追加日志 | append=true |
不覆盖已有内容 |
| 创建多级目录 | create_dirs=true |
自动创建不存在的父目录 |
注意事项
注意
- 覆盖警告:如果目标文件已存在且
append=false(默认值),工具会提示「文件已存在,是否覆盖?」这是防止意外丢失数据的重要保护。- 空内容保护:如果
content为空字符串,工具会拒绝执行,防止误删文件内容。- 二进制文件:虽然 write_file 主要处理文本,但也可以通过 base64 编码写入二进制内容。不过对于大二进制文件,建议使用专门的文件传输工具。
2.3 edit_file —— 编辑文件(差异替换)
功能说明
如果说 write_file 是「推土机」(全部推倒重来),那么 edit_file 就是「手术刀」——只修改文件的特定部分,保留其他内容不变。
edit_file 基于差异替换原理工作。你提供一段「旧文本」和一段「新文本」,工具会在文件中找到旧文本的位置,将其替换为新文本。这种方式非常适合代码修改、文本替换、配置更新等场景。
参数详解
{
"file_path": {
"type": "string",
"required": true,
"description": "要编辑的文件路径"
},
"old_string": {
"type": "string",
"required": true,
"description": "文件中要被替换的旧文本片段"
},
"new_string": {
"type": "string",
"required": true,
"description": "用于替换的新文本片段"
},
"occurrence": {
"type": "integer",
"required": false,
"default": 1,
"description": "替换第几次出现的旧文本(1=第一次,-1=最后一次)"
},
"backup": {
"type": "boolean",
"required": false,
"default": true,
"description": "编辑前是否自动创建 .bak 备份"
}
}
使用示例
示例 1:简单的文本替换
假设 greeting.txt 内容如下:
Hello, World!
Welcome to Hermes.
工具调用:
edit_file(
file_path="greeting.txt",
old_string="World",
new_string="Hermes User"
)
结果:
Hello, Hermes User!
Welcome to Hermes.
示例 2:修改代码中的函数实现
假设 calculator.py 中有如下代码:
def add(a, b):
return a + b
工具调用:
edit_file(
file_path="calculator.py",
old_string='def add(a, b):\n return a + b',
new_string='def add(a, b):\n """返回两个数的和"""\n return a + b'
)
结果:
def add(a, b):
"""返回两个数的和"""
return a + b
Tips
在编写
old_string时,一定要确保文本片段在文件中是唯一的。如果旧文本在文件中出现了多次,而你只想替换其中一处,就需要使用occurrence参数。否则工具会报错:「找到多处匹配,请使用 occurrence 参数指定」。
示例 3:替换第 N 次出现
工具调用:
edit_file(
file_path="data.txt",
old_string="apple",
new_string="orange",
occurrence=2 # 替换第二次出现的 "apple"
)
常见场景
| 场景 | 技巧 | 说明 |
|---|---|---|
| 修改函数签名 | 精确匹配整个函数定义行 | 确保 old_string 包含足够的上下文 |
| 更新版本号 | old_string="version = \"1.0.0\"" |
注意转义引号 |
| 添加 import 语句 | 在已有 import 块中插入 | 匹配最后一个 import,在其后追加 |
| 删除代码块 | new_string=""(空字符串) |
将 old_string 替换为空即可删除 |
注意事项
注意
- 匹配唯一性:
old_string必须在文件中能唯一标识要修改的位置。如果匹配到多处,工具会拒绝执行,防止误改。- 空白字符敏感:
old_string的匹配是精确的,包括空格和换行。如果文件中使用的是 Tab 缩进,而你的 old_string 用的是空格,匹配会失败。- 备份默认开启:
edit_file的backup默认为true,因为编辑操作通常比写入更危险——你可能只改了一行,却影响了整个文件的功能。常见问题
Q: edit_file 匹配失败,但我确定文本是对的,怎么办?
A: 最常见的原因是不可见字符(如 BOM、不同换行符
\r\nvs\n、尾部空格)。解决方法: 1. 先用read_file精确读取目标区域 2. 直接复制工具返回的文本作为old_string3. 如果还是失败,检查是否有混合缩进(Tab + 空格)Q: 如何一次性进行多处修改?
A:
edit_file一次调用只能修改一处。如果需要多处修改,可以: 1. 连续调用多次edit_file2. 或者使用write_file配合read_file先读取全部内容,在 Agent 内部修改后再写回
2.4 list_directory —— 列出目录内容
功能说明
list_directory 是 Agent 的「眼睛」——让它能看到某个目录下有什么文件和子目录。这是探索项目结构、查找文件、确认路径是否存在的必备工具。
参数详解
{
"directory_path": {
"type": "string",
"required": false,
"default": ".",
"description": "要列出的目录路径,默认为当前工作目录"
},
"recursive": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否递归列出子目录内容"
},
"show_hidden": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否显示隐藏文件(以 . 开头的文件)"
},
"filter": {
"type": "string",
"required": false,
"description": "文件过滤模式,如 *.py、*.md"
},
"sort_by": {
"type": "string",
"required": false,
"default": "name",
"description": "排序方式:name、size、mtime"
}
}
使用示例
示例 1:列出当前目录
工具调用:
list_directory()
返回结果:
📁 src/
📁 tests/
📄 README.md
📄 package.json
📄 .gitignore
示例 2:递归列出项目结构
工具调用:
list_directory(directory_path=".", recursive=true)
返回结果:
.
├── src/
│ ├── main.py
│ ├── utils/
│ │ ├── helpers.py
│ │ └── constants.py
│ └── models/
│ └── user.py
├── tests/
│ └── test_main.py
├── README.md
└── requirements.txt
示例 3:筛选特定类型的文件
工具调用:
list_directory(directory_path="src", filter="*.py", recursive=true)
返回结果:
src/main.py
src/utils/helpers.py
src/utils/constants.py
src/models/user.py
Tips
当你刚接触一个新项目,不了解它的目录结构时,让 Agent 执行
list_directory(recursive=true)是最快的方式。Agent 可以基于目录结构判断项目类型(Python 项目、Node.js 项目、Go 项目等),并给出相应的操作建议。
常见场景
| 场景 | 参数 | 说明 |
|---|---|---|
| 探索新项目 | recursive=true |
快速了解项目全貌 |
| 查找配置文件 | filter="*.json", recursive=true |
定位所有 JSON 配置文件 |
| 查看隐藏文件 | show_hidden=true |
显示 .env、.gitignore 等 |
| 找最近修改的文件 | sort_by="mtime" |
按修改时间排序 |
注意事项
注意
- 递归深度限制:
recursive=true时,默认最大递归深度为 5 层。这是为了防止在包含大量子目录的项目(如node_modules)中卡死。- 权限过滤:没有读取权限的目录会被跳过,并在结果中标注
[权限不足]。- 符号链接:默认会跟随符号链接,但最多跟随 10 层,防止循环链接导致的无限递归。
2.5 search_files —— 搜索文件(grep 风格)
功能说明
search_files 是 Agent 的「搜索引擎」——在文件系统中搜索包含指定文本的文件。它类似于 Linux 的 grep 命令,但更加智能和易用。
这个工具支持正则表达式、多目录搜索、文件类型过滤等高级功能,是代码审查、日志分析、批量替换的利器。
参数详解
{
"pattern": {
"type": "string",
"required": true,
"description": "搜索模式,支持正则表达式"
},
"path": {
"type": "string",
"required": false,
"default": ".",
"description": "搜索的根目录"
},
"glob": {
"type": "string",
"required": false,
"description": "文件过滤模式,如 *.py、*.js、*.md"
},
"recursive": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否递归搜索子目录"
},
"case_sensitive": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否区分大小写"
},
"max_results": {
"type": "integer",
"required": false,
"default": 50,
"description": "最多返回多少条结果"
},
"context_lines": {
"type": "integer",
"required": false,
"default": 2,
"description": "匹配行前后显示多少行上下文"
}
}
使用示例
示例 1:搜索包含特定函数的代码
工具调用:
search_files(pattern="def calculate", glob="*.py")
返回结果:
src/math.py:42: def calculate_area(radius):
src/math.py:58: def calculate_volume(radius, height):
src/finance.py:15: def calculate_interest(principal, rate):
示例 2:使用正则表达式搜索
工具调用:
search_files(
pattern="class \w+View",
glob="*.py",
context_lines=3
)
返回结果:
src/views.py:10:
8: import json
9: from django.views import View
10: class UserView(View):
11: def get(self, request):
12: pass
示例 3:在日志中搜索错误
工具调用:
search_files(
pattern="ERROR|CRITICAL|FATAL",
path="logs",
glob="*.log",
max_results=20
)
返回结果:
logs/app.log:156: [ERROR] Connection timeout after 30s
logs/app.log:203: [CRITICAL] Database connection lost
logs/app.log:215: [ERROR] Failed to process request #12345
Tips
当你需要修改某个函数或变量时,先用
search_files找到它所有出现的位置,再决定用edit_file还是批量处理。这能有效避免「改了一处,漏了另一处」的问题。
搜索语法速查表
| 需求 | 模式示例 | 说明 |
|---|---|---|
| 精确匹配 | exact_word |
普通字符串匹配 |
| 忽略大小写 | 默认行为 | 不需要额外设置 |
| 正则匹配 | \d{4}-\d{2}-\d{2} |
匹配日期格式 YYYY-MM-DD |
| 匹配整词 | \bword\b |
\b 表示单词边界 |
| 匹配行首 | ^import |
^ 表示行开头 |
| 匹配行尾 | \.py$ |
$ 表示行结尾 |
| 或条件 | error\|warn\|fatal |
\| 表示「或」 |
| 排除文件 | 使用 glob 反向筛选 | 如 *.py 只搜 Python 文件 |
注意事项
注意
- 二进制文件跳过:
search_files会自动跳过二进制文件(图片、视频、压缩包等),避免无意义的匹配。- 大文件处理:超过 100MB 的文件会被标记为
[文件过大,仅搜索前 1000 行]。- 忽略目录:默认会跳过
.git、node_modules、__pycache__、vendor等常见依赖目录。如果需要搜索这些目录,可以显式指定path。常见问题
Q: 搜索太慢怎么办?
A: 优化搜索速度的几种方法: 1. 缩小
path范围,不要从根目录开始搜 2. 使用更精确的glob过滤,如src/**/*.py3. 减小max_results,如果只需要前几个结果 4. 避免使用过于宽泛的正则,如.*Q: 如何搜索不包含某文本的文件?
A:
search_files本身不支持反向搜索(搜索不包含某文本的文件)。 workaround:先搜索包含目标文本的文件,再用list_directory获取全部文件,两者做差集。或者使用execute_shell运行grep -v命令。
2.6 file_info —— 获取文件元信息
功能说明
file_info 用于获取文件的元数据(Metadata)——不是文件内容,而是关于文件的「信息的信息」。比如文件大小、创建时间、修改时间、权限、文件类型等。
这个工具在以下场景特别有用:
- 判断一个文件是不是二进制文件(决定用 read_file 还是其他方式处理)
- 检查文件最近是否被修改过(排查问题)
- 确认文件权限是否正确(排查访问错误)
- 获取文件哈希值(验证文件完整性)
参数详解
{
"file_path": {
"type": "string",
"required": true,
"description": "目标文件路径"
},
"compute_hash": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否计算文件的 MD5 和 SHA256 哈希值"
}
}
使用示例
示例 1:查看文件基本信息
工具调用:
file_info(file_path="README.md")
返回结果:
{
"file_path": "README.md",
"exists": true,
"type": "file",
"size": 2458,
"size_human": "2.4 KB",
"created": "2024-01-10T08:30:00Z",
"modified": "2024-01-15T14:22:00Z",
"accessed": "2024-01-16T09:00:00Z",
"permissions": "644",
"owner": "jwangkun",
"group": "staff",
"is_binary": false,
"encoding": "utf-8",
"mime_type": "text/markdown"
}
示例 2:获取文件哈希值
工具调用:
file_info(file_path="installer.dmg", compute_hash=true)
返回结果:
{
"file_path": "installer.dmg",
"exists": true,
"type": "file",
"size": 52428800,
"size_human": "50.0 MB",
"md5": "5d41402abc4b2a76b9719d911017c592",
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
}
Tips
当你怀疑两个文件是否相同时,不需要用
read_file逐字比较。使用file_info(compute_hash=true)比较它们的 SHA256 哈希值即可。如果哈希值相同,文件内容 100% 相同(忽略哈希碰撞这种极特殊情况)。
常见场景
| 场景 | 用法 | 说明 |
|---|---|---|
| 排查文件访问问题 | 检查 permissions 和 owner |
确认当前用户有读取权限 |
| 判断文件类型 | 查看 mime_type |
决定后续处理方式 |
| 检查文件新鲜度 | 对比 modified 时间 |
确认文件是否是最新版本 |
| 验证下载完整性 | compute_hash=true |
对比官方提供的哈希值 |
注意事项
注意
- 符号链接:如果目标文件是符号链接,
file_info默认返回链接目标的信息。如果你想获取链接本身的信息,目前需要配合execute_shell使用ls -la。- 不存在的文件:如果文件不存在,工具不会报错,而是返回
"exists": false。这在编写条件逻辑时很有用——你可以先检查文件是否存在,再决定是读取还是创建。
文件系统工具组合实战
下面是一个将多个文件系统工具组合使用的实战案例。
场景:你接手了一个遗留项目,需要快速了解它的代码结构,并找到所有使用 eval() 函数的地方(因为 eval() 有安全隐患)。
步骤 1:查看项目结构
→ list_directory(recursive=true)
步骤 2:找到所有 Python 文件
→ list_directory(filter="*.py", recursive=true)
步骤 3:搜索 eval() 的使用
→ search_files(pattern="eval\(", glob="*.py", context_lines=5)
步骤 4:读取某个可疑文件查看上下文
→ read_file(file_path="src/legacy_module.py", offset=40, limit=20)
步骤 5:修改问题代码
→ edit_file(
file_path="src/legacy_module.py",
old_string='result = eval(user_input)',
new_string='result = ast.literal_eval(user_input) # 更安全的替代方案'
)
Tips
文件系统工具的调用链通常遵循「探索 → 定位 → 读取 → 修改」的模式。先用
list_directory和search_files探索,用read_file确认细节,最后用edit_file或write_file执行修改。不要跳过「探索」和「确认」步骤直接修改——这就像不看路就开车,很容易出问题。
本章小结
本章我们详细讲解了 6 个文件系统工具:
read_file:读取文件内容,支持分段读取和编码自动检测write_file:创建或覆盖文件,支持追加模式和自动备份edit_file:精确替换文件中的特定文本片段,默认自动备份list_directory:列出目录内容,支持递归和过滤search_files:grep 风格的文件搜索,支持正则和上下文显示file_info:获取文件元数据,包括大小、时间、权限、哈希值
核心原则:
- 先读再写:修改文件前先
read_file确认内容 - 搜索定位:用
search_files找到精确位置,再用edit_file修改 - 备份保护:重要文件操作开启
backup=true - 分段读取:大文件使用
offset和limit,避免上下文溢出
3. 第二类:代码执行工具 —— Agent 的「编译器」和「解释器」
本章你将学到
- 4 个代码执行工具的功能和安全边界
- 沙箱环境的限制和逃逸防护
- 危险命令的分级处理机制
- 如何在安全的前提下最大化代码执行工具的价值
- 代码执行失败的排查和调试技巧
代码执行工具是 Hermes 最强大的工具类别之一,也是最需要谨慎使用的类别。它们让 Agent 能够运行 Python、JavaScript、Shell 脚本,执行数据分析、自动化测试、系统管理等任务。但强大的能力伴随着风险——恶意或错误的代码可能破坏数据、泄露隐私、甚至损害系统。
3.1 execute_python —— 执行 Python 代码
功能说明
execute_python 让 Agent 能够运行任意 Python 代码。这是数据分析、自动化脚本、快速原型验证的终极武器。
Hermes 的 Python 执行环境具有以下特点:
- 隔离的虚拟环境:每个执行请求在独立的 Python 进程中运行
- 超时保护:默认 30 秒超时,防止死循环
- 内存限制:默认限制 512MB 内存使用
- 网络访问控制:可选启用或禁用网络访问
- 文件系统沙箱:默认只能访问当前工作目录
参数详解
{
"code": {
"type": "string",
"required": true,
"description": "要执行的 Python 代码"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "执行超时时间(秒)"
},
"memory_limit": {
"type": "integer",
"required": false,
"default": 512,
"description": "内存限制(MB)"
},
"network": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否允许网络访问"
},
"working_dir": {
"type": "string",
"required": false,
"default": ".",
"description": "工作目录,代码只能访问此目录下的文件"
},
"packages": {
"type": "array",
"required": false,
"description": "需要临时安装的 Python 包列表"
}
}
使用示例
示例 1:简单的数学计算
工具调用:
execute_python(
code="""
import math
# 计算复利
principal = 10000
rate = 0.05
years = 10
amount = principal * (1 + rate) ** years
print(f"本金: {principal}")
print(f"年利率: {rate*100}%")
print(f"年限: {years}")
print(f"最终金额: {amount:.2f}")
print(f"利息收入: {amount - principal:.2f}")
"""
)
返回结果:
本金: 10000
年利率: 5.0%
年限: 10
最终金额: 16288.95
利息收入: 6288.95
示例 2:数据分析(需要 pandas)
工具调用:
execute_python(
code="""
import pandas as pd
# 读取 CSV 文件
df = pd.read_csv('sales_data.csv')
# 基本统计
print("数据概览:")
print(df.describe())
print("\n按月份汇总销售额:")
monthly = df.groupby('month')['amount'].sum()
print(monthly)
""",
packages=["pandas"]
)
Tips
如果你不确定某个包是否已安装,可以在
packages中列出它。Hermes 会检查环境,如果包不存在会自动安装。但注意,自动安装需要联网,且会增加首次执行的等待时间。
示例 3:生成数据可视化图表
工具调用:
execute_python(
code="""
import matplotlib.pyplot as plt
import numpy as np
# 生成示例数据
x = np.linspace(0, 10, 100)
y1 = np.sin(x)
y2 = np.cos(x)
# 绘制图表
plt.figure(figsize=(10, 6))
plt.plot(x, y1, label='sin(x)', linewidth=2)
plt.plot(x, y2, label='cos(x)', linewidth=2)
plt.xlabel('x')
plt.ylabel('y')
plt.title('Trigonometric Functions')
plt.legend()
plt.grid(True, alpha=0.3)
# 保存图表
plt.savefig('trig_plot.png', dpi=150, bbox_inches='tight')
print("图表已保存到 trig_plot.png")
""",
packages=["matplotlib", "numpy"]
)
常见场景
| 场景 | 需要的包 | 说明 |
|---|---|---|
| 数据处理 | pandas, numpy | CSV/Excel 数据清洗和分析 |
| 数据可视化 | matplotlib, seaborn | 生成统计图表 |
| 文本处理 | re, json, csv | 正则匹配、JSON 解析 |
| 网络请求 | requests | 调用 API 获取数据 |
| 文件操作 | os, shutil, pathlib | 批量文件处理 |
| 科学计算 | scipy, numpy | 数值计算和算法 |
注意事项
注意
- 不要假设包已安装:Hermes 的基础 Python 环境只包含标准库。使用第三方库时,务必在
packages中声明。如果执行时 import 失败,工具会给出清晰的错误提示。- 输出长度限制:
print()的输出如果超过 10,000 字符,会被截断。对于大量数据,建议保存到文件,再用read_file读取。- 状态不持久:每次
execute_python调用都是独立的进程。你在上一次调用中定义的变量,下一次调用时就不存在了。如果需要跨调用保留数据,请写入文件。常见问题
Q: 执行时报 ModuleNotFoundError,但包明明安装了?
A: 每次
execute_python都在新进程中运行。如果上次执行时通过pip install安装了包,下次执行时可能需要重新指定packages参数,或者确保包安装在 Hermes 使用的 Python 环境中。建议始终通过packages参数声明依赖。Q: 如何读取代码执行的结果?
A:
execute_python会把stdout(标准输出)和stderr(标准错误)都返回给 Agent。所以用print()输出结果即可。如果需要返回结构化数据,可以print(json.dumps(result))。
3.2 execute_shell —— 执行 Shell 命令
功能说明
execute_shell 让 Agent 能够运行系统 Shell 命令(bash/zsh)。这是最高风险的工具之一,因为它可以直接操作系统——创建、修改、删除文件,安装软件,甚至执行任意系统命令。
正因为风险高,execute_shell 被归类为高风险操作,每次调用都需要用户审批,且无法配置为自动允许。
参数详解
{
"command": {
"type": "string",
"required": true,
"description": "要执行的 Shell 命令"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "执行超时时间(秒)"
},
"working_dir": {
"type": "string",
"required": false,
"default": ".",
"description": "命令执行的工作目录"
},
"env": {
"type": "object",
"required": false,
"description": "额外的环境变量(会合并到当前环境)"
}
}
使用示例
示例 1:查看当前目录的 Git 状态
工具调用:
execute_shell(command="git status")
返回结果:
On branch main
Your branch is up to date with 'origin/main'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit
示例 2:统计代码行数
工具调用:
execute_shell(command="find src -name '*.py' | xargs wc -l")
返回结果:
156 src/main.py
243 src/utils.py
89 src/models.py
488 total
示例 3:带环境变量的命令
工具调用:
execute_shell(
command="python -c 'import os; print(os.getenv(\"API_KEY\"))'",
env={"API_KEY": "sk-1234567890abcdef"}
)
返回结果:
sk-1234567890abcdef
Tips
对于复杂的 Shell 操作,建议先在终端手动测试命令,确认无误后再让 Agent 执行。尤其是涉及文件删除、系统修改的命令,一定要三思。
安全机制详解
execute_shell 有多层安全防护:
| 安全层 | 机制 | 说明 |
|---|---|---|
| 审批层 | 强制人工确认 | 每次调用都必须用户确认 |
| 黑名单层 | 命令关键字过滤 | 包含 rm -rf /、:(){ :|:& };: 等危险命令直接拒绝 |
| 沙箱层 | 文件系统隔离 | 默认只能在当前工作目录操作 |
| 超时层 | 执行时间限制 | 默认 30 秒超时,防止资源耗尽 |
| 审计层 | 操作日志记录 | 所有命令和输出都会被记录 |
绝对禁止执行的命令示例:
rm -rf / # 删除整个文件系统
rm -rf ~ # 删除用户主目录
mkfs.ext4 /dev/sda # 格式化硬盘
:(){ :|:& };: # Fork 炸弹(耗尽进程数)
dd if=/dev/zero of=/dev/sda # 清零硬盘
注意
即使命令本身看起来无害,组合起来也可能危险。比如
rm -rf /tmp/app是正常的清理操作,但如果working_dir被恶意篡改,实际执行的可能是rm -rf /(利用变量注入)。因此 Hermes 会对命令进行静态分析,检测潜在的危险模式。
常见场景
| 场景 | 命令示例 | 替代方案 |
|---|---|---|
| Git 操作 | git log --oneline -10 |
可使用 run_command(审批更轻量) |
| 包管理 | npm install lodash |
可用,但注意依赖安全 |
| 查看进程 | ps aux \| grep python |
建议使用 process_list 工具 |
| 压缩文件 | tar -czf backup.tar.gz src/ |
可用,建议设置 backup 前缀 |
| 系统信息 | uname -a |
建议使用 system_info 工具 |
常见问题
Q: 为什么某些合法命令也被拒绝了?
A: Hermes 的安全过滤器采用「宁可错杀,不可放过」的策略。如果命令包含危险关键字(如
mkfs、dd if=/dev),即使上下文是安全的,也会被拒绝。遇到这种情况,可以: 1. 尝试用更安全的替代命令 2. 或者手动在终端执行,然后把结果告诉 AgentQ: 如何执行管道命令(如
cat file \| grep pattern)?A: 直接在
command中写完整的管道命令即可。Hermes 的 Shell 执行器支持管道、重定向、命令组合等标准 Shell 语法。
3.3 execute_javascript —— 执行 JavaScript
功能说明
execute_javascript 让 Agent 能够在 Node.js 环境中运行 JavaScript/TypeScript 代码。这对于前端项目分析、JSON 处理、npm 包操作等场景非常有用。
参数详解
{
"code": {
"type": "string",
"required": true,
"description": "要执行的 JavaScript/TypeScript 代码"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "执行超时时间(秒)"
},
"packages": {
"type": "array",
"required": false,
"description": "需要临时安装的 npm 包列表"
},
"working_dir": {
"type": "string",
"required": false,
"default": ".",
"description": "工作目录"
}
}
使用示例
示例 1:处理 JSON 数据
工具调用:
execute_javascript(
code="""
const data = {
users: [
{ name: 'Alice', age: 30, city: 'Beijing' },
{ name: 'Bob', age: 25, city: 'Shanghai' },
{ name: 'Charlie', age: 35, city: 'Beijing' }
]
};
// 按城市分组
const grouped = data.users.reduce((acc, user) => {
acc[user.city] = acc[user.city] || [];
acc[user.city].push(user);
return acc;
}, {});
console.log(JSON.stringify(grouped, null, 2));
"""
)
返回结果:
{
"Beijing": [
{ "name": "Alice", "age": 30, "city": "Beijing" },
{ "name": "Charlie", "age": 35, "city": "Beijing" }
],
"Shanghai": [
{ "name": "Bob", "age": 25, "city": "Shanghai" }
]
}
示例 2:分析 package.json 依赖
工具调用:
execute_javascript(
code="""
const fs = require('fs');
const pkg = JSON.parse(fs.readFileSync('package.json', 'utf8'));
const deps = { ...pkg.dependencies, ...pkg.devDependencies };
const sorted = Object.entries(deps).sort((a, b) => a[0].localeCompare(b[0]));
console.log(`共 ${sorted.length} 个依赖:`);
sorted.forEach(([name, version]) => {
console.log(` ${name}: ${version}`);
});
"""
)
Tips
execute_javascript与execute_python的选择原则:如果项目主要是 Node.js 生态(前端、npm 包),用 JavaScript 更自然;如果是数据科学、后端脚本,用 Python 更合适。对于纯 JSON 处理,两者都可以。
注意事项
注意
- Node.js 版本:Hermes 使用系统默认的 Node.js 版本。如果你需要特定版本,可以在
~/.hermes/config.yaml中配置tools.javascript.node_path。- TypeScript 支持:如果代码以
.ts语法编写(包含类型注解),Hermes 会自动调用ts-node或tsx执行。确保这些工具已全局安装。
3.4 sandbox_run —— 沙箱环境执行
功能说明
sandbox_run 是 Hermes 最安全的代码执行工具。它在完全隔离的容器化沙箱中运行代码,与宿主机系统完全隔离。
沙箱环境的特点:
- 文件系统隔离:沙箱内看不到宿主机的文件(除非显式挂载)
- 网络隔离:默认无网络访问
- 资源限制:CPU、内存、磁盘都有严格配额
- 临时性:沙箱执行完毕后自动销毁,不留痕迹
这个工具非常适合运行不可信代码——比如从互联网下载的脚本、AI 生成的未经审核的代码、第三方提供的示例代码。
参数详解
{
"code": {
"type": "string",
"required": true,
"description": "要执行的代码(Python 或 JavaScript)"
},
"language": {
"type": "string",
"required": false,
"default": "python",
"description": "代码语言:python、javascript"
},
"mounts": {
"type": "array",
"required": false,
"description": "挂载到沙箱的宿主机目录列表"
},
"timeout": {
"type": "integer",
"required": false,
"default": 60,
"description": "执行超时时间(秒)"
},
"memory_limit": {
"type": "integer",
"required": false,
"default": 256,
"description": "内存限制(MB)"
},
"cpu_limit": {
"type": "integer",
"required": false,
"default": 1,
"description": "CPU 核心数限制"
}
}
使用示例
示例 1:运行不可信的 Python 脚本
工具调用:
sandbox_run(
language="python",
code="""
# 这段代码来自互联网,不确定是否安全
# 在沙箱中运行,即使有问题也不会影响主机
import os
print("当前目录:", os.getcwd())
print("文件列表:", os.listdir('.'))
# 尝试访问根目录(沙箱内被限制)
try:
print("根目录:", os.listdir('/'))
except PermissionError as e:
print("权限不足(这是预期的):", e)
""",
mounts=["/tmp/shared_data:/data:ro"] # 只读挂载
)
示例 2:安全的代码评测
工具调用:
sandbox_run(
language="python",
code="""
# 评测用户提交的算法代码
# 提供测试用例,在沙箱中运行
def solution(n):
# 用户提交的代码
return n * n
# 测试用例
test_cases = [(2, 4), (3, 9), (10, 100), (0, 0)]
for input_val, expected in test_cases:
result = solution(input_val)
status = "✓" if result == expected else "✗"
print(f"{status} solution({input_val}) = {result} (期望: {expected})")
""",
timeout=10,
memory_limit=128
)
Tips
当你让 Agent 从网上搜索代码示例并运行时,建议优先使用
sandbox_run而不是execute_python。这样即使代码包含恶意操作(如删除文件、发送网络请求),也会被沙箱隔离,不会危害你的系统。
沙箱限制说明
| 资源 | 默认限制 | 可调范围 | 说明 |
|---|---|---|---|
| 内存 | 256 MB | 64-2048 MB | 超过会被 OOM Kill |
| CPU | 1 核 | 1-4 核 | 限制 CPU 使用率 |
| 磁盘 | 100 MB | 10-1000 MB | 沙箱内可写空间 |
| 网络 | 禁用 | 可开启 | 默认完全隔离 |
| 执行时间 | 60 秒 | 10-300 秒 | 超时强制终止 |
注意
- 沙箱需要 Docker:
sandbox_run依赖 Docker 容器技术。如果你的系统没有安装 Docker,这个工具会报错。在 macOS 和 Linux 上,Docker Desktop 或 Docker Engine 都可以。- 首次启动较慢:创建沙箱容器需要几秒钟。如果需要频繁执行,可以考虑批量提交多个任务。
- 文件持久化:沙箱执行结束后,容器被销毁,内部文件也一并消失。如果需要保留输出,请确保代码将结果写入挂载的宿主机目录。
本章小结
本章我们深入讲解了 4 个代码执行工具:
execute_python:执行 Python 代码,适合数据分析、自动化脚本execute_shell:执行 Shell 命令,功能最强但风险最高,强制审批execute_javascript:执行 JavaScript/TypeScript,适合前端和 Node.js 项目sandbox_run:在隔离沙箱中执行代码,运行不可信代码的首选
安全使用原则:
- 默认用沙箱:不确定安全性的代码,先用
sandbox_run - 最小权限:只给代码执行所需的最小权限(网络、文件访问)
- 超时保护:对于可能死循环的代码,设置合理的
timeout - 审计日志:所有代码执行都有日志记录,定期审查
4. 第三类:Web 交互工具 —— Agent 的「浏览器」和「网络接口」
本章你将学到
- 8 个 Web 交互工具的功能边界和使用场景
- web_search 的高级搜索语法和结果过滤技巧
- web_browse 的浏览器自动化原理和操作示例
- HTTP 请求工具的各种认证方式和错误处理
- RSS 订阅获取和网页变化监控的实战配置
Web 交互工具让 Agent 能够连接到互联网——搜索信息、浏览网页、调用 API、监控变化。这是 Agent 从「本地助手」升级为「联网助手」的关键能力。
4.1 web_search —— 网络搜索
功能说明
web_search 是 Agent 获取实时信息的主要渠道。与 LLM 的「静态知识」不同,web_search 能够获取最新的、动态的、实时的信息——今天的新闻、最新的技术文档、当前的股价。
Hermes 的 web_search 支持多个搜索引擎后端:
- DuckDuckGo:默认后端,无需 API Key,隐私友好
- Google Custom Search:需要 API Key,结果更精准
- Bing Search:需要 API Key,中文搜索效果好
- SearXNG:自建搜索引擎,完全开源可控
参数详解
{
"query": {
"type": "string",
"required": true,
"description": "搜索查询词"
},
"engine": {
"type": "string",
"required": false,
"default": "duckduckgo",
"description": "搜索引擎:duckduckgo、google、bing、searxng"
},
"num_results": {
"type": "integer",
"required": false,
"default": 10,
"description": "返回结果数量(1-50)"
},
"time_range": {
"type": "string",
"required": false,
"description": "时间范围:day、week、month、year"
},
"site": {
"type": "string",
"required": false,
"description": "限制搜索特定网站,如 site:github.com"
},
"safe_search": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否开启安全搜索"
}
}
使用示例
示例 1:基础搜索
工具调用:
web_search(query="Hermes Agent AI framework 2024")
返回结果:
[
{
"title": "Hermes - An open-source AI agent framework",
"url": "https://github.com/NousResearch/hermes",
"snippet": "Hermes is an open-source AI agent framework developed by Nous Research..."
},
{
"title": "Getting Started with Hermes Agent",
"url": "https://docs.hermes.ai/quickstart",
"snippet": "Learn how to install and configure Hermes Agent in 5 minutes..."
}
]
示例 2:限定时间范围的搜索
工具调用:
web_search(
query="OpenAI GPT-5 release",
time_range="week",
num_results=5
)
示例 3:限定特定网站搜索
工具调用:
web_search(
query="machine learning tutorial",
site="arxiv.org",
num_results=10
)
Tips
搜索查询的质量直接影响结果质量。几个提升搜索效果的小技巧: 1. 用英文搜索:技术类内容英文搜索结果通常更好 2. 加关键词限定:如
Python asyncio best practices 2024比Python async更精准 3. 用 site: 限定来源:error solution site:stackoverflow.com4. 用引号精确匹配:"Hermes Agent" framework
搜索语法速查表
| 技巧 | 语法 | 示例 |
|---|---|---|
| 精确短语 | "exact phrase" |
"machine learning" |
| 排除关键词 | -keyword |
Python -snake |
| 限定网站 | site:domain |
site:github.com |
| 文件类型 | filetype:ext |
filetype:pdf |
| 时间范围 | after:YYYY-MM-DD |
after:2024-01-01 |
| OR 条件 | A OR B |
React OR Vue |
| 通配符 | * |
best * framework |
注意事项
注意
- 结果不保证实时:搜索引擎的索引有延迟,最新发布的内容可能需要几小时甚至几天才能被收录。
- API 配额:如果使用 Google 或 Bing 后端,注意 API 调用配额。DuckDuckGo 没有硬配额限制,但频繁请求可能触发反爬虫。
- 结果去重:Hermes 会自动对搜索结果进行去重和排序,优先返回权威来源(如官方文档、知名技术博客)。
常见问题
Q: 搜索返回空结果怎么办?
A: 尝试以下方法: 1. 简化查询词,去掉过于具体的关键词 2. 换用不同的搜索引擎(如从 DuckDuckGo 换到 Bing) 3. 检查网络连接,确认能正常访问搜索引擎 4. 如果是中文搜索,尝试用英文关键词
Q: 如何搜索学术论文?
A: 推荐使用
site:arxiv.org或site:scholar.google.com限定学术来源。或者使用专门的search_paper技能(如果已安装)。
4.2 web_extract —— 提取网页内容
功能说明
web_extract 用于从指定的 URL 提取网页的主要内容。与直接获取原始 HTML 不同,它会智能地去除广告、导航栏、页脚等噪音,只保留文章正文。
这个工具基于 Readability 算法和 AI 内容识别技术,能够从各种网页布局中准确提取核心内容。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "目标网页 URL"
},
"format": {
"type": "string",
"required": false,
"default": "markdown",
"description": "输出格式:markdown、text、html"
},
"max_length": {
"type": "integer",
"required": false,
"default": 10000,
"description": "最大提取字符数"
},
"include_images": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否保留图片链接"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "请求超时时间(秒)"
}
}
使用示例
示例 1:提取技术博客文章
工具调用:
web_extract(
url="https://blog.example.com/intro-to-async-python",
format="markdown",
max_length=5000
)
返回结果:
# Introduction to Async Python
## What is Async?
Asyncio is a library to write concurrent code using...
(提取的文章正文,已去除导航栏、广告、评论区等噪音)
示例 2:提取并保存为文本
工具调用:
web_extract(
url="https://docs.python.org/3/library/asyncio.html",
format="text",
max_length=8000
)
Tips
web_extract+write_file是制作「离线资料包」的经典组合。让 Agent 搜索一系列教程链接,逐个提取内容,然后合并保存为一个 Markdown 文件,你就得到了一份完整的离线学习资料。
注意事项
注意
- 动态内容限制:如果网页内容是通过 JavaScript 动态加载的(如 React/Vue 单页应用),
web_extract可能只能获取到初始 HTML 骨架,看不到动态内容。这种情况下需要使用web_browse工具。- 反爬虫机制:某些网站会检测并阻止自动化访问。如果遇到 403 或验证码,可以尝试:
- 使用
web_browse工具(它使用真实浏览器)- 检查网站的 robots.txt 是否允许爬取
- 减少请求频率
4.3 web_browse —— 浏览器控制
功能说明
web_browse 是 Hermes 最强大的网页交互工具。它控制一个真实的无头浏览器(Headless Browser,基于 Playwright),能够:
- 加载完整的网页(包括 JavaScript 动态内容)
- 模拟点击、滚动、填写表单等用户操作
- 截取网页截图
- 等待特定元素出现
- 在多个页面之间导航
这个工具是 web_extract 的「重武器版」——当简单的 HTTP 请求搞不定时,就派它上场。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "要访问的 URL"
},
"action": {
"type": "string",
"required": false,
"default": "navigate",
"description": "操作类型:navigate、click、type、scroll、wait、screenshot"
},
"selector": {
"type": "string",
"required": false,
"description": "CSS 选择器,用于定位元素(click、type 等操作需要)"
},
"text": {
"type": "string",
"required": false,
"description": "要输入的文本(type 操作需要)"
},
"wait_for": {
"type": "string",
"required": false,
"description": "等待某个选择器出现(如 .content-loaded)"
},
"viewport": {
"type": "object",
"required": false,
"description": "视口大小 {width, height}"
},
"user_agent": {
"type": "string",
"required": false,
"description": "自定义 User-Agent"
}
}
使用示例
示例 1:访问动态加载的网页
工具调用:
web_browse(
url="https://spa-app.example.com/dashboard",
wait_for=".dashboard-content"
)
返回结果:
页面标题: Dashboard - SPA App
页面内容: (渲染后的完整 HTML,包含 JavaScript 动态生成的内容)
示例 2:模拟表单填写和提交
工具调用:
# 第一步:打开登录页
web_browse(url="https://app.example.com/login")
# 第二步:填写用户名
web_browse(
action="type",
selector="input[name='username']",
text="my_username"
)
# 第三步:填写密码
web_browse(
action="type",
selector="input[name='password']",
text="my_password"
)
# 第四步:点击登录按钮
web_browse(
action="click",
selector="button[type='submit']"
)
# 第五步:等待页面加载
web_browse(
action="wait",
wait_for=".welcome-message"
)
Tips
web_browse的浏览器实例在多次调用之间是保持状态的(Cookie、LocalStorage、SessionStorage 都会保留)。这意味着你可以先登录一个网站,然后在后续调用中访问需要登录才能看到的页面。但要注意,如果长时间没有操作,浏览器实例可能会被回收。
操作类型详解
| action | 作用 | 需要 selector | 需要 text |
|---|---|---|---|
| navigate | 打开/刷新页面 | 否 | 否 |
| click | 点击元素 | 是 | 否 |
| type | 在输入框中输入文本 | 是 | 是 |
| scroll | 滚动页面 | 否 | 否 |
| wait | 等待条件满足 | 可选 | 否 |
| screenshot | 截取页面截图 | 可选 | 否 |
| evaluate | 执行 JavaScript | 否 | 是(JS 代码) |
注意事项
注意
- 资源消耗:无头浏览器比普通 HTTP 请求消耗更多内存和 CPU。不要同时打开太多浏览器实例。
- 超时设置:某些网页加载很慢(特别是有大量 JavaScript 的页面)。如果
wait_for的元素一直没出现,工具会超时。可以适当增加timeout参数。- 人机验证:对于需要 CAPTCHA、短信验证的网站,无头浏览器通常无法通过验证。这种情况下需要人工介入。
4.4 web_screenshot —— 网页截图
功能说明
web_screenshot 专门用于截取网页的屏幕截图。虽然 web_browse 也能截图,但 web_screenshot 更加轻量和专注——它不需要维护浏览器会话,截图完就释放资源。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "要截图的网页 URL"
},
"viewport": {
"type": "object",
"required": false,
"default": {"width": 1280, "height": 720},
"description": "视口大小"
},
"full_page": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否截取整个页面(而不仅是视口)"
},
"selector": {
"type": "string",
"required": false,
"description": "只截取某个元素的区域"
},
"output_path": {
"type": "string",
"required": false,
"description": "截图保存路径(默认返回 base64)"
},
"format": {
"type": "string",
"required": false,
"default": "png",
"description": "图片格式:png、jpeg、webp"
}
}
使用示例
示例 1:截取网页全屏
工具调用:
web_screenshot(
url="https://hermes.ai",
full_page=true,
output_path="screenshots/hermes_homepage.png"
)
返回结果:
截图已保存到 screenshots/hermes_homepage.png
文件大小: 1.2 MB
分辨率: 1280x4520
示例 2:截取特定元素
工具调用:
web_screenshot(
url="https://dashboard.example.com",
selector=".chart-container",
output_path="screenshots/chart.png"
)
Tips
web_screenshot返回的截图可以被image_analyze工具分析。这意味着你可以让 Agent「看图说话」——截图一个网页,然后分析它的 UI 设计、数据图表、错误提示等。
4.5 http_request —— HTTP 请求
功能说明
http_request 是一个通用的 HTTP 客户端工具,支持 GET、POST、PUT、DELETE 等所有标准 HTTP 方法。它是调用 REST API、Webhook、微服务的首选工具。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "请求 URL"
},
"method": {
"type": "string",
"required": false,
"default": "GET",
"description": "HTTP 方法:GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS"
},
"headers": {
"type": "object",
"required": false,
"description": "请求头"
},
"body": {
"type": "string",
"required": false,
"description": "请求体(字符串或 JSON 序列化后的字符串)"
},
"params": {
"type": "object",
"required": false,
"description": "URL 查询参数"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "超时时间(秒)"
},
"follow_redirects": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否跟随重定向"
}
}
使用示例
示例 1:GET 请求获取 JSON 数据
工具调用:
http_request(
url="https://api.github.com/repos/NousResearch/hermes",
headers={"Accept": "application/vnd.github.v3+json"}
)
返回结果:
{
"status": 200,
"headers": { ... },
"body": {
"name": "hermes",
"full_name": "NousResearch/hermes",
"stargazers_count": 5234,
"forks_count": 891,
"open_issues_count": 45
}
}
示例 2:POST 请求提交数据
工具调用:
http_request(
url="https://api.example.com/users",
method="POST",
headers={
"Content-Type": "application/json",
"Authorization": "Bearer sk-123456"
},
body='{"name":"Alice","email":"alice@example.com"}'
)
示例 3:带查询参数的搜索请求
工具调用:
http_request(
url="https://api.example.com/search",
params={
"q": "machine learning",
"page": 1,
"limit": 20
}
)
Tips
调用 API 时,建议先用
read_file读取 API 文档(如果有本地文档),或者先用web_search搜索 API 使用说明。错误的请求参数是 API 调用失败的最常见原因。
认证方式示例
| 认证类型 | headers 配置 |
|---|---|
| Bearer Token | {"Authorization": "Bearer YOUR_TOKEN"} |
| Basic Auth | {"Authorization": "Basic base64(user:pass)"} |
| API Key (Header) | {"X-API-Key": "your_key"} |
| API Key (Query) | params={"api_key": "your_key"} |
注意事项
注意
- 敏感信息:不要在
body或headers中硬编码 API Key。建议存储在环境变量中,通过env参数注入。- 响应大小限制:如果响应体超过 1MB,会被截断。对于大文件下载,建议使用
execute_shell配合curl或wget。- SSL 验证:默认开启 SSL 证书验证。如果访问自签名证书的服务器,需要在
~/.hermes/config.yaml中配置tools.http_request.verify_ssl: false。
4.6 rss_fetch —— RSS 订阅获取
功能说明
rss_fetch 用于获取 RSS/Atom 订阅源的内容。这是跟踪博客更新、新闻动态、软件发布的高效方式——不需要手动打开浏览器,Agent 会帮你聚合所有订阅源的更新。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "RSS/Atom 订阅源 URL"
},
"limit": {
"type": "integer",
"required": false,
"default": 20,
"description": "最多返回多少条条目"
},
"since": {
"type": "string",
"required": false,
"description": "只返回某个时间之后的条目(ISO 8601 格式)"
},
"include_content": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否包含条目的完整内容"
}
}
使用示例
示例 1:获取技术博客 RSS
工具调用:
rss_fetch(
url="https://blog.example.com/feed.xml",
limit=5
)
返回结果:
[
{
"title": "Introducing Hermes 2.0",
"link": "https://blog.example.com/hermes-2-0",
"published": "2024-01-10T08:00:00Z",
"author": "Alice Chen",
"summary": "We are excited to announce Hermes 2.0 with...",
"content": "完整文章内容..."
}
]
Tips
rss_fetch+memory_write是构建「个人资讯简报」的经典组合。让 Agent 每天早上拉取你关注的 RSS 源,提取重要信息,写入记忆系统。当你问「最近有什么新闻」时,Agent 就能基于记忆给出个性化回答。
4.7 api_call —— 通用 API 调用
功能说明
api_call 是一个更高级的 API 调用工具,内置了对多种流行 API 的适配器。与 http_request 的「裸 HTTP」不同,api_call 提供了更友好的接口,自动处理认证、分页、错误重试等常见问题。
内置适配器
| 服务 | 适配器名称 | 说明 |
|---|---|---|
| OpenAI | openai |
GPT 模型调用 |
| Anthropic | anthropic |
Claude 模型调用 |
| GitHub | github |
仓库、Issue、PR 操作 |
| Slack | slack |
消息发送 |
| Discord | discord |
Webhook 消息 |
| Notion | notion |
页面、数据库操作 |
| Twitter/X | twitter |
推文操作(需 API Key) |
参数详解
{
"provider": {
"type": "string",
"required": true,
"description": "API 提供商名称"
},
"action": {
"type": "string",
"required": true,
"description": "操作名称,如 send_message、create_issue"
},
"params": {
"type": "object",
"required": false,
"description": "操作参数"
},
"credentials": {
"type": "object",
"required": false,
"description": "认证信息(优先使用配置文件中的凭证)"
}
}
使用示例
示例 1:发送 Slack 消息
工具调用:
api_call(
provider="slack",
action="send_message",
params={
"channel": "#alerts",
"text": "部署完成!版本 v1.2.3 已成功上线。"
}
)
示例 2:创建 GitHub Issue
工具调用:
api_call(
provider="github",
action="create_issue",
params={
"owner": "NousResearch",
"repo": "hermes",
"title": "Bug: Memory leak in long-running sessions",
"body": "描述...",
"labels": ["bug", "memory"]
}
)
Tips
api_call的凭证通常在~/.hermes/credentials.yaml中配置,而不是每次调用都传入。配置格式如下:
yaml credentials: slack: token: "xoxb-your-bot-token" github: token: "ghp-your-personal-access-token" notion: token: "secret_..."
4.8 web_monitor —— 网页变化监控
功能说明
web_monitor 用于监控网页内容的变化。当指定网页的内容发生变化时,Agent 可以收到通知并执行预设的操作。
这是自动化监控的利器——监控竞争对手的价格页面、监控招聘网站的职位更新、监控文档站的 API 变更等。
参数详解
{
"url": {
"type": "string",
"required": true,
"description": "要监控的网页 URL"
},
"selector": {
"type": "string",
"required": false,
"description": "只监控某个 CSS 选择器选中的区域(而不是整个页面)"
},
"interval": {
"type": "integer",
"required": false,
"default": 3600,
"description": "检查间隔(秒),默认 1 小时"
},
"action": {
"type": "string",
"required": false,
"description": "变化时执行的操作:notify、webhook、script"
},
"name": {
"type": "string",
"required": false,
"description": "监控任务的名称"
}
}
使用示例
示例 1:监控文档站的变化
工具调用:
web_monitor(
url="https://docs.hermes.ai/changelog",
selector=".changelog-content",
interval=7200,
name="Hermes Changelog Monitor",
action="notify"
)
示例 2:监控价格页面
工具调用:
web_monitor(
url="https://shop.example.com/product/123",
selector=".price",
interval=3600,
name="Price Monitor - Product 123",
action="webhook"
)
注意事项
注意
- 监控任务持久化:
web_monitor创建的任务会在 Hermes 后台持续运行,即使 Agent 会话结束也不会停止。需要在~/.hermes/monitors/目录下查看和管理所有监控任务。- 频率限制:不要设置过短的检查间隔(如几秒),这会对目标网站造成压力,也可能触发反爬虫机制。建议至少 5 分钟以上的间隔。
- 变化检测算法:默认使用文本相似度算法检测变化。对于动态内容(如时间戳、广告轮播),建议使用
selector限定只监控核心内容区域。
本章小结
本章我们详细讲解了 8 个 Web 交互工具:
web_search:网络搜索,Agent 获取实时信息的主要渠道web_extract:提取网页正文,去除噪音保留核心内容web_browse:控制无头浏览器,处理 JavaScript 动态内容web_screenshot:截取网页截图,支持全屏和元素截图http_request:通用 HTTP 客户端,调用 REST APIrss_fetch:获取 RSS/Atom 订阅源内容api_call:高级 API 调用,内置多种服务适配器web_monitor:监控网页变化,自动化跟踪内容更新
使用建议:
- 信息获取链:
web_search→web_extract→write_file是最常见的信息收集工作流 - API 调用优先用适配器:如果
api_call支持你的目标服务,优先使用它而不是裸http_request - 截图+分析组合:
web_screenshot+image_analyze可以实现「看图说话」 - 监控任务管理:定期检查
~/.hermes/monitors/,清理不再需要的监控任务
5. 第四类:终端命令工具 —— Agent 的「系统管理员」套装
本章你将学到
- 5 个终端命令工具的功能和使用场景
- 危险命令的分级处理机制,理解为什么有些命令需要反复确认
- 后台任务管理和进程控制的完整工作流
- 如何安全地使用系统命令而不破坏环境
run_command与execute_shell的区别和选择策略
终端命令工具让 Agent 能够与你的操作系统直接交互——运行程序、管理进程、获取系统信息。这些工具是 Agent 的「系统管理员」套装,让它从「文件编辑者」升级为「系统操控者」。
5.1 run_command —— 运行系统命令
功能说明
run_command 是 execute_shell 的「轻量版」。它们都执行系统命令,但 run_command 的安全级别更高、审批更轻量。
关键区别:
| 特性 | run_command | execute_shell |
|---|---|---|
| 风险等级 | 中风险 | 高风险 |
| 审批策略 | 可配置为自动允许(白名单内) | 强制每次审批 |
| 命令白名单 | 支持 | 不支持(全部审批) |
| 适用场景 | 日常命令(git、npm、ls) | 复杂/危险操作 |
run_command 的设计思路是:对于常用的、相对安全的命令(如 git status、npm install、python script.py),经过首次确认后可以自动执行,不需要每次都打断用户。
参数详解
{
"command": {
"type": "string",
"required": true,
"description": "要执行的命令"
},
"timeout": {
"type": "integer",
"required": false,
"default": 30,
"description": "超时时间(秒)"
},
"working_dir": {
"type": "string",
"required": false,
"default": ".",
"description": "工作目录"
},
"env": {
"type": "object",
"required": false,
"description": "环境变量"
}
}
使用示例
示例 1:查看 Git 日志
工具调用:
run_command(command="git log --oneline -10")
返回结果:
a1b2c3d feat: add memory search
b2c3d4e fix: handle empty results
c3d4e5f docs: update API reference
d4e5f6a test: add unit tests for tools
e5f6a7b chore: bump version to 2.1.0
f6a7b8c refactor: simplify registry logic
g7h8i9d fix: race condition in sandbox
h8i9j0e feat: support custom user agents
i9j0k1f docs: add Chinese translation
j0k1l2g chore: update dependencies
示例 2:运行测试套件
工具调用:
run_command(command="pytest tests/ -v", timeout=120)
返回结果:
============================= test session starts ==============================
platform darwin -- Python 3.11.0
pytest-7.4.0
tests/test_file_tools.py::test_read_file PASSED
tests/test_file_tools.py::test_write_file PASSED
tests/test_web_tools.py::test_web_search PASSED
============================== 3 passed in 2.34s ===============================
示例 3:安装依赖
工具调用:
run_command(command="npm install lodash axios")
返回结果:
added 2 packages in 1.2s
Tips
在日常开发中,优先使用
run_command而不是execute_shell。只有当你需要执行白名单之外的复杂命令时,才使用execute_shell。这样既能享受自动化带来的便利,又能保持较高的安全性。
白名单配置
你可以在配置文件中定义 run_command 的白名单:
# ~/.hermes/config.yaml
tools:
run_command:
whitelist:
- "git"
- "npm"
- "pip"
- "pytest"
- "python"
- "node"
- "ls"
- "cat"
- "echo"
- "mkdir"
# 白名单内命令的策略
whitelist_strategy: "remember" # 首次确认后记住
# 白名单外命令的策略
non_whitelist_strategy: "prompt" # 每次都提示
注意事项
注意
- 命令注入风险:不要在
command中拼接用户输入的内容。如果必须拼接,要对特殊字符进行转义。比如command=f"grep {user_input} file.txt"中,如果user_input是"; rm -rf /;",就会导致灾难。- 长命令处理:如果命令输出很长(如
find / -name "*.log"),建议重定向到文件,然后用read_file读取,而不是直接输出。
5.2 background_task —— 后台任务管理
功能说明
background_task 用于在后台启动和管理长时间运行的任务。与同步执行的工具不同,后台任务启动后不会阻塞 Agent,Agent 可以继续执行其他操作,稍后检查任务状态。
典型使用场景:
- 启动一个开发服务器(如
npm run dev) - 运行耗时的数据批处理任务
- 启动日志监控进程
- 执行定时备份脚本
参数详解
{
"action": {
"type": "string",
"required": true,
"description": "操作:start、stop、status、list"
},
"task_id": {
"type": "string",
"required": false,
"description": "任务 ID(start 时自动生成,其他操作需要)"
},
"command": {
"type": "string",
"required": false,
"description": "要启动的命令(action=start 时需要)"
},
"working_dir": {
"type": "string",
"required": false,
"description": "工作目录"
},
"env": {
"type": "object",
"required": false,
"description": "环境变量"
},
"auto_restart": {
"type": "boolean",
"required": false,
"default": false,
"description": "任务崩溃后是否自动重启"
}
}
使用示例
示例 1:启动后台开发服务器
工具调用:
background_task(
action="start",
command="npm run dev",
working_dir="./my-app",
task_id="dev-server"
)
返回结果:
任务已启动
任务 ID: dev-server
PID: 12345
状态: running
启动时间: 2024-01-15 10:30:00
示例 2:查看后台任务状态
工具调用:
background_task(action="status", task_id="dev-server")
返回结果:
任务 ID: dev-server
命令: npm run dev
PID: 12345
状态: running
运行时间: 15 分钟
CPU: 2.3%
内存: 128 MB
最近输出: [10:45:00] Compiled successfully in 234ms
示例 3:列出所有后台任务
工具调用:
background_task(action="list")
返回结果:
┌─────────────┬────────────────┬─────────┬──────────┐
│ 任务 ID │ 命令 │ 状态 │ 运行时间 │
├─────────────┼────────────────┼─────────┼──────────┤
│ dev-server │ npm run dev │ running │ 15m │
│ log-monitor │ tail -f app.log│ running │ 2h │
│ backup-job │ python backup.py│ stopped │ - │
└─────────────┴────────────────┴─────────┴──────────┘
示例 4:停止后台任务
工具调用:
background_task(action="stop", task_id="dev-server")
返回结果:
任务 dev-server 已停止(发送 SIGTERM)
退出码: 0
运行总时长: 18 分钟
Tips
后台任务的输出会被保存到
~/.hermes/tasks/<task_id>.log。如果任务输出异常或崩溃,可以用read_file查看日志文件排查问题。
注意事项
注意
- 任务持久性:后台任务在 Hermes 进程退出后不会自动保留。如果需要真正的守护进程,建议使用系统的 systemd、launchd 或 pm2 等工具。
- 资源限制:每个后台任务默认有资源限制(CPU 50%、内存 512MB)。超过限制的任务会被强制终止。
- 端口冲突:如果后台任务需要监听端口(如开发服务器),确保端口没有被其他进程占用。
5.3 process_list —— 进程列表
功能说明
process_list 用于查看当前系统运行的进程列表。它是 ps 或 tasklist 命令的封装,但提供了更友好的输出格式和过滤功能。
参数详解
{
"filter": {
"type": "string",
"required": false,
"description": "按名称过滤进程"
},
"sort_by": {
"type": "string",
"required": false,
"default": "cpu",
"description": "排序方式:cpu、memory、pid、name"
},
"limit": {
"type": "integer",
"required": false,
"default": 50,
"description": "最多返回多少条"
}
}
使用示例
示例 1:查看所有进程
工具调用:
process_list()
返回结果:
┌───────┬────────────────┬────────┬──────────┬──────────┐
│ PID │ 名称 │ CPU% │ 内存(MB) │ 用户 │
├───────┼────────────────┼────────┼──────────┼──────────┤
│ 1234 │ hermes-agent │ 5.2 │ 256 │ jwangkun │
│ 5678 │ node │ 12.3 │ 128 │ jwangkun │
│ 9012 │ python │ 2.1 │ 64 │ jwangkun │
└───────┴────────────────┴────────┴──────────┴──────────┘
示例 2:查找特定进程
工具调用:
process_list(filter="hermes")
返回结果:
┌───────┬────────────────┬────────┬──────────┐
│ PID │ 名称 │ CPU% │ 内存(MB) │
├───────┼────────────────┼────────┼──────────┤
│ 1234 │ hermes-agent │ 5.2 │ 256 │
│ 1235 │ hermes-sandbox │ 1.0 │ 64 │
└───────┴────────────────┴────────┴──────────┘
Tips
当你觉得系统卡顿或某个程序无响应时,先用
process_list(sort_by="cpu")查看哪些进程占用了大量 CPU 资源。这是排查系统性能问题的第一步。
5.4 kill_process —— 终止进程
功能说明
kill_process 用于终止指定的进程。这是高风险操作,因为终止错误的进程可能导致数据丢失或系统不稳定。
参数详解
{
"pid": {
"type": "integer",
"required": false,
"description": "进程 PID"
},
"name": {
"type": "string",
"required": false,
"description": "进程名称(会终止所有匹配的进程)"
},
"signal": {
"type": "string",
"required": false,
"default": "SIGTERM",
"description": "发送的信号:SIGTERM(优雅终止)、SIGKILL(强制终止)"
},
"force": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否强制终止(相当于 SIGKILL)"
}
}
使用示例
示例 1:通过 PID 终止进程
工具调用:
kill_process(pid=5678)
返回结果:
进程 5678 已发送 SIGTERM 信号
等待进程退出中...
进程已优雅退出
示例 2:强制终止卡死的进程
工具调用:
kill_process(pid=5678, force=true)
返回结果:
进程 5678 已强制终止(SIGKILL)
注意
kill_process默认发送SIGTERM(优雅终止信号),给进程一个清理资源的机会。如果进程无响应,再使用force=true发送SIGKILL(强制终止)。直接强制终止可能导致数据损坏,尤其是数据库进程。
信号说明
| 信号 | 名称 | 作用 |
|---|---|---|
| SIGTERM | 终止 | 请求进程优雅退出(可被捕获) |
| SIGKILL | 强制终止 | 立即终止,无法被捕获或忽略 |
| SIGINT | 中断 | 相当于按 Ctrl+C |
5.5 system_info —— 系统信息获取
功能说明
system_info 用于获取当前系统的硬件和软件信息。这是诊断环境问题、确认系统配置、检查资源使用情况的便捷工具。
参数详解
{
"category": {
"type": "string",
"required": false,
"description": "信息类别:all、os、cpu、memory、disk、network、python"
}
}
使用示例
示例 1:获取完整系统信息
工具调用:
system_info()
返回结果:
{
"os": {
"platform": "darwin",
"release": "23.0.0",
"version": "Darwin Kernel Version 23.0.0",
"machine": "arm64",
"node": "MacBook-Pro.local"
},
"cpu": {
"cores": 10,
"threads": 10,
"architecture": "arm64",
"usage_percent": 15.3
},
"memory": {
"total_gb": 32.0,
"available_gb": 18.5,
"used_gb": 13.5,
"usage_percent": 42.2
},
"disk": {
"total_gb": 500.0,
"free_gb": 230.0,
"usage_percent": 54.0
},
"network": {
"hostname": "MacBook-Pro.local",
"interfaces": [
{"name": "en0", "ip": "192.168.1.100"}
]
},
"python": {
"version": "3.11.4",
"executable": "/opt/homebrew/bin/python3",
"pip_packages": 245
}
}
示例 2:只查看内存信息
工具调用:
system_info(category="memory")
返回结果:
内存总量: 32.0 GB
可用内存: 18.5 GB
已用内存: 13.5 GB
使用率: 42.2%
Tips
当你遇到「安装失败」「内存不足」「磁盘满了」等环境问题时,
system_info是最快的诊断工具。几秒钟内就能看到系统的全貌,避免盲目猜测。
注意事项
注意
- 隐私信息:
system_info不会返回敏感信息(如密码、密钥、详细的网络拓扑),但会返回主机名、IP 地址等基本信息。如果你在共享环境中使用,注意这些信息可能暴露你的身份。- 动态数据:CPU 使用率和内存使用率是实时数据,每次调用都会变化。
本章小结
本章我们讲解了 5 个终端命令工具:
run_command:运行系统命令,安全轻量,支持白名单background_task:后台任务管理,启动、停止、监控长时间运行的任务process_list:查看系统进程列表,支持过滤和排序kill_process:终止进程,高风险操作,默认优雅终止system_info:获取系统硬件和软件信息
安全使用原则:
- 优先用 run_command:日常命令用它,只有白名单外的复杂命令才用 execute_shell
- 终止前三思:kill_process 前先用 process_list 确认目标
- 后台任务监控:定期检查 background_task list,防止僵尸任务占用资源
- 环境诊断:遇到问题时,先 system_info 了解全局,再针对性排查
6. 第五类:记忆管理工具 —— Agent 的「笔记本」和「档案馆」
本章你将学到
- 6 个记忆管理工具的完整用法
- 会话记忆与持久记忆的读写区别
- FTS5 全文索引的查询语法和高级用法
- 记忆的隐私保护和清理策略
- 如何构建高效的「记忆-检索-更新」工作流
记忆管理工具让 Agent 能够读写、搜索、管理自己的记忆系统。在第七册中,我们已经深入了解了 Hermes 的三层记忆架构。本章我们将从「工具使用」的角度,讲解如何操作这些记忆。
6.1 memory_read —— 读取记忆
功能说明
memory_read 用于读取 Agent 的记忆内容。它可以读取不同类型的记忆文件,包括:
- 会话记忆(热记忆):当前对话的上下文
- 持久记忆(温记忆):
MEMORY.md和USER.md中的内容 - 检索记忆(冷记忆):SQLite 数据库中的历史记录
参数详解
{
"memory_type": {
"type": "string",
"required": true,
"description": "记忆类型:session、persistent、retrieval、all"
},
"key": {
"type": "string",
"required": false,
"description": "记忆的键名(读取特定条目)"
},
"limit": {
"type": "integer",
"required": false,
"default": 50,
"description": "最多返回多少条"
}
}
使用示例
示例 1:读取持久记忆
工具调用:
memory_read(memory_type="persistent")
返回结果:
# MEMORY.md
## 用户偏好
- 编程语言: Python、TypeScript
- 编辑器: VS Code
- 主题: Dark+
## 项目上下文
- 当前项目: Hermes 白皮书编写
- 技术栈: Markdown、Python
- 最近文件: 09-47个内置工具全解.md
示例 2:读取特定键的记忆
工具调用:
memory_read(memory_type="persistent", key="用户偏好")
返回结果:
- 编程语言: Python、TypeScript
- 编辑器: VS Code
- 主题: Dark+
Tips
在长时间对话中,Agent 的上下文可能被新的对话内容挤出。使用
memory_read可以主动回顾之前的记忆,避免「失忆」。比如你可以说:「你还记得我刚才提到的那个想法吗?」Agent 就会用memory_read去查找。
注意事项
注意
- 隐私边界:
memory_read只能读取当前 Agent 实例的记忆,不能访问其他 Agent 或用户的记忆。- 记忆层级:
all会返回所有类型的记忆,但可能会很长。建议指定具体的memory_type。
6.2 memory_write —— 写入记忆
功能说明
memory_write 用于向 Agent 的记忆系统写入新的信息。这是 Agent「学习」用户偏好、记录重要事件、保存中间成果的主要方式。
参数详解
{
"memory_type": {
"type": "string",
"required": true,
"description": "记忆类型:session、persistent、retrieval"
},
"key": {
"type": "string",
"required": true,
"description": "记忆的键名"
},
"value": {
"type": "string",
"required": true,
"description": "记忆的内容"
},
"tags": {
"type": "array",
"required": false,
"description": "标签,用于分类和搜索"
},
"overwrite": {
"type": "boolean",
"required": false,
"default": false,
"description": "如果键已存在,是否覆盖"
}
}
使用示例
示例 1:记录用户偏好
工具调用:
memory_write(
memory_type="persistent",
key="用户偏好.编程风格",
value="喜欢使用类型注解,偏好函数式编程风格,注释使用中文",
tags=["preference", "coding"]
)
返回结果:
记忆已写入
位置: ~/.hermes/memories/persistent.json
键: 用户偏好.编程风格
示例 2:保存中间成果到会话记忆
工具调用:
memory_write(
memory_type="session",
key="分析结果.用户画像",
value="用户是后端开发工程师,熟悉 Python 和 Go,对 AI Agent 感兴趣"
)
Tips
memory_write是构建个性化 Agent 体验的核心。每次 Agent 了解到关于你的新信息(喜欢的技术栈、工作习惯、项目背景),都应该写入持久记忆。这样下次对话时,Agent 就能「记得」你是谁,不用每次都重新介绍。
注意事项
注意
- 键名规范:建议使用层级键名(如
用户偏好.编辑器、项目.当前任务),这样便于组织和管理。- 内容长度:单条记忆建议不超过 2000 字符。过长的内容应该拆分成多条记忆,或者保存为文件后只把文件路径记入记忆。
- 敏感信息:不要在记忆中写入密码、API Key 等敏感信息。记忆文件虽然存储在本地,但仍有被意外泄露的风险。
6.3 memory_update —— 更新记忆
功能说明
memory_update 用于修改已有的记忆条目。与 memory_write 的「覆盖」不同,memory_update 提供了更精细的更新能力——可以追加内容、修改特定字段、或者基于旧内容生成新内容。
参数详解
{
"memory_type": {
"type": "string",
"required": true,
"description": "记忆类型"
},
"key": {
"type": "string",
"required": true,
"description": "要更新的键名"
},
"operation": {
"type": "string",
"required": false,
"default": "replace",
"description": "操作类型:replace、append、prepend、merge"
},
"value": {
"type": "string",
"required": true,
"description": "新的值或追加的内容"
}
}
使用示例
示例 1:追加内容到现有记忆
工具调用:
memory_update(
memory_type="persistent",
key="用户偏好.编程风格",
operation="append",
value=",不喜欢使用全局变量"
)
返回结果:
更新前: 喜欢使用类型注解,偏好函数式编程风格,注释使用中文
更新后: 喜欢使用类型注解,偏好函数式编程风格,注释使用中文,不喜欢使用全局变量
示例 2:合并结构化数据
工具调用:
memory_update(
memory_type="persistent",
key="项目配置",
operation="merge",
value='{"python_version": "3.11", "framework": "FastAPI"}'
)
Tips
operation="append"特别适合记录「时间线」类的信息。比如记录项目里程碑、学习进度、待办事项列表等。每次有新进展就 append,而不是覆盖整个列表。
6.4 memory_delete —— 删除记忆
功能说明
memory_delete 用于删除记忆系统中的条目。这是需要审批的操作,因为误删记忆可能导致 Agent「遗忘」重要信息。
参数详解
{
"memory_type": {
"type": "string",
"required": true,
"description": "记忆类型"
},
"key": {
"type": "string",
"required": true,
"description": "要删除的键名"
},
"confirm": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否确认删除(防止误操作)"
}
}
使用示例
工具调用:
memory_delete(
memory_type="persistent",
key="临时信息.旧项目配置",
confirm=true
)
返回结果:
记忆已删除
键: 临时信息.旧项目配置
注意
删除操作不可逆!建议删除前先
memory_read确认内容。对于不确定是否还需要的内容,可以先把键改为已归档.原键名,而不是直接删除。
6.5 memory_search —— 搜索历史记忆
功能说明
memory_search 是 Agent 的「记忆搜索引擎」。它在 SQLite + FTS5 全文索引上执行搜索,能够快速找到与查询相关的历史记忆。
这是第七册中讲解的「检索记忆(冷记忆)」的主要操作接口。
参数详解
{
"query": {
"type": "string",
"required": true,
"description": "搜索查询词"
},
"memory_type": {
"type": "string",
"required": false,
"description": "限制搜索的记忆类型"
},
"limit": {
"type": "integer",
"required": false,
"default": 10,
"description": "最多返回多少条"
},
"tags": {
"type": "array",
"required": false,
"description": "按标签过滤"
}
}
使用示例
示例 1:基础搜索
工具调用:
memory_search(query="Python 项目配置")
返回结果:
[
{
"key": "项目.Hermes配置",
"value": "Python 3.11,使用 Poetry 管理依赖...",
"relevance": 0.92,
"tags": ["project", "python"]
},
{
"key": "用户偏好.编程语言",
"value": "主要使用 Python 和 TypeScript...",
"relevance": 0.78,
"tags": ["preference"]
}
]
示例 2:按标签过滤搜索
工具调用:
memory_search(query="配置", tags=["project"], limit=5)
FTS5 全文索引查询语法
memory_search 底层使用 SQLite 的 FTS5 扩展,支持丰富的查询语法:
| 语法 | 说明 | 示例 |
|---|---|---|
| 普通词 | 包含任意一个词 | python web |
| 短语 | 精确短语匹配 | "machine learning" |
| AND | 同时包含 | python AND web |
| OR | 包含任意一个 | python OR javascript |
| NOT | 排除 | python NOT snake |
| 前缀 | 前缀匹配 | dev* 匹配 developer、development |
| NEAR | 邻近搜索 | python NEAR/5 web(距离5个词以内) |
Tips
当你说「我之前跟你提过……」但记不清具体内容时,Agent 会用
memory_search去查找。为了搜索效果更好,建议在写入记忆时使用清晰、描述性的键名和内容。比如用项目.Hermes部署问题而不是memo_001。
6.6 session_search —— 搜索历史会话
功能说明
session_search 用于搜索历史会话记录。与 memory_search 搜索「记忆条目」不同,session_search 搜索的是「完整的对话历史」。
这是找回「之前某次对话中说过的某句话」的利器。
参数详解
{
"query": {
"type": "string",
"required": true,
"description": "搜索查询词"
},
"time_range": {
"type": "string",
"required": false,
"description": "时间范围:today、week、month、all"
},
"limit": {
"type": "integer",
"required": false,
"default": 10,
"description": "最多返回多少条会话"
}
}
使用示例
工具调用:
session_search(query="Docker 部署", time_range="week")
返回结果:
[
{
"session_id": "sess_20240110_143022",
"timestamp": "2024-01-10 14:30:22",
"preview": "用户: 怎么在 Docker 里部署 Hermes?\nAgent: 部署 Hermes 到 Docker 的步骤如下...",
"relevance": 0.95
},
{
"session_id": "sess_20240108_092145",
"timestamp": "2024-01-08 09:21:45",
"preview": "用户: Docker Compose 配置有问题\nAgent: 让我看看你的 docker-compose.yml...",
"relevance": 0.82
}
]
Tips
session_search的结果会显示会话预览,但不会返回完整的对话内容。如果你想回顾完整的某次会话,可以记下session_id,然后使用hermes session show <session_id>命令查看。
本章小结
本章我们讲解了 6 个记忆管理工具:
memory_read:读取记忆,支持会话、持久、检索三种类型memory_write:写入记忆,记录用户偏好和上下文信息memory_update:更新记忆,支持替换、追加、前置、合并四种操作memory_delete:删除记忆,需要确认防止误删memory_search:搜索历史记忆,基于 FTS5 全文索引session_search:搜索历史会话,找回之前的对话内容
记忆管理最佳实践:
- 结构化键名:使用层级键名(如
用户偏好.编辑器)便于组织 - 打标签:写入时添加
tags,搜索时可以通过标签快速过滤 - 定期清理:过期或不再相关的记忆及时删除,保持记忆库精简
- 敏感信息隔离:密码、API Key 等敏感信息不要存入记忆
7. 第六类:技能管理工具 —— Agent 的「技能学院」管理员
本章你将学到
- 6 个技能管理工具的完整用法
- Skill 文件的格式规范和路径约定
- 从 Skills Hub 浏览、安装、更新技能的完整流程
- 技能版本管理和冲突解决
- 自定义技能的创建和调试方法
技能管理工具让 Agent 能够管理自己的「技能库」——创建新技能、查看已有技能、更新技能内容、安装社区技能。这是 Skill 系统的「元操作」工具集。
7.1 skill_create —— 创建技能
功能说明
skill_create 用于创建新的 Skill 文件。在第八册中,我们了解到 Skill 是存放在 ~/.hermes/skills/<name>/SKILL.md 路径下的 Markdown 文件。skill_create 工具就是程序化创建这个文件的方式。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "技能名称(只能包含字母、数字、连字符、下划线)"
},
"content": {
"type": "string",
"required": true,
"description": "SKILL.md 的完整内容"
},
"overwrite": {
"type": "boolean",
"required": false,
"default": false,
"description": "如果技能已存在,是否覆盖"
}
}
使用示例
示例 1:创建一个简单的代码审查技能
工具调用:
skill_create(
name="code-review-helper",
content='''# Code Review Helper
## 触发条件
用户要求审查代码或提到 "review"、"代码审查"、"CR"
## 执行步骤
1. 使用 `read_file` 读取目标文件内容
2. 检查以下方面:
- 代码风格和命名规范
- 潜在的安全问题(如 SQL 注入、XSS)
- 性能问题(如 N+1 查询、不必要的循环)
- 错误处理是否完善
3. 生成审查报告,使用 `write_file` 保存到 `reviews/` 目录
## 输出格式
```markdown
# 代码审查报告
## 文件: {filename}
### 发现的问题
1. **[级别]** 问题描述
- 位置: 第 X 行
- 建议: 修复方案
### 总体评价
(优良中差评级和总结)
示例
输入: "帮我审查一下 src/auth.py" 输出: 生成 src/auth.py 的详细审查报告 ''' )
返回结果: 技能已创建 路径: ~/.hermes/skills/code-review-helper/SKILL.md 大小: 1.2 KB
> **Tips**
>
> 创建技能时,`content` 参数就是 SKILL.md 的完整内容。建议在 Agent 内部先写好内容,确认格式正确后再调用 `skill_create`。你也可以先用 `write_file` 把内容写到临时文件,确认无误后再用 `skill_create` 正式创建。
#### Skill 文件格式要求
一个有效的 SKILL.md 必须包含以下部分:
```markdown
# 技能名称
## 触发条件
(描述什么情况下触发这个技能)
## 执行步骤
(具体的操作步骤,可以包含工具调用)
## 输出格式
(期望的输出格式)
## 示例
(输入输出示例)
注意
- 名称规范:技能名称只能包含小写字母、数字、连字符(-)和下划线(_)。不要包含空格或特殊字符。
- 路径安全:
skill_create只能创建到~/.hermes/skills/目录下,不能写入系统其他位置。- 语法检查:创建后 Hermes 会自动验证 SKILL.md 的格式。如果缺少必要章节,会给出警告。
7.2 skill_read —— 查看技能
功能说明
skill_read 用于读取已安装技能的内容。这在查看技能的触发条件、学习技能的使用方法、调试技能问题时非常有用。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "技能名称"
}
}
使用示例
工具调用:
skill_read(name="code-review-helper")
返回结果:
# Code Review Helper
## 触发条件
用户要求审查代码或提到 "review"、"代码审查"、"CR"
## 执行步骤
...
Tips
当你不确定某个技能具体会做什么时,用
skill_read查看它的完整内容。这比让 Agent 「试试看」更安全——你能提前知道技能会调用哪些工具、会修改哪些文件。
7.3 skill_update —— 更新技能
功能说明
skill_update 用于修改已有技能的内容。与 skill_create 的「全量覆盖」不同,skill_update 支持基于差异的局部更新。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "技能名称"
},
"content": {
"type": "string",
"required": true,
"description": "新的完整内容(覆盖)或差异片段"
},
"mode": {
"type": "string",
"required": false,
"default": "replace",
"description": "更新模式:replace(全量替换)、patch(差异补丁)"
}
}
使用示例
示例 1:全量更新技能
工具调用:
skill_update(
name="code-review-helper",
mode="replace",
content="新的完整 SKILL.md 内容..."
)
示例 2:局部更新(追加执行步骤)
工具调用:
skill_update(
name="code-review-helper",
mode="patch",
content='''--- 原内容
2. 检查以下方面:
- 代码风格和命名规范
- 潜在的安全问题
--- 新内容
2. 检查以下方面:
- 代码风格和命名规范
- 潜在的安全问题
- 类型注解是否完善(Python)
- 测试覆盖率
'''
)
注意
更新技能前,建议先用
skill_read读取当前内容,确认你要修改的部分。更新后,新内容会立即生效——下一次 Agent 匹配到触发条件时,就会使用更新后的版本。
7.4 skill_delete —— 删除技能
功能说明
skill_delete 用于删除已安装的技能。这是需要审批的操作,因为删除后技能无法恢复(除非重新安装或重新创建)。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "技能名称"
},
"confirm": {
"type": "boolean",
"required": false,
"default": false,
"description": "确认删除"
}
}
使用示例
工具调用:
skill_delete(name="old-experiment-skill", confirm=true)
返回结果:
技能已删除
名称: old-experiment-skill
路径: ~/.hermes/skills/old-experiment-skill/
备份: ~/.hermes/skills/.deleted/old-experiment-skill-20240115.bak
注意
删除操作会创建备份(存放在
~/.hermes/skills/.deleted/)。如果你误删了技能,可以从备份恢复。备份保留 30 天后自动清理。
7.5 skill_list —— 列出所有技能
功能说明
skill_list 用于查看当前已安装的所有技能。它会显示技能的名称、来源、信任等级、最近使用时间等信息。
参数详解
{
"filter": {
"type": "string",
"required": false,
"description": "按来源过滤:built-in、official、trusted、community、all"
},
"search": {
"type": "string",
"required": false,
"description": "按名称关键词搜索"
}
}
使用示例
示例 1:列出所有技能
工具调用:
skill_list()
返回结果:
┌────────────────────────┬───────────┬──────────┬──────────────┐
│ 技能名称 │ 来源 │ 信任等级 │ 最近使用 │
├────────────────────────┼───────────┼──────────┼──────────────┤
│ web-search-helper │ built-in │ 内置 │ 10 分钟前 │
│ code-review-helper │ local │ 本地 │ 2 小时前 │
│ gstack │ community │ 可信 │ 昨天 │
│ llm-wiki │ community │ 可信 │ 3 天前 │
│ manim │ community │ 官方 │ 上周 │
└────────────────────────┴───────────┴──────────┴──────────────┘
总计: 47 个技能
示例 2:只列出社区技能
工具调用:
skill_list(filter="community")
Tips
定期运行
skill_list清理不再使用的技能。技能文件虽然不大,但过多技能会影响 Agent 的匹配效率——每次用户输入时,Agent 都要在所有技能的触发条件中搜索匹配项。
7.6 skill_install —— 从 Hub 安装技能
功能说明
skill_install 用于从 Skills Hub(技能市场)安装社区技能。Skills Hub 是一个集中的技能仓库,包含 700+ 个社区贡献的技能。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "技能名称或 Hub ID"
},
"version": {
"type": "string",
"required": false,
"description": "指定版本号,默认安装最新版"
},
"source": {
"type": "string",
"required": false,
"default": "hub",
"description": "安装来源:hub、github、local"
},
"trust_level": {
"type": "string",
"required": false,
"description": "安装后设置的信任等级"
}
}
使用示例
示例 1:从 Hub 安装技能
工具调用:
skill_install(name="gstack")
返回结果:
正在从 Skills Hub 安装 gstack...
✓ 下载 SKILL.md
✓ 下载依赖文件
✓ 验证签名
✓ 安装完成
安装路径: ~/.hermes/skills/gstack/
版本: 1.3.2
作者: @alice_dev
信任等级: 可信(已验证签名)
示例 2:从 GitHub 安装技能
工具调用:
skill_install(
name="my-custom-skill",
source="github",
version="v2.0.0"
)
示例 3:安装本地技能包
工具调用:
skill_install(
name="company-internal-skill",
source="local",
version="1.0.0"
)
Tips
安装社区技能前,建议先查看技能的信任等级和评分。Hub 上的技能分为四个等级:内置(built-in)、官方(official)、可信(trusted)、社区(community)。对于「社区」等级的技能,建议先
skill_read查看内容,确认安全后再使用。
信任等级说明
| 等级 | 标识 | 说明 |
|---|---|---|
| 内置 | 🏛️ | Hermes 核心团队维护,随安装包分发 |
| 官方 | ✅ | 经过官方审核,从官方仓库安装 |
| 可信 | 🔒 | 签名验证通过,来自可信作者 |
| 社区 | 👥 | 社区贡献,未经过严格审核 |
注意
- 网络要求:从 Hub 安装需要网络连接。如果处于离线环境,可以手动下载技能文件放到
~/.hermes/skills/目录下。- 依赖安装:某些技能有额外的依赖(如 Python 包、Node.js 包)。
skill_install会自动安装这些依赖,但可能需要你的确认。- 版本冲突:如果已安装同名技能,
skill_install默认会报错。可以使用overwrite=true强制覆盖。
本章小结
本章我们讲解了 6 个技能管理工具:
skill_create:创建新技能,编写 SKILL.md 文件skill_read:查看技能内容,了解触发条件和执行步骤skill_update:更新技能,支持全量替换和差异补丁skill_delete:删除技能,自动创建备份skill_list:列出所有已安装技能,支持过滤和搜索skill_install:从 Skills Hub 安装社区技能
技能管理最佳实践:
- 命名规范:技能名称使用小写字母和连字符,如
code-review-helper - 信任等级:安装社区技能前查看信任等级,不安全的技能不要安装
- 定期清理:删除不再使用的技能,保持技能库精简
- 版本管理:重要技能更新前先用
skill_read备份旧版本
8. 第七类:代理委托工具 —— 多 Agent 协作的「调度中心」
本章你将学到
- 5 个代理委托工具的功能和使用场景
- 多 Agent 并发编排的实际案例
- 最多 3 个子 Agent 并行的限制原因和应对策略
- 子 Agent 间的通信机制和状态同步
- 委托任务的拆分粒度和最佳实践
代理委托工具是 Hermes 最高阶的工具类别。它们让单个 Agent 能够「分身」——创建多个子 Agent,各自执行不同的子任务,最后汇总结果。这是处理复杂任务、实现并行计算、模拟团队协作的核心能力。
8.1 delegate_task —— 委托子任务
功能说明
delegate_task 是代理委托系统的核心工具。它允许当前 Agent(称为「主 Agent」或「Parent」)将一个子任务分配给另一个 Agent(称为「子 Agent」或「Child」)执行。
委托的工作流程:
- 主 Agent 分析任务,决定可以拆分成哪些子任务
- 主 Agent 调用
delegate_task,指定子任务的描述和目标 - Hermes 创建或复用子 Agent,分配任务
- 子 Agent 独立执行,使用自己的工具链
- 子 Agent 完成后,结果返回给主 Agent
- 主 Agent 汇总所有子任务的结果,生成最终输出
参数详解
{
"task": {
"type": "string",
"required": true,
"description": "子任务的详细描述"
},
"context": {
"type": "string",
"required": false,
"description": "传递给子任务的上下文信息"
},
"agent_id": {
"type": "string",
"required": false,
"description": "指定子 Agent ID(不指定则自动创建)"
},
"timeout": {
"type": "integer",
"required": false,
"default": 300,
"description": "子任务超时时间(秒)"
},
"required_tools": {
"type": "array",
"required": false,
"description": "子 Agent 需要的工具列表"
}
}
使用示例
示例 1:委托代码审查子任务
主 Agent 思考:
用户要求我审查 5 个文件的代码。我可以并行委托给多个子 Agent,
每个审查一个文件,最后汇总结果。
工具调用:
delegate_task(
task="审查 src/auth.py 的代码质量和安全性",
context="项目使用 Python 3.11 + FastAPI,关注 SQL 注入和 JWT 安全问题",
required_tools=["read_file", "write_file"]
)
delegate_task(
task="审查 src/models.py 的数据模型设计",
context="项目使用 SQLAlchemy ORM,关注模型关系和性能",
required_tools=["read_file", "write_file"]
)
返回结果:
子任务 1 完成:
- 发现 2 个安全问题
- 发现 1 个性能问题
子任务 2 完成:
- 数据模型设计良好
- 建议添加索引优化
Tips
委托任务时,
task描述越详细,子 Agent 的执行效果越好。不要只写「审查代码」,而要写「审查 src/auth.py 的认证逻辑,重点关注 SQL 注入风险和 JWT 令牌处理」。明确的任务边界能减少子 Agent 的困惑。
任务拆分原则
好的任务拆分应该遵循以下原则:
| 原则 | 说明 | 示例 |
|---|---|---|
| 独立性 | 子任务之间尽量独立,减少依赖 | 审查文件 A 和审查文件 B 是独立的 |
| 原子性 | 每个子任务只负责一件事 | 「搜索 + 分析 + 写报告」应拆成三个子任务 |
| 明确边界 | 子任务的输入输出清晰 | 「输出一份 Markdown 格式的审查报告」 |
| 合理粒度 | 不要太细( overhead 高)也不要太粗 | 一个子任务 3-10 分钟完成为宜 |
8.2 agent_spawn —— 创建子 Agent
功能说明
agent_spawn 用于显式创建一个新的子 Agent 实例。与 delegate_task 的「委托即创建」不同,agent_spawn 先创建 Agent,之后可以多次向它委托任务。
这在以下场景很有用:
- 需要一个长期存在的「专家 Agent」(如专门负责代码审查的 Agent)
- 需要预热 Agent 环境(加载特定技能、配置上下文)
- 需要在多个任务之间保持 Agent 状态
参数详解
{
"agent_id": {
"type": "string",
"required": true,
"description": "子 Agent 的唯一标识"
},
"role": {
"type": "string",
"required": false,
"description": "Agent 的角色描述"
},
"skills": {
"type": "array",
"required": false,
"description": "预加载的技能列表"
},
"tools": {
"type": "array",
"required": false,
"description": "可用的工具列表(默认全部)"
},
"model": {
"type": "string",
"required": false,
"description": "指定使用的 LLM 模型"
}
}
使用示例
示例 1:创建一个代码审查专家 Agent
工具调用:
agent_spawn(
agent_id="code-reviewer-1",
role="Python 代码审查专家,专注于安全性、性能和可维护性",
skills=["security-audit", "python-best-practices"],
model="claude-sonnet-4"
)
返回结果:
子 Agent 已创建
ID: code-reviewer-1
角色: Python 代码审查专家...
模型: claude-sonnet-4
状态: ready
示例 2:创建一个前端专家 Agent
工具调用:
agent_spawn(
agent_id="frontend-expert",
role="React/TypeScript 前端开发专家",
skills=["react-patterns", "typescript-tips"],
tools=["read_file", "edit_file", "execute_javascript"]
)
Tips
子 Agent 的
agent_id是全局唯一的。如果尝试创建一个已存在的 ID,会报错。如果需要「重置」一个子 Agent,先agent_terminate再重新agent_spawn。
8.3 agent_communicate —— Agent 间通信
功能说明
agent_communicate 用于主 Agent 与子 Agent 之间、或子 Agent 之间的通信。这是多 Agent 协作的「消息总线」。
通信模式:
- 主 → 子:发送指令、提供额外上下文
- 子 → 主:汇报进度、请求澄清、返回中间结果
- 子 → 子:协作任务中的信息交换
参数详解
{
"from": {
"type": "string",
"required": true,
"description": "发送方 Agent ID"
},
"to": {
"type": "string",
"required": true,
"description": "接收方 Agent ID"
},
"message": {
"type": "string",
"required": true,
"description": "消息内容"
},
"message_type": {
"type": "string",
"required": false,
"default": "text",
"description": "消息类型:text、data、request、response"
}
}
使用示例
工具调用:
agent_communicate(
from="main-agent",
to="code-reviewer-1",
message="请在审查时特别关注用户输入验证部分",
message_type="request"
)
返回结果:
消息已发送
目标 Agent: code-reviewer-1
状态: 已接收
Tips
Agent 间通信的消息会被记录到
~/.hermes/agents/<agent_id>/messages.log。如果协作过程中出现问题,可以查看日志排查是消息丢失还是处理错误。
8.4 agent_status —— 查看子 Agent 状态
功能说明
agent_status 用于查看子 Agent 的当前状态。在多 Agent 协作时,主 Agent 需要知道哪些子 Agent 还在工作、哪些已完成、哪些遇到了问题。
参数详解
{
"agent_id": {
"type": "string",
"required": false,
"description": "指定 Agent ID(不指定则查看所有子 Agent)"
}
}
使用示例
示例 1:查看所有子 Agent 状态
工具调用:
agent_status()
返回结果:
┌──────────────────┬─────────┬──────────────────┬──────────┬──────────────┐
│ Agent ID │ 状态 │ 当前任务 │ 进度 │ 运行时间 │
├──────────────────┼─────────┼──────────────────┼──────────┼──────────────┤
│ code-reviewer-1 │ running │ 审查 src/auth.py │ 60% │ 2 分钟 │
│ frontend-expert │ idle │ - │ - │ 5 分钟 │
│ data-analyst │ done │ 分析销售数据 │ 100% │ 3 分钟 │
└──────────────────┴─────────┴──────────────────┴──────────┴──────────────┘
示例 2:查看特定 Agent 详情
工具调用:
agent_status(agent_id="code-reviewer-1")
返回结果:
Agent ID: code-reviewer-1
状态: running
角色: Python 代码审查专家
当前任务: 审查 src/auth.py
进度: 60%
已执行工具: read_file(3), search_files(1), write_file(0)
最近活动: 2 秒前读取了 src/auth.py 第 120-150 行
内存使用: 45 MB
Token 消耗: 2,340
Tips
当
agent_status显示某个子 Agent 长时间 stuck 在相同进度时,可能遇到了问题。可以用agent_communicate发送消息询问,或者agent_terminate后重新委托。
8.5 agent_terminate —— 终止子 Agent
功能说明
agent_terminate 用于终止子 Agent 的执行。当子 Agent 的任务已经完成、或者子 Agent 陷入死循环、或者需要释放资源时,可以使用这个工具。
参数详解
{
"agent_id": {
"type": "string",
"required": true,
"description": "要终止的 Agent ID"
},
"force": {
"type": "boolean",
"required": false,
"default": false,
"description": "是否强制终止(立即 kill,不等待清理)"
},
"reason": {
"type": "string",
"required": false,
"description": "终止原因(用于日志记录)"
}
}
使用示例
工具调用:
agent_terminate(
agent_id="code-reviewer-1",
reason="任务已完成,释放资源"
)
返回结果:
Agent code-reviewer-1 已终止
执行总结:
- 完成任务: 1
- 使用工具: 8 次
- Token 消耗: 4,560
- 运行时间: 5 分钟
注意
- 资源释放:终止 Agent 会释放其占用的内存和上下文资源,但已写入文件或记忆的内容会保留。
- 强制终止:如果 Agent 陷入死循环或无法响应,使用
force=true强制终止。但这可能导致未保存的数据丢失。
多 Agent 并发限制说明
Hermes 对子 Agent 的并行数量有严格限制:最多同时运行 3 个子 Agent。
这个限制的设计原因:
| 原因 | 说明 |
|---|---|
| 资源保护 | 每个子 Agent 都消耗内存和 Token,过多会导致系统卡顿 |
| 质量控制 | 并行太多,主 Agent 的协调成本会超过并行收益 |
| 成本考量 | 每个子 Agent 都独立调用 LLM,过多会快速消耗 API 配额 |
| 调试难度 | 并行 Agent 越多,问题定位和结果汇总越困难 |
应对策略:
- 分批处理:如果任务可以拆成 10 个子任务,分 4 批执行(3+3+3+1)
- 任务合并:将相关性强的子任务合并,减少 Agent 数量
- 串行执行:对于前后依赖的任务,串行执行比并行更合理
本章小结
本章我们讲解了 5 个代理委托工具:
delegate_task:委托子任务给子 Agent 执行agent_spawn:显式创建子 Agent 实例agent_communicate:Agent 间发送消息agent_status:查看子 Agent 状态和进度agent_terminate:终止子 Agent 释放资源
多 Agent 协作最佳实践:
- 任务拆分粒度:每个子任务 3-10 分钟完成为宜,不要太细也不要太粗
- 并行限制:最多 3 个子 Agent 并行,超出需分批
- 通信简洁:Agent 间消息要简洁明了,避免长上下文传递
- 状态监控:定期
agent_status检查子 Agent 状态,及时发现卡死 - 资源释放:任务完成后及时
agent_terminate,避免资源泄漏
9. 其他辅助工具 —— Agent 的「百宝箱」
本章你将学到
- 7 个辅助工具的功能和使用场景
- 剪贴板操作在自动化工作流中的妙用
- 定时任务的创建和管理
- 图像分析和音频转文字的实用案例
- 文本转换工具的各种编码和格式转换能力
除了前面七大类工具之外,Hermes 还提供了一系列小巧但实用的辅助工具。它们就像 Swiss Army Knife(瑞士军刀)上的那些小工具——开瓶器、螺丝刀、指甲锉——单独看都不起眼,但在特定场景下能救急。
9.1 clipboard —— 剪贴板操作
功能说明
clipboard 工具让 Agent 能够读取和写入系统剪贴板。这是连接 Agent 与外部应用的桥梁——Agent 可以把生成的内容放到剪贴板,你直接粘贴到微信、邮件、文档中;你也可以先把内容复制到剪贴板,让 Agent 读取并处理。
参数详解
{
"action": {
"type": "string",
"required": true,
"description": "操作:read(读取)、write(写入)、clear(清空)"
},
"content": {
"type": "string",
"required": false,
"description": "要写入剪贴板的内容(action=write 时需要)"
},
"format": {
"type": "string",
"required": false,
"default": "text",
"description": "内容格式:text、html、rtf"
}
}
使用示例
示例 1:读取剪贴板内容
工具调用:
clipboard(action="read")
返回结果:
会议记录:
- 讨论了 Q1 的产品路线图
- 确定了 3 个优先级最高的功能
- 下周五前完成原型设计
示例 2:将生成的内容写入剪贴板
工具调用:
clipboard(
action="write",
content="感谢各位参加今天的会议。会议决议如下:\n1. Q1 优先开发 AI 助手功能\n2. 下周五前提交原型\n3. 下周三安排技术评审"
)
返回结果:
内容已写入剪贴板(256 字符)
Tips
clipboard是「人机协作」的经典工具。比如你在浏览器里看到一段英文,复制到剪贴板,然后对 Agent 说「帮我翻译剪贴板里的内容」,Agent 就会用clipboard(action="read")读取,翻译完再用clipboard(action="write")把中文结果写回剪贴板,你直接粘贴即可。
常见场景
| 场景 | 操作 | 说明 |
|---|---|---|
| 翻译 | read → 翻译 → write | 复制外文,翻译后粘贴 |
| 格式化 | read → 格式化 → write | 粘贴混乱的 JSON,格式化后写回 |
| 提取 | read → 提取关键信息 | 复制长邮件,提取待办事项 |
| 生成摘要 | read → 生成摘要 → write | 复制文章,生成摘要后分享 |
注意事项
注意
- 隐私敏感:剪贴板可能包含密码、银行卡号等敏感信息。Agent 读取剪贴板时,会在日志中记录操作,但不会长期保存剪贴板内容。
- 平台兼容性:
clipboard在 macOS、Linux(需 xclip/xsel)和 Windows 上都可用,但某些远程 SSH 会话中可能无法访问剪贴板。- 大小限制:剪贴板内容超过 1MB 时会被截断。对于大内容,建议保存为文件。
9.2 notification —— 发送通知
功能说明
notification 让 Agent 能够发送系统通知(桌面通知)。当 Agent 完成了一个长时间运行的任务、或者监控到重要事件、或者需要用户注意时,可以弹出一个通知提醒。
参数详解
{
"title": {
"type": "string",
"required": true,
"description": "通知标题"
},
"message": {
"type": "string",
"required": true,
"description": "通知内容"
},
"urgency": {
"type": "string",
"required": false,
"default": "normal",
"description": "紧急程度:low、normal、critical"
},
"timeout": {
"type": "integer",
"required": false,
"default": 5,
"description": "通知显示时间(秒)"
}
}
使用示例
示例 1:任务完成通知
工具调用:
notification(
title="Hermes Agent",
message="代码审查已完成,发现 3 个问题",
urgency="normal"
)
示例 2:紧急错误通知
工具调用:
notification(
title="监控告警",
message="检测到网站响应时间超过 5 秒",
urgency="critical",
timeout=10
)
Tips
notification与web_monitor的组合是构建自动化监控系统的经典搭配。当网页监控检测到异常时,立即发送通知,让你第一时间知道问题。
平台支持
| 平台 | 通知方式 | 说明 |
|---|---|---|
| macOS | Notification Center | 显示在屏幕右上角 |
| Linux | notify-send / libnotify | 需要安装通知服务 |
| Windows | Toast Notification | Windows 10+ 原生支持 |
9.3 schedule_task —— 定时任务创建
功能说明
schedule_task 用于创建定时执行的任务。这是 Agent 的「闹钟」——可以设定在未来某个时间点或按某个周期执行特定操作。
参数详解
{
"name": {
"type": "string",
"required": true,
"description": "任务名称"
},
"command": {
"type": "string",
"required": true,
"description": "要执行的命令或工具调用描述"
},
"schedule": {
"type": "string",
"required": true,
"description": "执行计划:cron 表达式或自然语言描述"
},
"enabled": {
"type": "boolean",
"required": false,
"default": true,
"description": "是否启用"
}
}
使用示例
示例 1:每天生成日报
工具调用:
schedule_task(
name="daily-report",
command="搜索今日 AI 新闻并生成摘要报告",
schedule="0 9 * * *"
)
返回结果:
定时任务已创建
名称: daily-report
执行计划: 每天 9:00
下次执行: 2024-01-16 09:00:00
示例 2:每周五下午备份项目
工具调用:
schedule_task(
name="weekly-backup",
command="git push backup && tar czf backup.tar.gz project/",
schedule="0 17 * * 5"
)
示例 3:用自然语言描述
工具调用:
schedule_task(
name="reminder",
command="发送通知:该休息了!",
schedule="every 2 hours"
)
Cron 表达式速查
| 表达式 | 含义 |
|---|---|
0 * * * * |
每小时的第 0 分钟 |
0 9 * * * |
每天 9:00 |
0 9 * * 1 |
每周一 9:00 |
0 9 1 * * |
每月 1 日 9:00 |
*/15 * * * * |
每 15 分钟 |
0 9-17 * * 1-5 |
工作日 9:00-17:00 每小时 |
Tips
定时任务创建后会持久化到
~/.hermes/scheduled_tasks/目录。即使 Hermes 重启,任务也会保留。可以用hermes schedule list查看所有定时任务,hermes schedule remove <name>删除任务。
注意事项
注意
- 系统时钟:定时任务依赖系统时钟,确保你的系统时间准确。
- 任务重叠:如果一个任务执行时间超过了执行间隔,下一次执行会在当前执行完成后立即开始。对于耗时任务,建议设置足够的间隔。
- 睡眠唤醒:如果系统在任务执行时间点处于睡眠状态,任务会在系统唤醒后尽快补执行(取决于操作系统调度)。
9.4 image_analyze —— 图像分析
功能说明
image_analyze 让 Agent 能够「看懂」图片。它利用多模态大模型(如 GPT-4V、Claude 3 Vision)分析图像内容,可以:
- 描述图像中的场景和物体
- 识别图像中的文字(OCR)
- 分析图表和数据可视化
- 检测 UI 界面元素
- 评估图像质量
参数详解
{
"image_path": {
"type": "string",
"required": true,
"description": "图像文件路径或 URL"
},
"prompt": {
"type": "string",
"required": false,
"default": "描述这张图片的内容",
"description": "分析提示词"
},
"detail": {
"type": "string",
"required": false,
"default": "auto",
"description": "细节级别:low、auto、high"
}
}
使用示例
示例 1:描述图片内容
工具调用:
image_analyze(
image_path="screenshots/dashboard.png",
prompt="描述这个仪表盘的布局和数据"
)
返回结果:
这张图片展示了一个数据分析仪表盘:
- 顶部有 4 个 KPI 卡片:总收入 1.2M、用户数 45K、转化率 3.2%、客单价 $89
- 中间是折线图,显示过去 30 天的日活跃用户趋势
- 右侧是饼图,展示用户来源分布( organic 45%、 paid 30%、 social 25%)
- 底部是最近 10 笔交易的表格
示例 2:提取图片中的文字
工具调用:
image_analyze(
image_path="scanned_document.jpg",
prompt="提取图片中的所有文字,保持原有格式",
detail="high"
)
示例 3:分析错误截图
工具调用:
image_analyze(
image_path="error_screenshot.png",
prompt="分析这个错误截图,解释错误原因和可能的解决方案"
)
Tips
web_screenshot+image_analyze的组合可以实现「网页自动化分析」。比如让 Agent 截图一个电商网站的商品页面,然后分析价格、评价、库存等信息。这比解析 HTML 更稳定,因为不依赖具体的 DOM 结构。
注意事项
注意
- 模型依赖:
image_analyze需要后端 LLM 支持多模态(Vision)。如果使用的是纯文本模型(如某些 GPT-3.5 版本),这个工具会报错。- 图像大小:建议图像不超过 5MB。过大的图像会自动压缩,可能影响分析精度。
- 隐私注意:图像会被发送到 LLM 提供商的服务器。不要上传包含敏感信息(身份证、银行卡)的图片。
9.5 audio_transcribe —— 音频转文字
功能说明
audio_transcribe 用于将音频文件转换为文字。它基于 Whisper 等语音识别模型,支持多种语言和音频格式。
参数详解
{
"audio_path": {
"type": "string",
"required": true,
"description": "音频文件路径"
},
"language": {
"type": "string",
"required": false,
"description": "音频语言(如 zh、en、ja),不指定则自动检测"
},
"model": {
"type": "string",
"required": false,
"default": "base",
"description": "模型大小:tiny、base、small、medium、large"
},
"output_format": {
"type": "string",
"required": false,
"default": "text",
"description": "输出格式:text、srt、vtt、json"
}
}
使用示例
示例 1:转写会议录音
工具调用:
audio_transcribe(
audio_path="recordings/meeting_20240115.mp3",
language="zh",
model="medium"
)
返回结果:
参会人 A: 大家好,今天的会议主题是 Q1 的产品规划。
参会人 B: 我先汇报一下目前的进度...
(完整的会议转录文本)
示例 2:生成字幕文件
工具调用:
audio_transcribe(
audio_path="video/audio_track.mp3",
language="en",
output_format="srt"
)
Tips
模型越大(tiny < base < small < medium < large),转写精度越高,但速度越慢。对于中文内容,建议使用
medium或large模型。如果只是快速预览,base模型就够了。
模型选择指南
| 模型 | 速度 | 精度 | 适用场景 |
|---|---|---|---|
| tiny | 最快 | 一般 | 实时预览、低质量音频 |
| base | 快 | 较好 | 快速转写、对精度要求不高 |
| small | 中等 | 好 | 平衡速度和精度 |
| medium | 较慢 | 很好 | 重要会议、出版级内容 |
| large | 最慢 | 最佳 | 专业场景、多语言混合 |
9.6 text_transform —— 文本转换
功能说明
text_transform 是一个通用的文本处理工具,支持各种编码转换、格式转换、文本清理操作。它是「文本瑞士军刀」——JSON 格式化、URL 编解码、Base64 转换、Markdown/HTML 互转等都能搞定。
参数详解
{
"text": {
"type": "string",
"required": true,
"description": "要转换的文本"
},
"operation": {
"type": "string",
"required": true,
"description": "操作类型"
},
"options": {
"type": "object",
"required": false,
"description": "操作相关的额外选项"
}
}
使用示例
示例 1:JSON 格式化
工具调用:
text_transform(
text='{"name":"Alice","age":30,"city":"Beijing"}',
operation="json_format"
)
返回结果:
{
"name": "Alice",
"age": 30,
"city": "Beijing"
}
示例 2:Base64 编解码
工具调用:
text_transform(
text="Hello World",
operation="base64_encode"
)
返回结果:
SGVsbG8gV29ybGQ=
示例 3:Markdown 转 HTML
工具调用:
text_transform(
text="# 标题\n\n这是一段**粗体**文字",
operation="markdown_to_html"
)
返回结果:
<h1>标题</h1>
<p>这是一段<strong>粗体</strong>文字</p>
示例 4:URL 编码/解码
工具调用:
text_transform(
text="https://example.com/search?q=Hello World",
operation="url_encode"
)
返回结果:
https://example.com/search?q=Hello%20World
支持的操作类型
| 操作 | 说明 |
|---|---|
| json_format | JSON 格式化 |
| json_minify | JSON 压缩 |
| base64_encode | Base64 编码 |
| base64_decode | Base64 解码 |
| url_encode | URL 编码 |
| url_decode | URL 解码 |
| html_escape | HTML 转义 |
| html_unescape | HTML 反转义 |
| markdown_to_html | Markdown 转 HTML |
| html_to_markdown | HTML 转 Markdown |
| camel_to_snake | 驼峰转下划线 |
| snake_to_camel | 下划线转驼峰 |
| remove_extra_spaces | 去除多余空格 |
| fix_line_endings | 统一换行符 |
| count_words | 统计字数 |
Tips
text_transform是处理「格式混乱数据」的救星。比如从网页复制的内容经常带有奇怪的空格和换行,用remove_extra_spaces和fix_line_endings清理后,再用markdown_to_html转换,就能得到干净的格式。
9.7 calculator —— 计算器
功能说明
calculator 是一个精确的计算工具。虽然 LLM 本身也能做计算,但对于复杂的数学运算,LLM 可能会出现「幻觉」——算错结果。calculator 使用真实的数学引擎(如 Python 的 math 模块或 sympy),确保结果 100% 准确。
参数详解
{
"expression": {
"type": "string",
"required": true,
"description": "数学表达式"
},
"precision": {
"type": "integer",
"required": false,
"default": 10,
"description": "小数精度"
}
}
使用示例
示例 1:基础计算
工具调用:
calculator(expression="(10000 * 1.05^10 - 10000) / 10000 * 100")
返回结果:
62.8894626777479
示例 2:科学计算
工具调用:
calculator(expression="sin(pi/4) + cos(pi/4)")
返回结果:
1.4142135624
示例 3:复杂公式
工具调用:
calculator(
expression="sqrt(3^2 + 4^2)",
precision=5
)
返回结果:
5.0
Tips
当你需要 Agent 做涉及金额、统计、工程计算的任务时,明确要求它使用
calculator工具。比如「用计算器精确计算这笔投资的年化收益率」,而不是让它心算。这样能保证结果的准确性。
支持的运算符和函数
| 类型 | 示例 |
|---|---|
| 基础运算 | +, -, *, /, //, %, ** |
| 比较 | ==, !=, <, >, <=, >= |
| 数学函数 | sin, cos, tan, sqrt, log, exp, abs |
| 常量 | pi, e |
| 统计 | mean([1,2,3,4,5]), sum([...]) |
本章小结
本章我们讲解了 7 个辅助工具:
clipboard:剪贴板读写,连接 Agent 与外部应用notification:发送系统通知,任务完成或异常时提醒schedule_task:创建定时任务,自动化周期性工作image_analyze:图像分析,让 Agent 能「看懂」图片audio_transcribe:音频转文字,基于 Whisper 模型text_transform:文本格式转换,编码转换和文本清理calculator:精确计算,避免 LLM 数学幻觉
辅助工具使用建议:
- 剪贴板是桥梁:用 clipboard 实现 Agent 与任意应用的快速交互
- 定时任务自动化:把重复性工作交给 schedule_task,Agent 就是你的 cron 助手
- 精确计算用 calculator:涉及数字的任务不要依赖 LLM 心算
- 图像+分析组合:web_screenshot + image_analyze 是分析网页的利器
10. 工具组合实战案例 —— 从「会用工具」到「善用工具」
本章你将学到
- 4 个完整的多工具组合实战案例
- 每个案例的完整工具调用链和输出说明
- 如何根据任务特点选择合适的工具组合
- 实战中常见问题的排查和解决
单个工具的能力是有限的,但工具组合起来就能产生化学反应。本章通过 4 个完整的实战案例,展示如何将多个工具串联起来,解决真实世界的复杂问题。
案例 1:自动化投研报告(web_search + web_extract + write_file + delegate_task)
场景描述
你是一名投资分析师,每周一早上需要提交一份「AI 行业周报」,内容包括:
- 过去一周 AI 领域的重要新闻(至少 10 条)
- 主要 AI 公司的股价变化
- 热门论文和技术突破摘要
- 行业趋势判断和投资建议
手动完成这份报告需要 2-3 小时。现在,让 Hermes Agent 自动化这个流程。
工具调用链
步骤 1:主 Agent 分析任务并拆分子任务
主 Agent 思考:
这个任务可以拆成 4 个子任务,并行执行:
- 子任务 A:搜索 AI 新闻
- 子任务 B:获取主要 AI 公司股价
- 子任务 C:搜索热门论文
- 子任务 D:分析行业趋势框架
由于最多 3 个并行 Agent,将 A 和 B 合并为一个子任务。
步骤 2:委托子任务
→ delegate_task(
task="搜索过去一周的 AI 领域重要新闻(至少 10 条),
同时获取 NVIDIA、Microsoft、Google、OpenAI 相关公司的最新股价信息",
context="今天是 2024-01-15,搜索范围是 1 月 8 日到 1 月 15 日"
)
→ delegate_task(
task="搜索过去一周 AI 领域的热门论文和技术突破,
重点关注 arXiv 上的高引论文",
context="关注 LLM、多模态、AI Agent 三个方向"
)
→ delegate_task(
task="基于当前 AI 行业发展,分析未来一周的投资趋势,
给出 3-5 条投资建议",
context="面向机构投资者,语言专业严谨"
)
步骤 3:等待子任务完成
→ agent_status() # 检查所有子 Agent 是否完成
步骤 4:读取子任务结果
(子 Agent 的结果通过 delegate_task 的返回值自动传回)
步骤 5:汇总生成报告
主 Agent 将三个子任务的结果整合,生成完整的 Markdown 报告。
步骤 6:写入文件
→ write_file(
file_path="reports/AI_Weekly_2024-01-15.md",
content="(整合后的完整报告内容)"
)
步骤 7:发送通知
→ notification(
title="投研报告生成完成",
message="AI 行业周报已生成,共 15 条新闻、8 篇论文、5 条投资建议",
urgency="normal"
)
完整的子 Agent A 内部调用链
子 Agent A 收到任务后,会执行以下工具调用:
→ web_search(query="AI artificial intelligence news January 2024",
time_range="week", num_results=15)
→ web_search(query="NVIDIA Microsoft Google AI stock price January 2024",
time_range="week")
(对每条重要新闻)
→ web_extract(url="新闻链接", format="text", max_length=2000)
(整理结果后返回给主 Agent)
输出示例
# AI 行业周报
**报告日期**: 2024-01-15
**分析师**: Hermes Agent
**数据来源**: 公开新闻、arXiv、Yahoo Finance
---
## 一、本周重要新闻(15 条)
1. **OpenAI 发布 GPT-4 Turbo 更新**
- 来源: OpenAI Blog
- 摘要: 上下文窗口扩展至 128K,知识截止更新到 2024 年 4 月...
2. **Google 推出 Gemini Ultra**
- 来源: Google DeepMind
- 摘要: 在 MMLU 基准测试上首次超越人类专家水平...
...(更多新闻)
## 二、主要公司股价变化
| 公司 | 代码 | 周初 | 周末 | 变化 |
|------|------|------|------|------|
| NVIDIA | NVDA | $520 | $548 | +5.4% |
| Microsoft | MSFT | $380 | $395 | +3.9% |
| Google | GOOGL | $140 | $142 | +1.4% |
| C3.ai | AI | $28 | $25 | -10.7% |
## 三、热门论文与技术突破
1. **"Attention Is All You Need" 的继任者?**
- 论文: Mamba: Linear-Time Sequence Modeling
- 机构: CMU、Princeton
- 影响: 可能替代 Transformer 架构...
## 四、趋势判断与投资建议
1. **建议关注**: 边缘 AI 芯片厂商,随着端侧大模型需求增长...
2. **风险提示**: AI 监管政策不确定性增加...
3. **长期看好**: 企业级 AI Agent 平台...
Tips
这个案例的核心价值在于并行化。4 个子任务如果串行执行可能需要 20 分钟,但 3 个 Agent 并行只需要 8 分钟。对于每周都要做的重复任务,这种效率提升累计起来非常可观。
案例 2:代码审计流水线(read_file + search_files + execute_python + skill_create)
场景描述
你负责一个 Python Web 项目的安全审计。需要:
- 扫描所有 Python 文件,找出潜在的安全漏洞
- 检查依赖包是否有已知漏洞
- 检查是否使用了危险的函数(如
eval、exec、pickle.loads) - 生成审计报告并保存
- 将审计流程保存为技能,以便以后复用
工具调用链
步骤 1:探索项目结构
→ list_directory(recursive=true)
→ search_files(pattern=".*\\.py$", recursive=true)
步骤 2:扫描危险函数
→ search_files(
pattern="eval\\(|exec\\(|pickle\\.loads\\(|subprocess\\.call\\(|os\\.system\\(",
glob="*.py",
context_lines=3,
max_results=50
)
步骤 3:检查依赖漏洞
→ read_file(file_path="requirements.txt")
→ execute_python(
code="""
import subprocess
result = subprocess.run(['safety', 'check', '-r', 'requirements.txt'],
capture_output=True, text=True)
print(result.stdout)
print(result.stderr)
""",
packages=["safety"]
)
步骤 4:深度分析可疑文件
(对 search_files 找到的可疑文件逐个读取分析)
→ read_file(file_path="src/auth.py", offset=1, limit=100)
→ read_file(file_path="src/utils.py", offset=1, limit=100)
步骤 5:生成审计报告
→ write_file(
file_path="security_audit_report.md",
content="(完整的审计报告)"
)
步骤 6:保存为可复用技能
→ skill_create(
name="python-security-audit",
content='''# Python 安全审计
## 触发条件
用户要求进行安全审计、代码审查或提到 "security audit"
## 执行步骤
1. 使用 search_files 扫描项目中的 Python 文件
2. 搜索危险函数调用(eval、exec、pickle.loads 等)
3. 读取 requirements.txt,使用 safety 检查依赖漏洞
4. 对可疑文件进行深度 read_file 分析
5. 生成 security_audit_report.md 报告
## 输出格式
Markdown 格式的安全审计报告
## 示例
输入: "审计一下这个项目的安全性"
输出: security_audit_report.md
'''
)
审计报告示例
# Python 项目安全审计报告
**审计时间**: 2024-01-15 14:30
**审计范围**: src/ 目录下所有 Python 文件 + requirements.txt
**审计工具**: Hermes Agent + safety + bandit
---
## 高危漏洞(3 个)
### 1. SQL 注入风险
- **位置**: src/auth.py:45
- **代码**: `cursor.execute(f"SELECT * FROM users WHERE name = '{username}'")`
- **风险**: 用户输入直接拼接到 SQL 语句中
- **修复建议**: 使用参数化查询 `cursor.execute("SELECT * FROM users WHERE name = ?", (username,))`
- **严重程度**: 🔴 高危
### 2. 不安全的反序列化
- **位置**: src/cache.py:23
- **代码**: `data = pickle.loads(request.body)`
- **风险**: pickle 反序列化可执行任意代码
- **修复建议**: 使用 JSON 替代 pickle,或严格校验输入
- **严重程度**: 🔴 高危
### 3. 命令注入风险
- **位置**: src/admin.py:67
- **代码**: `os.system(f"ping {ip_address}")`
- **风险**: 用户输入直接传入系统命令
- **修复建议**: 使用 subprocess 模块并校验输入
- **严重程度**: 🟠 中危
## 依赖漏洞
| 包名 | 当前版本 | 漏洞 | 修复版本 |
|------|---------|------|---------|
| requests | 2.25.1 | CVE-2023-32681 | 2.31.0 |
| urllib3 | 1.26.5 | CVE-2021-33503 | 1.26.18 |
## 建议
1. 立即修复 3 个高危漏洞
2. 升级 requests 和 urllib3 到安全版本
3. 在 CI/CD 中加入安全扫描步骤
4. 使用 bandit 作为静态分析工具
Tips
将审计流程保存为
skill_create是这个案例的点睛之笔。下次你再接到类似任务,只需要说一句「审计一下这个项目的安全性」,Agent 就会自动执行整套流程——不需要你再描述每一个步骤。
案例 3:网站监控 + 通知(web_monitor + notification + schedule_task)
场景描述
你运营一个电商网站,需要:
- 监控首页是否正常加载
- 监控商品价格页面是否有异常
- 监控网站响应时间是否超过阈值
- 发现问题时立即发送通知
- 每天生成一份可用性报告
工具调用链
步骤 1:创建监控任务
→ web_monitor(
url="https://myshop.example.com",
selector="body",
interval=300,
name="homepage-monitor",
action="notify"
)
→ web_monitor(
url="https://myshop.example.com/products/123",
selector=".price",
interval=300,
name="price-monitor",
action="notify"
)
步骤 2:创建响应时间监控(使用 http_request + schedule_task)
→ schedule_task(
name="response-time-check",
command="检查 https://myshop.example.com 的响应时间,如果超过 3 秒则发送通知",
schedule="*/5 * * * *"
)
步骤 3:创建每日报告任务
→ schedule_task(
name="daily-uptime-report",
command="生成昨日网站可用性报告并保存到 reports/uptime_YYYYMMDD.md",
schedule="0 9 * * *"
)
监控告警示例
当网站首页加载失败时:
通知标题: 网站监控告警
通知内容: 首页监控检测到异常:
- URL: https://myshop.example.com
- 错误: HTTP 503 Service Unavailable
- 时间: 2024-01-15 15:23:00
- 建议: 检查服务器状态和负载均衡配置
紧急程度: critical
每日报告示例
# 网站可用性报告
**日期**: 2024-01-14
**监控目标**: myshop.example.com
## 可用性统计
| 监控项 | 检查次数 | 成功次数 | 成功率 | 平均响应时间 |
|--------|---------|---------|--------|-------------|
| 首页 | 288 | 285 | 98.9% | 1.2s |
| 商品页 | 288 | 288 | 100% | 0.8s |
## 异常事件
- 15:23:00 首页 503 错误,持续 2 分钟
- 原因: 服务器重启
- 恢复: 15:25:00 自动恢复
## 建议
1. 首页成功率低于 99%,建议排查偶发错误原因
2. 考虑增加 CDN 加速以进一步降低响应时间
Tips
web_monitor+notification+schedule_task的组合是构建轻量级监控系统的绝佳方案。不需要部署复杂的监控软件(如 Prometheus + Grafana),几行配置就能实现基本的可用性监控。对于个人项目或小型团队,这完全够用。
案例 4:多 Agent 研究团队(agent_spawn + delegate_task + memory_write)
场景描述
你需要在一天内完成一份「2024 年区块链技术趋势」的深度研究报告。这个任务涉及多个专业领域:
- 技术分析师:分析技术发展方向(Layer 2、ZK、跨链等)
- 市场分析师:分析市场数据和投融资情况
- 政策研究员:跟踪各国监管政策变化
- 报告撰写员:整合所有分析,生成最终报告
单个 Agent 难以同时精通这么多领域。解决方案:创建多个专家 Agent,各自负责一块,最后汇总。
工具调用链
步骤 1:创建专家 Agent
→ agent_spawn(
agent_id="tech-analyst",
role="区块链技术专家,专注于协议层和基础设施分析",
skills=["blockchain-tech", "protocol-analysis"]
)
→ agent_spawn(
agent_id="market-analyst",
role="加密市场分析师,关注投融资和市场趋势",
skills=["crypto-market", "fundraising-tracker"]
)
→ agent_spawn(
agent_id="policy-researcher",
role="区块链政策研究员,跟踪全球监管动态",
skills=["regulation-tracker", "policy-analysis"]
)
步骤 2:并行委托研究任务
→ delegate_task(
agent_id="tech-analyst",
task="研究 2024 年区块链技术趋势,重点关注:\n1. Layer 2 扩容方案进展\n2. 零知识证明应用\n3. 跨链互操作性\n4. 新型共识机制",
timeout=600
)
→ delegate_task(
agent_id="market-analyst",
task="分析 2024 年加密市场数据:\n1. 主要币种价格走势\n2. 投融资事件统计\n3. DeFi 和 NFT 市场数据\n4. 机构入场情况",
timeout=600
)
→ delegate_task(
agent_id="policy-researcher",
task="梳理 2024 年全球区块链监管政策:\n1. 美国 SEC 动态\n2. 欧盟 MiCA 法规进展\n3. 亚洲主要国家政策\n4. 央行数字货币(CBDC)发展",
timeout=600
)
步骤 3:监控进度
→ agent_status() # 查看三个 Agent 的进度
(等待所有 Agent 完成...)
步骤 4:将研究结果写入记忆
→ memory_write(
memory_type="session",
key="研究报告.技术分析",
value="(tech-analyst 的完整研究结果)"
)
→ memory_write(
memory_type="session",
key="研究报告.市场分析",
value="(market-analyst 的完整研究结果)"
)
→ memory_write(
memory_type="session",
key="研究报告.政策分析",
value="(policy-researcher 的完整研究结果)"
)
步骤 5:创建报告撰写 Agent 汇总
→ delegate_task(
task="整合技术、市场、政策三个维度的分析结果,\n生成一份结构化的深度研究报告。\n报告应包含:执行摘要、各章节详细分析、趋势预测、投资建议",
context="研究结果已保存在 session 记忆中,键名分别为 研究报告.技术分析、研究报告.市场分析、研究报告.政策分析"
)
步骤 6:保存最终报告
→ write_file(
file_path="reports/Blockchain_Trends_2024.md",
content="(最终整合的报告)"
)
步骤 7:清理资源
→ agent_terminate(agent_id="tech-analyst")
→ agent_terminate(agent_id="market-analyst")
→ agent_terminate(agent_id="policy-researcher")
输出说明
这个案例的最终输出是一份完整的深度研究报告,通常包含:
- 执行摘要(1-2 页):核心观点和建议
- 技术分析(5-8 页):Layer 2、ZK、跨链等技术方向
- 市场分析(5-8 页):价格、投融资、市场份额
- 政策分析(3-5 页):监管框架和合规趋势
- 综合预测(2-3 页):未来 6-12 个月的趋势判断
- 附录:数据来源、术语表、参考文献
Tips
多 Agent 协作的关键在于清晰的职责划分和标准化的输出格式。在委托任务时,明确指定每个 Agent 的专注领域和输出要求。如果输出格式不统一,汇总时会非常困难。建议在任务描述中附上输出模板。
本章小结
本章通过 4 个实战案例,展示了工具组合的强大威力:
| 案例 | 核心工具组合 | 解决的问题 |
|---|---|---|
| 自动化投研报告 | web_search + web_extract + delegate_task | 信息收集与报告生成自动化 |
| 代码审计流水线 | read_file + search_files + skill_create | 安全审计流程化、可复用 |
| 网站监控 + 通知 | web_monitor + notification + schedule_task | 7x24 可用性监控 |
| 多 Agent 研究团队 | agent_spawn + delegate_task + memory_write | 复杂任务的专家分工协作 |
组合设计原则:
- 并行优于串行:能并行的子任务尽量并行(受 3 Agent 限制)
- 记忆是纽带:多 Agent / 多步骤之间通过 memory_write/memory_read 传递信息
- 技能沉淀:将成功的工具组合保存为 Skill,实现一次配置、多次复用
- 通知闭环:耗时任务和监控任务一定要有 notification,避免「石沉大海」
11. 工具开发与扩展 —— 打造你的专属工具
本章你将学到
- 自定义工具的开发方法和完整示例
- ToolRegistry 的注册机制详解
- MCP 协议工具扩展的方法和原理
- 社区工具贡献的流程和规范
- 工具开发的调试和测试技巧
Hermes 的 47 个内置工具覆盖了绝大多数常见场景,但总有一些特定需求需要自定义工具。比如:
- 你的公司有一个内部 API,需要专门的调用工具
- 你经常使用某个特定的 SaaS 服务(如 Jira、Confluence)
- 你需要与本地特定的硬件设备交互
- 你想封装一套常用的数据处理逻辑
本章将教你如何开发和扩展 Hermes 工具。
11.1 自定义工具的开发方法
开发自定义工具的核心步骤:
- 继承 Tool 基类:创建一个新的 Python 类,继承
hermes.core.tools.Tool - 定义元数据:使用
@tool装饰器定义工具名称、描述、参数 - 实现 execute 方法:编写工具的实际执行逻辑
- 注册到 Registry:使用装饰器自动注册,或手动注册
完整示例:开发一个「生成二维码」工具
# ~/.hermes/custom_tools/qr_generator.py
import qrcode
import io
import base64
from hermes.core.tools import tool, Tool, ToolResult
@tool(
name="generate_qr",
description="生成二维码图片",
parameters={
"data": {
"type": "string",
"description": "要编码到二维码中的数据",
"required": True
},
"size": {
"type": "integer",
"description": "二维码尺寸(像素)",
"default": 256
},
"output_path": {
"type": "string",
"description": "保存路径(不指定则返回 base64)",
"required": False
}
},
requires_approval=False
)
class QRGeneratorTool(Tool):
async def execute(self, params: dict) -> ToolResult:
data = params["data"]
size = params.get("size", 256)
output_path = params.get("output_path")
# 生成二维码
qr = qrcode.QRCode(
version=1,
error_correction=qrcode.constants.ERROR_CORRECT_H,
box_size=10,
border=4,
)
qr.add_data(data)
qr.make(fit=True)
# 生成图像
img = qr.make_image(fill_color="black", back_color="white")
img = img.resize((size, size))
if output_path:
# 保存到文件
img.save(output_path)
return ToolResult(
content=f"二维码已保存到 {output_path}",
metadata={"path": output_path, "size": size}
)
else:
# 返回 base64
buffer = io.BytesIO()
img.save(buffer, format='PNG')
img_base64 = base64.b64encode(buffer.getvalue()).decode()
return ToolResult(
content=f"data:image/png;base64,{img_base64}",
metadata={"format": "base64", "size": size}
)
工具类结构详解
class Tool:
"""所有工具的基类"""
name: str # 工具名称
description: str # 工具描述(给 LLM 看的)
parameters: dict # 参数定义(用于 JSON Schema 验证)
requires_approval: bool # 是否需要审批
async def execute(self, params: dict) -> ToolResult:
"""核心执行方法,子类必须实现"""
raise NotImplementedError
async def validate(self, params: dict) -> bool:
"""参数校验,可选重写"""
return True
async def before_execute(self, params: dict):
"""执行前钩子,可选重写"""
pass
async def after_execute(self, result: ToolResult):
"""执行后钩子,可选重写"""
pass
ToolResult 结构
class ToolResult:
def __init__(
self,
content: str, # 主要返回内容(给 LLM 看的)
metadata: dict = None, # 元数据(如文件路径、耗时等)
error: str = None, # 错误信息(如果有)
attachments: list = None # 附件(如图片、文件)
):
self.content = content
self.metadata = metadata or {}
self.error = error
self.attachments = attachments or []
Tips
content是 LLM 能看到的内容,要尽量简洁明了。metadata可以放一些结构化数据(如文件路径、HTTP 状态码),方便后续工具链使用。error如果不为空,Agent 会知道工具执行失败了。
11.2 工具注册机制详解
装饰器注册(推荐)
@tool(
name="my_tool",
description="...",
parameters={...}
)
class MyTool(Tool):
...
装饰器在模块导入时自动执行,将工具注册到全局 ToolRegistry。这是最简单、最推荐的方式。
手动注册
from hermes.core.tools import ToolRegistry
registry = ToolRegistry()
my_tool = MyTool()
registry.register(my_tool)
手动注册适用于动态加载的场景——比如从配置文件读取工具定义,然后运行时创建和注册。
配置文件注册
在 ~/.hermes/config.yaml 中指定自定义工具的加载路径:
tools:
custom_paths:
- "~/.hermes/custom_tools/" # 加载此目录下所有 Python 文件
- "~/projects/hermes-tools/" # 也可以指定其他路径
# 禁用某些内置工具
disabled:
- "execute_shell" # 如果你不想允许 Shell 执行
注册优先级
当多个工具同名时,Hermes 的加载优先级是:
- 用户自定义工具(最高优先级)
- 插件工具
- 内置工具(最低优先级)
这意味着你可以用自定义工具覆盖内置工具。比如你觉得内置的 calculator 不够用,可以写一个同名工具替换它。
11.3 MCP 协议工具扩展
什么是 MCP
MCP(Model Context Protocol)是 Anthropic 提出的开放协议,用于标准化 AI 模型与外部数据源、工具之间的交互。Hermes 支持通过 MCP 协议集成第三方工具。
MCP 的优势:
- 标准化:统一的接口规范,工具开发一次,多处使用
- 语言无关:MCP 服务器可以用任何语言编写
- 安全隔离:MCP 服务器运行在独立进程中,与主程序隔离
- 动态发现:Hermes 可以自动发现和连接 MCP 服务器
使用 MCP 扩展示例
假设有一个 MCP 服务器提供了「查询公司内部知识库」的能力:
// ~/.hermes/mcp_config.json
{
"mcpServers": {
"company-kb": {
"command": "python",
"args": ["/path/to/company_kb_server.py"],
"env": {
"KB_API_KEY": "your-api-key"
}
}
}
}
配置后,Hermes 会自动连接 MCP 服务器,并将其暴露的工具纳入工具调用范围。Agent 可以像调用内置工具一样调用 MCP 工具:
工具调用:
company_kb_search(query="2024 年假政策")
返回结果:
根据公司内部知识库,2024 年假政策如下:
- 年假天数:10-15 天(根据工龄)
- 申请方式:OA 系统提前 3 天申请
- ...
Tips
MCP 协议是工具生态的未来方向。如果你要开发一个长期维护的工具,建议用 MCP 协议封装,而不是直接写 Hermes 原生工具。这样你的工具可以被多个支持 MCP 的 Agent 框架复用。
11.4 社区工具贡献指南
如果你想把开发的工具贡献给社区,可以通过以下渠道:
贡献到 Skills Hub
- 在 GitHub 上 fork
hermes-tools仓库 - 在
tools/目录下创建你的工具目录 - 编写工具代码和 README 文档
- 提交 Pull Request
- 等待审核(通常 3-5 个工作日)
工具贡献检查清单
- [ ] 工具代码完整,包含错误处理
- [ ] 包含完整的参数定义和类型注解
- [ ] 包含单元测试(覆盖率 > 80%)
- [ ] 包含使用示例
- [ ] README 文档包含功能说明、安装方法、使用示例
- [ ] 不包含敏感信息(API Key、密码等)
- [ ] 遵循 Hermes 代码风格
- [ ] 工具名称不与现有工具冲突
审核标准
| 等级 | 要求 |
|---|---|
| 官方(Official) | 通过全部检查清单 + 核心团队审核 + 签名验证 |
| 可信(Trusted) | 通过全部检查清单 + 自动化测试通过 |
| 社区(Community) | 基本功能正常 + 有文档 |
本章小结
本章我们讲解了工具开发与扩展的完整流程:
- 自定义工具开发:继承 Tool 基类,实现 execute 方法,使用 @tool 装饰器注册
- 注册机制:装饰器自动注册、手动注册、配置文件指定路径三种方式
- MCP 协议:标准化的工具扩展协议,语言无关,安全隔离
- 社区贡献:通过 GitHub PR 贡献工具,经过审核后进入 Skills Hub
开发建议:
- 从简单开始:先 clone 一个内置工具的代码,在此基础上修改
- 测试驱动:为工具编写单元测试,确保参数校验和边界条件处理正确
- 文档先行:写工具前先写文档,明确工具的输入输出和边界情况
- 考虑 MCP:长期维护的工具建议用 MCP 协议封装
12. 工具使用最佳实践 —— 从新手到高手的进阶之路
本章你将学到
- 工具使用的 5 大核心原则
- 10 个常见工具使用误区和避免方法
- 成本优化技巧:减少不必要的 API 调用
- 错误处理和故障恢复策略
- 工具性能优化和调试技巧
掌握了 47 个工具的用法之后,更重要的是学会「善用」工具。同样的工具,在不同的人手里效果可能天差地别。本章分享我在长期使用 Hermes 过程中总结的最佳实践。
12.1 安全第一:敏感命令必须审批
安全不是可选项,而是必选项。以下是安全使用工具的核心原则:
原则 1:默认不信任
即使是你自己写的 Agent,也要假设它可能犯错。对于任何会修改系统的操作:
- 在配置中启用审批(不要设置
auto_allow) - 定期检查工具调用历史
hermes tools history - 对重要操作开启
backup=true
原则 2:最小权限原则
给 Agent 的权限越小,潜在危害越小:
# 安全配置示例
tools:
execute_shell:
enabled: false # 如果不需要,直接禁用
execute_python:
network: false # 禁止网络访问
memory_limit: 256 # 限制内存
write_file:
allowed_paths:
- "~/projects/" # 只允许写入特定目录
- "~/Documents/"
原则 3:审计日志
定期审查工具调用日志:
# 查看最近的工具调用
hermes tools history --limit 50
# 查看高风险操作
hermes tools history --filter "execute_shell,execute_python,kill_process"
# 导出日志用于审计
hermes tools history --export audit_log.json
12.2 组合优于单打:多工具配合
一个常见的误区是「一个任务只用一个工具」。实际上,复杂任务往往需要多个工具配合。
反模式:单打独斗
❌ 错误示例:
用户:帮我分析一下这个项目的代码质量
Agent:好的,我用 search_files 搜一下代码文件
→ search_files(pattern=".*", glob="*.py")
(然后就没有然后了——只是列出了文件列表,没有深入分析)
正模式:工具链配合
✅ 正确示例:
用户:帮我分析一下这个项目的代码质量
Agent:
→ list_directory(recursive=true) # 了解项目结构
→ search_files(pattern="def ", glob="*.py") # 找到所有函数
→ read_file(file_path="src/main.py") # 读取核心文件
→ search_files(pattern="TODO|FIXME|XXX", glob="*.py") # 找技术债务
→ execute_python(code="统计代码行数和复杂度") # 量化分析
→ write_file(file_path="code_quality_report.md") # 生成报告
常用工具链组合
| 场景 | 工具链 | 说明 |
|---|---|---|
| 调研报告 | web_search → web_extract → write_file | 搜索、提取、汇总 |
| 代码重构 | search_files → read_file → edit_file → run_command | 定位、确认、修改、测试 |
| 数据分析 | read_file → execute_python → write_file | 读取、分析、输出 |
| 故障排查 | system_info → process_list → read_file(log) → execute_python(分析) | 全面诊断 |
| 批量处理 | list_directory → read_file(模板) → execute_python(批量生成) → write_file | 自动化生成 |
12.3 成本意识:减少不必要的 API 调用
每次工具调用都可能消耗 Token、时间和金钱。养成成本意识,能让你的 Agent 更高效。
成本优化技巧
1. 批量操作优于多次调用
❌ 低效:逐个读取文件
→ read_file(file_path="src/a.py")
→ read_file(file_path="src/b.py")
→ read_file(file_path="src/c.py")
✅ 高效:先搜索,再批量处理
→ search_files(pattern="class ", glob="*.py") # 找到所有类定义
→ read_file(file_path="src/main.py", limit=100) # 只读关键部分
2. 本地计算替代远程调用
❌ 低效:用 web_search 计算简单的数学问题
→ web_search(query="what is 234 * 567")
✅ 高效:用本地计算器
→ calculator(expression="234 * 567")
3. 缓存重复查询
# 在自定义工具中实现缓存
import functools
@functools.lru_cache(maxsize=100)
def fetch_api_data(endpoint):
# 只有第一次调用会发起 HTTP 请求
# 后续相同 endpoint 直接返回缓存
return http_request(url=endpoint)
4. 合理设置 limit 和 offset
❌ 低效:读取整个大文件
→ read_file(file_path="app.log") # 100MB 日志
✅ 高效:只读取需要的部分
→ read_file(file_path="app.log", offset=-100) # 只读最后 100 行
成本监控
# 查看工具调用的 Token 消耗统计
hermes tools stats --cost
# 输出示例
┌─────────────┬──────────┬────────────┬──────────────┐
│ 工具 │ 调用次数 │ Token 消耗 │ 预估成本(USD)│
├─────────────┼──────────┼────────────┼──────────────┤
│ web_search │ 45 │ 12,000 │ $0.18 │
│ read_file │ 120 │ 45,000 │ $0.68 │
│ execute_python│ 30 │ 8,000 │ $0.12 │
│ web_browse │ 15 │ 25,000 │ $0.38 │
└─────────────┴──────────┴────────────┴──────────────┘
总计: $1.36
12.4 错误处理:工具调用失败的应对
工具调用失败是不可避免的——网络超时、文件不存在、权限不足、API 限流等。良好的错误处理能让 Agent 更健壮。
错误类型和处理策略
| 错误类型 | 常见原因 | 处理策略 |
|---|---|---|
| 文件不存在 | 路径错误、文件被删除 | 先 file_info 检查存在性 |
| 权限不足 | 没有读写权限 | 检查文件权限,或换目录 |
| 网络超时 | 网络不稳定、目标慢 | 增加 timeout,或重试 |
| API 限流 | 请求太频繁 | 增加间隔,或使用缓存 |
| 内存不足 | 处理大数据 | 分块处理,或增加内存限制 |
| 编码错误 | 文件编码不对 | 尝试不同 encoding |
在自定义工具中实现错误处理
class RobustTool(Tool):
async def execute(self, params: dict) -> ToolResult:
try:
result = await self._do_work(params)
return ToolResult(content=result)
except FileNotFoundError as e:
return ToolResult(
content="",
error=f"文件不存在: {e.filename}。请检查路径是否正确。"
)
except PermissionError:
return ToolResult(
content="",
error="权限不足。请检查文件权限或尝试其他目录。"
)
except TimeoutError:
return ToolResult(
content="",
error="操作超时。请稍后重试,或增加 timeout 参数。"
)
except Exception as e:
return ToolResult(
content="",
error=f"未知错误: {str(e)}"
)
Tips
当工具返回
error时,Agent 会收到错误信息并决定如何处理。好的错误信息应该: 1. 说明发生了什么错误 2. 解释可能的原因 3. 给出具体的解决建议这样的错误信息能帮助 Agent 自我修复,或者给用户清晰的指导。
12.5 常见工具使用误区(10 个)
误区 1:用 write_file 做所有文件修改
❌ 错误:
→ write_file(file_path="config.py", content="全新内容")
(覆盖了文件中其他有用的配置)
✅ 正确:
→ read_file(file_path="config.py") # 先读取
→ edit_file(file_path="config.py", old_string="...", new_string="...") # 精确修改
误区 2:忽视 offset 和 limit,读取超大文件
❌ 错误:
→ read_file(file_path="server.log") # 500MB 日志文件
(导致上下文溢出,Token 暴增)
✅ 正确:
→ read_file(file_path="server.log", offset=-50) # 只看最后 50 行
→ search_files(pattern="ERROR", path="logs", glob="*.log") # 只搜错误
误区 3:在 execute_shell 中拼接用户输入
❌ 错误:
→ execute_shell(command=f"grep {user_input} file.txt")
(如果 user_input = "; rm -rf /;" 就完蛋了)
✅ 正确:
→ search_files(pattern=user_input, glob="*.txt") # 用安全的工具替代
→ 或者对输入做转义处理
误区 4:重复安装相同的 Python 包
❌ 错误:
每次 execute_python 都 packages=["pandas", "numpy"]
(每次调用都检查/安装,浪费时间)
✅ 正确:
在 ~/.hermes/config.yaml 中预配置常用包
或者在项目虚拟环境中提前安装
误区 5:用 web_search 查询本地知识
❌ 错误:
→ web_search(query="我上周让 Agent 写的代码在哪里")
(搜索引擎不知道你的本地文件)
✅ 正确:
→ memory_search(query="上周写的代码") # 搜索记忆
→ search_files(pattern="上周写的函数名") # 搜索本地文件
误区 6:创建太多监控任务不清理
❌ 错误:
每次测试都创建新的 web_monitor,从不删除
(导致后台一堆无用监控,浪费资源)
✅ 正确:
定期检查 ~/.hermes/monitors/
测试完成后删除临时监控任务
误区 7:忽略工具的返回值
❌ 错误:
Agent 调用了 edit_file,但文件实际上没有变化
(因为 old_string 匹配失败,但 Agent 没有检查返回结果)
✅ 正确:
关注工具的返回状态
如果 edit_file 返回 "未找到匹配",需要调整策略
误区 8:过度使用 execute_shell 做简单的事情
❌ 错误:
→ execute_shell(command="cat README.md")
(绕过了 read_file 的安全检查和编码处理)
✅ 正确:
→ read_file(file_path="README.md")
(有编码自动检测、大小限制、安全路径检查)
误区 9:不备份就修改重要文件
❌ 错误:
→ write_file(file_path=".env", content="新的配置")
(覆盖了原来的 API Key,可能导致服务中断)
✅ 正确:
→ read_file(file_path=".env") # 先读取备份到记忆
→ write_file(file_path=".env", content="新配置", backup=true)
误区 10:创建 Agent 后不终止,造成资源泄漏
❌ 错误:
→ agent_spawn(agent_id="helper")
→ delegate_task(agent_id="helper", task="...")
(任务完成后不 terminate,内存不释放)
✅ 正确:
→ agent_terminate(agent_id="helper") # 用完后释放
→ 或者在配置中设置自动超时清理
12.6 调试工具问题的技巧
当工具行为不符合预期时,按以下步骤排查:
步骤 1:隔离测试
# 直接用 CLI 测试工具,绕过 Agent 的推理逻辑
hermes tools test read_file --params '{"file_path": "test.txt"}'
步骤 2:检查参数
查看工具调用时的实际参数:
- 路径是否正确(相对路径 vs 绝对路径)
- 类型是否匹配(字符串 vs 数字)
- 必需的参数是否都提供了
步骤 3:查看日志
# 查看详细日志
tail -f ~/.hermes/logs/tools.log
# 过滤特定工具的日志
grep "read_file" ~/.hermes/logs/tools.log
步骤 4:最小复现
把问题简化为最小的可复现示例:
# 写一个简单的测试脚本
from hermes.tools import read_file_tool
result = read_file_tool.execute({"file_path": "test.txt"})
print(result.content)
print(result.error)
print(result.metadata)
步骤 5:检查环境
# 检查 Hermes 版本
hermes --version
# 检查工具加载情况
hermes tools list
# 检查配置文件语法
hermes config validate
本章小结
本章总结了工具使用的最佳实践和常见误区:
5 大核心原则:
- 安全第一:敏感操作必须审批,遵循最小权限原则
- 组合优于单打:复杂任务用工具链,而不是单个工具
- 成本意识:减少不必要的 API 调用,批量处理更高效
- 错误处理:工具调用失败时要有应对策略
- 及时清理:用完的 Agent 要终止,临时任务要删除
10 个常见误区回顾:
- 用
write_file做所有修改(应优先用edit_file) - 忽视
offset/limit读取超大文件 - 在 Shell 命令中拼接未转义的用户输入
- 重复安装相同的 Python 包
- 用
web_search查询本地知识 - 创建监控任务不清理
- 忽略工具的返回值和错误信息
- 过度使用
execute_shell做简单的事情 - 不备份就修改重要文件
- 创建 Agent 后不终止造成资源泄漏
进阶建议:
- 定期运行
hermes tools stats分析工具使用模式 - 建立团队的「工具使用规范」文档
- 把常用的工具组合沉淀为 Skill
- 关注 Hermes 更新日志,及时使用新工具
结语:工具是手段,解决问题才是目的
到这里,我们已经走完了 Hermes 47 个内置工具的完整旅程。从文件系统的基础操作,到代码执行的强大能力;从 Web 交互的信息获取,到多 Agent 协作的复杂编排——这些工具构成了 Hermes Agent 的「四肢百骸」,让它从一个只会聊天的「大脑」,变成了能够动手解决问题的「全能助手」。
但请记住,工具永远只是手段,而不是目的。掌握 47 个工具的名字和参数很容易,难的是知道「什么时候该用什么工具」「如何把工具组合起来解决真实问题」。
就像一位经验丰富的工匠,他不需要记住每一种工具的所有规格,但他知道:什么时候该用锤子,什么时候该用凿子,什么时候需要两只手配合。这种「手感」,只能通过大量的实践来培养。
所以,打开你的终端,启动 Hermes,开始动手吧。从简单的「读取一个文件」开始,到复杂的「多 Agent 协作完成研究报告」,每一步都会让你对工具的理解更深一层。
工具在手,天下我有。祝你在 Hermes 的世界里,探索愉快!
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十册:多平台接入实战
本章你将学到 - 为什么多平台接入是 Hermes 的杀手级特性 - Gateway 消息网关的工作原理与配置方法 - Telegram、飞书、微信、Discord 等主流平台的完整接入流程 - 编辑器集成与语音交互的配置技巧 - 多平台协同使用的实战策略与安全运维方案
1. 为什么需要多平台接入
1.1 从"只在电脑前用"到"随时随地指挥"
想象一下这样的场景:
早上你在地铁上,突然想到一个绝妙的创意,你想立刻让 AI 帮你整理思路、查找资料。但你只有手机,而你的 AI 助手却乖乖地待在电脑里。你只能手忙脚乱地打开手机备忘录,草草记几笔,等到了公司再重新输入给 AI。
中午你在咖啡馆见客户,客户临时提了一个技术问题,你想让 AI 快速查一下行业数据。但你电脑上没装通信软件,手机上的 AI 又没法访问你电脑里的文件和工具。
晚上你躺在床上,突然想到明天要给团队汇报的方案还没完善。你翻个身摸到手机,给 AI 发一条语音消息,它立刻帮你生成了一份完整的汇报提纲,还自动发到了飞书群里。
这就是多平台接入带来的变革。
在传统的 AI 使用方式里,你和 AI 的关系就像医生和病人——必须面对面坐在诊室里才能交流。但有了多平台接入,AI 就像你的贴身助理,无论你是在电脑前、手机上、智能手表里,甚至是在家里的智能音箱旁,它都能随时随地响应你的指令。
Tips Hermes 的多平台接入能力,本质上是一套消息网关(Gateway)系统。它相当于 AI 的"多语言翻译官",能把不同平台的消息格式翻译成 AI 能理解的通用语言,再把 AI 的回复翻译成对应平台能展示的格式。
1.2 消息网关的设计理念
Hermes 的 Gateway 架构设计,借鉴了互联网领域中成熟的消息队列和网关模式。它的核心理念可以用一句话概括:"一次接入,处处可达"。
让我们用一个生活中的类比来理解 Gateway 的工作原理:
想象你是一家跨国公司的 CEO,你的助理(Gateway)需要同时处理来自不同渠道的信息——微信上的客户消息、邮件里的合作邀约、电话里的紧急事务、钉钉上的内部审批。助理的职责不是让你同时盯着十个屏幕,而是把所有信息统一整理成标准格式的待办事项,按优先级呈现给你。当你给出指示后,助理再根据每条信息的来源渠道,用合适的方式回复出去。
Hermes 的 Gateway 就是你的这位超级助理:
- 消息路由(Routing):识别消息来自哪个平台、哪个用户、哪个群组,决定把回复发回哪里
- 格式转换(Transcoding):把 Telegram 的 Markdown 格式转成飞书的富文本卡片,把语音消息转成文字,把文件 attachments 统一处理
- 状态同步(State Sync):你在手机上和 AI 聊到一半,回到电脑前继续聊,AI 记得刚才聊到哪儿了
- 身份认证(Authentication):确认发消息的人是你,不是你二舅冒充你让 AI 转账
注意 Gateway 不是简单地"转发消息",它维护着一套完整的会话上下文。你在 Telegram 里问"刚才说的那个方案呢",AI 能准确理解"刚才"指的是你在飞书里的上一轮对话——这才是真正的多平台协同。
1.3 15+ 平台一览与分类
截止到目前,Hermes 已经支持接入的平台超过了 15 个,涵盖了即时通讯、企业协作、社交媒体、编辑器、语音设备等多个类别。下面这张表帮你快速了解全貌:
| 类别 | 平台 | 适用场景 | 接入复杂度 |
|---|---|---|---|
| 即时通讯 | Telegram | 个人用户、开发者社群、海外团队 | ⭐ 简单 |
| 海外商务沟通、亲友联络 | ⭐⭐ 中等 | ||
| Signal | 高隐私要求场景 | ⭐⭐ 中等 | |
| SMS | 无网络环境下的备用通道 | ⭐⭐ 中等 | |
| 企业协作 | 飞书(Lark) | 国内团队、字节生态 | ⭐ 简单 |
| 企业微信 | 腾讯生态企业、国内商务 | ⭐⭐ 中等 | |
| Slack | 海外团队、开发者社区 | ⭐ 简单 | |
| Discord | 游戏社群、开源社区、粉丝群 | ⭐ 简单 | |
| Matrix | 去中心化、隐私优先团队 | ⭐⭐⭐ 复杂 | |
| Mattermost | 自托管企业协作 | ⭐⭐⭐ 复杂 | |
| 社交媒体 | 微信公众号 | 内容运营、客服自动化 | ⭐⭐⭐ 复杂 |
| 智能家居 | Home Assistant | 语音控制、IoT 联动 | ⭐⭐ 中等 |
| 编辑器 | VS Code | 编程辅助、代码审查 | ⭐ 简单 |
| Zed | 新一代代码编辑器 | ⭐ 简单 | |
| JetBrains IDE | Java/Python/Go 开发 | ⭐⭐ 中等 | |
| 语音 | 语音交互后端 | 语音输入/输出 | ⭐⭐ 中等 |
| 邮件 | 异步沟通、报告分发 | ⭐⭐ 中等 |
Tips 如果你第一次接触多平台接入,建议从 Telegram 或 飞书 开始。这两个平台的文档最完善、社区支持最好、配置也最直观。等熟悉了 Gateway 的工作模式后,再逐步扩展到其他平台。
2. Gateway 架构与基础配置
2.1 hermes gateway 命令详解
在 Hermes 的命令行工具中,hermes gateway 是管理消息网关的核心命令。它就像机场塔台的指挥系统,负责让所有"航班"(来自不同平台的消息)有序起降。
先来看一下 gateway 命令的完整帮助信息:
# 查看 gateway 命令帮助
$ hermes gateway --help
Usage: hermes gateway [OPTIONS] COMMAND [ARGS]...
管理消息网关(Gateway)的多平台接入
Commands:
setup 交互式配置一个新平台
start 启动网关服务
stop 停止网关服务
restart 重启网关服务
status 查看网关运行状态
list 列出所有已配置的平台
logs 查看网关日志
test 发送测试消息到指定平台
每个子命令的详细用法:
# 交互式配置新平台(最常用)
$ hermes gateway setup
# 会弹出一个菜单让你选择要接入的平台,然后一步步引导你完成配置
# 启动网关服务(前台运行,适合调试)
$ hermes gateway start
# 启动网关服务(后台守护进程)
$ hermes gateway start --daemon
# 停止网关
$ hermes gateway stop
# 查看网关状态(哪些平台在线、消息队列长度等)
$ hermes gateway status
# 查看已配置的平台列表
$ hermes gateway list
# 实时查看网关日志(调试用)
$ hermes gateway logs --follow
# 发送测试消息验证配置
$ hermes gateway test telegram --message "Hello from Hermes!"
Tips 建议在首次配置时,先用
hermes gateway start(前台模式)启动网关。这样如果有报错,你能立刻在终端看到红色错误信息。等一切正常后,再用--daemon模式放到后台运行。
2.2 hermes gateway setup 交互式配置
hermes gateway setup 是 Hermes 最贴心的功能之一。你不需要手写复杂的配置文件,只需要跟着向导回答几个问题,就能完成平台接入。
下面是一个完整的 setup 流程示例(以 Telegram 为例):
$ hermes gateway setup
🌐 Hermes Gateway 配置向导
══════════════════════════════════════════
请选择要接入的平台:
[1] Telegram - 海外最流行的即时通讯
[2] 飞书 (Lark) - 国内企业协作首选
[3] 企业微信 - 腾讯生态企业通讯
[4] Discord - 游戏与开发者社区
[5] Slack - 海外团队协作
[6] 微信公众号 - 内容运营与客服
[7] WhatsApp - 海外商务沟通
[8] Matrix - 去中心化通讯
[9] Email - 邮件收发
[10] 更多平台...
请输入数字选择: 1
📱 Telegram 配置
──────────────────────────────────────────
第一步:获取 Bot Token
1. 在 Telegram 中搜索 @BotFather
2. 发送 /newbot 创建新机器人
3. 按提示命名你的 Bot(例如:HermesAssistant)
4. 保存获得的 Token(格式:123456789:ABCdefGHIjklMNOpqrsTUVwxyz)
请输入你的 Bot Token: 123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
✅ Token 格式验证通过
第二步:设置允许列表(Allowlist)
允许列表用于限制哪些用户可以与你的 Hermes Bot 交互。
建议先设置为你自己的用户 ID,测试成功后再添加其他人。
请输入允许的用户 ID(多个用逗号分隔,直接回车表示允许所有人): 12345678
⚠️ 注意:你选择了限制模式,只有以下用户能与 Bot 交互:
- 用户 ID: 12345678
第三步:高级选项(可选)
是否启用群组模式?Bot 可以在群组中被 @ 提到时响应 [y/N]: y
配置预览:
平台: Telegram
Bot Token: 123456789:XXX...XXX(已隐藏)
允许用户: 12345678
群组模式: 已启用
确认保存配置? [Y/n]: Y
✅ Telegram 配置已保存到 ~/.hermes/config.yaml
提示:运行 `hermes gateway start` 启动网关
Tips setup 向导会自动验证你输入的 Token 格式是否正确。如果提示"格式错误",请检查是不是多复制了一个空格,或者漏掉了冒号后面的部分。
2.3 Gateway 的工作原理
要真正掌握多平台接入,你需要理解 Gateway 的"黑盒"里到底在发生什么。让我们拆开来看:
2.3.1 整体架构图
┌─────────────────────────────────────────────────────────────┐
│ Hermes Core Engine │
│ (AI 大脑:推理、记忆、工具调用) │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Gateway Manager │
│ (统一消息格式转换、会话管理、权限控制) │
└─────────────────────────────────────────────────────────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Telegram │ │ 飞书 │ │ Discord │
│ Adapter │ │ Adapter │ │ Adapter │
└──────────────┘ └──────────────┘ └──────────────┘
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Telegram API │ │ 飞书 Open │ │ Discord API │
│ (Webhook │ │ API │ │ (WebSocket) │
│ /Polling) │ │ (Event Hub) │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
2.3.2 消息流转的完整流程
当一条消息从 Telegram 发过来时,整个处理流程是这样的:
第一步:接收(Receive)
Telegram Adapter 通过 Webhook 或 Long Polling 持续监听 Telegram 服务器的消息推送。当有新消息到达时,Adapter 接收到的是一个 JSON 对象:
{
"update_id": 123456789,
"message": {
"message_id": 1,
"from": {
"id": 12345678,
"first_name": "张三",
"username": "zhangsan"
},
"chat": {
"id": 12345678,
"type": "private"
},
"date": 1704067200,
"text": "帮我查一下明天北京的天气"
}
}
第二步:标准化(Normalize)
Gateway Manager 把这个平台特定的 JSON 转换成 Hermes 内部的标准消息格式:
{
"message_id": "msg_tg_123456789_1",
"platform": "telegram",
"channel_id": "12345678",
"sender": {
"id": "12345678",
"name": "张三",
"username": "zhangsan"
},
"content": {
"type": "text",
"text": "帮我查一下明天北京的天气"
},
"timestamp": "2024-01-01T00:00:00Z",
"reply_to": null
}
注意到这里做了几件事:
- 生成了全局唯一的 message_id
- 统一了 platform 字段标识来源
- 提取了发送者信息
- 把不同平台的消息内容结构统一了
第三步:权限检查(Auth)
Gateway Manager 检查 sender.id 是否在 allowlist 中。如果不在,直接丢弃这条消息(或者回复"你没有权限使用此服务")。
第四步:上下文加载(Context)
Gateway Manager 从记忆系统中加载这个用户的会话历史:
- 查找 user_id = "12345678" 的短期记忆
- 加载最近 10 轮对话上下文
- 检查是否有正在进行的任务流
第五步:交给 AI 处理(Process)
标准消息被送进 Hermes Core Engine,AI 开始思考、调用工具、生成回复。
第六步:格式化输出(Format)
AI 生成的是纯文本回复,Gateway Manager 需要把它转成目标平台支持的格式。比如:
AI 生成的原始回复:
"北京明天的天气预报:\n\n**天气**:晴转多云\n**温度**:15°C ~ 22°C\n**风力**:东北风 3-4 级\n\n建议穿薄外套。"
转成 Telegram 格式:
- Telegram 原生支持 MarkdownV2,可以直接发送
转成飞书格式:
- 需要封装成富文本卡片(Interactive Card)
第七步:发送(Send)
对应的 Adapter 调用平台 API,把回复发回去。
注意 如果你在手机上用 Telegram 发了一条消息,然后在电脑前用飞书继续同话题聊天,Gateway 会自动把两条消息关联到同一个
session_id下。这意味着 AI 知道"刚才"指的是跨平台的上一条消息。
2.4 config.yaml 中的 gateway 配置项
虽然 setup 向导能帮你完成大部分配置,但了解 config.yaml 的结构对进阶排错和自定义非常重要。
Gateway 的配置位于 ~/.hermes/config.yaml 文件的 gateway 节下:
# ~/.hermes/config.yaml
# ==================== Gateway 全局配置 ====================
gateway:
# 网关监听地址和端口
# 如果你希望外网能访问(比如接收 Webhook),设为 "0.0.0.0"
host: "127.0.0.1"
port: 8080
# 日志级别:debug, info, warning, error
log_level: "info"
# 消息队列配置
queue:
max_size: 1000 # 最大队列长度,超过将丢弃旧消息
worker_count: 4 # 并行处理消息的工作线程数
timeout: 300 # 单条消息处理超时(秒)
# 全局安全设置
security:
# 全局允许列表(优先级低于各平台的 allowlist)
# 如果设置了,只有这些用户能使用任何平台的 Bot
global_allowlist: []
# 消息内容过滤(正则表达式列表)
# 匹配到的消息会被拒绝
blocked_patterns:
- "(?i)(密码|password)\s*[=:]\s*\S+"
# 文件传输限制
max_file_size: "10MB"
allowed_file_types: ["txt", "pdf", "jpg", "png", "docx"]
# ==================== 各平台具体配置 ====================
gateways:
# Telegram 配置
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}" # 从环境变量读取(推荐!)
# 或者硬编码(不推荐,安全性差):
# bot_token: "123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
# 接收消息的方式:"polling" 或 "webhook"
receive_mode: "polling"
# 如果是 webhook 模式,需要配置以下项
webhook_url: "https://your-domain.com/webhook/telegram"
webhook_secret: "${TELEGRAM_WEBHOOK_SECRET}"
# 允许列表(空数组表示允许所有人)
allowlist:
- "12345678" # 用户数字 ID
- "87654321"
# 群组模式
group_mode:
enabled: true
# 只有在消息中 @ 提到 Bot 时才响应
require_mention: true
# Bot 的 @用户名(会自动检测,也可以手动指定)
bot_username: "HermesAssistantBot"
# 消息格式
formatting:
# 使用 Markdown 还是纯文本
parse_mode: "MarkdownV2"
# 是否自动把长消息拆分成多条
split_long_messages: true
max_message_length: 4096
# 飞书配置
lark:
enabled: true
app_id: "${LARK_APP_ID}"
app_secret: "${LARK_APP_SECRET}"
# 加密密钥(事件订阅用)
encrypt_key: "${LARK_ENCRYPT_KEY}"
# 事件订阅的验证 Token
verification_token: "${LARK_VERIFICATION_TOKEN}"
receive_mode: "webhook"
webhook_url: "https://your-domain.com/webhook/lark"
allowlist: []
# 消息卡片配置
card_mode: true
# Discord 配置
discord:
enabled: true
bot_token: "${DISCORD_BOT_TOKEN}"
receive_mode: "websocket"
allowlist: []
# 更多平台...
Tips 永远不要把 Token 硬编码在 config.yaml 里! 上面的示例中使用了
${VAR_NAME}语法,Hermes 会自动从环境变量中读取。正确的做法是在你的 shell 配置文件(如~/.zshrc或~/.bashrc)中设置:bash export TELEGRAM_BOT_TOKEN="123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
2.5 多平台同时接入的配置方法
让 Hermes 同时接入多个平台非常简单——你只需要在 gateways 下配置多个平台,并都设置 enabled: true:
gateways:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
allowlist: ["12345678"]
lark:
enabled: true
app_id: "${LARK_APP_ID}"
app_secret: "${LARK_APP_SECRET}"
allowlist: []
discord:
enabled: true
bot_token: "${DISCORD_BOT_TOKEN}"
allowlist: []
email:
enabled: true
imap_server: "imap.gmail.com"
imap_port: 993
username: "${EMAIL_USERNAME}"
password: "${EMAIL_PASSWORD}"
allowlist:
- "boss@company.com"
- "team@company.com"
启动网关后,你会看到类似这样的输出:
$ hermes gateway start
🌐 Hermes Gateway 启动中...
══════════════════════════════════════════════════
[✓] Telegram - 已连接 (@HermesAssistantBot)
[✓] 飞书 - 已连接 (应用: Hermes Assistant)
[✓] Discord - 已连接 (Bot: Hermes#1234)
[✗] Email - 连接失败: IMAP 认证错误,请检查密码
4 个平台已配置,3 个正常运行,1 个异常
消息处理线程:4
监听地址:127.0.0.1:8080
按 Ctrl+C 停止网关
注意 当多个平台同时在线时,来自任何平台的消息都会进入同一个消息队列,由 AI 统一处理。但每个平台的会话上下文是独立的——你在 Telegram 里的聊天历史不会自动出现在飞书里,除非两个平台绑定了同一个用户 ID(通过
user_mapping配置)。
2.6 本章小结
在本章中,我们学习了:
- 多平台接入的意义:让 AI 从"电脑里的程序"变成"随身助理"
- Gateway 架构:消息路由、格式转换、状态同步三大核心能力
- 命令行工具:
hermes gateway setup/start/stop/status的日常用法 - 配置文件:config.yaml 的完整结构和最佳实践
- 多平台并行:同时接入多个平台的配置方法
下一章,我们将从最流行的 Telegram 开始,手把手教你完成第一个平台的接入。
3. Telegram 接入(最流行,详细教程)
Telegram 是 Hermes 社区中使用最广泛的平台,原因很直观:免费、稳定、API 友好、隐私保护做得好,而且在中国以外的地区普及率极高。如果你是第一次接入多平台,强烈建议从 Telegram 开始。
3.1 创建 Telegram Bot(@BotFather 全流程)
Telegram 提供了一个官方的"机器人之父"——@BotFather,专门用来创建和管理 Bot。整个过程就像去民政局办营业执照一样简单。
步骤一:找到 @BotFather
打开 Telegram(手机 App 或桌面版都可以),在顶部的搜索框里输入 @BotFather。注意认准蓝勾认证标志,别加到假冒的机器人。
步骤二:开始对话
点击 @BotFather 后,发送 /start 开始对话。你会看到一长串命令列表。
步骤三:创建新 Bot
发送 /newbot 命令:
你: /newbot
BotFather: Alright, a new bot. How are we going to call it?
Please choose a name for your bot.
你: Hermes 智能助手
BotFather: Good. Now let's choose a username for your bot.
It must end in `bot`. Like this, for example: TetrisBot or tetris_bot.
你: HermesAssistantBot
BotFather: Done! Congratulations on your new bot.
You will find it at t.me/HermesAssistantBot
...
Use this token to access the HTTP API:
123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
...
这里有两个名字需要注意区分:
| 名称类型 | 示例 | 用途 |
|---|---|---|
| 显示名称(Name) | Hermes 智能助手 | 用户在聊天列表中看到的名字,可以包含中文和空格 |
| 用户名(Username) | HermesAssistantBot | 唯一标识,必须以 bot 结尾,用于 @ 提及和链接 |
步骤四:保存 Token
BotFather 发给你的那一串 123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 就是 Bot Token。这是你的 Bot 的"身份证+密码",一定要妥善保管:
# 保存到环境变量(推荐)
export TELEGRAM_BOT_TOKEN="123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
# 为了持久化,添加到 shell 配置文件
echo 'export TELEGRAM_BOT_TOKEN="123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"' >> ~/.zshrc
source ~/.zshrc
注意 Token 泄露 = 机器人被劫持。 任何人拿到你的 Token 就能控制你的 Bot,读取所有消息、冒充你的身份发消息。如果不小心泄露了,立刻找 @BotFather 发送
/revoke命令重置 Token。
步骤五(可选):设置头像和描述
你: /setuserpic
BotFather: Choose a bot to change profile photo.
你: @HermesAssistantBot
[上传一张图片]
你: /setdescription
BotFather: Choose a bot to change description.
你: @HermesAssistantBot
你: 我是你的 AI 智能助手,基于 Hermes 架构构建。
我可以帮你查资料、写代码、管理日程,随时为你效劳!
Tips 一个好的 Bot 描述能让用户一眼明白它是干嘛的。建议写清楚:1) 这是什么;2) 能做什么;3) 基于什么技术(比如"Powered by Hermes")。
3.2 获取 Bot Token
其实上一步你已经拿到了 Token。这里单独列出来,是为了强调几个重要的最佳实践:
Token 的安全存储方案对比:
| 存储方式 | 安全性 | 便利性 | 推荐度 |
|---|---|---|---|
| 硬编码在 config.yaml | ⭐ 极差 | ⭐⭐⭐ 方便 | ❌ 绝不推荐 |
| 环境变量 | ⭐⭐⭐ 好 | ⭐⭐ 中等 | ✅ 推荐 |
| 系统密钥管理器(Keychain) | ⭐⭐⭐⭐⭐ 极好 | ⭐⭐ 中等 | ✅✅ 最推荐 |
| 密码管理器(1Password 等) | ⭐⭐⭐⭐ 很好 | ⭐⭐ 中等 | ✅ 推荐 |
在 macOS 上,你可以用系统 Keychain 来存储 Token:
# 保存到 Keychain
security add-generic-password -s "hermes-telegram-token" \
-a "$(whoami)" -w "123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
# 从 Keychain 读取(Hermes 支持这种语法)
export TELEGRAM_BOT_TOKEN="$(security find-generic-password -s "hermes-telegram-token" -w)"
3.3 获取数字用户 ID(@userinfobot)
配置 allowlist 时,你需要的是数字用户 ID,不是你的 @用户名。这是 Telegram 设计的一个容易混淆的地方。
获取方法很简单:
- 在 Telegram 搜索
@userinfobot - 发送
/start或任意消息 - 它会回复你的用户信息:
@userinfobot:
Id: 12345678
First: 张三
Lang: zh-hans
这里的 Id: 12345678 就是你要的数字用户 ID。
常见问题 Q: 为什么不能用 @用户名做 allowlist? A: 因为 @用户名是可以修改的,而数字 ID 终身不变。用数字 ID 更安全、更稳定。
如果你想查看群里其他人的 ID,可以使用 @getidsbot:
- 把 @getidsbot 加到群里
- 随便发一条消息
- 它会回复包含所有成员 ID 的信息
3.4 配置 Hermes
拿到 Token 和用户 ID 后,配置 Hermes 只需要一行命令:
# 方法1:使用交互式向导
$ hermes gateway setup
# 然后选择 Telegram,按提示输入 Token 和 allowlist
# 方法2:直接用命令行设置
$ hermes config set TELEGRAM_BOT_TOKEN "123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
$ hermes config set TELEGRAM_ALLOWLIST "12345678"
# 方法3:手动编辑 config.yaml
$ nano ~/.hermes/config.yaml
# 在 gateways.telegram 下填入配置
完整的 Telegram 配置示例:
gateways:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
receive_mode: "polling" # 个人用户建议 polling
allowlist:
- "12345678" # 你的用户 ID
group_mode:
enabled: true
require_mention: true
formatting:
parse_mode: "MarkdownV2"
split_long_messages: true
3.5 启动网关与测试
配置完成后,启动网关并测试:
# 启动网关(前台模式,便于观察日志)
$ hermes gateway start
# 你应该看到类似输出:
🌐 Hermes Gateway 启动中...
[✓] Telegram - 已连接 (@HermesAssistantBot)
消息处理线程:4
监听地址:127.0.0.1:8080
# 打开 Telegram,给你的 Bot 发消息
# 你: 你好
# Bot: 你好!我是 Hermes 智能助手,很高兴为你服务。
如果启动失败,可以用调试模式查看详细日志:
# 设置调试日志级别
$ hermes config set GATEWAY_LOG_LEVEL debug
# 重新启动并查看日志
$ hermes gateway start 2>&1 | tee gateway.log
3.6 安全配置:允许列表(Allowlist)详解
Allowlist 是 Gateway 的第一道安全防线。它的作用很简单:只有列表里的用户能与你的 Bot 交互。
为什么必须设置 Allowlist?
想象你没设置 allowlist,然后你的 Bot Token 不小心泄露到了 GitHub 上(别笑,这种事每天都在发生)。黑客拿到 Token 后,可以:
- 查询你的 Bot 收到了哪些消息
- 冒充你的 Bot 给用户发钓鱼链接
- 利用你的 Bot 做跳板攻击其他系统
- 消耗你的 API 额度(如果接了付费模型)
设置了 allowlist 后,即使 Token 泄露,黑客也无法与 Bot 交互——因为他们的用户 ID 不在白名单里。
Allowlist 配置详解
gateways:
telegram:
# 方式1:仅允许特定用户
allowlist:
- "12345678" # 你的 ID
- "87654321" # 你队友的 ID
# 方式2:允许特定群组(把群组 ID 当作用户 ID)
allowlist:
- "-1001234567890" # 群组 ID(注意负号!)
# 方式3:允许所有人(不推荐用于生产环境)
allowlist: []
# 方式4:动态 allowlist(从外部 API 加载)
allowlist_url: "https://your-company.com/api/hermes-users"
allowlist_refresh_interval: 3600 # 每小时刷新一次
注意 群组 ID 通常是以
-100开头的负数。在 Telegram 中,超级群组(Supergroup)的 ID 格式是-100xxxxxxxxxx。如果你用错了格式,群组消息会收不到。
3.7 群组中使用 Bot
在群组中使用 Bot 和在私聊中略有不同,主要体现在权限管理和触发机制上。
把 Bot 加到群组
- 在 Telegram 中打开目标群组
- 点击群组名称 → 添加成员
- 搜索你的 Bot 用户名(如
@HermesAssistantBot) - 添加后,Bot 会收到一条系统消息,告知它已被加入群组
群组权限配置
你需要给 Bot 设置合适的权限。在群组设置 → 管理员 → 你的 Bot 中:
✅ 删除消息 —— 如果需要 Bot 管理群规
✅ 限制用户 —— 如果需要自动禁言功能
✅ 置顶消息 —— 如果需要发布公告
✅ 发送消息 —— 必须开启!
✅ 发送媒体 —— 如果需要发图片/文件
✅ 发送投票 —— 如果需要投票功能
❌ 保持匿名 —— 建议关闭,方便识别
❌ 添加新管理员 —— 绝对不能给 Bot!
触发机制
在群组中,默认要求用户 @ 提到 Bot 才会响应:
用户A: 大家好
用户A: @HermesAssistantBot 帮我总结一下今天的讨论
Bot: [回复用户A] 好的,今天的讨论要点如下:...
用户B: Hermes 帮我查一下天气 ← 没有 @,Bot 不会响应
你也可以关闭 require_mention,让 Bot 响应群里的所有消息:
group_mode:
enabled: true
require_mention: false # ⚠️ 慎用!会产生大量 API 调用
注意 在大型群组中关闭
require_mention会导致 Bot 对每条消息都进行处理,可能迅速耗尽你的 API 额度。建议只在 10 人以下的小群中使用。
3.8 富文本消息、文件传输、语音消息
Telegram 支持丰富的消息类型,Hermes 对这些类型的支持情况如下:
富文本消息
Hermes 支持在 Telegram 中发送格式化的 Markdown 消息:
Bot 发送的消息示例:
**加粗文本**
*斜体文本*
`行内代码`
```代码块```
[超链接](https://example.com)
配置方法:
formatting:
parse_mode: "MarkdownV2" # 或 "HTML"
常见问题 Q: 为什么有些特殊字符显示不出来? A: Telegram 的 MarkdownV2 模式要求对某些字符进行转义:
_ * [ ] ( ) ~> # + - = | { } . !`。如果你发现格式错乱,检查是否忘了转义。
文件传输
用户可以给 Bot 发送文件,Hermes 会下载并处理:
用户: [上传文件:report.pdf]
Bot: 已收到文件 report.pdf(2.3MB),正在分析...
Bot: 这是这份报告的核心观点:...
文件处理配置:
security:
max_file_size: "10MB"
allowed_file_types: ["txt", "pdf", "docx", "jpg", "png"]
语音消息
Telegram 支持语音消息输入和输出:
# 开启语音输入(用户发语音,AI 识别文字并回复)
voice_input:
enabled: true
language: "zh-CN" # 语音识别语言
# 开启语音输出(AI 用语音回复)
voice_output:
enabled: true
voice: "alloy" # 语音音色
用户发送语音消息后,Hermes 会自动: 1. 下载语音文件(.ogg 格式) 2. 调用语音识别 API 转文字 3. 把文字送进 AI 处理 4. 生成回复文本 5. (如果开启 voice_output)把回复转成语音发回
Tips 语音输入特别适合开车、做饭、健身时"动口不动手"的场景。但注意语音识别对环境噪音敏感,建议在相对安静的环境下使用。
3.9 常见问题排障(10个)
问题1:Bot 完全没有响应
排查步骤:
# 1. 检查网关是否启动
$ hermes gateway status
# 2. 检查 Bot Token 是否正确
$ curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getMe"
# 如果返回 {"ok":true,...},Token 有效;如果 401 Unauthorized,Token 错了
# 3. 检查 allowlist
$ hermes config get TELEGRAM_ALLOWLIST
# 确认你的用户 ID 在列表中
# 4. 查看日志
$ hermes gateway logs --tail 50
常见原因: - Token 输错或已失效 - 用户 ID 不在 allowlist - 网关进程崩溃了 - 网络不通(国内可能需要代理)
问题2:可以收到消息但发不出去
原因: Bot 被 Telegram 限制了发送消息(通常是新注册的 Bot 有频率限制)。
解决: 等 24 小时后再试,或者给 BotFather 发送 /setprivacy 设置为 Disabled。
问题3:群组里 Bot 不响应
排查:
1. 确认 Bot 已经被添加为群组成员
2. 确认 Bot 有发送消息的权限
3. 检查 require_mention 设置,确认你正确 @ 了 Bot
4. 确认群组 ID 在 allowlist 中(如果是负数 ID,检查是否写对了 -100 前缀)
问题4:中文消息显示乱码
解决: 在 config.yaml 中设置字符编码:
gateways:
telegram:
encoding: "utf-8"
问题5:文件上传失败
排查:
1. 检查文件大小是否超过 max_file_size
2. 检查文件类型是否在 allowed_file_types 中
3. Telegram 对 Bot 有文件大小限制(通常 20MB)
问题6:Webhook 模式收不到消息
排查: 1. 确认你的服务器有公网 IP 和 HTTPS 证书 2. 确认 webhook_url 可访问(用浏览器或 curl 测试) 3. 检查防火墙是否放行了 443 端口
# 测试 Webhook 是否可达
curl -X POST https://your-domain.com/webhook/telegram \
-H "Content-Type: application/json" \
-d '{"test": true}'
问题7:Polling 模式频繁断线
原因: 网络不稳定,或同时运行了多个 Gateway 实例。
解决:
# 检查是否有多个 hermes gateway 进程
ps aux | grep hermes
# 如果有多个,杀掉所有进程后重新启动
killall hermes-gateway
hermes gateway start
问题8:AI 回复很慢
排查:
1. 检查 AI 模型是否响应慢(直接测试 API)
2. 检查是否有大量消息在队列中:hermes gateway status
3. 增加 worker 数量:
yaml
queue:
worker_count: 8 # 从 4 增加到 8
问题9:Token 泄露了怎么办
紧急处理:
1. 立即找 @BotFather 发送 /revoke
2. 选择你的 Bot
3. BotFather 会生成新 Token,旧 Token 立即失效
4. 更新你的环境变量和配置
问题10:如何查看 Bot 的 webhook 信息
curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getWebhookInfo"
这个 API 会返回当前 webhook 的状态、挂起的更新数量、最后错误信息等,是排障的利器。
本章小结(Telegram 章节) 我们学习了 Telegram 接入的完整流程:创建 Bot、获取 Token、配置 allowlist、启动网关。还深入了解了群组使用、富文本、文件传输、语音消息等高级功能,以及 10 个常见问题的排障方案。现在你的 Hermes 已经可以通过 Telegram 随时响应你的指令了。
4. 飞书接入(国内最方便)
对于中国用户来说,飞书(Lark)是接入 Hermes 最方便的选择。 reasons 很简单:不用翻墙、服务器在国内、API 文档全中文、企业级稳定性。如果你的团队已经在用飞书,那接入 Hermes 后,团队成员可以直接在飞书里和 AI 对话,不需要额外安装任何 App。
4.1 飞书企业自建应用创建流程
飞书对第三方接入采用了"自建应用"的模式。你需要在飞书开放平台创建一个属于你自己的应用,然后给这个应用授权访问消息等能力。
步骤一:进入飞书开放平台
- 打开浏览器,访问 https://open.feishu.cn/
- 用企业管理员账号登录(注意:必须是企业管理员,普通员工没有创建应用的权限)
注意 如果你不是企业管理员,可以让管理员帮你操作,或者创建一个测试企业(免费)。创建测试企业的方法:飞书 App → 我的 → 创建或加入企业 → 创建企业 → 选择"用于开发测试"。
步骤二:创建企业自建应用
- 点击"开发者后台"
- 点击"创建企业自建应用"
- 填写应用信息:
- 应用名称:Hermes 智能助手(可以自定义)
- 应用描述:基于 Hermes 架构的 AI 智能助手
- 应用图标:上传一张 512x512 的 PNG 图片
- 点击"确定创建"
步骤三:获取 App ID 和 App Secret
创建完成后,你会进入应用详情页。在"凭证与基础信息"栏目下:
App ID: cli_xxxxxxxxxxxxxxxx
App Secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
这两个值就是你的"用户名"和"密码",保存好它们:
export LARK_APP_ID="cli_xxxxxxxxxxxxxxxx"
export LARK_APP_SECRET="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
4.2 App ID 和 App Secret 获取
实际上上一步已经拿到了这两个值。这里重点强调安全存储:
# 保存到 macOS Keychain
security add-generic-password -s "hermes-lark-app-id" \
-a "$(whoami)" -w "cli_xxxxxxxxxxxxxxxx"
security add-generic-password -s "hermes-lark-app-secret" \
-a "$(whoami)" -w "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
# 然后在 shell 配置文件中添加读取逻辑
# ~/.zshrc:
export LARK_APP_ID="$(security find-generic-password -s "hermes-lark-app-id" -w)"
export LARK_APP_SECRET="$(security find-generic-password -s "hermes-lark-app-secret" -w)"
4.3 hermes gateway setup 选飞书
$ hermes gateway setup
🌐 Hermes Gateway 配置向导
══════════════════════════════════════════
请选择要接入的平台:
...
[2] 飞书 (Lark) - 国内企业协作首选
...
请输入数字选择: 2
📱 飞书配置
──────────────────────────────────────────
请输入 App ID: cli_xxxxxxxxxxxxxxxx
请输入 App Secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
✅ 凭证验证通过,应用名称:Hermes 智能助手
请选择接收模式:
[1] Webhook - 需要公网服务器(推荐生产环境)
[2] 事件回调 - 飞书主动推送事件
请输入数字选择: 2
事件订阅配置:
事件订阅 URL: https://your-domain.com/webhook/lark
验证 Token: xxxxxxxx
加密密钥: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
请复制以下信息到飞书开放平台的事件订阅配置中:
Request URL: https://your-domain.com/webhook/lark
Verification Token: xxxxxxxx
4.4 事件订阅配置
飞书使用"事件订阅"机制来推送消息。你需要在飞书开放平台中配置一个回调 URL,飞书会把用户消息推送到这个 URL。
配置步骤:
- 在飞书开放平台 → 你的应用 → 事件订阅
- 设置 Request URL:
- 如果你有自己的服务器:
https://your-domain.com/webhook/lark - 如果你在内网/本地开发:使用 ngrok 穿透
bash # 安装 ngrok brew install ngrok # 注册并获取 authtoken ngrok config add-authtoken xxxxx # 启动穿透(把本地 8080 映射到公网) ngrok http 8080 # 会得到类似 https://abc123.ngrok-free.app 的地址 - 设置 Verification Token:从 Hermes 配置向导中复制
- 设置 Encrypt Key(可选但推荐):用于加密传输内容
订阅需要的事件:
在"事件订阅"页面,添加以下事件:
✅ 接收消息(v2.0) —— 必须!接收用户消息
✅ 应用被用户添加至群聊 —— 用于群组场景
✅ 用户进入会话 —— 可选,用于欢迎语
✅ 消息被撤回 —— 可选
4.5 权限设置(最小权限原则)
安全的第一原则是最小权限——只给应用它必须的权限,不多给一寸。
在飞书开放平台 → 你的应用 → 权限管理,申请以下权限:
必要权限(必须):
✅ 获取与发送单聊、群聊消息(im:chat:readonly, im:message:send_as_bot)
✅ 获取用户 user ID(contact:user.employee_id:readonly)
推荐权限(常用功能):
✅ 获取用户信息(contact:user.base:readonly)
✅ 获取群组信息(im:chat:readonly)
✅ 上传文件(drive:file:write)
可选权限(按需申请):
✅ 读取日历(calendar:calendar:readonly)
✅ 读取文档(docx:document:readonly)
注意 每次修改权限后,必须点击"申请发布" → "创建版本" → "保存",然后企业管理员在"应用审核"中批准,权限才能生效。这是很多新手卡住的地方。
4.6 消息卡片与富文本
飞书的强项是"消息卡片"(Interactive Card),它支持比纯文本丰富得多的展示形式。
Hermes 可以自动把 AI 的回复渲染成飞书卡片:
gateways:
lark:
card_mode: true
card_template: "default"
示例效果——当 AI 回复天气查询时:
┌─────────────────────────────────────┐
│ ☀️ 北京明日天气预报 │
├─────────────────────────────────────┤
│ 天气:晴转多云 │
│ 温度:15°C ~ 22°C │
│ 风力:东北风 3-4 级 │
│ 空气质量:良 │
├─────────────────────────────────────┤
│ [查看详情] [分享] │
└─────────────────────────────────────┘
Tips 飞书卡片的消息长度限制比纯文本宽松得多。如果你的 AI 回复特别长(比如一份完整报告),开启
card_mode能获得更好的阅读体验。
4.7 常见问题排障
问题1:事件订阅验证失败
原因: Request URL 不可达,或返回格式不正确。
解决: 1. 确认 URL 可以从公网访问(用浏览器或 curl 测试) 2. 确认返回了正确的 challenge 响应 3. 检查防火墙和 HTTPS 证书
# 测试回调 URL
curl -X POST https://your-domain.com/webhook/lark \
-H "Content-Type: application/json" \
-d '{"challenge": "test123", "type": "url_verification"}'
# 期望返回:
# {"challenge": "test123"}
问题2:消息能收到但发不出去
原因: 没有申请 im:message:send_as_bot 权限,或权限未审批。
解决: 1. 检查权限管理页面是否已申请发送消息权限 2. 检查应用是否已发布并通过审批 3. 检查 Bot 是否被用户添加到会话中
问题3:用户 ID 找不到
飞书的用户标识体系比较复杂:
| ID 类型 | 示例 | 用途 |
|---|---|---|
user_id |
ou_xxxxxxxxxxxxxxxx |
飞书内部用户 ID |
union_id |
on_xxxxxxxxxxxxxxxx |
企业内唯一 ID |
open_id |
ou_xxxxxxxxxxxxxxxx |
应用维度唯一 ID |
employee_id |
12345 |
员工工号 |
Hermes 的 allowlist 使用的是 user_id(以 ou_ 或 on_ 开头)。
问题4:应用在群里收不到消息
解决: 1. 把 Bot 添加到群里(在群里 @Bot 并选择"添加到群聊") 2. 确保订阅了"接收消息"事件 3. 检查应用是否有群聊消息的权限
问题5:企业管理员不审批怎么办
如果你的应用卡在"待审核"状态: 1. 联系企业管理员手动审批 2. 或者创建测试企业自己当管理员 3. 飞书开放平台也有"测试企业和人员"功能,可以免审批测试
本章小结(飞书章节) 我们学习了飞书接入的完整流程:创建自建应用、获取 App ID/Secret、配置事件订阅、设置最小权限。飞书的消息卡片能力让 AI 回复的展示效果更上一层楼。对于国内用户来说,飞书是团队协作场景下接入 Hermes 的最佳选择。
5. 微信接入
微信是国内使用最广泛的即时通讯工具,但它对第三方 Bot 的限制也最严格。微信生态有三个主要接入点:企业微信、微信公众号、以及个人微信(需第三方桥接)。
5.1 企业微信自建应用接入教程
企业微信是微信生态中对第三方应用最友好的入口,适合企业内部使用。
步骤一:注册企业微信
- 访问 https://work.weixin.qq.com/
- 注册一个企业(可以用个人身份注册)
- 进入"应用管理"
步骤二:创建自建应用
- 应用管理 → 自建 → 创建应用
- 填写应用信息:
- 应用名称:Hermes 智能助手
- 应用介绍:AI 办公助手
- 可见范围:选择可以使用此应用的部门/成员
- 上传应用 Logo
- 点击"创建应用"
步骤三:获取凭证
创建完成后,在应用详情页获取:
AgentId: 1000002
Secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
同时还需要企业 ID:
- 我的企业 → 企业 ID
- 复制
wwxxxxxxxxxxxxxxxx格式的企业 ID
步骤四:配置 Hermes
gateways:
wecom:
enabled: true
corp_id: "${WECOM_CORP_ID}"
agent_id: "${WECOM_AGENT_ID}"
secret: "${WECOM_SECRET}"
receive_mode: "webhook"
webhook_url: "https://your-domain.com/webhook/wecom"
token: "${WECOM_TOKEN}"
encoding_aes_key: "${WECOM_AES_KEY}"
allowlist: []
步骤五:配置接收消息
在企业微信应用详情 → 接收消息 → 设置 API:
URL: https://your-domain.com/webhook/wecom
Token: 随机生成一个字符串(和 config.yaml 中的 token 一致)
EncodingAESKey: 随机生成或手动输入(和 config.yaml 中的 encoding_aes_key 一致)
消息加解密:推荐选择"安全模式"
注意 企业微信的消息加密比较严格,Token 和 AES Key 必须完全匹配。如果验证失败,仔细检查大小写和空格。
5.2 微信公众号接入方式
微信公众号(订阅号/服务号)也可以接入 Hermes,适合做客服和内容推送。
前提条件: - 一个已认证的微信公众号(个人订阅号功能受限) - 服务器和域名(接收微信推送)
配置步骤:
- 微信公众平台 → 开发 → 基本配置
- 获取 AppID 和 AppSecret
- 设置服务器配置:
- URL:
https://your-domain.com/webhook/wechat-mp - Token:自定义,和 Hermes 配置一致
- EncodingAESKey:随机生成
- 消息加解密模式:明文/兼容/安全
- 在 Hermes config.yaml 中配置:
gateways:
wechat_mp:
enabled: true
app_id: "${WECHAT_MP_APP_ID}"
app_secret: "${WECHAT_MP_APP_SECRET}"
token: "${WECHAT_MP_TOKEN}"
encoding_aes_key: "${WECHAT_MP_AES_KEY}"
注意 微信公众号有严格的接口频率限制:普通订阅号每天只能发 1 条群发消息,服务号每月 4 条。用户主动发消息没有限制,但回复必须在 48 小时内。这些限制使得微信公众号不适合高频对话场景,更适合做"问答客服"。
5.3 个人微信接入方案(第三方桥接)
个人微信(就是你在手机上天天用的那个微信)没有官方 Bot API。如果有人说能"直接接入个人微信",那一定是在用非官方的第三方方案。
目前主流的方案有以下几种:
| 方案 | 原理 | 稳定性 | 风险 |
|---|---|---|---|
| iPad 协议 | 模拟 iPad 客户端登录 | ⭐⭐ 一般 | 可能被封号 |
| Windows Hook | 注入 Windows 微信进程 | ⭐ 差 | 极易被封 |
| Android Hook | 注入 Android 微信 | ⭐ 差 | 极易被封 |
| 企业微信互通 | 通过企业微信连接微信 | ⭐⭐⭐ 较好 | 较低 |
注意 使用非官方方案接入个人微信存在封号风险! 微信对此类行为的打击力度一直在加强。建议优先使用企业微信或微信公众号作为替代方案。
如果你确实需要个人微信接入,推荐使用基于 gewe 或 wechaty 的方案,但它们需要额外部署中间件服务:
gateways:
wechat_puppet:
enabled: true
puppet_type: "wechaty-puppet-wechat"
puppet_endpoint: "http://localhost:8788"
# 需要额外运行一个 wechaty gateway 服务
5.4 限制与注意事项
微信生态接入的限制汇总:
企业微信:
✓ 官方支持,稳定可靠
✓ 适合企业内部使用
✗ 外部客户使用需要购买接口许可
✗ 消息模板审核严格
微信公众号:
✓ 官方支持,用户基数大
✗ 频率限制严格
✗ 需要认证才能使用高级接口
✗ 48小时回复窗口限制
个人微信(第三方):
✗ 无官方 API
✗ 封号风险
✗ 需要额外部署中间件
✗ 不稳定
本章小结(微信章节) 企业微信是微信生态中接入 Hermes 的最佳选择,官方支持、稳定可靠。微信公众号适合做轻量级客服。个人微信接入风险较高,不建议生产环境使用。
6. Discord 接入
Discord 是全球游戏玩家和开发者社区的首选平台。如果你管理着一个开源社区、游戏公会或者技术讨论群,把 Hermes 接入 Discord 能让成员随时向 AI 提问。
6.1 Discord Bot 创建流程
步骤一:进入 Discord Developer Portal
- 访问 https://discord.com/developers/applications
- 用 Discord 账号登录
步骤二:创建应用
- 点击"New Application"
- 输入应用名称:Hermes Assistant
- 点击"Create"
步骤三:添加 Bot
- 左侧菜单 → "Bot" → "Add Bot"
- 点击"Yes, do it!"
步骤四:获取 Token
在 Bot 页面,点击"Reset Token",复制新生成的 Token:
export DISCORD_BOT_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxx.xxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxx"
注意 Discord 的 Token 格式是三段式的,中间有
.分隔。如果 Token 泄露,立即 Reset Token,旧的会立即失效。
6.2 Token 获取与权限配置
设置 Bot 权限:
在"Bot"页面,打开以下开关:
✅ Presence Intent —— 获取在线状态
✅ Server Members Intent —— 获取服务器成员列表
✅ Message Content Intent —— 必须!读取消息内容
注意
Message Content Intent是最容易被遗漏的选项。如果不开启,Bot 只能收到"有人发消息了"的事件,但看不到消息内容。这是 Discord 2022 年后的安全策略变更。
生成 OAuth2 邀请链接:
- 左侧菜单 → "OAuth2" → "URL Generator"
- 在 Scopes 中选择
bot - 在 Bot Permissions 中选择:
✅ Send Messages ✅ Send Messages in Threads ✅ Read Message History ✅ Use Slash Commands ✅ Attach Files ✅ Embed Links ✅ Add Reactions - 复制生成的 URL,在浏览器中打开,邀请 Bot 加入你的服务器
6.3 频道管理与权限
Discord 的权限模型比较复杂,分为服务器级、频道级和角色级。
建议的权限设置:
- 创建一个专门给 Bot 使用的角色(如"AI Assistant")
- 在频道设置中:
- 允许 Bot 角色:查看频道、发送消息、读取历史、嵌入链接
- 拒绝 Bot 角色:管理频道、管理消息、踢人、禁言
配置 Hermes:
gateways:
discord:
enabled: true
bot_token: "${DISCORD_BOT_TOKEN}"
receive_mode: "websocket"
allowlist: []
# 只在特定频道响应(可选)
allowed_channels:
- "1234567890123456789"
# 忽略特定频道
ignored_channels: []
# 命令前缀
command_prefix: "!"
Tips Discord 支持 Slash Command(
/ask这种命令形式)。Hermes 可以自动注册 Slash Command,让用户在任意频道输入/ask 问题来触发 AI。
7. 其他平台接入
7.1 Slack 接入
Slack 是海外企业协作的标配。接入流程和 Discord 类似:
步骤:
1. https://api.slack.com/apps → Create New App
2. 选择"From scratch"
3. 在"OAuth & Permissions"中申请权限:
- chat:write —— 发送消息
- im:history —— 读取私信历史
- channels:history —— 读取频道历史
- app_mentions:read —— 读取 @提及
4. 安装应用到 Workspace,获取 Bot User OAuth Token
5. 在"Event Subscriptions"中订阅 app_mention 和 message.im
gateways:
slack:
enabled: true
bot_token: "${SLACK_BOT_TOKEN}"
signing_secret: "${SLACK_SIGNING_SECRET}"
receive_mode: "webhook"
webhook_url: "https://your-domain.com/webhook/slack"
allowlist: []
7.2 WhatsApp 接入
WhatsApp Business API 需要 Meta 官方审批,流程较长:
- 注册 Meta 开发者账号
- 创建 Business App
- 申请 WhatsApp Business API 访问权限
- 设置 Business Account 和 Phone Number
- 获取 Access Token 和 Phone Number ID
gateways:
whatsapp:
enabled: true
api_token: "${WHATSAPP_API_TOKEN}"
phone_number_id: "${WHATSAPP_PHONE_NUMBER_ID}"
business_account_id: "${WHATSAPP_BUSINESS_ACCOUNT_ID}"
receive_mode: "webhook"
webhook_verify_token: "${WHATSAPP_VERIFY_TOKEN}"
注意 WhatsApp Business API 不是免费的。Meta 按对话收费,24小时内的消息往来算一个对话(约 0.005-0.08 美元,视地区而定)。使用前请确认成本预算。
7.3 Signal 接入
Signal 以隐私著称,官方没有 Bot API。需要使用第三方库 signald 或 signal-cli:
gateways:
signal:
enabled: true
# 需要本地运行 signald 或 signal-cli 服务
signal_cli_endpoint: "http://localhost:8080"
phone_number: "+8613800138000"
7.4 Email 接入
Email Gateway 让 Hermes 可以通过邮件与你交互,适合异步场景:
gateways:
email:
enabled: true
# IMAP 配置(接收邮件)
imap_server: "imap.gmail.com"
imap_port: 993
imap_ssl: true
username: "hermes@your-domain.com"
password: "${EMAIL_PASSWORD}"
# SMTP 配置(发送邮件)
smtp_server: "smtp.gmail.com"
smtp_port: 587
smtp_starttls: true
# 检查频率
poll_interval: 300 # 每 5 分钟检查一次
# 只处理特定主题的邮件
subject_filter: "[Hermes]"
allowlist:
- "boss@company.com"
Tips Gmail 需要使用"应用专用密码"(App Password),不能使用你的 Google 账号密码。在 Google 账号 → 安全性 → 两步验证 → 应用专用密码 中创建。
7.5 SMS 接入
SMS Gateway 需要第三方短信服务商(如 Twilio):
gateways:
sms:
enabled: true
provider: "twilio"
account_sid: "${TWILIO_ACCOUNT_SID}"
auth_token: "${TWILIO_AUTH_TOKEN}"
from_number: "+1234567890"
receive_mode: "webhook"
webhook_url: "https://your-domain.com/webhook/sms"
7.6 Matrix 接入
Matrix 是去中心化的通讯协议,适合自托管和隐私优先的场景:
gateways:
matrix:
enabled: true
homeserver: "https://matrix.org"
user_id: "@hermes:matrix.org"
access_token: "${MATRIX_ACCESS_TOKEN}"
device_id: "HERMES_GATEWAY"
allowed_rooms:
- "!xxxxxxxx:matrix.org"
7.7 Mattermost 接入
Mattermost 是开源的 Slack 替代品,适合自托管企业:
gateways:
mattermost:
enabled: true
server_url: "https://mattermost.your-company.com"
bot_token: "${MATTERMOST_BOT_TOKEN}"
team_name: "your-team"
7.8 Home Assistant 接入
Home Assistant 是开源智能家居平台。通过接入 Hermes,你可以用自然语言控制家里的设备:
gateways:
homeassistant:
enabled: true
server_url: "http://homeassistant.local:8123"
long_lived_token: "${HA_TOKEN}"
webhook_id: "hermes_gateway"
# 暴露给 AI 的设备域
allowed_domains:
- "light"
- "switch"
- "climate"
- "media_player"
配合 Hermes 的工具调用能力,你可以说:
你: 把客厅的灯关掉,空调调到 26 度
Hermes: 好的,已关闭客厅灯光,空调温度已设置为 26°C。
Tips Home Assistant 的
long_lived_token可以在"用户资料" → "长期访问令牌"中创建。务必妥善保管,这个 Token 拥有和你账号一样的所有权限。
8. 编辑器集成
编辑器集成是 Hermes 的杀手锏功能之一。它让你在写代码的同时,直接把 AI 召唤到编辑器里,不需要切换窗口、复制粘贴。
8.1 VS Code 集成(ACP 协议)
VS Code 是目前最流行的代码编辑器,Hermes 通过 ACP(Agent Communication Protocol) 与其深度集成。
安装扩展
- 打开 VS Code
- 点击左侧扩展图标(或按
Cmd+Shift+X) - 搜索 "Hermes Assistant"
- 点击"安装"
配置连接
安装后,点击左侧 Hermes 图标,输入你的 Hermes 服务器地址:
// VS Code settings.json
{
"hermes.serverUrl": "http://localhost:8080",
"hermes.apiKey": "your-api-key",
"hermes.autoConnect": true,
"hermes.inlineCompletion": true,
"hermes.chatLocation": "sidebar"
}
使用方式
方式1:侧边栏聊天
- 点击左侧 Hermes 图标
- 在聊天框输入问题
- 支持多轮对话
方式2:内联编辑(Inline Edit)
- 选中一段代码
- 按 Cmd+Shift+A(或右键 → Ask Hermes)
- 输入指令,比如"给这段代码加注释"
- AI 会直接修改选中的代码
方式3:命令面板
- Cmd+Shift+P → "Hermes: Explain Code"
- Cmd+Shift+P → "Hermes: Generate Tests"
- Cmd+Shift+P → "Hermes: Fix Bugs"
方式4:智能补全
- 输入代码时,按 Tab 接受 AI 建议
- 灰色文字是 AI 的续写建议
Tips ACP 协议让 VS Code 和 Hermes 之间可以传递丰富的上下文信息——不只是当前文件内容,还包括光标位置、选中的代码、打开的终端输出、甚至调试器状态。这让 AI 的回答比普通聊天精准得多。
8.2 Zed 编辑器集成
Zed 是新一代高性能编辑器,内置了 AI 助手功能。Hermes 可以作为 Zed 的自定义 AI 后端:
// ~/.config/zed/settings.json
{
"assistant": {
"version": "2",
"default_model": {
"provider": "hermes",
"model": "hermes-default"
},
"providers": {
"hermes": {
"type": "openai",
"api_url": "http://localhost:8080/v1",
"available_models": [
{
"name": "hermes-default",
"display_name": "Hermes",
"max_tokens": 128000
}
]
}
}
}
}
配置完成后,在 Zed 中按 Ctrl+~(或 Cmd+~)打开 Assistant 面板,即可与 Hermes 对话。
8.3 JetBrains IDE 集成
JetBrains 系列(IntelliJ IDEA、PyCharm、WebStorm 等)通过插件市场安装 Hermes 插件:
- 打开 IDE → Settings → Plugins → Marketplace
- 搜索 "Hermes"
- 安装并重启 IDE
- 配置 Hermes 服务器地址
使用方式:
- 选中代码 → 右键 → Hermes → Explain / Refactor / Test
- 底部工具栏打开 Hermes 聊天面板
- 使用快捷键 Alt+H 快速提问
9. 语音交互
语音是人类最自然的交互方式。Hermes 支持完整的语音输入和输出能力,让你"动动嘴"就能指挥 AI。
9.1 语音输入/输出配置
# ~/.hermes/config.yaml
voice:
# 语音输入(语音识别)
input:
enabled: true
# 识别引擎:openai_whisper, azure_speech, local_whisper
provider: "openai_whisper"
# 语言代码
language: "zh"
# 自动检测语言
auto_detect_language: true
# 识别超时
timeout: 30
# 语音输出(语音合成)
output:
enabled: true
# 合成引擎:openai_tts, azure_tts, edge_tts
provider: "openai_tts"
# 音色选择
voice: "alloy" # alloy, echo, fable, onyx, nova, shimmer
# 语速:0.25 ~ 4.0
speed: 1.0
# 输出格式
format: "mp3"
9.2 支持的语音后端
| 后端 | 类型 | 质量 | 成本 | 隐私 |
|---|---|---|---|---|
| OpenAI Whisper | 识别 | ⭐⭐⭐⭐⭐ | 按量计费 | 数据上传至 OpenAI |
| OpenAI TTS | 合成 | ⭐⭐⭐⭐⭐ | 按量计费 | 数据上传至 OpenAI |
| Azure Speech | 识别+合成 | ⭐⭐⭐⭐ | 按量计费 | 数据上传至 Azure |
| Edge TTS | 合成 | ⭐⭐⭐ | 免费 | 本地处理 |
| Local Whisper | 识别 | ⭐⭐⭐⭐ | 免费(消耗本地 GPU) | 完全本地 |
Local Whisper 配置(完全离线):
voice:
input:
provider: "local_whisper"
model: "base" # tiny, base, small, medium, large
device: "cuda" # cuda 或 cpu
download_root: "~/.hermes/models/whisper"
Tips 如果你在意隐私(比如处理公司内部敏感信息),强烈推荐使用 Local Whisper。
base模型在消费级 GPU 上实时识别没有问题,medium模型准确率接近云端 API。
9.3 语音交互最佳实践
场景1:开车时查询信息
你(语音):" Hermes,查一下今天有哪些会议"
AI(语音):"今天你有三个会议:上午 10 点的产品评审、下午 2 点的技术分享、下午 4 点的客户沟通"
场景2:做饭时听新闻摘要
你(语音):"总结一下今天的人工智能新闻"
AI(语音):"今天 AI 领域有三条重要消息:第一,..."
场景3:睡前口述日记
你(语音):"记录一下,今天完成了用户调研报告,明天需要..."
AI(文字+语音):"已记录到待办事项..."
注意 语音识别的准确率受环境影响很大。嘈杂环境、方言口音、专业术语都可能导致识别错误。建议在安静环境下使用,或者对重要信息做二次确认。
10. 多平台协同使用
多平台接入的真正威力,不在于"能在很多平台上用",而在于"不同平台之间能协同工作"。
10.1 同一 Hermes 实例多平台同时接入
我们已经知道,只需要在 config.yaml 中启用多个平台,它们就会同时在线:
gateways:
telegram:
enabled: true
# ...
lark:
enabled: true
# ...
discord:
enabled: true
# ...
启动后,Gateway Manager 会同时维护三个 Adapter 的连接:
$ hermes gateway status
🌐 Gateway 运行状态
══════════════════════════════════════════════════
Telegram ● 在线 (@HermesAssistantBot)
飞书 ● 在线 (应用: Hermes Assistant)
Discord ● 在线 (Bot: Hermes#1234)
Email ○ 离线 (IMAP 连接失败)
消息队列:3/1000
活跃会话:12
平均响应时间:2.3s
10.2 上下文和记忆在平台间同步
默认情况下,每个平台的会话上下文是独立的。但 Hermes 支持通过 user_mapping 把不同平台的用户身份关联起来:
gateway:
user_mapping:
# 把 Telegram 用户和飞书用户映射到同一个 Hermes 用户 ID
- hermes_user_id: "user_zhangsan"
platform_users:
- platform: "telegram"
platform_user_id: "12345678"
- platform: "lark"
platform_user_id: "ou_xxxxxxxx"
配置后,当"张三"在 Telegram 里问"刚才说的方案呢",AI 能找到他在飞书里上一轮对话的上下文——因为它们被映射到了同一个 hermes_user_id。
10.3 实战案例:手机 Telegram → 电脑执行 → 飞书汇报
这是一个真实的多平台协同场景:
时间线:
09:00 [手机 - Telegram]
你: "帮我查一下竞品 A 公司最近三个月的融资信息"
Hermes: "好的,正在搜索..."
09:05 [Hermes 后台]
- 调用搜索工具,查找竞品 A 的融资新闻
- 整理成结构化数据
- 保存到记忆系统,标记为"竞品分析任务"
09:15 [电脑 - VS Code]
你(看到侧边栏通知):"把刚才的竞品分析整理成 PPT 大纲"
Hermes: "基于刚才的搜索结果,PPT 大纲如下:..."
09:30 [Hermes 后台]
- 生成完整的 PPT 大纲
- 保存到文件 ~/Documents/竞品分析_2024Q1.md
10:00 [飞书]
你: "把今天的竞品分析发送到产品群"
Hermes: "已发送到飞书群「产品团队」"
[飞书群里出现一条消息卡片,包含完整的竞品分析]
这个案例展示了多平台协同的核心价值: - 设备无关:手机上发起任务,电脑上继续处理 - 状态持久:AI 记得"刚才"指的是什么 - 渠道分发:结果自动发送到最合适的平台(飞书群汇报)
11. 安全与运维
11.1 Token/Key 安全管理
所有平台接入都需要某种形式的凭证(Token、Key、Secret)。安全管理的核心原则:
原则1:绝不硬编码
# ❌ 错误示范
gateways:
telegram:
bot_token: "123456789:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
# ✅ 正确示范
gateways:
telegram:
bot_token: "${TELEGRAM_BOT_TOKEN}"
原则2:使用密钥管理工具
# macOS Keychain
security add-generic-password -s "hermes-tg-token" -w "..."
# 或 1Password CLI
op read "op://Private/Hermes/TelegramToken"
# 或 AWS Secrets Manager
aws secretsmanager get-secret-value --secret-id hermes/tokens
原则3:定期轮换
建议每 3-6 个月重置一次 Token,尤其是 Telegram 和 Discord 的 Bot Token。
原则4:最小权限
每个平台的凭证只申请必需的权限。不要图省事给"所有权限"。
11.2 访问控制与白名单
我们在 Telegram 章节已经介绍了 allowlist,这里补充一些进阶用法:
gateway:
security:
# 全局 allowlist(优先级最高)
global_allowlist:
- "telegram:12345678"
- "lark:ou_xxxxxxxx"
- "discord:987654321"
# 时间限制(只允许工作时间)
allowed_hours:
start: "09:00"
end: "21:00"
timezone: "Asia/Shanghai"
# 频率限制(防刷屏)
rate_limit:
max_requests_per_minute: 30
max_requests_per_hour: 200
# 超限后的冷却时间
cooldown_seconds: 60
# 内容过滤
blocked_patterns:
- "(?i)(密码|password)\s*[=:]\s*\S+"
- "(?i)(token|secret|key)\s*[=:]\s*\S+"
11.3 网关进程管理
生产环境中,你需要稳定地管理 Gateway 进程。
使用 systemd(Linux 服务器):
# /etc/systemd/system/hermes-gateway.service
[Unit]
Description=Hermes Gateway
After=network.target
[Service]
Type=simple
User=hermes
WorkingDirectory=/home/hermes
Environment=TELEGRAM_BOT_TOKEN=xxx
Environment=LARK_APP_ID=xxx
Environment=LARK_APP_SECRET=xxx
ExecStart=/usr/local/bin/hermes gateway start
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
# 启动服务
sudo systemctl enable hermes-gateway
sudo systemctl start hermes-gateway
# 查看状态
sudo systemctl status hermes-gateway
# 查看日志
sudo journalctl -u hermes-gateway -f
使用 PM2(Node.js 风格管理):
// ecosystem.config.js
module.exports = {
apps: [{
name: 'hermes-gateway',
script: 'hermes',
args: 'gateway start',
instances: 1,
autorestart: true,
watch: false,
max_memory_restart: '1G',
env: {
NODE_ENV: 'production',
TELEGRAM_BOT_TOKEN: process.env.TELEGRAM_BOT_TOKEN,
},
log_file: './logs/gateway.log',
error_file: './logs/gateway-error.log',
out_file: './logs/gateway-out.log',
time: true
}]
};
pm2 start ecosystem.config.js
pm2 save
pm2 startup
使用 Docker(容器化部署):
# Dockerfile
FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
ENV TELEGRAM_BOT_TOKEN=""
ENV LARK_APP_ID=""
ENV LARK_APP_SECRET=""
EXPOSE 8080
CMD ["hermes", "gateway", "start"]
# docker-compose.yml
version: '3.8'
services:
hermes-gateway:
build: .
ports:
- "8080:8080"
environment:
- TELEGRAM_BOT_TOKEN=${TELEGRAM_BOT_TOKEN}
- LARK_APP_ID=${LARK_APP_ID}
- LARK_APP_SECRET=${LARK_APP_SECRET}
volumes:
- ./config:/app/config
- ./logs:/app/logs
restart: unless-stopped
healthcheck:
test: ["CMD", "hermes", "gateway", "status"]
interval: 30s
timeout: 10s
retries: 3
使用 Hermes 内置的 daemon 命令:
# 启动守护进程
hermes gateway start --daemon
# 查看状态
hermes gateway status
# 停止
hermes gateway stop
# 重启
hermes gateway restart
# 查看日志
hermes gateway logs --tail 100 --follow
Tips 对于生产环境,推荐使用 systemd 或 Docker 管理进程,因为它们提供了更完善的日志收集、自动重启、资源限制等功能。内置的
--daemon适合个人开发和轻量级部署。
本章小结 在本章(第十册)中,我们完成了多平台接入的完整学习之旅: - 理解了 Gateway 架构的设计理念和工作原理 - 详细学习了 Telegram、飞书、微信、Discord 的接入流程 - 了解了 Slack、WhatsApp、Email、Home Assistant 等其他平台的配置 - 掌握了编辑器集成(VS Code、Zed、JetBrains)和语音交互的配置 - 学会了多平台协同使用的策略 - 建立了 Token 安全管理和网关运维的最佳实践
现在,你的 Hermes 已经可以在任何你需要的地方响应你的指令——无论是在手机上、电脑前、还是智能家居设备旁。多平台接入的真正价值,是让 AI 成为你生活中无缝衔接的一部分。
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十一册:MCP 协议与自动化
本章你将学到 - MCP(Model Context Protocol)是什么,为什么它被称为"Agent 世界的 USB-C" - MCP 的客户端-服务器架构和两种连接方式 - 在 Hermes 中配置和接入 MCP 服务的完整流程 - GitHub、Notion、Linear、Figma 等主流服务的 MCP 实战接入 - Cron 定时任务系统的配置与模板 - 多 Agent 编排和自动化流水线的设计方法 - 自动化系统的安全与合规最佳实践
1. MCP 协议:Agent 世界的 USB-C
1.1 什么是 Model Context Protocol(MCP)
想象你买了一台新笔记本电脑。它有一个 USB-C 接口。你可以用这个接口充电、接显示器、连移动硬盘、接网线转接头、甚至外接显卡坞。一个接口,万能适配。
现在想象 AI Agent 也要"接外设"——查 GitHub 代码、读 Notion 文档、发 Slack 消息、查 Google 日历。在过去,每接一个"外设",开发者都要写一套专门的对接代码,就像每台设备都要配一个专用充电器一样麻烦。
MCP(Model Context Protocol,模型上下文协议) 就是来解决这个问题的。它是 Anthropic 在 2024 年提出的开放协议,旨在为 AI Agent 和外部工具之间建立统一的通信标准。
用一句话概括:MCP 让 AI Agent 接入外部服务,像插 USB-C 一样简单。
1.2 MCP 诞生背景(Anthropic 提出)
在 MCP 出现之前,AI Agent 接入外部世界是一片混乱的"战国时代":
- OpenAI 有 Function Calling,但只能和 OpenAI 的模型用
- LangChain 有 Tool 封装,但每个 Tool 都要单独写适配层
- 每家 SaaS 公司的 API 格式都不一样:有的用 REST,有的用 GraphQL,有的用 gRPC
- 认证方式五花八门:API Key、OAuth、JWT、HMAC...每个都要单独处理
开发者们的痛苦可想而知。每想接一个新服务,就要: 1. 读一遍该服务的 API 文档 2. 写 HTTP 客户端代码 3. 处理各种边界情况和错误码 4. 维护文档告诉 AI 这个工具能干什么 5. 每次 API 升级都要改代码
Anthropic 看到了这个问题。他们想:为什么不能像 USB 标准化硬件接口一样,标准化 AI 和工具的接口呢?于是 MCP 诞生了。
Tips MCP 是一个开放协议,不是 Anthropic 的私有技术。任何 AI 平台、任何工具开发者都可以免费使用。这有点像 HTTP 协议——Tim Berners-Lee 发明了它,但整个互联网都在用。
1.3 设计理念与核心概念
MCP 的设计遵循三个核心原则:
原则一:统一接口(Universal Interface)
不管是连接 GitHub、Notion 还是你家智能灯泡,AI 都用同一套"语言"和它们对话。就像不管接什么设备,USB-C 的物理形状和电气协议都是一样的。
原则二:自描述能力(Self-Describing)
MCP Server 会主动告诉 AI:"我能做这些事,参数是这样的,返回结果是那样的。"AI 不需要提前"学习"每个工具的用法,只需要在运行时读取 Server 的"自我介绍"。
原则三:双向通信(Bidirectional)
传统的 API 调用是"我问你答"的单向模式。MCP 支持双向通信——AI 可以请求工具执行操作,工具也可以主动向 AI 推送通知(比如你关注的 GitHub Issue 有人回复了)。
核心概念速览:
| 概念 | 类比 | 说明 |
|---|---|---|
| MCP Client | 笔记本电脑 | AI Agent 中负责连接外部工具的组件 |
| MCP Server | USB 外设 | 提供具体功能的服务端(如 GitHub MCP Server) |
| Tool | 外设功能 | Server 暴露给 AI 可调用的功能(如"创建 Issue") |
| Resource | 文件系统 | Server 管理的可读数据(如"某份文档内容") |
| Prompt | 快捷指令 | 预定义的提示模板 |
1.4 与传统 API 调用的区别
很多人问:MCP 不就是封装了一层 API 调用吗?有什么区别?
让我们用一个具体的例子来对比——让 AI 帮你创建一个 GitHub Issue:
传统 API 调用方式:
# 开发者需要手写这个函数,并告诉 AI 怎么调用它
def create_github_issue(repo, title, body, labels=None):
"""
创建 GitHub Issue
参数:
repo: 仓库名,格式 "owner/repo"
title: Issue 标题
body: Issue 内容
labels: 标签列表,可选
"""
headers = {
"Authorization": f"token {GITHUB_TOKEN}",
"Accept": "application/vnd.github.v3+json"
}
data = {"title": title, "body": body}
if labels:
data["labels"] = labels
response = requests.post(
f"https://api.github.com/repos/{repo}/issues",
headers=headers,
json=data
)
return response.json()
# 然后还要在系统提示词里告诉 AI:
# "如果你需要创建 GitHub Issue,调用 create_github_issue 函数,
# 参数 repo 必须是 owner/repo 格式..."
MCP 方式:
# 配置文件中只需这一行
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
然后 AI 自动就知道: - GitHub MCP Server 提供了哪些工具 - 每个工具需要什么参数 - 参数的类型和约束 - 返回值是什么格式
注意 MCP 不是替代 API,而是标准化 API 的接入方式。GitHub MCP Server 底层仍然在调用 GitHub REST API,但开发者不需要关心这些细节。就像 USB-C 不是替代电线,而是标准化了插头形状。
对比总结:
| 维度 | 传统 API 调用 | MCP |
|---|---|---|
| 接入成本 | 高(读文档、写代码、维护) | 低(配置一行 YAML) |
| 自描述 | 无(需要手写文档) | 有(Server 自动声明能力) |
| 动态发现 | 不支持(代码写死) | 支持(运行时枚举工具) |
| 双向通信 | 不支持 | 支持(Server 可推送) |
| 生态互通 | 差(各平台不兼容) | 好(任何 MCP Client 都能接任何 MCP Server) |
2. MCP 架构详解
2.1 客户端-服务器模型
MCP 采用了经典的客户端-服务器(Client-Server)架构:
┌─────────────────────────────────────────────────────────────┐
│ Hermes AI Agent │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ MCP Client │◄────►│ MCP Client │◄────►│ MCP Client │ │
│ │ (GitHub) │ │ (Notion) │ │ (Slack) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────────────────┴────────────────────┘ │
│ ▲ │
│ AI Core Engine │
└─────────────────────────┬───────────────────────────────────┘
│ JSON-RPC 2.0
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ GitHub MCP │ │ Notion MCP │ │ Slack MCP │
│ Server │ │ Server │ │ Server │
│ (stdio/http) │ │ (stdio/http) │ │ (stdio/http) │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ GitHub API │ │ Notion API │ │ Slack API │
└─────────────────┘ └─────────────────┘ └─────────────────┘
关键组件说明:
- MCP Client:运行在 Hermes 内部,负责和 MCP Server 建立连接、发送请求、接收响应。每个 Server 对应一个 Client 实例。
- MCP Server:独立运行的进程或服务,暴露一组 Tools 和 Resources。它可以是本地进程(stdio 模式),也可以是远程服务(HTTP 模式)。
- Transport Layer:Client 和 Server 之间的通信通道,支持 stdio 和 HTTP/SSE 两种方式。
- JSON-RPC 2.0:MCP 的通信协议格式,所有消息都是 JSON-RPC 格式的。
2.2 stdio vs HTTP/SSE 两种连接方式
MCP 支持两种 Transport 模式,适用于不同场景:
stdio 模式(标准输入输出)
┌─────────────┐ stdin/stdout ┌─────────────┐
│ MCP Client │◄──────────────────────────────►│ MCP Server │
│ (父进程) │ (JSON-RPC 消息) │ (子进程) │
└─────────────┘ └─────────────┘
工作原理:
- Hermes 启动时,用 spawn 启动 MCP Server 进程
- Client 通过 Server 的 stdin 发送 JSON-RPC 请求
- Server 通过 stdout 返回 JSON-RPC 响应
- 两者通过管道(pipe)通信
适用场景:
- 本地运行的 MCP Server(如 npx 启动的 Node.js 程序)
- 对安全性要求高的场景(不暴露网络端口)
- 简单部署,不需要配置防火墙
优点: - 简单,不需要网络配置 - 安全,没有暴露端口 - 进程生命周期由 Client 管理,Server 随 Client 启动/停止
缺点: - 只能本地运行,无法远程连接 - 一个 Server 进程只能服务一个 Client - 不适合高并发场景
# stdio 模式配置示例
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
HTTP/SSE 模式
┌─────────────┐ HTTP POST/GET ┌─────────────┐
│ MCP Client │◄────────────────────────►│ MCP Server │
│ │ │ (HTTP 服务) │
│ │◄─────────────────────────│ │
│ │ SSE 推送 │ │
└─────────────┘ └─────────────┘
工作原理: - MCP Server 是一个独立的 HTTP 服务,监听某个端口 - Client 通过 HTTP POST 发送 JSON-RPC 请求 - Server 通过 HTTP Response 返回结果 - Server 可以通过 SSE(Server-Sent Events)主动向 Client 推送消息
适用场景: - 远程部署的 MCP Server(如部署在云服务器上) - 多个 Client 共享一个 Server 的场景 - 需要 Server 主动推送通知的场景
优点: - 可以远程连接 - 支持多个 Client - Server 可以主动推送(SSE)
缺点: - 需要网络配置(端口、防火墙、HTTPS) - 需要额外处理认证和安全性 - 部署复杂度更高
# HTTP/SSE 模式配置示例
mcp_servers:
remote-github:
url: "https://mcp.example.com/github"
headers:
Authorization: "Bearer ${MCP_API_KEY}"
# 是否使用 SSE 接收推送
sse: true
Tips 对于个人用户和小团队,stdio 模式是最简单的选择。大部分官方 MCP Server 都支持
npx一键启动。只有当你需要多个 Hermes 实例共享一个 MCP Server,或者 Server 必须部署在远程时,才需要考虑 HTTP 模式。
2.3 消息格式与协议规范
MCP 使用 JSON-RPC 2.0 作为通信协议。所有消息都是 JSON 格式,分为三种类型:
请求(Request)
Client 向 Server 发送的请求:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "create_issue",
"arguments": {
"repo": "owner/repo",
"title": "发现 Bug",
"body": "详情如下..."
}
}
}
响应(Response)
Server 返回的成功响应:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "Issue #42 已成功创建: https://github.com/owner/repo/issues/42"
}
],
"isError": false
}
}
通知(Notification)
Server 主动推送的通知(单向,不需要响应):
{
"jsonrpc": "2.0",
"method": "notifications/resources/updated",
"params": {
"uri": "file:///project/src/main.py"
}
}
核心方法列表:
| 方法 | 方向 | 说明 |
|---|---|---|
initialize |
C→S | 初始化连接,交换协议版本和能力 |
tools/list |
C→S | 获取 Server 提供的所有工具列表 |
tools/call |
C→S | 调用指定工具 |
resources/list |
C→S | 获取可用资源列表 |
resources/read |
C→S | 读取指定资源 |
prompts/list |
C→S | 获取可用提示模板 |
notifications/resources/updated |
S→C | 资源更新通知 |
2.4 工具声明与调用流程
工具声明(Tool Declaration) 是 MCP 最核心的设计之一。它让 AI 能够"动态发现"工具的能力,而不是依赖硬编码的提示词。
当 MCP Client 连接到 Server 后,第一件事就是调用 tools/list:
// Client 请求
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/list"
}
// Server 响应
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"tools": [
{
"name": "create_issue",
"description": "在指定仓库创建一个新的 GitHub Issue",
"inputSchema": {
"type": "object",
"properties": {
"repo": {
"type": "string",
"description": "仓库名,格式:owner/repo"
},
"title": {
"type": "string",
"description": "Issue 标题"
},
"body": {
"type": "string",
"description": "Issue 内容"
},
"labels": {
"type": "array",
"items": {"type": "string"},
"description": "标签列表"
}
},
"required": ["repo", "title"]
}
},
{
"name": "search_issues",
"description": "搜索 GitHub Issues",
"inputSchema": {
"type": "object",
"properties": {
"repo": {"type": "string"},
"query": {"type": "string"},
"state": {
"type": "string",
"enum": ["open", "closed", "all"]
}
},
"required": ["repo", "query"]
}
}
]
}
}
Hermes 拿到这个工具列表后,会把它转换成 AI 能理解的格式(通常是在系统提示词中描述这些工具)。当用户说"帮我创建一个 Issue"时,AI 就知道:
- GitHub Server 有一个叫
create_issue的工具 - 它需要
repo、title、body等参数 repo是字符串类型,格式是owner/repotitle是必填的
然后 AI 会调用 tools/call:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "create_issue",
"arguments": {
"repo": "mycompany/project",
"title": "首页加载速度过慢",
"body": "在 3G 网络下,首页加载需要 8 秒以上..."
}
}
}
Tips 这种"自描述"的设计意味着:即使 GitHub MCP Server 新增了一个工具(比如"创建 Discussion"),Hermes 不需要更新任何代码,下次连接时就能自动发现这个新工具。这就是 MCP 的扩展性优势。
3. Hermes 中的 MCP 配置
3.1 config.yaml 中的 mcp_servers 配置
Hermes 的 MCP 配置位于 ~/.hermes/config.yaml 的 mcp_servers 节下。它的结构非常直观:
# ~/.hermes/config.yaml
mcp_servers:
# Server 名称(自定义,用于标识)
github:
# stdio 模式配置
command: "npx"
args:
- "-y"
- "@modelcontextprotocol/server-github"
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
# 允许 AI 调用的工具列表(权限控制)
allowed_tools:
- "search_repositories"
- "create_issue"
- "search_issues"
- "get_issue"
# 另一个 Server
notion:
command: "npx"
args:
- "-y"
- "@modelcontextprotocol/server-notion"
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
allowed_tools: []
# HTTP 模式的 Server
remote-tools:
url: "https://mcp.internal.company.com/tools"
headers:
Authorization: "Bearer ${INTERNAL_API_KEY}"
sse: true
allowed_tools:
- "query_database"
- "send_notification"
配置项说明:
| 配置项 | 类型 | 说明 |
|---|---|---|
command |
string | stdio 模式下要执行的命令 |
args |
array | 命令参数 |
env |
object | 环境变量 |
url |
string | HTTP 模式下 Server 的地址 |
headers |
object | HTTP 请求头 |
sse |
boolean | 是否启用 SSE 推送 |
allowed_tools |
array | 允许 AI 调用的工具白名单(空数组表示允许所有) |
3.2 stdio 和 HTTP/SSE 模式示例
stdio 模式完整示例
mcp_servers:
# GitHub MCP Server
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
allowed_tools:
- "search_repositories"
- "get_file_contents"
- "create_issue"
- "search_issues"
- "create_pull_request"
- "list_commits"
# Notion MCP Server
notion:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-notion"]
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
allowed_tools: []
# PostgreSQL MCP Server
postgres:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-postgres"]
env:
POSTGRES_URL: "${DATABASE_URL}"
allowed_tools:
- "query"
# File System MCP Server(访问本地文件)
filesystem:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/username/Documents"]
allowed_tools:
- "read_file"
- "list_directory"
- "search_files"
HTTP/SSE 模式完整示例
mcp_servers:
# 公司内部 MCP 服务
company-tools:
url: "https://mcp.internal.company.com/v1"
headers:
Authorization: "Bearer ${COMPANY_MCP_TOKEN}"
X-Department: "engineering"
sse: true
allowed_tools:
- "query_employee"
- "book_meeting_room"
- "request_leave"
# 第三方 MCP 托管服务
mcp-cloud:
url: "https://api.mcp.cloud/v1/github"
headers:
X-API-Key: "${MCP_CLOUD_KEY}"
sse: false
allowed_tools: []
3.3 allowed_tools 权限控制
allowed_tools 是 MCP 配置中最重要的安全机制。它精确控制 AI 能调用哪些工具。
场景一:只读权限
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
# 只允许读操作,禁止创建/修改
allowed_tools:
- "search_repositories"
- "get_file_contents"
- "search_issues"
- "list_commits"
- "get_commit"
场景二:按仓库隔离
mcp_servers:
github-readonly:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_READONLY_TOKEN}"
allowed_tools:
- "search_repositories"
- "get_file_contents"
- "search_issues"
github-write:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_WRITE_TOKEN}"
allowed_tools:
- "create_issue"
- "create_pull_request"
- "create_branch"
场景三:完全禁止
mcp_servers:
dangerous-server:
command: "npx"
args: ["-y", "some-risky-server"]
# 空数组 = 禁止所有工具
allowed_tools: []
注意
allowed_tools是白名单机制。如果一个工具不在列表里,AI 即使"知道"它的存在,也无法调用。这是防止 AI"误操作"的重要防线。
3.4 多个 MCP Server 并存
Hermes 支持同时连接任意数量的 MCP Server。当用户提出一个请求时,Hermes 会自动判断:
- 需要调用哪个(些)Server
- 调用 Server 中的哪个工具
- 按什么顺序调用
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
notion:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-notion"]
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
slack:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-slack"]
env:
SLACK_BOT_TOKEN: "${SLACK_BOT_TOKEN}"
用户的请求:"把 GitHub 上最近的 Bug 整理一下,写到 Notion 文档里,然后在 Slack 通知团队"
Hermes 的处理流程:
1. 调用 GitHub Server 的 search_issues 获取 Bug 列表
2. 调用 Notion Server 的 append_page 把结果写入文档
3. 调用 Slack Server 的 send_message 发送通知
Tips 多个 MCP Server 协同工作时,Hermes 会自动处理依赖顺序。比如上面的例子,必须等 GitHub 返回结果后,才能写入 Notion。Hermes 的编排引擎会确保按正确顺序执行。
4. 实战:接入 GitHub
GitHub 是开发者最熟悉的平台,也是 MCP 生态中最成熟的 Server 之一。让我们从 GitHub 开始实战。
4.1 完整配置
# ~/.hermes/config.yaml
mcp_servers:
github:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_TOKEN}"
# 根据你的需求选择允许的工具
allowed_tools:
# 仓库操作
- "search_repositories"
- "get_file_contents"
- "list_branches"
# Issue 操作
- "search_issues"
- "get_issue"
- "create_issue"
- "update_issue"
- "add_issue_comment"
# PR 操作
- "create_pull_request"
- "get_pull_request"
- "list_pull_requests"
- "merge_pull_request"
# Commit 操作
- "list_commits"
- "get_commit"
# 搜索
- "search_code"
4.2 Token 获取
GitHub 的 MCP Server 需要 Personal Access Token(PAT)。
获取步骤:
- 登录 GitHub,点击右上角头像 → Settings
- 左侧菜单拉到底 → Developer settings → Personal access tokens
- 选择 "Tokens (classic)" 或 "Fine-grained tokens"
- 点击 "Generate new token"
- 填写 Token 信息:
- Note:Hermes MCP
- Expiration:选择过期时间(建议 90 天,到期后轮换)
- Scopes:勾选需要的权限:
✅ repo —— 访问私有仓库(如需) ✅ read:org —— 读取组织信息 ✅ read:user —— 读取用户信息 ✅ read:project —— 读取项目信息 - 点击 "Generate token"
- 立刻复制 Token(页面关闭后无法再次查看)
# 保存到环境变量
export GITHUB_TOKEN="ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
注意 Fine-grained tokens 是 GitHub 推荐的新一代 Token,支持更精细的权限控制(可以限定只访问特定仓库)。如果你的公司安全要求严格,建议使用 Fine-grained tokens 替代 Classic tokens。
4.3 安全配置
GitHub Token 拥有你账号的访问权限,务必妥善保管:
# 1. 使用环境变量(基础)
export GITHUB_TOKEN="ghp_xxx"
# 2. 使用 GitHub CLI(推荐)
gh auth login
# 然后用 `gh auth token` 获取 Token
# 3. 使用 1Password CLI(最安全)
export GITHUB_TOKEN=$(op read "op://Private/GitHub/PAT")
# 4. 定期轮换(最佳实践)
# 设置日历提醒,每 90 天重置一次 Token
4.4 使用示例
配置完成后,重启 Hermes,你就可以直接用自然语言操作 GitHub 了:
示例1:搜索代码
你: 在 GitHub 上搜索 Hermes 项目里关于 memory 的实现
Hermes: 正在搜索...
Hermes: 找到 12 个相关文件,其中最核心的是:
1. src/memory/short_term.py - 短期记忆实现
2. src/memory/long_term.py - 长期记忆实现
3. src/memory/hybrid.py - 混合记忆策略
需要我查看某个文件的具体内容吗?
示例2:创建 Issue
你: 在我的项目 myapp 里创建一个 Issue,标题是"优化数据库查询性能",
内容是:首页加载时用户列表查询耗时超过 2 秒,需要添加索引
Hermes: 正在创建 Issue...
Hermes: ✅ Issue 已创建
仓库: myname/myapp
标题: 优化数据库查询性能
链接: https://github.com/myname/myapp/issues/42
示例3:分析 PR
你: 帮我看看 #15 号 PR 改了哪些文件
Hermes: PR #15 "添加用户认证模块" 的变更概览:
新增文件:
- src/auth/login.py
- src/auth/middleware.py
- tests/auth/test_login.py
修改文件:
- src/main.py (+15/-3)
- requirements.txt (+2)
需要我查看具体代码差异吗?
常见问题 Q: 为什么 AI 说"我没有权限"? A: 检查两点:1)
allowed_tools里是否允许了这个操作;2) GitHub Token 是否有对应的权限(比如创建 Issue 需要reposcope)。
5. 实战:接入 Notion
Notion 是知识管理和文档协作的神器。把 Notion 接入 Hermes 后,AI 可以帮你读写文档、管理数据库、整理知识库。
5.1 Notion Integration 创建
步骤一:创建 Integration
- 访问 https://www.notion.so/my-integrations
- 点击 "New integration"
- 填写信息:
- Name:Hermes Assistant
- Associated workspace:选择你的 Notion Workspace
- Type:Internal(自用)或 Public(公开发布)
- Logo:上传一张图标(可选)
- 点击 "Submit"
步骤二:获取 API Key
创建完成后,在 Integration 详情页找到 "Internal Integration Token":
secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export NOTION_TOKEN="secret_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
注意 Notion 的 Integration 默认没有任何页面的访问权限。你需要手动把页面分享给 Integration,这是 Notion 的安全设计。
步骤三:授权页面访问
- 在 Notion 中打开你要让 AI 访问的页面
- 点击右上角 "..." → "Add connections"
- 搜索并选择你创建的 "Hermes Assistant"
- 确认添加
Tips 如果你希望 AI 能访问整个 Workspace 的所有页面,可以在 Integration 的 Capabilities 设置中开启 "Read user information including email addresses"。但建议按需授权,遵循最小权限原则。
5.2 API Key 配置
mcp_servers:
notion:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-notion"]
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
allowed_tools:
# 页面操作
- "notion_search"
- "notion_retrieve_page"
- "notion_retrieve_block_children"
# 数据库操作
- "notion_query_database"
- "notion_create_database_item"
# 写入操作(谨慎开启)
- "notion_append_block_children"
- "notion_update_page"
5.3 MCP 配置
上面的配置已经展示了完整的 MCP 配置。这里补充一些高级用法:
只读模式(安全推荐):
mcp_servers:
notion-readonly:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-notion"]
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
allowed_tools:
- "notion_search"
- "notion_retrieve_page"
- "notion_retrieve_block_children"
- "notion_query_database"
读写模式(需要时开启):
mcp_servers:
notion-write:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-notion"]
env:
NOTION_API_TOKEN: "${NOTION_TOKEN}"
allowed_tools:
- "notion_search"
- "notion_retrieve_page"
- "notion_query_database"
- "notion_create_database_item"
- "notion_append_block_children"
- "notion_update_page"
5.4 使用场景
场景1:知识库问答
你: 查一下我们产品需求文档里关于"支付模块"是怎么设计的
Hermes: 正在搜索 Notion...
Hermes: 找到相关内容(来自页面"产品需求文档 v2.0"):
支付模块设计要点:
1. 支持支付宝、微信支付、银联三种渠道
2. 支付状态机:待支付 → 处理中 → 成功/失败
3. 异步通知机制,超时 30 秒自动查询
4. 对账功能每日凌晨 2 点执行
需要我查看更详细的设计吗?
场景2:数据库管理
你: 在"项目跟踪"数据库里添加一个新任务:
名称:优化首页性能,负责人:张三,优先级:高,截止日期:下周五
Hermes: 已添加到 Notion 数据库:
页面: 优化首页性能
数据库: 项目跟踪
负责人: 张三
优先级: 高
截止日期: 2024-01-12
场景3:会议纪要整理
你: 把今天的会议纪要整理成结构化文档,存到 Notion
[粘贴会议录音转文字]
Hermes: 正在整理...
Hermes: 已创建 Notion 页面"2024-01-05 产品周会纪要",包含:
- 参会人员
- 核心结论(5 条)
- 待办事项(8 项,已分配负责人)
- 下次会议议题
6. 实战:接入更多服务
6.1 Linear(项目管理)
Linear 是海外开发者喜爱的项目管理工具,比 Jira 更轻量、更美观。
mcp_servers:
linear:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-linear"]
env:
LINEAR_API_KEY: "${LINEAR_API_KEY}"
allowed_tools:
- "linear_search_issues"
- "linear_create_issue"
- "linear_update_issue"
- "linear_add_comment"
获取 API Key:
1. Linear → Settings → API → Personal API keys
2. 点击 "Create key"
3. 复制 lin_api_xxxxxxxx
使用示例:
你: 创建一个 Linear Issue,标题"修复登录页面样式",
分配给李明,标签是 bug 和 frontend
Hermes: ✅ Linear Issue 已创建
标题: 修复登录页面样式
状态: Todo
负责人: 李明
标签: bug, frontend
链接: https://linear.app/company/issue/PROJ-123
6.2 Figma(设计协作)
Figma MCP Server 让 AI 能够读取设计稿信息,帮助工程师理解设计规范。
mcp_servers:
figma:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-figma"]
env:
FIGMA_ACCESS_TOKEN: "${FIGMA_TOKEN}"
allowed_tools:
- "get_file"
- "get_file_nodes"
- "get_comments"
获取 Access Token: 1. Figma → Settings → Personal access tokens 2. 点击 "Create new token" 3. 复制 Token
使用示例:
你: 查看 Figma 文件 abc123 中"登录页面"的设计规范
Hermes: 登录页面设计规范:
- 画布尺寸: 375 x 812 (iPhone)
- 主色调: #1A73E8
- 按钮圆角: 8px
- 输入框高度: 48px
- 间距系统: 4px 基准
需要我导出具体组件的 CSS 代码吗?
6.3 Slack(团队沟通)
mcp_servers:
slack:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-slack"]
env:
SLACK_BOT_TOKEN: "${SLACK_BOT_TOKEN}"
SLACK_TEAM_ID: "${SLACK_TEAM_ID}"
allowed_tools:
- "slack_search_messages"
- "slack_send_message"
- "slack_get_channel_history"
获取 Bot Token:
1. https://api.slack.com/apps → Create New App
2. OAuth & Permissions → Bot Token Scopes
3. 添加 chat:write, search:read
4. Install to Workspace
5. 复制 "Bot User OAuth Token"(格式:xoxb-xxx)
注意 Slack 的
search:read权限需要工作区管理员批准。如果你的 Bot 只能发消息不能搜索,检查权限是否已审批。
6.4 Google Calendar(日程管理)
mcp_servers:
google-calendar:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-gcalendar"]
env:
GOOGLE_CLIENT_ID: "${GOOGLE_CLIENT_ID}"
GOOGLE_CLIENT_SECRET: "${GOOGLE_CLIENT_SECRET}"
GOOGLE_REFRESH_TOKEN: "${GOOGLE_REFRESH_TOKEN}"
allowed_tools:
- "list_events"
- "create_event"
- "delete_event"
- "find_free_time"
OAuth 配置流程: 1. Google Cloud Console → APIs & Services → Credentials 2. 创建 OAuth 2.0 Client ID(Desktop App 类型) 3. 启用 Google Calendar API 4. 用 OAuth 流程获取 Refresh Token(Server 首次启动时会引导你完成授权)
使用示例:
你: 帮我看看下周有哪些会议
Hermes: 下周会议安排:
周一 10:00 - 11:00: 产品周会
周二 14:00 - 15:30: 技术评审
周三 09:00 - 10:00: 客户沟通
周四: 无会议 ✨
周五 16:00 - 17:00: 团队复盘
需要我帮你在周四安排一个专注工作的时间段吗?
6.5 Google Drive(文件存储)
mcp_servers:
google-drive:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-gdrive"]
env:
GOOGLE_CLIENT_ID: "${GOOGLE_CLIENT_ID}"
GOOGLE_CLIENT_SECRET: "${GOOGLE_CLIENT_SECRET}"
GOOGLE_REFRESH_TOKEN: "${GOOGLE_REFRESH_TOKEN}"
allowed_tools:
- "search_files"
- "read_file"
- "list_folder"
6.6 PostgreSQL/MySQL(数据库)
数据库 MCP Server 让 AI 能直接查询数据库,是数据分析师的利器。
PostgreSQL:
mcp_servers:
postgres:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-postgres"]
env:
POSTGRES_URL: "${DATABASE_URL}"
allowed_tools:
- "query"
数据库连接字符串格式:
export DATABASE_URL="postgresql://username:password@localhost:5432/dbname"
注意 数据库 MCP Server 是高风险工具! 建议: 1. 使用只读账号(
GRANT SELECT ON ALL TABLES) 2. 开启allowed_tools: ["query"]但不要给execute权限 3. 生产环境数据库强烈建议通过只读副本(Read Replica)连接 4. 避免直接连接含有敏感信息(用户密码、支付信息)的数据库
使用示例:
你: 查询最近 7 天的新用户注册数量,按天分组
Hermes: 正在查询数据库...
查询结果:
日期 新注册用户数
2024-01-01 156
2024-01-02 203
2024-01-03 189
2024-01-04 245
2024-01-05 198
2024-01-06 312
2024-01-07 267
周总计: 1,570 人
日均: 224 人
环比增长: +15.3%
7. 6000+ MCP 服务生态
7.1 按分类浏览
MCP 生态正在爆发式增长。截至 2024 年底,社区已经有了超过 6000 个 MCP Server,覆盖几乎所有主流 SaaS 服务。
主要分类:
| 分类 | 代表服务 | 数量 |
|---|---|---|
| 开发工具 | GitHub, GitLab, Bitbucket, Vercel | 800+ |
| 生产力 | Notion, Obsidian, Todoist, Trello | 600+ |
| 通讯协作 | Slack, Discord, Teams, Zoom | 500+ |
| 云服务 | AWS, GCP, Azure, Cloudflare | 700+ |
| 数据库 | PostgreSQL, MySQL, MongoDB, Redis | 400+ |
| 数据分析 | BigQuery, Snowflake, Databricks | 300+ |
| 设计创意 | Figma, Canva, Adobe | 200+ |
| 金融商务 | Stripe, PayPal, QuickBooks | 250+ |
| 智能家居 | Home Assistant, Philips Hue | 150+ |
| 其他 | 各种小众工具和企业内部系统 | 2000+ |
7.2 热门 Top 20
根据社区使用量排序的 Top 20 MCP Server:
- @modelcontextprotocol/server-github - GitHub 官方 MCP Server
- @modelcontextprotocol/server-filesystem - 本地文件系统访问
- @modelcontextprotocol/server-postgres - PostgreSQL 查询
- @modelcontextprotocol/server-notion - Notion 文档管理
- @modelcontextprotocol/server-slack - Slack 消息收发
- @modelcontextprotocol/server-google-maps - Google Maps 地点搜索
- @modelcontextprotocol/server-puppeteer - 网页浏览和截图
- @modelcontextprotocol/server-fetch - 通用 HTTP 请求
- @modelcontextprotocol/server-sqlite - SQLite 数据库
- @modelcontextprotocol/server-brave-search - Brave 搜索引擎
- @modelcontextprotocol/server-memory - 持久化记忆存储
- @modelcontextprotocol/server-sequential-thinking - 链式思考辅助
- @anthropic-ai/server-shopify - Shopify 电商管理
- @modelcontextprotocol/server-aws-kb-retrieval - AWS 知识库检索
- @modelcontextprotocol/server-everart - AI 图像生成
- @modelcontextprotocol/server-duckduckgo - DuckDuckGo 搜索
- @modelcontextprotocol/server-redis - Redis 缓存操作
- @modelcontextprotocol/server-github-advanced - GitHub 高级功能
- @modelcontextprotocol/server-discord - Discord 深度集成
- @modelcontextprotocol/server-youtube - YouTube 视频分析
Tips 安装任何 MCP Server 都可以用
npx一键启动,不需要手动下载:yaml mcp_servers: any-server: command: "npx" args: ["-y", "@scope/server-name"]
7.3 安全评估
使用第三方 MCP Server 时,安全评估必不可少:
检查清单:
□ 来源可信
- 是否来自官方账号(@modelcontextprotocol、@anthropic-ai)?
- 社区使用量大吗?GitHub stars 有多少?
- 最近还有更新吗?
□ 权限合理
- Server 请求的权限是否与其功能匹配?
- 文件系统 Server 是否限制了访问目录?
□ 代码审查
- 如果可能,快速浏览一下源码
- 特别关注它如何处理你的 Token/凭证
- 是否有可疑的网络请求?
□ 网络隔离
- 能否在沙箱/容器中运行?
- 能否限制其网络访问权限?
□ 最小权限
- 用 allowed_tools 限制可调用的工具
- 给 API Token 设置最小权限
注意 MCP Server 运行在本地时,理论上它可以访问你的文件系统、环境变量、网络。安装来路不明的 Server 就像安装来路不明的软件一样有风险。建议只使用官方或社区广泛验证的 Server。
8. Cron 定时任务系统
如果说 MCP 让 Hermes 有了"手"(操作外部工具的能力),那 Cron 定时任务系统就是给了 Hermes "生物钟"——让它能按时自动执行任务。
8.1 ~/.hermes/cron/tasks.yaml 配置详解
Hermes 的定时任务配置文件位于 ~/.hermes/cron/tasks.yaml:
# ~/.hermes/cron/tasks.yaml
# 全局配置
global:
# 时区设置
timezone: "Asia/Shanghai"
# 任务并发数
max_concurrent: 3
# 默认超时时间
default_timeout: 300
# 失败重试次数
default_retries: 2
# 通知渠道(任务完成/失败时通知你)
notifications:
on_success: false # 成功时不通知(避免打扰)
on_failure: true # 失败时通知
channels:
- platform: "telegram"
user_id: "12345678"
# 任务列表
tasks:
# 任务1:每日新闻摘要
- id: "daily-news"
name: "每日 AI 新闻摘要"
# Cron 表达式:每天早上 8 点执行
schedule: "0 8 * * *"
enabled: true
# 执行内容
actions:
- type: "prompt"
content: |
搜索今天的人工智能领域重要新闻,
整理成 5 条要点,每条包含标题和一句话摘要。
用中文输出。
- type: "notify"
platform: "telegram"
user_id: "12345678"
message_template: "📰 今日 AI 新闻\n\n{{result}}"
# 任务2:每周报告生成
- id: "weekly-report"
name: "每周数据报告"
schedule: "0 9 * * MON"
enabled: true
actions:
- type: "mcp"
server: "postgres"
tool: "query"
arguments:
sql: |
SELECT
DATE(created_at) as date,
COUNT(*) as new_users
FROM users
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY DATE(created_at)
ORDER BY date;
- type: "prompt"
content: |
根据以下数据生成周报摘要:
{{previous_result}}
要求:
1. 总结本周关键数据
2. 指出趋势和异常
3. 给出下周建议
- type: "notify"
platform: "lark"
user_id: "ou_xxxxxxxx"
# 任务3:网站监控
- id: "website-monitor"
name: "网站可用性监控"
# 每 5 分钟执行一次
schedule: "*/5 * * * *"
enabled: true
timeout: 30
actions:
- type: "http"
method: "GET"
url: "https://myapp.com/health"
expected_status: 200
- type: "condition"
if: "{{status}} != 200"
then:
- type: "notify"
platform: "telegram"
user_id: "12345678"
message_template: "🚨 网站异常!状态码: {{status}}"
8.2 Cron 表达式语法(详细带示例)
Cron 表达式是定时任务的"时间表语言"。它由 5 个字段组成:
┌───────────── 分钟 (0 - 59)
│ ┌───────────── 小时 (0 - 23)
│ │ ┌───────────── 日期 (1 - 31)
│ │ │ ┌───────────── 月份 (1 - 12)
│ │ │ │ ┌───────────── 星期 (0 - 6, 0=周日)
│ │ │ │ │
* * * * *
常用表达式示例:
| 表达式 | 含义 | 说明 |
|---|---|---|
0 8 * * * |
每天 8:00 | 每天早上准时执行 |
0 */2 * * * |
每 2 小时 | 在 0:00, 2:00, 4:00...执行 |
*/15 * * * * |
每 15 分钟 | 常用于监控类任务 |
0 9 * * MON |
每周一 9:00 | 周报、周会的最佳时间 |
0 9 1 * * |
每月 1 号 9:00 | 月报、账单提醒 |
0 22 * * 1-5 |
工作日 22:00 | 工作日晚间执行 |
0 0 * * 0 |
每周日 0:00 | 周日凌晨维护窗口 |
0 12 1,15 * * |
每月 1 号和 15 号 12:00 | 半月度任务 |
0 8-18 * * * |
每天 8:00-18:00 每小时 | 工作时间监控 |
@daily |
每天 0:00 | 简写形式 |
@weekly |
每周日 0:00 | 简写形式 |
@hourly |
每小时 0 分 | 简写形式 |
特殊字符说明:
* :任意值(每分钟/每小时/每天)
, :列表(1,15 表示 1 和 15)
- :范围(1-5 表示 1 到 5)
/ :步长(*/5 表示每 5 个单位)
Tips 如果你记不住 Cron 语法,可以使用在线工具辅助: - https://crontab.guru/ - 输入表达式,它用自然语言解释含义 - https://crontab-generator.org/ - 勾选时间条件,自动生成表达式
8.3 定时任务模板
模板1:每日新闻摘要
- id: "news-digest"
name: "每日行业新闻"
schedule: "0 8 * * *"
enabled: true
actions:
- type: "prompt"
content: |
搜索今天 {{date}} 的 {{industry}} 行业重要新闻。
整理成 3-5 条要点,每条包含:
- 标题(加粗)
- 一句话摘要
- 来源链接
用中文输出,格式清晰易读。
- type: "notify"
platform: "telegram"
user_id: "12345678"
message_template: |
📰 {{date}} 行业新闻
{{result}}
模板2:每日/周/月报告
- id: "daily-report"
name: "每日数据简报"
schedule: "0 9 * * *"
actions:
- type: "mcp"
server: "postgres"
tool: "query"
arguments:
sql: |
SELECT
COUNT(*) FILTER (WHERE created_at >= CURRENT_DATE) as today,
COUNT(*) FILTER (WHERE created_at >= CURRENT_DATE - 1) as yesterday
FROM orders;
- type: "prompt"
content: |
基于以下数据生成今日简报:
{{previous_result}}
格式要求:
📊 今日数据简报 ({{date}})
订单数: X 单(环比昨日 ±X%)
...
- type: "notify"
platform: "lark"
模板3:系统监控告警
- id: "health-check"
name: "服务健康检查"
schedule: "*/5 * * * *"
timeout: 10
actions:
- type: "http"
method: "GET"
url: "https://api.myapp.com/health"
- type: "condition"
if: "{{status}} != 200 or {{response_time}} > 2000"
then:
- type: "notify"
platform: "telegram"
message_template: |
🚨 服务异常告警
时间: {{timestamp}}
状态码: {{status}}
响应时间: {{response_time}}ms
请立即检查!
模板4:社交媒体内容发布
- id: "social-post"
name: "定时发布内容"
schedule: "0 10,15 * * *"
actions:
- type: "prompt"
content: |
生成一条关于 {{topic}} 的社交媒体帖子。
平台: 微信公众号
风格: 专业但亲切
字数: 300-500 字
包含一个相关话题标签。
- type: "notify"
platform: "telegram"
message_template: |
📝 待发布内容:
{{result}}
请审核后手动发布。
模板5:竞品监控
- id: "competitor-monitor"
name: "竞品动态监控"
schedule: "0 9 * * *"
actions:
- type: "prompt"
content: |
搜索 {{competitor}} 最近 24 小时的动态:
1. 新产品/功能发布
2. 官方博客更新
3. 社交媒体重要发文
4. 融资/合作新闻
整理成简报,标记需要关注的重要信息。
- type: "notify"
platform: "lark"
8.4 hermes cron 命令详解
# 查看 cron 帮助
$ hermes cron --help
Usage: hermes cron [OPTIONS] COMMAND [ARGS]...
管理定时任务
Commands:
list 列出所有任务
run 手动执行一个任务
enable 启用任务
disable 禁用任务
logs 查看任务执行日志
validate 验证配置文件语法
常用命令:
# 列出所有任务
$ hermes cron list
输出示例:
ID NAME SCHEDULE STATUS LAST_RUN
─────────────────────────────────────────────────────────────────────
daily-news 每日 AI 新闻摘要 0 8 * * * ✓ 启用 2小时前
weekly-report 每周数据报告 0 9 * * MON ✓ 启用 3天前
website-monitor 网站可用性监控 */5 * * * * ✓ 启用 5分钟前
# 手动执行一个任务(调试用)
$ hermes cron run daily-news
# 启用/禁用任务
$ hermes cron enable daily-news
$ hermes cron disable weekly-report
# 查看任务日志
$ hermes cron logs daily-news --tail 20
# 验证配置文件语法
$ hermes cron validate
# 实时监控任务执行
$ hermes cron logs --follow
8.5 调试技巧
定时任务出问题时,按以下步骤排查:
步骤1:验证配置语法
$ hermes cron validate
✅ 配置文件语法正确
任务数: 5
启用: 4, 禁用: 1
警告:
- 任务 "backup-db" 没有设置超时时间,将使用默认值 300 秒
步骤2:手动执行任务
$ hermes cron run daily-news --verbose
🔄 手动执行任务: daily-news
────────────────────────────────────
步骤1: prompt - 执行中...
✓ 步骤1完成 (耗时 3.2s)
步骤2: notify - 执行中...
✓ 步骤2完成 (耗时 0.5s)
────────────────────────────────────
任务完成,总计耗时 3.7s
步骤3:检查日志
# 查看最近失败的执行
$ hermes cron logs --status failed --last 24h
# 查看特定任务的详细日志
$ hermes cron logs website-monitor --tail 50
常见问题:
| 问题 | 原因 | 解决 |
|---|---|---|
| 任务没有按时执行 | Cron 服务未启动 | hermes cron start |
| 执行了但没有收到通知 | 通知配置错误 | 检查 platform 和 user_id |
| MCP 查询超时 | 数据库连接慢 | 增加 timeout 配置 |
| 任务执行成功但结果不对 | Prompt 不够明确 | 优化 prompt 内容 |
Tips 开发新任务时,建议先用
hermes cron run <task-id> --verbose手动执行几次,确认输出正确后再等待定时触发。这能节省大量等待时间。
9. 多 Agent 编排
9.1 delegate_task 机制
Hermes 支持一个强大的功能:多 Agent 编排。你可以把复杂任务拆解成子任务,分配给多个专门的 Agent 并行处理。
这就像一个项目经理(主 Agent)把大项目拆成多个模块,分配给不同的专家(子 Agent)同时开工,最后汇总结果。
# 在任务配置中使用 delegate_task
- id: "complex-analysis"
name: "复杂投研分析"
actions:
- type: "delegate"
# 最多 3 个子 Agent 并行
max_workers: 3
tasks:
- id: "market-research"
name: "市场调研"
prompt: |
分析 {{company}} 所在行业的市场规模、增长趋势、
竞争格局。重点关注最近一年的变化。
- id: "financial-analysis"
name: "财务分析"
prompt: |
分析 {{company}} 的财务报表:
- 营收和利润趋势
- 现金流状况
- 关键财务比率
- id: "tech-assessment"
name: "技术评估"
prompt: |
评估 {{company}} 的技术实力:
- 核心技术和专利
- 技术团队规模和质量
- 技术护城河
# 汇总结果
merge_prompt: |
将以下三个维度的分析结果整合成一份完整的投研报告:
## 市场调研
{{market-research.result}}
## 财务分析
{{financial-analysis.result}}
## 技术评估
{{tech-assessment.result}}
要求:
1. 给出综合评分(1-10)
2. 指出关键风险点
3. 给出投资建议
9.2 最多 3 子 Agent 并行
Hermes 目前最多支持 3 个子 Agent 并行。这个限制不是技术问题,而是有意设计的:
- 成本控制:每个子 Agent 都消耗 API Token,并行太多会迅速耗尽预算
- 质量保障:并行任务过多,主 Agent 整合结果时会遗漏关键信息
- 可调试性:3 个并行任务是最容易追踪和排错的规模
如果你的任务需要更多并行度,建议分层编排:
第一层:拆成 3 个大模块
├─ 模块A → 第二层:再拆 3 个子任务
├─ 模块B → 第二层:再拆 3 个子任务
└─ 模块C → 第二层:再拆 3 个子任务
注意 多层嵌套的 delegate 会增加总耗时和成本。建议只在确实需要并行处理时才使用,简单任务直接用顺序执行即可。
9.3 实战案例:投研/内容/代码审查流水线
案例1:AI 投研流水线
- id: "investment-research"
name: "AI 投研报告生成"
schedule: "0 7 * * MON"
actions:
- type: "delegate"
max_workers: 3
tasks:
- id: "collect-data"
name: "数据收集"
prompt: |
收集 {{target_company}} 的最新公开信息:
1. 搜索最近一周的新闻
2. 查找最新财报数据
3. 收集行业研报摘要
- id: "sentiment-analysis"
name: "舆情分析"
prompt: |
分析 {{target_company}} 的市场情绪:
1. 社交媒体讨论热度
2. 分析师评级变化
3. 投资者情绪指标
- id: "peer-comparison"
name: "同业对比"
prompt: |
将 {{target_company}} 与主要竞品对比:
1. 市值和估值对比
2. 营收增速对比
3. 技术实力对比
merge_prompt: |
基于收集的数据、舆情分析和同业对比,
生成一份专业的投研报告,包含:
- 执行摘要
- 核心数据
- 风险评估
- 投资建议
- type: "notify"
platform: "lark"
message_template: |
📊 投研报告已生成
标的: {{target_company}}
生成时间: {{timestamp}}
{{result}}
案例2:内容工厂流水线
- id: "content-factory"
name: "自动化内容生产"
actions:
- type: "delegate"
max_workers: 3
tasks:
- id: "topic-research"
name: "选题研究"
prompt: |
基于热点事件 {{event}},
生成 5 个适合社交媒体传播的内容选题。
每个选题包含:标题角度、目标平台、预期效果。
- id: "content-draft"
name: "内容起草"
prompt: |
为选题 "{{topic}}" 撰写完整内容:
- 微信公众号版本(800 字)
- 小红书版本(300 字+表情)
- Twitter 版本(280 字)
- id: "visual-design"
name: "配图建议"
prompt: |
为内容 "{{topic}}" 设计配图方案:
- 主视觉描述(供设计师参考)
- 信息图数据点
- 配色建议
merge_prompt: |
整合选题、内容和配图方案,
输出完整的内容发布计划表。
案例3:代码审查流水线
- id: "code-review-pipeline"
name: "自动化代码审查"
# 监听 GitHub Webhook,PR 创建时触发
trigger:
type: "webhook"
source: "github"
event: "pull_request.opened"
actions:
- type: "delegate"
max_workers: 3
tasks:
- id: "security-check"
name: "安全检查"
prompt: |
审查 PR {{pr_url}} 的安全问题:
- SQL 注入风险
- XSS 漏洞
- 敏感信息泄露
- 依赖包漏洞
- id: "quality-check"
name: "代码质量"
prompt: |
审查 PR {{pr_url}} 的代码质量:
- 代码复杂度
- 测试覆盖率
- 代码风格一致性
- 设计模式使用
- id: "logic-check"
name: "业务逻辑"
prompt: |
审查 PR {{pr_url}} 的业务逻辑:
- 需求实现是否完整
- 边界条件处理
- 异常处理
- 性能影响
merge_prompt: |
整合三方审查意见,生成完整的代码审查报告。
按严重程度分类,给出明确的修改建议。
- type: "mcp"
server: "github"
tool: "add_issue_comment"
arguments:
repo: "{{repo}}"
issue_number: "{{pr_number}}"
body: "{{result}}"
10. 自动化流水线设计
10.1 MCP + Cron + 多 Agent 组合
真正的自动化威力来自于把 MCP、Cron 和多 Agent 编排组合在一起。这三个组件的关系就像乐高积木:
- MCP = 积木块(能做什么)
- Cron = 定时器(什么时候做)
- 多 Agent = 分工协作(怎么做最高效)
10.2 全自动 AI 投研流水线示例
让我们设计一个完整的、全自动的投研流水线:
# ~/.hermes/cron/tasks.yaml
- id: "auto-research-pipeline"
name: "全自动投研流水线"
# 每天开盘前执行
schedule: "0 8 * * MON-FRI"
enabled: true
timeout: 600
actions:
# 步骤1:并行数据收集(3 个子 Agent)
- type: "delegate"
max_workers: 3
tasks:
- id: "market-data"
name: "市场数据"
prompt: |
获取今日市场数据:
- 大盘指数(上证、深证、创业板)
- 北向资金流向
- 涨跌停家数
- 板块涨跌排名
- id: "news-scan"
name: "新闻扫描"
prompt: |
扫描今日重要财经新闻:
- 政策面消息
- 行业动态
- 个股公告
- 国际市场影响
- id: "technical-analysis"
name: "技术面"
prompt: |
分析自选股的技术面:
- K线形态
- 均线系统
- MACD/KDJ 指标
- 支撑压力位
merge_prompt: |
将市场数据、新闻扫描和技术面分析汇总,
生成早盘简报。
# 步骤2:保存到 Notion
- type: "mcp"
server: "notion"
tool: "notion_append_block_children"
arguments:
page_id: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
children:
- type: "heading_2"
text: "{{date}} 早盘简报"
- type: "paragraph"
text: "{{previous_result}}"
# 步骤3:发送到飞书群
- type: "notify"
platform: "lark"
channel: "投研群"
message_template: |
📊 {{date}} 早盘简报已生成
已保存至 Notion 知识库。
重点关注的板块:{{highlight_sectors}}
点击查看详情
10.3 全自动内容工厂示例
- id: "content-factory-pipeline"
name: "全自动内容工厂"
schedule: "0 6 * * *"
actions:
# 步骤1:确定今日选题
- type: "prompt"
content: |
基于今天的日期 {{date}} 和热点事件,
为科技自媒体账号确定 3 个内容选题。
要求:
- 与 AI/科技相关
- 有话题性和传播潜力
- 适合公众号+小红书双平台发布
# 步骤2:为每个选题并行生产内容
- type: "delegate"
max_workers: 3
tasks:
- id: "content-1"
name: "选题1内容"
prompt: |
为选题 "{{topics[0]}}" 撰写:
1. 公众号文章(1000 字,专业深度)
2. 小红书笔记(300 字,轻松活泼)
3. 配图描述(3 张图)
- id: "content-2"
name: "选题2内容"
prompt: |
为选题 "{{topics[1]}}" 撰写:
1. 公众号文章
2. 小红书笔记
3. 配图描述
- id: "content-3"
name: "选题3内容"
prompt: |
为选题 "{{topics[2]}}" 撰写:
1. 公众号文章
2. 小红书笔记
3. 配图描述
merge_prompt: |
整理三份内容的生产计划:
- 发布时间表
- 内容要点
- 配图需求清单
# 步骤3:保存到 Notion 发布日历
- type: "mcp"
server: "notion"
tool: "notion_create_database_item"
arguments:
database_id: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
properties:
标题: "{{date}} 内容计划"
状态: "待审核"
内容: "{{result}}"
# 步骤4:通知审核
- type: "notify"
platform: "telegram"
message_template: |
📝 今日内容已生成,请审核
已保存至 Notion 发布日历。
共 3 篇内容待审核。
10.4 错误处理与告警
自动化流水线必须具备健壮的错误处理能力:
- id: "reliable-pipeline"
name: "带容错的流水线"
actions:
- type: "try"
try:
- type: "mcp"
server: "github"
tool: "search_issues"
arguments:
repo: "mycompany/project"
query: "is:open label:bug"
catch:
- type: "notify"
platform: "telegram"
message_template: |
⚠️ 任务步骤失败
任务: {{task_id}}
步骤: GitHub 查询
错误: {{error}}
已跳过此步骤,继续执行后续任务。
- type: "prompt"
content: |
基于获取的数据生成报告。
如果数据为空,请说明"今日无新增 Bug"。
# 最终通知,无论成功失败都发送
- type: "notify"
platform: "lark"
message_template: |
任务 {{task_id}} 执行完成
状态: {{status}}
{{#if error}}
异常信息: {{error}}
{{/if}}
告警升级策略:
global:
notifications:
on_failure: true
escalation:
# 第一次失败:立即通知
- after: 0
channels:
- platform: "telegram"
user_id: "12345678"
# 连续失败 3 次:升级告警
- after: 3
channels:
- platform: "lark"
user_id: "ou_xxxxxxxx"
# 连续失败 5 次:电话/短信告警
- after: 5
channels:
- platform: "sms"
phone: "+86138xxxxxxxx"
11. 安全与合规
11.1 权限最小化
自动化系统的安全基石是最小权限原则(Principle of Least Privilege)。
Token 权限控制:
# GitHub:使用 Fine-grained Token,限定只读特定仓库
mcp_servers:
github-readonly:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-github"]
env:
GITHUB_PERSONAL_ACCESS_TOKEN: "${GITHUB_READONLY_TOKEN}"
allowed_tools:
- "search_repositories"
- "get_file_contents"
# 禁止所有写操作!
# 数据库:使用只读账号
mcp_servers:
postgres:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-postgres"]
env:
# 这个 URL 连接的是只读副本,账号只有 SELECT 权限
POSTGRES_URL: "${DATABASE_READONLY_URL}"
分层权限设计:
┌─────────────────────────────────────────┐
│ 生产环境(Production) │
│ - 只读数据库连接 │
│ - 只读 GitHub Token │
│ - 禁止发送消息/邮件 │
└─────────────────────────────────────────┘
▲
┌─────────────────────────────────────────┐
│ staging 环境 │
│ - 读写测试数据库 │
│ - 可创建 Issue/PR(测试仓库) │
│ - 可发送到测试群组 │
└─────────────────────────────────────────┘
▲
┌─────────────────────────────────────────┐
│ 开发环境(Development) │
│ - 完全权限(本地数据库) │
│ - 完整 GitHub Token(个人仓库) │
│ - 可发送到个人账号 │
└─────────────────────────────────────────┘
11.2 敏感数据处理
自动化任务经常需要处理敏感数据。Hermes 提供多层保护:
环境变量隔离:
# 敏感信息只通过环境变量传入,不写入配置文件
export GITHUB_TOKEN="ghp_xxx"
export DATABASE_PASSWORD="secret"
export SLACK_BOT_TOKEN="xoxb-xxx"
日志脱敏:
global:
security:
# 日志中自动脱敏的模式
log_redaction:
- pattern: "ghp_[a-zA-Z0-9]{36}"
replacement: "[GITHUB_TOKEN]"
- pattern: "xoxb-[a-zA-Z0-9-]{10,}"
replacement: "[SLACK_TOKEN]"
- pattern: "password[=:]\s*\S+"
replacement: "password=[REDACTED]"
数据访问审计:
global:
audit:
enabled: true
log_file: "~/.hermes/logs/audit.log"
# 记录所有 MCP 工具调用
log_mcp_calls: true
# 记录所有数据库查询
log_database_queries: true
11.3 Rate Limit 与成本控制
自动化任务如果不加限制,可能在短时间内产生大量 API 调用,导致: 1. 触发平台的 Rate Limit 2. 产生意想不到的账单
Rate Limit 配置:
global:
rate_limit:
# 每个 MCP Server 的调用频率限制
mcp:
github:
requests_per_minute: 30
requests_per_hour: 500
notion:
requests_per_minute: 20
openai:
requests_per_minute: 60
# 全局预算控制
budget:
daily_max_tokens: 1000000 # 每日最大 Token 数
daily_max_cost_usd: 50 # 每日最大花费(美元)
alert_threshold: 80 # 达到 80% 时告警
成本监控:
# 查看今日 API 使用情况
$ hermes stats --today
今日 API 使用情况
─────────────────────────────────
OpenAI API:
请求数: 1,234
Token 数: 456,789
预估费用: $2.34
GitHub API:
请求数: 567
剩余额度: 4,433/5000
总计费用: $2.34
预算使用: 4.7%
11.4 审计日志
完整的审计日志是合规和排错的必需品:
global:
audit:
enabled: true
# 审计日志存储
storage:
type: "file" # file, database, remote
path: "~/.hermes/audit/"
retention_days: 90 # 保留 90 天
# 审计事件类型
events:
- "mcp.tool_called" # MCP 工具调用
- "mcp.server_connected" # MCP Server 连接
- "cron.task_executed" # 定时任务执行
- "cron.task_failed" # 定时任务失败
- "gateway.message_received" # 收到用户消息
- "config.changed" # 配置变更
# 审计日志格式
format:
include_timestamp: true
include_user_id: true
include_ip: false
include_full_prompt: false # 不包含完整 prompt(隐私)
审计日志示例:
{
"timestamp": "2024-01-15T08:00:00+08:00",
"event": "mcp.tool_called",
"level": "info",
"user_id": "zhangsan",
"details": {
"server": "github",
"tool": "create_issue",
"arguments": {
"repo": "mycompany/project",
"title": "[REDACTED]"
},
"result": "success",
"duration_ms": 1234
}
}
本章小结(第十一册) 在本章中,我们深入学习了 Hermes 的自动化能力: - 理解了 MCP 协议的设计理念、架构和通信机制 - 掌握了 Hermes 中 MCP 的配置方法,包括 stdio 和 HTTP 两种模式 - 完成了 GitHub、Notion、Linear、Figma、Slack、Google Calendar、数据库等服务的实战接入 - 了解了 6000+ MCP 服务生态的全貌和安全评估方法 - 学会了 Cron 定时任务系统的配置和常用模板 - 掌握了多 Agent 编排和自动化流水线的设计方法 - 建立了权限最小化、敏感数据保护、Rate Limit 和审计日志的安全体系
现在,你的 Hermes 已经从一个"对话式 AI"进化为一个真正的"自动化 Agent"——它能接入外部世界、按时自动执行任务、多个 Agent 协同工作、并且安全可控。这才是 AI Agent 的完整形态。
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十二册:高阶玩法与实战案例
本章你将学到
- 从入门到高阶的完整进阶路线图,明确你当前所处的阶段和下一步方向
- Hermes 沙箱环境的安全分级配置,让 Agent 既能干活又不会"闯祸"
- 语音交互的高级玩法,包括 STT/TTS 配置、多语言支持和语音触发工作流
- 六个完整的实战案例:AI 投研流水线、内容自动化工厂、代码质量守护者、个人知识管理系统、智能客服机器人、数据监控与告警
- 企业级应用场景的部署方案和安全合规考量
- 八大高阶技巧:模型热切换、记忆压缩、技能链式调用、并行任务加速等
预计阅读时间:120-150 分钟
建议准备:一台已安装 Hermes 的电脑(参考第五册)、一个可用的 API Key(OpenAI/Anthropic/DeepSeek 均可)
1. 高阶玩法总览
1.1 从入门到高阶的进阶路线图
恭喜你,如果你正在阅读这一章,说明你已经完成了 Hermes 的基础学习——安装、配置、对话、基础技能使用都已经不在话下。现在,是时候把 Hermes 从"玩具"升级为"生产力工具"了。
让我先给你画一张进阶路线图,帮你定位自己当前的位置。
第一阶段:新手村(已完成)
- [x] 成功安装并运行 Hermes
- [x] 能进行基础对话和简单任务
- [x] 了解记忆系统和技能系统的基本概念
- [x] 接入至少一个大模型(OpenAI/Anthropic/本地模型)
第二阶段:熟练工(当前阶段)
- [ ] 掌握沙箱安全配置,敢于让 Agent 执行系统命令
- [ ] 学会语音交互配置,实现"动口不动手"
- [ ] 能够搭建第一个自动化工作流(如定时日报)
- [ ] 熟悉 MCP 协议,能接入外部工具服务
- [ ] 掌握多平台接入(Telegram/飞书/微信等)
第三阶段:高阶玩家
- [ ] 搭建完整的 Multi-Agent 系统
- [ ] 实现复杂的业务自动化流水线
- [ ] 自定义工具开发和技能链式调用
- [ ] 性能优化和成本控制的精细调优
- [ ] 企业级部署和安全合规配置
第四阶段:大师级
- [ ] 为社区贡献高质量技能插件
- [ ] 参与核心代码开发和架构设计
- [ ] 基于 Hermes 构建商业产品或服务
- [ ] 指导和培训其他用户
类比
把学 Hermes 比作学做菜。第一阶段是你刚学会用燃气灶和基本刀工;第二阶段是你能炒几个家常菜了;第三阶段是你能招待一桌客人,冷热搭配、荤素均衡;第四阶段是你能开餐厅、创新菜品、带徒弟。本章的目标,是带你从"家常菜"迈向"宴席级别"。
1.2 高阶玩家的典型工作流
高阶玩家使用 Hermes 的方式,和新手有着本质的不同。让我用一个典型的高阶玩家一天来给你展示。
早上 8:00 —— 自动日报推送
Hermes 的 Cron 任务准时触发。它已经完成了以下工作: - 从 Hacker News、GitHub Trending、Twitter 抓取了昨晚的 AI 行业热点 - 用数据清洗 Agent 过滤了噪声信息 - 用分析 Agent 提炼了关键趋势 - 生成了一份格式化的 Markdown 报告 - 通过 Telegram Bot 推送到了你的手机
你睁开眼睛,拿起手机就能看到 curated 好的行业动态。
上午 10:00 —— 语音启动投研任务
你对着手机说:"Hermes,帮我分析一下今天加密货币市场的走势,重点关注以太坊和 Solana。"
Hermes 接收到语音指令,转换为文本,触发预定义的投资研究工作流: - 调用价格监控工具获取实时数据 - 读取过去 7 天的历史数据 - 分析链上指标(交易量、活跃地址数) - 检索记忆中的投资策略和风险管理规则 - 生成一份简短的投资建议报告
整个过程你不需要打字,也不需要盯着屏幕。
下午 2:00 —— 代码审查自动化
你提交了一个 Pull Request 到公司的代码仓库。Hermes 的 Git Hook 自动触发: - 读取 PR 中的代码变更 - 进行静态分析和安全扫描 - 检查代码风格是否符合团队规范 - 生成审查报告,标注潜在问题和改进建议 - 在 PR 下方自动发布评论
晚上 7:00 —— 内容自动发布
你运营着几个自媒体账号。Hermes 的内容自动化工厂在后台运行: - 选题 Agent 从热点追踪中筛选出适合的话题 - 写作 Agent 生成了 5 篇不同风格的 AI 快讯 - 审校 Agent 检查了事实准确性和表达流畅度 - 格式化 Agent 为不同平台(公众号、小红书、抖音)生成了适配版本 - 定时发布 Agent 按照最优时间推送到了各个平台
晚上 10:00 —— 知识归档
你今天浏览了很多文章和论文。Hermes 的知识管理系统: - 自动提取了你收藏的 RSS 文章的关键信息 - 对内容进行了智能分类和标签化 - 更新了个人知识图谱 - 将相关内容关联到了你之前的笔记 - 为明天的"每日回顾"准备了摘要
这就是高阶玩家的 Hermes —— 不是你在"用"它,而是它在"为你工作"。
Tips
不要被这个"理想化"的一天吓到。这些功能不是一天就能搭好的。高阶玩家的 Hermes 也是从小自动化开始,逐步叠加功能,最终形成一个完整的生态。本章的目的,就是手把手教你搭建这些系统。
1.3 本章实战案例的阅读方法
本章包含六个大型实战案例,每个案例都是一个完整的系统。为了让你最高效地学习,我建议以下阅读策略:
策略一:先通读,再精修
不要一开始就试图把某个案例的每行代码都搞懂。先快速浏览整个案例的架构和流程,理解"它做了什么"和"为什么这么做"。等你有了全局视角,再深入到具体配置和代码。
策略二:挑一个最感兴趣的先做
六个案例覆盖了不同领域:投研、内容创作、代码审查、知识管理、客服、数据监控。选择你最感兴趣或者最急需的那个,按照步骤完整搭建一遍。完成一个案例带来的成就感,会激励你继续做下一个。
策略三:从最小可用版本(MVP)开始
每个案例我都提供了"完整版"配置,但完整版可能涉及很多组件。我建议你先搭建一个最小可用版本——只保留核心功能,去掉锦上添花的功能。等 MVP 跑通了,再逐步添加高级功能。
策略四:边做边改
案例中的配置是"通用版",不一定完全适合你的需求。边做边根据自己的实际情况调整参数、修改逻辑、增减功能。最好的学习就是在实践中迭代。
注意
本章的所有案例都涉及外部服务(API、平台、数据库等)。在执行之前,请确保你已经阅读了每个案例的"前置准备"部分,并准备好了所需的 API Key 和账号。不要为了省事跳过安全设置——生产环境中一个配置错误可能导致数据泄露或财产损失。
2. 沙箱配置与安全调优
2.1 执行环境的安全分级
在让 Hermes 执行系统命令或运行代码之前,安全是你必须考虑的第一件事。想象一下,如果你的 Agent 不小心执行了 rm -rf /,或者运行了一个包含恶意代码的脚本,后果会怎样?
Hermes 的沙箱系统就是为了解决这个问题而设计的。它把代码执行环境分为四个安全等级,就像一个军营有不同的安全区域:
| 安全等级 | 名称 | 权限范围 | 适用场景 |
|---|---|---|---|
| Level 0 | 完全隔离 | 只读文件系统,禁止网络访问 | 运行完全不可信的代码 |
| Level 1 | 受限执行 | 可读写临时目录,限制网络访问 | 运行来源不明的脚本 |
| Level 2 | 标准沙箱 | 可读写工作目录,允许外部网络 | 日常任务执行 |
| Level 3 | 信任模式 | 完整系统访问,无限制 | 自己编写的可信代码 |
类比
安全等级就像机场的安检级别。Level 0 是最高级别——你要脱鞋、解皮带、全身扫描,什么东西都不能带。Level 3 就是 VIP 通道——快速通过,基本不检查。不同的航班(任务)需要不同的安检级别。
2.2 沙箱(Sandbox)配置详解
Hermes 的沙箱基于 Docker 容器和系统级隔离技术实现。下面是详细的配置方法。
基础配置(在 config.yaml 中)
# ============================================
# 沙箱安全配置文件 - config.yaml
# ============================================
sandbox:
# 默认安全等级:所有未明确指定的任务使用此等级
default_level: 2
# Docker 镜像配置
docker:
# 基础镜像,包含 Python、Node.js、常用工具
image: "hermes/sandbox:latest"
# 是否自动拉取最新镜像
auto_pull: true
# 容器资源限制
resources:
# CPU 核心数限制
cpus: 2.0
# 内存限制(MB)
memory: 1024
# 临时存储限制(MB)
disk: 512
# 网络访问控制
network:
# 是否允许容器访问外部网络
enabled: true
# 允许访问的域名白名单(为空表示允许所有)
allowed_hosts:
- "api.openai.com"
- "api.anthropic.com"
- "github.com"
- "registry.npmjs.org"
# 禁止访问的域名黑名单
blocked_hosts:
- "localhost"
- "127.0.0.1"
- "0.0.0.0"
# 文件系统权限
filesystem:
# 只读目录(容器内无法修改)
read_only:
- "/app/templates"
- "/app/config"
# 可读写目录
read_write:
- "/app/workspace"
- "/tmp"
# 禁止访问的路径
forbidden:
- "/etc/passwd"
- "/etc/shadow"
- "/root/.ssh"
- "~/.aws"
# 命令执行超时(秒)
timeout: 300
# 环境变量隔离
env_isolation: true
按任务类型设置安全等级
你可以在 Skill 或工作流配置中为特定任务指定安全等级:
# skills/web_search.yaml
name: "web_search"
description: "执行网络搜索"
# 此技能只需要访问外部网络,不需要本地文件操作
sandbox:
level: 2
network:
enabled: true
filesystem:
read_write:
- "/tmp/search_results"
---
# skills/code_execution.yaml
name: "code_execution"
description: "执行用户提供的代码"
# 用户代码不可信,使用严格隔离
sandbox:
level: 0
docker:
resources:
cpus: 1.0
memory: 512
disk: 256
timeout: 60
Tips
一个实用的经验法则:凡是涉及用户输入的代码执行,都至少用 Level 1;完全不可信的来源用 Level 0;你自己写的自动化脚本可以用 Level 3。 宁可在安全上过度配置,也不要为了方便留下隐患。
2.3 命令审批机制的自定义
Hermes 有一个非常重要的安全功能:命令审批(Command Approval)。当 Agent 要执行某些敏感操作时,会先暂停并征求你的确认。
配置审批规则
# config.yaml 中的审批配置
approval:
# 全局开关
enabled: true
# 审批模式:manual(手动)/ auto(自动)/ conditional(条件)
mode: "conditional"
# 条件审批规则
rules:
# 规则1:文件删除操作必须审批
- name: "file_deletion"
pattern: "rm\\s+-[rf]*\\s+.*"
action: "require_approval"
message: "⚠️ 检测到文件删除命令,请确认是否执行:{command}"
# 规则2:系统级命令必须审批
- name: "system_commands"
pattern: "(sudo|chmod|chown|mkfs|fdisk)\\s+.*"
action: "require_approval"
message: "⚠️ 检测到系统级命令,需要管理员权限,请确认:{command}"
# 规则3:网络请求自动通过(在允许域名内)
- name: "network_requests"
pattern: "(curl|wget|fetch)\\s+.*"
action: "auto_approve"
condition: "host_in_whitelist"
# 规则4:数据库操作必须审批
- name: "database_ops"
pattern: "(DROP|DELETE|TRUNCATE|UPDATE)\\s+.*"
action: "require_approval"
message: "⚠️ 检测到数据修改命令,请确认:{command}"
# 规则5:大规模文件操作提醒
- name: "bulk_operations"
pattern: "find\\s+.*-delete|rm\\s+-rf\\s+/.*"
action: "block"
message: "🚫 危险命令已拦截:{command}"
审批通知方式
approval:
# 通知渠道配置
notifications:
# 终端交互式审批(默认)
- channel: "terminal"
enabled: true
timeout: 60 # 等待用户输入的超时时间(秒)
# Telegram 审批(适合远程/无人值守场景)
- channel: "telegram"
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${TELEGRAM_CHAT_ID}"
timeout: 300 # 给用户更多时间响应
# 邮件审批(适合企业环境)
- channel: "email"
enabled: false
smtp_server: "smtp.gmail.com"
to: "admin@company.com"
timeout: 3600
注意
如果你把 Hermes 部署在服务器上并启用了 Web 界面或第三方平台接入,务必配置 Telegram 或邮件审批。否则当 Agent 需要审批时,你会在终端看不到提示,任务就会一直卡住。
2.4 信任级别设置
Hermes 允许你为不同的 Skill、工具或工作流设置信任级别,实现更细粒度的安全控制。
# trust_levels.yaml
# 信任级别配置文件
trust_levels:
# 内置工具和官方 Skill —— 完全信任
builtin:
sources:
- "hermes.builtin.*"
- "hermes.official.*"
permissions:
sandbox_level: 3
auto_approve: true
network_access: true
# 社区贡献的 Skill —— 有限信任
community:
sources:
- "hermes.community.*"
permissions:
sandbox_level: 1
auto_approve: false
network_access: true
filesystem:
read_only:
- "/app/data"
read_write:
- "/tmp"
# 用户自己编写的 Skill —— 根据用户选择
user:
sources:
- "user.*"
permissions:
sandbox_level: 2 # 默认标准沙箱
auto_approve: false
network_access: true
# 从未知来源安装的 Skill —— 最高警惕
untrusted:
sources:
- "*"
permissions:
sandbox_level: 0
auto_approve: false
network_access: false
filesystem:
read_only: []
read_write:
- "/tmp/isolated"
2.5 生产环境安全清单
在将 Hermes 部署到生产环境之前,请逐一检查以下清单:
# Hermes 生产环境安全清单
## 沙箱配置
- [ ] 默认安全等级不超过 Level 2
- [ ] 容器资源限制已配置(CPU、内存、磁盘)
- [ ] 网络白名单已配置,仅允许必要的域名
- [ ] 文件系统禁止访问敏感路径(SSH 密钥、密码文件等)
## 审批机制
- [ ] 命令审批已启用
- [ ] 危险的系统命令(rm -rf、sudo 等)需要审批
- [ ] 数据库 DROP/DELETE 操作需要审批
- [ ] 审批通知渠道已配置且可正常接收
## 访问控制
- [ ] API Key 存储在环境变量中,不在配置文件里写明文
- [ ] SSH 密钥、密码等凭证不在代码仓库中
- [ ] `.env` 文件已加入 `.gitignore`
- [ ] 如使用 Docker,容器以非 root 用户运行
## 网络安全
- [ ] 防火墙规则已配置,仅开放必要端口
- [ ] HTTPS 已启用(如暴露 Web 接口)
- [ ] 反爬虫/速率限制已配置
- [ ] 日志中不包含敏感信息(API Key、密码等)
## 监控与告警
- [ ] 异常执行行为监控已启用
- [ ] 沙箱逃逸尝试告警已配置
- [ ] 资源使用监控已配置(防止资源耗尽攻击)
2.6 案例:安全地运行未知代码
假设你收到了一段别人发来的 Python 脚本,说是可以帮你"自动整理桌面文件"。你想让 Hermes 运行它,但又担心有安全隐患。这时候应该怎么做?
步骤1:创建隔离沙箱配置
# isolated_run.yaml
name: "safe_execution"
description: "安全执行未知来源代码"
sandbox:
level: 0 # 最高隔离级别
docker:
image: "hermes/sandbox:minimal"
resources:
cpus: 0.5
memory: 256
disk: 100
network:
enabled: false # 完全断网
filesystem:
read_only:
- "/app/code" # 只读挂载待执行的代码
read_write:
- "/tmp/output" # 只允许写到临时目录
timeout: 30 # 30秒超时
步骤2:使用 Hermes CLI 安全执行
# 将未知代码放入隔离目录
mkdir -p ./isolated_run
cp unknown_script.py ./isolated_run/
# 使用 Hermes 的隔离执行命令
$ hermes exec --sandbox isolated_run.yaml --file ./isolated_run/unknown_script.py
# 查看执行结果(只能从指定输出目录读取)
cat ./isolated_run/output/result.json
步骤3:分析代码行为(不执行)
如果你连隔离执行都不放心,可以让 Hermes 先静态分析代码:
# 让 Hermes 分析代码的功能和潜在风险
$ hermes analyze --file unknown_script.py --depth detailed
# 预期输出示例:
# [ANALYSIS] 检测到以下行为:
# - 文件读取操作:读取 ~/Desktop 目录
# - 文件写入操作:在 ~/Desktop 创建整理后的文件夹
# - 网络操作:无
# - 系统调用:无
# - 风险评级:低(仅操作桌面文件,无敏感路径访问)
Tips
对于任何来源不明的代码,养成"先分析、再隔离执行、最后才正常执行"的习惯。Hermes 的
analyze命令会检查代码中的文件操作、网络请求、系统调用等行为,给你一个风险评级。这个习惯可能某天真会救你一命。
3. 语音交互高阶玩法
3.1 语音输入(STT)高级配置
语音输入(Speech-to-Text,简称 STT)让你可以用说话代替打字,跟 Hermes 交互。这对于双手忙碌的场景(开车、做饭、运动)特别有用。
Hermes 支持多种 STT 引擎,从完全免费的本地模型到高质量的云端 API。
支持的 STT 引擎
| 引擎 | 类型 | 质量 | 延迟 | 成本 | 适用场景 |
|---|---|---|---|---|---|
| Whisper (本地) | 本地 | 中高 | 中等 | 免费 | 日常对话、隐私敏感 |
| Whisper API | 云端 | 高 | 低 | $0.006/分钟 | 高质量要求 |
| DeepSpeech | 本地 | 中 | 低 | 免费 | 资源受限设备 |
| Google STT | 云端 | 高 | 低 | $0.024/分钟 | 多语言支持 |
| Azure STT | 云端 | 高 | 低 | $1.0/小时 | 企业环境 |
基础配置
# config.yaml 中的 STT 配置
stt:
# 默认引擎
engine: "whisper_local"
# 本地 Whisper 配置
whisper_local:
# 模型大小:tiny/base/small/medium/large
# 越大越准,但也越慢、越吃资源
model: "base"
# 语言设置:auto 自动检测,或指定如 "zh", "en"
language: "auto"
# 设备:cpu / cuda(需要 NVIDIA 显卡)
device: "cpu"
# 是否翻译为英文(Whisper 特有功能)
translate: false
# Whisper API 配置
whisper_api:
api_key: "${OPENAI_API_KEY}"
model: "whisper-1"
language: "auto"
# Google STT 配置
google_stt:
credentials_path: "${GOOGLE_CREDENTIALS_PATH}"
language_code: "zh-CN"
# 是否启用自动标点
enable_automatic_punctuation: true
# 音频输入设置
audio:
# 采样率
sample_rate: 16000
# 录音时长限制(秒)
max_duration: 60
# 静音检测阈值(用于自动停止录音)
silence_threshold: 0.02
# 静音持续多久自动停止(秒)
silence_duration: 2.0
高级配置:语音活动检测(VAD)
VAD(Voice Activity Detection)让 Hermes 能够自动检测你什么时候开始说话、什么时候说完,不需要手动按"录音"按钮。
stt:
# VAD 配置
vad:
enabled: true
# VAD 引擎:webrtc / silero / energy
engine: "silero"
silero:
# 模型路径(自动下载)
model: "silero_vad"
# 检测阈值(0-1,越高越严格)
threshold: 0.5
# 最小语音长度(毫秒)
min_speech_duration_ms: 250
# 最大语音长度(毫秒)
max_speech_duration_s: 60
# 语音前预留的静音(毫秒)
speech_pad_ms: 100
唤醒词配置
你可以设置一个唤醒词(Wake Word),就像"Hey Siri"或"OK Google"一样。只有检测到唤醒词后,Hermes 才会开始录音和识别。
stt:
wake_word:
enabled: true
# 唤醒词
phrase: "嘿 Hermes"
# 唤醒词引擎:porcupine / snowboy / custom
engine: "porcupine"
# 灵敏度(0-1)
sensitivity: 0.7
# 唤醒后的监听超时(秒)
listen_timeout: 10
类比
唤醒词就像是办公室的敲门声。平时 Hermes 在"专注做自己的事"(不监听),只有听到"敲门声"(唤醒词),它才会抬头听你说话。这样既省电(不处理无意义的背景音),又保护隐私(不会误录你的私人对话)。
3.2 语音输出(TTS)高级配置
语音输出(Text-to-Speech,简称 TTS)让 Hermes 可以用说话的方式回复你,而不是显示文字。
支持的 TTS 引擎
| 引擎 | 类型 | 质量 | 延迟 | 成本 | 特点 |
|---|---|---|---|---|---|
| Piper | 本地 | 中高 | 低 | 免费 | 开源、轻量、支持多种语言 |
| Coqui TTS | 本地 | 高 | 中 | 免费 | 质量优秀,支持语音克隆 |
| Edge TTS | 云端(免费) | 高 | 低 | 免费 | 微软 Edge 浏览器同款 |
| OpenAI TTS | 云端 | 很高 | 中 | $0.015/1K字符 | 音质极佳,多种声音 |
| ElevenLabs | 云端 | 顶级 | 中 | $0.18/1K字符 | 最自然的语音 |
基础配置
# config.yaml 中的 TTS 配置
tts:
# 默认引擎
engine: "edge_tts"
# Edge TTS 配置(免费)
edge_tts:
# 语音选择
# 中文女声:zh-CN-XiaoxiaoNeural
# 中文男声:zh-CN-YunjianNeural
# 英文女声:en-US-JennyNeural
voice: "zh-CN-XiaoxiaoNeural"
# 语速:0.5-2.0
rate: "+0%"
# 音量
volume: "+0%"
# OpenAI TTS 配置
openai_tts:
api_key: "${OPENAI_API_KEY}"
model: "tts-1" # tts-1(快)或 tts-1-hd(高质)
voice: "alloy" # alloy/echo/fable/onyx/nova/shimmer
speed: 1.0
# Piper 本地 TTS 配置
piper:
model: "zh_CN-huayan-medium"
# 语速
length_scale: 1.0
# 音调
noise_scale: 0.667
# 输出设置
output:
# 播放设备:auto / 设备名称
device: "auto"
# 是否自动播放
auto_play: true
# 缓存语音文件(避免重复生成)
cache_enabled: true
cache_dir: "./cache/tts"
流式 TTS 配置(降低延迟)
传统的 TTS 是"生成完整文本的语音,然后再播放",延迟较高。流式 TTS 可以在文本生成的过程中就开始合成和播放,实现"边想边说"的效果。
tts:
# 流式输出配置
streaming:
enabled: true
# 句子分隔符(遇到这些符号就切分并合成)
sentence_delimiters: ".。!!??;;\n"
# 最小句子长度(字符数)
min_sentence_length: 10
# 最大缓冲区(句子数)
max_buffer_size: 3
# 是否启用打断(用户说话时停止播放)
allow_barge_in: true
Tips
如果你追求"极致自然"的语音体验,推荐 OpenAI TTS 的
tts-1-hd模型配合shimmer声音。如果你追求"免费且好用",Edge TTS 是最好的选择——它和微软 Edge 浏览器的"大声朗读"功能用的是同一个引擎,质量相当高。如果你需要完全离线运行(比如车载场景),Piper 或 Coqui TTS 是首选。
3.3 多语言语音支持
Hermes 的语音系统支持多种语言的输入和输出,你可以根据场景灵活切换。
# 多语言语音配置
stt:
# 默认语言
default_language: "zh"
# 语言切换命令(说出这些词可以临时切换语言)
language_switch:
enabled: true
commands:
"说中文": "zh"
"说英语": "en"
"说日语": "ja"
# 切换后的持续时间(秒),0 表示永久切换
duration: 0
# 自动语言检测
auto_detect:
enabled: true
# 可能检测到的语言列表
languages:
- "zh"
- "en"
- "ja"
- "ko"
tts:
# 按语言配置不同的 TTS 引擎和声音
language_mapping:
zh:
engine: "edge_tts"
voice: "zh-CN-XiaoxiaoNeural"
en:
engine: "edge_tts"
voice: "en-US-JennyNeural"
ja:
engine: "edge_tts"
voice: "ja-JP-NanamiNeural"
# 自动检测语言后,使用对应的声音
auto_switch: true
3.4 语音触发工作流
语音不只是用来聊天的,还可以用来触发复杂的工作流。比如你说"开始晨间例行",Hermes 就自动执行一系列任务。
# workflows/voice_triggered.yaml
name: "voice_workflows"
description: "语音触发的工作流配置"
voice_triggers:
# 触发词1:晨间例行
- trigger: "开始晨间例行"
workflow: "morning_routine"
description: "执行晨间信息收集和汇报"
# 触发词2:投研分析
- trigger: "帮我分析市场"
workflow: "market_analysis"
description: "触发投资研究工作流"
# 触发词3:代码审查
- trigger: "审查这段代码"
workflow: "code_review"
description: "对最近的代码提交进行审查"
# 触发词4:紧急暂停
- trigger: "停止所有任务"
action: "pause_all"
description: "立即停止所有正在执行的任务"
# 触发词5:状态查询
- trigger: "你在忙什么"
action: "status_report"
description: "语音汇报当前任务状态"
# 晨间例行的具体工作流
workflows:
morning_routine:
steps:
- action: "fetch_weather"
params:
location: "current"
- action: "fetch_news"
params:
sources: ["hacker_news", "github_trending"]
count: 10
- action: "check_calendar"
params:
period: "today"
- action: "generate_report"
template: "morning_brief"
- action: "tts_speak"
text: "{{report.summary}}"
3.5 车载/穿戴设备场景
Hermes 的语音交互在车载和穿戴设备场景中有特别的优势——这些场景下打字几乎不可能,语音是唯一的交互方式。
车载场景配置
# 车载场景专用配置
car_mode:
enabled: true
# 蓝牙音频输入/输出
bluetooth:
device_name: "Car Audio"
auto_connect: true
# 车载场景优化
optimizations:
# 降低响应延迟(牺牲部分质量)
fast_response: true
# 简化回复(避免长篇大论)
concise_mode: true
# 大声朗读(适合车内噪音环境)
high_volume: true
# 优先使用本地模型(避免网络不稳定)
offline_priority: true
# 车载专用语音指令
voice_commands:
- "导航到{{目的地}}" -> action: "navigation"
- "播放{{音乐}}" -> action: "music_control"
- "打电话给{{联系人}}" -> action: "call"
- "发送语音消息给{{联系人}}" -> action: "voice_message"
- "汇报路况" -> action: "traffic_report"
穿戴设备场景配置
# 穿戴设备专用配置
wearable_mode:
enabled: true
# 资源受限设备优化
resource_optimization:
# 使用最小的 Whisper 模型
stt_model: "tiny"
# 禁用流式 TTS(节省电量)
streaming: false
# 缩短最大录音时长
max_recording: 15
# 降低 TTS 音质(节省电量和带宽)
tts_quality: "low"
# 电池管理
battery:
# 低电量模式阈值
low_threshold: 20
# 低电量时自动降低功能
low_power_mode:
disable_tts: true
disable_background_tasks: true
reduce_stt_quality: true
注意
在车载场景中使用 Hermes,安全永远是第一位的。确保语音交互不会分散你的驾驶注意力。建议把所有回复都设置为"一句话总结"模式,复杂信息等你停车后再查看。不要在驾驶过程中让 Hermes 执行需要审批的操作——你没法在开车时看屏幕确认。
3.6 案例:纯语音驱动的投研助手
这个案例展示如何搭建一个完全通过语音交互的投资研究助手。你可以在开车、健身、做饭的时候,用语音获取市场分析和投资建议。
系统架构
语音输入 → STT(Whisper) → 意图识别 → 工作流路由 → 数据处理 → TTS(OpenAI) → 语音输出
完整配置
# configs/voice_investment_assistant.yaml
name: "voice_investment_assistant"
description: "纯语音驱动的投资研究助手"
# STT 配置:快速响应优先
stt:
engine: "whisper_api"
whisper_api:
api_key: "${OPENAI_API_KEY}"
model: "whisper-1"
# 启用 VAD,实现免提交互
vad:
enabled: true
engine: "silero"
# 唤醒词
wake_word:
enabled: true
phrase: "小赫"
sensitivity: 0.8
# TTS 配置:高质量语音输出
tts:
engine: "openai_tts"
openai_tts:
api_key: "${OPENAI_API_KEY}"
model: "tts-1-hd"
voice: "nova"
streaming:
enabled: true
allow_barge_in: true
# 投资研究工作流
workflows:
investment_assistant:
# 意图识别配置
intent_detection:
model: "gpt-4o-mini"
intents:
- name: "price_query"
examples:
- "比特币现在多少钱"
- "以太坊价格"
- "BTC 现价"
- name: "market_analysis"
examples:
- "分析一下今天的市场"
- "大盘怎么看"
- "市场情绪如何"
- name: "portfolio_review"
examples:
- "我的持仓怎么样"
- "看看我的投资组合"
- name: "alert_setup"
examples:
- "比特币涨到 7 万提醒我"
- "设置价格提醒"
# 各意图对应的处理流程
handlers:
price_query:
- action: "fetch_crypto_price"
symbols: "{{entities.symbols}}"
- action: "format_price_response"
- action: "tts_speak"
market_analysis:
- action: "fetch_market_data"
timeframe: "1d"
- action: "analyze_market_sentiment"
- action: "generate_voice_report"
max_length: "200字" # 语音不宜过长
- action: "tts_speak"
portfolio_review:
- action: "read_portfolio"
- action: "calculate_returns"
- action: "tts_speak"
alert_setup:
- action: "create_price_alert"
symbol: "{{entities.symbol}}"
condition: "{{entities.condition}}"
target: "{{entities.price}}"
- action: "tts_speak"
text: "好的,已经为您设置提醒。"
# 后台数据服务
data_sources:
crypto_prices:
provider: "coingecko"
api_key: "${COINGECKO_API_KEY}"
update_interval: 60 # 秒
market_sentiment:
provider: "alternative"
indicators:
- "fear_greed_index"
- "btc_dominance"
使用示例对话
用户:"小赫"
Hermes:"我在,请说。"
用户:"比特币现在多少钱?"
Hermes:"比特币当前价格 67,432 美元,24 小时上涨 2.3%,交易量 285 亿美元。"
用户:"分析一下今天的市场"
Hermes:"今日市场整体偏乐观。恐惧贪婪指数 65,处于贪婪区间。比特币主导地位 52%,以太坊 Gas 费处于低位。主流币种普遍上涨,DeFi 板块表现突出。需要我详细分析某个板块吗?"
用户:"以太坊涨到 4000 提醒我"
Hermes:"好的,已经为您设置以太坊价格提醒,目标价 4000 美元。当前价格 3,521 美元,还需上涨 13.6%。"
Tips
纯语音交互有一个设计原则:回复要短,信息要密。想象一下你在听广播——如果主播说了一大段话,你很难记住所有内容。语音助手的回复最好控制在 100-200 字以内,一个回复只讲 1-2 个要点。复杂的信息用"分层汇报":先给摘要,用户问"详细说说"再给细节。
4. 实战案例:AI 投研流水线
4.1 需求分析:每日自动追踪 AI/Web3 热点
作为一个关注 AI 和 Web3 领域的投资者或研究人员,你每天早上都需要花 1-2 小时浏览各种信息源——Hacker News、GitHub Trending、Twitter、Reddit、技术博客……然后手动整理成一份可读性强的报告。
这个过程有几个痛点:
- 信息过载:每天产生的内容太多,你不可能全部看完
- 信息噪声:很多内容是重复、低质或不相关的
- 整理耗时:看完信息后,还需要花时间提炼要点、格式化
- 容易遗漏:手动浏览总有遗漏,可能错过重要信号
- 缺乏关联:单独看每条信息看不出趋势,需要跨源关联分析
解决方案:让 Hermes 搭建一条"投研流水线",每天自动完成信息收集、清洗、分析、报告生成和推送的全过程。
预期效果: - 每天早上 8:00,你的 Telegram/飞书收到一份 curated 好的行业日报 - 报告包含:热点摘要、趋势分析、关键数据、值得关注的项目 - 每日运行成本约 $0.1-0.5(主要是 API 调用费用) - 你自己只需要花 5 分钟浏览报告,而不是 2 小时手动整理
4.2 整体架构设计(MCP + Cron + 多Agent)
这个系统采用多 Agent 协作架构,每个 Agent 负责一个环节,像流水线一样串联工作。
┌─────────────────────────────────────────────────────────────┐
│ AI 投研流水线架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Cron 触发(每天 8:00) │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 数据收集 Agent │ ◄─── 多源并行抓取 │
│ └──────┬───────┘ │
│ │ 原始数据 │
│ ▼ │
│ ┌──────────────┐ │
│ │ 数据清洗 Agent │ ──── 去重、过滤、格式化 │
│ └──────┬───────┘ │
│ │ 清洗后数据 │
│ ▼ │
│ ┌──────────────┐ │
│ │ 分析 Agent │ ──── 趋势提取、情感分析、关联挖掘 │
│ └──────┬───────┘ │
│ │ 分析结果 │
│ ▼ │
│ ┌──────────────┐ │
│ │ 报告生成 Agent│ ──── 格式化、图表、摘要 │
│ └──────┬───────┘ │
│ │ 最终报告 │
│ ▼ │
│ ┌──────────────┐ │
│ │ 推送 Agent │ ──── Telegram/飞书/邮件 │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
为什么用多 Agent 而不是单个 Agent?
- 关注点分离:每个 Agent 只做好一件事,逻辑清晰,便于调试
- 并行优化:数据收集阶段可以同时抓取多个源
- 成本优化:不同环节可以用不同模型(收集用便宜模型,分析用强模型)
- 容错隔离:一个环节出问题不影响其他环节
- 可替换性:想换一个数据源?只改收集 Agent 就行
类比
多 Agent 流水线就像一家报社的编辑部。有记者(收集 Agent)去各地采访,有编辑(清洗 Agent)整理稿件,有评论员(分析 Agent)写深度分析,有排版员(报告生成 Agent)做成报纸,有发行员(推送 Agent)送到读者手中。每个人专精一项,效率最高。
4.3 数据源配置(Hacker News、GitHub Trending、Twitter/X、Reddit)
Hacker News 数据抓取
# data_sources/hacker_news.yaml
name: "hacker_news_source"
description: "从 Hacker News 抓取热门内容"
# 使用 Hermes 内置的 Web 搜索工具 + HN API
fetch:
# Hacker News 官方 API(免费,无需 Key)
- name: "top_stories"
url: "https://hacker-news.firebaseio.com/v0/topstories.json"
method: "GET"
# 取前 30 条热帖的 ID
parse: "json"
limit: 30
# 根据 ID 获取帖子详情
- name: "story_details"
url: "https://hacker-news.firebaseio.com/v0/item/{story_id}.json"
method: "GET"
# 从 top_stories 的结果中迭代获取
iterate: "top_stories"
# 只保留满足条件的帖子
filter:
- "score > 50" # 分数大于 50
- "type == 'story'"
fields:
- "title"
- "url"
- "score"
- "by" # 作者
- "time"
- "descendants" # 评论数
# 内容抓取(如果帖子是链接到外部文章)
content_extraction:
enabled: true
# 使用 Hermes 的网页内容提取工具
tool: "web_fetch"
# 提取正文(去除广告、导航等)
article_only: true
# 最大字符数
max_length: 5000
GitHub Trending 抓取
# data_sources/github_trending.yaml
name: "github_trending"
description: "抓取 GitHub Trending 项目"
fetch:
# GitHub Trending 页面(需要解析 HTML)
- name: "trending_repos"
url: "https://github.com/trending"
method: "GET"
parse: "html"
selectors:
repo_name: "h2.h3.lh-condensed a"
description: "p.col-9.color-fg-muted.my-1"
language: "span.d-inline-block.ml-0.mr-3 span[itemprop='programmingLanguage']"
stars_today: "span.d-inline-block.float-sm-right"
# 补充 API 获取详细信息
- name: "repo_details"
url: "https://api.github.com/repos/{owner}/{repo}"
method: "GET"
headers:
Authorization: "token ${GITHUB_TOKEN}"
fields:
- "stargazers_count"
- "forks_count"
- "topics"
- "created_at"
- "updated_at"
# 过滤条件
filter:
# 只关注 AI/Agent 相关项目
keywords:
- "ai"
- "agent"
- "llm"
- "machine learning"
- "openai"
- "anthropic"
# 今日新增 star 数
min_stars_today: 50
Twitter/X 数据抓取
# data_sources/twitter_monitor.yaml
name: "twitter_monitor"
description: "监控 Twitter/X 上的 AI 相关讨论"
# 使用 Twitter API v2(需要开发者账号)
fetch:
- name: "ai_tweets"
endpoint: "https://api.twitter.com/2/tweets/search/recent"
method: "GET"
headers:
Authorization: "Bearer ${TWITTER_BEARER_TOKEN}"
params:
query: "(AI OR Agent OR LLM OR GPT) lang:en -is:retweet"
max_results: 50
"tweet.fields": "created_at,public_metrics,author_id"
expansions: "author_id"
"user.fields": "username,public_metrics"
# 关注的关键账号(KOL 列表)
key_accounts:
- "karpathy" # Andrej Karpathy
- "ylecun" # Yann LeCun
- "sama" # Sam Altman
- " BinduReddy" # Bindu Reddy
- "DrJimFan" # Jim Fan
# 监控的关键词标签
hashtags:
- "#AI"
- "#LLM"
- "#ArtificialIntelligence"
- "#Web3"
注意
Twitter/X API 在 2025 年之后收费较贵。如果预算有限,可以用以下替代方案: 1. 使用 Nitter 等第三方前端(稳定性差,不推荐用于生产) 2. 关注几个关键账号,用 RSSHub 将他们的推文转为 RSS 3. 完全跳过 Twitter,用 Reddit 和 HN 替代(后两者免费且质量很高)
Reddit 数据抓取
# data_sources/reddit_monitor.yaml
name: "reddit_monitor"
description: "监控 Reddit 上 AI/Web3 相关讨论"
# Reddit API(免费,需要注册应用获取 client_id)
fetch:
- name: "subreddit_posts"
endpoint: "https://www.reddit.com/r/{subreddit}/hot.json"
method: "GET"
headers:
User-Agent: "HermesResearchBot/1.0"
params:
limit: 25
# 监控的 Subreddit
subreddits:
- "MachineLearning"
- "LocalLLaMA"
- "OpenAI"
- "web3"
- "cryptocurrency"
- "ethdev"
# 过滤条件
filter:
min_score: 20
exclude_flair:
- "Meme"
- "Shitpost"
4.4 数据清洗与分析 Agent
数据清洗 Agent 配置
# agents/data_cleaner.yaml
name: "data_cleaner"
description: "清洗和标准化原始数据"
# 使用的模型(清洗不需要太强的模型,用便宜的)
model: "gpt-4o-mini"
# 清洗流程
pipeline:
# 步骤1:去重
- step: "deduplication"
method: "semantic" # 语义去重(不仅比较标题,还比较内容相似度)
threshold: 0.85 # 相似度超过 85% 视为重复
# 步骤2:过滤低质量内容
- step: "quality_filter"
rules:
- "content_length > 200" # 正文太短的不保留
- "title_not_clickbait" # 过滤标题党
- "language == 'en' or language == 'zh'" # 只保留中英文
# 步骤3:分类打标签
- step: "classification"
categories:
- "LLM/大模型"
- "AI Agent"
- "Web3/区块链"
- "开源项目"
- "投资/融资"
- "产品发布"
- "技术论文"
- "行业观点"
# 步骤4:提取关键信息
- step: "extraction"
fields:
- "summary" # 一句话摘要
- "key_points" # 3-5 个要点
- "entities" # 提及的公司/项目/人名
- "sentiment" # 情感倾向
# 输出格式
output:
format: "json"
schema:
id: "string"
source: "string"
title: "string"
url: "string"
category: "string"
summary: "string"
key_points: "array[string]"
entities: "array[string]"
sentiment: "enum[positive, neutral, negative]"
score: "number"
timestamp: "datetime"
分析 Agent 配置
# agents/analyst.yaml
name: "investment_analyst"
description: "分析清洗后的数据,提取投资信号"
# 分析用强模型
model: "gpt-4o"
# 分析维度
analysis_dimensions:
# 维度1:趋势分析
- name: "trend_analysis"
prompt: |
分析以下 AI/Web3 行业数据,识别当前的主要趋势:
数据:{{data}}
请回答:
1. 今天最热门的 3 个趋势是什么?
2. 这些趋势是延续性的还是新出现的?
3. 哪些趋势值得持续关注?
output:
- "top_trends"
- "trend_momentum" # 趋势强度
# 维度2:情绪分析
- name: "sentiment_analysis"
prompt: |
分析以下内容的整体市场情绪:
数据:{{data}}
请给出:
1. 整体情绪评分(1-10,10 最乐观)
2. 情绪变化(比昨天更乐观/悲观/持平)
3. 影响情绪的关键事件
output:
- "sentiment_score"
- "sentiment_change"
- "key_events"
# 维度3:项目发现
- name: "project_discovery"
prompt: |
从以下数据中识别值得关注的项目/公司/产品:
数据:{{data}}
对每个值得关注的项目,给出:
1. 项目名称和简介
2. 为什么值得关注
3. 风险提醒(如有)
output:
- "notable_projects"
# 维度4:关联分析
- name: "correlation_analysis"
prompt: |
分析以下不同来源的信息之间有什么关联:
数据:{{data}}
寻找:
1. 跨平台热议的同一话题
2. 因果关系(A 事件可能导致 B 结果)
3. 共识与分歧(不同社区对同一事件的看法差异)
output:
- "cross_platform_topics"
- "causal_links"
- "consensus_gaps"
4.5 报告生成与格式化
报告模板配置
# reports/daily_brief_template.yaml
name: "daily_brief"
description: "每日行业简报模板"
# 报告结构
template: |
# 🚀 AI & Web3 每日简报
**日期**:{{date}}
**数据源**:Hacker News, GitHub, Reddit, Twitter
**生成时间**:{{generation_time}}
---
## 📊 市场脉搏
**整体情绪**:{{sentiment.score}}/10 {{sentiment.emoji}}
**情绪变化**:{{sentiment.change}}
**热门趋势**:
{{#each trends}}
- **{{name}}** — {{description}} (热度:{{momentum}})
{{/each}}
---
## 🔥 今日热点
{{#each hot_topics}}
### {{index}}. {{title}}
- **来源**:{{source}}
- **分类**:{{category}}
- **摘要**:{{summary}}
- **关键要点**:
{{#each key_points}}
- {{this}}
{{/each}}
- **🔗 原文**:{{url}}
{{/each}}
---
## 💎 值得关注
{{#each notable_projects}}
### {{name}}
{{description}}
- **亮点**:{{highlight}}
- **⚠️ 风险**:{{risk}}
{{/each}}
---
## 🔗 跨平台关联
{{#each correlations}}
**{{topic}}**:{{description}}
- HN 讨论:{{hn_sentiment}}
- Reddit 讨论:{{reddit_sentiment}}
- GitHub 动态:{{github_activity}}
{{/each}}
---
> 💡 **今日思考**
> {{daily_thought}}
---
*本报告由 Hermes Agent 自动生成,仅供参考,不构成投资建议。*
# 样式配置
styling:
# Markdown 格式
format: "markdown"
# 是否包含 emoji
use_emoji: true
# 最长长度
max_length: 5000
# 热点数量限制
max_hot_topics: 5
# 项目推荐数量限制
max_notable_projects: 3
4.6 推送到 Telegram/飞书
Telegram 推送配置
# notifications/telegram_push.yaml
name: "telegram_daily_push"
description: "每日报告 Telegram 推送"
# Telegram Bot 配置
bot:
token: "${TELEGRAM_BOT_TOKEN}"
# 目标聊天 ID(可以是个人或群组)
chat_id: "${TELEGRAM_CHAT_ID}"
# 推送内容
message:
# 发送方式:text / markdown / photo(生成图片发送)
format: "markdown"
# 如果报告太长,是否分段发送
split_long_message: true
# 每段最大长度
chunk_size: 4000
# 发送前的预览
preview: true
# 定时触发
schedule:
cron: "0 8 * * *" # 每天上午 8:00
timezone: "Asia/Shanghai"
飞书推送配置
# notifications/feishu_push.yaml
name: "feishu_daily_push"
description: "每日报告飞书推送"
# 飞书机器人配置
bot:
webhook_url: "${FEISHU_WEBHOOK_URL}"
# 飞书自定义机器人的签名密钥(如启用安全设置)
secret: "${FEISHU_SECRET}"
# 消息格式(飞书支持富文本卡片)
message:
format: "card"
card_template: |
{
"msg_type": "interactive",
"card": {
"header": {
"title": {
"tag": "plain_text",
"content": "🚀 AI & Web3 每日简报 — {{date}}"
},
"template": "blue"
},
"elements": [
{
"tag": "div",
"text": {
"tag": "lark_md",
"content": "**市场情绪**:{{sentiment_score}}/10\n**热门趋势**:{{top_trend}}"
}
},
{
"tag": "hr"
},
{
"tag": "div",
"text": {
"tag": "lark_md",
"content": "{{content_summary}}"
}
},
{
"tag": "action",
"actions": [
{
"tag": "button",
"text": {
"tag": "plain_text",
"content": "查看完整报告"
},
"type": "primary",
"url": "{{report_url}}"
}
]
}
]
}
}
# 定时触发
schedule:
cron: "0 8 * * *"
timezone: "Asia/Shanghai"
4.7 完整配置代码
下面是整个投研流水线的完整配置,你可以保存为 research_pipeline.yaml 并加载到 Hermes 中:
# ============================================================
# AI 投研流水线 —— 完整配置
# 作者:鲲鹏Talk
# 版本:v1.0
# ============================================================
name: "ai_research_pipeline"
description: "每日自动追踪 AI/Web3 热点并生成报告"
version: "1.0"
# ============ 调度配置 ============
schedule:
# 每天上午 8:00 执行
cron: "0 8 * * *"
timezone: "Asia/Shanghai"
# 如果某次执行失败,是否重试
retry:
enabled: true
max_attempts: 3
delay_seconds: 60
# ============ 数据源配置 ============
data_sources:
hacker_news:
enabled: true
fetch_count: 30
min_score: 50
github_trending:
enabled: true
languages: ["python", "typescript", "rust", "go"]
min_stars_today: 30
reddit:
enabled: true
subreddits:
- "MachineLearning"
- "LocalLLaMA"
- "web3"
min_score: 20
twitter:
enabled: true
# 如果 API 不可用,自动跳过不影响其他源
fallback: "skip"
# ============ Agent 配置 ============
agents:
collector:
model: "gpt-4o-mini"
max_concurrent: 4 # 并行抓取
cleaner:
model: "gpt-4o-mini"
dedup_threshold: 0.85
analyst:
model: "gpt-4o"
temperature: 0.3 # 分析要稳定,不要随机
reporter:
model: "gpt-4o"
max_output_length: 5000
# ============ 报告配置 ============
report:
template: "daily_brief"
format: "markdown"
max_hot_topics: 5
max_notable_projects: 3
include_sentiment: true
include_correlations: true
# ============ 推送配置 ============
notifications:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${TELEGRAM_CHAT_ID}"
format: "markdown"
feishu:
enabled: false # 按需开启
webhook_url: "${FEISHU_WEBHOOK_URL}"
format: "card"
# ============ 记忆配置 ============
memory:
# 保存历史报告,用于趋势对比
store_reports: true
# 保留天数
retention_days: 30
# 是否记录用户反馈("这篇报告有用/没用")
track_feedback: true
# ============ 成本控制 ============
cost_control:
# 每日预算上限(美元)
daily_budget: 1.0
# 预算超限时通知
alert_on_overrun: true
# 使用模型优先级(尽量用便宜的)
model_priority: ["gpt-4o-mini", "gpt-4o"]
启动流水线的命令
# 加载流水线配置
$ hermes pipeline load ./research_pipeline.yaml
# 手动触发一次测试(不等待定时任务)
$ hermes pipeline run ai_research_pipeline --dry-run
# 查看流水线状态
$ hermes pipeline status ai_research_pipeline
# 查看执行历史
$ hermes pipeline logs ai_research_pipeline --limit 10
# 暂停/恢复流水线
$ hermes pipeline pause ai_research_pipeline
$ hermes pipeline resume ai_research_pipeline
4.8 成本分析(每日运行约 $0.1-0.5)
让我们来算算这条流水线每天花多少钱。
成本构成
| 项目 | 单价 | 每日用量 | 每日成本 |
|---|---|---|---|
| GPT-4o-mini(收集+清洗) | $0.15/1M tokens | ~200K tokens | $0.03 |
| GPT-4o(分析+报告) | $2.50/1M tokens | ~100K tokens | $0.25 |
| Twitter API(Basic) | $100/月 | — | ~$3.33/天 |
| GitHub API | 免费(5000次/小时) | ~100次 | $0 |
| Reddit API | 免费 | ~50次 | $0 |
| HN API | 免费 | ~50次 | $0 |
| 服务器(VPS) | $5-10/月 | — | ~$0.3/天 |
Twitter API 替代方案(省钱版)
如果不使用 Twitter API,可以省掉每天 $3.33 的费用:
data_sources:
twitter:
enabled: false # 关闭 Twitter
# 用 RSSHub 替代
rsshub:
enabled: true
feeds:
- "https://rsshub.app/twitter/user/karpathy"
- "https://rsshub.app/twitter/user/ylecun"
优化后的每日成本
| 版本 | 每日成本 | 月度成本 |
|---|---|---|
| 完整版(含 Twitter API) | ~$3.9 | ~$117 |
| 精简版(无 Twitter) | ~$0.6 | ~$18 |
| 极致省钱版(全部本地模型) | ~$0.05 | ~$1.5 |
Tips
如果你是个人用户,推荐"精简版"配置。信息源用 HN + GitHub + Reddit 已经足够丰富。Twitter 上的大部分重要信息会在 Reddit 和 HN 上出现。省下的钱够你多喝几杯咖啡了。
4.9 优化建议
优化1:用缓存减少重复调用
# 在 config.yaml 中启用智能缓存
cache:
enabled: true
# 网页内容缓存(相同 URL 不重复抓取)
web_content:
ttl: 3600 # 1小时
# API 响应缓存
api_response:
ttl: 1800 # 30分钟
# 报告片段缓存
report_fragments:
ttl: 86400 # 24小时
优化2:增量更新代替全量抓取
# 只抓取自上次运行以来的新内容
data_sources:
hacker_news:
incremental: true
# 记录上次抓取的最大 item ID
state_file: "./state/hn_last_id.txt"
github_trending:
incremental: false # GitHub Trending 每天变化,需要全量
# 但可以用缓存避免重复请求
cache_ttl: 3600
优化3:动态模型选择
# 根据任务复杂度自动选择模型
model_routing:
# 简单任务用便宜模型
simple_tasks:
model: "gpt-4o-mini"
conditions:
- "token_count < 1000"
- "task_type in ['summarize', 'classify']"
# 复杂任务用强模型
complex_tasks:
model: "gpt-4o"
conditions:
- "task_type in ['analyze', 'reason', 'generate_report']"
# 超长文本用 Claude(上下文窗口更大)
long_context:
model: "claude-sonnet"
conditions:
- "input_tokens > 10000"
优化4:智能去重减少处理量
cleaning:
# 在抓取阶段就去重
early_dedup:
enabled: true
# 如果两个 URL 的域名+路径相似度 > 90%,视为同一篇文章
url_similarity_threshold: 0.9
# 语义去重
semantic_dedup:
enabled: true
# 使用 embedding 比较内容相似度
embedding_model: "text-embedding-3-small"
threshold: 0.85
5. 实战案例:内容自动化工厂
5.1 需求分析:自动生成社交媒体内容
自媒体运营有一个永恒的痛点:内容生产速度追不上发布频率的要求。
假设你运营着 3 个平台:微信公众号、小红书和抖音。每个平台的风格不同: - 公众号:深度长文,1500-3000 字,注重逻辑和论据 - 小红书:短平快,300-800 字,多用 emoji,注重视觉感 - 抖音:文案要口语化,适合配音,强调"钩子"和情绪
如果你每天要为每个平台生产内容,光是写作就要花 3-4 小时,还没算选题和排版的时间。
解决方案:搭建一个"内容自动化工厂",让 Hermes 的多个 Agent 协作完成从选题到发布的全流程。
预期效果: - 每天早上自动生成 5 篇 AI 快讯(不同平台版本) - 选题基于实时热点,确保内容的时效性 - 每篇内容都经过审校 Agent 检查,避免事实错误 - 发布时间优化(根据各平台流量高峰) - 你只需要花 10 分钟做最终确认和微调
5.2 选题 Agent(热点追踪)
选题是内容生产的第一步,也是最重要的一步。选题 Agent 的任务是:从海量信息中筛选出适合你账号定位的热点话题。
# agents/topic_selector.yaml
name: "topic_selector"
description: "从热点信息中筛选适合的内容选题"
# 账号定位(用于筛选匹配的话题)
account_profile:
name: "鲲鹏Talk"
niche: "AI 技术解读与行业观察"
target_audience: "AI 从业者、开发者、投资人"
content_style: "深度分析 + 通俗解释"
# 偏好话题权重
topic_weights:
"大模型技术": 1.5
"AI Agent": 1.5
"开源项目": 1.3
"创业融资": 1.2
"产品发布": 1.0
"行业八卦": 0.3 # 低权重,不太关注八卦
# 热点数据源
sources:
- "hacker_news"
- "github_trending"
- "weibo_hot" # 微博热搜
- "zhihu_hot" # 知乎热榜
- "twitter_trending"
# 选题策略
selection_strategy:
# 策略1:时效性优先(新发生的事)
- name: "timeliness"
weight: 0.3
criteria: "published_within_24h"
# 策略2:热度优先(讨论的人多)
- name: "popularity"
weight: 0.25
criteria: "engagement_score > threshold"
# 策略3:匹配度优先(符合账号定位)
- name: "relevance"
weight: 0.3
criteria: "semantic_similarity_to_profile > 0.7"
# 策略4:差异化优先(别人没讲过的角度)
- name: "differentiation"
weight: 0.15
criteria: "novelty_score > 0.6"
# 每日选题数量
daily_topics: 5
# 输出格式
output:
- "title" # 选题标题
- "angle" # 切入角度
- "source_url" # 参考链接
- "priority" # 优先级(1-5)
- "estimated_reads" # 预估阅读量
选题 Agent 的工作流程
workflow:
name: "daily_topic_selection"
steps:
# 步骤1:抓取热点
- action: "fetch_trending"
sources: "{{sources}}"
# 步骤2:初步过滤(排除明显不相关的)
- action: "filter"
rules:
- "language in ['zh', 'en']"
- "not contains: [色情, 赌博, 政治]"
# 步骤3:计算匹配度
- action: "score_topics"
strategy: "{{selection_strategy}}"
# 步骤4:去重(避免连续多天讲同一话题)
- action: "dedup_with_history"
history_days: 7
threshold: 0.8
# 步骤5:生成选题列表
- action: "generate_topic_list"
count: "{{daily_topics}}"
类比
选题 Agent 就像一个敏锐的编辑部主任。每天早上,他浏览上百份报纸和网站,从中挑出最值得报道的 5 个话题。他不是随便挑——他要考虑:这个话题我们的读者关心吗?我们能讲出跟别人不一样的角度吗?这个话题现在讲是不是最好的时机?
5.3 写作 Agent(内容生成)
写作 Agent 是内容工厂的核心。它根据选题和平台要求,生成适配不同渠道的文案。
# agents/writer.yaml
name: "content_writer"
description: "根据选题生成各平台适配的文案"
# 平台适配配置
platform_presets:
wechat:
name: "微信公众号"
style: "深度长文"
length: "1500-3000字"
tone: "专业、理性、有洞察"
structure: "
- 钩子开头(引发好奇)
- 背景介绍(让读者跟上)
- 核心分析(你的观点)
- 案例/数据支撑
- 总结升华
- 互动引导(留言/转发)
"
formatting:
use_headings: true
use_blockquotes: true
use_lists: true
xiaohongshu:
name: "小红书"
style: "短平快笔记"
length: "300-800字"
tone: "亲切、活泼、有共鸣"
structure: "
- 封面标题(抓眼球)
- 个人经历/感受引入
- 干货内容(分点列出)
- 情绪价值(共鸣、激励)
- 互动引导(评论区话题)
"
formatting:
use_emoji: true
use_hashtags: true
paragraph_length: "短句为主"
douyin:
name: "抖音"
style: "短视频文案"
length: "100-300字"
tone: "口语化、有情绪、带节奏"
structure: "
- 黄金3秒钩子
- 信息密度高的正文
- 金句/反转/悬念结尾
- 引导点赞关注
"
formatting:
line_breaks: "每句一行"
spoken_language: true # 适合朗读
# 写作提示词模板
prompt_template: |
你是一位专业的 {{platform.name}} 内容创作者,擅长 {{platform.style}}。
请根据以下选题,撰写一篇 {{platform.name}} 的文案。
**选题**:{{topic.title}}
**切入角度**:{{topic.angle}}
**参考信息**:{{topic.source_content}}
**要求**:
1. 字数控制在 {{platform.length}}
2. 语气风格:{{platform.tone}}
3. 结构遵循:{{platform.structure}}
4. 格式要求:{{platform.formatting}}
5. 不要编造数据,如果参考信息中没有具体数据,可以模糊表述或使用"据报道"等措辞
6. 确保内容有信息增量,不要泛泛而谈
# 使用的模型
model: "gpt-4o"
temperature: 0.7 # 创意写作需要一定的随机性
批量生成工作流
workflow:
name: "batch_content_generation"
steps:
# 步骤1:获取今日选题
- action: "get_topics"
source: "topic_selector"
count: 5
# 步骤2:为每个选题、每个平台生成内容
- action: "parallel_generate"
parallelism:
topics: 5
platforms: 3
# 总共生成 15 篇内容(5选题 × 3平台)
# 步骤3:格式化输出
- action: "format_output"
structure:
- "topic_id"
- "platform"
- "title"
- "content"
- "word_count"
- "estimated_read_time"
Tips
不同平台的文案风格差异很大,不要试图用同一篇内容"通发"所有平台。小红书的用户喜欢看"干货笔记",公众号的读者愿意读"深度分析",抖音的观众需要"快节奏信息"。写作 Agent 的价值就在于,它能理解这些差异并生成适配的内容。
5.4 审校 Agent(质量把控)
内容生成后,不能直接发布,必须经过审校。审校 Agent 负责检查事实准确性、语言表达、合规性等问题。
# agents/editor.yaml
name: "content_editor"
description: "审校生成的内容,确保质量"
# 审校维度
check_dimensions:
# 维度1:事实核查
- name: "fact_check"
model: "gpt-4o"
prompt: |
请检查以下内容中的事实性陈述,标记可能存在的问题:
内容:{{content}}
检查要点:
1. 数据是否准确(是否有明显错误的数据)
2. 人名/公司名是否拼写正确
3. 时间/日期是否合理
4. 引用是否标注来源
5. 是否存在明显的主观臆断被包装成事实
输出格式:
- 问题位置(段落/句子)
- 问题描述
- 建议修改
severity: "high" # 事实错误必须修正
# 维度2:语言表达
- name: "language_quality"
model: "gpt-4o-mini"
prompt: |
请检查以下内容的语言表达:
内容:{{content}}
平台:{{platform}}
检查要点:
1. 是否有语病或不通顺的句子
2. 是否符合 {{platform}} 的语言风格
3. 是否有重复啰嗦的表述
4. 标点符号使用是否规范
5. 段落划分是否合理
severity: "medium"
# 维度3:合规性检查
- name: "compliance"
model: "gpt-4o-mini"
prompt: |
请检查以下内容是否存在合规风险:
内容:{{content}}
检查要点:
1. 是否涉及敏感话题(政治、色情、暴力等)
2. 是否存在未经授权的引用/抄袭
3. 是否涉及不实医疗/投资建议
4. 是否侵犯他人隐私或名誉
5. 广告法相关:是否使用了违禁词("最"、"第一"、"国家级"等)
severity: "critical" # 合规问题一票否决
# 维度4:平台适配检查
- name: "platform_fit"
model: "gpt-4o-mini"
prompt: |
请检查以下内容是否符合 {{platform}} 的平台规范:
内容:{{content}}
检查要点:
1. 字数是否在合理范围内
2. 格式是否符合平台习惯
3. 是否有平台禁止的内容类型
4. 标题是否符合平台算法偏好
severity: "medium"
# 审校结果处理
result_handling:
# 如果没有问题,直接通过
auto_pass: "no_issues_found"
# 如果有中低风险问题,自动修正
auto_fix: "severity <= medium"
# 如果有高风险问题,标记为需人工审核
manual_review: "severity >= high"
# 如果有严重合规问题,直接拒绝
reject: "severity == critical"
5.5 多平台分发(公众号、小红书、抖音文案)
内容审校通过后,需要发布到各个平台。不同平台的发布方式不同:
微信公众号发布
# publishers/wechat_publish.yaml
name: "wechat_publisher"
description: "发布到微信公众号"
# 使用微信公众号 API(需要已认证的服务号)
api:
app_id: "${WECHAT_APP_ID}"
app_secret: "${WECHAT_APP_SECRET}"
# 发布配置
publish:
# 素材上传
upload_images: true
# 封面图生成
generate_cover: true
cover_template: "default"
# 文章设置
article_settings:
need_open_comment: true
only_fans_can_comment: false
# 发布方式:draft(保存草稿)/ publish(直接发布)/ schedule(定时)
mode: "draft" # 建议先保存草稿,人工确认后再发布
小红书发布
# publishers/xiaohongshu_publish.yaml
name: "xiaohongshu_publisher"
description: "发布到小红书"
# 小红书目前没有官方 API,需要使用第三方工具或模拟操作
# 方案1:使用小红书创作者服务平台 API(需申请)
# 方案2:使用 Puppeteer 模拟浏览器操作(稳定性差)
# 方案3:导出内容,人工复制粘贴(推荐)
# 本配置采用方案3:生成发布就绪的内容
output:
format: "copy_paste_ready"
includes:
- "title"
- "content_with_emojis"
- "hashtags"
- "suggested_cover_text" # 封面图文字建议
- "suggested_images" # 配图建议
抖音文案生成
# publishers/douyin_publish.yaml
name: "douyin_publisher"
description: "生成抖音发布文案"
# 抖音也没有直接的内容发布 API(视频发布除外)
# 这里生成适合抖音格式的文案
output:
format: "douyin_script"
includes:
- "hook" # 前3秒钩子
- "script" # 完整口播文案
- "captions" # 字幕文本
- "hashtags" # 推荐标签
- "music_suggestion" # BGM建议
- "duration_estimate" # 预估时长
5.6 定时调度配置
# schedule/content_factory.yaml
name: "content_factory_schedule"
description: "内容自动化工厂的定时调度"
# 整体调度计划
schedule:
# 阶段1:每天早上 6:00 选题
topic_selection:
cron: "0 6 * * *"
timezone: "Asia/Shanghai"
# 阶段2:6:30 开始批量写作
content_generation:
cron: "30 6 * * *"
depends_on: "topic_selection"
# 阶段3:7:00 审校
content_editing:
cron: "0 7 * * *"
depends_on: "content_generation"
# 阶段4:7:30 推送待发布队列
publish_queue:
cron: "30 7 * * *"
depends_on: "content_editing"
# 分平台发布时间优化
publish_times:
# 公众号最佳发布时间
wechat:
- "12:00" # 午休时间
- "18:30" # 下班路上
- "21:00" # 睡前阅读
# 小红书最佳发布时间
xiaohongshu:
- "07:30" # 早起刷手机
- "12:30" # 午休
- "20:00" # 晚饭后
# 抖音最佳发布时间
douyin:
- "07:00" # 起床刷
- "12:00" # 午饭刷
- "18:00" # 下班刷
- "21:00" # 睡前刷
5.7 案例:日更 5 篇 AI 快讯的配置方案
下面是一个完整的、可直接使用的日更 5 篇 AI 快讯配置:
# ============================================================
# 内容自动化工厂 —— 日更 5 篇 AI 快讯
# ============================================================
name: "daily_ai_news_factory"
description: "每日自动生成并发布 5 篇 AI 快讯"
# 账号设置
account:
name: "鲲鹏Talk"
niche: "AI 每日快讯"
platforms: ["wechat", "xiaohongshu"]
# 数据流
data_pipeline:
# 数据源
sources:
- "hacker_news"
- "github_trending"
- "reddit/MachineLearning"
- "reddit/LocalLLaMA"
# 筛选条件:只选 AI 相关
filter:
keywords:
- "AI"
- "LLM"
- "GPT"
- "Claude"
- "OpenAI"
- "Agent"
- "模型"
- "训练"
- "推理"
exclude:
- "NSFW"
- "political"
min_engagement: 20
# Agent 配置
agents:
# 选题 Agent
selector:
model: "gpt-4o-mini"
daily_count: 5
strategy: "timeliness_first"
# 写作 Agent
writer:
model: "gpt-4o"
temperature: 0.7
platforms:
wechat:
length: "800-1200字"
style: "专业深度"
xiaohongshu:
length: "300-500字"
style: "轻松干货"
# 审校 Agent
editor:
model: "gpt-4o-mini"
auto_fix: true
# 输出
output:
# 保存到本地
save_local: true
output_dir: "./content_output/{{date}}"
# 推送到 Telegram 预览
telegram_preview:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${TELEGRAM_CHAT_ID}"
# 发布到公众号(保存为草稿)
wechat:
enabled: true
mode: "draft"
app_id: "${WECHAT_APP_ID}"
app_secret: "${WECHAT_APP_SECRET}"
# 定时执行
schedule:
cron: "0 6 * * *"
timezone: "Asia/Shanghai"
# 成本控制
cost_control:
daily_budget: 0.5
model_priority: ["gpt-4o-mini", "gpt-4o"]
运行命令
# 加载内容工厂
$ hermes factory load ./daily_ai_news_factory.yaml
# 手动执行一次
$ hermes factory run daily_ai_news_factory
# 查看今日生成的内容
$ ls ./content_output/$(date +%Y-%m-%d)
# 查看生成日志
$ hermes factory logs daily_ai_news_factory
常见问题
Q:自动生成的内容会不会被平台判定为 AI 内容而降权?
A: 这是所有 AI 内容创作者都关心的问题。目前的建议是: 1. AI 生成后务必人工润色,加入你的个人经历、观点和表达习惯 2. 不要完全依赖 AI,把它当作"初稿生成器"而不是"完稿发布器" 3. 在内容中加入独特的信息增量,比如你自己的测试结果、采访、数据整理 4. 定期分析内容的阅读数据,根据反馈调整生成策略 平台算法在不断进化,核心原则是:给读者提供真正有价值的内容,无论是否用了 AI 辅助。
6. 实战案例:代码质量守护者
6.1 需求分析:自动化代码审查与安全扫描
代码审查是软件开发中至关重要但也非常耗时的环节。一个典型的代码审查可能需要: - 30 分钟理解代码变更的背景和目的 - 20 分钟检查代码风格和命名规范 - 20 分钟分析潜在的安全漏洞 - 15 分钟检查测试覆盖度 - 15 分钟给出改进建议
总计:每次 PR 审查约 100 分钟。如果团队每天产生 5-10 个 PR,光是代码审查就要占用一个人一整天的时间。
解决方案:让 Hermes 担任"代码质量守护者",自动完成大部分机械性的审查工作,把人类审查者的精力解放出来,专注于架构设计和业务逻辑。
预期效果: - 每个 PR 在提交后 1 分钟内得到初步审查反馈 - 自动拦截明显的安全漏洞和代码风格问题 - 生成结构化的审查报告,便于人类审查者快速浏览 - 与 CI/CD 管道集成,不达标的代码无法合并
6.2 Git Hook 集成
Git Hook 是在 Git 操作的特定时机自动执行的脚本。我们可以通过 Hook 在代码提交或推送时触发 Hermes 的审查。
pre-commit Hook(提交前检查)
#!/bin/bash
# .git/hooks/pre-commit
# 在每次 git commit 前执行
echo "🔍 Hermes 正在检查你的代码..."
# 获取暂存区的文件列表
STAGED_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '\.(py|js|ts|java|go)$')
if [ -z "$STAGED_FILES" ]; then
echo "✅ 没有需要检查的代码文件"
exit 0
fi
# 调用 Hermes 进行提交前检查
hermes review \
--mode pre-commit \
--files "$STAGED_FILES" \
--config ./hermes-code-review.yaml \
--output /tmp/hermes-pre-commit.json
# 读取检查结果
RESULT=$(cat /tmp/hermes-pre-commit.json | jq '.passed')
if [ "$RESULT" = "false" ]; then
echo "❌ 代码检查未通过,请修复以下问题:"
cat /tmp/hermes-pre-commit.json | jq '.issues[] | " - \(.severity): \(.message) (\(.file):\(.line))"'
echo ""
echo "如果你确定要提交,使用 git commit --no-verify 跳过检查(不推荐)"
exit 1
fi
echo "✅ 代码检查通过"
exit 0
pre-push Hook(推送前检查)
#!/bin/bash
# .git/hooks/pre-push
# 在每次 git push 前执行
echo "🔍 Hermes 正在检查本次推送..."
# 获取即将推送的提交
COMMITS=$(git log --oneline @{u}..HEAD 2>/dev/null || echo "")
if [ -z "$COMMITS" ]; then
echo "✅ 没有新的提交需要检查"
exit 0
fi
# 调用 Hermes 进行推送前检查
hermes review \
--mode pre-push \
--commits "@{u}..HEAD" \
--config ./hermes-code-review.yaml \
--output /tmp/hermes-pre-push.json
RESULT=$(cat /tmp/hermes-pre-push.json | jq '.passed')
if [ "$RESULT" = "false" ]; then
echo "❌ 推送检查未通过"
exit 1
fi
echo "✅ 推送检查通过"
exit 0
配置代码审查规则
# hermes-code-review.yaml
name: "code_quality_guardian"
description: "代码质量守护者配置"
# 审查触发时机
triggers:
- "pre-commit" # 提交前
- "pre-push" # 推送前
- "pr-created" # PR 创建时
- "pr-updated" # PR 更新时
# 按语言配置审查规则
rules_by_language:
python:
# 风格检查
style:
tool: "ruff" # 或 flake8, pylint
enabled: true
# 自动修复可修复的问题
auto_fix: true
# 忽略的规则
ignore: ["E501"] # 行长度(我们用 black 处理)
# 类型检查
typing:
tool: "mypy"
enabled: true
strict: true
# 安全扫描
security:
tool: "bandit"
enabled: true
severity_threshold: "medium"
# 测试覆盖度
coverage:
enabled: true
min_coverage: 70 # 最低 70%
javascript:
style:
tool: "eslint"
enabled: true
auto_fix: true
security:
tool: "eslint-plugin-security"
enabled: true
typescript:
style:
tool: "eslint"
enabled: true
auto_fix: true
typing:
tool: "tsc"
enabled: true
# 通用规则(所有语言)
general_rules:
# 检查敏感信息泄露
secret_detection:
enabled: true
patterns:
- "api_key\s*=\s*['\"][^'\"]{10,}['\"]"
- "password\s*=\s*['\"][^'\"]+['\"]"
- "AKIA[0-9A-Z]{16}" # AWS Access Key
- "ghp_[a-zA-Z0-9]{36}" # GitHub Personal Token
# 检查大文件
large_files:
enabled: true
max_size_mb: 10
# 检查二进制文件
binary_files:
enabled: true
allowed_extensions: [".png", ".jpg", ".pdf", ".woff2"]
6.3 PR 自动审查工作流
当开发者在 GitHub/GitLab 上创建或更新 PR 时,Hermes 自动进行审查并发布评论。
# workflows/pr_review.yaml
name: "pr_auto_review"
description: "PR 自动审查工作流"
# 触发条件
triggers:
- event: "pull_request"
actions: ["opened", "synchronize"]
# PR 审查流程
pipeline:
# 步骤1:获取 PR 信息
- action: "fetch_pr_info"
fields:
- "title"
- "description"
- "changed_files"
- "diff"
# 步骤2:代码变更分析
- action: "analyze_changes"
# 分析变更的复杂度
complexity_analysis: true
# 识别变更的影响范围
impact_analysis: true
# 步骤3:执行静态分析工具
- action: "run_linters"
parallel: true
tools:
- "ruff"
- "mypy"
- "bandit"
# 步骤4:AI 辅助审查
- action: "ai_review"
model: "gpt-4o"
# 审查重点
focus_areas:
- "逻辑正确性"
- "边界情况处理"
- "错误处理完整性"
- "性能影响"
- "可维护性"
# 输出格式
output_format: "structured"
# 步骤5:生成审查报告
- action: "generate_report"
template: "pr_review"
# 步骤6:发布评论
- action: "post_review_comment"
# 在 GitHub PR 下方发布评论
platform: "github"
# 如果检查通过,发布"LGTM"评论
post_lgtm_on_pass: true
AI 审查提示词
ai_review_prompt: |
你是一位资深代码审查专家,请对以下代码变更进行审查。
**PR 标题**:{{pr.title}}
**PR 描述**:{{pr.description}}
**变更文件**:{{pr.changed_files}}
**代码 Diff**:
```diff
{{pr.diff}}
```
请从以下维度进行审查:
1. **逻辑正确性**:代码逻辑是否正确?是否有明显的 bug?
2. **边界情况**:是否考虑了各种边界情况(空值、越界、并发等)?
3. **错误处理**:错误处理是否完善?是否有可能吞掉异常?
4. **性能**:是否有明显的性能问题(如 N+1 查询、内存泄漏等)?
5. **可读性**:代码是否易于理解?命名是否清晰?
6. **安全性**:是否有安全漏洞(注入、XSS、CSRF 等)?
7. **测试**:变更是否配套了测试?测试是否覆盖了关键路径?
对于每个发现的问题,请给出:
- 严重程度(critical/high/medium/low)
- 问题描述
- 具体位置(文件名和行号)
- 修改建议(包含代码示例)
如果代码没有问题,请明确说明"LGTM"(Looks Good To Me)。
6.4 安全漏洞扫描
# security/scan_config.yaml
name: "security_scanner"
description: "安全漏洞扫描配置"
# 扫描工具配置
scanners:
# 依赖漏洞扫描
dependency_check:
enabled: true
tools:
python: "safety" # 检查 Python 依赖漏洞
js: "npm audit" # 检查 npm 依赖漏洞
go: "govulncheck" # 检查 Go 依赖漏洞
# 漏洞严重性阈值
severity_threshold: "medium"
# 是否自动创建修复 PR
auto_fix: false
# 静态应用安全测试(SAST)
sast:
enabled: true
tools:
python: "bandit"
js: "eslint-plugin-security"
generic: "semgrep"
# 规则集
rules:
- "owasp-top-10"
- "cwe-top-25"
# 密钥扫描
secret_scan:
enabled: true
tool: "gitleaks"
# 扫描历史提交
scan_history: true
history_depth: 100
# 基础设施扫描(如果有 Dockerfile/K8s 配置)
infrastructure:
enabled: true
tool: "checkov"
files:
- "Dockerfile"
- "docker-compose.yml"
- "*.tf" # Terraform
- "k8s/**/*.yaml"
# 扫描结果处理
reporting:
# 生成 SARIF 格式报告(GitHub/GitLab 兼容)
format: "sarif"
output: "./security-report.sarif"
# 在 PR 中标注漏洞位置
annotate_pr: true
# 严重漏洞阻止合并
block_on_critical: true
6.5 代码质量报告生成
# reporting/quality_report.yaml
name: "quality_report"
description: "代码质量报告生成"
# 报告内容
sections:
- name: "summary"
title: "📊 质量概览"
content: |
- 检查文件数:{{stats.files_checked}}
- 发现问题数:{{stats.issues_found}}
- 严重问题:{{stats.critical}}
- 高风险问题:{{stats.high}}
- 中风险问题:{{stats.medium}}
- 低风险问题:{{stats.low}}
- 代码覆盖度:{{stats.coverage}}%
- 质量评分:{{stats.score}}/100
- name: "issues"
title: "🔍 发现的问题"
# 按严重程度分组
group_by: "severity"
# 每个问题包含
fields:
- "severity"
- "message"
- "file"
- "line"
- "suggestion"
- name: "trends"
title: "📈 质量趋势"
# 与历史数据对比
compare_with: "last_7_days"
metrics:
- "issue_count_trend"
- "coverage_trend"
- "score_trend"
- name: "recommendations"
title: "💡 改进建议"
# AI 生成的改进建议
ai_generated: true
model: "gpt-4o-mini"
# 报告分发
distribution:
# 发布到 PR 评论
pr_comment: true
# 发送到 Slack 频道
slack:
enabled: true
webhook: "${SLACK_WEBHOOK_URL}"
channel: "#code-quality"
# 保存到文件
file:
enabled: true
path: "./reports/quality-{{date}}.md"
6.6 CI/CD 集成方案
GitHub Actions 集成
# .github/workflows/hermes-review.yml
name: "Hermes Code Review"
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- name: "Checkout code"
uses: actions/checkout@v4
with:
fetch-depth: 0 # 需要完整历史进行增量分析
- name: "Setup Python"
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: "Install Hermes"
run: |
pip install hermes-cli
- name: "Run Hermes Review"
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
hermes review \
--mode pr-review \
--pr-number ${{ github.event.pull_request.number }} \
--config ./hermes-code-review.yaml \
--output ./review-result.json
- name: "Post Review Comment"
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const result = JSON.parse(fs.readFileSync('./review-result.json', 'utf8'));
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: result.review_comment
});
- name: "Check Review Result"
run: |
PASSED=$(cat ./review-result.json | jq '.passed')
if [ "$PASSED" = "false" ]; then
echo "❌ 代码审查未通过"
exit 1
fi
echo "✅ 代码审查通过"
GitLab CI 集成
# .gitlab-ci.yml
stages:
- review
hermes_review:
stage: review
image: python:3.11
before_script:
- pip install hermes-cli
script:
- hermes review
--mode pr-review
--merge-request-id $CI_MERGE_REQUEST_IID
--config ./hermes-code-review.yaml
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
6.7 案例:开源项目的自动化质量门禁
假设你是一个开源项目的维护者,每天有多个贡献者提交 PR。你希望在保证代码质量的同时,不给贡献者带来太高的门槛。
# ============================================================
# 开源项目自动化质量门禁
# ============================================================
name: "oss_quality_gate"
description: "开源项目质量门禁配置(对贡献者友好)"
# 贡献者友好配置
contributor_friendly:
# 第一次贡献者的 PR 使用更宽松的规则
first_time_contributor:
rules:
# 不强制要求测试(鼓励他们先参与)
coverage:
required: false
# 风格问题自动修复而不是报错
style:
auto_fix: true
block_on_style: false
# 欢迎消息
welcome_message: |
🎉 感谢你为这个项目贡献代码!
Hermes 已经自动审查了你的代码。一些小问题我已经帮你修正了,
请查看最新的 commit。如果有任何疑问,欢迎随时提问。
# 资深贡献者使用标准规则
regular_contributor:
rules:
coverage:
required: true
min_coverage: 70
style:
auto_fix: true
block_on_style: true
# 审查规则(分层)
rules:
# 第一层:快速检查(30秒内完成)
fast_checks:
timeout: 30
checks:
- "secret_detection"
- "large_files"
- "basic_style"
# 第二层:标准检查(2分钟内完成)
standard_checks:
timeout: 120
checks:
- "full_lint"
- "type_check"
- "security_scan"
# 第三层:深度检查(5分钟内完成,异步)
deep_checks:
timeout: 300
async: true # 不阻塞 PR,结果作为补充信息
checks:
- "ai_review"
- "complexity_analysis"
- "coverage_detailed"
# 质量门禁
quality_gate:
# 必须通过才能合并
required:
- "fast_checks.passed"
- "standard_checks.passed"
# 不通过会警告但不阻塞
recommended:
- "deep_checks.score > 70"
# 合并按钮状态
merge_button:
# 门禁通过:绿色
pass: "enable"
# 门禁失败:红色
fail: "disable"
# 进行中:黄色
pending: "show_progress"
7. 实战案例:个人知识管理系统
7.1 需求分析:打造第二大脑
现代人的信息摄入量是巨大的。每天你要浏览几十篇文章、看几十个视频、读几十条社交媒体动态、收到几十封邮件。但问题是:你真正记住并能够调用的信息,可能不到 1%。
传统的笔记方法(随手记、收藏夹、文件夹)有几个问题: 1. 存而不读:收藏了 1000 篇文章,但再也没看过 2. 找而不得:需要某个信息时,想不起来存在哪里 3. 信息孤岛:笔记之间没有关联,无法形成知识网络 4. 缺乏回顾:没有定期回顾机制,知识随着时间遗忘
解决方案:用 Hermes 搭建一个"第二大脑"——自动收集、智能分类、构建知识图谱、定期回顾,让你的知识资产真正产生复利。
预期效果: - 自动收集你浏览过的文章、邮件、书签 - 智能分类和标签化,无需手动整理 - 知识图谱可视化,发现信息之间的隐藏关联 - 定期生成回顾报告,强化记忆 - 需要时可以通过自然语言查询快速找到相关信息
7.2 信息收集自动化(RSS、邮件、书签)
RSS 订阅收集
# knowledge/rss_collector.yaml
name: "rss_collector"
description: "RSS 订阅自动收集"
# 订阅源
feeds:
# AI 技术博客
- url: "https://blog.openai.com/rss.xml"
category: "AI 公司动态"
priority: "high"
- url: "https://simonwillison.net/atom.xml"
category: "技术实践"
priority: "high"
- url: "https://lilianweng.github.io/index.xml"
category: "技术深度"
priority: "high"
# 中文源
- url: "https://www.qbitai.com/feed"
category: "中文 AI 资讯"
priority: "medium"
# 个人博客
- url: "https://example.com/feed.xml"
category: "关注博主"
priority: "medium"
# 收集配置
collection:
# 检查频率
check_interval: "1h"
# 只收集最近 7 天的内容
max_age: "7d"
# 文章内容提取
extract_content:
enabled: true
# 使用 Mercury 或 Readability 提取正文
tool: "readability"
# 保存完整内容
save_full_text: true
# 去重
dedup:
enabled: true
# 基于 URL 去重
by_url: true
# 基于标题相似度去重
by_title_similarity: 0.9
# 存储
storage:
# 保存到本地文件
local:
enabled: true
path: "./knowledge/inbox/{{date}}/"
# 同时保存到数据库(用于检索)
database:
enabled: true
type: "sqlite"
path: "./knowledge/knowledge.db"
邮件收集
# knowledge/email_collector.yaml
name: "email_collector"
description: "自动收集和归档重要邮件"
# 邮件账户配置
accounts:
- type: "imap"
server: "imap.gmail.com"
port: 993
username: "${EMAIL_USERNAME}"
password: "${EMAIL_APP_PASSWORD}" # 使用应用专用密码
# 只收集特定标签的邮件
labels: ["Newsletters", "AI", "Important"]
# 过滤规则
filters:
# 只收集 Newsletter 类邮件
- condition: "from contains 'newsletter' OR subject contains 'Newsletter'"
action: "collect"
# 收集特定发件人的邮件
- condition: "from in ['newsletter@openai.com', 'digest@github.com']"
action: "collect"
# 忽略营销邮件
- condition: "subject contains '促销' OR subject contains '优惠'"
action: "ignore"
# 内容提取
extraction:
# 提取邮件正文(去除签名、法律声明等)
extract_body: true
# 提取附件(PDF、DOC 等)
extract_attachments: true
# 附件保存路径
attachment_path: "./knowledge/attachments/"
浏览器书签收集
# knowledge/bookmark_collector.yaml
name: "bookmark_collector"
description: "收集浏览器书签"
# 导入浏览器书签
import:
# 支持的浏览器
browsers:
- "chrome"
- "firefox"
- "safari"
# 书签文件路径
paths:
chrome: "~/Library/Application Support/Google/Chrome/Default/Bookmarks"
firefox: "~/Library/Application Support/Firefox/Profiles/*/bookmarks.html"
# 只导入特定文件夹的书签
filter_folders:
- "AI"
- "Read Later"
- "Research"
# 忽略的文件
ignore_patterns:
- "javascript:"
- "chrome://"
# 对书签进行内容抓取
fetch_content:
enabled: true
# 抓取延迟(避免被封)
delay: 2
# 最大抓取数量(每次运行)
max_per_run: 20
# 超时时间
timeout: 30
7.3 智能分类与标签
收集到的信息需要自动分类和打标签,这样才能高效检索。
# knowledge/auto_classifier.yaml
name: "auto_classifier"
description: "知识内容自动分类和标签"
# 分类体系
categories:
# 一级分类
- name: "AI 技术"
subcategories:
- "大模型"
- "Agent"
- "RAG"
- "微调"
- "多模态"
- name: "编程开发"
subcategories:
- "Python"
- "前端"
- "系统架构"
- "DevOps"
- name: "行业观察"
subcategories:
- "创业"
- "投资"
- "产品"
- "商业化"
- name: "个人成长"
subcategories:
- "效率工具"
- "学习方法"
- "思维方式"
# 自动标签
tagging:
# 基于内容生成标签
auto_generate:
enabled: true
model: "gpt-4o-mini"
max_tags: 10
# 标签风格
style: "concise" # 简短标签,如 "transformer", "agent"
# 基于规则打标签
rule_based:
- pattern: "transformer|attention|BERT|GPT"
tags: ["transformer", "nlp"]
- pattern: "docker|kubernetes|ci/cd"
tags: ["devops", "container"]
- pattern: "startup|vc|funding"
tags: ["startup", "investment"]
# 实体标签(人名、公司、产品)
entity_extraction:
enabled: true
# 提取的实体类型
types:
- "PERSON" # 人名
- "ORG" # 组织/公司
- "PRODUCT" # 产品
- "TECH" # 技术术语
# 分类模型配置
classification:
model: "gpt-4o-mini"
# 分类方法:single(单分类)/ multi(多标签)
method: "multi"
# 置信度阈值
confidence_threshold: 0.7
7.4 知识图谱构建
知识图谱能把孤立的信息点连接起来,发现你原本不知道的关联。
# knowledge/knowledge_graph.yaml
name: "knowledge_graph"
description: "个人知识图谱构建"
# 图谱构建
graph:
# 节点类型
node_types:
- "document" # 文档/文章
- "concept" # 概念
- "person" # 人
- "organization" # 组织
- "technology" # 技术
- "tag" # 标签
# 关系类型
edge_types:
- "mentions" # 提及
- "related_to" # 相关
- "part_of" # 属于
- "contradicts" # 矛盾/反驳
- "supports" # 支持
- "prerequisite" # 前置知识
# 构建方法
construction:
# 基于共现(同一文档中出现的实体建立关联)
co_occurrence:
enabled: true
window_size: 100 # 字符窗口
min_co_occurrence: 2
# 基于语义相似度
semantic_similarity:
enabled: true
model: "text-embedding-3-small"
threshold: 0.8
# 基于显式链接(文档中的超链接)
explicit_links:
enabled: true
# 图谱存储
storage:
# 使用 NetworkX + 持久化
format: "graphml"
path: "./knowledge/knowledge_graph.graphml"
# 定期备份
backup:
enabled: true
interval: "1d"
keep_count: 7
# 可视化
visualization:
enabled: true
# 使用 D3.js 或 Gephi 导出
export_formats:
- "html" # 交互式网页
- "png" # 静态图片
- "gexf" # Gephi 格式
7.5 定期回顾与总结
# knowledge/review_system.yaml
name: "review_system"
description: "定期知识回顾系统"
# 回顾计划
schedule:
# 每日回顾(昨晚收集的内容)
daily:
cron: "0 9 * * *" # 每天早上 9 点
content: "昨天收集的 {{count}} 条内容摘要"
format: "brief"
# 每周回顾
weekly:
cron: "0 10 * * 1" # 每周一上午 10 点
content: "本周知识汇总"
includes:
- "本周收集的内容统计"
- "新出现的概念/技术"
- "知识图谱的变化"
- "推荐阅读 TOP 5"
format: "detailed"
# 每月回顾
monthly:
cron: "0 10 1 * *" # 每月 1 号上午 10 点
content: "月度知识报告"
includes:
- "月度阅读统计"
- "知识领域分布变化"
- "兴趣趋势分析"
- "知识盲区提醒"
format: "comprehensive"
# 回顾内容生成
review_generation:
model: "gpt-4o"
# 生成风格
style: "conversational" # 像朋友聊天一样回顾
# 个性化
personalization:
# 基于用户画像调整内容
based_on_profile: true
# 强调用户关注的领域
highlight_interests: true
# 提醒可能遗漏的重要内容
surface_missed_content: true
# 推送
notifications:
# Telegram 推送
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${TELEGRAM_CHAT_ID}"
7.6 与 Notion/Obsidian 集成
Notion 集成
# integrations/notion_sync.yaml
name: "notion_sync"
description: "与 Notion 同步知识库"
# Notion API 配置
notion:
token: "${NOTION_INTEGRATION_TOKEN}"
# 目标数据库
database_id: "${NOTION_DATABASE_ID}"
# 同步规则
sync:
# 双向同步还是单向?
direction: "bidirectional"
# 同步触发条件
triggers:
- "new_content_collected"
- "daily_schedule"
- "manual"
# 字段映射
field_mapping:
hermes_field: "notion_property"
mappings:
title: "Name"
content: "Content"
category: "Category"
tags: "Tags"
url: "URL"
summary: "Summary"
collected_at: "Created"
# 自动在 Notion 中创建页面
auto_create_page:
enabled: true
# 页面模板
template: |
# {{title}}
**来源**:{{url}}
**分类**:{{category}}
**标签**:{{tags}}
---
## 摘要
{{summary}}
## 笔记
{{content}}
## 关联
{{related_content}}
Obsidian 集成
# integrations/obsidian_sync.yaml
name: "obsidian_sync"
description: "与 Obsidian 同步知识库"
# Obsidian 库路径
obsidian:
vault_path: "~/Documents/Obsidian Vault"
# 同步配置
sync:
# 输出到 Obsidian 的文件夹
output_folder: "Hermes Inbox"
# 文件名格式
filename_format: "{{date}}-{{slugified_title}}.md"
# Frontmatter 配置
frontmatter:
enabled: true
fields:
- "title"
- "source"
- "category"
- "tags"
- "collected_at"
- "summary"
# 双向链接
backlinks:
enabled: true
# 自动在相关笔记之间创建链接
auto_link:
enabled: true
# 基于标签和类别匹配
match_by: ["tags", "category", "entities"]
# 图谱兼容
graph_compatible:
enabled: true
# 使用 Obsidian 的图谱格式
format: "obsidian"
7.7 案例:研究人员的文献管理助手
这个案例专门为学术研究人员设计,帮助管理论文、笔记和研究思路。
# ============================================================
# 研究人员文献管理助手
# ============================================================
name: "research_paper_manager"
description: "学术研究人员的智能文献管理助手"
# 论文收集
paper_collection:
# arXiv 监控
arxiv:
enabled: true
# 监控的分类
categories:
- "cs.AI"
- "cs.CL"
- "cs.LG"
- "cs.MA"
# 关键词过滤
keywords:
- "agent"
- "large language model"
- "RAG"
- "multi-agent"
# 每日推送新论文
daily_digest: true
# Google Scholar 监控(需要配置)
google_scholar:
enabled: true
# 监控的学者
authors:
- "Yann LeCun"
- "Yoshua Bengio"
- "Geoffrey Hinton"
# 监控的论文引用
citation_alerts:
- "paper_id_1"
- "paper_id_2"
# 论文处理
paper_processing:
# 自动下载 PDF
auto_download:
enabled: true
save_path: "./papers/{{year}}/{{title}}.pdf"
# 提取元数据
metadata_extraction:
enabled: true
fields:
- "title"
- "authors"
- "abstract"
- "keywords"
- "publication_date"
- "doi"
- "citation_count"
# 生成论文摘要
summarization:
enabled: true
model: "gpt-4o"
# 摘要风格
style: "academic"
# 摘要长度
max_length: 500
# 提取关键贡献
extract_contributions: true
# 提取实验结果
extract_results: true
# 提取方法论
extract_methodology: true
# 相关性评分
relevance_scoring:
enabled: true
# 基于你的研究兴趣评分
research_interests:
- "AI Agent"
- "Memory Systems"
- "Tool Learning"
# 高分论文优先推送
threshold: 0.7
# 笔记管理
note_management:
# 论文阅读笔记模板
note_template: |
# {{paper.title}}
**作者**:{{paper.authors}}
**发表**:{{paper.publication_date}}
**arXiv**:{{paper.url}}
---
## 一句话总结
{{summary.one_liner}}
## 研究问题
{{summary.research_question}}
## 核心方法
{{summary.methodology}}
## 主要贡献
{{summary.contributions}}
## 实验结果
{{summary.results}}
## 我的思考
- 这篇论文的创新点是什么?
- 有哪些局限性?
- 对我的研究有什么启发?
- 有哪些值得跟进的工作?
## 关联论文
{{related_papers}}
# 与 Zotero 同步
zotero_sync:
enabled: true
library_id: "${ZOTERO_LIBRARY_ID}"
api_key: "${ZOTERO_API_KEY}"
# 研究趋势分析
trend_analysis:
enabled: true
# 每周分析你的阅读数据
weekly_report:
includes:
- "本周阅读论文数"
- "研究领域分布"
- "高频关键词"
- "新兴研究方向"
- "推荐阅读"
8. 实战案例:客服机器人
8.1 需求分析:7x24 智能客服
对于电商、SaaS、在线教育等业务,客服是一个刚需但成本很高的环节: - 人工客服需要轮班,7×24 覆盖成本高 - 80% 的问题都是重复性的("怎么退款"、"密码忘了怎么办") - 高峰期(双 11、活动期间)客服压力巨大 - 培训新客服成本高,且服务质量不稳定
解决方案:用 Hermes 搭建一个智能客服机器人,处理常见问题,复杂问题再转人工。
预期效果: - 解决 70-80% 的常见问题,无需人工介入 - 7×24 在线,响应时间 < 3 秒 - 多语言支持(如果业务有出海需求) - 满意度收集和分析,持续优化 - 大幅降低客服成本
8.2 知识库构建
客服机器人的核心是其知识库。知识库的质量直接决定了回答的准确性。
# customer_service/knowledge_base.yaml
name: "cs_knowledge_base"
description: "客服知识库配置"
# 知识来源
sources:
# 1. FAQ 文档
faq:
files:
- "./knowledge/faq.md"
- "./knowledge/return_policy.md"
- "./knowledge/shipping_info.md"
# 2. 产品文档
product_docs:
url: "https://docs.yourcompany.com"
# 自动抓取和更新
auto_sync:
enabled: true
interval: "1d"
# 3. 历史客服记录
chat_history:
# 导入历史对话作为训练数据
import:
enabled: true
source: "zendesk" # 或 freshdesk, intercom
api_key: "${SUPPORT_API_KEY}"
# 只导入高评分对话
filter:
rating: ">= 4"
# 排除敏感对话
exclude_tags: ["sensitive", "legal"]
# 4. 商品信息
product_catalog:
source: "database"
connection: "${DATABASE_URL}"
query: "SELECT id, name, description, price, specs FROM products"
# 知识处理
processing:
# 分块策略
chunking:
strategy: "semantic"
chunk_size: 500
chunk_overlap: 100
# Embedding 模型
embedding:
model: "text-embedding-3-small"
# 是否缓存 embedding
cache: true
# 索引构建
indexing:
# 向量索引
vector_index:
enabled: true
# 使用 FAISS 或类似的向量索引
backend: "faiss"
# 关键词索引(用于混合检索)
keyword_index:
enabled: true
# 使用 SQLite FTS5
backend: "fts5"
# 混合检索权重
hybrid_weights:
semantic: 0.7
keyword: 0.3
# 知识库更新
updates:
# 定期重新索引
reindex_interval: "7d"
# 增量更新
incremental:
enabled: true
# 检测新内容并自动索引
watch_files: true
8.3 多轮对话管理
客服场景通常需要多轮对话——不是一问一答就能解决的。
# customer_service/conversation_manager.yaml
name: "conversation_manager"
description: "客服多轮对话管理"
# 对话状态跟踪
state_tracking:
enabled: true
# 跟踪的上下文信息
context:
- "user_intent" # 用户当前意图
- "intent_history" # 意图历史
- "collected_info" # 已收集的信息
- "missing_info" # 还缺的信息
- "escalation_reason" # 升级原因
# 对话流程定义
flows:
# 流程1:订单查询
order_inquiry:
trigger: "intent == 'order_query'"
steps:
- ask: "请问您的订单号是多少?"
extract: "order_id"
validation: "regex:^[A-Z0-9]{10}$"
- if: "order_id valid"
then:
- action: "query_order"
params:
order_id: "{{order_id}}"
- respond: "您的订单 {{order_id}} 当前状态是 {{order.status}},预计 {{order.eta}} 送达。"
else:
- ask: "订单号格式不正确,请提供 10 位字母数字组合的订单号。"
retry: 2
- ask: "还有其他我可以帮您的吗?"
branch:
- if: "intent == 'yes'"
then: "continue"
- if: "intent == 'no'"
then: "end"
# 流程2:退款申请
refund_request:
trigger: "intent == 'refund'"
steps:
- ask: "好的,我来帮您处理退款。请问您要退款的订单号是多少?"
extract: "order_id"
- ask: "退款原因是什么?"
extract: "refund_reason"
options:
- "商品质量问题"
- "与描述不符"
- "不想要了"
- "其他"
- action: "check_refund_eligibility"
params:
order_id: "{{order_id}}"
reason: "{{refund_reason}}"
- if: "eligible == true"
then:
- action: "create_refund_ticket"
- respond: "退款申请已提交,退款将在 3-5 个工作日原路返回。退款单号:{{ticket_id}}"
else:
- respond: "很抱歉,该订单不符合退款条件。原因:{{ineligible_reason}}"
- offer: "human_handoff"
# 流程3:技术支持
tech_support:
trigger: "intent == 'technical_issue'"
steps:
- ask: "请描述您遇到的问题,我会尽力帮您解决。"
extract: "issue_description"
- action: "search_knowledge_base"
query: "{{issue_description}}"
- if: "solution_found"
then:
- respond: "根据我们的知识库,您可以尝试以下解决方案:\n{{solution}}"
- ask: "问题解决了吗?"
branch:
- if: "solved"
then: "end_with_satisfaction"
- if: "not_solved"
then: "escalate_to_human"
else:
- respond: "这个问题比较特殊,我为您转接人工客服。"
- action: "escalate"
# 意图识别
intent_detection:
model: "gpt-4o-mini"
# 预定义意图
intents:
- "order_query"
- "refund"
- "shipping"
- "product_info"
- "technical_issue"
- "account"
- "complaint"
- "general_chat"
# 置信度阈值
confidence_threshold: 0.7
# 低于阈值时询问确认
ask_confirmation: true
8.4 人机转接机制
客服机器人不是万能的。当遇到以下情况时,应该及时转接人工:
# customer_service/escalation.yaml
name: "escalation_rules"
description: "人机转接规则"
# 自动转人工的触发条件
auto_escalate:
# 条件1:用户明确要求人工
- condition: "user_says: ['人工', '客服', '找人工', '转人工']"
action: "immediate_transfer"
message: "正在为您转接人工客服,请稍候..."
# 条件2:连续 3 次无法回答
- condition: "consecutive_failures >= 3"
action: "offer_transfer"
message: "很抱歉,我暂时无法解决这个问题。是否需要转接人工客服?"
# 条件3:检测到负面情绪升级
- condition: "sentiment_score < -0.5 AND escalation_count == 0"
action: "priority_transfer"
message: "非常抱歉给您带来不好的体验,我立即为您安排资深客服专员。"
# 条件4:涉及敏感话题(退款纠纷、法律问题等)
- condition: "topic in ['legal', 'complaint_severe', 'fraud']"
action: "immediate_transfer"
message: "这个问题需要专人处理,正在为您转接..."
# 条件5:超出知识库范围
- condition: "kb_confidence < 0.3"
action: "offer_transfer"
message: "这个问题超出了我的知识范围,需要人工客服协助。"
# 转接信息传递
handoff_context:
# 转接时传递给人工客服的信息
include:
- "conversation_history"
- "user_intent"
- "collected_information"
- "attempted_solutions"
- "escalation_reason"
- "user_sentiment"
# 格式化
format: "structured_summary"
# 人工客服状态
agent_availability:
# 检查人工客服是否在线
check_online: true
# 排队管理
queue:
enabled: true
# 预估等待时间
show_wait_time: true
# 排队中自动安抚
queue_messages:
- "当前排队人数:{{queue_position}},预计等待 {{wait_time}}"
- "您也可以先描述问题,客服上线后会优先处理"
8.5 满意度收集
# customer_service/satisfaction.yaml
name: "satisfaction_collection"
description: "客服满意度收集"
# 满意度调查
collection:
# 触发时机
trigger: "conversation_end"
# 调查方式
method: "inline"
# 调查内容
survey:
- question: "请问您对本次服务满意吗?"
type: "rating"
scale: 5
emoji: ["😠", "😞", "😐", "🙂", "😊"]
- question: "我的回答解决了您的问题吗?"
type: "boolean"
- question: "您还有其他建议吗?"
type: "text"
optional: true
# 反馈处理
feedback_processing:
# 实时分析反馈
real_time_analysis:
enabled: true
model: "gpt-4o-mini"
# 分析维度
dimensions:
- "satisfaction_score"
- "issue_resolved"
- "sentiment"
- "specific_complaints"
# 低满意度预警
alerts:
- condition: "rating <= 2"
action: "notify_manager"
message: "⚠️ 低满意度会话:{{conversation_id}},请及时跟进"
- condition: "rating == 1"
action: "create_follow_up_ticket"
# 数据驱动优化
optimization:
# 定期分析满意度数据
weekly_analysis:
enabled: true
# 生成改进建议
generate_insights: true
# 识别知识库缺口
identify_kb_gaps: true
# 更新知识库
auto_update_kb: false # 建议人工确认后再更新
8.6 多渠道部署(网站、微信、Telegram)
网站接入(Web Widget)
# deployment/web_widget.yaml
name: "web_widget"
description: "网站客服组件"
# Widget 配置
widget:
# 样式
appearance:
position: "bottom-right"
primary_color: "#1890ff"
welcome_message: "👋 你好!有什么可以帮您的吗?"
avatar: "./assets/bot-avatar.png"
# 触发方式
triggers:
- "user_clicks_button"
- "time_on_page > 30s"
- "scroll_depth > 80%"
# 功能
features:
- "text_chat"
- "quick_replies"
- "file_upload" # 用户可上传图片/截图
# 快捷回复按钮
quick_replies:
- "查询订单"
- "退款申请"
- "物流查询"
- "联系人工"
# 嵌入代码(给前端开发者)
embed_code: |
<script>
(function() {
var script = document.createElement('script');
script.src = 'https://hermes.yourcompany.com/widget.js';
script.async = true;
script.onload = function() {
HermesWidget.init({
apiKey: 'YOUR_API_KEY',
position: 'bottom-right'
});
};
document.head.appendChild(script);
})();
</script>
微信公众号接入
# deployment/wechat_bot.yaml
name: "wechat_customer_service"
description: "微信客服机器人"
# 微信公众号配置
wechat:
app_id: "${WECHAT_APP_ID}"
app_secret: "${WECHAT_APP_SECRET}"
token: "${WECHAT_TOKEN}"
encoding_aes_key: "${WECHAT_AES_KEY}"
# 消息处理
message_handling:
# 接收用户消息
receive:
endpoint: "/webhook/wechat"
method: "POST"
# 消息类型处理
handlers:
text:
action: "process_with_knowledge_base"
image:
action: "ocr_and_process" # 图片先 OCR 再处理
voice:
action: "stt_and_process" # 语音先转文字再处理
location:
action: "provide_local_service" # 基于位置的服务
# 被动回复(微信公众号 5 秒超时限制)
response_strategy:
# 快速回复(必须在 5 秒内)
immediate:
enabled: true
# 如果处理需要时间,先回复"正在处理"
processing_message: "正在为您查询,请稍候..."
# 异步回复(通过客服消息接口)
async:
enabled: true
# 使用微信客服消息接口(48 小时内可发 20 条)
use_customer_service_api: true
# 菜单配置
menu:
items:
- name: "查询订单"
type: "click"
key: "QUERY_ORDER"
- name: "常见问题"
type: "view"
url: "https://yourcompany.com/faq"
- name: "联系客服"
type: "click"
key: "CONTACT_SUPPORT"
Telegram Bot 接入
# deployment/telegram_bot.yaml
name: "telegram_customer_service"
description: "Telegram 客服机器人"
# Bot 配置
telegram:
bot_token: "${TELEGRAM_BOT_TOKEN}"
# Webhook 或轮询
update_mode: "webhook" # 或 "polling"
webhook_url: "https://yourdomain.com/webhook/telegram"
# 命令列表
commands:
- command: "start"
description: "开始使用"
handler: "welcome"
- command: "help"
description: "帮助信息"
handler: "show_help"
- command: "order"
description: "查询订单"
handler: "query_order"
- command: "refund"
description: "申请退款"
handler: "refund_request"
- command: "human"
description: "联系人工客服"
handler: "escalate_to_human"
# 内联键盘
inline_keyboards:
main_menu:
- buttons:
- text: "📦 查询订单"
callback_data: "menu_order"
- text: "💰 申请退款"
callback_data: "menu_refund"
- buttons:
- text: "📖 常见问题"
callback_data: "menu_faq"
- text: "👨💼 人工客服"
callback_data: "menu_human"
8.7 案例:小型电商的客服解决方案
下面是一个完整的小型电商客服系统配置,你可以直接基于它修改使用:
# ============================================================
# 小型电商智能客服系统
# ============================================================
name: "ecommerce_customer_service"
description: "小型电商 7x24 智能客服解决方案"
# 系统配置
system:
# 欢迎语
welcome_message: |
🛍️ 欢迎来到 {{shop_name}}!
我是您的智能客服助手,可以帮您:
• 📦 查询订单状态
• 💰 申请退款/退换货
• 🚚 查询物流信息
• 🎁 了解优惠活动
• 👤 账户相关问题
请直接输入您的问题,或点击下方菜单选择服务。
# 工作时段
business_hours:
weekdays: "09:00-22:00"
weekends: "10:00-21:00"
# 非工作时间的特殊回复
after_hours_message: "当前为非工作时间,您的留言将在客服上班后第一时间处理。紧急问题请拨打:{{emergency_phone}}"
# 知识库
knowledge_base:
# FAQ
faq:
- question: "多久发货"
answer: "一般情况下,订单付款后 24 小时内发货。预售商品以商品页面标注的时间为准。"
keywords: ["发货", "多久发货", "什么时候发货"]
- question: "支持哪些支付方式"
answer: "我们支持微信支付、支付宝、银行卡支付。部分商品支持货到付款。"
keywords: ["支付", "付款", "怎么付钱"]
- question: "怎么退货"
answer: |
退货流程:
1. 进入"我的订单"找到对应订单
2. 点击"申请售后"
3. 选择退货原因并提交
4. 审核通过后,按地址寄回商品
5. 我们收到商品后 3 个工作日内退款
注意:定制类商品不支持退货。
keywords: ["退货", "怎么退", "退款"]
- question: "运费怎么算"
answer: "订单满 99 元包邮(偏远地区除外)。不满 99 元收取 6 元运费。"
keywords: ["运费", "邮费", "多少钱"]
- question: "怎么修改地址"
answer: "订单未发货前可以修改地址。请提供订单号,我帮您查看是否还可以修改。"
keywords: ["改地址", "修改地址", "地址错了"]
# 订单查询(接入数据库)
order_query:
enabled: true
database:
connection: "${DATABASE_URL}"
# 查询模板
queries:
by_order_id: |
SELECT o.id, o.status, o.total, o.created_at,
oi.product_name, oi.quantity,
s.tracking_number, s.carrier, s.status as shipping_status
FROM orders o
LEFT JOIN order_items oi ON o.id = oi.order_id
LEFT JOIN shipments s ON o.id = s.order_id
WHERE o.id = $1
# 状态映射(数据库状态 -> 用户友好状态)
status_mapping:
pending: "待付款"
paid: "已付款,待发货"
shipped: "已发货"
delivered: "已送达"
completed: "已完成"
cancelled: "已取消"
refunding: "退款中"
# 退款处理
refund:
# 退款规则
rules:
# 7 天无理由退货
no_reason_return:
enabled: true
period_days: 7
exclude_categories: ["定制", "生鲜", "贴身衣物"]
# 质量问题退货
quality_issue:
enabled: true
# 免邮费退回
free_return: true
# 自动退款(小额)
auto_refund:
enabled: true
max_amount: 100 # 100 元以下自动退
require_approval_above: 100
# 部署
channels:
# 网站 Widget
web:
enabled: true
widget_config: "./web_widget.yaml"
# 微信公众号
wechat:
enabled: true
config: "./wechat_bot.yaml"
# 微信小程序(需要额外配置)
wechat_mini:
enabled: false
# 抖音(企业号私信)
douyin:
enabled: false
# 人工接管
human_handoff:
# 工作时间配置
working_hours:
agents_online: true
max_queue: 10
# 非工作时间
after_hours:
agents_online: false
leave_message: true
auto_reply: "客服当前不在线,您的问题已记录,上班后第一时间回复。"
# 数据分析
analytics:
# 每日统计
daily_report:
enabled: true
metrics:
- "总会话数"
- "机器人解决率"
- "平均响应时间"
- "转人工率"
- "满意度评分"
- "高频问题 TOP 10"
# 推送
notification:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${ADMIN_CHAT_ID}"
9. 实战案例:数据监控与告警
9.1 需求分析:实时监控关键指标
无论是个人用户还是企业,都有很多需要监控的指标: - 网站是否正常运行? - 关注的商品价格是否降价了? - 竞争对手发布了什么新产品? - 加密货币价格是否触及了你的买卖点? - 服务器资源使用是否超过阈值?
手动检查这些指标既耗时又容易遗漏。让 Hermes 帮你 7×24 监控,异常情况第一时间通知你。
9.2 网站可用性监控
# monitoring/website_monitor.yaml
name: "website_monitor"
description: "网站可用性监控"
# 监控目标
targets:
- name: "主站"
url: "https://yourwebsite.com"
method: "GET"
expected_status: 200
expected_response_time: 2000 # ms
- name: "API 服务"
url: "https://api.yourwebsite.com/health"
method: "GET"
expected_status: 200
# 检查返回内容
expected_body: '{"status":"ok"}'
- name: "博客"
url: "https://blog.yourwebsite.com"
method: "GET"
# 检查频率
intervals:
# 主站每 1 分钟检查一次
critical: "1m"
# 次要服务每 5 分钟
normal: "5m"
# 非核心服务每 15 分钟
low: "15m"
# 告警条件
alerts:
# 条件1:HTTP 状态码异常
- condition: "status_code != expected"
severity: "critical"
message: "🚨 {{target.name}} 返回异常状态码:{{status_code}}"
# 条件2:响应时间过长
- condition: "response_time > expected_response_time"
severity: "warning"
message: "⚠️ {{target.name}} 响应缓慢:{{response_time}}ms"
# 条件3:SSL 证书即将过期
- condition: "ssl_expiry_days < 7"
severity: "warning"
message: "🔒 {{target.name}} SSL 证书将在 {{ssl_expiry_days}} 天后过期"
# 条件4:DNS 解析失败
- condition: "dns_resolution_failed"
severity: "critical"
message: "🌐 {{target.name}} DNS 解析失败"
# 告警渠道
notification_channels:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${ALERT_CHAT_ID}"
email:
enabled: true
smtp_server: "smtp.gmail.com"
to: "${ADMIN_EMAIL}"
# 飞书
feishu:
enabled: true
webhook_url: "${FEISHU_WEBHOOK_URL}"
# 告警收敛
alert_grouping:
# 同一问题 5 分钟内不重复告警
dedup_window: "5m"
# 连续失败 2 次才告警(避免抖动)
min_consecutive_failures: 2
9.3 价格变动追踪
# monitoring/price_tracker.yaml
name: "price_tracker"
description: "商品价格追踪"
# 追踪的商品
tracked_products:
- name: "iPhone 16 Pro"
url: "https://www.apple.com/iphone-16-pro/"
# 价格选择器(CSS 或 XPath)
price_selector: ".price-current"
# 当前价格(用于计算变动)
current_price: 7999
# 目标价格(低于此价格时告警)
target_price: 6999
- name: "Sony WH-1000XM5"
url: "https://www.sony.com/headphones"
price_selector: ".price"
target_price: 1800
# 检查频率
check_interval: "1h"
# 价格变动告警
alerts:
# 降价到目标价以下
- condition: "price <= target_price"
severity: "info"
message: |
🎉 降价提醒!
{{product.name}} 当前价格:¥{{price}}
目标价格:¥{{target_price}}
购买链接:{{product.url}}
# 大幅降价(超过 10%)
- condition: "price_drop_percent >= 10"
severity: "info"
message: "📉 {{product.name}} 大幅降价 {{price_drop_percent}}%,当前 ¥{{price}}"
# 价格历史
history:
enabled: true
# 保存到数据库
storage: "sqlite"
# 生成价格走势图
generate_chart: true
9.4 竞品动态追踪
# monitoring/competitor_tracker.yaml
name: "competitor_tracker"
description: "竞品动态追踪"
# 监控的竞争对手
competitors:
- name: "竞品 A"
website: "https://competitor-a.com"
# 监控的页面
pages:
- url: "/pricing"
track_changes: true
- url: "/changelog"
track_changes: true
- url: "/blog"
track_new_posts: true
- name: "竞品 B"
twitter: "@competitor_b"
track_tweets: true
keywords: ["新品", "更新", "发布"]
# 监控内容
tracking:
# 官网变化
website_changes:
enabled: true
# 检测内容变化
detect_content_change: true
# 忽略的部分(如时间戳、广告)
ignore_selectors:
- ".timestamp"
- ".ad-banner"
# 新产品/功能发布
product_launches:
enabled: true
# 检测关键词
launch_keywords:
- "发布"
- "推出"
- "新品"
- "new release"
- "launch"
# 定价变化
pricing_changes:
enabled: true
# 价格页面监控
price_page_selectors:
- ".pricing-card"
- ".price-table"
# 告警
alerts:
- condition: "website_changed"
message: "🔍 {{competitor.name}} 官网有更新:{{changed_pages}}"
- condition: "new_product_launch"
message: "🚀 {{competitor.name}} 发布了新产品/功能:{{product_name}}"
- condition: "pricing_changed"
message: "💰 {{competitor.name}} 调整了定价"
9.5 异常检测与告警
# monitoring/anomaly_detection.yaml
name: "anomaly_detection"
description: "异常检测与智能告警"
# 检测方法
methods:
# 基于阈值的简单检测
threshold:
enabled: true
rules:
- metric: "cpu_usage"
warning: 70
critical: 90
- metric: "memory_usage"
warning: 80
critical: 95
- metric: "disk_usage"
warning: 80
critical: 90
- metric: "error_rate"
warning: 5
critical: 10
# 基于统计的异常检测
statistical:
enabled: true
model: "isolation_forest"
# 学习历史数据
training_window: "7d"
# 异常阈值
contamination: 0.01 # 期望的异常比例
# 基于 AI 的异常检测
ai_based:
enabled: true
model: "gpt-4o-mini"
# 分析日志和指标,识别异常模式
analyze_logs: true
analyze_metrics: true
# 告警升级
escalation:
# 第一次告警
first_alert:
channels: ["telegram"]
# 5 分钟未处理,升级
escalation_1:
delay: "5m"
channels: ["telegram", "email"]
# 15 分钟未处理,再次升级
escalation_2:
delay: "15m"
channels: ["telegram", "email", "phone"]
# 告警恢复通知
recovery_notification:
enabled: true
message: "✅ {{alert.name}} 已恢复正常"
9.6 案例:加密货币价格监控 + Telegram 告警
下面是一个完整的加密货币价格监控方案:
# ============================================================
# 加密货币价格监控 + Telegram 告警
# ============================================================
name: "crypto_price_monitor"
description: "加密货币实时价格监控与告警"
# 监控的币种
coins:
- symbol: "BTC"
name: "比特币"
# 当前持仓(用于计算盈亏)
holding: 0.5
avg_buy_price: 60000
# 价格告警
alerts:
- type: "above"
price: 75000
message: "🚀 BTC 突破 $75,000!当前 ${{price}}"
- type: "below"
price: 55000
message: "📉 BTC 跌破 $55,000!当前 ${{price}}"
- type: "percent_change_24h"
threshold: 10
message: "📊 BTC 24h 涨跌 {{change_percent}}%,当前 ${{price}}"
- symbol: "ETH"
name: "以太坊"
holding: 5
avg_buy_price: 3000
alerts:
- type: "above"
price: 4000
message: "🚀 ETH 突破 $4,000!"
- type: "below"
price: 2500
message: "📉 ETH 跌破 $2,500!"
- symbol: "SOL"
name: "Solana"
holding: 100
avg_buy_price: 120
# 数据源
price_sources:
primary: "coingecko"
fallback: "binance"
coingecko:
api_key: "${COINGECKO_API_KEY}"
update_interval: 60 # 秒
binance:
# 免费,无需 API Key
update_interval: 30
# 持仓盈亏监控
portfolio:
enabled: true
# 每天汇总持仓盈亏
daily_report:
enabled: true
cron: "0 9 * * *" # 每天早上 9 点
timezone: "Asia/Shanghai"
# 大幅波动告警
portfolio_alerts:
- condition: "total_pnl_change_24h > 10%"
message: |
💼 持仓日报
总持仓价值:${{total_value}}
24h 盈亏:{{pnl_24h}} ({{pnl_24h_percent}}%)
累计盈亏:{{total_pnl}} ({{total_pnl_percent}}%)
各币种详情:
{{#each coins}}
{{name}}: ${{price}} ({{change_24h}}%)
{{/each}}
# 推送
notifications:
telegram:
enabled: true
bot_token: "${TELEGRAM_BOT_TOKEN}"
chat_id: "${TELEGRAM_CHAT_ID}"
# 同时发送价格走势图
include_chart: true
# 命令(通过 Telegram Bot 交互)
commands:
- command: "/price"
description: "查询指定币种价格"
handler: |
/price BTC -> 返回比特币当前价格
/price ETH -> 返回以太坊当前价格
- command: "/portfolio"
description: "查看持仓"
handler: "show_portfolio"
- command: "/alert"
description: "设置价格提醒"
handler: |
/alert BTC above 70000 -> BTC 突破 70000 时提醒
/alert ETH below 3000 -> ETH 跌破 3000 时提醒
- command: "/top"
description: "查看涨幅榜"
handler: "show_top_gainers"
# 存储
storage:
# 价格历史
price_history:
enabled: true
retention: "90d" # 保留 90 天
# 告警历史
alert_history:
enabled: true
retention: "30d"
启动命令
# 加载监控配置
$ hermes monitor load ./crypto_price_monitor.yaml
# 手动测试告警
$ hermes monitor test-alert crypto_price_monitor --coin BTC
# 查看价格历史
$ hermes monitor history --coin BTC --days 7
# Telegram 交互示例
# 用户发送:/price BTC
# Bot 回复:
# 💰 BTC 当前价格
# 价格:$67,432
# 24h 涨跌:+2.34%
# 7d 涨跌:-1.23%
# 市值:$1.32T
注意
加密货币投资风险极高,本案例仅作为技术演示。任何投资决策请自行判断,切勿依赖自动化工具的输出。设置价格提醒时,建议同时设置止损提醒,控制风险。
10. 企业级应用场景
10.1 企业内部知识库助手
企业内部的文档、制度、流程分散在各个地方——Confluence、Wiki、SharePoint、邮件、聊天记录。新员工入职要花几周才能熟悉,老员工也经常找不到需要的信息。
# enterprise/internal_kb.yaml
name: "enterprise_knowledge_assistant"
description: "企业内部知识库助手"
# 数据源集成
data_sources:
# Confluence
confluence:
enabled: true
url: "https://yourcompany.atlassian.net"
username: "${CONFLUENCE_USER}"
api_token: "${CONFLUENCE_TOKEN}"
spaces:
- "ENGINEERING"
- "PRODUCT"
- "HR"
# 企业微信文档
wechat_docs:
enabled: true
corp_id: "${WECHAT_CORP_ID}"
secret: "${WECHAT_SECRET}"
# 本地文件
local_files:
enabled: true
paths:
- "/shared/docs/"
- "/shared/policies/"
# 支持的格式
formats: [".pdf", ".docx", ".md", ".txt"]
# 数据库
database:
enabled: true
queries:
- name: "员工信息"
query: "SELECT name, department, email FROM employees"
- name: "项目信息"
query: "SELECT name, status, owner FROM projects"
# 访问控制
access_control:
# 基于角色的访问
rbac:
enabled: true
roles:
- name: "employee"
access: ["general_docs", "hr_policies"]
- name: "manager"
access: ["general_docs", "hr_policies", "management_docs"]
- name: "engineer"
access: ["general_docs", "engineering_docs", "api_docs"]
- name: "hr"
access: ["*"] # HR 可以访问所有
# 问答优化
qa_optimization:
# 常见问题预设
faq:
- question: "请假流程是什么"
answer: |
请假流程:
1. 在 OA 系统提交请假申请
2. 直属领导审批
3. 3 天以上需部门总监审批
4. HR 备案
紧急请假可先口头告知,事后补流程。
- question: "怎么申请报销"
answer: |
报销流程:
1. 收集发票和收据
2. 在费控系统填写报销单
3. 上传电子发票
4. 直属领导审批
5. 财务审核打款
# 回答风格
tone: "professional"
# 引用来源
cite_sources: true
# 不确定时提示
uncertain_response: "这个问题我不确定答案,建议您咨询 {{suggested_contact}}"
# 部署方式
deployment:
# 企业微信机器人
wechat_work:
enabled: true
corp_id: "${WECHAT_CORP_ID}"
agent_id: "${AGENT_ID}"
secret: "${AGENT_SECRET}"
# 飞书机器人
feishu:
enabled: true
app_id: "${FEISHU_APP_ID}"
app_secret: "${FEISHU_APP_SECRET}"
# Web 界面
web:
enabled: true
host: "0.0.0.0"
port: 8080
auth: "sso" # 单点登录
10.2 数据库查询助手(接入公司 DB)
让非技术人员也能通过自然语言查询数据库,而不需要写 SQL。
# enterprise/db_assistant.yaml
name: "database_query_assistant"
description: "自然语言数据库查询助手"
# 数据库连接
databases:
- name: "production"
type: "postgresql"
host: "${DB_HOST}"
port: 5432
database: "analytics"
username: "${DB_USER}"
password: "${DB_PASSWORD}"
# 只读权限
read_only: true
# Schema 描述(帮助 AI 理解表结构)
schema_description:
tables:
- name: "orders"
description: "订单表,存储所有交易订单"
columns:
- name: "id"
description: "订单 ID"
- name: "user_id"
description: "用户 ID"
- name: "total_amount"
description: "订单总金额"
- name: "status"
description: "订单状态:pending, paid, shipped, completed"
- name: "created_at"
description: "创建时间"
- name: "users"
description: "用户表"
columns:
- name: "id"
description: "用户 ID"
- name: "email"
description: "邮箱"
- name: "registration_date"
description: "注册日期"
# 安全限制
security:
# 只允许 SELECT
allowed_operations: ["SELECT"]
# 禁止查询敏感表
forbidden_tables:
- "passwords"
- "api_keys"
- "salary_info"
# 最大返回行数
max_rows: 1000
# 查询超时
query_timeout: 30
# 数据脱敏
data_masking:
- column_pattern: "email"
mask: "partial" # 显示为 a***@example.com
- column_pattern: "phone"
mask: "full" # 完全隐藏
# 查询示例(用于 few-shot 提示)
examples:
- question: "上个月销售额是多少"
sql: |
SELECT SUM(total_amount) as total_sales
FROM orders
WHERE status = 'completed'
AND created_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
AND created_at < DATE_TRUNC('month', CURRENT_DATE)
- question: "哪个地区的用户最多"
sql: |
SELECT region, COUNT(*) as user_count
FROM users
GROUP BY region
ORDER BY user_count DESC
LIMIT 10
10.3 项目管理自动化(接入 Linear/Jira)
# enterprise/project_management.yaml
name: "pm_automation"
description: "项目管理自动化"
# 集成的项目管理工具
integrations:
linear:
enabled: true
api_key: "${LINEAR_API_KEY}"
team_id: "${LINEAR_TEAM_ID}"
jira:
enabled: false
url: "https://yourcompany.atlassian.net"
username: "${JIRA_USER}"
api_token: "${JIRA_TOKEN}"
# 自动化规则
automation_rules:
# 规则1:每日站会摘要
- name: "daily_standup_summary"
trigger:
schedule: "0 9 * * 1-5" # 工作日早上 9 点
actions:
- "fetch_recent_updates"
- "generate_summary"
- "post_to_channel"
summary_template: |
📋 昨日更新({{date}})
**已完成**:{{completed_count}} 个任务
{{#each completed}}
- {{title}} ({{assignee}})
{{/each}}
**进行中**:{{in_progress_count}} 个任务
{{#each in_progress}}
- {{title}} ({{assignee}}) - {{progress}}%
{{/each}}
**阻塞中**:{{blocked_count}} 个任务
{{#each blocked}}
- {{title}} ({{assignee}}) - 阻塞原因:{{block_reason}}
{{/each}}
# 规则2:逾期任务提醒
- name: "overdue_reminder"
trigger:
schedule: "0 10 * * *"
condition: "due_date < today AND status != 'done'"
actions:
- "notify_assignee"
- "notify_manager"
message: "⏰ 任务「{{title}}」已逾期 {{overdue_days}} 天,请尽快处理。"
# 规则3:PR 与 Ticket 关联
- name: "pr_ticket_link"
trigger: "pr_created"
condition: "pr.title contains ticket_id"
actions:
- "link_pr_to_ticket"
- "update_ticket_status"
- "comment_on_ticket"
# 规则4:发布计划自动更新
- name: "release_tracking"
trigger: "ticket_status_changed_to_done"
condition: "ticket.has_label('release')"
actions:
- "update_release_notes"
- "notify_stakeholders"
# 通知渠道
notifications:
slack:
enabled: true
channel: "#project-updates"
wechat_work:
enabled: true
webhook: "${WECHAT_WEBHOOK}"
10.4 会议纪要自动生成
# enterprise/meeting_notes.yaml
name: "meeting_assistant"
description: "会议纪要自动生成"
# 会议录音/转录
input:
# 方式1:上传录音文件
audio_upload:
enabled: true
formats: [".mp3", ".wav", ".m4a"]
# 方式2:实时转录(配合会议软件)
live_transcription:
enabled: true
# 支持的会议平台
platforms:
- "zoom"
- "teams"
- "tencent_meeting"
# 实时转录服务
stt_engine: "whisper_api"
# 纪要生成
generation:
model: "gpt-4o"
# 输出结构
output_structure:
- section: "基本信息"
fields:
- "会议主题"
- "参会人员"
- "会议时间"
- "会议地点/链接"
- section: "会议摘要"
fields:
- "一句话总结"
- "主要议题"
- section: "讨论要点"
fields:
- "议题1及结论"
- "议题2及结论"
- "未决事项"
- section: "行动项"
fields:
- "任务描述"
- "负责人"
- "截止日期"
- section: "下次会议"
fields:
- "待定事项"
- "建议时间"
# 风格
style: "concise" # concise / detailed
# 后续行动
follow_up:
# 自动创建任务
auto_create_tasks:
enabled: true
integration: "linear" # 或 jira
# 发送纪要给参会者
distribute:
enabled: true
method: "email"
# 自动提取参会者邮箱
extract_attendees: true
# 存档
archive:
enabled: true
location: "confluence"
space: "MEETING-NOTES"
10.5 企业安全与合规考量
在企业环境中部署 Hermes,安全和合规是不可妥协的底线。
# enterprise/security_compliance.yaml
name: "enterprise_security"
description: "企业安全与合规配置"
# 数据安全
data_security:
# 数据本地化
local_only: true
# 禁止上传到云端
cloud_upload: false
# 加密
encryption:
at_rest: true # 静态加密
in_transit: true # 传输加密
key_management: "internal" # 内部密钥管理
# 数据分类
data_classification:
levels:
- "public" # 公开
- "internal" # 内部
- "confidential" # 机密
- "restricted" # 受限
# 访问控制
access_control:
# 身份认证
authentication:
method: "sso" # SSO / ldap / oauth
provider: "okta"
mfa_required: true
# 授权
authorization:
rbac: true
abac: true # 基于属性的访问控制
# 审计日志
audit_log:
enabled: true
log_all_queries: true
log_all_actions: true
retention: "1y"
# 合规
compliance:
# GDPR
gdpr:
enabled: true
data_retention_limit: "2y"
right_to_be_forgotten: true
# 等保 2.0(中国)
mlps:
enabled: true
level: "三级"
# SOC 2
soc2:
enabled: true
type: "Type II"
# 模型安全
model_security:
# 使用私有化部署的模型(如果有)
private_model:
enabled: false
endpoint: "http://internal-llm:8000"
# 敏感信息过滤
pii_filter:
enabled: true
# 检测并脱敏
patterns:
- "身份证号"
- "银行卡号"
- "手机号"
- "邮箱"
# 输出审查
output_filter:
enabled: true
# 禁止模型输出敏感信息
block_pii_in_output: true
10.6 多用户共享实例配置
企业通常需要多个员工共享一个 Hermes 实例,同时保证数据隔离。
# enterprise/multi_user.yaml
name: "multi_user_setup"
description: "多用户共享实例配置"
# 用户管理
user_management:
# 用户认证
authentication:
method: "sso"
provider: "azure_ad" # 或 okta, google_workspace
# 用户目录同步
directory_sync:
enabled: true
sync_interval: "1h"
auto_create_users: true
auto_disable_leavers: true
# 数据隔离
isolation:
# 用户级隔离
user_level:
enabled: true
# 每个用户独立的数据空间
data_per_user: true
memory_per_user: true
settings_per_user: true
# 团队级隔离
team_level:
enabled: true
# 团队共享知识库
shared_kb_per_team: true
# 团队级权限
team_admin: true
# 资源分配
resource_quota:
# 每个用户的资源配额
per_user:
max_concurrent_sessions: 3
daily_api_calls: 1000
storage_limit: "1GB"
# 每个团队的资源配额
per_team:
daily_api_calls: 10000
storage_limit: "10GB"
max_members: 50
# 共享资源
shared_resources:
# 企业级知识库(全员可读)
enterprise_kb:
enabled: true
access: "all_users"
# 共享技能
shared_skills:
enabled: true
# 管理员审核后全员可用
approval_required: true
# 共享工具配置
shared_tools:
enabled: true
# 如:数据库连接、API 凭证(只读)
tools:
- "db_readonly"
- "internal_api"
11. 高阶技巧合集
11.1 技巧1:模型热切换(不同任务用不同模型)
不是所有任务都需要最强的模型。学会"按需选模",能帮你省下一大笔 API 费用。
# tips/model_routing.yaml
name: "smart_model_routing"
description: "智能模型路由配置"
# 模型路由规则
routing:
# 简单任务用便宜模型
- task_type: "summarize"
model: "gpt-4o-mini"
reason: "摘要任务对模型能力要求不高"
- task_type: "classify"
model: "gpt-4o-mini"
reason: "分类是模型的基础能力"
- task_type: "translate"
model: "gpt-4o-mini"
reason: "翻译任务 GPT-4o-mini 已足够优秀"
# 复杂任务用强模型
- task_type: "analyze"
model: "gpt-4o"
reason: "分析需要推理能力"
- task_type: "code"
model: "gpt-4o"
reason: "代码生成需要高精度"
- task_type: "creative"
model: "gpt-4o"
temperature: 0.8
reason: "创意写作需要更强的理解和生成能力"
# 超长文本用 Claude
- condition: "input_tokens > 100000"
model: "claude-sonnet"
reason: "Claude 的上下文窗口更大"
# 推理任务用 o1
- task_type: "reasoning"
model: "o1-mini"
reason: "o1 在推理任务上表现更好"
# 动态降级
fallback:
# 如果主模型超时或失败,降级到备选
enabled: true
chain:
- "gpt-4o"
- "gpt-4o-mini"
- "claude-haiku"
命令行快速切换
# 查看当前模型
$ hermes config get model
# 临时切换模型(单次对话)
$ hermes chat --model gpt-4o "分析这份报告"
# 切换默认模型
$ hermes config set model gpt-4o-mini
# 查看各模型成本对比
$ hermes model compare --task summarize --input-length 1000
11.2 技巧2:记忆压缩与归档策略
随着时间推移,Hermes 的记忆库会越来越庞大。如果不管理,检索会变慢,成本会增加。
# tips/memory_management.yaml
name: "memory_optimization"
description: "记忆压缩与归档策略"
# 自动归档
auto_archive:
enabled: true
# 归档规则
rules:
# 规则1:30 天前的会话记忆归档
- condition: "age > 30d AND access_count < 3"
action: "archive"
destination: "cold_storage"
# 规则2:90 天未访问的记忆归档
- condition: "last_access > 90d"
action: "archive"
destination: "cold_storage"
# 规则3:重复或冗余记忆合并
- condition: "similarity_to_other > 0.95"
action: "merge"
keep: "most_detailed"
# 记忆压缩
compression:
enabled: true
# 压缩策略
strategies:
# 摘要压缩
- type: "summarize"
# 长对话压缩为摘要
trigger: "conversation_length > 20"
model: "gpt-4o-mini"
# 向量化压缩
- type: "embedding"
# 用向量表示替代原始文本
trigger: "storage_size > 100MB"
model: "text-embedding-3-small"
# 分层存储
tiered_storage:
# 热存储:最近 7 天,内存中
hot:
retention: "7d"
storage: "memory"
max_size: "50MB"
# 温存储:7-90 天,本地 SQLite
warm:
retention: "90d"
storage: "sqlite"
path: "./memory/warm.db"
# 冷存储:90 天以上,压缩归档
cold:
storage: "file"
path: "./memory/archive/"
compression: "gzip"
# 需要时可以从冷存储恢复
recoverable: true
11.3 技巧3:技能链式调用
把多个 Skill 串联起来,形成更强大的复合能力。
# tips/skill_chaining.yaml
name: "skill_chain"
description: "技能链式调用示例"
# 链式工作流
chains:
# 链1:研究 -> 写作 -> 发布
research_to_publish:
name: "研究到发布"
steps:
- skill: "web_search"
output_var: "search_results"
- skill: "summarize"
input: "{{search_results}}"
output_var: "summary"
- skill: "write_article"
input: "{{summary}}"
params:
style: "blog"
output_var: "article"
- skill: "proofread"
input: "{{article}}"
output_var: "final_article"
- skill: "publish_to_wordpress"
input: "{{final_article}}"
# 链2:数据分析 -> 可视化 -> 报告
data_to_report:
name: "数据到报告"
steps:
- skill: "run_sql"
query: "SELECT * FROM sales WHERE date > NOW() - INTERVAL '30 days'"
output_var: "data"
- skill: "analyze_data"
input: "{{data}}"
output_var: "insights"
- skill: "generate_chart"
input: "{{data}}"
chart_type: "line"
output_var: "chart_path"
- skill: "generate_report"
data: "{{data}}"
insights: "{{insights}}"
charts: ["{{chart_path}}"]
output_var: "report"
# 条件分支
conditional_chains:
- name: "智能客服处理"
steps:
- skill: "intent_detect"
output_var: "intent"
- branch:
- condition: "intent == 'order_query'"
chain: "order_lookup_chain"
- condition: "intent == 'refund'"
chain: "refund_chain"
- condition: "intent == 'human'"
chain: "escalate_chain"
11.4 技巧4:并行任务加速
当多个任务之间没有依赖关系时,可以并行执行,大幅缩短总时间。
# tips/parallel_execution.yaml
name: "parallel_tasks"
description: "并行任务执行配置"
# 并行配置
parallel:
# 默认并行度
default_workers: 4
# 最大并发数
max_concurrent: 10
# 并行工作流示例
workflows:
# 同时收集多个数据源
multi_source_collection:
steps:
- parallel:
- skill: "fetch_hacker_news"
output_var: "hn_data"
- skill: "fetch_reddit"
output_var: "reddit_data"
- skill: "fetch_github"
output_var: "github_data"
- skill: "fetch_twitter"
output_var: "twitter_data"
- skill: "merge_data"
inputs:
- "{{hn_data}}"
- "{{reddit_data}}"
- "{{github_data}}"
- "{{twitter_data}}"
output_var: "all_data"
# 同时为多个平台生成内容
multi_platform_generation:
steps:
- skill: "select_topic"
output_var: "topic"
- parallel:
- skill: "write_for_wechat"
input: "{{topic}}"
output_var: "wechat_article"
- skill: "write_for_xiaohongshu"
input: "{{topic}}"
output_var: "xhs_article"
- skill: "write_for_douyin"
input: "{{topic}}"
output_var: "douyin_script"
- skill: "batch_publish"
articles:
wechat: "{{wechat_article}}"
xiaohongshu: "{{xhs_article}}"
douyin: "{{douyin_script}}"
# 批处理
batch_processing:
enabled: true
# 批量 API 调用(减少网络开销)
api_batch_size: 20
# 批处理超时
batch_timeout: 60
11.5 技巧5:自定义工具开发
Hermes 内置了 47 个工具,但你可能需要开发自己的工具。
# custom_tools/my_tool.py
# 自定义工具开发示例
from hermes.tools import Tool, ToolParameter
class MyCustomTool(Tool):
"""
自定义工具示例:汇率转换器
"""
name = "currency_converter"
description = "转换货币汇率"
parameters = [
ToolParameter(
name="amount",
type="number",
description="金额",
required=True
),
ToolParameter(
name="from_currency",
type="string",
description="源货币",
required=True
),
ToolParameter(
name="to_currency",
type="string",
description="目标货币",
required=True
)
]
async def execute(self, amount: float, from_currency: str, to_currency: str):
"""执行汇率转换"""
# 调用汇率 API
import aiohttp
url = f"https://api.exchangerate-api.com/v4/latest/{from_currency}"
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
data = await response.json()
rate = data["rates"][to_currency]
converted = amount * rate
return {
"original_amount": amount,
"original_currency": from_currency,
"converted_amount": round(converted, 2),
"target_currency": to_currency,
"rate": rate,
"date": data["date"]
}
# 注册工具
def register():
return [MyCustomTool]
工具注册配置
# config.yaml 中的工具注册
tools:
# 内置工具
builtin:
- "web_search"
- "file_read"
- "code_execution"
# 自定义工具
custom:
- path: "./custom_tools/my_tool.py"
enabled: true
- path: "./custom_tools/company_api.py"
enabled: true
# MCP 工具
mcp:
servers:
- command: "npx"
args: ["-y", "@modelcontextprotocol/server-filesystem", "./data"]
11.6 技巧6:Webhook 集成
Webhook 让外部系统能够主动通知 Hermes,是实现实时响应的关键。
# tips/webhook_integration.yaml
name: "webhook_setup"
description: "Webhook 集成配置"
# Hermes 作为 Webhook 接收端
incoming_webhooks:
# GitHub Webhook
github:
endpoint: "/webhook/github"
secret: "${GITHUB_WEBHOOK_SECRET}"
events:
- "pull_request"
- "issues"
- "push"
handlers:
pull_request:
action: "trigger_code_review"
issues:
action: "create_support_ticket"
# Stripe Webhook(支付事件)
stripe:
endpoint: "/webhook/stripe"
secret: "${STRIPE_WEBHOOK_SECRET}"
events:
- "payment_intent.succeeded"
- "invoice.payment_failed"
handlers:
payment_intent.succeeded:
action: "send_welcome_email"
invoice.payment_failed:
action: "notify_customer_and_retry"
# 自定义 Webhook
custom:
endpoint: "/webhook/custom"
auth:
type: "api_key"
header: "X-API-Key"
handlers:
default:
action: "process_custom_event"
# Hermes 作为 Webhook 发送端
outgoing_webhooks:
# 通知外部系统
notifications:
- name: "slack_notification"
url: "${SLACK_WEBHOOK_URL}"
events: ["task_completed", "alert_triggered"]
- name: "zapier_trigger"
url: "${ZAPIER_WEBHOOK_URL}"
events: ["new_lead", "order_created"]
11.7 技巧7:日志分析与调试
当 Hermes 出现问题时,日志是你最好的朋友。
# tips/logging_config.yaml
name: "advanced_logging"
description: "高级日志配置"
# 日志级别
logging:
# 全局级别
level: "INFO"
# 按模块设置
modules:
"hermes.agent": "DEBUG"
"hermes.memory": "DEBUG"
"hermes.tools": "INFO"
"hermes.sandbox": "WARNING"
# 输出格式
format: "json" # 或 "text"
# 输出目标
outputs:
- type: "console"
level: "INFO"
- type: "file"
path: "./logs/hermes.log"
level: "DEBUG"
rotation: "daily"
max_files: 30
- type: "file"
path: "./logs/hermes.error.log"
level: "ERROR"
rotation: "daily"
# 调试模式
debug:
# 显示详细的工具调用过程
show_tool_calls: true
# 显示 LLM 的完整输入输出
show_llm_io: false # 生产环境建议关闭,可能包含敏感信息
# 显示记忆检索过程
show_memory_retrieval: true
# 性能分析
profiling:
enabled: true
# 记录每个步骤的耗时
track_timing: true
# 慢操作阈值
slow_threshold_ms: 1000
常用调试命令
# 查看实时日志
$ hermes logs --follow
# 查看特定任务的日志
$ hermes logs --task-id abc123
# 查看错误日志
$ hermes logs --level ERROR --last 50
# 调试模式运行(显示详细信息)
$ hermes run --debug
# 性能分析
$ hermes profile --command "execute my_skill"
# 检查配置
$ hermes doctor
# 输出示例:
# ✓ Python version: 3.11
# ✓ Hermes version: 1.2.3
# ✓ Database connection: OK
# ✓ API Key (OpenAI): Valid
# ⚠ Memory usage: 85% (consider archiving)
# ✗ Sandbox Docker: Not running (docker service not found)
11.8 技巧8:性能监控与优化
# tips/performance_monitoring.yaml
name: "performance_monitor"
description: "性能监控与优化"
# 监控指标
metrics:
# 响应时间
response_time:
enabled: true
percentiles: [50, 95, 99]
# 吞吐量
throughput:
enabled: true
# 每秒请求数
rps: true
# 错误率
error_rate:
enabled: true
# 按类型分类
by_type: true
# 资源使用
resources:
cpu: true
memory: true
disk: true
network: true
# 告警
alerts:
- condition: "response_time_p95 > 5000"
message: "响应时间过高:{{value}}ms"
- condition: "error_rate > 5%"
message: "错误率过高:{{value}}%"
- condition: "memory_usage > 90%"
message: "内存使用率过高:{{value}}%"
# 自动优化
auto_optimization:
enabled: true
# 自动扩容
scaling:
enabled: true
# 并发过多时增加 worker
max_workers: 20
scale_up_threshold: 80 # CPU 使用率
scale_down_threshold: 20
# 缓存优化
caching:
enabled: true
# 自动缓存高频查询
auto_cache:
enabled: true
min_frequency: 3 # 3 次以上查询自动缓存
ttl: 3600
# 模型降级
model_fallback:
enabled: true
# 强模型超时时降级到快模型
timeout_threshold: 10000 # 10 秒
fallback_model: "gpt-4o-mini"
本章小结
恭喜你读完了第十二册!这一章的信息量非常大,让我们回顾一下你学到了什么。
沙箱配置与安全调优:
你学会了 Hermes 的四级安全沙箱体系,理解了如何为不同任务配置合适的安全等级。你掌握了命令审批机制的自定义方法,学会了设置信任级别和生产环境安全清单。最重要的是,你知道了如何安全地运行未知来源的代码——先用 analyze 静态分析,再用 Level 0 沙箱隔离执行。
语音交互高阶玩法:
你了解了多种 STT 和 TTS 引擎的选择策略,学会了配置语音活动检测(VAD)和唤醒词。你掌握了多语言语音切换的方法,理解了语音触发工作流的原理。你还学会了为车载和穿戴设备场景优化语音配置。纯语音驱动的投研助手案例,展示了"动口不动手"的 AI 交互体验。
六大实战案例:
-
AI 投研流水线:从多源数据收集到清洗、分析、报告生成和推送的完整自动化流程,每日成本仅 $0.1-0.5。
-
内容自动化工厂:选题 Agent、写作 Agent、审校 Agent 的多 Agent 协作系统,支持公众号、小红书、抖音的多平台内容自动生成。
-
代码质量守护者:Git Hook 集成、PR 自动审查、安全漏洞扫描、CI/CD 集成的完整 DevOps 方案。
-
个人知识管理系统:RSS/邮件/书签的自动收集、智能分类、知识图谱构建、与 Notion/Obsidian 的集成。
-
客服机器人:知识库构建、多轮对话管理、人机转接、满意度收集、多渠道部署的 7×24 智能客服方案。
-
数据监控与告警:网站可用性、价格变动、竞品动态、异常检测的监控体系,以及加密货币价格监控的完整 Telegram Bot 案例。
企业级应用场景:
你了解了企业内部知识库助手、数据库查询助手、项目管理自动化、会议纪要生成等企业级应用的配置方案。你掌握了企业安全与合规的核心考量,以及多用户共享实例的隔离配置。
八大高阶技巧:
模型热切换帮你节省成本,记忆压缩与归档保持系统轻量,技能链式调用构建复合能力,并行任务加速提升效率,自定义工具开发扩展边界,Webhook 集成实现实时响应,日志分析帮你快速排障,性能监控确保系统稳定。
下一步建议
本章的六个实战案例不需要一次性全部搭建。选择你最感兴趣或最急需的那个,从最小可用版本(MVP)开始,逐步迭代完善。记住,最好的自动化系统不是一次性设计出来的,而是在使用过程中不断打磨出来的。
如果你在搭建过程中遇到问题,第十五册「社区生态与资源」提供了丰富的社区支持渠道。记住:遇到困难不要独自纠结,社区里有很多热心的玩家愿意帮忙。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十三册:OpenClaw 对比与迁移
本章你将学到
- 为什么技术选型如此重要,以及如何用系统化的方法做决策
- Hermes 与 OpenClaw 在 12 个维度的深度对比(配详细分析)
- 两个项目最核心的差异:自学习 vs 手动配置、有界记忆 vs 模块化记忆
- 四个主流框架的官方定位和适用场景
- 详细的选型决策树,帮你找到最适合自己的工具
- 从 OpenClaw 迁移到 Hermes 的完整步骤和常见问题
- Hermes 与 OpenClaw 共存的最佳实践
预计阅读时间:90-120 分钟
特别提示:本章力求客观公正。Hermes 和 OpenClaw 都是优秀的开源项目,本章的目标是帮助你做出最适合自己的选择,而非贬低任何一方。
1. 为什么需要一章专门对比
1.1 "养虾"和"养马"的选择之困
在前面的章节里,我用了"养马"来比喻使用 Hermes——你需要了解它、训练它、照顾它,它才能成为你得力的伙伴。但如果你去社区里逛一圈,会发现有很多人还在"养虾"——用另一种同样优秀的 AI Agent 框架 OpenClaw。
这就带来了一个问题:我该养虾还是养马?
我见过太多人在这个选择上纠结不已: - 有人两个都装了,结果哪个都没学好 - 有人跟风选了热门的,后来发现不适合自己的工作流 - 有人死守一个拒绝尝试另一个,错过了更好的功能 - 还有人频繁切换,每次迁移都浪费大量时间
类比
选 AI Agent 框架就像选交通工具。OpenClaw 像是一辆配置丰富的 SUV——空间大、功能全、能装很多东西,但油耗也高。Hermes 像是一辆轻量级的电动跑车——启动快、操控灵活、充电便宜,但 cargo 空间没那么大。如果你要穿越荒野,SUV 更合适;如果你要在城市通勤,电动车更省心。没有绝对的好坏,只有适合不适合。
1.2 两个项目的社区规模与增长数据
在做选择之前,让我们先看看数据。
| 指标 | Hermes Agent | OpenClaw |
|---|---|---|
| GitHub Stars | 104,791(2026年4月) | 309,000+ |
| 首次发布 | 2026年2月 | 2025年11月 |
| Star 增长速度 | ~52k/月(前两个月) | ~26k/月(高峰期) |
| 贡献者数量 | 500+ | 2000+ |
| 社区 Discord 成员 | 45,000+ | 150,000+ |
| 月度活跃 issues | 800+ | 1200+ |
| 已发布版本 | v1.2.3 | v2.1.0 |
数据解读:
OpenClaw 的 Star 数遥遥领先,这是它一年多的积累。Hermes 虽然 Star 数暂时落后,但增长速度是 OpenClaw 峰值的两倍。这个增长速度说明社区对 Hermes 有很高的期待。
但 Star 数不是一切。很多 Star 是"收藏了准备以后看",不代表实际使用者。真正重要的是:哪个框架能更好地解决你的问题?
Tips
不要仅凭 GitHub Star 数做选择。Star 数反映的是"关注度",不是"好用度"。很多小而美的工具 Star 数不高,但在特定场景下比大项目更好用。建议你两个都试一周,亲身体验比任何数据都靠谱。
1.3 本章的客观立场声明
在正式对比之前,我需要声明本章的立场:
第一,我是 Hermes 白皮书的作者,但我首先是 AI Agent 领域的研究者。 我同时在使用 Hermes、OpenClaw、Claude Code 和其他工具。本章的对比基于实际使用体验和技术分析,而非商业利益。
第二,两个项目都有优秀的团队和活跃的社区。 OpenClaw 在 2025 年创造了 AI Agent 开源项目的 Star 增长纪录,它的社区贡献者和生态系统是 Hermes 需要追赶的。Hermes 在架构设计和创新功能上走出了自己的路,但它在社区成熟度上还有成长空间。
第三,大多数高级用户最终都会同时使用多个工具。 这不是"二选一"的选择题。就像摄影师不会只有一个镜头,高级 Agent 用户也不会只用一个框架。
注意
如果你在阅读本章时发现某个描述让你感觉"作者在贬低 OpenClaw"或"作者在夸大 Hermes",请告诉我。我承诺保持客观,如果有失偏颇,那一定是我的疏忽而非故意。
2. 项目背景对比
2.1 OpenClaw:独立开发者的杰作
创始人:Peter Steinberger
OpenClaw 的创始人 Peter Steinberger 是一位来自奥地利的独立开发者。在 AI Agent 领域爆发之前,他已经是 iOS 开发社区的知名人物——他创建的开源 PDF 库 PSPDFKit 被全球数万个应用使用。
Peter 在 2025 年初看到了 AI Agent 的潜力。他认为:"大语言模型已经足够聪明了,我们只需要给它配上合适的工具,它就能完成很多工作。"这个理念催生了 OpenClaw。
发布与成长
2025 年 11 月,OpenClaw 在 GitHub 上开源。最初的版本非常简洁——一个 TypeScript 项目,核心功能是让 AI 能够调用本地文件系统和命令行工具。但正是这种简洁,让它迅速获得了开发者的青睐。
OpenClaw 的爆火有几个关键因素: 1. 时机刚好:2025 年底是 AI Agent 概念最热的时候 2. 创始人影响力:Peter 在开发者社区有很高的声誉 3. 设计哲学清晰:Unix 哲学——一个工具做好一件事 4. TypeScript 生态:前端开发者最容易上手
到 2026 年初,OpenClaw 的 GitHub Star 数突破了 30 万,成为 GitHub 历史上增长最快的项目之一。
类比
Peter 和 OpenClaw 的故事,有点像 Linus Torvalds 和 Linux。一个技术极客,看到了行业的一个痛点,用简洁优雅的方案解决了它,然后整个社区就自发地围绕它建立起了生态。不同的是,Peter 是在 AI 时代做了一件类似的事。
2.2 Hermes:研究机构的专业之作
背后团队:Nous Research
Hermes 的背后是 Nous Research,这是一家在 AI 研究界颇有名气的机构。不同于 OpenClaw 的"个人项目"起点,Hermes 从诞生之初就带着"研究驱动"的基因。
Nous Research 在 2024-2025 年间完成了 6500 万美元的融资,投资方包括多家知名风投。这笔资金让他们能够组建一个全职的工程师和研究团队,专注于 Agent 架构的长期研发。
从 OpenClaw 到 Hermes 的演进
有趣的是,Nous Research 团队早期也是 OpenClaw 的活跃用户和贡献者。在使用过程中,他们发现了一些架构层面的局限性:
- 记忆管理不够灵活:OpenClaw 的记忆系统基于文件存储,在大规模使用时性能受限
- 技能系统是静态的:新技能需要手动编写,Agent 不会自己"学习"
- 配置复杂度:随着功能增加,配置文件变得越来越复杂
- TypeScript 的性能瓶颈:某些计算密集型任务在 Node.js 中表现不佳
这些观察促使 Nous Research 决定:不是给 OpenClaw 打补丁,而是重新设计一个 Agent 框架。2026 年 2 月,Hermes 诞生了。
注意
Hermes 不是 OpenClaw 的"竞争者",而是"进化者"。Nous Research 团队在很多场合都表达了对 Peter 和 OpenClaw 社区的尊重。两个项目的开源协议都是 MIT,代码和理念都在互相借鉴。开源社区的健康发展,需要这种"百花齐放"而非"你死我活"的氛围。
2.3 开源协议对比(MIT vs MIT)
两个项目都使用 MIT 许可证,这意味着: - 你可以自由地使用、修改、分发 - 可以用于商业用途 - 不需要开源你的衍生作品 - 只需要保留原始版权声明
MIT 许可证的核心条款
版权所有 (c) [年份] [作者]
特此免费授予任何人获得本软件及相关文档文件("软件")的副本,
不受限制地处理本软件,包括但不限于使用、复制、修改、合并、
发布、分发、再许可和/或销售软件副本的权利,并允许向其提供
软件的人这样做,但须符合以下条件:
上述版权声明和本许可声明应包含在本软件的所有副本或实质部分中。
Tips
MIT 是开源世界最宽松的许可证之一。对于商业用户来说,这意味着你可以放心地把 Hermes 或 OpenClaw 集成到你的产品中,不用担心法律风险。但记得保留版权声明——这是唯一的要求。
2.4 商业模式对比
虽然两个项目都是开源的,但它们的商业模式有所不同:
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 核心收入 | 个人捐赠、GitHub Sponsors | 研究机构资助、企业咨询 |
| 商业化路径 | 较慢,保持独立 | 可能更快,有投资人期待 |
| 企业服务 | 暂无官方服务 | 正在规划企业支持 |
| 生态盈利 | 社区自发 | 可能推出官方市场 |
OpenClaw 的商业模式
Peter 多次表示,OpenClaw 将保持独立和开源。目前的主要资金来源是: - GitHub Sponsors(个人捐赠) - 偶尔的咨询服务 - 社区贡献者的志愿工作
这种模式的好处是完全独立,不受资本影响。挑战是长期的可持续性——核心维护者需要吃饭。
Hermes 的商业模式
Nous Research 有 6500 万美元的融资,这意味着: - 团队可以全职投入开发 - 有更多的资源做长期研发(如自学习算法) - 但投资人最终期望回报
可能的商业化方向包括: - 企业版(高级安全、管理功能) - 托管服务(类似 GitHub 之于 Git) - 技能市场抽成
类比
OpenClaw 像是一家社区咖啡馆——老板用爱发电,靠常客的小费维持。Hermes 像是一家拿了风投的精品咖啡店——有更专业的团队、更好的装修,但未来可能需要推出会员制或周边产品来实现盈利。两家店都能做出好咖啡,选择哪家取决于你更看重什么。
3. 12 维度深度对比表
3.1 维度一:主语言/技术栈
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 主语言 | Python 93.6% | TypeScript 90.3% |
| 辅助语言 | Rust(性能模块) | JavaScript |
| 运行时 | Python 3.11+ | Node.js 20+ |
| 包管理 | pip/poetry | npm/yarn |
| 虚拟环境 | venv/conda | 无需 |
详细分析
Python 和 TypeScript 是当今最流行的两门语言,但它们的优势领域不同。
Python 的优势: - AI 生态无敌:PyTorch、TensorFlow、Transformers、NumPy、Pandas……几乎所有 AI 相关的库都是 Python 优先 - 数据处理能力:数据清洗、分析、可视化,Python 的工具链最成熟 - 科学计算:如果你需要做一些数值计算或机器学习,Python 是不二之选 - 脚本友好:写自动化脚本非常顺手,不需要编译
TypeScript 的优势: - 前端生态:如果你需要构建 Web UI 或浏览器扩展,TypeScript 更方便 - 类型系统:编译时类型检查能减少很多运行时错误 - 异步模型:Node.js 的异步 I/O 在处理大量并发连接时更高效 - 前端开发者上手快:如果你是前端工程师,OpenClaw 的学习曲线更平缓
对选择的影响:
如果你的团队主要是 Python 开发者,或者你需要做大量的数据处理、机器学习相关任务,Hermes 会更顺手。如果你的团队主要是前端/JavaScript 开发者,或者你需要构建复杂的 Web 界面,OpenClaw 可能更合适。
但这里有一个更深层的考量:生态系统的"重力"。Python 在 AI 领域的生态系统有一种"重力效应"——几乎所有新的 AI 论文都会附带 Python 实现,几乎所有新的模型都会先发布 Python 版本的 API。这意味着使用 Hermes,你能第一时间接入最新的 AI 能力。而 TypeScript 的优势更多体现在应用层和前端,如果你的 Agent 需要与用户进行复杂的界面交互,OpenClaw 的前端整合能力更强。
还有一个实际问题是招聘。如果你的团队需要扩充,Python AI 工程师的供给量明显大于 TypeScript AI 工程师。从团队长期发展的角度,这也是一个重要的考量因素。
Tips
不要太纠结于语言偏好。Hermes 和 OpenClaw 都是高级框架,你 90% 的时间是在写配置文件和提示词,而不是修改框架源码。但如果你计划深度定制或贡献代码,语言就很重要了。
一个折中的方案是:用 Hermes 做后端(数据处理、AI 逻辑),用 OpenClaw 或纯前端方案做界面。两个框架可以通过 API 互通,发挥各自的优势。
3.2 维度二:架构设计
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 架构风格 | 轻量 Python + SQLite | 重 Node.js Gateway + 分布式 |
| 核心组件 | 五层松耦合架构 | 模块化但耦合度较高 |
| 数据库 | SQLite(内置) | 文件系统 + 可选数据库 |
| 扩展方式 | Skill 插件 | Tool + Skill |
| 进程模型 | 单进程多线程 | 多进程/微服务 |
详细分析
Hermes 的五层架构
Hermes 采用了清晰的分层设计: 1. 接入层:处理不同平台的输入输出(微信、Telegram、Web 等) 2. 推理层:与 LLM 交互,负责决策和生成 3. 记忆层:三层记忆系统(会话、持久、Skill 级) 4. 技能层:Skill 的管理、创建、进化 5. 工具层:内置工具和 MCP 服务的调用
这种分层的好处是清晰——你知道每一层负责什么,调试时更容易定位问题。SQLite 作为内置数据库,意味着你不需要额外安装数据库就能使用持久记忆。
OpenClaw 的架构
OpenClaw 的核心是一个 Gateway(网关)模式。所有的输入(用户消息、文件、命令)都经过 Gateway,Gateway 决定调用哪些工具、如何组装上下文、如何输出结果。
OpenClaw 的架构更灵活——你可以替换任何组件。但这种灵活性也带来了复杂性:组件之间的接口没有严格的边界,深入定制时需要理解整个系统。
两种架构的适用场景
Hermes 的松耦合架构更适合: - 需要快速迭代的项目(修改一层不影响其他层) - 多人协作开发(清晰的边界减少冲突) - 长期维护的项目(分层清晰便于新人上手)
OpenClaw 的灵活架构更适合: - 需要深度定制的场景(每个组件都可以替换) - 实验性项目(快速尝试不同的组合) - 已有明确技术栈的团队(可以整合现有组件)
类比
Hermes 的架构像是一套精密的瑞士手表——每个齿轮都在固定的位置,运行稳定,维修时知道该拆哪部分。OpenClaw 的架构像是一套乐高积木——你可以搭出任何东西,但需要自己设计结构,搭错了可能整个倒塌。
如果你的目标是"准时看时间",手表更合适;如果你的目标是"搭一个独一无二的模型",乐高更合适。
3.3 维度三:学习能力
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 技能创建 | 自动创建(独特) | 需手动编写 |
| 技能进化 | 运行时自我优化 | 静态,需手动更新 |
| 用户画像 | 多维度用户建模 | 基础偏好存储 |
| 经验沉淀 | 跨会话 Skill 级记忆 | 会话级/文件级 |
| 学习触发 | 自动识别重复模式 | 用户手动触发 |
详细分析
这是两个项目最根本的差异之一。
Hermes 的自学习机制
Hermes 有一个完整的自学习闭环: 1. 模式识别:当你反复执行某类任务时,系统识别出模式 2. 主动提议:达到阈值后,Hermes 会问你"是否需要创建一个自动化技能?" 3. 自动生成:如果你同意,它会分析步骤、生成代码、注册技能 4. 持续优化:随着使用次数增加,Skill 会自动优化(简化步骤、修正错误)
这意味着 Hermes 越用越"懂"你。使用一个月后,它可能已经为你创建了 10 多个定制化技能。
OpenClaw 的学习方式
OpenClaw 的技能系统是"静态"的。你需要: 1. 手动编写技能代码(TypeScript) 2. 放入正确的目录 3. 在配置中注册 4. 手动更新和维护
OpenClaw 也有记忆功能,但主要是会话级的上下文管理。跨会话的经验沉淀需要开发者自己实现。
实际使用中的差异
想象一下你每周都要做一份周报。用 Hermes,做了三周后,它会自动问你"是否需要创建一个自动生成周报的技能?"如果你同意,第四周开始,你只需要说"生成周报",它就会自动完成数据收集、分析、格式化全过程。而且随着时间推移,它会越来越清楚你喜欢的报告格式、重点关注的数据指标、甚至你老板喜欢的汇报风格。
用 OpenClaw,你需要手动编写一个周报生成的 Skill。这给了你完全的控制权——你可以精确指定每一个步骤、每一个格式要求。但这也意味着,当你的需求变化时(比如老板换了、汇报格式变了),你需要手动修改代码。
哪种更适合你?
- 如果你的需求变化频繁,或者你自己也不完全清楚"最优流程"是什么,Hermes 的自学习更有优势
- 如果你的需求非常明确且稳定,或者你对自动化有极其精确的要求,OpenClaw 的手动配置更合适
- 如果你喜欢"惊喜"——发现 Agent 自己学会了你没想到的功能——选 Hermes
- 如果你喜欢"掌控"——每一行代码都在你的预期之内——选 OpenClaw
类比
Hermes 像一只聪明的边牧——你教它几次,它自己就能学会新把戏,还会琢磨怎么做得更好。OpenClaw 像一台精密的机器——你需要按照说明书组装和编程,它执行得非常精准,但不会自己"长出新功能"。
边牧可能会偶尔"自作主张"(比如自动创建了一个你不太满意的技能),机器则完全按照指令执行(但你得把所有指令都想清楚)。
3.4 维度四:记忆系统
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 架构 | 有界有机进化 | 模块化(SOUL/TOOLS/USER/Session) |
| 存储 | SQLite + FTS5 | 文件系统 |
| 检索 | 语义 + 关键词混合 | 关键词/文件名 |
| 上下文管理 | 按需检索 | 全量注入 |
| 跨会话记忆 | 原生支持 | 有限支持 |
详细分析
Hermes 的三层记忆
- 会话记忆(短期):当前对话的上下文,确保连贯性
- 持久记忆(中期):SQLite 数据库存储,支持全文检索
- Skill 级记忆(长期):跨会话的知识沉淀,直接优化 Skill 本身
Hermes 的按需检索是一个关键创新。它不会把所有记忆塞进 LLM 的上下文窗口,而是先分析任务需求,只检索最相关的片段。
OpenClaw 的记忆模块
OpenClaw 的记忆系统也是分层的,但实现方式不同: - SOUL:系统的核心记忆(类似系统提示词) - TOOLS:工具相关的记忆 - USER:用户特定的偏好 - Session:当前会话的上下文
OpenClaw 的记忆存储在文件系统中(通常是 JSON 或 Markdown 文件),而不是数据库中。这简化了部署,但在大量数据时的检索效率不如数据库方案。
存储方式对使用体验的影响
Hermes 使用 SQLite 数据库存储持久记忆,这带来了几个实际的好处: 1. 检索速度快:即使存储了几万条记忆,毫秒级就能找到相关内容 2. 支持复杂查询:可以按时间、类别、标签等多维度筛选 3. 数据完整性:数据库的事务机制保证数据不会损坏 4. 备份方便:单个文件,复制即可备份
OpenClaw 使用文件系统存储,优势在于: 1. 人类可读:你可以直接用文本编辑器打开记忆文件查看 2. 版本控制友好:记忆文件可以放入 Git 进行版本管理 3. 手动编辑:需要时可以直接修改记忆文件 4. 无依赖:不需要数据库引擎,部署更简单
实际案例对比
假设你使用 Agent 一年了,积累了 10,000 条记忆: - Hermes 的 SQLite 方案:检索响应时间 < 100ms,存储空间约 50MB - OpenClaw 的文件方案:检索可能需要遍历数百个文件,响应时间取决于文件数量和大小
当然,OpenClaw 社区也有开发者实现了基于向量数据库的记忆扩展,但这需要额外配置。
注意
记忆系统的"好坏"很大程度上取决于你的使用场景。如果你主要做短期任务(单次对话就能完成),两者的差异不大。但如果你需要 Agent 长期陪伴、积累对你的了解,Hermes 的记忆系统优势明显。
还有一个重要提醒:无论用哪种记忆系统,定期备份都是必须的。你的记忆数据是 Agent 最宝贵的资产——它记录了你们所有的互动和积累的知识。
3.5 维度五:工具生态
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 内置工具 | 47 个 | 4 个核心 |
| 社区工具 | 643 个(Skills Hub) | 13,700+ 个 |
| 工具哲学 | 功能丰富,开箱即用 | Unix 哲学,简洁核心 |
| MCP 支持 | 原生支持 | 社区适配 |
| 工具发现 | Skills Hub | 社区仓库 |
详细分析
Hermes 的工具策略
Hermes 内置了 47 个工具,覆盖七大类别:Web 与搜索、文件与数据、代码与开发、系统与运维、通信与消息、媒体与内容、金融与分析。这意味着你安装完 Hermes 就能完成很多任务,不需要额外配置。
此外,Hermes 原生支持 MCP(Model Context Protocol),可以接入 6000+ MCP 服务。
OpenClaw 的工具策略
OpenClaw 的核心只有 4 个工具:文件系统、命令行、Web 搜索、代码执行。但 OpenClaw 的社区贡献了 13,700+ 个扩展工具,这是目前最大的 Agent 工具生态。
OpenClaw 的哲学是 Unix 哲学——核心小而美,功能通过组合和扩展实现。
生态规模的实际意义
13,700+ 对比 643,这个差距看起来很大,但实际使用中需要考虑几个因素:
-
质量差异:OpenClaw 的社区工具数量庞大,但质量参差不齐。有些工具已经停止维护,有些文档不全。Hermes 的 Skills Hub 虽然数量少,但审核更严格,可用性更高。
-
核心覆盖度:Hermes 的 47 个内置工具已经覆盖了 90% 的常见需求(搜索、文件操作、代码执行、邮件、数据分析等)。除非你有非常特殊的需求,否则不需要额外安装工具。
-
MCP 的桥接作用:Hermes 原生支持 MCP 协议,可以接入 6000+ MCP 服务。这在很大程度上弥补了社区工具数量的差距。很多 OpenClaw 的工具已经有了对应的 MCP 版本。
-
开发成本:写一个新的 OpenClaw 工具需要 TypeScript 和 Node.js 知识。写一个新的 Hermes Skill 需要 Python 知识。选择哪个生态,取决于你的技术背景。
实际建议
- 如果你需要"立刻就能用"的丰富功能,Hermes 的内置工具 + MCP 生态已经足够
- 如果你需要某个非常小众的功能,OpenClaw 的社区生态找到现成工具的概率更高
- 如果你计划开发自己的工具并分享给社区,OpenClaw 的用户基数更大,潜在受众更多
- 如果你重视工具质量和文档完整性,Hermes 的审核机制更让人放心
类比
Hermes 像是一部功能齐全的智能手机,出厂就自带相机、地图、音乐播放器。OpenClaw 像是一台安装了应用商店的手机,出厂只有电话和短信,但应用商店里有 10 万+ App 可以下载。前者开箱即用,后者选择更多。
但如果你仔细看看,智能手机出厂自带的功能已经能满足 90% 的日常需求。应用商店里的 10 万+ App,你真正常用的可能不到 20 个。
3.6 维度六:平台支持
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 即时通讯 | Telegram、Discord、Slack | Telegram、Discord、Slack、Teams |
| 中国平台 | 微信、企业微信、飞书、钉钉 | 微信、飞书、钉钉 |
| 邮件 | 支持 | 支持 |
| Web | 支持 | 支持 |
| 移动应用 | 无 | iOS/Android 原生 |
| 总平台数 | 15+ | 26+ |
详细分析
OpenClaw 在平台支持上更胜一筹,尤其是它的原生移动应用。这意味着你可以直接在手机上与 Agent 交互,而不需要通过 Telegram 等第三方应用。
Hermes 目前没有原生移动应用,但可以通过以下方式在移动端使用: - Telegram Bot(手机上安装 Telegram) - 微信/企业微信/飞书机器人 - 手机浏览器访问 Web 界面 - 语音交互(配合手机语音输入)
Tips
如果你主要在手机上使用 Agent,OpenClaw 的原生应用体验确实更好。但如果你习惯用 Telegram 或微信,Hermes 的平台接入也完全够用。另外,Hermes 社区正在讨论开发移动应用的可能性——如果你对此感兴趣,可以去 GitHub 上关注相关 issue。
3.7 维度七:安全体系
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 沙箱 | 命令审批机制 | 分级沙箱(业界最佳) |
| 隔离级别 | 4 级(0-3) | 5 级 |
| 代码执行 | 需审批 | 严格沙箱 |
| 网络控制 | 白名单 | 完全隔离可选 |
| 安全审计 | 基础 | 详细日志 |
详细分析
这是 OpenClaw 的强项之一。OpenClaw 的分级沙箱被认为是 AI Agent 领域最完善的安全方案。
OpenClaw 的沙箱特点: - 使用 Docker 容器隔离 - 网络可以完全断开 - 文件系统访问精确控制 - 详细的执行日志和审计
Hermes 的安全方案: - 也有多级沙箱,但实现相对简单 - 命令审批机制是主要安全手段 - 对于生产环境,建议配合外部安全工具使用
企业用户的安全考量
安全是企业用户最关心的问题之一。OpenClaw 的沙箱系统确实更成熟,这体现在几个方面: 1. 更细粒度的权限控制:可以精确控制网络访问、文件系统访问、环境变量 2. 更完善的审计日志:每一次命令执行都有详细记录 3. 更严格的默认配置:默认情况下,危险操作是被禁止的 4. 社区安全实践更丰富:有大量企业用户分享的安全配置
但这不意味着 Hermes 不安全。Hermes 的安全策略是"审批驱动"——所有敏感操作都需要人工确认。这种策略在某些场景下反而更实用: - 对于个人用户,审批机制简单直观 - 对于小型团队,不需要复杂的安全配置就能保障基本安全 - 对于开发环境,审批机制比沙箱更灵活
安全配置的投入成本
OpenClaw 的安全功能强大,但配置也更复杂。你需要: - 理解沙箱的 5 个安全级别 - 配置 Docker 环境 - 设置网络白名单/黑名单 - 配置审计日志存储
Hermes 的安全配置更简单: - 设置审批规则(正则表达式匹配) - 配置通知渠道 - 选择沙箱级别
对于安全团队资源有限的小型组织,Hermes 的简单方案可能更实际。
注意
如果你要在生产环境中让 Agent 执行系统命令或访问敏感数据,OpenClaw 的安全体系更成熟。Hermes 的安全功能在快速发展中,但如果你是安全敏感型用户(比如金融机构),建议额外配置安全层或等待 Hermes 的安全功能进一步完善。
但无论选择哪个框架,以下安全原则是通用的: 1. 永远不要让 Agent 在无审批的情况下执行
rm -rf或类似命令 2. API Key 和凭证不要写在代码里,用环境变量管理 3. 定期审查 Agent 的执行日志 4. 给 Agent 最小必要的权限,遵循最小权限原则
3.8 维度八:移动应用
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| iOS 应用 | 无 | 有(原生) |
| Android 应用 | 无 | 有(原生) |
| 移动端体验 | 依赖第三方 IM | 原生体验 |
| 离线能力 | 无 | 部分支持 |
| 推送通知 | 依赖 IM | 原生推送 |
详细分析
OpenClaw 的原生移动应用是一个明显的差异化优势。这意味着: - 启动速度更快(不需要打开 Telegram 再找到 Bot) - 可以原生访问手机功能(相册、定位、通知) - 更好的离线支持 - 更流畅的交互体验
Hermes 用户目前的移动端体验主要依赖: - Telegram Bot(全球通用,但国内需要翻墙) - 微信/企业微信/飞书机器人(国内用户友好) - Web 界面(响应式设计,但不如原生 App 流畅)
移动端使用场景的实际影响
让我们坦诚地说:移动端体验确实是 OpenClaw 的一个明显优势。原生应用带来的流畅度、推送通知的及时性、离线能力,都是第三方 IM 机器人难以比拟的。
但这里也有几个实际的考量:
-
使用频率:你真的需要在手机上"深度使用" Agent 吗?大多数用户的核心使用场景是在电脑上(编程、写作、数据分析)。手机更多是"查看通知"和"简单查询"。
-
Telegram 的替代方案:对于国内用户,微信/企业微信/飞书机器人提供了非常好的移动端体验。你可以在微信里直接@机器人、发语音、收推送,体验并不差。
-
PWA 的可能性:Hermes 可以打包为 PWA,添加到手机主屏幕后,体验接近原生应用。这是一个成本较低的移动化方案。
-
语音交互:第十二章介绍的语音交互配置,可以让 Hermes 在手机上通过语音控制,这在某些场景下甚至比打字更方便。
常见问题
Q:Hermes 会推出移动应用吗?
A: 社区中有相关讨论,但目前没有官方时间表。考虑到 Hermes 是 Python 后端,如果要开发原生移动应用,可能需要: 1. 开发 iOS/Android 客户端(Flutter/React Native) 2. 或者开发 PWA(渐进式 Web 应用) 3. 或者与现有的移动框架集成 如果你对此有需求,建议在 Hermes 的 GitHub 上投票支持相关 issue。
Q:没有原生应用,会不会影响日常使用?
A: 取决于你的使用习惯。如果你主要在电脑前工作,影响很小。如果你希望随时随地与 Agent 深度交互,OpenClaw 的原生应用确实更好。但也请考虑:在手机上完成复杂任务本身就不是一个理想的体验,无论有没有原生应用。
3.9 维度九:模型支持
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| OpenAI | GPT-4o, GPT-4o-mini, o1 | GPT-4o, GPT-4o-mini, o1 |
| Anthropic | Claude 3.5 Sonnet, Opus | Claude 3.5 Sonnet, Opus |
| 本地模型 | Llama, Qwen, DeepSeek 等 | Llama, Qwen, DeepSeek 等 |
| Gemini | Gemini | |
| 总提供者 | 18+ | 多提供者 |
详细分析
两个项目在模型支持上大同小异,都支持主流的大模型提供商。差异主要在于:
Hermes 的特点: - 对本地模型的支持更友好(Python 生态更适合部署本地模型) - 模型路由功能更灵活(可以按任务类型自动切换模型) - 与 Hugging Face 等 Python 生态的整合更紧密
OpenClaw 的特点: - 与某些商业模型提供商的合作更深入 - 模型配置更标准化 - 对 OpenAI API 的某些高级功能(如 Assistants API)支持更好
本地模型部署的考量
如果你计划使用本地模型(如 Llama、Qwen、DeepSeek),Hermes 有明显优势:
- Python 的 transformers、llama.cpp 等库让本地部署极其简单
- 可以直接在 Hermes 中调用本地的 Python 模型服务
- 量化和推理优化的工具链更成熟
OpenClaw 也可以接入本地模型,但通常需要通过额外的服务层(如 Ollama 或 LM Studio),配置相对复杂。
模型成本优化的实际建议
无论你选择哪个框架,模型成本都是最大的开销。以下是一些通用的省钱策略: 1. 简单任务用便宜模型:摘要、分类用 GPT-4o-mini 或 Claude Haiku 2. 复杂任务再用强模型:分析、推理、创意写作用 GPT-4o 或 Claude Sonnet 3. 缓存重复查询:相同的问题直接返回缓存结果 4. 限制上下文长度:只发送必要的上下文,减少 token 消耗 5. 考虑本地模型:如果有 GPU,70B 级别的本地模型能力已经接近 GPT-4o-mini
Tips
模型支持不是选框架的决定性因素。两个框架支持的模型 90% 是重叠的。更重要的是:框架如何利用模型?比如 Hermes 的按需检索机制可以更有效地利用模型的上下文窗口,而 OpenClaw 的全量注入在上下文较短时更直接。
建议你先用同一个模型(如 GPT-4o-mini)在两个框架上测试同样的任务,看看哪个框架的输出质量更高、响应更快。实践出真知。
3.10 维度十:部署方式
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 一键安装 | curl 脚本 |
npm install |
| Docker | 官方镜像 | 官方镜像 |
| 本地部署 | 简单 | 简单 |
| VPS 部署 | 推荐 | 推荐 |
| 无服务器 | 支持(实验性) | 有限支持 |
| 安装复杂度 | 低 | 低 |
详细分析
Hermes 的部署
# 一键安装(curl)
curl -fsSL https://hermesagent.io/install.sh | bash
# Docker
docker run -d --name hermes nousresearch/hermes:latest
# Python 包
pip install hermes-agent
OpenClaw 的部署
# npm 安装
npm install -g openclaw
# Docker
docker run -d --name openclaw openclaw/openclaw:latest
# 从源码
git clone https://github.com/peter/openclaw.git
cd openclaw && npm install && npm run build
两个项目的部署都很简单。Hermes 的 curl 一键安装对新手最友好,OpenClaw 的 npm 安装对前端开发者更顺手。
部署后的配置复杂度
虽然初始安装都很简单,但配置阶段的复杂度有所不同:
Hermes 的配置相对集中:
- 一个主配置文件 config.yaml
- 环境变量管理 API Key
- 大部分常用功能开箱即用
OpenClaw 的配置更分散: - 多个配置文件(系统配置、工具配置、记忆配置等) - 需要手动选择和配置工具 - 某些高级功能需要额外的服务(如向量数据库)
首次运行体验
对于完全没有经验的新用户:
- Hermes:安装完运行 hermes chat,输入消息就能对话。不需要额外配置就能使用基本功能。
- OpenClaw:安装完需要配置模型提供商、选择工具、设置系统提示词,然后才能开始对话。
这意味着 Hermes 的"Hello World"路径更短,新手能更快获得成就感。
类比
部署就像搬家。Hermes 提供了一站式搬家服务——你打个电话,他们就来打包、搬运、安置,家具都摆好了,床单也铺好了,你直接就能睡。OpenClaw 提供了详细的搬家指南——步骤清晰,但需要你自己动手组装家具、铺床单。
两种方式最终都能把家搬好,但前者让你第一天就能睡个好觉,后者可能需要你忙到半夜。
3.11 维度十一:成本
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| 框架本身 | 免费(MIT) | 免费(MIT) |
| API 调用 | 按量付费(给 OpenAI 等) | 按量付费 |
| 本地模型 | 仅电费 | 仅电费 |
| 托管服务 | 暂无官方服务 | 暂无官方服务 |
| 典型月费 | $5-50(取决于使用量) | $5-50 |
详细分析
两个框架本身都是免费的。真正的成本来自 API 调用。
省钱策略(两个框架通用):
- 使用本地模型:如果你有 GPU,可以运行 Llama 3 或 Qwen 本地模型,API 成本为零
- 模型降级:简单任务用 GPT-4o-mini 而不是 GPT-4o
- 缓存响应:相同的问题直接返回缓存结果
- 限制上下文长度:只发送必要的上下文,减少 token 消耗
两个框架的成本差异
虽然 API 调用成本与框架无关,但框架的设计会影响你的实际支出:
Hermes 的按需检索机制可以帮你省钱: - 不会把所有记忆塞进上下文,减少不必要的 token 消耗 - 模型路由自动选择便宜模型处理简单任务 - 缓存机制更完善
OpenClaw 的全量注入可能增加成本: - 每次对话都会注入大量系统提示词和记忆 - 没有自动模型降级功能 - 但可以通过配置优化来减少开销
实际成本案例
假设你每天使用 Agent 4 小时,处理约 100 个任务: - 方案 A(全云端 GPT-4o):每月约 $80-120 - 方案 B(云端 + 本地混合):每月约 $30-50 - 方案 C(全本地 70B 模型):每月约 $5-10(电费)
框架选择对成本的影响大约是 10-20%,主要取决于框架的上下文管理和缓存效率。
Tips
如果你每月的 API 费用超过 $100,建议认真考虑本地模型方案。一台 RTX 4090 可以流畅运行 70B 级别的模型,虽然不如 GPT-4o 聪明,但对于大多数任务已经足够。硬件的一次性投入(约 $2000)在一年内就能回本。
另一个省钱技巧:Hermes 和 OpenClaw 都支持设置每日预算上限。建议新手设置一个 $5/天的上限,避免因为配置错误或无限循环导致账单爆炸。
3.12 维度十二:社区规模
| 项目 | Hermes Agent | OpenClaw |
|---|---|---|
| GitHub Stars | 104,791 | 309,000+ |
| Discord 成员 | 45,000+ | 150,000+ |
| 贡献者 | 500+ | 2000+ |
| 第三方工具 | 643 | 13,700+ |
| 中文社区 | 快速发展中 | 较大但分散 |
| 文档完善度 | 中(快速发展中) | 高 |
详细分析
OpenClaw 的社区规模目前遥遥领先。13,700+ 的第三方工具意味着你几乎可以找到任何功能的扩展。
但 Hermes 的社区增长非常快。考虑到它才发布两个月,104k Stars 和 45k Discord 成员已经是惊人的成绩。
社区质量的深层分析
数量不等于质量。让我们从几个维度看社区的实际价值:
文档和学习资源 - OpenClaw:英文文档非常完善,但中文资料分散且质量不一 - Hermes:英文文档在快速完善中,中文资源明显更丰富(本书就是一个例子)
问题响应速度 - OpenClaw:Discord 上提问,通常几小时内有人回复(但需要用英文) - Hermes:Discord 响应也很快,中文微信群内的响应更及时
第三方生态 - OpenClaw:13,700+ 工具,但质量参差不齐,很多已停止维护 - Hermes:643 个工具 + 6000+ MCP 服务,审核更严格,可用性更高
贡献门槛 - OpenClaw:需要 TypeScript 能力,核心代码较复杂 - Hermes:Python 门槛较低,Skill 开发更简单
中文社区现状:
- OpenClaw:中文用户不少,但分散在各个微信群和论坛,缺乏统一的社区平台
- Hermes:中文社区正在快速发展,有多个活跃的微信群和知识星球
对于中文用户来说,社区语言是一个非常重要的考量因素。阅读英文文档、在英文社区提问,对很多中文用户来说是巨大的门槛。Hermes 在中文内容方面的投入,让中文用户的学习曲线明显更平缓。
类比
OpenClaw 的社区像一座繁华的大都市——人多、设施全、应有尽有,但新人可能感到迷茫,而且大家主要说外语。Hermes 的社区像一座快速发展的卫星城——人没有那么多,但增长迅速,社区氛围更紧密,你更容易认识核心成员,而且大家都说中文。
4. 核心差异深度分析
4.1 自学习 vs 手动配置:这是最根本的差异
前面在 12 维度对比中,我们提到了学习能力的差异。这里我想更深入地分析这个差异对实际使用的影响。
自学习的好处: - 使用一个月后,Hermes 可能已经为你创建了 10+ 定制化技能 - 不需要写代码,只需要"正常用",系统自己学习 - Skill 会随着使用自动优化
自学习的局限: - 学习的质量取决于你的使用模式是否清晰 - 自动生成的 Skill 可能需要人工审核和调整 - 学习过程需要一定时间的"训练期"
手动配置的好处: - 完全可控,你知道每个 Skill 在做什么 - 可以精确调整每个参数 - 适合有明确需求、喜欢 DIY 的用户
手动配置的局限: - 需要写代码(TypeScript) - 维护成本高(需求变了要手动改) - 不容易发现"可以自动化"的机会
更深层的思考:两种哲学的工作流差异
使用 Hermes 一个月后的典型工作流: 1. 第 1 周:手动执行各种任务,Agent 在旁观察学习 2. 第 2 周:Agent 开始提醒你"这个任务我之前见过,需要我自动完成吗?" 3. 第 3 周:几个高频任务已经自动化,你只需要说"执行周报流程" 4. 第 4 周:Agent 比你更清楚你的习惯,主动提议优化方案
使用 OpenClaw 一个月后的典型工作流: 1. 第 1 周:研究文档,编写第一个 Skill 2. 第 2 周:调试和完善 Skill,处理各种边界情况 3. 第 3 周:编写更多 Skill,建立完整的工具链 4. 第 4 周:维护已有 Skill,根据新需求修改代码
两种工作流没有绝对的好坏。Hermes 适合"渐进式自动化"——你不需要提前规划所有自动化场景,Agent 会帮你发现。OpenClaw 适合"设计式自动化"——你需要先想清楚流程,然后精确实现。
类比
自学习像是一个自动整理房间的机器人——你用几天,它就知道你的习惯,自动把东西放到对的位置。手动配置像是一个按需呼叫的管家——你每次都要告诉他"把书放到书架上",但他每次都执行得很精确。前者省心但可能偶尔出错,后者精确但需要持续投入精力。
还有一个关键区别:机器人偶尔会"自作主张"把东西放到它认为对的地方(但你可能不同意),而管家完全按照你的指令执行(但你需要每次都给出指令)。
4.2 有界记忆 vs 模块化记忆:设计哲学的不同
两个项目的记忆系统设计反映了不同的哲学取向。
Hermes 的"有界有机进化"
Hermes 的记忆系统有一个核心概念——"有界"(Bounded)。这意味着: - 记忆不是无限增长的,而是有选择地保留 - 系统会定期清理低价值的记忆 - 重要的记忆会被"强化",形成长期知识 - 记忆之间会建立关联,形成知识网络
这种设计的好处是系统不会随着使用变得越来越臃肿。缺点是偶尔可能会"遗忘"一些你认为重要的东西。
OpenClaw 的"模块化记忆"
OpenClaw 的记忆系统是模块化的,你可以: - 为不同的任务创建不同的记忆模块 - 手动管理记忆文件 - 精确控制哪些内容进入记忆
这种设计的好处是可控性高。缺点是如果管理不善,记忆文件会越来越多,检索效率下降。
4.3 Python vs TypeScript:生态选择的影响
这个差异不只是"喜欢哪种语言",它影响了两个项目的方方面面。
Python 生态的影响(Hermes): - AI/ML 库丰富,容易集成新的 AI 能力 - 数据处理能力强,适合分析型任务 - 科学计算生态成熟 - 但前端/UI 能力相对弱
TypeScript 生态的影响(OpenClaw): - 前端/UI 能力强,容易构建漂亮的界面 - npm 生态庞大,工具丰富 - 类型系统减少运行时错误 - 但 AI/ML 库不如 Python 丰富
4.4 轻量 vs 全能:两种架构路线
Hermes 的"轻量路线"
Hermes 追求"够用就好": - 核心功能内置,开箱即用 - 不需要额外配置数据库 - 单个进程就能运行 - 资源占用少
适合:个人用户、小型团队、快速原型
OpenClaw 的"全能路线"
OpenClaw 追求"无所不能": - 核心简洁,功能通过扩展实现 - 支持微服务架构 - 企业级功能更完善 - 生态更丰富
适合:企业用户、大型团队、复杂场景
4.5 Harness Engineering vs Unix Philosophy
两个项目代表了两种不同的工程哲学。
Hermes:Harness Engineering(驾驭工程)
Hermes 的设计理念是:Agent 是一个需要"驾驭"的存在。你要培养它、训练它、与它建立信任关系。它的自学习、用户画像、记忆进化,都是为了让 Agent 成为"你的" Agent——独特、个性化、越用越顺手。
OpenClaw:Unix Philosophy(Unix 哲学)
OpenClaw 的设计理念是:一个工具做好一件事,然后通过组合实现复杂功能。它的核心很小,但每个组件都可以被替换、扩展、组合。这种哲学在软件工程界有深厚的传统,也是 Linux 成功的秘诀之一。
Tips
没有哪种哲学绝对更好。如果你喜欢"养成"的感觉,享受和 Agent 一起成长的过程,Hermes 更适合你。如果你喜欢"组装"的感觉,享受搭建和定制系统的乐趣,OpenClaw 更适合你。
5. 社区对比
5.1 官方定位:四个工具,四种角色
要理解 Hermes 和 OpenClaw 的差异,我们需要把它们放在更大的工具图景中来看。
| 工具 | 官方定位 | 核心场景 | 使用方式 |
|---|---|---|---|
| Claude Code | 仓库内编码代理 | 在代码仓库内辅助编程 | 命令行,IDE 集成 |
| Cursor | 编辑器内双人程序员 | 在编辑器里写代码 | IDE 插件 |
| OpenClaw | 配置驱动的任务运行器 | 自动化执行各种任务 | 配置文件驱动 |
| Hermes | 自我提升的自主代理 | 长期陪伴,持续进化 | 对话+自动学习 |
Claude Code 是 Anthropic 推出的工具,它直接集成在你的代码仓库中,可以读取文件、执行命令、修改代码。它的定位非常聚焦——编程辅助。
Cursor 是一款 AI 编辑器,它在 VS Code 的基础上深度集成了 AI 功能。你可以把它理解为"有一个 GPT-4 住在你的编辑器里"。
OpenClaw 的定位是"任务运行器"——你配置好规则和工具,它按照你的配置执行任务。它是"配置驱动"的。
Hermes 的定位是"自主代理"——你不只是在"用它",而是在"养它"。它会学习、进化、变得越来越懂你。
类比
如果把 AI 工具比作交通工具:Claude Code 是工地上的挖掘机——专业、强大,但只在工地上用。Cursor 是轿车里的导航——随时可用,帮你指路。OpenClaw 是货车——能拉很多货,但你需要自己装卸。Hermes 是马——能载你走很远,但需要培养和信任。
5.2 社区文化差异
OpenClaw 社区文化
- DIY 精神:社区鼓励自己动手,分享定制配置
- 工具导向:讨论集中在"怎么实现某个功能"
- 国际化:英文为主,全球开发者参与
- 极客氛围:技术讨论深入,新手可能感到门槛高
Hermes 社区文化
- 成长导向:讨论更多关于"怎么让 Agent 更聪明"
- 应用导向:更关注"Agent 能帮我做什么"
- 中文活跃:中文用户比例相对较高
- 包容性:对非技术背景的用户更友好
5.3 中文社区活跃度对比
| 维度 | Hermes | OpenClaw |
|---|---|---|
| 微信群数量 | 10+ | 20+ |
| 中文文档 | 完善(本书就是) | 分散,不完善 |
| 中文视频教程 | 鲲鹏Talk 等持续产出 | 较少 |
| 中文论坛 | 正在建设中 | 无统一平台 |
| 企业用户群 | 快速增长 | 较多 |
Hermes 在中文内容方面有明显的优势——本书的存在就是一个证明。对于中文用户来说,这是选择 Hermes 的一个重要因素。
5.4 社区贡献模式对比
OpenClaw 的贡献模式
- 核心代码由 Peter 和核心团队维护
- 社区贡献主要是工具和扩展
- 贡献门槛较高(需要理解核心架构)
- 但贡献者数量庞大
Hermes 的贡献模式
- Nous Research 团队全职开发
- 社区贡献包括技能、文档、教程
- 技能系统的门槛较低(Python 写几行代码即可)
- 贡献者数量在快速增长
5.5 大多数高级用户同时使用 Hermes + Claude Code(叠加而非竞争)
这是一个非常重要的观察:高级用户很少只用一个工具。
典型的"高级玩家工具栈": - Claude Code:在代码仓库里写代码、改代码 - Hermes:日常任务自动化、信息收集、内容管理 - OpenClaw:某些特定场景的深度定制 - Cursor:日常编码(如果不用 Claude Code)
这些工具不是竞争关系,而是互补关系。每个工具都有其最适合的场景,高级用户会根据任务选择最合适的工具。
Tips
如果你刚入门,不要试图同时学多个工具。先选一个专注学好。等你能熟练使用后,再根据需要添加其他工具。我见过太多人同时装了三四个工具,结果哪个都没学会。
6. 选型决策指南
6.1 场景化推荐(详细的决策树)
下面是一棵决策树,帮你快速定位最适合你的工具。
第一层:你的编程背景
你是程序员吗?
├── 是 -> 继续第二层
└── 不是 -> 推荐 Hermes(更友好)
第二层:你的主要语言
你主要用什么语言?
├── Python -> 推荐 Hermes
├── TypeScript/JavaScript -> 推荐 OpenClaw
├── 其他 -> 继续第三层
第三层:你的核心需求
你最看重什么?
├── 开箱即用,不想配置 -> 推荐 Hermes
├── 深度定制,喜欢 DIY -> 推荐 OpenClaw
├── 移动端使用 -> 推荐 OpenClaw
├── 长期陪伴,越用越聪明 -> 推荐 Hermes
├── 企业级安全 -> 推荐 OpenClaw(目前)
└── 中文支持和文档 -> 推荐 Hermes
详细场景推荐
| 场景 | 推荐 | 理由 |
|---|---|---|
| 学生/个人开发者 | Hermes | 学习成本低,中文文档丰富,自学习减少维护 |
| 企业/团队 | OpenClaw | 安全体系更成熟,生态更丰富,企业级功能完善 |
| 需要移动应用 | OpenClaw | 原生 iOS/Android 应用 |
| 追求效率部署 | Hermes | curl 一键安装,开箱即用 |
| 长期养成助手 | Hermes | 自学习、用户画像、Skill 进化 |
| 已有大量 OpenClaw 配置 | 可迁移到 Hermes | hermes migrate 命令支持 |
| 数据科学家 | Hermes | Python 生态,数据处理能力强 |
| 前端开发者 | OpenClaw | TypeScript 生态,上手更快 |
| 安全敏感型 | OpenClaw | 沙箱安全体系更完善 |
| 非技术用户 | Hermes | 配置更简单,中文支持好 |
| 需要快速原型验证 | Hermes | 内置工具多,MCP 生态丰富 |
| 需要深度定制 | OpenClaw | 模块化架构,可替换任何组件 |
| 预算极其有限 | Hermes | 本地模型支持更好,省去 API 费用 |
| 追求社区活跃度 | OpenClaw | 社区更大,第三方工具更多 |
| 中文环境为主 | Hermes | 中文文档、中文社区、国内平台支持更好 |
决策的灵活性
请记住,这个推荐表不是一成不变的。两个项目都在快速发展: - Hermes 正在加强企业级功能和安全体系 - OpenClaw 正在改进记忆系统和配置体验 - 六个月后的推荐可能与今天不同
所以,不要把这个表格当作"终身判决"。把它当作"当前时间点的参考",并随着项目的发展保持关注。
6.2 不同预算下的选择
预算:$0/月(完全免费)
- 使用本地模型(Llama 3、Qwen、DeepSeek)
- Hermes 和 OpenClaw 都可以,但 Hermes 对本地模型支持更友好
- 需要一台性能较好的电脑(至少 16GB 内存,推荐有 GPU)
预算:$5-20/月
- 使用 GPT-4o-mini 或 Claude Haiku
- 两个框架都可以,成本差异不大
- 建议根据其他因素选择
预算:$20-100/月
- 可以使用 GPT-4o、Claude Sonnet
- 两个框架都可以
- 如果追求性价比,Hermes 的模型路由可以帮你自动降级简单任务
预算:$100+/月
- 可以使用最强模型(GPT-4o、Claude Opus、o1)
- 两个框架都可以
- 考虑是否需要多个框架组合使用
- 可以承受一定的"试错成本",建议两个都深度体验
成本与价值的平衡思考
很多用户过于关注"哪个更便宜",而忽略了"哪个能创造更多价值"。一个能帮你每天节省 2 小时的 Agent,即使每月花费 $50,也是极其划算的投资。相比之下,一个免费的 Agent 如果每天都要花你 1 小时去调试和维护,反而更"贵"。
建议的决策方式是: 1. 先估算 Agent 能为你节省多少时间/创造多少价值 2. 根据这个价值设定合理的预算 3. 在预算范围内选择功能最适合的框架 4. 定期评估 ROI(投入产出比)
6.3 不同技术背景下的选择
完全不懂编程
推荐 Hermes。 - 配置更简单,不需要写代码 - 中文文档更完善 - 自学习减少你需要手动做的事 - 可以从本书的保姆级教程开始
对于非技术用户,最大的障碍往往不是"功能不够",而是"不知道怎么开始"。Hermes 的 curl 一键安装、开箱即用的设计、以及本书这种保姆级教程,能最大程度降低入门门槛。
会一点 Python
强烈推荐 Hermes。 - 你可以写自己的 Skill - 可以接入 Python 的数据分析生态 - 可以修改和扩展核心功能
即使你只是会写简单的 Python 脚本,也足以开发有用的 Hermes Skill。相比之下,要为 OpenClaw 写扩展,你需要了解 Node.js 的异步模型、TypeScript 的类型系统,学习曲线更陡。
前端开发者(TypeScript/JavaScript)
推荐 OpenClaw。 - 语言和生态完全匹配 - 可以写自己的工具和扩展 - 可以基于 OpenClaw 构建 Web 应用
前端开发者使用 OpenClaw 时,可以利用自己熟悉的技术栈快速定制。而且 OpenClaw 的 Gateway 架构与前端微服务的理念很相似,思维方式匹配度高。
全栈开发者
两个都可以,建议: - 如果偏向后端/数据:Hermes - 如果偏向前端/UI:OpenClaw - 或者两个都用(不同场景)
全栈开发者其实是最幸福的——你不需要做选择,可以根据场景自由切换。后端数据处理用 Hermes,前端界面集成用 OpenClaw,两者通过 API 互通。
AI/ML 工程师
推荐 Hermes。 - Python 生态与你的工作流完全匹配 - 更容易集成自己的模型 - 数据处理和分析能力更强
AI/ML 工程师通常已经熟悉 PyTorch、Hugging Face、LangChain 等 Python 生态。Hermes 可以让你无缝地将这些能力整合到 Agent 中。比如,你可以写一个 Skill 来调用你自己的微调模型,或者集成一个新的论文中的算法。
7. 从 OpenClaw 迁移到 Hermes
7.1 迁移前评估清单
在决定迁移之前,先评估一下你的现状:
# OpenClaw 迁移评估清单
## 当前使用情况
- [ ] 我有多少个自定义 Skill?
- [ ] 我有多少个自定义 Tool?
- [ ] 我修改过 OpenClaw 的核心代码吗?
- [ ] 我使用了哪些平台集成?
- [ ] 我的配置文件有多大/多复杂?
## 数据评估
- [ ] 我有多少历史对话记录需要保留?
- [ ] 我的记忆文件有多大?
- [ ] 是否有重要的自定义数据格式?
## 依赖评估
- [ ] 我使用了哪些 OpenClaw 特有的第三方扩展?
- [ ] 这些扩展在 Hermes 中有对应替代吗?
- [ ] 我的工作流是否依赖 OpenClaw 的特定行为?
## 时间评估
- [ ] 我有多少时间可以投入迁移?
- [ ] 迁移期间是否可以接受服务中断?
- [ ] 我是否需要并行运行两个系统一段时间?
7.2 hermes migrate openclaw 命令详解
Hermes 提供了官方的迁移工具,可以自动迁移大部分内容。
# 查看迁移工具帮助
$ hermes migrate --help
# 预览迁移内容(不实际执行)
$ hermes migrate openclaw --preview --source ~/.openclaw
# 执行迁移
$ hermes migrate openclaw \
--source ~/.openclaw \
--target ~/.hermes \
--include skills,config,history
# 迁移选项
$ hermes migrate openclaw --help
Options:
--source PATH OpenClaw 配置目录 [默认: ~/.openclaw]
--target PATH Hermes 目标目录 [默认: ~/.hermes]
--include LIST 要迁移的内容 [默认: all]
可选: skills, config, history, memory, tools
--exclude LIST 要排除的内容
--dry-run 预览迁移,不实际执行
--backup 迁移前备份目标目录
--conflict-strategy 冲突处理策略 [默认: prompt]
可选: overwrite, skip, prompt, rename
7.3 迁移过程详细步骤
步骤1:备份现有数据
# 备份 OpenClaw 配置
cp -r ~/.openclaw ~/.openclaw-backup-$(date +%Y%m%d)
# 备份 Hermes 配置(如果有)
cp -r ~/.hermes ~/.hermes-backup-$(date +%Y%m%d)
步骤2:安装 Hermes
# 按照本书第五册的安装指南安装 Hermes
curl -fsSL https://hermesagent.io/install.sh | bash
# 验证安装
hermes --version
步骤3:执行自动迁移
# 预览迁移内容
hermes migrate openclaw --preview --source ~/.openclaw
# 如果预览结果满意,执行迁移
hermes migrate openclaw --source ~/.openclaw --backup
步骤4:验证迁移结果
# 检查迁移的 Skill
hermes skill list
# 检查迁移的配置
hermes config get --all
# 测试一个迁移的 Skill
hermes skill test <skill_name>
步骤5:手动调整
自动迁移完成后,可能需要手动调整: - 某些 OpenClaw 特有的配置项需要重新配置 - 路径和变量名可能有变化 - 某些高级功能可能需要重新实现
7.4 自动迁移支持的内容(技能、配置、历史)
| 内容类型 | 自动迁移支持 | 说明 |
|---|---|---|
| Skill 代码 | 部分支持 | TypeScript -> Python 需要转换 |
| Skill 配置 | 支持 | 元数据可以迁移 |
| 系统配置 | 支持 | 基础配置项可以映射 |
| 平台配置 | 部分支持 | 相同平台可直接迁移 |
| 历史对话 | 支持 | 格式转换后导入 |
| 记忆文件 | 部分支持 | 文件格式需要转换 |
| 自定义工具 | 需手动 | 需要重写为 Python |
| API Key | 支持 | 安全配置迁移 |
7.5 需要手动调整的部分
Skill 代码转换
OpenClaw 的 Skill 是 TypeScript,Hermes 的 Skill 是 Python。自动迁移可以处理配置,但代码逻辑需要手动转换。
// OpenClaw Skill 示例(TypeScript)
export class MySkill {
async execute(params: any) {
const result = await fetch(params.url);
return result.json();
}
}
# Hermes Skill 示例(Python)
from hermes.tools import Tool
import aiohttp
class MySkill(Tool):
async def execute(self, url: str):
async with aiohttp.ClientSession() as session:
async with session.get(url) as response:
return await response.json()
配置差异
# OpenClaw 配置风格
model:
provider: openai
model: gpt-4o
tools:
- web_search
- file_read
# Hermes 配置风格
model:
default: gpt-4o
providers:
openai:
api_key: "${OPENAI_API_KEY}"
tools:
builtin:
- web_search
- file_read
7.6 迁移后验证
# 验证清单
# 1. 基础功能
hermes --version
hermes chat "Hello"
# 2. 模型连接
hermes model test
# 3. 工具功能
hermes tool test web_search
hermes tool test file_read
# 4. Skill 功能
hermes skill list
hermes skill test <important_skill>
# 5. 平台接入
hermes gateway test telegram
# 6. 记忆系统
hermes memory search "test"
# 7. 完整工作流
hermes workflow test <important_workflow>
7.7 常见迁移问题与解决方案(10个)
问题1:Skill 代码无法直接运行
原因:TypeScript 和 Python 语法不同
解决:需要手动将 Skill 逻辑从 TS 转换为 Python
参考:本书第八册「技能系统完全指南」
问题2:配置文件格式不兼容
原因:Hermes 和 OpenClaw 的配置结构不同
解决:使用 hermes migrate 自动转换基础配置,手动调整高级配置
参考:迁移工具的 --preview 选项可以先看差异
问题3:路径和变量名变化
原因:两个项目的环境变量和路径约定不同
解决:检查 .env 文件,更新变量名
常见变化:
OPENCLAW_API_KEY -> HERMES_API_KEY
~/.openclaw/skills -> ~/.hermes/skills
问题4:第三方扩展不可用
原因:OpenClaw 的某些扩展没有 Hermes 版本
解决:
1. 在 Hermes 社区寻找替代方案
2. 自己用 Python 重写
3. 通过 MCP 协议接入
问题5:记忆丢失
原因:记忆文件格式不兼容
解决:
1. 使用迁移工具的 --include memory 选项
2. 如果自动迁移失败,可以导出为文本后重新导入
3. 某些记忆可能需要重新"训练"
问题6:平台接入配置不同
原因:两个项目的 Gateway 配置格式不同
解决:参考本书第十册「多平台接入实战」重新配置
注意:Webhook URL 可能需要更新
问题7:性能差异
原因:Python 和 Node.js 的性能特征不同
解决:
1. 调整并发数
2. 开启缓存
3. 必要时使用更快的模型
问题8:安全问题
原因:两个项目的安全模型不同
解决:
1. 重新审查沙箱配置
2. 设置命令审批规则
3. 参考本书第十二章的安全配置
问题9:工作流中断
原因:自动化任务依赖特定路径或配置
解决:
1. 检查所有 Cron 任务
2. 更新路径引用
3. 测试每个工作流
问题10:习惯改变
原因:两个项目的交互方式不同
解决:
1. 给自己一周适应期
2. 利用 Hermes 的自学习加速适应
3. 保留 OpenClaw 作为备用(可以并行运行)
7.8 迁移后的优化建议
优化1:利用自学习加速适应
# 开启自动 Skill 创建
hermes config set auto_skill_creation true
# 设置学习阈值
hermes config set skill_creation_threshold 3
优化2:重新设计记忆策略
# 利用 Hermes 的三层记忆系统
memory:
session:
enabled: true
max_turns: 50
persistent:
enabled: true
db_path: "./memory.db"
skill_level:
enabled: true
auto_extract: true
优化3:探索 MCP 生态
# 查看可用的 MCP 服务
hermes mcp list
# 接入常用的 MCP 服务
hermes mcp add filesystem
hermes mcp add github
hermes mcp add fetch
8. 从其他框架迁移
8.1 从 AutoGPT 迁移
AutoGPT 是 AI Agent 领域的先驱之一,但它的架构与 Hermes 差异较大。
主要差异: - AutoGPT 使用"思考-行动-观察"循环,Hermes 使用技能驱动 - AutoGPT 的任务分解更自主,但也更容易陷入循环 - AutoGPT 的记忆系统相对简单
迁移建议: 1. 重新设计任务流程(从循环改为 Skill 链) 2. 利用 Hermes 的三层记忆替代 AutoGPT 的记忆文件 3. 使用 Hermes 的工具系统替代 AutoGPT 的插件系统
8.2 从 MetaGPT 迁移
MetaGPT 模拟软件开发团队的协作流程,适合复杂的软件开发任务。
主要差异: - MetaGPT 是多角色协作,Hermes 是单 Agent + Skill 系统 - MetaGPT 主要面向软件开发,Hermes 更通用
迁移建议: 1. 将 MetaGPT 的角色映射为 Hermes 的 Skill 2. 使用 Hermes 的多 Agent 功能(如果可用)替代角色协作 3. 保留 MetaGPT 用于大型软件开发项目,Hermes 用于日常任务
8.3 从 CrewAI 迁移
CrewAI 是一个轻量级的多 Agent 框架,与 Hermes 的架构较为接近。
主要差异: - CrewAI 强调 Agent 之间的协作,Hermes 强调 Skill 的复用 - CrewAI 的 Skill 是手动定义的,Hermes 支持自动创建
迁移建议: 1. CrewAI 的 Agent 可以映射为 Hermes 的 Skill 或工作流 2. 利用 Hermes 的自学习减少手动配置 3. CrewAI 的协作逻辑可以用 Hermes 的工作流系统实现
8.4 通用迁移思路
无论从哪个框架迁移到 Hermes,都可以遵循以下思路:
第一步:功能映射
列出你在原框架中使用的所有功能,找到 Hermes 中的对应方案:
| 原框架功能 | Hermes 对应方案 |
|---|---|
| 任务分解 | Skill 链 + 工作流 |
| 记忆系统 | 三层记忆系统 |
| 工具/插件 | 内置工具 + MCP |
| 角色定义 | Skill 配置 + 用户画像 |
| 自动化流程 | Cron + 工作流 |
第二步:数据迁移
- 导出历史数据为通用格式(JSON/CSV/Markdown)
- 使用 Hermes 的导入功能或脚本导入
- 验证数据完整性
第三步:逐步切换
- 不要一次性全部迁移
- 先迁移最常用的功能
- 并行运行两个系统一段时间
- 确认稳定后再完全切换
第四步:优化利用
- 利用 Hermes 特有的功能(自学习、用户画像等)
- 重新设计工作流,发挥 Hermes 的优势
- 持续优化和调整
迁移的心态调整
迁移不只是技术工作,也是习惯的改变。给自己一些时间适应: - 第一周:并行运行,熟悉 Hermes 的操作方式 - 第二周:把最常用的功能迁移过来 - 第三周:尝试 Hermes 特有的功能(如自学习) - 第四周:评估是否完全切换,或保持共存
不要期望迁移后立刻就能达到在 OpenClaw 上的熟练度。每个框架都有自己的"脾气",需要时间去了解和适应。
Tips
迁移期间,建议保留 OpenClaw 的备份。如果 Hermes 某个功能暂时无法满足需求,你可以随时回退。平滑迁移比"一刀切"更明智。
9. 两者共存方案
9.1 同时使用 Hermes + OpenClaw 的场景
很多高级用户选择同时使用两个框架。以下是一些典型的共存场景:
场景1:分工协作
- Hermes:日常任务自动化、内容生成、信息收集
- OpenClaw:代码审查、系统管理、需要高安全性的任务
场景2:渐进迁移
- 新功能用 Hermes 开发
- 旧功能继续用 OpenClaw 运行
- 逐步迁移,降低风险
场景3:场景专用
- Hermes:移动端通过 Telegram/微信使用
- OpenClaw:桌面端通过原生应用使用
场景4:团队分工
- 技术团队用 OpenClaw(TypeScript 生态)
- 运营团队用 Hermes(配置简单,中文友好)
9.2 数据互通方案
如果同时使用两个框架,数据互通是一个重要问题。
方案1:共享数据库
# 两个框架都连接到同一个数据库
# Hermes 配置
database:
url: "postgresql://user:pass@localhost:5432/shared_db"
# OpenClaw 配置
database:
url: "postgresql://user:pass@localhost:5432/shared_db"
方案2:文件共享
# 使用共享的文件系统目录
# Hermes 配置
storage:
shared_path: "/shared/agent_data/"
# OpenClaw 配置
storage:
shared_path: "/shared/agent_data/"
方案3:API 互通
# 让 Hermes 和 OpenClaw 通过 API 交换数据
# Hermes 端:提供数据接口
from hermes import app
@app.route('/api/share/memory')
def share_memory():
return get_recent_memories()
# OpenClaw 端:消费数据
const response = await fetch('http://hermes:8080/api/share/memory');
const memories = await response.json();
9.3 最佳实践
实践1:明确分工
不要让两个框架做同一件事。为每个框架定义清晰的职责范围,避免重复和冲突。
实践2:统一数据源
如果两个框架都需要访问相同的数据(如客户信息、订单数据),使用统一的数据库或 API,避免数据不一致。
实践3:共享通知渠道
两个框架的通知都发送到同一个 Telegram 群/Slack 频道,便于统一管理。
# Hermes 通知配置
notifications:
telegram:
chat_id: "${SHARED_CHAT_ID}"
# OpenClaw 通知配置
notifications:
telegram:
chat_id: "${SHARED_CHAT_ID}"
实践4:定期评估
每季度评估一次:哪个框架用得更多?哪个功能更需要?是否还需要同时维护两个?根据评估结果调整策略。
共存的长期视角
很多用户担心"同时使用两个框架会不会很混乱"。实际上,随着你对两个框架的理解加深,你会发现它们各自有不可替代的场景:
- 早上用 Hermes:让它自动收集 overnight 的信息,生成晨间简报
- 白天用 OpenClaw:在编程时使用它的代码助手功能
- 晚上用 Hermes:回顾一天的工作,让 Agent 帮你整理笔记
这种"分工协作"的模式,反而比死守一个框架更高效。
从共存到选择的自然过程
大多数用户的最终状态不是"永远共存",而是"自然选择"。使用几个月后,你会发现: - 80% 的时间你在用其中一个框架 - 另一个框架只用于 1-2 个特定场景 - 这时你可以考虑把特定场景也迁移到主框架,或者保持现状
无论最终选择什么,这段"共存期"都是有价值的——它让你更深入地理解了不同工具的优势和局限。
10. 本章小结
恭喜你读完了第十三册!这一章是对 AI Agent 选型最全面的中文分析之一,让我们回顾一下核心内容。
我们理解了为什么需要对比:
选择工具不是跟风,而是要根据自身需求做理性决策。OpenClaw 和 Hermes 都有庞大的社区和光明的未来,但它们的架构哲学、技术栈和适用场景有明显差异。
我们深入对比了 12 个维度:
从主语言、架构设计、学习能力、记忆系统、工具生态、平台支持、安全体系、移动应用、模型支持、部署方式、成本到社区规模,每个维度都有详细的分析和数据支撑。
我们理解了核心差异:
- 自学习 vs 手动配置:Hermes 会自动学习和进化,OpenClaw 需要手动编写配置
- 有界记忆 vs 模块化记忆:两种设计哲学,各有优劣
- Python vs TypeScript:生态选择影响开发体验
- 轻量 vs 全能:两种架构路线,适合不同场景
- Harness Engineering vs Unix Philosophy:养马 vs 组装的隐喻
我们看了社区对比:
四个主流工具(Claude Code、Cursor、OpenClaw、Hermes)有不同的定位和角色。高级用户通常同时使用多个工具,形成自己的工具栈。
我们得到了选型建议:
通过决策树和场景化推荐,你可以根据自己的背景、需求和预算找到最适合的工具。学生/个人开发者推荐 Hermes,企业/团队推荐 OpenClaw(目前),需要移动应用选 OpenClaw,追求效率部署选 Hermes。
我们学习了迁移方法:
从 OpenClaw 迁移到 Hermes 有官方工具支持,可以自动迁移大部分内容。迁移前要做好评估,迁移后要验证和优化。我们还讨论了从 AutoGPT、MetaGPT、CrewAI 等其他框架迁移的通用思路。
我们了解了共存方案:
两个框架不是非此即彼,很多高级用户同时使用两者。通过明确分工、统一数据源、共享通知渠道,可以实现高效的共存。
最后的建议
没有最好的工具,只有最合适的工具。不要盲目跟风,也不要死守一个拒绝尝试其他。技术选型是一个动态的过程——今天最适合你的工具,一年后可能不再是最佳选择。保持开放的心态,持续学习和尝试,才能在这个快速发展的领域始终站在前沿。
无论你最终选择 Hermes、OpenClaw,还是两者都用,记住:工具只是手段,解决问题才是目的。不要让选择工具本身成为你前进的阻碍。
作者:鲲鹏Talk
微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十四章:Hermes Agent 九大变现路径
本章你将学到: - 为什么 AI Agent 是个体搞钱的最佳工具 - 九条从零门槛到高收入的变现路径 - 每条路径的具体操作步骤、定价策略和收入预估 - 如何用 Hermes Agent 把"时间"变成"印钞机" - 组合策略和避坑指南,帮你少走弯路
1. AI Agent 时代的个体变现机遇
1.1 为什么 AI Agent 是个体搞钱的最佳工具?
咱们先聊个扎心的话题:你知道现在最值钱的是什么吗?
不是房子,不是股票,是时间。
每个人的一天都是 24 小时,这是世界上最公平的事情。但人与人之间的收入差距,往往就是 "时间利用率" 的差距。一个年薪百万的程序员和一个月薪五千的文员,最大的区别不是智商,而是前者写的代码可以同时服务一百万用户,而后者的工作只能服务一个老板。
这就是杠杆的力量。
以前,个体想要放大自己的时间价值,通常需要借助"资本杠杆"(创业融资)或"团队杠杆"(雇人干活)。但这两个选项的门槛都太高了——创业九死一生,雇人意味着要发工资、交社保、处理各种人事问题。
AI Agent 的出现,给了普通人第三条路:技术杠杆。
Hermes Agent 就是你的"数字员工"。你教会它一个技能,它就可以 7×24 小时不间断地工作,不会喊累、不会请假、不会要加班费。更关键的是,部署一个 Hermes Agent 的成本极低——一台树莓派、一个云服务器,甚至你的旧笔记本都能跑。
Tips:你可以把 Hermes Agent 想象成一个"智能实习生"。刚入职时需要培训(配置和调试),但一旦上手,它就能独立完成大量重复性工作,而你只需要坐在旁边"喝茶监督"。
1.2 "超级个体"的概念与 Hermes 的关系
"超级个体"这个词近几年特别火。什么是超级个体?简单说就是:一个人 + 一套工具 = 一家小型公司。
传统的超级个体通常需要掌握多种技能:写作、设计、编程、运营、销售……门槛相当高。但有了 Hermes Agent 之后,情况完全变了——你不需要自己会编程,你只需要知道"我想要什么",然后让 Agent 帮你实现。
举个例子: - 以前你想做个竞品监控工具,需要懂 Python、懂爬虫、懂数据库、懂前端可视化,前后折腾一两个月。 - 现在你用 Hermes Agent,写几句自然语言描述需求,Agent 就能帮你搭建完整的监控流水线,数据自动抓取、分析、推送,全程不超过半天。
这就是 Hermes 赋能超级个体的核心逻辑:把"技术门槛"变成"表达门槛"——你不需要懂代码,你只需要清楚表达你的需求。
1.3 变现的底层逻辑:用 AI 放大你的时间价值
在深入九条变现路径之前,咱们先搞清楚一个底层问题:AI Agent 到底怎么帮你赚钱?
答案其实很简单,就三个词:自动化、规模化、差异化。
自动化:把重复性工作交给 Agent,你的时间释放出来去做更有价值的事。比如以前你每天花 2 小时手动整理数据报表,现在 Agent 全自动完成,这 2 小时你可以用来开发新客户。
规模化:Agent 的工作是可以无限复制的。你开发一个技能包,卖给 1 个人和卖给 1000 个人,你的边际成本几乎为零。这在传统服务业是不可能的——理发师一天最多剪 20 个头,但 Agent 一天可以服务 10000 个用户。
差异化:当大多数人还在手动干活的时候,你已经用 AI 实现了自动化。同样的报价,你的交付速度是别人的 10 倍;同样的交付速度,你的报价可以比别人低 50%。这就是竞争优势。
注意:AI Agent 不是"躺着赚钱"的魔法。它确实能大幅提高效率,但你仍然需要投入时间去学习、调试和运营。把 Agent 当成"加速器"而不是"提款机",心态才能摆正。
1.4 九条路径总览与难度/收入预估表
好了,废话不多说,直接上干货。下面是本书为你精心梳理的九条变现路径总览表,你可以根据自己的技能水平、时间投入和风险偏好来选择:
| 路径 | 名称 | 入门难度 | 启动成本 | 月收入预估 | 适合人群 |
|---|---|---|---|---|---|
| 路径一 | 代安装与排障服务 | ★☆☆☆☆ | 0 元 | 2,000-5,000 元 | 小白、学生党 |
| 路径二 | 工作流定制开发 | ★★★☆☆ | 0 元 | 5,000-20,000 元 | 有一定基础 |
| 路径三 | 技能包销售 | ★★☆☆☆ | 0 元 | 1,000-10,000 元 | 任何人 |
| 路径四 | 自动化内容账号 | ★★☆☆☆ | 0-100 元 | 2,000-50,000 元 | 内容创作者 |
| 路径五 | 付费数据社群 | ★★★☆☆ | 100-500 元 | 5,000-100,000 元 | 行业从业者 |
| 路径六 | 技能分发赚提成 | ★★☆☆☆ | 0 元 | 500-5,000 元 | 开发者 |
| 路径七 | 自动化任务脚本 | ★★☆☆☆ | 0 元 | 1,000-5,000 元 | 技术爱好者 |
| 路径八 | 企业内部工具开发 | ★★★★☆ | 0 元 | 10,000-50,000 元 | 有经验者 |
| 路径九 | 培训与社群陪跑 | ★★★☆☆ | 0-500 元 | 5,000-50,000 元 | 表达能力强 |
常见问题:我应该从哪条路径开始?
我的建议是:如果你完全零基础,从路径一(代安装)开始,因为这个门槛最低,你甚至不需要自己很会配置,只需要"比客户多懂一点"就行。在帮别人安装的过程中,你自己的能力也会快速提升。等你熟练了,再逐步升级到路径二、三、四。
2. 路径一:代安装与排障服务
2.1 市场分析:大量小白不会安装
先说一个你可能不知道的事实:技术圈有个"最后一公里"问题。
一个工具的官方文档写得再好,也总有 80% 的潜在用户卡在安装这一步。不是因为他们笨,而是因为每个人的电脑环境不一样——操作系统版本不同、Python 环境混乱、网络连接有问题、依赖包版本冲突……这些问题对老手来说可能 5 分钟搞定,但对小白来说可能折腾三天三夜。
Hermes Agent 的安装虽然已经有 Docker、pip 等多种方式,但对纯小白来说,仍然有不少坑: - Docker 怎么装? - 配置文件里的 API Key 怎么申请? - 模型选择哪个? - 报错信息看不懂怎么办?
这些就是你的机会。
Tips:想象一下,你去一家餐厅吃饭,门口排了 100 个人,但只有 20 个人知道怎么推门进去。你只需要站在门口帮人推一下门,就能收钱。代安装服务就是这个道理。
2.2 接单渠道
闲鱼
闲鱼是目前最适合新手起步的平台。它的优势是: - 零门槛开店,不需要营业执照 - 用户群体广泛,从学生到职场人都有 - 搜索流量免费,关键词写得好就有曝光
闲鱼发布技巧:
标题:Hermes Agent 代安装部署 手把手教学 远程配置
文案:
【服务内容】
- Hermes Agent 一键安装部署(Docker/本地)
- API Key 配置指导(OpenAI/Claude/DeepSeek)
- 模型参数调优
- 基础使用教学
- 3天售后答疑
【服务流程】
1. 下单后发送远程控制软件(ToDesk/向日葵)
2. 远程连接你的电脑
3. 全程操作并讲解
4. 测试确认无误后交付
【价格】
基础安装:50元
完整配置(含API申请+模型调优):99元
疑难杂症排障:30-80元(视难度)
【我的优势】
已帮助 100+ 用户成功部署,好评率 99%
小红书
小红书的优势是信任感强、客单价高。
在小红书接单,不要直接发广告,而是发"经验分享帖": - "我用 Hermes Agent 搭建了一个自动写周报的工具" - "小白也能看懂的 Hermes 安装教程" - "Herms 排错经验:这 5 个坑千万别踩"
帖子火了之后,自然会有用户在评论区或私信问你"能不能帮忙安装",这时候再引导到私域成交。
淘宝
淘宝适合走量,但需要交保证金(约 1000 元)。优点是平台信任度高,适合标准化服务。你可以上架几个 SKU: - Hermes Agent 基础安装服务(50 元) - Hermes Agent 高级配置服务(150 元) - Hermes Agent 故障排查服务(按次计费)
知识星球
知识星球适合有粉丝基础的人。你可以创建一个"Hermes Agent 互助星球",提供安装指导和日常答疑,年费定价 99-199 元。星球的好处是一次性收费、持续服务,用户粘性高。
2.3 服务流程标准化
做服务最怕的就是"每次都不一样",流程不标准化,既累人又容易出问题。建议你按以下 SOP(标准操作流程)来:
第一阶段:售前咨询(5-10 分钟)
1. 了解客户环境:操作系统、是否有 Docker、网络情况
2. 明确需求:只需要安装,还是需要配置模型、技能等
3. 报价确认
4. 约定远程时间
第二阶段:远程安装(15-60 分钟)
1. 发送远程软件链接(推荐 ToDesk,免费且稳定)
2. 操作过程中语音讲解每个步骤
3. 记录关键配置信息(API Key、模型选择等)
4. 完成安装后,让客户亲自测试几个功能
第三阶段:交付与售后
1. 发送配置摘要文档(包含关键参数和注意事项)
2. 提供 3 天内的免费答疑
3. 邀请客户留好评(闲鱼/淘宝的话)
Tips:一定要准备一份"安装配置摘要模板",每次服务完填一下就能发给客户。这样既显得专业,又能减少后续重复答疑的时间。
2.4 定价策略
代安装的定价要遵循一个原则:让客户觉得"自己折腾不如找你",同时让自己觉得"这单值得做"。
建议定价区间:
| 服务类型 | 建议价格 | 耗时 |
|---|---|---|
| Docker 一键安装 | 50-80 元 | 10-20 分钟 |
| 本地环境完整配置 | 99-150 元 | 30-60 分钟 |
| 含 API 申请 + 模型调优 | 150-200 元 | 45-90 分钟 |
| 疑难杂症排障 | 30-100 元 | 15-60 分钟 |
| 月度技术支持(包月) | 299-499 元 | 不限次数答疑 |
注意:不要低价恶性竞争。我见过有人定价 9.9 元包安装,结果一天接 20 单,累得要死还赚不到钱。定价 50 元,一天接 5 单,赚得更多还轻松。记住,你的时间也是有成本的。
2.5 如何用 Hermes 自动生成排障指南
这里教给你一个"用魔法打败魔法"的技巧:你可以让 Hermes Agent 自己帮你写排障指南。
具体操作:
# 创建一个排障助手技能
system_prompt: |
你是一位 Hermes Agent 技术支持专家。当用户描述安装或使用过程中遇到的问题时,你需要:
1. 分析问题可能的原因
2. 给出具体的解决步骤
3. 提供预防此类问题再次发生的建议
请用中文回答,语言通俗易懂,适合技术水平较低的用户理解。
当客户遇到问题时,你把报错信息粘贴给 Hermes Agent,它会帮你生成一份完整的排障方案。你再把这个方案稍作润色发给客户,既专业又高效。
2.6 月收入预估:兼职 2000-5000 元
咱们来算一笔账: - 假设你晚上和周末兼职,每周能接 5-8 单 - 平均每单价格 80 元 - 每周收入:5 × 80 = 400 元 - 每月收入:400 × 4 = 3200 元
如果你是学生党或时间比较充裕,每天接 2-3 单,一个月做到 5000-8000 元也是完全有可能的。
常见问题:客户会要求退款怎么办?
建议在服务前明确说明:"远程安装服务属于技术咨询服务,一旦开始操作即产生服务成本。如因客户环境问题导致安装失败,可协商部分退款;如因我方技术原因导致失败,全额退款。"把规则说清楚,大部分纠纷都能避免。
2.7 实操案例与客户反馈模板
实操案例:大学生小张的兼职故事
小张是一名大二计算机专业的学生,他在自学 Hermes Agent 的过程中,把安装步骤整理成了笔记。有一天他在小红书发了一篇"Hermes 安装避坑指南",没想到一下子获得了 500 多个赞。评论区很多人问"能不能帮忙安装"。
小张顺势在闲鱼开了个链接,定价 66 元包安装。第一个月他接了 40 多单,赚了 2600 多元。更重要的是,他在帮别人安装的过程中,自己的技术水平也突飞猛进。三个月后,他已经能接工作流定制的单子了,客单价涨到了 500+。
客户反馈模板:
【服务完成后,可以礼貌地请求客户留评】
"服务已经完成啦!如果您对本次安装服务满意,
麻烦帮忙留个好评呀~ 您的好评是我持续服务的最大动力!
后续有任何问题,随时微信找我,3天内免费答疑。"
【好评回复模板】
"感谢您的认可!有任何新需求随时联系,祝您使用愉快~"
3. 路径二:工作流定制开发
3.1 目标客户
工作流定制是代安装服务的"进阶版"。如果说代安装是"帮人把软件装上",工作流定制就是"帮人把软件用好"——根据客户的具体业务需求,定制一套自动化工作流。
典型的目标客户包括:
电商团队 - 需求:竞品价格监控、自动上架商品、评论情感分析、库存预警 - 痛点:人工盯数据太累,容易错过最佳调价时机 - 预算:单个工作流 500-3000 元
投研团队 - 需求:财报数据自动抓取、舆情监控、研报摘要生成 - 痛点:信息太多看不过来,需要 7×24 监控 - 预算:单个工作流 1000-5000 元
内容团队 - 需求:热点话题追踪、竞品内容分析、自动排版发布 - 痛点:追热点靠人工太慢,错失流量窗口 - 预算:单个工作流 500-2000 元
中小企业 - 需求:客户数据自动整理、会议纪要自动生成、报表自动发送 - 痛点:行政工作占用太多人力 - 预算:单个工作流 500-3000 元,全套方案 5000-20000 元
3.2 常见需求类型
数据抓取类
这是需求量最大的一类。客户通常需要: - 抓取电商平台的商品价格、销量、评价 - 抓取社交媒体的热搜、话题、评论 - 抓取行业网站的最新文章、报告
用 Hermes Agent 实现这类需求,通常需要组合使用 Web Search Skill + Browser Skill + 数据处理 Skill。
报表自动化类
很多公司每周/每月都要做各种报表,数据从多个系统来,手动汇总非常耗时。
典型的自动化报表工作流:
1. 定时触发(每周一早上 8 点)
2. 从 A 系统 API 拉取销售数据
3. 从 B 系统 API 拉取库存数据
4. 用 Python 进行数据清洗和合并
5. 生成图表和关键指标分析
6. 自动发送邮件给管理层
客服自动化类
中小电商团队常常没有足够的客服人员。可以用 Hermes Agent 搭建: - 自动回复常见问题(退货政策、发货时间等) - 订单状态自动查询和回复 - 客户情绪分析,遇到投诉自动升级给人工
监控告警类
适合需要 7×24 监控的场景: - 网站可用性监控(每分钟 ping 一次,宕机立即告警) - 竞品动态监控(对手发布新产品、降价时通知) - 舆情监控(品牌负面消息实时推送)
3.3 定价策略
工作流定制的定价要比代安装复杂一些,因为每个项目的工作量差异很大。建议采用"基础价 + 复杂度加价"的模式:
| 复杂度 | 描述 | 建议价格 |
|---|---|---|
| 简单 | 单一步骤的自动化,如定时发送邮件 | 500-1000 元 |
| 中等 | 多步骤组合,如抓取+分析+推送 | 1000-3000 元 |
| 复杂 | 多数据源整合+可视化+权限管理 | 3000-8000 元 |
| 企业级 | 全套方案+长期维护+培训 | 5000-50000 元 |
报价公式参考:
总价 = 基础开发费(500-1000元)+ 功能模块数 × 单价(300-800元/模块)+ 维护费(可选,每月 10-20%)
Tips:首次合作建议适当优惠,比如"首单 8 折"或"赠送 1 个月维护"。先建立信任,后续长期合作才是利润来源。
3.4 开发流程与交付标准
标准开发流程:
第一阶段:需求沟通(1-2 天)
├─ 与客户视频会议,深入了解业务场景
├─ 输出《需求确认文档》,包含功能清单和流程图
└─ 双方确认后支付 30% 定金
第二阶段:开发实现(3-7 天)
├─ 搭建开发环境,编写 Skill 代码
├─ 中间版本发给客户预览,收集反馈
├─ 根据反馈调整优化
└─ 完成全部功能开发
第三阶段:测试交付(1-2 天)
├─ 完整功能测试
├─ 编写《用户使用手册》
├─ 线上培训(30-60 分钟)
├─ 客户验收确认
└─ 支付剩余 70% 尾款
第四阶段:维护期(可选,按月收费)
├─ Bug 修复
├─ 小范围功能调整
└─ 日常答疑支持
交付物清单: 1. 完整的 Skill 代码文件 2. 配置文件模板及说明 3. 《用户使用手册》(图文版) 4. 部署安装视频(录制屏幕) 5. 30 天免费 Bug 修复承诺
注意:一定要在合同中明确"需求变更"的处理方式。很多项目做到一半客户突然"再加个小功能",如果不提前约定,很容易被无限加需求。建议写明:"开发过程中如需新增需求,双方协商追加费用。"
3.5 如何展示案例获取客户
做定制开发,案例是最好的名片。
即使你是新手,没有真实客户案例,也可以通过以下方式积累"作品集":
方法一:做自己的 Demo 项目 - 搭建一个你感兴趣的自动化工作流 - 录制一个 2-3 分钟的演示视频 - 发布到小红书/B站/知乎 - 视频结尾加上"如需定制类似工作流,欢迎私信"
方法二:免费帮朋友做 - 找身边有需求的朋友,免费帮他做一个 - 作为交换,请他给你写个好评/推荐 - 把这个项目作为你的案例展示
方法三:参与开源社区 - 在 Hermes 社区贡献你的 Skill - 在 GitHub 上开源你的项目 - 有了 Star 数,客户自然更信任你
3.6 月收入预估:5000-20000 元
工作流定制的收入天花板比代安装高得多,但前提是你需要持续有订单。
收入模型: - 兼职状态:每月接 3-5 单,客单价 1500 元,月收入 4500-7500 元 - 半全职状态:每月接 8-12 单,客单价 2000 元,月收入 16000-24000 元 - 加上维护费:每个老客户每月收 200-500 元维护费,10 个老客户就是 2000-5000 元的被动收入
3.7 实操案例:为电商团队搭建竞品监控
客户需求: 某淘宝卖家团队(5 人)经营数码配件,需要监控 10 个竞品店铺的: 1. 新品上架情况 2. 价格变动 3. 促销活动 4. 评价变化
解决方案: 用 Hermes Agent 搭建了一个 7×24 自动监控系统:
# 竞品监控系统 Skill 配置
name: competitor_monitor
schedule:
- cron: "0 */4 * * *" # 每 4 小时执行一次
tasks:
- name: check_new_products
action: browser.scrape
target: "竞品店铺页面 URL"
extract: [product_name, price, create_time]
- name: compare_prices
action: python.execute
script: |
# 对比当前价格与上次记录
# 如果变化超过 5%,标记为异常
- name: generate_report
action: llm.generate
prompt: "根据以下竞品数据变化,生成一段简洁的分析摘要..."
- name: send_notification
action: email.send
to: "seller@example.com"
subject: "竞品监控日报"
项目收入: - 开发费用:3500 元 - 维护费用:300 元/月 - 客户后来追加了一个"自动调价建议"功能,又收了 2000 元
Tips:这个项目最有价值的地方不是技术本身,而是"业务理解"。如果你懂电商,你就知道卖家最在意什么;如果你不懂,就算技术再厉害,做出来的东西也可能不对路。所以,选一个你熟悉的行业深耕,比什么技能都强。
4. 路径三:技能包销售
4.1 什么是技能包
技能包,顾名思义,就是打包好的 Skill 文件。在 Hermes Agent 中,Skill 本质上就是一个 Markdown 文件,里面包含了: - 系统提示词(告诉 Agent 该怎么干活) - 工具调用定义(Agent 可以使用哪些工具) - 工作流程(处理任务的步骤)
你可以把自己开发的 Skill 打包成一个产品,像卖电子书一样卖出去。
Tips:技能包是完美的"虚拟产品"——制作一次,无限销售,没有库存,没有物流,边际成本为零。这就是数字产品的魅力。
4.2 虚拟产品零成本、无限复制
我们来对比一下不同类型的产品成本:
| 产品类型 | 制作成本 | 每份成本 | 库存 | 物流 |
|---|---|---|---|---|
| 实体商品 | 高 | 高 | 需要 | 需要 |
| 在线课程 | 中 | 低 | 不需要 | 不需要 |
| 技能包 | 低 | 零 | 不需要 | 不需要 |
技能包的制作成本主要是你的时间投入。一旦制作完成,你可以在 Gumroad、小红书、闲鱼、自己的独立站上反复销售,每卖一份都是纯利润。
4.3 热门技能包方向
根据市场需求和 Hermes 的能力,以下几个方向的技能包特别受欢迎:
投研分析类
- 财报数据解读助手
- 股票技术面分析助手
- 加密货币市场情绪分析
- 行业研报摘要生成
写作辅助类
- 小红书爆款文案生成器
- 公众号文章初稿生成
- 短视频脚本创作助手
- 邮件/商务文案润色
编程开发类
- 代码审查助手
- Bug 排查助手
- API 文档生成器
- 代码注释自动生成
数据分析类
- Excel 数据清洗助手
- CSV 数据可视化生成
- SQL 查询优化助手
- 数据报表自动解读
办公效率类
- 会议纪要自动整理
- PPT 大纲生成器
- 周报/月报自动撰写
- 待办事项智能优先级排序
4.4 销售渠道
小红书
小红书是卖虚拟产品的最佳平台之一。用户购买力强,且对"知识付费"接受度高。
发布策略: - 发"使用演示"帖子:展示你的技能包能做出什么效果 - 发"教程"帖子:教别人怎么做,但关键步骤留一手 - 评论区引导:"需要这个技能的完整版,私信"
定价建议: 9.9-49.9 元(小红书用户对这个价格区间接受度最高)
闲鱼
闲鱼的优势是搜索流量大,适合走量。
发布技巧: - 标题包含多个关键词:"Hermes Agent 技能包 投研 写作 数据分析" - 图片展示技能包的实际效果截图 - 价格定 9.9 元吸引点击,详情页说明有多个 SKU
独立站
如果你有自己的域名和网站,可以用以下工具搭建: - Gumroad:最适合卖虚拟产品,手续费 10% - LemonSqueezy:功能类似 Gumroad,界面更现代 - Notion:直接用 Notion 页面展示产品,链接到收款二维码
独立站的优势是没有平台抽成,缺点是需要自己引流。
知识星球/小册
如果你有多个技能包,可以打包成"技能包合集"在知识星球销售: - 定价 99-199 元 - 包含 10-20 个精选技能 - 附赠使用教程和更新服务
4.5 定价策略
| 类型 | 包含内容 | 建议价格 |
|---|---|---|
| 单品技能包 | 1 个 Skill 文件 + 使用说明 | 9.9-19.9 元 |
| 主题套装 | 3-5 个相关 Skill + 教程 | 29.9-69 元 |
| 全能合集 | 20+ Skill + 视频教程 + 答疑群 | 99-299 元 |
| 定制开发 | 根据客户需求定制 | 300-1000 元 |
Tips:定价心理学很重要。同样是 3 个技能包,单独卖每个 19.9 元(总价 59.7 元),打包卖 39.9 元,客户反而觉得"省了近 20 块",更愿意下单。这就是"套装优惠"的心理效应。
4.6 技能包的包装与营销
很多开发者有个误区:以为"技术好就能卖得好"。其实不然,包装和营销同样重要。
一个好的技能包产品页应该包含:
- 吸引人的标题
- 差:"股票分析 Skill"
-
好:"AI 私人投研助理:一键生成股票分析日报"
-
问题共鸣
-
"你是不是每天早上花 1 小时刷财联社、同花顺,还是抓不住重点?"
-
解决方案展示
-
放一张截图:左边是原始数据,右边是 AI 生成的精美分析报告
-
功能清单
-
清晰列出这个技能包能做的 5-10 件事
-
使用前后对比
- 使用前:手动整理数据,2 小时/天
-
使用后:AI 自动生成,5 分钟/天
-
用户评价
-
即使是朋友写的也要放几条,社会认同很重要
-
风险逆转
- "不满意全额退款"——虚拟产品几乎没人真的退款,这句话能大幅提升转化率
4.7 月收入预估:1000-10000 元
收入模型: - 单品 19.9 元,每天卖 3 份:19.9 × 3 × 30 = 1791 元/月 - 套装 59 元,每天卖 2 份:59 × 2 × 30 = 3540 元/月 - 如果出了爆款(小红书/知乎带来大量流量),单品一天卖 20-50 份也不稀奇
常见问题:技能包会被盗版吗?
会,但别太担心。Skill 文件本质上是文本,确实容易复制。但你的核心竞争力不是"这个文件",而是:1)持续更新的能力;2)配套的服务和答疑;3)你的品牌和信任。把精力花在"让更多人来买"而不是"防止少数人盗版"上。
4.8 实操案例:投研技能包的制作与销售
案例背景: 小李是一名金融从业者,平时用 Hermes Agent 做股票分析。他把自己常用的几个 Skill 整理了一下,做成了一套"AI 投研助手"技能包。
技能包内容:
📦 AI 投研助手技能包
├── 01_财报速读.skill
│ └── 输入:财报 PDF → 输出:关键指标摘要
├── 02_市场情绪监控.skill
│ └── 输入:雪球/东方财富热帖 → 输出:情绪分析报告
├── 03_技术面解读.skill
│ └── 输入:K线数据 → 输出:技术面分析
├── 04_研报摘要生成.skill
│ └── 输入:券商研报 → 输出:核心观点提炼
└── 05_每日复盘模板.skill
└── 自动生成每日投资复盘报告
销售过程: 1. 在小红书发了一篇"我用 AI 做投研,每天省 2 小时"的帖子,获得 2000+ 赞 2. 评论区有人问"这个怎么弄的",顺势推出技能包 3. 定价 39.9 元,前 50 名优惠价 19.9 元 4. 第一天卖出 30 多份,当月累计卖出 200+ 份 5. 后来又追加了"视频教程"版本,定价 99 元,又卖出 50 多份
总收入: 200 × 29.9(平均价)+ 50 × 99 = 5980 + 4950 = 10930 元
Tips:小李的成功关键在于——他本身就是金融从业者,做出来的技能包是"业内人士自用"的,比纯技术出身的开发者更懂用户痛点。行业经验 + 技术能力 = 王炸组合。
5. 路径四:自动化内容账号
5.1 核心思路
自动化内容账号,就是用 Hermes Agent + 定时任务(Cron),实现内容全自动生产、发布、运营。
想象一下这个场景: - 每天早上 8 点,你的公众号自动推送一篇 AI 行业快讯 - 内容不是随便拼凑的,而是由 Hermes 抓取昨晚全球 AI 新闻,用 LLM 生成结构化的深度解读 - 你甚至不用打开微信,文章就已经发好了 - 粉丝在评论区提问,Hermes 自动回复
这就是自动化内容账号的魅力——你在睡觉,它在干活。
Tips:但要注意,"自动化"不等于"无质量"。用 AI 自动生成内容的最大风险是"同质化"——如果每个人都用同样的方式生成同样的内容,你的账号就没有竞争力。所以,关键在于"差异化"——你的数据来源、分析视角、内容风格,必须有自己的特色。
5.2 适合的平台
| 平台 | 适合内容类型 | 变现方式 | 自动化难度 |
|---|---|---|---|
| 微信公众号 | 深度文章、行业分析 | 流量主广告、付费阅读、带货 | 中 |
| 小红书 | 图文笔记、教程 | 品牌合作、引流到私域 | 低 |
| 今日头条/百家号 | 资讯、热点 | 平台流量分成 | 低 |
| 抖音(文案) | 短视频脚本 | 带货、引流 | 中 |
| Twitter/X | 短讯、观点 | 付费订阅、引流 | 低 |
| 知乎 | 问答、专栏 | 付费咨询、引流 | 中 |
5.3 内容方向选择
不是所有内容都适合自动化。选择方向时,要考虑三个因素:
1. 数据可获取性 - 你的内容来源是否有 API 或可被爬取? - 新闻类、数据类内容最容易自动化 - 观点类、故事类内容最难自动化
2. 更新频率 - 日更类:AI 快讯、市场数据、天气预报 - 周更类:行业周报、数据复盘 - 事件驱动:财报季、发布会、突发事件
3. 目标受众 - B端(企业用户):行业分析、数据报告、技术解读 - C端(普通用户):实用教程、热点解读、娱乐内容
推荐的内容方向:
高推荐度:
├─ AI 行业快讯(每天全球 AI 新闻汇总)
├─ 加密货币市场日报(价格、舆情、事件)
├─ 电商数据洞察(热销品、价格趋势)
├─ 股票/基金每日复盘
└─ 技术教程周刊(新技术、新工具推荐)
中推荐度:
├─ 职场效率技巧
├─ 健康/养生科普
└─ 本地生活服务资讯
不推荐:
├─ 情感故事(AI 写得太假)
├─ 小说连载(同质化严重)
└─ 深度评论(需要人的独到见解)
5.4 自动化流水线配置
下面以一个"AI 快讯公众号"为例,展示完整的自动化流水线:
第一步:数据源配置
# 新闻源配置
sources:
- name: techcrunch_ai
url: "https://techcrunch.com/category/artificial-intelligence/"
type: rss
- name: 机器之心
url: "https://www.jiqizhixin.com/rss"
type: rss
- name: arxiv_ai
url: "https://arxiv.org/list/cs.AI/recent"
type: html_scrape
第二步:内容生成
# Hermes Skill 配置
system_prompt: |
你是一位资深的 AI 行业编辑。你的任务是:
1. 阅读今天收集到的 AI 新闻
2. 筛选出最重要的 5-8 条
3. 对每条新闻写一段 100-150 字的解读
4. 最后写一段"今日观察",总结整体趋势
写作风格:专业但不晦涩,适合科技从业者阅读。
语言:中文。
第三步:定时发布
# Crontab 配置
# 每天早上 7:30 生成文章,8:00 发布
30 7 * * * cd /hermes && python generate_daily_post.py
0 8 * * * cd /hermes && python publish_to_wechat.py
第四步:评论自动回复(进阶)
# 评论区监控与回复
comment_monitor:
platform: wechat_mp
trigger: new_comment
action:
- llm.generate_reply:
prompt: "根据用户评论内容,生成一段友好、专业的回复..."
- wechat.post_reply:
content: "{{generated_reply}}"
5.5 流量变现方式
平台流量分成
- 微信公众号:开通流量主,按阅读量和广告点击量分成(通常每千次阅读 5-20 元)
- 今日头条/百家号:平台直接按阅读量给钱
- 知乎:优质内容可获得平台补贴
广告合作
- 粉丝达到 1000+ 后,可以接品牌广告
- AI 类账号常见广告主:云服务商、AI 工具、培训机构
- 报价通常按粉丝数的 5-10%
带货/分销
- 推荐 AI 工具(如 API 服务、付费软件),赚取佣金
- 推荐书籍、课程,拿分销分成
- 闲鱼上卖自己的技能包/服务
引流到私域
- 公众号文章引导加微信
- 微信私域里卖高价服务(培训、定制、社群)
- 私域用户的价值通常是公域的 5-10 倍
5.6 合规注意事项
注意:用 AI 生成内容一定要遵守平台规则和法律法规,否则可能被封号甚至承担法律责任。
平台规则: - 微信公众号:要求 AI 生成内容必须标注"内容由 AI 生成" - 今日头条:对低质 AI 内容有打击政策 - 小红书:对搬运/拼凑内容有降权处理
合规建议: 1. 标注 AI 生成:在文章开头或结尾注明"本文由 AI 辅助生成" 2. 人工审核:即使内容由 AI 生成,也要人工检查一遍再发布 3. 事实核查:AI 可能会" hallucinate "(幻觉),重要数据务必人工核实 4. 版权问题:不要直接复制他人文章让 AI 改写,存在版权风险
5.7 月收入预估:2000-50000 元
自动化内容账号的收入跨度很大,取决于你的运营水平:
初级阶段(0-3 个月): - 粉丝量:0-1000 - 主要收入:平台流量分成 - 月收入:0-500 元
中级阶段(3-6 个月): - 粉丝量:1000-10000 - 主要收入:流量分成 + 偶尔的广告 - 月收入:1000-5000 元
高级阶段(6-12 个月): - 粉丝量:10000+ - 主要收入:广告 + 带货 + 引流私域 - 月收入:5000-50000 元
Tips:做内容账号最忌讳"三天打鱼两天晒网"。Hermes Agent 能帮你解决"生产内容"的问题,但"运营账号"仍然需要你的长期投入。建议至少坚持日更 3 个月,才能看到明显效果。
5.8 实操案例:日更 AI 快讯公众号
账号名称:「AI 每日速递」
运营模式: 1. 每天晚上 11 点,Hermes 自动抓取全球 AI 新闻源 2. LLM 筛选出最重要的 6-8 条,生成结构化文章 3. 第二天早上 7 点自动发布到公众号 4. 全程无需人工干预
数据源: - TechCrunch AI 板块 - The Verge AI 新闻 - 机器之心 - Paper Digest(论文推荐) - Twitter 热门 AI 讨论
内容结构模板:
标题:AI 每日速递 | 2026年4月21日
📌 今日头条
[最重要的一条新闻 + 解读]
📰 行业动态
[3-4 条重要新闻,每条 100 字摘要]
🔬 学术前沿
[1-2 条最新论文推荐]
💬 今日观察
[编辑点评,总结趋势]
收入情况: - 运营 6 个月后粉丝达到 15000 - 流量主月收入:约 2000 元 - 接了两条广告(云服务商 + AI 培训),共 6000 元 - 引流到付费社群 200 人,每人 99 元,共 19800 元 - 合计月收入约 28000 元
常见问题:AI 生成的内容会不会被平台限流?
关键在于"质量"。如果 AI 生成的内容确实有价值、有观点、有深度,平台不会管你是人写的还是 AI 写的。但如果只是拼凑、搬运、低质重复,不管是人还是 AI 写的,都会被限流。内容质量永远是第一位的。
6. 路径五:付费数据社群
6.1 核心卖点
付费数据社群,是自动化内容账号的"升级版"。区别在于: - 内容账号是"一对多广播",你发内容给所有人看 - 付费社群是"多对多互动",群成员之间也能交流
核心卖点就一句话:7×24 小时自动监控 + 实时推送,让客户"永不踏空"。
想象你是一个币圈投资者: - 你不可能 24 小时盯盘 - 但重要消息往往发生在凌晨(美国市场开盘) - 等你第二天早上醒来,可能已经错过了最佳买卖时机
但如果有一个社群,凌晨 3 点有重磅消息时,机器人立刻推送到你的微信,你设置了自动提醒,手机一震你就醒了,立刻做出决策——这就是付费社群的核心价值:消除信息不对称和时间差。
6.2 适合的领域
不是每个领域都适合搞付费数据社群。适合的领域通常有以下特征: 1. 信息时效性强:早 1 小时知道,价值巨大 2. 信息源分散:需要自己汇总多个渠道 3. 目标用户付费意愿强:投资、电商、跨境等领域用户愿意为信息付费
| 领域 | 监控内容 | 目标用户 | 定价参考 |
|---|---|---|---|
| 加密货币 | 价格异动、链上数据、监管政策 | 币圈投资者 | 199-499 元/月 |
| AI 投资 | 新品发布、融资动态、技术突破 | AI 从业者/投资者 | 99-299 元/月 |
| 跨境电商 | 平台政策、热销趋势、汇率变动 | 跨境卖家 | 99-199 元/月 |
| 股票/基金 | 财报预告、机构调研、大宗交易 | 股民/基民 | 99-399 元/月 |
| 域名/网站 | 过期域名、权重变动、SEO 趋势 | 站长/域名投资人 | 99-199 元/月 |
6.3 数据源配置与监控方案
以"AI/Web3 投研社群"为例,展示监控系统的搭建:
数据源清单:
# 数据源配置
data_sources:
# --- AI 领域 ---
- name: arxiv_daily
type: rss
url: "https://arxiv.org/rss/cs.AI"
keywords: ["agent", "llm", "multimodal", "reasoning"]
- name: producthunt
type: api
url: "https://api.producthunt.com/v2/api/graphql"
filter: category = "AI"
- name: github_trending
type: scrape
url: "https://github.com/trending"
filter: topic = "ai-agent"
- name: twitter_ai_kols
type: api
accounts: ["@DrJimFan", "@karpathy", "@AndrewYNg"]
# --- Web3 领域 ---
- name: chain_data
type: api
provider: defillama
metrics: [tvl_change, whale_movement]
- name: cointelegraph
type: rss
url: "https://cointelegraph.com/rss"
- name: governance_proposals
type: api
chains: [ethereum, arbitrum, optimism]
监控触发规则:
# 告警规则
alert_rules:
- name: major_price_movement
condition: "btc_24h_change > 5% OR btc_24h_change < -5%"
priority: high
channel: immediate
- name: funding_news
condition: "ai_company_funding > 10M"
priority: high
channel: immediate
- name: daily_digest
schedule: "0 8 * * *"
content: summary_of_last_24h
channel: daily_broadcast
推送渠道:
# 推送配置
notifications:
- platform: wechat_group
for: [high_priority, daily_digest]
- platform: wechat_private
for: [high_priority]
- platform: email
for: [daily_digest]
6.4 社群运营与管理
光有技术还不够,社群的运营同样重要。
社群运营三要素:
1. 内容价值 - 机器人推送的信息必须有价值,不能是垃圾信息 - 要对信息进行筛选和分级(紧急/重要/一般) - 定期输出深度分析报告(每周 1-2 篇)
2. 互动氛围 - 群主(你)要经常参与讨论,回答专业问题 - 鼓励成员分享观点,形成社区文化 - 定期举办线上分享会或 AMA
3. 成员管理 - 设置入群门槛(付费过滤掉白嫖党) - 制定群规,禁止广告、喷人等行为 - 对高质量成员给予奖励(免费续期、专属福利)
6.5 定价策略
付费社群的定价要考虑几个因素: - 信息价值:信息越稀缺、越值钱,定价越高 - 服务深度:纯推送便宜,加人工解读贵 - 目标人群:学生党定价低,高净值人群定价高
| 档位 | 包含内容 | 建议月费 |
|---|---|---|
| 基础版 | 机器人自动推送 | 49-99 元 |
| 进阶版 | 推送 + 每日人工解读 | 99-199 元 |
| VIP 版 | 推送 + 解读 + 1v1 答疑 | 199-499 元 |
| 终身版 | 以上所有,一次付费终身有效 | 999-2999 元 |
Tips:终身版虽然看起来"亏",但实际上是很好的现金流工具。一次收 1999 元,足够覆盖服务器和运营成本。而且很多人买了终身版后,其实并没有一直用下去(和健身卡一个道理)。
6.6 用 Hermes 自动化社群内容推送
下面是一个完整的社群推送 Skill 示例:
name: community_pusher
version: "1.0"
triggers:
- schedule: "0 8,12,18,22 * * *" # 每天 4 次推送
- event: alert_fired
tasks:
- name: collect_data
action: multi_source.fetch
sources:
- twitter_ai
- arxiv_daily
- github_trending
- market_data
- name: filter_and_rank
action: llm.analyze
prompt: |
请从以下信息中筛选出最重要的 3-5 条,按重要性排序。
对每条信息写一段 50-80 字的解读。
注意:只选真正重要的,宁可少选不要多选。
- name: format_message
action: template.render
template: |
📢 {{time}} AI/Web3 快讯
{% for item in items %}
{{loop.index}}. {{item.title}}
{{item.summary}}
{% endfor %}
---
本消息由 Hermes Agent 自动推送
- name: push_to_wechat
action: wechat.group_send
target_group: "AI 投研社群-VIP"
message: "{{formatted_message}}"
6.7 月收入预估:5000-100000 元
付费社群是九条路径中收入天花板最高的一条,但也是对运营能力要求最高的一条。
收入模型:
月收入 = 会员数 × 月费
- 200 人 × 99 元 = 19800 元/月
- 100 人 × 299 元 = 29900 元/月
- 500 人 × 199 元 = 99500 元/月
常见问题:用户会流失怎么办?
社群用户流失是正常的,通常月流失率在 5-15%。对抗流失的方法是: 1. 持续提升内容质量 2. 增加社群的社交属性(让用户之间产生连接) 3. 定期推出新功能/新服务 4. 对即将到期的用户发送优惠续费提醒
6.8 实操案例:AI/Web3 投研社群
社群名称:「Agent 投研内参」
运营模式: - 用 Hermes Agent 7×24 监控 AI 和 Web3 领域的关键信息源 - 每天 4 次定时推送(早 8 点、午 12 点、晚 6 点、晚 10 点) - 重大事件发生时(如 OpenAI 发新品、比特币暴涨),立即额外推送 - 每周日发布一篇深度分析文章
定价: - 月卡:199 元 - 季卡:499 元(省 98 元) - 年卡:1499 元(省 889 元)
运营数据: - 第 1 个月:30 人 - 第 3 个月:120 人 - 第 6 个月:300 人 - 平均客单价:约 160 元/月(很多人买了年卡) - 月收入:300 × 160 = 48000 元
成本: - 服务器:200 元/月 - API 调用费用:500 元/月 - 总计:700 元/月
净利润:约 47000 元/月
Tips:这个案例的关键成功因素有三个:1)选对了领域(AI + Web3 都是高付费意愿人群);2)信息质量确实高(用户觉得值这个价);3)持续运营了 6 个月以上(社群需要积累口碑)。
7. 路径六:技能分发赚提成
7.1 Skills Hub 的分成机制
Hermes Agent 生态中有一个重要的组成部分——Skills Hub(技能商店)。这是一个官方或第三方维护的技能分发平台,开发者可以把自己开发的 Skill 上传到平台上,其他用户下载使用时,开发者可以获得分成。
分成模式通常有以下几种:
- 按下载付费:用户付费下载 Skill,平台抽成 20-30%,开发者拿 70-80%
- 按调用付费:Skill 免费下载,但每次调用收取一定费用(如 0.01 元/次)
- 订阅分成:用户订阅平台会员后免费使用所有 Skill,平台按调用次数给开发者分成
- 打赏模式:用户自愿给开发者打赏
Tips:Skills Hub 目前还在发展中,具体的分成政策可能会变化。建议关注官方公告,及时调整策略。同时,不要把所有鸡蛋放在一个篮子里——即使 Skills Hub 分成不高,你的 Skill 在 Hub 上曝光也能为你带来其他渠道的客户。
7.2 如何开发高质量技能
要在 Skills Hub 上获得好的收入,技能质量是核心。
高质量技能的 5 个标准:
- 解决真实问题
- 不要开发"我觉得很酷"的技能,要开发"用户真正需要"的技能
-
多去社区看看用户在问什么问题
-
开箱即用
- 用户下载后不需要复杂配置就能用
-
提供默认参数和示例
-
文档完整
- 清晰的 README,说明 Skill 的功能、用法、参数
-
至少提供一个使用示例
-
错误处理完善
- 考虑各种边界情况
-
给出友好的错误提示
-
持续更新
- 根据用户反馈迭代改进
- 及时适配 Hermes 新版本
高质量 Skill 示例结构:
# Skill: 智能邮件助手
## 功能简介
自动帮你起草、润色、回复邮件。
## 使用场景
- 快速回复客户咨询
- 润色正式商务邮件
- 批量生成营销邮件
## 使用方法
使用本 Skill 时,只需告诉 Agent: "帮我给王总写一封会议邀请邮件,时间本周五下午"
## 参数说明
| 参数 | 说明 | 默认值 |
|------|------|--------|
| tone | 语气风格 | professional |
| length | 邮件长度 | medium |
## 示例
...
## 更新日志
- v1.1: 增加中文邮件支持
- v1.0: 初始版本
7.3 技能的推广策略
酒香也怕巷子深。好的 Skill 也需要推广。
推广渠道:
- 社区展示
- 在 Hermes 社区发帖介绍你的 Skill
- 附上使用演示视频或截图
-
主动回答用户的问题
-
内容营销
- 写教程文章"如何用 XXX Skill 实现 YYY"
- 发布到知乎、CSDN、掘金等平台
-
文章末尾放上 Skill 的下载链接
-
社交媒体
- 在 Twitter/X 上发 Skill 的功能展示
- 在 B 站发使用教程视频
-
在小红书发"效率神器"推荐
-
合作推广
- 找有粉丝的 KOL 试用你的 Skill
- 提供免费授权换取推荐
- 和其他开发者互相推荐
7.4 按调用次数分成的收入模型
假设你开发了一个热门 Skill,用户量如下:
| 阶段 | 日调用次数 | 单价 | 日收入 | 月收入 |
|---|---|---|---|---|
| 初期 | 100 次 | 0.01 元 | 1 元 | 30 元 |
| 成长期 | 1000 次 | 0.01 元 | 10 元 | 300 元 |
| 成熟期 | 10000 次 | 0.01 元 | 100 元 | 3000 元 |
| 爆款期 | 50000 次 | 0.01 元 | 500 元 | 15000 元 |
当然,单价和分成比例会因平台而异。但这个模型说明了规模效应的重要性——一个爆款 Skill 的收入可以非常可观。
7.5 月收入预估:500-5000 元
收入预估(保守): - 如果你是 Skills Hub 上的活跃开发者,有 5-10 个 Skill 在线 - 每个 Skill 平均每天被调用 100-500 次 - 月收入在 500-5000 元之间
提升收入的策略: - 多开发 Skill,增加曝光面 - 关注热门需求,快速开发对应 Skill - 维护好 Skill 的评分和评论,好评越多下载越多
7.6 实操案例
案例:开发者的"邮件助手"Skill
小王开发了一个"智能邮件助手"Skill,功能包括: - 根据关键词快速生成邮件草稿 - 润色已有邮件 - 批量生成个性化邮件
推广过程: 1. 先在 Hermes 社区发帖介绍,获得 50 多个赞 2. 写了一篇知乎文章"我用 AI 把写邮件的时间从 30 分钟压缩到 3 分钟" 3. 文章获得 5000+ 阅读,带来了 200+ 下载 4. 有用户在微博推荐,又带来一波下载
收入情况: - 第一个月:200 次下载 × 5 元 = 1000 元 - 第三个月:稳定在 1000+ 次调用/天 - 月收入:约 2000 元(按调用分成)
8. 路径七:自动化任务脚本
8.1 适合个人的自动化场景
Hermes Agent 不仅可以做"大项目",也非常适合解决个人的"小痛点"。这些小痛点汇聚起来,就是一批高需求、低门槛的自动化脚本市场。
热门自动化场景:
打折监控
- 监控电商平台的商品降价(京东、淘宝、亚马逊)
- 监控机票/酒店价格波动
- 监控 Steam 游戏折扣
抢购助手
- 限量商品抢购提醒 + 自动下单(注意合规!)
- 演唱会/火车票抢票提醒
- 热门课程/活动报名提醒
数据采集
- 批量下载某类资源(图片、论文、音乐等,注意版权!)
- 定期备份某个网站的内容
- 监控竞争对手的网站更新
生活服务
- 每日天气+穿衣提醒
- 快递状态自动跟踪
- 账单到期提醒
社交自动化
- 自动回复常见问题
- 定时发送生日祝福
- 朋友圈内容定时发布
注意:开发自动化脚本时,务必遵守相关平台的使用条款和法律法规。特别是抢购类脚本,某些平台视为违规操作。建议在提供服务前明确告知客户风险,并在脚本中加入合理的使用限制(如请求频率控制)。
8.2 脚本开发与部署
下面以"商品降价监控脚本"为例,展示如何用 Hermes Agent 实现:
需求描述: 用户想买一台 MacBook Pro,但觉得现在价格太贵。希望当价格降到 12000 元以下时,立即收到微信通知。
Skill 实现:
name: price_monitor
version: "1.0"
triggers:
- schedule: "0 */2 * * *" # 每 2 小时检查一次
tasks:
- name: fetch_price
action: browser.scrape
url: "{{product_url}}"
extract:
- selector: ".price-now"
name: current_price
- name: check_threshold
action: condition.if
condition: "{{current_price}} <= {{target_price}}"
then:
- name: send_notification
action: wechat.send
message: |
🔔 降价提醒!
商品:{{product_name}}
当前价格:¥{{current_price}}
目标价格:¥{{target_price}}
快去看看吧!{{product_url}}
- name: log_alert
action: file.append
path: "./price_alerts.log"
content: "{{timestamp}} - {{product_name}} 降至 {{current_price}}\n"
else:
- name: log_check
action: file.append
path: "./price_checks.log"
content: "{{timestamp}} - 当前价格 {{current_price}},未达目标\n"
部署方式:
# 使用 cron 定时执行
# 编辑 crontab
crontab -e
# 添加以下行
0 */2 * * * cd /path/to/hermes && hermes run skill:price_monitor --config ./config.yaml
8.3 定价与销售
个人自动化脚本的定价通常比较亲民:
| 脚本类型 | 定价区间 | 说明 |
|---|---|---|
| 简单监控脚本 | 9.9-29.9 元 | 单功能、标准化 |
| 多功能脚本 | 29.9-99 元 | 组合多个功能 |
| 定制脚本 | 100-500 元 | 按需求定制 |
| 部署 + 维护服务 | 50-200 元/月 | 帮客户部署并维护 |
销售渠道: - 闲鱼:搜索"监控脚本""自动化脚本",有很多需求 - 小红书:发"省钱神器""抢购技巧"帖子,引流到私域 - V2EX/吾爱破解:技术社区,用户付费意愿强
8.4 月收入预估:1000-5000 元
收入模型: - 每个脚本定价 29.9 元 - 在闲鱼/小红书推广,每天卖出 2-5 份 - 月收入:29.9 × 3 × 30 = 2691 元
如果加上定制开发和维护服务,月收入可以稳定在 3000-5000 元。
Tips:自动化脚本这个市场有个特点——需求很分散。每个人想要监控的东西都不一样。所以尽量把脚本做得"可配置化",让用户自己填 URL、价格阈值等参数,这样一套代码可以卖给很多人。
9. 路径八:企业内部工具开发
9.1 企业需求分析
企业级市场是九条路径中客单价最高、最稳定的,但同时也是门槛最高的。
企业为什么需要 Hermes Agent?
- 降本增效
- 很多公司有大量的重复性工作(数据整理、报表生成、客服回复)
- 雇人做:月薪 5000-10000 元
-
用 Agent 做:一次性开发 5000-20000 元,之后每月运行成本几百元
-
7×24 不间断
- 人工做不到全天候监控和响应
-
Agent 可以
-
数据安全
- 企业越来越担心把数据交给第三方 SaaS
- Hermes 可以本地部署,数据不出公司内网
典型的企业需求场景:
| 场景 | 具体需求 | 预算范围 |
|---|---|---|
| 客服自动化 | 智能回复常见问题、工单自动分类 | 1-5 万 |
| 数据分析 | 多系统数据汇总、自动生成报表 | 2-10 万 |
| 内容审核 | 社交媒体评论监控、舆情分析 | 1-5 万 |
| 内部知识库 | 搭建企业知识问答系统 | 2-8 万 |
| 流程自动化 | 审批流、通知、数据同步 | 1-5 万 |
| 代码辅助 | 内部代码库问答、文档生成 | 2-10 万 |
9.2 接入公司数据库/代码库的方案
企业项目最大的技术挑战是如何安全地接入企业内部系统。
方案一:数据库只读连接
# config.yaml
data_sources:
company_db:
type: postgresql
host: "10.0.1.100" # 内网地址
port: 5432
database: "analytics"
username: "hermes_readonly" # 只读账号!
password: "${DB_PASSWORD}"
# 重要:只授予 SELECT 权限
注意:企业数据库访问必须遵循最小权限原则。给 Hermes 的数据库账号只授予 SELECT 权限,绝不要给写入权限,除非有明确的业务需求且经过安全审批。
方案二:API 中间层
# 企业内部 API 网关
from flask import Flask, jsonify
from flask_limiter import Limiter
app = Flask(__name__)
limiter = Limiter(app, key_func=lambda: "hermes")
@app.route('/api/sales_data')
@limiter.limit("100/hour") # 限速,防止过载
def get_sales_data():
# 验证请求来源
if not verify_hermes_request(request):
return jsonify({"error": "Unauthorized"}), 401
# 返回脱敏后的数据
data = query_sales_data()
return jsonify(sanitize(data))
方案三:代码库 RAG(检索增强生成)
# 企业内部代码问答系统
name: codebase_qa
knowledge_base:
type: git
repo: "https://gitlab.company.com/backend/main.git"
update_schedule: "0 2 * * *" # 每天凌晨同步
index_branches: [main, develop]
retrieval:
top_k: 5
filter:
file_types: [".py", ".js", ".java", ".md"]
exclude_paths: ["test/", "vendor/"]
9.3 安全与合规
企业项目必须重视安全与合规,否则一个数据泄露可能让你赔得倾家荡产。
安全清单:
□ 数据传输加密(HTTPS/TLS)
□ 数据库只读访问,最小权限原则
□ API 请求限速和身份验证
□ 敏感数据脱敏(手机号、身份证号等)
□ 操作日志记录(谁、何时、做了什么)
□ 定期安全审查
□ 数据不出境(如涉及跨境业务)
□ 符合等保要求(国内项目)
合同中的安全条款模板:
第 X 条 数据安全与保密
1. 乙方(开发者)承诺在项目实施过程中严格遵守甲方的数据安全管理制度。
2. 乙方不得将甲方的任何数据用于本项目之外的任何目的。
3. 项目完成后,乙方应归还或销毁所有包含甲方数据的副本。
4. 如发生数据泄露事件,乙方应承担相应的法律责任和经济赔偿。
5. 乙方应配合甲方进行安全审查和漏洞修复。
9.4 定价策略
企业项目的定价策略和个人项目完全不同。企业客户对价格不敏感,但对确定性很敏感——他们要的是"问题被解决",而不是"省钱"。
项目制定价:
| 项目规模 | 工期 | 建议报价 |
|---|---|---|
| 小型项目(单功能) | 1-2 周 | 5000-15000 元 |
| 中型项目(多模块) | 1-2 月 | 20000-50000 元 |
| 大型项目(全流程) | 2-3 月 | 50000-200000 元 |
报价构成:
总报价 = 需求分析(10%)+ 开发实施(60%)+ 测试部署(15%)+ 培训文档(10%)+ 维护预留(5%)
付款方式: - 定金 30%:合同签署后 - 中期款 40%:功能开发完成,测试通过 - 尾款 30%:上线验收后
Tips:企业客户通常需要走采购流程,付款周期可能较长(1-3 个月)。建议在合同中明确付款时间节点,并预留一定的现金流缓冲。
9.5 外包项目获取渠道
线上渠道:
- 猪八戒/一品威客
- 国内最大的外包平台
- 项目多但竞争激烈
-
新手建议从小项目开始积累评价
-
程序员客栈
- 专注技术外包
- 客单价相对较高
-
需要实名认证和技术能力验证
-
电鸭社区
- 远程工作社区
- 很多小而美的项目
-
社区氛围好,长期合作机会多
-
LinkedIn/脉脉
- 直接对接企业决策者
- 适合有经验的人
- 通过内容输出建立专业形象
线下渠道:
- 朋友介绍
- 最可靠的获客方式
-
维护好人脉关系
-
行业活动
- 参加技术大会、行业沙龙
-
主动分享自己的 Agent 应用案例
-
老客户转介绍
- 给老客户推荐奖励(如项目费的 10%)
- 做好服务,口碑是最好的营销
9.6 月收入预估:10000-50000 元
收入模型: - 每月承接 1-2 个中型项目 - 客单价 20000-30000 元 - 月收入:20000-50000 元
如果加上维护合同(每月固定收入),收入会更稳定: - 3 个老客户维护:每个 2000 元/月 = 6000 元被动收入 - 新项目:20000-40000 元 - 总计:26000-46000 元/月
9.7 实操案例
案例:为跨境电商公司搭建智能客服系统
客户背景: 某跨境电商公司,有 5 个客服,每天处理 500+ 条客户咨询。客服团队成本每月 3 万元,且夜间和周末无人值班。
解决方案: 用 Hermes Agent 搭建智能客服系统:
- 知识库搭建
- 整理常见问题和答案(退货、物流、尺码、售后)
-
接入公司内部订单系统,可查询订单状态
-
智能回复
- 80% 的常见问题由 Agent 自动回复
-
复杂问题转接人工
-
多语言支持
- 自动识别客户语言(英语、西班牙语、法语等)
-
用 LLM 自动翻译和回复
-
24 小时值班
- 夜间和周末自动接管
- 紧急问题(如投诉)立即通知人工
项目收入: - 开发费用:35000 元 - 维护费用:2000 元/月 - 客户节省成本:每月减少 2 个客服岗位 = 12000 元/月 - ROI:3 个月收回投资
Tips:这个案例最成功的点在于——我帮客户算了一笔账。不是卖"一个 AI 客服系统",而是卖"每月帮你省 12000 元"。企业客户最关心的是 ROI,你把账算清楚,成交率会大幅提高。
10. 路径九:培训与社群陪跑
10.1 课程内容设计
知识付费是永恒的刚需。当一项新技术出现时,最早赚到钱的人往往是"教别人用这项技术的人"。Hermes Agent 作为一个新兴工具,相关的培训市场需求巨大。
课程层级设计:
📚 Hermes Agent 从入门到精通课程体系
├─ L1:小白速成营(1-3 天)
│ ├─ 什么是 AI Agent,为什么要学
│ ├─ Hermes 的安装与基础配置
│ ├─ 第一个 Skill:让 Agent 帮你写周报
│ ├─ 常用的 10 个内置工具
│ └─ 课程价格:99-199 元
│
├─ L2:进阶实战营(1-2 周)
│ ├─ Skill 开发核心技巧
│ ├─ 记忆系统的深度使用
│ ├─ 多工具组合工作流
│ ├─ 实战项目:搭建个人知识助手
│ ├─ 调试与排错技巧
│ └─ 课程价格:499-999 元
│
├─ L3:高手特训营(1 个月)
│ ├─ 复杂 Skill 架构设计
│ ├─ 企业级部署方案
│ ├─ 性能优化与成本控制
│ ├─ 实战项目:从零搭建商业级应用
│ ├─ 变现指导与案例分析
│ └─ 课程价格:1999-2999 元
│
└─ L4:1v1 私教(按需)
├─ 针对个人需求的定制培训
├─ 项目实战陪跑
├─ 长期答疑和指导
└─ 课程价格:5000-20000 元
10.2 教学形式
| 形式 | 优点 | 缺点 | 适合价格 |
|---|---|---|---|
| 录播课 | 一次录制,无限售卖 | 互动性差 | 99-499 元 |
| 直播课 | 互动性强,氛围好 | 需要固定时间 | 199-999 元 |
| 小班课 | 兼顾互动和效率 | 招生需要时间 | 499-1999 元 |
| 1v1 | 效果最好 | 时间成本高 | 5000+ 元 |
| 社群陪跑 | 持续服务,用户粘性高 | 需要长期投入 | 999-4999 元 |
推荐的组合策略: - 用低价录播课引流(99 元入门课) - 用中价直播/小班课盈利(599 元实战营) - 用高价 1v1/陪跑做利润(2999 元私教)
10.3 定价策略
定价的核心原则是:价值锚定。
不要按"我付出了多少时间"定价,要按"客户能获得多少价值"定价。
| 课程类型 | 定价区间 | 价值锚点 |
|---|---|---|
| 入门录播课 | 99-199 元 | "2 小时学会,省下半个月摸索时间" |
| 实战训练营 | 499-999 元 | "学会后能接单赚钱,一单就回本" |
| 变现陪跑营 | 1999-2999 元 | "我带过的学员,平均月入 5000+" |
| 企业内训 | 5000-20000 元 | "帮团队整体提效,ROI 看得见" |
Tips:定价时有一个心理学技巧——设置一个"锚定价"。比如你想要卖 999 元的课,先展示一个 2999 元的"1v1 私教",再展示 999 元的"小班课",客户就会觉得"哇,便宜好多",下单意愿更强。
10.4 长期答疑的价值
很多做培训的人只关注"卖课",忽略了"答疑"的价值。其实,答疑本身就是最好的变现手段。
为什么? 1. 答疑的过程中,你能深入了解用户的真实痛点 2. 用户的提问是最好的内容素材("这个问题很多人问,我专门录个视频讲") 3. 高质量的答疑能建立信任,带来转介绍和复购 4. 答疑可以单独收费(如"年度答疑会员")
答疑服务的定价: - 课程附赠:7 天答疑 - 月度答疑会员:99-199 元/月 - 年度答疑会员:599-999 元/年 - 1v1 即时答疑:按小时收费,200-500 元/小时
10.5 用 Hermes 辅助教学
有趣的是,你可以用 Hermes Agent 来辅助你的教学工作,进一步提升效率:
1. 自动生成课程大纲
提示词:"请根据'AI Agent 入门'这个主题,生成一份 10 节课的课程大纲,
每节课包含学习目标、核心内容和课后作业。"
2. 自动生成练习题
提示词:"根据以下课程内容,生成 5 道选择题和 2 道实操题,
并附带答案和评分标准。"
3. 自动批改作业
提示词:"以下是学员提交的 Skill 代码,请检查是否有明显错误,
给出评分和改进建议。"
4. 智能答疑助手
你可以把常见问题和答案录入 Hermes 的知识库,
让 Agent 先回答学员的常见问题,复杂问题再转给你。
这样你可以同时服务更多人。
10.6 月收入预估:5000-50000 元
收入模型(以训练营模式为例):
假设你开设一个 599 元的实战训练营:
- 第 1 期:20 人报名 = 11980 元
- 第 2 期:30 人报名 = 17970 元
- 第 3 期:50 人报名 = 29950 元
随着口碑积累,每期人数会增长。
同时你还可以卖录播课(被动收入)和答疑会员(持续收入)。
月收入预估:
- 训练营:10000-30000 元/月
- 录播课:1000-5000 元/月
- 答疑会员:2000-10000 元/月
- 合计:13000-45000 元/月
10.7 实操案例
案例:「Agent 变现营」的开办历程
讲师背景: 小王,本职是前端工程师,业余研究 Hermes Agent 半年,通过代安装和工作流定制月入过万。
课程设计: - 定位:"不只是教技术,更教变现" - 差异化:市面上的课大多只教"怎么用",小王的课还教"怎么赚钱" - 课程形式:14 天社群陪跑(录播 + 直播 + 作业 + 答疑)
定价策略: - 早鸟价:699 元(前 20 名) - 正式价:999 元 - VIP 版:1999 元(含 1v1 指导 + 技能包合集)
推广方式: 1. 在知乎发了系列文章「我用 Hermes Agent 月入过万」 2. 文章末尾放"想了解详情,加微信" 3. 朋友圈持续发学员案例和成果 4. 第 1 期招募 30 人,两周报满
收入情况: - 第 1 期:30 人 × 699(平均)= 20970 元 - 第 2 期:50 人 × 899(平均)= 44950 元 - 第 3 期:80 人 × 999(平均)= 79920 元 - 月收入稳定在 40000-80000 元
Tips:小王的成功关键在于差异化定位。市面上的技术课很多,但"教你用 Agent 赚钱"的课很少。找到你的独特定位,客户会主动来找你。
11. 变现路径组合策略
讲完了九条路径,你可能会问:"我应该只做一条,还是同时做几条?"
答案是:组合出击,效果最佳。
11.1 初级组合:安装服务 + 技能包
适合人群: 刚入门 1-3 个月的小白
组合逻辑: - 代安装服务是"现金流业务"——每天都有收入,保证基本生活 - 技能包是"被动收入业务"——制作一次,持续销售
时间分配: - 70% 时间:代安装服务(赚钱养活自己) - 30% 时间:开发技能包(积累被动收入)
预期收入: - 代安装:2000-4000 元/月 - 技能包:500-2000 元/月 - 合计:2500-6000 元/月
Tips:这个阶段的目的是"活下去 + 练手艺"。不要急着辞职,先用业余时间测试市场。等技能包收入稳定超过 3000 元/月,再考虑加大投入。
11.2 中级组合:工作流定制 + 培训
适合人群: 有 3-6 个月经验,技术能力扎实
组合逻辑: - 工作流定制是"高客单价业务"——单个项目 3000+,收入可观 - 培训是"规模化业务"——一份时间卖多次,杠杆效应强
时间分配: - 60% 时间:工作流定制项目 - 40% 时间:准备和交付培训课程
预期收入: - 工作流定制:5000-15000 元/月 - 培训:5000-20000 元/月 - 合计:10000-35000 元/月
Tips:这个组合的关键是"案例积累"。你做的每个定制项目,都可以变成培训案例;培训的学员,又可能成为你的定制客户。两个业务相互促进,形成飞轮效应。
11.3 高级组合:数据社群 + 企业开发
适合人群: 有 6 个月以上经验,有行业资源
组合逻辑: - 数据社群是"持续性收入"——会员按月付费,现金流稳定 - 企业开发是"爆发性收入"——单个项目几万到几十万
时间分配: - 40% 时间:社群运营和内容产出 - 50% 时间:企业项目开发和交付 - 10% 时间:品牌推广和新客户拓展
预期收入: - 数据社群:10000-50000 元/月 - 企业开发:20000-100000 元/月 - 合计:30000-150000 元/月
注意:到这个级别,你已经是"超级个体"了。但收入越高,责任越大。企业客户对 SLA(服务等级协议)要求高,社群用户对内容质量要求高。建议逐步建立团队(哪怕只是兼职助理),把重复性工作外包出去。
11.4 时间分配建议
无论你选择哪种组合,都要注意时间管理的黄金法则:
每天的时间分配(以 8 小时工作制为例):
├─ 40% 时间:核心业务(直接产生收入的工作)
│ └─ 如:做项目、交付课程、服务客户
│
├─ 30% 时间:业务开发(获取新客户的工作)
│ └─ 如:发内容、回复咨询、参加社群
│
├─ 20% 时间:能力建设(提升长期竞争力)
│ └─ 如:学习新功能、开发新产品、优化流程
│
└─ 10% 时间:休息和复盘
└─ 如:整理本周得失、规划下周工作
11.5 从副业到全职的过渡策略
阶段一:探索期(1-2 个月) - 用业余时间尝试 1-2 条路径 - 目标是"验证可行性",不是"赚大钱" - 如果月收入达到 2000+,进入下一阶段
阶段二:增长期(3-6 个月) - 加大时间投入(每天 3-4 小时) - 把有效的路径做深做透 - 如果月收入稳定达到 5000+(且呈增长趋势),可以考虑下一步
阶段三:转型期(6-12 个月) - 评估副业收入是否达到主业收入的 50-80% - 开始减少主业工作时间(如申请调岗到较轻松的岗位) - 储备 6 个月的生活费作为安全垫
阶段四:全职期(12 个月以后) - 正式辞职,全职投入 - 建立系统化的工作流程 - 考虑组建小团队或外包部分工作
注意:从副业到全职是一个重大的决策,不要冲动。建议同时满足以下条件再考虑辞职: 1. 副业月收入稳定超过主业收入的 70% 2. 副业收入呈持续增长趋势(至少连续 3 个月) 3. 有至少 6 个月的生活费储备 4. 有明确的下一步发展计划
12. 变现避坑指南
12.1 常见失败原因
我观察了很多想用 AI Agent 变现的人,总结出了最常见的失败原因:
1. 光想不做 - 症状:花三个月"调研",看了 100 个教程,一个客户都没找 - 药方:先干起来!用 1 天时间发布第一个闲鱼链接,比看 100 篇攻略有用
2. 追求完美 - 症状:"等我把 Skill 做得完美了再卖"——结果永远没卖 - 药方:先发布一个"够用"的版本,根据用户反馈迭代。完美是迭代的敌人。
3. 单打独斗 - 症状:闷头开发,从不混社区,从不发内容 - 药方:至少每周在 1 个平台发 1 条内容,让更多人知道你在做什么
4. 低价竞争 - 症状:看到有人定价 9.9 元,你也定 9.9 元,结果累死还没钱赚 - 药方:差异化竞争,不要拼价格,要拼价值。你贵,但要让客户觉得"值"
5. 忽视服务 - 症状:收了钱就消失,客户有问题爱答不理 - 药方:服务是最好的营销。一个满意的客户会带来 3 个新客户。
6. 分散精力 - 症状:九条路径每条都想做,结果每条都做不深 - 药方:先聚焦 1-2 条路径,做到月收入 5000+,再考虑扩展
12.2 版权与合规问题
版权风险: - 不要把别人的 Skill 改个名字就当自己的卖 - 不要复制别人的教程/文章来引流 - 使用第三方 API 时,遵守其使用条款
合规建议:
□ 明确告知客户服务的边界和限制
□ 不承诺无法交付的结果
□ 合同中写明责任划分
□ 敏感项目(如金融建议)加上免责声明
□ 遵守数据保护法规(如个人信息保护法)
免责声明模板:
本工具/服务仅供参考,不构成任何投资、医疗、法律等专业建议。
使用本工具产生的任何决策和后果,由用户自行承担。
开发者不对因使用本工具导致的任何损失负责。
12.3 客户关系管理
变现的本质是解决客户的问题。而客户关系的维护,直接决定了你的长期收入。
客户关系维护清单:
□ 建立客户档案:记录每个客户的需求、偏好、历史交易
□ 定期回访:项目完成后 1 周、1 个月、3 个月分别回访
□ 节日问候:生日、节日发一条祝福,成本极低但效果很好
□ 超预期交付:偶尔送客户一个小功能或小技能,制造惊喜
□ 主动告知:你的产品/服务有更新时,主动通知老客户
□ 请求推荐:满意的老客户是最好的获客渠道
客户分层管理:
| 层级 | 定义 | 维护策略 |
|---|---|---|
| VIP | 消费 5000+ 或多次复购 | 1v1 维护,优先响应,专属福利 |
| 普通 | 消费 500-5000 | 定期推送有价值的内容 |
| 潜力 | 咨询过但未成交 | 持续跟进,提供试用/优惠 |
| 流失 | 很久没互动 | 发送召回优惠,了解流失原因 |
12.4 持续学习的重要性
AI 领域变化太快了。今天的热门功能,明天可能就被官方内置了;今天的赚钱路径,明天可能就有 1000 个人涌进来做。
持续学习的建议:
- 关注官方动态
- 订阅 Hermes Agent 的 Release Notes
- 关注官方 Twitter/Discord/微信群
-
新版本发布后第一时间体验
-
混迹社区
- 每天至少花 30 分钟逛社区
- 看别人在讨论什么、在问什么
-
社区的热点话题就是商业机会
-
跨界学习
- 不要只学技术,要学运营、营销、销售
- 了解你目标客户的行业知识
-
一个懂金融的开发者,比纯技术开发者更容易接到投研项目
-
实践出真知
- 每学一个新功能,立刻动手做一个项目
- 每看到一个新机会,立刻验证一下
- 理论学习占 30%,实践应用占 70%
Tips:推荐一个学习方法——费曼学习法。每学一个新概念,试着用最简单的语言讲给别人听(或写成一篇教程)。如果你能讲清楚,说明你真的懂了;如果讲不清楚,说明还有盲区。
本章小结
好了,这一章我们一口气讲完了 Hermes Agent 的九大变现路径。来回顾一下核心要点:
九条路径速记卡:
| 路径 | 核心关键词 | 适合谁 |
|---|---|---|
| 代安装服务 | 零门槛、快变现 | 所有人 |
| 工作流定制 | 高客单、靠技术 | 有基础者 |
| 技能包销售 | 被动收入、规模化 | 所有人 |
| 自动化内容 | 流量变现、长期主义 | 内容创作者 |
| 付费数据社群 | 高天花板、需运营 | 行业从业者 |
| 技能分发 | 生态红利、持续分成 | 开发者 |
| 自动化脚本 | 小痛点、走量 | 技术爱好者 |
| 企业工具开发 | 高客单、稳定 | 有经验者 |
| 培训陪跑 | 知识变现、杠杆大 | 表达能力强 |
最重要的三条建议:
-
先干起来:不要等"准备好了"再开始。发布第一个闲鱼链接、写第一篇小红书、录第一个视频——行动是最好的老师。
-
聚焦深耕:九条路径都很好,但你不可能同时做九条。选 1-2 条最适合你的,做到月收入 5000+,再考虑扩展。
-
持续迭代:市场在变,技术在变,你的策略也要变。每三个月复盘一次,淘汰无效的,加码有效的。
最后送大家一句话:
Hermes Agent 是一个强大的杠杆,但杠杆本身不产生价值——产生价值的是使用杠杆的人。工具再好,不用就是废铁;路径再对,不做就是空谈。
现在就打开你的电脑,开始第一步吧!
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十五章:Hermes 社区生态与资源
本章你将学到: - Hermes 社区的整体面貌和文化氛围 - 官方和中文社区的各类资源入口 - 四条针对不同人群的学习路径 - 如何参与社区贡献(提 Issue、交 PR、贡献技能) - 20-30 个精选生态项目推荐 - 25 个最常见问题的解答
1. Hermes 社区全景
1.1 社区规模与活跃度
如果说 Hermes Agent 是一棵正在茁壮成长的树,那么社区就是滋养它的土壤。没有活跃的社区,再好的技术也只是一潭死水。
截止到 2026 年中,Hermes Agent 社区已经发展成了一个相当有活力的生态:
| 指标 | 数据(约) |
|---|---|
| GitHub Stars | 15,000+ |
| Discord 成员 | 8,000+ |
| 中文微信群/飞书群 | 20+ 个群,覆盖 5000+ 人 |
| 技能商店 Skills | 300+ 个 |
| 生态项目 | 100+ 个 |
| 活跃贡献者 | 200+ 人 |
这些数据放在整个 AI Agent 领域来看,虽然比不上 AutoGPT、LangChain 这些"老牌明星",但考虑到 Hermes Agent 是后起之秀,这个增长速度已经相当可观了。
Tips:判断一个开源项目是否值得投入时间,最重要的指标不是 Star 数,而是活跃度。建议你去 GitHub 看看最近一个月的 Commit 频率、Issue 的响应速度、PR 的合并速度——这些才是真正的健康指标。
1.2 核心贡献者与维护团队
Hermes Agent 最初由 Nous Research 发起和维护。Nous Research 是一家专注于开源 AI 研究的机构,在 AI 社区中颇有声望。
核心维护团队包括: - 创始人/核心架构师:负责整体技术路线和产品方向 - 核心开发者:负责主要模块的开发和维护 - 社区经理:负责协调社区活动、处理社区事务 - 文档维护者:负责官方文档的撰写和更新
除了官方团队,社区中还涌现了一大批明星贡献者: - 开发高质量 Skill 的"技能大神" - 写教程、做视频的"布道者" - 回答新手问题的"热心老哥" - 提交 Bug 修复和功能改进的"代码侠客"
注意:开源社区是" Meritocracy "( meritocracy 精英制)——你的影响力不取决于你的头衔,而取决于你的贡献。一个刚入门的新手,如果提交了一个高质量的 PR,同样会受到社区的尊重。
1.3 社区文化与价值观
每个社区都有自己的"气质"。Hermes 社区的文化可以概括为几个关键词:
"Stay Lazy, Stay Early" 这是 Hermes 社区最流行的 Slogan。什么意思呢? - Stay Lazy:用 AI 自动化一切能自动化的工作,把精力留给真正重要的事 - Stay Early:保持对新事物的敏感度,做早期采用者(Early Adopter)
开放与分享 社区鼓励成员分享自己的 Skill、工作流和经验。你会发现,很多大神会毫无保留地开源自己的项目——因为在 Hermes 社区,"分享"本身就是一种声望积累。
务实主义 Hermes 社区不太喜欢"空谈概念",更喜欢"动手实干"。一个能用的 Demo 比一百页 PPT 更有说服力。
包容新手 虽然社区里有很多技术大牛,但对待新手的态度非常友好。你可以在 Discord 或微信群里问任何"傻问题",通常都会有人耐心解答。
常见问题:我英语水平不好,能参与国际社区吗?
当然可以!Hermes 社区对非英语母语者非常包容。你可以在 Discord 的中文频道交流,也可以先用翻译工具辅助阅读。事实上,社区里有很多来自中国的活跃贡献者。
2. 官方资源大全
2.1 GitHub 仓库
地址:https://github.com/NousResearch/hermes-agent
GitHub 是 Hermes 的大本营,所有源代码、Release 版本、Issue 讨论都在这里。
仓库结构速览:
hermes-agent/
├── README.md # 项目介绍和快速开始
├── docs/ # 官方文档
├── src/ # 核心源代码
├── skills/ # 内置技能示例
├── tests/ # 测试用例
├── examples/ # 使用示例
├── CONTRIBUTING.md # 贡献指南
├── LICENSE # 开源协议
└── pyproject.toml # 项目配置
新手必看的几个页面: 1. README.md:项目的"门面",包含安装指南和快速开始 2. Releases 页面:下载稳定版本,查看更新日志 3. Issues 页面:搜索你遇到的问题,看看有没有人已经提过 4. Discussions 页面:技术讨论、使用心得交流
Tips:建议每个新手都先给 GitHub 仓库点个 Star,这样有更新时你会收到通知。同时,Watch 仓库可以及时收到 Issue 和 PR 的动态。
2.2 官方英文文档
地址:https://hermes-agent.nousresearch.com/docs/
官方文档是最权威的技术参考,涵盖: - 安装与配置指南 - 核心概念解释 - Skill 开发教程 - API 参考手册 - 高级主题(自定义工具、记忆系统、安全等)
文档使用技巧: - 左侧有目录导航,按主题查找 - 顶部有搜索框,可以直接搜索关键词 - 很多页面底部有"Edit this page"链接,可以直接提交文档改进
注意:官方文档是英文的。如果你的英文阅读有困难,可以配合浏览器翻译插件使用。同时,中文社区也有翻译版文档(见下文)。
2.3 中文社区文档
文档站 1:https://hermes-doc.aigc.green/
这是由中文社区志愿者维护的文档翻译站,内容主要来自官方文档的中文翻译,同时加入了一些中文用户特有的使用技巧。
特点: - 与官方文档结构对应,方便对照阅读 - 加入了很多中文用户的实战案例 - 更新频率较高,基本跟随官方版本
文档站 2:https://hermesagent.org.cn
这是另一个中文文档站,由不同的社区团队维护。
特点: - 界面更友好,适合纯新手 - 有很多图文并茂的教程 - 包含一些视频教程的链接
Tips:建议两个中文文档站都收藏,因为它们的侧重点不同。遇到问题时,如果一个站没找到答案,可以去另一个站试试。
2.4 官方技能商店
地址:https://hermes-agent.nousresearch.com/docs/skills
Skills Hub 是 Hermes 官方的 Skill 分发平台。你可以在这里: - 发现和下载社区贡献的 Skill - 上传自己开发的 Skill - 查看 Skill 的使用统计和评分
如何使用 Skills Hub:
# 从 Skills Hub 安装 Skill
hermes skill install author/skill-name
# 查看已安装的 Skill
hermes skill list
# 更新 Skill
hermes skill update skill-name
2.5 Hermes Atlas(生态地图)
地址:https://hermes-ecosystem.vercel.app
Hermes Atlas 是一个可视化生态地图,展示了整个 Hermes 生态系统的项目分布。
Atlas 上可以看到: - 各类生态项目的分类和介绍 - 项目之间的关联关系 - 热门项目排行榜 - 最新加入的项目
Tips:Atlas 是发现新项目的好地方。建议每个月去逛一次,看看有没有什么新工具可以试用。
2.6 Awesome 资源列表
地址:https://github.com/0xNyk/awesome-hermes-agent
这是一个社区维护的 Awesome List,收集了大量与 Hermes 相关的优质资源。
列表包含: - 官方资源 - 社区项目 - 教程和文章 - 工具和插件 - 视频和播客
Tips:Awesome List 是开源社区的传统。几乎每个热门项目都有一个对应的 Awesome List,是快速了解生态全貌的好工具。
2.7 橙皮书(花叔)
地址:https://www.huasheng.ai/orange-books/hermes-agent/
橙皮书是由社区知名贡献者"花叔"编写的一系列 Hermes Agent 教程和指南。
特点: - 中文原创,语言通俗易懂 - 有很多实战案例和踩坑经验 - 更新频繁,紧跟版本变化
Tips:花叔的橙皮书是很多中文用户的"入门圣经"。如果你刚接触 Hermes,建议先从橙皮书看起。
2.8 Release Notes 与 Changelog
位置: GitHub 仓库的 Releases 页面
每次新版本发布时,官方都会发布详细的 Release Notes,包含: - 新增功能 - Bug 修复 - 性能改进 - 破坏性变更(Breaking Changes) - 升级指南
注意:升级 Hermes 版本前,务必阅读 Release Notes 中的 Breaking Changes 部分。有些升级可能需要你修改配置文件或 Skill 代码。
3. 中文社区资源
3.1 中文文档站
除了前面提到的两个中文文档站(hermes-doc.aigc.green 和 hermesagent.org.cn),还有一些其他的中文资源:
Notion 知识库 部分社区成员会维护 Notion 知识库,收集整理各类教程和资料。这些知识库通常通过微信群或飞书群分享。
语雀文档 一些团队使用语雀维护 Hermes 相关的文档和教程,搜索"Hermes Agent"可以找到不少。
3.2 微信群与飞书群
中文社区最活跃的交流场所在微信群和飞书群。
如何加入: 1. 关注 Hermes 相关的公众号或小红书账号 2. 通常会在文章末尾放群二维码或邀请方式 3. 也可以去 GitHub Discussions 的中文板块询问
群里的日常: - 新手提问(安装、配置、报错) - 使用技巧分享 - 新功能讨论 - 项目展示和招聘
Tips:进群后建议先潜水观察几天,了解群里的氛围和规则。提问前先搜索聊天记录,很可能你的问题已经有人问过。
常见问题:群里消息太多,看不过来怎么办?
建议:1)屏蔽群消息,每天固定时间翻看;2)利用微信的"搜一搜"功能,直接搜索关键词;3)把群里的精华内容收藏或转发到"文件传输助手"保存。
3.3 知乎专栏与文章
知乎上有很多关于 Hermes Agent 的优质内容。
搜索关键词: - "Hermes Agent" - "Hermes AI Agent" - "Nous Research Hermes"
常见的文章类型: - 入门教程 - 使用心得 - 与其他 Agent 框架的对比 - 变现经验分享
Tips:知乎的文章质量参差不齐。建议优先看那些点赞数高、评论区活跃的,通常质量更有保障。
3.4 B站教程视频
B站是中文互联网最好的学习平台之一,上面有不少 Hermes Agent 的教程视频。
推荐搜索: - "Hermes Agent 教程" - "Hermes Agent 安装" - "AI Agent 入门"
视频内容通常包括: - 安装部署演示 - Skill 开发教学 - 实战项目案例 - 工具对比评测
Tips:B站视频的优势是"可视化"——你可以跟着屏幕操作,对新手特别友好。缺点是信息密度较低,一个 10 分钟能讲完的内容,视频可能要 30 分钟。建议视频 + 文字教程结合使用。
3.5 小红书教程
小红书上关于 Hermes 的内容越来越多,以图文形式为主。
常见的帖子类型: - "AI Agent 入门指南" - "Hermes 安装避坑" - "用 Hermes 实现 XXX" - "AI 副业赚钱"
注意:小红书上的内容偏"轻量",适合了解概貌和获取灵感。但深入的技术细节,建议还是看官方文档或 B站教程。
3.6 公众号推荐
以下是一些经常发布 Hermes 相关内容的公众号(仅供参考,请自行搜索关注):
| 公众号 | 内容特点 |
|---|---|
| 鲲鹏Talk | Hermes 系列教程、变现经验 |
| 花叔的 AI 笔记 | 橙皮书作者,技术干货 |
| AIGC 开放社区 | AI 工具资讯,含 Hermes |
| 机器之心 | AI 行业新闻 |
Tips:公众号内容比较碎片化,适合作为"信息补充",不适合作为系统学习的主渠道。
4. 学习路径推荐
不同的人有不同的背景和目标,因此需要不同的学习路径。下面为你设计了四条路径,请对号入座。
4.1 路径一:零基础快速入门(1-3 天)
适合人群: - 完全不懂编程的小白 - 想快速体验 Hermes 的能力 - 时间有限,想先有个感性认识
学习目标: - 成功安装并运行 Hermes Agent - 体验 3-5 个内置 Skill - 了解 Hermes 能做什么、不能做什么
学习清单:
Day 1:安装与初体验
├─ [30 分钟] 阅读官方 README,了解 Hermes 是什么
├─ [2 小时] 按照官方文档完成安装(Docker 方式推荐)
├─ [30 分钟] 配置 API Key,测试第一个对话
└─ [1 小时] 尝试 3 个内置 Skill(搜索、计算、文件读取)
Day 2:探索与玩耍
├─ [1 小时] 去 Skills Hub 下载 2-3 个感兴趣的社区 Skill
├─ [2 小时] 跟着一个教程视频,完成一个小项目
└─ [1 小时] 在社区群里看别人在讨论什么,了解使用场景
Day 3:总结与规划
├─ [1 小时] 整理你学到的内容,写一个学习笔记
├─ [1 小时] 思考:Hermes 能在你的工作/生活中解决什么问题?
└─ [1 小时] 制定下一步学习计划
推荐资源: - 橙皮书入门篇 - B站"Hermes 安装教程"类视频 - 官方 Quick Start 文档
Tips:这个阶段的目标是"跑起来",不要纠结原理。安装过程中遇到问题很正常,去群里问或者搜 Issue,90% 的问题都有人遇到过。
4.2 路径二:系统性学习(1-2 周)
适合人群: - 有一定技术基础(会一点 Python 或用过命令行) - 想系统掌握 Hermes 的使用和开发 - 目标是能独立开发 Skill 或工作流
学习目标: - 深入理解 Hermes 的核心架构 - 掌握 Skill 的开发和调试 - 能独立完成一个中等复杂度的项目
学习清单:
Week 1:核心概念与基础开发
Day 1-2:架构理解
├─ 阅读核心架构文档
├─ 理解 Agent、Skill、Tool、Memory 的关系
└─ 了解配置文件的各个参数含义
Day 3-4:Skill 开发入门
├─ 学习 Skill 的文件结构和语法
├─ 跟着教程写第一个简单 Skill
└─ 学习调试技巧(日志、断点)
Day 5-6:工具集成
├─ 了解内置工具的种类和用法
├─ 学习如何调用外部 API
└─ 实践:做一个调用天气 API 的 Skill
Day 7:休息 + 复盘
Week 2:进阶与实战
Day 8-9:记忆系统
├─ 学习三层记忆系统的原理
├─ 配置和使用记忆功能
└─ 实践:做一个能记住用户偏好的 Skill
Day 10-11:工作流编排
├─ 学习多步骤任务的编排
├─ 学习条件判断和错误处理
└─ 实践:做一个多步骤的数据处理工作流
Day 12-13:实战项目
├─ 选定一个项目目标(如:个人知识助手)
├─ 从 0 到 1 完成开发
└─ 测试、优化、写文档
Day 14:总结与分享
├─ 整理项目经验
├─ 写一篇教程或录一个视频
└─ 在社区分享你的项目
推荐资源: - 官方完整文档 - 橙皮书进阶篇 - GitHub 上的示例项目 - 社区高手的 Skill 源码(最好的学习材料)
Tips:系统性学习最忌讳"只看不练"。每学一个概念,立刻动手实践。哪怕只是改改参数、试试不同的配置,也比单纯阅读效果好 10 倍。
4.3 路径三:深度技术研究(1 个月)
适合人群: - 开发者,想深入理解 Hermes 的底层实现 - 有贡献开源项目的意愿 - 目标是成为社区核心贡献者
学习目标: - 理解 Hermes 的源码架构 - 掌握自定义工具的开发 - 能为社区贡献代码或 Skill
学习清单:
Week 1:源码阅读
├─ Clone 官方仓库
├─ 阅读项目结构和主要模块
├─ 从入口开始, tracing 一次完整的请求流程
└─ 理解核心类的职责和交互
Week 2:工具开发
├─ 学习 Tool 的接口规范
├─ 开发一个自定义 Tool(如连接某个特定 API)
├─ 学习测试方法,写单元测试
└─ 提交 PR 到社区(如果被合并,成就感爆棚)
Week 3:高级主题
├─ 自定义模型接入(本地模型、私有模型)
├─ 性能优化(并发、缓存、成本控制)
├─ 安全与权限管理
└─ 企业级部署方案
Week 4:贡献与输出
├─ 选择一个社区 Issue 解决
├─ 或开发一个高质量的 Skill 提交到 Skills Hub
├─ 写一篇深度技术文章
└─ 参与社区讨论,建立影响力
推荐资源: - 源码本身(最好的老师) - 官方架构文档 - 社区的技术讨论帖 - 相关论文(如 ReAct、CoT 等 Agent 相关论文)
Tips:读源码时,不要试图一次性理解所有代码。先抓主干、看流程,再逐步深入细节。善用 IDE 的"跳转到定义"和"查找引用"功能。
4.4 路径四:从 OpenClaw 迁移(1-3 天)
适合人群: - 之前用过 OpenClaw 或其他类似框架 - 想迁移到 Hermes,但不知道怎么做
学习目标: - 理解 Hermes 和 OpenClaw 的异同 - 完成项目迁移 - 掌握 Hermes 特有的优势功能
学习清单:
Day 1:对比与评估
├─ 阅读 Hermes vs OpenClaw 的对比文章
├─ 列出你当前 OpenClaw 项目的功能清单
├─ 评估每个功能在 Hermes 中的对应实现
└─ 制定迁移计划
Day 2:迁移实践
├─ 安装 Hermes
├─ 迁移核心功能(先迁最重要的)
├─ 测试对比,确保功能一致
└─ 记录迁移过程中的问题和解决方案
Day 3:优化与增强
├─ 利用 Hermes 特有的功能优化项目
├─ 整理迁移经验,写成文档
└─ 考虑是否把经验分享到社区
Hermes vs OpenClaw 核心差异:
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 安装复杂度 | 较复杂 | 简单(Docker 一键部署) |
| 配置文件 | 较繁琐 | 更简洁直观 |
| Skill 生态 | 较小 | 更活跃,Skills Hub 丰富 |
| 记忆系统 | 基础 | 三层记忆,更强大 |
| 社区活跃度 | 一般 | 更活跃 |
| 中文支持 | 较弱 | 更好 |
Tips:迁移时不要追求"一次性完美迁移"。先让核心功能跑起来,再逐步优化。迁移过程中遇到 API 差异,多在社区搜索或提问。
5. 社区参与指南
5.1 如何提 Issue
GitHub Issue 是报告 Bug、请求新功能、提出问题的主要渠道。
提 Issue 的正确姿势:
# Bug 报告模板
## 问题描述
[清楚描述你遇到的问题]
## 复现步骤
1. [第一步]
2. [第二步]
3. [第三步]
## 期望结果
[你希望发生什么]
## 实际结果
[实际发生了什么,附上完整的错误信息]
## 环境信息
- Hermes 版本:[如 1.2.3]
- 操作系统:[如 macOS 14.1]
- Python 版本:[如 3.11.4]
- 模型:[如 GPT-4]
## 附加信息
[截图、日志文件、相关配置等]
Tips:提 Issue 前先搜索一下,确认没有重复的问题。一个好的 Issue 应该让维护者能快速理解并复现问题——信息越完整,解决速度越快。
常见问题:我提的 Issue 没人回复怎么办?
开源维护者都是志愿者,有自己的本职工作。通常: - Bug 报告:1-7 天内会有回复 - 功能请求:可能需要几周甚至更久 - 使用问题:建议在 Discussions 板块提问,而不是开 Issue
如果 Issue 长时间没回复,可以礼貌地 Bump 一下(在评论里补充新信息或询问进展)。
5.2 如何提交 PR
Pull Request(PR)是向项目贡献代码的方式。
PR 流程:
# 1. Fork 官方仓库到自己的账号
# 在 GitHub 页面上点击 Fork 按钮
# 2. Clone 你 Fork 的仓库
git clone https://github.com/你的用户名/hermes-agent.git
cd hermes-agent
# 3. 创建新分支
git checkout -b fix-some-bug
# 4. 修改代码
# ... 编辑文件 ...
# 5. 提交更改
git add .
git commit -m "fix: 修复了 XXX 问题"
# 6. 推送到你的仓库
git push origin fix-some-bug
# 7. 在 GitHub 上发起 Pull Request
PR 注意事项: - 每个 PR 只解决一个问题,不要混多个改动 - 写清楚 PR 描述,说明改了什么、为什么改 - 确保代码通过了测试 - 遵守项目的代码风格(通常有 lint 检查) - 对维护者的 review 意见保持开放态度
Tips:第一次贡献可以从简单的开始,比如: - 修复文档中的错别字 - 补充某个函数的注释 - 增加一个简单的测试用例
小 PR 更容易被快速合并,也能帮你熟悉流程。
5.3 如何贡献技能
贡献 Skill 是参与 Hermes 社区最轻松也最有价值的方式之一。
Skill 贡献流程:
1. 开发你的 Skill
├─ 确保 Skill 功能完整、测试通过
├─ 写好 README,包含使用说明和示例
└─ 遵守 Skill 命名和格式规范
2. 上传到 Skills Hub
├─ 注册 Skills Hub 账号
├─ 填写 Skill 信息(名称、描述、标签等)
├─ 上传 Skill 文件
└─ 提交审核
3. 推广你的 Skill
├─ 在社区分享你的 Skill
├─ 写一篇使用教程
└─ 收集用户反馈,持续迭代
高质量 Skill 的评判标准: - 解决真实问题 - 开箱即用,配置简单 - 文档完整,示例丰富 - 错误处理完善 - 代码规范,易于维护
5.4 如何参与文档翻译
文档翻译是帮助中文社区发展的绝佳方式,而且门槛很低——不需要会编程,只要会中英双语即可。
参与方式: 1. 去中文文档站(如 hermes-doc.aigc.green)查看如何参与 2. 或者直接去 GitHub 文档仓库找 "help wanted" 或 "translation" 标签的 Issue 3. 认领一页或一节,翻译后提交 PR
翻译注意事项: - 保持技术术语的准确性 - 中文表达要通顺自然,不要直译 - 代码块和命令不需要翻译 - 保持原文的格式和结构
Tips:翻译过程中,如果遇到不确定的术语,可以去社区群里问问大家的习惯译法。统一术语翻译对文档质量非常重要。
5.5 社区行为准则
参与社区时,请遵守以下基本准则:
要做的(Do's): - 友好、尊重地与其他成员交流 - 分享你的知识和经验 - 对他人的贡献表示感谢 - 在提问前先搜索和尝试 - 提供具体、完整的信息
不要做的(Don'ts): - 不要人身攻击或嘲讽他人 - 不要发广告或垃圾信息 - 不要重复提问(尤其是在短时间内) - 不要泄露他人的隐私信息 - 不要要求维护者"立刻"解决你的问题
Tips:社区是一个"给予"的地方。你帮助别人的越多,别人帮助你的也越多。即使是新手,也可以回答比自己更新手的问题——教学相长。
6. 生态项目推荐
Hermes 生态中有大量的第三方项目,下面按分类为你推荐一些值得关注的项目。
6.1 记忆扩展类
| 项目名称 | 简介 | 推荐指数 | 链接 |
|---|---|---|---|
| hermes-memory-enhancer | 增强型记忆管理,支持更复杂的记忆检索 | ★★★★☆ | GitHub |
| long-term-memory-store | 长期记忆存储方案,支持大规模数据 | ★★★★☆ | GitHub |
| memory-visualizer | 记忆可视化工具,直观查看 Agent 的记忆内容 | ★★★☆☆ | GitHub |
| chroma-hermes-adapter | ChromaDB 适配器,向量存储优化 | ★★★★☆ | GitHub |
6.2 工具增强类
| 项目名称 | 简介 | 推荐指数 | 链接 |
|---|---|---|---|
| hermes-web-search-plus | 增强版网页搜索,支持更多搜索引擎 | ★★★★★ | GitHub |
| browser-automation-pro | 高级浏览器自动化,支持复杂交互 | ★★★★☆ | GitHub |
| file-processing-kit | 文件处理工具集(PDF、Excel、图片等) | ★★★★☆ | GitHub |
| api-connector-hub | 预置的常用 API 连接器(天气、翻译、邮件等) | ★★★★★ | GitHub |
| hermes-data-visualizer | 数据可视化工具,自动生成图表 | ★★★★☆ | GitHub |
6.3 平台集成类
| 项目名称 | 简介 | 推荐指数 | 链接 |
|---|---|---|---|
| hermes-wechat-connector | 微信接入方案,支持公众号和群聊 | ★★★★★ | GitHub |
| hermes-slack-integration | Slack 机器人集成 | ★★★★☆ | GitHub |
| hermes-discord-bot | Discord 机器人 | ★★★★☆ | GitHub |
| hermes-telegram-bot | Telegram 机器人 | ★★★★☆ | GitHub |
| hermes-feishu-connector | 飞书接入方案 | ★★★★☆ | GitHub |
| hermes-dingtalk-connector | 钉钉接入方案 | ★★★★☆ | GitHub |
6.4 开发工具类
| 项目名称 | 简介 | 推荐指数 | 链接 |
|---|---|---|---|
| hermes-skill-devkit | Skill 开发脚手架,快速创建新项目 | ★★★★★ | GitHub |
| hermes-debugger | 可视化调试工具,追踪 Agent 执行流程 | ★★★★★ | GitHub |
| hermes-config-validator | 配置文件校验工具,提前发现配置错误 | ★★★★☆ | GitHub |
| skill-testing-framework | Skill 自动化测试框架 | ★★★★☆ | GitHub |
| hermes-cli-extensions | CLI 命令扩展,增强命令行体验 | ★★★☆☆ | GitHub |
6.5 监控运维类
| 项目名称 | 简介 | 推荐指数 | 链接 |
|---|---|---|---|
| hermes-monitor | Agent 运行监控面板 | ★★★★★ | GitHub |
| hermes-logger | 增强日志系统,支持结构化日志 | ★★★★☆ | GitHub |
| cost-tracker | API 调用成本追踪与分析 | ★★★★☆ | GitHub |
| hermes-health-check | 健康检查与告警系统 | ★★★★☆ | GitHub |
| performance-profiler | 性能分析工具,找出性能瓶颈 | ★★★☆☆ | GitHub |
Tips:生态项目变化很快,上面的列表仅供参考。建议定期去 Hermes Atlas(https://hermes-ecosystem.vercel.app)查看最新项目。
常见问题:这些第三方项目安全吗?
使用第三方项目时,建议: 1. 查看项目的 Star 数和最近更新时间(太老的项目可能已废弃) 2. 阅读源码,确认没有可疑的网络请求 3. 不要在生产环境直接试用,先在测试环境验证 4. 关注社区中对该项目的评价
7. 常见问题总汇(FAQ)
本章整理了 25 个最常见的问题,按主题分类。如果你遇到了问题,先来这里找找答案。
7.1 安装相关(5 问)
Q1:安装时提示 "Docker 未启动" 怎么办?
A:请确保 Docker Desktop(Mac/Windows)或 Docker Daemon(Linux)正在运行。
# 检查 Docker 状态
docker info
# 如果未启动,手动启动
# Mac/Windows: 打开 Docker Desktop 应用
# Linux: sudo systemctl start docker
Q2:Python 版本有什么要求?
A:Hermes 需要 Python 3.10 或更高版本。
# 检查 Python 版本
python --version
# 如果版本不够,建议用 pyenv 或 conda 安装新版本
pyenv install 3.11.4
pyenv global 3.11.4
Q3:安装依赖时提示 "权限不足" 怎么办?
A:不要用 sudo 安装 Python 包,建议使用虚拟环境:
# 创建虚拟环境
python -m venv hermes-env
# 激活虚拟环境
source hermes-env/bin/activate # Linux/Mac
# 或
hermes-env\Scripts\activate # Windows
# 再安装依赖
pip install -r requirements.txt
Q4:Windows 上安装有什么特别注意的吗?
A:Windows 用户常见问题: - 建议使用 WSL2(Windows Subsystem for Linux)安装,体验更接近 Linux - 如果不用 WSL,确保安装了 Visual C++ Build Tools - 路径中避免中文和空格
Q5:安装完成后如何验证是否成功?
A:运行以下命令:
hermes --version
hermes doctor # 检查环境和配置
如果都能正常输出,说明安装成功。
7.2 使用相关(5 问)
Q6:如何修改配置文件?
A:配置文件通常位于 ~/.config/hermes/config.yaml(Linux/Mac)或 %USERPROFILE%\.config\hermes\config.yaml(Windows)。
# 用默认编辑器打开配置文件
hermes config edit
# 或手动找到并编辑
nano ~/.config/hermes/config.yaml
Q7:Agent 回复很慢怎么办?
A:可能的原因和解决方案: 1. 网络问题:检查你的网络连接,尤其是访问 API 的延迟 2. 模型选择:GPT-4 比 GPT-3.5 慢但质量高,根据场景选择 3. 工具调用太多:减少单次请求的工具调用数量 4. 本地模型:如果用本地模型,检查硬件资源(GPU/内存)
Q8:如何查看运行日志?
A:
# 实时查看日志
hermes logs -f
# 查看最近 100 行
hermes logs --tail 100
# 查看某个 Skill 的日志
hermes logs --skill skill-name
Q9:如何备份和迁移我的配置?
A:Hermes 的配置和记忆数据都在配置目录中:
# 备份
cp -r ~/.config/hermes ~/hermes-backup
# 迁移到新机器
cp -r ~/hermes-backup ~/.config/hermes
Q10:如何停止正在运行的任务?
A:
# 查看运行中的任务
hermes task list
# 停止指定任务
hermes task stop <task-id>
# 停止所有任务
hermes task stop-all
7.3 模型相关(5 问)
Q11:支持哪些模型?
A:Hermes 支持多种模型: - OpenAI:GPT-4、GPT-4o、GPT-3.5-turbo - Anthropic:Claude 3/3.5 系列 - DeepSeek:DeepSeek-V2/V3 - 本地模型:通过 Ollama、vLLM 等接入 - 其他:任何兼容 OpenAI API 格式的服务
Q12:API Key 怎么申请?
A: - OpenAI:https://platform.openai.com/api-keys - Anthropic:https://console.anthropic.com/ - DeepSeek:https://platform.deepseek.com/
注意:API Key 是收费服务,请妥善保管,不要在公开场合泄露。
Q13:使用本地模型怎么配置?
A:以 Ollama 为例:
# config.yaml
model:
provider: ollama
base_url: "http://localhost:11434"
model: "llama3.1:8b"
Q14:API 调用费用大概多少?
A:取决于你的使用量和选择的模型: - GPT-3.5:约 0.002 美元/1K tokens - GPT-4:约 0.03 美元/1K tokens - Claude 3.5 Sonnet:约 0.003 美元/1K tokens - 本地模型:电费成本,几乎为零
一个普通用户轻度使用,每月 API 费用通常在 10-50 元人民币。
Q15:如何选择合适的模型?
A:选择建议: - 日常对话/简单任务:GPT-3.5 或 DeepSeek(便宜且够用) - 复杂推理/代码任务:GPT-4o 或 Claude 3.5 Sonnet - 隐私敏感场景:本地模型(Llama、Qwen 等) - 追求性价比:DeepSeek-V3、Claude 3 Haiku
7.4 技能相关(5 问)
Q16:Skill 文件放在哪里?
A:
# 用户级 Skill 目录
~/.config/hermes/skills/
# 项目级 Skill 目录
./skills/ # 项目根目录下
Q17:如何调试 Skill?
A:
# 以调试模式运行 Skill
hermes run skill:my-skill --debug
# 查看详细日志
hermes run skill:my-skill --verbose
# 逐步执行(交互式)
hermes run skill:my-skill --step
Q18:Skill 里怎么引用环境变量?
A:
# 在 Skill 文件中使用环境变量
api_key: "${MY_API_KEY}"
base_url: "${API_BASE_URL|https://default.example.com}" # 带默认值
Q19:Skill 执行出错如何排查?
A:排查步骤: 1. 检查 Skill 语法(YAML 缩进是否正确) 2. 查看错误日志,定位出错的步骤 3. 检查工具参数是否正确 4. 确认 API Key 和权限有效 5. 在 GitHub Issues 搜索类似错误
Q20:如何分享我的 Skill 给别人?
A:
# 导出 Skill
hermes skill export my-skill -o ./my-skill.zip
# 对方导入
hermes skill import ./my-skill.zip
# 或上传到 Skills Hub,对方直接安装
hermes skill install 你的用户名/my-skill
7.5 其他(5 问)
Q21:Hermes 和 LangChain 有什么区别?
A: | 维度 | Hermes | LangChain | |------|--------|-----------| | 定位 | 面向终端用户的 Agent 框架 | 面向开发者的 LLM 应用框架 | | 使用难度 | 较低,配置驱动 | 较高,需要编程 | | 目标用户 | 个人用户、小型团队 | 开发者、企业 | | Skill 生态 | 内置 Skill 商店 | 主要通过代码集成 | | 部署方式 | 本地/服务器均可 | 主要在应用中集成 |
简单说:如果你是想"用"Agent,选 Hermes;如果你是想"开发"Agent 应用,两者都可以。
Q22:Hermes 是免费的吗?
A:Hermes 本身是开源免费的(MIT 协议)。但使用过程中可能产生: - API 调用费用(付给模型提供商) - 服务器费用(如果你部署在云上) - 部分第三方 Skill 可能收费
Q23:如何更新 Hermes 到最新版本?
A:
# 如果是 pip 安装
pip install -U hermes-agent
# 如果是 Docker 部署
docker pull nousresearch/hermes-agent:latest
注意:升级前请备份配置文件,并阅读 Release Notes。
Q24:遇到问题去哪求助?
A:按优先级: 1. 官方文档:最权威 2. GitHub Issues:搜索是否有人遇到过 3. Discord/微信群:实时交流 4. 知乎/B站:可能有教程 5. 直接提问:在 Discord 或 GitHub Discussions 提问
Q25:我想为 Hermes 做贡献,但不知道从何开始?
A:建议路径: 1. 先用 Hermes 做几个项目,熟悉它 2. 去 GitHub Issues 找标有 "good first issue" 的问题 3. 从文档改进、Bug 修复等小贡献开始 4. 逐步过渡到功能开发和 Skill 贡献 5. 积极参与社区讨论,建立影响力
本章小结
这一章我们全面梳理了 Hermes 的社区生态和学习资源。来回顾一下重点:
资源地图速查:
| 资源类型 | 地址/方式 |
|---|---|
| 源代码 | https://github.com/NousResearch/hermes-agent |
| 英文文档 | https://hermes-agent.nousresearch.com/docs/ |
| 中文文档 | https://hermes-doc.aigc.green/ |
| 中文文档2 | https://hermesagent.org.cn |
| 技能商店 | https://hermes-agent.nousresearch.com/docs/skills |
| 生态地图 | https://hermes-ecosystem.vercel.app |
| Awesome 列表 | https://github.com/0xNyk/awesome-hermes-agent |
| 橙皮书 | https://www.huasheng.ai/orange-books/hermes-agent/ |
| 社区交流 | Discord、微信群、飞书群 |
学习路径选择: - 完全小白 → 路径一(1-3 天快速入门) - 有技术基础 → 路径二(1-2 周系统学习) - 开发者 → 路径三(1 个月深度研究) - OpenClaw 用户 → 路径四(1-3 天迁移)
社区参与方式(从易到难): 1. 在社区提问和回答问题 2. 分享使用经验和教程 3. 贡献文档翻译 4. 上传 Skill 到 Skills Hub 5. 提交 Bug 修复的 PR 6. 开发新功能并提交 PR
最后想说的是:
开源社区的力量在于每一个人。你今天得到帮助,明天也可以帮助别人。哪怕只是回答一个新手的"傻问题",也是在为社区添砖加瓦。
Stay Lazy, Stay Early —— 但别忘了 Stay Helpful。
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!
第十六章:未来展望与总结
本章你将学到: - AI Agent 行业未来 1-2 年的发展趋势 - Hermes Agent 可能的演进方向 - "养马"文化的深层意义和未来形态 - 针对不同读者的行动建议 - 完整命令参考表和配置参数参考
1. AI Agent 行业趋势展望
1.1 2026 下半年到 2027 年的发展预测
站在 2026 年的中点回望,AI Agent 的发展速度已经超出了大多数人的预期。如果用一个词来形容,那就是——加速。
让我们先简单回顾一下 Agent 的发展时间线:
2023 年:概念萌芽期
├─ AutoGPT 横空出世,让人们第一次见识到"AI 自主行动"的可能性
├─ 但体验粗糙,成功率低,更多是"玩具"而非"工具"
└─ 投资者和开发者开始关注 Agent 赛道
2024 年:框架爆发期
├─ LangChain、LlamaIndex 等框架成熟
├─ ReAct、CoT 等 Agent 架构被广泛采用
├─ 大量初创公司涌入,各种 Agent 产品涌现
└─ "Agent"成为 AI 领域最热的 buzzword
2025 年:应用落地期
├─ 从"炫技"走向"实用",真正解决业务问题
├─ 企业开始尝试将 Agent 集成到工作流程中
├─ MCP(Model Context Protocol)协议出现
└─ 头部玩家格局初现
2026 年(上半年):生态成型期
├─ Hermes、Manus 等产品获得大量用户
├─ Skill 生态和社区蓬勃发展
├─ 变现模式逐渐清晰
└─ "超级个体"概念被广泛接受
那么,接下来的 2026 下半年到 2027 年,会发生什么?
预测一:Agent 将从"工具"进化为"同事"
现在的 Agent 更像是"高级工具"——你告诉它做什么,它去做。但未来的 Agent 会更像"同事"——它会主动观察、主动建议、主动协作。
想象一下这个场景: - 早上你打开电脑,Agent 告诉你:"昨晚竞品降价了,我建议我们也调整一下定价策略" - 你正在写报告,Agent 说:"根据最新数据,第三季度的预测可能需要修正,我跑了三种模型,这是结果" - 你忘了回复客户的邮件,Agent 提醒你:"这封邮件已经 24 小时未回复,建议优先级处理"
这不是科幻,这就是 Agent 的下一个阶段——从被动执行到主动协作。
预测二:多 Agent 协作成为标配
单个 Agent 的能力再强,也有边界。但多个 Agent 协作起来,就能完成极其复杂的任务。
未来的工作场景可能是这样: - 研究 Agent:负责收集和分析信息 - 写作 Agent:负责生成内容初稿 - 审查 Agent:负责检查错误和合规性 - 发布 Agent:负责推送和分发
这四个 Agent 协作完成一篇行业分析报告,全程不需要人类干预。人类只需要在最后确认一下即可。
Tips:如果你现在就在用 Hermes,可以尝试搭建一个简单的"多 Agent 协作"工作流。虽然 Hermes 目前主要还是单 Agent 架构,但通过 Skill 的组合和编排,已经可以实现初步的多步骤协作。提前熟悉这个概念,未来会很有优势。
预测三:Agent 的"数字身份"化
现在的 Agent 是"通用"的——每个人的 Agent 都差不多。但未来的 Agent 会有强烈的"个人特色"。
你的 Agent 会: - 记住你的所有偏好和习惯 - 学习你的写作风格和沟通方式 - 了解你的业务逻辑和决策模式 - 甚至继承你的"价值观"(比如保守型 vs 激进型)
最终,你的 Agent 会成为你的数字分身——它不是"一个工具",而是"你的一部分"。
1.2 自学习 Agent 将成为主流
目前的 Agent 还有一个明显的短板:不会自己进步。
你现在教了 Agent 一个技能,它会用了。但如果这个技能的用法需要调整,或者外部环境变了,你需要手动去更新 Skill。Agent 自己不会"总结经验"、"发现规律"、"优化策略"。
但这种情况正在改变。自学习 Agent(Self-Learning Agent)正在成为研究热点。
什么是自学习 Agent?简单说就是: - Agent 完成任务后,会自动复盘——哪里做得好?哪里可以改进? - Agent 会从自己的成功和失败中学习,调整策略 - Agent 会主动探索新的方法,而不是死板地执行预设流程
举个例子: - 现在的 Agent:你告诉它"每天早上 8 点发邮件",它就每天 8 点发 - 自学习 Agent:它发现邮件在 8 点的打开率只有 15%,在 9:30 的打开率有 45%,于是它自动调整到 9:30 发送——并且告诉你它为什么调整
这种能力一旦成熟,Agent 的价值将会跃升一个量级。
注意:自学习 Agent 也带来了新的风险。如果 Agent "学坏了"怎么办?如果它学到了错误的信息怎么办?这就引出了另一个重要话题——Agent 的对齐和安全。这个话题太大,这里不展开,但值得所有从业者关注。
1.3 模型成本持续下降的影响
AI 领域有一个铁律:能力越来越强,成本越来越低。
回顾过去两年: - 2023 年,GPT-4 的 API 费用是现在的 10 倍以上 - 2024 年,开源模型(Llama、Qwen 等)的性能追近了 GPT-4 - 2025 年,DeepSeek 等国产模型把价格打到了地板价 - 2026 年,本地模型的性能已经能满足大部分日常需求
这个趋势还会继续。
对 Agent 生态的影响:
- 门槛进一步降低
- 以前用 Agent 要考虑 API 费用,现在用本地模型几乎免费
-
更多个人用户和小团队能用得起 Agent
-
应用场景爆发
- 成本不再是限制因素,Agent 可以被部署到更多场景
-
以前"太贵不划算"的场景,现在变得可行
-
竞争加剧
- 当技术门槛和成本门槛都降低时,差异化就变得更重要
- 未来 Agent 产品的竞争,将不再是"技术"的竞争,而是"场景理解"和"用户体验"的竞争
Tips:对于 Hermes 用户来说,模型成本下降是重大利好。建议你持续关注新的模型选择,定期评估是否有更优的性价比方案。省钱就是赚钱。
1.4 MCP 协议成为行业标准
2025 年,Anthropic 提出了 MCP(Model Context Protocol)协议。这可以说是 Agent 发展史上的一个里程碑。
简单理解 MCP: - 以前,每个 Agent 框架都有自己的工具调用方式 - 开发者想集成一个外部工具,需要为每个框架写不同的适配代码 - MCP 协议就是一个"通用语言",只要工具支持 MCP,任何 Agent 都能直接调用
类比一下: - 没有 MCP 的时代:每个手机有自己的充电口(苹果 Lightning、安卓 Micro-USB、Type-C),出门要带一堆线 - 有了 MCP:统一成 Type-C,一根线走天下
MCP 的意义在于: 1. 工具生态大爆发:开发者只需要按 MCP 标准开发一次,所有 Agent 都能用 2. Agent 能力边界消失:理论上,任何支持 MCP 的工具都能被 Agent 调用 3. 用户受益:选择更多、兼容性更好、切换成本更低
Tips:Hermes 社区已经在积极拥抱 MCP 协议。如果你正在开发 Skill 或工具,建议优先考虑 MCP 兼容性。这不仅是对未来趋势的投资,也能让你的作品被更多人使用。
1.5 多 Agent 协作系统的成熟
前面提到过"多 Agent 协作",这里再深入聊一下。
目前的多 Agent 系统还处于比较初级的阶段,主要问题包括: - Agent 之间的通信机制不够成熟 - 任务分配和协调依赖人工设计 - 冲突解决机制不完善 - 调试和监控很困难
但这些问题正在被逐一攻克。
2026-2027 年,我们可能会看到:
- 标准化的多 Agent 框架
- 类似 Kubernetes 之于容器编排,会出现"Agent 编排"的标准框架
-
定义 Agent 角色、通信协议、协作模式的统一规范
-
Agent 市场(Agent Marketplace)
- 不只是 Skill 商店,而是"Agent 商店"
- 你可以购买一个"财务分析师 Agent"、一个"法律顾问 Agent"
-
这些 Agent 可以和你自己的 Agent 协作
-
人机协作的新范式
- 不再是"人指挥机器",而是"人和机器共同决策"
- Agent 提出建议,人类做最终判断
- Agent 之间协商,人类监督流程
Tips:如果你现在就在做 Hermes 相关的工作,可以有意识地培养"系统化思维"——不要只关注单个 Skill 的开发,而是思考如何让多个 Skill、多个 Agent 协同工作。这种能力在未来会非常稀缺和值钱。
2. Hermes Agent 路线图
2.1 已知的官方规划
虽然 Hermes 官方没有公布特别详细的长期路线图,但从 GitHub 的 Issue、PR 和社区的讨论中,我们可以窥见一些方向。
近期(2026 年下半年)可能的功能:
- 更强的 MCP 支持
- 原生集成 MCP 协议
- 支持直接使用社区的海量 MCP 工具
-
简化工具配置流程
-
改进的记忆系统
- 更智能的记忆检索算法
- 支持跨会话的长期记忆
-
记忆的可视化管理和编辑
-
可视化工作流编辑器
- 拖拽式的工作流设计界面
- 降低 Skill 开发门槛
-
实时预览和调试
-
性能优化
- 更快的启动速度
- 更低的内存占用
- 更高效的并发处理
中期(2027 年)可能的方向:
- 移动端支持
- iOS/Android 客户端
- 随时随地与你的 Agent 交互
-
手机端的 Push 通知集成
-
企业级功能
- 多用户权限管理
- 审计日志
- SSO(单点登录)集成
-
更完善的安全策略
-
云原生部署
- Kubernetes 原生支持
- 自动扩缩容
- 云端状态同步
2.2 社区呼声最高的功能
在社区中,用户最期待的功能包括:
| 排名 | 功能需求 | 需求热度 |
|---|---|---|
| 1 | 可视化 Skill 编辑器 | ★★★★★ |
| 2 | 更完善的文档和教程 | ★★★★★ |
| 3 | 移动端 App | ★★★★☆ |
| 4 | 更强的错误恢复机制 | ★★★★☆ |
| 5 | 内置更多常用 Skill | ★★★★☆ |
| 6 | 更好的调试工具 | ★★★★☆ |
| 7 | 多 Agent 编排支持 | ★★★☆☆ |
| 8 | 本地模型一键切换 | ★★★☆☆ |
| 9 | 更丰富的平台集成 | ★★★☆☆ |
| 10 | 性能监控面板 | ★★★☆☆ |
Tips:如果你有开发能力,可以从这个列表中挑一个你感兴趣的方向做贡献。社区呼声高的功能,被合并的概率也大,而且很容易获得认可和关注。
2.3 可能的发展方向
更强的自学习能力
未来的 Hermes 可能会内置"学习模式": - 你完成一次任务后,Hermes 问你"刚才的流程可以优化吗?" - 它会分析你的操作习惯,自动优化 Skill 的执行策略 - 长期使用后,它会越来越"懂你"
更多平台支持
除了现有的 Discord、Slack、微信等平台集成,未来可能会支持: - 企业微信 - 钉钉 - WhatsApp - Teams - 更多的 IoT 设备
企业级功能
企业市场是一个巨大的增量空间。未来的企业版 Hermes 可能包括: - 团队协作空间 - 共享 Skill 库 - 集中式管理和监控 - 合规和审计功能 - SLA 保障
移动端支持
手机上的 Agent 使用场景完全不同: - 语音交互为主 - Push 通知驱动 - 碎片化的使用方式 - 与手机系统深度集成(日历、通讯录、相册等)
本地模型优化
随着本地模型性能的提升,Hermes 可能会在本地运行方面做更多优化: - 一键切换云端/本地模型 - 本地模型的自动下载和管理 - 混合模式(简单任务本地处理,复杂任务云端处理) - 针对本地模型的性能优化
注意:以上预测基于当前的趋势和社区讨论,不代表官方承诺。技术发展迅速,实际情况可能会有变化。保持关注官方渠道,获取最新信息。
3. "养马"文化的未来
3.1 从个人助手到数字分身
如果你跟着本书一路读到这里,应该已经对"养马"这个词很熟悉了。在 Hermes 社区,"养马"就是指调教和训练自己的 Agent,让它越来越聪明、越来越懂你。
但"养马"的意义不止于此。
第一层:工具层面 - 把 Agent 当成一个高级工具 - 配置好 Skill,完成特定任务 - 这是目前大多数人的使用方式
第二层:助手层面 - Agent 开始理解你的工作习惯和偏好 - 能主动提供建议和帮助 - 成为你工作流程中不可或缺的一部分
第三层:分身层面 - Agent 不仅了解你的工作,还了解你的思维方式 - 它可以在你不在的时候"代表你"做一些决策 - 它是你的"数字双胞胎"
未来的"养马",将是从第一层向第三层的进化。
Tips:想要让你的 Hermes Agent 更接近"数字分身",关键在于记忆的积累和优化。多和它互动,让它记住你的偏好;多给它反馈,让它知道什么是"对"的。养马如养人,需要时间和耐心。
3.2 Agent 与 Agent 的协作生态
未来的互联网,可能不再是"人与人"的连接,而是"Agent 与 Agent"的连接。
想象这样一个世界: - 你的购物 Agent 和电商平台的销售 Agent 协商价格和配送 - 你的日程 Agent 和同事们的日程 Agent 自动协调会议时间 - 你的投资 Agent 和市场的数据分析 Agent 交换信息 - 你的内容 Agent 和平台的分发 Agent 合作优化流量
这种"Agent 经济"将带来全新的协作模式: - 效率大幅提升:7×24 不间断协商和交易 - 信息更透明:Agent 之间可以直接交换结构化数据 - 新的商业模式:Agent 服务本身可以成为商品
当然,这也带来了新的挑战: - 信任问题:你怎么知道对方的 Agent 是可信的? - 安全问题:Agent 被攻击或欺骗怎么办? - 责任问题:两个 Agent 交易出了问题,谁负责?
这些问题需要技术和制度的双重解决。
3.3 社区驱动的创新
Hermes 的一个独特优势是它的社区驱动模式。
与那些由大公司主导、闭门开发的产品不同,Hermes 的演进方向很大程度上由社区决定: - 社区成员提需求、报 Bug - 社区开发者贡献代码和 Skill - 社区用户投票决定优先级 - 社区文化塑造产品气质
这种模式的好处是: - 贴近用户:开发的功能就是用户真正需要的 - 创新快速:好的想法可以快速实现 - 生态丰富:社区贡献的内容远超官方团队的能力范围
未来的 Hermes,将继续强化这种社区驱动的模式: - 更开放的治理机制 - 更完善的贡献激励体系 - 更丰富的社区活动(黑客松、挑战赛等)
3.4 中国开发者的机遇
作为一个中国开发者,你可能想问:在这场 Agent 革命中,我们有什么独特优势?
优势一:应用场景丰富 - 中国拥有最丰富的互联网应用场景 - 从电商到社交,从外卖到出行,中国的 App 生态全球最复杂 - 复杂的场景 = 更多的自动化需求 = Agent 的巨大机会
优势二:用户基数庞大 - 中国的互联网用户超过 10 亿 - 中小企业数量庞大,对效率工具有强烈需求 - 市场足够大,哪怕 niche(细分)领域也能养活一个产品
优势三:工程师红利 - 中国拥有世界上规模最大的工程师群体 - 开发能力强,学习速度快 - 在开源社区中的影响力越来越大
优势四:本土模型崛起 - DeepSeek、通义千问、文心一言等国产模型性能越来越强 - 价格优势明显,有些甚至免费 - 为 Agent 应用提供了低成本的基础设施
Tips:如果你是中国开发者,建议重点关注"本土场景"+"本土模型"的组合。比如:用 DeepSeek 模型 + Hermes 框架,解决中国特有的业务场景(如微信群管理、钉钉审批、淘宝数据分析等)。这种组合既有技术优势,又有市场壁垒。
4. 给不同读者的建议
本书的读者来自不同的背景,有着不同的目标。在这一节,我想分别对几类读者说一些话。
4.1 给小白:现在就开始,不要等"完美时机"
如果你是个纯小白,之前从来没有接触过编程或 AI,我想对你说:
不要等。
很多人有这样的心理: - "等我学会了 Python 再开始" - "等官方出了中文文档再开始" - "等这个工具更成熟一点再开始" - "等我有了更多时间再开始"
结果是——永远没开始。
Hermes Agent 最大的好处就是门槛低。你不需要会编程,你只需要会"描述需求"。就像你不需要懂发动机原理也能开车一样,你不需要懂代码也能用 Hermes。
我的建议: 1. 今天就花 2 小时,跟着官方 Quick Start 把 Hermes 跑起来 2. 不管遇到什么坑,都记录下来 3. 跑通第一个 Skill 后,你会有一种"原来我也行"的信心 4. 这种信心会推着你继续学下去
Tips:小白最大的优势是什么?是"空杯心态"。你没有固有的思维定势,不会被"应该怎么做"束缚。很多创新恰恰来自外行。所以,不要觉得"我是小白就没价值",你的新鲜视角可能正是社区需要的。
4.2 给开发者:拥抱 Agent 开发范式
如果你是个开发者,已经会 Python、会写代码,我想对你说:
Agent 开发是一种新的范式,而不仅仅是一个新工具。
传统的软件开发是确定性的: - 输入 A,经过固定的逻辑处理,输出 B - 你可以精确控制每一步 - Bug 可以精确定位和修复
Agent 开发是概率性的: - 你给 Agent 一个目标,它自己决定怎么达成 - 同样的输入,可能产生不同的输出 - "Bug"的定义变了——不是"代码错了",而是"行为不符合预期"
这种范式转变需要新的思维模式: - 从"控制"到"引导":不要试图控制每一步,而是设计好目标和边界 - 从"精确"到"容错":接受不确定性,设计容错和回退机制 - 从"编码"到"编排":更多的时间在设计流程和调优提示词,而不是写代码
我的建议: 1. 不要把 Agent 当成"另一个 API 封装"来理解 2. 多研究 ReAct、CoT、ToT 等 Agent 架构的论文 3. 多动手做项目,在实战中理解 Agent 的行为模式 4. 关注 MCP 协议,这是未来的"通用接口"
4.3 给创业者:寻找 Agent 原生的商业模式
如果你是个创业者,正在思考 AI 时代的商业机会,我想对你说:
不要只是"用 AI 做原来的事",要思考"AI 能做什么原来做不到的事"。
很多创业者的思路是: - "我原来做客服 SaaS,现在加上 AI 功能" - "我原来做内容平台,现在用 AI 生成内容"
这种思路没错,但不够革命性。
Agent 原生的商业模式应该是什么样?
- 个性化服务的规模化:以前 1 个老师只能教 20 个学生,现在 1 个 AI 老师可以教 20000 个学生,而且每个学生都有个性化课程
- 7×24 的代理服务:以前律师下班就不接案子了,现在 AI 律师可以 24 小时回答客户的法律问题
- 超人类的信息处理:以前分析师一天只能看 10 份报告,现在 AI 分析师一天可以看 10000 份
我的建议: 1. 找一个你熟悉的垂直领域 2. 思考:这个领域里,最耗时、最重复、最依赖信息的环节是什么? 3. 设计一个 Agent 来解决这个环节 4. 不要追求"大而全",先做"小而美",验证市场需求
4.4 给投研人员:把 Hermes 当作你的研究助手
如果你是个投资研究人员,每天被海量信息淹没,我想对你说:
Hermes 是你最好的"实习生"。
投研工作的核心是什么? - 信息收集:从各种渠道获取信息 - 信息处理:整理、分类、提取关键信息 - 分析判断:基于信息做出投资决策
这三个环节中,前两个环节占了投研人员 80% 的时间,但价值产出主要在第三个环节。
Hermes 可以帮你把前两个环节自动化: - 7×24 监控你关注的资产和数据源 - 自动整理财报、研报、新闻 - 生成摘要和初步分析 - 异常情况立即告警
我的建议: 1. 把 Hermes 配置成你的"信息过滤器",只让它推送真正重要的信息 2. 训练它理解你的投资风格和关注领域 3. 不要完全依赖它的结论,把它当成"初稿",你来做最终判断 4. 记住:AI 帮你省时间,但决策责任仍然在你
4.5 给企业管理者:评估 Agent 的 ROI
如果你是个企业管理者,正在考虑是否要在团队里引入 Agent,我想对你说:
不要问"Agent 能做什么",要问"Agent 能帮我省多少钱/赚多少钱"。
企业决策的核心是 ROI(投资回报率)。评估 Agent 的 ROI,可以从以下几个维度:
成本节约:
某岗位年薪:120,000 元
该岗位 50% 的工作可以被 Agent 自动化
Agent 部署和维护成本:10,000 元/年
节约:120,000 × 50% - 10,000 = 50,000 元/年
效率提升:
某流程人工处理:2 小时/次,每周 10 次 = 20 小时/周
Agent 自动化后:0.5 小时/周(主要是监督和异常处理)
节省:19.5 小时/周 = 1014 小时/年
按 200 元/小时计算,价值约 200,000 元/年
错误减少:
人工处理错误率:5%
每次错误造成的平均损失:5,000 元
每月 200 次处理,错误 10 次,损失 50,000 元/月
Agent 错误率:0.5%
每月错误 1 次,损失 5,000 元/月
节约:45,000 元/月 = 540,000 元/年
我的建议: 1. 从一个小场景试点,量化评估效果 2. 选择"高频、规则明确、人工耗时"的场景优先自动化 3. 不要期望一步到位,Agent 的部署和调优需要时间 4. 重视员工的培训和接受度,技术再先进,人不用也是白搭
5. 写在最后
5.1 回顾本书的核心要点
如果你是从头读到这里的,恭喜你!你已经完成了对 Hermes Agent 从入门到精通、从使用到变现的完整学习旅程。
让我们用一张图回顾一下本书的核心内容:
Hermes Agent 完整知识体系
基础篇
├─ 什么是 AI Agent,行业全景
├─ Hermes 的诞生背景和技术特点
└─ 核心架构深度解析
实践篇
├─ 安装部署(多种方式)
├─ 基础使用(对话、任务、配置)
├─ 三层记忆系统(工作/短期/长期)
└─ 技能系统(开发/调试/发布)
进阶篇
├─ 九大变现路径(从代安装到企业开发)
├─ 社区生态与资源(官方/中文/生态项目)
└─ 未来展望与总结(趋势/路线图/建议)
5.2 AI Agent 不是取代人,而是赋能人
在结束之前,我想强调一个核心观点:
AI Agent 不是为了取代人类,而是为了让人类更强大。
每一次技术革命,都会有人担心"机器会不会抢走我的工作"。历史告诉我们: - 汽车发明后,马车夫确实失业了,但催生了司机、汽修工、道路建设者等更多职业 - 计算机普及后,打字员消失了,但出现了程序员、设计师、数据分析师等全新职业 - 互联网兴起后,传统媒体受到冲击,但诞生了自媒体、电商、直播等万亿级市场
AI Agent 也是一样。它确实会替代一些重复性工作,但同时会创造更多新的机会: - Agent 训练师:调教和优化 Agent 的专业人员 - Agent 架构师:设计复杂 Agent 系统的高级人才 - Agent 运营师:管理和优化 Agent 工作流程的专家 - 人机协作设计师:设计人和 Agent 如何配合的角色
未来的竞争力,不是"你比机器强",而是"你比不会用机器的人强"。
5.3 "Stay lazy, stay early"
这是 Hermes 社区的 Slogon,也是我想送给你的最后一句话。
- Stay Lazy:用 Agent 自动化一切可以自动化的工作,把时间和精力留给真正重要的事——创造、思考、连接
- Stay Early:做早期采用者,在别人还在观望的时候就已经行动。红利永远属于先行者
但我要加一个自己的理解:
Stay Lazy, Stay Early, Stay Curious.
保持好奇,持续学习,永远不要停止探索。技术是变化的,但学习能力是永恒的。
5.4 感谢读者
感谢你一路读到这儿。
写这本书的过程,也是我梳理自己认知的过程。我把过去一年多来使用、研究和变现 Hermes Agent 的经验,尽可能完整地呈现给你。如果其中有一两句话对你有启发,有一个案例对你有帮助,有一个技巧让你少踩了一个坑,那这本书就值了。
技术书籍最大的敌人是"过时"。AI 领域变化太快,今天写的明天可能就过时了。但我相信,本书中的思维方式和方法论是比具体技术更长久的价值。
5.5 期待反馈
如果你在阅读过程中发现了错误,或者有任何建议,欢迎通过以下方式反馈: - 在 GitHub 上提交 Issue - 在社区群里 @我 - 通过社交媒体私信
你的反馈将帮助这本书变得更好,也能帮助更多的读者。
6. 附录
附录 A:完整命令参考表
# ========== 基础命令 ==========
# 查看版本
hermes --version
# 查看帮助
hermes --help
hermes <command> --help
# 检查环境和配置
hermes doctor
# ========== 配置管理 ==========
# 编辑配置文件
hermes config edit
# 查看当前配置
hermes config show
# 验证配置是否正确
hermes config validate
# ========== Agent 交互 ==========
# 启动交互式会话
hermes chat
# 执行单条命令
hermes run "你的指令"
# 使用特定 Skill 执行
hermes run skill:skill-name "你的指令"
# ========== Skill 管理 ==========
# 列出已安装的 Skill
hermes skill list
# 安装 Skill(从 Skills Hub)
hermes skill install author/skill-name
# 从本地文件安装
hermes skill install ./path/to/skill.md
# 更新 Skill
hermes skill update skill-name
# 卸载 Skill
hermes skill uninstall skill-name
# 导出 Skill
hermes skill export skill-name -o ./output.zip
# 导入 Skill
hermes skill import ./skill.zip
# ========== 任务管理 ==========
# 列出运行中的任务
hermes task list
# 查看任务详情
hermes task show <task-id>
# 停止任务
hermes task stop <task-id>
# 停止所有任务
hermes task stop-all
# ========== 日志管理 ==========
# 查看日志
hermes logs
# 实时跟踪日志
hermes logs -f
# 查看最后 N 行
hermes logs --tail 100
# 查看指定 Skill 的日志
hermes logs --skill skill-name
# ========== 记忆管理 ==========
# 查看记忆内容
hermes memory show
# 搜索记忆
hermes memory search "关键词"
# 清空记忆(谨慎使用!)
hermes memory clear
# ========== 调试命令 ==========
# 调试模式运行
hermes run "指令" --debug
# 详细输出
hermes run "指令" --verbose
# 逐步执行
hermes run "指令" --step
附录 B:config.yaml 完整参数参考
# ========== 核心配置 ==========
# Hermes 应用配置
app:
name: "my-hermes" # 实例名称
log_level: "INFO" # 日志级别: DEBUG, INFO, WARNING, ERROR
data_dir: "~/.config/hermes" # 数据存储目录
# ========== 模型配置 ==========
model:
provider: "openai" # 提供商: openai, anthropic, deepseek, ollama
model: "gpt-4o" # 模型名称
api_key: "${OPENAI_API_KEY}" # API Key(推荐用环境变量)
base_url: null # 自定义 API 地址(用于代理或本地模型)
temperature: 0.7 # 创造性程度 (0-2)
max_tokens: 4096 # 最大输出长度
timeout: 30 # 请求超时时间(秒)
# ========== 记忆系统配置 ==========
memory:
enabled: true # 是否启用记忆
working_memory:
max_messages: 20 # 工作记忆保留的消息数
short_term_memory:
enabled: true
storage: "sqlite" # 存储方式: sqlite, redis
retention_days: 7 # 保留天数
long_term_memory:
enabled: true
storage: "chroma" # 向量数据库: chroma, pinecone, qdrant
embedding_model: "text-embedding-3-small"
max_entries: 10000 # 最大条目数
# ========== 工具配置 ==========
tools:
enabled: # 启用的工具列表
- web_search
- browser
- file_read
- file_write
- python_execute
- shell_execute
web_search:
engine: "duckduckgo" # 搜索引擎
max_results: 5 # 最大结果数
browser:
headless: true # 无头模式
timeout: 10 # 页面加载超时
python_execute:
sandboxed: true # 是否沙箱执行
max_execution_time: 30 # 最大执行时间
shell_execute:
allowed_commands: [] # 允许执行的命令白名单
blocked_commands: ["rm", "dd", "mkfs"] # 禁止执行的命令
# ========== Skill 配置 ==========
skills:
auto_load: true # 是否自动加载 skills 目录下的 Skill
directories: # Skill 搜索路径
- "~/.config/hermes/skills"
- "./skills"
# ========== 安全配置 ==========
security:
confirm_destructive: true # 破坏性操作前是否确认
max_file_size: 10485760 # 允许操作的最大文件大小(字节)
allowed_paths: # 允许访问的路径
- "./"
- "~/.config/hermes"
附录 C:推荐阅读书单
入门阶段: 1. 《AI 未来进行式》——李开复、陈楸帆(了解 AI 应用前景) 2. 《生成式 AI:人工智能的未来》——了解生成式 AI 的基本原理 3. 《Prompt 工程指南》(在线免费资源)——学习如何与 AI 有效沟通
进阶阶段: 4. 《动手学深度学习》——李沐(理解 AI 底层原理) 5. 《LangChain 实战》——了解 LLM 应用开发框架 6. 《设计模式》——GoF(Agent 架构设计需要的设计思维)
商业阶段: 7. 《从 0 到 1》——彼得·蒂尔(创业思维) 8. 《精益创业》——埃里克·莱斯(快速验证商业想法) 9. 《影响力》——罗伯特·西奥迪尼(营销和说服力)
在线资源: 10. Papers with Code(https://paperswithcode.com)——最新 AI 论文 11. arXiv(https://arxiv.org)——学术论文预印本 12. Hugging Face(https://huggingface.co)——模型和数据集
附录 D:相关论文与研究
Agent 架构基础: - ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022) - Chain-of-Thought Prompting Elicits Reasoning in LLMs (Wei et al., 2022) - Tree of Thoughts: Deliberate Problem Solving with Large Language Models (Yao et al., 2023)
Agent 系统与框架: - AutoGPT: An Autonomous GPT-4 Experiment - LangChain: Building applications with LLMs through composability - MCP: Model Context Protocol (Anthropic, 2025)
记忆与学习: - Memory in Large Language Models: A Survey - Retro: Improving language models by retrieving from trillions of tokens
多 Agent 系统: - Communicative Agents for Software Development (ChatDev) - MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework
Tips:读论文对很多人来说有门槛。建议先从综述(Survey)文章开始,了解全貌后再深入具体的论文。很多论文也有中文解读版本,可以在知乎、CSDN 上搜索。
附录 E:本书更新日志
| 版本 | 日期 | 更新内容 |
|---|---|---|
| v1.0 | 2026-04 | 初始版本,涵盖 00-16 章完整内容 |
注意:由于 AI 领域发展迅速,建议定期关注本书的更新。最新版本将通过公众号和社区渠道发布。
7. 完结语
鲲鹏Talk 的寄语
各位朋友,当你们读到这一页时,意味着我们已经一起走完了一段不短的旅程。
从最初的好奇"AI Agent 是什么",到亲手安装配置 Hermes,再到开发自己的 Skill,甚至思考如何用它变现——这一路,你收获的不仅是技术能力,更是面向 AI 时代的思维方式。
我想送你三句话:
第一句:工具是死的,人是活的。
Hermes Agent 再好,也只是个工具。真正创造价值的是使用工具的你。不要迷信工具,也不要轻视工具——把它当成你能力的放大器,而不是替代品。
第二句:行动胜过完美。
很多人花大量时间"准备",却迟迟不行动。看十遍教程不如动手做一遍。遇到问题再查、再学、再问——这种"边做边学"的效率,远超"看完所有资料再开始"。
第三句:分享是最好的学习。
当你学会一样东西,试着教给别人。写一篇文章、录一个视频、回答一个问题——在分享的过程中,你会发现自己理解得还不够深,这会倒逼你学得更好。而且,分享会为你带来意想不到的机会。
全平台联系方式
如果你在阅读过程中有任何问题,或者想和我交流,欢迎通过以下方式找到我:
- 微信视频号:搜索「鲲鹏Talk」
- B 站:搜索「鲲鹏Talk」
- 微信公众号:搜索「鲲鹏Talk」
- YouTube:搜索「鲲鹏Talk」
- 小红书:搜索「鲲鹏Talk」
- 抖音:搜索「鲲鹏Talk」
Tips:建议关注我的公众号,我会定期发布: - Hermes Agent 的最新教程 - AI 行业动态解读 - 变现案例分享 - 读者答疑精选
白皮书系列预告
本书是 Hermes Agent 白皮书系列的收官之作。整个系列包括:
| 分册 | 内容 |
|---|---|
| 00-01 | 目录、前言与概述 |
| 02-03 | AI Agent 行业全景、Hermes 诞生与演进 |
| 04-05 | 核心架构、安装部署 |
| 06-08 | 基础使用、记忆系统、技能系统 |
| 14 | 九大变现路径 |
| 15 | 社区生态与资源 |
| 16 | 未来展望与总结(本书) |
如果你是从中间某一本开始读的,建议把前面的分册也找来看看,构建完整的知识体系。
未来可能的新内容: - Hermes Agent 2.0 新版教程 - 企业级部署实战指南 - 多 Agent 协作系统开发 - AI Agent 安全与对齐专题
最后的话
技术发展的车轮滚滚向前,从不等待任何人。
有人害怕被时代抛下,有人焦虑于学不完的新东西。但我想告诉你:
不必焦虑,只需行动。
你不需要成为 AI 专家,你只需要成为"会用 AI 解决问题"的人。你不需要掌握所有技术,你只需要找到一个场景,把 Hermes Agent 用好。
今天,就是最好的开始时机。
打开你的电脑,启动 Hermes Agent,对它说:
"你好,我们一起做点有趣的事情吧。"
它已经在等你了。
Stay Lazy, Stay Early.
我们江湖再见。
作者:鲲鹏Talk 微信视频号 | B站 | 微信公众号 | YouTube | 小红书 | 抖音 搜索「鲲鹏Talk」即可找到我,欢迎关注交流!