用 Hermes Agent 100 天后，他总结了 5 个最耗时间的错误

公众号名称：极客BIM设计工坊

作者名称：朗朗晴空

发布时间：2026-06-18 05:38

很多人以为会用 ChatGPT 就算会用 AI，但真正拉开差距的，是会不会让代理在后台替你完成重复循环。

前一百天里，被浪费最多的是时间

一位开发者在 X 上贴出一段 21 分钟的视频，标题很平实：用 Hermes Agent 100 天的经验。真正让这条内容传播开来的，不是炫技，而是坦诚：他把这 100 天里犯过的 5 个错误，按时间戳一条条摊出来。

视频里的第一句话就刺中了很多人：使用 Hermes 与实际运营 Hermes 的差距。前者是想到什么问什么，后者是把提问变成可重复的循环、把提示词沉淀成技能、把手动触发替换成定时任务。

Hermes 官方 README 里列出的能力并不少：skills、memory、tool use、multi-platform gateway、profiles、cron/schedules、subagents。问题是，大多数人停在了“能用聊天框”这一步。没有让代理记住你是谁，没有把常见提示词固化，没有让 Cron 在后台跑日报，没有把网关挂到 Telegram 或 Discord 上。

把提示词做成可重复的循环

视频里把最有价值的方法放在最前面讲。他提到一个概念：Loop。不是新工具，也不是新文件夹，而是把“一组提示词 + 期望产出 + 下次触发条件”封装成固定格式。

如果你每次问代理的问题都是相似的，比如“整理今天的信息流并给出摘要”“检查项目状态并生成进度卡”，那它们本质上就是同一个 Loop。

在 Hermes 里，Loop 对应的实现方式至少有三种：把常用 prompt 固化到 Skill 里、用 Cron 定时运行同一段自然语言任务、或者把触发条件绑到 Webhook/Polling 上。这三层不是互斥的，而是叠加使用。

聊天不是一个万能容器

视频第二个错误讲得很具体：把所有东西堆进一个聊天窗口。结果是同一个会话里混杂着工作需求、生活杂事、研究任务、代码调试，语境很快互相污染。

他的解法是用 Telegram Topics 作为独立工作区。每个 Topic 代表一个长期任务，上下文隔离，历史不会混在一起。官方 README 也支持这种思路：Hermes 支持多平台网关，一个 Gateway 可以同时接 Telegram、Discord、Slack、WhatsApp、Signal 和 Email，但上下文是分会话管理的。

他推荐了三种工作空间配置：第一种是按项目拆，每个长期项目一个 Topic；第二种是按职能拆，比如研究、写作、编程各自独立；第三种是按触发方式拆，把 Cron 和 Webhook 进来的任务和聊天区分开。

不要只用一个代理做所有事

第三个错误是让同一个代理承载所有任务。他在视频里展示了两个专用子代理：Nova 和 Sage。前者偏执行，后者偏分析。

Hermes 原生支持 delegate_task 派生子代理，每个子代理拥有隔离的上下文和终端回话。父代理只负责分发和汇总。

视频里强调：子代理不是炫技，而是减少主会话的上下文污染。

这一点在官方 README 里也能找到对应：代理可以写成调用工具的 Python 脚本，通过 RPC 把多步流程压进零上下文消耗的回合。拆成 Nova 和 Sage 之后，主代理只保留调度权，执行层下沉到子代理，整个结构会干净很多。

让代理自己跑起来

第四个错误最典型：永远手动触发。你想到什么就问一句，不问就不动。视频专门用一段讲解 Webhook 和 Polling Cron，用来替代这种“人走代理停”的状态。

他举的例子是 Notion 内容板：每当内容板更新，就通过 Webhook 通知 Hermes，Hermes 自动拉取并生成下一轮任务。另一种是 Polling Cron，让代理按时间间隔自动检查外部系统有没有变化。这两种方式对应着两种不同的世界：一种是事件驱动，一种是时间驱动。

Hermes 官方文档里，Cron 是内置能力，支持自然语言写定时任务，并且可以把结果投递到任何平台。也就是说，你不必守在聊天框前，代理可以自己跑日报、跑备份、跑周审，完成后把结果发到 Telegram 或 Discord。

给自己建一个任务控制台

视频最后一个错误是“永远在聊天里管理一切”。代理的运行状态、任务队列、Cron 列表、历史记录，全部散落在会话窗口里，没有总览，也没有版本。

他的解法是给自己建一个 Mission Control Dashboard：不用额外依赖复杂 GUI，只要把关键信息集中在一个地方，就能看清楚当前哪些任务在跑、哪些代理在线、哪些任务最近执行过。这是一种可见性设计，不是功能堆叠。

Hermes Desktop 在这点上提供了一个现成思路：它不是另一个聊天壳，而是把安装、Provider、Chat、Profiles、Memory、Skills、Tools、Schedules、Gateway、Logs、Backups 集中到同一个桌面控制台。对普通用户来说，它降低的不是模型门槛，而是操作门槛。

从头开始，到底该先做什么

视频最后给了一个顺序：先配好一个 Provider，把基本的 Chat 和 Tools 跑通；再开 Memory，让代理记住你是谁；接着上 Skills，把重复提示词固化成可复用指令；最后再加 Cron、Gateway、Dashboard。

这个顺序的关键，是先跑通“代理能记得住、叫得动”，再追求“代理会自动跑”。跳过记忆和技能直接上自动化，结果往往是你根本不知道它在后台做了什么，出了错也接不住。

最好的学习方式不是看十篇教程，而是用一个真实 Loop 把代理跑通。

这段视频最值钱的地方，是把 100 天的真实使用经验压缩成了 5 条避坑原则。它们不绑定某一个具体功能，而是绑定一种工作方式：把 Agent 从“聊天对象”变成“自动化同事”。

来源

NousResearch, “Hermes Agent” | GitHub https://github.com/NousResearch/hermes-agent

hermes-agent.nousresearch.com/docs | https://hermes-agent.nousresearch.com/docs/

内容效果不满意？点此反馈