TechLog 技术日志

Hermes Agent Docker 部署踩坑实录:从「能跑」到「为什么我最终放弃容器化」

Fri, 07 Aug 2026 18:00:00 +0800

最近折腾了一段时间 Hermes Agent。

最开始我的想法非常简单:

«Hermes 不就是一个 AI Agent 吗?Docker 隔离一下环境,岂不是既干净又方便升级?»

于是我选择了 Docker 部署。

结果一路从"这东西跑起来真简单",折腾到了"我已经把 Docker 部署所有坑都踩完了"。

最后得出的结论反而是:

Hermes 可以很好地运行在 Docker 里,但如果你的目标是让它长期作为一台机器上的自动化 Agent 使用,原生部署反而更加合理。

这篇文章记录一下整个过程。

一、为什么一开始选择 Docker

我平时本身就大量使用 Docker。

数据库、Home Assistant、各种 Web 服务基本都是容器化部署,因此看到 Hermes 官方提供 Docker 镜像之后,第一反应就是:

services:
 hermes:
 image: nousresearch/hermes-agent:latest
 container_name: hermes
 restart: unless-stopped
 command: gateway run

 ports:
 - "9119:9119" # Dashboard(默认 127.0.0.1,按需暴露)

 volumes:
 - ./data:/opt/data

 environment:
 HERMES_DASHBOARD: "1"

然后:

Hermes Dashboard 修改密码:配置热更新技巧

Fri, 07 Aug 2026 17:00:00 +0800

修改 Hermes Dashboard 的登录密码,不需要重启整个容器——改配置 + kill 进程即可,QQ 会话不断线。

背景

Hermes Agent 的 Dashboard(Web 管理界面)默认带 basic auth 登录。Dashboard 页面本身没有"改密码"功能,需要改配置文件。但很多人以为要重启容器才能生效——其实有更轻的方式。

方法

1. 改配置文件

编辑 Hermes 配置(config.yaml),找到 dashboard 的 basic_auth 配置:

dashboard:
 basic_auth:
 username: admin
 password_hash: "<scrypt 哈希>" # 或明文 password: "xxx"

两种密码写法:

password_hash:scrypt 哈希(推荐,不存明文)
password:明文密码(简单但安全性低)

生成 password_hash(交互式输入,避免密码出现在命令行历史里):

# 容器部署的,先进入容器内再执行:
docker exec -it <容器名> bash
# 然后在容器内:
python3 -c "
from plugins.dashboard_auth.basic import hash_password
import getpass
pw = getpass.getpass('输入新密码: ')
print(hash_password(pw))
"

用 getpass 交互输入——密码不会显示在终端、不会进 shell history。 (如果容器里找不到 plugins 模块,说明需要在 Hermes 的虚拟环境里执行:/opt/hermes/.venv/bin/python3)

关于

Fri, 07 Aug 2026 10:00:00 +0800

关于 TechLog

TechLog 技术日志 — 一个 IT 运维与技术情报的公开日志站。

记录什么

内核与系统更新:Kylin / Debian / PVE 等发行版的内核版本与安全公告追踪
软件动态:Caddy、ddns-go 等常用软件的安全更新与版本变化
AI 与价格:DeepSeek 等 AI 服务的定价变动
硬件调研:低功耗小主机、NAS、迷你 PC 的选型与功耗数据

为什么做这个

日常技术运维中积累了大量的版本追踪、更新核对、选型调研工作。与其散落在聊天记录里,不如整理成按日期更新的公开日志——既方便自己回溯,也能给有同样需求的人参考。

内容原则

所有数据来自公开来源(官方仓库、官方公告、公开评测),可自行核实
按日期更新,记录真实查证过程
内容公开,欢迎交流

技术栈

Hugo + PaperMod 主题
部署于 GitHub Pages,自动构建

联系

仓库: https://github.com/Icestab/TechLog
有问题或建议欢迎在仓库提 Issue

Hugo + PaperMod 博客搭建记录(含踩坑)

Fri, 07 Aug 2026 03:30:00 +0800

本博客即本文的产物。记录完整搭建过程和踩过的坑,供以后重建参考。

技术选型

Hugo v0.164.0(extended)— Go 单二进制,极快
PaperMod 主题 — 极简技术风,内置搜索/归档/标签
目标:按日期更新的技术日志流

