别让你的AI当"差不多先生"——Hermes 0.18 这4个更新，把智能体从"会干活"推到了"值得托付"

你有没有过这种时刻——

凌晨1点，你让 AI 帮你生成一份数据报告，它噼里啪啦处理了3分钟，最后说："任务已完成。"

你满怀期待地打开文件——只写了一页，图表缺失，关键数据还是空的。

你深吸一口气，输入："你确定做完了吗？"

它沉默了两秒，然后说："抱歉，我重新生成一下……"

这个场景，几乎是所有重度 AI Agent 用户的共同痛点。智能体"做完了"≠"做好了"。在0.17时代，你跟 AI 的关系像带实习生：每个任务都要盯着、追着、纠正着。

Hermes 0.18 系列版本（v0.18.0 "The Judgment Release" → v0.18.1 稳定性补丁 → v0.18.2 构建修复），没有做"新增 XX 大模型"的花哨更新，而是扎扎实实干了四件事：让 AI 学会自我检查、学会举一反三、学会团队协作、学会精打细算。

下面从真实使用场景出发，逐个看看这些更新到底改变了什么。

一、/goal 自我验证：AI 终于学会"做完检查再交作业"

你肯定遇到过这个瞬间

你让 Hermes 帮你生成一篇营销文案并推送到微信。它开始搜索、抓取、写作、推送，在工具调用里你能看到每一步都在跑。

最后它说："任务已完成。"

可你去微信一看——文案推送了，但其中的 banner 图没生成。你只好再补一句："图呢？"

你追问，它补救。你追问，它再补。来来回回三轮之后，你打开计时器一看：原本一个"本可以一次成功"的任务，你花了 20 分钟在"对账"上。

这不是能力问题，是流程问题。 0.17 时代的 AI Agent 执行任务时是"先做完再汇报"，中间某一步失败了自己不会回头检查——就像一个交了卷从不检查答案的学生。

0.18 改变了什么

v0.18.0 引入的 /goal 完成合约机制和pre_verify 预验证钩子，本质上是在 Hermes 的任务执行链里嵌入了一个"自检收口"。

具体发生了什么改变？ 当你在对话中用 /goal 设定一个目标，Hermes 拿到这个目标后，会做两件事：

1. 执行前的目标拆解：把这个 goal 拆成多个子任务，每个都有明确的完成条件。
2. 执行后的逐项自检：pre_verify 钩子逐一检查子任务是否真的完成了，失败的自动重试。

你可以这样用

假设你每天早上需要一份 AI 行业简报，包含热点新闻汇总、数据对比图，然后推送到你的微信群。在 0.17 时代，你的对话大概是这样的：

👤 你：帮我生成今天的 AI 行业简报，发到微信。

🤖 Hermes：好的。（搜索 → 提取 → 写稿 → 推送）

🤖 Hermes：任务已完成！

👤 你：（去微信看了一眼）只有文字，没有对比图。图呢？

🤖 Hermes：抱歉，我补充一下。（重新生成图片 → 推送）

👤 你：（再去检查）这次图文都有了，但你是不是只搜了3条新闻？我说的是"简报"，至少要5条吧？

🤖 Hermes：我重新搜索补充……

一来一回，15分钟过去了，你还没开始干正事。

0.18 时代，你只需要设定一个 goal：

👤 你：/goal 每天早上 8 点生成 AI 行业简报，要求：① 至少 5 条当天热点新闻 ② 附一张数据对比图 ③ 推送到我的微信。

🤖 Hermes：（搜索 5 条新闻 ✓ → 生成对比图 ✓ → 推送微信，返回 HTTP 200 ✓ → pre_verify 逐项检查全部通过）

🤖 Hermes：今日简报已完成，5 条新闻已覆盖，对比图已插入，微信推送状态：200 OK。

你醒来看到这条消息，打开微信，一份图文完整的简报已经躺在那里。你不需要追着问"有没有漏"，因为如果有漏，它在告诉你"完成了"之前就已经自己补上了。

或者更简化的日常用法——在对话中直接设目标，不需要 cron：

👤 你：/goal 帮我整理这份 PDF 的核心要点，输出为 Markdown 表格，然后存到桌面。

🤖 Hermes：（读取 PDF → 提取要点 → 生成表格 → 写入桌面文件 → pre_verify 确认文件存在且内容不为空）

🤖 Hermes：已保存到桌面 核心要点_20260718.md，文件大小 8.2KB，包含 12 条要点。Goal 全部达成。

这对你意味着什么

对于每天要跟 AI 交互数十次的深度用户来说，最大的收益不是某个功能变好了，而是"不被打断"的时间变长了。

