定时任务跑完了，结果怎么交到人手上？敏感信息有没有从日志里漏出去？断点续跑能不能在模型切换时也不丢失选择？
这三天，116条提交，方向是统一的：让系统在后台做的事，能被看见、被信任、被安全地送到该去的地方。
一、定时任务：跑完只是开始，送达才是闭环
之前定时任务能跑，但跑完的结果留在系统里，需要人主动去看。这轮把最后一步补齐了：定时任务完成后，结果可以自动发送到钉钉——文本消息或单聊直达，用户不需要理解底层工具名和身份参数，只需配置通知目标。
同时，定时任务以服务身份运行时，可以通过组织级窄口授权获得指定能力，只能使用管理员明确授权的扩展服务，授权过程接入身份和审计链路。
前端同步增加了通知开关和扩展服务管理界面，手册也补充了服务身份说明。
定时任务从“后台执行”走到了“执行→授权→通知”的完整闭环。
二、安全加固：敏感信息不该出现在不该出现的地方
这一批提交集中修补了多个敏感信息泄漏点。
外部用户ID、渠道身份、工具参数不再原样进入观测日志；节点异常、定时任务结果和执行账本统一脱敏；零宽字符和嵌套异常等绕过脱敏的路径被封堵。已提交到代码仓库的明文凭据被替换或移除，无法通过代码完成的主密钥轮换登记为后续债务。
日志是用来排查问题的，不是用来泄漏信息的。
三、知识库入库：重入、并发、超时、删除，四种场景逐一加固
知识库入库是系统里最容易出并发问题的地方之一。这轮做了几件事：
同一文档重复上传时保持事务一致性，防止旧任务覆盖新版本；文档删除和后台摄取并发时不会重新写回已删除内容；上传记录先持久化，异常中断后可以识别和回收孤儿任务；明确不支持的文件类型直接判定失败，不浪费重试配额；后台还在处理但前端等待超时的场景不再被错误标记为最终入库失败。
四种场景，四种修复，一个目标：入库这件事，结果是确定的。
四、稳定性与可观测性
会话配额泄漏：清理流程失败时，沙箱并发配额可能永久不释放——任务已经消失，但组织名额始终被占用。这轮修复了配额死锁，清理无法继续时根据侧真实证据释放配额，同时长任务不再按固定时间杀死，改为判断是否仍在产生进展，避免正常任务被误杀。
模型路由快照：用户选好的模型，在任务排队期间可能丢失。这轮在提交时冻结路由快照，执行时按快照解析。安全策略切换模型时明确告知用户，不再静默降级，切换提示通过事件流到达前端。
失败归因：订单全集失败原因不再被统一错误码覆盖，沙箱失败遵守统一归因协议，源数据无效时区分语法错误、上下文不匹配等具体原因——失败从一个笼统的状态变成可定位的诊断信息。
OpenAPI状态码：租户自建Agent在OpenAPI路径下全部返回404，修复后正确返回业务状态。并发配额等冲突返回409/429，不再是500。
前端性能：大量历史执行结果默认折叠，避免一次渲染全部内容导致假死。
定时任务知道把结果送到钉钉，敏感信息不再泄漏到日志，知识库入库在并发下保持确定，每一个失败都有明确归因。
这三天，系统在变得更“体面”——它知道该把东西送到哪，知道什么不该说，也知道自己为什么出错。
这，是第八十四天。
《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。
