Hermes 科普视频｜正式报告式交付（完整版）

> 交付标准：链接内直接看完。 > 本页包含：关键信息、判断结论、完整分析、完整口播稿、完整 prompt/spec 产出。 > 不需要再去本地文件里翻，不靠额外附件补内容。

---

值得做。

原因很明确：

• 它解决的是真实问题，不是空科普
• 它对非专业人士有认知增量
• 它兼具传播性和搜索价值
• 它容易扩展成系列内容

最好的切口不是“全面介绍 Hermes”，而是：

> 把 Hermes 讲成一套普通人也能看懂的 AI 工作台。

推荐主线：

• 项目目录是什么
• ~/.hermes 是什么
• config.yaml 和 .env 分别管什么
• dashboard 和 Open WebUI 分别干什么
• 为什么理解完这 5 件事，你就从“陌生”走到“可控”

《看不懂 Hermes？3 分钟带你走到“第一次敢改配置”》

推荐理由：

• 非专业人士最容易代入
• 有成长感和获得感
• 更适合短视频传播
• 方便后续做系列

---

面向非专业人士做一期 Hermes 科普视频，核心覆盖：

• Hermes 项目文件结构
• ~/.hermes 配置结构
• 如何修改配置
• Hermes 自带 dashboard
• Open WebUI 的安装与使用

> 检索时间：2026-04-16 > 检索对象：Hermes Agent / Hermes CLI / Dashboard / Open WebUI / config.yaml / ~/.hermes / OpenClaw 对比

本轮补充检索的公开来源包括：

• GitHub 官方仓库与 Issues：看真实安装报错、配置疑问、Dashboard / Open WebUI 接入问题、安全问题
• YouTube：看英文社区如何包装标题与卖点
• B站：看中文视频内容最容易打爆的标题与叙事
• CSDN：看中文教程/架构拆解/安装指南的高频表达

从 GitHub issues、中文教程和视频标题看，Hermes 相关讨论最集中在这几类：

真实讨论重点不是概念，而是：

• Windows / WSL 安装兼容问题
• 本地依赖、路径、browser tools、provider 配置
• Open WebUI 接入后看不到工具进度 / reasoning / 模型显示异常
• Dashboard 远程访问、host / CORS / 安全暴露问题

典型公开讨论包括：

• GitHub issue：[Bug]: FileNotFoundError: [WinError 2] 系统找不到指定的文件。
• GitHub issue：[Bug]: Open WebUI - No Tool Progress?
• GitHub issue：display.show_reasoning config option is not honored by the API server adapter
• GitHub issue：api_server: make exposed /v1/models model id configurable

这说明对普通用户来说，真正的热点不是“Hermes 强不强”，而是“为什么我装好了却还不会用”。

围绕 Dashboard 的讨论已经从“有没有”进入“能不能安全给普通人用”：

• 默认只绑本地地址，不方便远程访问
• 用 Tailscale / VPN / VPS 暴露时，host / CORS 配置不够直观
• 直接公开暴露会带来安全风险
• 社区已经出现“first-run onboarding wizard”的需求，说明大家希望它更像可交付产品，而不是纯开发者工具

不管是 YouTube 还是 B站，最容易打爆的不是纯教程，而是：

• OpenClaw killer
• Why I switched from OpenClaw to Hermes Agent
• 完美取代 OpenClaw
• 从 OpenClaw 迁移到 Hermes

也就是说，Hermes 现在的流量入口，本质上是： 新工具爆火 + 旧工作流迁移 + 使用门槛争议。

本轮搜索到的高频关键词大致可分为四组：

• 自我进化 AI Agent
• 长期记忆
• 本地优先
• 开源智能体
• 个人 AI 工作台 / AI 操作系统

• Hermes 安装
• Hermes 配置
• config.yaml
• .env
• ~/.hermes
• Dashboard
• Open WebUI
• API server
• Gateway
• Windows / WSL / Ollama / VPS

• OpenClaw 替代
• 从 OpenClaw 迁移到 Hermes
• OpenClaw killer
• Agent 对比

• 少走弯路
• 保姆级
• 一步到位
• 避坑
• 翻车点
• 真能跑起来
• 别直接公网暴露

当前最值得参考的爆款表达不是“介绍功能”，而是这几种：

