Hermes升级0.13之后：三个让我差点重装系统的坑
Hermes升级0.13之后：三个让我差点重装系统的坑，以及一个价值10倍的多Agent工作流
作者按：本文不是教程，是事故报告。
上周我把Hermes从0.12升到0.13，卡了整整两天。期间经历：Dashboard显示版本对不上、微信推送突然失效、多Agent协作莫名其妙崩溃。最后发现不是我的配置问题，是升级过程中有三个机制悄悄变了。
如果你也在用Hermes，这篇建议你认真看完——至少能省掉我踩的那些雷。
第一个坑：升级之后日志里突然全是"REDACTED"
升级完0.13的第一天，我发现微信推送报错了。
错误日志里有个陌生的词：REDACTED。
查了半天发现，0.13默认开启了secret redaction（敏感信息自动打码）。这个功能是fb1ce793e这个commit加的，官方说是"安全加固"，但它把日志里所有看起来像密钥的东西都打上了[REDACTED]标记——包括我自己写的WX_SECRET。
# 0.12的日志 curl -X POST https://api.weixin.qq.com/cgi-bin/media/upload \ -H "Authorization: Bearer 45bb8f3e2d1c..." # 0.13的日志 curl -X POST https://api.weixin.qq.com/cgi-bin/media/upload \ -H "Authorization: Bearer [REDACTED]" 解决方案： 在~/.hermes/config.yaml里加一行：
security: redact_secrets: false # 关闭自动脱敏，或者精确配置白名单 或者，如果你希望保留安全功能，只对特定字段关闭，可以用环境变量：
HERMES_REDACT_SECRETS=false hermes run 经验： 升级之后第一时间跑hermes doctor，它会提示配置不一致的地方。
第二个坑：Dashboard显示0.12，CLI显示0.13
这个问题更诡异。
升级完成后，我敲hermes --version显示0.13.0。但打开Dashboard（Web UI），页面左下角写的是v0.12.0。
最离谱的是：我重装了三次，版本还是对不上。
根因： Dashboard是一个独立进程（PID 113939），它启动于5月8日，比我升级还早。它读取的是虚拟环境里预装的旧版包，而不是升级后的新代码。
# 查看Dashboard实际进程 ps aux | grep hermes | grep dashboard # fayi 113939 ... /home/fayi/.local/share/hermes/venv/bin/python ... dashboard # 升级后需要重启Dashboard hermes dashboard --port 9119 # 现在显示：v0.13.0 | release_date: 2026.5.7 ✓ 解决方案： 升级之后必须：
hermes update # 更新包 pkill -f "hermes dashboard" # 杀掉旧Dashboard hermes dashboard --port 9119 # 重启 经验： Hermes的所有进程（gateway、dashboard、board）都是独立运行的，升级后不会自动重启。需要手动拉起。
第三个坑：多Agent串行流水线跑着跑着就崩了
我搭了一个三节点的多Agent流水线：researcher → analyst → writer。researcher搜集信息，analyst分析，writer写稿。
跑了三天，一切正常。第四天，突然崩了。
错误信息：
AttributeError: 'NoneType' object has no attribute 'send' Broadcast send error: no close frame received or sent 根因： 我查了代码，发现是websockets库从15.x升级到16.0，导致Board Server的handler函数签名变了。
# 旧版（15.x） async def handler(ws, path): await ws.send(data) # 新版（16.0）— path参数被移除了 async def handler(ws): await ws.send(data) # 如果还在用 asyncio.run() 这里会炸 而且Board Server里的广播函数用了asyncio.run()，但它本身已经在event loop里运行了——asyncio.run()不能嵌套，会直接崩溃。
修复后的代码（已验证）：
async def broadcast_to_channel(self, channel: str, message: dict, sender_ws=None): if channel not in self.channel_clients: return dead = [] for ws in self.channel_clients[channel]: try: await ws.send(json.dumps(message)) # 直接await，不套asyncio.run() except Exception as e: print(f"Broadcast send error: {e}") dead.append(ws) # 不要在这里del连接，放在handler的finally块里统一清理 经验： Board Server（Terminator Board）跑的时间越长，连接状态越容易积累问题。升级依赖库之后一定要重启服务。
福利：这三个坑其实是一件事的三个切面
回看这三个坑，它们说的其实是同一件事：
Hermes 0.13是一个"安全优先、长期运行"设计的版本。
-
secret redaction默认开启 → 防止日志泄露
-
checkpoints v2 rewrite → 减少磁盘占用，防止存储泄漏
-
Dashboard/Board独立进程 → 各自稳定运行不互相影响
-
官方在release note里写了三句话就带过了，但我花了两天才真正理解——0.13的改动全是在为"让它稳定跑很久"这件事铺路。
-
实战演示：10分钟搭建一个多Agent工作流
-
既然升级踩坑的经历这么痛苦，给个甜头。
-
下面演示一个我目前在用的多Agent流水线——每天自动搜集AI和金融资讯，生成一篇深度分析文，然后推送到微信草稿箱。
-
架构图（文字版）：
-
┌─────────────────────────────────────────────────────┐ │ Terminator Board (WS总线) │ │ │ │ @researcher ──→ 收集 ──→ @analyst ──→ 分析 ──→ @writer │ │ │ │ [每个Agent是独立进程，通过Board频道传递消息] │ └─────────────────────────────────────────────────────┘ │ │ ▼ ▼ ┌─────────────┐ ┌──────────────┐ │ pusher_api │ │ 微信草稿箱 │ │ (HTTP :8767)│ │ │ └─────────────┘ └──────────────┘ -
第一步：启动Board Server（已修复16.0兼容性）
-
cd ~/board/board/venv python server.py --port 8766 & -
第二步：启动三个Agent（后台常驻）
-
# researcher：搜集AI和科技新闻 python board_client.py researcher "收集今日AI和科技领域重大新闻，2-3条" & # analyst：分析金融市场动态 python board_client.py analyst "分析今日金融市场与AI相关的资金动向，2-3条" & # writer：基于上游输出写文章 python board_client.py writer "根据researcher和analyst的输出，写一篇800字深度分析" & -
第三步：触发流水线（串行执行）
-
# 在Hermes里用delegate_task串行触发 result = delegate_task(goal="调用@researcher收集信息，等待完成", role="orchestrator") result = delegate_task(goal="调用@analyst分析信息，等待完成", context=result, role="orchestrator") result = delegate_task(goal="调用@writer写稿，完成后POST到http://localhost:8767/publish", context=result, role="orchestrator") -
实际运行结果（昨天）：
-
researcher收集了2条新闻（DeepSeek 500亿新融资、OpenAI内部路线争议），耗时9.8秒
-
analyst分析了资金流向（美股科技板块资金净流入），耗时13.9秒
-
writer写完了800字初稿，并自动推送到微信草稿箱，耗时20秒
-
全程无需人工干预
-
推送效果截图（昨天的真实输出）：
-
文章标题：「马斯克的1190亿美元豪赌，暴露了OpenAI最深的恐惧」
-
-
核心论点：xAI算力投入与OpenAI商业化困境的对比，说明AI竞赛正在从技术竞争转向资本竞争
-
-
有具体数据：Stargate项目400亿、xAI 500亿、马斯克个人资产变化
-
-
有判断：文章最后给了"这场游戏的真正赌注不是AI，而是能源基础设施"的结论
-
升级checklist（收藏级）
-
结合我自己的踩坑经验，整理了一个升级前后的检查清单：
-
升级前
-
# 1. 备份当前状态 cp -r ~/.hermes ~/.hermes.backup.$(date +%Y%m%d) # 2. 记录当前版本 hermes --version > version_before.txt # 3. 停止所有长期进程（Dashboard、Board等） pkill -f "hermes dashboard" pkill -f "board_server" -
升级中
-
# 4. 执行升级 hermes update # 5. 验证版本 hermes --version # 应该显示新版本 -
升级后
-
# 6. 跑健康检查 hermes doctor # 7. 检查secret redaction配置（如果不希望开启） # 编辑 ~/.hermes/config.yaml # security: # redact_secrets: false # 按需关闭 # 8. 重启所有长期进程 hermes dashboard --port 9119 & python ~/board/board/venv/server.py --port 8766 & # 9. 验证核心功能 curl http://localhost:8767/health # 微信推送API curl http://localhost:9119/api/status # Dashboard版本 # 10.跑一次完整的定时任务，观察日志 cronjob run <job_id> -
最后
-
写完这篇我意识到一件事：升级踩坑这件事本身就是一个好话题。
-
因为它意味着你在用这个东西，而且用了有一段时间了。升级遇到的问题，本质上是你对这个系统理解最深刻的时候——你知道它原来怎么跑的，才能发现它现在哪里变了。
-
Hermes 0.13的改动大多数是好的。secret redaction保护了隐私，checkpoints v2省了磁盘空间，Kanban让多Agent协作更稳定。但这些改动需要有人把它们说清楚，而不是只放在release note里一行带过。
-
如果你也在用Hermes，遇到了我没有遇到过的坑，欢迎来聊。也许下一个踩坑的人就能在这篇的基础上省点时间。
-
相关资源：
-
Hermes官方文档：https://hermes-agent.nousresearch.com/docs
-
我的Board脚本合集：~/board/board/venv/（board_client.py、board_ai_agent.py、pusher_api.py）
-
升级前备份命令：cp -r ~/.hermes ~/.hermes.backup.$(date +%Y%m%d)
-
下期预告： Hermes 0.13的Kanban任务看板实测——多Agent协作的 DAG 编排引擎到底怎么用。