WorkBuddy 的 11 个入口接入 Odoo，企业真实数据的 AI 工作台怎么搭

全文结构一张图看完，下面逐段拆

上周三下午，一个做门窗的客户把报价单发我，说客户嫌贵，让我看看还能不能让点。

我打开一看，单价一分没多，问题出在折扣上。他填的是 59.92，系统里存的是 60。

就差这 0.08，一张 12 万的单子多让了 96 块。。。他盯着屏幕愣了两秒，说了一句，那这系统还不如我用 Excel。

这话我听了十年。

不过这次真不怪系统。Odoo 的折扣字段是整数精度，小数会被四舍五入，文档里写着，只是没人看。

我想聊的是另一件事。

现在很多企业想把 AI 接到自己的业务系统上，第一天就卡住了。卡的不是技术，是不知道该先动哪个入口。工具列了一屏，每个都点开看过，回头还是回到微信里问人，这东西到底怎么用。

所以这篇讲两件事。十一个入口分别接 Odoo 的哪一段，以及一条真能跑起来的链路。

先说个数字，这套东西的软件授权费是 0。

Odoo 社区版，LGPLv3，源码和 PostgreSQL 都在你自己的机器上。WorkBuddy 那边十一个入口全开，也不额外收费。

但真正难的地方，压根不在省钱。

难在你把十一个入口点开之后，发现它们是十一个功能，得一个个学。

我一开始也这么以为。后来用久了才发现，它们只在回答五个问题。

哪五个？

怎么开始，谁干活，连什么，怎么自动，最后东西放哪。

十一个入口摊开看是这样。

表里最右边那列是我建议的推进顺序，P1 先做，P3 最后做。

说到谁干活，我要偏一下，说个自己的看法。

技能这个入口被严重低估了。大部分人把它当提示词收藏夹用，存一堆写得挺漂亮的句子，然后发现效果不稳定。

不是这么用的。技能里该装的是规则，不是话术。

我们给一个客户做的技能，里面就三条。报价默认用哪个价格表，外币订单必须走币种对应的价格表，折扣是整数不能填小数。

就这三条，写进去之后，AI 录单的准确率从六成上到九成多。

为什么？因为这三条正好是我们踩过的坑。

连接器回答连什么，它是唯一一个真正负责打通的入口。剩下十个决定的是这东西好不好用、能不能长期跑下去。

一句话概括分工，数据进 Odoo，决策在 WorkBuddy，产出回到资料库。

WorkBuddy 11 个入口一览

底座为什么选社区版。

三件事。

业务模型是现成的。客户、线索、产品、销售单、采购、库存、制造、项目，全在同一套 ORM、同一个库里。AI 问上个月哪些订单还没发货，不需要跨系统拼数据。官方口径是 4 万多个社区应用、2800 万用户。

接口是开放的。/xmlrpc/2/common 负责认证，/xmlrpc/2/object 用 execute_kw 调任意模型方法，fields_get 先摸清字段结构。这套对外接口不用买付费模块，自建社区版就能用。

第三是不锁死。数据在 PostgreSQL，源码可改，模块能自己写。哪天换了 AI 客户端，业务系统这边一行都不用动。

社区版缺什么我也得说清楚，不然就是坑你。

2026 年 9 月发布的 Odoo 20 依然是社区版和企业版双轨。完整会计、Studio、原生移动端、官方支持、版本升级服务，都在企业版那侧。社区版只有开票和基础会计，升级靠自己或者 OCA 的 OpenUpgrade。

所以免费工作台有个前提，团队里得有人能管服务器和备份。

10 人以内、流程还在调、只想先验证 AI 到底能不能帮上忙，社区版够用。到了要合并报表、审计合规、移动审批那一步，别硬扛，上企业版或者找实施方。省下来的授权费，补不上运维的坑。

链路是四层，数据层、通道层、能力层、沉淀层。顺序别乱。

数据层先做一件事，建一个只读的 API 用户。

Odoo 设置里的用户界面，建一个专用集成账号，在 API 密钥里签发密钥，按模型逐个授权。别拿 admin 的密钥去接 AI 客户端，这是现场实施最容易翻车的一步。凭据只放环境变量，配置文件里用 ${ODOO_MCP_TOKEN} 这类变量引用。

先用 common.version() 确认实例可达，再 common.authenticate(db, user, key, {}) 拿到 uid。

通道层是三种接法，我一个个说，每种都有它该待的地方。

自定义 MCP 连接器，客户端配一个地址，指向远程 MCP 端点，权限由 MCP Server 和 Odoo 用户共同决定。想最快跑通、以后可能换实现的团队用它。配置文件长这样。

{"mcpServers":{"odoo-community":{"type":"streamableHttp","url":"https://odoo.example.com/mcp/","headers":{"Authorization":"Bearer ${ODOO_MCP_TOKEN}"}}}}

一个坑。type 在各客户端版本里有 http 和 streamableHttp 两种写法，跟着内置连接器列表里的驼峰写法最稳。

加载后常用的就四个，list_models、search_records、get_fields、read_group。先跑只读。

Odoo 侧 MCP 模块，把端点做成 Odoo 里的一个 controller，不另起桥进程。好处是权限直接走 Odoo 自己的 ACL 和记录规则，可以按连接配模型白名单、写入审批、调用审计。多给几个 AI 客户端分账号时，这种结构省心。缺点是版本必须对齐。

