多节点 AI Agent 运行体系

背景与约束

我长期在不同设备和服务器上运行 AI Agent。随着版本升级和能力增加，三个节点逐渐出现不同状态：有的服务版本落后，有的插件仍使用旧配置字段，有的默认模型已经修改，但历史会话仍保留旧覆盖。

这种系统最危险的状态不是完全宕机，而是“看起来在运行”：进程存在、配置文件也有值，但真实模型请求、消息通道或业务会话仍可能失败。

真实约束包括版本和配置结构差异、认证信息分散、多层会话覆盖、插件 Schema 变化，以及部分不属于本次授权范围的安全策略。

关键判断

配置同步不是复制一个文件

模型、认证和会话状态可能同时存在于环境变量、主配置、运行时认证存储和历史会话中。同步对象必须覆盖完整状态，而不是只修改默认模型字段。

服务运行不等于业务可用

验收顺序被固定为：

1. 配置语法
2. 服务进程
3. HTTP 健康
4. 插件与通道
5. 真实模型请求

只有最后一步成功，才说明用户真正能使用系统。

升级问题要按层定位

旧插件字段、新包与旧进程并存、插件未显式启用、历史会话覆盖等问题，表面都像“升级没有生效”，但根因分别属于配置、服务、插件和会话。

实施过程

1. 盘点三个节点的版本、模型、插件和会话状态。
2. 为关键配置建立备份，不覆盖唯一可用版本。
3. 分节点升级，逐项处理 Schema 和插件兼容问题。
4. 统一模型与认证状态，清理会话中的旧覆盖。
5. 重启并确认实际运行进程已经使用新版本。
6. 依次验证配置、Gateway、HTTP、通道和真实推理。
7. 将范围外的安全警告保留为明确限制。

结果与复用

最终交付的不只是一次升级，而是一条可复用的多节点验收链。此后更换模型、升级运行时或迁移插件时，都可以沿用同一顺序，避免“配置看起来一致，但业务链路并不一致”。

系统验收必须走到用户真正执行的最后一步。配置、容器或进程只是中间证据，不是业务成功。

Evidence

验证证据