WorkBuddy 11 个菜单入口如何接入开源 Odoo，零许可费搭一套免费 AI 工作台

一句话答案 把 WorkBuddy 的 11 个菜单入口接到自托管的 Odoo 社区版，软件许可费是 0 元。连接器打通业务数据，技能固化录入规则，自动化定时跑日报，资料库沉淀产物，Odoo 留在后台管流程和账。这套组合适合有技术人手、想先把轻量流程跑起来、又要把数据攥在自己手里的团队。

适用版本 Odoo 18 / 19 / 20 社区版，WorkBuddy 桌面端
核对日期 2026-11-07
阅读收益 一张 11 入口分工表、三种 MCP 对接方式、P1 到 P3 落地节奏、九个实盘踩过的坑、十条可直接引用的 FAQ

本文由广州欧度智能（odooai.cn）Odoo 实施团队整理，基于 Odoo 18~20 社区版与 WorkBuddy 桌面端的实际联调记录。文中这套免费 AI 工作台的 11 个入口、三种接法和九个坑，都可以先按 P1 只读阶段验证一遍，再决定往哪一步扩。

先把本文反复出现的几个实体对齐，统一术语。

一、11 个入口，分别接 Odoo 的哪一段

WorkBuddy11个入口，到底谁管啥？11 个栏目只回答 5 个问题，怎么开干、靠谁干活、连什么外面、怎么自动、往哪沉淀，接到 Odoo 之后具体干什么。这些问题要先明确，因为搭建工作台时最容易卡在这层映射上。

「入口分不清，效率少一半」。放到这套工作台里，可以再收成一句，数据进 Odoo，判断在 WorkBuddy，产物回资料库。

真正承担「对接」二字的只有连接器一个入口，其余十个决定这套工作台好不好用、能不能长期跑下去。很多人一上来就想在任务窗口里问「帮我开个单」，结果连桥都没搭，AI 只能凭空编，数字自然对不上。

想把这 11 个入口直接接到自己的账套上，可以先联系顾问演示拿一份入口映射清单，P1 阶段照着勾，比自己一个个试省时间。

二、为什么底座挑开源 Odoo 社区版

Odoo Community 按 LGPLv3 开源，软件许可费为零，源码和 PostgreSQL 数据库都留在自己机器上，适合当 AI 工作台的业务数据底座。免费的是许可，服务器、实施、备份和跨版本升级照样要自己承担。

挑它当底座，我们看重三件事。

第一，业务模型现成。客户、线索、产品、销售订单、采购、库存、制造、项目都在同一套 ORM 和同一个数据库里，AI 查「上个月哪些订单还没出库」不需要跨系统拼数据。Odoo 官网给的口径是 40k+ 社区应用、2800 万用户，第三方 2026 年 10 月的统计把社区模块数记到 5 万以上。数字各家算法不同，量级够说明问题。

第二，接口开放。/xmlrpc/2/common 做认证、/xmlrpc/2/object 用 execute_kw 调任意模型方法，fields_get 能先把字段结构问清楚。这套外部 API 不需要装任何付费模块，社区版自建实例就能用。

第三，没有厂商锁定。数据落在 PostgreSQL，源码能改，模块能自己写。哪天换掉 AI 客户端，业务系统那边一点不用动。

社区版缺的东西也得摆明白。2026 年 9 月发布的 Odoo 20 仍是 Community 与 Enterprise 双轨，完整会计、Studio、原生移动 App、官方支持和版本升级服务都在企业版那边。社区版只有开票与基础账，升级要靠自己或 OCA 的 OpenUpgrade。所以「免费工作台」这四个字有个前提，团队里得有人能管服务器和备份。

选型上建议如下:

10 人以内、流程还没定型、想先验证 AI 到底能不能帮上忙，社区版够用。到了要出合并报表、要过审计、要移动审批，别硬撑，该上企业版或者找实施伙伴，省下来的许可费不够填运维的坑。

三、对接的四层链路