• 替代型：Hermes Agent 能不能替代 OpenClaw？
• 避坑型：Hermes 装好了却不能用，90% 的人卡在这几个配置
• 记忆型：这个 AI 助手最狠的不是会聊天，而是会越来越懂你
• Dashboard 型：Hermes 终于有 Dashboard 了，但先别急着公网暴露
• 迁移型：从 OpenClaw 迁到 Hermes，我最明显感受到的 3 个变化

这类表达的共同点是：

• 有问题感
• 有迁移感
• 有风险感
• 有真实使用门槛
• 比“纯概念科普”更容易让观众点开

基于公开讨论，当前用户最强烈的情绪不是“没兴趣”，而是：

• 想试，但怕折腾
• 能跑，但不好用
• 看不懂配置
• 想接 Open WebUI，但显示不对
• 想远程访问，但怕不安全
• 想知道值不值得从 OpenClaw 迁过去

所以这个选题如果只是讲“Hermes 是什么”，会偏空； 如果改成讲“为什么大家都在讨论 Hermes、它到底强在哪、坑在哪、适合谁”，就会更有传播力。

基于公开搜索结果，这个选题适合走 “问题驱动型科普”，而不是“百科介绍型科普”。

最推荐的内容主线是： > Hermes 为什么突然被拿来和 OpenClaw 比？它到底强在哪、难在哪、适合谁上手？

这条主线的好处是：

• 能自然解释 Hermes 的项目目录、~/.hermes、config.yaml、.env
• 能顺势讲清 Dashboard 和 Open WebUI 的角色分工
• 能把“为什么普通人装好了还不敢改配置”讲得更有真实感
• 能同时覆盖搜索价值和传播价值

• GitHub：NousResearch/hermes-agent
• GitHub issue：[Bug]: FileNotFoundError: [WinError 2] 系统找不到指定的文件。
• GitHub issue：[Bug]: Open WebUI - No Tool Progress?
• GitHub issue：display.show_reasoning config option is not honored by the API server adapter
• GitHub issue：api_server: make exposed /v1/models model id configurable
• GitHub issue：High-risk vulnerability: Hermes webUI is publicly accessible with no auth by default
• GitHub issue：Add --host and CORS config for hermes dashboard to enable Tailscale/VPN access
• GitHub issue：Feature: secure first-run web onboarding wizard for initial Hermes setup
• YouTube 搜索：Hermes Agent
• B站搜索：Hermes Agent
• CSDN：Hermes Agent 安装与基础配置 / 深度解析 / 对阵 OpenClaw 等相关文章

多数中文 AI 教程只教安装和运行，真正讲“目录结构、配置层次、前后台界面关系”的内容偏少。对普通观众来说，这类内容会带来明显的获得感，因为他们终于知道这东西不是一团黑箱。

普通人真正怕的不是装软件，而是：

• 配置到底改哪里
• 出问题去哪看
• dashboard 和 Open WebUI 有什么区别
• 为什么换个模型、换个路径就不工作了

只要这几个问题讲清楚，内容就有现实价值。

这个题目不是纯理论，它很好拍：

• 目录树可以直接展示
• config.yaml / .env 可以做对比讲解
• dashboard 页面可以录屏
• Open WebUI 接入可以演示
• 前后台关系可以做图解

它不仅吸引轻技术用户，也能吸引那种“想用 AI 工作台但不想学太多技术”的普通效率用户。所以比纯源码解析更容易传播。

这类问题不是一阵热点，而是会反复有人搜：

• Hermes 怎么改配置
• ~/.hermes 是什么
• Hermes dashboard 怎么装
• Open WebUI 怎么接 Hermes

这类内容适合沉淀长期流量。

---

不要把它讲成“项目源码导读”，而要讲成：

> 一个 AI 助手系统，文件放在哪里，设置放在哪里，后台怎么看，前台怎么用。

• 项目目录 = 房子的房间结构
• ~/.hermes = 私人物品柜 / 后台抽屉
• 配置文件 = 行为说明书
• dashboard / Open WebUI = 控制面板和使用界面

这样观众不会一听就退。要让他们理解：很多时候你只是在调设置，不是在开发。

强调它是看状态、看运行、做管理，不是主对话界面。

强调它偏使用体验，偏聊天交互，更像普通用户真正会接触的界面。

这比直接讲文件名更容易让人产生代入和收藏欲望。

---

