35,000次重启。不是压力测试数据，是生产环境真实的PM2日志。一个负责安全扫描的AI代理进程，在Windows服务器上陷入死循环：发现危险代码→报错崩溃→自动重启→再次扫描同一文件→再次崩溃。
这是「AI System Guardian」诞生的起点。一支团队用11轮调试、70+个生产级Bug的代价，打磨出一套自愈合监控守护程序。他们的经验值得任何做多代理系统的人抄作业。
编码陷阱：一行默认值引发的万次崩溃
第一个35,000次重启的罪魁祸首，藏在Python的subprocess.run()默认行为里。Windows系统编码默认是CP-950（繁体中文），当子进程输出无法编码的字符时，UnicodeEncodeError直接杀死进程。
PM2的自动重启机制在这里成了帮凶。崩溃→重启→遇到同样输出→再崩溃。团队花了大量时间才定位到，修复只需要一行参数：
encoding="utf-8", errors="replace"
这行代码被写进Guardian的第一条规则：PM2重启异常检测。任何进程50次重启内必须触发告警，而不是让日志默默堆积到五位数。
同步地狱：双向桥接的无限回声
paperclip_matrix_bridge进程的4,000次重启暴露了更隐蔽的设计缺陷。这个组件负责两个系统间的任务双向同步：Matrix到Paperclip，再反向同步状态更新。
问题出在事件监听机制。任务A从Matrix同步到Paperclip，触发Paperclip的变更事件，事件处理器又将它同步回Matrix，Matrix再次触发变更——无限循环就此形成。CPU被彻底吃光。
解决方案是给每次同步操作打上「血统标签」。如果任务的_sync_source字段显示最后一次修改来自桥接器本身，直接跳过。代码只有三行，但定位问题花了整整两天。
Guardian为此增加了振荡模式识别：任何进程在冷却期内频繁切换「online」和「errored」状态，立即人工介入。
错误处理悖论：扫描器的自我毁灭
安全扫描器的35,000次重启则是一个经典错误处理反例。当扫描器发现危险模式（如eval()调用）时，它抛出RuntimeError——但从未将问题文件移出扫描路径。
结果可预见：重启后扫描同一文件，发现同一问题，再次崩溃。这个设计本意是保护系统，实际却成了最稳定的崩溃源。
修复逻辑很简单：发现危险代码→立即隔离文件→记录审计日志→继续扫描其他文件。但Guardian从这里学到了一个更深层的教训：生产系统的错误处理必须包含「状态重置」机制，否则重启只是延迟下一次崩溃。
从灭火到防火：Guardian的架构设计
经历这些事件后，团队把救火经验固化为三层防御体系。第一层是实时监控，用PM2的编程接口持续拉取进程状态，计算重启频率、内存曲线、CPU占用模式。
第二层是模式匹配。Guardian内置了常见故障的特征库：编码崩溃、同步循环、内存泄漏、僵尸进程。每种模式对应特定的诊断逻辑和修复建议，而非盲目重启。
第三层是人工兜底。当自动修复失败或故障模式超出已知范围，Guardian生成结构化的「战报」推送到Discord，包含时间线、相关日志片段、建议检查点。团队保留了一个Cursor IDE集成入口，用于紧急代码任务。
这套系统的核心假设是：多代理AI系统的故障从来不是单点问题，而是组件间交互的涌现现象。监控工具必须理解业务语义，而不能停留在进程存活检测。
团队公开的数据中，一个细节很有意思：70+个Bug里，超过60%发生在组件边界——桥接器、编排器、状态同步层。纯代理内部逻辑反而相对稳定。这印证了分布式系统的一句老话：故障喜欢躲在接口里。
Guardian现在跑在同一台Windows机器上，和四个核心代理进程、Dashboard后端、Discord机器人共处。它的自愈合能力也有边界——当自身进程异常时，依赖PM2的外部重启。团队考虑过双守护进程互检，但觉得过度设计。
他们的最后一个待解问题是：如果Guardian的告警逻辑本身有Bug，谁来守护Guardian？目前答案是「人」。每周一次的日志审计，人工抽查10%的自动修复决策。
这个折中方案能撑多久？团队没有给出预测。他们只是把问题写进了Guardian的Roadmap，优先级P2。
热门跟贴