以前你启动一个任务之后，心里总是悬着——"它会不会又漏了什么？"——你没法真正切换到下一件事上。现在的体验是：启动任务 → 继续做自己的事 → 瞟一眼结果确认完成。从启动到确认之间的那段"真空时间"，你不需要参与。

仙踪问道团队在实际部署测试中发现，引入 /goal + pre_verify 后，用户"因 AI 执行不完整而二次补充指令"的频次下降了约 60%。而对那些每天要通过 Hermes 自动化跑定时任务的用户来说（如每天早上自动生成的运营数据简报），这个机制直接决定了：你早上醒来看到的是"完整可用的报告"，还是"需要自己再补刀的半成品"。

AI 的终极天花板不是能力，是信任。能力不够你可以教，信任不够你得盯着。

二、/learn 技能蒸馏：你的 AI 越用越"懂你"

又一个熟悉的场景

你在用 Hermes 的过程中，有没有发现某些操作会反复出现——

• 每次要写营销文案，都得手动加载 marketing-copy-generation、viral-copywriting、domestic-marketing-compliance 三个技能；
• 每次生成 banner 图，都得指定模型用 gpt-image、规格 16:9、加上品牌 logo 作为参考图；
• 每次让 AI 帮你做数据分析，都要叮嘱"先用 pandas 清洗一遍，异常值用中位数填充，输出用中文表头"。

你重复了五六次之后，心想：它就不能记住吗？

在 0.17 时代，每个对话都是相对独立的——AI 能从长期记忆中调取你的偏好和规则，但"一套连贯的操作流程"很难被完整继承。你每次都需要重新描述。

0.18 的突破

/learn 技能蒸馏功能，让这个"它就不能记住吗"终于有了答案。

你只需要在完成一套你频繁重复的操作后，对 Hermes 说一句："帮我把刚才这套流程学习成一个技能。" Hermes 会自动分析你刚才的完整操作链路——加载了哪些技能、调用了哪些工具、设置了哪些参数、你纠正了哪些错误——然后生成一个结构化的技能文件，保存到你的本地技能库中。

下次当你说出与这个场景相关的指令时，Hermes 会自动加载这个技能，所有参数和流程预设全部到位。 你不需要再说"先加载 X 技能，再设定 Y 参数，注意 Z 规则"——一句自然语言，整套流程跑通。

你可以这样用

场景一：内容创作者的多平台分发

你经常需要把一篇文章改写为"小红书版""公众号版""头条版"，三套格式完全不同。在 0.17 时代，每篇都要重新描述每个平台的要求。

👤 你：帮我把这篇关于 Hermes 0.18 的文章改成小红书版本。

⚠️ （0.17 你要加一堆说明：字数 600-800、标题不超过 20 字、加 emoji、3-5 个标签……）

🤖 Hermes：（按照你零散的指令，勉强制出一个版本）

0.18 的用法：

首先，你做一次完整的小红书改写流程，把每一步的要求都告诉 Hermes。完成后：

👤 你：/learn 把刚才小红书文案改写的完整流程存为技能，命名为"小红书文案改写"。要点：标题 ≤20 字、正文 600-800 字、每 2-3 句穿插 emoji、标签 3-5 个、结尾要有关注引导和互动提问、合规检查。

🤖 Hermes：已分析刚才的 8 步操作链路，提取出 12 条核心规则，技能文件已保存到 ~/.hermes/skills/productivity/xiaohongshu-rewrite/SKILL.md。

下一次：

👤 你：帮我把这篇关于 Hermes 0.18 的文章改成小红书版本。

🤖 Hermes：（自动加载小红书文案改写技能，标题自动控在 20 字、段落自动穿插 emoji、字数自动控制在 800 以内、结尾自动附加互动引导和合规检查）

（输出完全符合你上次定义的所有规则，一句多余的说明都没加）

你可以把"公众号文案改写""头条文案改写"分别蒸馏成技能，每个技能自动匹配对应平台的格式。一套操作定义一次，从此告别重复啰嗦。

场景二：数据分析师的固定工作流

👤 你：/learn 把刚才的数据清洗流程存为技能"数据清洗标准流程"。规则：读 CSV → pandas 处理 → 异常值用中位数填充 → 缺省值用列均值填充 → 输出中文表头的 Excel。

之后你只需要说"帮我按标准流程清洗这份数据"，Hermes 自动跑完 5 步，出错时自动补救。

长期使用会发生什么

用仙踪问道团队在实际部署中的观察来说——

