Hermes Agent 进阶补充:把 AI 助手从「会聊天」调成「会干活」

关注微信公众号：RowanFYI

探索 AI 应用与效率提升的实战经验

上一篇《Hermes Agent 从中级到高级进阶指南》发出去后，反馈最好的一点不是“功能多”，而是很多人发现：Hermes 真正有价值的地方，不是多一个聊天窗口，而是它能被调成一个长期工作的系统。

所以这篇不重复安装、模型配置、记忆系统这些基础内容，而是继续往后走一步：如果 Hermes 已经能稳定用了，下一步应该怎么把它变成你的“自动化工作台”？

我这段时间试下来，最值得补充的是 7 个进阶玩法。

它们分别解决 7 个真实问题：

一个助手不够用，怎么拆成多个身份？
每天重复做的事，怎么自动跑？
复杂任务一个 Agent 容易跑偏，怎么分工？
外部系统有事件，怎么主动触发 Hermes？
工具越来越多，怎么接入又不把上下文塞爆？
做错了文件改动，怎么安全回滚？
经验越积越多，怎么避免技能库变成垃圾堆？

如果上一篇是“把 Hermes 用起来”，这篇就是“把 Hermes 管起来”。

Part 1：先别急着加工具，先拆 Profile

很多人刚开始玩 Agent，第一反应是给它塞更多工具：浏览器、搜索、GitHub、Notion、MCP、数据库、邮件……

结果没过几天就发现一个问题：

同一个 AI 助手同时负责写代码、发公众号、查资料、跑运维，记忆和风格很快会混在一起。

比如你做内容时希望它语气自然一点；做服务器操作时又希望它极度保守；做代码时还希望它能大胆重构。这三种人格放在同一个配置里，非常容易互相打架。

Hermes 的 Profiles 就是为这个问题准备的。

你可以把它理解成“多个独立分身”：每个 Profile 有自己的配置、会话、记忆、技能和工具权限。

我建议至少拆三个：

default：日常主助手，负责聊天、搜索、杂事
content：内容生产助手，负责选题、改写、发布
worker：执行型助手，负责跑脚本、定时任务、自动化流程

常用命令很简单：

# 查看已有 profile
hermes profile list

# 创建一个内容生产 profile
hermes profile create content --clone default

# 创建一个更干净的 worker profile
hermes profile create worker

# 使用某个 profile 启动
hermes -p content

我个人最喜欢的做法是：

主助手负责判断，worker 助手负责执行。

比如发公众号这类流程，主助手只负责确定选题、审核标题和结构；真正下载图片、生成封面、调用微信 API 的动作，交给 content 或 worker Profile 去做。

这样有两个好处：

主助手的记忆不会被大量执行细节污染
出问题时更容易定位，是内容逻辑错了，还是执行环境错了

一个小建议：不要一上来拆十几个 Profile。先从 2-3 个开始，等某类任务每周都重复出现，再把它独立出来。

Part 2：Cron 才是 Hermes 的隐藏大招

上一篇里我提到 Hermes 可以在 Telegram 里用，很多人觉得这已经很方便了。

但真正让我觉得“这个东西能长期留下来”的，是 Cron。

Cron 的意思是：你可以让 Hermes 定时执行任务，而且它不是简单跑脚本，而是可以在每次运行时重新调用模型、查资料、总结、判断，再把结果推送给你。

这就不是普通定时任务了，而是一个“定时思考的 Agent”。

比如：

hermes cron create "0 8 * * *"

然后写一个任务：

每天早上 8 点，搜索过去 24 小时 AI Agent 方向值得关注的进展。
筛掉融资新闻、产品营销和重复内容。
只保留 3 条真正有实操价值的内容，用中文总结后发给我。

这和 RSS 最大的区别是：RSS 只是把信息推给你，Hermes 会先帮你筛一遍。

我现在最推荐的 Cron 用法有三类：

1. 信息筛选型

适合每天跑：

AI 实战教程筛选
GitHub 热门项目摘要
某个关键词的 X / Hacker News / Reddit 监控
竞品更新追踪

关键点是：不要让它“全部总结”，而是让它“只挑值得看的”。

错误提示词：

每天总结 AI 新闻。

更好的提示词：

每天筛选 AI Agent 方向的新内容，只保留满足以下条件的 3 条：
1. 有具体实操方法或代码
2. 不是融资、发布会、纯观点争论
3. 对个人开发者或内容创作者有启发
每条用 100 字以内说明为什么值得看。

