最危险的故障不是系统崩溃，而是系统看上去正常运行，但悄悄用一个错误的结果替换了正确答案。
这24小时里，修了三件事。其中最值得记录的，是一次静默降级引发的连锁反应，以及最终的结构性修复。
一、智能体权限：从"能不能看见"到"能不能用"
上一期打通了知识库的成员级权限，这一期补完了智能体侧。
智能体可见性现在分三档：
-
组织开放：所有成员默认可见、可用
-
受限可发现：出现在列表里，但只有被授权的成员能发送
-
受限隐藏：不出现在列表里，只有被授权的成员能找到并使用
后端加了成员授权、用户组授权、可见性过滤和发送硬闸，前端补了权限配置页和使用侧置灰交互。同时加了两条边界规则：管理员豁免发送限制，不会因为某个智能体被设为受限而把自己锁在外面；平台级智能体禁止租户修改配置，确保系统内置能力不会被租户覆写。
二、向量化：一次静默降级引发的架构重构
这是这一期技术含量最高的一条线，也是最能说明"静默失败比崩溃更难处理"的例子。
事情的起点是离线环境下的一个行为：当网络不可用时，向量化模型加载失败，系统没有报错，而是悄悄切换成用哈希值替代真实的向量表示。哈希值没有语义，检索结果全部失效------但系统显示一切正常，知识库查询有返回，只是答案从来不对。这个问题在中文知识库检索上尤其明显：召回率归零，但没有任何报错提示。
修复这一处静默降级之后，暴露了下一个问题：为了让向量化在离线环境下真正可用，每个工作进程都要自己加载一份模型，内存消耗成倍增长，编排器开始出现内存不足的崩溃。临时处理是把内存上限提高兜底，但这不是根本解法。
根本解法是把向量化模型从"每个进程各自加载"改成"独立共享服务"：抽出一个专门的向量化服务，所有业务进程通过网络接口调用，不再各自持有模型。模型只加载一次，内存占用降回正常水位，编排器的内存限额随后收回到合理值。
但共享服务上线后又出现了两个新问题：一是返回的数据类型在序列化时报错，接口返回异常；二是内部服务地址被误路由到了外网代理，请求出不去，再次触发静默降级回哈希。两处都在当天修复。
整条链路的修复路径大致如此：
静默降级发现 → 离线加载修复 → 多进程内存不足 → 共享向量化服务 → 序列化异常修复 → 代理误路由修复 → 内存限额收回
每一步修复都触发下一个问题，直到结构性改造完成才稳住。
三、技能沉淀与可观测性清理
技能沉淀管道里有两个长期存在的死通道，从来没有真实数据流经，只是占着位置。这一期删掉了，同时给沉淀队列加了语义相似度门槛：候选技能在入队前先做相似度检查，和已有技能高度重复的直接过滤，避免队列积累大量同质候选。
可观测性侧修了一个低频但每次出现都产生大量噪声的问题：链路追踪写数据库时，文本字段里偶尔含有不可见的非法字符，数据库直接拒写，观测数据丢失。修复是在写入前做一次清洗，把非法字符剥掉。
三件事，时间跨度24小时。权限体系在上一期之后继续收口，向量化架构从"临时可用"走到"结构稳定"，管道和观测做了一轮清理。
最让人印象深刻的，还是那次静默降级。系统没有崩，日志没有红，检索结果还在返回------只是所有答案都错了。这种故障不容易发现，因为它不会让人第一时间去查。
这，是第六十五天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。