Hermes Decision Trace

Hermes 5.28 / 5.29 升级评估与方法复盘

这轮升级已经完成并通过最终验收：当前 live Hermes 为 Hermes Agent v0.15.1 (2026.5.29)。5.28 对应 0.15.0 大版本，5.29 是同日 hotfix 0.15.1；实际升级选择直接落到 5.29 是正确路线。

HTML完整论证

Wiki可检索归档

Feishu短入口交付

🎯

核心结论

🧭

推荐路径

本轮验证后的标准流程：

🛡️

关键边界

不调用真实 executor；生产动作另走审批。

关键判断

判断项	摘要
推荐方案	本轮验证后的标准流程：
关键依据	`/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-final-validation-and-upgrade-lessons-2026-05-29.md`
落地方式	按行动清单推进，保持可回退。
风险边界	不跨执行边界；真实执行需另走审批。

证据摘要

/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-final-validation-and-upgrade-lessons-2026-05-29.md证据点 1
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-live-cutover-phase6-2026-05-29.md证据点 2
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-p1-post-cutover-asset-restore-2026-05-29.md证据点 3
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-phase8-management-sync-2026-05-29.md证据点 4
/home/ht/.hermes/skill-bundles/hermes-upgrade.yaml证据点 5

行动清单

这次升级方法是正确的，尤其是“直接选 5.29 hotfix + staging + P0/P1 分层 + live cutover + Phase 8 管理位收口”。

后续 Hermes 升级不要再从 live 运行位直接起手，默认先走 /hermes-upgrade bundle 和 runbook。

把 v2026.5.29 作为当前稳定本地基线，未来升级先看新版本是否能减少本地 patch 面或带来明确收益。

LCM 401 单独处理，不应该污染本次升级成功结论。

边界 / 风险

风险点

未记录额外风险。

完整记录

本节目录一句话结论升级收益总览已验证事实我们为什么应该重视这次升级升级方法评估风险与遗留项最终建议关联本地证据 Footer

Hermes 5.28 / 5.29 升级评估与方法复盘

一句话结论

核心判断：这不是一次“追新版本”的升级，而是一次把官方 0.15 系列新能力、本地长期补丁、运行态服务、测试资产和个人维护仓库治理重新收拢的升级。收益明确，但升级方法必须分阶段，不能直接覆盖生产态。

升级收益总览

维度	5.28 / 5.29 带来的价值	对我们的重要性
官方版本基线	5.28 是 0.15.0 大版本，5.29 是 0.15.1 hotfix	直接升 hotfix，减少二次修补成本
配置迁移	live 验收记录显示 `config_version: 24`	降低配置结构漂移风险
provider 兼容	保留 custom provider declared-model fallback 与 list-of-dict normalize	对本机多 provider / reseller endpoint 很重要
Feishu 表现层	Feishu cards、long decision autopublish、Decision Trace 链路恢复并纳入回归	飞书是主战场，这属于核心工作流能力
Recall/Search	session_search_exact、search_router、search-worker 边界继续保留	直接影响历史回忆、证据包、搜索质量与成本控制
Hindsight retain	Hindsight session retain 相关测试通过	让长决策与历史成果能被后续发现
Prompt compaction	context/tool/skill prompt compaction 相关测试通过	对长期会话、复杂任务成本和稳定性关键
Image provider	OpenAI image edit / provider 能力通过 targeted regression	支持小墨视觉和图像编辑链路
Config guard	Hermes config write guard 继续保留	防止工具误写核心配置，属于控制面安全补丁

已验证事实

live 版本

Hermes Agent v0.15.1 (2026.5.29) Project: /home/ht/.hermes/hermes-agent Python: 3.12.3

当前 hermes --version 仍提示 behind upstream，但这是本地 cutover/managed branch 常见噪音，不等价于版本未生效。

最终验收口径

来自本地 runbook 的最终验收记录：

Hermes Agent v0.15.1 (2026.5.29) config_version: 24 services: gateway/dashboard/webui/project-dashboard active, NRestarts=0 ports: 8642 / 8649 / 8765 / 8787 listening core targeted regression: green managed branch pushed: origin/local/v2026.5.29-managed-live-20260529 main index pushed: origin/main

targeted regression

本轮最终回归记录：

Feishu + long decision + Decision Trace: 255 passed, 9 warnings Recall/search_router/session_search_exact: 26 passed, 1 warning Image provider + custom provider fallback + config guard: 29 passed Hindsight retain: 5 passed Prompt compaction + single-query guard: 24 passed, 1 warning Combined targeted regression: 731 passed, 9 warnings