2. 看门狗型

适合服务器和自动化系统：

磁盘空间低于阈值提醒
某个服务挂了提醒
定时检查网站是否可访问
检查某个脚本是否连续失败

这类任务甚至可以不经过模型，直接让脚本输出告警。没问题就静默，有问题才通知。

3. 内容生产型

适合公众号、小红书、Newsletter：

每天自动搜集候选选题
每周整理爆款标题库
定时检查草稿箱文章格式
发布前自动跑检查清单

这里有一个坑：不要让 Cron 直接“自动发布”。

我的建议是：

自动采集、自动初筛、自动成稿，但发布前保留人工确认。

Agent 很适合做 80% 的体力活，但最后 20% 的判断，尤其是标题、观点、风险，最好还是人来拍板。

Part 3：复杂任务别让一个 Agent 硬扛

很多人用 AI 做复杂任务时，会犯一个错误：把所有要求塞进一个超长提示词里，然后期待它一次性完成。

结果通常是：前面做得很好，后面开始遗忘；代码写完了，测试忘了跑；文章写完了，封面和摘要没检查。

Hermes 的 delegate_task 更适合处理这种场景。

你可以把它理解为：主 Agent 临时叫几个“同事”来并行干活。

比如我要做一篇技术文章，可以这样拆：

子 Agent A：查资料，只负责事实和来源
子 Agent B：写大纲，只负责结构和读者路径
子 Agent C：审稿，只负责找空话、重复和风险点
主 Agent：整合，决定最终版本

这种模式比“一个 Agent 从头写到尾”稳定很多。

尤其适合这几类任务：

代码重构：一个写方案，一个审方案，一个执行
内容创作：一个找资料，一个写初稿，一个挑刺
数据分析：一个清洗数据，一个做图，一个写结论
调研报告：多个子 Agent 分别查不同来源

我自己的经验是：

不要让子 Agent 做最终决定。子 Agent 负责产出候选，主 Agent 负责裁决。

这和真实团队一样。你不会让实习生直接合并生产代码，但你会让他帮你搜资料、跑测试、列风险。

Part 4：Webhook：让 Hermes 从“被动聊天”变成“主动响应”

大多数人把 Agent 当聊天工具：我问一句，它答一句。

但真正的自动化系统应该是事件驱动的。

比如：

GitHub 有新 Issue，自动让 Hermes 分类、打标签、生成回复建议
表单收到新线索，自动做背景调研
监控系统发出告警，自动拉日志并给出排查步骤
支付成功后，自动创建用户资料和欢迎消息

Hermes 的 Webhook 就是干这个的。

你可以创建一个路由：

hermes webhook subscribe github-issue

外部系统往这个地址 POST 数据，Hermes 就能被唤醒，带着这段数据执行指定任务。

这其实是一个非常重要的变化：

聊天机器人是人触发的；Webhook Agent 是系统触发的。

前者适合临时问答，后者才适合接进真实业务流程。

当然，这里也要保守一点。我的建议是先从“只读动作”开始：

收到事件后只总结，不改数据
先发建议给你确认，不自动回复用户
先创建草稿，不直接发布

等流程跑稳定了，再逐步开放写权限。

Part 5：MCP 不要乱接，先做工具分层

MCP 现在很火，很多人看到一个 MCP Server 就想接一个。

但我踩过坑：工具越多，Agent 不一定越强，反而可能更犹豫。

因为每个工具都要进入上下文，工具描述越多，模型越容易分神。最后你只是想让它查个文件，它先在十几个工具里纠结半天。

我的原则是：

高频工具进核心，低频工具进 Profile，实验工具临时加载。

可以分三层：

第一层：核心工具

每天都会用的，比如：

文件读写
终端
搜索
浏览器
记忆
session search

这些可以放在主 Profile。

第二层：业务工具

只在特定场景用，比如：

GitHub
Notion
Google Workspace
微信发布
小红书发布
数据库查询

这些更适合放进专门 Profile。

第三层：实验工具

临时测试的 MCP、新插件、新 API，不要一上来装进默认环境。

先单独开一个 Profile，确认稳定、有用、不会污染上下文，再考虑长期保留。

一句话总结：

工具不是越多越好，而是越贴近当前任务越好。

Part 6：一定要学会用 Checkpoints 和 Rollback

Agent 最大的问题不是不会做事，而是太会做事。

