让常驻 AI 助手经得起验收

把一次升级当作服务变更

2026 年 8 月的一次 Hermes 维护，让我重新整理了常驻助手的验收方式。助手承担消息入口、定时任务与内容投递，升级牵涉模型配置、网关连接和扩展工作流。安装命令结束，只能说明某个步骤完成；用户能否继续发起任务，还要沿实际使用路径检查。

当次记录中，Hermes 完成版本升级与配置迁移，Telegram 轮询和飞书连接重新建立，真实模型请求也返回了预期结果。这些是那次维护的验收证据，不能代替今天的在线检查。

每一层回答一个问题

配置检查回答“服务将怎样启动”。依赖与配置结构需要匹配，旧参数迁移之后，也要确认原有通知与并发边界仍能表达。网关检查回答“入口是否连接”。实际模型请求则继续确认，入口之后的模型调用能够完成。

扩展组件有自己的验收点。例如流式卡片运行状态正常，不等于所有定时报告都已经验证。每项结论应写清范围，避免一个正常状态覆盖整个系统。需要投递的任务，还应查看目标端收到的内容，不能只凭发送函数返回成功判断完成。

保留已有工作流的入口

当次整理将常用能力组合成投资日报、维护和内容投递三类工作流，同时保留旧扩展的兼容入口。这样做让升级后的调用方式有连续性，也减少重新查找命令的成本。

项目登记与工作流整理没有顺带修改项目业务代码。把服务升级与业务调整分开，可以更清楚地判断问题来自哪里；需要恢复时，也更容易找到对应的变更。

留下可复查的交付记录

我希望一次维护的交付说明能回答三个问题：改了什么、在哪条路径验证过、还有什么没有验证。配置迁移、真实请求和消息通道分别记录，后续排查才有可以比较的起点。

这次经历形成了一个实用习惯：先确认常驻助手承担的具体职责，再为每个职责找到直接证据。服务越多，越需要让“完成”对应一个可观察的结果，而不是一句笼统的运行正常。