Hermes

📅 最近两天（2026-08-27 至 2026-08-29）Hermes 配置优化日志 🎯 目标 在长期 429 限流和模型配置不合理的情况下，重构 Hermes Agent 的模型分层策略，修复 fallback 链，并给 27 个 cron 任务按复杂度分配对应的 model tier。确保小任务不再调用大模型，降低成本并提高响应速度。 🛠 关键问题（按严重程度排序） # 问题 影响 位置 1 NVIDIA API 持续 429 限流 导致所有 NVIDIA provider 任务失败/延迟，已持续 24h+ .env + config.yaml 2 仅 1 个任务显式指定 model/provider 26 个任务依赖 fallback 链，链路不健全 jobs.json 3 Gemini 模型名错误 gemini-1.5-flash 在 v1beta 不存在 → 404 错误 config.yaml fallback_providers 4 Discord 已卸载但残留配置 旧任务 origin.platform: weixin，已卸载 mautrix/weixin .env + jobs.json 5 无显式 fallback key NVIDIA_FALLBACK_API_KEY 未在环境变量中，fallback 断裂 .env + config.yaml ✅ 已完成的修复 1. 配置文件重构 (/root/.hermes/config.yaml) 新增 四层模型路由： ...

引子：我们都在等一个不会到来的"时刻" 2007 年 1 月，乔布斯从牛仔裤口袋里掏出第一代 iPhone。事后的人们把那一天钉在科技史的墙上，作为移动互联网的创世记。 之所以记得住，是因为那一刻太整齐了——硬件（多点触控）、交互（App Store）、分发（运营商渠道）三层结构几乎同时锁死，像三道闸门在同一秒钟落下。分水岭清晰到可以精确到某一天、某一场发布会、某一个人。 我们这代八零后，是被这种"时刻叙事"喂大的一代人。所以我们本能地也在等 AI 的那一声枪响：等某个模型发布、等某个应用爆红、等某个日期被写进教科书。 但我要说的判断可能让你失望：AI 没有那个时刻。而这不是坏事。 网景时刻与 iPhone 时刻：中间隔着一整个时代 如果非要给 AI 找一个坐标，2022 年 11 月的 ChatGPT 发布更像网景时刻——大众认知第一次觉醒，街谈巷议皆是 AI，但产品形态还只是一个聊天框。它没有改变交互的底层，更没有改变分发的底层。 真正接近"iPhone 时刻"的，是另一个更少戏剧性的东西：agent 开始稳定替代人执行完整工作流，且可复用的接入协议（MCP 这类标准，或被嵌进超级应用）变成平常事的那个窗口。 这件事正在发生，但还没有完成。它大概率落在 2025 到 2027 之间的某个平淡无奇的交易日——没有发布会，没有 Keynote，只有某家公司悄悄把一整条客服流水线交给了 agent，而第二天新闻都没上。 三层结构——推理成本的下降曲线、agent 从"对话"走向"自主执行"、分发入口的归属——正在各自独立收敛，尚未锁死成一个稳定组合。这不是悬崖式的跳跃，而是一段爬坡。 事后清晰，身处其中模糊 回头看我们亲历过的每一轮浪潮，剧本早就写过： 非典之后淘宝的爆发——事后看是必然，当时看是"网上买东西？骗子吧" 2014 年微信红包打通支付——事后看是国运级节点，当时只是群里抢了几块钱 空投规则明朗前的那几个月——事后看满地黄金，当时连规则在哪都要靠猜 每一轮，分水岭在事后都清晰得像刻在石头上；身处其中时，都模糊得像隔着一层毛玻璃。 所以真正决定谁是弄潮儿、谁是围观者的，从来不是"精准预判那一刻"——而是浪来的时候，你正好已经在水里。 提前把船造好的人，浪一起就能上船；等浪已经三米高了才下水找船的人，基本只能捡漂浮物。 三层水域：这次该往哪层开 每轮浪潮最后值钱的位置，通常落在三层里的一层。AI 这轮的三层，形状和移动互联网不一样： 基础设施层：卖水卖铲子的位置，门关上了 移动互联网时代，做浏览器、做云服务、做 CDN 的都是这层的赢家。AI 这轮，这层是千亿美元资本开支、万卡集群和顶尖实验室的专属游戏。门槛已经高到一人公司根本摸不到，不必恋战。 分发层：入口之争未定局，但重注太早 谁掌握"用户第一眼看到谁"，谁就掌握了移动互联网最肥的利润。AI 这轮的分发层还在剧烈变动：模型即入口？agent 商店？还是超级应用内嵌？——每一种都有可能，每一种都没赢。值得死死盯住，但不值得现在押上全部。 应用/内容层：这是还开着门的水域 直接触达终端用户，直接交付价值。这一层的规则只有一条：你手里得有 AI 复制不了的东西。 而这恰恰是"对有积累的个体最友好"的一层。 给八零后过来人的定位：用别人的基础设施，打自己的水域 如果你读到这里，你的体量大概率是一人公司或小团队。那么现实的位置只有一句话： 用别人的基础设施层，做自己在结构性优势上仍然成立的应用/内容层。 不要训练模型，不要做协议，不要碰算力。调用别人的模型，编排自己的工作流，交付自己领域里的结果。 ...