脚本直连 XML-RPC 或 JSON-2，本地跑个 Python，账号权限全自己写。

uid = common.authenticate(db, user, api_key, {})orders = models.execute_kw(    db, uid, api_key,"sale.order", "search_read",    [[["state", "=", "sale"]]],    {"fields": ["name", "partner_id", "amount_total"], "limit": 20},)

三个提醒。查询一定带 limit，Odoo 大表上无条件搜索很吃资源。写操作前用 fields_get 看清类型和必填，别把几百个字段全倒给模型，答案会跑偏。多语言字段读写要显式带 context={'lang': 'zh_CN'}，否则写进 en_US 列，前端看着没变化。

三种接法的结构差异

还有个时间线要提前知道。从 Odoo 19 起，/xmlrpc、/jsonrpc 会打弃用警告。社区模块文档转述的官方移除节点是 Online 21.1 和 Odoo 22，替代者是 External JSON-2 API。

新项目优先选支持 JSON-2 的实现。别把整套自动化绑在一个迟早要退休的接口上。

能力层回答的是另一个问题，不是能不能读，是读完别乱写。

这一步最能体现专业度，也最容易被跳过。

下面几条都是真金白银踩出来的。

产品先按名称或编码查，查到就用现有的，查不到才新建，别复用别人留下的测试产品。外币订单先确认币种启用、汇率配好，再建该币种的通用价格表套到订单上。出口 EXW 报价的订单行不套税，小计才对得上。

按面积计价的产品，建库时单位就设平方米，数量按宽乘高实算，配件用件。单位设错，后面所有报表都要重做。位置、尺寸、玻璃这类定制信息写进订单行的定制说明字段，行名称保持产品描述。

改订单行的产品会触发价格重算，同一次更新里要带上单价，之后单独清税。默认销售税是价内税时，用数量乘单价除以 1.13 再乘一减折扣，核对行小计。对不上先怀疑税，别急着改数据。

这一层里，专家管审核标准，助理管跟进，项目管共享上下文，三者都不直接碰数据。

沉淀层是让工作台自己转起来。

自动化把日报周报设成定时跑，结果推到飞书或钉钉。资料库存 SOP、字段字典、报表模板，新同事不用再问一遍。应用入口把周报发成链接，给不进 Odoo 的人看。灵感入口收集社区里现成的模板，看到合适的直接复刻。

验收标准很简单。你出差一周，日报照常到，没人再问那个数在哪看，工作台才算真立住。

节奏上分三段，不排日历日期，每段只做一件能被验收的事。

P1 打通只读，查客户、订单、库存，出一份日报。用连接器、任务、空间。验收看数字和 Odoo 界面逐项一致，权限只给专用只读账号。

P2 规则固化，把录单规则写进技能，开放低风险写入。验收看写入回查一致，税、币种、单位都不出错，只放开线索、任务、草稿类模型。

P3 自动运行，定时执行、自动分发、产物归档。验收看连续一周不用人工干预。

P1 别急着开写权限，只读跑一周，先把字段定义、时区、多语言、分页这些基础问题暴露出来。P2 别急着连生产库，先用测试库把规则一条条验。P3 别急着加花活，稳定比功能数量重要。

这个节奏跟我们做售前方案是一个道理。先把最小闭环跑起来，让人看见东西，再往外扩。

坑我挑几个代价最高的说，按代价从高到低。

前三个坑跟技术无关，纯粹是流程习惯，却最容易撞上。真正翻过车的团队，几乎都栽在权限和凭据上，很少栽在 ORM 语法上。

这事让我想起 1880 年代的美国工厂。

那会儿电力刚开始普及，很多工厂主花大价钱买了发电机和电动机，装进车间，然后发现效率没怎么涨。

为什么？因为他们只是用电动机替换了蒸汽机，车间布局没动，流程没动，管理方式也没动。电变成了一个更贵的动力源，别的什么都没变。

真正吃到电力红利的那批人，是最早想明白电力到底改变了什么的人。

AI 现在这个阶段，就挺像 1880 年。

最后说说免费的到底是什么。

社区版免的是软件授权费，不是总成本。一台能跑 PostgreSQL 和 Odoo 的服务器、定期备份和恢复演练、安全补丁、跨版本升级、初始实施和字段梳理，这些都要人。

企业版收订阅费，买的是官方支持、升级服务和完整财务模块。

我算账的方法很简单。自建一年的运维人力加服务器，和订阅费乘用户数，放进一张表比，再单独加一行「数据必须留在自己机房」的权重。这行是硬约束，社区版基本就是唯一选择。

回到开头那张报价单。

那个客户后来把折扣字段改成了整数录入，前端加了一句提示，说只能填整数百分比。就这一行提示，再没出现过 59.92 变 60 的事。

接 AI 也是一样。你要的真是十一个功能全上吗？

我觉得不是。你要的是先把那条最容易错的路堵上，让它每次都走对。

我们把这套接入做成了现成的 MCP 接口模块，内置最小权限集成账号配置、只读起步的工具白名单、常用模型字段字典，还有可直接复制的 mcp.json。拿到之后按 P1 跑一次只读查询，当天就能在自己库里看到真实数据。

不用先写桥接进程，也不用先把十一个入口研究明白。