> 把 Hermes 讲成普通人也能看懂的 AI 工作台，并用“项目目录 → ~/.hermes → dashboard → Open WebUI”这条主线，完成一次从陌生到可控的认知拆解。

• 吸引力：高于平均教程类内容
• 普通人友好度：中高
• 视频化表达潜力：高
• 系列化潜力：高

---

《看不懂 Hermes？3 分钟带你走到“第一次敢改配置”》

• 最适合非专业人士代入
• 有“从不会到敢动手”的成长感
• 容易传播，也方便后续做系列
• 兼顾认知解释与行动突破

《Hermes 到底是什么？把它理解成 AI 工作台的后台，你就懂了》

• 适合做置顶认知视频
• 搜索价值高
• 能打底整个 Hermes 系列

《Hermes 装好后第一天该干嘛？从“装好了”到“真的敢用”》

• 获得感最强
• 适合新手入门
• 搜索型流量潜力强

《很多人改错地方了，Hermes 真正该看的其实是 ~/.hermes》

• 命中高频误区
• 收藏价值高
• 适合做纠错型内容

《别再用技术词讲 Hermes 了，用“家居系统”一听就懂》

• 最通俗
• 最适合小红书传播
• 适合拉新

本期继续生产采用：

---

从陌生到可控，一次讲清 Hermes 到底该看哪里、改哪里

• Hermes 别再乱翻了，这条视频带你看懂文件、配置和两个界面
• 3 分钟讲透 Hermes，新手最该知道的 6 个地方

• Hermes 到底看哪、改哪、用哪？
• 从陌生到可控，Hermes 一次看懂
• 文件、配置、界面，别再傻傻分不清

• 你是不是也这样，打开 Hermes 之后，文件一堆，界面两个，完全不知道先看哪？
• 很多人不是不会用 Hermes，是根本没搞清楚它到底哪部分是文件，哪部分是界面。
• 今天这条视频，我就用人话把 Hermes 讲清楚，让你从陌生直接走到可控。

很多人第一次接触 Hermes，最大的痛点不是配置难。 而是你会有一种很乱的感觉。 项目目录一份，家目录下面还有个 ~/.hermes，再加上 config.yaml、.env、dashboard、Open WebUI，名字都认识，关系却不清楚。 所以今天我不讲深技术，我只讲一件事：怎么把 Hermes 从“陌生”变成“可控”。

你先把 Hermes 想成一套“系统 + 控制台 + 使用界面”的组合。 这里面最重要的不是死记文件名，而是先分清三层：

第一层，是项目目录。 这个地方更像“工程现场”，你能看到项目本体、代码、说明、结构。

第二层，是 ~/.hermes。 这个地方更像“个人后台”或者“运行数据区”，很多 Hermes 自己要记住的配置、状态、缓存类内容，通常会放在这里。

第三层，是界面。 界面一般有两个，一个是 dashboard，一个是 Open WebUI。 一个偏管理，一个偏使用。 这两个界面不是互相替代，是分工不同。

先说项目目录。 如果你想知道“这个 Hermes 项目本身长什么样”，优先看这里。 比如目录结构、有哪些模块、有哪些脚本、说明文档在不在，通常都在项目目录里。 所以项目目录回答的是这类问题：

• 这个项目本体放在哪
• 里面有哪些文件夹
• 功能大概怎么组织
• 我现在用的是哪一套项目内容

你可以把它理解成：Hermes 的“房子结构图”在这里看。

再说 ~/.hermes。 这个位置很多新手会忽略，但它非常关键。 因为它通常不是项目源码本身，而是 Hermes 在你这台机器上的个人配置区。 也就是说，它更像“你自己的使用痕迹”和“运行时要读的东西”。

所以如果你问： 为什么同一个项目，在不同机器上表现不一样？ 很多时候就要去看 ~/.hermes。

一句话记住： 项目目录，是项目本体。 ~/.hermes，是这台机器上的 Hermes 私人抽屉。

接下来是很多人最关心的，配置去哪改。

先说 config.yaml。 它一般管的是结构化配置，也就是那些比较明确、成体系、看起来像“设置项列表”的内容。 比如某些功能开关、路径、默认行为，这类更适合放在 config.yaml 里。 所以你以后想找“系统怎么运行、默认怎么设”，优先去看 config.yaml。

再说 .env。 它更像“环境参数的小盒子”。 通常放一些不想硬写进主配置里的东西，比如密钥、地址、账号相关环境值之类。 所以你以后如果是改“环境变量类”的内容，优先想到 .env。