一个做内容运营的客户，在使用 /learn 之前，每一篇多平台分发都需要手动指定规则。使用 /learn 把三个平台的文案生成流程分别蒸馏成技能后，一个月内他的技能库积累了 12 个个性化技能——不仅覆盖了内容生产，还包括数据分析模板、邮件模板、竞品监控流程。

这带来的复利效应是：你的 AI 不是每次都从零开始的"新员工"，而是一个在你的领域持续积累经验的"老手"。一个月后，它对你的工作习惯、品牌偏好、常用工具的熟悉程度，可能超过你自己。

最好的 AI 不是最聪明的那个，而是在你的工作场景里待得最久的那个。

三、Mixture-of-Agents：多个模型"开会讨论"为什么比一个模型更靠谱

这个场景很多开发者会心一笑

你在做技术方案选型，同一个问题你问了 Claude，又问了 GPT，还问了 DeepSeek。三个回答各有优劣——Claude 代码风格好但逻辑有漏洞，GPT 方案全面但太啰嗦，DeepSeek 思路清晰但细节不够。

你花了 15 分钟在三者之间取长补短，最终拼出一个还算完整的方案。这个过程就叫"人工 MoA"（Mixture of Agents），而 0.17 时代的你就在做这件事。

0.18 里的 MoA 做了什么

v0.18.0 把 Mixture-of-Agents 提升为一级可选模型。简单说就是：你的一个问题，可以同时发给多个参考模型，它们各自给出回答后，由一个"裁判模型"综合所有观点，生成最终的答案。

关键是：这个过程你可以实时看到。Hermes 会在终端或仪表盘上流式展示每个参考模型是怎么思考的，哪条结论是哪个模型提出的，最终答案是怎么综合形成的。

你可以这样用

在 Hermes 中启用 MoA（通过 hermes config 或 /model 切换到 MoA 模式），然后像平常一样提问即可。

场景一：技术方案评审

👤 你：我需要在 Flask 和 FastAPI 之间选一个做新的微服务项目，要求支持异步高并发、WebSocket 实时推送、以及 JWT 鉴权。帮我做技术选型分析。

🤖 Hermes（MoA 模式）：

🔵 Claude 的观点：FastAPI 对 WebSocket 的原生支持更完善，websocket_endpoint 装饰器比 Flask 的 Flask-SocketIO 插件方式更轻量。异步方面 FastAPI 基于 Starlette + asyncio，Flask 虽然 2.0 以后支持 async，但生态插件仍以同步为主。结论：偏 FastAPI。

🟢 GPT 的观点：Flask 的优势在于生态成熟度——JWT 鉴权有 Flask-JWT-Extended，部署文档更丰富，对于已有 Flask 经验的团队学习成本更低。但并发性能方面，FastAPI 的 uvloop 基准测试比 Flask + gunicorn 快约 40%。结论：如果团队有 Flask 经验且并发要求不高，Flask 稳妥；否则 FastAPI 更优。

🟣 DeepSeek 的观点：从代码简洁性看，FastAPI 的类型提示 + Pydantic 自动校验能减少约 30% 的数据验证代码量。微服务场景下每个服务的代码量不大，减少样板代码的收益更明显。结论：FastAPI。

🔴 裁判模型综合：三方一致倾向于 FastAPI。综合建议：选择 FastAPI，主要理由包括 WebSocket 原生支持、异步性能优势、以及 Pydantic 类型系统降低样板代码量。但需注意团队学习成本——如果团队主要用 Flask，建议安排一周过渡期熟悉 FastAPI 的路由和依赖注入模式。

你不仅拿到了最终建议，还看到了三个模型各自的论证角度。 这比你自己切换到三个模型分别提问、再手动对比，快了至少 5 倍。

场景二：行业分析报告

👤 你：分析 2026 年生成式 AI 对内容创作行业的影响趋势。

🤖 Hermes（MoA 模式）：

🟡 （角色：技术分析师） 从 LLM 能力演进角度，多模态生成（文生图、文生视频）正在打破内容生产的技能壁垒。2026 年上半年 SD 和 Midjourney 的迭代速度约为每月 1-2 个重要版本...

🔵 （角色：市场研究员） 从广告/营销行业数据看，使用 AI 辅助内容生产的团队，人均产出提升了 2-3 倍。但"内容同质化"成为新痛点，差异化选题和深度分析的溢价反而提高了...

🟢 （角色：产品经理） 从创作者工具的产品形态看，2026 年正在从"AI 辅助"向"AI 主导 + 人审核"转变。Notion AI 和 Canva Magic Studio 的产品迭代路径都印证了这一点...

