半年后的某天下午，你突然想起来看一眼那个每天 6:00 自动跑的日报。它这半年出过事吗？你敲了一条 hermes security audit。输出回来：37 个漏洞，77 个组件，13 个 HIGH。你不是每天都看着它跑吗，怎么漏成这样？
这个画面我今天真的跑出来了，不是假设。上一篇把日报接进 cron 之后，它每天 6:00 无人值守自己跑------可它从没做过一次健康检查。没人盯的系统，安全、数据、成本三件事全是坑。
这篇是「Hermes 工程化实战」系列的收官篇，回答「跑起来了，然后呢」：一个 agent 从装好到无人值守，再往下，怎么让它长期、安全、不烧钱地跑下去。
先看现象：无人值守的三类新问题
系列第 8 篇结尾我写过一句话：无人值守不是把问题消掉了，是把问题换了一批。以前你盯着跑，现在没人盯。换出来的这批问题，我数了三类。
没人盯，是第一类。系统每天自己跑，但不会有人主动去看它依赖的东西有没有爆出漏洞。供应链是实打实的一层------Python 依赖、插件、MCP server，任何一个出漏洞，都等于你的 agent 带着病上班。
数据是第二类。日报跑了一年，state.db、memories、cron 执行记录堆了一大堆。机器崩了、盘坏了、手滑删了目录，这些东西能不能找回来？
花钱是第三类。以前手动跑一次花一次钱，你有体感；现在每天自动跑，token 不声不响地累积------不抬头看水表，你根本不知道一个月流了多少。
画成图就是这样，后面每一节都是给图里的一格填细节：
生产化不是加功能，是防出事。加功能是加法，防出事是兜底------兜底不出彩，但出事的那个下午，你只想要兜底。
供应链安全审计：hermes security audit
先跑审计。hermes security --help 把扫什么说得很清楚，逐字：
On-demand vulnerability scan against OSV.dev. Covers the Hermes venv (installed PyPI dists), Python deps declared by plugins under ~/.hermes/plugins/, and pinned npx/uvx MCP servers in config.yaml. Does NOT scan globally-installed packages or editor/browser extensions.
扫四样：Hermes 自己的 venv（装了的 PyPI 包）、插件声明的 Python 依赖、config.yaml 里 pin 的 npx/uvx MCP server。数据源是 OSV.dev。不扫全局装的包，也不扫浏览器扩展------边界划得很清楚。
子命令是 audit，跑一遍（逐字，节选）：
text
Found 37 known vulnerability finding(s) across 77 component(s):
[venv]
HIGH cryptography==46.0.7 GHSA-537c-gmf6-5ccf
Vulnerable OpenSSL included in cryptography wheels
fixed in: 48.0.1
HIGH cryptography==46.0.7 GHSA-g6cj-pr64-35w5
cryptography: PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle
fixed in: 50.0.0
...
HIGH pillow==12.2.0 GHSA-45hq-cxwh-f6vc
Pillow `BdfFontFile`: `Image.new()` called without `_decompression_bomb_check()`
fixed in: 12.3.0
...
MODERATE hermes-agent==0.19.0 GHSA-pmqc-57g8-c22c
hermes-agent has an Uncontrolled Resource Consumption issue
MODERATE hermes-agent==0.19.0 GHSA-xq8w-9jvx-gm3v
hermes-agent has an Injection issue37 个 finding，分布在 77 个组件上：13 个 HIGH，18 个 UNKNOWN，6 个 MODERATE，全在本机 venv。大头集中在两个库------pillow 12.2.0 一串 HIGH，fixed in 12.3.0；cryptography 46.0.7 一串 HIGH，fixed in 48.0.1 / 50.0.0。
看到这儿，你可能跟我最初想的一样：把 pillow 和 cryptography 升级一下就完事。不是。
真正扎眼的，是列表最后两行------hermes-agent 自己，0.19.0，2 个 MODERATE：GHSA-pmqc-57g8-c22c（Uncontrolled Resource Consumption，无节制资源消耗）和 GHSA-xq8w-9jvx-gm3v（Injection，注入），另有 PYSEC-2026-3576 / 3577 两条记录。第三方库的 HIGH 再多，升级就行；但装 agent 的人自己拿什么升级 agent？
这个「修不了」的坑，是这一整篇最重要的工程事实。下一节揭晓。
关键坑：pip 安装已不再受官方支持
答案藏在一句警告里。我跑 hermes update --check 想看有没有新版本，输出逐字：
text
⚠ pip installs are no longer an officially supported platform and will not receive further updates. See https://hermes-agent.nousresearch.com/docs/getting-started/platform-support for supported install methods.
✓ Already up to date.两行并列，讽刺得很。上面说 pip 已经不再受官方支持、不会再收到更新；下面紧接着说「Already up to date」。hermes version 也确认了：Install method: pip。
把两句连起来读，我才明白发生了什么。本机是 uv venv + pip 装的------这是系列第 2 篇《安装部署实战》我亲测走通的路。但 Hermes 官方已经把 pip/PyPI 从支持渠道里划掉了。
写作日（2026-08-28）我 WebSearch 交叉核实过官方平台支持文档：受支持的渠道是 shell installer（install.sh / install.ps1）、Hermes Desktop、Docker、Nix；明确列为 Unsupported 的有 pip/PyPI（含 uv tool install）、Homebrew（brew install）和 AUR。
后果是这样的：上游最新版本已经走到 v0.20.6（v2026.8.27，2026-08-27 发布）。这之前，8 月 3 日发了 v0.20.0，8 月 19 日发了 v0.20.5（v2026.8.19），昨天刚发 v0.20.6------一串新版本，本机这个 pip 渠道一个都收不到。update --check 说 up to date 没有说谎，它只是检查一个已经没人补货的货架，货架上的东西当然一直是最新的。
所以 security audit 对 hermes-agent 0.19.0 报的那 2 个 MODERATE，就地修不了。不是 Hermes 没修，是我这个安装渠道拿不到修好的版本。
官方甚至加了构建守卫：setup.py 里直接禁止构建 wheel/sdist，除非在密封的 Nix 派生里（HERMES_NIX_BUILD=1）------因为 wheel 装出去会缺内置资源（locales、skills、web/TUI 前端、插件清单），这些只能在官方渠道里随包带齐。等于把「自己 pip 装一个能用的」这条路也堵死了。
修复路径只有一条：换官方支持渠道重装------shell installer、Desktop、Docker、Nix 里选一个。有个附带前提：Docker 装上之后连 hermes update 都不支持，升级要靠拉新镜像。整条逻辑画成图：
到这里我认一个判断：装的时候选对渠道，是这个系列最早的一课，但代价直到收官篇才兑现。系列第 2 篇我写安装，对比过几种方式，最终选了 pip------顺手、一条命令、不需要官方脚本。当时它没错，能跑。但这份「顺手」换来的是安全修复要重装、升级要重装，连官方都在主动切断这条路。
备份与恢复：hermes backup / import
在讨论重装之前，先说备份------因为任何迁移的第一步，都是先把现场存下来。
hermes backup 一键打包。--help 逐字：
Create a zip archive of your entire Hermes configuration, skills, sessions, and data (excludes the hermes-agent codebase). Use --quick for a fast snapshot of just critical state files.
整个配置、技能、会话和数据打成 zip，不含 agent 本体。实测一次（逐字）：
text
Scanning ~/AppData\Local\hermes ...
Backing up 28 files ...
Backup complete: C:\Users\admin\AppData\Local\Temp\hermes-h8-backup-test.zip
Files: 28
Original: 5.1 MB
Compressed: 710.0 KB
Time: 0.1s
Restore with: hermes import hermes-h8-backup-test.zip28 个文件，5.1 MB，压到 710 KB，0.1 秒。对我这种连 git 都懒得频繁提交的人，这是最没有理由不做的操作------它快到没有成本。
zip 里装了什么？我打开数过：config.yaml（还带着一个 .bak-h3）、SOUL.md、state.db、memories/USER.md、两个技能（ai-daily-digest 和 daily-report-rescue）的 SKILL.md、cron 的 jobs.json 加 executions.db 加 output、调度脚本 run_daily_report.py、logs、auth.json。基本是把整个 Hermes 现场搬走------配置、人格、记忆、技能、调度、日志、凭据文件，一样不少。
--quick 是快速快照，只存关键状态：config、state.db、.env、auth、cron，适合每天定时丢一份的轻量备份。恢复命令是 hermes import <zip>，backup 输出最后一行就写着。
还有个我差点漏掉的细节：hermes update --help 里能看到 --no-backup（跳过所有更新前备份）和 --backup------也就是说 update 默认会先做一次备份再升级。把「升级前先备份」做成默认行为，这本身就是一种工程态度。
成本与用量：hermes insights
第三件事，钱。hermes insights 给出本机近 30 天的用量，逐字：
text
Period: Aug 28, 2026 --- Aug 28, 2026
📋 Overview
Sessions: 10 Messages: 36
Tool calls: 9 User messages: 10
Input tokens: 107,122 Output tokens: 19,577
Total tokens: 276,331
Avg msgs/session: 3.6
🤖 Models Used
deepseek-v4-flash 10 276,331
🔧 Top Tools
memory 3 33.3%
skills_list 3 33.3%
skill_manage 1 11.1%
terminal 1 11.1%
skill_view 1 11.1%
🧠 Top Skills
daily-report-rescue Loads 1 Edits 0
ai-daily-digest Loads 0 Edits 1
📅 Activity Patterns
Fri ███████████████ 10 Peak hours: 9PM (7), 7PM (3)
🏆 Notable Sessions
Most messages 9 msgs (20260828_211350_)
Most tokens 23,203 (20260828_211350_)
Most tool calls 4 calls (20260828_211350_)10 个会话，276,331 total tokens------输入 107,122，输出 19,577，全部跑在 deepseek-v4-flash。这是本系列 H1-H7 全部会话的真实消耗，有据可查。视图有 Overview / Models Used / Top Tools / Top Skills / Activity Patterns / Notable Sessions------工具使用频率、技能加载次数、活跃时段（我晚上 9 点最活跃）全被量化了。
--days N 调时间窗口，--source 按平台过滤。
对日报这种每天自动跑的任务，insights 的价值不是「看看我花了多少」，是「我能不能预判下个月花多少」。276k tokens 里输入 107k 是主头------调度用 --no-agent 模式，外层没有 agent 循环，但 curate.py 内部那一次 Hermes 汇总，输入量是固定的。用量曲线平滑可预测，就能算预算；算不清的，才会在月底吓一跳。
本地模型零成本路线：Ollama
成本往下走一步，就是本地模型。
机制跟 DeepSeek 直连是同构的：custom provider + base_url 指向 http://localhost:11434/v1 + api_mode: chat_completions + 本地模型名。providers.py 里 "ollama": "custom" 是本地版；"ollama-cloud" 是云版（base_url https://ollama.com/v1，transport openai_chat，OLLAMA_BASE_URL 环境变量可覆盖）。
但「零成本」要说清楚：零的是 API 计费，不是总成本。前提是本地有模型、有跑得动模型的硬件。机器上没装 Ollama、没下模型，这条路就是零------想靠它省钱之前，先确认你手上的卡跑得动。这跟自建发电机一个道理：电费省了，发电机本身和噪音还在。
凭据与密钥
备份那一节有个细节值得单独拎出来：因为我使用agent的时候，会把秘钥配置到环境变量，不让AI直接读取，所以我本机备份的zip 里没有 .env。本机 Hermes home 下根本没有 .env 文件------密钥全部走机器级环境变量（DS-KEY、FEISHU_WEBHOOK 这种）。所以备份打出来的 zip，不含任何运行密钥。如果你走的是配置文件，那就会一起打包。
这不是坏事，但它是现实，恢复时要记得：hermes import 把 zip 还原之后，机器级环境变量还得在，agent 才能连上模型、推送才有凭据。
系列第 2 篇我把 DeepSeek 的 key 放在环境变量里（key_env: DS-KEY），系列第 7 篇《多渠道接入》的飞书 webhook 也从 FEISHU_WEBHOOK 读------这套设计让密钥天然不进代码、不进备份、不进文章。
如果连环境变量都不想放，Hermes 还有一条外部密钥管理器路线：hermes secrets 接 Bitwarden / 1Password。这条本机没实跑，标「待核实」------但方向是对的：密钥交给专门的密钥管理器，比散落在环境变量里更可审计、可轮换。
工程判断：生产化三件事清单
东西都试过了，回到判断。一个 agent 要长期跑下去，我收敛成三件事。
安全基线：用官方支持渠道装，定期 hermes security audit。渠道选错，后续所有安全动作都白做------这是本篇最贵的教训，我替你付过了。
数据：备份自动化。update 默认带备份是最低线，再加一个手动的 hermes backup（或 --quick）落进周维度习惯。丢了能恢复，是「上生产」的及格线。
成本：insights 量化，再决定要不要上本地模型。先看水表，再决定换不换水龙头。
什么程度算「上生产」？我的定义三条：跑得久（不是一次性玩具）、丢了能恢复（备份可还原）、出事有人管（有人知道怎么看、怎么修）。
对照这三条，本机这个日报------跑得久勉强算，丢了能恢复（backup 有了但还没自动化），出事有人管（我还在看）。它够格叫「无人值守的产品」，但离「托管服务」还差一口气。差的两件事，就是自动化备份和官方渠道迁移。
结论：系列收官，回望这一路
写到这里，这个系列到了头。从系列第 1 篇《Hermes 是什么------会自我进化的 Agent》讲概念，到系列第 2 篇《安装部署实战》把 Hermes 装上、连上 DeepSeek，再到系列第 3 篇《第一个真实任务》立起「各家 AI 动态日报」这个载体项目------collect→curate→render 三步。
后面每篇都在给它加东西：系列第 4 篇《记忆系统拆解》加跨天去重，系列第 5 篇《学习闭环》讲技能怎么从经验里诞生，系列第 6 篇《技能系统实战》把技能落到日报管线，系列第 7 篇《多渠道接入》加推送，系列第 8 篇《调度》让它 6:00 自己跑，这一篇再加安全、备份、用量。
最后一件我坚持要做的事：如果你也在跑 agent，别等出事。现在敲一条 hermes security audit，再敲一条 hermes backup------两个命令加起来花不了你十秒，却是这篇三件事里最不贵、也最容易拖到出事那天的那两件。读到这里如果觉得这一路的坑替你踩得值，转发给你身边那个也在折腾 agent 的人，比点赞更能让它被需要的人看到。
这个系列收官了。下一个系列我已经在筹备------方向是把 agent 从「单个帮手」变成「一支队伍」：多个 agent 各管一段、接力协作、一起上线。想追的可以先关注，别走丢。
最后留两个问题，评论区见：你的 agent 任务遇到过什么生产事故------跑挂了、重复了，还是偷偷烧了很多钱？你最想让 agent 帮你跑什么------查天气、盯告警、把收藏夹打包成早报，还是别的？这两个问题，都可能成为下一个系列的素材。