我把 Hermes 用成了工作台：从聊天到持续干活

用了几个月 Hermes，我最明显的感受是：用它回答问题，和把它慢慢配置成自己的工作台，是两种体验。

前者是有事就问，后者是让它记住必要背景、掌握常用流程，并在约定的时间完成一部分重复工作。我现在更常用的是后者：技术日报投递到飞书，面经整理进文档，秋招进度生成卡片，出门时还能从手机发起任务。

这些用法没有一次配置就全部跑通。真正花时间的，是整理方法、接通工具，以及处理那些平时不显眼、定时运行时却会卡住整个流程的问题。

这篇文章就分享我实际在用的部分。数量、任务安排和报错记录来自我的环境；安装与功能说明可以对照 Hermes 官方文档。

先把背景、方法和临时状态分开

我最开始容易把所有“下次可能用到的东西”都塞进记忆。后来发现，这样很快就会塞满，而且很多内容在无关任务里也会出现。

现在我大致这样分：

放在哪里	我会存什么	怎样使用
持久记忆	环境事实、长期偏好、稳定约定	会话开始时载入必要背景
Skills	某类任务的流程、常见坑和操作方法	相关任务需要时读取
会话历史	一次性讨论、临时状态、过去的处理过程	需要回溯时检索

当前官方文档把持久记忆分为环境笔记 MEMORY.md 和用户资料 USER.md，两者有容量限制，在会话开始时作为快照进入上下文。会话中保存的新内容会落盘，但不会实时替换这份快照。持久记忆文档

对我来说，记忆适合保存“我在 Windows 上工作”“通常喜欢简洁回复”这样的背景。偏好也应该保留弹性：我平时喜欢简洁，不代表这次要求详细分析时还要强行压缩。

而“怎样从飞书记录生成秋招卡片”是一套流程，放进 Skill 更合适。它只在做这类任务时有用，没有必要让每次聊天都带着它。

技能库的价值，是减少反复解释

写这份记录时，我的技能库已经有四十多个 Skill，其中飞书相关的占了很大一部分。高频方向主要是飞书文档和多维表格、资料研究、内容制作，以及开发工具的操作方法。

最直观的例子是飞书多维表格。

以前我要解释接口怎么调、字段怎样处理、视图怎么建。现在同类流程已经沉淀下来，我可以直接说：“给这个表加一个按状态分组的看板视图。”Agent 有了可以参考的方法，我只需要补充这次任务的对象和要求。

当然，Skill 不是装得越多越好。Hermes 的技能系统采用按需读取方式：先查看技能信息，需要时再加载正文和具体参考文件。技能目录信息仍然有成本，不能理解成“不触发就完全不占上下文”。技能系统文档

我的做法是，每次完成一件有点绕、以后可能重复的事，就把正确步骤和踩过的坑整理下来。先确认这次真的跑通，再保存方法。否则保存下来的可能只是一个看起来合理的失败方案。

这也接着我之前写的从提示词到工作方法：Skill 最有用的部分，是它让下一次少一点临场解释和重复试错。

定时任务，是我收益最大的一块

如果只让我保留两个功能，我会选 Skills 和定时任务。前者保存方法，后者让方法在我没有打开聊天窗口时也能执行。

我记录里的三个任务是：

安排（北京时间）	任务	输出
每天 20:00	深夜寓言	选一个学科概念，写一段有一定深度的科普
每天 09:10	每日技术日报	筛选 GitHub Trending 与技术新闻，关注后端、AI 和 Agent
每三天 09:00	面经收录	搜索近期面经，分类追加到三个飞书文档

前两项更像内容阅读，第三项是持续维护资料。任务完成后投递到飞书，我可以直接在那里看结果。

这里最重要的配置经验，是把任务交代清楚。信息从哪里来，什么值得保留，输出多长，写到哪里，以及没有合适内容时怎么办，都需要明确。

比如技术日报，我宁愿它说“今天没有值得单独推荐的内容”，也不希望它为了凑够条数，把低价值信息包装成重要新闻。面经整理则要能识别重复内容，避免文档越长、噪声越多。

在我的配置里，这些任务尽量跟随全局默认模型，方便集中切换供应商。对有特定模型依赖的任务仍然可以单独设置，关键是知道哪些配置会继承、哪些已经被覆盖。

定时运行还需要运行环境保持可用。电脑休眠、服务没启动、网络断开，都可能让任务错过执行或投递。写好了任务说明，只完成了其中一部分。