搭建步骤

1. 安装 Hugo(容器内,免 root)

# 下载官方 release 的 tar.gz 到用户目录(路径按实际环境替换)
curl -L "https://github.com/gohugoio/hugo/releases/download/v0.164.0/hugo_extended_0.164.0_linux-amd64.tar.gz" -o /tmp/hugo.tar.gz
mkdir -p ~/bin && tar -xzf /tmp/hugo.tar.gz -C ~/bin hugo
# 验证
~/bin/hugo version

2. 建站点 + 装主题

cd ~ && ~/bin/hugo new site techlog
git clone --depth 1 https://github.com/adityatelange/hugo-PaperMod ~/techlog/themes/PaperMod

3. 配置 config.toml(中文)

关键配置点:

theme = "PaperMod"
菜单:归档 / 搜索 / 标签
输出:HTML + RSS + JSON(搜索需要)

4. 创建归档/搜索页面

<!-- content/archives.md -->
---
title: "归档"
layout: "archives"
url: "/archives/"
---

<!-- content/search.md -->
---
title: "搜索"
layout: "search"
url: "/search/"
---

5. 构建

hugo --minify # 输出到 public/

踩坑记录

坑 1:hugo.toml vs config.toml 并存

Hugo 0.164 的 hugo new site 默认生成 hugo.toml,如果又写了 config.toml,两个文件并存时 hugo 优先读 hugo.toml(还是默认内容),你的配置全部不生效。

AI 用量成本真相:4 亿 token 里 98.6% 是便宜的缓存读

Thu, 06 Aug 2026 23:00:00 +0800

仪表盘显示 7 天消耗 4 亿 token,看似吓人——但拆开看,真实成本一个月才几十块。

现象

hermes insights 显示:

输入 477 万 + 输出 92 万
Total 4 亿(对不上?)

真相:Total = 输入 + 输出 + 缓存读 + 缓存写 + 推理

4 亿的真实构成:

项目	数量	占比
缓存读取(cache read)	3.99 亿	98.6%
输入	447 万	1.1%
输出	76 万	0.2%
推理	33 万	0.08%

“4 亿"几乎全是缓存读取——不是真的消耗了 4 亿新 token。

为什么有这么多缓存读

长会话场景(如 QQ 单窗口聊天):每轮对话都要把整个会话历史重新发给模型。但历史大部分没变,被**上下文缓存(cache)**命中——服务端只收极低的缓存价,不重新计费。

单轮实测:发一条消息,输入 2,421 token,但缓存读 23 万(整个历史)。

成本换算

按 DeepSeek V4-Flash 价格(涨价前):

Firecrawl 计费陷阱:PDF 提取按页计费

Thu, 06 Aug 2026 22:30:00 +0800

一次 82 页 PDF 提取烧掉 84 credits(月度免费额度的 8.4%),血的教训。

计费规则(官方确认)

操作	消耗
搜索	2 credits / 10 条结果(向上取整)
HTML 提取	1 credit / 页
PDF 提取	按页计费(82 页 ≈ 84 credits)
搜索+自动抓正文	搜索 2 + 每结果 1 credit

免费额度:1000 credits/月。

教训

PDF 绝对不要直接扔给 Firecrawl 提取——按页计费,一个几十页的 PDF 就能烧掉月度额度的百分之几到十几。

正确做法

PDF → curl 下载到本地 → 本地解析(pymupdf/read_file) → 免费
HTML → Firecrawl(1 credit/页) 或 curl
搜索 → DeepSeek 服务端(不耗 Firecrawl 额度)

实测对比:

82 页 PDF 扔 Firecrawl:84 credits
同 PDF curl + 本地解析:0 credits

为什么 Firecrawl 搜索也烧额度

Firecrawl 的搜索默认会抓每个结果的正文(“search + extraction in one call”)——一次搜索 10 条结果 = 2(搜索)+ 10(抓取)= 12 credits。所以搜索密集场景要小心,最好用纯搜索服务(如 DeepSeek web_search)。

搜索体系重建:DeepSeek 服务端搜索 + Firecrawl 提取

Thu, 06 Aug 2026 22:00:00 +0800

2026-08-05 ~ 08-06 折腾两天,解决"搜索引擎全被反爬"的痛点的完整方案。