你不用死背技术定义，直接记这句就够了： 大配置看 config.yaml，环境值看 .env。

然后说两个界面。 这个地方最容易混。

dashboard，更像管理后台。 你进去之后，重点是“看系统状态、做管理动作、检查有没有跑起来、配置有没有生效”。 它偏“管”。

Open WebUI，更像使用界面。 你进去之后，更像是在真正和模型、能力、工作流发生交互。 它偏“用”。

所以如果你现在的目标是： 我想确认 Hermes 状态对不对，配置有没有问题，服务是不是正常。 去 dashboard。

如果你的目标是： 我想实际用起来，我想对话、测试、体验结果。 去 Open WebUI。

一句话记住： dashboard 负责管，Open WebUI 负责用。

最后我帮你收一下。 如果你看完这条视频，只记住 3 件事，其实就够了。

第一，想看项目本体，去项目目录。 第二，想找这台机器上的 Hermes 配置和运行痕迹，去 ~/.hermes。 第三，想改配置，优先分清 config.yaml 和 .env；想操作界面，分清 dashboard 和 Open WebUI。

这样你就不会再一上来乱翻。 你会知道：

• 文件在哪看：项目目录、~/.hermes
• 配置去哪改：config.yaml、.env
• 两个界面分别干什么：dashboard 管理，Open WebUI 使用

这时候你对 Hermes 就不再是“陌生”。 你开始有地图了。 而一旦有地图，系统就开始变得可控。

如果你愿意，我下一条可以继续用同样的人话方式，带你把 Hermes 具体目录怎么读、常见文件先看哪几个，再拆成一版真正能上手的入门图。 你想看的话，评论区打一个：继续拆。

#Hermes #AI工具 #新手入门 #系统认知 #配置文件 #OpenWebUI #dashboard #自媒体知识科普 #小白也能懂 #效率工具

---

``yaml base_style: 深色科技感界面 accent_color: 金色点缀 information_hierarchy: 主标题强对比、卡片分层清楚、重点区域高亮 viewing_adaptation: 适合手机竖屏短视频观看，关键信息大字少字 interface_feel: 真实桌面/控制台/UI 混合呈现，不赛博过头 core_rule: 科技感来自结构与秩序，不靠夸张科幻元素 ``

```yaml asset_type: cover platform: 小红书 ratio: 3:4 goal: 让非专业用户一眼理解这期视频是在讲 Hermes 如何从“看不懂”走向“可掌控” visual_focus:

• 一个深色桌面控制面板作为主视觉
• 中央突出 Hermes 认知路径：项目目录 → ~/.hermes → config.yaml → .env → dashboard → Open WebUI
• “陌生”到“可控”的状态转变可视化

style_direction:

• 深色科技感界面
• 金色路径/节点高亮
• 结构清楚、信息少而准

must_include:

• Hermes 名称或等效主标识
• 项目目录、~/.hermes、config.yaml、.env、dashboard、Open WebUI 六个核心元素
• 从混乱/陌生到清晰/可控的视觉对比
• 适合手机端阅读的大标题区

must_avoid:

• 代码雨、过强赛博朋克、霓虹泛滥
• 过多英文技术细节
• 复杂网络拓扑导致看不懂
• 人物表情夸张、营销味过重

prompt_summary: 做一张深色科技感但亲和的竖版封面，用金色节点把 Hermes 的六个关键认知点串起来，让用户感觉这不是高门槛技术，而是一套可以被看懂和掌控的系统 ```

```yaml goal: 先帮观众建立 Hermes 的总体认知地图 visual_focus:

• 用一条清晰路径把六个核心点连起来
• 左侧是陌生状态，右侧是可控状态
• 项目目录作为入口，dashboard/Open WebUI 作为外显操作层

style_direction:

• 总览图
• UI 地图感
• 一眼能扫懂

must_include:

• 六个核心节点命名清晰
• 节点层级关系明确
• 金色高亮主路径

must_avoid:

• 流程箭头太多
• 技术术语解释过密

prompt_summary: 生成一张竖版深色 UI 认知地图，展示 Hermes 的六个关键认知点如何从入口、配置到操作层层展开 ```

