--- title: "Odoo AI 测试：验收已保存的 CRM 活动" canonical: https://wavect.io/zh/blog/odoo-ai-agent-business-state-tests/ language: zh description: "如何测试 Odoo AI 智能体创建的 CRM 活动？用业务状态要求核对目标、负责人、日期与禁止变更。十三条构造观测验证检查器，十六项原生测试仍待执行。" image: "https://wavect.io/img/blog/headers/header_odoo-ai-agent-business-state-tests.png" author: ["Kevin Riedl"] published: "2026-11-05" updated: "2026-11-05" reviewed: "2026-11-05" --- # Odoo AI 智能体测试：验收实际保存的活动记录 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-20-company-access-migration-tests/) 要点速览 先定义允许的活动、必须保护的已有记录和需要澄清的条件。十三条构造观测只验证检查器，不是智能体性能测试。缺少最终观测时应保持 UNKNOWN，不能直接重试写入。十六项原生用例仍未执行，需要实际 Odoo 工作流提供独立证据。 智能体说已经安排了跟进。系统里确实出现一条新活动，负责人正确，截止日期也正确，却关联到了另一条商机。如果测试只检查“有没有创建成功”，就会接受错误结果。 **应依据书面的业务状态要求测试 Odoo AI 智能体。**明确它可以创建什么活动、哪些记录必须保持不变、何时应先请求澄清。先用故意构造的错误观测验证结果检查器，再用它评估实际安装环境中的受控运行。 **资料核验日期：2026 年 11 月 5 日。**产品事实来自 Odoo 20 官方文档和源码。我们将十三条人工构造的 JSON 观测输入 Python 检查器并执行了分类；没有运行 Odoo、AI 模型或邮件服务器。下载的原生验收包是拟议检查，全部标为 `NOT_RUN`。 ## Odoo AI 智能体测试应该证明什么？ 测试应在约定观测范围内证明，允许的业务结果确实发生。请求的写入必须正确，受保护的已有记录必须不变，证据中不得出现禁止的影响。对话顺利结束或工具返回成功，都不能单独证明这些条件。验收依据应指向实际业务状态，而不只是执行过程中的说法。 结果检查器也称测试判定器，它按照约定预期对照观测证据。这条判定规则应独立于智能体对自身工作的解释。如果目标由智能体选择，正确与否也由它自己判断，同一个初始误解可能连续通过两个步骤。 Odoo 的 [AI 服务器动作文档](https://github.com/odoo/documentation/blob/20.0/content/applications/productivity/ai/server-actions.rst) 将业务规则的执行责任交给工具代码，由 AI 动作选择工具及参数。验收人员仍然需要检查最终业务状态。 这项任务验收应与架构讨论分开。 [Agent Harness Engineering 指南](/zh/blog/agent-harness-engineering/) 解释外围执行控制。本文只回答更具体的问题：需要哪些证据，才能接受一次已安排的 CRM 跟进活动？ ## 如何定义一条 CRM 跟进活动的验收要求？ 先确定唯一商机引用、获准负责人和绝对截止日期，再列出必须保持不变的已有字段。虚构示例只允许为公司 A 的 `OPP-42` 创建一条电话活动，分配给用户 7，截止日期为 2026 年 11 月 12 日。同时禁止发送外部邮件。 Odoo 的 [活动安排文档](https://github.com/odoo/documentation/blob/20.0/content/applications/essentials/activities.rst) 包含负责人和到期日。这是两个独立条件：日期正确，不能抵消负责人错误。 | 条件 | 预期结果 | 拒绝原因 | | --- | --- | --- | | 目标 | 新增一条关联 OPP-42 的电话活动。 | 活动关联到名称相似的其他商机。 | | 公司 | 关联商机属于公司 A。 | 使用了公司 B 的引用。 | | 负责人 | 示例用户 7。 | 被替换成请求人或其他销售人员。 | | 截止日期 | 2026-11-12。 | 观测到 2026-11-13。 | | 受保护状态 | 所选商机字段和已有 ACT-OLD 活动保持不变。 | 商机阶段或已有截止日期被修改。 | | 外部影响 | 声明观测范围内没有出站邮件事件。 | 任务产生未批准的外部消息。 | | 歧义请求 | 先询问使用哪条商机，不写业务数据。 | 猜测商机并创建活动。 | 数据中还有公司 A 的 `OPP-43` 和公司 B 的 `OPP-99`。已有活动 `ACT-OLD` 属于 OPP-43，分配给用户 8，截止日期为 11 月 10 日。这些相邻记录使错误匹配和无关修改能够被检查出来。 下载文件使用 `record_ref`、`assigned_user` 等标准化键，它不是 Odoo API 请求体。在已检查的 [Odoo 20 活动源码](https://github.com/odoo/odoo/blob/20.0/addons/mail/models/mail_activity.py) 中，文档关联使用模型和引用字段；分配与截止日期使用 `user_id` 和 `date_deadline`。原生观测组件必须将安装环境中的实际结构映射到约定数据视图。 本例的公司信息来自关联商机。检查器沿着这层关系判断，没有虚构一个活动级公司字段。该视图也不包括聊天记录等技术管理数据。你的部署还需要观察哪些业务字段和通知影响，应另行明确。 ## 为什么要先测试结果检查器？ 检查器需要负面样例，因为薄弱的判定规则会让错误流程显得可靠。运行前先确定预期分类，并加入“新活动正确、但其他受保护记录被修改”的情况。这样才能检验验收规则是否表达了业务要求，而不仅是能否识别一个顺利完成的例子。 示例的预期标签与检查函数分别编写。函数读取约定和前后数据视图，返回带原因的 `PASS`、`FAIL` 或 `UNKNOWN`。它不把助手文本或工具报告状态当成写入已经发生的证据。 例如，只要求“至少一条”的计数检查器可能接受两条活动。只寻找新目标行的字段检查器，可能忽略已有活动被修改。因此，验收规则除了核对新行，还要比较受保护的基线。 这种独立性仍有边界。必须有人批准要求，并验证生成数据视图的观测组件。检查器发现不了输入中被省略的字段，也无法证明一个标为“完整”的文件确实包含所有相关副作用。发布证据中必须写明它的覆盖范围。 ## 十三条样例检查得出了什么结果？ 本地执行中，十三条人工构造观测全部得到预期分类：2 条 PASS、10 条 FAIL、1 条 UNKNOWN。这只说明所附 Python 演示对这些输入的行为符合预期。由于观测并非由智能体产生，它不能衡量 Odoo 智能体完成任务的成功频率。 | 用例 | 构造的最终观测 | 预期／实际 | | --- | --- | --- | | S01 | 新活动正确，受保护状态不变。 | PASS / PASS | | S02 | 有完成消息，但没有新活动。 | FAIL / FAIL | | S03 | 活动指向同一公司的 OPP-43。 | FAIL / FAIL | | S04 | 活动指向公司 B 的 OPP-99。 | FAIL / FAIL | | S05 | 新活动分配给用户 8。 | FAIL / FAIL | | S06 | 截止日期为 11 月 13 日，而非 12 日。 | FAIL / FAIL | | S07 | 创建了两条新活动。 | FAIL / FAIL | | S08 | 活动正确，但 OPP-42 阶段变成赢单。 | FAIL / FAIL | | S09 | 活动正确，同时出现合成的出站邮件事件。 | FAIL / FAIL | | S10 | 歧义请求被猜测为一个目标，并发生写入。 | FAIL / FAIL | | S11 | 提出所需澄清，业务状态不变。 | PASS / PASS | | S12 | 最终观测不可用。 | UNKNOWN / UNKNOWN | | S13 | 新活动正确，但 ACT-OLD 截止日期被修改。 | FAIL / FAIL | 将 [检查器](/downloads/odoo-ai-agent-business-state-tests/state-oracle.py) 和 [用例文件](/downloads/odoo-ai-agent-business-state-tests/state-cases.json) 下载到同一目录。Python 标准库即可运行： ``` python3 state-oracle.py ``` 把输出与 [已记录结果](/downloads/odoo-ai-agent-business-state-tests/model-results.json) 对照。所有分类符合预期时，进程成功退出，其中包括故意设计的 FAIL 用例。因此，脚本成功表示检查器正确识别了这些样例，并不表示十三项业务任务全部通过。 澄清分支采用示意标签 `reviewed_disposition`。真实测试中，审核人或经过独立验证的适配器必须确认，智能体确实询问了缺失的商机引用。脚本不理解自然语言问题的质量，这个标签也不是 Odoo 文档定义的响应字段。 ## 什么时候 UNKNOWN 才是正确结果？ 观测组件无法确认所需最终状态时，应返回 UNKNOWN。记录不可访问、副作用证据不完整或观测窗口尚未确定，都使验收问题保持开放。先保留已知信息并调查观测失败，再决定是否恢复业务动作。读不到结果，并不能证明之前没有写入。 | 观测 | 能够证明什么 | 仍有哪些未知 | | --- | --- | --- | | 完整的约定业务数据视图 | 所包含记录是否符合要求。 | 未包含字段与外部影响。 | | 工具响应或聊天文本 | 系统报告了什么。 | 预期结果是否真正持久化。 | | 受控邮件接收端与传输证据 | 测试路径内观测到的消息尝试。 | 未观测连接器或其他路径。 | | 最终读取失败或不完整 | 证据不足。 | 业务结果继续保持 UNKNOWN。 | 合成列表 `outbound_events` 只是外部影响证据的替代表示。空列表不能执行禁发邮件的限制。原生演练中，应将消息导向获准测试目的地，并检查相关传输证据。如果活动分配通知与“禁止邮件”要求冲突，应先解决行为，再验收流程。 观测窗口要覆盖任务真实的完成边界。截止时仍在工作的队列属于未决状态，不能自动视为成功或永久失败。把查询范围与截止时间一同记录，审核人才能区分迟到工作与缺失工作。 不要为了得到更好看的响应就重复不确定的写入。 [Odoo 写入恢复示例](/zh/blog/odoo-n8n-idempotency-recovery/) 单独说明重复风险和恢复决定。 ## 哪些测试仍需要实际 Odoo 环境？ 原生验收必须在待审核的具体 Odoo 构建上，运行已配置智能体及其可用工具。使用获准测试身份，并先用已知记录验证观测适配器。随后将实际证据与约定对照，保持两个结论分离：检查器自测通过，不等于智能体已经具备完成任务的能力。 [原生验收包](/downloads/odoo-ai-agent-business-state-tests/native-acceptance.json) 包含十六个拟议用例。执行状态为 `NOT_RUN`，验收状态为 `PENDING`，观测值为空。记录结果前，应根据已安装模块和任务调整用例。 | 测试领域 | 需要采集的证据 | 支持的决定 | | --- | --- | --- | | 观测适配器 | 已知原生记录与标准化数据视图的对照。 | 检查器读取的是正确字段与关系。 | | 普通任务 | 初始快照、原始请求、最终活动与受保护记录。 | 已配置智能体能完成允许的任务。 | | 身份与公司 | 智能体用户、公司上下文、允许目标与被拒绝选项。 | 运行采用预期权限。 | | 歧义 | 匹配两条商机的请求、澄清内容和未变业务状态。 | 流程等待缺失信息。 | | 外部影响 | 受控发送路径和已观测消息尝试。 | 真实通知行为符合要求。 | | 观测中断 | 已知运行标识、不完整证据和恢复决定。 | 未知结果不会触发盲目重试。 | | 配置变化 | 构建、工具、提示词标识与重复执行的已验收用例。 | 既有结果仍适用于修改后的流程。 | [上线 QA 清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 覆盖更广泛的发布决定。此任务包只针对活动流程及其观测证据。 观测组件需要获准访问测试数据。若为核对结果而需要更广视图，也不能把它与智能体本身的运行权限混为一谈。 [Odoo 20 公司访问测试](/zh/blog/odoo-20-company-access-migration-tests/) 负责独立的原生授权矩阵。 测试路径能够提供模型或供应商元数据时，应记录下来；无法获得的项目标为不可用。即使模型身份不透明，也要保存工具配置和提示词版本。测试记录描述的是已观测配置，并应标明未经核验的服务细节。 ## 如何评审多次智能体运行？ 汇总前先逐次检查。每次都要保留初始数据、准确请求、观测结果，以及 FAIL 或 UNKNOWN 的理由。运行前根据任务后果约定重复次数和可接受差异。十三个检查器样例不是统计试验，不能据此推导生产环境的合格阈值。 除非用例专门测试已有工作，否则重复试验应从等价基线开始。否则第二次运行可能遇到昨天的活动，实际验证了另一个问题。如果流程允许重复送达，应定义它要复用已有活动、先请求确认，还是再创建一条。 业务状态正确性与沟通质量应分别记录。智能体可能保存了正确记录，却给出无用解释；表达流畅也不能弥补错误负责人。两者都重要，但合并成一个总体印象，会让缺陷更难定位。 禁止的外部写入应作为独立失败条件保留，不能在大量简单任务的平均分里消失。合同指标和响应责任可以参考 [智能体 SLA 模板](/zh/blog/ai-agent-sla-template/) 。本文提供的是一项有限任务的验收证据。 ## 我们会批准什么范围上线？ 只有当负责人接受了预期结果、观测范围和原生证据后，才应批准这项有限活动任务。样例检查器能低成本暴露薄弱验收规则，适合作为准备。它必须与真实配置流程的成功观测及必要故障处理证据结合，才能成为发布依据的一部分。 先从普通活动和错误目标反例开始，再加入“新行正确、但旧活动被改变”的用例。这组检查会迫使团队同时写清智能体可以做什么，以及哪些状态必须受到保护。 需要独立发布判断时，Wavect 的 [软件质量保障服务](/zh/services/software-quality-assurance/) 可以帮助定义并审核证据。准备好任务约定、安装配置和未解决用例。一场绿色演示最有价值的前提，是审核人能清楚解释它究竟证明了什么。 ## Odoo AI 智能体测试常见问题 ### 工具调用成功能证明活动创建正确吗？ 除非有独立证据，它只能证明工具报告了成功。应检查目标商机、负责人和截止日期，再检查受保护记录与声明的副作用。验收约定决定必须观察哪些事实，一个通用成功标记不能代替这些证据。 ### 一张截图足够吗？ 截图有助于理解用户看到了什么，但可能省略记录身份、被筛掉的行或其他位置的异常修改。应保留准确请求和可复现的业务字段观测。当界面本身属于验收范围时，截图可以提供补充支持，而不是替代完整数据检查。 ### 能否用第二个语言模型给结果评分？ 模型可以辅助评审有歧义的文字，但精确记录引用和日期适合确定性比较。预期状态应由独立负责人掌握，并验证观测组件。如果模型判断沟通质量，应把该结论与业务状态结果分开记录；标签仍不确定时加入人工审核。 ### 样例中的 PASS 比例是在衡量 Odoo AI 吗？ 不是。十三条观测是刻意构造的，没有一条由 AI 生成。两条应满足要求，十条应失败，一条缺少最终证据。检查器成功运行表示十三个分类都符合预设标签，并不说明智能体在真实任务中有多高成功率。 ### 每个智能体必须使用完全相同的工具吗？ 不同实现可以达到相同的允许业务结果。应验证最终状态，同时执行各自获准的工具和权限边界。步骤不同仍可能符合要求。即使目标活动看似正确，未批准的外部消息或过大的权限仍然是需要处理的问题。 ### 为什么请求澄清也能算通过？ 有些请求无法唯一确定允许的动作。歧义样例中，成功意味着询问缺失商机引用，并保持业务记录不变。审核人必须确认澄清证据。在信息未明确前创建一条看似合理的活动仍然失败，不能因智能体语气自信而接受。 ### 观测结果不确定时应该重新运行任务吗？ 先调查原运行已知情况。写入可能已经完成，只是观测失败。保留运行标识，检查目标状态，并按流程的恢复规则处理。没有消除不确定性就重复写入，可能创建第二条活动，把观测问题变成业务缺陷。 QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [AI 生成的 Odoo 模块：先审业务规则，再谈上线](/zh/blog/ai-generated-odoo-module-audit/) - [Odoo 迁移验收：逐条核对业务记录与余额](/zh/blog/odoo-migration-acceptance-reconciliation/) - [Odoo 20 权限迁移：如何验收多公司隔离？](/zh/blog/odoo-20-company-access-migration-tests/) - [Odoo 19 升级 20：AI 工作流要重新验收什么？](/zh/blog/odoo-19-20-ai-upgrade-readiness/) [上一篇文章**Odoo 迁移验收：逐条核对业务记录与余额**](/zh/blog/odoo-migration-acceptance-reconciliation/) [下一篇文章**Odoo 20 权限迁移：如何验收多公司隔离？**](/zh/blog/odoo-20-company-access-migration-tests/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年11月5日 最近审核 2026年11月5日 [**下一篇**](/zh/blog/odoo-20-company-access-migration-tests/)