今日概览 核心产出：完成《AI 的"iPhone时刻"不会到来——而这恰恰是机会》博文，从初稿修饰到上线 配图制作：两张矢量图——三层结构船只比喻图、关键指标 2025-2027 时间线 知识库状态：Notion 本地 KB 75 个主文件 + 蒸馏卡，统一索引 100 条（博客 91 + Notion 9） 闭环验证：今天跑通了一次完整链路：对话中的想法 → 文章 → 配图 → 构建 → 上线 → 线上验证 核心思考：AI 的分水岭不是时刻，是过程 今天深度对话后整理出的核心判断： 移动互联网的 iPhone 时刻是 2007 年的一天，AI 的分水岭是 2025-2027 这一段爬坡期。 三个独立收敛的层还没锁死： 推理成本曲线——正在下降，拐点在"完成某类任务成本 < 人工 10%" Agent 自主执行——从"对话"走向"稳定完成完整工作流"，临界点是 30% 自主完成率 分发入口——MCP 等协议是否成为"平常事"，谁掌握入口还没定局 对八零后来说，关键不是抓住某个发布会，而是确保船足够结实。 三层水域与我的定位 层级 AI 时代现状 我的定位 基础设施层 门槛极高，一人公司摸不到 用别人的 分发层 未定局，值得盯但重注太早 观察不重注 应用/内容层 可落地位置 主攻方向 我的船是 Hermes 系统：模型路由 + 降级逻辑 + 多智能体编排 + Notion 知识库闭环。这已经在水里了。 ...

问题背景：Hermes Cron Gateway 的 systemd 限制 Hermes 的 cron 系统依赖 systemd-run --user --scope 启动隔离 worker。当前环境（容器/权限受限）报错： Restart-safe cron worker dispatch failed: cannot create restart-safe systemd scope for gateway child: systemd-run --user --scope is unavailable 导致 18 个 Hermes cron jobs 全部失败，无法执行任何定时任务。 解决方案：迁移到系统级 crontab 直接编写 /root/.hermes/cron/system-crontab 并 crontab /root/.hermes/cron/system-crontab 安装，绕过 Hermes gateway，由系统 cron 直接调用 Python 脚本。 # 安装 crontab /root/.hermes/cron/system-crontab # 查看 crontab -l 核心脚本 1. Notion KB 每日全量同步 (sync-notion-kb.py) #!/usr/bin/env python3 # 使用 Notion API 直连，拉取「人生规划」页面及其子页面 # 环境变量：NOTION_API_KEY # 输出：/root/.hermes/kb/notion/*.md + LIVE-INDEX.txt + UNIFIED-INDEX.txt 运行时间：0 3 * * * (每日 03:00) 结果：33/33 页面成功，LIVE-INDEX 93 行，UNIFIED-INDEX 427 行 日志：/root/.hermes/cron/system-logs/sync-notion-kb.log 2. 双向写回模块 (writeback_notion.py) # 支持三种模式 writeback(page_id, title, content, mode='date-toggle') # date-toggle: 同一天同标题创建 toggle 块，后续追加到 children # append: 直接追加 # overwrite: 覆盖 4 个 preset 配置： ...

