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