一个系统能不能被信任不取决于它正常运行时有多稳而取决于它崩了之后能不能自己恢复——并且不丢任何一条消息。这一轮最核心的工作不是新功能是“崩溃恢复链路”的完整性。一、崩溃恢复从OOM止血到消息去重到优雅退出进程内存超限被杀然后重启然后继续处理请求然后再次超限被杀——这个循环一旦开始整个编排服务就进入了反复崩溃的状态用户侧看到的全是“系统超时”。表面上这是资源问题解法是把内存限额调大。但调大只是止血不是修复。真正的问题在于没有并发控制。如果同时涌入的请求数量超过系统能处理的上限每一个请求都会消耗内存叠加起来就会撑爆进程。第一层修复是在进程内加了一个并发闸门——超过上限的请求排队等待而不是全部同时开始处理。OOM修完之后暴露了第二个问题崩溃后重投的消息被静默丢弃了。原来的去重逻辑是单态的——消息要么“处理中”要么“不存在”。进程崩溃时“处理中”的消息状态没有清理重启后这些消息再投进来系统认为它们已经在处理直接丢弃不报错。用户的感知是发出去的消息什么回复都没有。单态去重的问题在于它假设“处理中”一定会变成“完成”但进程崩溃打破了这个假设。第二层修复是改成两态处理中和已完成。崩溃恢复后所有还在处理中的消息视为未完成允许重新处理。已完成状态的消息才是真正的去重边界。止血之后是防复发。滚动升级和节点驱逐是两个常见的“意外终止”场景。如果进程被强制杀死正在处理的请求没有机会完成就又回到了消息丢失的问题。第三层修复是两个机制优雅退出窗口给进程一个“收尾时间”让它在被杀死之前把正在处理的请求跑完副本可用性保护防止滚动升级一次把所有副本都杀掉。OOM止血、去重两态、优雅退出——三个修复合在一起才构成一个完整的“崩溃恢复链路”。以前的目标是不崩现在的目标是崩了也能自己恢复。二、夜间日志巡检比用户更早知道问题这轮有一批修复来自“夜间日志巡检”包括解密失败日志洪泛、工具参数名导致的运行时错误、跨租户越权写库失败。这些问题的共同特点是不会让系统崩溃但会持续污染日志掩盖真正的异常信号。把日志巡检变成日常流程意义不在于“能发现更多问题”而在于“能看清系统真实在发生什么”。巡检驱动修复比等用户反馈驱动修复要早至少一个反馈周期。这是一种运营成熟度的标志你比用户更早知道系统出了问题。三、权限上下文没带全是比逻辑错误更隐蔽的bug这轮权限类的修复集中在一个模式上逻辑写对了但调用时上下文没带全。数据库的行级安全策略是正确的但它需要每次查询都显式声明当前的组织身份。漏掉这个声明查询不会报语法错只是静默返回空——或者在写入时报权限不足。消息写入没带组织归属、用户信息入库时没设组织上下文、工具加载时身份参数没注入——每一个单独看都是遗漏但背后是同一个问题多租户架构下“我是谁”这个身份信息需要在每一个调用边界都显式传递不能依赖全局状态或隐式继承。四、动态路由的脆弱性每一个环节都有状态自定义意图路由的核心逻辑是用户定义意图 → 系统自动注入到路由图 → 命中时跳转到对应子图。这条链路看起来顺畅但每个环节都有状态任何一个状态不对整条路由就断。具体问题包括查询意图定义时结果集被提前消费导致第二次读取为空节点名为空时没有过滤污染了边的配置身份上下文没注入导致查询权限不足。调试动态路由比调试静态路由难因为失败路径是在运行时才被激活的。修复之后自定义意图不再容易触发路由错误路由装配的稳定性明显提高。一共二十多条提交两次发版主线只有一件事让系统在压力下不崩崩了之后能恢复恢复后不丢消息。发版之后团队里有人说“以前我们是做到不崩现在是做到崩了也没事。”这两句话之间差了这整轮的工作量。这是第五十四天。《从0到1企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话只记录进化。如果你也在做企业 AI 落地欢迎留言来聊。或者把这篇转发给一个正在踩同样坑的朋友。