Odoo AI 智能体测试：验收实际保存的活动记录

返回

Kevin Riedl

12 分钟 阅读 · 2026年11月5日
最近审核 2026年11月5日

下一篇

智能体说已经安排了跟进。系统里确实出现一条新活动，负责人正确，截止日期也正确，却关联到了另一条商机。如果测试只检查“有没有创建成功”，就会接受错误结果。

应依据书面的业务状态要求测试 Odoo AI 智能体。明确它可以创建什么活动、哪些记录必须保持不变、何时应先请求澄清。先用故意构造的错误观测验证结果检查器，再用它评估实际安装环境中的受控运行。

资料核验日期：2026 年 11 月 5 日。产品事实来自 Odoo 20 官方文档和源码。我们将十三条人工构造的 JSON 观测输入 Python 检查器并执行了分类；没有运行 Odoo、AI 模型或邮件服务器。下载的原生验收包是拟议检查，全部标为 NOT_RUN。

Odoo AI 智能体测试应该证明什么？

测试应在约定观测范围内证明，允许的业务结果确实发生。请求的写入必须正确，受保护的已有记录必须不变，证据中不得出现禁止的影响。对话顺利结束或工具返回成功，都不能单独证明这些条件。验收依据应指向实际业务状态，而不只是执行过程中的说法。

结果检查器也称测试判定器，它按照约定预期对照观测证据。这条判定规则应独立于智能体对自身工作的解释。如果目标由智能体选择，正确与否也由它自己判断，同一个初始误解可能连续通过两个步骤。

Odoo 的AI 服务器动作文档将业务规则的执行责任交给工具代码，由 AI 动作选择工具及参数。验收人员仍然需要检查最终业务状态。

这项任务验收应与架构讨论分开。Agent Harness Engineering 指南解释外围执行控制。本文只回答更具体的问题：需要哪些证据，才能接受一次已安排的 CRM 跟进活动？

如何定义一条 CRM 跟进活动的验收要求？

先确定唯一商机引用、获准负责人和绝对截止日期，再列出必须保持不变的已有字段。虚构示例只允许为公司 A 的 OPP-42 创建一条电话活动，分配给用户 7，截止日期为 2026 年 11 月 12 日。同时禁止发送外部邮件。

Odoo 的活动安排文档包含负责人和到期日。这是两个独立条件：日期正确，不能抵消负责人错误。

数据中还有公司 A 的 OPP-43 和公司 B 的 OPP-99。已有活动 ACT-OLD 属于 OPP-43，分配给用户 8，截止日期为 11 月 10 日。这些相邻记录使错误匹配和无关修改能够被检查出来。

下载文件使用 record_ref、assigned_user 等标准化键，它不是 Odoo API 请求体。在已检查的Odoo 20 活动源码中，文档关联使用模型和引用字段；分配与截止日期使用 user_id 和 date_deadline。原生观测组件必须将安装环境中的实际结构映射到约定数据视图。

本例的公司信息来自关联商机。检查器沿着这层关系判断，没有虚构一个活动级公司字段。该视图也不包括聊天记录等技术管理数据。你的部署还需要观察哪些业务字段和通知影响，应另行明确。

为什么要先测试结果检查器？

检查器需要负面样例，因为薄弱的判定规则会让错误流程显得可靠。运行前先确定预期分类，并加入“新活动正确、但其他受保护记录被修改”的情况。这样才能检验验收规则是否表达了业务要求，而不仅是能否识别一个顺利完成的例子。

示例的预期标签与检查函数分别编写。函数读取约定和前后数据视图，返回带原因的 PASS、FAIL 或 UNKNOWN。它不把助手文本或工具报告状态当成写入已经发生的证据。

例如，只要求“至少一条”的计数检查器可能接受两条活动。只寻找新目标行的字段检查器，可能忽略已有活动被修改。因此，验收规则除了核对新行，还要比较受保护的基线。

这种独立性仍有边界。必须有人批准要求，并验证生成数据视图的观测组件。检查器发现不了输入中被省略的字段，也无法证明一个标为“完整”的文件确实包含所有相关副作用。发布证据中必须写明它的覆盖范围。

十三条样例检查得出了什么结果？

本地执行中，十三条人工构造观测全部得到预期分类：2 条 PASS、10 条 FAIL、1 条 UNKNOWN。这只说明所附 Python 演示对这些输入的行为符合预期。由于观测并非由智能体产生，它不能衡量 Odoo 智能体完成任务的成功频率。