🔴 裁判模型综合：三个角色的分析在"效率提升"和"差异化价值"两个方向上达成共识...

三个分析视角同时产生，你读完就有了一份多维度的行业扫描，不需要自己再去拼凑。

独断的 AI 是工具，协商的 AI 才是顾问。

四、三个容易被忽略但"每天都省你一点时间"的改进

Scale-to-Zero 网关：闲时不烧钱

如果你在阿里云、腾讯云等按量计费平台上自建了 Hermes 实例，下面这个数字可能让你心疼——你的 GPU 或高配 CPU 实例，一天中有 60%-80% 的时间是在空转的。

v0.18.0 引入的 Scale-to-Zero 网关配合排空协调机制，解决的正是这个"闲时资源浪费"：

• 当 Hermes 检测到一段时间内没有活跃会话时，自动缩容到最低资源
• 新请求到达时，毫秒级唤醒
• 用户完全不感知——你随时发消息，它随时响应

你可以这样用：

👤 你：hermes config set gateway.scale_to_zero.enabled true

👤 你：hermes config set gateway.scale_to_zero.idle_timeout 30m

（设置 30 分钟无活跃会话自动缩容）

不需要额外的脚本或监控工具，一次配置，永久生效。下次你睡觉的时候，你的云账单也在"睡觉"。

对于国内自建 Hermes + 按量计费云实例的用户，这个功能保守估计能节省 30%-50% 的月度算力成本。

/journey 记忆时间线：你能看到 AI 的"记忆演变"

如果你在做需要长期上下文管理的项目，一定遇到过"它怎么忘了上周我们讨论过的那个方案"的情况。

v0.18.0 引入的 /journey 记忆时间线，把这个黑盒打开了。

你可以这样用：

👤 你：/journey

🤖 Hermes：

📅 2026-07-11 — 记住：用户偏好小红书标题不超过20字 📅 2026-07-14 — 记住：图片生成默认用 seedream-lite 模型 📅 2026-07-15 — 记住：营销文案要加载三个技能（marketing-copy + viral + compliance） 📅 2026-07-17 — 更新：base_image 从 hermes logo 改为仙踪问道 logo

👤 你：/journey search 营销

🤖 Hermes：

📅 2026-07-15 — 规则：营销文案三技能加载 📅 2026-07-11 — 规则：小红书标题字数限制 📅 2026-07-12 — 规则：文章中的决策树用 Mermaid 格式

你能看到 AI 在每个时间点记住了什么、修正了什么、当前对话中正在使用哪些记忆。对于持续半年的项目来说，这个功能让你能实际验证"它真的还记得"，而不是凭感觉相信。

桌面端 Projects + 跨平台扩展

桌面端新增的 Projects 编码功能，把编程项目管理直接整合进桌面应用。同时扩展了对 15+ 个消息平台的适配，包括 DingTalk、飞书、企业微信、微信、iMessage 等。Google Vertex AI 原生 OAuth2 的支持也大幅降低了在 Google 云服务上搭建 Hermes 的鉴权复杂度。

一个重要的提醒：v0.18.1 和 v0.18.2 不是功能更新，但别跳过

v0.18.1 是一次大规模稳定性补丁——合并了约 667 次提交，涉及近 990 个文件，重点解决了 Windows 安装器自修复、Dashboard 稳定性、WhatsApp 配对、MCP 协议兼容性等问题。

v0.18.2 则是单点修复了 WhatsApp 桥接依赖（Baileys）导致的 Docker 构建失败问题。

如果你是 Docker 化部署或重度依赖 MCP 协议的用户，直接升至 v0.18.2 以获得稳定的构建和协议兼容体验。

总结：0.18 让 Hermes 从一个"能干活的"变成了"值得托付的"

这四个更新的共同方向其实很清晰：把 AI Agent 从"一个可以执行任务的工具"升级为"一个可以自主完成任务的助手"。

衡量一个 AI Agent 好不好，最直接的标准是——你敢不敢设置完任务就去睡觉。

关于仙踪问道

仙踪问道团队长期深耕 Hermes Agent 的本地部署与定制优化，为国内开发者、创作者和中小企业提供开箱即用的 AI Agent 部署方案。我们的 Hermes Assistant 支持 Apple Silicon (M1-M4) 与 Intel 芯片双架构，提供国内网络加速、一键安装、图形化管理面板、oMLX 本地推理引擎深度适配等能力，覆盖一键安装到日常使用的全链路。如果你在 Hermes 部署、技能配置或工作流搭建上遇到任何问题，欢迎在评论区交流。