```yaml goal: 让观众理解 config.yaml 和 .env 分别管什么 visual_focus:

• config.yaml 与 .env 两张核心卡片并列
• 一个偏结构规则，一个偏环境变量/敏感配置
• ~/.hermes 作为它们的归属背景

style_direction:

• 双卡片对比
• 信息拆解
• 不展示真实敏感信息

must_include:

• config.yaml 标签
• .env 标签
• ~/.hermes 目录语义
• “一个定规则，一个放变量”的白话提示

must_avoid:

• 真实密钥
• 密密麻麻键值对
• 像教程截图

prompt_summary: 生成一张深色科技感双卡片画面，把 config.yaml 和 .env 用非技术用户也能理解的方式拆开呈现 ```

```yaml goal: 让观众看到 Hermes 并不是抽象概念，而是能通过 dashboard 和 Open WebUI 触达的可用入口 visual_focus:

• dashboard 主控制台
• Open WebUI 作为更友好的交互入口
• 用户从看配置走向实际可操作界面

style_direction:

• 产品界面感
• 实操入口展示
• 更有亲和力

must_include:

• dashboard
• Open WebUI
• 明显的按钮、输入区、状态卡片
• 从配置走向操作的转化感

must_avoid:

• 假大空未来感屏幕
• 无意义装饰图标
• 过多假文本

prompt_summary: 生成一张竖版深色 UI 实操入口图，突出 dashboard 与 Open WebUI，让观众感到 Hermes 是可进入、可观察、可控制的 ```

```yaml asset_type: infographic platform: 小红书 ratio: 9:16 goal: 用一张信息图把 Hermes 的核心认知框架讲明白，帮助非专业人士快速建立“我该先看哪里”的顺序 visual_focus:

• Hermes 认知拆解总图
• 六个核心点的层级关系
• 从文件系统到可操作界面的认知路径

style_direction:

• 深色信息图
• 金色编号步骤
• 卡片式层级

must_include:

• 项目目录
• ~/.hermes
• config.yaml
• .env
• dashboard
• Open WebUI
• 每个模块一句白话解释
• 建议阅读顺序

must_avoid:

• 写成文档页
• 解释文字太长
• 小字密集

prompt_summary: 制作一张竖版深色科技感信息图，用金色编号把 Hermes 六个关键认知点分层拆解，每一项都配一句非专业人士能看懂的白话说明 ```

```yaml goal: 把观众从“Hermes 很陌生”带到“原来它有清楚结构” visual_focus:

• 镜头从模糊杂乱界面推进到清晰结构图
• 项目目录、~/.hermes、config.yaml、.env 依次被点亮
• 形成“先看文件结构”的认知路径

style_direction:

• 界面聚焦
• 路径点亮
• 认知建立型

must_include:

• 从混乱到清晰的转场
• 目录与配置文件的顺序呈现
• 金色高亮框和引导线

must_avoid:

• 转场特效过花
• 大量英文弹窗

prompt_summary: 生成一段竖版短视频 UI 动画，先呈现陌生杂乱感，再逐步点亮项目目录、~/.hermes、config.yaml、.env，建立 Hermes 的基础认知地图 ```

```yaml goal: 把抽象配置过渡到可见可操作的 dashboard 和 Open WebUI，收束为“可控” visual_focus:

• 配置卡片缓慢收拢为控制台界面
• dashboard 主界面出现状态卡片
• Open WebUI 出现对话/操作入口

style_direction:

• 从底层到上层
• 操作感增强
• 收尾建立掌控感

must_include:

• dashboard
• Open WebUI
• 按钮、状态、输入框等可操作元素
• 最后停在清晰可控的主界面

must_avoid:

• 假炫光遮挡信息
• 像游戏 HUD
• 无意义粒子

prompt_summary: 生成一段竖版短视频 UI 动画，将 config.yaml 和 .env 的抽象配置逐步转化为 dashboard 与 Open WebUI 的可操作界面，结尾强调“从陌生到可控” ```

---

如果现在继续生产，正确顺序是：

• 确认标题
• 确认封面路线
• 进入字幕断句 / 分镜脚本
• 再补成真正可投喂模型的完整版 prompt
• 最后进入发布包

---

后续我会按这个标准交付：

• 分析必须完整并放进最终链接
• 正式口播稿必须完整，不再只给摘要
• prompt/spec 必须直接放进链接内，不靠本地补充
• 状态信息只做很短的元说明，不再抢正文空间
• 报告页必须能独立阅读，单链接看完全部关键内容