你让它“顺手优化一下”，它可能真的顺手改了十几个文件。大多数时候这是好事，但偶尔也会让人心里一紧：它到底改了哪些？还能不能回去？

Hermes 的 checkpoints 就是保险绳。

启动时可以打开：

hermes chat --checkpoints

之后如果改坏了，可以用：

/rollback

或者指定回滚到前几个快照。

我建议在这几类任务前主动开启：

批量重构
自动修复 lint
修改配置文件
数据迁移脚本
批量处理文章或图片

有了回滚，你对 Agent 的信任会明显提高。因为你知道它不是“不可逆地乱改”，而是在一个可恢复的轨道上工作。

这里还有一个习惯：

让 Hermes 每次完成后给出变更摘要。

不是“我完成了”，而是：

改了哪些文件
为什么改
怎么验证
如果要回滚，用什么命令

这四项会极大降低失控感。

Part 7：技能系统要养，不然会变成垃圾堆

上一篇我说 Hermes 的技能沉淀是杀手锏。现在补一句：

技能系统不是收藏夹，它更像团队 SOP。

收藏夹的问题是越存越多，最后谁也不看。技能也一样，如果每个小技巧都沉淀成一个 Skill，半年后你会有一堆过期、重复、互相冲突的文档。

我现在会按这三个标准决定要不要保存成技能：

值得保存

经过 3 次以上试错才跑通的流程
涉及多个工具、多个系统的固定流程
用户明确纠正过偏好的做法
以后每月至少会复用一次

不值得保存

一次性任务进度
某个临时链接或 ID
今天刚修好的一个小 bug
一周后就会过期的状态

需要定期清理

命令已经失效
路径已经变化
同类技能重复
技能太长，核心步骤埋在废话里

Hermes 有 curator 机制，可以帮助维护技能生命周期。但我的建议是：不要完全依赖自动清理，最好每隔一段时间让它做一次“技能体检”：

帮我检查最近一个月最常用的技能，找出过期、重复、冲突的地方，给出合并建议。不要直接删除，先列清单。

真正高级的用法不是“让 AI 什么都记住”，而是“让 AI 只记该记的东西”。

我现在推荐的 Hermes 工作流

如果把上面这些合起来，我会建议这样搭：

轻量个人版

适合刚进阶的用户：

1 个默认 Profile
内置记忆 + Session Search
少量高频 Skill
只开文件、终端、搜索、浏览器
每周手动备份一次

内容创作者版

适合做公众号、Newsletter、小红书：

default：日常助手
content：内容生产 Profile
Cron：每天自动筛选选题
Skill：固定发布流程、排版规范、封面规范
发布前检查：摘要、封面、外链、模板重复

开发者增强版

适合写代码和维护项目：

default：需求讨论
dev：代码修改
reviewer：代码审查
Checkpoints：所有批量修改前开启
delegate_task：复杂任务拆成方案、实现、审查三步
GitHub/Webhook：Issue、PR 触发自动分析

自动化工作台版

适合想把 Hermes 接进真实工作流的人：

多 Profile 隔离职责
Cron 定时信息筛选和监控
Webhook 接外部事件
MCP 接业务系统
Worker Profile 负责执行
主 Profile 负责决策和审核

这个版本才是 Hermes 最有潜力的形态：

不是一个更聪明的聊天机器人，而是一套可以被你编排、审计、复用、持续改进的个人自动化系统。

最后，说点大实话

Hermes 的进阶用法并不在于“开更多功能”。

恰恰相反，真正用得顺的人，通常是在做减法：

把不同任务拆到不同 Profile
把重复流程沉淀成 Skill
把固定时间的事交给 Cron
把外部事件交给 Webhook
把复杂任务拆给子 Agent
把高风险改动放进 Checkpoint
把低频工具从默认上下文里移出去

这套思路一旦跑通，Hermes 就不再只是一个问答助手，而是变成一个“会记事、会分工、会定时、会接事件、会复盘”的工作系统。

上一篇文章的结论是：Hermes 值得作为主力助手。

这篇补充后的结论是：

如果你只是把 Hermes 当聊天框，它确实只是一个更顺手的 AI；但如果你开始用 Profile、Cron、Webhook、Skill 和子 Agent 去组织它，它就会慢慢变成你的个人操作系统。

这才是我觉得 Hermes 真正值得继续投入的原因。

如果这篇文章对你有启发，欢迎点个赞或在看。

也欢迎留言聊聊你的实践经验。

留言区见。