一句话：AI 的价值不在于多一个对话框，而在于让系统里已有的数据和规则能被直接使用。这条能力不做新系统，只做一件事——把 Odoo 的模型方法变成智能体可以安全调用的出入口。
问题在哪
为什么不是再挂一个 AI 对话框
把 AI 接在 ERP 上，常见做法是「导出数据 → 问模型 → 人工执行」。这条路能出演示效果，但落到日常经营里有三处硬伤。
导出即副本：口径会漂、时点会过期。模型给出的数字和系统里对不上，最后还得人工回去核对，省下的时间又还回去了。
查完还是人工录一遍。AI 只是「更快的搜索框」，效率提升有限，而人工转录的错误照样进系统，还得再查一遍。
没有走系统自己的方法与日志，事后无法回答「谁、在什么时候、按什么规则改的」。对需要留痕的业务来说，这一条就足以否掉整个方案。
让智能体在系统内部执行：动作落在具体的模型方法上，天然继承 Odoo 的权限、日志与字段校验。做完就有痕迹，出问题查得到。
它是什么
一个可复用的技能包，不是一套新系统
它按「技能」的形式交付：任何支持技能机制的智能体装上它，就获得操作 Odoo 的能力。不需要为每个智能体、每个场景单独写一套接口。
怎么工作
从一句自然语言，到一次可追溯的改动
六个步骤，每一步都尽量把「不确定」挡在执行之前。
实例地址、数据库名与 API Key 存成本地连接配置，之后复用，不在对话里反复出现凭据。
把一句自然语言解析成目标业务对象与操作类型：查询、读取、新建、更新、删除、自定义动作，还是经营分析。
先调接口索引确认模型确实存在，再取该模型的说明确认方法名与参数，最后才组装请求。不靠记忆猜模型名。
只带必填字段与实际要改的字段。写操作之前，先用只读查询把命中的记录摊开看清范围。
调用对应模型的接口执行；非 2xx 一律按失败处理，如实回报 HTTP 状态、message 与 debug，不把失败讲成成功。
按周期与维度聚合对比，区分事实与假设，输出结论、风险与按优先级排好的建议动作。
能力与边界
它能做什么，到哪里为止
右侧一列同样重要：能力清单不写边界，等于把风险留给客户自己发现。
| 能力 | 具体做法 | 边界 |
|---|---|---|
| 查数据 | 按条件检索与读取记录，可选择返回字段、限定条数 | 受 API Key 对应用户的数据权限限制——看不到的数据，它同样看不到 |
| 改数据 | 新建（支持批量）、按记录 ID 更新指定字段、删除记录 | 破坏性改动先列出命中的记录与将要修改的字段，确认后才执行 |
| 调用自定义方法 | 只要模型方法出现在 Odoo 的接口索引里就能调用，包括你们自研模块的方法 | 索引里没有的模型与方法不会被猜着调用；也不绕过模型的校验规则 |
| 经营分析 | 按时间趋势与结构维度聚合对比，指出主要拉动项与拖累项，给出建议与优先级 | 关键字段缺失时会先问，不编数字、不假设口径；事实、假设与建议分开写 |
安全边界
先把它不该做的事说清楚
任何能改数据的通道都值得被追问。下面六条是这条能力从设计上就带着的约束，不是事后补的说明书。
模型与方法都从 Odoo 自己的接口读出来核对，不靠猜。名字对不上就不执行，宁可停下问人。
查询、读取随时可做；新建、更新、删除这类改动，先把命中的记录列出来，确认后才落库。
API Key 保存在本机的连接配置里，不写进日志、不进入对话输出、不随代码分发。
请求只带必要字段；能幂等完成的操作优先用幂等方式，减少重复执行带来的副作用。
非 2xx 一律按失败处理，回报 HTTP 状态与错误详情，不把「没成功」包装成「已完成」。
以所配 API Key 对应用户的身份执行，遵循 Odoo 原有的访问权限、记录规则与字段级约束。
它不做什么：不绕过 Odoo 的权限体系；不做无人值守的高危写操作（建议给智能体的 Key 只开必要权限，写操作保留人工确认）；不替你做决定——它把数据与选项摆清楚，决定权仍在人手上。
它落在哪儿
横切在底座之上，不是第五个档位
四档产品体系都基于同一个 Odoo 业务核心，因此这条能力对四档同样适用。加它不需要换系统、不需要重做数据、不需要改现有流程。
底座回答「业务跑在哪」——Odoo 是业务事实来源，网关与 IoT 承载两条流量。这条能力回答「谁能操作它、怎么安全地操作」。它挂在 Odoo 这一层，不改变底座的任何职责边界。
① Odoo 侧启用接口文档模块（提供索引与执行入口）；② 为智能体单独签发一个 API Key，按最小权限给；③ 提供实例地址与数据库名；④ 建议先只在只读场景跑起来，口径确认无误后再开放写入。
常见问题
关于安全与边界的追问
它会自己改我的数据吗？
默认只读优先。涉及新建、更新、删除这类改动时，会先把命中的记录列出来，说明要改哪些字段，确认之后才执行；不确认就不动。
需要额外买什么？
需要在 Odoo 侧启用 api_doc 模块，并为智能体签发一个独立 API Key。技能本身是在本机运行的脚本，不引入第三方云服务，也不改变 Odoo 的部署方式。
我们自己开发的模块也能操作吗？
能。接口索引是按模型和方法生成的，你们自研模块的方法只要出现在索引里就能被调用，不需要为了它去改技能。
数据会流到哪里？
技能本身只在你的 Odoo 实例与本机之间走 HTTP，不往第三方服务发数据；但运行智能体所用的模型决定了对话内容的去向，这一点在选型时必须说清楚，不能含糊。
它能替我做决定吗？
不能，也不该。它负责把数据取准、把口径讲清、把建议按优先级列出来；要不要做、什么时候做、投多少资源，仍然由人决定。
想在你的 Odoo 上试这条能力？
我们可以先用只读权限跑一遍，把口径、边界与可改范围一起确认清楚
首次沟通不收费。如果你们的场景不适合让智能体操作数据，我们会直说，不硬上。