我们为什么应该重视这次升级

1. 这是 0.15 线的稳定落点，不是单点功能升级

5.28 是大版本，5.29 是紧随其后的 hotfix。对我们的环境来说，正确策略不是“先上 5.28 看看”，而是直接以 5.29 为目标，把 hotfix 当作正式落点。

2. 它把本地能力从“脏运行位”推进到“可治理资产”

这轮升级不是只跑通 live。更关键的是后面 Phase 8：

导出 live bundle
生成 patch matrix v2
在目标 upgrade worktree 上切正式管理分支
分 P0/P1 commit 纳管
提交态 targeted regression
push 到个人维护仓库

这让 ht1072/hermes-agent-local 更像“备份 + 本地与官方差异治理仓库”，而不是普通 fork 或 PR 仓库。

3. 它保住了飞书、搜索、记忆、压缩四条主链

对我们最重要的不是版本号，而是这四条主链不能退化：

飞书：card、long decision、Decision Trace
搜索：search_router、search-worker、session_search_exact
记忆：Hindsight retain、session retain hook
成本/上下文：prompt/tool/skill compaction

这几条都已进入最终回归清单。

升级方法评估

推荐路线：分阶段 cutover，而不是直接 update

本轮验证后的标准流程：

Phase 0 现场冻结：config/.env/cron/db/repo dirty/进程端口/日志 Phase 1 创建官方 tag upgrade worktree Phase 2 patch matrix：P0/P1/P2/verify/drop Phase 3 staging HERMES_HOME 验证 Phase 4 runtime dirty / untracked 对账 Phase 5 最小阻断复核 Phase 6 live cutover：停服务、stash 保护、切目标、回放最小 patch、启动验证 Phase 7 P1 post-cutover asset restore Phase 8 管理位同步：managed-live branch、patch matrix、targeted regression、push Phase 9 最终验收：服务、端口、config、cron、核心回归 Phase 10 经验固化：runbook / skill / wiki / Decision Trace

P0 / P1 拆分是关键

P0 只带基础阻断项：

provider fallback
recall/session_search_exact
image edit
config guard
search_router
Feishu/fresh-final minimal glue

P1 后置恢复：

Feishu cards / long decision autopublish
Decision Trace tests
Hindsight retain tests
prompt compaction / token saver

这个拆分减少了“基础 cutover 失败时不知道是哪块大资产引入问题”的风险。

脏运行位不能 reset

本轮再次确认：live 运行位有未资产化能力时，不能为了干净直接 reset --hard。正确方式是：

先 stash / tar / patch / checksum
再切目标版本
再按能力组回放
旧 hunk 只当真相源，不能整文件倒灌

风险与遗留项

风险	当前判断	处理方式
`hermes --version` behind 提示	非阻断噪音	按 tag/version/live 服务验收判断，不按 behind 数字判断失败
LCM summarization 401	辅助 provider 凭据问题，不是 5.29 升级失败	另开 LCM/auxiliary 凭据排查
大颗粒资产混入基础 cutover	已通过 P0/P1 拆分规避	后续升级继续沿用
管理仓库 diff 误读	managed-live 不合并 main，main 做索引	正确 diff 是 official tag..managed-live branch
Feishu 表现层退化	已纳入 targeted regression	后续每次升级继续跑同组测试

最终建议

这次升级方法是正确的，尤其是“直接选 5.29 hotfix + staging + P0/P1 分层 + live cutover + Phase 8 管理位收口”。
后续 Hermes 升级不要再从 live 运行位直接起手，默认先走 /hermes-upgrade bundle 和 runbook。
把 v2026.5.29 作为当前稳定本地基线，未来升级先看新版本是否能减少本地 patch 面或带来明确收益。
LCM 401 单独处理，不应该污染本次升级成功结论。

关联本地证据

/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-final-validation-and-upgrade-lessons-2026-05-29.md
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-live-cutover-phase6-2026-05-29.md
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-p1-post-cutover-asset-restore-2026-05-29.md
/home/ht/.hermes/skills/devops/hermes-upgrade-runbook/references/0151-phase8-management-sync-2026-05-29.md
/home/ht/.hermes/skill-bundles/hermes-upgrade.yaml

模型：gpt-5.5

生成时间：2026-05-29 16:43:05 +0800