一、起因：一份漂亮的规范和它的三个陷阱 前几天，一份《Agent OS v1.0 — 完整系统规范》在圈子里流传。它设计了一个七层目录的 Personal AI Operating System：Identity、Knowledge、Working Memory、Episodic Memory、Decisions、Governance、Reflection，配合完整的写入 Pipeline（重要性评分→去重→冲突检测→Schema 验证→写入）和 Token 预算分配。 这份规范非常漂亮——如果对象是企业级 AI 团队。但对于个人使用大模型+Agent 的创作者来说，它踩中了三个经典陷阱。 二、陷阱一：过度架构化 规范设计了 9 层目录：Identity、Knowledge、Working、Episodic、Decision、Scratch、Archive、Reflection、Governance。 每一层都有对应的文件、模板、Pipeline。看起来很完整。但问题在于——Agent 会花越来越多时间管理知识，而不是使用知识。 症状 你创建了一个 reflection/daily/ 目录，写了日反思模板。第一周你认真填了 7 天。第二周填了 3 天。第三周，Agent 开始提醒你「日反思已过期 4 天，是否补填？」你开始回避打开 Agent。 这不是 Agent 的问题，是架构的问题。反思作为一种能力，不应该是一个需要维护的目录，而应该是 Pipeline 中的一个环节。 修正方案：逻辑分层，物理精简 之前（9个物理目录） 之后（5个逻辑层） identity/ Identity knowledge/ Knowledge working/ Workspace（Working + Projects） episodic/ History（Episodic + Decisions） decisions/ Archive projects/ scratch/ archive/ reflection/ → Pipeline 能力，不设目录 governance/ → Pipeline 能力，不设目录 Reflection、Validation、Governance 不是存储层，它们是贯穿整个系统的规则。就像你不需要一个叫「质检」的房间——质检是生产线上的一道工序，不是一个仓库。 ...

起因 上周读到 Daniel Warfield 的 《Agent Harnesses：现代 AI Agent 开发的新标准》（原文 Daniel Warfield，Medium/Substack）。核心观点： Harness = 角色 + 上下文 + Skills + References 的结构化打包，让通用 Agent 在具体任务中稳定、可复用、可维护地工作。 三层结构： HARNESS.md —— 入口地图 skills/ —— 能力包 references/ —— 环境手册 设计原则：Progressive Disclosure（渐进披露）——先读入口，按需加载，别一次性塞满上下文。 对照 Hermes：它本质上已经是 Harness 读完后我没急着加文件，先把 Hermes 现有架构拆开对照： Harness 概念 Hermes 对应 判断 SKILL.md + scripts/references/assets ~/.hermes/skills/ 99 个 skill，完整目录结构 ✅ 一致 Skills 目录 已按 category 分子目录（devops/、creative/ 等） ✅ 更成熟 References 每个 skill 内 references/（如 hugo-blog 有 31 个） ✅ 已有 Progressive Disclosure system prompt 只注入 skill name+desc → skill_view(name) 加载全文 → skill_view(name, file_path) 加载单个 reference ✅ 三层已实现 角色约束 MEMORY.md + USER.md + system prompt 身份注入 ⚠️ 隐式实现 可版本化 skills/ 有 git + curator 生命周期 ✅ 子目录导航 category 分层 + system prompt 缩进列表 ✅ 结论：Hermes 不需要引入 Harness 标准——它已经是 Harness 思想的另一种实现。区别只是组织方式不同： ...

Skill 不是魔法，它是经验的复用。 如果你用过 Hermes Agent，一定见过 skill_view("hugo-blog") 这样的调用。这就是 Skill——Hermes 的核心扩展机制。本文将带你从使用者变成创造者。 一、Skill 是什么？ 简单说：Skill 是可复用的工作流模板。 想象你每次写博客都要重复： 创建 content/posts/xxx.md 填写 frontmatter 找配图 hugo --minify 部署 这些步骤完全可以固化成一个 skill，以后只需要说"发篇文章"，Agent 自动走完流程。 二、Skill 的三种来源 1. 内置 Skill（官方维护） # 查看所有可用 skill skills_list() # 查看特定分类 skills_list(category="devops") # 加载具体 skill 内容 skill_view("hugo-blog") skill_view("hugo-blog", file_path="references/deploy.md") 内置 skill 存放在 ~/.hermes/skills/ 目录，按分类组织： ~/.hermes/skills/ ├── devops/ │ ├── hugo-blog/ │ │ ├── SKILL.md │ │ ├── references/ │ │ │ └── sensitive-topic-writing-guide.md │ │ └── templates/ │ │ └── post-template.md │ └── astro-vercel-deployment/ ├── github/ │ └── codebase-inspection/ │ ├── SKILL.md │ └── scripts/ │ └── count-lines.py └── ... 2. 插件 Skill（第三方扩展） 插件的 skill 用 插件名:skill名 格式引用： ...

