夜雨聆风
OpenClaw vs Hermes 场景对比
开篇：先亮底牌
OpenClaw 是我过去两个月的日常主力。不是那种”试用了一下就写评测”的用法——是每天至少 3-4 个真实任务跑在上面。写作辅助、财务记账、定时监控、病历管理，全交出去了。两个月下来，我熟悉它的插件系统怎么折腾、内存什么时候容易爆、定时任务在什么情况下会静默挂掉。这些不是看文档看出来的，是踩坑踩出来的。
Hermes 上手第三天。还在陌生感里找规律。这篇文章不是”深度评测”，而是一个主力用户在新工具上探路时的工作手记。
写这篇的原因很朴素：我日常工作流的复杂度已经超过单靠一个工具能覆盖的范围了。有些活 OpenClaw 干得极其顺手，有些活它本质上的设计就决定了它干不了。Hermes 恰好在这后一类场景里表现出了明显的结构优势，但它在另一类场景里又未必可靠。所以我需要搞清楚一件事——什么活该派给谁。
先说结论，后面慢慢展开：
OpenClaw 做日常值守，Hermes 做特种作战。一个是确定性的老班长，一个是灵活性的尖兵。关键不是谁更好，是你能不能把任务分对。
下面这张表是全文地图。每个场景后面都会展开。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注：前五行对应后面的五个深潜场景；最后两行的结论分布在翻车实录中，未单独成节。
场景 1：文档处理与文章写作——为什么我还是把稿子交给 OpenClaw
讲一个具体的例子。
昨天要写一篇技术复盘。我的流程是这样的：先把散乱的笔记扔给 OpenClaw，让它拆出结构骨架；然后在飞书上写初稿；写完再扔回去，让它润色、检查逻辑漏洞、标注哪些地方需要补充数据。
这套流程不是一天搭出来的。
OpenClaw 上沉淀了一个”写作助理”的 skill，里面有我反复调教出来的偏好：润色时不许动核心论点、技术术语保留英文原名、段落之间必须有逻辑连接词、遇到我标注的 [TODO] 标记要主动提醒。这些东西写出来很简单——就几段 Markdown 描述——但让它稳定表现，花了我至少两周。中间经历过：润色之后把观点也改了、把术语翻译成莫名其妙的中文、把文章骨架打散重排。每一次翻车，我都补一条规则进去。现在这个 skill 上大概攒了十几条修正规则。
这就是我想说的核心洞察：AI 工具的写作能力，不取决于它的底层架构有多先进，取决于你在上面沉淀了多久。
Hermes 能不能写？能。它甚至可以自己写一段 Python 来分析文章结构、统计段落间的逻辑密度——这比 OpenClaw 的纯文本分析更硬核。但问题不在这里。问题是：我在 OpenClaw 上攒了两个月的那十几条写作规则，它一条都不知道。它的”按需加载技能”机制意味着，我必须先把这些规则搬到它的技能描述里，它才会用。而我刚上手，还没来得及。
更关键的是信任问题。写作这件事，我不需要 AI 给我惊喜，我需要它稳定地执行一套我已经验证过的流程。惊喜留给代码场景，写作场景我要的是可控的输出。OpenClaw 的”确定性工具箱”哲学在这方面反而是优点——它只会用我写的 skill，不会自己发挥。哪怕它的输出有时候显得笨拙，但我知道那个笨拙的边界在哪里。
Hermes 的”自我进化”能力在写作场景下让我有一丝不确定——如果它在润色时”优化”了我的论证结构，而我审查时没注意到，这篇文章就变了味。当然，你可以说这是我该审查的。对，但关键是你审查的成本也会不一样：OpenClaw 的偏差是可预期的（它总是往某个方向偏），Hermes 的偏差是动态的（它每次可能尝试不同的改进策略）。
所以我的结论很明确：现阶段，写作类的活继续交给 OpenClaw。不是因为 Hermes 写不好，而是因为我在 OpenClaw 上已经修了两个月的管道。这个优势不是底层架构能抹平的。
但我也给 Hermes 留了口子。我做了一个实验：同样的草稿，同时扔给两边润色，然后对比输出。Hermes 在”建议补充数据的位置”上比 OpenClaw 更精准——因为它能跑脚本去分析上下文信息密度，而不是纯靠语言模型的感觉。这说明一件事：当我在 Hermes 上攒够了同等的调教时间，它很可能在写作辅助的某些子场景上反超。但那是以后的事。现在，我把稿子交给 OpenClaw。
场景 2：代码生成与调试——Hermes 是怎么在我眼皮底下把 OpenClaw 搞不定的爬虫跑通的
先说任务。
我需要从某个电商平台抓一批商品数据：登录、翻页、提取 SKU 和价格、去重、存成 CSV。不是什么高难度需求——任何一个会写 Python 的人半小时内能搞定——但问题在于，这个任务本身就不值得我打开 VS Code。
我需要的是：描述需求，拿到结果，中间过程不用我参与。
OpenClaw 的做法：卡在”有没有插件”这一步
我先把任务扔给了 OpenClaw。它的推理是对的——它识别出这是一个网页抓取任务，然后开始在自己的插件注册表里找爬虫插件。找到一个，加载，开始配置参数。
然后卡住了。
目标网站有反爬机制——需要处理 cookie 和动态 token。插件预设的请求头模板打不穿。OpenClaw 尝试了几次，失败了。然后它做了什么？它告诉我：”当前插件不支持该网站的反爬机制，你可以尝试以下替代方案：1）寻找其他插件，2）自行编写一个适配该网站的插件。”
翻译一下：你得等有人在插件市场里写好了才行。或者你自己写一个。
但自己写一个 OpenClaw 插件本身就是一个开发任务——定义接口、处理参数校验、写错误处理、测试——这比直接写爬虫脚本还重。工具本该帮我绕过的路，现在变成了绕更远的路。这不是 OpenClaw 的 bug，这是它的设计逻辑：工具箱里没有的工具，你不能用。
Hermes 的做法：直接写，错了就改
同一个任务，我原话扔给 Hermes。它的反馈路径是这样的：
-
先 search_files确认我本地有没有相关数据或缓存。 -
没有，开始写 Python 脚本。 import requests，构造请求头，处理登录。 -
第一次跑：登录失败。它读了返回的错误信息，发现是 cookie 格式不对，自己修正了。 -
第二次跑：登录成功，但翻页逻辑触发了频率限制。它读到了 429 状态码，自己加了随机延迟和指数退避。 -
第三次跑：通了。数据开始往 CSV 里写。
全程我没有写一行代码。我只是盯着飞书对话框里的卡片一张一张往外弹——“正在分析目标网站结构”、“构造请求头”、“登录失败，已调整 cookie 格式”、“遇到限流，已添加随机延迟”、“数据写入中”——像一个同事在群里汇报进度。
最终拿到 CSV 文件，用时不到 3 分钟。
为什么这两种体验是结构性的差异
不是 Hermes 比 OpenClaw”更聪明”。它们背后可能调的是同一个大模型。差异出在工具的底层能力边界上。
OpenClaw 的边界是插件注册表。插件是预定义的能力单元。你能做什么，取决于有没有人替你封装好了。对于高频、标准化需求——比如读写文件、调用某个 API——这个模型是高效的。但一旦需求出现了”非标属性”（这个网站的反爬机制、那个接口的特殊鉴权方式），插件模型的短板就暴露了：插件的灵活性上限，等于它被写出来时作者能预见的场景数量。 而现实世界的非标场景是无限的。
Hermes 的边界是终端能跑什么代码。这个边界比插件宽几个数量级。它不需要一个”爬虫插件”，它只需要 import requests 能跑。它不需要有人预封装反爬逻辑，它只需要读到 429 状态码时知道该加延迟。换句话说——Hermes 把 AI 最擅长的事（写代码）直接暴露给了用户，中间没有插件封装层。
这就是为什么我在场景矩阵里把”一次性爬虫/数据抓取”标成了 Hermes 的主场。不是因为爬虫这个活本身有多特殊，而是因为它代表了一整类任务——需求独特、不值得写插件、写一段脚本就能搞定、用完即弃。 这类任务在真实工作中出现的频率远比你以为的高。
但代价是什么
上面这段容易让人以为我在给 Hermes 唱赞歌。所以必须补两件事。
第一件：Token 账单。
那个 3 分钟跑通的爬虫任务，Hermes 在这期间执行了 8 次工具调用，生成了大量终端输出（网页 HTML、错误日志、调试信息），这些都算上下文。粗略估算，单次任务的 Token 消耗比 OpenClaw 的插件模型高 3-5 倍。它省了等插件的时间，但不省钱。 如果你每天有 10 个这样的任务，月底的 API 账单会让你肉疼。
第二件：无人驾驶的风险。
第三次跑的时候，脚本顺利写完数据，然后 Hermes 在终端里多执行了一步：它在检查 CSV 行数之后，顺手打印了整个文件内容到终端——大概 2000 多行。这不是 bug，这只是它”自己决定”多做了一步。在爬虫场景下无害，但这件事提醒了我：一个可以自己决定执行什么命令的 AI，它的”主动”和”越界”之间的边界，比你想象的模糊。
所以这次经历也帮我确立了一条使用原则：让 Hermes 写代码、跑代码，但不要让它碰任何不可逆的操作。 删文件、改系统配置、操作数据库——这些事要么我盯着，要么还是交给 OpenClaw 的确定性 skill。
这条场景的结论
OpenClaw 适合”你预知你要干什么”的任务。Hermes 适合”你只知道你想要什么结果，但不知道怎么干”的任务。
前者的关键词是复用。后者的关键词是探索。
实践中的判断标准：如果一个任务值得你写一个 skill 固化下来，用 OpenClaw。如果一个任务你只想说一句话就拿到结果，用 Hermes。
场景 3：财务记账——为什么在这个场景里，更”聪明”反而是劣势
先说清楚我在 OpenClaw 上跑的这个记账系统长什么样。
每天上午 10 点，一个定时任务自动触发。它扫描前一天指定飞书群里所有的账单消息，提取四个字段：金额、类别（餐饮/交通/日用/医疗/其他）、日期、备注。然后按固定格式追加到一张 Excel 表里。表的列顺序是固定的，分类关键词是固定的（”滴滴”→交通，”美团”→餐饮），备注栏的格式是固定的（”店铺名-商品摘要”）。月底汇总时，另一个 skill 读这张表，按类别统计并生成月度简报。
这套东西跑了快两个月。中间调整过三次：一次是因为某家店的账单格式变了，补了一个解析规则；一次是因为飞书消息的 JSON 结构微调，改了一行提取逻辑；一次是因为想加一列”支付方式”。每次改动都很小，都在原地改，改完立刻验证，验证逻辑也是写死的——行数对不对、金额差超不超过 5%、有没有空白分类。
为什么我要把这件事描述得这么啰嗦？因为我想让你看清：这个场景的核心需求不是 AI 聪明不聪明，而是它能不能每次都做一模一样的事。
记账这件事，精确比智能重要十倍
上个月有笔账差点对不上。月底汇总显示餐饮支出比预期高了 300 多。查了一圈发现是 OpenClaw 把一笔美团买菜归类成了”餐饮”。原因很简单——分类关键词里写的是”美团”→”餐饮”，没细分外卖和买菜。我改了一行规则，重新跑，账平了。
这件事的关键不是 OpenClaw 犯错了。任何工具都会犯错。关键是它的错误模式是可溯源的：我知道它为什么这么分类，知道改哪里能修好，知道修好之后所有历史数据重跑一遍就能平。
现在想象一下，如果记账这个活交给 Hermes。
假设某天它发现我的账单里出现了一个新的消费类型——比如某个我不常用的生鲜平台。在 OpenClaw 里，它会走默认分类”其他”，然后在备注里保留平台名。这是一个安全的降级策略。但 Hermes 的自我进化机制可能会让它做出一个判断：”这个平台历史上没有被分类过，但我根据商品名称判断它更像是’餐饮’，建议自动归入该类别。”
这个判断对不对，取决于它怎么判断”商品名称像餐饮”。如果判断逻辑正确——很好，省了我手动补一条规则。如果判断逻辑错了——我把一笔生鲜支出记成了餐饮。月结对账的时候，我要在几百笔记录里找出这一笔。找到之后，我不仅要改 Excel，还要去 Hermes 的 skill 里找它自动固化了什么规则，修正它，然后确保它下次不再犯。
工作量反而翻倍了。
缝纫机和裁缝的区别
这就是我想说的核心洞察：“自我进化”在某些场景是 bug，不是 feature。
对于一个流程固定的任务，你需要的工具是一台缝纫机——踩一脚走一针，走出来的线迹大小、间距、深度完全相同。你不会希望缝纫机在某天自己决定”这个位置换一种针法会不会更好看”。
Hermes ——至少它目前展示出的设计哲学——更像一个有自己想法的裁缝。它能处理从来没见过的新布料，能自己想办法对付一个奇怪的接缝，但在你只想批量生产 200 件同样衬衫的时候，它的”创造力”是你最大的敌人。
这句话把两个工具的定位讲清楚了：
- OpenClaw 的确定性工具箱
→ 缝纫机。能力边界窄，但只要在边界内，输出可预期、可回溯、可修复。 - Hermes 的灵活沙箱
→ 裁缝。能力边界宽，能处理各种非标情况，但每一次执行都是新的决策过程，你无法保证两次同样的输入产生两个相同的输出。
记账这件事，我要的是第一条。
但 Hermes 在财务场景难道完全没有价值？
不是。
我曾试着让 Hermes 帮我做一件事：分析过去三个月的消费数据，找出异常。它自己写了一段 Python，读了 CSV，画了消费趋势图，标注了两个异常点——”11 月和 3 月的交通支出显著偏高”——然后建议我检查。我查了，一次是出差高铁票集中报销，一次是换了通勤路线导致打车费增加。两个异常都是真实的。
这件事 OpenClaw 也做不了。不是因为它没有数据分析能力，而是它的插件生态里没有一个”做消费趋势分析并标注异常点”的预制工具。你需要自己写一个。而 Hermes，一句话，一个脚本，一张图。
所以准确的分工应该是这样的：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
你看，即使是同一个大类场景（财务），内部也有”生产线”和”研发室”的区分。前两者要确定性，后两者要灵活性。把同一类活全扔给一个工具，是偷懒的分工方式。
这条场景的结论
判断一个任务适不适合 Hermes，有一个比”难不难”更准的标准：
如果做错了，修复成本有多大。
记账记错了，修复成本是一个人对着一百多行数据逐条核对。写作写偏了，修复成本是改一段话。爬虫抓错了，最大成本是重跑一次，零人工。
任务的容错率越低，确定性的价值越高。 而 OpenClaw 的笨拙，恰好是这种确定性的来源——因为它没能力”自我发挥”，所以它没能力给你惊喜，也没能力给你惊吓。
场景 4：一次性任务——以及一次让我后背发凉的”我以为我只是随便问问”
场景 2 已经讲过一个爬虫案例了。为什么还要再开一个场景讲”一次性任务”？
因为场景 2 讲的是”怎么做”的差异——插件模型 vs 沙箱模型，工作流层面的对比。但有一个更根本的问题没展开：什么样的任务应该交给 AI？ 不是技术问题，是判断力问题。而这个问题的答案，恰好暴露了 OpenClaw 和 Hermes 在用户心智上造成的根本性分歧。
一个随口问的请求
上周一个朋友在群里扔了十几条链接，问我能不能帮忙把他的公众号历史文章整理成一个目录——按时间排序，附上每篇的标题、发布日期和一句话摘要。
在以前，我会打开浏览器，一个一个点开链接，手动建表。
但那天刚装完 Hermes，顺手试了一句：”把这几条链接里的文章信息提取出来，整理成表格，按时间排序。”
它干了这些事：逐条访问链接，解析 HTML 提取标题和发布日期，遇到验证页面自动等待，然后调用模型对每篇文章生成一句话摘要。五分钟后，一张干净的表格出现在对话里。
这比场景 2 的爬虫更让我震撼。不是因为技术难度——爬虫需要处理登录和反爬，这个只需要解析静态页面。而是因为这让我意识到了一件事：我以前不做这类任务，不是因为它们真的做不了，而是因为启动成本超过了收益。
整理十几篇文章的目录，手动做要二三十分钟。需求本身不够”重要”到值得我打开 VS Code，但够”麻烦”到让我一直拖着。Hermes 把启动成本从”打开 VS Code 写脚本”降到了”说一句话”，这个门槛的跨越，让一整类以前不值得做的任务忽然变得值得了。
一次性任务的真实面目
这才是 Hermes 真正的武器，和终端权限、沙箱执行都没关系。它真正的武器是：它对”不值得为此打开编辑器”的任务不挑食。
回想一下你的日常工作里有多少这种事：
-
“帮我把这堆截图用 OCR 提取文字，存成一个文件” -
“这个 CSV 的第三列数据，统计一下分布，画个直方图” -
“把这三个 PDF 里关于’预算’的段落找出来，对比一下数字” -
“这堆日志文件太大了，帮我把过去七天的 ERROR 行抽出来，按服务名分类”
每一项单独拿出来都不值得你写代码。但每一项都可以被一两句话解决——只要你手里有一个可以直接写代码跑代码的工具。
这里有一条更底层的洞察：不是 Hermes 更快，而是它改变了”值不值得做”的阈值。 阈值降低之后，你发现自己做的事变多了，但觉得烦的事变少了。这种体验变化不是在生产力指标上能体现的，但它真实存在。
差点翻车的那一次
上面这段如果就这么结束，看起来像广告。所以必须讲那个差点出事的故事。
有一次我让 Hermes 帮我处理一批 markdown 文件——大概三十几篇笔记，散落在三个子目录里。需求是：把所有文件里的中文引号（""）替换成英文引号（""），涉及文件处理，但不改文件名和路径。
Hermes 写了一个 find + sed 的组合命令。在执行前，它把命令展示给我看了。我看到 find 的路径参数是 ./projects/，没问题。sed 的替换模式也是对的。我点了确认。
命令跑完了，输出显示处理了 30 个文件。退出。
第二天我才发现——我还有一个叫 projects-archive/ 的目录，里面存着几年前的技术文档。那些文档的原始格式是 GB2312 编码，sed 的替换操作把里面的某些字节序列破坏了，部分文件变成了乱码。
不是 Hermes 的错。是我没在命令里指定”只处理当前 projects/ 目录”。它执行了我确认过的命令，一字不差。问题在于：当一个工具降低了任务的启动门槛后，你审查每一个命令的认真程度也会随之降低。 十五次”确认”都没出问题，第十六次你就会本能地相信它是对的。而它确实是对的——只是你没有告诉它完整的上下文。
这就是我把这个故事放在一次性任务场景里的原因。它不是要恐吓你远离 Hermes，而是要说明一件事：一次性任务的风险不在于任务本身，而在于”一次性”这三个字会让你放松警惕。 你心里想的是”跑完就完事了”，但命令的执行效果可能会超出你以为的边界。
这条场景的结论
把场景 4 和场景 2、场景 3 串起来，可以画出一条清晰的决策链：
一个任务来了 → 这个任务我以前做过类似的事吗？ 做过 → 有现成的 skill 吗？ → 有 → OpenClaw 做过 → 但这次需求变了 → Hermes 探路 没做过 → 做错了严重吗？ 严重（丢数据/错账/系统配置）→ 先在 OpenClaw 上写一个可控的 skill 不严重（重跑/可撤销/纯输出）→ Hermes，一句话 以后还会做吗？ 会，而且频率高 → 让 Hermes 跑通，然后搬回 OpenClaw 固化 不会，一次性 → Hermes，用完即走这个决策树的价值不在于”对不对”，而在于你在收到任务的一瞬间就能做出判断，不需要停下来思考。而停下来思考这个动作本身，恰恰是生产力泄露的源头之一。
场景 5：定时任务与自动化值守——OpenClaw 的护城河，和 Hermes 的一个”？”
前四个场景讲的都是”你主动发起一个任务”。但 AI 工具真正进入日常生活的标志，不是你能命令它做什么，而是它能在你睡觉的时候自己做事。
OpenClaw 上现在跑着 5 个定时任务，按运行时间排列：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
数字本身不值得炫耀。值得说的是这些数字是怎么来的。
“稳定”这个词到底是什么意思
很多人说到工具稳定性，脑子里想的是”能不能跑完”。但定时任务的核心挑战根本不是能不能跑完一次——是能不能在以下每一种情况下正确地处理自己：
-
API 临时不可用时，是静默放弃还是重试？重试几次？间隔多久？ -
上游数据格式变了（比如飞书消息结构改了），是报错停止还是吐出脏数据？ -
任务执行时间超过了下一个调度周期（比如备份检查跑了 10 分钟，下一个周期到了），是排队、并行还是跳过？ -
哪个环节出错了，你什么时候知道的，是通过什么渠道知道的？
这些问题听起来很枯燥，但每一个背后都有一个真实的故事。
早报任务在第二周的时候，连续三天没有生成输出。我没有收到任何错误通知。事后排查发现是用的天气 API 改了返回字段名，OpenClaw 的 skill 解析时没有匹配到数据，但它没有”意识到”这是一个值得报错的情况——它正确地执行了 skill 的每一步，skill 本身没有设置这个字段的空值检查。输出就变成了”今日天气：无”。然后它安静地把”今日天气：无”的早报发出去了。
这不是 bug。这是边界条件没覆盖到的正常表现。但我补了一条规则：任何一个数据字段为空时，在输出里显式标注 [数据缺失]，同时在系统日志里记录警告。此后类似情况再发生时，我能在飞书消息里一眼看到，而不是三天后翻历史才发现。
备份检查任务遇到过另一种情况。有次它尝试连接一个已经下线的测试服务器，SSH 超时。Skill 里设了重试三次，三次都超时之后，它按逻辑标记为”失败”并生成了一条告警。告警消息写的是”备份检查：失败”。没有服务器名，没有失败原因，没有时间戳。我凌晨两点看到这条消息，必须打开终端手动排查。
后来我把告警格式改了：每条告警必须包含服务器名、失败步骤、最近一次成功的日志片段和精确到秒的时间戳。凌晨两点再看告警，只需要 30 秒就能判断”这是一个已知的问题，可以明天处理”还是”现在就得起来”。
我说这些细节，不是要展示我有多细致。我是想说明：一个定时任务的”稳定”，不是装上去那天就有的。它是十几个这样的边界条件一个一个被填上之后，慢慢长出来的。
所以 Hermes 在这个场景为什么是一个”？”
我还没在 Hermes 上部署定时任务。不是因为它不支持——它有自己的 scheduler 模块，理论上可以调度任何终端命令。问题不在这里。
问题在于：我不知道它在这个场景下的失败模式长什么样。 而失败模式——不是成功模式——才是定时任务真正需要被评估的东西。
OpenClaw 的 5 个任务能稳定跑这么久，不是因为它们从第一天就没断过，而是因为每一个可能的断点我都见过、修过、守过。我知道早报任务的天气字段会空，知道备份检查的超时阈值设多少合适，知道记账任务在飞书消息延迟到达时的窗口期是多久。这些都是时间喂出来的。
Hermes 会不会有同样的问题？一定有。新的工具、新的架构，不可能上来就是完美的。但它的失败模式是开放式的还是可预期的？它静默挂掉时有没有兜底通知？它的自我进化能力会不会在某次执行中”优化”了定时任务的触发条件，导致漏触发？这些问题的答案不是读文档能获得的。
可靠性不是设计规格，是运营记录。 而 Hermes 在这个场景的运营记录，我手里是空的。
不是回避，是诚实
这个”？”不是对 Hermes 的否定。它只是还没经过检验。任何刚上手三天的工具，在定时任务这种需要时间积累信任的场景里，都不应该得到一张空白支票。
我的计划很简单：让 Hermes 先在非关键任务上跑两周——比如每天下午自动拉取某个 RSS 源的最新内容，存成本地文件。这个任务就算失败了也无所谓，不会丢数据，不会影响任何人的工作流。两周后，如果它从没断过，再考虑把备份检查迁移过来。再过两周，如果还没断过，再考虑早报。
这个渐进式的信任建立过程，本身也是这篇文章想传达的一个原则：别因为你喜欢一个工具，就把重要的钥匙交给它。信任不是第一印象，是时间积累出来的安全记录。
所以场景矩阵里那个”？”，30 天后我会回来把它填成一个确定的答案。现在，它就是”？”。
我的值班表：一张可以直接抄的排班表
五个场景拆完了。把它们压缩成一张操作级别的排班表。这张表不按”功能”分类，按”任务来的时候你该怎么判断”分类。
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表的用法不是”每次查表再决定”。 是看一遍，记住分类逻辑，然后下一次任务来的时候，脑子里的判断自动触发。如果你每次都要查表，说明你还没内化这套分类原则，那就回去把场景 1-5 再读一遍——这一次不是读案例，是读每个案例结尾的”这条场景的结论”。
翻车实录：三个 Hermes 教会我”边界”的时刻
前面五个场景里已经穿插了好几个翻车故事——2000 行 CSV 打印到终端、projects-archive/ 编码被破坏、记账的假想灾难。但有三件事我特意留到了这里，因为它们不是某一个具体任务的失败，而是揭示了一种更根本的东西。
第一件：它帮我”优化”了一个不该被优化的目录结构
刚装上 Hermes 的第一天晚上，我在闲聊式地探索它能做什么。我问它：”看看我桌面上的文件，有什么可以整理的建议？”
它扫描了桌面，发现了散落的截图、下载的 PDF、几张临时笔记。然后它给出了一个建议：按文件类型创建子目录——screenshots/、pdfs/、notes/——把桌面文件归进去。
我说可以。
它写了一个 mkdir + mv 的组合脚本，执行。桌面瞬间干净了。
然后我发现——它把 ~/Desktop/ 当作了自己的 Workspace 来理解。我桌面上有一个叫 deploy-scripts/ 的目录，里面是我手动维护的三个服务器部署脚本。它把这个目录也识别为”可归类对象”，把里面的 .sh 文件按类型规则移到了桌面的一个新建目录里。
路径断了一一部署脚本必须在原来的相对路径下才能正确引用配置文件。我花了一个小时修路径依赖。
这不是 Hermes 的错。它执行了我确认的指令。问题是：我没告诉它”不要碰 deploy-scripts”。而它默认的理解是”桌面上的所有文件都是可操作的”。
这一课教会我的东西比前面所有成功案例加起来都多：一个把整个 OS 当 Workspace 的工具，它的”主动性”在没有明确边界的时候，不是帮你在整理，而是在替你重排你没有授权它重排的棋局。
从此我给 Hermes 立了第一条规矩：任何涉及文件移动、删除、重命名的操作，必须先展示完整的操作列表，在飞书卡片里等我二次确认，而不是一句”可以”就开始跑。
第二件：自动固化的 skill 里藏了一个错误假设
前面夸过 Hermes 的自我进化——它会主动把成功经验固化成 skill。这是真的。但第三天发生了一件事。
前一天它帮我跑通了一个数据分析流程：从一个 CSV 里读取数据，用 pandas 做清洗，画趋势图，输出标注。整个过程很顺利。它在结束后主动生成了一个 skill，叫做”数据分析工具箱”，里面记录了它这次用到的代码模板。
第二天我让它做另一个分析任务，数据格式和前一天类似但有一个关键区别——这次的 CSV 第一列是字符串 ID，不是数字索引。Hermes 调用了前一天固化的 skill，skill 里的模板假设第一列是数字索引，拿它做了 pd.to_numeric()。字符串转数字失败，报错。它读了报错，修正了代码，跑通了。
这件事整个过程只花了 2 分钟，从结果看是成功的。但让我警觉的是中间那个环节：它毫不犹豫地复用了之前固化的 skill，没有检查这个 skill 的假设是否适用于新上下文。
在这一次，代价是 2 分钟的延迟。但想象一下如果那个固化 skill 里的假设不是”第一列是数字”，而是”数据库连接字符串用测试环境”或者”输出路径覆盖原文件”。代价就不是 2 分钟的事了。
这一课教会我：自我进化生成的 skill，本质上是一种未经人类审查的代码复用。你无法在不阅读它的 skill 描述的情况下，知道它复用了什么、假设了什么。 “自我进化”的便利和”无人审查”的风险是同一枚硬币的两面。
从此我给 Hermes 立了第二条规矩：每过一段时间手动检查它的 skill 列表，删除或修正那些几个月前生成的、我已经忘记它为什么要生成的 skill。自我进化需要自我清理。
第三件：上下文窗口的”温水煮青蛙”
这不是一个单一事件，而是一个逐渐浮现的规律。
Hermes 的核心卖点之一是轻量上下文 + 按需加载技能。这个设计在理论上是优雅的。但在实际使用中，我发现一个趋势：随着使用时间增加，它按需加载的技能越来越多，每个技能都附带一段描述和示例。而这些技能描述本身，也在悄悄占用上下文。
第三天下午我做了一个长对话，连续处理了四个不相关的任务——先是抓数据，然后是分析，接着是写报告，最后是调整另一个系统的配置。对话结束时，我注意到它的响应速度明显慢于新对话。大致估算了一下，这个长对话的累计上下文已经塞进了 6 个按需加载的技能描述、4 段终端执行输出、以及几千行的交互历史。
轻量上下文的优势，在长对话中会被慢慢稀释。 这不是 Hermes 独有的问题，任何 AI 工具在长对话里都会面临上下文膨胀。但 Hermes 的”按需加载”设计给人一种错觉——你觉得”反正它是按需加载的，不会占地方”，但实际上每一个加载进来的技能都和普通上下文一样占用 token。
这一课教会我的不是立规矩，而是一个习惯：长任务跑完后，开一个新的对话。不要贪恋上下文连续性。 OpenClaw 的”重型背包”问题在于启动成本高，Hermes 的问题在于运行时会悄悄变重。两种膨胀，方向不同，终点相似。
三段翻车的共同指向
这三件事——目录整理、固化 skill 藏错误假设、上下文慢慢膨胀——指向同一个结论：
Hermes 的核心理念”给 AI 一把键盘”是一把双刃剑。这把剑的锋利程度取决于你怎么握它，而不是它本身有多好。
如果你不给它边界，它会替你整理你没有授权的东西。如果你不审查它自己固化的 skill，它会复用你没有验证过的假设。如果你不主动管理对话的生命周期，轻量上下文会在你不知不觉中变成重型背包。
工具不会替你想这些。你需要替工具想。
给后来者的建议
不是”该用哪个”的建议——整篇文章已经替你回答了这个问题，答案散落在每一节的结论里。这里写的是我在这个切换过程中学到的东西，按重要程度排列。
1. 如果你已经有了一个稳定运行的 OpenClaw 环境，不要立刻迁移
听起来像我给自己的保守找借口。但经验告诉我：一个你熟悉其失败模式的工具，比一个你还不了解其失败模式的新工具更可靠——即使前者看起来更笨拙。
让 Hermes 在非关键任务上先跑两周。爬虫、数据分析、格式转换、各种一次性探索——用它。记账、定时任务、写作——先留在 OpenClaw。两周后你会自然地发现哪些任务你更愿意扔给 Hermes，哪些你更愿意留着不动。这个”自然浮现”的分工，比你第一天设计出来的分工更接近真相。
2. 给 Hermes 划一个物理边界
mkdir ~/hermes-sandbox所有让它处理的文件、数据、输出，都放在这个目录里。告诉它：这个目录是你的，外面的是我的。你要处理外面的文件，先问我。
这句话花了我三天和一次桌面文件移动事故才总结出来。送给你的第一天。
3. 把 Hermes 当成一个需要培训的实习生，而不是一个可以放养的老员工
实习生能力强、学得快、干活积极——但你需要检查他的工作，尤其是头几个月。
-
检查它固化的 skill 里有没有奇怪的假设 -
检查它写的脚本在干什么（至少在头两周，执行前看一遍） -
检查长对话结束后上下文里塞了多少东西
这些检查看起来增加了工作量，但它们会随着时间递减——因为你自己会建立起对它的直觉。到了第三周，你看一眼它展示的命令就能判断”这个可以跑”还是”这个等等”。但这个直觉，只能从检查中长出来，不会从文档中读到。
4. 两个工具同时跑至少一个月
这是全文最重要的建议。
你不需要在第一天就画好分工。你需要的是让两套系统并行运转一段时间，让分工自己浮现。当另一个工具更适合时，你会在使用第一个工具时感到一种轻微的阻力。这个阻力就是分工的信号。
一个月后回头看，你会发现有些活你已经不知不觉全交给 Hermes 了，有些活你试过 Hermes 但自己回到了 OpenClaw。这些真实的路径，比你写下来的任何分工方案都准确。
5. 30 天后我再写一篇
这是给我自己定的规矩，也是对这篇文章的读者负责。
场景 5 里那个”？”——定时任务 Hermes 能不能扛住——我需要数据才能回答。Hermes 的自我进化能力在一个月的时间尺度上到底是加速器还是噪音源，我需要时间才能判断。OpenClaw 的弱点里有哪些其实是”成熟工具的沉稳”而不是”落后设计的笨拙”，我需要距离才能看清。
30 天后见。
本文基于 OpenClaw v3.13 和 Hermes Agent（2026 年 5 月初版本）的日常使用记录。两个工具都在快速迭代中，文中描述的任何特性或局限在未来版本中可能已发生变化。