Odoo 19 引入了一层超越文本生成的 AI。它可以帮助用户查找信息、解读记录、打开视图、分类文档、支持客服工作、回答网站访客并选择受控操作。Odoo 19.4 进一步扩展了这一方向，加入了自动模型选择、语音交互、已保存对话、更丰富的在线聊天记录卡片以及 MCP 连接。

真正有价值的问题不是 Odoo 是否有 AI，而是在特定情况下，哪个代理被允许使用哪些信息和工具。Odoo 通过代理、技能、来源和服务器动作来区分这些职责。

从标准的 Ask AI 助手开始

标准的 Ask AI 助手可通过命令面板以及 Odoo 界面中的 AI 按钮使用。根据官方 Odoo AI 文档，它可以回答自然语言问题、打开视图、改进内容、总结聊天记录，并基于上下文提出下一步建议。

标准的 Ask AI 代理不能修改数据库记录。它可以帮助用户理解和浏览信息，但 Odoo 有意将这种辅助与执行写入操作的工具分开。这是一个重要的默认设置，因为流畅的回答不应在不知不觉中变成会计、销售或运营交易。

自定义代理定义特定职责

自定义 Odoo AI 代理具有系统提示、回复风格、一个或多个技能以及可选来源。官方 AI 代理文档 将代理描述为一个具有明确目的并可访问 Odoo 工具的自然语言助手。

在较早的 Odoo 19 文档中，指令和工具的集合被称为 topics。Odoo 19.4 将其重命名为 skills。目的保持不变：每个 skill 说明任务的上下文、规则和工作流程，而 tools 则是代理可以调用的实际功能。

这种结构支持为不同场景设计的代理，而不是一个拥有宽泛且模糊权限的助手。示例如下：

  • 销售助手，用于查找商机、解释管道数据并起草后续消息。
  • 支持代理，依据已批准的 Knowledge 文章回答问题，并将不确定的案例升级处理。
  • 文档代理，用于分类上传内容并选择已批准的文件夹或标签。
  • 现场服务助手，用于总结任务历史并准备客户更新。
  • 在线聊天代理，用于回答常见问题，并在收集必要信息后创建 CRM 线索。

来源决定代理可以参考什么

Odoo 代理可以使用 PDF、网页链接、Documents 文件和 Knowledge 文章作为索引来源。Restrict to Sources 选项会将代理限制为当前已上传的来源。这对面向客户的回答很有用，因为组织可以定义代理应使用的材料，而不是允许宽泛、缺乏依据的回复。

来源限制提高了控制力，但来源质量仍然很重要。文档应有负责人、审查日期，以及移除过时定价、政策或说明的流程。即使每个文档在技术上都已获批，冲突来源仍可能导致答案不一致。

Odoo AI 在线聊天如何工作

Odoo 可以将 AI 代理分配给 Live Chat 渠道规则。官方 AI Live Chat 文档 说明，代理可以回答常见问题、请求更多信息、评估对话并升级给人工客服。

所提供的在线聊天模式不会在第一条消息后就直接创建线索。其指令定义了何时适合升级处理、如何收集缺失的联系信息、如何确认已知信息，以及如何只调用一次线索创建工具。这说明工作流程指令与语言模型同样重要。

当代理在在线聊天中提到受支持的 Odoo 记录时，Odoo 19.4 还可以显示丰富的可点击卡片。这可以让访客更容易理解并打开产品、预约或其他受支持的记录。

公司专属聊天机器人是一种设计模式，不是一个复选框

多公司组织可能希望每个公司网站都有一个只回答本公司相关问题的聊天机器人。Odoo 提供了这种设计所需的构建模块，但边界必须明确配置。

一种实用模式是：

  • 为每个面向公司的体验使用单独的网站和 Live Chat 渠道或渠道规则。
  • 为每家公司单独创建 AI 代理，而不是使用一个试图推断公司归属的代理提示词。
  • 只向每个代理提供该公司已批准的 Knowledge 文章、文档、政策和网页链接。
  • 启用 Restrict to Sources，以确保回答始终限定在公司专属来源集中。
  • 仅分配该渠道所需的技能和工具，例如信息检索或受控线索创建。
  • 确保任何创建的线索、工单或预约都带有预期的公司上下文和负责团队。
  • 测试跨公司问题、含糊的品牌名称以及试图获取其他公司信息的尝试。