Agent 不是未来——它正在我们指尖发生。从写不完的文章到做不完的 PPT，这些真实场景告诉你，为什么 Hermes Agent 是现代人的数字分身。 一、爆款自媒体矩阵运营 痛点：选题、作图、排版、发布、数据分析，一个自媒体团队干不完的活。 Hermes 方案： 调用 image_generate 生成插图，browser 抓取热点话题 用 web_search 搜集素材，write_file 批量产出图文 Markdown 配合 cronjob 定时发布到微信公众号、知乎、小红书 成效：一个人运营 6 个账号，日更 3 篇，粉丝月增 50%。 二、学术论文加速阅读与综述生成 痛点：读完 50 篇文献才能写综述，博士生平均看 3 篇就要睡觉。 Hermes 方案： web_extract 一键下载 arXiv 论文 PDF 转 Markdown 向 Assistant 连续追问核心方法、创新点、实验结果 自动对比多篇论文差异，生成结构化学术综述表格 成效：文献综述从 2 周压缩到 3 天。 三、智能编程助手：从 Debug 到 Code Review 痛点：Stack Overflow 翻烂了，Bug 还在第 273 行。 Hermes 方案： ...

如果你已经第三次教 AI 同样的事情，问题可能不在 AI，而在工作流本身。 一、那些反复出现的「低级错误」 和 AI 助手协作写博客一段时间后，我开始注意到一个规律：同样的 bug 会以不同的面貌反复出现。 第一次是 +++ 残留在 YAML frontmatter 之后，导致 Hugo 解析失败，文章虽然能访问但首页根本看不到它。第二次是配图位置放错——AI 把 ![featured] 放在了二级标题下面，而不是文章开头。第三次是日期设成了未来，Hugo 直接跳过不生成。 每次修复完，我都以为「这次总该记住了」。但下一次，类似的问题又以新的形式出现。 这不是 AI 变笨了。这是流程的脆弱性在反复暴露。 二、7 个反复踩坑的具体场景 1. Frontmatter 格式混乱：YAML 与 TOML 混用 Hugo 支持 YAML (---)、TOML (+++) 和 JSON 三种 frontmatter。但如果一个项目里大部分文章用 YAML，突然插入一篇 TOML，PaperMod 的列表逻辑可能会跳过它——不是报错，就是安静地不显示。 2. +++ 残留：最隐蔽的错误 把 TOML 转成 YAML 时，如果前面的 --- 忘记删掉，或者后面跟着一串 +++，Hugo 不会报错。文章能 build，URL 能访问，但首页和分类列表里永远找不到它。hugo list all 显示正常，但 index.html 的 post-entry 列表里没有。 ...

Hermes 技巧（下）：批量化与并行策略 ««««« DO NOT LOCALIZE — img src=https://images.unsplash.com/photo-325498 »»»»» 跟「中文互联网科技普遍低质量」的结论类似，真正的问题在于 提问者本人的学徒期限 —— 过去答主需要靠A/B刷榜积累经验，而 Hermes 的 delegate_task 在本地虚拟出了足够多的 A/B 测试场景，让用户得以在短时间内以极小成本确立明确预期。 hermes delegate_task "在国内社媒平台（微博、小红书、知乎） 同时发布一篇关于『下岗职工与农村光棍携手拥抱AI』的话题， 注意尾调不同平台语境差异" 以上命令将同时生成 3 个独立线程，分别适配微博、小红书和知乎，避免跨⽹文体⽔土不服， ⽽且每个线程的质量得分（coherence、engagement）可以⾃动追踪。

