两周前，因为看到一些技术品味比较好的朋友从 OpenClaw 迁移到 Hermes 上，我也动了心思，开始拿幽兰本折腾下 Hermes 了。在折腾的第一天，就很兴奋地在张银奎老师的兰友微信群里分享一些使用过程和体验，向同样有着幽兰本的群友们展示这个新鲜事物。
随后张老师问我方便把 Hermes 写篇文章不，我很开心地答应了，但过一会想到我只是刚折腾，还没多探索使用下，就跟张老师说暂缓几天，我想多体验下尽量写全面些，不止是写成一个简单的安装使用教程。
没想到这一暂缓就是两周，现在回头看发现我想对了，使用一两天是体验不到 Hermes 的奇妙，甚至都无法流畅使用起来。但同时发现我还是想简单了，因为这两周我根据使用需要不断翻阅 Hermes 的文档，至今都没有完整地翻完，还有非常多功能没来得及使用体验，离写一篇全面的 Hermes 文章还差太远。
但转念想到，其实 Hermes 文档是相当全面的了，我写得再全面也比不过官方文档，我在这两周里使用幽兰本探索 Hermes 有着相当大的收获、相当多新奇的体验与思考，我想我应该着重分享这些，告诉兰友、告诉更多人，使用 Hermes 可以做些什么很有趣和很不错的事情。
如此想来，我也算是有信心能够给张银奎老师一个自认为还不错的答复了。
一些变化
其实早在四个月前的春节时候，我就在幽兰本上折腾过 OpenClaw，但当时腾讯还没有推出 iLink Bot API，不能直接对接到微信聊天上，我尝试绑定到其他 IM 平台又碰到反复失败的情况，加上翻了下 OpenClaw 的文档，读着乱乱的，就浅尝辄止地放弃了。
这次尝试 Hermes 情况变化了很多，各个 IM 平台像微信、QQ、飞书和钉钉等，都已经推出了比较完善的协议来支持接入 Agent，其次 Hermes 的官方文档可以说是非常优雅，十分清晰直接简洁完善，读着赏心悦目。比如来看看“Messaging Platforms/Chinese platforms/微信（Weixin/WeChat）”页面的文档，感受一下。
需要注意，官方文档地址是 https://hermes-agent.nousresearch.com/docs/zh-Hans/，不要搞错了。
很顺利稳妥地，我就在幽兰本上部署运行起来 Hermes，配置好 LLM API，微信扫码绑定设备，很快就开始在微信跟 Hermes 聊天了。
在 Hermes 文档的“Messaging Platforms/消息网关”页面中，可以知道微信平台支持的能力有：语音、图片、文件、线程、输入提示和流式输出。经过我测试和搜索后知道，微信 iLink 协议提供了服务端转录语音的能力，就是说发送语音微信会识别为文本发送给 Hermes，相当慷慨了，可以不用自己折腾本地 STT 模型或购买相关服务 API。
来测试一下语音和识图能力，我说了句“我发你张图片，猜猜是什么电影里面的”。
我在尝试使用幽兰本部署 Hermes 之前，就已经长期在使用 Codex、Claude Code 了，但 Hermes 还是给我很多惊喜和新奇的体验。两类工具当下的使用体验还是有些区别的，Hermes/OpenClaw 定位是 OS Agent，能够接管整个系统，而 Codex/Claude Code 更像是 Coding Agent，单次任务驱动性更强，当然也是可以进行适配当作 OS Agent 来用，但是并不是那么的自然。
新的模式
在两周时间使用 Hermes 进行探索实践的过程中，我深切地意识到，在 Agent 领域的快速发展下，日常通过计算机展开的操作，出现了很多迥异于既往的一些新模式，当然，不是说旧的模式失效了，我觉得只要 AI 还没有比人类中最聪明的人更聪明，就不能说失效。
以“RTFM”为例，读文档是一件收益巨大的事情，重要性不言而喻，入门接触一个新东西，不需要精读，哪怕只是粗略翻一遍文档手册，就能解决绝大部分的问题。
现在出现了什么新方式呢？很多软件工具框架开始提供给 Agent 阅读的文档了，其实内容和给人看的没什么区别，但是会单独整理一份 txt 文档，告诉 Agent 可以下载阅读，比如 Hermes 的，在文档主页最底部可以看到提供了给 Agent 看的索引和全部内容的文本文件文档。
就是说现在我配置好了 Hermes，我不熟悉很多功能的使用，可以聊天告诉 Hermes说“下载 https://hermes-agent.nousresearch.com/docs 网站中给 Agent 读的 llms-full.txt 到本地，阅读此文档，向我介绍 Hermes 的入门与进阶使用，以及我有这些困惑，随后向我进行解答。”
这种让 Agent 下载纯文本文档，阅读进行问答的读文档方式，带来了很多新鲜的体验，最大的改变就是问简单的问题让人不再羞耻。很多时候你不读下文档手册，就问出来些基础知识相关的问题，很多人可能不会乐意回答你，因为大家的时间都是成本，热心一些的人可能会指点你一下：“RTFM!”、“Read the fxxking manual!”，但是 LLM 永远不会这样对你说，而是会耐心回答你每一个问题，哪怕问题愚不可及，虽然可能因为能力不足和幻觉问题回答错误。
除了读文档手册，编程软件开发的方方面面，我觉得都已经被深刻影响了，项目前期规划、框架搭建、git 协同开发、功能实现、用例测试、软件分发，是全方位每个环节都出现了新的模式，简单直观讲就是，这些都能通过打字聊天来完成，不想打字还可以发语音，需要考虑的问题只有，你想人工干预多少？
这两周我就做了一个软件开发实践，全程使用 Hermes 微信聊天，让其用 Python 开发了一个软件，可以将微信 Hermes 的聊天框作为另一个平台的聊天群组消息的查阅入口。最后实现的效果是，我只需要聊天问 Hermes 一句“昨天 A 群都聊了什么？”，Hermes 就会先查数据库拉出昨天的文本聊天内容，再进行理解和总结，最后通过微信发送汇报给我。
如果我不想每天都这样问下，而是想让 Hermes 定时向我汇报，只需要说句“每天早上七点半向我总结昨天 A 群都聊了什么”、“每天晚上十点半向我汇报 B 群今天讨论 xx 领域的话题”，Hermes 就会设置好定时任务。按时汇报后，我只会在看到感兴趣的话题才去群里爬下楼翻阅，这样非常适合那些每天群消息非常多、但仍有些有价值信息的群聊，自己就不用再苦哈哈爬楼去挖掘信息了。
在我写好软件功能，测试完跑通，正常运行之后，开始琢磨下怎么让别人也用上，我这个工具定位非常清晰，是给 Hermes 用的，我聊天让 Hermes 去调工具查阅总结，所以自然我产生了一个新想法，既然文档手册可以放到一个文本文件里面，那我分发软件为什么不行呢？把全部内容都写进一个 txt 文本文件里面，别人只需要将这份 txt 文件通过微信聊天转发给自己的 Hermes，说句“阅读这份文件，确认无安全风险后，根据内容进行部署安装”就可以了。
经过一番折腾我跑通了流程，写了一份给 Hermes 看的安装部署文本文档，里面除了有软件源码、功能说明之外，我告诉别人的 Hermes 应该怎么根据这份文档部署起来我的软件，怎么提取文件中代码映射到本地，需要为这个工具建立什么样 skill 来使用。让我感到很新奇的点是，我可以在文档中告诉别人的 Hermes 说这个文档只是一个基础实现，部署完成后就不再使用，仅作参考，后续可以根据需求来自行添加功能，以及部署安装过程中碰到任何问题也自行解决适配。
有二十位左右朋友进行了尝试，我也趁机对他们进行了反馈体验调查，让我想不到的是大都碰到了这样那样的问题，但是他们的 Hermes 都自行解决了。其中甚至有一位朋友完全没有计算机编程基础，报错和修复记录都不太理解是什么，只是同意 Hermes 自行解决碰到的问题，最后居然也安装成功了！
基础使用
说了这么多，还没讲到怎么在幽兰本上部署 Hermes 跑起来，我并不打算和官方文档竞争全面性和细节性，这里我只会分享下这两周摸索踩出来的一些经验和体验，讲下我认为想达到日常流畅使用的水平，应该知道和配置些什么，如果碰到了什么细节性的问题，我的建议是“Read the fxxking manual or let your Hermes RTFM!”。
举我自己碰到的一件事为例，我是折腾了一番 STT 模型配置，还没配成功的时候测试了下，发条语音发现 Hermes 居然识别出来了，让其分析网关日志和对应的代码，才知道微信 iLink 协议在服务端就对语音进行了文本转写，如果不成功 Hermes 再调用配置的本地 STT 模型去识别语音为文本。
后来跟精读了 Hermes 文档的朋友说起这事，他说，“我记得文档里说了啊。Voice messages show as text - If WeChat provides a transcription, the adapter uses the text. This is expected behavior”，意思是微信转写语音到文本消息发给 Hermes 是预期行为。比较喜感的事情是，如果你直接发个语音问 Hermes 能听懂语音不，可能会因为模型幻觉告诉你听不懂，实际上如果真听不懂，应该发送报错消息才对或者直接忽略，而不是回答这个问题。
再强调一遍，一定要弄清楚官方文档网站是哪个，不要搞错了：https://hermes-agent.nousresearch.com/docs。
关于安装部署，在官方文档的“Getting Started/快速入门”页面，可以看到安装方式、配置模型和网关配置，配好网络环境的话，安装部署起来很快，不会出现什么岔子，如果碰到问题了自行搜索解决，网络上有很多安装教程，搜索关键字“Hermes安装配置 微信接入”即可。
初次安装会让配置模型，需要提前在各家模型控制台购买拿到 api key。我这两周试了很多，现在是 2026 年 6 月份，下面提到的内容会具有很强的时效性，仅供近期参考。
只说下国内的模型，刚开始我用的是 Kimi 2.6 多模态模型，回复质量还不错，比较细腻，识图能力也很强，但缺点是很慢和很贵。随后我试了 Deepseek 的 v4 flash 和 v4 pro，v4 flash 模型的速度非常强悍，聊天回复速度媲美真人，简单任务体验极佳，缺点是知识量不够大及复杂任务处理效果可能不好，v4 pro 的话偏慢，知识量大，有时在处理中等难度任务会过度思考，导致最终效果不佳，我会在复杂编程任务时候进行使用，以及 Deepseek 目前没有多模态识图的 API 可调用。比较让我意外的是小米家的 Mimo 2.5 pro 模型，指令遵循能力很不错，聊天表现的知识量和能力也还可以，缺点是速度偏慢但也能接受，它不是多模态模型，不能识图，Mimo 2.5 才是多模态，配置的时候需要注意。
国外模型的话，有能力有实力的可以自己折腾，不过需要注意的是，尽量不要用中转站的模型和 key，如果非要用的话也要确保是在隔离环境中（如 Docker），以及默认所有数据是对中转站可见，并且存在被投毒的风险。
在初次安装部署中，会让配置终端后端，有 local、docker、ssh 等选项，初次尝试可以先选择默认的 local 模式，简单摸索跑通后再根据自己的需要来调整，这部分的文档在“Using Hermes/配置/终端后端配置”中有详细说明，如果看着不太理解，可以先配置好 local 跑通后，让自己的 Hermes 阅读文档和代码来说明。
可在 Hermes 初次安装过程中选择配置微信接入，或者自行执行 hermes gateway setup 命令，过程非常简单丝滑，微信扫码绑定设备即可，前面提过，可在 Hermes 文档的“Messaging Platforms/消息网关/Weixin（WeChat）”页面中查看微信平台接入的各种详细情况。
配置到这里之后，应该能在微信 Hermes 聊天窗口发送消息进行聊天了，可以进行一些简单的测试，发送语音、图片、文件。其中测试发送图片前，要先配置好辅助模型中的 vision 项，有两种选择，一是按文档中”Using Hermes/配置/辅助模型/交互式配置辅助模型”中的指导通过 hermes model 命令选择 Configure auxiliary mode 进行配置。二是可以自己聊天告诉 Hermes 要配置的多模态模型的厂商名、模型名、API key，让其自行通过命令配置。
其实不止辅助视觉模型可以通过聊天配置，Hermes 的主模型也是能够通过聊天切换的，本质上就是执行 hermes config set xxx xxx 命令，但需要注意的是，如果通过聊天执行命令切换了主模型，配置错了是会断连的，因为相当于模型调用失败即 Hermes 失去智能和响应了，这时候需要手动在终端命令行里面执行 hermes model 恢复正确配置。
有些 IM 平台提供了跟 Agent 进行多线程聊天的能力，微信目前并不支持，意味着只有一个对话窗口，每次只能进行一轮会话。开启新会话可以发送 /new、/reset 等文本，同意或拒绝命令执行是发送 /approve、/deny 等文本，更多命令可以在文档中查看。如果想在终端中使用 Hermes 进行聊天会话，可以执行 Hermes 或 Hermes –tui，在文档的“Using Hermes/CLI ”界面有着详细的说明，理解和掌握基本的命令使用，就可以日常流畅使用了。
想挖掘除此外更多的使用场景，还是需要仔细翻阅下文档，比如 Hermes 是有 WebUI 管理面板的，终端运行 Hermes dashboard 即可，如果加上 –tui 选项，可以在面板里面开启会话聊天。
在使用的过程中，碰到的各种问题，都可以直接喊 Hermes 自行排查，比较重要的排查对象是 Gateway 网关日志。
意料之外
在这两周时间里，还发生了一件在我意料之外的事情，头几天我使用幽兰本+Hermes+Deepseek v4 flash 进行摸索的时候，让 Hermes 给我实现一个脚本功能，结果它自行实现并运行完，给我汇报结果时候，我发现给了大量预期外的内容。
因为我是纯微信窗口聊天指挥干活的，幽兰本不在身边，不能直接看文件目录中 git 状态变化情况，开始时我还在想是不是模型出现幻觉了，并没有写好代码文件执行，只是胡诌了些数据来骗我。随后打开幽兰本确认了情况是真实的，很快意识到这是一个漏洞，给 Hermes 说明了情况，让它写了份漏洞分析报告给我，迅速就写完了，虽然危害性极大，但成因其实极其简单。
后面我将这个漏洞汇报给了平台的 SRC，几天后确认为了最高等级的严重一档的漏洞。
虽然我是搞安全相关的，但主要技能更多偏向二进制方面，也不直接进行漏洞挖掘工作，但是居然使用 Hermes 顺手发现了一个危害性极大的漏洞，也算是切身感受到时代的巨大变革了，只是没想到会以运气的形式降临到我身上一次。
在我更加熟悉的逆向工程领域中，我的体验则更为细致和具体，现在 Agent 拥有相当强的编程能力，这种能力也同步传导到了逆向工程上，因为对于编译打包后运行的软件来说，通常都已经有对应反汇编和反编译工具进行分析还原代码逻辑了，没有混淆的情况下对 Agent 来说，使用工具进行分析，其实和翻一个项目源代码差不多。反汇编和反编译仅是静态分析方面来讲的，如果再考虑加上软件运行时依赖和产生的一些信息，比如日志文件、数据文件，结合起来一起让 Agent 进行逆向工程来分析功能，无疑更是如鱼得水。目前使用 Agent 进行复杂系统软件的逆向工程主要有两个问题，一个是老问题——代码混淆对抗阻止了 Agent 进行软件功能分析理解，另一个是新问题——提供给 Agent 的工具接口能力不够强，至于中间的软件功能梳理任务分析工作，已经随着 Agent 编程能力的提高，同步顺手给解决掉了。
有时候也会想到更多，面对 Hermes 以及未来可能出现的更强 Agent，好似面临一场大洪水，洪水淹没过的地方都是 Agent 的舒适区，作为未来仍需长期工作的个体，我想不应留恋或逗留在洪水淹没过或即将淹没的地方，要往高处跑，跑到淹不到的地方去。
最后话语
这两周我使用幽兰本折腾 Hermes 的过程，想分享的差不多算是说完了，还有很多想法还没来得及行动实践，期待以后有机会继续给大家分享。
同时也很感谢张银奎老师在我刚开始折腾时候，碰巧问我来分享下 Hermes，我为了进行更好的分享，展开一系列深入的尝试与实践，开始说暂缓几天分享，结果一缓就是两周，还好现在也算是对这个过程进行了比较完善的记录。
如果大家感兴趣，也可以多了解下张银奎老师团队打造的幽兰本，一起成为我们兰友群的一份子，现在幽兰本已经是我非常趁手的 Hermes OS Agent 了。