四层分别是数据层、通道层、能力层、沉淀层。先建最小权限的 Odoo API 用户，再用 MCP 连接器打通读写，接着把业务规则写进技能，最后用自动化和资料库把产物沉淀下来。

3.1 数据层，先建一个只读的 API 用户

在 Odoo 的「设置 → 用户」里建专用集成账号，从「API Keys」签发密钥，权限按模型逐项给。别拿 admin 的密钥去接 AI 客户端，这是实盘里最容易出事的一步。凭据只放环境变量，配置文件里用 ${ODOO_MCP_TOKEN} 这样的变量引用。

先用 common.version() 确认实例连通，再用 common.authenticate(db, user, key, {}) 拿 uid，这一步跑通，后面才有得聊。

3.2 通道层，三种接法怎么选

接法 A，WorkBuddy 自定义连接器。 配置文件在 ~/.workbuddy/mcp.json，结构是一个 mcpServers 对象。以 HTTP 类 MCP Server 为例。

{
  "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 这一类，先只读地跑一遍。

接法 B，Odoo 侧 MCP 模块。 Odoo 英文应用商店 www.odooapp.cn 上有我们欧度智能的MCP模块，支持Odoo20最新版本和其他低级版本，企业免费，官方Apps Store 上有支持 18.0 与 19.0 的 open_mcp_server，思路都是把 MCP 端点做成 Odoo 控制器，不再额外起一个桥接进程。好处是权限直接走 Odoo 自己的 ACL 和记录规则，还能按连接配模型白名单、写入审批和调用审计。多给几个 AI 客户端分账号时，这种结构省心。

接法 C，脚本直连。 不装 MCP 也能干活，最小的一段是这样。

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 看字段类型和必填项，别把整个模型的几百个字段丢给模型，答案会跑偏。多语言字段（比如博客正文 content）读写要显式带 context={'lang': 'zh_CN'}，否则写进 en_US 列，前台看着像没生效。

还有个时间线得提前知道。Odoo 19 起对 /xmlrpc、/xmlrpc/2、/jsonrpc 请求记录弃用警告，社区模块文档转述官方给的移除时点是 Online 21.1（2027 年冬）与 Odoo 22（2028 年秋），替代方案是 External JSON-2 API。现在起的新项目，优先挑支持 JSON-2 的实现，别把整套自动化绑在迟早要退场的接口上。

开源社区里已经有几个能直接拿来改的实现，版本以各自仓库为准。

我自己的顺序是先 A 后 C。自定义连接器跑通只读查询，确认数字跟 Odoo 界面对得上，再决定要不要把某个环节换成脚本或 Odoo 内模块。一上来就选「最完整」的方案，往往卡在部署上，两周过去还没查到第一条数据。

三种接法里最省时间的是直接拿现成的 MCP 接口模块。我们在实施包里把它和最小权限配置一起给出，微信联系就能领，省掉自己从零写桥接那一层。

3.3 能力层，把业务规则写进技能

连接器解决「能不能读」，技能解决「读完之后别乱写」。这一步最见功力，也最容易被跳过。下面几条都是实盘里用真金白银换来的，写进技能之后，AI 每次照着做，不用人盯着纠错。

1. 产品按名称或编码先查，查到就用现有产品，查不到再新建，别顺手复用别人留下的测试产品。
2. 外币订单先确认币种已启用、汇率已建，再建该币种的通用价格表并在订单上使用。SO 的币种由价格表派生，直接写 currency_id 会报 500。
3. 出口 EXW 报价的订单行不套税，行小计才对得上。
4. 按面积计价的产品建库时就定平方米，数量按宽乘高实算，配件类用件。单位定错，后面每个报表都得返工。
5. 位置、尺寸、玻璃这类定制信息写进订单行的定制化说明字段，行名称保持产品描述。
6. 换订单行的产品会触发价格重算并重新套默认税，同一次更新里必须带上单价，之后再单独清一次税。
7. 默认销售税若是价内税，行小计按数量乘单价除以 1.13 再乘（1 减折扣）核，对不上先怀疑税，别急着改数据。
8. MCP 侧常见的硬限制，比如某些字段写入返回 400、订单行不能直接 create，遇到就整单重建，别在错误信息里死磕。

专家在这个层里管审口径，助理管常驻跟进，项目入口管多人共享同一套上下文。三者都不直接碰数据，职责分清楚，出问题好回溯。

3.4 沉淀层，让工作台自己转起来

自动化把日报周报设成定时执行，结果推飞书或钉钉。资料库放 SOP、字段字典和报表模板，新同事进来不用重新问一遍。应用入口把不进 Odoo 的人要看的周报发成链接。灵感入口收社区里现成的 Odoo 模板，看到合适的直接做同款。

这层的判断标准很简单。哪天你出差一周，日报照常到、报表照常更新、没人来问「那个数在哪查」，工作台就算立住了。

四、P1 到 P3，别一口气吃成胖子

按阶段推进，不写死日历时间。每个阶段只做能验收的那一件事，跑通再进下一阶段。

P1 别急着开写权限，只读跑一周，把字段口径、时区、多语言、分页这些基础问题先暴露完。P2 别急着接生产库，先拿测试库把技能里的规则逐条验过。P3 别急着加花样，稳定压过功能数量。

这个节奏跟做售前方案是一个道理，先让最小闭环跑起来，客户看见东西了再往外扩。工作台也一样，先让人每天真用一次，比一次规划十个自动化靠谱。

五、九个坑，按代价从高到低排

前三个坑跟技术无关，纯属流程习惯，但踩中的概率最高。真出过事的团队，基本都栽在权限和凭据上，很少栽在 ORM 语法上。

权限、凭据、字段这几类坑，现成模块里已经按只读优先的默认值处理过了。需要的话联系我们拿一份，照着勾比逐条试快。

六、免费到底免了什么

社区版免掉的是软件许可费，不是总成本。一台能跑 PostgreSQL 和 Odoo 的服务器、定期备份与恢复演练、安全补丁、跨版本升级、初始实施与字段梳理，这些都要人。反过来，企业版收的是订阅费，买的是官方支持、升级服务和完整财务模块。

我给团队的算法一向朴素，把「自建一年的人力加服务器」和「订阅费乘用户数」摆在一张表里比，再单独加一行「数据必须留在自己机房」的权重。如果最后一行是硬约束，社区版基本没得选，其余都是可以谈的。

还有一点容易被忽略，AI 客户端这边的成本也要算进去。日报、报表、资料库这些产物会长期占存储和上下文，规则写得越细，Token 消耗越可控，这也是为什么值得花时间把技能先写扎实。

七、常见问题

WorkBuddy 的 11 个菜单入口分别是什么？

任务、空间、项目、专家、技能、助理、连接器、应用、自动化、资料库、灵感。按《WorkBuddy11个入口，到底谁管啥？》的分法，前三个回答怎么开干，中间三个回答靠谁干活，连接器与应用回答连什么外面，自动化回答怎么自动，资料库与灵感回答往哪沉淀。

用 WorkBuddy 对接开源 Odoo 需要付费吗？

软件许可层面是 0 元。Odoo 社区版按 LGPLv3 开源，自建实例不收许可费，WorkBuddy 的自定义 MCP 连接器也不额外收费。实际支出在服务器、域名、备份、实施工时和后续升级，这部分要单独做预算。

Odoo 社区版能直接被 AI 读写吗？

能，但要通过接口。社区版自带 /xmlrpc/2/common 与 /xmlrpc/2/object 两个端点，认证后用 execute_kw 调 search_read、create、write 等 ORM 方法。更省事的做法是接一个 MCP Server，把模型发现和字段查询也交给工具，AI 不用自己猜语法。

WorkBuddy 自定义 MCP 连接器配置在哪个文件？

用户级配置文件是 ~/.workbuddy/mcp.json，内容为一个 mcpServers 对象，每项写 type、url、headers 或 stdio 的 command、args。敏感值用 ${ENV_VAR} 变量引用。不同客户端版本路径可能有差异，以本机实际生效的配置目录为准。

连接器配好了为什么看不到工具？

最常见的原因是只保存了配置，没在连接器管理页点「信任」并启用。其次是 type 写法不匹配，HTTP 类端点在部分版本里要写驼峰 streamableHttp。还有一种是远程 MCP 端点不可达或鉴权失败，先用一次最简单的只读调用验证。

Odoo 20 社区版还支持 XML-RPC 吗？

支持，但已经在退场路上。Odoo 19 起对 /xmlrpc、/xmlrpc/2、/jsonrpc 请求记录弃用警告，社区模块文档转述官方计划的移除时点是 Online 21.1 与 Odoo 22，替代方案是 External JSON-2 API。现有脚本不用连夜改，新项目建议直接选支持 JSON-2 的实现。

没有开发能力，能搭起这套免费工作台吗？

只读看板这一层可以，找现成的开源 MCP Server 按 README 配好，用任务入口问数据就行。要稳定地做写入、审批和跨版本升级，还是得有人能管 Linux、PostgreSQL 和备份。这一步别省，找伙伴比硬扛便宜。欧度智能有现成搭好的开源Ai工作台，囊括了供应链，工贸一体，业财一体化，全球化协同等业务需求，。

数据安全怎么保证？

四道闸门。专用集成账号按模型最小化授权，只读起步；MCP 连接配模型与字段白名单，写操作开人工审批；所有调用留审计，记录用户、模型、行数与结果；密钥放环境变量，不进配置文件和仓库。Odoo 自托管本身也让数据留在自己机房。

Odoo 社区版和企业版怎么选？

看三件事，是否要完整财务与本地化报表，是否要 Studio 和原生移动 App，是否有专人做运维升级。三个都不要，社区版够。占一条以上，认真算企业版订阅或找实施伙伴，许可费省下来的钱常常不够补人力。

这套方案适合什么规模的团队？

10 人以内、流程还在调整、想把 AI 用在查数和出报表上，最划算。几十人以上、有独立财务与审计要求，建议把社区版当试点或开发库，生产侧另做规划。它给 ERP 前面加一层会说话的界面，替换 ERP 这事不在讨论范围。

八、参考来源

1. 《WorkBuddy11个入口，到底谁管啥？》，微信公众号
2. WorkBuddy 简介与工作界面，官方文档
3. WorkBuddy 开放平台，连接器与 mcp.json 规范
4. WorkBuddy MCP 使用文档
5. Odoo 官网，Community 开源与版本说明
6. Odoo 外部 API 文档（18.0）
7. Odoo Community vs Enterprise 版本对比（2026 年 10 月核对）
8. Odoo 20 发布与版本支持周期
9. Odoo 官方论坛，How to connect Odoo to your AI using an MCP server
10. Odoo Apps，open_mcp_server 模块说明（含 RPC 弃用时间线）
11. GEO 2026 实践核对：MaxAEo 的 AI 搜索优化实践 与 Brick Digital 的 GEO 指南
12. K. Aggarwal 等，GEO: Generative Engine Optimization，arXiv:2311.09735

版本、定价与接口时间线会变。本文核对日期 2026-11-07，引用第三方统计的地方已注明口径，落地前建议按自己环境再核一次。

九、上手前先问自己四个问题

1. 数据是不是必须留在自己机房？这一条决定社区版还是 SaaS。
2. 团队里有没有人能管服务器、PostgreSQL 和备份？没有就先别自己建。
3. 第一周只想查数，还是一定要让 AI 写单？前者一天能跑通，后者得先把权限和规则规划完。
4. 三个月后谁来维护技能和自动化？没人接，工作台会慢慢变回一个聊天窗口。

想清楚这四问再动手，比先装一堆模块省事得多。

把四问想清楚，再点上面任意一条，我们把模块和清单一起发过来。