背景

之前用 curl/浏览器直接抓搜索引擎(Google/Bing/DDG/Startpage/Yandex 等),结果全被反爬挡住(CAPTCHA/403/验证页)。需要一个稳定、免反爬、低成本的搜索方案。

方案演进

阶段 1:发现 DeepSeek 支持服务端 web_search

DeepSeek 官方 Responses API 支持 web_search 工具——搜索在 DeepSeek 服务器端执行,客户端拿到的就是结构化结果,完全绕开反爬。

关键验证:

api.deepseek.com/v1/responses 支持 tools: [{type: web_search}]
事件流有 web_search_call.in_progress / searching / completed
返回结果含 title/url/description

阶段 2:发现 opencode-go 中转也支持

意外收获:opencode-go 的 /zen/go/v1/responses 端点同样支持 web_search 工具——意味着可以用已有的 OPENCODE_GO_API_KEY(和主模型同一账户),不用额外注册 DeepSeek 官方 key。

实测:

{"tools": [{"type": "web_search"}]}
→ output 含 web_search_call(completed),返回真实搜索结果

阶段 3:Firecrawl 负责提取(分工)

社区共识:Firecrawl 擅长网页提取(extract),搜索是弱项(官方也承认"basic search endpoint, not true SERP")。于是分工:

web.search_backend: deepseek ← 搜索(服务端,免反爬)
web.extract_backend: firecrawl ← 提取(HTML 转 markdown)

最终架构

┌─────────────────────────────────────────────┐
│ 搜索(web_search) → opencode-go /responses │
│ → DeepSeek 服务端执行 → 结构化结果 │
├─────────────────────────────────────────────┤
│ 提取(web_extract) → Firecrawl API │
│ → 网页转 markdown(1 credit/页) │
├─────────────────────────────────────────────┤
│ 兜底 → cn.bing / 搜狗 / curl 直抓 │
└─────────────────────────────────────────────┘

关键点

搜索和提取解耦:搜索走模型服务商(不烧 Firecrawl 额度),提取走 Firecrawl(免费 1000 credits/月)
服务端搜索免反爬:反爬是客户端直抓的问题,服务端执行彻底绕开
成本极低:搜索按 token 计费(缓存命中 0.02 元/百万),提取 1 credit/页

附:Firecrawl 注册

2026 年 6 月起 Firecrawl 推出 Keyless 模式(免 key 每月 1000 credits),但 Hermes 插件仍需要 key——邮箱注册即可拿到 fc- 开头的 key,免费额度无需绑卡。

DeepSeek API 大幅涨价预告与峰谷定价

Thu, 06 Aug 2026 20:30:00 +0800

2026-08-06,DeepSeek 在开发者后台发布涨价提示,多家媒体(东方财富/新浪财经/界面等)同日报道。

核心信息

DeepSeek 官方宣布:近期将整体上调 API 服务定价,预计涨幅较大,并引入峰谷定价机制。

当前 V4-Flash 价格(涨价前)

单位:元/百万 tokens

计费项	平峰	高峰(工作日 9-12点/14-18点,翻倍)
缓存命中输入	0.02	0.04
缓存未命中输入	1	2
输出	2	4

V4-Pro 当前价:缓存未命中输入 3 元、输出 6 元(高峰翻倍)。

2026 年调价轨迹

时间	事件
4 月	限时折扣
5 月	优惠结束,正式定价调整为原价 1/4(大降价)
6 月底	预告 V4 上线涨价 + 引入峰谷定价
8 月 6 日	预告大幅整体上调

对重度用户的影响分析

以实际用量为例(7 天 4 亿 token,其中 98.6% 是缓存读取):

缓存读 3.99 亿 × 0.02 元/百万 ≈ 8 元(平峰)
输出 76 万 × 2 元/百万 ≈ 1.5 元
输入 447 万 × 1 元/百万 ≈ 4.5 元
周成本约 14 元,月约 50-60 元

关键结论:长会话 + 上下文重发型用量(缓存命中占比极高)恰好是 DeepSeek 定价最友好的场景——即使涨价翻倍,真实成本上升也有限,因为大头是本就便宜的缓存读取。

Kylin 内核更新 23.74 与 Caddy 2.11.4

