结论先行
很多人对“让 AI 读业务数据库”的直觉是：连上数据库、抓一遍表、机器人马上就能答。企业版没有这么做。数据库接入在源码里至少被拆成三段：远端同步、平台内落库、AI source 可访问性判断。这条链的重点不是连通，而是边界。
第一层：入口或表面动作
第一棒在 databases 模块。project_project._cron_synchronize_all_databases() 会按托管类型、错误次数、上次同步时间筛数据库，再创建 databases.synchronization.wizard 批量同步；而 _do_synchronize() 又会把远端返回的用户、KPI 等内容拆到 _write_users()、_write_kpis() 落库。也就是说，外部数据库接入 Odoo 后，先变成平台上的结构化投影，而不是 AI 直接连远端跑查询。
第二层：真正的业务护栏
第二棒是访问边界。project_project._compute_database_can_access() 会根据当前用户 login 是否存在于 databases.user 分组结果里，决定这条数据库记录对当前用户是不是可访问。这个设计很关键：数据库是否被同步成功，不等于任何 AI 用户都能读取它。可访问性先由数据库模块自己定义。
第三层：状态落点与边界
第三棒才到 AI。ai_agent_source._compute_user_has_access() 与 _update_source_status() 表明，AI source 会根据底层来源类型、embedding 状态、失败情况来决定是否激活；models._get_ai_context() 则把可读记录组织成供模型消费的 mini ORM snapshot。换句话说，AI 读到的不是“任意数据库连接”，而是一份已经过同步、映射、索引、权限判断后的上下文快照。
为什么这套设计更稳
这就是为什么“接上数据库就能让机器人读”是个危险错觉。少了同步层，AI 查询不可审计；少了 source 状态层，embedding 失败和缺块会变成静默错误；少了 access 计算层，AI 很容易把本不该看的业务数据读出来。企业版把三层都摆在明面上，本质上是在保护数据边界而不是展示酷炫功能。
实战启示
如果你想扩展这条链，最稳的做法往往不是让 AI 直接拿凭证连数据库，而是在同步写入、source 激活、上下文裁剪上做文章。真正应该回答的问题，不是“机器人能不能读”，而是“这段数据经过了哪些中继、现在以什么身份被读”。
DISCUSSION
评论区