面向 MCP 与 AI 工作流的 Odoo 治理型模型接入。

受控模型暴露

通过治理型桥接层暴露获准的 Odoo 模型，而不是直接公开内部模型 authority 内容，也不是依赖临时导出的静态元数据。

商业私有交付

把受保护能力保留在私有商业版本里，同时又为市场上架、客户评估和合规审查提供公开的产品页、支持页和隐私页。

贴合实际部署

根据真实 Odoo 运行时的模块安装情况与版本边界决定暴露结果，避免“设计上可见、运行时却不存在”的漂移问题。

版本与版本线隔离

• 文档化的 manifest 基线中明确区分 community 与 pro。
• 支持非公开商业能力的受保护交付路径。
• 避免把公开元数据入口与私有 authority 源混在一起。

运行时可用性判断

• 根据真实安装模块决定模型是否暴露，而不是默认所有可选应用都存在。
• 像 mrp、project 这类应用按部署情况处理。
• 对可见模型与 metadata fallback 行为保持最终治理控制。

受治理的分发模型

• 适配 bundle 与 lock 的分发模型，而不是靠 authority 侧源码复制。
• 适合需要稳定、可重复交付语义的下游消费者。
• 支持私有商业交付，而不是被迫公开仓库。

工程基线

• 当前工作区记录了 475 项通过测试的基线。
• 当前记录版本基线：17.0.1.6.0。
• 迁移脚本已进入记录中的交付基线。

1. Odoo 侧

桥接能力安装在客户的 Odoo 环境中，并以真实启用模块和实际版本边界为准。

2. Foggy 侧

Foggy MCP 或网关组件消费治理后的输出，桥接层负责模型可见性与交付边界的最终判断。

3. 消费侧

AI 助手、工具或其他下游系统通过 MCP 或网关链路来消费暴露出的模型能力。

适合的客户类型

• 希望把部分 Odoo 模型开放给 AI 或自动化流程的组织。
• 需要版本线隔离、运行时判断与治理边界的团队。
• 希望走私有商业交付，而不是公开源码暴露的合作伙伴。

公开站点应承担的职责

• 准确描述产品。
• 明确披露外部服务依赖。
• 提供支持、隐私和条款入口。
• 不把 roadmap 伪装成当前默认交付能力。

AI 辅助的内部运营

在助手或自动化流程中使用获准的 Odoo 模型，而不是把整个 ERP 面向不受控消费者开放。

企业级治理交付

当多个团队或多个环境共享一条集成线时，保持版本边界、可选模块与运行时可用性始终明确。

私有伙伴交付

在客户交付中保留私有桥接逻辑，而不是被迫把商业实现流程放进公开仓库或公开市场包里。

1. 明确目标模型

先确认需要暴露给 MCP 消费端的 Odoo 模型、模块与业务流程。

2. 评估治理边界

确认版本线隔离、可选模块行为、部署模式，以及是否需要 Foggy 侧服务组件。

3. 规划上线方式

确定交付路径、支持通道，以及测试、预发、生产环境的上线步骤。