手机入口，让工作台更容易用起来

我接了飞书机器人，也接了微信 iLink。这样在外面时，可以从手机发一句话，让 Agent 去处理已经配置好的工作。

对我来说，多一个入口的价值很简单：不用等回到电脑前，再把想到的事情重新整理一遍。但不同入口的会话和配置需要核对，不能仅凭“都是同一个 Agent”就认定所有上下文自动共享。

微信这边我遇到过一个容易误判的问题：超过约二十四小时没有主动发消息后，机器人的主动投递失败，报错看起来像 rate limited，当时排查下来却和会话窗口有关。

这个记录来自我使用的接入方式和版本，不能把所有同名报错都归因于会话过期。我的经验是，投递失败时要一起检查会话状态、平台响应和任务日志，别只盯着错误文案里“限流”两个字。

外部 CLI，是这些流程真正落地的地方

我用得比较多的两个外部工具是 lark-cli 和 opencli。

前者负责飞书里的具体操作，比如读文档、追加记录、处理表格。后者让我把网站上的操作组织成可自动化的调用，再通过 Skill 把使用方法交给 Agent。

我不会要求模型每次重新探索所有接口和按钮。已经验证过的命令、参数和输出格式，应该尽量复用。模型负责理解这次要做什么，工具负责执行明确的动作。

这和我在关于 MCP 与 CLI 的笔记里讨论的是同一件事：接口形式之外，更重要的是能力是否稳定、结果是否清楚，以及多个动作能不能顺利衔接。

在 Windows 上，这里面还藏着一个很现实的坑：Node 版本和 PATH。某个 CLI 在交互终端里能运行，不代表 Git Bash 或后台任务也能找到它。我把工具装在特定 Node 环境下，就需要确认实际执行任务的环境指向了正确路径。

一个完整例子：把秋招记录变成分享卡片

我的秋招记录放在飞书 Wiki 下，主要是每日 TODO、刷题记录和投递面试记录三个文档。

围绕这些已有记录，我做了一条流程：晚上读取当天进度，用 Python Pillow 生成两张 1080 × 1440 卡片，再上传图片，配上已经验证过的话题标签，发布到小红书。

第一张是“秋招 Day X”，第二张展示今日进度和明日计划。它让记录和分享用同一份事实来源，我不用再手动复制整理一遍。

一个很小但很有用的细节是：卡片上的对勾和方框，我最后改成了用 draw.line 和 draw.rectangle 绘制。Emoji 在不同字体和设备上的表现差异很大，可能错位，也可能变成缺字方块。固定版式里的简单图形，直接画出来更容易控制。

第一版效果并不好，改了三轮才稳定。这几轮不只是改提示词，还包括调整取数、内容密度、排版和图形渲染。完成一条自动化流程，通常需要沿着整条链路看结果。

让失败可见，比让它安静运行更重要

我遇到过一次 lark-cli 的用户 Token 失效，任务写飞书一直失败，返回 4030004，生成的内容只能留在本地。

如果只看“任务有没有启动”，很容易以为一切正常。实际需要分开看：内容有没有生成，目标文档有没有写入，消息有没有成功送达。前一步完成，不代表后一步也完成了。

所以我现在很看重失败记录和投递状态。自动化省掉的是重复操作，不能顺便把异常也藏起来。

对长任务，我还会明确要求“精选，不要全塞”，并让它说明省略了什么。对涉及已有文件、配置或文档的改动，我倾向于先看问题和修改范围，再确认需要对外生效的部分。这样我能把注意力放在关键决定上。

我真正留下来的，是一套能继续改进的方法

Hermes 对我最有用的地方，是把几样原本分散的东西接起来：背景放进记忆，方法放进 Skill，实际动作交给工具，重复任务按时运行，结果回到日常使用的飞书和微信。

模型能力仍然重要，但很多体验差异来自这些具体配置。一个知道该读哪份文档、调用哪个工具、输出什么结果的助手，才更容易进入我的日常工作。

如果要从一个地方开始，我会先挑一件自己每周都在重复做的事。把输入、步骤和结果说明白，手动跑通几次，修正问题，再决定是否交给定时任务。

对我来说，这就是“养”一个 Agent 的实际含义：把用过的方法和遇到的问题，慢慢变成下一次还能用上的经验。

本文根据我的 Hermes 使用记录整理，发布于 2026 年 10 月 6 日。具体功能、容量与平台行为，以实际安装版本和 官方文档 为准。