用户点击发送之后的沉默，比慢更伤害信任。
慢，意味着系统在努力。沉默，意味着系统是不是还活着都不知道。两者在感知上的差距，远比实际耗时的差距大得多。
这两天最重要的一件事，就是把沉默变成反馈。
一、首响应延迟：多层同时压
聊天链路的首响应优化不是一个点，是同时在多个层面一起压：
提前开流：用户发送之后，不等到真正有内容再建立流式连接------连接提前拉起来，状态事件先到前端。于是"发送后的第一秒"从黑屏变成可感知的进度反馈。
过程状态事件化：从收到请求、进入准备、进入队列、开始执行，每一阶段都有明确事件推送到前端。用户能看到系统在哪个阶段，而不是只能等。
去掉冗余路径：后端不同组件之间有重复的安全分类调用------同一句话被分类了两次，去掉一次，延迟直接省掉。
连接复用：原来每次请求都重建基础连接，改成复用，减少请求初始化开销。
查询缓存：知识库检索改写阶段增加单次飞行缓存，同一个问题在多知识库扇出时不重复调用语言模型做改写。
意图分类短路：问候语判断改成本地规则直接短路，不再走完整分类流程；意图分类本身换成更轻量的模型。
这些改动每一个单独拿出来都不大，叠在一起，静默窗口明显收窄。同时加了结构化的延迟日志，首反馈时间和首Token时间现在可以被量化观测------知道改了什么，也知道改了多少。
二、递归死循环：一个生产事故的根和治
某些租户的执行链路进入了无限递归，一直转，出不来。
根因是：当系统尝试刷新工具列表时，命中了一个特定意图，系统试图调用对应的子图处理------但这个租户没有定义这个子图。没有子图怎么办？系统没有报错，而是静默回退到默认主图。默认主图又会再次触发同一个意图判断，再次找不到子图，再次回退......
静默回退是这个事故的核心。 系统没有崩，没有报错，只是在原地兜圈子。
修法分两层：
第一层是加护栏------子图入口检测递归，刷新工具意图增加长度闸门，拦截误触发。
第二层是结构调整------把刷新工具节点从子图间接层直接提进主图，消除"找不到子图"这个触发条件本身。不只是防住症状，把能递归的路径在图结构上去掉了。
三、系统说的"已发送"是什么意思
这是一个产品诚实性的问题。
消息发出之后，系统提示"已发送"。但这个"已发送"的实际含义是：平台方已经受理了发送请求，不代表用户真正收到了。两者之间有差距------消息可能因为模板问题、计费问题、对方设备状态等原因没有送达，但操作员已经认为任务完成。
修法是：文案改成明确的"平台已受理"，同时新增状态查询工具，操作员可以主动查真实送达状态、识别失败原因。
同一个逻辑还体现在另一处：未发布或已下架的智能体被调用时，之前直接抛出服务器内部错误，用户看到的是无法理解的系统错误。改成明确的业务错误码加中文说明------这是什么状态、为什么不能用，让操作员能读懂、能处理。
系统报的错，也是产品的一部分。
四、地基：一批看不见的修复
这轮还有一大批稳定性修复，集中在会话与资源管理这条线：
容器会话的身份识别、执行权限、资源配额、用量计量、任务终态资源回收------一口气修了将近十个问题，把会话从能跑到准确计账到任务结束后干净退出，整条链路都打通了。同时给会话沙箱关掉了出网权限，提升容器隔离级别。
数据库连接池最大连接数之前是硬编码的固定值，在并发尖峰时池被打满导致排队。改成环境变量可调，生产环境按需调高。
外部OAuth登录最后一步因为一个参数签名漏改，导致登录成功后回调直接报服务器错误。修掉，同时保持此前用户身份归一的结果不被破坏。
今天的主线，用一句话概括：让系统在等待时开口，在出错时说清楚，在循环时能停下来。
这，是第七十三天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。