Odoo 多公司记录可以共享，也可以是公司专属的。其 multi-company 文档 说明，带有公司关联的报价单、发票和供应商账单会被限制在相应的公司上下文中，而联系人和产品等某些记录则可能默认共享。

这并不意味着每个 AI 来源都会自动隔离。不要把“只讨论 Company A”这样的系统提示当作保密控制。单独的来源集合、渠道分配、访问权限和工具侧检查，才提供更强的边界。如果需要严格的法律隔离，独立数据库可能比共享的多公司配置更合适。

代理只能通过分配的工具执行任务

如果代理没有技能，Odoo 说明它可以提供信息，但不能完成任务或修改数据库。工具会将代理的能力扩展到对话之外。预配置示例包括打开视图和创建线索，而已安装的应用还可以提供其他工具。

对于自动化记录工作流，Odoo 使用 AI 服务器动作。官方 AI server actions 文档 将 AI 管理器与执行工具分离。AI 读取记录和提示词，选择一个工具并提供声明的参数。标准服务器动作随后执行真正的业务逻辑。

这使 AI 能够做出上下文决策，而确定性代码负责执行规则。例如，AI 可以对供应商文档进行分类，但所选工具在写入任何内容之前，应验证目标、公司、允许的记录状态和必填字段。

有用的任务自动化模式

  • 对传入文档分类，并应用已批准的标签或文件夹。
  • 总结帮助台工单，并填充结构化的分诊字段。
  • 基于记录选择后续路径，同时将发送或审批留给用户。
  • 在确认所需联系方式后，根据实时聊天创建一条 CRM 线索。
  • 根据当前记录上下文起草一封电子邮件，供人工审核。
  • 将文档中的结构化信息提取到受控工作流中。

最薄弱的模式，是给一个宽泛的智能体配上一组强大的写入工具。范围更窄的智能体更容易测试、解释和审计。

Odoo 19.4 新增内容

官方Odoo 19.4 发布说明 为这种智能体模型增加了几项能力：

  • 为任务自动选择最合适的已配置 AI 模型。
  • 通过语音与智能体交互，口述请求。
  • 在最后一条消息后最多保留 30 天的智能体对话记录。
  • 与兼容的外部工具进行 MCP 连接。
  • 为实时聊天中提到的受支持记录显示丰富预览卡片。
  • 将 topics 更名为 skills。

MCP 扩展了集成可能性，但也扩大了安全审查范围。在连接外部 AI 客户端之前，应先记录凭据、已暴露的工具、用户权限、日志和数据边界。

提供商与定价考虑

Odoo 支持 OpenAI 和 Google Gemini 提供商。Odoo Online 用户无需为标准服务添加自己的 API 密钥，尽管他们可以这样做以获得更高控制权。Odoo.sh 和本地部署数据库需要提供商密钥才能使用 AI 功能。The Odoo AI API key documentation 指出，当使用客户自有密钥时，可能会产生提供商费用。

安全上线清单

  • 选择一个范围明确、且已有可衡量人工流程的用例。
  • 定义允许来源、禁止主题以及人工升级路径。
  • 分配所需的最少工具，并在每个工具内强制执行规则。
  • 使用普通账户测试公司、用户和记录访问权限，不要只用管理员账户。
  • 测试错误、不完整、对抗性以及跨公司的问题。
  • 对财务、合同、破坏性或外发操作要求人工审核。
  • 上线后监控回答、工具调用、提供商使用情况和来源新鲜度。

实践结论

Odoo AI 最适合作为现有业务流程中一组聚焦的助手。实时聊天、公司专属知识、线索创建、文档分类和基于记录的自动化，都是可信的用例，因为 Odoo 可以将自然语言决策与结构化记录及受控工具结合起来。

设计绝不能只依赖信心或单靠提示词。应按用途拆分智能体，限制其来源，最小化其工具，并将业务规则保留在确定性的 Odoo 动作中。这样，聊天机器人演示才能变成可支持的运营能力。