多租户系统最隐蔽的 Bug，不是崩溃，是数据悄悄流向了别人。

崩溃有日志，有报警，有人会来修。数据流错了，系统照常运行，用户照常登录，只是某家企业的员工信息，悄悄落进了另一家企业的数据库。

这种 Bug 不报错。

一、通讯录同步串企业：一次需要复盘的事故

这是今天最高风险的一组改动，也是最值得写清楚的。

系统支持接入飞书和钉钉通讯录，自动同步企业成员数据。早期实现里有一个隐患：同步操作使用的是平台全局凭证，而不是各企业自己的凭证。后果是：多租户环境下，一家企业的通讯录同步，可能用另一家企业的授权去请求，把数据写进错误的租户。

提交记录里有一段事故复盘：某个租户的通讯录被错误写入了另一家钉钉组织的员工数据，后来做了数据清理和重新同步。

修法不复杂：飞书和钉钉通讯录同步，改为强制使用各自租户自己的凭证；如果某个租户没配置凭证，直接拒绝同步，不走全局兜底。

“全局凭证方便，自己的凭证正确。” 早期为了跑通功能选了方便的那条路，到了多租户上线压力下，代价一次性还清。

顺着同一个问题往深处看：系统里有多少地方，在处理请求时，没有把“当前操作属于哪个企业”这件事传递下去？

答案不乐观：检索节点在某些路径下会绕过当前企业的隔离，打到默认租户的知识库；后台任务在异步调度时丢失了企业上下文，触发数据层拒绝写入；链路追踪里没有企业标识，排查跨租户问题时看不出来数据属于谁；工具调用时的身份注入散落在各处，修一个漏一个。

这批改动的目标是收口：把企业上下文的注入，从“哪里需要哪里补”，改成 “统一在执行边界处注入，内部链路不用再操心”。

二、消息媒体处理：别让一张图片卡死整条服务

外部消息渠道现在支持文档、图片、语音。

听起来是功能扩展，做起来发现全是坑。

第一个坑：媒体消息进来之后，系统需要先下载文件，再交给 AI 识别。如果下载和识别放在同步链路里，碰到大文件或慢网络，整个回调响应就超时了——消息平台以为投递失败，会反复重投，触发风暴。修法：收到消息先返回成功，再把处理任务放进后台异步执行。

第二个坑：图片识别是计算密集型的同步调用，放在异步事件循环里会阻塞整个进程，其他请求全卡住。修法：改用线程池调用，超时时间放宽。

第三个坑：文件大小没限制，任何大文件都往系统里塞。修法：设上限，超过的直接拒收。

三个坑，三种不同的问题本质： 第一个是“先确认再处理”的经典模式没用对；第二个是异步和同步混用的典型陷阱；第三个是边界校验缺失。

同一个功能点，三种系统问题类型，集中暴露。

三、开放平台能力扩展与追踪系统自建

上一轮开放平台只打通了 Agent 对话接口。这一轮扩展到知识库和文件管理：外部系统现在可以通过 API 创建、查询、更新、删除知识库，上传和下载文件，批量下载打包。功能不复杂，但接口化是一件标志性的事——知识库从“用界面管理”变成“可编程管理”，外部流程可以驱动 AI 系统的数据入库，不用人工操作界面。

与此同时，之前用第三方服务记录 AI 调用链路，这一轮彻底移除，替换成内建追踪表，数据落到内部数据库，不依赖外部服务，隐私数据不出域。

开放让能力可被调用，自建让数据可控可审计。 两个方向在同一天落地。

四、个人工具接入与内网适配

个人工具接入 Google Drive，这条线从“设计评审”推进到“测试环境可以跑通授权”。流程是：用户在设置里点击连接，完成授权，授权凭证绑定到个人账号，后续工具调用时自动带上个人凭证，不共享，不串用。

有一处细节值得说：为了让内网私有部署的服务也能被调用，系统对内网地址做了显式放行——企业级部署有很多服务不走公网，这是实际落地必须处理的场景，不是理想环境的设计。

今天没有新功能上线。做的事情都是：让已经存在的能力，真正安全地运行在多租户环境里。

这，是第五十九天。

《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。

---

如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。