将检查器和用例文件下载到同一目录。Python 标准库即可运行：

python3 state-oracle.py

把输出与已记录结果对照。所有分类符合预期时，进程成功退出，其中包括故意设计的 FAIL 用例。因此，脚本成功表示检查器正确识别了这些样例，并不表示十三项业务任务全部通过。

澄清分支采用示意标签 reviewed_disposition。真实测试中，审核人或经过独立验证的适配器必须确认，智能体确实询问了缺失的商机引用。脚本不理解自然语言问题的质量，这个标签也不是 Odoo 文档定义的响应字段。

什么时候 UNKNOWN 才是正确结果？

观测组件无法确认所需最终状态时，应返回 UNKNOWN。记录不可访问、副作用证据不完整或观测窗口尚未确定，都使验收问题保持开放。先保留已知信息并调查观测失败，再决定是否恢复业务动作。读不到结果，并不能证明之前没有写入。

合成列表 outbound_events 只是外部影响证据的替代表示。空列表不能执行禁发邮件的限制。原生演练中，应将消息导向获准测试目的地，并检查相关传输证据。如果活动分配通知与“禁止邮件”要求冲突，应先解决行为，再验收流程。

观测窗口要覆盖任务真实的完成边界。截止时仍在工作的队列属于未决状态，不能自动视为成功或永久失败。把查询范围与截止时间一同记录，审核人才能区分迟到工作与缺失工作。

不要为了得到更好看的响应就重复不确定的写入。Odoo 写入恢复示例单独说明重复风险和恢复决定。

哪些测试仍需要实际 Odoo 环境？

原生验收必须在待审核的具体 Odoo 构建上，运行已配置智能体及其可用工具。使用获准测试身份，并先用已知记录验证观测适配器。随后将实际证据与约定对照，保持两个结论分离：检查器自测通过，不等于智能体已经具备完成任务的能力。

原生验收包包含十六个拟议用例。执行状态为 NOT_RUN，验收状态为 PENDING，观测值为空。记录结果前，应根据已安装模块和任务调整用例。

上线 QA 清单覆盖更广泛的发布决定。此任务包只针对活动流程及其观测证据。

观测组件需要获准访问测试数据。若为核对结果而需要更广视图，也不能把它与智能体本身的运行权限混为一谈。Odoo 20 公司访问测试负责独立的原生授权矩阵。

测试路径能够提供模型或供应商元数据时，应记录下来；无法获得的项目标为不可用。即使模型身份不透明，也要保存工具配置和提示词版本。测试记录描述的是已观测配置，并应标明未经核验的服务细节。

如何评审多次智能体运行？

汇总前先逐次检查。每次都要保留初始数据、准确请求、观测结果，以及 FAIL 或 UNKNOWN 的理由。运行前根据任务后果约定重复次数和可接受差异。十三个检查器样例不是统计试验，不能据此推导生产环境的合格阈值。

除非用例专门测试已有工作，否则重复试验应从等价基线开始。否则第二次运行可能遇到昨天的活动，实际验证了另一个问题。如果流程允许重复送达，应定义它要复用已有活动、先请求确认，还是再创建一条。

业务状态正确性与沟通质量应分别记录。智能体可能保存了正确记录，却给出无用解释；表达流畅也不能弥补错误负责人。两者都重要，但合并成一个总体印象，会让缺陷更难定位。

禁止的外部写入应作为独立失败条件保留，不能在大量简单任务的平均分里消失。合同指标和响应责任可以参考智能体 SLA 模板。本文提供的是一项有限任务的验收证据。

我们会批准什么范围上线？

只有当负责人接受了预期结果、观测范围和原生证据后，才应批准这项有限活动任务。样例检查器能低成本暴露薄弱验收规则，适合作为准备。它必须与真实配置流程的成功观测及必要故障处理证据结合，才能成为发布依据的一部分。

先从普通活动和错误目标反例开始，再加入“新行正确、但旧活动被改变”的用例。这组检查会迫使团队同时写清智能体可以做什么，以及哪些状态必须受到保护。

需要独立发布判断时，Wavect 的软件质量保障服务可以帮助定义并审核证据。准备好任务约定、安装配置和未解决用例。一场绿色演示最有价值的前提，是审核人能清楚解释它究竟证明了什么。