Hermes 技巧（中）：GitHub CLI 集成优化节奏 ««««« DO NOT LOCALIZE — img src=https://images.unsplash.com/photo-563492 »»»»» # 跨仓库 PR 查看节奏 hermes run "/root/ai-bachelor-series" "检查最近 5 天提交的 PR， 用 delegate_task 每个 PR 派发一条微信公众号推送稿， 要求√简报 包含：国内光棍数量对比上一年变化%%" --toolsets terminal,delegate_task,send_message 从 Hermes CLI 向上看，GitHub 变成了一个纯状态机而不是操作流程—— 没有手动滚动的“review list”，没有“查看 build log”的单击， 只有提交、自动分类和事件触发，从而将项目节奏拉齐到 AI 协同的拍子上。

为什么需要自定义技能？ 开发者的日常工作中充满重复性任务，如部署博客、格式化代码、备份数据等。通过将这些任务封装为 Hermes 技能（Skills），可以实现一键执行，节省时间。 技能的基础结构 Hermes 技能由以下部分组成： 元数据：技能名称、描述、触发条件（YAML 前言）。 步骤：具体的执行逻辑，支持工具调用和条件分支。 引用文件：如脚本、模板或配置文件（可选）。 技能存储在 ~/.hermes/skills/ 目录下，每个技能是一个子目录，包含 SKILL.md 文件。 创建第一个技能：自动部署 Hugo 博客 第一步：创建技能目录 mkdir -p ~/.hermes/skills/deploy-blog cd ~/.hermes/skills/deploy-blog 第二步：编写 SKILL.md --- name: deploy-blog description: "一键构建并部署 Hugo 博客到 Vercel" --- 1. 进入博客目录： ```bash cd /root/hugo-blog 构建静态文件： hugo --minify 部署到 Vercel： npx vercel deploy --prod --yes ### 第三步：测试技能 ```bash hermes run deploy-blog 进阶技巧 1. 动态参数传递 在技能步骤中使用变量： ...

Hermes CLI 提示（上）：基本命令用法与环境配置 ««««« DO NOT LOCALIZE — img src=https://images.unsplash.com/photo-205126 »»»»» hermes run "在 ~/project 下写一个 Python 脚本 分析最近半年 Git 提交频率" 上述命令将创建一个独立的 Hermes 实例，自动切换到你的项目目录，编写并执行脚本，最后返回结果。无需预装环境，无需额外对话。 将 Hermes 用于个人搜索助手： cat ~/archive/research-notes/**/*.md | hermes run "从上述文件中归纳出适合『下岗职工』话题且可能引起争议的部分，每点不超过 24 字"

Hermes Agent 记忆系统详解：机器人「进化闭环」的5层实现 ««««« DO NOT LOCALIZE — img src=https://images.unsplash.com/photo-229828 »»»»» 在 Hermes 项目的主 config.yaml 里，记忆设置被锐化为两个核心指令： memory: max_user_tokens: 1536 # 用户Profile上限 max_memory_tokens: 2048 # LTM的总token数上限

核心原则：命令式交互 Hermes 是为行动设计的，而非解释或规划。模糊的指令会触发不必要的明确化请求（如"你是想让我部署博客吗？"），而命令式语句则直接触发执行。 低效示例（会被打断）： “如何部署 Hugo 博客到 Vercel？” 高效示例（直接执行）： “部署 Hugo 博客到 Vercel，使用默认配置” 1.1 直击要害 部署：直接说 部署 Hugo 博客，Hermes 会自动调用 npx vercel deploy --prod --yes。 调试：检查 Vercel 构建日志 会触发 npx vercel logs --prod。 修改文件：在 hugo.toml 添加 Umami 配置 会调用 patch 工具。 2 避免的坑 2.1 工具明确性 Hermes 会优先选择最合适的工具执行任务，但有时可能猜错（如误用 web_search 查找本地文件）。在复杂任务中明确指定工具： # ❌ 低效 "给博客加个 RSS" # ✅ 高效 "修改 hugo.toml 启用 RSS，使用 patch 工具" 2.2 文件路径 始终使用绝对路径（如 /root/hugo-blog/hugo.toml），避免相对路径的歧义。Hermes 默认以用户的 home 目录（/root）为起点，但不会假设项目路径。 ...