Thu, 06 Aug 2026 15:00:00 +0800

Kylin V10SP1 内核 23.74

版本: kernel-core 4.19.90-23.74.v2101.ky10
公告: KYBA-202607-3631
类型: Bugfix(缺陷修复),非安全更新,0 个 CVE
发布时间: 2026-07-28

Caddy 2.11.4

2026-06-02 发布
含安全修复: 路径匹配器加固、占位符处理、header 冲突防护
2.11.3 修复高危 CVE-2026-45692(admin API 认证绕过)

AI Agent 记忆分层架构:常驻内存 + 外部知识库

Wed, 05 Aug 2026 22:00:00 +0800

解决 AI Agent 记忆"不够用、存不下、查不到"三难问题的实践方案。

问题背景

AI Agent(如 Hermes)的持久记忆面临矛盾:

常驻记忆有容量上限(默认 2000 字符,可扩容)— 存不了多少事实
全部塞进上下文太贵——每轮对话都要重新发送,按 token 计费
低频信息不能丢——设备配置、排障细节、API 用法,几周后可能还要用

分层方案

┌─────────────────────────────────────────────┐
│ 第一层:常驻记忆(memory) │
│ · 高频事实:IP/端口/凭据位置/用户偏好/关键配置 │
│ · 默认2000字符可扩容,每轮注入上下文 │
│ · 只放精简核心 │
├─────────────────────────────────────────────┤
│ 第二层:外部知识库(fact_store) │
│ · 低频背景:设备配置/排障细节/软件特性/API用法 │
│ · 大容量、不衰减、不删除、不占 token │
│ · 结构化存储,支持实体关联/组合查询 │
├─────────────────────────────────────────────┤
│ 第三层:会话历史(session db) │
│ · 完整对话记录,可全文检索 │
│ · 用于回溯"当时怎么做的" │
└─────────────────────────────────────────────┘

核心机制

1. 自动分层存储

先扩容常驻记忆(默认 2000 → 8000 字符),容纳更多高频事实
扩容后仍放不下的低频信息 → 外部库
Agent 判断信息频度:高频 → 常驻 memory,低频 → 外部库
存储时自动打标签(tags),支持实体关联

2. 索引锚点(关键设计)

外部库内容不注入上下文(不占 token),但需要"知道有这回事"才能去查:

Kylin V10SP1 内核 23.67→23.72 漏洞修复追踪

Sun, 26 Jul 2026 20:00:00 +0800

记录于 2026-07-26。数据来源:麒麟官方 updateinfo.xml(update.cs2c.com.cn),所有 CVE 均可通过麒麟安全中心核实。

背景

Kylin V10 SP1 基于 Linux 4.19 内核,版本格式 4.19.90-XX.XX.v2101.ky10。服务器当时部署 23.67,需要确认升级路径上的安全修复情况。

各版本修复的 CVE 数量

内核版本	修复 CVE 数	严重程度	说明
23.68	1 个	🟡	CVE-2026-46243
23.69	49 个	🔴 大量	KYSA-202606-1308,Important 级别,跨越 2021-2026 五年漏洞
23.70	1 个	🟡	CVE-2026-46331
23.71	2 个	🟡	CVE-2026-43456, CVE-2026-43503
23.72	2 个	🟡	CVE-2026-43499, CVE-2026-53359

重点:23.69 是大版本安全更新(49 个 CVE)

公告编号 KYSA-202606-1308,类型 security,严重级别 Important。

CVE 时间分布:

年份	CVE 数	代表 CVE
2021	1	CVE-2021-47209
2022	5	CVE-2022-50073, 50616, 50630, 50735
2023	8	CVE-2023-52935, 53305, 53596, 53616, 53622, 53668, 53676
2024	1	CVE-2024-58240
2025	~14	CVE-2025-38624, 38697, 38702, 38708, 39883, 39891, 39945 等
2026	~20+	CVE-2026-23054, 23073, 23074, 23076, 23083, 23089, 23191, 23204, 23216, 23234, 23235, 23253, 23274, 23462, 31408, 31532, 31788, 43211, 43494

结论

从 23.67 升级到 23.72,累计修复 55+ 个 CVE(其中 23.69 一次堵上 49 个)。对于 7×24 服务器,建议直接升级到最新版。